Google announced plans for Ice Cream Sandwich with the ambitious but laudable goal of reducing fragmentation: one OS to rule them all, so to speak. Unifying the user experience among smart phones, tablets and televisions is certainly a goal we heartily support. However, Ice Cream Sandwich will only be a start. Android platforms will still be fragmented by how they integrate sensors for various implementations. For example, sensors differ in resolution, sensitivity, repeatability, bandwidth, and sampling rate.
Fragmentation in Android platforms is growing as Android supports more sensor types. Sensor components in a phone, for example, affect whether an app requiring sensors runs in a platform as the developer intended. The table below shows the common sensor types that smart phones apps use, and how sensor component parameters may differ. Android developers can get a sensor components list using SensorManager.getSensorList(Sensor.TYPE_ALL)
But knowing which components are in a platform won’t be enough. Component datasheets often specify key performance parameters like bias changes, gain linearity, and skew only as a “typical” value or not at all. Furthermore, many apps use information from “virtual sensors,” like Sensor.TYPE_ROTATION_VECTOR and Sensor.TYPE_LINEAR_ACCELERATION.
A virtual sensor combines the results of many sensor components. To fully understand a virtual sensor’s performance, we have to examine, not just the sensor components, but also the underlying sensor system architecture and controlling algorithms. We shall discuss sensor performance from a system perspective in a subsequent article.
