diff --git a/src/app.yaml b/src/app.yaml
index c21e1ed..1fdcdda 100644
--- a/src/app.yaml
+++ b/src/app.yaml
@@ -1,7 +1,8 @@
 application: google.com:sourceandroid-staging
 version: 1
-runtime: python
+runtime: python27
 api_version: 1
+threadsafe: true
 
 handlers:
 # re-direct to index.html if no path is given
diff --git a/src/devices/audio/latency.jd b/src/devices/audio/latency.jd
index 9d381e5..d4b46a6 100644
--- a/src/devices/audio/latency.jd
+++ b/src/devices/audio/latency.jd
@@ -16,198 +16,34 @@
     See the License for the specific language governing permissions and
     limitations under the License.
 -->
-<div id="qv-wrapper">
-  <div id="qv">
-    <h2>In this document</h2>
-    <ol id="auto-toc">
-    </ol>
-  </div>
-</div>
-
 <p>Audio latency is the time delay as an audio signal passes through a system.
-  For a complete description of audio latency for the purposes of Android
-  compatibility, see <em>Section 5.5 Audio Latency</em>
-  in the <a href="{@docRoot}compatibility/index.html">Android CDD</a>.
-  See <a href="latency_design.html">Design For Reduced Latency</a> for an 
-  understanding of Android's audio latency-reduction efforts.
 </p>
 
-<p>
-  This page focuses on the contributors to output latency,
-  but a similar discussion applies to input latency.
-</p>
-<p>
-  Assuming the analog circuitry does not contribute significantly, then the major 
-  surface-level contributors to audio latency are the following:
-</p>
+<h3 id="resources">Resources</h3>
 
