-The ability to launch VPNs is now sticky; once approved by the user,
further approvals are not needed UNLESS the connection is revoked in
Quick Settings.
-The old persistent notification has been removed in favor of the new
Quick Settings UI.
-The name of the VPN app is now pulled from the label of the VPN
service rather than the app itself, if one is set.
Bug: 12878887
Bug: 16578022
Change-Id: I102a14c05db26ee3aef030cda971e5165f078a91
If we have a message in flight about a NetworkAgentInfo when it gets disconnected
we are left with a zombie network. Fixes this by verifing the network is still
live before we process the msg.
bug:17142206
Change-Id: I2c94a39b3ea97c1562066571b277280c1f69f71c
This is a small change but should fix a number of functional problems:
1. When registering a listening NetworkRequest and when a Network is
validated, we should always add the listening NetworkRequest to the
Network's list of NetworkRequests if the Network satisfies the
NetworkRequest. Previously in both cases this was only done for
the highest scoring network. This enables the listening
NetworkRequest to listen for all networks, not just the highest
scoring network.
2. No longer add listening NetworkRequests to mNetworkForRequestId as
it doesn't make sense as it's a 1:1 mapping but listening
NetworkRequests to Networks is a many:many mapping.
3. Don't "keep" a Network that's finished validating when only a
listening NetworkRequest requests it.
4. Don't send updated scores to NetworkFactories from listening
NetworkRequests. NetworkFactories and NetworkAgents shouldn't
concern themselves with listening NetworkRequests.
bug:16680764
Change-Id: Iaba14263227771e4bd84ee4bce488beaef20a8a3
LinkProperties can represent way more complicated configurations
than what we can actually apply to interfaces. This makes it
error-prone to use it to represent static configuration, both
when trying to apply configuration coming from LinkProperties
and when trying to save configuration from current
LinkProperties.
Instead, move static configuration (IPv4 only, since we don't
support static IPv6 configuration) into a separate
StaticIpConfiguration class.
Bug: 16114392
Bug: 16893413
Change-Id: Ib33f35c004e30b6067bb20235ffa43c247d174df
Add logic to obtain the mtu from the network PCO parameter and set it to kernel
when the mobile data connection is established. When there is no PCO mtu configured
from the network, the mtu size defined in the corresponding APN will be used. In case
no mtu size is defined for an APN used for data connection, the MCC/MNC based MTU
defined in the framework overaly will be applied.
bug:17046179
Change-Id: I6465d4b8f2076aaa380ae3617fb3f24adbe136d4
This addresses a TODO and also makes it possible to create
routes to destinations that are not valid LinkAddresses, such as
multicast addresses.
Bug: 16875580
Change-Id: Id4c77b00dc3064bf27d78cdcbbe035e645748cfe
This was old code I missed in previous inet condition refactor
and caused us to show "not connect" icon any time we connected
to a secondary network (mms/supl/etc).
bug:16896743
Change-Id: I0fa62e09bb0b7c0ee0864bb1f95967eac5f60d3e
for determining carrier app instead of MCC/MNC.
Related ConnectivityService change: http://ag/374479
Related Aeroshell change to SetupWizard: http://ag/520857
Bug: 16457806
Change-Id: I78eb2a25d578400c2de6bae4af3d6e8e1ee4d0c7
Some devices use clatd for catching raw IPv4 traffic when running on
a pure-IPv6 carrier network. In those situations, the per-UID
stats are accounted against the clat iface, so framework users need
to combine both the "base" and "stacked" iface usage together.
This also means that policy rules (like restricting background data
or battery saver) need to apply to the stacked ifaces.
Finally, we need to massage stats data slightly:
-- Currently xt_qtaguid double-counts the clatd traffic *leaving*
the device; both against the original UID on the clat iface, and
against UID 0 on the final egress interface.
-- All clatd traffic *arriving* at the device is missing the extra
IPv6 packet header overhead when accounted against the final UID.
Bug: 12249687, 15459248, 16296564
Change-Id: I0ee59d96831f52782de7a980e4cce9b061902fff
Switching from GCM-only inet condition reports to using our network
validation (captive portal check).
Note that currently the GCM signal is disconnected. Next step is to
make the bad-network report API trigger a re-evaluation of the network
and get negative reports from the NetworkMonitor.
Change-Id: Ie2ebab1e5c04775e3c4d6738f656a6c8157dba76
We used to do this but the change got lost in the NetworkAgent
upgrade. This brings it back. ConnectivityService has netd do
the actual flushing.
bug:16549455
Change-Id: I11ddd55fcb9d1ed1d2c6a9be7eb8c57e41bdbdb8
Keep track of requests as well as of networks that come and go.
This is necessary, for example, to ensure that we pretend that
HIPRI has gone down when the HIPRI request goes away, even
though the underlying cell network is actually completely
unaffected.
Also, ensure that when switching default networks we send
disconnect broadcasts (and do so *before* connect broadcasts, to
maintain the illusion).
Bug: 16610051
Change-Id: Ib3c831387124940156df05b312cc36bc0724373e
There are some bugs where getActiveNetworkInfo gives bad data (seemingly)
and this will give the backing data in logs.
bug:16610051
Change-Id: Iad867485ad78daeb3e88665dcd0fdb0af756a3bf
If Socket.connect() times out, the socket cannot be used any
more - any attempt to do so fails with EBADF. Use a new
socket for each IP address.
Bug: 16664129
Change-Id: If3616df86f7c2da0eabd30dca5db65d0da85cb17
Removing ConnectivityService.NetworkFactory. This requires disabling
the ConnectivityServiceTest, but that's been broken since we stopped
using NetworkStateTrackers anyway.
Change-Id: I9b86bd37eb9d018c40f60dca5b00d62c36d4e3ad
Starting with startUsingNetworkFeature and stop.
Figure it's easier to code review incremental changes.
Change-Id: I19aee65e740858c3a9a2a1a785663f6fee094334
Bypassable VPNs grab all traffic by default (just like secure VPNs), but:
+ They allow all apps to choose other networks using the multinetwork APIs.
If these other networks are insecure ("untrusted"), they will enforce that the
app holds the necessary permissions, such as CHANGE_NETWORK_STATE.
+ They support consistent routing. If an app has an existing connection over
some other network when the bypassable VPN comes up, it's not interrupted.
Bug: 15347374
Change-Id: Iaee9c6f6fa8103215738570d2b65d3fcf10343f3
It was calling into dead ConnectivityService code rather than using
the new ConnectivityManager shim code.
bug:15221541
Change-Id: I1e3eea8a658a162ce36673ed1cf7b1e7e4372c42
ConnectivityService has been rewritten for L and is in a stabilizing period.
We need the logging to track down bugs people report.
Restoring to Pre-L conditions.
If there's excess logging please report it - it probably indicates a bug.
Change-Id: I7baf891e3bf12e1545afeb92b8d5af0b01e12a7b
ConnectivityManager.requestNetwork pass TYPE_NONE to
sendRequestForNetwork which prevents it from being used with legacy API
requestRouteToHostAddress. This CL infers the legacy network type
automatically from the network capabilities.
b/16324360
Change-Id: I591d38f875f42f56e8cfc157db2069c9eee0ee26
When a network comes online, is a candidate for being the default network
(i.e. satisfies default NetworkRequest), and the device has no default
network, then make the new network the default network for the purposes
of routing network traffic. This does not affect NetworkRequests or
NetworkCallbacks. This ignores but does not affect network validation.
Benefits:
1. Offers a fail-safe in case network validation returns a false negative.
For example: It would be nice if every Android device didn't fail when
clients3.google.com/generate_204 went down.
2. Offers a method to debug connectivity issues.
For example: If WiFi is failing, disabling Cellular would rule out
interference from WiFi network validation.
3. Reduces delay between no connectivity and any connectivity.
4. Offers a fail-safe in cases of unreliable networks.
For example: You need rescuing from a remote location with a weak signal
offering 90% packet loss. You just want your distress call to go out
but are infuriated to find network validation blocks connectivity.
Change-Id: I78621a1fe8ed2a336591f65bf7b07a6cbcc7ba5e
Don't rely on the NetworkAgent still being connected when we go to
hide the notification. The notification is hidden when the
NetworkAgent is disconnected so that wasn't a safe assumption.
By using the NetID as the notification identifier we also fix the
issue of multiple notifications of the same network type inadvertently
hiding the incorrect notification with the same network type.
bug:16317917
Change-Id: I01fdc466a0f430af9fc378445586ec7b83b3ac83
