Like a normal (foreground) request, a background request is only
satisfied by one network and will keep that network up. Unlike a
foreground request, when a network only has background requests,
it will linger, and after lingering is complete, it will become
a background network.
Future CLs will cause the system to treat background networks
differently, e.g., by requiring different permissions.
Bug: 23113288
Change-Id: I40f735269dad1042eb04fea15e64584fc903ccb3
This CL splits rematching in two parts: first rematch requests,
then rematch listens. This will allow us to change a network's
capabilities depending on what requests are on that network, and
properly dispatch callbacks depending on those capabilities.
The behaviour changes are as follows:
- Before this CL, callbacks for requests and listens were sent
intermingled. After this CL, all request callbacks will be
grouped together, and all listen callbacks will be grouped
together.
- Before this CL, the order was:
1. Send onLost callbacks.
2. If applicable, switch the default network.
3. Send onAvailable callbacks.
After this CL, the order is:
1. Send onLost callbacks for requests.
2. If applicable, switch the default network.
3. Send onLost callbacks for listens.
4. Send onAvailable callbacks for listens.
5. Send onAvailable callbacks for requests.
These changes shouldn't affect any apps because:
1. The order of callbacks continues to be first all onLost,
then all onAvailable.
2. Both the old and the new code send callbacks in no particular
order. Thus, the possible ordering combinations of callbacks
in the new code are a strict subset of the possible ordering
combinations of the old code.
3. The default network is switched before any onAvailable
callback is sent.
4. Even though the new code does not send all onLost callbacks
before switching the default network, even before this CL
there was no guarantee that those callbacks would be received
before the default network switch anyway, because callbacks
are asynchronous.
Bug: 23113288
Change-Id: Ia08900c50db9ff43895047e2f4f36b6c6c31a1f9
Add TRANSPORT_WIFI_NAN - specifies a peer-to-peer Wi-Fi NAN data
connectivity request.
While NAN uses Wi-Fi L1 PHY and part of the MAC - it is a different
protocol and constitutes a different transport.
(cherry-pick of commit 7473bc20ad)
Bug: 26564277
Change-Id: I975ebc72d8f97a592d18038b3d6465b7a40efa75
Methods onRestrictBackgroundWhitelistChanged() and
onRestrictBackgroundBlacklistChanged() were replaced by a more generic
onUidPoliciesChanged().
Test: m javac-check RUN_ERROR_PRONE=true
Test: m -j32 FrameworksServicesTests && adb install -r -g ${ANDROID_PRODUCT_OUT}/data/app/FrameworksServicesTests/FrameworksServicesTests.apk && adb shell am instrument -e class "com.android.server.NetworkPolicyManagerServiceTest" -w "com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner"
BUG: 28791717
Change-Id: I18b2ee4af06802e0d23822b153d1be9b429d5811
This patch adds a daily limit to the maximum number of notifications
shown when switching networks.
It also adds a rate limit to prevent rapid successive notifications in
flapping scenarios.
Bug: 31132499
Change-Id: Iccb6d0899646ea6df3cfad32a421922263e0eb85
Sometimes we switch away from a network to another (e.g., wifi to
cell data) not because the old network is unvalidated, but
because the score is lowered by a low signal strength.
In this case, don't notify the user of a network switch.
Bug: 31132499
Change-Id: I996a6e00096f8cb864fa9b00b36921725a4edb53
1. Move from deprecated network types to transport types.
2. Rename and simplify (by passing in a NetworkAgentInfo object)
the call signature of the method that displays notifications.
3. Add a method to clear notification, and unindent lots of code.
4. Move the legacy DcTracker-issued notification code to
NetworkNotificationManager.
Bug: 31025214
Change-Id: Ie49c60126d0ed5bac620bc47e84fe038791b2d6c
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
