Overview of Context Hub Runtime Environment (CHRE) Architecture and NanoApp Development

CHRE (Context Hub Runtime Environment) is a Google‑provided software platform that runs applications on low‑power processors. It offers a simple, standardized, and embedded‑friendly API for sensors, Bluetooth, Wi‑Fi, audio and other modules, and is widely used in Android system development.

The overall architecture (Figure 1) consists of multiple layers. An APP, after obtaining the ACCESS_CONTEXT_HUB permission, interacts with the ContextHubManager , which communicates with the ContextHub HAL via socket and FastRPC. The HAL then controls Nanoapps that run inside the CHRE environment, enabling direct APP‑hardware interaction.

Figure 1. CHRE framework architecture

The code base is organized into several directories (Figure 2):

ContextHubManager – located in core/java/android/hardware/location , provides the API for APPs.

ContextHub HAL – located in system/chre/host/hal_generic , acts as a bridge between HAL and CHRE.

CHRE – located in system/chre , contains the core CHRE implementation.

Figure 2. CHRE code directory

The CHRE source also contains directories such as Apps (sample Nanoapps), Build (Makefiles), Chpp (Context Hub Peripheral Protocol), Core (framework core), Doc (documentation), External (third‑party libraries), Host (reference HAL implementation), PAL (Platform Abstraction Layer), and Platform‑specific code.

Communication between an APP and CHRE is performed through ContextHubManager using APIs such as:

getContextHubInfo

loadNanoApp

unloadNanoApp

getNanoAppInstanceInfo

findNanoAppOnHub

sendMessage

getContextHubs

createClient

These calls are forwarded to the ContextHub Service, which interacts with the HAL and ultimately with Nanoapps.

Figure 3. ContextHubManager class diagram

After registering a client and a callback, the APP receives Nanoapp state change notifications (loaded, unloaded, aborted, enabled, disabled) and messages sent by Nanoapps (Figure 4 and Figure 5 illustrate the callback and APP call flow).

Figure 4. ClientCallback functions

Figure 5. APP call flow

The Framework‑to‑HAL communication uses socket and FastRPC (Figure 6). The HAL registers as a FastRPC client, while the CHRE daemon registers as a service; they exchange messages such as loadNanoApp (Figure 7 and Figure 8 show HAL registration and a loadNanoApp example).

Figure 6. ContextHub HAL

Figure 7. HAL instance initialization

Figure 8. loadNanoApp example

HAL‑to‑CHRE communication (Figure 9) shows that the HAL registers as a FastRPC client, the CHRE daemon registers as a service, and messages are passed through the FastRPC daemon to the CHRE process.

Figure 9. HAL and CHRE communication

A Nanoapp must implement three entry points: nanoappStart() , nanoappHandleEvent() , and nanoappEnd() . The sensor example (system/chre/apps/sensor_world/sensor_world.cc) demonstrates declaration (providing name, id, version, permissions), resource acquisition and sensor initialization in nanoappStart , event handling (including sensor data, open/close, sampling rate, timer events) in nanoappHandleEvent , and cleanup in nanoappEnd (Figure 10‑13 illustrate the code snippets).

On a FreeRTOS platform, the CHRE thread is created during system initialization. The task runs chreThreadEntry , which initializes EventLoopManagerSingleton and loads static Nanoapps. The task then repeatedly processes the event loop, dispatching events to the appropriate Nanoapps via their handleEvent callbacks (see EventLoop::run()).

In summary, the article presents the CHRE workflow, including APP‑to‑CHRE communication, the runtime architecture, and Nanoapp development, providing a reference for learning and debugging CHRE.

Reference: Context Hub Runtime Environment (CHRE) documentation