Lines Matching +full:power +full:- +full:off

11 low-power hardware. Typically, nanoapps integrate with a component on the
12 Android side, such as a privileged APK, in order to provide complete end-to-end
13 functionality of the target feature. This Android-side component is referred to
14 as the nanoapp’s “client”. Since nanoapps are not limited to the same power
16 much more frequently while the device’s screen is off.
20 is *code compatible* across devices - its source code does not need to be
31 hold a special privileged/same-signature permission (`ACCESS_CONTEXT_HUB`) to be
33 does not mean that third-party APKs cannot benefit from CHRE - nanoapps can be
34 used to power APIs available for use by any Android app.
50 can be useful during CHRE development and bring-up of new devices, especially
56 (using the `--gc-sections` option, or equivalent). Static nanoapps are
61 Some boilerplate is needed to enable nanoapp to be built as a static nanoapp -
75 While the mechanism for loading prebuilt nanoapps is platform-specific, the CHRE
120 example low-power tightly coupled memory (TCM, usually SRAM), versus a
121 higher-power but higher-capacity memory bank (such as DRAM). This distinction is
125 purpose is to accomplish some low-level, device-specific functionality that is
176 ### Power Test
179 hardware that directly measures the power usage of the system and/or its
180 components. This nanoapp is intended to be used with its host-side client,
184 5 seconds - the power monitoring equipment can then be used to determine the
185 power cost of performing a WiFi scan from CHRE. Typically this is done after
188 get a clean power trace of purely the functionality exercised by the
194 ### Nanoapps Used with Java-based Test Suites
198 upholds the requirements of the CHRE API. Much of the host-side Java code