The access mock location is no longer a runtime permission. It is a
signature protected one that apps cannot get but the fact they request
it means they want to inject location into the system. Now the user
gets to choose the current mock location app in developer options from
the apps that request the mock location permission. The access to mock
location is no longer guarded by the permisson but from a new app op
which is off by default and the settiings UI sets it to enabled only
for the currently selected mock location app.
bug:21078873
Change-Id: I19e3f9dc7c7de82eab46b30fec1abfbca54a0e59
This CL addresses the comments from API Council about Android KeyStore
KeyPairGeneratorSpec, KeyGeneratorSpec and KeyStoreParameter:
1. These abstractions should not take or hold references to Context.
2. The Builders of these abstractions should take all mandatory
parameters in their constructors rather than expose them as
setters -- only optional paratemers should be exposed via setters.
These comments cannot be addressed without deprecation in the already
launched KeyPairGeneratorSpec and KeyStoreParameter. Instead of
deprecating just the getContext methods and Builder constructors, this
CL goes for the nuclear option of deprecating KeyPairGeneratorSpec and
KeyStoreParameter as a whole and exposing all of the AndroidKeyStore
API in the new package android.security.keystore. This enables this CL
to correct all of the accrued design issues with KeyPairGeneratorSpec
(e.g., naming of certificate-related methods) and KeyStoreParameter.
This also makes the transition to API Level M more clear for existing
users of the AndroidKeyStore API. These users will only have to deal
with the new always-mandatory parameters (e.g., purposes) and
sometimes-mandatory (e.g., digests, block modes, paddings) if they
switch to the new API. Prior to this CL they would've had to deal with
this if they invoked any of the new methods of KeyPairGeneratorSpec
or KeyStoreParameter introduced in API Level M.
This CL rips out all the new API introduced into KeyPairGeneratorSpec
and KeyStoreParameter classes for Android M, thus reverting these
classes to the API launched in L MR1. This is because the new API is
now in android.security.keystore.KeyGenParameterSpec and KeyProtection
respectively.
Bug: 21039983
Change-Id: I59672b3c6ef7bc25c40aa85f1c47d9d8a05d627c
* commit 'ce4408a104300006a3296bfd2f2aad9c0f2fd9dc':
docs: Added training docs for Android unit testing tools and APIs. This training covers techniques for running unit tests on local machines, using mock objects in local unit tests, and building instrumented unit tests to run on a device or emulator.
* commit 'd43ec6380ce04f4c0830cd35d1dbd7b3050799d4':
docs: Added training docs for Android unit testing tools and APIs. This training covers techniques for running unit tests on local machines, using mock objects in local unit tests, and building instrumented unit tests to run on a device or emulator.
* commit '174dc3ba607965cf1dd0578f83ce373fa74d0f65':
docs: Added training docs for Android unit testing tools and APIs. This training covers techniques for running unit tests on local machines, using mock objects in local unit tests, and building instrumented unit tests to run on a device or emulator.
This training covers techniques for running unit tests on local
machines, using mock objects in local unit tests, and building
instrumented unit tests to run on a device or emulator.
Change-Id: I9fee9ac3bd7382fb158145600b1850775edb687d
isKeyguardSecure also returns true when SIM PIN is required. We don't
care about that because entering SIM PIN does not unlock keys
requiring user authentication. isDeviceSecure returns true only if
secure lock screen is set up, which is exactly what we want.
Bug: 18088752
Change-Id: I47b21f3351f55c11e8e9bcfd7654762973dd9271
This simplifies the AndroidKeyStore API around user authentication: no
more explicit control over which user authenticators are bound to
which keys.
User-authenticated keys with timeout are unlocked by whatever unlocks
the secure lock screen (currently, password/PIN/pattern or
fingerprint). User-authenticated keys that need authentication for
every use are unlocked by fingerprint only.
Bug: 20526234
Bug: 20642549
Change-Id: I1e5e6c988f32657d820797ad5696797477a9ebe9
The method is missing the Uri parameter and the implementation is
both inefficient and unnecessary. It is documented as fine to
return null in getType.
Change-Id: I78c83918916ca5ef28172e544d9ddc9c3695444d
* commit '591ba605aa91fdec05ac73399ee5893da63833e8':
cherrypick from lmp-docs docs: Listening for restrictions-changed Original Change-Id: I19c7150a9f36de226d00ad6d8db0e9210d5d135d
Original Change-Id: I19c7150a9f36de226d00ad6d8db0e9210d5d135d
Per bug 19848206, it turns out that APPLICATION_RESTRICTIONS_CHANGED
is only sent to dynamically-declared listeners, *not* to listeners
declared in the manifest. Updated doc to note this. (The code snippet
already showed how to dynamically declare a listener.)
See first comment for doc stage location.
bug: 19848206
Change-Id: I6dc5f39dc6eed71cf2e303564ea906be3832d8a4
* commit 'a5ee27b3aa60dc5f839e95e7d9c219f7bf59ea5d':
cherrypick from lmp-docs docs: Add Wear Capability training Original Change-Id: I52ede5d91936c5eab3d6ee8be8108004cce1f0e0
Doc-in-progress inherited from xoogler's (unfinished) CL
http://ag/427505 . See comments for staging location.
Patch set 1 is the version inherited from the xoogler; PS2 is after
my edits. Per a conversation with CB, I've removed the "ListFragment"
doc, and just put in a note about that topic in the
"add-swipe-refresh" doc.
Change-Id: Id1a1294b15c5a7363f650ea13237948b0effbc40