-<ul>
-  <li>Application</li>
-  <li>Total number of buffers in pipeline</li>
-  <li>Size of each buffer, in frames</li>
-  <li>Additional latency after the app processor, such as from a DSP</li>
-</ul>
-
-<p>
-  As accurate as the above list of contributors may be, it is also misleading.
-  The reason is that buffer count and buffer size are more of an
-  <em>effect</em> than a <em>cause</em>.  What usually happens is that
-  a given buffer scheme is implemented and tested, but during testing, an audio
-  underrun or overrun is heard as a "click" or "pop."  To compensate, the
-  system designer then increases buffer sizes or buffer counts.
-  This has the desired result of eliminating the underruns or overruns, but it also
-  has the undesired side effect of increasing latency.
-</p>
-
-<p>
-  A better approach is to understand the causes of the
-  underruns and overruns, and then correct those.  This eliminates the
-  audible artifacts and may permit even smaller or fewer buffers
-  and thus reduce latency.
-</p>
-
-<p>
-  In our experience, the most common causes of underruns and overruns include:
-</p>
-<ul>
-  <li>Linux CFS (Completely Fair Scheduler)</li>
-  <li>high-priority threads with SCHED_FIFO scheduling</li>
-  <li>long scheduling latency</li>
-  <li>long-running interrupt handlers</li>
-  <li>long interrupt disable time</li>
-  <li>power management</li>
-  <li>security kernels</li>
-</ul>
-
-<h3 id="linuxCfs">Linux CFS and SCHED_FIFO scheduling</h3>
-<p>
-  The Linux CFS is designed to be fair to competing workloads sharing a common CPU
-  resource. This fairness is represented by a per-thread <em>nice</em> parameter.
-  The nice value ranges from -19 (least nice, or most CPU time allocated)
-  to 20 (nicest, or least CPU time allocated). In general, all threads with a given
-  nice value receive approximately equal CPU time and threads with a
-  numerically lower nice value should expect to
-  receive more CPU time. However, CFS is "fair" only over relatively long
-  periods of observation. Over short-term observation windows,
-  CFS may allocate the CPU resource in unexpected ways. For example, it
-  may take the CPU away from a thread with numerically low niceness
-  onto a thread with a numerically high niceness.  In the case of audio,
-  this can result in an underrun or overrun.
-</p>
-
-<p>
-  The obvious solution is to avoid CFS for high-performance audio
-  threads. Beginning with Android 4.1, such threads now use the
-  <code>SCHED_FIFO</code> scheduling policy rather than the <code>SCHED_NORMAL</code> (also called
-  <code>SCHED_OTHER</code>) scheduling policy implemented by CFS.
-</p>
-
-<h3 id="schedFifo">SCHED_FIFO priorities</h3>
-<p>
-  Though the high-performance audio threads now use <code>SCHED_FIFO</code>, they
-  are still susceptible to other higher priority <code>SCHED_FIFO</code> threads.
-  These are typically kernel worker threads, but there may also be a few
-  non-audio user threads with policy <code>SCHED_FIFO</code>. The available <code>SCHED_FIFO</code>
-  priorities range from 1 to 99.  The audio threads run at priority
-  2 or 3.  This leaves priority 1 available for lower priority threads,
-  and priorities 4 to 99 for higher priority threads.  We recommend 
-  you use priority 1 whenever possible, and reserve priorities 4 to 99 for
-  those threads that are guaranteed to complete within a bounded amount
-  of time, execute with a period shorter than the period of audio threads,
-  and are known to not interfere with scheduling of audio threads.
-</p>
-
-<h3 id="rms">Rate-monotonic scheduling</h3>
-<p>
-  For more information on the theory of assignment of fixed priorities,
-  see the Wikipedia article
-  <a href="http://en.wikipedia.org/wiki/Rate-monotonic_scheduling">Rate-monotonic scheduling</a> (RMS).
-  A key point is that fixed priorities should be allocated strictly based on period,
-  with higher priorities assigned to threads of shorter periods, not based on perceived "importance."
-  Non-periodic threads may be modeled as periodic threads, using the maximum frequency of execution
-  and maximum computation per execution.  If a non-periodic thread cannot be modeled as
-  a periodic thread (for example it could execute with unbounded frequency or unbounded computation
-  per execution), then it should not be assigned a fixed priority as that would be incompatible
-  with the scheduling of true periodic threads.
-</p>
-
-<h3 id="schedLatency">Scheduling latency</h3>
-<p>
-  Scheduling latency is the time between when a thread becomes
-  ready to run, and when the resulting context switch completes so that the
-  thread actually runs on a CPU. The shorter the latency the better, and 
-  anything over two milliseconds causes problems for audio. Long scheduling
-  latency is most likely to occur during mode transitions, such as
-  bringing up or shutting down a CPU, switching between a security kernel
-  and the normal kernel, switching from full power to low-power mode,
-  or adjusting the CPU clock frequency and voltage.
-</p>
-
-<h3 id="interrupts">Interrupts</h3>
-<p>
-  In many designs, CPU 0 services all external interrupts.  So a
-  long-running interrupt handler may delay other interrupts, in particular
-  audio direct memory access (DMA) completion interrupts. Design interrupt handlers
-  to finish quickly and defer lengthy work to a thread (preferably
-  a CFS thread or <code>SCHED_FIFO</code> thread of priority 1).
-</p>
-
-<p>
-  Equivalently, disabling interrupts on CPU 0 for a long period
-  has the same result of delaying the servicing of audio interrupts.
-  Long interrupt disable times typically happen while waiting for a kernel
-  <i>spin lock</i>.  Review these spin locks to ensure that
-  they are bounded.
-</p>
-
-<h3 id="power">Power, performance, and thermal management</h3>
-<p>
-  <a href="http://en.wikipedia.org/wiki/Power_management">Power management</a>
-  is a broad term that encompasses efforts to monitor
-  and reduce power consumption while optimizing performance.
-  <a href="http://en.wikipedia.org/wiki/Thermal_management_of_electronic_devices_and_systems">Thermal management</a>
-  and <a href="http://en.wikipedia.org/wiki/Computer_cooling">computer cooling</a>
-  are similar but seek to measure and control heat to avoid damage due to excess heat.
-  In the Linux kernel, the CPU
-  <a href="http://en.wikipedia.org/wiki/Governor_%28device%29">governor</a>
-  is responsible for low-level policy, while user mode configures high-level policy.
-  Techniques used include:
-</p>
-
-<ul>
-  <li>dynamic voltage scaling</li>
-  <li>dynamic frequency scaling</li>
-  <li>dynamic core enabling</li>
-  <li>cluster switching</li>
-  <li>power gating</li>
-  <li>hotplug (hotswap)</li>
-  <li>various sleep modes (halt, stop, idle, suspend, etc.)</li>
-  <li>process migration</li>
-  <li><a href="http://en.wikipedia.org/wiki/Processor_affinity">processor affinity</a></li>
-</ul>
-
-<p>
-  Some management operations can result in "work stoppages" or
-  times during which there is no useful work performed by the application processor.
-  These work stoppages can interfere with audio, so such management should be designed
-  for an acceptable worst-case work stoppage while audio is active.
-  Of course, when thermal runaway is imminent, avoiding permanent damage
-  is more important than audio!
-</p>
-
-<h3 id="security">Security kernels</h3>
-<p>
-  A <a href="http://en.wikipedia.org/wiki/Security_kernel">security kernel</a> for
-  <a href="http://en.wikipedia.org/wiki/Digital_rights_management">Digital rights management</a>
-  (DRM) may run on the same application processor core(s) as those used
-  for the main operating system kernel and application code.  Any time
-  during which a security kernel operation is active on a core is effectively a
-  stoppage of ordinary work that would normally run on that core.
-  In particular, this may include audio work.  By its nature, the internal
-  behavior of a security kernel is inscrutable from higher-level layers, and thus
-  any performance anomalies caused by a security kernel are especially
-  pernicious.  For example, security kernel operations do not typically appear in
-  context switch traces.  We call this "dark time" &mdash; time that elapses
-  yet cannot be observed.  Security kernels should be designed for an
-  acceptable worst-case work stoppage while audio is active.
-</p>
+<table>
+<tr>
+  <th>Topic</th>
+  <th>Links</th>
+</tr>
+<tr>
+  <td>Description of audio latency for purposes of Android compatibility</td>
+  <td><a href="{@docRoot}compatibility/android-cdd.pdf">Android CDD</a><br /><em>section 5.5 Audio Latency</em></td>
+</tr>
+<tr>
+  <td>Common causes of audio latency</td>
+  <td><a href="latency_contrib.html">Contributors to Audio Latency</a></td>
+</tr>
+<tr>
+  <td>Android's audio latency-reduction efforts</td>
+  <td><a href="latency_design.html">Design For Reduced Latency</a></td>
+</tr>
+<tr>
+  <td>Techniques to measure audio latency</td>
+  <td>
+    <a href="latency_measure.html">Measuring Audio Latency</a><br />
+    <a href="testing_circuit.html">Light Testing Circuit</a><br />
+    <a href="loopback.html">Audio Loopback Dongle</a>
+  </td>
+</tr>
+</table>
diff --git a/src/devices/audio/latency_contrib.jd b/src/devices/audio/latency_contrib.jd
new file mode 100644
index 0000000..fb7cd71
--- /dev/null
+++ b/src/devices/audio/latency_contrib.jd
@@ -0,0 +1,204 @@
+page.title=Contributors to Audio Latency
+@jd:body
+
+<!--
+    Copyright 2013 The Android Open Source Project
+
+    Licensed under the Apache License, Version 2.0 (the "License");
+    you may not use this file except in compliance with the License.
+    You may obtain a copy of the License at
+
+        http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
+-->
+<div id="qv-wrapper">
+  <div id="qv">
+    <h2>In this document</h2>
+    <ol id="auto-toc">
+    </ol>
+  </div>
+</div>
+
+<p>
+  This page focuses on the contributors to output latency,
+  but a similar discussion applies to input latency.
+</p>
+<p>
+  Assuming the analog circuitry does not contribute significantly, then the major
+  surface-level contributors to audio latency are the following:
+</p>
+
+<ul>
+  <li>Application</li>
+  <li>Total number of buffers in pipeline</li>
+  <li>Size of each buffer, in frames</li>
+  <li>Additional latency after the app processor, such as from a DSP</li>
+</ul>
+
+<p>
+  As accurate as the above list of contributors may be, it is also misleading.
+  The reason is that buffer count and buffer size are more of an
+  <em>effect</em> than a <em>cause</em>.  What usually happens is that
+  a given buffer scheme is implemented and tested, but during testing, an audio
+  underrun or overrun is heard as a "click" or "pop."  To compensate, the
+  system designer then increases buffer sizes or buffer counts.
+  This has the desired result of eliminating the underruns or overruns, but it also
+  has the undesired side effect of increasing latency.
+</p>
+
+<p>
+  A better approach is to understand the causes of the
+  underruns and overruns, and then correct those.  This eliminates the
+  audible artifacts and may permit even smaller or fewer buffers
+  and thus reduce latency.
+</p>
+
+<p>
+  In our experience, the most common causes of underruns and overruns include:
+</p>
+<ul>
+  <li>Linux CFS (Completely Fair Scheduler)</li>
+  <li>high-priority threads with SCHED_FIFO scheduling</li>
+  <li>long scheduling latency</li>
+  <li>long-running interrupt handlers</li>
+  <li>long interrupt disable time</li>
+  <li>power management</li>
+  <li>security kernels</li>
+</ul>
+
+<h3 id="linuxCfs">Linux CFS and SCHED_FIFO scheduling</h3>
+<p>
+  The Linux CFS is designed to be fair to competing workloads sharing a common CPU
+  resource. This fairness is represented by a per-thread <em>nice</em> parameter.
+  The nice value ranges from -19 (least nice, or most CPU time allocated)
+  to 20 (nicest, or least CPU time allocated). In general, all threads with a given
+  nice value receive approximately equal CPU time and threads with a
+  numerically lower nice value should expect to
+  receive more CPU time. However, CFS is "fair" only over relatively long
+  periods of observation. Over short-term observation windows,
+  CFS may allocate the CPU resource in unexpected ways. For example, it
+  may take the CPU away from a thread with numerically low niceness
+  onto a thread with a numerically high niceness.  In the case of audio,
+  this can result in an underrun or overrun.
+</p>
+
+<p>
+  The obvious solution is to avoid CFS for high-performance audio
+  threads. Beginning with Android 4.1, such threads now use the
+  <code>SCHED_FIFO</code> scheduling policy rather than the <code>SCHED_NORMAL</code> (also called
+  <code>SCHED_OTHER</code>) scheduling policy implemented by CFS.
+</p>
+
+<h3 id="schedFifo">SCHED_FIFO priorities</h3>
+<p>
+  Though the high-performance audio threads now use <code>SCHED_FIFO</code>, they
+  are still susceptible to other higher priority <code>SCHED_FIFO</code> threads.
+  These are typically kernel worker threads, but there may also be a few
+  non-audio user threads with policy <code>SCHED_FIFO</code>. The available <code>SCHED_FIFO</code>
+  priorities range from 1 to 99.  The audio threads run at priority
+  2 or 3.  This leaves priority 1 available for lower priority threads,
+  and priorities 4 to 99 for higher priority threads.  We recommend
+  you use priority 1 whenever possible, and reserve priorities 4 to 99 for
+  those threads that are guaranteed to complete within a bounded amount
+  of time, execute with a period shorter than the period of audio threads,
+  and are known to not interfere with scheduling of audio threads.
+</p>
+
+<h3 id="rms">Rate-monotonic scheduling</h3>
+<p>
+  For more information on the theory of assignment of fixed priorities,
+  see the Wikipedia article
+  <a href="http://en.wikipedia.org/wiki/Rate-monotonic_scheduling">Rate-monotonic scheduling</a> (RMS).
+  A key point is that fixed priorities should be allocated strictly based on period,
+  with higher priorities assigned to threads of shorter periods, not based on perceived "importance."
+  Non-periodic threads may be modeled as periodic threads, using the maximum frequency of execution
+  and maximum computation per execution.  If a non-periodic thread cannot be modeled as
+  a periodic thread (for example it could execute with unbounded frequency or unbounded computation
+  per execution), then it should not be assigned a fixed priority as that would be incompatible
+  with the scheduling of true periodic threads.
+</p>
+
+<h3 id="schedLatency">Scheduling latency</h3>
+<p>
+  Scheduling latency is the time between when a thread becomes
+  ready to run and when the resulting context switch completes so that the
+  thread actually runs on a CPU. The shorter the latency the better, and
+  anything over two milliseconds causes problems for audio. Long scheduling
+  latency is most likely to occur during mode transitions, such as
+  bringing up or shutting down a CPU, switching between a security kernel
+  and the normal kernel, switching from full power to low-power mode,
+  or adjusting the CPU clock frequency and voltage.
+</p>
+
+<h3 id="interrupts">Interrupts</h3>
+<p>
+  In many designs, CPU 0 services all external interrupts.  So a
+  long-running interrupt handler may delay other interrupts, in particular
+  audio direct memory access (DMA) completion interrupts. Design interrupt handlers
+  to finish quickly and defer lengthy work to a thread (preferably
+  a CFS thread or <code>SCHED_FIFO</code> thread of priority 1).
+</p>
+
+<p>
+  Equivalently, disabling interrupts on CPU 0 for a long period
+  has the same result of delaying the servicing of audio interrupts.
+  Long interrupt disable times typically happen while waiting for a kernel
+  <i>spin lock</i>.  Review these spin locks to ensure they are bounded.
+</p>
+
+<h3 id="power">Power, performance, and thermal management</h3>
+<p>
+  <a href="http://en.wikipedia.org/wiki/Power_management">Power management</a>
+  is a broad term that encompasses efforts to monitor
+  and reduce power consumption while optimizing performance.
+  <a href="http://en.wikipedia.org/wiki/Thermal_management_of_electronic_devices_and_systems">Thermal management</a>
+  and <a href="http://en.wikipedia.org/wiki/Computer_cooling">computer cooling</a>
+  are similar but seek to measure and control heat to avoid damage due to excess heat.
+  In the Linux kernel, the CPU
+  <a href="http://en.wikipedia.org/wiki/Governor_%28device%29">governor</a>
+  is responsible for low-level policy, while user mode configures high-level policy.
+  Techniques used include:
+</p>
+
+<ul>
+  <li>dynamic voltage scaling</li>
+  <li>dynamic frequency scaling</li>
+  <li>dynamic core enabling</li>
+  <li>cluster switching</li>
+  <li>power gating</li>
+  <li>hotplug (hotswap)</li>
+  <li>various sleep modes (halt, stop, idle, suspend, etc.)</li>
+  <li>process migration</li>
+  <li><a href="http://en.wikipedia.org/wiki/Processor_affinity">processor affinity</a></li>
+</ul>
+
+<p>
+  Some management operations can result in "work stoppages" or
+  times during which there is no useful work performed by the application processor.
+  These work stoppages can interfere with audio, so such management should be designed
+  for an acceptable worst-case work stoppage while audio is active.
+  Of course, when thermal runaway is imminent, avoiding permanent damage
+  is more important than audio!
+</p>
+
+<h3 id="security">Security kernels</h3>
+<p>
+  A <a href="http://en.wikipedia.org/wiki/Security_kernel">security kernel</a> for
+  <a href="http://en.wikipedia.org/wiki/Digital_rights_management">Digital rights management</a>
+  (DRM) may run on the same application processor core(s) as those used
+  for the main operating system kernel and application code.  Any time
+  during which a security kernel operation is active on a core is effectively a
+  stoppage of ordinary work that would normally run on that core.
+  In particular, this may include audio work.  By its nature, the internal
+  behavior of a security kernel is inscrutable from higher-level layers, and thus
+  any performance anomalies caused by a security kernel are especially
+  pernicious.  For example, security kernel operations do not typically appear in
+  context switch traces.  We call this "dark time" &mdash; time that elapses
+  yet cannot be observed.  Security kernels should be designed for an
+  acceptable worst-case work stoppage while audio is active.
+</p>
diff --git a/src/devices/audio/latency_measure.jd b/src/devices/audio/latency_measure.jd
index 411e048..f6b1d3e 100644
--- a/src/devices/audio/latency_measure.jd
+++ b/src/devices/audio/latency_measure.jd
@@ -1,4 +1,4 @@
-page.title=Audio Latency
+page.title=Measuring Audio Latency
 @jd:body
 
 <!--
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 2f5d0e4..90404a4 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -15,9 +15,7 @@
 -->
 <?cs # Table of contents for devices.?>
 <ul id="nav">
