Lines Matching refs:a
11 This section gives an overview of the steps one should take to add support for a
30 strictly necessary for a given platform to use it.
35 of a given platform, for example the APIs which are used to access functionality
37 layer for a given device may be composed of files from multiple
45 `platform/<platform_name>/<file_name>.cc`, but may appear in a subdirectory
59 Partners who add support for a new platform are recommended to upstream their
64 addressed in a timely fashion, and enables you to receive useful code review
68 If some parts of a platform’s CHRE implementation must be kept closed source,
69 then it is recommended to be kept in a separate Git project (under vendor/ in
76 When starting to add support for a new platform in the CHRE framework, it’s
82 CHRE provides various test nanoapps in `apps/` that exercise a particular
84 firmware statically via a `static_nanoapps.cc` source file.
88 1. Create a new platform with only empty stubs, with optional features (like
91 2. Work on updating the build system to add a new build target and achieve
101 5. Add static nanoapp initialization support (usually this is just a copy/paste
110 with a combination of the message world nanoapp and the host-side test code
122 underlying CHRE implementation, but as CHRE is implemented on a different
128 implementations are able to choose a different protocol if desired, but would
129 require a new HAL implementation), and passes the messages to and from the CHRE
130 daemon over a socket. The CHRE daemon is in turn responsible for communicating
145 When adding support for a new platform, a new HAL implementation and/or daemon
153 support a desired nanoapp. CHRE feature areas include sensors, GNSS, audio, and
169 included in the `shared` platform directory may be used. PALs provide a C API
170 which is suitable for use as a binary interface, for example between two dynamic
175 framework to work with a module that implements a different minor version of the
178 While it is possible for a PAL implementation to simultaneously support multiple
181 benefits of a common PAL binary are desired.
185 a platform implementation is included in AOSP, then it is possible for the
190 If a feature area is not supported, setting the make variable
202 may retrieve a reference to other objects in CHRE via
203 `EventLoopManagerSingleton::get()`, which returns a pointer to the
212 framework do not have a stable API.
214 If a PAL implementation is provided as a dynamic module in binary form, it can
240 deploy a single nanoapp binary across multiple devices, even if they support
243 * Makes it possible to update nanoapps without requiring a system reboot,
244 particularly on platforms where CHRE runs as part of a statically compiled
249 While dynamic loading is a responsibility of the platform implementation and may
250 already be a part of the underlying OS/system capabilities, the CHRE team is
251 working on a reference implementation for a future release. Please reach out via