Currently, when the avoid bad wifi setting changes, we rematch
all networks and requests, but do not update any NetworkFactories
with new scores. This means that if a wifi network's score goes
down as a result of enabling bad wifi avoidance, we will not look
for another network (e.g., cell data) to satisfy its requests.
This makes it so that when the user enables avoiding bad wifi,
we will attempt to bring up cell data will if it is not already
connected.
Bug: 31075769
Change-Id: Ie5b685be8676999adea8c9ecbbc1abb92f81a74f
Lorenzo Colitticommited 2016-09-21 15:10:14 +09:00
This contains the following changes:
1. Make NETWORK_AVOID_BAD_WIFI a tristate: 0 means never avoid
bad wifi, unset means prompt the user, 1 means always avoid.
2. Look at NETWORK_AVOID_BAD_WIFI only if the carrier restricts
avoiding bad wifi (previously, we relied on the setting being
null and defaulting to the value of the config variable).
3. Add an avoidUnvalidated bit to NetworkAgentInfo to track
whether the user has requested switching away from this
unvalidated network even though avoiding bad wifi is generally
disabled. This is set to true when the user selects "switch"
in the dialog without setting the "Don't ask again" checkbox.
4. Add a hidden setAvoidUnvalidated API to ConnectivityManager to
set the avoidUnvalidated bit.
5. Additional unit test coverage.
Bug: 31075769
Change-Id: I1be60c3016c8095df3c4752330149ce638bd0ce1
Lorenzo Colitticommited 2016-09-20 16:03:53 +09:00
Currently, every call to avoidBadWifi fetches the current value
of the config variable and setting whenever it is called. This
means that the score of an unvalidated wifi network can
unpredictably change at any time, creating a data race.
Instead, persist the value and only update it when something
changes.
Bug: 31075769
Change-Id: I0f4e0e742c91ef77fabc95d3ebb494338396aca5
Lorenzo Colitticommited 2016-09-17 00:57:38 +09:00
This patch adds a way to configure devices so that a validated network
that becomes unvalidated is not penalized in the network scoring and
selection logic.
The intent is to prevent devices configured to do so from switching to a
lower scoring network such as cellular networks when a higher scoring
network such as wifi networks loses internet connectivity.
Bug: 31075769
Change-Id: Ie7e0f2607d214a178367fedfbef6c44768fa00a4
This allows simplification of getCurrentScore function in
NetworkAgentInfo and its return value to depend on everValidated and
lastValidated.
Bug: 31075769
Change-Id: I0b3c85e3a61b006733e900e0a231424878317476
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
Lorenzo Colitticommited 2016-09-09 18:49:24 +09:00
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
Lorenzo Colitticommited 2016-09-09 18:28:00 +09:00
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
Lorenzo Colittiauthored and Hugo Benichicommited 2016-08-31 00:36:11 +09:00
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
Lorenzo Colitticommited 2016-08-29 16:30:21 +09:00
Lorenzo Colitti
authored and
android-build-merger
commited 
Hugo Benichi
authored and
Felipe Leme
commited