Overview of CHRE (Context Hub Runtime Environment) Architecture, Code Structure, and Event Processing

CHRE (Context Hub Runtime Environment) is an event‑driven system built around a single event loop that executes nanoapp code and CHRE system callbacks. According to the CHRE API, a nanoapp can run on only one thread at a time, so the framework revolves around a single thread that drives the event loop. The EventLoopManager is a singleton that holds the main CHRE state, including the EventLoops and Manager classes for each subsystem.

1. Sensor Hub and CHRE Architecture Overview

The Sensor Hub runs algorithms and sensor drivers directly, tightly coupling drivers to algorithms and following the sensor HAL API. CHRE provides the platform for running nanoapps; each algorithm or sensor driver is implemented as a nanoapp. Communication between the host and the hub follows the Context Hub HAL API (host side) and CHRE API (hub side).

2. CHRE Code Directory Structure

The CHRE source tree is organized into several directories:

1) chre_api : stable API for nanoapps.

2) Core : platform‑independent code, especially event management.

3) Pal : abstract layer for device‑specific functions (e.g., GPS, sensors). PAL is a C API implemented by vendor libraries.

4) Platform : platform‑specific interfaces and implementations, including CHRE API implementations.

5) Apps : example nanoapps that illustrate usage; they are reference code, not required for CHRE operation.

6) Util : common data structures used by CHRE and utility code.

3. Nanoapp Structure on CHRE

A nanoapp consists of several parts, illustrated with the sensor_world example (source: sensor_world.cc ).

1) Nanoapp entry declaration – defines app ID, version, and performs initialization.

2) NanoappStart() – initializes the sensor module and platform resources.

3) NanoappEnd() – handles nanoapp shutdown.

4) NanoappHandleEvent() – processes events such as sensor enable/disable, sampling rate changes, and data reports.

4. CHRE Initialization Process

Using the SLPI platform as an example, the CHRE host calls chre_slpi_start_thread via fastRPC, which performs two main tasks: chre:init() (system time and event‑loop manager initialization) and creation of the chreThreadEntry thread.

Key source files:

platform/system/chre/+/refs/heads/master/platform/slpi/init.cc

platform/system/chre/+/refs/heads/master/core/init.cc

The chreThreadEntry thread loads static nanoapps, starts the message loop, and waits for system events. Source: platform/system/chre/+/refs/heads/master/platform/slpi/init.cc

5. CHRE Event Handling Flow

The event‑management code includes:

Event.cc / Event.h – defines system events and the interface for sending events to the host.

Event_loop.cc / Event_loop.h – implements the event loop, fetching messages from the queue and dispatching them to handlers.

Event_loop_manager.cc / Event_loop_manager.h – manages multiple event loops (Wi‑Fi, sensor, memory, host command, GNSS, etc.).

Event_ref_queue.cc / Event_ref_queue.h – implements the event queue with push and pop operations.

The core functions are deferCallback() (sends queued events to the appropriate nanoapp), run() (extracts events from the queue and dispatches them), and distributeEvent() (matches event IDs to target apps).

Reference: framework_overview.md