Lines Matching refs:nanoapp

14 as the nanoapp’s “client”. Since nanoapps are not limited to the same power
19 which is standardized across all CHRE implementations. This means that a nanoapp
23 a nanoapp does not need to be recompiled to run on a device that exposes a newer
61 Some boilerplate is needed to enable nanoapp to be built as a static nanoapp -
69 “preloaded” onto the device). The binaries associated with a preloaded nanoapp
82 2. For each nanoapp in the JSON file, the CHRE daemon reads the `.napp_header`
83    from storage, and sends a message to CHRE requesting it to load the nanoapp.
86    authenticating, linking, and starting the nanoapp.
90    avoid race conditions leading to clients believing that a preloaded nanoapp
100 At the binary level, a preloaded nanoapp and fully dynamic nanoapp are
104 and `.so` file for the actual binary, a fully dynamic nanoapp has the header
107 can be used to create a fully dynamic nanoapp file from these components.
124 CHRE also supports the concept of a *system nanoapp*, which is a nanoapp whose
127 nanoapp list at the HAL. This property is controlled by setting the
128 `NANOAPP_IS_SYSTEM_NANOAPP` variable in the nanoapp Makefile.
141 * `hello_world`: While not technically a FeatureWorld nanoapp, it’s generally
142   the first nanoapp to be tried, and it simply outputs a log message when it
150   nanoapp is typically customized prior to executing, for example to control
170 * `unload_tester`: Used in conjunction with the spammer nanoapp to verify that
171   unloading a nanoapp with pending events/messages completes successfully. Note
172   that this nanoapp references internal framework functions (e.g.
178 The `power_test` nanoapp is intended to be used in conjunction with special
180 components. This nanoapp is intended to be used with its host-side client,
183 5000000000` will configure the `power_test` nanoapp to request a WiFi scan every
189 `power_test` nanoapp.