1. Add a validating method to convert a netmask to a prefix length.
2. Add a function to get the implicit netmask of an IPv4 address.
3. Add a unit test.
Bug: 19704592
Change-Id: Icb9f58d3903ea01df9e3720383c9bd5db6dd8f26
Separate out starting DHCP (DISCOVER) and RENEW operations from fetching
the results. Add NetworkUtils.getDhcpResults(), to enable quick checks
of any available DhcpResults without extraneous interaction with the
DHCP daemon.
Bug: 19422416
Change-Id: I58808e529dda8429737e749f5caef56d923c0809
1. If reportInetCondition says the network is not working, and
the network is already marked not validated, don't revalidate
it. This was superfluous and should save battery.
2. If reportInetCondition says the network is working, and the
network is not marked as validated, revalidated. This will
allow us to get out of a validated state quickly based on app
input (e.g., allowing GCM's exponential backoff timer to drive
revalidation instead of our 10-minute timer).
Bug: 19258761
Bug: 19209043
Change-Id: Iaa4bac82d117ed1f4088dab106e6f6ce46b34bc3
If a user is subject to a VPN, getActiveNetworkInfo() will return
the VPN's underlying network (e.g., TYPE_WIFI), so that apps that
call getActiveNetworkInfo to answer questions like "is the device
connected to wifi?" will continue to work. Make getNetworkInfo
do this as well: if the query is for a network type that is
underlying the current user's VPN, then return that network.
Bug: 19196545
Change-Id: Ic5a651735b927c758594a26d26a03fbd704b52e6
In K and earlier, we would connect to a network where the gateway
was not covered by the subnet mask of the IP address. This is an
invalid configuration, but it used to work, and other OSes appear
to accept it too, so support it.
Bug: 19067207
Change-Id: I822e1d754b336691b675438eefa959a3d75fd07b
Don't say we're disconnected from a legacy type until there are no outstanding requests for it.
bug:18946574
Change-Id: I8e45c4a7558f7ced0840b71c50081989ba13c1c7
These networks may be on their way to becoming validated at which point
they could satisfy the default NetworkRequest. This change unifies the
is-this-network-needed code into a single function.
bug:18652378
Change-Id: Ia511d5c66be79b47dd7c9348ec02784ab30b960c
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. This was not completely fixed in d5f5339.
bug:18826162
Change-Id: I7bb4b99ec969099e9815f46d4c09253be71a29be
When requests made by ConnectivityManager.startUsingNetworkFeature() are
expired or are canceled via ConnectivityManager.stopUsingNetworkFeature(),
we must remember to clear the binding of DNS requests from the calling
process to the Network satisfying the request.
bug:18778725
Change-Id: I800c808ac6486000241b5d263aa79a1192a9fe9e
A legacy network type request would generate a bcast before the network
notification was sent - the legacy startUsingNetworkFeature API requires
the notification so it can bind your dns queries to the new network.
Fast-moving clients could try to use the network before it was ready.
bug:18792871
Change-Id: I24c46ef15c249c50bfc321f62756d1f66dc3a6a9
When we switched the way the status bar determines if a
connection is validated from using INET_CONDITION_ACTION
broadcasts to calling getDefaultNetworkCapabilitiesForUser(),
the statusbar stopped displaying ! when a network stopped having
working Internet connectivity. This is because the validated bit
is never set to false once a network is validated.
Fix this, hopefully temporarily, by introducing a new validated
bit that does go back to being false when a network no longer
has working connectivity, and use that bit in
getDefaultNetworkCapabilitiesForUser().
Bug: 18777225
Change-Id: I991c068be50252391d0e64c647fcf2e053dc82f9
This is a straight rename and thus a complete no-op from a
functionality perspective.
Bug: 18777225
Change-Id: I140d7640f1460c869a311294873772819a7a7059
Now that the delay between connectivity changes and CONNECTIVITY_ACTION
has been removed (ag/599650) races between CONNECTIVITY_ACTION and
the setting of the default network become more evident.
In http://crbug.com/441818 Chrome is calling getaddrinfo()
immediately after a device goes from no connectivity to cellular
connectivity, and Chrome is erroneously getting back EAI_NODATA
because netd hasn't yet set the default network for DNS resolutions.
bug:18757162
Change-Id: Ib607dcb3697403272a8c838713a9cb602e9c6820
1. Send PROXY_CHANGE_ACTION broadcast when any network's proxy changes,
not just the default network.
2. When a process is bound to a particular Network, update the proxy
system properties to those for the bound Network, and keep them
updated when PROXY_CHANGE_ACTION broadcasts are received.
3. Make Network.openConnection() use the proxy for the Network.
bug:17905627
bug:17420465
bug:18144582
(cherry-pick of https://android-review.googlesource.com/#/c/115170)
Change-Id: Ia2819985e6108a8c121e74c683a5646becfd0a97
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 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
