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