s.a.c. redesign, first checkin
Change-Id: I4dead2f18bc5e4a38f204c92198a267c286e775d
diff --git a/src/compatibility/2.1/versions.jd b/src/compatibility/2.1/versions.jd
new file mode 100644
index 0000000..cbc12ef
--- /dev/null
+++ b/src/compatibility/2.1/versions.jd
@@ -0,0 +1,22 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.1-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 2.1 are:</p>
+<ul>
+<li>
+<p>2.1</p>
+</li>
+<li>
+<p>2.1-update1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/2.1/versions.md b/src/compatibility/2.1/versions.md
deleted file mode 100644
index 143b4a7..0000000
--- a/src/compatibility/2.1/versions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- 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.
--->
-
-# Permitted Version Strings for Android 2.1 #
-
-As described in Section 3.2.2 of the [Android 2.1 Compatibility Definition](/cdds/android-2.1-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.1-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.1 are:
-
-- 2.1
-
-- 2.1-update1
-
diff --git a/src/compatibility/2.2/versions.jd b/src/compatibility/2.2/versions.jd
new file mode 100644
index 0000000..5846316
--- /dev/null
+++ b/src/compatibility/2.2/versions.jd
@@ -0,0 +1,22 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.2-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 2.2 are:</p>
+<ul>
+<li>
+<p>2.2</p>
+</li>
+<li>
+<p>2.2.1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/2.2/versions.md b/src/compatibility/2.2/versions.md
deleted file mode 100644
index 571760a..0000000
--- a/src/compatibility/2.2/versions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- 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.
--->
-
-# Permitted Version Strings for Android 2.2 #
-
-As described in Section 3.2.2 of the [Android 2.2 Compatibility Definition](/cdds/android-2.2-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.2-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.2 are:
-
-- 2.2
-
-- 2.2.1
-
diff --git a/src/compatibility/2.3/versions.jd b/src/compatibility/2.3/versions.jd
new file mode 100644
index 0000000..a3b5481
--- /dev/null
+++ b/src/compatibility/2.3/versions.jd
@@ -0,0 +1,17 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.3-based system. The only permitted values for
+<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
diff --git a/src/compatibility/2.3/versions.md b/src/compatibility/2.3/versions.md
deleted file mode 100644
index 5cb3e68..0000000
--- a/src/compatibility/2.3/versions.md
+++ /dev/null
@@ -1,32 +0,0 @@
-<!--
- 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.
--->
-
-# Permitted Version Strings for Android 2.3 #
-
-As described in Section 3.2.2 of the [Android 2.3 Compatibility Definition](/cdds/android-2.3-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.3-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.3 are:
-
-- 2.3.3
diff --git a/src/compatibility/4.0/versions.jd b/src/compatibility/4.0/versions.jd
new file mode 100644
index 0000000..12039ba
--- /dev/null
+++ b/src/compatibility/4.0/versions.jd
@@ -0,0 +1,28 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.0-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.0 are:</p>
+<ul>
+<li>
+<p>4.0</p>
+</li>
+<li>
+<p>4.0.1</p>
+</li>
+<li>
+<p>4.0.3</p>
+</li>
+<li>
+<p>4.0.4</p>
+</li>
+</ul>
diff --git a/src/compatibility/4.0/versions.md b/src/compatibility/4.0/versions.md
deleted file mode 100644
index 895b820..0000000
--- a/src/compatibility/4.0/versions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-<!--
- 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.
--->
-
-# Permitted Version Strings for Android 4.0 #
-
-As described in Section 3.2.2 of the [Android 4.0 Compatibility Definition](/cdds/android-4.0-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 4.0-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 4.0 are:
-
-- 4.0
-
-- 4.0.1
-
-- 4.0.3
-
-- 4.0.4
diff --git a/src/compatibility/4.1/android-4.1-cdd.pdf b/src/compatibility/4.1/android-4.1-cdd.pdf
index 4e54ccf..46b6482 100644
--- a/src/compatibility/4.1/android-4.1-cdd.pdf
+++ b/src/compatibility/4.1/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.1/versions.jd b/src/compatibility/4.1/versions.jd
new file mode 100644
index 0000000..9a3106c
--- /dev/null
+++ b/src/compatibility/4.1/versions.jd
@@ -0,0 +1,22 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.1-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.1 are:</p>
+<ul>
+<li>
+<p>4.1</p>
+</li>
+<li>
+<p>4.1.1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/4.1/versions.md b/src/compatibility/4.1/versions.md
deleted file mode 100644
index 9b04064..0000000
--- a/src/compatibility/4.1/versions.md
+++ /dev/null
@@ -1,34 +0,0 @@
-<!--
- 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.
--->
-
-# Permitted Version Strings for Android 4.1 #
-
-As described in Section 3.2.2 of the [Android 4.1 Compatibility Definition](/cdds/android-4.1-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 4.1-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 4.1 are:
-
-- 4.1
-
-- 4.1.1
diff --git a/src/compatibility/4.2/android-4.2-cdd.pdf b/src/compatibility/4.2/android-4.2-cdd.pdf
new file mode 100755
index 0000000..10addf3
--- /dev/null
+++ b/src/compatibility/4.2/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.2/versions.jd b/src/compatibility/4.2/versions.jd
new file mode 100644
index 0000000..065085b
--- /dev/null
+++ b/src/compatibility/4.2/versions.jd
@@ -0,0 +1,17 @@
+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>,
+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
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.2-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.2 are:</p>
+<ul>
+<li>4.2</li>
+</ul>
diff --git a/src/compatibility/android-4.1-cdd.pdf b/src/compatibility/android-4.1-cdd.pdf
old mode 100644
new mode 100755
index 4e54ccf..46b6482
--- a/src/compatibility/android-4.1-cdd.pdf
+++ b/src/compatibility/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-4.2-cdd.pdf b/src/compatibility/android-4.2-cdd.pdf
new file mode 100755
index 0000000..10addf3
--- /dev/null
+++ b/src/compatibility/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-cts-manual-r5.pdf b/src/compatibility/android-cts-manual-r6.pdf
similarity index 82%
rename from src/compatibility/android-cts-manual-r5.pdf
rename to src/compatibility/android-cts-manual-r6.pdf
index 5f911dc..5f4173b 100644
--- a/src/compatibility/android-cts-manual-r5.pdf
+++ b/src/compatibility/android-cts-manual-r6.pdf
Binary files differ
diff --git a/src/compatibility/compatibility.jd b/src/compatibility/compatibility.jd
new file mode 100644
index 0000000..5d07a95
--- /dev/null
+++ b/src/compatibility/compatibility.jd
@@ -0,0 +1,203 @@
+page.title=Overview
+@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.
+-->
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>
+ In this document
+ </h2>
+ <ol>
+ <li><a href="#arch">Android Low-Level System Architecture</a></li>
+ <li><a href="#pdk">PDK Components</a></li>
+ <li><a href="#inc-ex">PDK Inclusions and Exclusions</a></li>
+ <li><a href="#knownissues">Support and Known Issues</a></li>
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android Platform Development Kit (PDK) Guide! The Android PDK allows partners to port
+ their drivers as well as develop, optimize, and test against an upcoming Android platform release.
+ The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL),
+ platform sources for integration, a binary system image, and HAL and integration documentation.
+ In addition, the PDK also ships with the Android Compatibility Test Suite (CTS).
+</p>
+
+<h2 id="arch">Android Low-Level 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 as well as the PDK.
+The following diagram shows a system level view of how Android works:
+</p>
+
+<img src="images/system-architecture.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.
+ 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).
+</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. The PDK
+ does not provide kernel sources, so you must provide your own. 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="http://source.android.com/source/building-kernels.html" >Building Kernels</a>.
+</p>
+
+
+<h2 id="pdk">PDK Components</h2>
+<p>Now that you have a high-level overview of the Android system, we'll go over the PDK and what it provides
+ to port Android to your product. The PDK provides source files needed to implement
+ your product and a platform binary that lets you build a runnable system image. You can then install
+ this barebones image to test your product with the latest builds of Android. The most important source files
+ included in the PDK are located in the:</p>
+
+ <ul>
+ <li><code>frameworks/native</code> directory</li>
+ <li><code>frameworks/av</code> directory for media, camera, DRM, and the audio framework stack</code></li>
+ <li><code>hardware/libhardware/include/hardware</code> directory for the HAL interfaces </li>
+ <li><code>vendor/pdk/data/cts</code> directory for the CTS binaries</li>
+ </ul>
+</p>
+<p>In addition, the Android PDK includes the following source directories:</p>
+<ul>
+ <li>abi</li>
+ <li>bionic</li>
+ <li>bootable</li>
+ <li>build</li>
+ <li>device</li>
+ <li>external (Chromium and Webkit are not included)</li>
+ <li>hardware</li>
+ <li>libnativehelper</li>
+ <li>pdk</li>
+ <li>prebuilt</li>
+ <li>prebuilts</li>
+ <li>system</li>
+</ul>
+
+ <p>The PDK also contains documentation that is split into three different sections:</p>
+ <ul>
+ <li><a href="{@docRoot}guide/getting_started.html">Getting Started</a> - Explains how to download the PDK source, how the Android build system works, and how to configure a build for your specific product.</li>
+ <li><a href="{@docRoot}guide/hal.html">The Hardware Abstraction Layer</a> - Explains the various HALs provided by Android and the interfaces (C header files) that define them. </li>
+ <li><a href="{@docRoot}guide/reference/files.html">HAL reference</a> - A quick reference for the various HAL interfaces.</li>
+ </ul>
+
+<h3 id="cts">Compatibility Test Suite</h3>
+<p>CTS binaries for ARM, MIPS, and x86 are provided in the corresponding directories in <code>vendor/pdk/data/cts</code>. Only the ARM
+ variant is Google-verified as there is no Nexus device running on any other architecture. Not all of the CTS tests since the
+ complete Android platform is not present. The following CTS tests should work:</p>
+
+<ul>
+ <li>android.bluetooth</li>
+ <li>android.graphics</li>
+ <li>android.graphics2</li>
+ <li>android.hardware</li>
+ <li>android.location</li>
+ <li>android.opengl</li>
+ <li>android.openglperf</li>
+ <li>android.media</li>
+ <li>android.mediastress</li>
+ <li>android.nativemedia.sl</li>
+ <li>android.nativemedia.xa</li>
+ <li>android.net</li>
+ <li>android.renderscript</li>
+ </ul>
+ <p>You can run individual packages such as <code>android.media</code> with:</p>
+ <pre>cts-tradefed run singleCommand cts --skip-device-info --package android.media</pre>
+</ul>
+
+ <p>Because the PDK is missing many components compared to a full Android source tree,
+ there is a PDK test plan that is provided with CTS that limits the tests that are ran when using the PDK. You can run
+ this special test plan with the following command:</p>
+
+ <pre>run cts --plan PDK</pre>
+
+<p>CTS is always actively under development, so we expect some tests to fail. CTS results
+ for the Galaxy Nexus are provided for you in the
+ the <code>vendor/pdk/data/cts/</code> directory and will show which tests fail on that
+ device. You can safely ignore the failed tests for your devices as well.</p>
+
+ <p>See the <a href="http://source.android.com/compatibility/cts-intro.html">CTS manual</a> for more information on CTS.</p>
+
+<h2 id="inc-ex">PDK Inclusions and Exclusions</h2>
+<p>The PDK is a subset of the complete Android source tree and might be missing things that you might need. Here is a list of what the PDK supports
+ and does not support:</p>
+<ul>
+ <li>Supports building Android apps using the publicly available, standard SDK. Builds with non-public platform APIs are not supported. The JNI build is supported.</li>
+ <li>Supports only <code>en_US</code> locale.</li>
+ <li>Supports only phone layouts. Tablet layouts are not included.</li>
+ <li>Enables support for software navigation buttons by default, which you can disable by setting <code>qemu.jw.mainkeys=1</code>.</li>
+ <li>Builds all binaries with SMP (symmetric multiprocessing) features enabled. This might have a small performance impact on non-SMP CPUs.</li>
+ <li>Includes a minimal amount of Java libraries. Obtain any additional Java libraries from the publicly released Android source tree.</li>
+ <li>Contains a minimum number of applications. Build and install necessary applications as needed.</li>
+ <li>Does not support media streaming.</li>
+ <li>Does not include non-Latin fonts. (set by <code>MINIMAL_FONT_FOOTPRINT</code> variable in <code>BoardConfig.mk</code>).
+ An app might crash if it requires such fonts. </li>
+ <li>Does not support replacing framework resources by using the overlay mechanism.
+ This means all configurations controlled by framework resources are fixed.</li>
+ <li>Does not support NFC</li>
+ <li>Does not support DRM</li>
+</ul>
+
+<h2 id="knownissues">Support and Known Issues</h2>
+<p>
+For questions or to report issues related with the PDK, send a message to the <a href="https://groups.google.com/a/google.com/forum/?fromgroups#!forum/android-pdk-feedback">android-pdk@google.com</a> mailing list.</p>
+
+<p>The following list describes the known issues with the PDK:</p>
+<ul>
+ <li>After running the CTS (Compatibility Test Suite), <code>android.process.acore</code> crashes. This is caused by
+some missing components in PDK and does not affect the operation of CTS tests.</li>
+</p>
diff --git a/src/compatibility/compatibility_toc.cs b/src/compatibility/compatibility_toc.cs
new file mode 100644
index 0000000..ed83355
--- /dev/null
+++ b/src/compatibility/compatibility_toc.cs
@@ -0,0 +1,37 @@
+<!--
+ 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.
+-->
+<?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+<!-- Compatibility -->
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>compatibility/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>compatibility/overview.html">CTS Overview</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/cts-intro.html">CTS Introduction</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/cts-development.html">CTS Development</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/android-4.2-cdd.pdf">Compatibility Definition Document (CDD)</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/downloads.html">Downloads</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/contact-us.html">Contact Us</a></li>
+ </ul>
+<!-- End Compatibility -->
+ </li>
+
+
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/contact-us.jd b/src/compatibility/contact-us.jd
new file mode 100644
index 0000000..3c9418c
--- /dev/null
+++ b/src/compatibility/contact-us.jd
@@ -0,0 +1,39 @@
+page.title=Contact Us
+@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.
+-->
+
+<p>Thanks for your interest in Android compatibility!</p>
+<p>If you have questions about Android compatibility that aren't covered in
+this site, you can reach us in one of a few different ways. To get the most
+out of any of these options, please first read "Getting the Most from Our
+Lists" on the <a href="index.html">Community page</a></p>
+<h2 id="for-general-discussion">For General Discussion</h2>
+<p>The preferred way to reach us is via the <a href="mailto:compatibility@android.com">compatibility@android.com</a> address.</p>
+<h2 id="for-cts-technical-questions">For CTS Technical Questions</h2>
+<p>If you have specific issues with the Compatibility Test Suite that require
+you to disclose information you'd prefer not to be public, you can contact an
+email address we've set up specifically this purpose: <a href="mailto:cts@android.com">cts@android.com</a>. This email address is for
+cases that require disclosure of confidential information only, so general
+questions will be directed back to the public android-compatibility
+list. Note also that this list is for specific technical questions; general
+inquiries will also be directed back to the <a href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility list.</a></p>
+<h2 id="for-business-inquiries">For Business Inquiries</h2>
+<p>Finally, business inquiries about the compatibility program, including
+requests to use branding elements and so on, can be sent to the address <a href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>. Like
+the CTS address, this address is for specific, private inquiries; general
+questions will be directed back to the android-compatibility list.</p>
diff --git a/src/compatibility/contact-us.md b/src/compatibility/contact-us.md
deleted file mode 100644
index 285ddca..0000000
--- a/src/compatibility/contact-us.md
+++ /dev/null
@@ -1,45 +0,0 @@
-<!--
- 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.
--->
-
-# Contact Us #
-
-Thanks for your interest in Android compatibility!
-
-If you have questions about Android compatibility that aren't covered in
-this site, you can reach us in one of a few different ways. To get the most
-out of any of these options, please first read "Getting the Most from Our
-Lists" on the [Community page](index.html)
-
-## For General Discussion ##
-
-The preferred way to reach us is via the [compatibility@android.com](mailto:compatibility@android.com) address.
-
-## For CTS Technical Questions ##
-
-If you have specific issues with the Compatibility Test Suite that require
-you to disclose information you'd prefer not to be public, you can contact an
-email address we've set up specifically this purpose: [cts@android.com](mailto:cts@android.com). This email address is for
-cases that require disclosure of confidential information only, so general
-questions will be directed back to the public android-compatibility
-list. Note also that this list is for specific technical questions; general
-inquiries will also be directed back to the [android-compatibility list.](https://groups.google.com/forum/?fromgroups#!forum/android-compatibility)
-
-## For Business Inquiries ##
-
-Finally, business inquiries about the compatibility program, including
-requests to use branding elements and so on, can be sent to the address [android-partnerships@google.com](mailto:android-partnerships@google.com). Like
-the CTS address, this address is for specific, private inquiries; general
-questions will be directed back to the android-compatibility list.
diff --git a/src/compatibility/cts-development.jd b/src/compatibility/cts-development.jd
new file mode 100644
index 0000000..bacbd9c
--- /dev/null
+++ b/src/compatibility/cts-development.jd
@@ -0,0 +1,109 @@
+page.title=CTS Development
+@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="initializing-your-repo-client">Initializing Your Repo Client</h2>
+<p>Follow the <a href="/source/downloading.html">instructions</a>
+to get and build the Android source code but specify <code>-b android-4.2_r1</code>
+when issuing the <code>repo init</code> command. This assures that your CTS
+changes will be included in the next CTS release and beyond.</p>
+<h2 id="setting-up-eclipse">Setting Up Eclipse</h2>
+<p>Follow the <a href="/source/using-eclipse.html">instructions</a>
+to setup Eclipse but execute the following command to generate the
+<code>.classpath</code> file rather than copying the one from the development
+project:</p>
+<pre><code>cd /path/to/android/root
+./cts/development/ide/eclipse/genclasspath.sh > .classpath
+chmod u+w .classpath
+</code></pre>
+<p>This <code>.classpath</code> file will contain both the Android framework
+packages and the CTS packages.</p>
+<h2 id="building-and-running-cts">Building and Running CTS</h2>
+<p>Execute the following commands to build CTS and start the interactive
+CTS console:</p>
+<pre><code>cd /path/to/android/root
+make cts
+cts-tradefed
+</code></pre>
+<p>At the cts-tf console, enter e.g.:</p>
+<pre><code>run cts --plan CTS
+</code></pre>
+<h2 id="writing-cts-tests">Writing CTS Tests</h2>
+<p>CTS tests use JUnit and the Android testing APIs. Review the
+<a href="https://developer.android.com/guide/topics/testing/testing_android.html">Testing and Instrumentation</a>
+tutorial while perusing the existing tests under the
+<code>cts/tests/tests</code> directory. You will see that CTS tests mostly follow the same
+conventions used in other Android tests.</p>
+<p>Since CTS runs across many production devices, the tests must follow
+these rules:</p>
+<ul>
+<li>Must take into account varying screen sizes, orientations, and keyboard layouts.</li>
+<li>Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.</li>
+<li>Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.</li>
+<li>Don't rely upon root privileges.</li>
+</ul>
+<h3 id="test-naming-and-location">Test Naming and Location</h3>
+<p>Most CTS test cases target a specific class in the Android API. These tests
+have Java package names with a <code>cts</code> suffix and class
+names with the <code>Test</code> suffix. Each test case consists of
+multiple tests, where each test usually exercises a particular API method of
+the API class being tested. These tests are arranged in a directory structure
+where tests are grouped into different categories like "widgets" and "views."</p>
+<p>For example, the CTS test for <code>android.widget.TextView</code> is
+<code>android.widget.cts.TextViewTest</code> found under the
+<code>cts/tests/tests/widget/src/android/widget/cts</code> directory with its
+Java package name as <code>android.widget.cts</code> and its class name as
+<code>TextViewTest</code>. The <code>TextViewTest</code> class has a test called <code>testSetText</code>
+that exercises the "setText" method and a test named "testSetSingleLine" that
+calls the <code>setSingleLine</code> method. Each of those tests have <code>@TestTargetNew</code>
+annotations indicating what they cover.</p>
+<p>Some CTS tests do not directly correspond to an API class but are placed in
+the most related package possible. For instance, the CTS test,
+<code>android.net.cts.ListeningPortsTest</code>, is in the <code>android.net.cts</code>, because it
+is network related even though there is no <code>android.net.ListeningPorts</code> class.
+You can also create a new test package if necessary. For example, there is an
+"android.security" test package for tests related to security. Thus, use your
+best judgement when adding new tests and refer to other tests as examples.</p>
+<p>Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew.
+These are no longer necessary so do not annotate new tests with these.</p>
+<h3 id="new-test-packages">New Test Packages</h3>
+<p>When adding new tests, there may not be an existing directory to place your
+test. In that case, refer to the example under <code>cts/tests/tests/example</code> and
+create a new directory. Furthermore, make sure to add your new package's
+module name from its <code>Android.mk</code> to <code>CTS_COVERAGE_TEST_CASE_LIST</code> in
+<code>cts/CtsTestCaseList.mk</code>. This Makefile is used by <code>build/core/tasks/cts.mk</code>
+to glue all the tests together to create the final CTS package.</p>
+<h3 id="test-stubs-and-utilities">Test Stubs and Utilities</h3>
+<p>Some tests use additional infrastructure like separate activities
+and various utilities to perform tests. These are located under the
+<code>cts/tests/src</code> directory. These stubs aren't separated into separate test
+APKs like the tests, so the <code>cts/tests/src</code> directory does not have additional
+top level directories like "widget" or "view." Follow the same principle of
+putting new classes into a package with a name that correlates to the purpose
+of your new class. For instance, a stub activity used for testing OpenGL like
+<code>GLSurfaceViewStubActivity</code> belongs in the <code>android.opengl.cts</code> package under
+the <code>cts/tests/src/android/opengl</code> directory.</p>
+<h2 id="other-tasks">Other Tasks</h2>
+<p>Besides adding new tests there are other ways to contribute to CTS:</p>
+<ul>
+<li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li>
+</ul>
+<h2 id="submitting-your-changes">Submitting Your Changes</h2>
+<p>Follow the <a href="/source/submit-patches.html">Android Contributors' Workflow</a>
+to contribute changes to CTS. A reviewer
+will be assigned to your change, and your change should be reviewed shortly!</p>
diff --git a/src/compatibility/cts-development.md b/src/compatibility/cts-development.md
deleted file mode 100644
index 6cee879..0000000
--- a/src/compatibility/cts-development.md
+++ /dev/null
@@ -1,130 +0,0 @@
-<!--
- 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.
--->
-
-# CTS Development #
-
-## Initializing Your Repo Client ##
-
-Follow the [instructions](/source/downloading.html)
-to get and build the Android source code but specify `-b android-4.1.1_r1`
-when issuing the `repo init` command. This assures that your CTS
-changes will be included in the next CTS release and beyond.
-
-## Setting Up Eclipse ##
-
-Follow the [instructions](/source/using-eclipse.html)
-to setup Eclipse but execute the following command to generate the
-`.classpath` file rather than copying the one from the development
-project:
-
- cd /path/to/android/root
- ./cts/development/ide/eclipse/genclasspath.sh > .classpath
- chmod u+w .classpath
-
-This `.classpath` file will contain both the Android framework
-packages and the CTS packages.
-
-## Building and Running CTS ##
-
-Execute the following commands to build CTS and start the interactive
-CTS console:
-
- cd /path/to/android/root
- make cts
- cts
-
-Provide arguments to CTS to immediately start executing a test:
-
- cts start --plan CTS -p android.os.cts.BuildVersionTest
-
-## Writing CTS Tests ##
-
-CTS tests use JUnit and the Android testing APIs. Review the
-[Testing and Instrumentation](https://developer.android.com/guide/topics/testing/testing_android.html)
-tutorial while perusing the existing tests under the
-`cts/tests/tests` directory. You will see that CTS tests mostly follow the same
-conventions used in other Android tests.
-
-Since CTS runs across many production devices, the tests must follow
-these rules:
-
-- Must take into account varying screen sizes, orientations, and keyboard layouts.
-- Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.
-- Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.
-- Don't rely upon root privileges.
-
-### Test Naming and Location ###
-
-Most CTS test cases target a specific class in the Android API. These tests
-have Java package names with a `cts` suffix and class
-names with the `Test` suffix. Each test case consists of
-multiple tests, where each test usually exercises a particular API method of
-the API class being tested. These tests are arranged in a directory structure
-where tests are grouped into different categories like "widgets" and "views."
-
-For example, the CTS test for `android.widget.TextView` is
-`android.widget.cts.TextViewTest` found under the
-`cts/tests/tests/widget/src/android/widget/cts` directory with its
-Java package name as `android.widget.cts` and its class name as
-`TextViewTest`. The `TextViewTest` class has a test called `testSetText`
-that exercises the "setText" method and a test named "testSetSingleLine" that
-calls the `setSingleLine` method. Each of those tests have `@TestTargetNew`
-annotations indicating what they cover.
-
-Some CTS tests do not directly correspond to an API class but are placed in
-the most related package possible. For instance, the CTS test,
-`android.net.cts.ListeningPortsTest`, is in the `android.net.cts`, because it
-is network related even though there is no `android.net.ListeningPorts` class.
-You can also create a new test package if necessary. For example, there is an
-"android.security" test package for tests related to security. Thus, use your
-best judgement when adding new tests and refer to other tests as examples.
-
-Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew.
-These are no longer necessary so do not annotate new tests with these.
-
-### New Test Packages ###
-
-When adding new tests, there may not be an existing directory to place your
-test. In that case, refer to the example under `cts/tests/tests/example` and
-create a new directory. Furthermore, make sure to add your new package's
-module name from its `Android.mk` to `CTS_COVERAGE_TEST_CASE_LIST` in
-`cts/CtsTestCaseList.mk`. This Makefile is used by `build/core/tasks/cts.mk`
-to glue all the tests together to create the final CTS package.
-
-### Test Stubs and Utilities ###
-
-Some tests use additional infrastructure like separate activities
-and various utilities to perform tests. These are located under the
-`cts/tests/src` directory. These stubs aren't separated into separate test
-APKs like the tests, so the `cts/tests/src` directory does not have additional
-top level directories like "widget" or "view." Follow the same principle of
-putting new classes into a package with a name that correlates to the purpose
-of your new class. For instance, a stub activity used for testing OpenGL like
-`GLSurfaceViewStubActivity` belongs in the `android.opengl.cts` package under
-the `cts/tests/src/android/opengl` directory.
-
-## Other Tasks ##
-
-Besides adding new tests there are other ways to contribute to CTS:
-
-- Fix or remove tests annotated with BrokenTest and KnownFailure.
-
-## Submitting Your Changes ##
-
-Follow the [Android Contributors' Workflow](/source/submit-patches.html)
-to contribute changes to CTS. A reviewer
-will be assigned to your change, and your change should be reviewed shortly!
-
diff --git a/src/compatibility/cts-intro.jd b/src/compatibility/cts-intro.jd
new file mode 100644
index 0000000..3db4b36
--- /dev/null
+++ b/src/compatibility/cts-intro.jd
@@ -0,0 +1,154 @@
+page.title=Compatibility Test Suite
+@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="how-does-the-cts-work">How does the CTS work?</h2>
+<div style="float: right">
+ <img src="/images/cts-0.png">
+</div>
+
+<p>The CTS is an automated testing harness that includes two major software components:</p>
+<ul>
+<li>
+<p>The CTS test harness runs on your desktop machine and manages test execution.</p>
+</li>
+<li>
+<p>Individual test cases are executed on attached mobile devices or on an
+emulator. The test cases are written in Java as JUnit tests and packaged as
+Android .apk files to run on the actual device target.</p>
+</li>
+</ul>
+<h2 id="workflow">Workflow</h2>
+<ol>
+<li>
+<p><a href="downloads.html">Download</a> the CTS and CTS media files.</p>
+</li>
+<li>
+<p>Attach at least one device (or emulator) to your machine.</p>
+</li>
+<li>
+<p>For CTS 2.1 R2 and beyond, setup your device (or emulator) to run the accessibility tests:</p>
+<ol>
+<li>
+<p>adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk</p>
+</li>
+<li>
+<p>On the device, enable Settings > Accessibility > Accessibility > Delegating Accessibility Service</p>
+</li>
+</ol>
+</li>
+<li>
+<p>For CTS 2.3 R4 and beyond, setup your device to run the device administration tests:</p>
+<ol>
+<li>
+<p>adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk</p>
+</li>
+<li>
+<p>On the device, enable all the android.deviceadmin.cts.* device administrators under Settings > Location & security > Select device administrators</p>
+</li>
+</ol>
+</li>
+<li>
+<p>For CTS 2.3 R12 and beyond, the CTS media files must be copied to the device's external storage. Check section 4.2 of the latest CTS manual for further details on copying these files:</p>
+<ol>
+<li>
+<p>Unzip the CTS Media zip file.</p>
+</li>
+<li>
+<p>Run copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]. If no resolution is specified, the default maximum resolution of 480x360 is assumed.</p>
+</li>
+</ol>
+</li>
+<li>
+<p>Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:</p>
+<ul>
+<li>
+<p>The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.</p>
+</li>
+<li>
+<p>The test harness removes the .apk file from each device.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.</p>
+</li>
+</ol>
+<p>When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.</p>
+<h2 id="types-of-test-cases">Types of test cases</h2>
+<p>The CTS includes the following types of test cases:</p>
+<ul>
+<li>
+<p><em>Unit tests</em> test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap.</p>
+</li>
+<li>
+<p><em>Functional tests</em> test a combination of APIs together in a higher-level use-case.</p>
+</li>
+<li>
+<p><em>Reference application tests</em> instrument a complete sample application to exercise a full set of APIs and Android runtime services</p>
+</li>
+</ul>
+<p>Future versions of the CTS will include the following types of test cases:</p>
+<ul>
+<li>
+<p><em>Robustness tests</em> test the durability of the system under stress.</p>
+</li>
+<li>
+<p><em>Performance tests</em> test the performance of the system against defined benchmarks, for example rendering frames per second.</p>
+</li>
+</ul>
+<h2 id="areas-covered">Areas Covered</h2>
+<p>The unit test cases cover the following areas to ensure compatibility:</p>
+<table>
+<thead>
+<tr>
+<th>Area</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Signature tests</td>
+<td>For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.</td>
+</tr>
+<tr>
+<td>Platform API Tests</td>
+<td>Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK <a href="https://developer.android.com/reference/classes.html">Class Index</a> to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.</td>
+</tr>
+<tr>
+<td>Dalvik VM Tests</td>
+<td>The tests focus on testing the Dalvik VM</td>
+</tr>
+<tr>
+<td>Platform Data Model</td>
+<td>The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK <a href="https://developer.android.com/reference/android/provider/package-summary.html">android.provider</a> package: contacts, browser, settings, etc.</td>
+</tr>
+<tr>
+<td>Platform Intents</td>
+<td>The CTS tests the core platform intents, as documented in the SDK <a href="https://developer.android.com/guide/appendix/g-app-intents.html">Available Intents</a>.</td>
+</tr>
+<tr>
+<td>Platform Permissions</td>
+<td>The CTS tests the core platform permissions, as documented in the SDK <a href="https://developer.android.com/reference/android/Manifest.permission.html">Available Permissions</a>.</td>
+</tr>
+<tr>
+<td>Platform Resources</td>
+<td>The CTS tests for correct handling of the core platform resource types, as documented in the SDK <a href="https://developer.android.com/guide/topics/resources/available-resources.html">Available Resource Types</a>. This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.</td>
+</tr>
+</tbody>
+</table>
diff --git a/src/compatibility/cts-intro.md b/src/compatibility/cts-intro.md
deleted file mode 100644
index 842a583..0000000
--- a/src/compatibility/cts-intro.md
+++ /dev/null
@@ -1,96 +0,0 @@
-<!--
- 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.
--->
-
-# Compatibility Test Suite #
-
-## How does the CTS work? ##
-
-<div style="float: right">
- <img src="/images/cts-0.png">
-</div>
-
-The CTS is an automated testing harness that includes two major software components:
-
-- The CTS test harness runs on your desktop machine and manages test execution.
-
-- Individual test cases are executed on attached mobile devices or on an
-emulator. The test cases are written in Java as JUnit tests and packaged as
-Android .apk files to run on the actual device target.
-
-## Workflow ##
-
-1. [Download](downloads.html) the CTS and CTS media files.
-
-1. Attach at least one device (or emulator) to your machine.
-
-1. For CTS 2.1 R2 and beyond, setup your device (or emulator) to run the accessibility tests:
-
- 2. adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk
-
- 2. On the device, enable Settings > Accessibility > Accessibility > Delegating Accessibility Service
-
-1. For CTS 2.3 R4 and beyond, setup your device to run the device administration tests:
-
- 2. adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk
-
- 2. On the device, enable all the android.deviceadmin.cts.* device administrators under Settings > Location & security > Select device administrators
-
-1. For CTS 2.3 R12 and beyond, the CTS media files must be copied to the device's external storage. Check section 4.2 of the latest CTS manual for further details on copying these files:
-
- 2. Unzip the CTS Media zip file.
-
- 2. Run copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]. If no resolution is specified, the default maximum resolution of 480x360 is assumed.
-
-1. Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:
-
- - The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.
-
- - The test harness removes the .apk file from each device.
-
-1. Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.
-
-When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.
-
-## Types of test cases ##
-
-The CTS includes the following types of test cases:
-
-- *Unit tests* test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap.
-
-- *Functional tests* test a combination of APIs together in a higher-level use-case.
-
-- *Reference application tests* instrument a complete sample application to exercise a full set of APIs and Android runtime services
-
-Future versions of the CTS will include the following types of test cases:
-
-- *Robustness tests* test the durability of the system under stress.
-
-- *Performance tests* test the performance of the system against defined benchmarks, for example rendering frames per second.
-
-## Areas Covered ##
-
-The unit test cases cover the following areas to ensure compatibility:
-
-Area | Description
------|-------------
-Signature tests | For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
-Platform API Tests | Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK [Class Index](https://developer.android.com/reference/classes.html) to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.
-Dalvik VM Tests | The tests focus on testing the Dalvik VM
-Platform Data Model | The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK [android.provider](https://developer.android.com/reference/android/provider/package-summary.html) package: contacts, browser, settings, etc.
-Platform Intents | The CTS tests the core platform intents, as documented in the SDK [Available Intents](https://developer.android.com/guide/appendix/g-app-intents.html).
-Platform Permissions | The CTS tests the core platform permissions, as documented in the SDK [Available Permissions](https://developer.android.com/reference/android/Manifest.permission.html).
-Platform Resources | The CTS tests for correct handling of the core platform resource types, as documented in the SDK [Available Resource Types](https://developer.android.com/guide/topics/resources/available-resources.html). This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.
-
diff --git a/src/compatibility/downloads.jd b/src/compatibility/downloads.jd
new file mode 100644
index 0000000..1e5c3e6
--- /dev/null
+++ b/src/compatibility/downloads.jd
@@ -0,0 +1,97 @@
+page.title=Android Compatibility Downloads
+@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.
+-->
+
+<p>Thanks for your interest in Android Compatibility! The links below allow
+you to access the key documents and information.</p>
+<h2 id="android-42">Android 4.2</h2>
+<p>Android 4.2 is the release of the development milestone code-named
+Jelly Bean-MR1. Android 4.2 is the current version of Android. Source code for
+Android 4.2 is found in the 'android-4.2_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.2/android-4.2-cdd.pdf">Android 4.2 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.2_r1-linux_x86-arm.zip">Android 4.2 R1 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.2_r1-linux_x86-arm.zip">Android 4.2 R1 CTS Verifier</a></li>
+</ul>
+<h2 id="android-41">Android 4.1</h2>
+<p>Android 4.1.1 is the release of the development milestone code-named
+Jelly Bean. Android 4.1.1 is the current version of Android. Source code for
+Android 4.1.1 is found in the 'android-4.1.1_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.1/android-4.1-cdd.pdf">Android 4.1 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.1_r1-linux_x86-arm.zip">Android 4.1 R1 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.1_r2-linux_x86-arm.zip">Android 4.1 R2 CTS Verifier</a></li>
+</ul>
+<h2 id="android-403">Android 4.0.3</h2>
+<p>Android 4.0.3 is the release of the development milestone code-named
+Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
+Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.0/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.0.3_r3-linux_x86-arm.zip">Android 4.0.3 R3 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r2-linux_x86-arm.zip">Android 4.0.3 R2 CTS Verifier</a></li>
+</ul>
+<h2 id="android-23">Android 2.3</h2>
+<p>Android 2.3 is the release of the development milestone code-named
+Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in
+the open-source tree.</p>
+<ul>
+<li><a href="2.3/android-2.3.3-cdd.pdf">Android 2.3 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip">Android 2.3 R13 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-2.3_r3-linux_x86-armv5.zip">Android 2.3 R3 CTS Verifier</a></li>
+</ul>
+<h2 id="android-22">Android 2.2</h2>
+<p>Android 2.2 is the release of the development milestone code-named
+FroYo. Source code for Android 2.2 is found in the 'froyo' branch in the
+open-source tree.</p>
+<ul>
+<li><a href="2.2/android-2.2-cdd.pdf">Android 2.2 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.2_r8-linux_x86-arm.zip">Android 2.2 R8 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="android-21">Android 2.1</h2>
+<p>Android 2.1 is the release of the development milestone code-named
+Eclair. Source code for Android 2.1 is found in the 'eclair' branch in the
+open-source tree. Note that for technical reasons, there is no compatibility
+program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.</p>
+<ul>
+<li><a href="2.1/android-2.1-cdd.pdf">Android 2.1 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.1_r5-x86.zip">Android 2.1 R5 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="android-16">Android 1.6</h2>
+<p>Android 1.6 was the release of the development milestone code-named Donut.
+Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found
+in the 'donut' branch in the open-source tree.</p>
+<ul>
+<li><a href="1.6/android-1.6-cdd.pdf">Android 1.6 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-1.6_r1-x86.zip">Android 1.6 R1 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="compatibility-test-suite-manual">Compatibility Test Suite Manual</h2>
+<p>The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and
+beyond require <a href="cts-intro.html">additional steps</a> to run the accessibility tests.</p>
+<ul>
+<li><a href="android-cts-manual-r6.pdf">Compatibility Test Suite (CTS) User Manual</a></li>
+</ul>
+<h2 id="cts-media-files">CTS Media Files</h2>
+<p>These media files are required for the CTS media stress tests.</p>
+<ul>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip">CTS Media 1.0</a></li>
+</ul>
+<h2 id="older-android-versions">Older Android Versions</h2>
+<p>There is no Compatibility Program for older versions of Android, such as Android
+1.5 (known in development as Cupcake). New devices intended to be Android
+compatible must ship with Android 1.6 or later.</p>
diff --git a/src/compatibility/downloads.md b/src/compatibility/downloads.md
deleted file mode 100644
index 8f2dcf7..0000000
--- a/src/compatibility/downloads.md
+++ /dev/null
@@ -1,97 +0,0 @@
-<!--
- 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.
--->
-
-# Android Compatibility Downloads #
-
-Thanks for your interest in Android Compatibility! The links below allow
-you to access the key documents and information.
-
-## Android 4.1 ##
-
-Android 4.1.1 is the release of the development milestone code-named
-Jelly Bean. Android 4.1.1 is the current version of Android. Source code for
-Android 4.1.1 is found in the 'android-4.1.1_r1' branch in the open-source tree.
-
-- [Android 4.1 Compatibility Definition Document (CDD)](4.1/android-4.1-cdd.pdf)
-- [Android 4.1 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.1_r1-linux_x86-arm.zip)
-- [Android 4.1 R2 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.1_r2-linux_x86-arm.zip)
-
-
-## Android 4.0.3 ##
-
-Android 4.0.3 is the release of the development milestone code-named
-Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
-Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open-source tree.
-
-- [Android 4.0 Compatibility Definition Document (CDD)](4.0/android-4.0-cdd.pdf)
-- [Android 4.0.3 R3 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.0.3_r3-linux_x86-arm.zip)
-- [Android 4.0.3 R2 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r2-linux_x86-arm.zip)
-
-## Android 2.3 ##
-
-Android 2.3 is the release of the development milestone code-named
-Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in
-the open-source tree.
-
-- [Android 2.3 Compatibility Definition Document (CDD)](2.3/android-2.3.3-cdd.pdf)
-- [Android 2.3 R13 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip)
-- [Android 2.3 R3 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-2.3_r3-linux_x86-armv5.zip)
-
-## Android 2.2 ##
-
-Android 2.2 is the release of the development milestone code-named
-FroYo. Source code for Android 2.2 is found in the 'froyo' branch in the
-open-source tree.
-
-- [Android 2.2 Compatibility Definition Document (CDD)](2.2/android-2.2-cdd.pdf)
-- [Android 2.2 R8 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.2_r8-linux_x86-arm.zip)
-
-## Android 2.1 ##
-
-Android 2.1 is the release of the development milestone code-named
-Eclair. Source code for Android 2.1 is found in the 'eclair' branch in the
-open-source tree. Note that for technical reasons, there is no compatibility
-program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.
-
-- [Android 2.1 Compatibility Definition Document (CDD)](2.1/android-2.1-cdd.pdf)
-- [Android 2.1 R5 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.1_r5-x86.zip)
-
-## Android 1.6 ##
-
-Android 1.6 was the release of the development milestone code-named Donut.
-Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found
-in the 'donut' branch in the open-source tree.
-
-- [Android 1.6 Compatibility Definition Document (CDD)](1.6/android-1.6-cdd.pdf)
-- [Android 1.6 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-1.6_r1-x86.zip)
-
-## Compatibility Test Suite Manual ##
-
-The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and
-beyond require [additional steps](cts-intro.html) to run the accessibility tests.
-
-- [Compatibility Test Suite (CTS) User Manual](android-cts-manual-r5.pdf)
-
-## CTS Media Files ##
-These media files are required for the CTS media stress tests.
-
-- [CTS Media 1.0](https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip)
-
-## Older Android Versions ##
-
-There is no Compatibility Program for older versions of Android, such as Android
-1.5 (known in development as Cupcake). New devices intended to be Android
-compatible must ship with Android 1.6 or later.
diff --git a/src/compatibility/index.jd b/src/compatibility/index.jd
new file mode 100644
index 0000000..d081d3c
--- /dev/null
+++ b/src/compatibility/index.jd
@@ -0,0 +1,69 @@
+page.title=Android Compatibility
+@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.
+-->
+
+<p>Android's purpose is to establish an open platform for developers to build innovative apps.
+The Android Compatibility program defines the technical details of Android platform and provides
+tools used by OEMs to ensure that developers' apps run on a variety of devices. The Android SDK
+provides built-in tools that developers use to clearly state the device features their apps
+require. And Google Play shows apps only to those devices that can properly run them.
+</p>
+
+<h2 id="why-build-compatible-android-devices">Why build compatible Android devices?</h2>
+<h3 id="users-want-a-customizable-device">Users want a customizable device.</h3>
+<p>A mobile phone is a highly personal, always-on, always-present gateway to
+the Internet. We haven't met a user yet who didn't want to customize it by
+extending its functionality. That's why Android was designed as a robust
+platform for running after-market applications.</p>
+<h3 id="developers-outnumber-us-all">Developers outnumber us all.</h3>
+<p>No device manufacturer can hope to write all the software that a person could
+conceivably need. We need third-party developers to write the apps users want,
+so the Android Open Source Project aims to make it as easy and open as
+possible for developers to build apps.</p>
+<h3 id="everyone-needs-a-common-ecosystem">Everyone needs a common ecosystem.</h3>
+<p>Every line of code developers write to work around a particular phone's bug
+is a line of code that didn't add a new feature. The more compatible phones
+there are, the more apps there will be. By building a fully compatible Android
+device, you benefit from the huge pool of apps written for Android, while
+increasing the incentive for developers to build more of those apps.</p>
+<h2 id="android-compatibility-is-free-and-its-easy">Android compatibility is free, and it's easy.</h2>
+<p>If you are building a mobile device, you can follow these steps to make
+sure your device is compatible with Android. For more details about the
+Android compatibility program in general, see <a href="overview.html">the program overview</a>.</p>
+<p>Building a compatible device is a three-step process:</p>
+<ol>
+<li>
+<p><em>Obtain the Android software source code</em>.
+ This is <a href="/source/index.html">the source code for the Android platform</a>, that you port to your hardware.</p>
+</li>
+<li>
+<p><em>Comply with Android Compatibility Definition Document (CDD)</em>.
+ The CDD enumerates the software and hardware requirements of a compatible Android device.</p>
+</li>
+<li>
+<p><em>Pass the Compatibility Test Suite (CTS)</em>.
+ You can use the CTS (included in the Android source code) as an ongoing aid to compatibility during the development process.</p>
+</li>
+</ol>
+
+<h2 id="joining-the-ecosystem">Joining the Ecosystem</h2>
+<p>Once you've built a compatible device, you may wish to include Google
+Play to provide your users access to the third-party app ecosystem.
+Unfortunately, for a variety of legal and business reasons, we aren't able to
+automatically license Google Play to all compatible devices. To inquire
+about access about Google Play, you can <a href="contact-us.html">contact us</a>.</p>
\ No newline at end of file
diff --git a/src/compatibility/index.md b/src/compatibility/index.md
deleted file mode 100644
index 3edc47d..0000000
--- a/src/compatibility/index.md
+++ /dev/null
@@ -1,80 +0,0 @@
-<!--
- 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.
--->
-
-# Android Compatibility #
-
-Android's purpose is to establish an open platform for developers to build
-innovative mobile apps. Three key components work together to realize this
-platform.
-
-The Android Compatibility Program defines the technical details of Android
-platform and provides tools used by OEMs to ensure that developers' apps run
-on a variety of devices. The Android SDK provides built-in tools that
-Developers use to clearly state the device features their apps require. And
-Google Play shows apps only to those devices that can properly run
-them.
-
-These pages describe the Android Compatibility Program and how to get
-access to compatibility information and tools.
-
-## Why build compatible Android devices? ##
-
-### Users want a customizable device. ###
-
-A mobile phone is a highly personal, always-on, always-present gateway to
-the Internet. We haven't met a user yet who didn't want to customize it by
-extending its functionality. That's why Android was designed as a robust
-platform for running after-market applications.
-
-### Developers outnumber us all. ###
-
-No device manufacturer can hope to write all the software that a person could
-conceivably need. We need third-party developers to write the apps users want,
-so the Android Open Source Project aims to make it as easy and open as
-possible for developers to build apps.
-
-### Everyone needs a common ecosystem. ###
-
-Every line of code developers write to work around a particular phone's bug
-is a line of code that didn't add a new feature. The more compatible phones
-there are, the more apps there will be. By building a fully compatible Android
-device, you benefit from the huge pool of apps written for Android, while
-increasing the incentive for developers to build more of those apps.
-
-## Android compatibility is free, and it's easy. ##
-
-If you are building a mobile device, you can follow these steps to make
-sure your device is compatible with Android. For more details about the
-Android compatibility program in general, see [the program overview](overview.html).
-
-Building a compatible device is a three-step process:
-
-1. *Obtain the Android software source code*.
- This is [the source code for the Android platform](/source/index.html), that you port to your hardware.
-
-1. *Comply with Android Compatibility Definition Document (CDD)*.
- The CDD enumerates the software and hardware requirements of a compatible Android device.
-
-1. *Pass the Compatibility Test Suite (CTS)*.
- You can use the CTS (included in the Android source code) as an ongoing aid to compatibility during the development process.
-
-# Joining the Ecosystem #
-
-Once you've built a compatible device, you may wish to include Google
-Play to provide your users access to the third-party app ecosystem.
-Unfortunately, for a variety of legal and business reasons, we aren't able to
-automatically license Google Play to all compatible devices. To inquire
-about access about Google Play, you can [contact us](contact-us.html).
diff --git a/src/compatibility/overview.jd b/src/compatibility/overview.jd
new file mode 100644
index 0000000..184903a
--- /dev/null
+++ b/src/compatibility/overview.jd
@@ -0,0 +1,120 @@
+page.title=Compatibility Program Overview
+@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.
+-->
+
+<p>The Android compatibility program makes it easy for mobile device
+manufacturers to develop compatible Android devices.</p>
+<h1 id="program-goals">Program goals</h1>
+<p>The Android compatibility program works for the benefit of the entire
+Android community, including users, developers, and device manufacturers.</p>
+<p>Each group depends on the others. Users want a wide selection of devices
+and great apps; great apps come from developers motivated by a large market
+for their apps with many devices in users' hands; device manufacturers rely
+on a wide variety of great apps to increase their products' value for
+consumers.</p>
+<p>Our goals were designed to benefit each of these groups:</p>
+<ul>
+<li>
+<p><em>Provide a consistent application and hardware environment to application
+developers.</em>
+ Without a strong compatibility standard, devices can vary so
+greatly that developers must design different versions of their applications
+for different devices. The compatibility program provides a precise definition
+of what developers can expect from a compatible device in terms of APIs and
+capabilities. Developers can use this information to make good design
+decisions, and be confident that their apps will run well on any compatible
+device.</p>
+</li>
+<li>
+<p><em>Enable a consistent application experience for consumers.</em>
+ If an application runs well on one compatible Android device, it should run well on
+any other device that is compatible with the same Android platform version.
+Android devices will differ in hardware and software capabilities, so the
+compatibility program also provides the tools needed for distribution systems
+such as Google Play to implement appropriate filtering. This means that
+users can only see applications which they can actually run.</p>
+</li>
+<li>
+<p><em>Enable device manufacturers to differentiate while being
+compatible.</em>
+ The Android compatibility program focuses on the aspects of
+Android relevant to running third-party applications, which allows device
+manufacturers the flexibility to create unique devices that are nonetheless
+compatible.</p>
+</li>
+<li>
+<p><em>Minimize costs and overhead associated with compatibility.</em>
+ Ensuring compatibility should be easy and inexpensive to
+device manufacturers. The testing tool (CTS) is free, open source, and
+available for <a href="downloads.html">download</a>.
+CTS is designed to be used for continuous self-testing
+during the device development process to eliminate the cost of changing your
+workflow or sending your device to a third party for testing. Meanwhile, there
+are no required certifications, and thus no corresponding costs and
+fees.</p>
+</li>
+</ul>
+<p>The Android compatibility program consists of three key components:</p>
+<ul>
+<li>The source code to the Android software stack</li>
+<li>The Compatilbility Definition Document, representing the "policy" aspect of compatibility</li>
+<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li>
+</ul>
+<p>Just as each version of the Android platform exists in a separate branch in
+the source code tree, there is a separate CTS and CDD for each version as
+well. The CDD, CTS, and source code are -- along with your hardware and your
+software customizations -- everything you need to create a compatible device.</p>
+<h1 id="compatibility-definition-document-cdd">Compatibility Definition Document (CDD)</h1>
+<p>For each release of the Android platform, a detailed Compatibility
+Definition Document (CDD) will be provided. The CDD represents the "policy"
+aspect of Android compatibility.</p>
+<p>No test suite, including CTS, can truly be comprehensive. For instance, the
+CTS includes a test that checks for the presence and correct behavior of
+OpenGL graphics APIs, but no software test can verify that the graphics
+actually appear correctly on the screen. More generally, it's impossible to
+test the presence of hardware features such as keyboards, display density,
+WiFi, and Bluetooth.</p>
+<p>The CDD's role is to codify and clarify specific requirements, and
+eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
+Android is a single corpus of open-source code, the code itself is the
+comprehensive "specification" of the platform and its APIs. The CDD acts as a
+"hub", referencing other content (such as SDK API documentation) that provides
+a framework in which the Android source code may be used so that the end
+result is a compatible system.</p>
+<p>If you want to build a device compatible with a given Android version,
+start by checking out the source code for that version, and then read the
+corresponding CDD and stay within its guidelines. For additional details,
+simply examine <a href="4.2/android-4.2-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>.
+The CTS represents the "mechanism" of compatibility.</p>
+<p>The CTS runs on a desktop machine and executes test cases directly on
+attached devices or an emulator. The CTS is a set of unit tests designed to be
+integrated into the daily workflow (such as via a continuous build system) of
+the engineers building a device. Its intent is to reveal incompatibilities
+early on, and ensure that the software remains compatible throughout the
+development process.</p>
+<h1 id="compatibility-test-suite-verifier-cts-verifier">Compatibility Test Suite Verifier (CTS Verifier)</h1>
+<p>The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
+Compatibility Test Suite (CTS), available for <a href="downloads.html">download</a>.
+CTS Verifier provides tests for APIs and functions that cannot be tested on a
+stationary device without manual input (e.g. audio quality, accelerometer, etc).</p>
+<p>For details on the CTS, consult the <a href="cts-intro.html">CTS introduction</a>.</p>
+
+
diff --git a/src/compatibility/overview.md b/src/compatibility/overview.md
deleted file mode 100644
index 627334c..0000000
--- a/src/compatibility/overview.md
+++ /dev/null
@@ -1,127 +0,0 @@
-<!--
- 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.
--->
-
-# Compatibility Program Overview #
-
-The Android compatibility program makes it easy for mobile device
-manufacturers to develop compatible Android devices.
-
-# Program goals #
-
-The Android compatibility program works for the benefit of the entire
-Android community, including users, developers, and device manufacturers.
-
-Each group depends on the others. Users want a wide selection of devices
-and great apps; great apps come from developers motivated by a large market
-for their apps with many devices in users' hands; device manufacturers rely
-on a wide variety of great apps to increase their products' value for
-consumers.
-
-Our goals were designed to benefit each of these groups:
-
-- *Provide a consistent application and hardware environment to application
-developers.*
- Without a strong compatibility standard, devices can vary so
-greatly that developers must design different versions of their applications
-for different devices. The compatibility program provides a precise definition
-of what developers can expect from a compatible device in terms of APIs and
-capabilities. Developers can use this information to make good design
-decisions, and be confident that their apps will run well on any compatible
-device.
-
-- *Enable a consistent application experience for consumers.*
- If an application runs well on one compatible Android device, it should run well on
-any other device that is compatible with the same Android platform version.
-Android devices will differ in hardware and software capabilities, so the
-compatibility program also provides the tools needed for distribution systems
-such as Google Play to implement appropriate filtering. This means that
-users can only see applications which they can actually run.
-
-- *Enable device manufacturers to differentiate while being
-compatible.*
- The Android compatibility program focuses on the aspects of
-Android relevant to running third-party applications, which allows device
-manufacturers the flexibility to create unique devices that are nonetheless
-compatible.
-
-- *Minimize costs and overhead associated with compatibility.*
- Ensuring compatibility should be easy and inexpensive to
-device manufacturers. The testing tool (CTS) is free, open source, and
-available for [download](downloads.html).
-CTS is designed to be used for continuous self-testing
-during the device development process to eliminate the cost of changing your
-workflow or sending your device to a third party for testing. Meanwhile, there
-are no required certifications, and thus no corresponding costs and
-fees.
-
-The Android compatibility program consists of three key components:
-
-- The source code to the Android software stack
-- The Compatilbility Definition Document, representing the "policy" aspect of compatibility
-- The Compatilbility Test Suite, representing the "mechanism" of compatibility
-
-Just as each version of the Android platform exists in a separate branch in
-the source code tree, there is a separate CTS and CDD for each version as
-well. The CDD, CTS, and source code are -- along with your hardware and your
-software customizations -- everything you need to create a compatible device.
-
-# Compatibility Definition Document (CDD) #
-
-For each release of the Android platform, a detailed Compatibility
-Definition Document (CDD) will be provided. The CDD represents the "policy"
-aspect of Android compatibility.
-
-No test suite, including CTS, can truly be comprehensive. For instance, the
-CTS includes a test that checks for the presence and correct behavior of
-OpenGL graphics APIs, but no software test can verify that the graphics
-actually appear correctly on the screen. More generally, it's impossible to
-test the presence of hardware features such as keyboards, display density,
-WiFi, and Bluetooth.
-
-The CDD's role is to codify and clarify specific requirements, and
-eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
-Android is a single corpus of open-source code, the code itself is the
-comprehensive "specification" of the platform and its APIs. The CDD acts as a
-"hub", referencing other content (such as SDK API documentation) that provides
-a framework in which the Android source code may be used so that the end
-result is a compatible system.
-
-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 [the latest CDD](4.1/android-4.1-cdd.pdf).
-
-# Compatibility Test Suite (CTS) #
-
-The CTS is a free, commercial-grade test suite, available for
-[download](downloads.html).
-The CTS represents the "mechanism" of compatibility.
-
-The CTS runs on a desktop machine and executes test cases directly on
-attached devices or an emulator. The CTS is a set of unit tests designed to be
-integrated into the daily workflow (such as via a continuous build system) of
-the engineers building a device. Its intent is to reveal incompatibilities
-early on, and ensure that the software remains compatible throughout the
-development process.
-
-
-# Compatibility Test Suite Verifier (CTS Verifier) #
-The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
-Compatibility Test Suite (CTS), available for [download](downloads.html).
-CTS Verifier provides tests for APIs and functions that cannot be tested on a
-stationary device without manual input (e.g. audio quality, accelerometer, etc).
-
-For details on the CTS, consult the [CTS introduction](cts-intro.html).
diff --git a/src/compatibility/sidebar.md b/src/compatibility/sidebar.md
deleted file mode 100644
index 9df9f50..0000000
--- a/src/compatibility/sidebar.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Getting Started #
-- [Compatibility Overview](/compatibility/overview.html)
-- [Current CDD](/compatibility/4.1/android-4.1-cdd.pdf)
-- [CTS Introduction](/compatibility/cts-intro.html)
-- [CTS Development](/compatibility/cts-development.html)
-
-# More Information #
-- [Downloads](/compatibility/downloads.html)
-- [FAQs](/faqs.html#compatibility)
-- [Contact Us](/compatibility/contact-us.html)
-
-