Google Will Now Define "High Fidelity Sensor Support" For Android Devices, Has Extensive List Of Performance Requirements

Ever had a phone with a bum gyroscope? Or a totally irrational pedometer? Google, in the interest of better counting your steps and determining just what in the hell your phone is doing moving around in three-dimensional space has now defined a “high fidelity sensor support” flag for Android devices, as in the Android 6.0 Compatibility Definition Document.

The idea here is to give developers a single flag to look for that says “this phone / tablet / whatever is not a dumpster fire of awful sensor accuracy.” Or, perhaps, more positively, to just say a device has really good sensors. The sensors targeted by this new flag include the accelerometer, gyroscope, compass (geomagnetic field), barometer (pressure), and pedometer (step counter). Not only are accuracy requirements defined, but strict power consumption targets are provided as well. That is to say, even if your gyroscope is wicked accurate, it can’t be using more than 1.5mW (milliwatts) of power when it’s turned on if it wants to qualify for the cool kids sensor club. Here is the complete text.

Device implementations supporting a set of higher quality sensors that can meet all the requirements listed in this section MUST identify the support through the android.hardware.sensor.hifi_sensors feature flag.

A device declaring android.hardware.sensor.hifi_sensors MUST support all of the following sensor types meeting the quality requirements as below:

SENSOR_TYPE_ACCELEROMETER

  • MUST have a measurement range between at least -8g and +8g
  • MUST have a measurement resolution of at least 1024 LSB/G
  • MUST have a minimum measurement frequency of 12.5 Hz or lower
  • MUST have a maxmium measurement frequency of 200 Hz or higher
  • MUST have a measurement noise not above 400uG/√Hz
  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events
  • MUST have a batching power consumption not worse than 3 mW

SENSOR_TYPE_GYROSCOPE

  • MUST have a measurement range between at least -1000 and +1000 dps
  • MUST have a measurement resolution of at least 16 LSB/dps
  • MUST have a minimum measurement frequency of 12.5 Hz or lower
  • MUST have a maxmium measurement frequency of 200 Hz or higher
  • MUST have a measurement noise not above 0.014°/s/√Hz

SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as

SENSOR_TYPE_GYROSCOPE

SENSOR_TYPE_GEOMAGNETIC_FIELD

  • MUST have a measurement range between at least -900 and +900 uT
  • MUST have a measurement resolution of at least 5 LSB/uT
  • MUST have a minimum measurement frequency of 5 Hz or lower
  • MUST have a maxmium measurement frequency of 50 Hz or higher
  • MUST have a measurement noise not above 0.5 uT

SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality

requirements as SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:

MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events

SENSOR_TYPE_PRESSURE

  • MUST have a measurement range between at least 300 and 1100 hPa
  • MUST have a measurement resolution of at least 80 LSB/hPa
  • MUST have a minimum measurement frequency of 1 Hz or lower
  • MUST have a maximum measurement frequency of 10 Hz or higher
  • MUST have a measurement noise not above 2 Pa/√Hz
  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events
  • MUST have a batching power consumption not worse than 2 mW

SENSOR_TYPE_ROTATION_VECTOR

  • MUST have a batching power consumption not worse than 4 mW

SENSOR_TYPE_GAME_ROTATION_VECTOR

  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events

SENSOR_TYPE_SIGNIFICANT_MOTION

  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving

SENSOR_TYPE_STEP_DETECTOR

  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events
  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving
  • MUST have a batching power consumption not worse than 4 mW

SENSOR_TYPE_STEP_COUNTER

  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving

SENSOR_TILT_DETECTOR

  • MUST have a power consumption not worse than 0.5 mW when device is staticand 1.5 mW when device is moving

Also such a device MUST meet the following sensor subsystem requirements:

  • The event timestamp of the same physical event reported by the Accelerometer, Gyroscope sensor and Magnetometer MUST be within 2.5 milliseconds of each other.
  • The Gyroscope sensor event timestamps MUST be on the same time base as the camera subsystem and within 1 millisconds of error.
  • The latency of delivery of samples to the HAL SHOULD be below 5 milliseconds from the instant the data is available on the physical sensor hardware.
  • The power consumption MUST not be higher than 0.5 mW when device is static and 2.0 mW when device is moving when any combination of the following sensors are enabled:

       SENSOR_TYPE_SIGNIFICANT_MOTION,
       SENSOR_TYPE_STEP_DETECTOR    
       SENSOR_TYPE_STEP_COUNTER
       SENSOR_TILT_DETECTORS
Note that all power consumption requirements in this section do not include the power consumption of the Application Processor. It is inclusive of the power drawn by the entire sensor chain – the sensor, any supporting circuitry, any dedicated sensor processing system, etc.

The following sensor types MAY also be supported on a device implementation declaring android.hardware.sensor.hifi_sensors, but if these sensor types are present they MUST meet the following minimum buffering capability requirement:

  • SENSOR_TYPE_PROXIMITY: 100 sensor events

Our speculation is that this set of requirements is probably met by the new Nexus “sensor hub” on the Nexus 5X and 6P (or at least one of them), with those phones serving as reference designs for high fidelity sensor support. Again, the idea here is pretty developer-centric, even if this is a document targeted at manufacturers. If OEMs meet the requirements, they can tick the flag for high fidelity support, which will allow developers to decide just how to calibrate their apps and games for a given device or whether to display a warning if a given device does not have the level of hi-fi sensor support for optimal performance or power consumption. Basically, this is about standardizing hardware performance for the benefit of user experience.

Note that OEMs are not compelled to build high fidelity sensor support, they merely need to meet the requirements of it if they want their devices to be flagged as hi-fi sensor capable. This isn’t a requirement for getting the Play Store or anything like that – just to be clear. It is 100% optional.

Posted in: