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
The system settings permission is going away and the user will
be able to choose which apps have access to system settings in
the UI. So, if an app is white-listed by the user or being on
the system image, we allow access to system settings. Also if
the caller has the stronger write secure settings permission
we allow changes of the less sensitive system settings.
Change-Id: I7aca958fd0ad2c588117b8c6e44d78eb16d648bc
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
Define a new scan flag to control whether or not we're performing
an initial scan for packages. On internal storage, an intial
scan occurs during every boot. For adopted storage, an intial scan
occurs immediately after the adopted volume is mounted or whenever
an application is moved.
Bug: 21815906
Change-Id: Ieda9668230597346bce9ee25ecfa204f931bcef6
3.5 times as many bytes, at 1/4th the frequency, so a net reduction
in log size, although it'll seem like an increase due to being bursty
and therefore more noticable.
Bug: 21530763
Change-Id: Icb1a1a1b0dcd4fd8b3c24f317d39b38f1591757e
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
Without this fix if a listening NetworkRequest with NET_CAPABILITY_VALIDATED
is submitted after a network has been validated but failed the most recent
validation attempt, the NetworkRequest will never receive callbacks.
Bug: 21343774
Change-Id: I6fa6d563c9a6f278b20e645776b707559033b249
This makes Android Keystore's KeyPairGenerator fall back to generating
a self-signed certificate with an invalid/fake signature when the
attempt to generate a self-signed certificate with a valid signature
fails.
There is a growing number of reasons/authorizations due to which the
generated private key cannot be used to sign the self-signed
certificate. It's safer for KeyPairGenerator to succeed than to fail.
Bug: 22033161
Change-Id: I1ecbd421346166bfd536b5cfbaea169b11f0b1c8
