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
(cherry picked from commit d2a878d730)
Change-Id: I80088f291466dbd5a47f360dcc1620acee5cf57e
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 935ceef.
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
ICU, zlib & openssl export them using LOCAL_EXPORT_C_INCLUDE_DIRS.
The dependency on libc/dns/include was bogus and can be removed
trivially.
bug: 18581021
Change-Id: I4b8047ff0df1050ab48b61c0c886888b3f2f0c18
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