-
-<!-- Porting Android -->
-  <li class="nav-section">
+  <li class="nav-section">  <!-- Begin nav section, Device Interfaces -->
     <div class="nav-section-header">
       <a href="<?cs var:toroot ?>devices/index.html">
         <span class="en">Interfaces</span>
@@ -42,10 +40,11 @@
               </a>
             </div>
             <ul>
-              <li><a href="<?cs var:toroot ?>devices/audio/latency_measure.html">Measure</a></li>
+              <li><a href="<?cs var:toroot ?>devices/audio/latency_contrib.html">Contributors</a></li>
               <li><a href="<?cs var:toroot ?>devices/audio/latency_design.html">Design</a></li>
+              <li><a href="<?cs var:toroot ?>devices/audio/latency_measure.html">Measure</a></li>
               <li><a href="<?cs var:toroot ?>devices/audio/testing_circuit.html">Light Testing Circuit</a></li>
-              <li><a href="<?cs var:toroot ?>devices/audio/loopback.html">Loopback Audio Dongle</a></li>
+              <li><a href="<?cs var:toroot ?>devices/audio/loopback.html">Audio Loopback Dongle</a></li>
             </ul>
           </li>
           <li><a href="<?cs var:toroot ?>devices/audio/avoiding_pi.html">Priority Inversion</a></li>
