resolved conflicts for merge of 35f2fda6 to jb-mr1-dev-plus-aosp, preserving conflciting files(.md files should be deleted) for now to fix conflicts and to keep track of changes htat need to be migrated to .jd. Will resolve for real in another CL
Change-Id: I0913254e89539b418ff9a52184dddcd524fca830
diff --git a/scripts/build.py b/scripts/build.py
index 33a1e33..2600f92 100755
--- a/scripts/build.py
+++ b/scripts/build.py
@@ -102,6 +102,18 @@
else:
sidebar3 = parent[2]
+ if 'index-intro.md' in files:
+ intro = md(os.path.join(curdir, 'index-intro.md'))
+ del files[files.index('index-intro.md')]
+ else:
+ intro = ''
+
+ if 'index-news.md' in files:
+ news = md(os.path.join(curdir, 'index-news.md'))
+ del files[files.index('index-news.md')]
+ else:
+ news = ''
+
parents[curdir] = (sidebar, sidebar2, sidebar3)
# Step D: mirror all non-*.md files, and translate (file).md files into (file).html
@@ -115,6 +127,9 @@
final = template.safe_substitute(main=main, sidebar=sidebar, sidebar2=sidebar2, \
sidebar3=sidebar3, category=category, title=get_title(absfilename))
+ if cmp(absfilename, 'src/index.md') == 0:
+ final = string.Template(final).safe_substitute(intro=intro, news=news)
+
html = codecs.open(os.path.join(outdir, f.replace('.md', '.html')), 'w', encoding="utf8")
html.write(final)
else:
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.2/android-4.2-cdd.pdf b/src/compatibility/4.2/android-4.2-cdd.pdf
index 10addf3..9ea111b 100755
--- a/src/compatibility/4.2/android-4.2-cdd.pdf
+++ 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.2-cdd.pdf b/src/compatibility/android-4.2-cdd.pdf
index 10addf3..9ea111b 100755
--- a/src/compatibility/android-4.2-cdd.pdf
+++ b/src/compatibility/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/contact-us.md b/src/compatibility/contact-us.md
new file mode 100644
index 0000000..e411797
--- /dev/null
+++ b/src/compatibility/contact-us.md
@@ -0,0 +1,43 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Contact Us #
+
+Thanks for your interest in Android compatibility!
+
+If you have questions about Android compatibility that aren't covered in
+this site, you can reach us in one of a few different ways. To get the most
+out of any of these options, please first read "Getting the Most from Our
+Lists" on the [Community page](index.html)
+
+## For Android Compatibility Definition and Compatibility Test Suite Technical Questions ##
+If you have questions about Android compatibility that aren't covered in this site, you can reach
+us in one of a few different ways. To get the most out of any of these options, please first read "Getting the Most from Our
+Lists" on the [Community page](/community/index.html). If you have specific issues with the Compatibility Test Suite or the Compatibility Definition
+[android-compatibility list.](https://groups.google.com/forum/?fromgroups#!forum/android-compatibility) is the discussion forum for you.
+
+- Subscribe using Google Groups: [android-compatibility](https://groups.google.com/forum/?fromgroups#!forum/android-compatibility)
+- Subscribe via email: [android-building](mailto:android-compatibility+subscribe@googlegroups.com)
+
+Note that if you're a user looking for help with your Android device, this page probably isn't for you;
+you should contact your carrier or manufacturer for help with your Android device.
+
+## For Business Inquiries ##
+
+Finally, business inquiries about the compatibility program, including
+requests to use branding elements and so on, can be sent to the address [android-partnerships@google.com](mailto:android-partnerships@google.com). Like
+the CTS address, this address is for specific, private inquiries; general
+questions will be directed back to the android-compatibility list.
diff --git a/src/compatibility/cts-development.md b/src/compatibility/cts-development.md
new file mode 100644
index 0000000..78996a7
--- /dev/null
+++ b/src/compatibility/cts-development.md
@@ -0,0 +1,130 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# CTS Development #
+
+## Initializing Your Repo Client ##
+
+Follow the [instructions](/source/downloading.html)
+to get and build the Android source code but specify `-b android-4.2_r1`
+when issuing the `repo init` command. This assures that your CTS
+changes will be included in the next CTS release and beyond.
+
+## Setting Up Eclipse ##
+
+Follow the [instructions](/source/using-eclipse.html)
+to setup Eclipse but execute the following command to generate the
+`.classpath` file rather than copying the one from the development
+project:
+
+ cd /path/to/android/root
+ ./cts/development/ide/eclipse/genclasspath.sh > .classpath
+ chmod u+w .classpath
+
+This `.classpath` file will contain both the Android framework
+packages and the CTS packages.
+
+## Building and Running CTS ##
+
+Execute the following commands to build CTS and start the interactive
+CTS console:
+
+ cd /path/to/android/root
+ make cts
+ cts-tradefed
+
+At the cts-tf console, enter e.g.:
+
+ run cts --plan CTS
+
+## Writing CTS Tests ##
+
+CTS tests use JUnit and the Android testing APIs. Review the
+[Testing and Instrumentation](https://developer.android.com/guide/topics/testing/testing_android.html)
+tutorial while perusing the existing tests under the
+`cts/tests/tests` directory. You will see that CTS tests mostly follow the same
+conventions used in other Android tests.
+
+Since CTS runs across many production devices, the tests must follow
+these rules:
+
+- Must take into account varying screen sizes, orientations, and keyboard layouts.
+- Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.
+- Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.
+- Don't rely upon root privileges.
+
+### Test Naming and Location ###
+
+Most CTS test cases target a specific class in the Android API. These tests
+have Java package names with a `cts` suffix and class
+names with the `Test` suffix. Each test case consists of
+multiple tests, where each test usually exercises a particular API method of
+the API class being tested. These tests are arranged in a directory structure
+where tests are grouped into different categories like "widgets" and "views."
+
+For example, the CTS test for `android.widget.TextView` is
+`android.widget.cts.TextViewTest` found under the
+`cts/tests/tests/widget/src/android/widget/cts` directory with its
+Java package name as `android.widget.cts` and its class name as
+`TextViewTest`. The `TextViewTest` class has a test called `testSetText`
+that exercises the "setText" method and a test named "testSetSingleLine" that
+calls the `setSingleLine` method. Each of those tests have `@TestTargetNew`
+annotations indicating what they cover.
+
+Some CTS tests do not directly correspond to an API class but are placed in
+the most related package possible. For instance, the CTS test,
+`android.net.cts.ListeningPortsTest`, is in the `android.net.cts`, because it
+is network related even though there is no `android.net.ListeningPorts` class.
+You can also create a new test package if necessary. For example, there is an
+"android.security" test package for tests related to security. Thus, use your
+best judgement when adding new tests and refer to other tests as examples.
+
+Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew.
+These are no longer necessary so do not annotate new tests with these.
+
+### New Test Packages ###
+
+When adding new tests, there may not be an existing directory to place your
+test. In that case, refer to the example under `cts/tests/tests/example` and
+create a new directory. Furthermore, make sure to add your new package's
+module name from its `Android.mk` to `CTS_COVERAGE_TEST_CASE_LIST` in
+`cts/CtsTestCaseList.mk`. This Makefile is used by `build/core/tasks/cts.mk`
+to glue all the tests together to create the final CTS package.
+
+### Test Stubs and Utilities ###
+
+Some tests use additional infrastructure like separate activities
+and various utilities to perform tests. These are located under the
+`cts/tests/src` directory. These stubs aren't separated into separate test
+APKs like the tests, so the `cts/tests/src` directory does not have additional
+top level directories like "widget" or "view." Follow the same principle of
+putting new classes into a package with a name that correlates to the purpose
+of your new class. For instance, a stub activity used for testing OpenGL like
+`GLSurfaceViewStubActivity` belongs in the `android.opengl.cts` package under
+the `cts/tests/src/android/opengl` directory.
+
+## Other Tasks ##
+
+Besides adding new tests there are other ways to contribute to CTS:
+
+- Fix or remove tests annotated with BrokenTest and KnownFailure.
+
+## Submitting Your Changes ##
+
+Follow the [Android Contributors' Workflow](/source/submit-patches.html)
+to contribute changes to CTS. A reviewer
+will be assigned to your change, and your change should be reviewed shortly!
+
diff --git a/src/compatibility/downloads.md b/src/compatibility/downloads.md
new file mode 100644
index 0000000..e342e37
--- /dev/null
+++ b/src/compatibility/downloads.md
@@ -0,0 +1,107 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Android Compatibility Downloads #
+
+Thanks for your interest in Android Compatibility! The links below allow
+you to access the key documents and information.
+
+## Android 4.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 R3 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.2_r3-linux_x86-arm.zip)
+
+## Android 4.1 ##
+
+Android 4.1.1 is the release of the development milestone code-named
+Jelly Bean. Android 4.1.1 is the current version of Android. Source code for
+Android 4.1.1 is found in the 'android-4.1.1_r1' branch in the open-source tree.
+
+- [Android 4.1 Compatibility Definition Document (CDD)](4.1/android-4.1-cdd.pdf)
+- [Android 4.1 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.1_r1-linux_x86-arm.zip)
+- [Android 4.1 R4 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.1_r4-linux_x86-arm.zip)
+
+
+## Android 4.0.3 ##
+
+Android 4.0.3 is the release of the development milestone code-named
+Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
+Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open-source tree.
+
+- [Android 4.0 Compatibility Definition Document (CDD)](4.0/android-4.0-cdd.pdf)
+- [Android 4.0.3 R3 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.0.3_r3-linux_x86-arm.zip)
+- [Android 4.0.3 R2 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r2-linux_x86-arm.zip)
+
+## Android 2.3 ##
+
+Android 2.3 is the release of the development milestone code-named
+Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in
+the open-source tree.
+
+- [Android 2.3 Compatibility Definition Document (CDD)](2.3/android-2.3.3-cdd.pdf)
+- [Android 2.3 R13 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip)
+- [Android 2.3 R3 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-2.3_r3-linux_x86-armv5.zip)
+
+## Android 2.2 ##
+
+Android 2.2 is the release of the development milestone code-named
+FroYo. Source code for Android 2.2 is found in the 'froyo' branch in the
+open-source tree.
+
+- [Android 2.2 Compatibility Definition Document (CDD)](2.2/android-2.2-cdd.pdf)
+- [Android 2.2 R8 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.2_r8-linux_x86-arm.zip)
+
+## Android 2.1 ##
+
+Android 2.1 is the release of the development milestone code-named
+Eclair. Source code for Android 2.1 is found in the 'eclair' branch in the
+open-source tree. Note that for technical reasons, there is no compatibility
+program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.
+
+- [Android 2.1 Compatibility Definition Document (CDD)](2.1/android-2.1-cdd.pdf)
+- [Android 2.1 R5 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.1_r5-x86.zip)
+
+## Android 1.6 ##
+
+Android 1.6 was the release of the development milestone code-named Donut.
+Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found
+in the 'donut' branch in the open-source tree.
+
+- [Android 1.6 Compatibility Definition Document (CDD)](1.6/android-1.6-cdd.pdf)
+- [Android 1.6 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-1.6_r1-x86.zip)
+
+## Compatibility Test Suite Manual ##
+
+The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and
+beyond require [additional steps](cts-intro.html) to run the accessibility tests.
+
+- [Compatibility Test Suite (CTS) User Manual](android-cts-manual-r6.pdf)
+
+## CTS Media Files ##
+These media files are required for the CTS media stress tests.
+
+- [CTS Media 1.0](https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip)
+
+## Older Android Versions ##
+
+There is no Compatibility Program for older versions of Android, such as Android
+1.5 (known in development as Cupcake). New devices intended to be Android
+compatible must ship with Android 1.6 or later.
diff --git a/src/compatibility/overview.md b/src/compatibility/overview.md
new file mode 100644
index 0000000..d691cfc
--- /dev/null
+++ b/src/compatibility/overview.md
@@ -0,0 +1,127 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Compatibility Program Overview #
+
+The Android compatibility program makes it easy for mobile device
+manufacturers to develop compatible Android devices.
+
+# Program goals #
+
+The Android compatibility program works for the benefit of the entire
+Android community, including users, developers, and device manufacturers.
+
+Each group depends on the others. Users want a wide selection of devices
+and great apps; great apps come from developers motivated by a large market
+for their apps with many devices in users' hands; device manufacturers rely
+on a wide variety of great apps to increase their products' value for
+consumers.
+
+Our goals were designed to benefit each of these groups:
+
+- *Provide a consistent application and hardware environment to application
+developers.*
+ Without a strong compatibility standard, devices can vary so
+greatly that developers must design different versions of their applications
+for different devices. The compatibility program provides a precise definition
+of what developers can expect from a compatible device in terms of APIs and
+capabilities. Developers can use this information to make good design
+decisions, and be confident that their apps will run well on any compatible
+device.
+
+- *Enable a consistent application experience for consumers.*
+ If an application runs well on one compatible Android device, it should run well on
+any other device that is compatible with the same Android platform version.
+Android devices will differ in hardware and software capabilities, so the
+compatibility program also provides the tools needed for distribution systems
+such as Google Play to implement appropriate filtering. This means that
+users can only see applications which they can actually run.
+
+- *Enable device manufacturers to differentiate while being
+compatible.*
+ The Android compatibility program focuses on the aspects of
+Android relevant to running third-party applications, which allows device
+manufacturers the flexibility to create unique devices that are nonetheless
+compatible.
+
+- *Minimize costs and overhead associated with compatibility.*
+ Ensuring compatibility should be easy and inexpensive to
+device manufacturers. The testing tool (CTS) is free, open source, and
+available for [download](downloads.html).
+CTS is designed to be used for continuous self-testing
+during the device development process to eliminate the cost of changing your
+workflow or sending your device to a third party for testing. Meanwhile, there
+are no required certifications, and thus no corresponding costs and
+fees.
+
+The Android compatibility program consists of three key components:
+
+- The source code to the Android software stack
+- The Compatilbility Definition Document, representing the "policy" aspect of compatibility
+- The Compatilbility Test Suite, representing the "mechanism" of compatibility
+
+Just as each version of the Android platform exists in a separate branch in
+the source code tree, there is a separate CTS and CDD for each version as
+well. The CDD, CTS, and source code are -- along with your hardware and your
+software customizations -- everything you need to create a compatible device.
+
+# Compatibility Definition Document (CDD) #
+
+For each release of the Android platform, a detailed Compatibility
+Definition Document (CDD) will be provided. The CDD represents the "policy"
+aspect of Android compatibility.
+
+No test suite, including CTS, can truly be comprehensive. For instance, the
+CTS includes a test that checks for the presence and correct behavior of
+OpenGL graphics APIs, but no software test can verify that the graphics
+actually appear correctly on the screen. More generally, it's impossible to
+test the presence of hardware features such as keyboards, display density,
+WiFi, and Bluetooth.
+
+The CDD's role is to codify and clarify specific requirements, and
+eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
+Android is a single corpus of open-source code, the code itself is the
+comprehensive "specification" of the platform and its APIs. The CDD acts as a
+"hub", referencing other content (such as SDK API documentation) that provides
+a framework in which the Android source code may be used so that the end
+result is a compatible system.
+
+If you want to build a device compatible with a given Android version,
+start by checking out the source code for that version, and then read the
+corresponding CDD and stay within its guidelines. For additional details,
+simply examine [the latest CDD](4.2/android-4.2-cdd.pdf).
+
+# Compatibility Test Suite (CTS) #
+
+The CTS is a free, commercial-grade test suite, available for
+[download](downloads.html).
+The CTS represents the "mechanism" of compatibility.
+
+The CTS runs on a desktop machine and executes test cases directly on
+attached devices or an emulator. The CTS is a set of unit tests designed to be
+integrated into the daily workflow (such as via a continuous build system) of
+the engineers building a device. Its intent is to reveal incompatibilities
+early on, and ensure that the software remains compatible throughout the
+development process.
+
+
+# Compatibility Test Suite Verifier (CTS Verifier) #
+The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
+Compatibility Test Suite (CTS), available for [download](downloads.html).
+CTS Verifier provides tests for APIs and functions that cannot be tested on a
+stationary device without manual input (e.g. audio quality, accelerometer, etc).
+
+For details on the CTS, consult the [CTS introduction](cts-intro.html).
diff --git a/src/compatibility/sidebar.md b/src/compatibility/sidebar.md
new file mode 100644
index 0000000..1745dc7
--- /dev/null
+++ b/src/compatibility/sidebar.md
@@ -0,0 +1,12 @@
+# Getting Started #
+- [Compatibility Overview](/compatibility/overview.html)
+- [Current CDD](/compatibility/4.2/android-4.2-cdd.pdf)
+- [CTS Introduction](/compatibility/cts-intro.html)
+- [CTS Development](/compatibility/cts-development.html)
+
+# More Information #
+- [Downloads](/compatibility/downloads.html)
+- [FAQs](/faqs.html#compatibility)
+- [Contact Us](/compatibility/contact-us.html)
+
+
diff --git a/src/devices/tech/security/index.jd b/src/devices/tech/security/index.jd
index 8c5a864..290137a 100644
--- a/src/devices/tech/security/index.jd
+++ b/src/devices/tech/security/index.jd
@@ -661,6 +661,38 @@
<p>Applications are also able to declare security permissions at the Signature
protection level, restricting access only to applications signed with the same
key while maintaining distinct UIDs and Application Sandboxes. A closer
+<<<<<<< HEAD:src/tech/security/index.md
+relationship with a shared Application Sandbox is allowed via the [shared UID
+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
+
+Android 4.2 and later support application verification. Users can choose to
+enable “Verify Apps" and have applications evaluated by an application verifier
+prior to installation. App verification can alert the user if they try to
+install an app that might be harmful; if an application is especially bad, it
+ can block installation.
+
+
+##Digital Rights Management
+
+The Android platform provides an extensible DRM framework that lets
+applications manage rights-protected content according to the license
+constraints that are associated with the content. The DRM framework supports
+many DRM schemes; which DRM schemes a device supports is left to the device
+manufacturer.
+
+The [Android DRM
+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.
+
++ A native code DRM manager, which implements the DRM framework and exposes an
+=======
relationship with a shared Application Sandbox is allowed via the <a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared UID
feature</a>
where two or more applications signed with same developer key can
@@ -681,6 +713,7 @@
</li>
<li>
<p>A native code DRM manager, which implements the DRM framework and exposes an
+>>>>>>> 35f2fda6:src/devices/tech/security/index.jd
interface for DRM plug-ins (agents) to handle rights management and decryption
for various DRM schemes</p>
</li>
@@ -730,6 +763,34 @@
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:
+<<<<<<< HEAD:src/tech/security/index.md
+[https://developer.android.com/security_at_android_dot_com.txt](https://developer.android.com/security_at_android_dot_com.txt).
+
+#Other Resources
+
+Information about the Android Open Source Project is available at
+[https://source.android.com](https://source.android.com).
+
+Information for Android application developers is here:
+[https://developer.android.com](https://developer.android.com).
+
+The Android Security team can be reached at
+[security@android.com](mailto:security@android.com).
+
+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://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.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).
+
+=======
<a href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a>.</p>
<h1 id="other-resources">Other Resources</h1>
<p>Information about the Android Open Source Project is available at
@@ -747,3 +808,4 @@
<a href="https://developer.android.com/guide/practices/security.html">https://developer.android.com/guide/practices/security.html</a>.</p>
<p>A community resource for discussion about Android security exists here:
<a href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a>.</p>
+>>>>>>> 35f2fda6:src/devices/tech/security/index.jd
diff --git a/src/index-intro.md b/src/index-intro.md
new file mode 100644
index 0000000..963a84d
--- /dev/null
+++ b/src/index-intro.md
@@ -0,0 +1,28 @@
+<!--
+ Copyright 2013 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.
+-->
+
+Here you can find the information and source code you need to build an
+Android-compatible device.
+
+Android is an open-source software stack for mobile devices, and a
+corresponding open-source project led by Google. We created Android in
+response to our own experiences launching mobile apps. We wanted to make
+sure that there was no central point of failure, so that no industry player
+can restrict or control the innovations of any other. That's why we
+created Android, and made its source code open.
+
+[Learn more »](about/index.html)
+
diff --git a/src/index-news.md b/src/index-news.md
new file mode 100644
index 0000000..0ecce69
--- /dev/null
+++ b/src/index-news.md
@@ -0,0 +1,33 @@
+<!--
+ Copyright 2013 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.
+-->
+
+## News ##
+
+### Source Code Available for Android 4.1 ###
+
+The source code for the Android 4.1 platform and software stack has been
+released! This release allows OEMs to begin preparing Android 4.1 for
+installation on new and existing devices, and allows hobbyists, enthusiasts,
+and researchers to develop custom builds. For information on how to obtain the
+software, visit our [Getting the Source](source/downloading.html) page.
+
+### Compatibility Definition for Android 4.0 ###
+
+The Compatibility Definition Document for Android 4.0 has been published.
+Android 4.0 allows device manufacturers to use the Android source code to ship
+a significantly wider variety of devices including phones and tablets.
+For more information, visit the [Compatibility](compatibility/index.html) page.
+
diff --git a/src/index.md b/src/index.md
new file mode 100644
index 0000000..5c168bc
--- /dev/null
+++ b/src/index.md
@@ -0,0 +1,69 @@
+<!--
+ 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.
+-->
+
+# Welcome to Android #
+
+<div style="float: right; width: 35%;">
+$news
+</div>
+
+<img style="float: right; padding-right: 1.5em;" src="images/home-bugdroid.png" alt="Android Mascot"/>
+
+<div style="font-size: 1.3em;">
+$intro
+</div>
+<div style="clear: both;"/>
+
+<table border="0" style="border: 0px; margin: 0px; padding: 0px;"><tr><td align="center" style="border: 0px; margin: 0px; padding: 0px;">
+<div style="float: left; width: 15%; margin: 1em;"> </div>
+<div class="rebox" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Source</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em; margin-bottom: 5em;"/>
+ If you're interested in contributing to the Android source code or helping
+ out with the open-source project, our Source pages have the information
+ you need.</p>
+ <p><a href="source/index.html">Get Involved »</a></p>
+ </div>
+</div>
+
+<!--
+<div class="rebox" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Porting</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em; margin-bottom: 5em;"/>
+ If you're an engineer building a device
+ intended to run the Android software stack, look at our Porting pages for
+ information and tips.</p>
+ <p><a href="porting/index.html">Build a Device »</a></p>
+ </div>
+</div>
+-->
+
+<div class="rebox" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Compatibility</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em; margin-bottom: 5em;"/>
+ If you're an organization building an Android device, you'll want to check out our
+ Compatibility pages to find out how to take advantage of the benefits of
+ compatibility.</p>
+ <p><a href="compatibility/index.html">Get Compatible »</a></p>
+ </div>
+</div>
+<div style="float: left; width: 15%; margin: 1em;"> </div>
+</td></tr></table>
+
+<div style="clear: both;"/>
diff --git a/src/source/build-numbers.md b/src/source/build-numbers.md
new file mode 100644
index 0000000..e66d244
--- /dev/null
+++ b/src/source/build-numbers.md
@@ -0,0 +1,173 @@
+<!--
+ 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.
+-->
+
+# Codenames, Tags, and Build Numbers #
+
+At a high level, Android development happens around families of
+releases, which use code names ordered alphabetically after tasty
+treats.
+
+## Platform code names, versions, API levels, and NDK releases ##
+
+The code names match the following version numbers, along with
+API levels and NDK releases provided for convenience:
+
+Code name | Version | API level
+-----------------|---------------|--------------------
+(no code name) | 1.0 | API level 1
+(no code name) | 1.1 | API level 2
+Cupcake | 1.5 | API level 3, NDK 1
+Donut | 1.6 | API level 4, NDK 2
+Eclair | 2.0 | API level 5
+Eclair | 2.0.1 | API level 6
+Eclair | 2.1 | API level 7, NDK 3
+Froyo | 2.2.x | API level 8, NDK 4
+Gingerbread | 2.3 - 2.3.2 | API level 9, NDK 5
+Gingerbread | 2.3.3 - 2.3.7 | API level 10
+Honeycomb | 3.0 | API level 11
+Honeycomb | 3.1 | API level 12, NDK 6
+Honeycomb | 3.2.x | API level 13
+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.
+
+The first letter is the code name of the release family, e.g. F is
+Froyo.
+
+The second letter is a branch code that allows Google to identify
+the exact code branch that the build was made from, and R is by
+convention the primary release branch.
+
+The next letter and two digits are a date code. The letter counts
+quarters, with A being Q1 2009. Therefore, F is Q2 2010. The two
+digits count days within the quarter, so F85 is June 24 2010.
+
+Finally, the last letter identifies individual versions related to
+the same date code, sequentially starting with A; A is actually
+implicit and usually omitted for brevity.
+
+The date code is not guaranteed to be the exact date at which a build
+was made, and it is common that minor variations added to an existing
+build re-use the same date code as that existing build.
+
+## Source code tags and builds ##
+
+Starting with Donut, the exact list of tags and builds is in the
+following table:
+
+Build | Tag | Notes
+-------|--------------------|-----------------------------------
+DRC83 | android-1.6_r1.1 | earliest Donut version, ADP1, ADP2
+DRC92 | android-1.6_r1.2
+DRD08 | android-1.6_r1.3
+DRD20 | android-1.6_r1.4
+DMD64 | android-1.6_r1.5 | latest Donut version
+ESD20 | android-2.0_r1 | earliest Eclair version
+ESD56 | android-2.0.1_r1
+ERD79 | android-2.1_r1 | Nexus One
+ERE27 | android-2.1_r2 | Nexus One
+EPE54B | android-2.1_r2.1p | Nexus One
+ESE81 | android-2.1_r2.1s
+EPF21B | android-2.1_r2.1p2 | latest Eclair version
+FRF85B | android-2.2_r1 | earliest Froyo version, Nexus One
+FRF91 | android-2.2_r1.1 | Nexus One
+FRG01B | android-2.2_r1.2
+FRG22D | android-2.2_r1.3
+FRG83 | android-2.2.1_r1 | Nexus One
+FRG83D | android-2.2.1_r2 | Nexus One
+FRG83G | android-2.2.2_r1 | Nexus One
+FRK76 | android-2.2.3_r1
+FRK76C | android-2.2.3_r2 | latest Froyo version
+GRH55 | android-2.3_r1 | earliest Gingerbread version, Nexus S
+GRH78 | android-2.3.1_r1 | Nexus S
+GRH78C | android-2.3.2_r1 | Nexus S
+GRI40 | android-2.3.3_r1 | Nexus One, Nexus S
+GRI54 | android-2.3.3_r1.1 | Nexus S
+GRJ06D | android-2.3.4_r0.9 | Nexus S 4G
+GRJ22 | android-2.3.4_r1 | Nexus One, Nexus S, Nexus S 4G
+GRJ90 | android-2.3.5_r1 | Nexus S 4G
+GRK39C | android-2.3.6_r0.9 | Nexus S
+GRK39F | android-2.3.6_r1 | Nexus One, Nexus S
+GWK74 | android-2.3.7_r1 | latest Gingerbread version, Nexus S 4G
+ITL41D | android-4.0.1_r1 | earliest Ice Cream Sandwich version, Galaxy Nexus
+ITL41D | android-4.0.1_r1.1 | Galaxy Nexus
+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
+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
+IMM76L | android-4.0.4_r2.1 | latest Ice Cream Sandwich version
+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 | 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 | Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10
+JOP40F | android-4.2.1_r1.1 | Nexus 10
+JOP40G | android-4.2.1_r1.2 | Nexus 4
+JDQ39 | android-4.2.2_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, jb-mr1.1-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
+the official tagged releases, and those haven't been as thoroughly
+tested.
+
+## Honeycomb GPL modules ##
+
+For Honeycomb, the entire platform source code isn't available.
+However, the parts of Honeycomb licensed under the GPL and LGPL
+are available under the following tags:
+
+Build | Tag | Notes
+-------|--------------------|-----------------------------------
+HRI39 | android-3.0_r1 | earliest Honeycomb version
+HRI66 | android-3.0_r1.1
+HWI69 | android-3.0_r1.2
+HRI83 | android-3.0_r1.3
+HMJ37 | android-3.1_r1
+HTJ85B | android-3.2_r1
+HTK55D | android-3.2.1_r1
+HTK75D | android-3.2.1_r2
+HLK75C | android-3.2.2_r1
+HLK75D | android-3.2.2_r2
+HLK75F | android-3.2.4_r1
+HLK75H | android-3.2.6_r1 | latest Honeycomb version
+
+There is no manifest that contains exactly those. However, there
+are manifests that allow building those components. The following
+commands work for 3.0_r1.1, and using other versions can be done by
+switching the git checkout paramater, and if necessary the -m parameter in
+repo init. The git checkout command outputs an error for the non-GPL
+projects, where it can't find the tag in question.
+
+ $ repo init -b master -m base-for-3.0-gpl.xml
+ $ repo sync
+ $ repo forall -c git checkout android-3.0_r1.1
diff --git a/src/source/building-devices.md b/src/source/building-devices.md
new file mode 100644
index 0000000..a34fefe
--- /dev/null
+++ b/src/source/building-devices.md
@@ -0,0 +1,214 @@
+<!--
+ 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.
+-->
+
+# Building for devices #
+
+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 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 configurations of Nexus 10 can be used. On those devices, graphics, audio,
+Wi-Fi, Bluetooth, camera, NFC, GPS and orientation sensors are functional.
+
+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 Wi-Fi, Bluetooth, and access to the
+respective cellular networks. NFC and the orientation sensors are functional.
+
+The Sprint CDMA/LTE configuration "toroplus" of Galaxy Nexus is supported
+experimentally, in the jb-mr1-dev-plus-aosp branch. 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, 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 jb-mr1-dev-plus-aosp branch, but is considered experimental.
+The specific details to use a PandaBoard with the Android Open-Source Project
+are in the file `device/ti/panda/README` in the source tree.
+
+Nexus One a.k.a. "passion" is obsolete, was experimental in gingerbread,
+and can't be used with newer versions of the Android Open-Source
+Project.
+
+Android Developer Phones (ADP1 and ADP2, a.k.a. "dream" and "sapphire") are
+obsolete, were experimental in froyo, and can't be used with
+newer versions of the Android Open-Source Project.
+
+## Building fastboot and adb ##
+
+If you don't already have those tools, fastboot and adb can be built with
+the regular build system. Follow the instructions on the page about
+[building](building.html), and replace the main `make` command with
+
+ $ make fastboot adb
+
+## Booting into fastboot mode ##
+
+During a cold boot, the following key combinations can be used to boot into fastboot mode,
+which is a mode in the bootloader that can be used to flash the devices:
+
+Device | Keys
+---------|------
+manta | Press and hold both *Volume Up* and *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*
+
+Also, the command `adb reboot bootloader` can be used to reboot from
+Android directly into the bootloader with no key combinations.
+
+## Unlocking the bootloader ##
+
+It's only possible to flash a custom system if the bootloader allows it.
+
+The bootloader is locked by default. With the device in fastboot mode, the
+bootloader is unlocked with
+
+ $ fastboot oem unlock
+
+The procedure must be confirmed on-screen, and deletes the user data for
+privacy reasons. It only needs to be run once.
+
+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 10, after unlocking the bootloader, the internal storage is
+left unformatted and must be formatted with
+
+ $ fastboot format cache
+ $ fastboot format userdata
+
+The bootloader can be locked back with
+
+ $ fastboot oem lock
+
+Note that this erases user data on Xoom (including the shared USB data).
+
+## Obtaining proprietary binaries ##
+
+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,
+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.
+
+When using the master branch for a device, the binaries for the most
+recent numbered release are the ones that should be used in the master
+branch.
+
+### Extracting the proprietary binaries ###
+
+Each set of binaries comes as a self-extracting script in a compressed archive.
+After uncompressing each archive, run the included self-extracting script
+from the root of the source tree, confirm that you agree to the terms of the
+enclosed license agreement, and the binaries and their matching makefiles
+will get installed in the `vendor/` hierarchy of the source tree.
+
+### Cleaning up when adding proprietary binaries ###
+
+In order to make sure that the newly installed binaries are properly
+taken into account after being extracted, the existing output of any previous
+build needs to be deleted with
+
+ $ make clobber
+
+## Picking and building the configuration that matches a device ##
+
+The steps to configure and build the Android Open-Source Project
+are described in the page about [Building](building.html).
+
+The recommended builds for the various devices are available through
+the lunch menu, accessed when running the `lunch` command with no arguments:
+
+Device | Branch | Build configuration
+---------|------------------------------|------------------------
+manta | android-4.2.1_r1.2 | full_manta-userdebug
+grouper | android-4.2.1_r1.2 | full_grouper-userdebug
+maguro | android-4.2.1_r1.2 | full_maguro-userdebug
+toro | android-4.2.1_r1.2 | full_toro-userdebug
+toroplus | jb-mr1-dev-plus-aosp | full_toroplus-userdebug
+panda | jb-mr1-dev-plus-aosp | full_panda-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 ##
+
+Set the device in fastboot mode if necessary (see above).
+
+An entire Android system can be flashed in a single command: this writes
+the boot, recovery and system partitions together after verifying that the
+system being flashed is compatible with the installed bootloader and radio,
+and reboots the system. This also erases all the user data, similarly to
+`fastboot oem unlock` mentioned earlier.
+
+ $ fastboot -w flashall
+
+Note that filesystems created via fastboot on Motorola Xoom aren't working
+optimally, and it is strongly recommended to re-create them through recovery
+
+ $ adb reboot recovery
+
+Once in recovery, open the menu (press Power + Volume Up), wipe the cache
+partition, then wipe data.
+
+## Restoring a device to its original factory state ##
+
+Factory images
+for Nexus 10,
+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.
diff --git a/src/source/building-kernels.md b/src/source/building-kernels.md
new file mode 100644
index 0000000..f62483b
--- /dev/null
+++ b/src/source/building-kernels.md
@@ -0,0 +1,100 @@
+<!--
+ Copyright 2011 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.
+-->
+
+# Building Kernels #
+
+If you are only interested in the kernel, you may use this guide
+to download and build the appropriate kernel.
+
+The following instructions assume that you have not downloaded all
+of AOSP. If you have downloaded all of AOSP, you may skip the git
+clone steps other than the step to download the actual kernel sources.
+
+We will use the Pandaboard kernel in all the following examples.
+
+
+## Figuring out which kernel to build ##
+
+You will want to look at the git log for the kernel in the device project that
+you are interested in.
+Device projects are of the form device/<vendor>/<name>.
+
+ $ git clone https://android.googlesource.com/device/ti/panda
+ $ cd panda
+ $ git log kernel
+
+The log should contain notes of the commit SHA1 for the appropriate
+kernel project. Keep this value at hand so that you can use it in
+a later step.
+
+## Downloading sources ##
+
+Depending on which kernel you want,
+
+ $ git clone https://android.googlesource.com/kernel/common.git
+ $ git clone https://android.googlesource.com/kernel/exynos.git
+ $ git clone https://android.googlesource.com/kernel/goldfish.git
+ $ git clone https://android.googlesource.com/kernel/msm.git
+ $ git clone https://android.googlesource.com/kernel/omap.git
+ $ git clone https://android.googlesource.com/kernel/samsung.git
+ $ git clone https://android.googlesource.com/kernel/tegra.git
+
+ - The `goldfish` project contains the kernel sources for the emulated
+platforms.
+ - 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 ##
+
+Ensure that the prebuilt toolchain is in your path.
+
+ $ git clone https://android.googlesource.com/platform/prebuilt
+ $ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
+
+
+## Building ##
+
+As an example, we would build the panda kernel using the following commands:
+
+ $ export ARCH=arm
+ $ export SUBARCH=arm
+ $ export CROSS_COMPILE=arm-eabi-
+ $ cd omap
+ $ git checkout <commit_from_first_step>
+ $ make panda_defconfig
+ $ make
+
+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`
+
+The image is output as `arch/arm/boot/zImage`. You may copy it as
+`device/<vendor>/<name>/kernel` or `device/ti/panda/kernel` in the case of this
+example.
diff --git a/src/source/downloading.md b/src/source/downloading.md
new file mode 100644
index 0000000..923d3c9
--- /dev/null
+++ b/src/source/downloading.md
@@ -0,0 +1,209 @@
+<!--
+ 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.
+-->
+
+# Downloading the Source Tree #
+
+## Installing Repo ##
+
+Repo is a tool that makes it easier to work with Git in the context of Android. For more information about Repo, see [Version Control](version-control.html).
+
+To install, initialize, and configure Repo, follow these steps:
+
+ - Make sure you have a bin/ directory in your home directory, and that it is included in your path:
+
+ $ mkdir ~/bin
+ $ PATH=~/bin:$PATH
+
+ - Download the Repo script and ensure it is executable:
+
+ $ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
+ $ chmod a+x ~/bin/repo
+
+ - For version 1.17, the SHA-1 checksum for repo is
+ ddd79b6d5a7807e911b524cb223bc3544b661c28
+ - For version 1.19, the SHA-1 checksum for repo is
+ 92cbad8c880f697b58ed83e348d06619f8098e6c
+
+
+## Initializing a Repo client ##
+
+After installing Repo, set up your client to access the android source repository:
+
+ - Create an empty directory to hold your working files.
+ If you're using MacOS, this has to be on a case-sensitive filesystem.
+ Give it any name you like:
+
+
+ $ mkdir WORKING_DIRECTORY
+ $ cd WORKING_DIRECTORY
+
+ - Run `repo init` to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest, which specifies where the various repositories included in the Android source will be placed within your working directory.
+
+ $ repo init -u https://android.googlesource.com/platform/manifest
+
+ To check out a branch other than "master", specify it with -b:
+
+ $ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
+
+ - When prompted, please configure Repo with your real name and email address. To use the Gerrit code-review tool, you will need an email address that is connected with a [registered Google account](https://www.google.com/accounts). Make sure this is a live address at which you can receive messages. The name that you provide here will show up in attributions for your code submissions.
+
+A successful initialization will end with a message stating that Repo is initialized in your working directory. Your client directory should now contain a `.repo` directory where files such as the manifest will be kept.
+
+
+## Getting the files ##
+
+To pull down files to your working directory from the repositories as specified in the default manifest, run
+
+ $ repo sync
+
+The Android source files will be located in your working directory
+under their project names. The initial sync operation will take
+an hour or more to complete. For more about `repo sync` and other
+Repo commands, see [Version Control](version-control.html).
+
+
+## Using authentication ##
+
+By default, access to the Android source code is anonymous. To protect the
+servers against excessive usage, each IP address is associated with a quota.
+
+When sharing an IP address with other users (e.g. when accessing the source
+repositories from beyond a NAT firewall), the quotas can trigger even for
+regular usage patterns (e.g. if many users sync new clients from the same IP
+address within a short period).
+
+In that case, it is possible to use authenticated access, which then uses
+a separate quota for each user, regardless of the IP address.
+
+The first step is to create a password from
+[the password generator](https://android.googlesource.com/new-password) and
+to save it in `~/.netrc` according to the instructions on that page.
+
+The second step is to force authenticated access, by using the following
+manifest URI: `https://android.googlesource.com/a/platform/manifest`. Notice
+how the `/a/` directory prefix triggers mandatory authentication. You can
+convert an existing client to use mandatory authentication with the following
+command:
+
+ $ repo init -u https://android.googlesource.com/a/platform/manifest
+
+## Troubleshooting network issues ##
+
+When downloading from behind a proxy (which is common in some
+corporate environments), it might be necessary to explicitly
+specify the proxy that is then used by repo:
+
+ $ export HTTP_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
+ $ export HTTPS_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
+
+More rarely, Linux clients experience connectivity issues, getting
+stuck in the middle of downloads (typically during "Receiving objects").
+It has been reported that tweaking the settings of the TCP/IP stack and
+using non-parallel commands can improve the situation. You need root
+access to modify the TCP setting:
+
+ $ sudo sysctl -w net.ipv4.tcp_window_scaling=0
+ $ repo sync -j1
+
+
+## Using a local mirror ##
+
+When using several clients, especially in situations where bandwidth is scarce,
+it is better to create a local mirror of the entire server content, and to
+sync clients from that mirror (which requires no network access). The download
+for a full mirror is smaller than the download of two clients, while containing
+more information.
+
+These instructions assume that the mirror is created in `/usr/local/aosp/mirror`.
+The first step is to create and sync the mirror itself, which uses close to
+13GB of network bandwidth and a similar amount of disk space. Notice the
+`--mirror` flag, which can only be specified when creating a new client:
+
+ $ mkdir -p /usr/local/aosp/mirror
+ $ cd /usr/local/aosp/mirror
+ $ repo init -u https://android.googlesource.com/mirror/manifest --mirror
+ $ repo sync
+
+Once the mirror is synced, new clients can be created from it. Note that it's
+important to specify an absolute path:
+
+ $ mkdir -p /usr/local/aosp/master
+ $ cd /usr/local/aosp/master
+ $ repo init -u /usr/local/aosp/mirror/platform/manifest.git
+ $ repo sync
+
+Finally, to sync a client against the server, the mirror needs to be synced
+against the server, then the client against the mirror:
+
+ $ cd /usr/local/aosp/mirror
+ $ repo sync
+ $ cd /usr/local/aosp/master
+ $ repo sync
+
+It's possible to store the mirror on a LAN server and to access it over
+NFS, SSH or Git. It's also possible to store it on a removable drive and
+to pass that drive around between users or between machines.
+
+
+## Verifying Git Tags ##
+
+Load the following public key into your GnuPG key database. The key is used to sign annotated tags that represent releases.
+
+ $ gpg --import
+
+Copy and paste the key(s) below, then enter EOF (Ctrl-D) to end the input and process the keys.
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+ Version: GnuPG v1.4.2.2 (GNU/Linux)
+
+ mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
+ lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
+ 8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
+ u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
+ wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
+ /HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
+ jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
+ MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
+ b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
+ aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
+ cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
+ gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
+ 2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
+ QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
+ hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
+ C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
+ LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
+ OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
+ pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
+ KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
+ N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
+ vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
+ G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
+ hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
+ EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
+ =Wi5D
+ -----END PGP PUBLIC KEY BLOCK-----
+
+After importing the keys, you can verify any tag with
+
+ $ git tag -v TAG_NAME
+
+If you haven't [set up ccache](initializing.html#ccache) yet,
+now would be a good time to do it.
+
+# Next: Build the code #
+
+You now have a complete local copy of the Android codebase. Continue on to [building](building.html)....
diff --git a/src/source/initializing.md b/src/source/initializing.md
new file mode 100644
index 0000000..52da7d6
--- /dev/null
+++ b/src/source/initializing.md
@@ -0,0 +1,344 @@
+<!--
+ 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.
+-->
+
+# Initializing a Build Environment #
+
+The "Getting Started" section describes how to set up your local work environment, how to use Repo to get the Android files, and how to build the files on your machine. To build the Android source files, you will need to use Linux or Mac OS. Building under Windows is not currently supported.
+
+*Note: The source download is approximately 8.5GB in size.
+You will need over 30GB free to complete a single build, and
+up to 100GB (or more) for a full set of builds.*
+
+For an overview of the entire code-review and code-update process, see [Life of a Patch](life-of-a-patch.html).
+
+# Choosing a Branch #
+
+Some of the requirements for your build environment are determined by which
+version of the source code you plan to compile. See
+[Build Numbers](build-numbers.html) for a full listing of branches you may
+choose from. You may also choose to download and build the latest source code
+(called "master"), in which case you will simply omit the branch specification
+when you initialize the repository.
+
+Once you have selected a branch, follow the appropriate instructions below to
+set up your build environment.
+
+# Setting up a Linux build environment #
+
+These instructions apply to all branches, including master.
+
+The Android build is routinely tested in house on recent versions of
+Ubuntu LTS (10.04), but most distributions should have the required
+build tools available. Reports of successes or failures on other
+distributions are welcome.
+
+For Gingerbread (2.3.x) and newer versions, including the master
+branch, a 64-bit environment is required. Older versions can be
+compiled on 32-bit systems.
+
+*Note: It is also possible to build Android in a virtual machine.
+If you are running Linux in a virtual machine, you will need at
+least 16GB of RAM/swap and 30GB or more of disk space in order to
+build the Android tree.*
+
+Detailed instructions for Ubuntu and MacOS follow. In general you will need:
+
+ - Python 2.6 -- 2.7, which you can download from [python.org](http://www.python.org/download/).
+
+ - GNU Make 3.81 -- 3.82, which you can download from [gnu.org](http://ftp.gnu.org/gnu/make/),
+
+ - JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from [java.sun.com](http://java.sun.com/javase/downloads/).
+
+ - Git 1.7 or newer. You can find it at [git-scm.com](http://git-scm.com/download).
+
+## Installing the JDK ##
+
+The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add the appropriate repository and indicate to the system which JDK should be used.
+
+Java 6: for Gingerbread and newer
+
+ $ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
+ $ sudo apt-get update
+ $ sudo apt-get install sun-java6-jdk
+
+Java 5: for Froyo and older
+
+ $ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy main multiverse"
+ $ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy-updates main multiverse"
+ $ sudo apt-get update
+ $ sudo apt-get install sun-java5-jdk
+
+*Note: The `lunch` command in the build step will ensure that the Sun JDK is
+used instead of any previously installed JDK.*
+
+## Installing required packages (Ubuntu 10.04 -- 11.10) ##
+
+You will need a 64-bit version of Ubuntu. Ubuntu 10.04 is recommended.
+Building using a newer version of Ubuntu is currently only experimentally
+supported and is not guaranteed to work on branches other than master.
+
+ $ sudo apt-get install git-core gnupg flex bison gperf build-essential \
+ zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \
+ x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \
+ libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \
+ libxml2-utils xsltproc
+
+On Ubuntu 10.10:
+
+ $ sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so
+
+On Ubuntu 11.10:
+
+ $ sudo apt-get install libx11-dev:i386
+
+## Installing required packages (Ubuntu 12.04) ##
+
+Building on Ubuntu 12.04 is currently only experimentally supported and is not
+guaranteed to work on branches other than master.
+
+ $ sudo apt-get install git gnupg flex bison gperf build-essential \
+ zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
+ libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
+ libgl1-mesa-dev g++-multilib mingw32 tofrodos \
+ python-markdown libxml2-utils xsltproc zlib1g-dev:i386
+ $ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
+
+## Configuring USB Access ##
+
+Under GNU/linux systems (and specifically under Ubuntu systems),
+regular users can't directly access USB devices by default. The
+system needs to be configured to allow such access.
+
+The recommended approach is to create a file
+`/etc/udev/rules.d/51-android.rules` (as the root user) and to copy
+the following lines in it. `<username>` must be replaced by the
+actual username of the user who is authorized to access the phones
+over USB.
+
+ # adb protocol on passion (Nexus One)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0600", OWNER="<username>"
+ # fastboot protocol on passion (Nexus One)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0600", OWNER="<username>"
+ # adb protocol on crespo/crespo4g (Nexus S)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"
+ # fastboot protocol on crespo/crespo4g (Nexus S)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"
+ # adb protocol on stingray/wingray (Xoom)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="70a9", MODE="0600", OWNER="<username>"
+ # fastboot protocol on stingray/wingray (Xoom)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="708c", MODE="0600", OWNER="<username>"
+ # adb protocol on maguro/toro (Galaxy Nexus)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0600", OWNER="<username>"
+ # fastboot protocol on maguro/toro (Galaxy Nexus)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0600", OWNER="<username>"
+ # adb protocol on panda (PandaBoard)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d101", MODE="0600", OWNER="<username>"
+ # fastboot protocol on panda (PandaBoard)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d022", MODE="0600", OWNER="<username>"
+ # usbboot protocol on panda (PandaBoard)
+ 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/tilapia (Nexus 7)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0600", OWNER="<username>"
+ # fastboot protocol on grouper/tilapia (Nexus 7)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", MODE="0600", OWNER="<username>"
+ # adb protocol on manta (Nexus 10)
+ SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0600", OWNER="<username>"
+ # fastboot protocol on manta (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
+back into the computer.
+
+This is known to work on both Ubuntu Hardy Heron (8.04.x LTS) and
+Lucid Lynx (10.04.x LTS). Other versions of Ubuntu or other
+variants of GNU/linux might require different configurations.
+
+<a name="ccache"></a>
+## Setting up ccache ##
+
+You can optionally tell the build to use the ccache compilation tool.
+Ccache acts as a compiler cache that can be used to speed-up rebuilds.
+This works very well if you do "make clean" often, or if you frequently
+switch between different build products.
+
+Put the following in your .bashrc or equivalent.
+
+ export USE_CCACHE=1
+
+By default the cache will be stored in ~/.ccache.
+If your home directory is on NFS or some other non-local filesystem,
+you will want to specify the directory in your .bashrc as well.
+
+ export CCACHE_DIR=<path-to-your-cache-directory>
+
+The suggested cache size is 50-100GB.
+You will need to run the following command once you have downloaded
+the source code:
+
+ prebuilts/misc/linux-x86/ccache/ccache -M 50G
+
+When building Ice Cream Sandwich (4.0.x) or older, ccache is in
+a different location:
+
+ prebuilt/linux-x86/ccache/ccache -M 50G
+
+This setting is stored in the CCACHE_DIR and is persistent.
+
+## Using a separate output directory ##
+
+By default, the output of each build is stored in the out/
+subdirectory of the matching source tree.
+
+On some machines with multiple storage devices, builds are
+faster when storing the source files and the output on
+separate volumes. For additional performance, the output
+can be stored on a filesystem optimized for speed instead
+of crash robustness, since all files can be re-generated
+in case of filesystem corruption.
+
+To set this up, export the `OUT_DIR_COMMON_BASE` variable
+to point to the location where your output directories
+will be stored.
+
+ export OUT_DIR_COMMON_BASE=<path-to-your-out-directory>
+
+The output directory for each separate source tree will be
+named after the directory holding the source tree.
+
+For instance, if you have source trees as `/source/master1`
+and `/source/master2` and `OUT_DIR_COMMON_BASE` is set to
+`/output`, the output directories will be `/output/master1`
+and `/output/master2`.
+
+It's important in that case to not have multiple source
+trees stored in directories that have the same name,
+as those would end up sharing an output directory, with
+unpredictable results.
+
+This is only supported on Jelly Bean (4.1) and newer,
+including the master branch.
+
+# Setting up a Mac OS X build environment #
+
+In a default installation, OS X runs on a case-preserving but case-insensitive
+filesystem. This type of filesystem is not supported by git and will cause some
+git commands (such as "git status") to behave abnormally. Because of this, we
+recommend that you always work with the AOSP source files on a case-sensitive
+filesystem. This can be done fairly easily using a disk image, discussed below.
+
+Once the proper filesystem is available, building the master branch in a modern
+OS X environment is very straightforward. Earlier branches, including ICS,
+require some additional tools and SDKs.
+
+### Creating a case-sensitive disk image ###
+
+You can create a case-sensitive filesystem within your existing OS X environment
+using a disk image. To create the image, launch Disk
+Utility and select "New Image". A size of 25GB is the minimum to
+complete the build, larger numbers are more future-proof. Using sparse images
+saves space while allowing to grow later as the need arises. Be sure to select
+"case sensitive, journaled" as the volume format.
+
+You can also create it from a shell with the following command:
+
+ # hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg
+
+This will create a .dmg (or possibly a .dmg.sparsefile) file which, once mounted, acts as a drive with the required formatting for Android development. For a disk image named "android.dmg" stored in your home directory, you can add the following to your `~/.bash_profile` to mount the image when you execute "mountAndroid":
+
+ # mount the android file image
+ function mountAndroid { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
+
+Once mounted, you'll do all your work in the "android" volume. You can eject it (unmount it) just like you would with an external drive.
+
+## Master branch ##
+
+To build the latest source in a Mac OS environment, you will need an Intel/x86
+machine running MacOS 10.6 (Snow Leopard) or MacOS 10.7 (Lion), along with Xcode
+4.2 (Apple's Developer Tools). Although Lion does not come with a JDK, it should
+install automatically when you attempt to build the source.
+
+The remaining sections for Mac OS X only apply to those who wish to build
+earlier branches.
+
+## Branch 4.0.x and all earlier branches ##
+
+To build android-4.0.x and earlier branches in a Mac OS environment, you need an
+Intel/x86 machine running MacOS 10.5 (Leopard) or MacOS 10.6 (Snow Leopard). You
+will need the MacOS 10.5 SDK.
+
+### Installing required packages ###
+
+- Install Xcode from [the Apple developer site](http://developer.apple.com/).
+We recommend version 3.1.4 or newer, i.e. gcc 4.2.
+Version 4.x could cause difficulties.
+If you are not already registered as an Apple developer, you will have to
+create an Apple ID in order to download.
+
+- Install MacPorts from [macports.org](http://www.macports.org/install.php).
+
+ *Note: Make sure that `/opt/local/bin` appears in your path BEFORE `/usr/bin`. If not, add*
+
+ export PATH=/opt/local/bin:$PATH
+
+ *to your `~/.bash_profile`.*
+
+- Get make, git, and GPG packages from MacPorts:
+
+ $ POSIXLY_CORRECT=1 sudo port install gmake libsdl git-core gnupg
+
+ If using Mac OS 10.4, also install bison:
+
+ $ POSIXLY_CORRECT=1 sudo port install bison
+
+### Reverting from make 3.82 ###
+
+For versions of Android before ICS, there is a bug in gmake 3.82 that prevents android from building. You can install version 3.81 using MacPorts by taking the following steps:
+
+- Edit `/opt/local/etc/macports/sources.conf` and add a line that says
+
+ file:///Users/Shared/dports
+
+ above the rsync line. Then create this directory:
+
+ $ mkdir /Users/Shared/dports
+
+- In the new `dports` directory, run
+
+ $ svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
+
+- Create a port index for your new local repository:
+
+ $ portindex /Users/Shared/dports
+
+- Finally, install the old version of gmake with
+
+ $ sudo port install gmake @3.81
+
+### Setting a file descriptor limit ###
+
+On MacOS the default limit on the number of simultaneous file descriptors open is too low and a highly parallel build process may exceed this limit.
+
+To increase the cap, add the following lines to your `~/.bash_profile`:
+
+ # set the number of open files to be 1024
+ ulimit -S -n 1024
+
+# Next: Download the source #
+
+Your build environment is good to go! Proceed to [downloading the source](downloading.html)....
diff --git a/src/source/known-issues.md b/src/source/known-issues.md
new file mode 100644
index 0000000..076e499
--- /dev/null
+++ b/src/source/known-issues.md
@@ -0,0 +1,246 @@
+<!--
+ 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.
+-->
+
+# Known Issues #
+
+Even with our best care, small problems sometimes slip in. This page keeps
+track of the known issues around using the Android source code.
+
+## Missing CellBroadcastReceiver in toro builds ##
+
+**Symptom**: On AOSP builds for toro (up to Jelly Bean 4.2.1),
+CellBroadcastReceiver doesn't get included in the system.
+
+**Cause**: There's a typo in vendor/samsung/toro/device-partial.mk,
+where PRODUCT_PACKAGES has the K replaced by an H.
+
+**Fix**: Use the latest packages for 4.2.2, or manually fix the typo.
+
+## Missing CTS Native XML Generator ##
+
+**Symptom**: On some builds of IceCreamSandwich and later, the following
+warning is printed early during the build:
+`/bin/bash: line 0: cd: cts/tools/cts-native-xml-generator/src/res: No
+such file or directory`
+
+**Cause**: Some makefile references that path, which doesn't exist.
+
+**Fix**: None. This is a harmless warning.
+
+## Black Gingerbread Emulator ##
+
+**Symptom**: The emulator built directly from the gingerbread branch
+doesn't start and stays stuck on a black screen.
+
+**Cause**: The gingerbread branch uses version R7 of the emulator,
+which doesn't have all the features necessary to run recent versions
+of gingerbread.
+
+**Fix**: Use version R12 of the emulator, and a newer kernel that matches
+those tools. No need to do a clean build.
+
+ $ repo forall platform/external/qemu -c git checkout aosp/tools_r12
+ $ make
+ $ emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7
+
+## Emulator built on MacOS 10.7 Lion doesn't work. ##
+
+**Symptom**: The emulator (any version) built on MacOS 10.7 Lion
+and/or on XCode 4.x doesn't start.
+
+**Cause**: Some change in the development environment causes
+the emulator to be compiled in a way that prevents it from working.
+
+**Fix**: Use an emulator binary from the SDK, which is built on
+MacOS 10.6 with XCode 3 and works on MacOS 10.7.
+
+## Difficulties syncing the source code (proxy issues). ##
+
+**Symptom**: `repo init` or `repo sync` fail with http errors,
+typically 403 or 500.
+
+**Cause**: There are quite a few possible causes, most often
+related to http proxies, which have difficulties handling the
+large amounts of data getting transfered.
+
+**Fix**: While there's no general solution, using python 2.7
+and explicitly using `repo sync -j1` have been reported to
+improve the situation for some users.
+
+## Difficulties syncing the source tree (VirtualBox Ethernet issues). ##
+
+**Symptom**: When running `repo sync` in some VirtualBox installations,
+the process hangs or fails with a variety of possible symptoms.
+One such symptom is
+`DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble)`.
+
+**Cause**: The default network behavior of VirtualBox is to use
+NAT (Network Addrss Translation) to connect the guest system to
+the network. The heavy network activity of repo sync triggers some
+corner cases in the NAT code.
+
+**Fix**: Configure VirtualBox to use bridged network instead of NAT.
+
+## Difficulties syncing the source tree (DNS issues). ##
+
+**Symptom**: When running `repo sync`, the process fails with
+various errors related to not recognizing the hostname. One such
+error is `<urlopen error [Errno -2] Name or service not known>`.
+
+**Cause**: Some DNS systems have a hard time coping with the
+high number of queries involved in syncing the source tree
+(there can be several hundred requests in a worst-case scenario).
+
+**Fix**: Manually resolve the relevant hostnames, and hard-code
+those results locally.
+
+You can resolve them with the `nslookup` command, which will give
+you one numerical IP address for each of those (typically in the
+"Address" part of the output).
+
+ $ nslookup googlesource.com
+ $ nslookup android.googlesource.com
+
+You can then hard-code them locally by editing `/etc/hosts`, and
+adding two lines in that file, of the form:
+
+ aaa.bbb.ccc.ddd googlesource.com
+ eee.fff.ggg.hhh android.googlesource.com
+
+Note that this will only work as long as the servers' addresses
+don't change, and if they do and you can't connect you'll have
+to resolve those hostnames again and edit `etc/hosts` accordingly.
+
+## Difficulties syncing the source tree (TCP issues). ##
+
+**Symptom**: `repo sync` hangs while syncing, often when it's
+completed 99% of the sync.
+
+**Cause**: Some settings in the TCP/IP stack cause difficulties
+in some network environments, such that `repo sync` neither completes
+nor fails.
+
+**Fix**: On linux, `sysctl -w net.ipv4.tcp_window_scaling=0`. On
+MacOS, disable the rfc1323 extension in the network settings.
+
+## `make snod` and emulator builds. ##
+
+**Symptom**: When using `make snod` (make system no dependencies)
+on emulator builds, the resulting build doesn't work.
+
+**Cause**: All emulator builds now run Dex optimization at build
+time by default, which requires to follow all dependencies to
+re-optimize the applications each time the framework changes.
+
+**Fix**: Locally disable Dex optimizations with
+`export WITH_DEXPREOPT=false`, delete the existing optimized
+versions with `make installclean` and run a full build to
+re-generate non-optimized versions. After that, `make snod`
+will work.
+
+## "Permission Denied" during builds. ##
+
+**Symptom**: All builds fail with "Permission Denied", possibly
+along with anti-virus warnings.
+
+**Cause**: Some anti-virus programs mistakenly recognize some
+source files in the Android source tree as if they contained
+viruses.
+
+**Fix**: After verifying that there are no actual viruses
+involved, disable anti-virus on the Android tree. This has
+the added benefit of reducing build times.
+
+## Camera and GPS 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.
+
+**Cause**: Those hardware peripherals require proprietary
+libraries that aren't available in the Android Open Source
+Project.
+
+**Fix**: None.
+
+## Build errors related to using the wrong compiler. ##
+
+**Symptom**: The build fails with various symptoms. One
+such symptom is `cc1: error: unrecognized command line option "-m32"`
+
+**Cause**: The Android build system uses the default compiler
+in the PATH, assuming it's a suitable compiler to generate
+binaries that run on the host. Other situations (e.g. using
+the Android NDK or building the kernel) cause the default
+compiler to not be a host compiler.
+
+**Fix**: Use a "clean" shell, in which no previous
+actions could have swapped the default compiler.
+
+## Build errors caused by non-default tool settings. ##
+
+**Symptom**: The build fails with various symptoms, possibly
+complinaing about missing files or files that have the
+wrong format. One such symptom is `member [...] in archive is not an object`.
+
+**Cause**: The Android build system tends to use many host tools
+and to rely on their default behaviors. Some settings change
+those tools' behaviors and make them behave in ways that
+confuse the build system. Variables known to cause such
+issues are `CDPATH` and `GREP_OPTIONS`.
+
+**Fix**: Build Android in an environment that has as few
+customizations as possible.
+
+## Build error with 4.0.x and earlier on MacOS 10.7. ##
+
+**Symptom**: Building IceCreamSandwich 4.0.x (and older
+versions) fails on MacOS 10.7 with errors similar to this:
+`Undefined symbols for architecture i386: "_SDL_Init"`
+
+**Cause**: 4.0.x is not compatible with MacOS 10.7.
+
+**Fix**: Either downgrade to MacOS 10.6, or use the master
+branch, which can be built on MacOS 10.7.
+
+ $ repo init -b master
+ $ repo sync
+
+## Build error on MacOS with XCode 4.3. ##
+
+**Symptom**: All builds fail when using XCode 4.3.
+
+**Cause**: XCode 4.3 switched the default compiler from
+gcc to llvm, and llvm rejects code that used to be
+accepted by gcc.
+
+**Fix**: Use XCode 4.2.
+
+## Build error with 4.0.x and earlier on Ubuntu 11.10. ##
+
+**Symptom**: Building IceCreamSandwich 4.0.x (and older
+versions) on Ubuntu 11.10 and newer fails with errors similar to this:
+`<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]`
+
+**Cause**: Ubuntu 11.10 uses a version of gcc where that symbol
+is defined by default, and Android also defines that symbol,
+which causes a conflict.
+
+**Fix**: Either downgrade to Ubuntu 10.04, or use the master
+branch, which can be compiled on Ubuntu 11.10 and newer.
+
+ $ repo init -b master
+ $ repo sync
diff --git a/src/source/overview.md b/src/source/overview.md
new file mode 100644
index 0000000..7f664ca
--- /dev/null
+++ b/src/source/overview.md
@@ -0,0 +1,74 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Android Platform Overview #
+
+Our sister site, [developer.android.com](https://developer.android.com/),
+includes feature overviews of the various Android platform versions.
+The links below will take you to developer.android.com where you can view this
+information.
+
+The links below will navigate you away from this site.
+
+## [Android 4.1](https://developer.android.com/about/versions/jelly-bean.html) ##
+
+Android 4.1 corresponded to the "Jelly Bean" milestone branch, and has an API level of 16.
+
+## [Android 4.0](https://developer.android.com/sdk/android-4.0-highlights.html) ##
+
+Android 4.0 corresponded to the "IceCreamSandwich" milestone branch, and has an API level of 14.
+
+## [Android 2.3](https://developer.android.com/sdk/android-2.3-highlights.html) ##
+
+Android 2.3 corresponded to the "Gingerbread" milestone branch, and has an API level of 9.
+In versions 2.3.3 and higher, the API level is 10.
+
+## [Android 2.2](https://developer.android.com/sdk/android-2.2-highlights.html) ##
+
+Android 2.2 corresponded to the "FroYo" milestone branch, and has an API level of 8.
+
+## [Android 2.1](https://developer.android.com/sdk/android-2.0-highlights.html) ##
+
+Android 2.1 corresponded to the "Eclair" milestone branch, and has an API level of 7.
+
+The Eclair branch was also used for 2.0 and 2.0.1; however, both of those
+releases were quickly obsoleted by the version 2.1 Eclair release. As Android
+2.1 includes key bug fixes and improvements not present in 2.0/2.0.1, only
+Android 2.1 should be used for new devices. As there is no compatibility
+program for 2.0 or 2.0.1, the officially compatible Eclair-based release is Android
+2.1. (The linked document refers to Android 2.0, because there were
+no new platform features added in 2.1.)
+
+## [Android 1.6](https://developer.android.com/sdk/android-1.6-highlights.html) ##
+
+Android 1.6 corresponded to the "Donut" milestone branch, and has an API level of 4.
+
+## [Android 1.5](https://developer.android.com/sdk/android-1.5-highlights.html) ##
+
+Android 1.5 corresponded to the "Cupcake" milestone branch, and has an API
+level of 3.
+
+## [Android 1.1](https://developer.android.com/sdk/android-1.1.html) ##
+
+Android 1.1 has an API level of 2. Android 1.1 was known as
+"Petit Four" internally, though this name was not used officially.
+
+## Android 1.0 ##
+
+was the first release of Android, and has an API
+level of 1. Since it was the first released version of Android, no platform
+highlights were prepared for this release.
+
diff --git a/src/source/roles.md b/src/source/roles.md
new file mode 100644
index 0000000..9252ec8
--- /dev/null
+++ b/src/source/roles.md
@@ -0,0 +1,95 @@
+<!--
+ 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.
+-->
+
+# People and Roles #
+
+The Android Open Source Project (AOSP) includes individuals working in a variety
+of roles. As noted in [Our Philosophy](/about/philosophy.html), Google is responsible for Android product management
+and the engineering process for the core framework and platform; however,
+the project considers contributions from any source, not just Google. This
+page describes the kinds of roles that interested parties can take on.
+
+Anyone who is interested in exploring and contributing to Android can use the
+Android Open Source Project resources. Anyone can join the mailing lists, ask
+questions, contribute patches, report bugs, look at submitted patches, and use
+the tools. To get started with the Android code, see [Get Involved](/source/index.html).
+
+## Contributor ##
+
+A "Contributor" is anyone making contributions to the AOSP source code,
+including both employees of Google or other companies, as well as external
+developers who are contributing to Android on their own behalf. There is no
+distinction between Contributors who are employed by Google, and those who are
+not: all engineers use the same tools (git, repo, and gerrit),
+follow the same code review process, and are subject
+to the same requirements on code style and so on.
+
+## Developer ##
+
+A "Developer" is an engineer writing applications that run on Android
+devices. There is, of course, no difference in skillset between a "Developer"
+and a "Contributor", but AOSP uses "Developer" to distinguish between
+engineers using the platform and those contributing to it. Developers are
+(along with end users) the "customers" of the platform that the Contributors
+create. As such, we talk about Developers a lot, though this isn't technically
+a separate role in the AOSP per se.
+
+## Verifier ##
+
+"Verifiers" are responsible for testing change requests. After individuals
+have submitted a significant amount of high-quality code to the project, the
+Project Leads might invite them to become Verifiers. *Note: at this
+time, generally Verifiers are the same as Approvers.*
+
+## Approver ##
+
+"Approvers" are experienced members of the project who have demonstrated their
+design skills and have made significant technical contributions to the
+project. In the code-review process, an Approver decides whether to include or
+exclude a change. Project Leads (who are typically employed by Google) choose
+the Approvers, sometimes promoting to this position Verifiers who have
+demonstrated their expertise within a specific project.
+
+## Project Leads ##
+
+Android consists of a number of sub-projects; you can see these in the git
+repository, as individual .git files. Tech Leads are senior Contributors who
+oversee the engineering for individual Android projects. Typically these tech
+leads will be Google employees. A Project Lead for an individual project is
+responsible for the following:
+
+- Lead all technical aspects of the project; for example, the project roadmap,
+ development, release cycles, versioning, and QA.
+
+- Ensure that the project is QA-ed in time for scheduled Android platform
+ releases.
+
+- Designate Verifiers and Approvers for submitted patches.
+
+- Be fair and unbiased while reviewing changes. Accept or reject patches
+ based on technical merit and alignment with the Android strategy.
+
+- Review changes in a timely manner and make best efforts to communicate
+ when changes are not accepted.
+
+- Optionally maintain a web site for the project for information and
+ documents specific to the project.
+
+- Act as a facilitator in resolving technical conflicts.
+
+- Be a public face for the project and the go-to person for questions
+ related to the project.
+
diff --git a/src/source/submit-patches.md b/src/source/submit-patches.md
new file mode 100644
index 0000000..951ea00
--- /dev/null
+++ b/src/source/submit-patches.md
@@ -0,0 +1,237 @@
+<!--
+ 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.
+-->
+
+# Submitting Patches #
+
+This page describes the full process of submitting a patch to the AOSP, including
+reviewing and tracking changes with [Gerrit](https://android-review.googlesource.com/).
+
+## Prerequisites ##
+
+- Before you follow the instructions on this page, you will need to set up your
+local working environment and get the Android source files. For instructions,
+follow the "Getting Started" section [here](downloading.html).
+
+- For details about Repo and Git, see [Version Control](version-control.html).
+
+- For information about the different roles you can play within the Android
+Open Source community, see [Project roles](/source/roles.html).
+
+- If you plan to contribute code to the Android platform, be sure to read
+the [AOSP's licensing information](/source/licenses.html).
+
+- Note that changes to some of the upstream projects used by Android should be
+made directly to that project, as described in [Upstream Projects](#upstream-projects).
+
+# For contributors #
+
+## Authenticate with the server ##
+
+Before you can upload to Gerrit, you need to establish a password that
+will identify you with the server. You only need to do this once.
+
+- Sign in on the [AOSP Gerrit Server](https://android-review.googlesource.com/).
+
+- Go to Settings -> HTTP Password -> Obtain Password
+
+- Follow the instructions on the subsquent pages, and copy-paste your
+password in `~/.netrc`. If there are two password lines, copy both.
+
+## Start a repo branch ##
+
+For each change you intend to make, start a new branch within the relevant git repository:
+
+ $ repo start NAME .
+
+You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and will not be included on gerrit or the final source tree.
+
+## Make your change ##
+
+Once you have modified the source files (and validated them, please) commit the changes to your local repository:
+
+ $ git add -A
+ $ git commit -s
+
+Provide a detailed description of the change in your commit message. This description will be pushed to the public AOSP repository, so please follow our guidelines for writing changelist descriptions:
+
+- Start with a one-line summary (60 characters max), followed by a blank line. This format is used by git and gerrit for various displays.
+
+ short description on first line
+
+ more detailed description of your patch,
+ which is likely to take up multiple lines.
+
+- The description should focus on what issue it solves, and how it solves it. The second part is somewhat optional when implementing new features, though desirable.
+
+- Include a brief note of any assumptions or background information that may be important when another contributor works on this feature next year.
+
+A unique change ID and your name and email as provided during `repo init` will be automatically added to your commit message.
+
+## Upload to gerrit ##
+
+Once you have committed your change to your personal history, upload it to gerrit with
+
+ $ repo upload
+
+If you have started multiple branches in the same repository, you will be prompted to select which one(s) to upload.
+
+After a successful upload, repo will provide you the URL of a new page on
+[Gerrit](https://android-review.googlesource.com/). Visit this link to view
+your patch on the review server, add comments, or request specific reviewers
+for your patch.
+
+## Uploading a replacement patch ##
+
+Suppose a reviewer has looked at your patch and requested a small modification. You can amend your commit within git, which will result in a new patch on gerrit with the same change ID as the original.
+
+*Note that if you have made other commits since uploading this patch, you will need to manually move your git HEAD.*
+
+ $ git add -A
+ $ git commit --amend
+
+When you upload the amended patch, it will replace the original on gerrit and in your local git history.
+
+## Resolving sync conflicts ##
+
+If other patches are submitted to the source tree that conflict with yours, you will need to rebase your patch on top of the new HEAD of the source repository. The easy way to do this is to run
+
+ $ repo sync
+
+This command first fetches the updates from the source server, then attempts to automatically rebase your HEAD onto the new remote HEAD.
+
+If the automatic rebase is unsuccessful, you will have to perform a manual rebase.
+
+ $ git rebase master
+
+Using `git mergetool` may help you deal with the rebase conflict. Once you have successfully merged the conflicting files,
+
+ $ git rebase --continue
+
+After either automatic or manual rebase is complete, run `repo upload` to submit your rebased patch.
+
+## After a submission is approved ##
+
+After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. Other users will be able to run `repo sync` to pull the update into their local client.
+
+# For reviewers and verifiers #
+
+## Reviewing a change ##
+
+If you are assigned to be the Approver for a change, you need to determine the following:
+
+- Does this change fit within this project's stated purpose?
+
+- Is this change valid within the project's existing architecture?
+
+- Does this change introduce design flaws that will cause problems in the future?
+
+- Does this change follow the best practices that have been established for this project?
+
+- Is this change a good way to perform the described function?
+
+- Does this change introduce any security or instability risks?
+
+If you approve of the change, mark it with LGTM ("Looks Good to Me") within Gerrit.
+
+## Verifying a change ##
+
+If you are assigned to be the Verifier for a change, you need to do the following:
+
+- Patch the change into your local client using one of the Download commands.
+
+- Build and test the change.
+
+- Within Gerrit use Publish Comments to mark the commit as "Verified" or "Fails," and add a message explaining what problems were identified.
+
+## Downloading changes from Gerrit ##
+
+A submission that has been verified and merged will be downloaded with the next `repo sync`. If you wish to download a specific change that has not yet been approved, run
+
+ $ repo download TARGET CHANGE
+
+where TARGET is the local directory into which the change should be downloaded and CHANGE is the
+change number as listed in [Gerrit](https://android-review.googlesource.com/). For more information,
+see the [Repo reference](/source/using-repo.html).
+
+## How do I become a Verifier or Approver? ##
+
+In short, contribute high-quality code to one or more of the Android projects.
+For details about the different roles in the Android Open Source community and
+who plays them, see [Project Roles](/source/roles.html).
+
+## Diffs and comments ##
+
+To open the details of the change within Gerrit, click on the "Id number" or "Subject" of a change. To compare the established code with the updated code, click the file name under "Side-by-side diffs."
+
+## Adding comments ##
+
+Anyone in the community can use Gerrit to add inline comments to code submissions. A good comment will be relevant to the line or section of code to which it is attached in Gerrit. It might be a short and constructive suggestion about how a line of code could be improved, or it might be an explanation from the author about why the code makes sense the way it is.
+
+To add an inline comment, double-click the relevant line of the code and write your comment in the text box that opens. When you click Save, only you can see your comment.
+
+To publish your comments so that others using Gerrit will be able to see them, click the Publish Comments button. Your comments will be emailed to all relevant parties for this change, including the change owner, the patch set uploader (if different from the owner), and all current reviewers.
+
+<a name="upstream-projects"></a>
+
+# Upstream Projects #
+
+Android makes use of a number of other open-source projects, such as the Linux kernel and WebKit, as described in
+[Branches and Releases](/source/code-lines.html). For most projects under `external/`, changes should be made upstream and then the Android maintainers informed of the new upstream release containing these changes. It may also be useful to upload patches that move us to track a new upstream release, though these can be difficult changes to make if the project is widely used within Android like most of the larger ones mentioned below, where we tend to upgrade with every release.
+
+One interesting special case is bionic. Much of the code there is from BSD, so unless the change is to code that's new to bionic, we'd much rather see an upstream fix and then pull a whole new file from the appropriate BSD. (Sadly we have quite a mix of different BSDs at the moment, but we hope to address that in future, and get into a position where we track upstream much more closely.)
+
+## ICU4C ##
+
+All changes to the ICU4C project at `external/icu4c` should be made upstream at
+[icu-project.org/](http://site.icu-project.org/).
+See [Submitting ICU Bugs and Feature Requests](http://site.icu-project.org/bugs) for more.
+
+## LLVM/Clang/Compiler-rt ##
+
+All changes to LLVM-related projects (`external/clang`, `external/compiler-rt`,
+`external/llvm`) should be made upstream at
+[llvm.org/](http://llvm.org/).
+
+## mksh ##
+
+All changes to the MirBSD Korn Shell project at `external/mksh` should be made upstream
+either by sending an eMail to miros-mksh on the mirbsd.o®g domain (no subscription
+required to submit there) or (optionally) at [Launchpad](https://launchpad.net/mksh).
+
+## OpenSSL ##
+
+All changes to the OpenSSL project at `external/openssl` should be made upstream at
+[openssl.org](http://www.openssl.org).
+
+## V8 ##
+
+All changes to the V8 project at `external/v8` should be submitted upstream at
+[code.google.com/p/v8](https://code.google.com/p/v8). See [Contributing to V8](https://code.google.com/p/v8/wiki/Contributing)
+for details.
+
+## WebKit ##
+
+All changes to the WebKit project at `external/webkit` should be made
+upstream at [webkit.org](http://www.webkit.org). The process begins by filing a WebKit bug.
+This bug should use `Android` for the `Platform` and `OS`
+fields only if the bug is specific to Android. Bugs are far more likely to receive the reviewers'
+attention once a proposed fix is added and tests are included. See
+[Contributing Code to WebKit](http://webkit.org/coding/contributing.html) for details.
+
+## zlib ##
+
+All changes to the zlib project at `external/zlib` should be made upstream at
+[zlib.net](http://zlib.net).
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.
+
+[» 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.
+
+[» 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
new file mode 100644
index 0000000..ef6d019
--- /dev/null
+++ b/src/tech/index.md
@@ -0,0 +1,82 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Android Technical Information #
+Welcome to the Android technical documentation section of the site. Here you
+can find technical information useful to people and organizations who are
+looking to modify, contribute to, or port the Android software. This is "under
+the hood" information intended for engineers.
+
+## Dalvik Technical Information ##
+The Dalvik Virtual Machine is the heart of Android. It's a fast, just-in-time
+compiled, optimized bytecode virtual machine. Android applications are
+compiled to Dalvik bytecode and run on the Dalvik VM. This section includes
+detailed information such as the Dalvik bytecode format specification,
+design information on the VM itself, and so on.
+
+[» Dalvik Information](/tech/dalvik/index.html)
+
+
+## Debugging ##
+Android is a large and complex system. This section includes tips and tricks
+about debugging at the platform level.
+
+[» Debugging Information](/tech/debugging/index.html)
+
+
+## Encryption Technical Information ##
+The Android Open-Source Project includes the ability to encrypt the user's data.
+This document is written for 3rd parties developing Android devices who want to
+include support for encryption on their device. It covers the few things that
+must be done so encryption will work.
+
+[» Encryption Information](/tech/encryption/index.html)
+
+##Security Technical Information ##
+Android provides a robust multi-layered security architecture that provides the
+flexibility required for an open platform, while providing protection for all
+users of the platform. This document focuses on the security features of the
+core Android platform.
+
+[» Android Security Overview](/tech/security/index.html)
+
+## Input Technical Information ##
+Android's input subsystem is responsible for supporting touch screens,
+keyboard, joysticks, mice and other devices.
+
+[» Input Information](/tech/input/index.html)
+
+## Data Usage Technical Information ##
+Android's data usage features allow users to understand and control how their
+device uses network data. This document is designed for systems integrators
+and mobile operators, to help explain technical details they should be aware
+of when porting Android to specific devices.
+
+[» Data Usage Information](/tech/datausage/index.html)
+
+## 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.
+
+[» 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.
+
+[» External Storage Technical Information](/tech/storage/index.html)
diff --git a/src/tech/input/key-layout-files.md b/src/tech/input/key-layout-files.md
new file mode 100644
index 0000000..9f3088d
--- /dev/null
+++ b/src/tech/input/key-layout-files.md
@@ -0,0 +1,337 @@
+<!--
+ Copyright 2011 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.
+-->
+
+# Key Layout Files #
+
+Key layout files (`.kl` files) are responsible for mapping Linux key codes
+and axis codes to Android key codes and axis codes and specifying associated
+policy flags.
+
+Device-specific key layout files are *required* for all internal (built-in)
+input devices that have keys, including special keys such as volume, power
+and headset media keys.
+
+Device-specific key layout files are *optional* for other input devices but
+they are *recommended* for special-purpose keyboards and joysticks.
+
+If no device-specific key layout file is available, then the system will
+choose a default instead.
+
+## Location ##
+
+Key layout files are located by USB vendor, product (and optionally version)
+id or by input device name.
+
+The following paths are consulted in order.
+
+* `/system/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl`
+* `/system/usr/keylayout/Vendor_XXXX_Product_XXXX.kl`
+* `/system/usr/keylayout/DEVICE_NAME.kl`
+* `/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl`
+* `/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX.kl`
+* `/data/system/devices/keylayout/DEVICE_NAME.kl`
+* `/system/usr/keylayout/Generic.kl`
+* `/data/system/devices/keylayout/Generic.kl`
+
+When constructing a file path that contains the device name, all characters
+in the device name other than '0'-'9', 'a'-'z', 'A'-'Z', '-' or '_' are replaced by '_'.
+
+## Generic Key Layout File ##
+
+The system provides a special built-in generic key layout file called `Generic.kl`.
+This key layout is intended to support a variety of standard external
+keyboards and joysticks.
+
+*Do not modify the generic key layout!*
+
+## Syntax ##
+
+A key layout file is a plain text file consisting of key or axis declarations
+and flags.
+
+### Key Declarations ###
+
+Key declarations each consist of the keyword `key` followed by a Linux key code
+number and an Android key code name, or the keyword `usage` followed by a HID
+usage and an Android key code name. The HID usage is represented as a 32-bit
+integer, where the high 16-bits represent the HID usage page and the low
+16-bits represent the HID usage ID. Either of these declarations can then be
+followed by an optional set of whitespace delimited policy flags.
+
+ key 1 ESCAPE
+ key 114 VOLUME_DOWN WAKE
+ key 16 Q VIRTUAL WAKE
+ key usage 0x0c006F BRIGHTNESS_UP
+
+The following policy flags are recognized:
+
+* `WAKE`: The key should wake the device when it is asleep. For historical reasons,
+ this flag behaves in the same manner as `WAKE_DROPPED` below.
+* `WAKE_DROPPED`: The key should wake the device when it is asleep but the key itself
+ should be dropped when the wake-up occurs. In a sense, the key's action was to
+ wake the device, but the key itself is not processed.
+* `SHIFT`: The key should be interpreted as if the SHIFT key were also pressed.
+* `CAPS_LOCK`: The key should be interpreted as if the CAPS LOCK key were also pressed.
+* `ALT`: The key should be interpreted as if the ALT key were also pressed.
+* `ALT_GR`: The key should be interpreted as if the RIGHT ALT key were also pressed.
+* `FUNCTION`: The key should be interpreted as if the FUNCTION key were also pressed.
+* `VIRTUAL`: The key is a virtual soft key (capacitive button) that is adjacent to
+ the main touch screen. This causes special debouncing logic to be enabled, see below.
+* `MENU`: Deprecated. Do not use.
+* `LAUNCHER`: Deprecated. Do not use.
+
+### Axis Declarations ###
+
+Axis declarations each consist of the keyword `axis` followed by a Linux axis code
+number, and qualifiers that control the behavior of the axis including at least
+one Android axis code name.
+
+#### Basic Axes ####
+
+A basic axis simply maps a Linux axis code to an Android axis code name.
+
+The following declaration maps `ABS_X` (indicated by `0x00`) to `AXIS_X` (indicated by `X`).
+
+ axis 0x00 X
+
+In the above example, if the value of `ABS_X` is `5` then `AXIS_X` will be set to `5`.
+
+#### Split Axes ####
+
+A split axis maps a Linux axis code to two Android axis code names, such that
+values less than or greater than a threshold are split across two different axes when
+mapped. This mapping is useful when a single physical axis reported by the device
+encodes two different mutually exclusive logical axes.
+
+The following declaration maps values of the `ABS_Y` axis (indicated by `0x01`) to
+`AXIS_GAS` when less than `0x7f` or to `AXIS_BRAKE` when greater than `0x7f`.
+
+ axis 0x01 split 0x7f GAS BRAKE
+
+In the above example, if the value of `ABS_Y` is `0x7d` then `AXIS_GAS` is set
+to `2` (`0x7f - 0x7d`) and `AXIS_BRAKE` is set to `0`. Conversely, if the value of
+`ABS_Y` is `0x83` then `AXIS_GAS` is set to `0` and `AXIS_BRAKE` is set to `4`
+(`0x83 - 0x7f`). Finally, if the value of `ABS_Y` equals the split value of `0x7f`
+then both `AXIS_GAS` and `AXIS_BRAKE` are set to `0`.
+
+#### Inverted Axes ####
+
+An inverted axis inverts the sign of the axis value.
+
+The following declaration maps `ABS_RZ` (indicated by `0x05`) to `AXIS_BRAKE`
+(indicated by `BRAKE`), and inverts the output by negating it.
+
+ axis 0x05 invert AXIS_RZ
+
+In the above example, if the value of `ABS_RZ` is `2` then `AXIS_RZ` is set to `-2`.
+
+#### Center Flat Position Option ####
+
+The Linux input protocol provides a way for input device drivers to specify the
+center flat position of joystick axes but not all of them do and some of them
+provide incorrect values.
+
+The center flat position is the neutral position of the axis, such as when
+a directional pad is in the very middle of its range and the user is not
+touching it.
+
+To resolve this issue, an axis declaration may be followed by a `flat`
+option that specifies the value of the center flat position for the axis.
+
+ axis 0x03 Z flat 4096
+
+In the above example, the center flat position is set to `4096`.
+
+### Comments ###
+
+Comment lines begin with '#' and continue to the end of the line. Like this:
+
+ # A comment!
+
+Blank lines are ignored.
+
+### Examples ###
+
+#### Keyboard ####
+
+ # This is an example of a key layout file for a keyboard.
+
+ key 1 ESCAPE
+ key 2 1
+ key 3 2
+ key 4 3
+ key 5 4
+ key 6 5
+ key 7 6
+ key 8 7
+ key 9 8
+ key 10 9
+ key 11 0
+ key 12 MINUS
+ key 13 EQUALS
+ key 14 DEL
+
+ # etc...
+
+#### System Controls ####
+
+ # This is an example of a key layout file for basic system controls, such as
+ # volume and power keys which are typically implemented as GPIO pins that
+ # the device decodes into key presses.
+
+ key 114 VOLUME_DOWN WAKE
+ key 115 VOLUME_UP WAKE
+ key 116 POWER WAKE
+
+#### Capacitive Buttons ####
+
+ # This is an example of a key layout file for a touch device with capacitive buttons.
+
+ key 139 MENU VIRTUAL
+ key 102 HOME VIRTUAL
+ key 158 BACK VIRTUAL
+ key 217 SEARCH VIRTUAL
+
+#### Headset Jack Media Controls ####
+
+ # This is an example of a key layout file for headset mounted media controls.
+ # A typical headset jack interface might have special control wires or detect known
+ # resistive loads as corresponding to media functions or volume controls.
+ # This file assumes that the driver decodes these signals and reports media
+ # controls as key presses.
+
+ key 163 MEDIA_NEXT WAKE
+ key 165 MEDIA_PREVIOUS WAKE
+ key 226 HEADSETHOOK WAKE
+
+#### Joystick ####
+
+ # This is an example of a key layout file for a joystick.
+
+ # These are the buttons that the joystick supports, represented as keys.
+ key 304 BUTTON_A
+ key 305 BUTTON_B
+ key 307 BUTTON_X
+ key 308 BUTTON_Y
+ key 310 BUTTON_L1
+ key 311 BUTTON_R1
+ key 314 BUTTON_SELECT
+ key 315 BUTTON_START
+ key 316 BUTTON_MODE
+ key 317 BUTTON_THUMBL
+ key 318 BUTTON_THUMBR
+
+ # Left and right stick.
+ # The reported value for flat is 128 out of a range from -32767 to 32768, which is absurd.
+ # This confuses applications that rely on the flat value because the joystick actually
+ # settles in a flat range of +/- 4096 or so. We override it here.
+ axis 0x00 X flat 4096
+ axis 0x01 Y flat 4096
+ axis 0x03 Z flat 4096
+ axis 0x04 RZ flat 4096
+
+ # Triggers.
+ axis 0x02 LTRIGGER
+ axis 0x05 RTRIGGER
+
+ # Hat.
+ axis 0x10 HAT_X
+ axis 0x11 HAT_Y
+
+## Wake Keys ##
+
+Wake keys are special keys that wake the device from sleep, such as the power key.
+
+By default, for internal keyboard devices, no key is a wake key. For external
+keyboard device, all keys are wake keys.
+
+To make a key be a wake key, set the `WAKE_DROPPED` flag in the key layout file
+for the keyboard device.
+
+Note that the `WindowManagerPolicy` component is responsible for implementing wake
+key behavior. Moreover, the key guard may prevent certain keys from functioning
+as wake keys. A good place to start understanding wake key behavior is
+`PhoneWindowManager.interceptKeyBeforeQueueing`.
+
+## Virtual Soft Keys ##
+
+The input system provides special features for implementing virtual soft keys.
+
+There are three cases:
+
+1. If the virtual soft keys are displayed graphically on the screen, as on the
+ Galaxy Nexus, then they are implemented by the Navigation Bar component in
+ the System UI package.
+
+ Because graphical virtual soft keys are implemented at a high layer in the
+ system, key layout files are not involved and the following information does
+ not apply.
+
+2. If the virtual soft keys are implemented as an extended touchable region
+ that is part of the main touch screen, as on the Nexus One, then the
+ input system uses a virtual key map file to translate X / Y touch coordinates
+ into Linux key codes, then uses the key layout file to translate
+ Linux key codes into Android key codes.
+
+ Refer to the section on [Touch Devices](/tech/input/touch-devices.html)
+ for more details about virtual key map files.
+
+ The key layout file for the touch screen input device must specify the
+ appropriate key mapping and include the `VIRTUAL` flag for each key.
+
+3. If the virtual soft keys are implemented as capacitive buttons that are
+ separate from the main touch screen, as on the Nexus S, then the kernel
+ device driver or firmware is responsible for translating touches into
+ Linux key codes which the input system then translates into Android
+ key codes using the key layout file.
+
+ The key layout file for the capacitive button input device must specify the
+ appropriate key mapping and include the `VIRTUAL` flag for each key.
+
+When virtual soft key are located within or in close physical proximity of the
+touch screen, it is easy for the user to accidentally press one of the buttons
+when touching near the bottom of the screen or when sliding a finger from top
+to bottom or from bottom to top on the screen.
+
+To prevent this from happening, the input system applies a little debouncing
+such that virtual soft key presses are ignored for a brief period of time
+after the most recent touch on the touch screen. The delay is called the
+virtual key quiet time.
+
+To enable virtual soft key debouncing, we must do two things.
+
+First, we provide a key layout file for the touch screen or capacitive button
+input device with the `VIRTUAL` flag set for each key.
+
+ key 139 MENU VIRTUAL
+ key 102 HOME VIRTUAL
+ key 158 BACK VIRTUAL
+ key 217 SEARCH VIRTUAL
+
+Then, we set the value of the virtual key quiet time in a resource overlay
+for the framework `config.xml` resource.
+
+ <!-- Specifies the amount of time to disable virtual keys after the screen is touched
+ in order to filter out accidental virtual key presses due to swiping gestures
+ or taps near the edge of the display. May be 0 to disable the feature.
+ It is recommended that this value be no more than 250 ms.
+ This feature should be disabled for most devices. -->
+ <integer name="config_virtualKeyQuietTimeMillis">250</integer>
+
+## Validation ##
+
+Make sure to validate your key layout files using the
+[Validate Keymaps](/tech/input/validate-keymaps.html) tool.
diff --git a/src/tech/sidebar.md b/src/tech/sidebar.md
new file mode 100644
index 0000000..09f2f2f
--- /dev/null
+++ b/src/tech/sidebar.md
@@ -0,0 +1,8 @@
+# Topics #
+- [Dalvik](/tech/dalvik/index.html)
+- [Debugging](/tech/debugging/index.html)
+- [Encryption](/tech/encryption/index.html)
+- [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