Lines Matching full:to

10  * Unless required by applicable law or agreed to in writing, software
22  * This header file includes all the headers which combine to fully define the
24  * of interest to both implementers of CHREs and authors of nanoapps.  The API
25  * documentation attempts to address concerns of both.
43  * CHRE is the Context Hub Runtime Environment.  CHRE is used in Android to run
46  * API, documented herein, is the common interface exposed to nanoapps for any
49  * implementations and underlying platforms. Refer to the following sections for
55  * The following entry points are used to bind a nanoapp to the CHRE system, and
62  * prior to invoking nanoappStart, or after nanoappEnd returns:
63  * - bss section zeroed out (prior to nanoappStart)
64  * - static variables initialized (prior to nanoappStart)
65  * - global C++ constructors called (prior to nanoappStart)
70  * A CHRE implementation is free to choose among many different
72  * system with preemption.  The current platform definition is agnostic to this
76  * especially latency-sensitive tasks such as sensor event delivery to the AP.
82  * must be FIFO, but the CHRE implementation may choose to violate total
83  * ordering of events across all nanoapps to achieve more fair resource sharing,
90  * invoked if a previous invocation to the same or any other function in the
94  * not allowed to call nanoappHandleEvent() again, or to call a memory freeing
96  * callback, the CHRE is not allowed to call nanoappHandleEvent(), or invoke
99  * There are two exceptions to this rule: If an invocation of chreSendEvent()
100  * fails (returns 'false'), it is allowed to immediately invoke the memory
102  * where otherwise a CHRE implementation is likely to leak memory. Similarly,
103  * chreSendMessageToHost() is allowed to invoke the memory freeing callback
105  * implementation may copy the message data to its own buffer, and therefore
109  * For a nanoapp author, this means no thought needs to be given to
113  * [1]: Note to CHRE implementers: A future version of the CHRE platform may
115  * and to allow implementors deciding between implementation approaches to
120  * Nanoapps should expect to be running on a highly constrained system, with
121  * little memory and little CPU.  Any single nanoapp should expect to
125  * Thus, a nanoapp needs to be efficient in its memory and CPU usage.
129  * must run "quickly".  "Quickly" is difficult to define, as there is a
131  * to limit their application to consuming no more than 1 second of CPU time
132  * prior to returning control to the CHRE implementation.  A CHRE implementation
133  * may consider a nanoapp as unresponsive if it spends more time than this to
136  * A nanoapp may have the need to occasionally perform a large block of
138  * this case is to split up the large block of calculations into smaller
140  * batch, and then set a timer or send an event (chreSendEvent()) to itself
141  * indicating which batch should be done next. This will allow the nanoapp to
148  * is required to support 'float's.
151  * CHRE implementation.  Note that if a CHRE decides to support them, unlike
155  * If a CHRE implementation choses not to support 'double' or
156  * 'long double', then the build toolchain setup provided needs to set
161  * CHRE implementations must make affordances to maintain binary compatibility
162  * across minor revisions of the API version (e.g. v1.1 to v1.2).  This applies
163  * to both running a nanoapp compiled for a newer version of the API on a CHRE
166  * minor version changes that may require special measures to ensure binary
167  * compatibility include: addition of new functions; addition of arguments to
170  * and addition of fields to existing structures, even when this induces a
184  * approach to accomplish binary compatibility is to build a Nanoapp Support
185  * Library (NSL) that is specific to the CHRE implementation into the nanoapp
186  * binary, and use it to handle ABI details in a way that ensures compatibility.
187  * In addition, to accomplish forwards compatibility, the CHRE implementation is
188  * expected to recognize the CHRE API version that a nanoapp is targeting and
191  * By definition, major API version changes (e.g. v1.1 to v2.0) break
192  * compatibility.  Therefore, a CHRE implementation must not attempt to load a