@@ -110,8 +109,7 @@
               <li><a href="<?cs var:toroot ?>devices/graphics/cts-integration.html">Integrating with Android CTS</a></li>
             </ul>
          </li>
-        </ul>
-      </li>
+        </ul> </li>
       <li class="nav-section">
         <div class="nav-section-header">
           <a href="<?cs var:toroot ?>devices/input/index.html">
@@ -132,59 +130,23 @@
         </ul>
       </li>
       <li><a href="<?cs var:toroot ?>devices/media.html">Media</a></li>
-     <li class="nav-section">
-          <div class="nav-section-header">
-            <a href="<?cs var:toroot ?>devices/sensors/index.html">
-              <span class="en">Sensors</span>
-            </a>
-          </div>
-          <ul>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/sensor-stack.html">
-                <span class="en">Sensor stack</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/report-modes.html">
-                <span class="en">Reporting modes</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/suspend-mode.html">
-                <span class="en">Suspend mode</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/power-use.html">
-                <span class="en">Power consumption</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/interaction.html">
-                <span class="en">Interaction</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/hal-interface.html">
-                <span class="en">HAL interface</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/batching.html">
-                <span class="en">Batching</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/sensor-types.html">
-                <span class="en">Sensor types</span>
-              </a>
-            </li>
-            <li>
-              <a href="<?cs var:toroot ?>devices/sensors/versioning.html">
-                <span class="en">Version deprecation</span>
-              </a>
-            </li>
-          </ul>
+      <li class="nav-section">
+        <div class="nav-section-header">
+          <a href="<?cs var:toroot ?>devices/sensors/index.html">
+            <span class="en">Sensors</span>
+          </a>
+        </div>
+        <ul>
+          <li><a href="<?cs var:toroot ?>devices/sensors/sensor-stack.html">Sensor stack</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/report-modes.html">Reporting modes</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/suspend-mode.html">Suspend mode</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/power-use.html">Power consumption</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/interaction.html">Interaction</span></a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/hal-interface.html">HAL interface</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/batching.html">Batching</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/sensor-types.html">Sensor types</a></li>
+          <li><a href="<?cs var:toroot ?>devices/sensors/versioning.html">Version deprecation</a></li>
+        </ul>
       </li>
       <li class="nav-section">
         <div class="nav-section-header">
