diff --git a/src/devices/index.jd b/src/devices/index.jd
index 68abdcd..e433f1c 100644
--- a/src/devices/index.jd
+++ b/src/devices/index.jd
@@ -24,76 +24,95 @@
   </div>
 </div>
 
-  <p>Android provides you with the freedom to implement your own device specifications
-  and the drivers to support them. The hardware abstraction layer (HAL) gives you a
-  standard way to create software hooks in between the Android
-  platform stack and your hardware. In addition, the Android operating system
-  is open-sourced to help you through your device's bringup.</p>
+<p>
+Android gives you the freedom to implement your own device specifications and
+drivers. The hardware abstraction layer (HAL) provides a standard method for
+creating software hooks between the Android platform stack and your hardware.
+The Android operating system is also open source, so you can contribute your own
+interfaces and enhancements.
+</p>
 
-  <p>To ensure that your devices maintain a high level of quality and offers a consistent
-  experience for your users, they must must also
-  pass the tests in the compatibility test suite (CTS). CTS ensures that anyone
-  building a device meets a quality standard that ensures apps run reliably well
-  and gives users a good experience. For more information, see the
-  <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p>
+<p>
+To ensure devices maintain a high level of quality and offer a consistent user
+experience, each device must pass tests in the compatibility test suite (CTS).
+The CTS verifies devices meet a quality standard that ensures apps run reliably
+and users have a good experience. For details on the CTS, see
+<a href="{@docRoot}compatibility/index.html">Compatibility</a>.
+</p>
 
- <h2>Android Low-Level System Architecture</h2>
+<h2 id="Android system architecture">Android system architecture</h2>
 
-<p>Before you begin porting Android to your hardware, it is important to have an
-understanding of how Android works at a high level. Because your drivers and HAL code interact
-with many layers of Android code, this understanding can help you find
-your way through the many layers of code that are available to you through the AOSP
-(Android Open Source Project) source tree. The following diagram shows a system
-level view of how Android works:
+<p>
+Before porting Android to your hardware, take a moment to understand the Android
+system architecture at a high level. Because your drivers and the HAL interact
+with Android, knowing how Android works can help you navigate the many layers of
+code in the Android Open Source Project (AOSP) source tree.
 </p>
 
 <img src="images/ape_fwk_all.png">
 
 <p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
 
-  <h4>Application framework</h4>
-  <p>This is the level that most application developers concern themselves with. You should be
-    aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
-    interfaces and can provide information as to how to implement your driver.
-  </p>
-
-  <h4>Binder IPC</h4>
-  <p>
-  The Binder Inter-Process Communication mechanism allows the application framework to
-  cross process boundaries and call into the Android system services code. This basically allows
-  high level framework APIs to interact with Android's system services. At the application framework level, all
-  of this communication is hidden from the developer and things appear to "just work."
-  </p>
-
-  <h4>System services</h4>
-  <p>Most of the functionality exposed through the application framework APIs  must
-    communicate with some sort of system service to access the underlying hardware. Services
-    are divided into modular components with focused functionality
-    such as the Window Manager, Search Service, or Notification Manager. System services are grouped
-    into two buckets: system and media. The system services include things such as the Window or
-    Notification Manager. The media services include all the services involved in playing and
-    recording media.
-  </p>
-
-<h4>Hardware abstraction layer (HAL)</h4>
-<p>The HAL serves as a standard interface that allows the Android system to call into the device
-  driver layer while being agnostic about the lower-level implementations of your drivers and hardware.</p>
-<img src="images/ape_fwk_hal.png">
-<p class="img-caption"><strong>Figure 2.</strong> Hardware abstraction layer (HAL) components</p>
+<h3 id="Application framework">Application framework</h3>
 <p>
-  You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
-  provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
-  you have free reign to do what is best for your situation. However, you must abide by the contract
-  defined in each hardware-specific HAL interface for the Android system to be able
-  to correctly interact with your hardware. HAL implementations are typically built into
-  shared library modules (<code>.so</code> files).
+The application framework is used most often by application developers. As a
+hardware developer, you should be aware of developer APIs as many map directly
+to the underlying HAL interfaces and can provide helpful information about
+implementing drivers.
 </p>
-<h4>Linux Kernel</h4>
-<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
-  Android uses a specialized version of the Linux kernel with a few special additions such as
-  wakelocks, a memory management system that is more agressive in preserving memory,
-  the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
-  These additions have less to do with driver development than with the system's functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend
-  using the latest version of the Android kernel. For the latest Android kernel, see
-  <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
+
+<h3 id="Binder IPC">Binder IPC</h3>
+<p>
+The Binder Inter-Process Communication (IPC) mechanism allows the application
+framework to cross process boundaries and call into the Android system services
+code. This enables high level framework APIs to interact with Android system
+services. At the application framework level, this communication is hidden from
+the developer and things appear to "just work."
 </p>
+
+<h3 id="System services">System services</h3>
+<p>
+Functionality exposed by application framework APIs communicates with system
+services to access the underlying hardware. Services are modular, focused
+components such as Window Manager, Search Service, or Notification Manager.
+Android includes two groups of services: <em>system</em> (services such as
+Window Manager and Notification Manager) and <em>media</em> (services involved
+in playing and recording media).
+</p>
+
+<h3 id="Hardware Abstraction Layer">Hardware abstraction layer (HAL)</h3>
+<p>
+The HAL is a standard interface that allows the Android system to call into the
+device driver layer while being agnostic about the lower-level implementations
+of drivers and hardware.
+</p>
+
+<img src="images/ape_fwk_hal.png">
+
+<p class="img-caption"><strong>Figure 2.</strong> Hardware abstraction layer
+(HAL) components</p>
+
+<p>
+You must implement the corresponding HAL (and driver) for the specific hardware
+your product provides. HAL implementations are typically built into shared
+library modules (<code>.so</code> files). Android does not mandate a standard
+interaction between your HAL implementation and your device drivers, so you have
+free reign to do what is best for your situation. However, to enable the Android
+system to correctly interact with your hardware, you <strong>must</strong> abide
+by the contract defined in each hardware-specific HAL interface.
+</p>
+
+<h3 id="Linux kernel">Linux Kernel</h3>
+<p>
+Developing your device drivers is similar to developing a typical Linux device
+driver. Android uses a version of the Linux kernel with a few special additions
+such as wake locks (a memory management system that is more agressive in
+preserving memory), the Binder IPC driver, and other features important for a
+mobile embedded platform. These additions are primarily for system functionality
+and do not affect driver development.
+
+<p>
+You can use any version of the kernel as long as it supports the required
+features (such as the binder driver). However, we recommend using the latest
+version of the Android kernel. For details on the latest Android kernel, see <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
+</p>
\ No newline at end of file