clean up pdk references in s.a.c

Change-Id: I1e41cac5a23a82cf7aa45ad54172e3f6947932e8

14 files changed, 33 insertions, 1595 deletions

diff --git a/src/accessories/accessories_toc.cs b/src/accessories/accessories_toc.cs
index 3bc5718a..273977bc 100644
--- a/src/accessories/accessories_toc.cs
+++ b/src/accessories/accessories_toc.cs
@@ -13,7 +13,7 @@
     See the License for the specific language governing permissions and
     limitations under the License.
 -->
-<?cs # Table of contents for Dev pdk.?>
+<?cs # Table of contents for adk?>
 <ul id="nav">
   <!-- Accessories -->
   <li class="nav-section">
diff --git a/src/compatibility/compatibility.jd b/src/compatibility/compatibility.jd
deleted file mode 100644
index 5d07a953..00000000
--- a/src/compatibility/compatibility.jd
+++ /dev/null
@@ -1,203 +0,0 @@
-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
index ed83355a..1e81dcf2 100644
--- a/src/compatibility/compatibility_toc.cs
+++ b/src/compatibility/compatibility_toc.cs
@@ -1,19 +1,19 @@
 <!--
-    Copyright 2010 The Android Open Source Project     
+    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    
+    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.   
+    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.?>
+<?cs # Table of contents for compatibility.?>
 <ul id="nav">
 <!-- Compatibility -->
   <li class="nav-section">
