diff --git a/src/devices/sensors/batching.jd b/src/devices/sensors/batching.jd
index 68e3632..405df88 100644
--- a/src/devices/sensors/batching.jd
+++ b/src/devices/sensors/batching.jd
@@ -32,18 +32,18 @@
 <h2 id="batch-function">batch(int handle, int flags, int64_t period_ns, int64_t
   max_report_latency)</h2>
 <p>Enabling batch mode for a given sensor sets the delay between events.
-  max_report_latency sets the maximum time by which events can be delayed and 
+  <code>max_report_latency</code> sets the maximum time by which events can be delayed and
   batched together before being reported to the applications. A value of zero 
-  disables batch mode for the given sensor. The period_ns parameter is equivalent 
+  disables batch mode for the given sensor. The <code>period_ns</code> parameter is equivalent
   to calling setDelay() -- this function both enables or disables the batch mode 
   AND sets the event's period in nanoseconds. See setDelay() for a detailed 
-  explanation of the period_ns parameter.</p>
+  explanation of the <code>period_ns</code> parameter.</p>
 <p>In non-batch mode, all sensor events must be reported as soon as they are 
   detected. For example, an accelerometer activated at 50Hz will trigger 
   interrupts 50 times per second.<br/>
   While in batch mode, sensor events do not need to be reported as soon as they 
   are detected. They can be temporarily stored and reported in batches, as long as 
-  no event is delayed by more than &quot;maxReportingLatency&quot; nanoseconds. That is, all events 
+  no event is delayed by more than <code>maxReportingLatency</code> nanoseconds. That is, all events 
   since the previous batch are recorded and returned at once. This reduces the 
   amount of interrupts sent to the SoC and allows the SoC to switch to a lower 
   power mode (idle) while the sensor is capturing and batching data.</p>
@@ -83,24 +83,26 @@
   even when the device goes into suspend mode.</p>
 <p>For a given rate, if a sensor has the capability to store at least 10 seconds 
   worth of events in its FIFO and is able to wake up the SoC, it can implement an 
-  optional secondary mode: the WAKE_UPON_FIFO_FULL mode.</p>
-<p>The caller will set the SENSORS_BATCH_WAKE_UPON_FIFO_FULL flag to activate this 
+  optional secondary mode: the <code>WAKE_UPON_FIFO_FULL</code> mode.</p>
+<p>The caller will set the <code>SENSORS_BATCH_WAKE_UPON_FIFO_FULL</code> flag to activate this
   mode. If the sensor does not support this mode, batch() will fail when the flag 
   is set.</p>
-<p>In batch mode, and only when the flag SENSORS_BATCH_WAKE_UPON_FIFO_FULL is
+<p>In batch mode, and only when the flag
+<code>SENSORS_BATCH_WAKE_UPON_FIFO_FULL</code> is
   set and supported, the specified sensor must be able to wake-up the SoC and be
   able to buffer at least 10 seconds worth of the requested sensor events.</p>
-<p>When running with the WAKE_UPON_FIFO_FULL flag set, no events can be lost. When 
+<p>When running with the <code>WAKE_UPON_FIFO_FULL</code> flag set, no events can be lost. When
   the FIFO is getting full, the sensor must wake up the SoC from suspend and 
   return a batch before the FIFO fills-up.</p>
 <p>Depending on the device, it might take a few milliseconds for the SoC to 
   entirely come out of suspend and start flushing the FIFO. Enough head room must 
   be allocated in the FIFO to allow the device to entirely come out of suspend 
   without the FIFO overflowing (no events shall be lost).</p>
-<p>Implementing the WAKE_UPON_FIFO_FULL mode is optional. If the hardware cannot 
+<p>Implementing the <code>WAKE_UPON_FIFO_FULL</code> mode is optional. If the hardware cannot
   support this mode, or if the physical FIFO is so small that the device would 
   never be allowed to go into suspend for at least 10 seconds, then this function 
-  <strong>must</strong> fail when the flag SENSORS_BATCH_WAKE_UPON_FIFO_FULL is set, regardless 
+  <strong>must</strong> fail when the flag
+<code>SENSORS_BATCH_WAKE_UPON_FIFO_FULL</code> is set, regardless
   of the value of the maxReportingLatency parameter.</p>
 <h2 id="Implementing">Implementing batching</h2>
 <p>Batch mode, if supported, should happen at the hardware level, typically using 
@@ -113,8 +115,8 @@
   as soon as one batch must be reported.</p>
 <p>For example, if the following sensors are activated:</p>
 <ul>
