diff --git a/src/compatibility/2.1/versions.jd b/src/compatibility/2.1/versions.jd
index cbc12ef..2551382 100644
--- a/src/compatibility/2.1/versions.jd
+++ b/src/compatibility/2.1/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 2.1
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.1-cdd.pdf">Android 2.1 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-2.1-cdd.pdf">Android 2.1 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
@@ -19,4 +19,4 @@
 <li>
 <p>2.1-update1</p>
 </li>
-</ul>
\ No newline at end of file
+</ul>
diff --git a/src/compatibility/2.2/versions.jd b/src/compatibility/2.2/versions.jd
index 5846316..dd223ff 100644
--- a/src/compatibility/2.2/versions.jd
+++ b/src/compatibility/2.2/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 2.2
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.2-cdd.pdf">Android 2.2 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-2.2-cdd.pdf">Android 2.2 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
@@ -19,4 +19,4 @@
 <li>
 <p>2.2.1</p>
 </li>
-</ul>
\ No newline at end of file
+</ul>
diff --git a/src/compatibility/2.3/versions.jd b/src/compatibility/2.3/versions.jd
index a3b5481..57ec37d 100644
--- a/src/compatibility/2.3/versions.jd
+++ b/src/compatibility/2.3/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 2.3
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.3-cdd.pdf">Android 2.3 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-2.3-cdd.pdf">Android 2.3 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
@@ -14,4 +14,4 @@
 <code>android.os.Build.VERSION.RELEASE</code> for Android 2.3 are:</p>
 <ul>
 <li>2.3.3</li>
-</ul>
\ No newline at end of file
+</ul>
diff --git a/src/compatibility/4.0/versions.jd b/src/compatibility/4.0/versions.jd
index 12039ba..a3283c5 100644
--- a/src/compatibility/4.0/versions.jd
+++ b/src/compatibility/4.0/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 4.0
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
diff --git a/src/compatibility/4.1/versions.jd b/src/compatibility/4.1/versions.jd
index 9a3106c..e3439e9 100644
--- a/src/compatibility/4.1/versions.jd
+++ b/src/compatibility/4.1/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 4.1
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.1-cdd.pdf">Android 4.1 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-4.1-cdd.pdf">Android 4.1 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
@@ -19,4 +19,4 @@
 <li>
 <p>4.1.1</p>
 </li>
-</ul>
\ No newline at end of file
+</ul>
diff --git a/src/compatibility/4.2/versions.jd b/src/compatibility/4.2/versions.jd
index 065085b..9730b6a 100644
--- a/src/compatibility/4.2/versions.jd
+++ b/src/compatibility/4.2/versions.jd
@@ -1,7 +1,7 @@
 page.title=Permitted Version Strings for Android 4.2
 @jd:body
 
-<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.2-cdd.pdf">Android 4.2 Compatibility Definition</a>, 
+<p>As described in Section 3.2.2 of the <a href="/compatibility/android-4.2-cdd.pdf">Android 4.2 Compatibility Definition</a>, 
 only certain strings are allowable for the system property
 <code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
 applications and web sites may rely on predictable values for this string, and
diff --git a/src/compatibility/overview.jd b/src/compatibility/overview.jd
index 184903a..befc946 100644
--- a/src/compatibility/overview.jd
+++ b/src/compatibility/overview.jd
@@ -99,7 +99,7 @@
 <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="4.2/android-4.2-cdd.pdf">the latest CDD</a>.</p>
+simply examine <a href="/compatibility/android-4.3-cdd.pdf">the latest CDD</a>.</p>
 <h1 id="compatibility-test-suite-cts">Compatibility Test Suite (CTS)</h1>
 <p>The CTS is a free, commercial-grade test suite, available for
 <a href="downloads.html">download</a>.
diff --git a/src/devices/audio.jd b/src/devices/audio.jd
index 50be277..08ed9ff 100644
--- a/src/devices/audio.jd
+++ b/src/devices/audio.jd
@@ -249,7 +249,7 @@
   </li>
 </ol>
 
-<h2>Audio preprocessing effects</h2>
+<h2 id="preprocessing">Audio preprocessing effects</h2>
 <p>
 The Android platform supports audio effects on supported devices in the
 <a href="http://developer.android.com/reference/android/media/audiofx/package-summary.html">audiofx</a>
@@ -291,7 +291,7 @@
 <p class="warning"><strong>Warning:</strong> For the <code>VOICE_RECOGNITION</code> use case, do not enable
 the noise suppression pre-processing effect. It should not be turned on by default when recording from this audio source,
 and you should not enable it in your own audio_effects.conf file. Turning on the effect by default will cause the device to fail
-the <a href="http://static.googleusercontent.com/external_content/untrusted_dlcp/source.android.com/en/us/compatibility/4.2/android-4.2-cdd.pdf"> compatibility requirement </a>
+the <a href="/compatibility/index.html"> compatibility requirement </a>
 regardless of whether is was on by default due to configuration file, or the audio HAL implementation's default behavior.</p>
 
 <p>The following example enables pre-processing for the VoIP <code>AudioSource</code> and Camcorder <code>AudioSource</code>.
@@ -309,7 +309,7 @@
 }
 </pre>
 
-<h3>Source tuning</h3>
+<h3 id="tuning">Source tuning</h3>
 <p>For <code>AudioSource</code> tuning, there are no explicit requirements on audio gain or audio processing
 with the exception of voice recognition (<code>VOICE_RECOGNITION</code>).</p>
 
@@ -341,7 +341,7 @@
   </li>
 </ul>
 
-<h3>More information</h3>
+<h3 id="more">More information</h3>
 <p>For more information, see:</p>
 <ul>
 <li>Android documentation for <a href="http://developer.android.com/reference/android/media/audiofx/package-summary.html">audiofx 
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 64ff7dc..5446c74 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -169,10 +169,15 @@
                 <span class="en">Security Enhancements in Android 4.3</span>
               </a>
             </li>
+            <li>
+              <a href="<?cs var:toroot ?>devices/tech/security/se-linux.html">
+                <span class="en">Security-Enhanced Linux</span>
+              </a>
+            </li>
+
           </ul>
       </li>
 
-
       <li class="nav-section">
         <div class="nav-section-header">
           <a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/index.html">