diff --git a/src/devices/build_new_device.jd b/src/devices/build_new_device.jd
deleted file mode 100644
index 7f9cdd2a..00000000
--- a/src/devices/build_new_device.jd
+++ /dev/null
@@ -1,411 +0,0 @@
-page.title=Configuring and Building a Product
-@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 id="auto-toc">
-    </ol>
-  </div>
-</div>
-
-<p>
-  There are many ways to organize the source files for your device. We'll briefly go over how the
-  Galaxy Nexus implementation was organized as an example, but you can organize your source files
-  and build the way you see fit.
-</p>
-<p>
-  Galaxy Nexus was implemented with a main device configuration named <code>tuna</code> that has
-  two specific variations: <code>maguro</code> for GSM and <code>toro</code> for CDMA. The two
-  device variations inherited common characteristics from <code>tuna</code> by calling
-  <code>tuna</code>'s device Makefile and then defined their own device-specific characteristics.
-  From these device configurations, a product is created with a product definition Makefile that
-  declares product-specific information about the device such as the name and model.
-  You can view the <code>device/samsung/tuna</code>, <code>device/samsung/maguro</code>, and
-  <code>device/samsung/toro</code> directories to see how all of this is setup.
-</p>
-<h2 id="configuring">
-  Configuring a Product
-</h2>
-<p>
-  The following steps describe how to set up products in a way similar to that of the Galaxy Nexus
-  product line:
-</p>
-<ol>
-  <li>Create a <code>device/&lt;company_name&gt;/&lt;device_name&gt;</code> directory for your
-  product. For example, <code>device/samsung/tuna</code>. This directory will contain source code
-  for your device along with the Makefiles to build them.
-  </li>
-
-  <li>Create a <code>device.mk</code> Makefile that declares the files and modules needed for the
-  device. For an example, see <code>device/samsung/tuna/device.mk</code>.
-  </li>
-
-  <li>Create a product definition Makefile to create a specific product based on the device. The
-  following Makefile is taken from <code>device/samsung/tuna/full_tuna.mk</code> as an example.
-  Notice that the product is inheriting from the tuna and full (emulator) devices via their
-  Makefiles, while also declaring the product-specific information such as the name, brand, and model.
-  
-<pre>
-# Inherit from those products. Most specific first.
-$(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk)
-# This is where we'd set a backup provider if we had one
-#$(call inherit-product, device/sample/products/backup_overlay.mk)
-# Inherit from tuna device
-$(call inherit-product, device/samsung/tuna/device.mk)
-
-# Set those variables here to overwrite the inherited values.
-PRODUCT_NAME := full_tuna
-PRODUCT_DEVICE := tuna
-PRODUCT_BRAND := Android
-PRODUCT_MODEL := Full AOSP on Tuna
-</pre>
-
-    <p>
-      See <a href="{@docRoot}devices/build_new_device.html#prod-def">Product Definition Variables</a> for additional product-specific
-      variables you can add to your Makefiles.
-    </p>    
-  </li>
-
-  <li>Create an <code>AndroidProducts.mk</code> file that points to the product's Makefiles. In
-  this example, only the product definition Makefile is needed. The example below is from
-  <code>device/samsung/tuna/AndroidProducts.mk</code>:
-    <pre>
-#
-# This file should set PRODUCT_MAKEFILES to a list of product makefiles
-# to expose to the build system.  LOCAL_DIR will already be set to
-# the directory containing this file. 
-#
-# This file may not rely on the value of any variable other than
-# LOCAL_DIR; do not use any conditionals, and do not look up the
-# value of any variable that isn't set in this file or in a file that
-# it includes.
-#
-
-PRODUCT_MAKEFILES := \
-    $(LOCAL_DIR)/full_tuna.mk
-</pre>
-  </li>
-
-  <li>Create a <code>BoardConfig.mk</code> Makefile that contains board-specific configurations.
-  For an example, see <code>device/samsung/tuna/BoardConfig.mk</code>.
-  </li>
-
-  <li>Create a <code>vendorsetup.sh</code> file to add your product (a "lunch combo") to the build
-  along with a <a href="{@docRoot}devices/build_system.html#variants">build variant</a> separated by a dash. For example:
-<pre>
-add_lunch_combo &lt;product_name&gt;-userdebug
-</pre>
-  </li>
-
-  <li>At this point, you can create more product variants based on the same device, like how the
-  Galaxy Nexus does with the <code>maguro</code> and <code>toro</code> products. For a complete
-  example, see the Galaxy Nexus implementation in <code>device/samsung/tuna</code>,
-  <code>device/samsung/maguro</code>, and <code>device/samsung/toro</code>.
-  </li>
-
-</ol>
-
-<h3 id="prod-def">
-  Product Definition Variables
-</h3>
-<p>
-  Product-specific variables are defined in the product's Makefile. Variables maintained in a
-  product definition files include:
-</p>
-<table>
-  <tbody>
-    <tr>
-      <th>
-        Parameter
-      </th>
-      <th>
-        Description
-      </th>
-      <th>
-        Example
-      </th>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_AAPT_CONFIG
-      </td>
-      <td>
-        <code>aapt</code> configurations to use when creating packages
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_BRAND
-      </td>
-      <td>
-        The brand (e.g., carrier) the software is customized for, if any
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_CHARACTERISTICS
-      </td>
-      <td>
-        <code>aapt</code> characteristics to allow adding variant-specific resources to a package.
-      </td>
-      <td>
-        tablet,nosdcard
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_CONTRIBUTORS_FILE
-      </td>
-      <td>
-        HTML file containing the contributors to the project.
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_COPY_FILES
-      </td>
-      <td>
-        List of words like <code>source_path:destination_path</code>. The file at the source path
-        should be copied to the destination path when building this product. The rules for the copy
-        steps are defined in config/Makefile
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_DEVICE
-      </td>
-      <td>
-        Name of the industrial design
-      </td>
-      <td>
-        <code>tuna</code>
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_LOCALES
-      </td>
-      <td>
-        A space-separated list of two-letter language code, two-letter country code pairs that
-        describe several settings for the user, such as the UI language and time, date and currency
-        formatting. The first locale listed in PRODUCT_LOCALES is is used if the locale has never
-        been set before.
-      </td>
-      <td>
-        <code>en_GB de_DE es_ES fr_CA</code>
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_MANUFACTURER
-      </td>
-      <td>
-        Name of the manufacturer
-      </td>
-      <td>
-        <code>acme</code>
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_MODEL
-      </td>
-      <td>
-        End-user-visible name for the end product
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_NAME
-      </td>
-      <td>
-        End-user-visible name for the overall product. Appears in the Settings &gt; About screen.
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_OTA_PUBLIC_KEYS
-      </td>
-      <td>
-        List of Over the Air (OTA) public keys for the product
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_PACKAGES
-      </td>
-      <td>
-        Lists the APKs to install.
-      </td>
-      <td>
-        <code>Calendar Contacts</code>
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_PACKAGE_OVERLAYS
-      </td>
-      <td>
-        Indicate whether to use default resources or add any product specific overlays
-      </td>
-      <td>
-        <code>vendor/acme/overlay</code>
-      </td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_PROPERTY_OVERRIDES
-      </td>
-      <td>
-        List of property assignments in the format "key=value"
-      </td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>
-        PRODUCT_TAGS
-      </td>
-      <td>
-        list of space-separated words for a given product
-      </td>
-      <td></td>
-    </tr>
-  </tbody>
-</table>
-
-
-<h2 id="building">Building a Product</h2>
-<p>To eventually build your product, add your HAL implementations and drivers to
-  your device's source tree and execute the following commands.</p>
-    <p>
-      For a Fusion build for armv7 with NEON:
-    </p>
-<pre>
-  build/envsetup.sh
-  lunch your_lunch_combo
-  PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/platform/platform.zip make -j32
-</pre>
-    <p>
-      For a Fusion build for armv7:
-    </p>
-<pre>
-  build/envsetup.sh
-  lunch your_lunch_combo
-  PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a/mini_armv7a-userdebug/platform/platform.zip make -j32
-</pre>
-    <p>
-      For a non-Fusion build for both architectures, run <code>make</code> like this instead:
-    </p>
-<pre>
-TARGET_BUILD_PDK=true make -j32
-</pre>
-
-<p class="note"><strong>Important:</strong> 
-If you are switching between different lunch combos or between fusion and non-fusion builds,
-run the following command
-to remove any remnants of the test build so that it doesn't interfere
-with your real product's build later on.
-
-<pre>make installclean</pre>
-</p>
-
-    <p>
-      You should find new binaries located in
-      <code>/out/target/product/&lt;device_name&gt;</code>.
-    </p>
-  </li>
-</ol>
-
-
-<h2 id="managing">
-  Managing Makefiles
-</h2>
-<p>
-  Building with the PDK is different from normal product builds that have access to all of the
-  Android sources. Existing product Makefiles require changes to build the product. This section
-  provides an overview of the available workarounds in the PDK to support product builds.
-</p>
-<p>
-  For product Makefiles:
-</p>
-<ul>
-  <li>Use the <code>inherit-product-if-exists</code> macro instead of <code>inherit-product</code>
-  if the target product file does not exist in the PDK.
-  </li>
-  <li>For the <code>PRODUCT_COPY_FILES</code> variable, use the
-  <code>add-to-product-copy-files-if-exists</code> macro, which excludes the component if it does
-  not exist.
-  </li>
-  <li>For an include sentence, use <code>-include</code> to ignore the error if the included file
-  does not exist.
-  </li>
-  <li>You can also check the presence of necessary files and include it in a PDK based build with
-  the <code>$(wildcard ...)</code> macro. For example, the following if statement executes the code
-  block if <code>frameworks/base/Android.mk</code> exists:
-    <pre>
-ifneq ($(wildcard frameworks/base/Android.mk),)
-
-...
-
-endif
-</pre>
-  </li>
-</ul>
-<p>
-  For <code>Android.mk</code> files:
-</p>
-<ul>
-  <li>
-    <code>TARGET_BUILD_PDK</code> is set to true for PDK builds. If you have a component that
-    cannot be built in the PDK build, wrap the code to build the component in an if statement:
-    <pre>
-ifeq ($(TARGET_BUILD_PDK),)
-...
-endif
-</pre>
-  </li>
-  <li>For building Android framework apps, the PDK uses the
-  <code>TARGET_BUILD_JAVA_SUPPORT_LEVEL</code> variable to notify you if building apps is
-  supported. The variable is set to <code>platform</code> if the platform APIs are available. The
-  variable is set to <code>sdk</code> when only SDK based builds are supported. Because the PDK is
-  shared pre-release and is based on a development tree, earlier versions of the PDK may not
-  support a Java build and the variable is set to null. The following statements can enable a Java
-  build only when it is supported:
-    <pre>
-ifneq ($(TARGET_BUILD_JAVA_SUPPORT_LEVEL),)
-...
-endif
-</pre>
-  </li>
-
-  <li style="list-style: none">
-    <p class="note">
-      <strong>Note:</strong> You cannot use <code>TARGET_BUILD_...</code> variables in product
-      definition Makefiles, because these variables are checked after the build reads the product
-      definition Makefiles.
-    </p>
-  </li>
-</ul>
diff --git a/src/devices/build_system.jd b/src/devices/build_system.jd
deleted file mode 100644
index 19fd8a31..00000000
--- a/src/devices/build_system.jd
+++ /dev/null
@@ -1,179 +0,0 @@
-page.title=Building the PDK
-@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 id="auto-toc">
-    </ol>
-  </div>
-</div>
-
-<p>Android uses a custom build system to generate tools, binaries, and documentation.</p>
-
-<p>The build system is Make-based and requires a recent version of GNU Make (note that
-  Android uses advanced features of GNU Make that may not yet appear on the GNU Make web site).
-  Before continuing, check your version of make by running <code>% make -v</code>. If you
-  don't have version 3.80 or greater, you need to
-  <a href="http://www.gnu.org/software/make/">upgrade your version of make</a>.
-</p>
-
-
-<h2 id="layers">Build Layers</h2>
-
-<p>The build hierarchy includes the abstraction layers that correspond to the physical makeup of a device. These
-  layers are described in the table below. Each layer relates to the one above it in a one-to-many relationship.
-  For example, an architecture can have more than one board and each board can have more than one device.
-  You may define an element in a given layer as a specialization of an element in the same layer,
-  thus eliminating copying and simplifying maintenance.</p>
- 
-<table>
- <tbody><tr>
-  <th>Layer</th>
-  <th>Example</th>
-  <th>Description</th>
- </tr>
-  <tr>
-    <td>Product</td>
-    <td>myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk</td>
-    <td><p>The product layer defines the feature specification of a shipping product such as the modules to build,
-    locales supported, and the configuration for various locales. In other words, this is the name of the
-    overall product. Product-specific variables are defined in product definition Makefiles. A product 
-     can inherit from other product definitions,
-    which simplifies maintenance. A common method is to create a base product that contains features that apply
-    for all products, then creating product variants based on that base product. For example, you can have
-    two products that differ only by their radios (CDMA vs GSM) inherit from the same base product that does not define a radio.
-    <p>For a full list of product definition variables, see the
-    <a href="{@docRoot}devices/build_new_device.html#prod-def">Product Definition Files</a> section.</p>
-</td>
-
-  </tr>
-  <tr>
-    <td>Device</td>
-    <td>myDevice, myDevice_eu, myDevice_eu_lite</td>
-    <td>The device layer represents the physical layer of plastic on the device (i.e. the industrial design of the device). For example, North American devices probably include QWERTY keyboards whereas devices sold in France probably include AZERTY keyboards.</td>
-  </tr>
-  <tr>
-    <td>Board</td>
-    <td>sardine, trout, goldfish </td>
-    <td>The board layer represents the bare schematics of a product. This includes the peripherals on the board and their
-      configuraiton.</td>
-  </tr>
-  <tr>
-    <td>Arch</td>
-    <td>arm (armv7-a-neon, armv7), x86, 68k </td>
-    <td>The architecture layer describes the processor configuration and ABI (Application Binary Interface) running on the board. </td>
-  </tr>
-</table>
-
-
-<h2 id="variants">Build Variants</h2>
-
-<p> 
-When building for a particular product, it's often useful to have minor
-variations on what is ultimately the final release build.  These are the
-currently-defined build variants:
-</p> 
- 
-<table border=1> 
-<tr> 
-    <td> 
-        <code>eng<code> 
-    </td> 
-    <td> 
-        This is the default flavor. A plain <code>make</code> is the
-        same as <code>make eng</code>.
-        <ul> 
-        <li>Installs modules tagged with: <code>eng</code>, <code>debug</code>,
-            <code>user</code>, and/or <code>development</code>.
-        <li>Installs non-APK modules that have no tags specified.
-        <li>Installs APKs according to the product definition files, in
-            addition to tagged APKs.
-        <li><code>ro.secure=0</code> 
-        <li><code>ro.debuggable=1</code> 
-        <li><code>ro.kernel.android.checkjni=1</code> 
-        <li><code>adb</code> is enabled by default.
-    </td> 
-</tr> 
-<tr>
-    <td>
-        <code>user<code>
-    </td>
-    <td>
-        <code>make user</code>
-        <p> 
-        This is the flavor intended to be the final release bits.
-        <ul> 
-        <li>Installs modules tagged with <code>user</code>.</li>
-        <li>Installs non-APK modules that have no tags specified.</li>
-        <li>Installs APKs according to the product definition files; tags
-            are ignored for APK modules.</li>
-        <li><code>ro.secure=1</code> </li>
-        <li><code>ro.debuggable=0</code> </li>
-        <li><code>adb</code> is disabled by default.</li>
-    </td>
-</tr>
-<tr>
-    <td>
-        <code>userdebug<code> 
-    </td> 
-    <td> 
-        <code>make userdebug</code>
-        <p> 
-        The same as <code>user</code>, except:
-        <ul> 
-        <li>Also installs modules tagged with <code>debug</code>.
-        <li><code>ro.debuggable=1</code> 
-        <li><code>adb</code> is enabled by default.
-    </td> 
-</tr> 
-</table> 
-
-<p class="note"><strong>Note:</strong> 
-If you build one flavor and then want to build another, you should run
-<code>make installclean</code> between the two makes to guarantee that
-you don't pick up files installed by the previous flavor.  <code>make
-clean</code> also suffices, but it takes a lot longer.
-</p>
-
-<h2 id="pdk-build">The PDK Build</h2>
-<p>The PDK build differs from a normal platform build in that it does not contain the entire Android source tree.
-  A <code>platform.zip</code> binary is provided that contains the missing pieces that aren't in the PDK source tree.
-  The PDK supports two different build flavors, Fusion and non-Fusion:
-</p>
-<ul>
-  <li>The Fusion build includes the <code>platform.zip</code>
-  components and allows your device to boot up into a usable Android system with a UI.
-  </li>
-  <li>The non-Fusion build omits the <code>platform.zip</code> components and boots
-  your device without a UI. In this mode,
-  you can <code>adb shell</code> into the device to run command line programs to test your
-  hardware in the early stages of development. This is useful when you only have a few HAL
-  implementations and drivers to test initially.
-  </li>
-</ul>
-
-  <h3 id="running-pdk-build">Running a default PDK build</h3>
-<p>When you have the PDK source synced, you can run a default build for the PDK to verify that your environment
-  is setup correctly. To do this, run the following commands:</p>
-
-<pre>
-source build/envsetup.sh
-lunch mini_armv7a_neon-userdebug
-PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/platform/platform.zip make -j32
-</pre>
\ No newline at end of file
diff --git a/src/devices/compatibility.jd b/src/devices/compatibility.jd
deleted file mode 100644
index 3c43041c..00000000
--- a/src/devices/compatibility.jd
+++ /dev/null
@@ -1,197 +0,0 @@
-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 id="auto-toc">
-    </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/devices/devices_toc.cs b/src/devices/devices_toc.cs
index c66d8918..eadd823a 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -13,7 +13,7 @@
     See the License for the specific language governing permissions and
     limitations under the License.
 -->
