Listen for ICMP6 router advertisements on networks that support
packet filters. Construct packet filters and install them to
ignore redundant future ICMP6 router advertisements.
Bug: 26238573
Change-Id: If78300b9fda257c21f3ee6533e1da7de9f897cb4
Paul Jensenauthored and Lorenzo Colitticommited 2016-03-03 17:32:01 +09:00
1. Unhide MSIM APIs in TelephonyManager that already have non-MSIM equivalent
APIs public.
2. Make MSIM API naming consistent (overloaded, no suffix).
3. Unhide APIs in SubscriptionManager that are necessary for MSIM.
Bug: 26772894
Change-Id: Ibebab7379ea79c8e4812bbd190342827048e30e2
Current usage of NetworkSpecifier: network factory will match a request
if the request has either a (1) empty network specifier, or (2) a
network specifier which is identical to that of the network factory.
Note: 'matching' w.r.t. network specifier - all other matching rules
are still in effect.
Change: add rule (3) or the network specifier of the network factory
is the special string (which is defined as "*" and which user-facing
network requests aren't allowed to use).
Rationale: allows on-demand network creation.
Example:
- Can specify a Wi-Fi NetworkRequest with NetworkSpecifier="ssid"
- It will match a Wi-Fi network factory specifying NetworkSpecifier="*"
- That network factory will bring up a Wi-Fi network, connecting to the
specified SSID.
- Once the network is created it will create a NetworkAgent which will
now have a NetworkSpecifier matching that of the request (not the
match-all special string!)
That final step of making sure that the NetworkAgent matches the request
and not the match-all is critical to delivering any subsequent callbacks
correctly. I.e. your network will only get callbacks which match it.
Bug: 26192833
Change-Id: I49e3b492e0bb48a3f6e9a34e3f94f0e1cf89741f
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
Lorenzo Colitticommited 2015-10-22 08:33:45 +09:00
This is necessary because currently the wifi code just returns
whatever hardware-specific integer it gets back from the HAL,
which is bad because that will be interpreted by the caller as
one of the error codes defined in this class.
In parallel we'll also modify the wifi code to return this new
error code if the hardware returns an error.
Bug: 21405946
Change-Id: Ic9fa1193ced69a4e7ff543e397221c89b10a5a13
Lorenzo Colitticommited 2015-09-09 00:16:57 +09:00
Move SUPL CONNECTIVITY_ACTION bcasts to a different, hidden intent
to reduce the churn of apps when SUPL comes/goes.
Short term hack until SUPL moves to use the new APIs and there's
no bcast.
bug:23350688
Change-Id: I3dc14b42afa72465260aa41ccedfe1df27baabd9
Robert Greenwaltcommited 2015-09-01 15:06:04 -07:00
If an app uses the new api (requestNetwork) to bring up MMS, don't
mark it as a legacy request. This was done because the messaging
service had to use a combination of new API and old
(requestRouteToHost) due to api problems. This has been resolved
so don't mark these as legacy requests anymore.
The general stuff is still in for other types due to lack of testing
time but this should be removed altogether in the future.
bug:23350688
Change-Id: I41c27efb253c39d8af1357ae7916ed5315c716db
Robert Greenwaltcommited 2015-08-28 12:37:54 -07:00
Requests without NET_CAPABILITIES_INTERNET and just the default network
capabilities should not be marked restricted. Without this fix apps
can hit permissions exceptions if they inadvertently make requests
without NET_CAPABILITIES_INTERNET.
Bug:23164917
Change-Id: I4c7136821315bcb05dfc42ffbc505a5d4f6109e6
Merge the CHANGE_NETWORK_STATE permission with WRITE_SETTINGS.
AndroidManifest.xml:
Raised the protection level of CHANGE_NETWORK_STATE permission from
normal to signature|appops and pre23|preinstall for compatibility
provider/Settings:
Wrote new helper methods to check if app is allowed to change network
state.
ConnectivityManager.java & ConnectivityService.java:
Replace enforcement checks for CHANGE_NETWORK_STATE with
checkAndNoteChangeNetworkStateOperations instead.
Change-Id: If8c2dd3c76a5324ca43f1d90fa17973216c2bcc5
With this change:
1. NOT_RESTRICTED should be removed from NetworkRequests that bring up
special restricted carrier networks (e.g. IMS, FOTA).
2. NetworkRequests without NOT_RESTRICTED require CONNECTIVITY_INTERNAL
permission to register
3. Binding sockets to networks without NOT_RESTRICTED requires
CONNECTIVITY_INTERNAL permission
Bug:21637535
Change-Id: I5991d39facaa6b690e969fe15dcbeec52e918321
The methods startUsingNetworkFeature, stopUsingNetworkFeature and
requestRouteToHost were @removed in all the M preview builds, but
internal and external developers have noted that this imposes
additional burden for applications that need to work across
multiple platform versions because it causes compile-time errors.
We switched from @removed back to @deprecated to avoid these
problems. In order to effectively deprecate these methods, which
are error-prone and insecure, make them throw
UnsupportedOperationException if the app's target SDK is M or
above.
Because there are still one or two places in system code that use
these APIs, exempt Process.SYSTEM_UID and the OMA-DM client from
the check for now.
Bug: 22728205
Change-Id: I790bd32f3aa8067cbb625962a209bb9232f4b58c
Lorenzo Colitticommited 2015-07-31 11:08:27 +09:00
These were @removed too soon. We need to keep them @deprecated until
the bulk of devices support the new API and then we can remove them.
bug:22728205
Change-Id: If1b46ff1878f1778517624112b195c461645ddd1
Robert Greenwaltcommited 2015-07-28 11:41:31 -07:00
If a network no longer satisfies a NetworkRequest, send the onLost
NetworkCallback. If it was a real request (not listen) then update
the NetworkFactories.
To test this change I created a little infrastructure to fake
different Internet connectivity probe results during tests. This
allowed me to rewrite some of ConnectivityServiceTest's logic for
validating networks. This brought to light a couple issues that
I had to address to keep tests passing:
1. testUnlingeringDoesNotValidate was relying on a bad side-effect
of my old method of ConnectivityServiceTest's logic for
validating networks, so I rewrote the test.
2. ConnectivityService was not sending out NetworkCallbacks for
WiFi when Cellular was validated. I'm including a fix for this
in this CL also.
Bug:22220234
Change-Id: I29314f38189817f8b2561a213c4f9e8522696663
* commit 'e288b3af14421731d8f477b97e8d77588f20498b':
Add a test for public bugs 2111 and 2136.
Always check off-link connectivity in NetworkDiagnostics.
Lorenzo Colittiauthored and Android Git Automergercommited 2015-07-28 01:20:16 +00:00
Currently, NetworkDiagnostics only checks off-link connectivity if
one of the DNS servers is off-link. Make it check off-link
connectivity in all cases by sending probes to Google Public DNS
if off-link DNS servers are not specified.
Bug: 22569331
Bug: 22641669
Bug: 22748900
Change-Id: I6cb0dd8491bc0c1a488631deca56722b9c1d2b3f
Lorenzo Colitticommited 2015-07-27 16:41:44 +09:00
If the user selects "No" in the "Stay connected?" dialog box:
1. Disable autojoining that network in the future, and
2. Disassociate from that network.
Bug:22187193
Change-Id: I14dc9236c57e3ab7d3ec95edc906787cbfbf3c9f
Hooks the ConnectivityManager.TYPE_MOBILE_EMERGENCY,
PhoneConstants.APN_TYPE_EMERGENCY, and NetworkCapabilities.NET_CAPABILITY_EIMS
together so carrier apps can request connections to this APN.
bug:21785357
Change-Id: Id92a5e28d19407cc7a8f8b5478b23457f2f7f89d
Robert Greenwaltcommited 2015-07-09 14:49:35 -07:00
This new class replaces the awkward string token and ConnectivityManager APIs
used by apps handling captive portals.
Bug:21343774
Change-Id: I1a2c69edb17322715bf8422bb4216b0ea60bfd59
This got lost in the multinetwork work for L. It means
that if telephony stops having the ability to pass packets for a while
the rest of the platform doesn't know.
Telephony enters the suspended state if it enters a telephony call
while using certain radio access technologies, or if it switches to
one of those RATs while in a call. It also can enter this state if
it temporarily loses contact with the network - the modem will
not report the loss of the data call for an indeterminant time in
the hope that regaining the network will restore the connection
without harm to any ongoing ip layer interactions. For example
passing through a tunnel or taking an elevator trip may use this
mechanism.
bug: 19637156
Change-Id: If9fde68175e8561c19323c81fbfcb02a6e5a00fb
Robert Greenwaltcommited 2015-07-08 20:42:55 -07:00
This way, system applications with INTERACT_ACROSS_USERS permission will
be able to fetch the information they need.
Pre-requisite for bug 21499103
Change-Id: I7e759d5039ae6e85abc6435049016b1dcaabc834
Move reachable DNS server computation out of ConnectivityService
and split it into LinkProperties#isReachable() and a companion
change in WifiStateMachine's makeLinkProperties().
Restore previous ConnectivityService#updateDnses() behaviour, as
the pruning is done in WifiStateMachine now.
Bug: 19470192
Bug: 20733156
Bug: 22098233
Change-Id: I810ef74d504e5dc1ca2017d435cdadd6b82171e6
It's not clear what it means to request a network with a mutable
NetworkCapability like NET_CAPABILITY_VALIDATED or
NET_CAPABILITY_CAPTIVE_PORTAL. Presently requesting such a network
would fail in a number of different ways:
1. The NetworkFactories would fail to match the request against their
filter which doesn't include stateful NetworkCapabilities.
2. If the NetworkFactories did match, they'd bring up networks to try
and satisfy the requests, but the networks would not have any
mutable NetworkCapabilities initially so they'd be reaped.
Because of these problems it's safest to simply disallow these
requests.
Bug: 21343774
Change-Id: I56303242b81d39b370b8d5d1e32059bfcfc25949
Paul Jensen
authored and
Lorenzo Colitti
commited 
Erik Kline
commited 
Etan Cohen
authored and
Android Partner Code Review
commited 
Shishir Agrawal
commited 
Jan Nordqvist
authored and
Randy Pan
commited 
Robert Greenwalt
commited 
Android Git Automerger
commited 
Billy Lau
authored and
Android (Google) Code Review
commited 
Dianne Hackborn
authored and
Prerepa Viswanadham
commited 
Robin Lee
authored and