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
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
* commit '2ae3a05b424f7ef7c3a28507e2c19fde7f1e5963':
Add a test for public bugs 2111 and 2136.
Always check off-link connectivity in NetworkDiagnostics.
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.
Added Context.sendBroadcastMultiplePermissions(Intent intent, String[]
receiverPermissions) method, which allows an array of required permissions
to be enforced.
Bug: 21852542
Change-Id: I27c9130e8f004b428452501ebc8a36aabde1f343
Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
Previously, once a network validated, for the purposes of comparing networks
to select the default network, we always considered it validated.
With this change if a network later fails to validate, we'll take this latest
validation result into account. This means if WiFi and cellular are up
(e.g. if we recently switched from cellular->WiFi, and cellular is now
lingering) and both are validated, but for some reason WiFi fails a validation,
cellular will become the default network connection.
Bug:20896761
Change-Id: I858aa10c1aaec5cd9032067f960963409107bdb1
Reduce the duplication of some logic so when falling back to Cellular
when WiFi fails to validate is enabled, there's less chance for bugs
and failures:
1. De-duplicate several Network vs NetworkRequest matching functions
2. Remove the very tricky nascent logic by adding a simple "lingering" bit.
Bug:20896761
Change-Id: I21da9e827eec9cfd6835fcaa650192b9186ed053
1. We don't parse PAD options properly, leading in failure to
parse packets sent by DHCP servers that put the end of options
marker after pad options and at an odd offset.
2. We get the DhcpResults vendorInfo from the wrong option type
(60 instead of 43).
Fix these and add unit tests for the offer packets sent by a few
different DHCP servers.
Bug: 21955617
Bug: 22281295
Change-Id: I5d13f1a6a3ff0b53112f18f3db8792fa32ad2da3
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
Aggregate and then periodically report stats that are high-frequency
because they are driven by app behavior, not user behavior.
Reuse the NotificationUsageStats facility.
Remove redundant stats.
Lessen memory foot print.
Enable in-memeory aggregates with small, bounded memory footprint.
Bug: 20258744
Change-Id: I87e391419c53917fa13c68a56f8cdb40a7c8e548
Add exceptions/checks for keysetmgrservice interractions which *should* never
happen, but would result in NPE or invalid metadata. Also handle mismatches
between package and keyset metadata in packages.xml.
Bug: 20128916
Change-Id: Ia0f63f78d232d9d8d9fbe4cd8e6cc3406e5192a7
We used to only remove requests that we'd acted on but that's
just wrong.
Also adds test case which exposed the problem but passes with the fix.
bug:20731384
Change-Id: I581a005560cc71167b857abf2452769399a9e1b7