-<?cs # Table of contents for Dev pdk.?>
+<?cs # Table of contents for devices.?>
 <ul id="nav">
 
 <!-- Porting Android -->
@@ -22,7 +22,7 @@
       <a href="<?cs var:toroot ?>devices/index.html">
         <span class="en">Porting</span>
       </a>
-    </div>    
+    </div>
     <ul>
       <li><a href="<?cs var:toroot ?>devices/media.html">Media</a></li>
       <li class="nav-section">
@@ -53,7 +53,7 @@
 <!-- End Porting Android -->
   </li>
 
-  
+
   <li class="nav-section">
     <div class="nav-section-header">
       <a href="<?cs var:toroot ?>devices/tech/index.html">
@@ -131,14 +131,14 @@
           <li><a href="<?cs var:toroot ?>devices/tech/input/validate-keymaps.html">Validate Keymaps</a></li>
         </ul>
       </li>
-      
-      <li>      
+
+      <li>
           <a href="<?cs var:toroot ?>devices/tech/kernel.html">
             <span class="en">Kernel</span>
           </a>
       </li>
-      
-      <li>      
+
+      <li>
           <a href="<?cs var:toroot ?>devices/tech/power.html">
             <span class="en">Power</span>
           </a>
@@ -150,14 +150,14 @@
             </a>
           </div>
           <ul>
