Compatibility Definition
2f44OdUf0
2f44OdUf0
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
MUST perform the lock screen authentication in the secure hardware if the<br />
device has a hardware-backed keystore implementation and only when<br />
successful allow the authentication-bound keys to be used. The upstream<br />
Android Open Source Project provides the Gatekeeper Hardware Abstraction<br />
Layer (HAL) that can be used to satisfy this requirement [Resources, 136].<br />
Note that while the above TEE-related requirements are stated as STRONGLY RECOMMENDED, the<br />
<strong>Compatibility</strong> <strong>Definition</strong> for the next API version is planned to changed these to REQIUIRED. If a<br />
device implementation is already launched on an earlier Android version and has not implemented a<br />
trusted operating system on the secure hardware, such a device might not be able to meet the<br />
requirements through a system software update and thus is STRONGLY RECOMMENDED to<br />
implement a TEE.<br />
9.12. Data Deletion<br />
Devices MUST provide users with a mechanism to perform a "Factory Data Reset" that allows logical<br />
and physical deletion of all data. This MUST satisfy relevant industry standards for data deletion such<br />
as NIST SP800-88. This MUST be used for the implementation of the wipeData() API (part of the<br />
Android Device Administration API) described in section 3.9 Device Administration.<br />
Devices MAY provide a fast data wipe that conducts a logical data erase.<br />
10. Software <strong>Compatibility</strong> Testing<br />
Device implementations MUST pass all tests described in this section.<br />
However, note that no software test package is fully comprehensive. For this reason, device<br />
implementers are STRONGLY RECOMMENDED to make the minimum number of changes as<br />
possible to the reference and preferred implementation of Android available from the Android Open<br />
Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring<br />
rework and potential device updates.<br />
10.1. <strong>Compatibility</strong> Test Suite<br />
Device implementations MUST pass the Android <strong>Compatibility</strong> Test Suite (CTS) [Resources, 137]<br />
available from the Android Open Source Project, using the final shipping software on the device.<br />
Additionally, device implementers SHOULD use the reference implementation in the Android Open<br />
Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and<br />
for any reimplementations of parts of the reference source code.<br />
The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain<br />
bugs. The CTS will be versioned independently of this <strong>Compatibility</strong> <strong>Definition</strong>, and multiple revisions<br />
of the CTS may be released for Android 6.0. Device implementations MUST pass the latest CTS<br />
version available at the time the device software is completed.<br />
10.2. CTS Verifier<br />
Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS<br />
Verifier is included with the <strong>Compatibility</strong> Test Suite, and is intended to be run by a human operator to<br />
test functionality that cannot be tested by an automated system, such as correct functioning of a<br />
camera and sensors.<br />
The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional.<br />
Device implementations MUST pass all tests for hardware that they possess; for instance, if a device<br />
possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS<br />
Verifier. Test cases for features noted as optional by this <strong>Compatibility</strong> <strong>Definition</strong> Document MAY be<br />
Page 66 of 74
Change language