diff --git a/src/compatibility/android-cts-manual.pdf b/src/compatibility/android-cts-manual.pdf
index bf8b5ed..2c77b5c 100644
--- a/src/compatibility/android-cts-manual.pdf
+++ b/src/compatibility/android-cts-manual.pdf
Binary files differ
diff --git a/src/compatibility/contact-us.jd b/src/compatibility/contact-us.jd
index 1718956..585c2a8 100644
--- a/src/compatibility/contact-us.jd
+++ b/src/compatibility/contact-us.jd
@@ -16,25 +16,35 @@
     See the License for the specific language governing permissions and    
     limitations under the License.   
 -->
+<p>Thanks for your interest in Android compatibility! This page describes the
+contact methods for inquiries regarding the Android compatibility program,
+including the Compatibility Definition Document (CDD) and Compatibility Test
+Suite (CTS). See the <a href="{@docRoot}community/index.html">Community</a>
+page for communication channels regarding other topics.</p>
 
-<p>Thanks for your interest in Android compatibility!</p>
-<p>If you have questions about Android compatibility that aren't covered in
-this site, you can reach us in one of a few different ways. To get the most
-out of any of these options, please first read "Getting the Most from Our
-Lists" on the <a href="{@docRoot}community/index.html">Community page</a></p>
-<h2 id="for-android-compatibility-definition-and-compatibility-test-suite-technical-questions">For Android Compatibility Definition and Compatibility Test Suite Technical Questions</h2>
-<p>If you have questions about Android compatibility that aren't covered in this site, you can reach
-us in one of a few different ways. To get the most out of any of these options, please first read "Getting the Most from Our
-Lists" on the <a href="{@docRoot}community/index.html">Community page</a>. If you have specific issues with the Compatibility Test Suite or the Compatibility Definition
-<a href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility list.</a> is the discussion forum for you.</p>
+<h2
+id="for-android-compatibility-definition-and-compatibility-test-suite-technical-questions">For
+CDD and CTS technical questions</h2>
+<p>If you have technical questions about Android compatibility that aren't covered in
+this site, you can seek help from your peers on the <a
+href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility</a>
+list.</p>
+
 <ul>
-<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility</a></li>
-<li>Subscribe via email: <a href="mailto:android-compatibility+subscribe@googlegroups.com">android-compatibility</a></li>
+<li>Subscribe using Google Groups: <a
+href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility</a></li>
+<li>Subscribe via email: <a
+href="mailto:android-compatibility+subscribe@googlegroups.com">android-compatibility</a></li>
 </ul>
-<p>Note that if you're a user looking for help with your Android device, this page probably isn't for you;
-you should contact your carrier or manufacturer for help with your Android device.</p>
-<h2 id="for-business-inquiries">For Business Inquiries</h2>
+
+<p>To make best use of this list, please first read <em>Getting the Most from
+Our Lists</em> on the <a href="{@docRoot}community/index.html">Community</a>
+page. Users looking for help with Android devices should contact their carrier
+or manufacturer for help.</p>
+
+<h2 id="for-business-inquiries">For business inquiries</h2>
 <p>Finally, business inquiries about the compatibility program, including
-requests to use branding elements and so on, can be sent to the address <a href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>. Like
-the CTS address, this address is for specific, private inquiries; general
-questions will be directed back to the android-compatibility list.</p>
+requests to use branding elements and similar, can be sent to the address <a
+href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>.
+This address is for specific, private inquiries; general questions will be
+directed back to the android-compatibility list.</p>
diff --git a/src/compatibility/cts-intro.jd b/src/compatibility/cts-intro.jd
index f78e115..2813aef 100644
--- a/src/compatibility/cts-intro.jd
+++ b/src/compatibility/cts-intro.jd
@@ -34,6 +34,8 @@
 </li>
 </ul>
 <h2 id="workflow">Workflow</h2>
+<p>This section summarizes CTS setup. Please refer to the <a href="android-cts-manual.pdf">
+CTS User Manual</a> for detailed instructions.</p>
 <ol>
 <li>
 <p><a href="downloads.html">Download</a> the CTS and CTS media files.</p>
@@ -45,7 +47,7 @@
 <p>For CTS versions 2.1 R2 through 4.2 R4, set up your device (or emulator) to run the accessibility tests:</p>
 <ol>
 <li>
-<p>adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk</p>
+<code>adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk</code>
 </li>
 <li>
 <p>On the device, enable Settings &gt; Accessibility &gt; Accessibility &gt; Delegating Accessibility Service</p>
@@ -56,10 +58,13 @@
 <p>For CTS 2.3 R4 and beyond, set up your device to run the device administration tests:</p>
 <ol>
 <li>