diff --git a/src/devices/tech/security/se-linux.jd b/src/devices/tech/security/se-linux.jd
new file mode 100644
index 0000000..d23be8c
--- /dev/null
+++ b/src/devices/tech/security/se-linux.jd
@@ -0,0 +1,315 @@
+page.title=Security-Enhanced Linux 
+@jd:body
+
+<!--
+    Copyright 2010 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.
+-->
+
+<h2 id="introduction">Introduction</h2> <p>In Android 4.3,
+Android begins supporting Security-Enhanced Linux (SELinux), a tool for applying
+access control policies. SELinux enhances Android security, and contributions to
+it have been made by a number of companies and organizations; all Android code
+and contributors are publicly available for review on this same site <a
+href="http://source.android.com/">source.android.com</a>. With SELinux, Android
+can better control access to application data and system logs, reduce the
+effects of malicious software, and protect users from potential flaws in mobile
+code. </p>
+
+<p>In this release, Android includes SELinux in permissive mode and a
+corresponding security policy that works by default across the <a
+href="https://android.googlesource.com/">Android Open Source Project</a>. In
+permissive mode, no actions are prevented. Instead, all potential violations are
+logged by the kernel to <code>dmesg</code>. This allows Android and Android device
+manufacturers to gather information about errors so they may refine their
+software and SELinux policies before enforcing them.</p>
+
+<h2 id="background">Background</h2> <p>Used properly, SELinux greatly limits the
+potential damage of compromised machines and accounts. When you adopt SELinux,
+you instill a structure by which software runs at only the minimum privilege
+level. This mitigates the effects of attacks and reduces the likelihood of
+errant processes overwriting or even transmitting data.</p>
+
+<p>SELinux provides a mandatory access control (MAC) umbrella over traditional
+discretionary access control (DAC) environments. For instance, software must
+typically run as the root user account to write to raw block devices. In a
+traditional DAC-based Linux environment, if the root user becomes compromised
+that user can write to every raw block device. However, SELinux can be used to
+label these devices so the user role assigned the root privilege can write to
+only those specified in the associated policy. In this way, root cannot
+overwrite data and system settings outside of the specific raw block device.</p>
+
+<p>See the <em>Use Cases</em> section for more examples of threats and ways to
+address them with SELinux.</p>
+
+<h2 id="implementation">Implementation</h2> <p>Android&rsquo;s initial SELinux
+implementation is launching in permissive mode - rather than the non-functional
+disabled mode or the most stringent enforcing mode - to act as a reference and
+facilitate testing and development.</p>
+
+<p>SELinux is launching in permissive mode on Android to enable the first phase
+of policy development, and it is accompanied by everything you need to enable
+SELinux now.</p>
+
+<p>You merely need to integrate the <a
+href="https://android.googlesource.com/kernel/common/">latest Android kernel</a>
+and then incorporate the files found in the ~<a
+href="https://android.googlesource.com/platform/external/sepolicy/">platform/external/sepolicy</a>
+directory:<br>
+<a
+href="https://android.googlesource.com/kernel/common/">https://android.googlesource.com/kernel/common/</a>
+<br>
+<a
+href="https://android.googlesource.com/platform/external/sepolicy/">https://android.googlesource.com/platform/external/sepolicy/</a></p>
+
+<p>Those files when compiled comprise the SELinux kernel security policy and
+cover the upstream Android operating system. Place those files within the
+&lt;root&gt;/device/manufacturer/device-name/sepolicy directory.</p>
+
+<p>Then just update your <code>BoardConfig.mk</code> makefile - located in the
+&lt;device-name&gt; directory containing the sepolicy subdirectory - to
+reference the sepolicy subdirectory once created, like so:</p>
+
+<pre>
+BOARD_SEPOLICY_DIRS := \
+        &lt;root&gt;/device/manufacturer/device-name/sepolicy
+
+BOARD_SEPOLICY_UNION := \
+        genfs_contexts \ 
+        file_contexts \ 
+        sepolicy.te 
+</pre>
+
+<p>After rebuilding your device, it is enabled with SELinux. You can now either
+customize your SELinux policies to accommodate your own additions to the Android
+operating system as described in the <em>Customization</em> section or verify
+your existing setup as covered in the <em>Validation</em> section.</p>
+
+<h2 id="customization">Customization</h2> <p>Once you&rsquo;ve integrated this
+base level of functionality and thoroughly analyzed the results, you may add
+your own policy settings to cover your customizations to the Android operating
+system. Of course, these policies must still meet the <a
+href="{@docRoot}compatibility/index.html">Android Compatibility
+program</a> requirements and not remove the default SELinux settings.</p>
+
+<p>Manufacturers should not remove existing security settings. Otherwise, they
+risk breaking the Android SELinux implementation and the applications it
+governs. This includes third-party applications that will likely need to be
+improved to be compliant and operational. Applications must require no
+modification to continue functioning on SELinux-enabled devices.</p>
+
+<p>See section 9.7 of the Android 4.3 Compatibility Definition document for
+specific requirements:<br><a
+href="{@docRoot}compatibility/android-4.3-cdd.pdf">http://source.android.com/compatibility/android-4.3-cdd.pdf</a></p>
+
+<p>SELinux uses a whitelist approach, meaning it grants special privileges based
+upon role. Because the default policy provided by Android is so permissive, OEMs
+have great leeway in strengthening it. Here is how we recommend proceeding:</p>
+
+<ol>
+<li>
+<p>Use the <a
+href="https://android.googlesource.com/kernel/common/">latest Android
+kernel</a>.</p> </li>
+<li>
+<p>Adopt the <a
+href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of
+least privilege</a>.</p></li>
+<li>
+<p>Address only your own additions to
+Android. The default policy works with the <a
+href="https://android.googlesource.com/">Android Open Source Project</a>
+codebase automatically.</p></li>
+<li>
+<p>Compartmentalize software components
+into modules that conduct singular tasks.</p></li>
+<li>
+<p>Create SELinux
+policies that isolate those tasks from unrelated functions.</p></li>
+<li>
+<p>Put those policies in *.te files (the extension for SELinux policy source
+files) within the &lt;root&gt;/device/manufacturer/device-name/sepolicy
+directory.</p></li>
+<li>
+<p>Release your SELinux implementation in permissive
+mode first.</p></li>
+<li><p>Analyze results and refine policy settings.</p>
+</li>
+</ol>
+
+<p>Once integrated, OEM Android development should include a step to ensure
+SELinux compatibility going forward. In an ideal software development process,
+SELinux policy changes only when the software model changes and not the actual
+implementation.</p>
+
+<p>As device manufacturers begin to customize SELinux, they should first audit
+their additions to Android. If you&rsquo;ve added a component that conducts a
+new function, the manufacturer will need to ensure the component meets the
+security policy applied by Android, as well as any associated policy crafted by
+the OEM, before turning on enforcement.</p>
+
+<p>To prevent unnecessary issues, it is better to be overbroad and
+over-compatible than too restrictive and incompatible, which results in broken
+device functions. Conversely, if a manufacturer&rsquo;s changes will benefit
+others, it should supply the modifications to the default SELinux policy as a <a
+href="{@docRoot}source/submit-patches.html">patch</a>. If the
+patch is applied to the default security policy, the manufacturer will no longer
+need to make this change with each new Android release.</p>
+
+<h2 id="use-cases">Use Cases</h2> <p>Here are specific examples of exploits to
+consider when crafting your own software and associated SELinux policies:</p>
+
+<p><strong>Symlinks</strong> - Because symlinks appear as files, they are often read 
+just as that. This can lead to exploits. For instance, some privileged components such
+as init change the permissions of certain files, sometimes to be excessively
+open.</p>
+
+<p>Attackers might then replace those files with symlinks to code they control,
+allowing the attacker to overwrite arbitrary files. But if you know your application 
+will never traverse a symlink, you can prohibit it from doing so with SELinux.</p>
+
+<p><strong>System files</strong> - Consider the class of system files that should only be
+modified by the system server. Still, since <code>netd</code>, <code>init</code>, 
+and <code>vold</code> run as root, they can access those system files. So if 
+<code>netd</code> became compromised, it could compromise those files and 
+potentially the system server itself.</p>
+
+<p>With SELinux, you can identify those files as system server data files.
+Therefore, the only domain that has read/write access to them is system server.
+Even if <code>netd</code> became compromised, it could not switch domains to the 
+system server domain and access those system files although it runs as root.</p>
+
+<p><strong>App data</strong> - Another example is the class of functions that
+must run as root but should not get to access app data. This is incredibly useful as 
+wide-ranging assertions can be made, such as certain domains unrelated to application data
+being prohibited from accessing the internet.</p>
+
+<p><strong>setattr</strong> - For commands such as <code>chmod</code> and
+<code>chown</code>, you could identify the set of files where the associated domain 
+can conduct <code>setattr</code>. Anything outside of that could be prohibited from 
+these changes, even by root. So an application might run <code>chmod</code> and
+<code>chown</code> against those labeled app_data_files but not shell_data_files or 
+system_data_files.</p> <h2 id="related-files">Related
+Files</h2> <p>This section serves to guide you once you&rsquo;ve decided to
+customize the SELinux policy settings. See the <em>Customization</em> section
+for steps. We recommend device manufacturers start with the default Android
+SELinux policy and make the minimum possible set of changes to address their
+additions to Android. Existing Android SELinux policy files are found in the
+root of the ~<a
+href="https://android.googlesource.com/platform/external/sepolicy/">platform/external/sepolicy</a>
+directory.</p>
+
+<p>Android upgraded its SELinux policy version to allow the SELinux mode to be
+set to permissive on a per-domain basis. For example, if you run all of your
+applications on a single domain, you could set that domain to be permissive and
+then have all other functions and their domains set to enforcement. Domains are
+associated with applications by the key used to sign each application. This
+setting is made at the top of each SELinux policy source (*.te) file.</p>
+
+<p>Here are the files you must create or edit in order to customize SELinux:</p>
+<ul> 
+<li>
+<p><em>New SELinux policy source (*.te) files</em> - Located in the
+&lt;root&gt;/device/manufacturer/device-name/sepolicy directory These files
+define domains and their labels. The new policy files get concatenated with the
+existing policy files during compilation into a single SELinux kernel policy
+file.</p></li> 
+<li>
+<p><em>Updated <code>BoardConfig.mk</code> makefile</em> - Located in the
+&lt;device-name&gt; directory containing the sepolicy subdirectory. It must be
+updated to reference the sepolicy subdirectory once created if it wasn&rsquo;t
+in initial implementation.</p> </li> 
+<li>
+<p><em>Updated <code>file_contexts</code></em> - Located in
+the sepolicy subdirectory. It labels files and is managed in the userspace. As
+you create new policies, update this file to reference them. In order to apply
+new <code>file_contexts</code>, you must run <code>restorecon</code> on the file
+to be relabeled.</p>
+</li> </ul>
+
+<p>The remaining files in the sepolicy directory are either auto-generated or
+should remain static. The policy files come in the form: allow, domain, and
+context, for a set of actions:</p>
+
+<ul>
+<li>
+<p><em>Allow</em> - Gives the role permission to carry out the action described
+in the context within the specified domain.</p> </li>
+<li>
+<p><em>Domain</em> - Domain
+represents scope of the rule and gets converted to a security identifier (SID)
+in the kernel.</p> </li>
+<li>
+<p><em>Context</em> - An identifier for the rule, this is converted
+to an integer in the kernel.</p> </li> </ul>
+
+<p>And so the an example use of this would follow the structure:<br>
+<code>allow appdomain app_data_file:file rw_file_perms;</code></p>
+
+<p>This says an application is allowed to read and write files labeled
+app_data_file. During compilation, those overrides are concatenated to the
+existing SELinux settings and into a single security policy. These overrides add
+to the base security policy rather than subtract from existing settings.</p>
+
+<p>Once the new policy files and <code>BoardConfig.mk</code> updates are in place, the new
+policy settings get automatically uploaded to the device.</p>
+
+<h2 id="validation">Validation</h2> <p>Android strongly encourages OEMs to test
+their SELinux implementations thoroughly. As manufacturers implement SELinux,
+they should initially release their own policies in permissive mode. If
+possible, apply the new policy to devices of employees first as a test.</p>
+
+<p>Once applied, make sure SELinux is running in the correct mode on the device
+by issuing the command: <code>getenforce</code></p>
+
+<p>This will print the SELinux mode: either Disabled, Enforcing, or Permissive.
+If permissive, you are compliant. Enforcing is explicitly not compliant in
+Android 4.3. (Because of its risk, enforcing mode comes with a much heavier
+testing burden.)</p>
+
+<p>Then check for errors. Errors are routed as event logs to <code>dmesg</code> 
+and viewable locally on the device. Manufacturers should examine the SELinux output 
+to <code>dmesg</code> on these devices and refine settings prior to public release in 
+permissive mode.</p>
+
+<p>With this output, manufacturers can readily identify when system users or
+components are in violation of SELinux policy. Manufacturers can then repair
+this bad behavior, either by changes to the software, SELinux policy, or
+both.</p>
+
+<p>Specifically, these log messages indicate what roles and processes would fail
+under policy enforcement and why. Android is taking this information, analyzing
+it and refining its default security policy so that it works on a wide range of
+Android devices with little customization. With this policy, OEMs must only
+accommodate their own changes to the Android operating system.</p>
+
+<p>Then run the SELinux-enabled devices through the <a
+href="{@docRoot}compatibility/cts-intro.html">Android
+Compatibility Test Suite</a> (CTS).</p> <p>As said, any new policies must still
+meet the <a href="{@docRoot}compatibility/index.html">Android
+Compatibility program</a> requirements:<br><a
+href="{@docRoot}compatibility/android-4.3-cdd.pdf">http://source.android.com/compatibility/android-4.3-cdd.pdf</a></p>
+
+<p>If you run the devices through the CTS and find no errors in
+<code>dmesg</code>, you can consider your SELinux implementation compatible.</p>
+
+<p>Finally, if possible, turn on enforcement internally (on devices of
+employees) to raise the visibility of failures. Identify any user issues and
+resolve them.  </p> <h2 id="help">Help</h2> Device manufacturers are strongly
+encouraged to work with their Android account managers to analyze SELinux
+results and improve policy settings. Over time, Android intends to support
+common manufacturer additions in its default SELinux policy. For more
+information, contact <a
+href="mailto:security@android.com">security@android.com</a> or Geremy Condra (<a
+href="mailto:gcondra@google.com">gcondra@google.com</a>) directly.
diff --git a/src/images/Android_Robot_100.png b/src/images/Android_Robot_100.png
new file mode 100644
index 0000000..946ee3a
--- /dev/null
+++ b/src/images/Android_Robot_100.png
Binary files differ
diff --git a/src/index.jd b/src/index.jd
index 7fa4b2f..c48a90e 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -44,7 +44,8 @@
     <h3>Updates</h3>
       <a href="{@docRoot}source/index.html">
         <h4>Source Code Available for Android 4.3</h4>
