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