-  <li>accelerometer batched with maxReportingLatency = 20s</li>
-  <li>gyroscope batched with maxReportingLatency = 5s</li>
+  <li>accelerometer batched with <code>maxReportingLatency</code> = 20s</li>
+  <li>gyroscope batched with <code>maxReportingLatency</code> = 5s</li>
 </ul>
 <p>Then the accelerometer batches can be reported at the same time the gyroscope 
   batches are reported (every 5 seconds).<br/>
@@ -158,11 +160,11 @@
   Allows full collection of sensor data while leaving the SoC in<br/>
   suspend mode. Only to consider if fifo space is not an issue.<br/>
   <br/>
-  In each of the cases above, if WAKE_UPON_FIFO_FULL is implemented, the<br/>
+  In each of the cases above, if <code>WAKE_UPON_FIFO_FULL</code> is implemented, the<br/>
   applications might decide to let the SoC go to suspend, allowing for even<br/>
   more power savings.</p>
 <h2 id="Dry-run">Dry run</h2>
-<p>If the flag SENSORS_BATCH_DRY_RUN is set, this function returns without 
+<p>If the flag <code>SENSORS_BATCH_DRY_RUN</code> is set, this function returns without
   modifying the batch mode or the event period and has no side effects, but 
   returns errors as usual (as it would if this flag was not set). This flag is 
   used to check if batch mode is available for a given configuration, in 
@@ -170,8 +172,9 @@
 <h2 id="Return-values">Return values</h2>
 <p>Because sensors must be independent, the return value must not depend on the 
   state of the system (whether another sensor is on or not), nor on whether the 
