How to Inspect Sensor Nanoapps and Context Hub Runtime on Android Using ADB dumpsys contexthub

Modern mobile devices operate continuous environmental and biometric sensing features—such as step counting, lift-to-wake, audio hotword detection, double-tap gestures, and crash detection—24 hours a day. If these background sensing algorithms ran continuously on the device’s main application processor (CPU), battery life would be depleted within hours. To maintain ultra-low power consumption, Android offloads continuous background processing to an isolated microcontroller or digital signal processor (DSP) subsystem known as the Context Hub Runtime Environment (CHRE).

Within CHRE, compact, event-driven compiled C/C++ applications called “nanoapps” process raw hardware sensor feeds while the main application processor remains in deep sleep. When a significant event occurs (such as a sudden vehicular collision or step milestone), the nanoapp wakes the main Android operating system. Using the Android Debug Bridge (ADB) and the dumpsys contexthub diagnostic command, embedded engineers and Android developers can inspect running nanoapps, monitor DSP heap memory allocation, and trace messaging queues directly from the terminal.

Architecture of the Context Hub Runtime Environment (CHRE)

The Android Context Hub architecture operates across three distinct system tiers:

• Hardware Context Hub (DSP/MCU): A dedicated low-power coprocessor (such as a Qualcomm Hexagon DSP or Google Tensor sensor hub) running a lightweight real-time operating system (RTOS) and the CHRE runtime.
• Vendor HAL and Context Hub Service: The hardware abstraction layer (android.hardware.contexthub) and the framework system service (ContextHubService) inside system_server that manage nanoapp loading, firmware lifecycle, and message routing.
• Nanoapps: Modular, dynamically loadable binary packages compiled against CHRE APIs. Nanoapps possess unique 64-bit hexadecimal identifiers (App IDs) and register event handlers for sensor events, Wi-Fi RTT ranging, and audio triggers.

Inspecting Context Hub Service Diagnostics with dumpsys

To inspect the status of the Context Hub subsystem, connect your Android device with USB debugging enabled and execute dumpsys contexthub via ADB:

# Query the Context Hub system service diagnostics
adb shell dumpsys contexthub

The command dumps the registered Context Hub hardware instances, runtime versions, and active client connections:

Context Hub Service:
  Hub ID: 0 [ContextHubInfo: id=0, name=Google Sensor Hub, vendor=Google, version=1]
  Peak memory: 1048576 bytes
  Max message size: 4096 bytes
  Chre Platform Version: 0x01060000 (CHRE v1.6)
  Active clients: 4

The output confirms the physical vendor of the sensor coprocessor, the maximum supported message size exchanged across the inter-processor communication (IPC) boundary, and the compiled CHRE specification level.

Auditing Loaded Nanoapps and Memory Heap Usage

To view which sensor nanoapps are currently active and loaded inside coprocessor memory, inspect the nanoapp registry section in the dumpsys output:

# Query loaded nanoapps and their memory consumption
adb shell dumpsys contexthub | grep -A 15 "Loaded nanoapps:"

The terminal outputs a detailed list of all compiled nanoapps running on the coprocessor:

Loaded nanoapps:
  App ID: 0x476f6f676c001001 (Google Step Detector)
    Version: 1
    Permissions: [NanoappPerm: AUDIO, SENSORS]
    Memory: 18432 bytes static, 4096 bytes heap
  App ID: 0x476f6f676c002005 (Google Lift-to-Wake Gesture)
    Version: 2
    Permissions: [NanoappPerm: SENSORS]
    Memory: 12288 bytes static, 2048 bytes heap
  App ID: 0x476f6f676c003010 (Crash Detection Nanoapp)
    Version: 4
    Permissions: [NanoappPerm: SENSORS, LOCATION]
    Memory: 65536 bytes static, 16384 bytes heap

Key attributes include the 64-bit App ID, active security permissions, and precise memory footprints. If an experimental nanoapp leaks memory, its heap allocation increases over time, eventually triggering an out-of-memory exception on the DSP.

Monitoring Inter-Processor Message Queues

Communication between user-space Android applications and low-power nanoapps occurs via asynchronous messages. dumpsys contexthub tracks message transmission statistics across the IPC bridge:

# Inspect message queue telemetry and transaction latencies
adb shell dumpsys contexthub | grep -A 10 "Message stats:"

The output reveals message throughput and dropped packet rates:

Message stats:
  Total messages to nanoapps: 12480
  Total messages from nanoapps: 45192
  Dropped messages: 0
  Average round-trip latency: 1.2 ms

If Dropped messages is greater than zero, the low-power microcontroller is experiencing buffer starvation or processing delays, indicating that a sensor nanoapp is performing computationally heavy calculations that should be optimized.

Debugging Sensor Hub Crashes and Watchdog Resets

If an unhandled exception or memory fault occurs inside the Context Hub coprocessor, the hardware watchdog resets the DSP without crashing the main Android operating system. When this occurs, dumpsys contexthub logs crash diagnostics and restart counts:

# Query sensor hub reset and crash history
adb shell dumpsys contexthub | grep -i -E "reset|crash|recovery"

The diagnostic log records the timestamp of the reset, the fault address, and the specific nanoapp ID executing at the time of the panic, allowing firmware developers to isolate buggy algorithms quickly.

Using dumpsys contexthub provides embedded developers and mobile performance engineers with indispensable visibility into Android’s low-power sensor tier, ensuring responsive contextual awareness while maximizing battery longevity.