-            <li>      
+            <li>
               <a href="<?cs var:toroot ?>devices/tech/security/enhancements.html">
                 <span class="en">Security Enhancements in Android 4.2</span>
               </a>
             </li>
           </ul>
       </li>
-      
+
 
       <li class="nav-section">
         <div class="nav-section-header">
diff --git a/src/devices/getting_started.jd b/src/devices/getting_started.jd
deleted file mode 100644
index df4fe897..00000000
--- a/src/devices/getting_started.jd
+++ /dev/null
@@ -1,200 +0,0 @@
-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 id="auto-toc">
-    </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="{@docRoot}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 the following sections:</p>
-  <ul>
-    <li><a href="{@docRoot}devices/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}devices/porting.html">Porting</a> - Explains the various HALs provided by Android
-    and the interfaces (C header files) that define them. This section also provides reference documentation
-    for the various HAL interfaces.</li>
-    <li><a href="{@docRoot}devices/debugtune.html">Debugging and Tuning</a> - Explains the debugging and tuning features of the PDK.</li>
-    <li><a href="{@docRoot}devices/tech/index.html">Technical Information</a> - Explains important concepts of the Android platform.</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 <a href="{@docRoot}compatibility/index.html">Compatibility</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/devices/index.jd b/src/devices/index.jd
index a54d3396..d19f23c0 100644
--- a/src/devices/index.jd
+++ b/src/devices/index.jd
@@ -27,14 +27,14 @@ page.title=Porting Android to Devices
   <p>Android provides you with the freedom to implement your own device specifications
   and the drivers to support them. The hardware abstraction layer (HAL) gives you a
   standard way to create software hooks in between the Android
