diff --git a/src/accessories/index.html b/src/accessories/index.html
new file mode 100644
index 0000000..a6502a5
--- /dev/null
+++ b/src/accessories/index.html
@@ -0,0 +1,7 @@
+<!DOCTYPE HTML>
+<html>
+<head>
+<title>Android</title>
+<meta http-equiv="REFRESH" content="0;url=/tech/accessories/index.html">
+</head>
+</html>
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.2/android-4.2-cdd.pdf b/src/compatibility/4.2/android-4.2-cdd.pdf
new file mode 100755
index 0000000..9ea111b
--- /dev/null
+++ b/src/compatibility/4.2/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.2/versions.md b/src/compatibility/4.2/versions.md
new file mode 100644
index 0000000..90c166f
--- /dev/null
+++ b/src/compatibility/4.2/versions.md
@@ -0,0 +1,32 @@
+<!--
+   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.2 #
+
+As described in Section 3.2.2 of the [Android 4.2 Compatibility Definition](/cdds/android-4.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 4.2-based system. The only permitted values for
+`android.os.Build.VERSION.RELEASE` for Android 4.2 are:
+
+- 4.2
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..9ea111b
--- /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/cts-development.md b/src/compatibility/cts-development.md
index ea43d1c..78996a7 100644
--- a/src/compatibility/cts-development.md
+++ b/src/compatibility/cts-development.md
@@ -19,7 +19,7 @@
 ## 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`
+to get and build the Android source code but specify `-b android-4.2_r1`
 when issuing the `repo init` command. This assures that your CTS
 changes will be included in the next CTS release and beyond.
 
@@ -48,7 +48,7 @@
 
 At the cts-tf console, enter e.g.:
 
-    run cts --plan CTS -p android.os.cts.BuildVersionTest
+    run cts --plan CTS
 
 ## Writing CTS Tests ##
 
diff --git a/src/compatibility/downloads.md b/src/compatibility/downloads.md
index 8f2dcf7..05d8d36 100644
--- a/src/compatibility/downloads.md
+++ b/src/compatibility/downloads.md
@@ -19,6 +19,16 @@
 Thanks for your interest in Android Compatibility! The links below allow
 you to access the key documents and information.
 
+## Android 4.2 ##
+
+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.
+
+- [Android 4.2 Compatibility Definition Document (CDD)](4.2/android-4.2-cdd.pdf)
+- [Android 4.2 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.2_r1-linux_x86-arm.zip)
+- [Android 4.2 R1 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.2_r1-linux_x86-arm.zip)
+
 ## Android 4.1 ##
 
 Android 4.1.1 is the release of the development milestone code-named
@@ -83,7 +93,7 @@
 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)
+- [Compatibility Test Suite (CTS) User Manual](android-cts-manual-r6.pdf)
 
 ## CTS Media Files ##
 These media files are required for the CTS media stress tests.
diff --git a/src/compatibility/overview.md b/src/compatibility/overview.md
index 627334c..d691cfc 100644
--- a/src/compatibility/overview.md
+++ b/src/compatibility/overview.md
@@ -102,7 +102,7 @@
 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).
+simply examine [the latest CDD](4.2/android-4.2-cdd.pdf).
 
 # Compatibility Test Suite (CTS) #
 
diff --git a/src/compatibility/sidebar.md b/src/compatibility/sidebar.md
index 9df9f50..1745dc7 100644
--- a/src/compatibility/sidebar.md
+++ b/src/compatibility/sidebar.md
@@ -1,6 +1,6 @@
 # Getting Started #
 - [Compatibility Overview](/compatibility/overview.html)
-- [Current CDD](/compatibility/4.1/android-4.1-cdd.pdf)
+- [Current CDD](/compatibility/4.2/android-4.2-cdd.pdf)
 - [CTS Introduction](/compatibility/cts-intro.html)
 - [CTS Development](/compatibility/cts-development.html)
 
diff --git a/src/source/build-numbers.md b/src/source/build-numbers.md
index 807152f..9a248dd 100644
--- a/src/source/build-numbers.md
+++ b/src/source/build-numbers.md
@@ -43,6 +43,7 @@
 Ice Cream Sandwich | 4.0.1 - 4.0.2 | API level 14, NDK 7
 Ice Cream Sandwich | 4.0.3 - 4.0.4 | API level 15, NDK 8
 Jelly Bean       | 4.1.x         | API level 16
+Jelly Bean       | 4.2.x         | API level 17
 
 Starting with Cupcake, individual builds are identified with a short
 build code, e.g. FRF85B.
@@ -110,8 +111,8 @@
 ITL41F | android-4.0.1_r1.2 | Galaxy Nexus
 ICL53F | android-4.0.2_r1   | Galaxy Nexus
 IML74K | android-4.0.3_r1   | Nexus S
-IML77  | android-4.0.3_r1.1 |
-IMM76  | android-4.0.4_r1   |
+IML77  | android-4.0.3_r1.1
+IMM76  | android-4.0.4_r1
 IMM76D | android-4.0.4_r1.1 | Nexus S, Nexus S 4G, Galaxy Nexus
 IMM76I | android-4.0.4_r1.2 | Galaxy Nexus
 IMM76K | android-4.0.4_r2   | Galaxy Nexus
@@ -119,10 +120,17 @@
 JRO03C | android-4.1.1_r1   | earliest Jelly Bean version, Galaxy Nexus
 JRO03D | android-4.1.1_r1.1 | Nexus 7
 JRO03E | android-4.1.1_r2   | Nexus S
-JRO03H | android-4.1.1_r3   |
-JRO03L | android-4.1.1_r4   | latest Jelly Bean version, Nexus S
+JRO03H | android-4.1.1_r3
+JRO03L | android-4.1.1_r4   | Nexus S
+JRO03O | android-4.1.1_r5   | Galaxy Nexus
+JRO03R | android-4.1.1_r6   | Nexus S 4G
+JRO03S | android-4.1.1_r6.1 | Nexus 7
+JZO54K | android-4.1.2_r1   | Nexus S, Galaxy Nexus, Nexus 7
+JOP40C | android-4.2_r1     | Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10
+JOP40D | android-4.2.1_r1   | latest Jelly Bean version, Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10
 
 The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
