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 b5ae87a8d0, 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
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
Among other reasons, this is needed when a Wi-Fi connection is
upgraded from untrusted to trusted, so that the default route can be
updated to point to the Wi-Fi network instead.
Bug: 18206275
Change-Id: I53f7a6f00f66a23ae4873fa2334cd8a621f39d4f
These framework permission strings were being used as arbitrary labels
that mapped to netd permissions that have completely different meaning.
This leads to confusion, so use different strings.
Bug: 18194858
Change-Id: Ib3ec377ab26ce904d3d4678f04edec6cb1260517
This is achieved by adding TYPE_VPN as a supported legacy type.
Note that this is added in code, and not in a config.xml file,
so there's no way to remove TYPE_VPN (i.e., make it unsupported).
Bug: 17426546
Change-Id: I02eb5f22737720095f646f8db5c87fd66da129d6
Once optimistic addresses become useable upon kernel notification
there will be no need for a connectivity delay.
This change requires kernel changes like:
https://android-review.googlesource.com/#/c/109934
Bug: 17769720
Change-Id: I8510c540aa655aad6a82ee322d591331357ee272
1. Add a command to NetworkManagementService to enable/disable
IPv6 ND offload via netd.
2. Make Nat464Xlat enable offload if clatd successfully comes up
on a wifi network (which means it detected a NAT64), and
correspondingly re-enable offload when the clatd interface
goes down.
This change does not enable clatd on wifi yet, that requires an
extra 2 lines to enable it.
Bug: 12111730
Change-Id: I4318611762a37487c9a84f8c4867ec5aece98be8
1. Make Nat464Xlat a per-network object, one for every network
requiring clat, instead of a ConnectivityService singleton.
2. Make the NetworkManagementService clatd commands take an
interface.
3. When we attempt to start clatd on a network, store its
Nat464Xlat object in the NetworkAgentInfo, so we have an
authoritative way of knowing whether clat is running on a
given network.
4. Rework Nat464Xlat, hopefully simplifying it.
Bug: 12111730
Change-Id: I1fa5508ef020cd1c3d1c7a1f7b06370ac5fc2ae2
This simplifies callers.
Also remove all "implementations" of addStackedLink and
removeStackedLink except the one in LinkProperties, because they
are unused.
Bug: 12111730
Change-Id: Ie294b855facba4b1436299dcb3211b72d9ba448e
The placeholder for disconnected networks was setting it to false, but
this technically means that we know an attempt to connect to that
network will fail (which we don't really now). Some applications use
this an decide not to bother trying - an MMS app for example would
never send an MMS because it thinks the network is never available.
This is a L regression.
bug:17669247
Change-Id: Id6041f226da069c267c56418d42c55978c36c66f