-  platform stack and your hardware. In addition, the Android operating system 
+  platform stack and your hardware. In addition, the Android operating system
   is open-sourced to help you through your device's bringup.</p>
 
   <p>To ensure that your devices maintain a high level of quality and offers a consistent
   experience for your users, they must must also
   pass the tests in the compatibility test suite (CTS). CTS ensures that anyone
   building a device meets a quality standard that ensures apps run reliabaly well
-  and gives users a good experience. For more information, see the 
+  and gives users a good experience. For more information, see the
   <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p>
 
  <h2>Android Low-Level System Architecture</h2>
@@ -62,19 +62,19 @@ level view of how Android works:
   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." 
+  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 
+    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.
@@ -90,9 +90,7 @@ level view of how Android works:
   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
+  These additions have less to do with driver development than with the system's functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend
   using the latest version of the Android kernel. For the latest Android kernel, see
   <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
 </p>
\ No newline at end of file
diff --git a/src/devices/overview.jd b/src/devices/overview.jd
deleted file mode 100644
index ddb34b9e..00000000
--- a/src/devices/overview.jd
+++ /dev/null
@@ -1,198 +0,0 @@
-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>
-    </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/devices/porting.jd b/src/devices/porting.jd
deleted file mode 100644
index e0b6eb8f..00000000
--- a/src/devices/porting.jd
+++ /dev/null
@@ -1,98 +0,0 @@
-page.title=Porting
-@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 id="auto-toc">
-    </ol>
-  </div>
-</div>
-
-  <p>Android provides you with the freedom to implement your own device specifications
-  and the drivers to support them. The hardware abstraction layer (HAL) gives you a
-  standard way to create software hooks in between the Android
-  platform stack and your hardware. In addition, the Android operating system 
-  is open-sourced to help you through your device's bringup.</p>
-
-  <p>To ensure that your devices maintain a high level of quality and offers a consistent
-  experience for your users, they must must also
-  pass the tests in the compatibility test suite (CTS). CTS ensures that anyone
-  building a device meets a quality standard that ensures apps run reliabaly well
-  and gives users a good experience. For more information, see the 
-  <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p>
-
- <h2>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. 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="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
-</p>
\ No newline at end of file
diff --git a/src/devices/source.jd b/src/devices/source.jd
deleted file mode 100644
index 0b9bc7ae..00000000
--- a/src/devices/source.jd
+++ /dev/null
@@ -1,72 +0,0 @@
-page.title=Getting the Source
-@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>
-  Before you can use the PDK, ensure that your <a href="{@docRoot}source/initializing.html">build environment
-  is set up</a>. When you are done, follow these steps to obtain the Android PDK source:
-</p>
-<ol>
-  <li>
-    <a href=
-    "https://accounts.google.com/SignUp?continue=https%3A%2F%2Faccounts.google.com%2FManageAccount">
-    Create a Google Account</a> with a corporate email address (e.g. @htc.com or @motorola.com and
-    not @gmail.com) for each individual who needs access to the partner source server. This should
-    be a relatively small number of users.
-  </li>
-  <li>Sign into the <a href="https://partner-android-review.googlesource.com">Android Gerrit
-  server</a> with the Google Account you just created and go to <strong>Settings &gt; HTTP Password
-  &gt; Obtain Password</strong> to get a password that you can use to authenticate to the Android
-  source servers. Follow the directions on that page for more information.
-  </li>
-  <li>Send a list of the Google Accounts that were created to Google to add them to our access
-  list.
-  </li>
-  <li>There are four variants of the source that you can sync to. For armv7a, run the following commands:
-<pre>
-repo init -u https://partner-android.googlesource.com/platform/vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/manifest.git -b &lt;branch_name&gt;
-repo sync
-</pre>
-<p>For armv7a with NEON support, run the following commands:</p>
-<pre>
-repo init -u https://partner-android.googlesource.com/platform/vendor/pdk/mini_armv7a/mini_armv7a-userdebug/manifest.git -b &lt;branch_name&gt;
-repo sync 
-</pre>
-<p>For MIPS, run the following commands:</p>
-<pre>
-repo init -u https://partner-android.googlesource.com/a/platform/vendor/pdk/mini_mips/mini_mips-userdebug/manifest.git -b &lt;branch_name&gt;
-repo sync 
-</pre>
-<p>For x86, run the following commands:</p>
-<pre>
-repo init -u https://partner-android.googlesource.com/a/platform/vendor/pdk/mini_x86/mini_x86-userdebug/manifest.git -b &lt;branch_name&gt;
-repo sync 
-</pre>
-
-<p>For example, use the <code>jb-mr1-release</code> branch for the PDK release for Jelly Bean MR1.</p>
-</li>
-</ol>
-
-
-<p class="note"><strong>Note:</strong> The PDK repository might be updated many times a day,
-  so it might be a good idea to sync less often if bandwidth is a concern.
-  It is usually more beneficial to sync more frequently at the early development phases of a new platform release
-  as more drastic changes can happen. Additionally, any PDK repository update results in an
-  updated <code>manifest.xml</code> so if you manually change the <code>manifest.xml</code>
-to add your own projects, this blocks syncing of the repository.
-A solution to both these issues is to have a local repository set up that syncs with the PDK
-  repository and then have your developers sync with your local repository and not the main PDK one.</p>
\ No newline at end of file
diff --git a/src/index.jd b/src/index.jd
index d977612e..044d7386 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -24,7 +24,7 @@ header.hide=1
 
   <div class="landing-banner">
       <h1 itemprop="name" style="margin-bottom:0;">Welcome to the Android Open Source Project!</h1>
