Docs: Fixing many small issues encountered during testing of L release.

Bug: 18192817
Change-Id: I7cfa3e61f1e65a64599e9c6858b6848e8331ccc7
diff --git a/src/devices/sensors/hal-interface.jd b/src/devices/sensors/hal-interface.jd
index 5c232fa..7feadf2 100644
--- a/src/devices/sensors/hal-interface.jd
+++ b/src/devices/sensors/hal-interface.jd
@@ -24,7 +24,7 @@
   </div>
 </div>
 
-<p>The HAL interface, declared in <a href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a>, represents the interface between the Android <a href="sensor-stack.html#framework">framework</a> and the hardware-specific software. A HAL implementation must define each
+<p>The HAL interface, declared in <a href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a>, represents the interface between the Android <a href="sensor-stack.html#framework">framework</a> and the hardware-specific software. A HAL implementation must define each
   function declared in sensors.h. The main functions are:</p>
 <ul>
   <li><code>get_sensors_list</code> - Returns the list of all sensors. </li>
@@ -47,7 +47,7 @@
   <li><code>sensor_t</code></li>
   <li><code>sensors_event_t</code></li>
 </ul>
-<p>In addition to the sections below, see <a href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> for more information on those types.</p>
+<p>In addition to the sections below, see <a href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> for more information on those types.</p>
 <h2 id="get_sensors_list_list">get_sensors_list(list)</h2>
 <pre>int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t
   const** list);</pre>
@@ -240,13 +240,13 @@
   <code>HAL_MODULE_INFO_SYM</code> of this type to expose the <a
   href="#get_sensors_list_list">get_sensors_list</a> function. See the definition
   of <code>sensors_module_t</code> in <a
-  href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> and the
+  href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> and the
   definition of <code>hw_module_t</code> for more information.</p>
 <h2 id="sensors_poll_device_t_sensors_poll_device_1_t">sensors_poll_device_t / sensors_poll_device_1_t</h2>
 <p><code>sensors_poll_device_1_t</code> contains the rest of the methods defined above:
   <code>activate</code>, <code>batch</code>, <code>flush</code> and
   <code>poll</code>. Its <code>common</code> field (of type <a
-  href="{@docRoot}devices/reference/structhw__device__t.html">hw_device_t</a>)
+  href="{@docRoot}devices/halref/structhw__device__t.html">hw_device_t</a>)
   defines the version number of the HAL.</p>
 <h2 id="sensor_t">sensor_t</h2>
 <p><code>sensor_t</code> represents an <a href="index.html">Android sensor</a>. Here are some of its important fields:</p>
@@ -268,7 +268,7 @@
   <em>Cool-product</em> team at Fictional-Company could use
   <code>stringType=”com.fictional_company.cool_product.unicorn_detector”</code>.
   The <code>stringType</code> is used to uniquely identify non-official sensors types. See <a
-  href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> for more
+  href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> for more
   information on types and string types.</p>
 <p><strong>requiredPermission:</strong> A string representing the permission that applications must
   possess to see the sensor, register to it and receive its data. An empty string
@@ -328,7 +328,7 @@
 <p>Sensor events generated by Android sensors and reported through the <a
 href="#poll">poll</a> function are of <code>type sensors_event_t</code>. Here are some
 important fields of <code>sensors_event_t</code>:</p>
-<p>version: must be <code>sizeof(struct sensors_event_t)</code></p>
+<p><strong>version:</strong> Must be <code>sizeof(struct sensors_event_t)</code></p>
 <p><strong>sensor:</strong> The handle of the sensor that generated the event, as defined by
   <code>sensor_t.handle</code>.</p>
 <p><strong>type:</strong> The sensor type of the sensor that generated the event, as defined by
@@ -342,9 +342,9 @@
   causes too high jitter, and using only the sensor chip time to set the
   timestamps can cause de-synchronization from the
   <code>elapsedRealtimeNano</code> clock, as the sensor clock drifts.</p>
-<p>data and overlapping fields: The values measured by the sensor. The meaning and
+<p><strong>data and overlapping fields:</strong> The values measured by the sensor. The meaning and
   units of those fields are specific to each sensor type. See <a
-  href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> and the
+  href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> and the
   definition of the different <a href="sensor-types.html">Sensor types</a> for a
   description of the data fields. For some sensors, the accuracy of the
   readings is also reported as part of the data, through a <code>status</code> field. This
@@ -355,10 +355,10 @@
 <p>Metadata events have the same type as normal sensor events:
   <code>sensors_event_meta_data_t = sensors_event_t</code>. They are returned together with
   other sensor events through poll. They possess the following fields:</p>
-<p>version must be <code>META_DATA_VERSION</code></p>
-<p>type must be <code>SENSOR_TYPE_META_DATA</code></p>
-<p>sensor, reserved, and <strong>timestamp </strong>must be 0</p>
-<p>meta_data.what contains the metadata type for this event. There is currently a
+<p><strong>version:</strong> Must be <code>META_DATA_VERSION</code></p>
+<p><strong>type:</strong> Must be <code>SENSOR_TYPE_META_DATA</code></p>
+<p><strong>sensor, reserved, and timestamp</strong>: Must be 0</p>
+<p><strong>meta_data.what:</strong> Contains the metadata type for this event. There is currently a
   single valid metadata type: <code>META_DATA_FLUSH_COMPLETE</code>.</p>
 <p><code>META_DATA_FLUSH_COMPLETE</code> events represent the completion of the flush of a
   sensor FIFO. When <code>meta_data.what=META_DATA_FLUSH_COMPLETE</code>, <code>meta_data.sensor</code>