diff --git a/inc/chre.h b/inc/chre.h
index 0f2f8ca..950f03c 100644
--- a/inc/chre.h
+++ b/inc/chre.h
@@ -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 465c40a..c1c9510 100644
--- a/inc/chre_event.h
+++ b/inc/chre_event.h
@@ -202,7 +202,9 @@
  *     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 @@
  *     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 cea5ecb..31b0ed7 100644
--- a/inc/chre_re.h
+++ b/inc/chre_re.h
@@ -172,7 +172,6 @@
  *          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 @@
  * @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 aba1dd7..eafedd9 100644
--- a/inc/chre_sensor.h
+++ b/inc/chre_sensor.h
@@ -239,7 +239,7 @@
     (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 @@
  *
  * 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 @@
  * 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 @@
  *
  * 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]