@@ -196,14 +158,11 @@
           <li><a href="<?cs var:toroot ?>devices/tv/HDMI-CEC.html">HDMI-CEC control service</a></li>
         </ul>
       </li>
-
     </ul>
-  </li>
-<!-- End Porting Android -->
-  </li>
+  </li> <!-- End nav-section, Device Interfaces-->
 
 
-  <li class="nav-section">
+  <li class="nav-section"> <!--Begin nav-section, Core Technologies-->
     <div class="nav-section-header">
       <a href="<?cs var:toroot ?>devices/tech/index.html">
         <span class="en">Core Technologies</span>
@@ -251,7 +210,6 @@
           <li><a href="<?cs var:toroot ?>devices/tech/debug/tuning.html">Performance Tuning</a></li>
           <li><a href="<?cs var:toroot ?>devices/tech/debug/native-memory.html">Native Memory Usage</a></li>
           <li><a href="<?cs var:toroot ?>devices/tech/debug/dumpsys.html">Dumpsys</a></li>
-
         </ul>
       </li>
 
@@ -263,31 +221,22 @@
         </div>
       </li>
 
-      <li>
-          <a href="<?cs var:toroot ?>devices/tech/kernel.html">
-            <span class="en">Kernel</span>
-          </a>
-      </li>
-
-      <li>
-          <a href="<?cs var:toroot ?>devices/tech/low-ram.html">
-            <span class="en">Low RAM</span>
-          </a>
-      </li>
+      <li><a href="<?cs var:toroot ?>devices/tech/kernel.html">Kernel</a></li>
+      <li><a href="<?cs var:toroot ?>devices/tech/low-ram.html">Low RAM</a></li>
 
       <li class="nav-section">
