It is malformed to write a single intent filter like this:
<intent-filter android:autoVerify="true">
<data android:host="foo.example"
android:path="/"
android:scheme="http" />
<data android:host="*"
android:path="/custom"
android:scheme="fooexamplecustomscheme" />
</intent-filter>
In practice this app is accidentally defining a filter that will match
"http://*". This is now detected, and will never be auto-verified for
any of the mentioned domains.
Verified intent filters must *only* handle the http & https schemes.
Bug 21920537
Change-Id: I933cddbea23185d242565cac940e1e7a7e4e289b
Otherwise after the Device Owner is gone, runtime
permissions might still be auto granted/denied.
I understand that there are many other policies that
we don't reset after the device/profile owner goes
away (e.g. keyguard enabled/disabled). At least now
we have a single method when we could clear the
ones that we care about.
Bug: 21889278
Change-Id: I6997655e6ef6d474bd25ae1c323eca5b17944b16
This CL ensures that Android Keystore framework code complies with
signedness of keymaster tags. In particular:
* INT tags are unsigned 32-bit numbers, and
* LONG and DATE tags are unsigned 64-bit numbers.
The ensure compliance, KeymasterArguments and KeyCharacteristics
classes through which Android Keystore interacts with Keymaster tags
have been modified as follows:
* ENUM and INT tags which used to be conflated are now added/queried
via separate methods, because ENUM can remain represented as an int
data type whereas INT is now represented as a long data type with
permitted range being [0; 2^32).
* Methods for adding/quering LONG tags have been switched from the long
data type to the BigInteger data type and now ensure that the value
is in the permitted [0; 2^63).
* Methods for adding/querying DATE tags now ensure the Date value is
in the permitted range [0; 2^63) ms since Unix epoch.
* Methods for adding tags throw an IllegalArgumentException if the tag
type is unsuitable for the method. This is to ensure that tags with
invalid values cannot be added through similar methods (e.g., INT tag
added via an ENUM tag addition method invoked with a negative value).
Bug: 22008538
Change-Id: I6eefd5cbb561cc52d27de952691af4d9d5e1af1e
Crash immediately so that we can track down the cause. If we let it
through, we'll hit an ISE later in dispatchVsync() and never know why.
Bug: 21948478
Change-Id: I84edf93cdf09d755419e18a7606b7b6cbd059956
Avoids many copies during IPC and duplicate Java heap consumption in
system_server, SystemUI, etc.
Bug: 18386420
Change-Id: Id5ac9406062d472f7848009d65f12131f5f4dac9
Had to add a way for BrightnessController to know when its the end
of a touch, so that we don't spam the event logs with intermediate
values.
Added visibility to BrightnessDialog as this is what settings
launches.
Bug: 21528168
Change-Id: Ie214b4ddb0c9f9bbe8c4f182f9c59f229963ebc7
This CL makes Android Keystore framework code add
KM_TAG_ACTIVE_DATETIME, KM_TAG_ORIGINATION_EXPIRE_DATETIME, and
KM_TAG_USAGE_EXPIRE_DATETIME tags to the authorizations set only
if the corresponding time instants were specified through the
framework-level API. This is fine because these tags are optional as
it turns out.
Bug: 18088752
Change-Id: I6a5ae4cadb441e61576231815e6bec6e9248bc72
Clarify docs that runtime permissions can be granted or revoked by
a profile owner/device owner only for MNC apps and not legacy apps.
Check the targetSdkVersion and return false if legacy app.
Remove all policy flags from permissions when cleaning up
a device or profile owner.
Bug: 21835304
Bug: 21889278
Change-Id: I4271394737990983449048d112a1830f9d0f2d78
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