-  flag SENSORS_BATCH_DRY_RUN is set (in other words, if a batch call with 
-  SENSORS_BATCH_DRY_RUN is successful, the same call without SENSORS_BATCH_DRY_RUN 
+  flag <code>SENSORS_BATCH_DRY_RUN</code> is set (in other words, if a batch call with
+  <code>SENSORS_BATCH_DRY_RUN</code> is successful, the same call without
+<code>SENSORS_BATCH_DRY_RUN</code>
   must succeed as well).</p>
 <p>If successful, 0 is returned.</p>
 <p>If the specified sensor doesn't support batch mode, -EINVAL is returned.<br/>
@@ -182,10 +185,10 @@
   time and not based on the state of the system.</p>
 <p>If some other constraints above cannot be satisfied, -EINVAL is returned.<br/>
   <br/>
-  Note: the maxReportingLatency parameter when &gt; 0 has no impact on whether this function 
-  succeeds or fails.<br/>
+  Note: The <code>maxReportingLatency</code> parameter when &gt; 0 has no impact on
+  whether this function succeeds or fails.<br/>
   <br/>
-  If maxReportingLatency is set to 0, this function must succeed.</p>
+  If <code>maxReportingLatency</code> is set to 0, this function must succeed.</p>
 <h2 id="Supporting-docs">Supporting documentation</h2>
 <p><a href="http://developer.android.com/guide/topics/sensors/index.html">Developer - Location and Sensors 
   APIs</a></p>
diff --git a/src/devices/sensors/composite_sensors.jd b/src/devices/sensors/composite_sensors.jd
index 2c98672..d3fbed2 100644
--- a/src/devices/sensors/composite_sensors.jd
+++ b/src/devices/sensors/composite_sensors.jd
@@ -131,7 +131,8 @@
 
 <p>Indicates the linear acceleration of the device in device coordinates, not 
 including gravity. The output is conceptually:<br/>
-output of TYPE_ACCELERATION minus output of TYPE_GRAVITY.</p>
+output of <code>TYPE_ACCELERATION</code> minus output of
+<code>TYPE_GRAVITY</code>.</p>
 
 <p>Readings on all axes should be close to 0 when the device is immobile. Units are 
 m/s^2. The coordinate system is the same as is used for the acceleration sensor.</p>
@@ -193,7 +194,7 @@
 application processor should not be allowed to go back to sleep in the 200 
 milliseconds following a wake-up interrupt.</p>
 
-<p>IMPORTANT NOTE: This sensor is very different from the other types in that it 
+<p><strong>Important</strong>: This sensor is very different from the other types in that it
 must work when the screen is off without the need for holding a partial wake 
 lock (other than the timeout wake lock) and MUST allow the SoC to go into 
 suspend. When significant motion is detected, the sensor must awaken the SoC and 
@@ -323,10 +324,10 @@
 <p>The rotation is encoded as the four (reordered) components of a unit quaternion:</p>
 
 <ul>
-<li>sensors_event_t.data[0] = rot_axis.x*sin(theta/2)</li>
-<li>sensors_event_t.data[1] = rot_axis.y*sin(theta/2)</li>
-<li>sensors_event_t.data[2] = rot_axis.z*sin(theta/2)</li>
-<li>sensors_event_t.data[3] = cos(theta/2)</li>
+<li><code>sensors_event_t.data[0]</code> = rot_axis.x*sin(theta/2)</li>
+<li><code>sensors_event_t.data[1]</code> = rot_axis.y*sin(theta/2)</li>
+<li><code>sensors_event_t.data[2]</code> = rot_axis.z*sin(theta/2)</li>
+<li><code>sensors_event_t.data[3]</code> = cos(theta/2)</li>
 </ul>
 
 <p>Where:</p>
@@ -341,7 +342,7 @@
 this will cause erratic client behaviour.</p>
 
 <p>In addition, this sensor reports an estimated heading accuracy:<br/>
-sensors_event_t.data[4] = estimated_accuracy (in radians)</p>
+<code>sensors_event_t.data[4]</code> = estimated_accuracy (in radians)</p>
 
 <p>The heading error must be less than estimated_accuracy 95% of the time. This 
 sensor must use a gyroscope and an accelerometer as main orientation change 
@@ -362,7 +363,7 @@
 magnitude as the gyroscope drifts around the Z axis.</p>
 
 <p>This sensor does not report an estimated heading accuracy:<br/>
-sensors_event_t.data[4] is reserved and should be set to 0</p>
+<code>sensors_event_t.data[4]</code> is reserved and should be set to 0</p>
 
 <p>In an ideal case, a phone rotated and returned to the same real-world 
 orientation should report the same game rotation vector (without using the 
@@ -397,7 +398,7 @@
 
 <p>Just like the rotation vector sensor, this sensor reports an estimated heading 
 accuracy:<br/>
-sensors_event_t.data[4] = estimated_accuracy (in radians)</p>
+<code>sensors_event_t.data[4]</code> = estimated_accuracy (in radians)</p>
 
 <p>The heading error must be less than estimated_accuracy 95% of the time.</p>
 
@@ -492,7 +493,8 @@
 <a href="{@docRoot}devices/sensors/base_triggers.html#Gyroscope">Gyroscope</a> sensor is used without drift compensation.</p>
 
 <p>If this sensor is present, then the corresponding Gyroscope sensor must be 
-present and both must return the same sensor_t::name and sensor_t::vendor.</p>
+present and both must return the same <code>sensor_t::name</code> and
+<code>sensor_t::vendor</code>.</p>
 
 <h3 id="Magnetic-field-uncalibrated">Magnetic field uncalibrated</h3>
 
@@ -525,7 +527,8 @@
 changes, and they should be stable the rest of the time.</p>
 
 <p>If this sensor is present, then the corresponding Geomagnetic field sensor must 
-be present and both must return the same  sensor_t::name and sensor_t::vendor.</p>
+be present and both must return the same  <code>sensor_t::name</code> and
+<code>sensor_t::vendor</code>.</p>
 
 <p>See the <a href="{@docRoot}devices/sensors/base_triggers.html#Geomagnetic">geomagnetic field</a> sensor description for more 
 information.<br/></p>
diff --git a/src/devices/sensors/index.jd b/src/devices/sensors/index.jd
index b47dd3b..e5fa438 100644
--- a/src/devices/sensors/index.jd
+++ b/src/devices/sensors/index.jd
@@ -55,7 +55,7 @@
   The JNI code associated with <a href="http://developer.android.com/reference/android/hardware/package-summary.html">android.hardware</a> is located in the frameworks/base/core/jni/ directory. This code calls the lower 
   level native code to obtain access to the sensor hardware.</p>
 <p>Native framework<br/>
-  The native framework is defined in frameworks/native/ and provides a native 
+  The native framework is defined in <code>frameworks/native/</code> and provides a native
   equivalent to the <a href="http://developer.android.com/reference/android/hardware/package-summary.html">android.hardware</a> package. The native framework calls the Binder IPC proxies to obtain access to 
   sensor-specific services.</p>
 <p>Binder IPC<br/>
@@ -64,7 +64,9 @@
   The Hardware Abstraction Layer (HAL) defines the standard interface that sensor 
   services call into and that you must implement to have your sensor hardware 
   function correctly. The sensor HAL interfaces are located in 
-  hardware/libhardware/include/hardware.</p>
+  <code>hardware/libhardware/include/hardware</code>. See <a
+href="http://source.android.com/devices/reference/sensors_8h.html">sensors.h</a> for
+additional details.</p>
 <p>Kernel Driver<br/>
   The sensors driver interacts with the hardware and your implementation of the 
   HAL. The HAL is driver-agnostic.</p>
@@ -171,14 +173,14 @@
 <h4 id="getSensorList">getSensorList(sensor_type)</h4>
 <p>Provide the list of sensors implemented by the HAL for the given sensor type. </p>
 <p>Developers may then make multiple calls to get sensors of different types or use 
-  Sensor.TYPE_ALL to get all the sensors. See getSensorList() defined on 
+  <code>Sensor.TYPE_ALL</code> to get all the sensors. See getSensorList() defined on
   developer.android.com for more details.</p>
 <h4 id="activate">activate(sensor, true/false)</h4>
 <pre>
             int (*activate)(struct sensors_poll_device_t *dev,
                     int handle, int enabled);</pre>
 <p>Activates or deactivates the sensor with the specified handle. Handles must be 
-  higher than SENSORS_HANDLE_BASE and must be unique. A handle identifies a given 
+  higher than <code>SENSORS_HANDLE_BASE</code> and must be unique. A handle identifies a given
   sensor. The handle is used to activate and/or deactivate sensors. In this 
   version of the API, there can only be 256 handles.</p>
 <p>The handle is the handle of the sensor to change. The enabled argument is set to 
@@ -210,16 +212,17 @@
             int (*setDelay)(struct sensors_poll_device_t *dev,
                     int handle, int64_t period_ns);
 </pre>
-<p>Sets the event's period in nanoseconds for a given sensor. What the period_ns 
-  parameter means depends on the specified sensor's trigger mode:</p>
+<p>Sets the event's period in nanoseconds for a given sensor. What the
+<code>period_ns</code> parameter means depends on the specified sensor's trigger mode:</p>
 <ul>
   <li>Continuous: setDelay() sets the sampling rate.</li>
   <li>On-change: setDelay() limits the delivery rate of events.</li>
   <li>One-shot: setDelay() is ignored. It has no effect.</li>
   <li>Special: See specific sensor type descriptions.</li>
 </ul>
-<p>For continuous and on-change sensors, if the requested value is less than sensor_t::minDelay,
-then it's silently clamped to sensor_t::minDelay unless sensor_t::minDelay is 0,
+<p>For continuous and on-change sensors, if the requested value is less than
+<code>sensor_t::minDelay</code>, then it's silently clamped to
+<code>sensor_t::minDelay</code> unless <code>sensor_t::minDelay</code> is 0,
 in which case it is clamped to &gt;= 1ms. setDelay will not be called when the sensor is
 in batching mode. In this case, batch() will be called with the new period. Return 0 if successful, 
 &lt; 0 on error.</p>
@@ -230,20 +233,21 @@
 <pre>
             int (*flush)(struct sensors_poll_device_1* dev, int handle);
 </pre>
-<p>Flush adds a META_DATA_FLUSH_COMPLETE event (sensors_event_meta_data_t) to the 
+<p>Flush adds a <code>META_DATA_FLUSH_COMPLETE</code> event
+(<code>sensors_event_meta_data_t</code>) to the
   end of the &quot;batch mode&quot; FIFO for the specified sensor and flushes the FIFO; 
   those events are delivered as usual (i.e.: as if the batch timeout had expired) 
   and removed from the FIFO.<br/>
   <br/>
   The flush happens asynchronously (i.e.: this function must return immediately). 
   If the implementation uses a single FIFO for several sensors, that FIFO is 
-  flushed and the META_DATA_FLUSH_COMPLETE event is added only for the specified 
+  flushed and the <code>META_DATA_FLUSH_COMPLETE</code> event is added only for the specified
   sensor.<br/>
   <br/>
   If the specified sensor wasn't in batch mode, flush succeeds and promptly sends 
-  a META_DATA_FLUSH_COMPLETE event for that sensor.</p>
+  a <code>META_DATA_FLUSH_COMPLETE</code> event for that sensor.</p>
 <p>If the FIFO was empty at the time of the call, flush returns 0 (success) and 
-  promptly sends a META_DATA_FLUSH_COMPLETE event for that sensor.<br/>
+  promptly sends a <code>META_DATA_FLUSH_COMPLETE</code> event for that sensor.<br/>
   <br/>
   If the specified sensor wasn't enabled, flush returns -EINVAL. return 0 on 
   success, negative errno code otherwise.</p>