-            <div class="nav-section-header">
-              <a href="<?cs var:toroot ?>devices/tech/ota/index.html">
-                <span class="en">OTA Updates</span>
-              </a>
-    </div>
-            <ul>
-              <li><a href="<?cs var:toroot ?>devices/tech/ota/tools.html">OTA Tools</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/ota/block.html">Block-based OTA</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/ota/inside_packages.html">Inside OTA Packages</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/ota/device_code.html">Device-Specific Code</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/ota/sign_builds.html">Signing Builds for Release</a></li>
-            </ul>
+        <div class="nav-section-header">
+            <a href="<?cs var:toroot ?>devices/tech/ota/index.html">
+              <span class="en">OTA Updates</span>
+            </a>
+        </div>
+        <ul>
+          <li><a href="<?cs var:toroot ?>devices/tech/ota/tools.html">OTA Tools</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/ota/block.html">Block-based OTA</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/ota/inside_packages.html">Inside OTA Packages</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/ota/device_code.html">Device-Specific Code</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/ota/sign_builds.html">Signing Builds for Release</a></li>
+        </ul>
       </li>
 
       <li>
@@ -295,14 +244,14 @@
             <span class="en">Power</span>
           </a>
       </li>
-     <li class="nav-section">
-          <div class="nav-section-header">
+      <li class="nav-section">
+        <div class="nav-section-header">
             <a href="<?cs var:toroot ?>devices/tech/security/index.html">
               <span class="en">Security</span>
             </a>
-          </div>
+        </div>
         <ul>
-       <li class="nav-section">
+          <li class="nav-section">
             <div class="nav-section-header">
               <a href="<?cs var:toroot ?>devices/tech/security/overview/index.html">
                 <span class="en">Overview</span>
@@ -312,62 +261,58 @@
               <li><a href="<?cs var:toroot ?>devices/tech/security/overview/kernel-security.html">Kernel security</a></li>
               <li><a href="<?cs var:toroot ?>devices/tech/security/overview/app-security.html">App security</a></li>
               <li><a href="<?cs var:toroot ?>devices/tech/security/overview/updates-resources.html">Updates and resources</a></li>
-                        <li class="nav-section">
-            <div class="nav-section-header">
-              <a href="<?cs var:toroot ?>devices/tech/security/enhancements/index.html">
-                <span class="en">Enhancements</span>
-              </a>
-            </div>
-            <ul>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements50.html">Android 5.0</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements44.html">Android 4.4</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements43.html">Android 4.3</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements42.html">Android 4.2</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements41.html">Android 4.1</a></li>
+              <li class="nav-section">
+                <div class="nav-section-header">
+                  <a href="<?cs var:toroot ?>devices/tech/security/enhancements/index.html">
+                    <span class="en">Enhancements</span>
+                  </a>
+                </div>
+                <ul>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements50.html">Android 5.0</a></li>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements44.html">Android 4.4</a></li>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements43.html">Android 4.3</a></li>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements42.html">Android 4.2</a></li>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements41.html">Android 4.1</a></li>
+                </ul>
+              </li>
+              <li><a href="<?cs var:toroot ?>devices/tech/security/overview/acknowledgements.html">Acknowledgements</a></li>
             </ul>
           </li>
-            <li><a href="<?cs var:toroot ?>devices/tech/security/overview/acknowledgements.html">Acknowledgements</a></li>
-            </ul>
-          </li>
-        <li class="nav-section">
+          <li class="nav-section">
             <div class="nav-section-header">
               <a href="<?cs var:toroot ?>devices/tech/security/implement.html">
                 <span class="en">Implementation</span>
               </a>
             </div>
             <ul>
-            <li>
-              <a href="<?cs var:toroot ?>devices/tech/security/encryption/index.html">
-                <span class="en">Encryption</span>
-              </a>
+              <li><a href="<?cs var:toroot ?>devices/tech/security/encryption/index.html">Encryption</a></li>
+              <li class="nav-section">
+                <div class="nav-section-header">
+                  <a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/index.html">
+                    <span class="en">Verified Boot</span>
+                  </a>
+                </div>
+                <ul>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/verified-boot.html">Verifying boot</a></li>
+                  <li><a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/dm-verity.html">Implementing dm-verity</a></li>
+                </ul>
+              </li>
+            <li class="nav-section">
+              <div class="nav-section-header">
+                <a href="<?cs var:toroot ?>devices/tech/security/selinux/index.html">
+                  <span class="en">Security-Enhanced Linux</span>
+                </a>
+              </div>
+              <ul>
+                <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/concepts.html">Concepts</a></li>
+                <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/implement.html">Implementation</a></li>
+                <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/customize.html">Customization</a></li>
+                <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/validate.html">Validation</a></li>
+              </ul>
             </li>
