diff options
| -rw-r--r-- | src/compatibility/android-cdd.html | 288 |
1 files changed, 284 insertions, 4 deletions
diff --git a/src/compatibility/android-cdd.html b/src/compatibility/android-cdd.html index 32fde768..0ae68994 100644 --- a/src/compatibility/android-cdd.html +++ b/src/compatibility/android-cdd.html @@ -225,6 +225,10 @@ <p class="toc_h3"><a href="#7_3_8_proximity_sensor">7.3.8. Proximity Sensor</a></p> +<p class="toc_h3"><a href="#7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</a></p> + +<p class="toc_h3"><a href="#7_3_10_fingerprint">7.3.10. Fingerprint Sensor</a></p> + <p class="toc_h2"><a href="#7_4_data_connectivity">7.4. Data Connectivity</a></p> <p class="toc_h3"><a href="#7_4_1_telephony">7.4.1. Telephony</a></p> @@ -307,6 +311,8 @@ <p class="toc_h2"><a href="#9_10_verified_boot">9.10. Verified Boot</a></p> +<p class="toc_h2"><a href="#9_11_keys_and_credentials">9.11. Keys and Credentials</a></p> + <p class="toc_h1"><a href="#10_software_compatibility_testing">10. Software Compatibility Testing</a></p> <p class="toc_h2"><a href="#10_1_compatibility_test_suite">10.1. Compatibility Test Suite</a></p> @@ -1131,7 +1137,52 @@ device implementations MAY allocate more memory per application.</p> <th>Minimum Application Memory</th> </tr> <tr> - <td rowspan="10">small/normal</td> + <td rowspan="12">Android Watch</td> + <td>120 dpi (ldpi)</td> + <td rowspan="3">32MB</td> + </tr> + <tr> + <td>160 dpi (mdpi)</td> + </tr> + <tr> + <td>213 dpi (tvdpi)</td> + </tr> + <tr> + <td>240 dpi (hdpi)</td> + <td rowspan="2">36MB</td> + </tr> + <tr> + <td>280 dpi (280dpi)</td> + </tr> + <tr> + <td>320 dpi (xhdpi)</td> + <td rowspan="2">48MB</td> + </tr> + <tr> + <td>360 dpi (360dpi)</td> + </tr> + <tr> + <td>400 dpi (400dpi)</td> + <td>56MB</td> + </tr> + <tr> + <td>420 dpi (420dpi)</td> + <td>64MB</td> + </tr> + <tr> + <td>480 dpi (xxhdpi)</td> + <td>88MB</td> + </tr> + <tr> + <td>560 dpi (560dpi)</td> + <td>112MB</td> + </tr> + <tr> + <td>640 dpi (xxxhdpi)</td> + <td>154MB</td> + </tr> + <tr> + <td rowspan="12">small/normal</td> <td>120 dpi (ldpi)</td> <td rowspan="2">32MB</td> </tr> @@ -1150,13 +1201,20 @@ device implementations MAY allocate more memory per application.</p> </tr> <tr> <td>320 dpi (xhdpi)</td> - <td>80MB</td> + <td rowspan="2">80MB</td> + </tr> + <tr> + <td>360 dpi (360dpi)</td> </tr> <tr> <td>400 dpi (400dpi)</td> <td>96MB</td> </tr> <tr> + <td>420 dpi (420dpi)</td> + <td>112MB</td> + </tr> + <tr> <td>480 dpi (xxhdpi)</td> <td>128MB</td> </tr> @@ -1169,7 +1227,7 @@ device implementations MAY allocate more memory per application.</p> <td>256MB</td> </tr> <tr> - <td rowspan="10">large</td> + <td rowspan="12">large</td> <td>120 dpi (ldpi)</td> <td>32MB</td> </tr> @@ -1193,10 +1251,18 @@ device implementations MAY allocate more memory per application.</p> <td>128MB</td> </tr> <tr> + <td>360 dpi (360dpi)</td> + <td>160MB</td> + </tr> + <tr> <td>400 dpi (400dpi)</td> <td>192MB</td> </tr> <tr> + <td>420 dpi (420dpi)</td> + <td>228MB</td> + </tr> + <tr> <td>480 dpi (xxhdpi)</td> <td>256MB</td> </tr> @@ -1209,7 +1275,7 @@ device implementations MAY allocate more memory per application.</p> <td>512MB</td> </tr> <tr> - <td rowspan="10">xlarge</td> + <td rowspan="12">xlarge</td> <td>120 dpi (ldpi)</td> <td>48MB</td> </tr> @@ -1233,10 +1299,18 @@ device implementations MAY allocate more memory per application.</p> <td>192MB</td> </tr> <tr> + <td>360 dpi (360dpi)</td> + <td>240MB</td> + </tr> + <tr> <td>400 dpi (400dpi)</td> <td>288MB</td> </tr> <tr> + <td>420 dpi (420dpi)</td> + <td>336MB</td> + </tr> + <tr> <td>480 dpi (xxhdpi)</td> <td>384MB</td> </tr> @@ -2748,7 +2822,9 @@ default display.</p> <li>240 dpi (hdpi)</li> <li>280 dpi (280dpi)</li> <li>320 dpi (xhdpi)</li> + <li>360 dpi (360dpi)</li> <li>400 dpi (400dpi)</li> + <li>420 dpi (420dpi)</li> <li>480 dpi (xxhdpi)</li> <li>560 dpi (560dpi)</li> <li>640 dpi (xxxhdpi)</li> @@ -3288,6 +3364,9 @@ the SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong> to meet these requirement so they will be able to upgrade to the future platform releases where this might become a REQUIRED component. The synchronization error SHOULD be below 100 milliseconds [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">Resources, 75</a>].</li> + <li>MUST report sensor data with a maximum latency of 100 milliseconds + 2 * sample_time for the case of a sensor streamed + with a minimum required latency of 5 ms + 2 * sample_time when the application processor is active. This delay does not include any filtering delays.</li> + <li>MUST report the first sensor sample within 400 milliseconds + 2 * sample_time of the sensor being activated. It is acceptable for this sample to have an accuracy of 0.</li> </ul> <p>The list above is not comprehensive; the documented behavior of the Android SDK @@ -3479,6 +3558,169 @@ other orientation, it MUST NOT be accessible through this API.</li> <li>MUST have 1-bit of accuracy or more.</li> </ul> + +<h3 id="7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</h3> + +<p>Device implementations supporting a set of higher quality sensors that can meet all +the requirements listed in this section MUST identify the support through the +<code>android.hardware.sensor.hifi_sensors</code> feature flag.</p> + +<p>A device declaring android.hardware.sensor.hifi_sensors MUST support all of the following +sensor types meeting the quality requirements as below:</p> + +<ul> + <li>SENSOR_TYPE_ACCELEROMETER + <ul> + <li>MUST have a measurement range between at least -8g and +8g</li> + <li>MUST have a measurement resolution of at least 1024 LSB/G</li> + <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li> + <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li> + <li>MUST have a measurement noise not above 400uG/√Hz</li> + <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events</li> + <li>MUST have a batching power consumption not worse than 3 mW</li> + </ul> + </li> + <li>SENSOR_TYPE_GYROSCOPE + <ul> + <li>MUST have a measurement range between at least -1000 and +1000 dps</li> + <li>MUST have a measurement resolution of at least 16 LSB/dps</li> + <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li> + <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li> + <li>MUST have a measurement noise not above 0.014°/s/√Hz</li> + </ul> + </li> + <li>SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as + SENSOR_TYPE_GYROSCOPE</li> + <li>SENSOR_TYPE_GEOMAGNETIC_FIELD + <ul> + <li>MUST have a measurement range between at least -900 and +900 uT</li> + <li>MUST have a measurement resolution of at least 5 LSB/uT</li> + <li>MUST have a minimum measurement frequency of 5 Hz or lower</li> + <li>MUST have a maxmium measurement frequency of 50 Hz or higher</li> + <li>MUST have a measurement noise not above 0.5 uT</li> + </ul> + </li> + <li>SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality requirements as + SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition: + <ul> + <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events</li> + </ul> + </li> + <li>SENSOR_TYPE_PRESSURE + <ul> + <li>MUST have a measurement range between at least 300 and 1100 hPa</li> + <li>MUST have a measurement resolution of at least 80 LSB/hPa</li> + <li>MUST have a minimum measurement frequency of 1 Hz or lower</li> + <li>MUST have a maximum measurement frequency of 10 Hz or higher</li> + <li>MUST have a measurement noise not above 2 Pa/√Hz</li> + <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li> + <li>MUST have a batching power consumption not worse than 2 mW</li> + </ul> + </li> + <li>SENSOR_TYPE_ROTATION_VECTOR + <ul> + <li>MUST have a batching power consumption not worse than 4 mW</li> + </ul> + </li> + <li>SENSOR_TYPE_GAME_ROTATION_VECTOR MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li> + <li>SENSOR_TYPE_SIGNIFICANT_MOTION + <ul> + <li>MUST have a power consumption not worse than 0.5 mW when device is static + and 1.5 mW when device is moving</li> + </ul> + </li> + <li>SENSOR_TYPE_STEP_DETECTOR + <ul> + <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events</li> + <li>MUST have a power consumption not worse than 0.5 mW when device is static + and 1.5 mW when device is moving</li> + <li>MUST have a batching power consumption not worse than 4 mW</li> + </ul> + </li> + <li>SENSOR_TYPE_STEP_COUNTER + <ul> + <li>MUST have a power consumption not worse than 0.5 mW when device is static + and 1.5 mW when device is moving</li> + </ul> + </li> + <li>SENSOR_TILT_DETECTOR + <ul> + <li>MUST have a power consumption not worse than 0.5 mW when device is static + and 1.5 mW when device is moving</li> + </ul> + </li> +</ul> + +<p>Also such a device MUST meet the following sensor subsystem requirements:</p> + +<ul> + <li>The event timestamp of the same physical event reported by the Accelerometer, Gyroscope + sensor and Magnetometer MUST be within 2.5 milliseconds of each other.</li> + <li>The Gyroscope sensor event timestamps MUST be on the same time base as the camera + subsystem and within 1 millisconds of error.</li> + <li>The latency of delivery of samples to the HAL SHOULD be below 5 milliseconds from + the instant the data is available on the physical sensor hardware.</li> + <li>The power consumption MUST not be higher than 0.5 mW when device is static and 2.0 mW + when device is moving when any combination of the following sensors are enabled: + <ul> + <li>SENSOR_TYPE_SIGNIFICANT_MOTION</li> + <li>SENSOR_TYPE_STEP_DETECTOR</li> + <li>SENSOR_TYPE_STEP_COUNTER</li> + <li>SENSOR_TILT_DETECTORS</li> + </ul> + </li> +</ul> + +<p>Note that all power consumption requirements in this section do not include the power + consumption of the Application Processor. It is inclusive of the power drawn by the entire + sensor chain - the sensor, any supporting circuitry, any dedicated sensor processing system, + etc.</p> + +<p>The following sensor types MAY also be supported on a device implementation declaring + android.hardware.sensor.hifi_sensors, but if these sensor types are present they MUST meet the + following minimum buffering capability requirement:</p> + +<ul> + <li>SENSOR_TYPE_PROXIMITY: 100 sensor events</li> +</ul> + +<h3 id="7_3_10_fingeprint">7.3.10. Fingerprint Sensor</h3> + +<p>Device implementations with a secure lock screen SHOULD include a fingerprint sensor. +If a device implementation includes a fingerprint sensor and has a corresponding API for +third-party developers, it:</p> + +<ul> + <li>MUST declare support for the android.hardware.fingerprint feature.</li> + <li>MUST fully implement the corresponding API as described in the Android SDK documentation +[<a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">Resources, XX</a>]. + </li> + <li>MUST have a false acceptance rate not higher than 0.002%.</li> + <li>Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a + latency from when the fingerprint sensor is touched until the screen is unlocked below + 1 second, for 1 enrolled finger.</li> + <li>MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint + verification.</li> + <li>MUST have a hardware-backed keystore implementation, and perform the fingerprint matching + in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE. + </li> + <li>MUST have all identifiable fingerprint data encrypted and cryptographically + authenticated such that they cannot be acquired, read or altered outside of the + Trusted Execution Environment (TEE) as documented in the implementation guidelines + on the Android Open Source Project site + [<a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">Resources, XX</a>]. + </li> + <li>MUST prevent adding a fingerprint without first establishing a chain of trust by + having the user confirm existing or add a new device credential (PIN/pattern/password) + using the TEE as implemented in the Android Open Source project.</li> + <li>MUST NOT enable 3rd-party applications to distinguish between individual fingerprints. + </li> + <li>MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.</li> + <li>MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint + data securely migrated to meet the above requirements or removed.</li> + <li>SHOULD use the Android Fingerprint icon provided in the Android Open Source Project.</li> +</ul> + <h2 id="7_4_data_connectivity">7.4. Data Connectivity</h2> @@ -4538,6 +4780,44 @@ If a device implementation is already launched without supporting verified boot version of Android, such a device can not add support for this feature with a system software update and thus are exempted from the requirement.</p> +<h2 id="9_11_keys_and_credentials">9.11. Keys and Credentials</h2> + +<p>The Android Keystore System +[<a href="https://developer.android.com/training/articles/keystore.html">Resources, XX</a>] +allows app developers to store cryptographic keys in a container and use them in cryptographic +operations through the KeyChain API +[<a href="https://developer.android.com/reference/android/security/KeyChain.html">Resources, XX</a>] +or the Keystore API + [<a href="https://developer.android.com/reference/java/security/KeyStore.html">Resources, XX</a>]. +</p> + +<p>All Android device implementations MUST meet the following requirements:</p> + +<ul> +<li>SHOULD not limit the number of keys that can be generated, and MUST at least allow more +than 8,192 keys to be imported.</li> +<li>The lock screen authentication MUST rate limit attempts and SHOULD have an exponential + backoff algorithm as implemented in the Android Open Source Project.</li> +<li>When the device implementation supports a secure lock screen and has a secure hardware + such as a Secure Element (SE) where a Trusted Execution Environment (TEE) can be implemented, + then it: + <ul> + <li>MUST back up the keystore implementation with the secure hardware. The upstream Android + Open Source Project provides the Keymaster Hardware Abstraction Layer (HAL) implementation + that can be used to satisfy this requirement.</li> + <li>MUST perform the lock screen authentication in the secure hardware and only when successful + allow the authentication-bound keys to be used. The upstream Android Open Source Project + provides the Gatekeeper Hardware Abstraction Layer (HAL) that can be used to satisfy this + requirement + [<a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">Resources, XX</a>].</li> + </ul> +</li> +</ul> + +<p>Note that if a device implementation is already launched on an earlier Android version and has + not implemented a trusted operating system on the secure hardware, such a device cannot meet + the above TEE-related requirements through a system software update and thus is exempted from these TEE-related requirements.</p> + <h1 id="10_software_compatibility_testing">10. Software Compatibility Testing</h1> |