During IpManager startup, anything sending messages to the state machine
must not begin doing so until after the state machine has been started.
Reorder the constructor accordingly.
During shutdown, AvoidBadWifiTracker needs to unregister the registered
BroadcastReceiver and might as well also unregister the ContentObserver.
Bug: 33388922
Change-Id: I58e07f7ccddaab160c153bcfb69fd45f50bb8710
This patch improves system logging around captive portal detection to
make inspection of bug reports sligthly easier:
- NetworkMonitor now logs by default CMD_CAPTIVE_PORTAL_RECHECK and
CMD_CAPTIVE_PORTAL_APP_FINISHED. Other system logs are kept off with
a new VDBG boolean contant,
- NetworkNotificationManager now prints the notification id at
notification time. This allows to easily correlate show and clear.
- errors in NetworkNotificationManager are logged as Throwable instead
of through their implicit toString() method.
Test: $ runtest frameworks-net
Bug: 32198726
(cherry picked from commit 6fe7d3cdb3)
Change-Id: I7780c389a94c4b9fa226f53b02fe5960d1c08618
Test: ConnectivityServiceTest updated with test cases.
Test: Manually tested against att-wifi in B42.
Bug: 30222699
Change-Id: Ibe63942da04748ab0406e24e0f44be31d47710a0
(cherry picked from commit 3fd101e574)
Additionally, add this utility class to IpManager for compatibility
verification. A follow-on CL will make use of IpManager's local
AvoidBadWifiTracker.
Bug: 31827713
Change-Id: If8c56c3f8076d6a5157ea180e361bbdadc2bc1dd
Erik Klineauthored and Lorenzo Colitticommited 2016-10-04 15:07:42 +09:00
(cherry-pick of d73faf07606d40d3915d22a72fa14f7ba956d459)
No longer do this in ConnectivityService#tether/untether.
Instead, have Tethering do it when an interface is actually
tethered.
Bug: 31405407
Test: Toggling hotspot now disables data saver
Change-Id: I9910a2e488c30c92d45f817c8f5df0fac5510de6
Christopher Wileycommited 2016-09-30 10:33:19 -07:00
This patch defines new Settings symbols for
- setting the probe urls for captive portal detection.
- setting which User-Agent to use for captive portal detection.
The existing default values for these settings are not changed, i.e:
- HTTP and HTTPS probes urls are unchanged.
- the fallback probe is not used.
- User-Agent is empty by default.
Bug: 29367974
Change-Id: I6e4b3b172e56b8b67fffa4b51f776d68d5851f25
When a network goes into the background, tell netd to set the
network's permission to NETWORK. Also, close all TCP sockets on
that network, to prevent long-lived TCP connections from staying
on it and possibly continuing to use metered data.
Bug: 23113288
Change-Id: Ie89c1940b6739160e25c6e9022b8b977afb3e16e
Lorenzo Colitticommited 2016-09-23 11:27:13 +09:00
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
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
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
Lorenzo Colitticommited 2016-08-23 17:57:46 +09:00
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
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
Lorenzo Colitticommited 2016-07-07 16:18:57 +09:00
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
Lorenzo Colitticommited 2016-07-07 14:50:12 +09:00
http://ag/1194313 broke unregisterNetworkCallback because the
system does not parcel the type of the request back to the app.
So when the app calls unregisterNetworkCallback, the
NetworkRequest that's passed in does not have a type and thus
doesn't match the request in mNetworkRequests.
Fix this by parceling over the type as well.
This was not caught by the unit test because the unit test all
runs in the same process with no parceling.
Bug: 23113288
Change-Id: I58b2ed651b9bf5cbdcca5b25c3ca24db53cffdf1
Lorenzo Colitticommited 2016-07-05 01:59:49 +09:00
Ensure every public method is annotated with why it's public.
This can be either an @Override or @VisibleForTesting annotation
or a comment explaining why it's public.
Bug: 29927488
Change-Id: I3582aef7997dc0d723718ca5e3dd115647d22979
Lorenzo Colitticommited 2016-07-04 12:58:29 +09:00
This allows us to keep track of how many live requests a network
is satisfying without having to count them every time.
Bug: 23113288
Change-Id: Ic4756676491e09071dbf80b7c48da3be028d68eb
Lorenzo Colitticommited 2016-07-01 21:14:26 +09:00
This will allow us to simplify code that deals with
NetworkRequests outside ConnectivityService.
Bug: 23113288
Change-Id: I9b3a859d0c68cad73d7f6baa4b584d13ffd2ae36
Lorenzo Colitticommited 2016-07-01 20:15:19 +09:00
This patch removes static methods for logging IP connectivity events
defined in android.net.metrics and replaces them with a single log()
instance method defined on IpConnectivityLog. Event constructors are
now public also. Every classes logging such events now create an
instance of IpConnectivityLog for logging event objects directly
instantiated with new.
Removing static dependencies allow straightforward testing of logging.
This patch also removes the base IpConnectivityEvent class which is not
needed any more.
Bug: 29035129
Change-Id: I3de700f93f46deaa48a759f938f7d00e1d8bff98
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
Change-Id: I915aac527fc8828b32bf35fee870add2dfb11d8d
Hugo Benichi
commited 
Erik Kline
commited 
Calvin On
commited 
android-build-merger
commited 
Lorenzo Colitti
commited 
Christopher Wiley
commited 
Android (Google) Code Review
commited 
TreeHugger Robot
authored and