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
This patch partially undoes ag/869831 (Change-Id:
Ia42ed7aefaebd8caf3eada8e42b6cb7a940d7647) so that ConnectivityManager
does not remove callbacks from its internal request-to-callback map at
unregistration, but instead let the singleton CallbackHandler do it when
receiving a CALLBACK_RELEASED from ConnectivityService.
ag/869831 was thought to fix b/26749700 that reported a callback leak
from sNetworkCallback, but a finer analysis of the code shows that
callbacks were correctly removed by the CallbackHandler before
ag/869831. There was therefore no callback leak.
Bug: 26749700
Bug: 28537383
Change-Id: I421d889d0e225c0e3d1eebea664f44a1cc0f3191
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
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
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
This will allow us to simplify code that deals with
NetworkRequests outside ConnectivityService.
Bug: 23113288
Change-Id: I9b3a859d0c68cad73d7f6baa4b584d13ffd2ae36
