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
Do not use LOG_FATAL_IF in JNI setup. This is one-time on startup
and important enough to always check.
Add a header with common helper definitions. Move to inlined functions
instead of macros to clean up the code.
Change-Id: Ib12d0eed61b110c45d748e80ec36c563e9dec7e5
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
Lorenzo Colitticommited 2014-11-10 19:33:13 -08:00
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
Robert Greenwaltcommited 2014-11-05 15:06:20 -08:00
setDomain() and toLinkProperties() were not setting the domains.
The setDomain() bug affected Wifi and I believe the toLinkProperties()
bug affected Ethernet and Bluetooth reverse-tethering.
bug:18252947
Change-Id: I8764cb944c293e01d99822bb52b55af7e9d77853
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
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
Lorenzo Colitticommited 2014-10-30 20:31:26 +09:00
Paul Jensen
authored and
Android Git Automerger
commited 
Android (Google) Code Review
commited 
Jeff Davidson
authored and
Sreeram Ramachandran
authored and
Jeff Sharkey
authored and
android-build-merger
commited 
Geoffrey Borggaard
authored and
Erik Kline
authored and
Andreas Gampe
authored and
Lorenzo Colitti
authored and
xinhe
authored and
Jeremy Joslin
commited 
Robert Greenwalt
authored and