Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
This intent will be broadcasted when:
- Global restrict background setting is changed (sent to all packages)
- An individual uid is added to or removed from the whitelist (sent just
to the packages belonging to that uid).
This intent is only sent to registered receivers.
BUG: 26451391
Change-Id: Ic0a5771f88baa52076ad04764f29098a386463cc
* changes:
Framework support to read newly added fields
Added an API to query GPS hardware version info
GPS Measurement and Navigation APIs go public
Supported GNSS multi-constellation in frameworks
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
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
This CL exposes startTethering and stopTethering functions which also
encapsulate all provisioning check logic. Right now, only silent checks
are implemented, but UI checks will come in a follow-up CL. GTS tests
and Settings changes are under the same topic ID.
BUG: 26247383
Change-Id: I65f61d899594cb3f9035d8496366af17a57a090f
usage while running in background.
The new API is 'int getRestrictBackgroundStatus()' and returns the
following values:
- RESTRICT_BACKGROUND_STATUS_DISABLED: no restrictions
- RESTRICT_BACKGROUND_STATUS_WHITELISTED: restriction but app is
whitelisted
- RESTRICT_BACKGROUND_STATUS_ENABLED: full restriction
The proper way to interprete these values for using metered networks
while running on background is:
- When disabled, there is no restriction and the application could use the
metered networks freely.
- When whitelisted, the application can use the metered network, but should try
to minimize the usage.
- When enabled, the application should not try to use metered networks at
all, since the usage will be denied.
BUG: 26451391
Change-Id: If07d42bb88e4c02802df0234861f38aef2cfead7
Whether a network is deemed roaming or not was already being tracked
as part of the NetworkIdentitySet, so the underlying data store
already tracks roaming and native data separately. However, this data
was being aggregated together in NetworkStatsCollection#getSummary,
since the NetworkIdentitySet is converted to an iface name for the
purposes of matching, and the iface name will be identical whether or
not the iface is considered roaming. Now it is separated.
Also fixes a long-standing bug in NetworkIdentitySet where an identity
read from a saved file would always be considered roaming == false,
even if it wasn't at the time it was written.
Bug: 25813438
Change-Id: I11ab5b51182ed8da7af8fde468df065f9fdc3dad
This also creates a hidden api for the captive portal server calculation
so that the Setup Wizard can use this as well.
bug:13246857
Change-Id: I4dfd0916df97cfce13252c7cc15f7bd05ed95f77
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
Currently, we look at network requests that are created by the
current requestNetwork API to see if they look like requests
that could have been created using the legacy
startUsingNetworkFeature API.
This causes those networks to be added to LegacyTypeTracker,
and so cause CONNECTIVITY_ACTION broadcasts, be accessible
using getNetworkInfo(int type), etc. This was done in the L
timeframe so that apps could request networks using the
then-new requestNetwork APIs and still use them using legacy
APIs such as requestRouteToHost.
However, the resulting CONNECTIVITY_ACTION broadcasts are
expensive. requestRouteToHost has been deprecated since L, and
mixing the old and new APIs was never recommended, so it's time
to delete this hack.
Bug: 22513439
Bug: 23350688
Bug: 25295964
Change-Id: Id867058446e5ee44396743d126d26fa57da0c990
The documentation for this method says that the request can be
released using releaseNetworkRequest, but that's not true.
releaseNetworkRequest only takes a PendingIntent, and can only be
used to release a request filed with a PendingIntent.
Fix the docs to say that the request needs to be released using
unregisterNetworkCallback.
Change-Id: If044fd2d463ab8d09874172d5d56946251057a3c
This method is public @hide to support progressive refactoring of
tethering away from startUsingNetworkFeature to requestNetwork,
without getting in the way of the CONNECTIVITY_ACTION cleanup in
b/22513439 .
Bug: 9580643
Bug: 22513439
Change-Id: I9053ec746cc8f415a2d5849f044667eeb14e1b19
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
* commit 'fd18370675f8794807747a18276dd7385e25f06e':
Require the new PACKET_KEEPALIVE_OFFLOAD permission.
Add an error code for generic hardware error.
Fix bugs and crashes in PacketKeepalive API.
Add tests for the PacketKeepalive API.
Add a PACKET_KEEPALIVE_OFFLOAD permission.
Use a CountDownLatch instead of sleep() in NetworkFactory tests.
Get rid of shortSleep() in ConnectivityServiceTest.
Make ConnectivityServiceTest a bit more readable.
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
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
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
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