-<p>adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk</p>
+<code>adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk</code>
 </li>
 <li>
-<p>On the device, enable the two android.deviceadmin.cts.CtsDeviceAdminReceiver* device administrators under Settings &gt; Location &amp; security &gt; Select device administrators</p>
+<p>On the device, enable the two <code>android.deviceadmin.cts.CtsDeviceAdminReceiver*</code> device
+administrators under Settings &gt; Location &amp; security &gt; Select device administrators</p>
+<p><strong>Note</strong>: Make sure the <code>android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver</code>
+stays disabled in the same menu.</p>
 </li>
 </ol>
 </li>
@@ -70,7 +75,9 @@
 <p>Unzip the CTS Media zip file.</p>
 </li>
 <li>
-<p>Run copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]. If no resolution is specified, the default maximum resolution of 480x360 is assumed.</p>
+<p>Run the following command. If no resolution is specified, the default maximum resolution of
+480x360 is assumed:</p>
+<code>copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]</code>
 </li>
 </ol>
 </li>
@@ -78,7 +85,7 @@
 <p>Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:</p>
 <ul>
 <li>
-<p>The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.</p>
+<p>The test harness pushes an .apk file to each device, executes the test through instrumentation, and records test results.</p>
 </li>
 <li>
 <p>The test harness removes the .apk file from each device.</p>
@@ -86,7 +93,8 @@
 </ul>
 </li>
 <li>
-<p>Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.</p>
+<p>Once all the tests are executed, view the test results in your browser and
+use them to adjust your design. You can continue to run the CTS throughout your development process.</p>
 </li>
 </ol>
 <h2 id="types-of-test-cases">Types of test cases</h2>
@@ -99,7 +107,8 @@
 <p><em>Functional tests</em> test a combination of APIs together in a higher-level use-case.</p>
 </li>
 <li>
-<p><em>Reference application tests</em> instrument a complete sample application to exercise a full set of APIs and Android runtime services</p>
+<p><em>Reference application tests</em> instrument a complete sample application
+to exercise a full set of APIs and Android runtime services.</p>
 </li>
 </ul>
 <p>Future versions of the CTS will include the following types of test cases:</p>
@@ -131,7 +140,7 @@
 </tr>
 <tr>
 <td>Dalvik VM Tests</td>
-<td>The tests focus on testing the Dalvik VM</td>
+<td>The tests focus on testing the Dalvik VM.</td>
 </tr>
 <tr>
 <td>Platform Data Model</td>
diff --git a/src/compatibility/index.jd b/src/compatibility/index.jd
index cd679c6..60c2951 100644
--- a/src/compatibility/index.jd
+++ b/src/compatibility/index.jd
@@ -18,7 +18,7 @@
 -->
 
 <p>Android's purpose is to establish an open platform for developers to build innovative apps.
-The Android Compatibility program defines the technical details of Android platform and provides
+The Android Compatibility program defines the technical details of the Android platform and provides
 tools used by OEMs to ensure that developers' apps run on a variety of devices. The Android SDK
 provides built-in tools that developers use to clearly state the device features their apps
 require. And Google Play shows apps only to those devices that can properly run them.
@@ -29,10 +29,10 @@
 <p>A mobile phone is a highly personal, always-on, always-present gateway to
 the Internet. We haven't met a user yet who didn't want to customize it by
 extending its functionality. That's why Android was designed as a robust
-platform for running after-market applications.</p>
+platform for running aftermarket applications.</p>
 <h3 id="developers-outnumber-us-all">Developers outnumber us all.</h3>
 <p>No device manufacturer can hope to write all the software that a person could
-conceivably need. We need third-party developers to write the apps users want,
+conceivably need. We need third-party developers to write the apps users want;
 so the Android Open Source Project aims to make it as easy and open as
 possible for developers to build apps.</p>
 <h3 id="everyone-needs-a-common-ecosystem">Everyone needs a common ecosystem.</h3>
@@ -48,22 +48,25 @@
 <p>Building a compatible device is a three-step process:</p>
 <ol>
 <li>
-<p><em>Obtain the Android software source code</em>.
-    This is <a href="{@docRoot}source/index.html">the source code for the Android platform</a>, that you port to your hardware.</p>
+<p><em>Obtain the <a href="{@docRoot}source/index.html">Android software source
+code</a></em>.
+    This is the source code for the Android platform that you port to your hardware.</p>
 </li>
 <li>
-<p><em>Comply with Android Compatibility Definition Document (CDD)</em>.
+<p><em>Comply with the <a href="{@docRoot}compatibility/android-cdd.pdf">Android
+Compatibility Definition Document (CDD)</a></em>.
     The CDD enumerates the software and hardware requirements of a compatible Android device.</p>
 </li>
 <li>
