1## 7.3\. Sensors 2 3If device implementations include a particular sensor type that has a 4corresponding API for third-party developers, the device implementation 5MUST implement that API as described in the Android SDK documentation and 6the Android Open Source documentation on [sensors]( 7http://source.android.com/devices/sensors/). 8 9Device implementations: 10 11* [C-0-1] MUST accurately report the presence or absence of sensors per the 12[`android.content.pm.PackageManager`]( 13http://developer.android.com/reference/android/content/pm/PackageManager.html) 14class. 15* [C-0-2] MUST return an accurate list of supported sensors via the 16`SensorManager.getSensorList()` and similar methods. 17* [C-0-3] MUST behave reasonably for all other sensor APIs (for example, by 18returning `true` or `false` as appropriate when applications attempt to register 19listeners, not calling sensor listeners when the corresponding sensors are not 20present; etc.). 21 22If device implementations include a particular sensor type that has a 23corresponding API for third-party developers, they: 24 25* [C-1-1] MUST [report all sensor measurements]( 26http://developer.android.com/reference/android/hardware/SensorEvent.html) 27using the relevant International System of Units (metric) values for each 28sensor type as defined in the Android SDK documentation. 29* [C-1-2] MUST report sensor data with a maximum latency of 100 30milliseconds + 2 * sample_time for the case of a sensor stream with a 31maximum requested latency of 0 ms when the application processor is active. 32This delay does not include any filtering delays. 33* [C-1-3] MUST report the first sensor sample within 400 milliseconds + 2 * 34sample_time of the sensor being activated. It is acceptable for this sample to 35have an accuracy of 0. 36* [SR] SHOULD [report the event time]( 37http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp) 38in nanoseconds as defined in the Android SDK documentation, representing the 39time the event happened and synchronized with the 40SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are 41**STRONGLY RECOMMENDED** to meet these requirements so they will be able to 42upgrade to the future platform releases where this might become a REQUIRED 43component. The synchronization error SHOULD be below 100 milliseconds. 44 45* [C-1-4] For any API indicated by the Android SDK documentation to be a 46 [continuous sensor]( 47 https://source.android.com/devices/sensors/report-modes.html#continuous), 48 device implementations MUST continuously provide 49 periodic data samples that SHOULD have a jitter below 3%, 50 where jitter is defined as the standard deviation of the difference of the 51 reported timestamp values between consecutive events. 52 53* [C-1-5] MUST ensure that the sensor event stream 54 MUST NOT prevent the device CPU from entering a suspend state or waking up 55 from a suspend state. 56* When several sensors are activated, the power consumption SHOULD NOT exceed 57 the sum of the individual sensor’s reported power consumption. 58 59The list above is not comprehensive; the documented behavior of the Android SDK 60and the Android Open Source Documentations on 61[sensors](http://source.android.com/devices/sensors/) is to be considered 62authoritative. 63 64 65Some sensor types are composite, meaning they can be derived from data provided 66by one or more other sensors. (Examples include the orientation sensor and the 67linear acceleration sensor.) 68 69Device implementations: 70 71* SHOULD implement these sensor types, when they 72include the prerequisite physical sensors as described 73in [sensor types](https://source.android.com/devices/sensors/sensor-types.html). 74 75If device implementations include a composite sensor, they: 76 77* [C-2-1] MUST implement the sensor as described in the Android Open Source 78documentation on [composite sensors]( 79https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary). 80 81 82### 7.3.1\. Accelerometer 83 84Device implementations: 85 86* [C-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer. 87 88If device implementations include a 3-axis accelerometer, they: 89 90* [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz. 91* [C-1-2] MUST implement and report [`TYPE_ACCELEROMETER`]( 92 http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER) 93 sensor. 94* [C-1-3] MUST comply with the [Android sensor coordinate system]( 95http://developer.android.com/reference/android/hardware/SensorEvent.html) 96as detailed in the Android APIs. 97* [C-1-4] MUST be capable of measuring from freefall up to four times the 98gravity(4g) or more on any axis. 99* [C-1-5] MUST have a resolution of at least 12-bits. 100* [C-1-6] MUST have a standard deviation no greater than 0.05 m/s^, where 101the standard deviation should be calculated on a per axis basis on samples 102collected over a period of at least 3 seconds at the fastest sampling rate. 103* [SR] are **STRONGLY RECOMMENDED** to implement the `TYPE_SIGNIFICANT_MOTION` 104 composite sensor. 105* [SR] are STRONGLY RECOMMENDED to implement and report [`TYPE_ACCELEROMETER_UNCALIBRATED`] 106(https://developer.android.com/reference/android/hardware/Sensor.html#STRING_TYPE_ACCELEROMETER_UNCALIBRATED) 107sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so 108they will be able to upgrade to the future platform release where this might 109become REQUIRED. 110* SHOULD implement the `TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`, 111`TYPE_STEP_DETECTOR`, `TYPE_STEP_COUNTER` composite sensors as described 112in the Android SDK document. 113* SHOULD report events up to at least 200 Hz. 114* SHOULD have a resolution of at least 16-bits. 115* SHOULD be calibrated while in use if the characteristics changes over 116the life cycle and compensated, and preserve the compensation parameters 117between device reboots. 118* SHOULD be temperature compensated. 119 120If device implementations include a 3-axis accelerometer and any of the 121`TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`, `TYPE_STEP_DETECTOR`, 122`TYPE_STEP_COUNTER` composite sensors are implemented: 123 124* [C-2-1] The sum of their power consumption MUST always be less than 4 mW. 125* SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or 126 static condition. 127 128If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, 129they: 130 131* [C-3-1] MUST implement the `TYPE_GRAVITY` and `TYPE_LINEAR_ACCELERATION` 132composite sensors. 133* [C-SR] Are STRONGLY RECOMMENDED to implement the [`TYPE_GAME_ROTATION_VECTOR`]( 134https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GAME_ROTATION_VECTOR) 135composite sensor. 136 137If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, 138and a magnetometer sensor, they: 139 140* [C-4-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor. 141 142### 7.3.2\. Magnetometer 143 144Device implementations: 145 146* [C-SR] Are STRONGLY RECOMMENDED to include a 3-axis magnetometer (compass). 147 148If device implementations include a 3-axis magnetometer, they: 149 150* [C-1-1] MUST implement the `TYPE_MAGNETIC_FIELD` sensor. 151* [C-1-2] MUST be able to report events up to a frequency of at least 10 Hz 152and SHOULD report events up to at least 50 Hz. 153* [C-1-3] MUST comply with the [Android sensor coordinate system]( 154 http://developer.android.com/reference/android/hardware/SensorEvent.html) 155 as detailed in the 156 Android APIs. 157* [C-1-4] MUST be capable of measuring between -900 µT and +900 µT on each 158axis before saturating. 159* [C-1-5] MUST have a hard iron offset value less than 700 µT and SHOULD have 160a value below 200 µT, by placing the magnetometer far from 161dynamic (current-induced) and static (magnet-induced) magnetic fields. 162* [C-1-6] MUST have a resolution equal or denser than 0.6 µT. 163* [C-1-7] MUST support online calibration and compensation of the hard iron 164 bias, and preserve the compensation parameters between device reboots. 165* [C-1-8] MUST have the soft iron compensation applied—the calibration can be 166done either while in use or during the production of the device. 167* [C-1-9] MUST have a standard deviation, calculated on a per axis basis on 168samples collected over a period of at least 3 seconds at the fastest sampling 169rate, no greater than 1.5 µT; SHOULD have a standard deviation no greater than 1700.5 µT. 171* SHOULD implement `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor. 172* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to implement the 173 `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor. 174 175 176If device implementations include a 3-axis magnetometer, an accelerometer 177sensor, and a 3-axis gyroscope sensor, they: 178 179* [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor. 180 181If device implementations include a 3-axis magnetometer, an accelerometer, they: 182 183* MAY implement the `TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor. 184 185If device implementations include a 3-axis magnetometer, an accelerometer and 186`TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor, they: 187 188* [C-3-1] MUST consume less than 10 mW. 189* SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz. 190 191### 7.3.3\. GPS 192 193Device implementations: 194 195* [C-SR] Are STRONGLY RECOMMENDED to include a GPS/GNSS receiver. 196 197If device implementations include a GPS/GNSS receiver and report the capability 198to applications through the `android.hardware.location.gps` feature flag, they: 199 200* [C-1-1] MUST support location outputs at a rate of at least 1 Hz when 201requested via `LocationManager#requestLocationUpdate`. 202* [C-1-2] MUST be able to determine the location in open-sky conditions 203 (strong signals, negligible multipath, HDOP < 2) within 10 seconds (fast 204 time to first fix), when connected to a 0.5 Mbps or faster data speed 205 internet connection. This requirement is typically met by the use of some 206 form of Assisted or Predicted GPS/GNSS technique 207 to minimize GPS/GNSS lock-on time (Assistance data includes Reference Time, 208 Reference Location and Satellite Ephemeris/Clock). 209 * [C-1-6] After making such a location calculation, device 210 implementations MUST determine its location, in open sky, within 211 5 seconds, when location requests are restarted, up to an hour after 212 the initial location calculation, even when the subsequent request is 213 made without a data connection, and/or after a power cycle. 214* In open sky conditions after determining the location, while stationary or 215 moving with less than 1 meter per second squared of acceleration: 216 217 * [C-1-3] MUST be able to determine location within 20 meters, and speed 218 within 0.5 meters per second, at least 95% of the time. 219 * [C-1-4] MUST simultaneously track and report via 220 [`GnssStatus.Callback`]( 221 https://developer.android.com/reference/android/location/GnssStatus.Callback.html#GnssStatus.Callback()') 222 at least 8 satellites from one constellation. 223 * SHOULD be able to simultaneously track at least 24 satellites, from 224 multiple constellations (e.g. GPS + at least one of Glonass, Beidou, 225 Galileo). 226* [C-SR] Are STRONGLY RECOMMENDED to continue to deliver normal GPS/GNSS 227location outputs through GNSS Location Provider API's during an emergency phone 228call. 229* [C-SR] Are STRONGLY RECOMMENDED to report GNSS measurements from all 230constellations tracked (as reported in GnssStatus messages), with the exception 231of SBAS. 232* [C-SR] Are STRONGLY RECOMMENDED to report AGC, and Frequency of GNSS 233measurement. 234* [C-SR] Are STRONGLY RECOMMENDED to report all accuracy estimates 235(including Bearing, Speed, and Vertical) as part of each GPS/GNSS location. 236* [C-SR] Are STRONGLY RECOMMENDED to report GNSS measurements, as soon as 237they are found, even if a location calculated from GPS/GNSS is not yet 238reported. 239* [C-SR] Are STRONGLY RECOMMENDED to report GNSS pseudoranges and 240pseudorange rates, that, in open-sky conditions after determining the location, 241while stationary or moving with less than 0.2 meter per second squared of 242acceleration, are sufficient to calculate position within 20 meters, and speed 243within 0.2 meters per second, at least 95% of the time. 244 245 246### 7.3.4\. Gyroscope 247 248Device implementations: 249 250* [C-SR] Are STRONGLY RECOMMENDED to include a gyroscope sensor unless a 2513-axis accelerometer is also included. 252 253If device implementations include a 3-axis gyroscope, they: 254 255* [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz. 256* [C-1-2] MUST implement the `TYPE_GYROSCOPE` sensor and are STRONGLY 257 RECOMMENDED to also implement the 258 [`TYPE_GYROSCOPE_UNCALIBRATED`](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GYROSCOPE_UNCALIBRATED) 259 sensor. 260* [C-1-4] MUST have a resolution of 12-bits or more and SHOULD have a 261resolution of 16-bits or more. 262* [C-1-5] MUST be temperature compensated. 263* [C-1-6] MUST be calibrated and compensated while in use, and preserve the 264 compensation parameters between device reboots. 265* [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz 266(variance per Hz, or rad^2 / s). The variance is allowed to vary with the 267sampling rate, but MUST be constrained by this value. In other words, if you 268measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater 269than 1e-7 rad^2/s^2. 270* [SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s 271when device is stationary at room temperature. 272* SHOULD report events up to at least 200 Hz. 273 274If device implementations include a 3-axis gyroscope, an accelerometer sensor and a 275magnetometer sensor, they: 276 277* [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor. 278 279If device implementations include a 3-axis accelerometer and a 3-axis gyroscope 280sensor, they: 281 282* [C-3-1] MUST implement the `TYPE_GRAVITY` and 283`TYPE_LINEAR_ACCELERATION` composite sensors. 284* [C-SR] Are STRONGLY RECOMMENDED to implement the 285 [`TYPE_GAME_ROTATION_VECTOR`](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GAME_ROTATION_VECTOR) 286 composite sensor. 287 288### 7.3.5\. Barometer 289 290Device implementations: 291 292* [C-SR] Are STRONGLY RECOMMENDED to include a barometer (ambient air pressure 293 sensor). 294 295If device implementations include a barometer, they: 296 297* [C-1-1] MUST implement and report `TYPE_PRESSURE` sensor. 298* [C-1-2] MUST be able to deliver events at 5 Hz or greater. 299* [C-1-3] MUST be temperature compensated. 300* [SR] STRONGLY RECOMMENDED to be able to report pressure measurements in the 301 range 300hPa to 1100hPa. 302* SHOULD have an absolute accuracy of 1hPa. 303* SHOULD have a relative accuracy of 0.12hPa over 20hPa range 304 (equivalent to ~1m accuracy over ~200m change at sea level). 305 306### 7.3.6\. Thermometer 307 308Device implementations: 309 310* MAY include an ambient thermometer (temperature sensor). 311* MAY but SHOULD NOT include a CPU temperature sensor. 312 313If device implementations include an ambient thermometer (temperature sensor), 314they: 315 316* [C-1-1] MUST be defined as `SENSOR_TYPE_AMBIENT_TEMPERATURE` and MUST 317 measure the ambient (room/vehicle cabin) temperature from where the user 318 is interacting with the device in degrees Celsius. 319* [C-1-2] MUST be defined as `SENSOR_TYPE_TEMPERATURE`. 320* [C-1-3] MUST measure the temperature of the device CPU. 321* [C-1-4] MUST NOT measure any other temperature. 322 323Note the `SENSOR_TYPE_TEMPERATURE` sensor type was deprecated in Android 4.0. 324 325### 7.3.7\. Photometer 326 327* Device implementations MAY include a photometer (ambient light sensor). 328 329### 7.3.8\. Proximity Sensor 330 331* Device implementations MAY include a proximity sensor. 332 333If device implementations include a proximity sensor, they: 334 335* [C-1-1] MUST measure the proximity of an object in the same direction as the 336 screen. That is, the proximity sensor MUST be oriented to detect objects 337 close to the screen, as the primary intent of this sensor type is to 338 detect a phone in use by the user. If device implementations include a 339 proximity sensor with any other orientation, it MUST NOT be accessible 340 through this API. 341* [C-1-2] MUST have 1-bit of accuracy or more. 342 343 344### 7.3.9\. High Fidelity Sensors 345 346If device implementations include a set of higher quality sensors as defined 347in this section, and make available them to third-party apps, they: 348 349* [C-1-1] MUST identify the capability through the 350`android.hardware.sensor.hifi_sensors` feature flag. 351 352If device implementations declare `android.hardware.sensor.hifi_sensors`, 353they: 354 355* [C-2-1] MUST have a `TYPE_ACCELEROMETER` sensor which: 356 * MUST have a measurement range between at least -8g and +8g, SHOULD have 357 a measurement range between at least -16g and +16g. 358 * MUST have a measurement resolution of at least 2048 LSB/g. 359 * MUST have a minimum measurement frequency of 12.5 Hz or lower. 360 * MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD 361 support the SensorDirectChannel [`RATE_VERY_FAST`]( 362 https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST). 363 * MUST have a measurement noise not above 400 μg/√Hz. 364 * MUST implement a non-wake-up form of this sensor with a buffering 365 capability of at least 3000 sensor events. 366 * MUST have a batching power consumption not worse than 3 mW. 367 * [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at 368 least 80% of Nyquist frequency, and white noise spectrum within this 369 bandwidth. 370 * SHOULD have an acceleration random walk less than 30 μg √Hz tested at 371 room temperature. 372 * SHOULD have a bias change vs. temperature of ≤ +/- 1 mg/°C. 373 * SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤ 374 0.03%/C°. 375 * SHOULD have cross-axis sensitivity of < 2.5 % and variation of 376 cross-axis sensitivity < 0.2% in device operation temperature range. 377 378* [C-2-2] MUST have a `TYPE_ACCELEROMETER_UNCALIBRATED` with the same 379quality requirements as `TYPE_ACCELEROMETER`. 380 381* [C-2-3] MUST have a `TYPE_GYROSCOPE` sensor which: 382 * MUST have a measurement range between at least -1000 and +1000 dps. 383 * MUST have a measurement resolution of at least 16 LSB/dps. 384 * MUST have a minimum measurement frequency of 12.5 Hz or lower. 385 * MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD 386 support the SensorDirectChannel [`RATE_VERY_FAST`]( 387 https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST). 388 * MUST have a measurement noise not above 0.014°/s/√Hz. 389 * [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at 390 least 80% of Nyquist frequency, and white noise spectrum within this 391 bandwidth. 392 * SHOULD have a rate random walk less than 0.001 °/s √Hz tested at room 393 temperature. 394 * SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C. 395 * SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C. 396 * SHOULD have a best-fit line non-linearity of ≤ 0.2%. 397 * SHOULD have a noise density of ≤ 0.007 °/s/√Hz. 398 * SHOULD have calibration error less than 0.002 rad/s in 399 temperature range 10 ~ 40 ℃ when device is stationary. 400 * SHOULD have g-sensitivity less than 0.1°/s/g. 401 * SHOULD have cross-axis sensitivity of < 4.0 % and cross-axis sensitivity 402 variation < 0.3% in device operation temperature range. 403* [C-2-4] MUST have a `TYPE_GYROSCOPE_UNCALIBRATED` with the same quality 404requirements as `TYPE_GYROSCOPE`. 405 406* [C-2-5] MUST have a `TYPE_GEOMAGNETIC_FIELD` sensor which: 407 * MUST have a measurement range between at least -900 and +900 μT. 408 * MUST have a measurement resolution of at least 5 LSB/uT. 409 * MUST have a minimum measurement frequency of 5 Hz or lower. 410 * MUST have a maximum measurement frequency of 50 Hz or higher. 411 * MUST have a measurement noise not above 0.5 uT. 412* [C-2-6] MUST have a `TYPE_MAGNETIC_FIELD_UNCALIBRATED` with the same quality 413requirements as `TYPE_GEOMAGNETIC_FIELD` and in addition: 414 * MUST implement a non-wake-up form of this sensor with a buffering 415 capability of at least 600 sensor events. 416 * [C-SR] Is STRONGLY RECOMMENDED to have white noise spectrum from 1 Hz to 417 at least 10 Hz when the report rate is 50 Hz or higher. 418 419* [C-2-7] MUST have a `TYPE_PRESSURE` sensor which: 420 * MUST have a measurement range between at least 300 and 1100 hPa. 421 * MUST have a measurement resolution of at least 80 LSB/hPa. 422 * MUST have a minimum measurement frequency of 1 Hz or lower. 423 * MUST have a maximum measurement frequency of 10 Hz or higher. 424 * MUST have a measurement noise not above 2 Pa/√Hz. 425 * MUST implement a non-wake-up form of this sensor with a buffering 426 capability of at least 300 sensor events. 427 * MUST have a batching power consumption not worse than 2 mW. 428* [C-2-8] MUST have a `TYPE_GAME_ROTATION_VECTOR` sensor. 429* [C-2-9] MUST have a `TYPE_SIGNIFICANT_MOTION` sensor which: 430 * MUST have a power consumption not worse than 0.5 mW when device is 431 static and 1.5 mW when device is moving. 432* [C-2-10] MUST have a `TYPE_STEP_DETECTOR` sensor which: 433 * MUST implement a non-wake-up form of this sensor with a buffering 434 capability of at least 100 sensor events. 435 * MUST have a power consumption not worse than 0.5 mW when device is 436 static and 1.5 mW when device is moving. 437 * MUST have a batching power consumption not worse than 4 mW. 438* [C-2-11] MUST have a `TYPE_STEP_COUNTER` sensor which: 439 * MUST have a power consumption not worse than 0.5 mW when device is 440 static and 1.5 mW when device is moving. 441* [C-2-12] MUST have a `TILT_DETECTOR` sensor which: 442 * MUST have a power consumption not worse than 0.5 mW when device is 443 static and 1.5 mW when device is moving. 444* [C-2-13] The event timestamp of the same physical event reported by the 445Accelerometer, Gyroscope, and Magnetometer MUST be within 2.5 milliseconds 446of each other. The event timestamp of the same physical event reported by 447the Accelerometer and Gyroscope SHOULD be within 0.25 milliseconds of each 448other. 449* [C-2-14] MUST have Gyroscope sensor event timestamps on the same time 450base as the camera subsystem and within 1 milliseconds of error. 451* [C-2-15] MUST deliver samples to applications within 5 milliseconds from 452the time when the data is available on any of the above physical sensors 453to the application. 454* [C-2-16] MUST NOT have a power consumption higher than 0.5 mW 455when device is static and 2.0 mW when device is moving 456when any combination of the following sensors are enabled: 457 * `SENSOR_TYPE_SIGNIFICANT_MOTION` 458 * `SENSOR_TYPE_STEP_DETECTOR` 459 * `SENSOR_TYPE_STEP_COUNTER` 460 * `SENSOR_TILT_DETECTORS` 461* [C-2-17] MAY have a `TYPE_PROXIMITY` sensor, but if present MUST have 462a minimum buffer capability of 100 sensor events. 463 464Note that all power consumption requirements in this section do not include the 465power consumption of the Application Processor. It is inclusive of the power 466drawn by the entire sensor chain—the sensor, any supporting circuitry, any 467dedicated sensor processing system, etc. 468 469If device implementations include direct sensor support, they: 470 471* [C-3-1] MUST correctly declare support of direct channel types and direct 472 report rates level through the [`isDirectChannelTypeSupported`]( 473 https://developer.android.com/reference/android/hardware/Sensor.html#isDirectChannelTypeSupported%28int%29) 474 and [`getHighestDirectReportRateLevel`]( 475 https://developer.android.com/reference/android/hardware/Sensor.html#getHighestDirectReportRateLevel%28%29) 476 API. 477* [C-3-2] MUST support at least one of the two sensor direct channel types 478 for all sensors that declare support for sensor direct channel. 479 * [`TYPE_HARDWARE_BUFFER`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER) 480 * [`TYPE_MEMORY_FILE`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_MEMORY_FILE) 481* SHOULD support event reporting through sensor direct channel for primary 482 sensor (non-wakeup variant) of the following types: 483 * `TYPE_ACCELEROMETER` 484 * `TYPE_ACCELEROMETER_UNCALIBRATED` 485 * `TYPE_GYROSCOPE` 486 * `TYPE_GYROSCOPE_UNCALIBRATED` 487 * `TYPE_MAGNETIC_FIELD` 488 * `TYPE_MAGNETIC_FIELD_UNCALIBRATED` 489 490### 7.3.10\. Biometric Sensors 491 492 493For additional background on Measuring Biometric Unlock Security, please see 494[Measuring Biometric Security documentation](https://source.android.com/security/biometric/measure). 495 496If device implementations include a secure lock screen, they: 497 498* SHOULD include a biometric sensor 499 500Biometric sensors can be classified as **Strong**, **Weak**, or **Convenience** 501based on their spoof and imposter acceptance rates, and on the security of the 502biometric pipeline. This classification determines the capabilities the 503biometric sensor has to interface with the platform and with third-party 504applications. Sensors are classified as **Convenience** by default, and need 505to meet additional requirements as detailed below if they wish to be classified 506as either **Weak** or **Strong**. Both **Weak** and **Strong** biometrics get 507additional capabilities as detailed below. 508 509 510To make a biometric sensor available to third-party applications, device 511implementations: 512 513* [C-0-1] MUST meet the requirements for **Strong** or **Weak** biometric as 514 defined in this document. 515 516 517To allow access to keystore keys to third-party applications, 518device implementations: 519 520* [C-0-2] MUST meet the requirements for **Strong** as defined in this 521 document. 522 523Additionally: 524 525* [C-0-3] MUST be paired with an explicit confirm action (e.g. a button press) 526 if that **Strong** biometric is passive (e.g. face or iris where no 527 explicit signal of the user's intent exists). 528 * [C-SR] The confirm action for passive biometrics is STRONGLY 529 RECOMMENDED to be secured such that an operating system or kernel 530 compromise cannot spoof it. For example, this means that the confirm action 531 based on a physical button is routed through an input-only general-purpose 532 input/output (GPIO) pin of a secure element (SE) that cannot be driven 533 by any other means than a physical button press. 534 535If device implementations wish to treat a biometric sensor as **Convenience**, 536they: 537 538* [C-1-1] MUST have a false acceptance rate less than 0.002%. 539* [C-1-2] MUST disclose that this mode may be less secure than a strong PIN, 540 pattern, or password and clearly enumerate the risks of enabling it, if the 541 spoof and imposter acceptance rates are higher than 7%. 542* [C-1-3] MUST rate limit attempts for at least 30 seconds after five false 543 trials for biometric verification - where a false trial is one with an 544 adequate capture quality ([`BIOMETRIC_ACQUIRED_GOOD`]( 545 https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.html#BIOMETRIC_ACQUIRED_GOOD)) 546 that does not match an enrolled biometric. 547* [C-1-4] MUST prevent adding new biometrics without first establishing a 548 chain of trust by having the user confirm existing or add a new device 549 credential (PIN/pattern/password) that's secured by TEE; the Android Open 550 Source Project implementation provides the mechanism in the framework to do 551 so. 552* [C-1-5] MUST completely remove all identifiable biometric data for a user 553 when the user's account is removed (including via a factory reset). 554* [C-1-6] MUST honor the individual flag for that biometric (i.e. 555 [`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`]( 556 https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_FINGERPRINT), 557 [`DevicePolicymanager.KEYGUARD_DISABLE_FACE`]( 558 https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_FACE) 559 , or 560 [`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`]( 561 https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_IRIS) 562 ). 563* [C-1-7] MUST challenge the user for the recommended primary 564 authentication (e.g. PIN, pattern, password) once every 24 hours 565 or less for new devices launching with Android version 10, once every 566 72 hours or less for devices upgrading from earlier Android version. 567* [C-1-8] MUST challenge the user for the recommended primary 568 authentication (eg: PIN, pattern, password) after one of the 569 following: 570 * a 4-hour idle timeout period, OR 571 * 3 failed biometric authentication attempts. 572 * The idle timeout period and the failed authentication count is reset 573 after any successful confirmation of the device credentials. 574* [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 575 10%, as measured on the device. 576* [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured 577 from when the biometric is detected, until the screen is unlocked, for each 578 enrolled biometric. 579 580If device implementations wish to treat a biometric sensor as **Weak**, they: 581 582* [C-2-1] MUST meet all requirements for **Convenience** above, except 583 for [C-1-2]. 584* [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%. 585* [C-2-3] MUST have a hardware-backed keystore implementation, and perform the 586 biometric matching in an isolated execution environment outside Android user 587 or kernel space, such as the Trusted Execution Environment (TEE), or on a 588 chip with a secure channel to the isolated execution environment. 589* [C-2-4] MUST have all identifiable data encrypted and cryptographically 590 authenticated such that they cannot be acquired, read or altered outside of 591 the isolated execution environment or a chip with a secure channel to the 592 isolated execution environment as documented in the [implementation 593 guidelines](https://source.android.com/security/biometric#hal-implementation) 594 on the Android Open Source Project site. 595* [C-2-5] For camera based biometrics, while biometric based authentication or 596 enrollment is happening: 597 * MUST operate the camera in a mode that prevents camera frames from 598 being read or altered outside the isolated execution environment or a chip 599 with a secure channel to the isolated execution environment. 600 * For RGB single-camera solutions, the camera frames CAN be 601 readable outside the isolated execution environment to support operations 602 such as preview for enrollment, but MUST still NOT be alterable. 603* [C-2-6] MUST NOT enable third-party applications to distinguish between 604 individual biometric enrollments. 605* [C-2-7] MUST NOT allow unencrypted access to identifiable 606 biometric data or any data derived from it (such as embeddings) to 607 the Application Processor outside the context of the TEE. 608* [C-2-8] MUST have a secure processing pipeline such that an operating 609 system or kernel compromise cannot allow data to be directly injected to 610 falsely authenticate as the user. 611 612 If device implementations are already launched on an earlier Android version 613 and cannot meet the requirement C-2-8 through a system software update, they 614 MAY be exempted from the requirement. 615 616If device implementations wish to treat a biometric sensor as **Strong**, they: 617 618* [C-3-1] MUST meet all the requirements of **Weak** above. Upgrading 619 devices from an earlier Android version is not exempted from C-2-7. 620* [C-3-2] MUST have a spoof and imposter acceptance rate not higher than 7%. 621* [C-3-3] MUST challenge the user for the recommended primary 622 authentication (e.g. PIN, pattern, password) once every 72 hours 623 or less. 624 625## 7.3.12\. Pose Sensor 626 627Device implementations: 628 629* MAY support pose sensor with 6 degrees of freedom. 630 631If device implementations support pose sensor with 6 degrees of freedom, they: 632 633* [C-1-1] MUST implement and report [`TYPE_POSE_6DOF`]( 634https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_POSE_6DOF) 635sensor. 636* [C-1-2] MUST be more accurate than the rotation vector alone. 637