-      
+
       <p>
       Android is an open-source software stack for a wide range of devices and a corresponding open-source project led by Google.
       Here you can find the information and source code you need to learn more about the Android platform. From there you can
@@ -62,15 +62,13 @@ header.hide=1
       </a>
       <a href="{@docRoot}devices/index.html">
         <h4>Build Devices</h4>
-        <p>The Android PDK lets you build devices with the latest Android platform, before
-          it is released to the public. This gives you a headstart on creating the compelling
-          devices that your customers want.</p>
+        <p>Build devices with the latest Android platform and create
+        create compelling devices that your customers want.</p>
       </a>
 
       <a href="{@docRoot}accessories/index.html">
         <h4>Build Accessories</h4>
-        <p>Sometimes, a device can't do it all. Tap into Android's open accessory standard and
-          build accessories to complement the wide variety of Android-powered devices.</p>
+        <p>Sometimes, a device can't do it all. Tap into Android's open accessory standard and build accessories to complement the wide variety of Android-powered devices.</p>
       </a>
 
       <a href="{@docRoot}compatibility/index.html">
diff --git a/src/source/source_toc.cs b/src/source/source_toc.cs
index 969a4fa3..d2b1464d 100644
--- a/src/source/source_toc.cs
+++ b/src/source/source_toc.cs
@@ -12,14 +12,14 @@
     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.?>
+--><?cs # Table of contents for source.?>
 <ul id="nav">
   <li class="nav-section">
     <div class="nav-section-header">
       <a href="<?cs var:toroot ?>source/index.html">
         <span class="en">Overview</span>
       </a>
-    </div>    
+    </div>
     <ul>
       <li><a href="<?cs var:toroot ?>source/code-lines.html">Codelines, Branches, and Releases</a></li>
       <li><a href="<?cs var:toroot ?>source/build-numbers.html">Codenames, Tags, and Build Numbers</a></li>
@@ -37,7 +37,7 @@
         </a>
       </div>
        <ul>
-        <li><a href="<?cs var:toroot ?>source/initializing.html">Initializing the Build Environment</a></li>        
+        <li><a href="<?cs var:toroot ?>source/initializing.html">Initializing the Build Environment</a></li>
         <li><a href="<?cs var:toroot ?>source/downloading.html">Downloading the Source</a></li>
         <li><a href="<?cs var:toroot ?>source/building-running.html">Building and Running</a></li>
         <li><a href="<?cs var:toroot ?>source/building-devices.html">Building for Devices</a></li>