How to Inspect Hardware Sensors and Active Listeners on Android Using ADB dumpsys sensor_service

Modern Android smartphones and tablets contain rich hardware sensor arrays, including accelerometers, gyroscopes, magnetometers, ambient light sensors, proximity detectors, barometers, and specialized step counters. When an application drains battery excessively or causes thermal throttling by polling hardware sensors continuously in the background at unthrottled sampling frequencies, isolating the culpable process through standard user interface menus is impossible. To inspect physical sensor registers, hardware batching queues, active event listeners, and package subscriptions, the Android Debug Bridge (ADB) provides the dumpsys sensor_service command.

Understanding the Android Sensor Framework Architecture

The Android sensor stack operates in a multi-layered hierarchy:

• Sensor Hardware & HAL: Physical micro-electromechanical (MEMS) sensors communicate with hardware sensor hubs via I2C or SPI buses. The Sensor Hardware Abstraction Layer (HAL) exposes standardized C interfaces to the framework.
• SensorService: The central system daemon (SensorService) runs within system_server, managing multi-client access, multiplexing hardware sample rates, enforcing background access restrictions, and delivering events to app listeners.
• Sensor Event Connections: Applications register listeners using SensorManager.registerListener(), establishing an active IPC channel with SensorService.

Generating a Full Sensor Diagnostics Dump

To inspect the entire sensor subsystem on a connected Android device, execute:

adb shell dumpsys sensor_service

The command outputs a comprehensive diagnostic dump comprising two main sections:

1. Sensor List: A catalogue of all registered physical and composite virtual sensors.
2. Active Connections: A real-time audit of every application process currently listening for sensor events.

Inspecting Physical and Virtual Sensor Capabilities

The first part of the output details device sensor hardware specifications:

Sensor List:
0x00000001) Accelerometer | Bosch BMI260 | ver: 1 | type: android.sensor.accelerometer(1) | perm: n/a | flags: 0x00000000
    continuous | minDelay=5000us | maxDelay=200000us | FIFO: 3000 events | 0.25mA
0x00000002) Magnetic Field Sensor | AKM AK09918 | ver: 1 | type: android.sensor.magnetic_field(2) | perm: n/a | flags: 0x00000000
    continuous | minDelay=10000us | maxDelay=200000us | FIFO: 600 events | 0.85mA
0x00000004) Gyroscope | Bosch BMI260 | ver: 1 | type: android.sensor.gyroscope(4) | perm: n/a | flags: 0x00000000
    continuous | minDelay=5000us | maxDelay=200000us | FIFO: 3000 events | 0.55mA

Key hardware metrics to note:

• Power Draw (mA): Identifies the operational current consumed by the sensor chip during active polling.
• minDelay / maxDelay: Defines the maximum sampling rate supported by hardware (e.g., minDelay=5000us corresponds to 200 Hz).
• FIFO Size: Indicates hardware event buffer capacity, allowing the main CPU to remain asleep while the sensor batches measurements.

Identifying Rogue Applications and Active Listeners

To identify which background application is holding sensors open and causing battery drain, inspect the active connections section:

adb shell dumpsys sensor_service | grep -A 15 "active connections"

The diagnostic log exposes active client sockets:

Total 2 active connections
Connection 0x7c41a200:
  Package: com.example.gameapp (uid 10184)
  Sampling period: 20000us (50.0 Hz)
  Max reporting latency: 0us (batching disabled)
  Sensors:
    android.sensor.accelerometer (handle=0x00000001)
    android.sensor.gyroscope (handle=0x00000004)
Connection 0x7c41b800:
  Package: com.google.android.gms (uid 10012)
  Sampling period: 200000us (5.0 Hz)
  Max reporting latency: 10000000us (batching enabled: 10s)
  Sensors:
    android.sensor.step_counter (handle=0x00000013)

Evaluating this output reveals:

• Package & UID: Confirms the exact application package responsible for maintaining the sensor connection.
• Sampling period: Demonstrates requested update frequencies. High frequencies (e.g., 20000us or 50Hz) prevent the CPU from entering low-power sleep states.
• Max reporting latency: If 0us, hardware batching is disabled, forcing instantaneous CPU interrupts on every sensor tick. Efficient apps configure batching (e.g., 10000000us) to receive batched events every 10 seconds.

Restricting Background Sensor Access via AppOps

If an application is consuming excessive power by polling sensors while in the background, you can revoke its sensor permissions via ADB without uninstalling the app:

adb shell cmd appops set com.example.gameapp BODY_SENSORS ignore

This restricts the application from receiving hardware sensor updates, immediately dropping its active connection in dumpsys sensor_service.