diff options
| -rw-r--r-- | inc/chre.h | 28 | ||||
| -rw-r--r-- | inc/chre_event.h | 9 | ||||
| -rw-r--r-- | inc/chre_re.h | 3 | ||||
| -rw-r--r-- | inc/chre_sensor.h | 12 |
4 files changed, 39 insertions, 13 deletions
@@ -73,9 +73,15 @@ * callback, the CHRE is not allowed to call nanoappHandleEvent(), or invoke * another memory freeing callback. * - * For a nanoapp author, this means no thought needs to be given to - * synchronization issues with global objects, as they will, by definition, - * only be accessed by a single thread at once. + * There is one exception to this rule: If an invocation of chreSendEvent() + * or chreSendMessageToHost() fails (returns 'false'), it is allowed to + * immediately invoke the memory freeing callback passed into that function. + * This is a rare case, and one where otherwise a CHRE implementation is + * likely to leak memory. + * + * For a nanoapp author, this means no thought (outside of our one exception) + * needs to be given to synchronization issues with global objects, as they + * will, by definition, only be accessed by a single thread at once. * * * [1] Note to CHRE implementors: A future version of the CHRE platform may @@ -114,6 +120,22 @@ */ /** + * Floating point support. + * + * The C type 'float' is used in this API, and thus a CHRE implementation + * is required to support 'float's. + * + * Support of the C types 'double' and 'long double' is optional for a + * CHRE implementation. Note that if a CHRE decides to support them, unlike + * 'float' support, there is no requirement that this support is particularly + * efficient. So nanoapp authors should be aware this may be inefficient. + * + * If a CHRE implementation choses not to support 'double' or + * 'long double', then the build toolchain setup provided needs to set + * the preprocessor define CHRE_NO_DOUBLE_SUPPORT. + */ + +/** * CHRE and Nanoapp compatibility. * * The Android N release introduces the first version of this API. diff --git a/inc/chre_event.h b/inc/chre_event.h index 465c40ac..c1c95108 100644 --- a/inc/chre_event.h +++ b/inc/chre_event.h @@ -202,7 +202,9 @@ typedef void (chreMessageFreeFunction)(void *message, size_t messageSize); * to. Note that this is allowed to be our own instance. * @returns true if the event was enqueued, false otherwise. Note that even * if this method returns 'false', the 'freeCallback' will be invoked, - * if non-NULL. + * if non-NULL. Note in the 'false' case, the 'freeCallback' may be + * invoked directly from within chreSendEvent(), so it's necessary + * for nanoapp authors to avoid possible recursion with this. * * @see chreEventDataFreeFunction */ @@ -252,8 +254,9 @@ bool chreSendEvent(uint16_t eventType, void *eventData, * to be NULL, in which case no callback will be invoked. * @returns true if the message was accepted for transmission, false otherwise. * Note that even if this method returns 'false', the 'freeCallback' will - * be invoked, if non-NULL. - * + * be invoked, if non-NULL. Note in the 'false' case, the 'freeCallback' + * may be invoked directly from within chreSendMessageToHost(), so it's + * necessary for nanoapp authors to avoid possible recursion with this. * * @see chreMessageFreeFunction */ diff --git a/inc/chre_re.h b/inc/chre_re.h index cea5ecb0..31b0ed7c 100644 --- a/inc/chre_re.h +++ b/inc/chre_re.h @@ -172,7 +172,6 @@ uint32_t chreGetInstanceId(void); * leading zeros if needed to meet the minimum. * - 'f' context: Number of digits to output after the decimal * point (to the right of it). - * - 'g' context: Maximum number of digits to be output. * - 's' context: Maximum number of characters to output. * * Integral format specifiers: @@ -281,6 +280,8 @@ bool chreTimerCancel(uint32_t timerId); * @param abortCode A value indicating the reason for aborting. (Note that * in this version of the API, there is no way for anyone to access this * code, but future APIs may expose it.) + * @returns Never. This method does not return, as the CHRE stops nanoapp + * execution immediately. */ void chreAbort(uint32_t abortCode); diff --git a/inc/chre_sensor.h b/inc/chre_sensor.h index aba1dd79..eafedd96 100644 --- a/inc/chre_sensor.h +++ b/inc/chre_sensor.h @@ -239,7 +239,7 @@ extern "C" { (CHRE_EVENT_SENSOR_FIRST_EVENT + 0x0100) /** - * nanoappHandleEvent argument: struct chreSensorSamplingChangeEvent + * nanoappHandleEvent argument: struct chreSensorSamplingStatusEvent * * Indicates that the interval and/or the latency which this sensor is * sampling at has changed. @@ -721,11 +721,11 @@ bool chreGetSensorSamplingStatus(uint32_t sensorHandle, * * For example, the following is valid usage: * <code> - * chreSensorConfigure(myHandle, interval0, latency0, mode); + * chreSensorConfigure(myHandle, mode, interval0, latency0); * [...] - * chreSensorConfigure(myHandle, interval1, latency0, mode); + * chreSensorConfigure(myHandle, mode, interval1, latency0); * [...] - * chreSensorConfigure(myHandle, interval1, latency1, mode); + * chreSensorConfigure(myHandle, mode, interval1, latency1); * [...] * chreSensorConfigureModeOnly(myHandle, CHRE_SENSOR_CONFIGURE_MODE_DONE); * </code> @@ -741,7 +741,7 @@ bool chreGetSensorSamplingStatus(uint32_t sensorHandle, * DONE mode after that single event triggers. Thus, the * following are legitimate usages: * <code> - * chreSensorConfigure(myHandle, rate, latency, MODE_ONE_SHOT); + * chreSensorConfigure(myHandle, MODE_ONE_SHOT, rate, latency); * [...] * [myHandle triggers an event] * [no need to configure to DONE]. @@ -749,7 +749,7 @@ bool chreGetSensorSamplingStatus(uint32_t sensorHandle, * * And: * <code> - * chreSensorConfigure(myHandle, rate, latency, MODE_ONE_SHOT); + * chreSensorConfigure(myHandle, MODE_ONE_SHOT, rate, latency); * [...] * chreSensorConfigureModeOnly(myHandle, MODE_DONE); * [we cancelled myHandle before it ever triggered an event] |