-          <li class="nav-section">
-            <div class="nav-section-header">
-              <a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/index.html">
-                <span class="en">Verified Boot</span>
-              </a>
-            </div>
-            <ul>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/verified-boot.html">Verifying boot</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/dm-verity.html">Implementing dm-verity</a></li>
-            </ul>
-          </li>
-          <li class="nav-section">
-            <div class="nav-section-header">
-              <a href="<?cs var:toroot ?>devices/tech/security/selinux/index.html">
-                              <span class="en">Security-Enhanced Linux</span>
-              </a>
-            </div>
-            <ul>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/concepts.html">Concepts</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/implement.html">Implementation</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/customize.html">Customization</a></li>
-              <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/validate.html">Validation</a></li>
-            </ul>
-          </li>
-         </ul>
-      </li>
-    </ul>
+          </ul>
+        </li>
+      </ul>
       <li class="nav-section">
         <div class="nav-section-header">
           <a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/index.html">
@@ -375,29 +320,21 @@
           </a>
         </div>
         <ul>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/index.html"
-            >Start Here</a></li>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/machine_setup.html"
-            >Machine Setup</a></li>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/devices.html"
-            >Working with Devices</a></li>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/lifecycle.html"
-            >Test Lifecycle</a></li>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/options.html"
-            >Option Handling</a></li>
-          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/full_example.html"
-            >An End-to-End Example</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/index.html">Start Here</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/machine_setup.html">Machine Setup</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/devices.html">Working with Devices</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/lifecycle.html">Test Lifecycle</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/fundamentals/options.html">Option Handling</a></li>
+          <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/full_example.html">An End-to-End Example</a></li>
           <li id="tradefed-tree-list" class="nav-section">
             <div class="nav-section-header">
               <a href="<?cs var:toroot ?>reference/packages.html">
-            <span class="en">Package Index</span>
-          </a>
-        <div>
-      </li>
+                <span class="en">Package Index</span>
+              </a>
+            </div>
+          </li>
         </ul>
       </li>
-
     </ul>
-  </li>
-
-</ul>
+  </li> <!-- End nav-section, Core Technologies -->
+</ul> 
diff --git a/src/devices/tech/security/overview/acknowledgements.jd b/src/devices/tech/security/overview/acknowledgements.jd
index 6fe71f8..19e79ec 100644
--- a/src/devices/tech/security/overview/acknowledgements.jd
+++ b/src/devices/tech/security/overview/acknowledgements.jd
@@ -30,6 +30,19 @@
 
 <p><a href="mailto:higongguang@gmail.com">Guang Gong</a> of <a href="http://www.360safe.com/">Qihoo 360 Technology Co. Ltd</a> (<a href="https://twitter.com/oldfresher">@oldfresher</a>)</p>
 
