Lines Matching refs:to

5 The CHRE framework is easily extensible with no modifications to the core
7 steps must be performed. At a high-level, to add a new vendor-specific API to
13 2. Expose the new APIs from the framework to nanoapps, and connect them to a new
14    module to provide the desired functionality
17    event subsystem, to provide complete functionality that fits within the
20 It's best to refer to existing standard CHRE API feature areas, such as
28 it’s recommended to prefix the APIs with the vendor’s name as lowercase. For
30 ‘widget’ API, it’s recommended to use a naming scheme like
37 where vendors may wish or need to define a custom value in an existing field. To
39 only use values within vendor-reserved ranges. If you would like to add a new
40 value to an existing field for a vendor extension and a vendor-reserved range
41 does not already exist, please reach out to the CHRE team for guidance -
45 Vendors can only add on to the CHRE API - existing APIs must not be changed. Do
46 not modify core CHRE definitions, for example by adding on fields to common
53 If this API is intended to be open-sourced, it should be added to
56 `vendor/` in the Android tree, to avoid potential conflicts when upgrading to a
62 environment variable can be used to inject an external `.mk` file into the
65 additions needed to support the new vendor API. Refer to the CHRE framework
68 To expose the new functionality to nanoapps, it’s recommended to create a single
71 nanoapps should include in their Makefile prior to including
77 the EventLoop, so vendor extension code does not need to worry about race
78 conditions due to multiple nanoapps calling into APIs, and likewise nanoapps do
79 not need to worry about race conditions in its callbacks/handlers. However, it
80 is common for a platform module to receive data in a callback on another thread.
81 In that case, it is recommended to use `EventLoopManager::deferCallback()` to
82 pass the incoming data to the CHRE thread for processing, as opposed to using
83 mutexes or other synchronization primitives, to avoid multithreading-related
85 CHRE functionality is only safe to call from within the CHRE thread (other than
91 to `EventLoopManager` or initialized as part of `chre::init()` or
97 invoking `EventLoop::run()` to ensure that nanoapps don’t begin interacting with
103 code (refer to the Framework Overview documentation for details). The first step
104 once an API call reaches the framework is usually to call
105 `EventLoopManager::validateChreApiCall(__func__)`. This fetches a pointer to the
109 be used to invoke the appropriate functionality.
111 ## Sending Events to Nanoapps
113 Vendor extension APIs that need to pass data to a nanoapp asynchronously should
115 at `CHRE_EVENT_INTERNAL_EXTENDED_FIRST_EVENT` and extending to
121 executing, and/or cause the pending event queue to grow excessively during
122 periods of high activity. Refer to the GNSS and WWAN APIs for design patterns
123 related to passing data to a nanoapp asynchronously, using custom event payloads
126 Events can either be unicast to a nanoapp identified by its instance ID
127 (`Nanoapp::getInstanceId()`), or broadcast to all nanoapps registered for the
132 (via `EventLoopManagerSingleton::get()->getEventLoop()`) to pass events to
134 cannot be posted to the queue. Any memory referenced by `eventData` must not be