History log of /frameworks/base/core/java/android/service/oemlock/OemLockManager.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
d86b8fea43ebb6e5c31691b44d8ceb0d8d3c9072 03-Jun-2017 Jeff Sharkey <jsharkey@android.com> Annotate @SystemApi with required permissions.

Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.

Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.

This is purely a docs change; no logic changes are being made.

Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
/frameworks/base/core/java/android/service/oemlock/OemLockManager.java
3b8b46f3a46ccf35a6bb6a828af0f2d011cc9abe 13-Feb-2017 Andrew Scull <ascull@google.com> Service for OEM lock management.

The new service separates OEM lock management from the implementation.
Currently, a user restriction (DISALLOW_OEM_UNLOCK) and the persistent
data block have been used to implement OEM lock management. In future,
other implemention will be used e.g. a secure element.

The new API also allows for a signature to be passed when changing
whether the device is allowed to be OEM unlocked by the carrier which
can be used for cryptographic protection of the flag.

Bug: 34766843
Test: gts-tradefed run gts -m GtsOemLockServiceTestCases -t com.google.android.oemlock.gts.OemLockServiceTest
Test: cts-tradefed run cts -m CtsPermission2TestCases -t android.permission2.cts.PrivappPermissionsTest
Change-Id: I01660d7605d297f273d43436ca03d64ff611b6cf
/frameworks/base/core/java/android/service/oemlock/OemLockManager.java