This will let ConnectivityService send the right callbacks to the
relevant apps.
Test: manual with apps
runtest frameworks-net
cts
new tests for this functionality
Bug: 67408339
Change-Id: I6f08efd9e73c7e191f833d7f307a3bf4c9e2f0b4
Useful for clients such as BatteryStats which currently rely
on NetworkStatsFactory. Data at that stage is incomplete as
it does not account for tethering, VT data and corresponding
464xlat corrections.
Test: runtest frameworks-net, CTS tests pass.
Change-Id: I763b77f601c827fd2963204694fb5b45425cc791
Currently, when a network goes into CONNECTED state, we call
updateLinkProperties and then notifyIfacesChangedForNetworkStats.
The latter is unnecessary, as there are exactly two cases:
1. networkAgent.linkProperties != null: updateLinkProperties will
call notifyIfacesChangedForNetworkStats, because oldLp is null
and networkAgent.linkProperties is not null.
2. networkAgent.linkProperties is null: there is no need to call
notifyIfacesChangedForNetworkStats, because no interfaces were
added or removed. When they are, updateLinkProperties will be
called again.
Removing the call to notifyIfacesChangedForNetworkStats avoids
a stats poll, which is a minor performance improvement.
Also, remove the NetworkStatsService code to do asynchronous
interface updates, since it has no callers.
Bug: 72107146
Test: builds, boots
Test: runtest frameworks-net
Change-Id: I9337ea26c0505a1c66ceda01254b68e25cd7972c
Fix test breakages I caused when adding cell
support for NATT keepalives.
-Make the minimum keepalive interval a constant in
ConnectivityManager and use it in tests.
-Re-Disallow IPv6 Keepalives
Bug: 73327535
Test: 'runtest -x ConnectivityServiceTest' now passes
Change-Id: I5ec4367d250ee371014e65c897c3897a25a05e2d
This has no concrete impact on the behavior of ConnectivityService,
but in principle TRACK_DEFAULT requests should not be counted toward
requests that make a network foreground. It does not have an impact
because only VPNs could be affected by this, and VPNs are always in
the foreground by definition.
Test: runtest frameworks-net
Test: cts
Change-Id: Id2ae6b5c9d542fe168e64ed713b6ec0a04062c82
NOT_SUSPENDED and FOREGROUND are capabilities that need to
be public so as to reach feature parity with what information
can be gotten through the use of CONNECTIVITY_ACTION and
synchronous calls to ConnectivityManager. This change makes
them public, and wires up the NOT_SUSPENDED capability.
This deprecates in effect the old onSuspended and onResumed
callbacks, but these have never been public.
This also converts the onAvailable path from a multiple
binder call design to a simpler, single binder call. This
is only for internal convenience
Test: runtest frameworks-net
Test: cts
Test: also manual testing
Change-Id: I6ea524bb361ecef0569ea2f9006c1e516378bc25
Prior to this change ConnectivityManager used to patch in the UID
of the requesting app inside the NetworkCapabilities sent to it.
The rationale was that the app may not know what other apps may
use the network, so the view it should have of the network should
always say the network only applies to that app.
But this has an unfortunate side effect : apps can't match the
received network against a default NetworkCapabilities. Ostensibly
this only applies to the system because all involved calls are
@hide, but still : system code would get some NetworkCapabilities,
for example using networkCapabilitiesForType, and then try to
match the capabilities of an available network using
satisfiedByNetworkCapabilities. Because the passed network is
declared to only apply to one's own UID and the UIDs of the
NetworkCapabilities are set to null meaning "I need this network
to apply to all UIDs", the answer will be "false".
While this is WAI in a sense, it is very counter-intuitive that
code trying to match a network would be required to patch in its
own UIDs.
There are three ways of fixing this :
1. Require all apps to do the above. It's correct, but it's
cumbersome and counterintuitive. Multiple places in existing
code needs to be fixed, Tethering is an example.
2. Write the UIDs of the caller in any NetworkCapabilities object
that is created. This is not very practical, because it imposes
the converse requirement on all NetworkAgents, which would then
have to clear the UIDs before they send the capabilities to
ConnectivityService. All NetworkAgents need to be fixed.
3. Instead of sending an object with a list of one UID to apps,
send a null list. The drawback is that the networks nominally
look to apps like they apply to all apps. I argue this does
not matter ; what matters is that the UID lists do not leak.
Clients just see a null list of UIDs (and third party can't
even access them without using reflection). No other changes
are required besides this two-line patch.
This patch implements 3. I believe it is the saner approach, with
both the most intuitive behavior and the best backward compatibility
characteristics, as well as the easiest change.
This does not encroach on the future plans to make the actual
UID list available to apps with NETWORK_SETTINGS.
Test: runtest frameworks-net
Change-Id: I978d91197668119e051c24e1d04aafe1644a41cf
KeepalivePacketData currently mixes multiple concepts: the
list of parameters that are used to generate a keepalive
packet, the keepalive packet itself, and the parameters that
are needed to send a keepalive packet over an ethernet link.
The KeepalivePacketData is now a parcelable that can be used
generically by any NetworkAgent, regardless of how that Agent
fulfills its duty to initiate and maintain a keepalive session.
Bug: 69063212
Test: verified with SL4A, additional tests pending
Merged-In: I23dc4827ae729583356a8ff0f02e39a2ad2b81f5
Change-Id: I23dc4827ae729583356a8ff0f02e39a2ad2b81f5
(cherry picked from commit 5be3f5a2b1)
Due to an issue resolving the boot classpath, the
KeepalivePacketData structure cannot be referenced
by frameworks/opt/telephony while it is in services.
-Move KeepalivePacketData to android.net
-Also, relocate IpUtils without changing the package
name.
Bug: 38350389
Test: compilation
Merged-In: If5fc63e9ad8b9b2d4c2fee47ff4bab2ab190a05a
Change-Id: If5fc63e9ad8b9b2d4c2fee47ff4bab2ab190a05a
(cherry picked from commit f8a2bc3eee)
This change adds one KernelResourceRecord type (TunnelInterfaceRecord),
and adds methods for the creation of TunnelInterfaces, as well as the
application of Transforms to the given TunnelInterfaces
As part of the generation of ikeys/okeys, a ReserveKeyTracker manages a
java bitset to avoid collisions and reserve/release keys.
Bug: 63588681
Test: Compiles, CTS, unit tests all pass on AOSP_marlin
Change-Id: I9e9b6455e27073acd4491eae666aa966b3b10e0f
Also audit all constants, make some private, annotate some
with @VisibleForTesting.
Test: runtest framework && cts
Change-Id: Iaf5ea7abd36fd8d544dcc84654f6cb529196d654
* changes:
Track and persist in stats whether traffic is on the default network.
Add the default network to NetworkStats and NetworkStatsCollection.
Pass all default networks to NetworkStatsService
This will allow NetworkStatsService to treat traffic on these
networks differently from traffic where the app selects a network
that is not the default.
Bug: 35142602
Test: runtest frameworks-net
Change-Id: I5ea9d200d9fb153490c6108bb9390bf152f297da
In a future set of CLs, NPMS will offer to override a handful of
capabilities on a per-subId basis. Define a no-op version of the
interface to make it easier to add new methods in the future.
Test: bit FrameworksNetTests:android.net.,com.android.server.net.
Test: bit FrameworksTelephonyTests:com.android.internal.telephony.dataconnection.DataConnectionTest
Bug: 64133169
Change-Id: I03dfd98463861f0338c4174e8d8a88c300ea5b55
In future, managing DNS-over-TLS hostname lookup and netd programming
can be encapsulated here.
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
Bug: 64133961
Change-Id: I47ccfa99c30c780524c45c4af605e720ccba34a0
The mLockdownEnabled boolean and the mLockdownTracker objects are read
and mutated in many places involving vpn logic inside of
ConnectivityService. This includes codepaths run on the
ConnectivityService handler and codepaths run on Binder calls from
IConnectivityManager.aidl, however the access to these variables are not
synchronized.
This patch adds proper synchronization to mLockdownEnabled and
mLockdownTracker by moving access to them into the mVpns lock used for
all of vpn logic.
Bug: 18331877
Test: runtest frameworks-net
Change-Id: I4abde43b1036861f4486dd2b5567782d10204bd6
This patch fixes a regression introduced by commit d5c11bbb65
for logging NetworkEvents when lingering and unlingering a network.
Commit d5c11bbb65 removed an overloaded constructor for the
NetworkEvent class, which caused NetworkEvents with event type of
LINGER or UNLINGER logged in ConnectivityService to have incorrect
event types (set to the network id instead) and incorrect duration
(set as the event type instead).
Bug: 34901696
Test: runtest frameworks-net
Change-Id: Iab97a58ca805413617c8e8b4553404625a820ceb
This patch changes instrumentation of default networks and default
network events:
- stop logging events for default network transitions,
but instead consistently log one event per continuous segment
when one given network was the default, including logging an
event for when there is no default network.
- keep a separate rolling buffer of DefaultNetworkEvent for
dumpsys and bug reports.
These changes allow to simplify post aggregation of default network
event metrics by removing any need to do time series processing.
Instead, metrics and counters can be implemented withouth any ambiguity
by following the recipe:
% of x = sum(duration | x = true) / sum (all durations)
where x can be various conditions such as:
- the default network was validated
- the default network was WiFi
- the default network was IPv6
- there was no default network
- ...
Most importantly, this new logging scheme allows to measure much more
reliably:
- the % of the time that a device had Internet, in the sense that the
default network was validated.
- the time transitions between default networks, keyed by previous and
new transports/link layer, which allows to derive wakelock durations
and wakelock power costs from default network switches.
This patch also simplifies the dumpsys interface of the connmetrics
service and reduces the commands to three:
- "flush" for metrics upload.
- "proto" for printing buffered event in text proto format.
- "list" for listing all events and statistics.
Bug: 34901696
Bug: 65700460
Test: runtest frameworks-net
Change-Id: I0521f1681a60cca07ac3bfd5741d64ce44de4cdd
The "roaming" state of a network really belongs on NetworkCapabilities
instead of being published through NetworkInfo.isRoaming(). One major
reason is to support developers creating NetworkRequests for a
non-roaming network.
Watch for any capability changes that network statistics are
interested in (either metered or roaming) and notify it to perform
an update pass; fixes bug where we previously only triggered on
roaming changes.
Fix bug in VPNs where metered/roaming capabilities of underlying
networks weren't being propagated; this was probably preventing
some jobs from running over unmetered networks, and causing other
jobs to run over roaming networks! Also passes along link bandwidth
information from underlying networks, and propegates any changes
to underlying networks.
Fix race condition by reading prevNc inside lock. Utility methods
correctly calculate min/max link bandwidth values.
Test: bit FrameworksNetTests:android.net.,com.android.server.net.,com.android.server.connectivity.,com.android.server.ConnectivityServiceTest
Bug: 68397798, 16207332
Change-Id: I3e1a6544c902bf3a79356b72d3616af1fd2b0f49
This patch extracts the logging of DefaultNetworkEvent from inside
ConnectivityService and move it to a new DefaultNetworkMetrics class.
The DefaultNetworkMetrics is a singleton owned by the
IpConnectivityMetrics singleton implementing the metrics service for
core networking. ConnectivityService has access to this singleton via
LocalServices.
This class layout will allow to remove the Parcelable interface of
DefaultNetworkEvent and will instead let the IpConnectivityMetrics
service grab metrics from the DefaultNetworkMetrics directly.
Bug: 34901696
Test: runtest frameworks-net
Change-Id: I55694d89124272732aba114198776462372de18b
This only worked on broadcom devices, and was superseded in
M by a wifi HAL call made by IpManager.
Test: bullhead builds, boots
Change-Id: I711cae7dafe171c2c8b4e84a229adbcad27f3d14
On some devices, support for TYPE_ETHERNET is not specified in
the networkAttributes config resource, even though the device is
capable of supporting Ethernet (e.g., via USB host adapters).
This leads to Ethernet working but various connectivity APIs
behaving as if it was not - for example, no CONNECTIVITY_ACTION
broadcasts will be issues when it connects or disconnects.
Ensure that ConnectivityService always treats Ethernet as
available if the service is running. Currently the service is
started if the device supports FEATURE_ETHERNET or
FEATURE_USB_HOST.
Bug: 37359230
Test: bullhead builds, boots
Test: ConnectivityServiceTest passes
Test: Ethernet is available even if removed from networkAttributes resource
Test: ConnectivityManagerTest CTS test passes
Change-Id: I58801bf4f0bbdc3ff6345ec6bfdc911ce045c8ab
adds privileged permission for getCaptivePortalServerUrl
adds tether privileged permission for
startTethering,isTetheringSupported
bug:62348162
Test: make and manual testing
Change-Id: I8eb8e3c9dcd7201abe9ea303ee57fe99073d67eb
