Connectivity broadcasts recently changed and are no longer sent for
certain types of network changes. For example, when stacked network
interfaces change for a mobile network. To ensure that we pick up
all these details, directly wire the two services together.
Also remove some unused code for split network types.
Bug: 18666753
Change-Id: I0467bd5b330c0e0cb51af2306d821b41ad16337a
There are some cases where multiple subscriber identities (IMSI)
should be treated as "merged together" from a data usage
perspective. This is done by extending the template used for
matching purposes to support multiple subscribers.
Then, when we query historical usage or set network policies, we
normalize the matching template to merge to any other identities
that should be included. When normalizing, the "lowest" identity
is always used for equality and storage purposes, which allows
identities to come and go over time.
This change also fixes data usage recording for multi-SIM devices
by passing along the concrete subscriber identity for each network
interface. Also correctly create default policies for multi-SIM
devices. This change also drops setPolicyDataEnable() until it can
be wired up to the right underlying NetworkAgent. (This means we
still bring up the network, and then rely on iptables rules to block
traffic when over the limit, instead of proactively disabling the
connection.)
Bug: 18012787
Change-Id: If6acf32009fdfea2b836f5aff8e2f3e5e0248b4a
Since optimistic addresses are useable upon kernel notification
there is no need for this extra connectivity delay.
---
This functionality was originally submitted in ag/572619. Owing
to issues with bind()ing to optimistic addresses (see b/18609055)
this was reverted in ag/598673.
This reverts the revert. :-)
Bug: 17769720
Change-Id: Ibee490b2af72050693b6bd748193f51e312ca527
Fixing a bug where a NetworkRequest's PendingIntent can be sent more
than once when networks are rematched before the intent completes.
Added a small delay before removing the request to give the receiving
client an opportunity to put in its own request. The delay value is
configurable via Settings.Secure.
Bug: 18614074
Change-Id: Iac7c5e5a04f42f2b6794e9e22349cc631bebeab7
- Now aggregate number of times each process has crashed and ANRed.
- Now aggregate total number of connectivity changes.
- Now record connectivity changes in the history.
Crash and ANR counts are new entries at the end of "pr" in checkin.
Connectivity change counts is a new entry at the end of "m" in checkin.
Connectivity changes in the history checkin are Ecn and include the
type of connection and its state.
Change-Id: I0c01186446034cf6c3fb97d45f5e3b5c69a0438a
This is the revert of ag/572619.
This reverts commit 31c992a477, reversing
changes made to 32b61ab28f54e5b00f472b2166f9b1100375e4ff.
Bug: 18609055
Bug: 17769720
Change-Id: I122eba200f2071d4e5777ec34c1d04fb567345a8
These networks are unneeded and waste battery. We won't bring up these
networks in the first place if they have no chance of becoming highest scoring.
This change handles the case where these networks are already up and
transition to a state where they have no chance of becoming highest scoring.
This happens when another network validates with a score higher than this
network can ever hope to attain.
bug:18489123
Change-Id: I77a96a72e250e25e44e0c50e7a928af8b35bb6ab
The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
When WiFi's score drops and then comes back up we would previously linger
WiFi but forget to cancel the linger timeout, so 30s later WiFi would
unexpectedly tear down. Also, make sure this is only done for created
Networks as "created" is the signal to initialy match Networks and requests.
bug:18169560
Change-Id: Ia69b110f6473371e556c60b950253758e023b7aa
Currently, if a network does not specify DNS servers, we default
it to using 8.8.8.8. This was done because the emulator did not
specify DNS servers. However, it causes queries to fail slowly,
instead of failing fast, on networks that do not have
connectivity to 8.8.8.8.
Bug: 18327075
Change-Id: I0df13ff4a17ee65e640be96695a3af31b020963a
GCM can call reportInetCondition() at any time which can cause
the NetworkMonitor to transition states to reevaluate at any time.
Previously we were only listening for users clicking the sign-in
notificaiton or completing sign-in when in the appropriate state.
With this change NetworkMonitor's state does not stop us from
listening for the user's actions.
bug:17917929
Change-Id: Ic1da31d90f7090e5fc111874cb7c37d505aaf590
If a VPN app requests to be prepared and has already obtained user
consent, there is no need to additionally enforce the control
permission. We only need to enforce the control permission when a VPN
is first being prepared, where such a preparation would bypass user
consent.
Also ensure that in this case, the VPN being prepared matches the
calling app. Otherwise an app could prepare another pre-consented VPN,
which is not particularly dangerous but is likely unexpected.
Finally, remove misleading comment in ConnectivityService#prepareVpn.
This method IS called from VpnService.prepare(), not only from
system-privileged apps.
Bug: 18442887
Change-Id: Ic3227c6c1c74312697f0576d3811b06692a4edff
Define and print a compact version of network statistics when dump
is requested with the "--checkin" flag. Defaults to last 24 hours,
but included data can be tweaked with various flags.
Groups together detailed network identities into larger umbrella
terms like "mobile" and "wifi."
Bug: 18415963
Change-Id: I70cf9c828ea5c6e5bb6884837d3608f66fbad2e6
These are used when responding to getActiveNetworkInfo() (and cousins)
when an app is subject to the VPN.
Bug: 17460017
Change-Id: Ief7a840c760777a41d3358aa6b8e4cdd99c29f24
The previous code retrieved information from the legacy tracker multiple
times for each user query, leading to race conditions where the info
could've changed between the calls.
Refactors the handling of legacy data types in ConnectivityService and
unifies call paths so that APIs that deal with legacy data types
(NetworkInfo and int/networkType) and newer types (such as Network) go
through common code paths, using NetworkState to hold all the necessary
data pieces. This enables follow-on bug fixes to getActiveNetworkInfo().
The changes are limited to public "query" APIs (those that retrieve some
network information or the other). More details about the specific
changes and their rationale can be found in the code review thread.
Bug: 17460017
Change-Id: I656ee7eddf2b8cace5627036452bb5748043406c
The only immediate change in behavior is not validating untrusted networks.
bug:18299572
bug:18394654
Change-Id: I8d626baf37db0bd0f55ddf3af8a0abf094a12369
ProxyInfo.getPacFileUrl() can not be null. It will be equal to
Uri.EMPTY. Checking for null was causing global proxies to never be
disabled. Or more accurately, global proxies would be disabled, but
would reappear after a reboot.
ProxyInfo.getExclusionListByString() can be null. If no
exclusion list was specified, the proxy settings would not be
successfully saved, they would disappear after reboot.
Bug: 18453223
Change-Id: I1c27e5dca5b9664bb7468ea909bff489fa110a07
This could happen when another Network changes its capabilities and
updateCapabilities() calls rematchAllNetworksAndRequests() which
calls rematchNetworkAndRequests() on all Networks, even those that
are uncreated.
Allowing uncreated Networks to satisfy requests can lead to bugs
where ConnectivityService instructs netd to perform actions
(e.g. set default Network) on uncreated Networks which netd doesn't
know about yet.
bug:18446301
Change-Id: I857262ac66d1d3af4c264ce128f0a4bee95655de
This is NOT designed to be called normally. Most apps (even
system-privileged ones) should request user consent before launching a
VPN. However, it is needed to support flows where consent can be
obtained through other means external to the VPN flow itself.
The API requires a system-privileged permission, CONTROL_VPN.
Bug: 18327583
Change-Id: I1bcdcf0fb5707faeb861ec4535e7ccffea369ae7
Currently Nat464Xlat reads the clat IPv4 address and updates the
clat LinkProperties when the interface is created. This causes a
race condition: because clatd only sets the IPv4 address after
creating the interface, it's possible that Nat464Xlat will read
the address before clatd has set it, causing the framework to
think that the clat IPv4 address is 0.0.0.0/32.
This seems to be happening more frequently now, perhaps because
clatd takes a bit longer to configure the IPv4 address now that
it needs to check that the address is free before using it.
Fix this by making Nat464Xlat listen for the interface coming up
instead of listening for the interface being added.
Bug: 12111730
Change-Id: Ic1c59b5b6dbb851b7431d1b06885f67803373bb9
ConnectivityManager.requestNetwork(NetworkRequest, PendingIntent)
was unhidden and implemented.
Added ConnectivityManager.removePendingIntentRequest(PendingIntent) as
the companion method.
Bug: 17356414
Change-Id: I656a1e149cc1292c443ebfe9e61ee3eb5a80f143
We're starting to get network requests for specific SIMs
and the Legacy Type Inference was broken because the incoming
request included a network specifier while the legacy requests
it was compared with did not. Only compare the things we care
about.
bug:18031008
Change-Id: If107042828c152ede51a2497a3859bc1a6c83694
