Docs: Fixing many small issues encountered during testing of L release.
Bug: 18192817
Change-Id: I7cfa3e61f1e65a64599e9c6858b6848e8331ccc7
diff --git a/src/accessories/headset-spec.jd b/src/accessories/headset-spec.jd
index 6e9bd69..88b6023 100644
--- a/src/accessories/headset-spec.jd
+++ b/src/accessories/headset-spec.jd
@@ -24,6 +24,8 @@
</div>
</div>
+<p><em>Version 1.0</em></p>
+
<p>This document specifies the requirements for headsets and mobile devices to
function uniformly across the Android ecosystem. It is separated into two
sections beginning with the specifications for the headset
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>
diff --git a/src/devices/sensors/index.jd b/src/devices/sensors/index.jd
index 6f21488..dea285b 100644
--- a/src/devices/sensors/index.jd
+++ b/src/devices/sensors/index.jd
@@ -28,19 +28,19 @@
<p>Android sensors give applications access to a mobile device's underlying
physical sensors. They are data-providing virtual devices defined by the
implementation of <a
- href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a>,
+ href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a>,
the sensor Hardware Abstraction Layer (HAL).</p>
<ul>
<li> Those virtual devices provide data coming from a set of physical sensors:
accelerometers, gyroscopes, magnetometers, barometer, humidity, pressure,
- light, proximity and heart rate sensors… </li>
+ light, proximity and heart rate sensors.</li>
<li> Notably, camera, fingerprint sensor, microphone and touch screen are currently
not in the list of physical devices providing data through “Android sensors.”
- They have their own reporting mechanism. </li>
+ They have their own reporting mechanism.</li>
<li> The separation is arbitrary, but in general, Android sensors provide lower
bandwidth data. For example, “100hz x 3 channels” for an accelerometer versus
“25hz x 8 MP x 3 channels” for a camera or “44kHz x 1 channel” for a
- microphone. </li>
+ microphone.</li>
</ul>
<p>How the different physical sensors are connected to the system on chip
(SoC) is not defined by Android.</p>
@@ -62,7 +62,7 @@
<p>Each Android sensor has a “type” representing how the sensor behaves and what
data it provides.</p>
<ul>
- <li> The official Android <a href="sensor-types.html">Sensor types</a> are defined in <a href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> under the names SENSOR_TYPE_…
+ <li> The official Android <a href="sensor-types.html">Sensor types</a> are defined in <a href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> under the names SENSOR_TYPE_…
<ul>
<li> The vast majority of sensors have an official sensor type. </li>
<li> Those types are documented in the Android SDK. </li>
@@ -144,7 +144,7 @@
</li>
<li> Hardware abstraction layer (HAL)
<ul>
- <li> <a href="{@docRoot}devices/reference/sensors_8h_source.html">https://source.android.com/devices/reference/sensors_8h_source.html</a></li>
+ <li> <a href="{@docRoot}devices/halref/sensors_8h_source.html">https://source.android.com/devices/halref/sensors_8h_source.html</a></li>
<li> Also known as “sensors.h” </li>
<li> The source of truth. First document to be updated when new features are
developed. </li>
diff --git a/src/devices/sensors/sensor-stack.jd b/src/devices/sensors/sensor-stack.jd
index 9776c44..5ffcce8 100644
--- a/src/devices/sensors/sensor-stack.jd
+++ b/src/devices/sensors/sensor-stack.jd
@@ -128,7 +128,7 @@
<p>The interface is defined by Android and AOSP contributors, and the
implementation is provided by the manufacturer of the device.</p>
<p>The sensor HAL interface is located in <code>hardware/libhardware/include/hardware</code>.
- See <a href="{@docRoot}devices/reference/sensors_8h.html">sensors.h</a> for additional details.</p>
+ See <a href="{@docRoot}devices/halref/sensors_8h.html">sensors.h</a> for additional details.</p>
<h3 id="release_cycle">Release cycle</h3>
<p>The HAL implementation specifies what version of the HAL interface it
implements by setting <code>your_poll_device.common.version</code>. The existing HAL
diff --git a/src/devices/sensors/sensor-types.jd b/src/devices/sensors/sensor-types.jd
index 824680f..7ebac25 100644
--- a/src/devices/sensors/sensor-types.jd
+++ b/src/devices/sensors/sensor-types.jd
@@ -274,15 +274,17 @@
<td><p>Continuous</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p>i<a href="#geomagnetic_rotation_vector"Geomagnetic rotation vector</a></p></td>
+ <td><p><a href="#geomagnetic_rotation_vector">Geomagnetic rotation
+ vector</a> <img src="images/battery_icon.png" width="20" height="20" alt="Low
+ power sensor" /></p></td>
<td><p>Attitude</p></td>
<td><p>Accelerometer, Magnetometer, MUST NOT USE Gyroscope</p></td>
<td><p>Continuous</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#glance_gesture">Glance gesture</a></p></td>
+ <td><a href="#glance_gesture">Glance gesture</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Interaction</p></td>
<td><p>Undefined</p></td>
<td><p>One-shot</p></td>
@@ -318,8 +320,9 @@
<td><p>Continuous</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#pick_up_gesture">Pick up gesture</a></p></td>
+ <td><p><a href="#pick_up_gesture">Pick up gesture</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Interaction</p></td>
<td><p>Undefined</p></td>
<td><p>One-shot</p></td>
@@ -331,43 +334,46 @@
<td><p>Continuous</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#significant_motion">Significant motion</a></p></td>
+ <td><p><a href="#significant_motion">Significant motion</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Activity</p></td>
<td><p>Accelerometer (or another as long as very low power)</p></td>
<td><p>One-shot</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#step_counter">Step counter</a></p></td>
+ <td><p><a href="#step_counter">Step counter</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Activity</p></td>
<td><p>Accelerometer</p></td>
<td><p>On-change</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#step_detector">Step detector</a></p></td>
+ <td><p><a href="#step_detector">Step detector</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td> <td><p>Activity</p></td>
+ <td><p>Accelerometer</p></td>
+ <td><p>Special</p></td>
+ </tr>
+ <tr>
+ <td><p><a href="#tilt_detector">Tilt detector</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Activity</p></td>
<td><p>Accelerometer</p></td>
<td><p>Special</p></td>
</tr>
<tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#tilt_detector">Tilt detector</a></p></td>
- <td><p>Activity</p></td>
- <td><p>Accelerometer</p></td>
- <td><p>Special</p></td>
- </tr>
- <tr>
- <td><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
- <p><a href="#wake_up_gesture">Wake up gesture</a></p></td>
+ <td><p><a href="#wake_up_gesture">Wake up gesture</a> <img
+ src="images/battery_icon.png" width="20" height="20" alt="Low power sensor"
+ /></p></td>
<td><p>Interaction</p></td>
<td><p>Undefined</p></td>
<td><p>One-shot</p></td>
</tr>
</table>
-<img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" />
-<p> = Low power sensor</p>
+<p><img src="images/battery_icon.png" width="20" height="20" alt="Low power sensor" /> = Low power sensor</p>
<h2 id="activity_composite_sensors">Activity composite sensors</h2>
<h3 id="linear_acceleration">Linear acceleration</h3>
<p>Underlying physical sensors: Accelerometer and (if present) Gyroscope (or
@@ -622,7 +628,7 @@
direction. (Mathematically speaking, it should be positive in the
counter-clockwise direction):</p>
<div class="figure" style="width:264px">
- <imgsrc="images/axis_positive_roll.png" alt="Depiction of orientation
+ <img src="images/axis_positive_roll.png" alt="Depiction of orientation
relative to a device" height="253" />
<p class="img-caption">
<strong>Figure 2.</strong> Orientation relative to a device.
diff --git a/src/devices/tech/encryption/index.jd b/src/devices/tech/encryption/index.jd
index 1a88d77..9d63354 100644
--- a/src/devices/tech/encryption/index.jd
+++ b/src/devices/tech/encryption/index.jd
@@ -127,7 +127,7 @@
<p>In addition to these flows, the device can also fail to encrypt <code>/data</code>. Each of the flows are explained in detail below.</p>
-<h3 id=encrypt_a_new_device_with_forceencrypt>Encrypt a new device with <code>/forceencrypt</code></h3>
+<h3 id=encrypt_a_new_device_with_forceencrypt>Encrypt a new device with /forceencrypt</h3>
<p>This is the normal first boot for an Android 5.0 device. </p>
diff --git a/src/devices/tech/security/se-linux.jd b/src/devices/tech/security/se-linux.jd
index 6c34a02..bbc6ed8 100644
--- a/src/devices/tech/security/se-linux.jd
+++ b/src/devices/tech/security/se-linux.jd
@@ -63,7 +63,7 @@
Per-domain permissive mode also enables policy development for new services
while keeping the rest of the system enforcing.</p>
-<p>In the L release, Android moves to full enforcement of SELinux. This builds
+<p>In the Android 5.0 (L) release, Android moves to full enforcement of SELinux. This builds
upon the permissive release of 4.3 and the partial enforcement of 4.4. In
short, Android is shifting from enforcement on a limited set of crucial domains
(<code>installd</code>, <code>netd</code>, <code>vold</code> and <code>zygote</code>) to everything (more than 60 domains). This means manufacturers will have to
@@ -71,7 +71,7 @@
devices. Understand that:</p>
<ul>
- <li> Everything is in enforcing mode in the L release
+ <li> Everything is in enforcing mode in the 5.0 release
<li> No processes other than <code>init</code> should run in the <code>init</code> domain
<li> Any generic denial (for a block_device, socket_device, default_service, etc.)
indicates that device needs a special domain
@@ -81,7 +81,7 @@
<p>See the documentation below for details on constructing useful policies:</p>
-<p><a href="https://seandroid.bitbucket.org/PapersandPresentations.html">https://seandroid.bitbucket.org/PapersandPresentations.html</a></p>
+<p><a href="http://seandroid.bitbucket.org/PapersandPresentations.html">http://seandroid.bitbucket.org/PapersandPresentations.html</a></p>
<p><a href="https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid">https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid</a></p>
@@ -93,7 +93,7 @@
<p><a href="https://www.gnu.org/software/m4/manual/index.html">https://www.gnu.org/software/m4/manual/index.html</a></p>
-<p><a href="https://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf">https://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf</a></p>
+<p><a href="http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf">http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf</a></p>
<h2 id=help>Help</h2>
diff --git a/src/devices/tv/HDMI-CEC.jd b/src/devices/tv/HDMI-CEC.jd
index 9c23ba5..bbf6547 100644
--- a/src/devices/tv/HDMI-CEC.jd
+++ b/src/devices/tv/HDMI-CEC.jd
@@ -95,8 +95,7 @@
to use to implement the HAL layer.</li>
</ul>
-<p class="note">
-<p><strong>Note</strong>: Device manufacturers should add the following line into <code>PRODUCT_COPY_FILES</code> in <code>device.mk</code></p>
+<p class="note"><strong>Note</strong>: Device manufacturers should add the following line into <code>PRODUCT_COPY_FILES</code> in <code>device.mk</code>.</p>
<pre>
PRODUCT_COPY_FILES += \
diff --git a/src/devices/tv/images/TV_App_CEC_integration.png b/src/devices/tv/images/TV_App_CEC_integration.png
index da2908c..bf36fac 100644
--- a/src/devices/tv/images/TV_App_CEC_integration.png
+++ b/src/devices/tv/images/TV_App_CEC_integration.png
Binary files differ
diff --git a/src/devices/tv/index.jd b/src/devices/tv/index.jd
index 72e03fa..cf24aa4 100644
--- a/src/devices/tv/index.jd
+++ b/src/devices/tv/index.jd
@@ -78,7 +78,9 @@
<h2 id=permissions>Permissions</h2>
<ul>
- <li>Only <code><a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">signatureOrSystem</a> T</code>V Inputs and TV App have full access to the TV Provider database and are able
+ <li>Only <code><a
+href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">signatureOrSystem</a></code>
+TV Inputs and TV App have full access to the TV Provider database and are able
to receive KeyEvents.
<li>Only system TV Inputs can access the TV Input HAL through the TV Input Manager
service. TV Inputs are accessed one-to-one via TV Input Manager sessions.