-        <p>Android is an open-source software stack for a wide array of mobile devices with different form factors. 
+        <p>Android is an open-source software stack for a wide array of mobile devices with different form factors.
+<img border="0" src="images/Android_Robot_100.png" alt="Android Partner icon" style="display:inline;float:right;margin:5px 10px"> 
         We created Android in response to our own experiences launching mobile apps. We wanted to make sure there was 
         no central point of failure so no industry player can restrict or control the innovations of any other. That's 
         why we created Android and made its source code open.</p>
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
index af80f13..fc84fc8 100644
--- a/src/source/build-numbers.jd
+++ b/src/source/build-numbers.jd
@@ -430,6 +430,12 @@
 </tr>
 
 <tr>
+<td>JZO54M</td>
+<td>android-4.1.2_r2.1</td>
+<td></td>
+</tr>
+
+<tr>
 <td>JOP40C</td>
 <td>android-4.2_r1</td>
 <td>Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
@@ -479,8 +485,26 @@
 
 <tr>
 <td>JWR66N</td>
+<td>android-4.3_r0.9.1</td>
+<td>Galaxy Nexus, Nexus 7 (grouper/tilapia/flo), Nexus 4, Nexus 10</td>
+</tr>
+
+<tr>
+<td>JWR66V</td>
 <td>android-4.3_r1</td>
-<td>latest Jelly Bean version, Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
+<td>Galaxy Nexus, Nexus 7 (grouper/tilapia), Nexus 4, Nexus 10</td>
+</tr>
+
+<tr>
+<td>JSR78D</td>
+<td>android-4.3_r2</td>
+<td>Nexus 7 (deb)</td>
+</tr>
+
+<tr>
+<td>JSS15J</td>
+<td>android-4.3_r2.1</td>
+<td>latest Jelly Bean version, Nexus 7 (flo/deb)</td>
 </tr>
 
 </tbody>
diff --git a/src/source/building-devices.jd b/src/source/building-devices.jd
index 5bb2f2c..5428259 100644
--- a/src/source/building-devices.jd
+++ b/src/source/building-devices.jd
@@ -32,8 +32,7 @@
 Nexus 4, Nexus 7, and for some variants of Galaxy Nexus.
 The exact level of functionality for each device depends on the availability
 of the relevant proprietary hardware-specific binaries.</p>
-<p>For Nexus 4 "mako" and on Nexus 7 "grouper" (Wi-Fi) and "tilapia" (Mobile),
-all configurations can be used,
+<p>For Nexus 4 and Nexus 7, all configurations can be used,
 and all the hardware is functional.
 Due to hardware differences, do not use 4.1.1 on a Nexus 7 that
 was originally sold with 4.1.2 or newer.</p>
@@ -77,6 +76,14 @@
 </thead>
 <tbody>
 <tr>
+<td>flo</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>deb</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
 <td>manta</td>
 <td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
 </tr>
@@ -186,6 +193,16 @@
 </thead>
 <tbody>
 <tr>
+<td>flo</td>
+<td>android-4.3_r2.1 or master</td>
+<td>aosp_flo-userdebug</td>
+</tr>
+<tr>
+<td>deb</td>
+<td>android-4.3_r2.1 or master</td>
+<td>aosp_deb-userdebug</td>
+</tr>
+<tr>
 <td>manta</td>
 <td>android-4.2.2_r1</td>
 <td>full_manta-userdebug</td>
@@ -203,7 +220,7 @@
 <tr>
 <td>tilapia</td>
 <td>android-4.3_r1 or master</td>
-<td>aosp_grouper-userdebug</td>
+<td>aosp_tilapia-userdebug</td>
 </tr>
 <tr>
 <td>maguro</td>
diff --git a/src/source/building-kernels.jd b/src/source/building-kernels.jd
index 3cc6c1e..092e3d3 100644
--- a/src/source/building-kernels.jd
+++ b/src/source/building-kernels.jd
@@ -40,6 +40,18 @@
     <th>Build configuration</th>
   </tr>
   <tr>
+    <td>flo</td>
+    <td>device/asus/flo-kernel/kernel</td>
+    <td>kernel/msm</td>
+    <td>flo_defconfig</td>
+  </tr>
+  <tr>
+    <td>deb</td>
+    <td>device/asus/flo-kernel/kernel</td>
+    <td>kernel/msm</td>
+    <td>flo_defconfig</td>
+  </tr>
+  <tr>
     <td>manta</td>
     <td>device/samsung/manta/kernel</td>
     <td>kernel/exynos</td>
@@ -173,4 +185,4 @@
 <p>
 The kernel binary is output as `arch/arm/boot/zImage`, and needs to be copied
 into the Android source tree in order to build the matching boot image.
-</p>
\ No newline at end of file
+</p>
diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd
index 97a6ca8..95188ee 100644
--- a/src/source/code-lines.jd
+++ b/src/source/code-lines.jd
@@ -25,10 +25,10 @@
 </div>
 
 <p>
-  The Android Open Source Project maintains a complete software stack intended to be ported by
-  OEMs and other device implementors to run on actual hardware. To maintain the quality of
-  Android, Google has contributed full-time engineers, product managers, UI designers, Quality
-  Assurance, and all the other roles required to bring modern devices to market.
+  The Android Open Source Project (AOSP) maintains a complete software stack to be ported by
+  OEMs and other device implementors and run on their own hardware. To maintain the quality of
+  Android, Google has contributed full-time engineers, product managers, user interface designers,
+  quality assurance testers, and all the other roles required to bring modern devices to market.
 </p>
 
 <p>
@@ -40,9 +40,8 @@
 <p>
   The chart below depicts at a conceptual level how AOSP manages code and releases. We're
   referring to these as "code lines" instead of "branches" simply because at any given moment
-  there may be more than one branch extant for a given "code line". For instance, when a
-  release is cut, sometimes that will become a new branch in git, and sometimes not, based on
-  the needs of the moment.
+  there may be more than one branch for a given "code line". For instance, when a
+  release is cut, it may or may not become a new branch based on the needs of the moment.
 </p>
 <ol>
   <li>
@@ -60,14 +59,14 @@
   <li>
 	<p>
 	  In parallel, Google works internally on the next version of the Android platform and
-	  framework, working according to the product's needs and goals. We develop the next
+	  framework according to the product's needs and goals. We develop the next
 	  version of Android by working with a device partner on a flagship device whose
 	  specifications are chosen to push Android in the direction we believe it should go.
 	</p>
   </li>
   <li>
 	<p>
-	  When the "n+1"th version is ready, it will be published to the public source tree, and
+	  When the "n+1"th version is ready, it will be published to the public source tree and
 	  become the new latest release.
 	</p>
   </li>
@@ -76,38 +75,32 @@
   <img src="{@docRoot}images/code-lines.png" alt="code-line diagram">
 </p>
 
-<h2 id="notes-and-explanations">
-  Notes and Explanations
+<h2 id="terms-and-caveats">
+  Terms and Caveats
 </h2>
 <ul>
   <li>
 	<p>
 	  A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5,
-	  2.1, and so on. Generally speaking, a release of the platform corresponds to a version of
-	  the <code>SdkVersion</code> field used in AndroidManifest.xml files, and defined in
+	  2.1, and so on. Generally speaking, a release of the platform corresponds to the version in
+	  the <code>SdkVersion</code> field of AndroidManifest.xml files and defined within
 	  <code>frameworks/base/api</code> in the source tree.
 	</p>
   </li>
   <li>
 	<p>
 	  An <em>upstream</em> project is an open-source project from which the Android stack is