+jb-mr1-dev,
 represent development
 branches that do not exactly match configurations that were tested
 by Google. They might contain a variety of changes in addition to
diff --git a/src/source/building-devices.md b/src/source/building-devices.md
index 9c2ab82..18055ba 100644
--- a/src/source/building-devices.md
+++ b/src/source/building-devices.md
@@ -19,28 +19,38 @@
 This page complements the main page about [Building](building.html) with
 information that is specific to individual devices.
 
-With the current release, it is possible to build for Nexus 7, for some
-variants of Galaxy Nexus, for a variant of the Motorola Xoom, and for
-all variants of Nexus S and Nexus S 4G. The exact level of functionality
-for each device depends on the availability of the relevant proprietary
-hardware-specific binaries.
+With the current release, it is possible to build for
+Nexus 10, for Nexus 7 (Wi-Fi), and for some variants of Galaxy Nexus.
+The exact level of functionality for each device depends on the availability
+of the relevant proprietary hardware-specific binaries.
 
-All variants of Nexus 7 can be used. On Nexus 7, graphics and audio are
-functional, as well as WiFi and Bluetooth.
+All configurations of Nexus 10 can be used. On those devices, graphics, audio,
+Wi-Fi, Bluetooth, camera, NFC, GPS and orientation sensors are functional.
 
-The variants of Galaxy Nexus that be used are the GSM/HSPA+ configuration
+Nexus 4 cannot be used at the moment.
+
+The Wi-Fi variants of Nexus 7 can be used. On Nexus 7, graphics and audio are
+functional, as well as Wi-Fi and Bluetooth. Due to hardware differences, do
+not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2 or newer.
+The Mobile variant is not supported.
+
+The variants of Galaxy Nexus that can be used are the GSM/HSPA+ configuration
 "maguro" (only if it was originally sold with a "yakju" or "takju" operating
 system) and the VZW CDMA/LTE configuration "toro". On those devices, graphics
-and audio are functional, as well as WiFi, Bluetooth, and access to the
-respective cellular networks. The orientation sensors are functional.
+and audio are functional, as well as Wi-Fi, Bluetooth, and access to the
+respective cellular networks. NFC and the orientation sensors are functional.
 
-The Motorola Xoom is can be used in the Wi-Fi configuration "wingray"
-sold in the USA. Graphics and audio are functional as well as WiFi and
-Bluetooth and the orientation sensors.
+The Sprint CDMA/LTE configuration "toroplus" of Galaxy Nexus is supported
+experimentally. On that configuration, the cellular network is not functional,
+and the other peripherals work like they do on "toro".
 
