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/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/source/build-numbers.md b/src/source/build-numbers.md
index 807152f..f1481e1 100644
--- a/src/source/build-numbers.md
+++ b/src/source/build-numbers.md
@@ -110,8 +110,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,8 +119,12 @@
 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   | latest Jelly Bean version, Nexus S, Galaxy Nexus, Nexus 7
 
 The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
 represent development
diff --git a/src/source/building-devices.md b/src/source/building-devices.md
index 9c2ab82..4b0dad7 100644
--- a/src/source/building-devices.md
+++ b/src/source/building-devices.md
@@ -26,15 +26,20 @@
 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.
+functional, as well as WiFi 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 variants of Galaxy Nexus that be used are the GSM/HSPA+ configuration
+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.
 
-The Motorola Xoom is can be used in the Wi-Fi configuration "wingray"
+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".
+
+The Motorola Xoom 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.
 
@@ -71,6 +76,7 @@
 Device   | Keys
 ---------|------
 grouper  | 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*
 panda    | Press and hold *Input*, then press *Power*
@@ -158,17 +164,21 @@
 
 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
+grouper  | android-4.1.2_r1 or master   | full_grouper-userdebug
+maguro   | android-4.1.2_r1 or master   | full_maguro-userdebug
+toro     | android-4.1.2_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
+wingray  | android-4.1.2_r1 or master   | full_wingray-userdebug
+crespo   | android-4.1.2_r1 or master   | full_crespo-userdebug
+crespo4g | android-4.1.2_r1 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
 
+Do not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2
+or newer.
+
 ## Flashing a device ##
 
 Set the device in fastboot mode if necessary (see above).
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 cd42289..97c8714 100644
--- a/src/tech/security/index.md
+++ b/src/tech/security/index.md
@@ -718,8 +718,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.
 
 ##Digital Rights Management
@@ -731,8 +731,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.
@@ -794,8 +794,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
 
@@ -810,12 +809,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