-<p><em>Pass the Compatibility Test Suite (CTS)</em>.
-    You can use the CTS (included in the Android source code) as an ongoing aid to compatibility during the development process.</p>
+<p><em>Pass the <a href="{@docRoot}compatibility/cts-intro.html">Compatibility
+Test Suite (CTS)</a></em>.
+    Use the CTS as an ongoing aid to compatibility during the development process.</p>
 </li>
 </ol>
 
-<h2 id="joining-the-ecosystem">Joining the Ecosystem</h2>
+<h2 id="joining-the-ecosystem">Joining the ecosystem</h2>
 <p>Once you've built a compatible device, you may wish to include Google
 Play to provide your users access to the third-party app ecosystem.
 Unfortunately, for a variety of legal and business reasons, we aren't able to
 automatically license Google Play to all compatible devices. To inquire
-about access about Google Play, you can <a href="contact-us.html">contact us</a>.</p>
+about access to Google Play, you can <a href="contact-us.html">contact us</a>.</p>
diff --git a/src/compatibility/overview.jd b/src/compatibility/overview.jd
index 62c2083..ac0fb9f 100644
--- a/src/compatibility/overview.jd
+++ b/src/compatibility/overview.jd
@@ -46,8 +46,8 @@
 any other device that is compatible with the same Android platform version.
 Android devices will differ in hardware and software capabilities, so the
 compatibility program also provides the tools needed for distribution systems
-such as Google Play to implement appropriate filtering. This means that
-users can only see applications which they can actually run.</p>
+such as Google Play to implement appropriate filtering. This means
+users see only the applications they can actually run.</p>
 </li>
 <li>
 <p><em>Enable device manufacturers to differentiate while being
@@ -60,9 +60,9 @@
 <li>
 <p><em>Minimize costs and overhead associated with compatibility.</em>
     Ensuring compatibility should be easy and inexpensive to
-device manufacturers. The testing tool (CTS) is free, open source, and
+device manufacturers. The testing tool is free, open source, and
 available for <a href="downloads.html">download</a>. 
-CTS is designed to be used for continuous self-testing
+It is designed to be used for continuous self-testing
 during the device development process to eliminate the cost of changing your
 workflow or sending your device to a third party for testing. Meanwhile, there
 are no required certifications, and thus no corresponding costs and
@@ -72,35 +72,34 @@
 <p>The Android compatibility program consists of three key components:</p>
 <ul>
 <li>The source code to the Android software stack</li>
-<li>The Compatilbility Definition Document, representing the "policy" aspect of compatibility</li>
-<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li>
+<li>The Compatilbility Definition Document (CDD), representing the "policy" aspect of compatibility</li>
+<li>The Compatilbility Test Suite (CTS), representing the "mechanism" of compatibility</li>
 </ul>
 <p>Just as each version of the Android platform exists in a separate branch in
 the source code tree, there is a separate CTS and CDD for each version as
 well. The CDD, CTS, and source code are -- along with your hardware and your
 software customizations -- everything you need to create a compatible device.</p>
-<h1 id="compatibility-definition-document-cdd">Compatibility Definition Document (CDD)</h1>
-<p>For each release of the Android platform, a detailed Compatibility
-Definition Document (CDD) will be provided. The CDD represents the "policy"
+<h1 id="compatibility-definition-document-cdd">Compatibility Definition Document</h1>
+<p>For each release of the Android platform, a detailed CDD will be provided. The CDD represents the "policy"
 aspect of Android compatibility.</p>
 <p>No test suite, including CTS, can truly be comprehensive. For instance, the
 CTS includes a test that checks for the presence and correct behavior of
 OpenGL graphics APIs, but no software test can verify that the graphics
 actually appear correctly on the screen. More generally, it's impossible to
 test the presence of hardware features such as keyboards, display density,
-WiFi, and Bluetooth.</p>
+Wi-Fi, and Bluetooth.</p>
 <p>The CDD's role is to codify and clarify specific requirements, and
 eliminate ambiguity.  The CDD does not attempt to be comprehensive. Since
 Android is a single corpus of open-source code, the code itself is the
 comprehensive "specification" of the platform and its APIs. The CDD acts as a
-"hub", referencing other content (such as SDK API documentation) that provides
+"hub" referencing other content (such as SDK API documentation) that provides
 a framework in which the Android source code may be used so that the end
 result is a compatible system.</p>
 <p>If you want to build a device compatible with a given Android version,
 start by checking out the source code for that version, and then read the
 corresponding CDD and stay within its guidelines. For additional details,
 simply examine <a href="/compatibility/android-cdd.pdf">the latest CDD</a>.</p>