-	  pulling code. These include obvious projects such as the Linux kernel and WebKit, but
-	  over time we are migrating some of the semi-autonomous Android projects (such as Dalvik,
+	  pulling code. These include obvious projects such as the Linux kernel and WebKit.
+	  Over time we are migrating some of the semi-autonomous Android projects (such as Dalvik,
 	  the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally,
 	  these projects are developed entirely in the public tree. For some upstream projects,
-	  development is done by contributing directly to the upstream project itself. See <a href= 
+	  development is done by contributing directly to the upstream project itself. See <a href=
 	  "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases,
 	  snapshots will be periodically pulled into releases.
 	</p>
   </li>
   <li>
 	<p>
-	  The diagram refers to "Eclair" and "FroYo"; however, they are simply placeholders, and
-	  the diagram actually reflects the overall release and branching strategy.
-	</p>
-  </li>
-  <li>
-	<p>
 	  At all times, a release code-line (which may actually consist of more than one actual
 	  branch in git) is considered the sole canonical source code for a given Android platform
 	  version. OEMs and other groups building devices should pull only from a release branch.
@@ -115,14 +108,14 @@
   </li>
   <li>
 	<p>
-	  We will set up "experimental" code-lines to capture changes from the community, so that
-	  they can be iterated on, with an eye toward stability.
+	  "Experimental" code-lines are established to capture changes from the community so they can
+          be iterated on with an eye toward stability.
 	</p>
   </li>
   <li>
 	<p>
-	  Changes that prove stable will eventually be pulled into a release branch. Note that this
-	  will only apply to bug fixes, app improvements, and other things that do not affect the
+	  Changes that prove stable will eventually be pulled into a release branch. Note this
+	  applies only to bug fixes, application improvements, and other changes that do not affect the
 	  APIs of the platform.
 	</p>
   </li>
@@ -135,7 +128,8 @@
   <li>
 	<p>
 	  The "n+1"th version (that is, next major version of the framework and platform APIs) will
-	  be developed by Google internally. See below for details.
+	  be developed by Google internally. See <a href=
+          "#about-private-code-lines">About Private Codelines</a> for details.
 	</p>
   </li>
   <li>
@@ -169,23 +163,23 @@
 </p>
 <p>
   OEMs and other device builders naturally want to ship devices with the latest version of
-  Android. Similarly, application developers don't want to deal with more extant platform
+  Android. Similarly, application developers don't want to deal with more platform
   versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
-  direction of Android as a platform and a product. Our approach is based on focusing on a
-  small number of flagship devices to drive features, and secure protections of Android-related
-  intellectual property.
+  direction of Android as a platform and a product. Our approach focuses on a small number of
+  flagship devices to drive features while securing protections of Android-related intellectual
+  property. 
 </p>
 <p>
-  As a result, Google frequently has possession of confidential information of third parties,
-  and we must refrain from revealing sensitive features until we've secured the appropriate
-  protections. Meanwhile, there are real risks to the platform arising from having too many
+  As a result, Google frequently has possession of confidential information from third parties.
+  And we must refrain from revealing sensitive features until we've secured the appropriate
+  protections. In addition, there are real risks to the platform arising from having too many
   platform versions extant at once. For these reasons, we have structured the open-source
   project -- including third-party contributions -- to focus on the currently-public stable
   version of Android. "Deep development" on the next version of the platform will happen in
-  private, until it's ready to become an official release.
+  private until it's ready to become an official release.
 </p>
 <p>
-  We recognize that many contributors will disagree with this approach. We respect that others
-  may have a different point of view; however, this is the approach that we feel is best, and
+  We recognize many contributors will disagree with this approach. We respect others
+  may have a different point of view; however, this is the approach we feel is best, and
   the one we've chosen to implement.
 </p>
diff --git a/src/source/faqs.jd b/src/source/faqs.jd
index 7c1e5d4..60e02c2 100644
--- a/src/source/faqs.jd
+++ b/src/source/faqs.jd
@@ -31,54 +31,52 @@
 people, the processes, and the source code that make up Android.</p>
 <p>The people oversee the project and develop the actual source code. The
 processes refer to the tools and procedures we use to manage the development
-of the software. The net result is the source code that you can use to build
-cell phone and other devices.</p>
+of the software. The net result is the source code you can use to build
+mobile phones and other devices.</p>
 <h3 id="why-did-we-open-the-android-source-code">Why did we open the Android source code?</h3>
 <p>Google started the Android project in response to our own experiences
-launching mobile apps. We wanted to make sure that there would always be an
+launching mobile apps. We wanted to make sure there would always be an
 open platform available for carriers, OEMs, and developers to use to make
-their innovative ideas a reality. We also wanted to make sure that there was no
-central point of failure, so that no single industry player could restrict or control
+their innovative ideas a reality. We also wanted to make sure there was no
+central point of failure, so no single industry player could restrict or control
 the innovations of any other.  The single most important goal of the Android
-Open-Source Project (AOSP) is to make sure that the open-source Android
+Open Source Project (AOSP) is to make sure that the open-source Android
 software is implemented as widely and compatibly as possible, to everyone's
 benefit.</p>
-<p>You can find more information on this topic at our Project Philosophy page.</p>
 <h3 id="what-kind-of-open-source-project-is-android">What kind of open-source project is Android?</h3>
-<p>Google oversees the development of the core Android open-source platform,
-and works to create robust developer and user communities. For the most part
+<p>Google oversees the development of the core Android open-source platform
+and works to create robust developer and user communities. For the most part,
 the Android source code is licensed under the permissive Apache Software
 License 2.0, rather than a "copyleft" license. The main reason for this is
 because our most important goal is widespread adoption of the software, and
 we believe that the ASL2.0 license best achieves that goal.</p>
-<p>You can find more information on this topic at our Project Philosophy and
-Licensing pages. </p>
+<p>You can find more information on this topic on our <a href="{@docRoot}source/licenses.html">Licenses</a> page.</p>
 <h3 id="why-is-google-in-charge-of-android">Why is Google in charge of Android?</h3>
 <p>Launching a software platform is complex. Openness is vital to the
 long-term success of a platform, since openness is required to attract
 investment from developers and ensure a level playing field. However, the
-platform itself must also be a compelling product to end users.</p>
+platform itself must also be a compelling product to users.</p>
 <p>That's why Google has committed the professional engineering resources
 necessary to ensure that Android is a fully competitive software platform.
 Google treats the Android project as a full-scale product development
-operation, and strikes the business deals necessary to make sure that great
+operation and strikes the business deals necessary to make sure great
 devices running Android actually make it to market.</p>
-<p>By making sure that Android is a success with end users, we help ensure the
-vitality of Android as a platform, and as an open-source project. After all,
+<p>By making sure Android is a success with users, we help ensure the
+vitality of Android as a platform and as an open-source project. After all,
 who wants the source code to an unsuccessful product?</p>
-<p>Google's goal is to ensure a successful ecosystem around Android, but no
-one is required to participate, of course. We opened the Android source code
+<p>Google's goal is to ensure a successful ecosystem around Android. Of course, no
+one is required to participate. We opened the Android source code
 so anyone can modify and distribute the software to meet their own needs.</p>
 <h3 id="what-is-googles-overall-strategy-for-android-product-development">What is Google's overall strategy for Android product development?</h3>
-<p>We focus on releasing great devices into a competitive marketplace, and
+<p>We aim to release great devices into a competitive marketplace. We
 then incorporate the innovations and enhancements we made into the core
-platform, as the next version.</p>
-<p>In practice, this means that the Android engineering team typically focuses
-on a small number of "flagship" devices, and develops the next version of
+platform as the next version.</p>
+<p>In practice, this means the Android engineering team typically focuses
+on a small number of "flagship" devices and develops the next version of
 the Android software to support those product launches. These flagship
 devices absorb much of the product risk and blaze a trail for the broad OEM
 community, who follow up with many more devices that take advantage of the
-new features. In this way, we make sure that the Android platform evolves
+new features. In this way, we make sure the Android platform evolves
 according to the actual needs of real-world devices.</p>
 <h3 id="how-is-the-android-software-developed">How is the Android software developed?</h3>
 <p>Each platform version of Android (such as 1.5, 1.6, and so on) has a
@@ -93,60 +91,61 @@
 <p>Finally, Google works on the next version of the Android platform in tandem
 with developing a flagship device. This branch pulls in changes from the
 experimental and stable branches as appropriate.</p>
-<p>You can find more information on this topic at our <a href="{@docRoot}source/code-lines.html">Branches and Releases</a>.</p>
+<p>You can find more information on this topic at our <a href="{@docRoot}source/code-lines.html">Codelines,
+Branches and Releases</a> page.</p>
 <h3 id="why-are-parts-of-android-developed-in-private">Why are parts of Android developed in private?</h3>
-<p>It typically takes over a year to bring a device to market, but of course
+<p>It typically takes more than a year to bring a device to market. And, of course,
 device manufacturers want to ship the latest software they can. Developers,
-meanwhile, don't want to have to constantly track new versions of the
+meanwhile, don't want to constantly track new versions of the
 platform when writing apps. Both groups experience a tension between
-shipping products, and not wanting to fall behind.</p>
+shipping products and not wanting to fall behind.</p>
 <p>To address this, some parts of the next version of Android including the
 core platform APIs are developed in a private branch. These APIs constitute
 the next version of Android. Our aim is to focus attention on the current
-stable version of the Android source code, while we create the next version
-of the platform as driven by flagship Android devices. This allows developers
-and OEMs to focus on a single version without having to track unfinished
+stable version of the Android source code while we create the next version
+of the platform. This allows developers
+and OEMs to use a single version without tracking unfinished
 future work just to keep up. Other parts of the Android system that aren't
 related to application compatibility are developed in the open, however.
 It's our intention to move more of these parts to open development over
 time.</p>
 <h3 id="when-are-source-code-releases-made">When are source code releases made?</h3>
-<p>When they are ready. Some parts of Android are developed in the open,
+<p>When they are ready. Releasing the source code is a fairly complex process.
+Some parts of Android are developed in the open,
 so that source code is always available. Other parts are developed first in
 a private tree, and that source code is released when the next platform
 version is ready.</p>
 <p>In some releases, core platform APIs will be ready far enough in advance
-that we can push the source code out for an early look in advance of the
-device's release; however in others, this isn't possible. In all cases, we
+that we can push the source code out for an early look prior to the
+device's release; however in other releases, this isn't possible. In all cases, we
 release the platform source when we feel the version has stabilized enough,
-and when the development process permits. Releasing the source code is a
-fairly complex process.</p>
+and when the development process permits.</p>
 <h3 id="what-is-involved-in-releasing-the-source-code-for-a-new-android-version">What is involved in releasing the source code for a new Android version?</h3>
 <p>Releasing the source code for a new version of the Android platform is a
 significant process. First, the software gets built into a system image for
-a device, and put through various forms of certification, including
+a device and put through various forms of certification, including
 government regulatory certification for the regions the phones will be
 deployed. It also goes through operator testing. This is an important phase
 of the process, since it helps shake out a lot of software bugs.</p></p>
 <p>Once the release is approved by the regulators and operators, the
 manufacturer begins mass producing devices, and we turn to releasing the
 source code.</p>
-<p>Simultaneous to mass production the Google team kicks off several efforts
-to prepare the open source release. These efforts include final API changes
-and documentation (to reflect any changes that were made during
+<p>Simultaneous to mass production, the Google team kicks off several efforts
+to prepare the open source release. These efforts include making final API changes,
+updating documentation (to reflect any modifications that were made during
 qualification testing, for example), preparing an SDK for the new version,
 and launching the platform compatibility information.</p>
 <p>Also included is a final legal sign-off to release the code into open
 source. Just as open source contributors are required to sign a Contributors
-License Agreement attesting to their IP ownership of their contribution,
-Google too must verify that it is clear to make contributions.</p>
-<p>Starting at the time mass production begins, the software release process
-usually takes around a month, which often roughly places source code
-releases around the same time that the devices reach users.</p>
+License Agreement attesting to their intellectual property ownership of their
+contribution, Google too must verify it is clear to make contributions.</p>
+<p>From the time mass production begins, the software release process
+usually takes around a month. This often places source code releases
+around the same time the devices reach users.</p>
 <h3 id="how-does-the-aosp-relate-to-the-android-compatibility-program">How does the AOSP relate to the Android Compatibility Program?</h3>
-<p>The Android Open-Source Project maintains the Android software, and
+<p>The Android Open Source Project maintains the Android software, and
 develops new versions. Since it's open-source, this software can be used for
-any purpose, including to ship devices that are not compatible with other
+any purpose, including to develop devices that are not compatible with other
 devices based on the same source.</p>
 <p>The function of the Android Compatibility Program is to define a baseline
 implementation of Android that is compatible with third-party apps written
@@ -154,23 +153,25 @@
 Android ecosystem, including Google Play; devices that don't meet the
 compatibility requirements exist outside that ecosystem.</p>
 <p>In other words, the Android Compatibility Program is how we separate
-"Android compatible devices" from devices that merely run derivatives of the
+"Android-compatible devices" from devices that merely run derivatives of the
 source code. We welcome all uses of the Android source code, but only
-Android compatible devices -- as defined and tested by the Android
+Android-compatible devices -- as defined and tested by the Android
 Compatibility Program -- may participate in the Android ecosystem.</p>
 <h3 id="how-can-i-contribute-to-android">How can I contribute to Android?</h3>
 <p>There are a number of ways you can contribute to Android. You can report
 bugs, write apps for Android, or contribute source code to the Android
-Open-Source Project.</p>
-<p>There are some limits on the kinds of code contributions we are willing or
+Open Source Project.</p>
+<p>There are some limits to the kinds of code contributions we are willing or
 able to accept. For instance, someone might want to contribute an
 alternative application API, such as a full C++-based environment. We would
-decline that contribution, since Android is focused on applications that run
-in the Dalvik VM. Alternatively, we won't accept contributions such as GPL
+decline that contribution, since Android encourages applications to be run
+in the Dalvik VM. Similarly, we won't accept contributions such as GPL
 or LGPL libraries that are incompatible with our licensing goals.</p>
-<p>We encourage those interested in contributing source code to contact us via
-the AOSP Community page prior to beginning any work. You can find more
-information on this topic at the Getting Involved page.</p>
+<p>We encourage those interested in contributing source code to contact us
+via the channels listed on the <a href="{@docRoot}source/community/index.html">
+Android Community</a> page prior to beginning any work. You can find more
+information on this topic from the <a href="{@docRoot}source/contributing.html">
+Contributing</a> page.</p>
 <h3 id="how-do-i-become-an-android-committer">How do I become an Android committer?</h3>
 <p>The Android Open Source Project doesn't really have a notion of a
 "committer". All contributions -- including those authored by Google
@@ -181,40 +182,40 @@
 <p>Once submitted, changes need to be accepted by a designated Approver.
 Approvers are typically Google employees, but the same approvers are
 responsible for all submissions, regardless of origin.</p>
-<p>You can find more information on this topic at the <a href="source/submit-patches.html">Submitting Patches</a> page.</p>
+<p>You can find more information on this topic at the <a href="submit-patches.html">Submitting Patches</a> page.</p>
 <a href="#top">Back to top</a>  
 <h2 id="compatibility">Compatibility</h2>
 <h3 id="what-does-compatibility-mean">What does "compatibility" mean?</h3>
-<p>We define an "Android compatible" device as one that can run any
+<p>We define an "Android-compatible device" as one that can run any
 application written by third-party developers using the Android SDK and NDK.
 We use this as a filter to separate devices that can participate in the
-Android app ecosystem, and those that cannot. Devices that are properly
+Android app ecosystem and those that cannot. Devices that are properly
 compatible can seek approval to use the Android trademark. Devices that are
 not compatible are merely derived from the Android source code and may not
 use the Android trademark.</p>
 <p>In other words, compatibility is a prerequisite to participate in the
-Android apps ecosystem. Anyone is welcome to use the Android source code,
-but if the device isn't compatible, it's not considered part of the Android
+Android apps ecosystem. Anyone is welcome to use the Android source code.
+But if the device isn't compatible, it's not considered part of the Android
 ecosystem.</p>
 <h3 id="what-is-the-role-of-google-play-in-compatibility">What is the role of Google Play in compatibility?</h3>
 <p>Devices that are Android compatible may seek to license the Google Play
 client software. This allows them to become part of the Android app
-ecosystem, by allowing users to download developers' apps from a catalog
+ecosystem, enabling their users to download developers' apps from a catalog
 shared by all compatible devices. This option isn't available to devices
 that aren't compatible.</p>
 <h3 id="what-kinds-of-devices-can-be-android-compatible">What kinds of devices can be Android compatible?</h3>
-<p>The Android software can be ported to a lot of different kinds of devices,
-including some on which third-party apps won't run properly. The Android
-Compatibility Definition Document (CDD) spells out the specific device
-configurations that will be considered compatible.</p>
+<p>The Android software can be ported to many different kinds of devices,
+including some on which third-party apps won't run properly. The
+<a href="{@docRoot}compatibility/index.html">Android Compatibility Definition
+Document</a> (CDD) spells out the specific device configurations that will be
+considered compatible.</p>
 <p>For example, though the Android source code could be ported to run on a
-phone that doesn't have a camera, the CDD requires that in order to be
-compatible, all phones must have a camera. This allows developers to rely
-on a consistent set of capabilities when writing their apps.</p>
+phone that doesn't have a camera, the CDD requires all phones to have a camera.
+This allows developers to rely on a consistent set of capabilities when writing their apps.</p>
 <p>The CDD will evolve over time to reflect market realities. For instance,
-the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit
-telephony hardware, allowing for non-phone devices such as tablet-style
-music players to be compatible. As we make these changes, we will also
+version 1.6 of the CDD supports only cell phones. But the 2.1 CDD allows devices
+to omit telephony hardware, enabling non-phone devices such as tablet-style music
+players to be compatible. As we make these changes, we will also
 augment Google Play to allow developers to retain control over where
 their apps are available. To continue the telephony example, an app that
 manages SMS text messages would not be useful on a media player, so Google
@@ -223,26 +224,27 @@
 <h3 id="if-my-device-is-compatible-does-it-automatically-have-access-to-google-play-and-branding">If my device is compatible, does it automatically have access to Google Play and branding?</h3>
 <p>Google Play is a service operated by Google. Achieving compatibility is
 a prerequisite for obtaining access to the Google Play software and branding.
-Device manufacturers should contact Google to obtain access to Google
-Play.</p>
+Device manufacturers should contact <a
+href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>
+to obtain access to Google Play.</p>
 <h3 id="if-i-am-not-a-manufacturer-how-can-i-get-google-play">If I am not a manufacturer, how can I get Google Play?</h3>
 <p>Google Play is only licensed to handset manufacturers shipping devices.
-For questions about specific cases, contact android-partnerships@google.com.</p>
+For questions about specific cases, contact <a
+href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>.</p>
 <h3 id="how-can-i-get-access-to-the-google-apps-for-android-such-as-maps">How can I get access to the Google apps for Android, such as Maps?</h3>
-<p>The Google apps for Android, such as YouTube, Google Maps and Navigation,
-Gmail, and so on are Google properties that are not part of Android, and
-are licensed separately.  Contact android-partnerships@google.com for
-inquiries related to those apps.</p>
+<p>The Google apps for Android, such as YouTube, Google Maps,
+Gmail, and more, are Google properties that are not part of Android and
+are licensed separately.  Contact <a
+href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>
+for inquiries related to those apps.</p>
 <h3 id="is-compatibility-mandatory">Is compatibility mandatory?</h3>
 <p>No. The Android Compatibility Program is optional. Since the Android source
-code is open, anyone can use it to build any kind of device. However, if a
-manufacturer wishes to use the Android name with their product, or wants
-access to Google Play, they must first demonstrate that the device is
-compatible.</p>
+code is open, anyone can use it to build any kind of device. However, if manufacturers
+wish to use the Android name with their products, or want access to Google Play,
+they must first demonstrate their devices are compatible.</p>
 <h3 id="how-much-does-compatibility-certification-cost">How much does compatibility certification cost?</h3>
 <p>There is no cost to obtain Android compatibility for a device. The
-Compatibility Test Suite is open-source and available to anyone to use to
-test a device.</p>
+Compatibility Test Suite is open-source and available to anyone for device testing.</p>
 <h3 id="how-long-does-compatibility-take">How long does compatibility take?</h3>
 <p>The process is automated. The Compatibility Test Suite generates a report
 that can be provided to Google to verify compatibility. Eventually we intend
@@ -251,7 +253,7 @@
 <p>Since Google is responsible for the overall direction of Android as a
 platform and product, Google maintains the Compatibility Definition Document
 for each release. We draft the CDD for a new Android version in consultation
-with a number of OEMs, who provide input on its contents.</p>
+with various OEMs who provide input on its contents.</p>
 <h3 id="how-long-will-each-android-version-be-supported-for-new-devices">How long will each Android version be supported for new devices?</h3>
 <p>Since Android's code is open-source, we can't prevent someone from using an
 old version to launch a device. Instead, Google chooses not to license the
@@ -260,9 +262,9 @@
 but those devices won't use the Android name and will exist outside the
 Android apps ecosystem, just as if they were non-compatible.</p>
 <h3 id="can-a-device-have-a-different-user-interface-and-still-be-compatible">Can a device have a different user interface and still be compatible?</h3>
-<p>The Android Compatibility Program focuses on whether a device can run
+<p>The Android Compatibility Program determines whether a device can run
 third-party applications. The user interface components shipped with a
-device (such as home screen, dialer, color scheme, and so on) does not
+device (such as home screen, dialer, color scheme, and so on) do not
 generally have much effect on third-party apps. As such, device builders are
 free to customize the user interface as much as they like. The Compatibility
 Definition Document does restrict the degree to which OEMs may alter the
@@ -304,7 +306,7 @@
 <p>The CTS is licensed under the same Apache Software License 2.0 that the
 bulk of Android uses.</p>
 <h3 id="does-the-cts-accept-contributions">Does the CTS accept contributions?</h3>
-<p>Yes please! The Android Open-Source Project accepts contributions to
+<p>Yes please! The Android Open Source Project accepts contributions to
 improve the CTS in the same way as for any other component. In fact,
 improving the coverage and quality of the CTS test cases is one of the best
 ways to help out Android.</p>
@@ -323,16 +325,14 @@
 of the most secure mobile platforms available while still fulfilling our goal
 of opening the mobile device space to innovation and competition.</p>
 
-<p> A comprehensive overview  of the <a
-href="http://source.android.com/tech/security/index.html">Android
-security model and Android security processes</a> is provided in the Android
-Open Source Project Website.</p>
+<p>See the <a href="{@docRoot}devices/tech/security/index.html">Android Security
+Overview</a> for a comprehensive description of the Android security model and processes.</p>
 
 <p>Application developers play an important part in the security of Android.
 The Android Platform provides developers with a rich <a
-href="http://code.google.com/android/devel/security.html">security model</a>
-that to request the capabilities, or access, needed by their
-application and to define new capabilities that other applications can request.
+href="http://developer.android.com/training/articles/security-tips.html">security model</a>
+that allows them to request capabilities, or access, from users
+and define new capabilities other applications can request.
 The Android user can choose to grant or deny an application's request for
 certain capabilities on the handset.</p>
 
@@ -343,17 +343,16 @@
 </p>
 
 
-<h3 id="issue">I think I found a security flaw. How do I
-report it?</h3>
+<h3 id="issue">I think I found a security flaw. How do I report it?</h3>
 
 <p>You can reach the Android security team at <a
 href="mailto:security@android.com">security@android.com</a>. If you like, you
 can protect your message using our <a
-href="http://code.google.com/android/security_at_android_dot_com.txt">PGP
+href="http://developer.android.com/security_at_android_dot_com.txt">PGP
 key</a>.</p>
 
 <p>We appreciate researchers practicing responsible disclosure by emailing us
-with a detailed summary of the issue and keeping the issue confidential while
+a detailed summary of the issue and keeping the issue confidential while
 users are at risk. In return, we will make sure to keep the researcher informed
 of our progress in issuing a fix. </p>
 
@@ -368,16 +367,16 @@
 
 <h3 id="use">How do I securely use my Android phone?</h3>
 
-<p>Android was designed so that you can safely use your phone without making
+<p>Android was designed so you can safely use your phone without making
 any changes to the device or installing any special software.  Android applications
 run in an Application Sandbox that limits access to sensitive information or data
 with the users permission.</p>
 
 <p>To fully benefit from the security protections in Android, it is important that
-users only download and install software from known sources.</p>
+users download and install software only from known sources.</p>
 
 <p>As an open platform, Android allows users to visit any website and load
-software from any developer onto a device. As with a home PC, the user must be
+software from any developer onto a device. As with a home PC, users must be
 aware of who is providing the software they are downloading and must decide
 whether they want to grant the application the capabilities it requests.
 This decision can be informed by the user's judgment of the software
@@ -396,22 +395,22 @@
 being distributed from and why you suspect it of being malicious software.</p>
 
 <p>The term <i>malicious software</i> is subjective, and we cannot make an
-exhaustive definition.  Some examples of what the Android Security Team believes
+exhaustive definition.  Some examples of what the Android security team believes
 to be malicious software is any application that:
 <ul>
     <li>uses a bug or security vulnerability to gain permissions that have not
-    been granted by the user</li>
+    been granted by the user.</li>
     <li>shows the user unsolicited messages (especially messages urging the
-    user to buy something);</li>
-    <li>resists (or attempts to resist) the user's effort to uninstall it;</li>
-    <li>attempts to automatically spread itself to other devices;</li>
-    <li>hides its files and/or processes;</li>
+    user to buy something).</li>
+    <li>resists (or attempts to resist) the user's effort to uninstall it.</li>
+    <li>attempts to automatically spread itself to other devices.</li>
+    <li>hides its files and/or processes.</li>
     <li>discloses the user's private information to a third party, without the
-    user's knowledge and consent;</li>
+    user's knowledge and consent.</li>
     <li>destroys the user's data (or the device itself) without the user's
-    knowledge and consent;</li>
+    knowledge and consent.</li>
     <li>impersonates the user (such as by sending email or buying things from a
-    web store) without the user's knowledge and consent; or</li>
+    web store) without the user's knowledge and consent.</li>
     <li>otherwise degrades the user's experience with the device.</li>
 </ul>
 </p>
@@ -421,12 +420,12 @@
 
 <p>The manufacturer of each device is responsible for distributing software
 upgrades for it, including security fixes. Many devices will update themselves
-automatically with software downloaded "over the air", while some devices
+automatically with software downloaded "over the air" (OTA), while some devices
 require the user to upgrade them manually.</p>
 
 <p>Google provides software updates for a number of Android devices, including
 the <a href="http://www.google.com/nexus">Nexus</a>
-series of devices, using an "over the air" (OTA) update. These updates may include
+series of devices, using an OTA update. These updates may include
 security fixes as well as new features.</p>
 
 <h3 id="directfix">Can I get a fix directly from the
diff --git a/src/source/index.jd b/src/source/index.jd
index e39c611..46d5431 100644
--- a/src/source/index.jd
+++ b/src/source/index.jd
@@ -18,15 +18,15 @@
 -->
 <p>
 Android is an open-source software stack created for a wide array of devices
-with different form factors. The primary purpose of Android is to create an
+with different form factors. The primary purposes of Android are to create an
 open software platform available for carriers, OEMs, and developers to make
-their innovative ideas a reality and to create a successful,
-real-world product that improves the mobile experience for end users.
+their innovative ideas a reality and to introduce a successful,
+real-world product that improves the mobile experience for users.
 
-We also wanted to make sure that there was
+We also wanted to make sure there was
 no central point of failure, where one industry player could restrict or
 control the innovations of any other. The result is a full, production-quality
-consumer product whose source is open for customization and porting.
+consumer product with source code open for customization and porting.
 </p>
 
 
@@ -35,13 +35,14 @@
 <h2 id="governance-philosophy">Governance Philosophy</h2
 <p>Android was originated by a group of companies known as the Open
 Handset Alliance, led by Google. Today, many companies -- both original members
-of the OHA and others -- have invested heavily in Android, typically in the form
-of allocating significant engineering resources to improve Android and bring Android devices to market.
+of the OHA and others -- have invested heavily in Android. These companies have
+allocated significant engineering resources to improve Android and bring Android
+devices to market.
 </p>
-<p>The companies that have invested in Android have done so on its merits,
-because we believe that an open platform is necessary. Android is
-intentionally and explicitly an open-source -- as opposed to free software --
-effort: a group of organizations with shared needs has pooled
+<p>The companies that have invested in Android have done so on its merits
+because we believe an open platform is necessary. Android is
+intentionally and explicitly an open-source -- as opposed to a free software --
+effort; a group of organizations with shared needs has pooled
 resources to collaborate on a single implementation of a shared product.
 The Android philosophy is pragmatic, first and foremost. The objective is
 a shared product that each contributor can tailor and customize.</p>
@@ -49,10 +50,10 @@
 <p>Uncontrolled customization can, of course, lead to incompatible
 implementations. To prevent this, the Android Open Source Project also maintains the <a href="{@docRoot}compatibility/index.html">Android
 Compatibility Program</a>, which spells out what it means to be "Android
-compatible", and what is required of device builders to achieve that status.
+compatible" and what is required of device builders to achieve that status.
 Anyone can (and will!) use the Android source code for any purpose, and we
-welcome all such uses. However, in order to take part in the shared
-ecosystem of applications that we are building around Android, device builders
+welcome all legitimate uses. However, in order to take part in the shared
+ecosystem of applications we are building around Android, device builders
 must participate in the Android Compatibility Program.</p>
 
 <p>The Android Open Source Project is led by Google, who
@@ -62,4 +63,4 @@
 holistic software product, not a "distribution", specification, or collection
 of replaceable parts. Our intent is that device builders port
 Android to a device; they don't implement a specification or curate a
-distribution.</p>
\ No newline at end of file
+distribution.</p>
diff --git a/src/source/licenses.jd b/src/source/licenses.jd
index 7db245c..6287cda 100644
--- a/src/source/licenses.jd
+++ b/src/source/licenses.jd
@@ -24,14 +24,16 @@
   </div>
 </div>
 
-<p>The Android Open Source Project uses a few <a href="http://www.opensource.org/">open source initiative</a> 
+<p>The Android Open Source Project uses a few 
+<a href="http://www.opensource.org/">open source initiative</a>
 approved open source licenses for our software.</p>
-<h2 id="android-open-source-project-license">Android Open Source Project license</h2>
-<p>The preferred license for the Android Open Source Project is the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 
-Software License, 2.0</a> ("Apache 2.0"), 
+<h2 id="android-open-source-project-license">Android Open Source Project License</h2>
+<p>The preferred license for the Android Open Source Project is the
+<a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
+Software License, Version 2.0</a> ("Apache 2.0"),
 and the majority of the Android software is licensed
 with Apache 2.0. While the project will strive to adhere to the preferred
-license, there may be exceptions which will be handled on a case-by-case
+license, there may be exceptions that will be handled on a case-by-case
 basis. For example, the Linux kernel patches are under the GPLv2 license with
 system exceptions, which can be found on <a href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a>.</p>
 <h2 id="contributor-license-grants">Contributor License Grants</h2>
@@ -47,28 +49,28 @@
 other purpose.</p>
 <p>For a <em>corporation</em> (or other entity) that has assigned employees to
 work on the Android Open Source Project, a <a href="cla-corporate.pdf">Corporate
-Contributor License Grant</a> is available. 
+Contributor License Grant</a> is available.
 This version of the grant allows a
 corporation to authorize contributions submitted by its designated employees
 and to grant copyright and patent licenses. Note that a Corporate Contributor
 License Grant does not remove the need for any developer to sign their own
-Individual Contributor License Grant as an individual, to cover any of their
-contributions which are <em>not</em> owned by the corporation signing the
+Individual Contributor License Grant as an individual. The individual grant is needed
+to cover any of their contributions that are <em>not</em> owned by the corporation signing the
 Corporate Contributor License Grant.</p>
-<p>Please note that we based our grants on the ones that the 
+<p>Please note we based our grants on the ones the
 <a href="http://www.apache.org">Apache Software Foundation</a> uses, which can
-be found on <a href="http://www.apache.org/licenses/">the Apache web site</a>.</p>
+be found on the <a href="http://www.apache.org/licenses/">Apache web site</a>.</p>
 <h2 id="why-apache-software-license">Why Apache Software License?</h2>
 <p>We are sometimes asked why Apache Software License 2.0 is the preferred
 license for Android. For userspace (that is, non-kernel) software, we do in
 fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
 licenses such as LGPL.</p>
 <p>Android is about freedom and choice. The purpose of Android is promote
-openness in the mobile world, but we don't believe it's possible to predict or
+openness in the mobile world, and we don't believe it's possible to predict or
 dictate all the uses to which people will want to put our software. So, while
 we encourage everyone to make devices that are open and modifiable, we don't
 believe it is our place to force them to do so. Using LGPL libraries would
-often force them to do so.</p>
+often force them to do just that.</p>
 <p>Here are some of our specific concerns:</p>
 <ul>
 <li>
@@ -83,8 +85,8 @@
 <li>
 <p>LGPL requires allowance of customer modification and reverse
 engineering for debugging those modifications.  Most device makers do
-not want to have to be bound by these terms, so to minimize the burden on
-these companies we minimize usage of LGPL software in userspace.</li></p>
+not want to have to be bound by these terms. So to minimize the burden on
+these companies, we minimize usage of LGPL software in userspace.</li></p>
 </li>
 <li>
 <p>Historically, LGPL libraries have been the source of a large number
@@ -97,8 +99,8 @@
 </li>
 </ul>
 <p>The issues discussed above are our reasons for preferring ASL2.0 for
-our own code. They aren't criticisms of LGPL or other licenses. We do
-feel strongly on this topic, even to the point where we've gone out of our
-way to make sure as much code as possible is ASL2.0. However, we love all free
+our own code. They aren't criticisms of LGPL or other licenses. We are
+passionate about this topic, even to the point where we've gone out of our
+way to make sure as much code as possible is ASL2.0 licensed. However, we love all free
 and open source licenses, and respect others' opinions and preferences. We've
-simply decided that ASL2.0 is the right license for our goals.</p>
\ No newline at end of file
+simply decided ASL2.0 is the right license for our goals.</p>
diff --git a/src/source/life-of-a-bug.jd b/src/source/life-of-a-bug.jd
index 6f3b2c3..21995d5 100644
--- a/src/source/life-of-a-bug.jd
+++ b/src/source/life-of-a-bug.jd
@@ -23,26 +23,35 @@
     </ol>
   </div>
 </div>
-<p>The Android Open Source project maintains a public issue tracker where you
-can report bugs and request features for the Android software stack. (For
-details on this issue tracker, please see the <a href="report-bugs.html">Reporting Bugs</a> page).
+<p>The Android Open Source Project maintains a public issue tracker where you
+can report bugs and request features for the core Android software stack.
+(For details on this issue tracker, please see the
+<a href="report-bugs.html">Reporting Bugs</a> page).
 Reporting bugs is great (thank you!), but what happens to a bug report once
 you file it? This page describes the Life of a Bug.</p>
+
 <p>*Please note: the Android Open Source Project (AOSP) issue tracker is
-intended only for bugs and feature requests related to the Android software
-stack. Because many users find their way here looking for the Google apps for
-Android (such as Gmail and so on), we have components set up for their
-convenience. However, these apps are not part of Android, and any issues
-reported on these components are not guaranteed to to receive attention.
-Most notably, to report issues related to Google Play, you should visit the
-<a href="https://support.google.com/googleplay/">Google Play Support Forum</a>.</p>
+intended only for bugs and feature requests related to the core Android
+software stack, and is a technical tool for the Open Source community.</p>
+
+<p>This is not a customer support forum.
+You can find support for Nexus devices on
+<a href="http://support.google.com/nexus">Google's Nexus support site</a>.
+Support for other devices is provided by the device manufacturers or by the
+carriers selling those devices.</p>
+
+<p>Support for Google applications is through
+<a href="http://support.google.com/">Google's support site</a>. Support
+for 3rd-party applications is with each application's developer, e.g.
+through the contact information provided on Google Play.</p>
+
 <p>Here's the life of a bug, in a nutshell:</p>
 <ol>
 <li>
 <p>A bug is filed, and has the state "New".</p>
 </li>
 <li>
-<p>An AOSP contributor periodically reviews and triages bugs. Bugs are
+<p>An AOSP maintainer periodically reviews and triages bugs. Bugs are
 triaged into one of four "buckets": New, Open, No-Action, or Resolved.</p>
 </li>
 <li>
@@ -63,7 +72,7 @@
 <ul>
 <li>
 <p><em>New:</em>
-    The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)</p>
+    The bug report has not yet been triaged (that is, reviewed by an AOSP maintainer.)</p>
 </li>
 <li>
 <p><em>NeedsInfo:</em>
