Lines Matching refs:a
15 CHRE framework") is developed primarily in C++11 using a modular object-oriented
19 in more than one thread at a time, so CHRE is structured around a single thread
21 that support CHRE. The EventLoopManager is a Singleton object which owns the
25 To get a better understanding of code structure and how it weaves between common
26 and platform-specific components, it is helpful to trace the flow through a few
31 ## Loading a nanoapp via the HAL
33 There are multiple ways by which a nanoapp can be loaded (see the relevant
35 loading a nanoapp that has been passed in via the Context Hub HAL's
39 processor where CHRE is running using a platform-specific method. While the
54 object as needed, and passes it to `EventLoop::startNanoapp()` - this marks a
57 4. `EventLoop` takes ownership of the `Nanoapp` object (which is a composite of
64 code can vary by platform, transferring control from the framework to a
69 ## Invoking a CHRE API from a nanoapp
84 function is being called from the context of a nanoapp being executed within
85 the event loop (since associating the API call with a specific nanoapp is a
88 fetch a pointer to the current `Nanoapp` (i.e. it retrieves `mCurrentNanoapp`
107 ## Passing an event to a nanoapp
112 1. Starting in platform-specific code, likely in a different thread, the
114 typically happens in a different thread than the main CHRE thread, and within
146 Each framework module as described in the previous section is represented by a
151 functionality, such as multiplexing sensor requests from all clients into a
157 defined in a common header file (under `platform/include/chre/platform`), but
158 implemented in a platform-specific source file. In other words, it defines the
162 defined in a platform-specific header file, which allows for extending
175 it interacts with platform-specific code - it must always go through a common