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.
45  * CHRE is the Context Hub Runtime Environment.  CHRE is used in Android to run
48  * API, documented herein, is the common interface exposed to nanoapps for any
51  * implementations and underlying platforms. Refer to the following sections for
57  * The following entry points are used to bind a nanoapp to the CHRE system, and
64  * prior to invoking nanoappStart, or after nanoappEnd returns:
65  * - bss section zeroed out (prior to nanoappStart)
66  * - static variables initialized (prior to nanoappStart)
67  * - global C++ constructors called (prior to nanoappStart)
72  * A CHRE implementation is free to choose among many different
74  * system with preemption.  The current platform definition is agnostic to this
78  * especially latency-sensitive tasks such as sensor event delivery to the AP.
84  * must be FIFO, but the CHRE implementation may choose to violate total
85  * ordering of events across all nanoapps to achieve more fair resource sharing,
92  * invoked if a previous invocation to the same or any other function in the
96  * not allowed to call nanoappHandleEvent() again, or to call a memory freeing
98  * callback, the CHRE is not allowed to call nanoappHandleEvent(), or invoke
101  * There are two exceptions to this rule: If an invocation of chreSendEvent()
102  * fails (returns 'false'), it is allowed to immediately invoke the memory
104  * where otherwise a CHRE implementation is likely to leak memory. Similarly,
105  * chreSendMessageToHost() is allowed to invoke the memory freeing callback
107  * implementation may copy the message data to its own buffer, and therefore
111  * For a nanoapp author, this means no thought needs to be given to
115  * [1]: Note to CHRE implementers: A future version of the CHRE platform may
117  * and to allow implementors deciding between implementation approaches to
122  * Nanoapps should expect to be running on a highly constrained system, with
123  * little memory and little CPU.  Any single nanoapp should expect to
127  * Thus, a nanoapp needs to be efficient in its memory and CPU usage.
131  * must run "quickly".  "Quickly" is difficult to define, as there is a
133  * to limit their application to consuming no more than 1 second of CPU time
134  * prior to returning control to the CHRE implementation.  A CHRE implementation
135  * may consider a nanoapp as unresponsive if it spends more time than this to
138  * A nanoapp may have the need to occasionally perform a large block of
140  * this case is to split up the large block of calculations into smaller
142  * batch, and then set a timer or send an event (chreSendEvent()) to itself
143  * indicating which batch should be done next. This will allow the nanoapp to
150  * is required to support 'float's.
153  * CHRE implementation.  Note that if a CHRE decides to support them, unlike
157  * If a CHRE implementation chooses not to support 'double' or
158  * 'long double', then the build toolchain setup provided needs to set
163  * CHRE implementations must make affordances to maintain binary compatibility
164  * across minor revisions of the API version (e.g. v1.1 to v1.2).  This applies
165  * to both running a nanoapp compiled for a newer version of the API on a CHRE
168  * minor version changes that may require special measures to ensure binary
169  * compatibility include: addition of new functions; addition of arguments to
172  * and addition of fields to existing structures, even when this induces a
186  * approach to accomplish binary compatibility is to build a Nanoapp Support
187  * Library (NSL) that is specific to the CHRE implementation into the nanoapp
188  * binary, and use it to handle ABI details in a way that ensures compatibility.
189  * In addition, to accomplish forwards compatibility, the CHRE implementation is
190  * expected to recognize the CHRE API version that a nanoapp is targeting and
193  * By definition, major API version changes (e.g. v1.1 to v2.0) break
194  * compatibility.  Therefore, a CHRE implementation must not attempt to load a