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