+<p>Stephan Huber of Testlab Mobile Security, <a
+href="https://www.sit.fraunhofer.de/">Fraunhofer SIT</a> (<a
+href="mailto:Stephan.Huber@sit.fraunhofer.de">Stephan.Huber@sit.fraunhofer.de</a>)
+</p>
+
+<p><a
+href="http://www.ec-spride.tu-darmstadt.de/en/research-groups/secure-software-engineering-group/staff/siegfried-rasthofer/">Siegfried
+Rasthofer</a> of <a href="http://sseblog.ec-spride.de/">Secure Software
+Engineering Group</a>, EC SPRIDE Technische Universität Darmstadt (<a
+href="mailto:siegfried.rasthofer@gmail.com">siegfried.rasthofer@gmail.com</a>)</p>
+
+<p><a href="mailto:laginimaineb@gmail.com">Gal Beniamini</a> (<a href="http://bits-please.blogspot.com">http://bits-please.blogspot.com</a>)</p>
+
 </div>
 
 <h2>2014</h2>
diff --git a/src/index.jd b/src/index.jd
index a0e4624..6cc69db 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -41,6 +41,43 @@
   <div class="landing-docs">
     <div class="col-8">
     <h3>What's New</h3>
+<a href="{@docRoot}source/initializing.html">
+        <h4>Initializing Improvements</h4></a>
+        <p>Build environment <strong><a
+        href="{@docRoot}source/initializing.html#setting-up-a-mac-os-x-build-environment">Initializing</a></strong>
+        instructions now explain how to resize and unmount Mac OS sparse
+        images. And the ccache section has been moved to an optional <strong><a
+        href="{@docRoot}source/initializing.html#optimizing-a-build-environment">Optimizing
+        a build environment</a></strong> section.</p>
+
+<a href="{@docRoot}devices/tech/security/selinux/index.html">
+        <h4>SELinux Permissive Declarations</h4></a>
+        <p>SELinux <strong><a
+        href="{@docRoot}devices/tech/security/selinux/customize.html">Customizing</a></strong>
+        and <strong><a
+        href="{@docRoot}devices/tech/security/selinux/implement.html">Implementing</a></strong>
+        instructions have been updated to recommend using permissive declarations
+        directly as <code>permissive_or_unconfined()</code> has been deprecated.
+        Similarly, <code>BOARD_SEPOLICY_UNION</code> has been removed, so
+        <code>BOARD_SEPOLICY_*</code> variables are suggested insead.</p>
+
+<a href="{@docRoot}devices/input/diagnostics.html">
+        <h4>Dumpsys Input and System Diagnostics</h4></a>
+        <p>Dumpsys contents have been completely rewritten with fresh output
+        examples and split into <strong><a
+        href="{@docRoot}devices/input/diagnostics.html">Input Diagnostics</a></strong>
+        and <strong><a href="{@docRoot}devices/tech/debug/dumpsys.html">System
+        Diagnostics</a></strong>.</p>
+
+<a href="{@docRoot}devices/bluetooth.html">
+        <h4>Android 5.0 Bluetooth HCI Requirements</h4></a>
+        <p><strong><a
+        href="{@docRoot}devices/Android-5.0-Bluetooth-HCI-Reqs.pdf">Bluetooth
+        Host Controller Interface (HCI) requirements</a></strong> to leverage
+        the Bluetooth Low Energy APIs in Android 5.0 have
+        been published and linked from the <strong><a
+        href="{@docRoot}devices/bluetooth.html">Bluetooth</a></strong> introduction.</p>
+
 <a href="{@docRoot}devices/tech/ota/index.html">
         <h4>OTA Updates</h4></a>
         <p>An entire suite of documentation has been added describing the <strong><a
@@ -61,43 +98,6 @@
         boot</a></strong> and <strong><a
         href="{@docRoot}devices/tech/security/verifiedboot/dm-verity.html">implementing
         dm-verity</a></strong>.</p>
-
-<a href="{@docRoot}devices/graphics/testing.html">
-        <h4>OpenGL ES Graphics Diagnostics</h4></a>
-        <p>The graphics diagnostics user guide has been converted to an <strong><a
-        href="{@docRoot}devices/graphics/testing.html">OpenGL ES
-        testing</a></strong> section of the site for easy access to information for <strong><a
-        href="{@docRoot}devices/graphics/build-tests.html">building test programs</a></strong>, <strong><a
-        href="{@docRoot}devices/graphics/run-tests.html">running the tests</a></strong>, <strong><a
-        href="{@docRoot}devices/graphics/test-groups.html">using special test groups</a></strong>, and more.</p>
-
-<a href="{@docRoot}devices/index.html">
-        <h4>Devices Diagrams and Other Figures</h4></a>
-        <p>Diagrams and other figures within <strong><a
-        href="{@docRoot}devices/index.html">Devices</a></strong> have been redesigned
-        to become more clear and adhere to Android’s material design theme.</p>
-
-<a href="{@docRoot}source/submit-patches.html">
-        <h4>Submitting Patches</h4></a>
-        <p>The <strong><a
-        href="{@docRoot}source/submit-patches.html#resolving-sync-conflicts">Resolving
-        sync conflicts section of Submitting Patches</a></strong> has been updated to
-        replace an outdated <code>git rebase</code> command with: <code>repo
-        rebase</code></p>
-
-<a href="{@docRoot}source/build-numbers.html">
-        <h4>Lollipop API level, Build Tag</h4></a>
-        <p>The latest <strong><a
-        href="{@docRoot}source/build-numbers.html#platform-code-names-versions-api-levels-and-ndk-releases">Lollipop
-        API level</a></strong> and <strong><a
-        href="{@docRoot}source/build-numbers.html#source-code-tags-and-builds">build
-        tag</a></strong> have been updated to 22 and LMY47D, respectively.</p>
-
-<a href="{@docRoot}compatibility/contact-us.html">
-        <h4>Google Mobile Services Inquiry Form</h4></a>
-        <p>Prospective Google Mobile Services (GMS) partners now have an online <strong><a
-        href="https://docs.google.com/a/google.com/forms/d/1qAHuR-MbmXeYuJ1aBd3neaUjNGxnnnCd2kzb0MEJpGQ/viewform"
-        target="_blank">inquiry form</a></strong> to request a GMS license.</p>
     </div>
 
     <div class="col-8">
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
index 3337685..bff9b0d 100644
--- a/src/source/build-numbers.jd
+++ b/src/source/build-numbers.jd
@@ -187,7 +187,7 @@
   <td>LMY47D</td>
   <td>android-5.1.0_r1</td>
   <td>Lollipop</td>
-  <td>Nexus 5, Nexus 6, Nexus 7 (grouper), Nexus 10, Nexus Player</td>
+  <td>Nexus 5, Nexus 6, Nexus 7 (grouper/tilapia), Nexus 10, Nexus Player</td>
 </tr>
 <tr>
   <td>LRX22G</td>