{
	"id": "d56a88d7-b293-44a0-b8af-35d9d6b7c7c6",
	"created_at": "2026-04-06T00:13:06.800458Z",
	"updated_at": "2026-04-10T03:20:17.840071Z",
	"deleted_at": null,
	"sha1_hash": "56580f48a98fd133833e3dc4fd77417eee897e50",
	"title": "Sensors Overview",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 315165,
	"plain_text": "Sensors Overview\r\nArchived: 2026-04-05 13:14:40 UTC\r\nMost Android-powered devices have built-in sensors that measure motion, orientation, and various environmental\r\nconditions. These sensors are capable of providing raw data with high precision and accuracy, and are useful if\r\nyou want to monitor three-dimensional device movement or positioning, or you want to monitor changes in the\r\nambient environment near a device. For example, a game might track readings from a device's gravity sensor to\r\ninfer complex user gestures and motions, such as tilt, shake, rotation, or swing. Likewise, a weather application\r\nmight use a device's temperature sensor and humidity sensor to calculate and report the dewpoint, or a travel\r\napplication might use the geomagnetic field sensor and accelerometer to report a compass bearing.\r\nThe Android platform supports three broad categories of sensors:\r\nMotion sensors\r\nThese sensors measure acceleration forces and rotational forces along three axes. This category includes\r\naccelerometers, gravity sensors, gyroscopes, and rotational vector sensors.\r\nEnvironmental sensors\r\nThese sensors measure various environmental parameters, such as ambient air temperature and pressure,\r\nillumination, and humidity. This category includes barometers, photometers, and thermometers.\r\nPosition sensors\r\nThese sensors measure the physical position of a device. This category includes orientation sensors and\r\nmagnetometers.\r\nYou can access sensors available on the device and acquire raw sensor data by using the Android sensor\r\nframework. The sensor framework provides several classes and interfaces that help you perform a wide variety of\r\nsensor-related tasks. For example, you can use the sensor framework to do the following:\r\nDetermine which sensors are available on a device.\r\nDetermine an individual sensor's capabilities, such as its maximum range, manufacturer, power\r\nrequirements, and resolution.\r\nAcquire raw sensor data and define the minimum rate at which you acquire sensor data.\r\nRegister and unregister sensor event listeners that monitor sensor changes.\r\nThis topic provides an overview of the sensors that are available on the Android platform. It also provides an\r\nintroduction to the sensor framework.\r\nIntroduction to Sensors\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 1 of 16\n\nThe Android sensor framework lets you access many types of sensors. Some of these sensors are hardware-based\r\nand some are software-based. Hardware-based sensors are physical components built into a handset or tablet\r\ndevice. They derive their data by directly measuring specific environmental properties, such as acceleration,\r\ngeomagnetic field strength, or angular change. Software-based sensors are not physical devices, although they\r\nmimic hardware-based sensors. Software-based sensors derive their data from one or more of the hardware-based\r\nsensors and are sometimes called virtual sensors or synthetic sensors. The linear acceleration sensor and the\r\ngravity sensor are examples of software-based sensors. Table 1 summarizes the sensors that are supported by the\r\nAndroid platform.\r\nFew Android-powered devices have every type of sensor. For example, most handset devices and tablets have an\r\naccelerometer and a magnetometer, but fewer devices have barometers or thermometers. Also, a device can have\r\nmore than one sensor of a given type. For example, a device can have two gravity sensors, each one having a\r\ndifferent range.\r\nTable 1. Sensor types supported by the Android platform.\r\nSensor Type Description Common Uses\r\nTYPE_\r\nACCELEROMETER\r\nHardware\r\nMeasures the acceleration force in m/s2 that is\r\napplied to a device on all three physical axes (x, y,\r\nand z), including the force of gravity.\r\nMotion detection\r\n(shake, tilt, etc.).\r\nTYPE_AMBIENT_\r\nTEMPERATURE\r\nHardware\r\nMeasures the ambient room temperature in degrees\r\nCelsius (°C). See note below.\r\nMonitoring air\r\ntemperatures.\r\nTYPE_GRAVITY\r\nSoftware\r\nor\r\nHardware\r\nMeasures the force of gravity in m/s2 that is\r\napplied to a device on all three physical axes (x, y,\r\nz).\r\nMotion detection\r\n(shake, tilt, etc.).\r\nTYPE_\r\nGYROSCOPE\r\nHardware\r\nMeasures a device's rate of rotation in rad/s around\r\neach of the three physical axes (x, y, and z).\r\nRotation detection\r\n(spin, turn, etc.).\r\nTYPE_LIGHT Hardware\r\nMeasures the ambient light level (illumination) in\r\nlx.\r\nControlling screen\r\nbrightness.\r\nTYPE_LINEAR_\r\nACCELERATION\r\nSoftware\r\nor\r\nHardware\r\nMeasures the acceleration force in m/s2 that is\r\napplied to a device on all three physical axes (x, y,\r\nand z), excluding the force of gravity.\r\nMonitoring\r\nacceleration along\r\na single axis.\r\nTYPE_MAGNETIC_\r\nFIELD\r\nHardware\r\nMeasures the ambient geomagnetic field for all\r\nthree physical axes (x, y, z) in μT.\r\nCreating a\r\ncompass.\r\nTYPE_\r\nORIENTATION\r\nSoftware Measures degrees of rotation that a device makes\r\naround all three physical axes (x, y, z). As of API\r\nlevel 3 you can obtain the inclination matrix and\r\nrotation matrix for a device by using the gravity\r\nDetermining\r\ndevice position.\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 2 of 16\n\nsensor and the geomagnetic field sensor in\r\nconjunction with the getRotationMatrix()\r\nmethod.\r\nTYPE_PRESSURE Hardware Measures the ambient air pressure in hPa or mbar.\r\nMonitoring air\r\npressure changes.\r\nTYPE_\r\nPROXIMITY\r\nHardware\r\nMeasures the proximity of an object in cm relative\r\nto the view screen of a device. This sensor is\r\ntypically used to determine whether a handset is\r\nbeing held up to a person's ear.\r\nPhone position\r\nduring a call.\r\nTYPE_RELATIVE_\r\nHUMIDITY\r\nHardware\r\nMeasures the relative ambient humidity in percent\r\n(%).\r\nMonitoring\r\ndewpoint,\r\nabsolute, and\r\nrelative humidity.\r\nTYPE_ROTATION_\r\nVECTOR\r\nSoftware\r\nor\r\nHardware\r\nMeasures the orientation of a device by providing\r\nthe three elements of the device's rotation vector.\r\nMotion detection\r\nand rotation\r\ndetection.\r\nTYPE_\r\nTEMPERATURE\r\nHardware\r\nMeasures the temperature of the device in degrees\r\nCelsius (°C). This sensor implementation varies\r\nacross devices and this sensor was replaced with\r\nthe TYPE_AMBIENT_TEMPERATURE sensor in API\r\nLevel 14\r\nMonitoring\r\ntemperatures.\r\nSensor Framework\r\nYou can access these sensors and acquire raw sensor data by using the Android sensor framework. The sensor\r\nframework is part of the android.hardware package and includes the following classes and interfaces:\r\nSensorManager\r\nYou can use this class to create an instance of the sensor service. This class provides various methods for\r\naccessing and listing sensors, registering and unregistering sensor event listeners, and acquiring orientation\r\ninformation. This class also provides several sensor constants that are used to report sensor accuracy, set\r\ndata acquisition rates, and calibrate sensors.\r\nSensor\r\nYou can use this class to create an instance of a specific sensor. This class provides various methods that let\r\nyou determine a sensor's capabilities.\r\nSensorEvent\r\nThe system uses this class to create a sensor event object, which provides information about a sensor event.\r\nA sensor event object includes the following information: the raw sensor data, the type of sensor that\r\ngenerated the event, the accuracy of the data, and the timestamp for the event.\r\nSensorEventListener\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 3 of 16\n\nYou can use this interface to create two callback methods that receive notifications (sensor events) when\r\nsensor values change or when sensor accuracy changes.\r\nIn a typical application you use these sensor-related APIs to perform two basic tasks:\r\nIdentifying sensors and sensor capabilities\r\nIdentifying sensors and sensor capabilities at runtime is useful if your application has features that rely on\r\nspecific sensor types or capabilities. For example, you may want to identify all of the sensors that are\r\npresent on a device and disable any application features that rely on sensors that are not present. Likewise,\r\nyou may want to identify all of the sensors of a given type so you can choose the sensor implementation\r\nthat has the optimum performance for your application.\r\nMonitor sensor events\r\nMonitoring sensor events is how you acquire raw sensor data. A sensor event occurs every time a sensor\r\ndetects a change in the parameters it is measuring. A sensor event provides you with four pieces of\r\ninformation: the name of the sensor that triggered the event, the timestamp for the event, the accuracy of\r\nthe event, and the raw sensor data that triggered the event.\r\nSensor Availability\r\nWhile sensor availability varies from device to device, it can also vary between Android versions. This is because\r\nthe Android sensors have been introduced over the course of several platform releases. For example, many sensors\r\nwere introduced in Android 1.5 (API Level 3), but some were not implemented and were not available for use\r\nuntil Android 2.3 (API Level 9). Likewise, several sensors were introduced in Android 2.3 (API Level 9) and\r\nAndroid 4.0 (API Level 14). Two sensors have been deprecated and replaced by newer, better sensors.\r\nTable 2 summarizes the availability of each sensor on a platform-by-platform basis. Only four platforms are listed\r\nbecause those are the platforms that involved sensor changes. Sensors that are listed as deprecated are still\r\navailable on subsequent platforms (provided the sensor is present on a device), which is in line with Android's\r\nforward compatibility policy.\r\nTable 2. Sensor availability by platform.\r\n1\r\n This sensor type was added in Android 1.5 (API Level 3), but it was not available for use until Android 2.3 (API\r\nLevel 9).\r\n2\r\n This sensor is available, but it has been deprecated.\r\nIdentifying Sensors and Sensor Capabilities\r\nThe Android sensor framework provides several methods that make it easy for you to determine at runtime which\r\nsensors are on a device. The API also provides methods that let you determine the capabilities of each sensor, such\r\nas its maximum range, its resolution, and its power requirements.\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 4 of 16\n\nTo identify the sensors that are on a device you first need to get a reference to the sensor service. To do this, you\r\ncreate an instance of the SensorManager class by calling the getSystemService() method and passing in the\r\nSENSOR_SERVICE argument. For example:\r\nprivate lateinit var sensorManager: SensorManager\r\n...\r\nsensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager\r\nprivate SensorManager sensorManager;\r\n...\r\nsensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);\r\nNext, you can get a listing of every sensor on a device by calling the getSensorList() method and using the\r\nTYPE_ALL constant. For example:\r\nval deviceSensors: List\u003cSensor\u003e = sensorManager.getSensorList(Sensor.TYPE_ALL)\r\nList\u003cSensor\u003e deviceSensors = sensorManager.getSensorList(Sensor.TYPE_ALL);\r\nIf you want to list all of the sensors of a given type, you could use another constant instead of TYPE_ALL such as\r\nTYPE_GYROSCOPE , TYPE_LINEAR_ACCELERATION , or TYPE_GRAVITY .\r\nYou can also determine whether a specific type of sensor exists on a device by using the getDefaultSensor()\r\nmethod and passing in the type constant for a specific sensor. If a device has more than one sensor of a given type,\r\none of the sensors must be designated as the default sensor. If a default sensor does not exist for a given type of\r\nsensor, the method call returns null, which means the device does not have that type of sensor. For example, the\r\nfollowing code checks whether there's a magnetometer on a device:\r\nprivate lateinit var sensorManager: SensorManager\r\n...\r\nsensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager\r\nif (sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD) != null) {\r\n // Success! There's a magnetometer.\r\n} else {\r\n // Failure! No magnetometer.\r\n}\r\nprivate SensorManager sensorManager;\r\n...\r\nsensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);\r\nif (sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD) != null){\r\n // Success! There's a magnetometer.\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 5 of 16\n\n} else {\r\n // Failure! No magnetometer.\r\n}\r\nNote: Android does not require device manufacturers to build any particular types of sensors into their Android-powered devices, so devices can have a wide range of sensor configurations.\r\nIn addition to listing the sensors that are on a device, you can use the public methods of the Sensor class to\r\ndetermine the capabilities and attributes of individual sensors. This is useful if you want your application to\r\nbehave differently based on which sensors or sensor capabilities are available on a device. For example, you can\r\nuse the getResolution() and getMaximumRange() methods to obtain a sensor's resolution and maximum range\r\nof measurement. You can also use the getPower() method to obtain a sensor's power requirements.\r\nTwo of the public methods are particularly useful if you want to optimize your application for different\r\nmanufacturer's sensors or different versions of a sensor. For example, if your application needs to monitor user\r\ngestures such as tilt and shake, you could create one set of data filtering rules and optimizations for newer devices\r\nthat have a specific vendor's gravity sensor, and another set of data filtering rules and optimizations for devices\r\nthat do not have a gravity sensor and have only an accelerometer. The following code sample shows you how you\r\ncan use the getVendor() and getVersion() methods to do this. In this sample, we're looking for a gravity\r\nsensor that lists Google LLC as the vendor and has a version number of 3. If that particular sensor is not present\r\non the device, we try to use the accelerometer.\r\nprivate lateinit var sensorManager: SensorManager\r\nprivate var mSensor: Sensor? = null\r\n...\r\nsensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager\r\nif (sensorManager.getDefaultSensor(Sensor.TYPE_GRAVITY) != null) {\r\n val gravSensors: List\u003cSensor\u003e = sensorManager.getSensorList(Sensor.TYPE_GRAVITY)\r\n // Use the version 3 gravity sensor.\r\n mSensor = gravSensors.firstOrNull { it.vendor.contains(\"Google LLC\") \u0026\u0026 it.version == 3 }\r\n}\r\nif (mSensor == null) {\r\n // Use the accelerometer.\r\n mSensor = if (sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) != null) {\r\n sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)\r\n } else {\r\n // Sorry, there are no accelerometers on your device.\r\n // You can't play this game.\r\n null\r\n }\r\n}\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 6 of 16\n\nprivate SensorManager sensorManager;\r\nprivate Sensor mSensor;\r\n...\r\nsensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);\r\nmSensor = null;\r\nif (sensorManager.getDefaultSensor(Sensor.TYPE_GRAVITY) != null){\r\n List\u003cSensor\u003e gravSensors = sensorManager.getSensorList(Sensor.TYPE_GRAVITY);\r\n for(int i=0; i\u003cgravSensors.size(); i++) {\r\n if ((gravSensors.get(i).getVendor().contains(\"Google LLC\")) \u0026\u0026\r\n (gravSensors.get(i).getVersion() == 3)){\r\n // Use the version 3 gravity sensor.\r\n mSensor = gravSensors.get(i);\r\n }\r\n }\r\n}\r\nif (mSensor == null){\r\n // Use the accelerometer.\r\n if (sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) != null){\r\n mSensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);\r\n } else{\r\n // Sorry, there are no accelerometers on your device.\r\n // You can't play this game.\r\n }\r\n}\r\nAnother useful method is the getMinDelay() method, which returns the minimum time interval (in\r\nmicroseconds) a sensor can use to sense data. Any sensor that returns a non-zero value for the getMinDelay()\r\nmethod is a streaming sensor. Streaming sensors sense data at regular intervals and were introduced in Android 2.3\r\n(API Level 9). If a sensor returns zero when you call the getMinDelay() method, it means the sensor is not a\r\nstreaming sensor because it reports data only when there is a change in the parameters it is sensing.\r\nThe getMinDelay() method is useful because it lets you determine the maximum rate at which a sensor can\r\nacquire data. If certain features in your application require high data acquisition rates or a streaming sensor, you\r\ncan use this method to determine whether a sensor meets those requirements and then enable or disable the\r\nrelevant features in your application accordingly.\r\nCaution: A sensor's maximum data acquisition rate is not necessarily the rate at which the sensor framework\r\ndelivers sensor data to your application. The sensor framework reports data through sensor events, and several\r\nfactors influence the rate at which your application receives sensor events. For more information, see Monitoring\r\nSensor Events.\r\nMonitoring Sensor Events\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 7 of 16\n\nTo monitor raw sensor data you need to implement two callback methods that are exposed through the\r\nSensorEventListener interface: onAccuracyChanged() and onSensorChanged() . The Android system calls\r\nthese methods whenever the following occurs:\r\nA sensor's accuracy changes.\r\nIn this case the system invokes the onAccuracyChanged() method, providing you with a reference to the\r\nSensor object that changed and the new accuracy of the sensor. Accuracy is represented by one of four\r\nstatus constants: SENSOR_STATUS_ACCURACY_LOW , SENSOR_STATUS_ACCURACY_MEDIUM ,\r\nSENSOR_STATUS_ACCURACY_HIGH , or SENSOR_STATUS_UNRELIABLE .\r\nA sensor reports a new value.\r\nIn this case the system invokes the onSensorChanged() method, providing you with a SensorEvent\r\nobject. A SensorEvent object contains information about the new sensor data, including: the accuracy of\r\nthe data, the sensor that generated the data, the timestamp at which the data was generated, and the new\r\ndata that the sensor recorded.\r\nThe following code shows how to use the onSensorChanged() method to monitor data from the light sensor. This\r\nexample displays the raw sensor data in a TextView that is defined in the main.xml file as sensor_data .\r\nclass SensorActivity : Activity(), SensorEventListener {\r\n private lateinit var sensorManager: SensorManager\r\n private var mLight: Sensor? = null\r\n public override fun onCreate(savedInstanceState: Bundle?) {\r\n super.onCreate(savedInstanceState)\r\n setContentView(R.layout.main)\r\n sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager\r\n mLight = sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT)\r\n }\r\n override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {\r\n // Do something here if sensor accuracy changes.\r\n }\r\n override fun onSensorChanged(event: SensorEvent) {\r\n // The light sensor returns a single value.\r\n // Many sensors return 3 values, one for each axis.\r\n val lux = event.values[0]\r\n // Do something with this sensor value.\r\n }\r\n override fun onResume() {\r\n super.onResume()\r\n mLight?.also { light -\u003e\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 8 of 16\n\nsensorManager.registerListener(this, light, SensorManager.SENSOR_DELAY_NORMAL)\r\n }\r\n }\r\n override fun onPause() {\r\n super.onPause()\r\n sensorManager.unregisterListener(this)\r\n }\r\n}\r\npublic class SensorActivity extends Activity implements SensorEventListener {\r\n private SensorManager sensorManager;\r\n private Sensor mLight;\r\n @Override\r\n public final void onCreate(Bundle savedInstanceState) {\r\n super.onCreate(savedInstanceState);\r\n setContentView(R.layout.main);\r\n sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);\r\n mLight = sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);\r\n }\r\n @Override\r\n public final void onAccuracyChanged(Sensor sensor, int accuracy) {\r\n // Do something here if sensor accuracy changes.\r\n }\r\n @Override\r\n public final void onSensorChanged(SensorEvent event) {\r\n // The light sensor returns a single value.\r\n // Many sensors return 3 values, one for each axis.\r\n float lux = event.values[0];\r\n // Do something with this sensor value.\r\n }\r\n @Override\r\n protected void onResume() {\r\n super.onResume();\r\n sensorManager.registerListener(this, mLight, SensorManager.SENSOR_DELAY_NORMAL);\r\n }\r\n @Override\r\n protected void onPause() {\r\n super.onPause();\r\n sensorManager.unregisterListener(this);\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 9 of 16\n\n}\r\n}\r\nIn this example, the default data delay ( SENSOR_DELAY_NORMAL ) is specified when the registerListener()\r\nmethod is invoked. The data delay (or sampling rate) controls the interval at which sensor events are sent to your\r\napplication via the onSensorChanged() callback method. The default data delay is suitable for monitoring typical\r\nscreen orientation changes and uses a delay of 200,000 microseconds. You can specify other data delays, such as\r\nSENSOR_DELAY_GAME (20,000 microsecond delay), SENSOR_DELAY_UI (60,000 microsecond delay), or\r\nSENSOR_DELAY_FASTEST (0 microsecond delay). As of Android 3.0 (API Level 11) you can also specify the delay\r\nas an absolute value (in microseconds).\r\nThe delay that you specify is only a suggested delay. The Android system and other applications can alter this\r\ndelay. As a best practice, you should specify the largest delay that you can because the system typically uses a\r\nsmaller delay than the one you specify (that is, you should choose the slowest sampling rate that still meets the\r\nneeds of your application). Using a larger delay imposes a lower load on the processor and therefore uses less\r\npower.\r\nThere is no public method for determining the rate at which the sensor framework is sending sensor events to your\r\napplication; however, you can use the timestamps that are associated with each sensor event to calculate the\r\nsampling rate over several events. You should not have to change the sampling rate (delay) once you set it. If for\r\nsome reason you do need to change the delay, you will have to unregister and reregister the sensor listener.\r\nIt's also important to note that this example uses the onResume() and onPause() callback methods to register\r\nand unregister the sensor event listener. As a best practice you should always disable sensors you don't need,\r\nespecially when your activity is paused. Failing to do so can drain the battery in just a few hours because some\r\nsensors have substantial power requirements and can use up battery power quickly. The system will not disable\r\nsensors automatically when the screen turns off.\r\nHandling Different Sensor Configurations\r\nAndroid does not specify a standard sensor configuration for devices, which means device manufacturers can\r\nincorporate any sensor configuration that they want into their Android-powered devices. As a result, devices can\r\ninclude a variety of sensors in a wide range of configurations. If your application relies on a specific type of\r\nsensor, you have to ensure that the sensor is present on a device so your app can run successfully.\r\nYou have two options for ensuring that a given sensor is present on a device:\r\nDetect sensors at runtime and enable or disable application features as appropriate.\r\nUse Google Play filters to target devices with specific sensor configurations.\r\nEach option is discussed in the following sections.\r\nDetecting sensors at runtime\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 10 of 16\n\nIf your application uses a specific type of sensor, but doesn't rely on it, you can use the sensor framework to detect\nthe sensor at runtime and then disable or enable application features as appropriate. For example, a navigation\napplication might use the temperature sensor, pressure sensor, GPS sensor, and geomagnetic field sensor to display\nthe temperature, barometric pressure, location, and compass bearing. If a device doesn't have a pressure sensor,\nyou can use the sensor framework to detect the absence of the pressure sensor at runtime and then disable the\nportion of your application's UI that displays pressure. For example, the following code checks whether there's a\npressure sensor on a device:\nprivate lateinit var sensorManager: SensorManager\n...\nsensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager\nif (sensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE) != null) {\n // Success! There's a pressure sensor.\n} else {\n // Failure! No pressure sensor.\n}\nprivate SensorManager sensorManager;\n...\nsensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);\nif (sensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE) != null){\n // Success! There's a pressure sensor.\n} else {\n // Failure! No pressure sensor.\n}\nUsing Google Play filters to target specific sensor configurations\nIf you are publishing your application on Google Play you can use the element in your manifest\nfile to filter your application from devices that do not have the appropriate sensor configuration for your\napplication. The element has several hardware descriptors that let you filter applications based\non the presence of specific sensors. The sensors you can list include: accelerometer, barometer, compass\n(geomagnetic field), gyroscope, light, and proximity. The following is an example manifest entry that filters apps\nthat do not have an accelerometer:\nIf you add this element and descriptor to your application's manifest, users will see your application on Google\nPlay only if their device has an accelerometer.\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\nPage 11 of 16\n\nYou should set the descriptor to android:required=\"true\" only if your application relies entirely on a specific\r\nsensor. If your application uses a sensor for some functionality, but still runs without the sensor, you should list the\r\nsensor in the \u003cuses-feature\u003e element, but set the descriptor to android:required=\"false\" . This helps ensure\r\nthat devices can install your app even if they do not have that particular sensor. This is also a project management\r\nbest practice that helps you keep track of the features your application uses. Keep in mind, if your application uses\r\na particular sensor, but still runs without the sensor, then you should detect the sensor at runtime and disable or\r\nenable application features as appropriate.\r\nSensor Coordinate System\r\nIn general, the sensor framework uses a standard 3-axis coordinate system to express data values. For most\r\nsensors, the coordinate system is defined relative to the device's screen when the device is held in its default\r\norientation (see figure 1). When a device is held in its default orientation, the X axis is horizontal and points to the\r\nright, the Y axis is vertical and points up, and the Z axis points toward the outside of the screen face. In this\r\nsystem, coordinates behind the screen have negative Z values. This coordinate system is used by the following\r\nsensors:\r\nFigure 1. Coordinate system (relative to a device) that's used by the Sensor API.\r\nAcceleration sensor\r\nGravity sensor\r\nGyroscope\r\nLinear acceleration sensor\r\nGeomagnetic field sensor\r\nThe most important point to understand about this coordinate system is that the axes are not swapped when the\r\ndevice's screen orientation changes—that is, the sensor's coordinate system never changes as the device moves.\r\nThis behavior is the same as the behavior of the OpenGL coordinate system.\r\nAnother point to understand is that your application must not assume that a device's natural (default) orientation is\r\nportrait. The natural orientation for many tablet devices is landscape. And the sensor coordinate system is always\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 12 of 16\n\nbased on the natural orientation of a device.\nFinally, if your application matches sensor data to the on-screen display, you need to use the getRotation()\nmethod to determine screen rotation, and then use the remapCoordinateSystem() method to map sensor\ncoordinates to screen coordinates. You need to do this even if your manifest specifies portrait-only display.\nNote: Some sensors and methods use a coordinate system that is relative to the world's frame of reference (as\nopposed to the device's frame of reference). These sensors and methods return data that represent device motion or\ndevice position relative to the earth. For more information, see the getOrientation() method, the\ngetRotationMatrix() method, Orientation Sensor, and Rotation Vector Sensor.\nSensor Rate-Limiting\nTo protect potentially sensitive information about users, if your app targets Android 12 (API level 31) or higher,\nthe system places a limit on the refresh rate of data from certain motion sensors and position sensors. This data\nincludes values recorded by the device's accelerometer, gyroscope, and geomagnetic field sensor.\nThe refresh rate limit depends on how you access sensor data:\nIf you call the registerListener() method to monitor sensor events, the sensor sampling rate is limited\nto 200 Hz. This is true for all overloaded variants of the registerListener() method.\nIf you use the SensorDirectChannel class, the sensor sampling rate is limited to RATE_NORMAL , which is\nusually about 50 Hz.\nIf your app needs to gather motion sensor data at a higher rate, you must declare the\nHIGH_SAMPLING_RATE_SENSORS permission, as shown in the following code snippet. Otherwise, if your app tries to\ngather motion sensor data at a higher rate without declaring this permission, a SecurityException occurs.\nAndroidManifest.xml\n... Best Practices for Accessing and Using Sensors\nAs you design your sensor implementation, be sure to follow the guidelines that are discussed in this section.\nThese guidelines are recommended best practices for anyone who is using the sensor framework to access sensors\nand acquire sensor data.\nOnly gather sensor data in the foreground\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\nPage 13 of 16\n\nOn devices running Android 9 (API level 28) or higher, apps running in the background have the following\r\nrestrictions:\r\nSensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive\r\nevents.\r\nSensors that use the on-change or one-shot reporting modes don't receive events.\r\nGiven these restrictions, it's best to detect sensor events either when your app is in the foreground or as part of a\r\nforeground service.\r\nUnregister sensor listeners\r\nBe sure to unregister a sensor's listener when you are done using the sensor or when the sensor activity pauses. If a\r\nsensor listener is registered and its activity is paused, the sensor will continue to acquire data and use battery\r\nresources unless you unregister the sensor. The following code shows how to use the onPause() method to\r\nunregister a listener:\r\nprivate lateinit var sensorManager: SensorManager\r\n...\r\noverride fun onPause() {\r\n super.onPause()\r\n sensorManager.unregisterListener(this)\r\n}\r\nprivate SensorManager sensorManager;\r\n...\r\n@Override\r\nprotected void onPause() {\r\n super.onPause();\r\n sensorManager.unregisterListener(this);\r\n}\r\nFor more information, see unregisterListener(SensorEventListener) .\r\nTest with the Android Emulator\r\nThe Android Emulator includes a set of virtual sensor controls that allow you to test sensors such as\r\naccelerometer, ambient temperature, magnetometer, proximity, light, and more.\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 14 of 16\n\nThe emulator uses a connection with an Android device that is running the SdkControllerSensor app. Note that\r\nthis app is available only on devices running Android 4.0 (API level 14) or higher. (If the device is running\r\nAndroid 4.0, it must have Revision 2 installed.) The SdkControllerSensor app monitors changes in the sensors on\r\nthe device and transmits them to the emulator. The emulator is then transformed based on the new values that it\r\nreceives from the sensors on your device.\r\nYou can view the source code for the SdkControllerSensor app in the following location:\r\n$ your-android-sdk-directory/tools/apps/SdkController\r\nTo transfer data between your device and the emulator, follow these steps:\r\n1. Check that USB debugging is enabled on your device.\r\n2. Connect your device to your development machine using a USB cable.\r\n3. Start the SdkControllerSensor app on your device.\r\n4. In the app, select the sensors that you want to emulate.\r\n5. Run the following adb command:\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 15 of 16\n\n$ adb forward tcp:1968 tcp:1968\r\n6. Start the emulator. You should now be able to apply transformations to the emulator by moving your\r\ndevice.\r\nNote: If the movements that you make to your physical device aren't transforming the emulator, try running the\r\nadb command from step 5 again.\r\nFor more information, see the Android Emulator guide.\r\nDon't block the onSensorChanged() method\r\nSensor data can change at a high rate, which means the system may call the onSensorChanged(SensorEvent)\r\nmethod quite often. As a best practice, you should do as little as possible within the\r\nonSensorChanged(SensorEvent) method so you don't block it. If your application requires you to do any data\r\nfiltering or reduction of sensor data, you should perform that work outside of the\r\nonSensorChanged(SensorEvent) method.\r\nAvoid using deprecated methods or sensor types\r\nSeveral methods and constants have been deprecated. In particular, the TYPE_ORIENTATION sensor type has been\r\ndeprecated. To get orientation data you should use the getOrientation() method instead. Likewise, the\r\nTYPE_TEMPERATURE sensor type has been deprecated. You should use the TYPE_AMBIENT_TEMPERATURE sensor type\r\ninstead on devices that are running Android 4.0.\r\nVerify sensors before you use them\r\nAlways verify that a sensor exists on a device before you attempt to acquire data from it. Don't assume that a\r\nsensor exists simply because it's a frequently-used sensor. Device manufacturers are not required to provide any\r\nparticular sensors in their devices.\r\nChoose sensor delays carefully\r\nWhen you register a sensor with the registerListener() method, be sure you choose a delivery rate that is\r\nsuitable for your application or use-case. Sensors can provide data at very high rates. Allowing the system to send\r\nextra data that you don't need wastes system resources and uses battery power.\r\nSource: https://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nhttps://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://developer.android.com/guide/topics/sensors/sensors_overview#sensors-practices"
	],
	"report_names": [
		"sensors_overview#sensors-practices"
	],
	"threat_actors": [],
	"ts_created_at": 1775434386,
	"ts_updated_at": 1775791217,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/56580f48a98fd133833e3dc4fd77417eee897e50.pdf",
		"text": "https://archive.orkl.eu/56580f48a98fd133833e3dc4fd77417eee897e50.txt",
		"img": "https://archive.orkl.eu/56580f48a98fd133833e3dc4fd77417eee897e50.jpg"
	}
}