-All configurations of Nexus S and Nexus S 4G can be used, and on those
-devices all the peripherals are functional: graphics, audio, Wifi, Bluetooth,
-cell networks, sensors, camera, hardware codecs, NFC, GPS.
+The Motorola Xoom can be used in the Wi-Fi configuration "wingray"
+sold in the USA, with Android 4.1.2. Graphics and audio are functional
+as well as Wi-Fi and Bluetooth and the orientation sensors.
+
+All configurations of Nexus S and Nexus S 4G can be used with Android 4.1.2.
+On those devices all the peripherals are functional: graphics, audio, Wi-Fi,
+Bluetooth, cell networks, sensors, camera, hardware codecs, NFC, GPS.
 
 In addition, [PandaBoard](http://pandaboard.org) a.k.a. "panda" can be used
 in the master branch, but is considered experimental.
@@ -70,16 +80,18 @@
 
 Device   | Keys
 ---------|------
+manta    | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
+mako     | Press and hold *Volume Down*, then press and hold *Power*
 grouper  | Press *Power* for a second, and press *Volume Down* when the bootloader logo appears
+tilapia  | Press *Power* for a second, and press *Volume Down* when the bootloader logo appears
+phantasm | Power the device, cover it with one hand after the LEDs light up and until they turn red
 maguro   | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
 toro     | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
+toroplus | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
 panda    | Press and hold *Input*, then press *Power*
 wingray  | Press and hold *Volume Down*, then press and hold *Power*
 crespo   | Press and hold *Volume Up*, then press and hold *Power*
 crespo4g | Press and hold *Volume Up*, then press and hold *Power*
-passion  | Press and hold the trackball, then press *Power*
-sapphire | Press and hold *Back*, then press *Power*
-dream    | Press and hold *Back*, then press *Power*
 
 Also, the command `adb reboot bootloader` can be used to reboot from
 Android directly into the bootloader with no key combinations.
@@ -88,10 +100,7 @@
 
 It's only possible to flash a custom system if the bootloader allows it.
 
-This is the default setup on ADP1 and ADP2.
-
-On Nexus One, Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-the bootloader is locked by default. With the device in fastboot mode, the
+The bootloader is locked by default. With the device in fastboot mode, the
 bootloader is unlocked with
 
     $ fastboot oem unlock
@@ -99,17 +108,18 @@
 The procedure must be confirmed on-screen, and deletes the user data for
 privacy reasons. It only needs to be run once.
 
-Note that on the Nexus S, Nexus S 4G, Motorola Xoom, Galaxy Nexus,
-and on Nexus 7,
-all data on the phone is erased, i.e. both the applications' private data
+All data on the phone is erased, i.e. both the applications' private data
 and the shared data that is accessible over USB, including photos and
 movies. Be sure to make a backup of any precious files you have before
 unlocking the bootloader.
 
-On Nexus One, the operation voids the warranty and is irreversible.
+On Nexus 10, after unlocking the bootloader, the internal storage is
+left unformatted and must be formatted with
 
-On Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-the bootloader can be locked back with
+    $ fastboot format cache
+    $ fastboot format userdata
+
+The bootloader can be locked back with
 
     $ fastboot oem lock
 
@@ -117,11 +127,12 @@
 
 ## Obtaining proprietary binaries ##
 
-Starting with Ice Cream Sandwich, the Android Open-Source Project can't be used
+The Android Open-Source Project can't be used
 from pure source code only, and requires additional hardware-related proprietary
 libraries to run, specifically for hardware graphics acceleration.
 
-Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, and PandaBoard
+Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, Nexus 4,
+Nexus 10 and PandaBoard
 can be downloaded from
 [Google's Nexus driver page](https://developers.google.com/android/nexus/drivers),
 which add access to additional hardware capabilities with non-Open-Source code.
@@ -130,8 +141,6 @@
 recent numbered release are the ones that should be used in the master
 branch.
 
-There are limited binaries for Nexus One, and none for ADP2 or ADP1.
-
 ### Extracting the proprietary binaries ###
 
 Each set of binaries comes as a self-extracting script in a compressed archive.
@@ -158,16 +167,19 @@
 
 Device   | Branch                       | Build configuration
 ---------|------------------------------|------------------------
-grouper  | android-4.1.1_r4 or master   | full_grouper-userdebug
-maguro   | android-4.1.1_r4 or master   | full_maguro-userdebug
-toro     | android-4.1.1_r4 or master   | full_toro-userdebug
+manta    | android-4.2.1_r1 or master   | full_manta-userdebug
+grouper  | android-4.2.1_r1 or master   | full_grouper-userdebug
+tipalia  | android-4.2.1_r1 or master   | full_tilapia-userdebug
+maguro   | android-4.2.1_r1 or master   | full_maguro-userdebug
+toro     | android-4.2.1_r1 or master   | full_toro-userdebug
+toroplus | master                       | full_toroplus-userdebug
 panda    | master                       | full_panda-userdebug
-wingray  | android-4.1.1_r4 or master   | full_wingray-userdebug
-crespo   | android-4.1.1_r4 or master   | full_crespo-userdebug
-crespo4g | android-4.1.1_r4 or master   | full_crespo4g-userdebug
-passion  | android-2.3.7_r1             | full_passion-userdebug
-sapphire | android-2.2.3_r1             | full_sapphire-userdebug
-dream    | android-2.2.3_r1             | full_dream-userdebug
+wingray  | android-4.1.2_r1             | full_wingray-userdebug
+crespo   | android-4.1.2_r1             | full_crespo-userdebug
+crespo4g | android-4.1.2_r1             | full_crespo4g-userdebug
+
+Do not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2
+or newer.
 
 ## Flashing a device ##
 
@@ -192,13 +204,15 @@
 ## Restoring a device to its original factory state ##
 
 Factory images
-for Nexus 7,
-for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju", and CDMA/LTE "mysid"),
+for Nexus 10,
+for Nexus 4,
+for Nexus Q,
+for Nexus 7 (all variants),
+for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju",
+and CDMA/LTE "mysid" and "mysidspr"),
 and
 for Nexus S and Nexus S 4G (all variants)
 are available from
 [Google's factory image page](https://developers.google.com/android/nexus/images).
 
 Factory images for the Motorola Xoom are distributed directly by Motorola.
-
-No factory images are available for Nexus One.
diff --git a/src/source/building-kernels.md b/src/source/building-kernels.md
index 5c3709d..f62483b 100644
--- a/src/source/building-kernels.md
+++ b/src/source/building-kernels.md
@@ -54,16 +54,16 @@
 
   - The `goldfish` project contains the kernel sources for the emulated
 platforms.
-  - The `msm` project has the sources for ADP1, ADP2, Nexus One, and
-can be used as a starting point for work on Qualcomm MSM chipsets.
-  - The `omap` project is used for PandaBoard and Galaxy Nexus, and
-can be used as a starting point for work on TI OMAP chipsets.
-  - The `samsung` project is used for Nexus S and can be used as a
-starting point for work on Samsung Hummingbird chipsets.
-  - The `tegra` project is for Xoom and Nexus 7, and can be used as
-a starting point for work on NVIDIA Tegra chipsets.
-  - The `exynos` project can be used as a starting point for work
-on Samsung Exynos chipsets.
+  - The `msm` project has the sources for ADP1, ADP2, Nexus One, Nexus 4,
+and can be used as a starting point for work on Qualcomm MSM chipsets.
+  - The `omap` project is used for PandaBoard and Galaxy Nexus,
+and can be used as a starting point for work on TI OMAP chipsets.
+  - The `samsung` project is used for Nexus S,
+and can be used as a starting point for work on Samsung Hummingbird chipsets.
+  - The `tegra` project is for Xoom and Nexus 7,
+and can be used as a starting point for work on NVIDIA Tegra chipsets.
+  - The `exynos` project has the kernel sources for Nexus 10,
+and can be used as a starting point for work on Samsung Exynos chipsets.
 
 ## Downloading a prebuilt gcc ##
 
@@ -88,6 +88,9 @@
 To build the tuna kernel, you may run the previous commands replacing all
 instances of "panda" with "tuna".
 
+  - The kernel for mantaray is `device/samsung/manta/kernel`
+  - The kernel for mako is `device/lge/mako-kernel/kernel`
+  - The kernel for grouper and tilapia is `device/asus/grouper/kernel`
   - The kernel for maguro and toro is `device/samsung/tuna/kernel`
   - The kernel for crespo and crespo4g is `device/samsung/crespo/kernel`
   - The kernel for stingray and wingray is `device/moto/wingray/kernel`
diff --git a/src/source/initializing.md b/src/source/initializing.md
index 266900a..cad530a 100644
--- a/src/source/initializing.md
+++ b/src/source/initializing.md
@@ -152,10 +152,14 @@
     SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d00f", MODE="0600", OWNER="<username>"
     # usbboot protocol on panda (PandaBoard ES)
     SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d010", MODE="0600", OWNER="<username>"
-    # adb protocol on grouper (Nexus 7)
+    # adb protocol on grouper/tilapia (Nexus 7)
     SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0600", OWNER="<username>"
-    # fastboot protocol on grouper (Nexus 7)
+    # fastboot protocol on grouper/tilapia (Nexus 7)
     SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", MODE="0600", OWNER="<username>"
+    # adb protocol on mako/manta (Nexus 4, Nexus 10)
+    SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0600", OWNER="<username>"
+    # fastboot protocol on mako/manta (Nexus 4, Nexus 10)
+    SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="0600", OWNER="<username>"
 
 Those new rules take effect the next time a device is plugged in.
 It might therefore be necessary to unplug the device and plug it
diff --git a/src/source/known-issues.md b/src/source/known-issues.md
index 74579de..c2cfb22 100644
--- a/src/source/known-issues.md
+++ b/src/source/known-issues.md
@@ -154,9 +154,9 @@
 involved, disable anti-virus on the Android tree. This has
 the added benefit of reducing build times.
 
-## Camera, GPS and NFC don't work on Galaxy Nexus. ##
+## Camera and GPS don't work on Galaxy Nexus. ##
 
-**Symptom**: Camera, GPS and NFC don't work on Galaxy Nexus.
+**Symptom**: Camera and GPS don't work on Galaxy Nexus.
 As an example, the Camera application crashes as soon as it's
 launched.
 
diff --git a/src/tech/accessories/aoap/aoa.md b/src/tech/accessories/aoap/aoa.md
new file mode 100644
index 0000000..e806eaf
--- /dev/null
+++ b/src/tech/accessories/aoap/aoa.md
@@ -0,0 +1,135 @@
+# Android Open Accessory Protocol 1.0 #
+
+An Android USB accessory must adhere to Android Accessory Protocol, which defines how
+an accessory detects and sets up communication with an Android-powered device. In general, an
+accessory should carry out the following steps:
+
+- Wait for and detect connected devices
+- Determine the device's accessory mode support
+- Attempt to start the device in accessory mode if needed
+- Establish communication with the device if it supports the Android accessory protocol
+
+The following sections explain how to implement these steps.
+
+## Wait for and Detect Connected Devices ##
+
+Your accessory should have logic to continuously check for connected Android-powered devices.
+When a device is connected, your accessory should determine if the device supports accessory mode.
+
+
+## Determine Accessory Mode Support ##
+
+When an Android-powered device is connected, it can be in one of three states:
+
+- The attached device supports Android accessory mode and is already in accessory mode.
+- The attached device supports Android accessory mode, but it is not in accessory mode.
+- The attached device does not support Android accessory mode.
+
+During the initial connection, the accessory should check the vendor and product IDs of the
+connected device's USB device descriptor. The vendor ID should match Google's ID (`0x18D1`) and the
+product ID should be `0x2D00` or `0x2D01` if the device is already in accessory mode (case A). If
+so, the accessory can now
+[establish communication with the device](#establish-communication-with-the-device) through
+bulk transfer endpoints with its own communication protocol. There is no need to start the device
+in accessory mode.
+
+**Note:** `0x2D00` is reserved for Android-powered devices that
+support accessory mode. `0x2D01` is reserved for devices that support accessory mode as well as the
+ADB (Android Debug Bridge) protocol, which exposes a second interface with two bulk endpoints for
+ADB. You can use these endpoints for debugging the accessory application if you are simulating
+the accessory on a computer. In general, do not use this interface unless your accessory is
+implementing a passthrough to ADB on the device.
+
+If the vendor and product ID do not match, there is no way to distinguish between states b and c, so
+the accessory [attempts to start the device in accessory mode](#attempt-to-start-in-accessory-mode)
+to determine if the device is supported.
+
+
+## Attempt to Start in Accessory Mode ##
+
+If the vendor and product IDs do not correspond to an Android-powered device in accessory
+mode, the accessory cannot discern whether the device supports accessory mode and is not in that
+state, or if the device does not support accessory mode at all. This is because devices that
+support accessory mode but aren't in it initially report the device's manufacturer vendor ID and
+product ID, and not the special Android Open Accessory ones. In either case, the accessory should
+try to start the device into accessory mode to figure out if the device supports it. The following
+steps explain how to do this:
+
+<ul>
+  <li>Send a 51 control request ("Get Protocol") to figure out if the device supports the Android
+  accessory protocol. A non-zero number is returned if the protocol is supported, which
+  represents the version of the protocol that the device supports (currently, only version 1
+  exists). This request is a control request on endpoint 0 with the following characteristics:
+
+<pre>
+requestType:    USB_DIR_IN | USB_TYPE_VENDOR
+request:        51
+value:          0
+index:          0
+data:           protocol version number (16 bits little endian sent from the
+                device to the accessory)
+</pre>
+  </li>
+  <li>If the device returns a proper protocol version, send identifying string information to the
+  device. This information allows the device to figure out an appropriate application for this
+  accessory and also present the user with a URL if an appropriate application does not exist.
+  These requests are control requests on endpoint 0 (for each string ID) with the following
+  characteristics:
+
+<pre>
+requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+request:        52
+value:          0
+index:          string ID
+data            zero terminated UTF8 string sent from accessory to device
+</pre>
+
+  <p>The following string IDs are supported, with a maximum size of 256 bytes for each string
+  (must be zero terminated with `\0`).</p>
+
+<pre>
+manufacturer name:  0
+model name:         1
+description:        2
+version:            3
+URI:                4
+serial number:      5
+</pre>
+  </li>
+  <li>When the identifying strings are sent, request the device start up in accessory mode. This
+  request is a control request on endpoint 0 with the following characteristics:
+
+<pre>
+requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+request:        53
+value:          0
+index:          0
+data:           none
+</pre>
+  </li>
+</ul>
+
+After sending the final control request, the connected USB device should re-introduce itself
+on the bus in accessory mode and the accessory can re-enumerate the connected devices. The
+algorithm jumps back to
+[determining the device's accessory mode support](#determine-accessory-mode-support)
+to check for the vendor and product ID. The vendor ID and product ID of the device will be
+different if the device successfully switched to accessory mode and will now correspond to
+Google's vendor and product IDs instead of the device manufacturer's IDs. The accessory can now
+[establish communication with the device](#establish-communication-with-the-device).
+
+If at any point these steps fail, the device does not support Android accessory mode and the
+accessory should wait for the next device to be connected.
+
+
+## Establish Communication with the Device ##
+
+If an Android-powered device in accessory mode is detected, the accessory can query the
+device's interface and endpoint descriptors to obtain the bulk endpoints to communicate with the
+device. An Android-powered device that has a product ID of `0x2D00` has one interface with two bulk
+endpoints for input and output communication. A device with product ID of `0x2D01` has two
+interfaces with two bulk endpoints each for input and output communication. The first interface
+is for standard communication while the second interface is for ADB communication. To communicate
+on an interface, all you need to do is find the first bulk input and output endpoints, set the
+device's configuration to a value of 1 with a `SET_CONFIGURATION` (`0x09`) device request, then
+communicate using the endpoints.
\ No newline at end of file
diff --git a/src/tech/accessories/aoap/aoa2.md b/src/tech/accessories/aoap/aoa2.md
new file mode 100644
index 0000000..803c6c5
--- /dev/null
+++ b/src/tech/accessories/aoap/aoa2.md
@@ -0,0 +1,200 @@
+# Android Open Accessory Protocol 2.0 #
+
+This document describes the changes to the Android Open Accessory (AOA) protocol since its
+initial release, and is a supplement to the documentation of the
+[first release of AOA](/tech/accessories/aoap/aoa.html).
+
+The Android Open Accessory Protocol 2.0 adds two new features: audio output (from the Android
+device to the accessory) and support for the accessory acting as one or more Human Interface Devices
+(HID) to the Android device. The Android SDK APIs available to Android application developers
+remain unchanged.
+
+
+## Detecting Android Open Accessory 2.0 Support ##
+
+In order for an accessory to determine if a connected Android device supports accessories and at
+what protocol level, the accessory must send a `getProtocol()` command and check the result.
+Android devices supporting the initial version of the Android Open Accessory protocol return a
+`1`, representing the protocol version number. Devices that support the new features described
+in this document must return `2` for the protocol version. Version 2.0 of the protocol is
+upwardly compatible, so accessories designed for the original accessory protocol still work
+with newer Android devices. The following example from the Accessory Development Kit 2011
+[source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+(`<adk-src>/adk1/board/AndroidAccessory/AndroidAccessory.cpp`) library demonstrates this protocol
+check:
+
+    bool AndroidAccessory::switchDevice(byte addr)
+    {
+        int protocol = getProtocol(addr);
+        if (protocol >= 1) {
+            Serial.print("device supports protocol 1 or higher\n");
+        } else {
+            Serial.print("could not read device protocol version\n");
+            return false;
+        }
+
+        sendString(addr, ACCESSORY_STRING_MANUFACTURER, manufacturer);
+        sendString(addr, ACCESSORY_STRING_MODEL, model);
+        sendString(addr, ACCESSORY_STRING_DESCRIPTION, description);
+        sendString(addr, ACCESSORY_STRING_VERSION, version);
+        sendString(addr, ACCESSORY_STRING_URI, uri);
+        sendString(addr, ACCESSORY_STRING_SERIAL, serial);
+
+        usb.ctrlReq(addr, 0, USB_SETUP_HOST_TO_DEVICE | USB_SETUP_TYPE_VENDOR |
+                    USB_SETUP_RECIPIENT_DEVICE, ACCESSORY_START, 0, 0, 0, 0, NULL);
+        return true;
+    }
+
+AOA 2.0 includes new USB product IDs, one for each combination of USB interfaces available when
+in accessory mode. The possible USB interfaces are:
+
+- **accessory** - An interface providing 2 bulk endpoints for communicating with an
+Android application.
+- **audio** - A new standard USB audio class interface for streaming audio
+from an Android device to an accessory.
+- **adb** - An interface intended only for debugging purposes while developing an
+accessory. Only enabled if the user has USB Debugging enabled in Settings on the Android device.
+
+
+In AOA 1.0, there are only two USB product IDs:
+
+- `0x2D00` - accessory
+- `0x2D01` - accessory + adb
+
+AOA 2.0 adds an optional USB audio interface and, therefore, includes product IDs for the new
+combinations of USB interfaces:
+
+- `0x2D02` - audio
+- `0x2D03` - audio + adb
+- `0x2D04` - accessory + audio
+- `0x2D05` - accessory + audio + adb
+
+
+## Audio Support ##
+
+AOA 2.0 includes optional support for audio output from an Android device to an accessory. This
+version of the protocol supports a standard USB audio class interface that is capable of 2 channel
+16-bit PCM audio with a bit rate of 44100 Khz. AOA 2.0 is currently limited to this output mode, but
+additional audio modes may be added in the future.
+
+To enable the audio support, the accessory must send a new USB control request:
+
+    **SET_AUDIO_MODE**
+    requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+    request:        58
+    value:          0 for no audio (default),
+                    1 for 2 channel, 16-bit PCM at 44100 KHz
+    index:          0
+    data            none
+
+This command must be sent _before_ sending the `ACCESSORY_START` command for
+entering accessory mode.
+
+
+## HID Support ##
+
+AOA 2.0 allows the accessory to register one or more USB Human Interface Devices (HID) with
+an Android device. This approach reverses the direction of communication for typical USB HID
+devices like USB mice and keyboards. Normally, the HID device is a peripheral connected to a USB
+host like a personal computer. But in the case of the AOA protocol, the USB host acts as one or more
+input devices to a USB peripheral.
+
+HID support in AOA 2.0 is simply a proxy for standard HID events. The implementation makes no
+assumptions about the content or type of events and merely passes it through to the input system,
+so an AOA 2.0 accessory can act as any HID device (mouse, keyboard, game controller, etc.). It
+can be used for something as simple as the play/pause button on a media dock, or something as
+complicated as a docking station with a mouse and full QWERTY keyboard.
+
+The AOA 2.0 protocol adds four new USB control requests to allow the accessory to act as one or
+more HID input devices to the Android device.  Since HID support is done entirely through
+control requests on endpoint zero, no new USB interface is needed to provide this support. The
+control requests are as follows:
+
+- **ACCESSORY_REGISTER_HID** registers a new HID device with the Android device.
+The accessory provides an ID number that is used to identify the HID device for the other three
+calls. This ID is valid until USB is disconnected or until the accessory sends
+`ACCESSORY_UNREGISTER_HID` to unregister the HID device.
+- **ACCESSORY_UNREGISTER_HID** unregisters a HID device that was previously
+registered with `ACCESSORY_REGISTER_HID`.
+- **ACCESSORY_SET_HID_REPORT_DESC** sends a report descriptor for a HID device to
+the Android device. This request is used to describe the capabilities of the HID device, and must
+be sent before reporting any HID events to the Android device. If the report descriptor is larger
+than the maximum packet size for endpoint zero, multiple `ACCESSORY_SET_HID_REPORT_DESC` commands
+are sent in order to transfer the entire descriptor.
+- **ACCESSORY_SEND_HID_EVENT** sends input events from the accessory to the Android
+device.
+
+The code definitions for these new control requests are as follows:
+
+    /* Control request for registering a HID device.
+     * Upon registering, a unique ID is sent by the accessory in the
+     * value parameter. This ID will be used for future commands for
+     * the device
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_REGISTER_HID_DEVICE
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          total length of the HID report descriptor
+     *  data            none
+     */
+    #define ACCESSORY_REGISTER_HID         54
+
+    /* Control request for unregistering a HID device.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_REGISTER_HID
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          0
+     *  data            none
+     */
+    #define ACCESSORY_UNREGISTER_HID         55
+
+    /* Control request for sending the HID report descriptor.
+     * If the HID descriptor is longer than the endpoint zero max packet size,
+     * the descriptor will be sent in multiple ACCESSORY_SET_HID_REPORT_DESC
+     * commands. The data for the descriptor must be sent sequentially
+     * if multiple packets are needed.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_SET_HID_REPORT_DESC
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          offset of data in descriptor
+     *                      (needed when HID descriptor is too big for one packet)
+     *  data            the HID report descriptor
+     */
+    #define ACCESSORY_SET_HID_REPORT_DESC         56
+
+    /* Control request for sending HID events.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_SEND_HID_EVENT
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          0
+     *  data            the HID report for the event
+     */
+    #define ACCESSORY_SEND_HID_EVENT         57
+
+
+## Interoperability with AOA 1.0 Features ##
+
+The original [AOA protocol](/tech/accessories/aoap/aoa.html) provided support for an Android
+application to communicate directly with a USB host (accessory) over USB. AOA 2.0 keeps that
+support, but adds new features to allow the accessory to communicate with the Android operating
+system itself (specifically the audio and input systems). The design of the AOA 2.0 makes it is
+possible to build an accessory that also makes use of the new audio and/or HID support in addition
+to the original feature set. Simply use the new features described in this document in addition to
+the original AOA protocol features.
+
+
+## Connecting AOA 2.0 without an Android App ##
+
+It is possible to design an accessory (for example, an audio dock) that uses the new audio and
+HID support, but does not need to communicate with an application on the Android device. In that
+case, the user would not want to see the dialog prompts related to finding and associating the newly
+attached accessory with an Android application that can communicate with it. To prevent these
+dialogs from appearing after the device and accessory are connected, the accessory can simply not
+send the manufacturer and model names to the Android device. If these strings are not provided to
+the Android device, then the accessory is able to make use of the new audio and HID support in AOA
+2.0 without the system attempting to find an application to communicate with the accessory. Also,
+if these strings are not provided, the accessory USB interface is not present in the Android
+device USB configuration after the device enters accessory mode.
\ No newline at end of file
diff --git a/src/tech/accessories/guide/audio.md b/src/tech/accessories/guide/audio.md
new file mode 100644
index 0000000..a1a572a
--- /dev/null
+++ b/src/tech/accessories/guide/audio.md
@@ -0,0 +1,67 @@
+# Building Audio Accessories #
+
+In building an audio accessory, such as an audio dock or other playback device, you should
+consider how your accessory will connect with Android devices. In particular, you should decide
+if your accessory will use Universal Serial Bus (USB) or a Bluetooth connection to stream music or
+other audio content.
+
+
+## Audio over USB ##
+
+An accessory that connects with Android over USB connection must use the Android Open
+Accessory (AOA) protocol version 2.0. This version of the AOA protocol is supported on Android 4.1
+(API Level 16) and higher. Once an Android device connects to an accessory that supports this
+protocol, the Android system treats it as a standard audio output device and routes all audio to
+that accessory. No secondary software application is required on the Android device.
+
+**Note:** Due to the low power output of Android devices, the Android Open Accessory
+Protocol requires that accessories act as a USB host, which means that the connecting accessory
+must power the bus.
+
+
+### Next steps ###
+
+To get started on building an audio accessory that uses a USB connection:
+
+- Select a hardware platform or build a hardware device that can support USB host mode.
+- Review the [AOA 2.0 protocol](/tech/accessories/aoap/aoa2.html) specification to understand
+  how to implement this protocol on your accessory hardware.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of an audio playback accessory using a USB connection.
+
+**Note:** The AOA 2.0 protocol also supports the
+[human interface device](/tech/accessories/aoap/aoa2.html#hid-support) (HID) protocol through a USB
+connection, enabling accessories such as audio docks to provide hardware play back controls such
+as pause, fast-forward or volume buttons.
+
+
+## Audio over Bluetooth ##
+
+An accessory that connects with Android over Bluetooth can use an Advanced Audio Distribution
+Profile (A2DP) connection stream music for playback. Playing audio over a Bluetooth with A2DP is
+supported on Android 1.5 (API Level 3) and higher. An Android user can connect to an accessory
+that supports this profile using the system Settings > Bluetooth and play music directly to the
+accessory without the need for a secondary application.
+
+**Note:** If you want to provide a custom application for output to your audio
+accessory, note that the Android 3.0 (API Level 11) allows applications to operate an A2DP
+connection using the
+[`BluetoothA2dp`](http://developer.android.com/reference/android/bluetooth/BluetoothA2dp.html)
+class.
+
+
+### Next steps ###
+
+To get started on building an audio accessory that uses a Bluetooth connection:
+
+- Select a hardware platform or build an hardware device that can support Bluetooth
+  communications and the A2DP connection profile.
+- Review the ADK 2012
+  [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of an audio playback accessory using a Bluetooth connection.
+
+**Note:** The ADK 2012 source code includes an open source Bluetooth stack that
+is built for the Texas Instruments CC2564 chip, but can work with any Bluetooth chip that
+implements a standard Host/Controller Interface (HCI).
\ No newline at end of file
diff --git a/src/tech/accessories/guide/custom.md b/src/tech/accessories/guide/custom.md
new file mode 100644
index 0000000..d4022b0
--- /dev/null
+++ b/src/tech/accessories/guide/custom.md
@@ -0,0 +1,77 @@
+# Building Custom Accessories #
+
+An accessory for Android can be anything: keyboard, thermometer, robot, lighting control or
+anything else you can imagine. Accessories for Android all have one thing in common; they all
+connect to an Android device in some way. When starting out to build an accessory, you should
+decide how your accessory will connect to Android devices. This page gives you quick overview of
+your options for connecting your Android accessory and resources to help you get started.
+
+
+## Connecting over USB ##
+
+An accessory that connects to an Android device through a USB cable must support the Android
+Open Accessory (AOA) protocol, which specifies how an accessory can establish communication with
+an Android device over a USB cable. Due to the low power output of Android devices, the AOA
+protocol requires the accessory act as a USB host, which means that the connecting accessory must
+power the bus.
+
+The AOA protocol has two versions which support different types of communication. Version
+1.0 supports a generic accessory communication and adb debugging. This version of the protocol is
+supported by the platform in Android 3.1 (API Level 12) and higher, and supported through an
+[Add-On Library](https://developers.google.com/android/add-ons/google-apis/) in Android
+2.3.4 (API Level 10) and higher. Version 2.0 of the protocol is available in Android 4.1 (API Level
+16) and adds audio streaming and human interface device (HID) capabilities.
+
+If you use the general accessory protocol to communicate with your accessory (rather than the
+adb or audio protocol), you must provide an Android application that can detect the connection of
+your USB accessory and establish communication.
+
+
+### Next steps ###
+
+To get started on building an Android accessory that uses a USB connection:
+
+- Select a hardware platform or build a hardware device that can support USB host mode.
+- Review the [AOA protocol](/tech/accessories/aoap/index.html) specifications to understand
+  how to implement this protocol on your accessory hardware. Implementing the
+  [AOA 2.0 protocol](/tech/accessories/aoap/aoa2.html) is recommended for all new Android USB
+  accessories.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which demonstrates an implementation of an accessory
+  using a USB connection for general data communications and audio streaming.
+- If you are planning to build an Android application that communicates with your accessory
+  via USB, review the ADK 2012 Android
+  [application source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/app/`).
+
+
+## Connecting over Bluetooth ##
+
+An accessory that connects with Android devices over a Bluetooth connection can use the
+various connection profiles supported by Android, including the Simple Serial Protocol (SSP) and
+Advanced Audio Distribution Profile (A2DP) profile. An accessory that uses Bluetooth to connect to
+Android devices must support Bluetooth communications and at least one of the supported connection
+profiles.
+
+Users must enable Bluetooth on their Android device and pair with your accessory in order to
+use it. You can also provide a secondary Android application that handles any specialized
+communication, such as data input or control outputs, to interface with your accessory.
+
+
+### Next steps ###
+
+To get started on building an Android accessory that uses a Bluetooth connection:
+
+- Select a hardware platform or build an hardware device that can support Bluetooth
+  communications and an Android supported connection profile, such as SSP or A2DP.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of general data communications and audio streaming using a Bluetooth connection.
+- If you are planning to build an Android application that communicates with your accessory
+  via Bluetooth, review the ADK 2012 Android
+  [application source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/app/`).
+
+**Note:** The ADK 2012 source code includes an open source Bluetooth stack which
+is built for the Texas Instruments CC2564 chip, but can work with any Bluetooth chip that
+supports a standard Host/Controller Interface (HCI).
\ No newline at end of file
diff --git a/src/tech/accessories/index.md b/src/tech/accessories/index.md
new file mode 100644
index 0000000..17a5039
--- /dev/null
+++ b/src/tech/accessories/index.md
@@ -0,0 +1,39 @@
+# Build Accessories for Android #
+
+Android Open Accessory support allows external USB hardware (an Android USB accessory) to interact
+with an Android-powered device in a special accessory mode. When an Android-powered powered device
+is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates
+devices) and the Android-powered device acts in the USB accessory role. Android USB accessories are
+specifically designed to attach to Android-powered devices and adhere to the Android Open Accessory
+Protocol, that allows them to detect Android-powered devices that support
+accessory mode. Accessories must also provide 500mA at 5V for charging power. Many previously
+released Android-powered devices are only capable of acting as a USB device and cannot initiate
+connections with external USB devices. Android Open Accessory support overcomes this limitation
+and allows you to build accessories that can interact with an assortment of Android-powered
+devices by allowing the accessory to initiate the connection.
+
+**Note:** Accessory mode is ultimately dependent on the device's hardware and not all devices
+support accessory mode. Devices that support accessory mode can be filtered using a `<uses-feature>`
+element in your corresponding application's Android manifest. For more information, see the
+[USB Accessory](http://developer.android.com/guide/topics/connectivity/usb/accessory.html#manifest)
+developer guide.
+
+Android Open Accessory support is included in Android 3.1 (API Level 12) and higher, and supported
+through an [Add-On Library](https://developers.google.com/android/add-ons/google-apis/) in Android
+2.3.4 (API Level 10) and higher.
+
+
+## Audio Accessories ##
+
+Android 4.1 and higher has support for audio output over a USB connection or Bluetooth. Find out
+how to build audio docks and other plug-in audio output hardware for Android.
+
+[&raquo; Build Audio Accessories](/tech/accessories/guide/audio.html)
+
+
+## Custom Accessories ##
+
+What do you want to connect to your Android device? Alarm clock? Keyboard? Thermostat? Robot?
+Learn how to connect existing equipment or your own unique hardware to Android.
+
+[&raquo; Build Custom Accessories](/tech/accessories/guide/custom.html)
\ No newline at end of file
diff --git a/src/tech/accessories/sidebar2.md b/src/tech/accessories/sidebar2.md
new file mode 100644
index 0000000..38bf48f
--- /dev/null
+++ b/src/tech/accessories/sidebar2.md
@@ -0,0 +1,9 @@
+# Getting Started #
+
+- [Audio Accessories](/tech/accessories/guide/audio.html)
+- [Custom Accessories](/tech/accessories/guide/custom.html)
+
+# Open Accessory Protocol #
+
+- [AOA 2.0](/tech/accessories/aoap/aoa2.html)
+- [AOA 1.0](/tech/accessories/aoap/aoa.html)
\ No newline at end of file
diff --git a/src/tech/index.md b/src/tech/index.md
index 42908be..ef6d019 100644
--- a/src/tech/index.md
+++ b/src/tech/index.md
@@ -67,8 +67,14 @@
 
 [&raquo; Data Usage Information](/tech/datausage/index.html)
 
-## External Storage Technical Information
+## Accessory Protocol Information ##
+Android devices can connect to hardware accessories, such as audio docks,
+keyboards and custom hardware, through USB or Bluetooth. This document
+describes the Android Open Accessory protocol for accessory hardware builders.
 
+[&raquo; Accessory Protocol Information](/tech/accessories/index.html)
+
+## External Storage Technical Information
 Android supports devices with external storage, typically provided by physical
 media or an emulation layer.  This document is designed to help systems
 integrators configure Android devices.
diff --git a/src/tech/security/index.md b/src/tech/security/index.md
index db5f140..867f55e 100644
--- a/src/tech/security/index.md
+++ b/src/tech/security/index.md
@@ -760,8 +760,8 @@
 protection level, restricting access only to applications signed with the same
 key while maintaining distinct UIDs and Application Sandboxes. A closer
 relationship with a shared Application Sandbox is allowed via the [shared UID
-feature](https://developer.android.com/guide/topics/manifest/manifest-element.htm
-l#uid) where two or more applications signed with same developer key can
+feature](https://developer.android.com/guide/topics/manifest/manifest-element.html#uid)
+where two or more applications signed with same developer key can
 declare a shared UID in their manifest.
 
 ##Application Verification
@@ -782,8 +782,8 @@
 manufacturer.
 
 The [Android DRM
-framework](https://developer.android.com/reference/android/drm/package-summary.ht
-ml) is implemented in two architectural layers (see figure below):
+framework](https://developer.android.com/reference/android/drm/package-summary.html)
+is implemented in two architectural layers (see figure below):
 
 + A DRM framework API, which is exposed to applications through the Android
 application framework and runs through the Dalvik VM for standard applications.
@@ -845,8 +845,7 @@
 security team of potential security issues by sending email to
 security@android.com. If desired, communication can be encrypted using the
 Android security team PGP key available here:
-[https://developer.android.com/security_at_android_dot_com.txt](https://develope
-r.android.com/security_at_android_dot_com.txt).
+[https://developer.android.com/security_at_android_dot_com.txt](https://developer.android.com/security_at_android_dot_com.txt).
 
 #Other Resources
 
@@ -861,12 +860,13 @@
 
 Security information exists throughout the Android Open Source and Developer
 Sites. A good place to start is here:
-[https://developer.android.com/guide/topics/security/security.html](https://develo
-per.android.com/guide/topics/security/security.html).
+[https://developer.android.com/guide/topics/security/security.html](https://developer.android.com/guide/topics/security/security.html).
 
 A Security FAQ for developers is located here:
-[https://developer.android.com/resources/faq/security.html](https://developer.andr
-oid.com/resources/faq/security.html).
+[https://developer.android.com/resources/faq/security.html](https://developer.android.com/resources/faq/security.html).
+
+Security Best Practices for developers is located here:
+[https://developer.android.com/guide/practices/security.html](https://developer.android.com/guide/practices/security.html).
 
 A community resource for discussion about Android security exists here:
 [https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss](https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss).
diff --git a/src/tech/sidebar.md b/src/tech/sidebar.md
index c3701fd..09f2f2f 100644
--- a/src/tech/sidebar.md
+++ b/src/tech/sidebar.md
@@ -5,3 +5,4 @@
 - [Security](/tech/security/index.html)
 - [Input](/tech/input/index.html)
 - [Data Usage](/tech/datausage/index.html)
+- [Accessories](/tech/accessories/index.html)
\ No newline at end of file