-<h1 id="compatibility-test-suite-cts">Compatibility Test Suite (CTS)</h1>
+<h1 id="compatibility-test-suite-cts">Compatibility Test Suite</h1>
 <p>The CTS is a free, commercial-grade test suite, available for
 <a href="downloads.html">download</a>.
 The CTS represents the "mechanism" of compatibility.</p>
@@ -112,7 +111,7 @@
 development process.</p>
 <h1 id="compatibility-test-suite-verifier-cts-verifier">Compatibility Test Suite Verifier (CTS Verifier)</h1>
 <p>The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
-Compatibility Test Suite (CTS), available for <a href="downloads.html">download</a>.
+CTS available for <a href="downloads.html">download</a>.
 CTS Verifier provides tests for APIs and functions that cannot be tested on a
 stationary device without manual input (e.g. audio quality, accelerometer, etc).</p>
 <p>For details on the CTS, consult the <a href="cts-intro.html">CTS introduction</a>.</p>
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 7ede9ee..d3fbed2 100644
--- a/src/devices/sensors/composite_sensors.jd
+++ b/src/devices/sensors/composite_sensors.jd
@@ -30,6 +30,10 @@
 underlying base sensors, and trigger modes. Certain base sensors are required of 
 each sensor for accuracy. Using other tools to approximate results should be 
 avoided as they will invariably provide a poor user experience.</p>
+
+<p>When there is no gyroscope on the device, and
+only when there is no gyroscope, you may implement the rotation vector and
+other composite sensors without using the gyroscope.</p>
 <table>
   <tr>
 <th>Sensor type</th>
@@ -127,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>
@@ -189,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 
@@ -319,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>
@@ -337,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 
@@ -358,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 
@@ -393,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>
 
@@ -488,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>
 
@@ -521,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 449cdbd..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,35 +212,42 @@
             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, in which case it is clamped to &gt;= 1ms:<br/>
-  @return 0 if successful, &lt; 0 on error</p>
+<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>
+<p>When calculating the sampling period T in setDelay (or batch), the actual period
+should be smaller than T and no smaller than T/2. Finer granularity is not
+necessary.</p>
 <h4 id="flush">flush()</h4>
 <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>
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
index e80fb34..440ef5d 100644
--- a/src/source/build-numbers.jd
+++ b/src/source/build-numbers.jd
@@ -132,7 +132,7 @@
 </tr>
 <tr>
 <td>KitKat</td>
-<td>4.4</td>
+<td>4.4 - 4.4.2</td>
 <td>API level 19</td>
 </tr>
 </tbody>
@@ -551,7 +551,19 @@
 <tr>
 <td>KRT16S</td>
 <td>android-4.4_r1.2</td>
-<td>Latest KitKat version, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10</td>
+<td>KitKat version, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10</td>
+</tr>
+
+<tr>
+<td>KOT49E</td>
+<td>android-4.4.1_r1</td>
+<td>KitKat version, Nexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10</td>
+</tr>
+
+<tr>
+<td>KOT49H</td>
+<td>android-4.4.2_r1</td>
+<td>Latest KitKat version, Nexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10</td>
 </tr>
 
 </tbody>
diff --git a/src/source/faqs.jd b/src/source/faqs.jd
index 52b0a0b..e9b018c 100644
--- a/src/source/faqs.jd
+++ b/src/source/faqs.jd
@@ -25,6 +25,10 @@
 </div>
 
 <a name="top"></a>
+<p>Please see the <a
+href="http://developer.android.com/guide/faq/index.html">Android FAQs</a> on
+developer.android.com for answers to other common questions.
+
 <h2 id="open-source">Open Source</h2>
 <h3 id="what-is-the-android-open-source-project">What is the Android Open Source Project?</h3>
 <p>We use the phrase "Android Open Source Project" or "AOSP" to refer to the
diff --git a/src/source/submit-patches.jd b/src/source/submit-patches.jd
index 5ab7ccd..994087d 100644
--- a/src/source/submit-patches.jd
+++ b/src/source/submit-patches.jd
@@ -191,7 +191,7 @@
 <code>external/llvm</code>) should be made upstream at
 <a href="http://llvm.org/">llvm.org/</a>.</p>
 
-<h2 id="mksh">
+<h2 id="mksh">mksh</h2>
 <p>All changes to the MirBSD Korn Shell project at <code>external/mksh</code> should be made upstream
 either by sending an email to miros-mksh on the mirbsd.o®g domain (no subscription
 required to submit there) or (optionally) at <a href="https://launchpad.net/mksh">Launchpad</a>.