@@ -82,18 +91,7 @@
 <p><em>Unassigned:</em>
     The bug report has been recognized as an adequately
 detailed report of a legitimate issue, but has not yet been assigned to an
-AOSP contributor to be fixed. Typically, bugs in this state are considered low
-priority, at least insofar that if they were high priority, they'd be assigned
-to a contributor.</p>
-</li>
-<li>
-<p><em>Reviewed:</em>
-    Like <em>Unassigned</em>, but the issue
-represented is being tracked in a separate bug database. For example, the bug
-might have been reported via an internal bug-tracking system,
-which is considered the "master" copy. (For instance, Google maintains one
-such private issue tracker, intended primarily for bugs which contain
-sensitive information which can't be revealed publicly.)</p>
+AOSP contributor to be fixed.</p>
 </li>
 <li>
 <p><em>Assigned:</em>
@@ -102,14 +100,15 @@
 </li>
 </ul>
 <p>Typically, a given bug will start in <em>Unassigned</em>, where it
-will remain until it is associated with a specific upcoming release, at which
-point it will enter <em>Reviewed</em> or <em>Assigned</em>. However,
+will remain until someone intends to resolve it, at which
+point it will enter <em>Assigned</em>. However,
 note that this isn't a guarantee, and it's not uncommon for bugs to go from
 <em>Unassigned</em> to one of the Resolved states.</p>
 <p>In general, if a bug is in one of these Open states, the AOSP team has
-recognized it as a legitimate issue and will fix it according to the product
-priorities and milestones. However, it's impossible to guarantee a fix in time 
-for any particular release.</p>
+recognized it as a legitimate issue, and a high-quality contribution fixing
+that bug is likely to get accepted. However, it's impossible to guarantee a
+fix in time for any particular release.</p>
+
 <h2 id="no-action-issues">No-Action Issues</h2>
 <p>This bucket contains bugs that have for one reason or another been
 determined to not require any action.</p>
@@ -120,10 +119,9 @@
 regrettably, do not want.</p>
 </li>
 <li>
-<p><em>Question:</em>
-    Someone mistook the issue tracker for a help forum.
-(This is not as uncommon as you might think: many users whose native language
-isn't English misunderstand the site and make this mistake.)</p>
+<p><em>Duplicate:</em>
+    There was already an identical report in the issue tracker. Any actual
+action will be reported on that report.</p>
 </li>
 <li>
 <p><em>Unreproducible:</em>
@@ -133,40 +131,58 @@
 that the bug was fixed in a later release.</p>
 </li>
 <li>
+<p><em>Obsolete:</em>
+    Similar to <em>Unreproducible,</em> but with a reasonable certainty
+that the bug did exist in the reported version but was already fixed in
+a later release.</p>
+</li>
+<li>
 <p><em>WorkingAsIntended:</em>
-    An AOSP contributor has determined that the
+    An AOSP maintainer has determined that the
 behavior described isn't a bug, but is the intended behavior. This state is
 also commonly referred to as "WAI".</p>
 </li>
 <li>
 <p><em>Declined:</em>
     This is like <em>WorkingAsIntended</em>, except
-typically used for feature requests instead of bugs.  That is, an AOSP
-contributor has determined that the request is not going to be implemented in
+typically used for feature requests instead of bugs. That is, an AOSP
+maintainer has determined that the request is not going to be implemented in
 Android.</p>
 </li>
+<li>
+<p><em>NotEnoughInformation:</em>
+    The report didn't have enough information to be able to take any action.</p>
+</li>
+<li>
+<p><em>UserError:</em>
+    The report was the result of a user making a mistake while using Android,
+e.g. typing a wrong password and therefore not being able to connect to a
+server.</p>
+</li>
+<li>
+<p><em>WrongForum:</em>
+    The report cannot be handled in AOSP, typically because it is related
+to a customized device or to an external application.</p>
+</li>
+<li>
+<p><em>Question:</em>
+    Someone mistook the issue tracker for a help forum.</p>
+</li>
 </ul>
 <h2 id="resolved-issues">Resolved Issues</h2>
 <p>This bucket contains bugs that have had action taken, and are now
 considered resolved.</p>
 <ul>
 <li>
-<p><em>FutureRelease:</em>
-    This bug has been fixed (or feature implemented) in
-a source tree, but has not yet been included in a formal Android
-platform release. (Note that this may also include fixes that exist in a
-private source tree that has not yet been contributed to a public
-tree.)</p>
-</li>
-<li>
 <p><em>Released:</em>
-    This bug has been fixed, and is included in a formal
-Android platform release. When this state is set, we try to also set a
+    This bug has been fixed, and is included in a formal release.
+When this state is set, we try to also set a
 property indicating which release it was fixed in.</p>
 </li>
 <li>
-<p><em>Duplicate:</em>
-    This bug is a duplicate of another, existing bug report.</p>
+<p><em>FutureRelease:</em>
+    This bug has been fixed (or feature implemented) in
+a source tree, but has not yet been included in a formal release.</p>
 </li>
 </ul>
 <h1 id="other-stuff">Other Stuff</h1>
@@ -176,14 +192,3 @@
 states in a formal progression. We do try to keep the system up to date, but
 we tend to do so in periodic "bug sweeps" where we review the database and
 make updates.</p>
-<p>Since the AOSP is essentially constantly evolving, we do make tweaks to
-the list of bug states and the lifecycle described above.  When we do this,
-however, we'll be sure to update this page as well.</p>
-<p>Finally, you should be aware that for a variety of reasons, there are
-actually multiple issue trackers for Android-related issues. The 
-<a href="https://code.google.com/p/android/issues/list">Google Code Project Hosting Issue Tracker</a>
-is the <em>only</em> official public issue tracker; however,
-Google also maintains a private issue tracker, own, as do most OEMs. We try to
-keep the public issue tracker in sync with private issue trackers
-wherever possible, but in cases where confidential information and security
-issues are involved, this isn't always possible.</p>
\ No newline at end of file
diff --git a/src/source/report-bugs.jd b/src/source/report-bugs.jd
index 9b85b08..0a0ffbb 100644
--- a/src/source/report-bugs.jd
+++ b/src/source/report-bugs.jd
@@ -35,7 +35,11 @@
 <p>Here's how to report non-security bugs:</p>
 <ul>
 <li>
-<p><a href="https://code.google.com/p/android/issues/advsearch">Search for your bug</a> to see if anyone has already reported it.</p>
+<p><a href="https://code.google.com/p/android/issues/advsearch">Search for
+your bug</a> to see if anyone has already reported it. Don't forget to
+search for all issues, not just open ones, as your issue might already
+have been reported and closed. To help find the most popular results,
+sort the result by number of stars.</p>
 </li>
 <li>
 <p>If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.</p>
@@ -55,6 +59,15 @@
 </ul>
 </li>
 </ul>
+<p>Keep in mind that an issue tracker is not a user support forum. It is a list
+of pending technical tasks, along with information relevant for those tasks,
+and information about progress on those tasks including which ones might
+get worked on in the short term.</p>
+<p>This issue tracker is narrowly focused on the Android Open Source Project.
+Issues with retail devices need to be reported through those devices' support
+channels, especially for devices other than Nexus. Issues with applications
+that aren't part of AOSP need to be reported with those applications'
+developers; that is also the case for Google applications.</p>
 <p>Please note that we can't guarantee that any particular bug can be fixed in
 any particular release. To see what happens to your bug once you report it,
 read <a href="life-of-a-bug.html">Life of a Bug</a>.</p>
@@ -149,4 +162,4 @@
         at
 org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
         at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
-</pre>
\ No newline at end of file
+</pre>
diff --git a/src/source/roles.jd b/src/source/roles.jd
index 7f2258b..44eeae4 100644
--- a/src/source/roles.jd
+++ b/src/source/roles.jd
@@ -33,46 +33,46 @@
 questions, contribute patches, report bugs, look at submitted patches, and use
 the tools. To get started with the Android code, see <a href="{@docRoot}source/contributing.html">Contributing</a>.</p>
 <h2 id="contributor">Contributor</h2>
-<p>A "Contributor" is anyone making contributions to the AOSP source code,
-including both employees of Google or other companies, as well as external
-developers who are contributing to Android on their own behalf.  There is no
-distinction between Contributors who are employed by Google, and those who are
-not: all engineers use the same tools (git, repo, and gerrit), 
+<p>"Contributors" are those making contributions to the AOSP source code,
+including both employees of Google or other companies, as well as individual
+developers who are contributing to Android on their own behalf. There is no
+distinction between contributors who are employed by Google and those who are
+not; all engineers use the same tools (git, repo, and gerrit),
 follow the same code review process, and are subject
 to the same requirements on code style and so on.</p>
 <h2 id="developer">Developer</h2>
-<p>A "Developer" is an engineer writing applications that run on Android
-devices. There is, of course, no difference in skillset between a "Developer"
-and a "Contributor", but AOSP uses "Developer" to distinguish between
-engineers using the platform and those contributing to it. Developers are
-(along with end users) the "customers" of the platform that the Contributors
-create. As such, we talk about Developers a lot, though this isn't technically
+<p>"Developers" are engineers writing applications that run on Android
+devices. There is often little difference in skillset between a developer
+and a contributor. But AOSP uses "developer" to distinguish between
+engineers using the platform and those contributing to it. Developers
+(along with users) are the "customers" of the platform the contributors
+create. As such, we talk about developers a lot, though this isn't technically
 a separate role in the AOSP per se.</p>
 <h2 id="verifier">Verifier</h2>
 <p>"Verifiers" are responsible for testing change requests. After individuals
 have submitted a significant amount of high-quality code to the project, the
-Project Leads might invite them to become Verifiers. <em>Note: at this
-time, generally Verifiers are the same as Approvers.</em></p>
+project leads might invite them to become verifiers. <em>Note: at this
+time, verifiers act similarly to approvers.</em></p>
 <h2 id="approver">Approver</h2>
 <p>"Approvers" are experienced members of the project who have demonstrated their
 design skills and have made significant technical contributions to the
-project. In the code-review process, an Approver decides whether to include or
-exclude a change. Project Leads (who are typically employed by Google) choose
-the Approvers, sometimes promoting to this position Verifiers who have
+project. In the code-review process, an approver decides whether to include or
+exclude a change. Project leads (who are typically employed by Google) choose
+the approvers, sometimes promoting to this position verifiers who have
 demonstrated their expertise within a specific project.</p>
-<h2 id="project-leads">Project Leads</h2>
+<h2 id="project-leads">Project Lead</h2>
 <p>Android consists of a number of sub-projects; you can see these in the git
-repository, as individual .git files. Tech Leads are senior Contributors who
-oversee the engineering for individual Android projects. Typically these tech
-leads will be Google employees.  A Project Lead for an individual project is
+repository as individual .git files. "Project leads" are senior contributors who
+oversee the engineering for individual Android projects. Typically these project
+leads are Google employees. A project lead for an individual project is
 responsible for the following:</p>
 <ul>
 <li>
-<p>Lead all technical aspects of the project; for example, the project roadmap, 
-  development, release cycles, versioning, and QA.</p>
+<p>Lead all technical aspects of the project, including the project roadmap,
+  development, release cycles, versioning, and quality assurance (QA).</p>
 </li>
 <li>
-<p>Ensure that the project is QA-ed in time for scheduled Android platform
+<p>Ensure the project is tested by QA in time for scheduled Android platform
   releases.</p>
 </li>
 <li>