Most tests were failing because due to a null NetworkCapabilities.
Example:
1) testNetworkStatsWifi(com.android.server.net.NetworkStatsServiceTest)
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.net.NetworkCapabilities.hasCapability(int)' on a null object reference
at
com.android.server.net.NetworkStatsService.updateIfacesLocked(NetworkStatsService.java:983)
BUG: 30839080
Change-Id: Ib81d81df2828fc573c40b26c23af9d80ae43d3f6
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
Change-Id: I62a75a0c0c0111e052b7903baa9f5d6d94ef57fd
Similarly to ApfTest, this patch changes ConnectivityServiceTest to use
a mock object instead of IpConnectivityLog so that running
ConnectivityServiceTest does not generate android.net.metrics events.
Bug: 30450301
Change-Id: Ibc0479f381f26e60baefbae15407c62aecbf6666
This patch creates a new permission used by ConnectivityService to give
access to restricted networks without the NET_CAPABILITY_NOT_RESTRICTED
capability bit on.
Bug: 24497316
Change-Id: I5b6c8a9ef14395b2f1ab26cb17b24d7876ec79f1
Add an IPv6TetheringCoordinator to TetheringMaster StateMachine, which
receives and processes NetworkState updates and passes the necessary IPv6
information to the revelant TetherInterfaceStateMachine.
Add an IPv6TetheringInterfaceServices to TetherInterfaceStateMachine, which
is responsible for adding local network routes and managing an IPv6
RouterAdvertisementDaemon.
Bug: 9580643
Change-Id: I3eaae460b80752e2115359d7bde873a1e9ea515a
This patch adds synchronization inside LegacyTypeTracker so that
getNetworkForType() can safely run concurrently with remove().
Without synchronization if remove() removes the last network for a
given type while getNetworkForType() runs for the same type, it is
possible that getNetworkForType tries to access the head of an empty
list, resulting in a runtime exception.
This issue was found by zoran.jovanovic@sonymobile.com who proposed a
fix in AOSP (Change-Id: Ia963662edb9d643790e8d9439e4dbdcac4c2187b).
This patch differs from the fix proposed by the bug reporter and tries
instead to do the minimum amount of locking to make getNetworkForType
safe.
Bug: 29030387
(cherry picked from commit 9c807fdcd4)
Change-Id: I915aac527fc8828b32bf35fee870add2dfb11d8d
This patch adds NetworkInfo BLOCKED/UNBLOCKED status of apps to
ConnectivityService's dump logs.
The BLOCKED or UNBLOCKED status of an app is logged with the app uid
when the app calls getActiveNetworkInfo().
Examples:
mNetworkInfoBlockingLogs (most recent first):
07-11 11:04:43.139 - BLOCKED 10060
07-11 11:04:39.056 - UNBLOCKED 10061
07-11 11:04:38.851 - BLOCKED 10061
Bug: 29981766
Change-Id: I6e2fde446702b92b0964ed894409b5d733d8f8a7
The two major changes here are:
- Move lingering out of NetworkMonitor. The fact that lingering
is currently its own state in NetworkMonitor complicates the
logic there: while a network is lingering it cannot be in any
other state, we have to take care not to leave LingeringState
for the wrong reason, etc.
- Instead of keeping a single per-network boolean to indicate
whether a network is lingered or not, keep a linger timer for
every request. This allows us to fix various corner-case bugs
in lingering.
The changes in behaviour compared to the current code can be seen
in the unit test changes. Specifically:
1. Bug fix: when a network is lingered, and a request is added
and removed to it, the existing code tears the network down
immediately. The new code just sends another CALLBACK_LOSING
and resumes lingering with the original timeout.
2. Bug fix: if cell is unvalidated and wifi comes up and
validates before cell does (as might happen on boot), the
existing code immediately tears down cell. The new code
lingers cell, which is correct because unvalidated cell was
the default network, so an app might have been using it.
3. Correctness improvement: always send CALLBACK_AVAILABLE for
the new network before sending CALLBACK_LOSING. This was not
really an issue in practice, because the usual flow is:
- Network A is the default.
- Network B connects, CALLBACK_AVAILABLE.
- Network B validates, CALLBACK_LOSING.
Bug: 23113288
Change-Id: I2f1e779ff6eb869e62921a95aa9d356f380cf30a
As explained in the TODO, the loop serves no purpose since only
one network can be satisfying a given request at a time.
Instead of looping, look up the nai in the mNetworkForRequestId
array that exists for this purpose.
Keep the loop around with an Slog.wtf statement on it so we can
see if we ever hit it, and add a TODO to delete it if we don't.
Bug: 23113288
Change-Id: I173de4bd45c5a4169b7a062a981f2ecccaa44143
