s.a.c. redesign, first checkin
Change-Id: I4dead2f18bc5e4a38f204c92198a267c286e775d
diff --git a/src/about/index.html b/src/about/index.html
new file mode 100644
index 0000000..b8f56fc
--- /dev/null
+++ b/src/about/index.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/about/index.md b/src/about/index.md
deleted file mode 100644
index dae8e85..0000000
--- a/src/about/index.md
+++ /dev/null
@@ -1,41 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# About the Android Open Source Project #
-
-Android is an open-source software stack created for mobile phones and
-other devices. The Android Open Source Project (AOSP), led by Google, is
-tasked with the maintenance and further development of Android. Many device
-manufacturers have brought to market devices running Android, and they are
-readibly available around the world.
-
-Our primary purpose is to build an excellent software platform for everyday
-users. A number of companies have committed many engineers to achieve this
-goal, and the result is a full production quality consumer product whose
-source is open for customization and porting.
-
-You can find more information about Android from these pages:
-
-- [Our Project Philosophy and Goals](philosophy.html)
-
-- [People and Roles](/source/roles.html)
-
-- [Interacting with the Project](/source/index.html)
-
-- [Android Compatibility](/compatibility/index.html)
-
-- [Licensing Information](/source/licenses.html)
-
diff --git a/src/about/philosophy.html b/src/about/philosophy.html
new file mode 100644
index 0000000..b8f56fc
--- /dev/null
+++ b/src/about/philosophy.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/about/philosophy.md b/src/about/philosophy.md
deleted file mode 100644
index 995d5e4..0000000
--- a/src/about/philosophy.md
+++ /dev/null
@@ -1,89 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Philosophy and Goals #
-
-Android is an open-source software stack for mobile phones and other
-devices.
-
-## Origin and Goal ##
-
-Android was originated by a group of companies known as the Open Handset
-Alliance, led by Google. Today, many companies -- both original members of the
-OHA and others -- have invested heavily in Android, typically in the form of
-allocating significant engineering resources to improve Android and bring
-Android devices to Market.
-
-We created Android in response to our own experiences launching mobile
-apps. We wanted to make sure that there would always be an open platform
-available for carriers, OEMs, and developers to use to make their innovative
-ideas a reality. We wanted to make sure that there was no central point of
-failure, where one industry player could restrict or control the innovations
-of any other. The solution we chose was an open and open-source platform.
-
-The goal of the Android Open Source Project is to create a successful
-real-world product that improves the mobile experience for end users.
-
-## Governance Philosophy ##
-
-The companies that have invested in Android have done so on its merits,
-because we believe that an open platform is necessary. Android is
-intentionally and explicitly an open-source -- as opposed to free software --
-effort: a group of organizations with shared needs has pooled
-resources to collaborate on a single implementation of a shared product.
-The Android philosophy is pragmatic, first and foremost. The objective is
-a shared product that each contributor can tailor and customize.
-
-Uncontrolled customization can, of course, lead to incompatible
-implementations. To prevent this, the AOSP also maintains the Android
-Compatibility Program, which spells out what it means to be "Android
-compatible", and what is required of device builders to achieve that status.
-Anyone can (and will!) use the Android source code for any purpose, and we
-welcome all such uses. However, in order to take part in the shared
-ecosystem of applications that we are building around Android, device builders
-must participate in the Compatibility Program.
-
-Though Android consists of multiple sub-projects, this is strictly a
-project-management technique. We view and manage Android as a single,
-holistic software product, not a "distribution", specification, or collection
-of replaceable parts. Our intent is that device builders port
-Android to a device; they don't implement a specification or curate a
-distribution.
-
-## How We Work ##
-
-We know that quality does not come without hard work. Along with many
-partners, Google has contributed full-time engineers, product managers, UI
-designers, Quality Assurance, and all the other roles required to bring
-modern devices to market. We roll the open source administration and
-maintenance into the larger product development cycle.
-
-- At any given moment, there is a current latest release of the Android
-platform. This typically takes the form of a branch in the tree.
-
-- Device builders and Contributors work with the current
-latest release, fixing bugs, launching new devices, experimenting with new
-features, and so on.
-
-- In parallel, Google works internally on the next version of the
-Android platform and framework, working according to the product's needs and
-goals. We develop the next version of Android by working with a device partner
-on a flagship device whose specifications are chosen to push Android
-in the direction we believe it should go.
-
-- When the "n+1"th version is ready, it will be published to the public
-source tree, and become the new latest release.
-
diff --git a/src/about/sidebar.md b/src/about/sidebar.md
deleted file mode 100644
index f9f0c6e..0000000
--- a/src/about/sidebar.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Links #
-
-- [Project Philosophy](philosophy.html)
-- [People and Roles](/source/roles.html)
-- [Getting Involved](/source/index.html)
-- [Compatibility](/compatibility/index.html)
-- [Licensing Information](/source/licenses.html)
-
diff --git a/src/accessories/accessories_toc.cs b/src/accessories/accessories_toc.cs
new file mode 100644
index 0000000..3bc5718
--- /dev/null
+++ b/src/accessories/accessories_toc.cs
@@ -0,0 +1,41 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+ <!-- Accessories -->
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>accessories/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>accessories/protocol.html">
+ <span class="en">Open Accessory Protocol</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>accessories/aoa2.html">Version 2.0</a></li>
+ <li><a href="<?cs var:toroot ?>accessories/aoa.html">Version 1.0</a></li>
+ </ul>
+ </li>
+ <li><a href="<?cs var:toroot ?>accessories/audio.html">Building Audio Accessories</a></li>
+ <li><a href="<?cs var:toroot ?>accessories/custom.html">Building Custom Accessories</a></li>
+ </li>
+ <!-- End Accessories -->
+</ul>
\ No newline at end of file
diff --git a/src/accessories/aoa.jd b/src/accessories/aoa.jd
new file mode 100644
index 0000000..3d0c29e
--- /dev/null
+++ b/src/accessories/aoa.jd
@@ -0,0 +1,138 @@
+page.title=Android Open Accessory Protocol 1.0
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>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:</p>
+<ul>
+<li>Wait for and detect connected devices</li>
+<li>Determine the device's accessory mode support</li>
+<li>Attempt to start the device in accessory mode if needed</li>
+<li>Establish communication with the device if it supports the Android accessory protocol</li>
+</ul>
+<p>The following sections explain how to implement these steps.</p>
+<h2 id="wait-for-and-detect-connected-devices">Wait for and Detect Connected Devices</h2>
+<p>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.</p>
+<h2 id="determine-accessory-mode-support">Determine Accessory Mode Support</h2>
+<p>When an Android-powered device is connected, it can be in one of three states:</p>
+<ul>
+<li>The attached device supports Android accessory mode and is already in accessory mode.</li>
+<li>The attached device supports Android accessory mode, but it is not in accessory mode.</li>
+<li>The attached device does not support Android accessory mode.</li>
+</ul>
+<p>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 (<code>0x18D1</code>) and the
+product ID should be <code>0x2D00</code> or <code>0x2D01</code> if the device is already in accessory mode (case A). If
+so, the accessory can now
+<a href="#establish-communication-with-the-device">establish communication with the device</a> through
+bulk transfer endpoints with its own communication protocol. There is no need to start the device
+in accessory mode.</p>
+<p><strong>Note:</strong> <code>0x2D00</code> is reserved for Android-powered devices that
+support accessory mode. <code>0x2D01</code> 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.</p>
+<p>If the vendor and product ID do not match, there is no way to distinguish between states b and c, so
+the accessory <a href="#attempt-to-start-in-accessory-mode">attempts to start the device in accessory mode</a>
+to determine if the device is supported.</p>
+<h2 id="attempt-to-start-in-accessory-mode">Attempt to Start in Accessory Mode</h2>
+<p>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:</p>
+<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>
+
+<p>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
+<a href="#determine-accessory-mode-support">determining the device's accessory mode support</a>
+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
+<a href="#establish-communication-with-the-device">establish communication with the device</a>.</p>
+<p>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.</p>
+<h2 id="establish-communication-with-the-device">Establish Communication with the Device</h2>
+<p>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 <code>0x2D00</code> has one interface with two bulk
+endpoints for input and output communication. A device with product ID of <code>0x2D01</code> 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 <code>SET_CONFIGURATION</code> (<code>0x09</code>) device request, then
+communicate using the endpoints.</p>
+
+
diff --git a/src/accessories/aoa2.jd b/src/accessories/aoa2.jd
new file mode 100644
index 0000000..81a0b23
--- /dev/null
+++ b/src/accessories/aoa2.jd
@@ -0,0 +1,196 @@
+page.title=Android Open Accessory Protocol 2.0
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>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
+<a href="{@docRoot}accessories/aoa.html">first release of AOA</a>.</p>
+<p>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.</p>
+<h2 id="detecting-android-open-accessory-20-support">Detecting Android Open Accessory 2.0 Support</h2>
+<p>In order for an accessory to determine if a connected Android device supports accessories and at
+what protocol level, the accessory must send a <code>getProtocol()</code> command and check the result.
+Android devices supporting the initial version of the Android Open Accessory protocol return a
+<code>1</code>, representing the protocol version number. Devices that support the new features described
+in this document must return <code>2</code> 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
+<a href="http://developer.android.com/tools/adk/adk2.html#src-download">source code</a>
+(<code><adk-src>/adk1/board/AndroidAccessory/AndroidAccessory.cpp</code>) library demonstrates this protocol
+check:</p>
+<pre><code>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;
+}
+</code></pre>
+<p>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:</p>
+<ul>
+<li><strong>accessory</strong> - An interface providing 2 bulk endpoints for communicating with an
+Android application.</li>
+<li><strong>audio</strong> - A new standard USB audio class interface for streaming audio
+from an Android device to an accessory.</li>
+<li><strong>adb</strong> - 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.</li>
+</ul>
+<p>In AOA 1.0, there are only two USB product IDs:</p>
+<ul>
+<li><code>0x2D00</code> - accessory</li>
+<li><code>0x2D01</code> - accessory + adb</li>
+</ul>
+<p>AOA 2.0 adds an optional USB audio interface and, therefore, includes product IDs for the new
+combinations of USB interfaces:</p>
+<ul>
+<li><code>0x2D02</code> - audio</li>
+<li><code>0x2D03</code> - audio + adb</li>
+<li><code>0x2D04</code> - accessory + audio</li>
+<li><code>0x2D05</code> - accessory + audio + adb</li>
+</ul>
+<h2 id="audio-support">Audio Support</h2>
+<p>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.</p>
+<p>To enable the audio support, the accessory must send a new USB control request:</p>
+<pre><code>**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
+</code></pre>
+<p>This command must be sent <em>before</em> sending the <code>ACCESSORY_START</code> command for
+entering accessory mode.</p>
+<h2 id="hid-support">HID Support</h2>
+<p>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.</p>
+<p>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.</p>
+<p>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:</p>
+<ul>
+<li><strong>ACCESSORY_REGISTER_HID</strong> 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
+<code>ACCESSORY_UNREGISTER_HID</code> to unregister the HID device.</li>
+<li><strong>ACCESSORY_UNREGISTER_HID</strong> unregisters a HID device that was previously
+registered with <code>ACCESSORY_REGISTER_HID</code>.</li>
+<li><strong>ACCESSORY_SET_HID_REPORT_DESC</strong> 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 <code>ACCESSORY_SET_HID_REPORT_DESC</code> commands
+are sent in order to transfer the entire descriptor.</li>
+<li><strong>ACCESSORY_SEND_HID_EVENT</strong> sends input events from the accessory to the Android
+device.</li>
+</ul>
+<p>The code definitions for these new control requests are as follows:</p>
+<pre><code>/* 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
+</code></pre>
+<h2 id="interoperability-with-aoa-10-features">Interoperability with AOA 1.0 Features</h2>
+<p>The original <a href="{@docRoot}accessories/aoa.html">AOA protocol</a> 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.</p>
+<h2 id="connecting-aoa-20-without-an-android-app">Connecting AOA 2.0 without an Android App</h2>
+<p>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.</p>
+
diff --git a/src/accessories/audio.jd b/src/accessories/audio.jd
new file mode 100644
index 0000000..cb7a669
--- /dev/null
+++ b/src/accessories/audio.jd
@@ -0,0 +1,70 @@
+page.title=Building Audio Accessories
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>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.</p>
+<h2 id="audio-over-usb">Audio over USB</h2>
+<p>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.</p>
+<p><strong>Note:</strong> 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.</p>
+<h3 id="next-steps">Next steps</h3>
+<p>To get started on building an audio accessory that uses a USB connection:</p>
+<ul>
+<li>Select a hardware platform or build a hardware device that can support USB host mode.</li>
+<li>Review the <a href="{@docRoot}accessories/aoa2.html">AOA 2.0 protocol</a> specification to understand
+ how to implement this protocol on your accessory hardware.</li>
+<li>Review the ADK 2012 <a href="http://developer.android.com/tools/adk/adk2.html#src-download">firmware source code</a>
+ (<code><adk-src>/adk2012/board/library/ADK2/</code>), which includes an example implementation
+ of an audio playback accessory using a USB connection.</li>
+</ul>
+<p><strong>Note:</strong> The AOA 2.0 protocol also supports the
+<a href="{@docRoot}accessories/aoa2.html#hid-support">human interface device</a> (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.</p>
+<h2 id="audio-over-bluetooth">Audio over Bluetooth</h2>
+<p>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.</p>
+<p><strong>Note:</strong> 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
+<a href="http://developer.android.com/reference/android/bluetooth/BluetoothA2dp.html"><code>BluetoothA2dp</code></a>
+class.</p>
+<h3 id="next-steps_1">Next steps</h3>
+<p>To get started on building an audio accessory that uses a Bluetooth connection:</p>
+<ul>
+<li>Select a hardware platform or build an hardware device that can support Bluetooth
+ communications and the A2DP connection profile.</li>
+<li>Review the ADK 2012
+ <a href="http://developer.android.com/tools/adk/adk2.html#src-download">firmware source code</a>
+ (<code><adk-src>/adk2012/board/library/ADK2/</code>), which includes an example implementation
+ of an audio playback accessory using a Bluetooth connection.</li>
+</ul>
+<p><strong>Note:</strong> 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).</p>
+
diff --git a/src/accessories/custom.jd b/src/accessories/custom.jd
new file mode 100644
index 0000000..032aaa2
--- /dev/null
+++ b/src/accessories/custom.jd
@@ -0,0 +1,79 @@
+page.title=Building Custom Accessories
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>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.</p>
+<h2 id="connecting-over-usb">Connecting over USB</h2>
+<p>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.</p>
+<p>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
+<a href="https://developers.google.com/android/add-ons/google-apis/">Add-On Library</a> 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.</p>
+<p>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.</p>
+<h3 id="next-steps">Next steps</h3>
+<p>To get started on building an Android accessory that uses a USB connection:</p>
+<ul>
+<li>Select a hardware platform or build a hardware device that can support USB host mode.</li>
+<li>Review the <a href="{@docRoot}accessories/index.html">AOA protocol</a> specifications to understand
+ how to implement this protocol on your accessory hardware. Implementing the
+ <a href="{@docRoot}accessories/aoa2.html">AOA 2.0 protocol</a> is recommended for all new Android USB
+ accessories.</li>
+<li>Review the ADK 2012 <a href="http://developer.android.com/tools/adk/adk2.html#src-download">firmware source code</a>
+ (<code><adk-src>/adk2012/board/library/ADK2/</code>), which demonstrates an implementation of an accessory
+ using a USB connection for general data communications and audio streaming.</li>
+<li>If you are planning to build an Android application that communicates with your accessory
+ via USB, review the ADK 2012 Android
+ <a href="http://developer.android.com/tools/adk/adk2.html#src-download">application source code</a>
+ (<code><adk-src>/adk2012/app/</code>).</li>
+</ul>
+<h2 id="connecting-over-bluetooth">Connecting over Bluetooth</h2>
+<p>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.</p>
+<p>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.</p>
+<h3 id="next-steps_1">Next steps</h3>
+<p>To get started on building an Android accessory that uses a Bluetooth connection:</p>
+<ul>
+<li>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.</li>
+<li>Review the ADK 2012 <a href="http://developer.android.com/tools/adk/adk2.html#src-download">firmware source code</a>
+ (<code><adk-src>/adk2012/board/library/ADK2/</code>), which includes an example implementation
+ of general data communications and audio streaming using a Bluetooth connection.</li>
+<li>If you are planning to build an Android application that communicates with your accessory
+ via Bluetooth, review the ADK 2012 Android
+ <a href="http://developer.android.com/tools/adk/adk2.html#src-download">application source code</a>
+ (<code><adk-src>/adk2012/app/</code>).</li>
+</ul>
+<p><strong>Note:</strong> 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).</p>
diff --git a/src/accessories/index.jd b/src/accessories/index.jd
new file mode 100644
index 0000000..e374f72
--- /dev/null
+++ b/src/accessories/index.jd
@@ -0,0 +1,43 @@
+page.title=Build Accessories for Android
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Build compelling USB and Bluetooth Accessories to extend
+ the capabilities of your user's Android-powered devices. Android defines an standard
+ protocol that you can implement in your accessories and have it compatible with
+ a wide range of Android-powered devices.
+</p>
+
+<div class="layout-content-row">
+
+ <div class="layout-content-col span-6">
+ <h4 id="audio-accessories">Audio Accessories</h4>
+ <p>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.</p>
+ <p><a href="{@docRoot}accessories/audio.html">» Build Audio Accessories</a></p>
+ </div>
+
+ <div class="layout-content-col span-6">
+ <h4 id="custom-accessories">Custom Accessories</h4>
+ <p>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.</p>
+ <p><a href="{@docRoot}accessories/custom.html">» Build Custom Accessories</a></p>
+ </div>
+
+</div>
+
+
diff --git a/src/accessories/protocol.jd b/src/accessories/protocol.jd
new file mode 100644
index 0000000..23122a1
--- /dev/null
+++ b/src/accessories/protocol.jd
@@ -0,0 +1,44 @@
+page.title=Android Open Accessory Protocol
+@jd:body
+
+<!--
+ Copyright 2013The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<p> Android 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.</p>
+
+
+<p><strong>Note:</strong> 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 <code><uses-feature></code>
+element in your corresponding application's Android manifest. For more information, see the
+<a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html#manifest">USB Accessory</a>
+developer guide.</p>
+
+
+<p>Android Open Accessory support is included in Android 3.1 (API Level 12) and higher, and supported
+through an <a href="https://developers.google.com/android/add-ons/google-apis/">Add-On Library</a> in Android
+2.3.4 (API Level 10) and higher.</p>
+
+
diff --git a/src/app.yaml b/src/app.yaml
new file mode 100644
index 0000000..f8f4788
--- /dev/null
+++ b/src/app.yaml
@@ -0,0 +1,38 @@
+application: androidsourcedocs-staging
+version: 1
+runtime: python
+api_version: 1
+
+# This file defines two mutually exclusive
+# hander blocks:
+# - a handler for use on a local dev_appserver
+# during development or non-production doc build
+# - a handler for use on a production gae
+# instance. This handler requires that the
+# docs files in the app have been compressed
+# with divide_and_compress.py and that main.py
+# and gae_shell/ are present.
+#
+# Only one of the handler blocks should be
+# uncommented at any given time. By default,
+# the development handler is exposed.
+
+handlers:
+
+# DEVELOPMENT HANDLER
+# (this handler block *must* be commented
+# out before pushing to a production server)
+- url: /
+ static_dir: /
+
+# PRODUCTION GAE HANDLER
+#- url: /gae_shell/static
+# static_dir: gae_shell/static
+# expiration: 1d
+#
+#- url: /gae_shell/.*
+# script: /gae_shell/shell.py
+# login: admin
+#
+#- url: .*
+# script: main.py
diff --git a/src/community/groups-charter.html b/src/community/groups-charter.html
new file mode 100644
index 0000000..fd0be49
--- /dev/null
+++ b/src/community/groups-charter.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/community/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/community/groups-charter.md b/src/community/groups-charter.md
deleted file mode 100644
index eea9033..0000000
--- a/src/community/groups-charter.md
+++ /dev/null
@@ -1,60 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Discussion Groups Charter #
-
-## Audience ##
-
-These discussion groups are intended for developers working with the
-Android platform. Everyone is welcome to join in, provided you follow our
-community's policies described below. Our users help each other, and many
-experts post to these groups, including members of the Open Handset Alliance.
-
-No topic is off-limits, provided it relates to Android in some way.
-However, since these are very busy lists, search the archives before posting
-your question; you may find your question has already been answered.
-
-## Mailing list rules ##
-
-We love simplicity and hate restrictions, so we keep our policies minimal.
-The rules below describe what's expected of subscribers to the Android mailing
-lists.
-
-- *Please be friendly*:
- Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive
-toward anyone; if you think there is, think again before you post.
- Mobile development is serious business, but it's also a lot of
-fun. Let's keep it that way. Let's strive to be one of the friendliest
-communities in all of open source.
-
-- *Allowed discussion topics*:
- Most of our groups are for technical discussions of Android or users helping each other. Generally we don't put hard restrictions on the topics discussed in the group: as long as the topic is relevant to Android in some way, it's welcome on our groups. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news,
-but *please do not cross-post*. Post only to the most relevant group for your message. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen.
-
-- *Working Lists*:
- Some of our groups are considered "working lists", by which we mean that the list is intended to be used in support of the completion of specific tasks. On these groups, we don't welcome off-topic conversations, and will generally ask you to take general discussions to a different list. Since these are lists where people are trying to get work done, we will be pretty aggressive about keeping the noise level low. We ask that you respect our contributors' time and keep general discussions to appropriate lists.
-
-- *Spam*:
- We hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
-
-The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one. That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
-
-## Contacting the moderators ##
-
-If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
-
-But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
-
diff --git a/src/community/index.html b/src/community/index.html
new file mode 100644
index 0000000..fd0be49
--- /dev/null
+++ b/src/community/index.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/community/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/community/index.md b/src/community/index.md
deleted file mode 100644
index adc094c..0000000
--- a/src/community/index.md
+++ /dev/null
@@ -1,113 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Community #
-
-Welcome to the Android community!
-
-The key to any community is, obviously, communication. Like most projects,
-Android communicates via mailing lists. Because Android is an extremely large
-project with many components, we have many discussion forums, each focusing on
-a different topic.
-
-Please check out the groups below, and join any that seem interesting to
-you. 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 retailer
-for help with your phone.
-
-Please note that if you're looking for information about building
-applications for Android, you can find a separate set of groups for those at
-our sister site, developer.android.com: [https://developer.android.com/resources/community-groups.html]
-
-## Getting the Most from Our Lists ##
-
-Please consider the following before you post to our lists.
-
-- *Read the [Charter for our forums.](groups-charter.html)* This explains the (few) rules and guidelines for our community.
-
-- *Search the group archives to see whether your questions have already been discussed.* This avoids time-wasting redundant discussions.
-
-- *Use a clear, relevant message subject.* This helps everyone, both those trying to answer your question as well as those who may be looking for information in the future.
-
-- *Give plenty of details in your post.* Code or log snippets, pointers to screenshots, and similar details will get better results and make for better discussions. For a great guide to phrasing your questions, read [How to Ask Questions the Smart Way](http://www.catb.org/%7Eesr/faqs/smart-questions.html).
-<img src="/images/external-link.png">
-
-## Open Source Project discussions ##
-
-- *android-platform*:
- This list is for general discussion about the Android open-source project or the platform technologies.
- - Subscribe using Google Groups: [android-platform](https://groups.google.com/forum/?fromgroups#!forum/android-platform)
- - Subscribe via email: [android-platform](mailto:android-platform+subscribe@googlegroups.com)
-
-- *android-building*:
- Subscribe to this list for discussion and help on building the Android source code, and on the build system. If you've just checked out the source code and have questions about how to turn it into binaries, start here.
- - Subscribe using Google Groups: [android-building](https://groups.google.com/forum/?fromgroups#!forum/android-building)
- - Subscribe via email: [android-building](mailto:android-building+subscribe@googlegroups.com)
-
-- *android-porting*:
- This list is for developers who want to port Android to a new device. If you're wondering how to combine the Android source code with your hardware, this is the right group for you. Discuss here the specifics of porting Android to individual devices, from obtaining toolchains and merging kernel drivers all the way to configuring or modifying applications for your specific
-configuration.
- - Subscribe using Google Groups: [android-porting](https://groups.google.com/forum/?fromgroups#!forum/android-porting)
- - Subscribe via email: [android-porting](mailto:android-porting+subscribe@googlegroups.com)
-
-- *android-contrib*:
- This list is for developers who want to contribute code to Android. This is a working list, and is not appropriate for general discussion. We ask that general discussion go to android-platform. Note: contributors to the Android kernel should go to the android-kernel list, below.
- - Subscribe using Google Groups: [android-contrib](https://groups.google.com/forum/?fromgroups#!forum/android-contrib)
- - Subscribe via email: [android-contrib](mailto:android-contrib+subscribe@googlegroups.com)
-
-- *android-kernel*:
- This list is for deveopers who want to contribute to the Linux kernel that Android devices use. If you've downloaded the kernel code, if you know how to compile it, if you want to write kernel code to specifically support Android,
-this is your place. This group isn't for user-space topics (see android-platform for that), and people will shake their fingers at you and call you naughty if you ask user-space questions here.
- - Subscribe using Google Groups: [android-kernel](https://groups.google.com/forum/?fromgroups#!forum/android-kernel)
- - Subscribe via email: [android-kernel](mailto:android-kernel+subscribe@googlegroups.com)
-
-## Using email with Google Groups ##
-
-Instead of using the [Google groups](https://groups.google.com/) site, you can use your email client of choice to participate in the mailing lists.
-
-To subscribe to a group without using the Google Groups site, use the link under "subscribe via email" in the lists above.
-
-To set up how you receive mailing list postings by email:
-
-1. Sign into the group via the Google Groups site. For example, for the android-platform group you would use [https://groups.google.com/forum/?fromgroups#!forum/android-platform].
-
-1. Click "My membership" on the right side.
-
-1. Under "How do you want to read this group?" select one of the email options.
-
-## Android on IRC ##
-
-We also have a presence on IRC via [freenode](http://freenode.net/).
-We maintain two official IRC channels on [irc.freenode.net](irc://irc.freenode.net/) (access via the web
-at [freenode webchat](http://webchat.freenode.net/))
-
-- [\#android](irc://irc.freenode.net/android) - dedicated to general Android discussion and porting concerns
-
-- [\#android-dev](irc://irc.freenode.net/android-dev) - dedicated to discussion about writing Android applications
-
-The channels above are official. There are a few other channels the
-community is using, but are not official. These aren't official or officially
-moderated/managed, so you use the channels below at your own risk. The Open
-Handset Alliance doesn't endorse these channels, there's no warranty express
-or implied, and so on. There may be more channels than just these listed.
-
-- [\#android-firehose](irc://irc.freenode.net/android-firehose) - displays in real-time the commits to the Android Open Source Project
-
-- [\#android-fr](irc://irc.freenode.net/android-fr) - pour discuter d'Android en français
-
-- [\#android-offtopic](irc://irc.freenode.net/android-offtopic) - for, well, off-topic discussions
-
-- [\#android-root](irc://irc.freenode.net/android-root) - for discussion related to off-label uses of hardware
diff --git a/src/community/sidebar.md b/src/community/sidebar.md
deleted file mode 100644
index 5b72530..0000000
--- a/src/community/sidebar.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Discussion Groups #
-
-- [android-building](https://groups.google.com/forum/?fromgroups#!forum/android-building) (off-site)
-- [android-contrib](https://groups.google.com/forum/?fromgroups#!forum/android-contrib) (off-site)
-- [android-kernel](https://groups.google.com/forum/?fromgroups#!forum/android-kernel) (off-site)
-- [android-platform](https://groups.google.com/forum/?fromgroups#!forum/android-platform) (off-site)
-- [android-porting](https://groups.google.com/forum/?fromgroups#!forum/android-porting) (off-site)
-- [repo-discuss](https://groups.google.com/forum/?fromgroups#!forum/repo-discuss) (off-site)
-
-# Other Links #
-
-- [Groups Charter](groups-charter.html)
-- [App Developer Groups](https://developer.android.com/resources/community-groups.html) (off-site)
-
diff --git a/src/compatibility/2.1/versions.jd b/src/compatibility/2.1/versions.jd
new file mode 100644
index 0000000..cbc12ef
--- /dev/null
+++ b/src/compatibility/2.1/versions.jd
@@ -0,0 +1,22 @@
+page.title=Permitted Version Strings for Android 2.1
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.1-cdd.pdf">Android 2.1 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.1-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 2.1 are:</p>
+<ul>
+<li>
+<p>2.1</p>
+</li>
+<li>
+<p>2.1-update1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/2.1/versions.md b/src/compatibility/2.1/versions.md
deleted file mode 100644
index 143b4a7..0000000
--- a/src/compatibility/2.1/versions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Permitted Version Strings for Android 2.1 #
-
-As described in Section 3.2.2 of the [Android 2.1 Compatibility Definition](/cdds/android-2.1-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.1-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.1 are:
-
-- 2.1
-
-- 2.1-update1
-
diff --git a/src/compatibility/2.2/versions.jd b/src/compatibility/2.2/versions.jd
new file mode 100644
index 0000000..5846316
--- /dev/null
+++ b/src/compatibility/2.2/versions.jd
@@ -0,0 +1,22 @@
+page.title=Permitted Version Strings for Android 2.2
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.2-cdd.pdf">Android 2.2 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.2-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 2.2 are:</p>
+<ul>
+<li>
+<p>2.2</p>
+</li>
+<li>
+<p>2.2.1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/2.2/versions.md b/src/compatibility/2.2/versions.md
deleted file mode 100644
index 571760a..0000000
--- a/src/compatibility/2.2/versions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Permitted Version Strings for Android 2.2 #
-
-As described in Section 3.2.2 of the [Android 2.2 Compatibility Definition](/cdds/android-2.2-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.2-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.2 are:
-
-- 2.2
-
-- 2.2.1
-
diff --git a/src/compatibility/2.3/versions.jd b/src/compatibility/2.3/versions.jd
new file mode 100644
index 0000000..a3b5481
--- /dev/null
+++ b/src/compatibility/2.3/versions.jd
@@ -0,0 +1,17 @@
+page.title=Permitted Version Strings for Android 2.3
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-2.3-cdd.pdf">Android 2.3 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 2.3-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 2.3 are:</p>
+<ul>
+<li>2.3.3</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/2.3/versions.md b/src/compatibility/2.3/versions.md
deleted file mode 100644
index 5cb3e68..0000000
--- a/src/compatibility/2.3/versions.md
+++ /dev/null
@@ -1,32 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Permitted Version Strings for Android 2.3 #
-
-As described in Section 3.2.2 of the [Android 2.3 Compatibility Definition](/cdds/android-2.3-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 2.3-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 2.3 are:
-
-- 2.3.3
diff --git a/src/compatibility/4.0/versions.jd b/src/compatibility/4.0/versions.jd
new file mode 100644
index 0000000..12039ba
--- /dev/null
+++ b/src/compatibility/4.0/versions.jd
@@ -0,0 +1,28 @@
+page.title=Permitted Version Strings for Android 4.0
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.0-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.0 are:</p>
+<ul>
+<li>
+<p>4.0</p>
+</li>
+<li>
+<p>4.0.1</p>
+</li>
+<li>
+<p>4.0.3</p>
+</li>
+<li>
+<p>4.0.4</p>
+</li>
+</ul>
diff --git a/src/compatibility/4.0/versions.md b/src/compatibility/4.0/versions.md
deleted file mode 100644
index 895b820..0000000
--- a/src/compatibility/4.0/versions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Permitted Version Strings for Android 4.0 #
-
-As described in Section 3.2.2 of the [Android 4.0 Compatibility Definition](/cdds/android-4.0-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 4.0-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 4.0 are:
-
-- 4.0
-
-- 4.0.1
-
-- 4.0.3
-
-- 4.0.4
diff --git a/src/compatibility/4.1/android-4.1-cdd.pdf b/src/compatibility/4.1/android-4.1-cdd.pdf
index 4e54ccf..46b6482 100644
--- a/src/compatibility/4.1/android-4.1-cdd.pdf
+++ b/src/compatibility/4.1/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.1/versions.jd b/src/compatibility/4.1/versions.jd
new file mode 100644
index 0000000..9a3106c
--- /dev/null
+++ b/src/compatibility/4.1/versions.jd
@@ -0,0 +1,22 @@
+page.title=Permitted Version Strings for Android 4.1
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.1-cdd.pdf">Android 4.1 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.1-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.1 are:</p>
+<ul>
+<li>
+<p>4.1</p>
+</li>
+<li>
+<p>4.1.1</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/4.1/versions.md b/src/compatibility/4.1/versions.md
deleted file mode 100644
index 9b04064..0000000
--- a/src/compatibility/4.1/versions.md
+++ /dev/null
@@ -1,34 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Permitted Version Strings for Android 4.1 #
-
-As described in Section 3.2.2 of the [Android 4.1 Compatibility Definition](/cdds/android-4.1-cdd.pdf),
-only certain strings are allowable for the system property
-`android.os.Build.VERSION.RELEASE`. The reason for this is that
-applications and web sites may rely on predictable values for this string, and
-so that end users can easily and reliably identify the version of Android
-running on their devices.
-
-Because subsequent releases of the Android software may revise this string,
-but not change any API behavior, such releases may not be accompanied by a new
-Compatibility Definition Document. This page lists the versions that are
-allowable by an Android 4.1-based system. The only permitted values for
-`android.os.Build.VERSION.RELEASE` for Android 4.1 are:
-
-- 4.1
-
-- 4.1.1
diff --git a/src/compatibility/4.2/android-4.2-cdd.pdf b/src/compatibility/4.2/android-4.2-cdd.pdf
new file mode 100755
index 0000000..10addf3
--- /dev/null
+++ b/src/compatibility/4.2/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.2/versions.jd b/src/compatibility/4.2/versions.jd
new file mode 100644
index 0000000..065085b
--- /dev/null
+++ b/src/compatibility/4.2/versions.jd
@@ -0,0 +1,17 @@
+page.title=Permitted Version Strings for Android 4.2
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a href="/cdds/android-4.2-cdd.pdf">Android 4.2 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 4.2-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 4.2 are:</p>
+<ul>
+<li>4.2</li>
+</ul>
diff --git a/src/compatibility/android-4.1-cdd.pdf b/src/compatibility/android-4.1-cdd.pdf
old mode 100644
new mode 100755
index 4e54ccf..46b6482
--- a/src/compatibility/android-4.1-cdd.pdf
+++ b/src/compatibility/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-4.2-cdd.pdf b/src/compatibility/android-4.2-cdd.pdf
new file mode 100755
index 0000000..10addf3
--- /dev/null
+++ b/src/compatibility/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-cts-manual-r5.pdf b/src/compatibility/android-cts-manual-r6.pdf
similarity index 82%
rename from src/compatibility/android-cts-manual-r5.pdf
rename to src/compatibility/android-cts-manual-r6.pdf
index 5f911dc..5f4173b 100644
--- a/src/compatibility/android-cts-manual-r5.pdf
+++ b/src/compatibility/android-cts-manual-r6.pdf
Binary files differ
diff --git a/src/compatibility/compatibility.jd b/src/compatibility/compatibility.jd
new file mode 100644
index 0000000..5d07a95
--- /dev/null
+++ b/src/compatibility/compatibility.jd
@@ -0,0 +1,203 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>
+ In this document
+ </h2>
+ <ol>
+ <li><a href="#arch">Android Low-Level System Architecture</a></li>
+ <li><a href="#pdk">PDK Components</a></li>
+ <li><a href="#inc-ex">PDK Inclusions and Exclusions</a></li>
+ <li><a href="#knownissues">Support and Known Issues</a></li>
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android Platform Development Kit (PDK) Guide! The Android PDK allows partners to port
+ their drivers as well as develop, optimize, and test against an upcoming Android platform release.
+ The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL),
+ platform sources for integration, a binary system image, and HAL and integration documentation.
+ In addition, the PDK also ships with the Android Compatibility Test Suite (CTS).
+</p>
+
+<h2 id="arch">Android Low-Level System Architecture</h2>
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree as well as the PDK.
+The following diagram shows a system level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="http://source.android.com/source/building-kernels.html" >Building Kernels</a>.
+</p>
+
+
+<h2 id="pdk">PDK Components</h2>
+<p>Now that you have a high-level overview of the Android system, we'll go over the PDK and what it provides
+ to port Android to your product. The PDK provides source files needed to implement
+ your product and a platform binary that lets you build a runnable system image. You can then install
+ this barebones image to test your product with the latest builds of Android. The most important source files
+ included in the PDK are located in the:</p>
+
+ <ul>
+ <li><code>frameworks/native</code> directory</li>
+ <li><code>frameworks/av</code> directory for media, camera, DRM, and the audio framework stack</code></li>
+ <li><code>hardware/libhardware/include/hardware</code> directory for the HAL interfaces </li>
+ <li><code>vendor/pdk/data/cts</code> directory for the CTS binaries</li>
+ </ul>
+</p>
+<p>In addition, the Android PDK includes the following source directories:</p>
+<ul>
+ <li>abi</li>
+ <li>bionic</li>
+ <li>bootable</li>
+ <li>build</li>
+ <li>device</li>
+ <li>external (Chromium and Webkit are not included)</li>
+ <li>hardware</li>
+ <li>libnativehelper</li>
+ <li>pdk</li>
+ <li>prebuilt</li>
+ <li>prebuilts</li>
+ <li>system</li>
+</ul>
+
+ <p>The PDK also contains documentation that is split into three different sections:</p>
+ <ul>
+ <li><a href="{@docRoot}guide/getting_started.html">Getting Started</a> - Explains how to download the PDK source, how the Android build system works, and how to configure a build for your specific product.</li>
+ <li><a href="{@docRoot}guide/hal.html">The Hardware Abstraction Layer</a> - Explains the various HALs provided by Android and the interfaces (C header files) that define them. </li>
+ <li><a href="{@docRoot}guide/reference/files.html">HAL reference</a> - A quick reference for the various HAL interfaces.</li>
+ </ul>
+
+<h3 id="cts">Compatibility Test Suite</h3>
+<p>CTS binaries for ARM, MIPS, and x86 are provided in the corresponding directories in <code>vendor/pdk/data/cts</code>. Only the ARM
+ variant is Google-verified as there is no Nexus device running on any other architecture. Not all of the CTS tests since the
+ complete Android platform is not present. The following CTS tests should work:</p>
+
+<ul>
+ <li>android.bluetooth</li>
+ <li>android.graphics</li>
+ <li>android.graphics2</li>
+ <li>android.hardware</li>
+ <li>android.location</li>
+ <li>android.opengl</li>
+ <li>android.openglperf</li>
+ <li>android.media</li>
+ <li>android.mediastress</li>
+ <li>android.nativemedia.sl</li>
+ <li>android.nativemedia.xa</li>
+ <li>android.net</li>
+ <li>android.renderscript</li>
+ </ul>
+ <p>You can run individual packages such as <code>android.media</code> with:</p>
+ <pre>cts-tradefed run singleCommand cts --skip-device-info --package android.media</pre>
+</ul>
+
+ <p>Because the PDK is missing many components compared to a full Android source tree,
+ there is a PDK test plan that is provided with CTS that limits the tests that are ran when using the PDK. You can run
+ this special test plan with the following command:</p>
+
+ <pre>run cts --plan PDK</pre>
+
+<p>CTS is always actively under development, so we expect some tests to fail. CTS results
+ for the Galaxy Nexus are provided for you in the
+ the <code>vendor/pdk/data/cts/</code> directory and will show which tests fail on that
+ device. You can safely ignore the failed tests for your devices as well.</p>
+
+ <p>See the <a href="http://source.android.com/compatibility/cts-intro.html">CTS manual</a> for more information on CTS.</p>
+
+<h2 id="inc-ex">PDK Inclusions and Exclusions</h2>
+<p>The PDK is a subset of the complete Android source tree and might be missing things that you might need. Here is a list of what the PDK supports
+ and does not support:</p>
+<ul>
+ <li>Supports building Android apps using the publicly available, standard SDK. Builds with non-public platform APIs are not supported. The JNI build is supported.</li>
+ <li>Supports only <code>en_US</code> locale.</li>
+ <li>Supports only phone layouts. Tablet layouts are not included.</li>
+ <li>Enables support for software navigation buttons by default, which you can disable by setting <code>qemu.jw.mainkeys=1</code>.</li>
+ <li>Builds all binaries with SMP (symmetric multiprocessing) features enabled. This might have a small performance impact on non-SMP CPUs.</li>
+ <li>Includes a minimal amount of Java libraries. Obtain any additional Java libraries from the publicly released Android source tree.</li>
+ <li>Contains a minimum number of applications. Build and install necessary applications as needed.</li>
+ <li>Does not support media streaming.</li>
+ <li>Does not include non-Latin fonts. (set by <code>MINIMAL_FONT_FOOTPRINT</code> variable in <code>BoardConfig.mk</code>).
+ An app might crash if it requires such fonts. </li>
+ <li>Does not support replacing framework resources by using the overlay mechanism.
+ This means all configurations controlled by framework resources are fixed.</li>
+ <li>Does not support NFC</li>
+ <li>Does not support DRM</li>
+</ul>
+
+<h2 id="knownissues">Support and Known Issues</h2>
+<p>
+For questions or to report issues related with the PDK, send a message to the <a href="https://groups.google.com/a/google.com/forum/?fromgroups#!forum/android-pdk-feedback">android-pdk@google.com</a> mailing list.</p>
+
+<p>The following list describes the known issues with the PDK:</p>
+<ul>
+ <li>After running the CTS (Compatibility Test Suite), <code>android.process.acore</code> crashes. This is caused by
+some missing components in PDK and does not affect the operation of CTS tests.</li>
+</p>
diff --git a/src/compatibility/compatibility_toc.cs b/src/compatibility/compatibility_toc.cs
new file mode 100644
index 0000000..ed83355
--- /dev/null
+++ b/src/compatibility/compatibility_toc.cs
@@ -0,0 +1,37 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+<!-- Compatibility -->
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>compatibility/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>compatibility/overview.html">CTS Overview</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/cts-intro.html">CTS Introduction</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/cts-development.html">CTS Development</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/android-4.2-cdd.pdf">Compatibility Definition Document (CDD)</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/downloads.html">Downloads</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/contact-us.html">Contact Us</a></li>
+ </ul>
+<!-- End Compatibility -->
+ </li>
+
+
+</ul>
\ No newline at end of file
diff --git a/src/compatibility/contact-us.jd b/src/compatibility/contact-us.jd
new file mode 100644
index 0000000..3c9418c
--- /dev/null
+++ b/src/compatibility/contact-us.jd
@@ -0,0 +1,39 @@
+page.title=Contact Us
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<p>Thanks for your interest in Android compatibility!</p>
+<p>If you have questions about Android compatibility that aren't covered in
+this site, you can reach us in one of a few different ways. To get the most
+out of any of these options, please first read "Getting the Most from Our
+Lists" on the <a href="index.html">Community page</a></p>
+<h2 id="for-general-discussion">For General Discussion</h2>
+<p>The preferred way to reach us is via the <a href="mailto:compatibility@android.com">compatibility@android.com</a> address.</p>
+<h2 id="for-cts-technical-questions">For CTS Technical Questions</h2>
+<p>If you have specific issues with the Compatibility Test Suite that require
+you to disclose information you'd prefer not to be public, you can contact an
+email address we've set up specifically this purpose: <a href="mailto:cts@android.com">cts@android.com</a>. This email address is for
+cases that require disclosure of confidential information only, so general
+questions will be directed back to the public android-compatibility
+list. Note also that this list is for specific technical questions; general
+inquiries will also be directed back to the <a href="https://groups.google.com/forum/?fromgroups#!forum/android-compatibility">android-compatibility list.</a></p>
+<h2 id="for-business-inquiries">For Business Inquiries</h2>
+<p>Finally, business inquiries about the compatibility program, including
+requests to use branding elements and so on, can be sent to the address <a href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>. Like
+the CTS address, this address is for specific, private inquiries; general
+questions will be directed back to the android-compatibility list.</p>
diff --git a/src/compatibility/contact-us.md b/src/compatibility/contact-us.md
deleted file mode 100644
index 285ddca..0000000
--- a/src/compatibility/contact-us.md
+++ /dev/null
@@ -1,45 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Contact Us #
-
-Thanks for your interest in Android compatibility!
-
-If you have questions about Android compatibility that aren't covered in
-this site, you can reach us in one of a few different ways. To get the most
-out of any of these options, please first read "Getting the Most from Our
-Lists" on the [Community page](index.html)
-
-## For General Discussion ##
-
-The preferred way to reach us is via the [compatibility@android.com](mailto:compatibility@android.com) address.
-
-## For CTS Technical Questions ##
-
-If you have specific issues with the Compatibility Test Suite that require
-you to disclose information you'd prefer not to be public, you can contact an
-email address we've set up specifically this purpose: [cts@android.com](mailto:cts@android.com). This email address is for
-cases that require disclosure of confidential information only, so general
-questions will be directed back to the public android-compatibility
-list. Note also that this list is for specific technical questions; general
-inquiries will also be directed back to the [android-compatibility list.](https://groups.google.com/forum/?fromgroups#!forum/android-compatibility)
-
-## For Business Inquiries ##
-
-Finally, business inquiries about the compatibility program, including
-requests to use branding elements and so on, can be sent to the address [android-partnerships@google.com](mailto:android-partnerships@google.com). Like
-the CTS address, this address is for specific, private inquiries; general
-questions will be directed back to the android-compatibility list.
diff --git a/src/compatibility/cts-development.jd b/src/compatibility/cts-development.jd
new file mode 100644
index 0000000..bacbd9c
--- /dev/null
+++ b/src/compatibility/cts-development.jd
@@ -0,0 +1,109 @@
+page.title=CTS Development
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<h2 id="initializing-your-repo-client">Initializing Your Repo Client</h2>
+<p>Follow the <a href="/source/downloading.html">instructions</a>
+to get and build the Android source code but specify <code>-b android-4.2_r1</code>
+when issuing the <code>repo init</code> command. This assures that your CTS
+changes will be included in the next CTS release and beyond.</p>
+<h2 id="setting-up-eclipse">Setting Up Eclipse</h2>
+<p>Follow the <a href="/source/using-eclipse.html">instructions</a>
+to setup Eclipse but execute the following command to generate the
+<code>.classpath</code> file rather than copying the one from the development
+project:</p>
+<pre><code>cd /path/to/android/root
+./cts/development/ide/eclipse/genclasspath.sh > .classpath
+chmod u+w .classpath
+</code></pre>
+<p>This <code>.classpath</code> file will contain both the Android framework
+packages and the CTS packages.</p>
+<h2 id="building-and-running-cts">Building and Running CTS</h2>
+<p>Execute the following commands to build CTS and start the interactive
+CTS console:</p>
+<pre><code>cd /path/to/android/root
+make cts
+cts-tradefed
+</code></pre>
+<p>At the cts-tf console, enter e.g.:</p>
+<pre><code>run cts --plan CTS
+</code></pre>
+<h2 id="writing-cts-tests">Writing CTS Tests</h2>
+<p>CTS tests use JUnit and the Android testing APIs. Review the
+<a href="https://developer.android.com/guide/topics/testing/testing_android.html">Testing and Instrumentation</a>
+tutorial while perusing the existing tests under the
+<code>cts/tests/tests</code> directory. You will see that CTS tests mostly follow the same
+conventions used in other Android tests.</p>
+<p>Since CTS runs across many production devices, the tests must follow
+these rules:</p>
+<ul>
+<li>Must take into account varying screen sizes, orientations, and keyboard layouts.</li>
+<li>Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.</li>
+<li>Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.</li>
+<li>Don't rely upon root privileges.</li>
+</ul>
+<h3 id="test-naming-and-location">Test Naming and Location</h3>
+<p>Most CTS test cases target a specific class in the Android API. These tests
+have Java package names with a <code>cts</code> suffix and class
+names with the <code>Test</code> suffix. Each test case consists of
+multiple tests, where each test usually exercises a particular API method of
+the API class being tested. These tests are arranged in a directory structure
+where tests are grouped into different categories like "widgets" and "views."</p>
+<p>For example, the CTS test for <code>android.widget.TextView</code> is
+<code>android.widget.cts.TextViewTest</code> found under the
+<code>cts/tests/tests/widget/src/android/widget/cts</code> directory with its
+Java package name as <code>android.widget.cts</code> and its class name as
+<code>TextViewTest</code>. The <code>TextViewTest</code> class has a test called <code>testSetText</code>
+that exercises the "setText" method and a test named "testSetSingleLine" that
+calls the <code>setSingleLine</code> method. Each of those tests have <code>@TestTargetNew</code>
+annotations indicating what they cover.</p>
+<p>Some CTS tests do not directly correspond to an API class but are placed in
+the most related package possible. For instance, the CTS test,
+<code>android.net.cts.ListeningPortsTest</code>, is in the <code>android.net.cts</code>, because it
+is network related even though there is no <code>android.net.ListeningPorts</code> class.
+You can also create a new test package if necessary. For example, there is an
+"android.security" test package for tests related to security. Thus, use your
+best judgement when adding new tests and refer to other tests as examples.</p>
+<p>Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew.
+These are no longer necessary so do not annotate new tests with these.</p>
+<h3 id="new-test-packages">New Test Packages</h3>
+<p>When adding new tests, there may not be an existing directory to place your
+test. In that case, refer to the example under <code>cts/tests/tests/example</code> and
+create a new directory. Furthermore, make sure to add your new package's
+module name from its <code>Android.mk</code> to <code>CTS_COVERAGE_TEST_CASE_LIST</code> in
+<code>cts/CtsTestCaseList.mk</code>. This Makefile is used by <code>build/core/tasks/cts.mk</code>
+to glue all the tests together to create the final CTS package.</p>
+<h3 id="test-stubs-and-utilities">Test Stubs and Utilities</h3>
+<p>Some tests use additional infrastructure like separate activities
+and various utilities to perform tests. These are located under the
+<code>cts/tests/src</code> directory. These stubs aren't separated into separate test
+APKs like the tests, so the <code>cts/tests/src</code> directory does not have additional
+top level directories like "widget" or "view." Follow the same principle of
+putting new classes into a package with a name that correlates to the purpose
+of your new class. For instance, a stub activity used for testing OpenGL like
+<code>GLSurfaceViewStubActivity</code> belongs in the <code>android.opengl.cts</code> package under
+the <code>cts/tests/src/android/opengl</code> directory.</p>
+<h2 id="other-tasks">Other Tasks</h2>
+<p>Besides adding new tests there are other ways to contribute to CTS:</p>
+<ul>
+<li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li>
+</ul>
+<h2 id="submitting-your-changes">Submitting Your Changes</h2>
+<p>Follow the <a href="/source/submit-patches.html">Android Contributors' Workflow</a>
+to contribute changes to CTS. A reviewer
+will be assigned to your change, and your change should be reviewed shortly!</p>
diff --git a/src/compatibility/cts-development.md b/src/compatibility/cts-development.md
deleted file mode 100644
index 6cee879..0000000
--- a/src/compatibility/cts-development.md
+++ /dev/null
@@ -1,130 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# CTS Development #
-
-## Initializing Your Repo Client ##
-
-Follow the [instructions](/source/downloading.html)
-to get and build the Android source code but specify `-b android-4.1.1_r1`
-when issuing the `repo init` command. This assures that your CTS
-changes will be included in the next CTS release and beyond.
-
-## Setting Up Eclipse ##
-
-Follow the [instructions](/source/using-eclipse.html)
-to setup Eclipse but execute the following command to generate the
-`.classpath` file rather than copying the one from the development
-project:
-
- cd /path/to/android/root
- ./cts/development/ide/eclipse/genclasspath.sh > .classpath
- chmod u+w .classpath
-
-This `.classpath` file will contain both the Android framework
-packages and the CTS packages.
-
-## Building and Running CTS ##
-
-Execute the following commands to build CTS and start the interactive
-CTS console:
-
- cd /path/to/android/root
- make cts
- cts
-
-Provide arguments to CTS to immediately start executing a test:
-
- cts start --plan CTS -p android.os.cts.BuildVersionTest
-
-## Writing CTS Tests ##
-
-CTS tests use JUnit and the Android testing APIs. Review the
-[Testing and Instrumentation](https://developer.android.com/guide/topics/testing/testing_android.html)
-tutorial while perusing the existing tests under the
-`cts/tests/tests` directory. You will see that CTS tests mostly follow the same
-conventions used in other Android tests.
-
-Since CTS runs across many production devices, the tests must follow
-these rules:
-
-- Must take into account varying screen sizes, orientations, and keyboard layouts.
-- Only use public API methods. In other words, avoid all classes, methods, and fields that are annotated with the "hide" annotation.
-- Avoid relying upon particular view layouts or depend on the dimensions of assets that may not be on some device.
-- Don't rely upon root privileges.
-
-### Test Naming and Location ###
-
-Most CTS test cases target a specific class in the Android API. These tests
-have Java package names with a `cts` suffix and class
-names with the `Test` suffix. Each test case consists of
-multiple tests, where each test usually exercises a particular API method of
-the API class being tested. These tests are arranged in a directory structure
-where tests are grouped into different categories like "widgets" and "views."
-
-For example, the CTS test for `android.widget.TextView` is
-`android.widget.cts.TextViewTest` found under the
-`cts/tests/tests/widget/src/android/widget/cts` directory with its
-Java package name as `android.widget.cts` and its class name as
-`TextViewTest`. The `TextViewTest` class has a test called `testSetText`
-that exercises the "setText" method and a test named "testSetSingleLine" that
-calls the `setSingleLine` method. Each of those tests have `@TestTargetNew`
-annotations indicating what they cover.
-
-Some CTS tests do not directly correspond to an API class but are placed in
-the most related package possible. For instance, the CTS test,
-`android.net.cts.ListeningPortsTest`, is in the `android.net.cts`, because it
-is network related even though there is no `android.net.ListeningPorts` class.
-You can also create a new test package if necessary. For example, there is an
-"android.security" test package for tests related to security. Thus, use your
-best judgement when adding new tests and refer to other tests as examples.
-
-Finally, a lot of tests are annotated with @TestTargets and @TestTargetNew.
-These are no longer necessary so do not annotate new tests with these.
-
-### New Test Packages ###
-
-When adding new tests, there may not be an existing directory to place your
-test. In that case, refer to the example under `cts/tests/tests/example` and
-create a new directory. Furthermore, make sure to add your new package's
-module name from its `Android.mk` to `CTS_COVERAGE_TEST_CASE_LIST` in
-`cts/CtsTestCaseList.mk`. This Makefile is used by `build/core/tasks/cts.mk`
-to glue all the tests together to create the final CTS package.
-
-### Test Stubs and Utilities ###
-
-Some tests use additional infrastructure like separate activities
-and various utilities to perform tests. These are located under the
-`cts/tests/src` directory. These stubs aren't separated into separate test
-APKs like the tests, so the `cts/tests/src` directory does not have additional
-top level directories like "widget" or "view." Follow the same principle of
-putting new classes into a package with a name that correlates to the purpose
-of your new class. For instance, a stub activity used for testing OpenGL like
-`GLSurfaceViewStubActivity` belongs in the `android.opengl.cts` package under
-the `cts/tests/src/android/opengl` directory.
-
-## Other Tasks ##
-
-Besides adding new tests there are other ways to contribute to CTS:
-
-- Fix or remove tests annotated with BrokenTest and KnownFailure.
-
-## Submitting Your Changes ##
-
-Follow the [Android Contributors' Workflow](/source/submit-patches.html)
-to contribute changes to CTS. A reviewer
-will be assigned to your change, and your change should be reviewed shortly!
-
diff --git a/src/compatibility/cts-intro.jd b/src/compatibility/cts-intro.jd
new file mode 100644
index 0000000..3db4b36
--- /dev/null
+++ b/src/compatibility/cts-intro.jd
@@ -0,0 +1,154 @@
+page.title=Compatibility Test Suite
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<h2 id="how-does-the-cts-work">How does the CTS work?</h2>
+<div style="float: right">
+ <img src="/images/cts-0.png">
+</div>
+
+<p>The CTS is an automated testing harness that includes two major software components:</p>
+<ul>
+<li>
+<p>The CTS test harness runs on your desktop machine and manages test execution.</p>
+</li>
+<li>
+<p>Individual test cases are executed on attached mobile devices or on an
+emulator. The test cases are written in Java as JUnit tests and packaged as
+Android .apk files to run on the actual device target.</p>
+</li>
+</ul>
+<h2 id="workflow">Workflow</h2>
+<ol>
+<li>
+<p><a href="downloads.html">Download</a> the CTS and CTS media files.</p>
+</li>
+<li>
+<p>Attach at least one device (or emulator) to your machine.</p>
+</li>
+<li>
+<p>For CTS 2.1 R2 and beyond, setup your device (or emulator) to run the accessibility tests:</p>
+<ol>
+<li>
+<p>adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk</p>
+</li>
+<li>
+<p>On the device, enable Settings > Accessibility > Accessibility > Delegating Accessibility Service</p>
+</li>
+</ol>
+</li>
+<li>
+<p>For CTS 2.3 R4 and beyond, setup your device to run the device administration tests:</p>
+<ol>
+<li>
+<p>adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk</p>
+</li>
+<li>
+<p>On the device, enable all the android.deviceadmin.cts.* device administrators under Settings > Location & security > Select device administrators</p>
+</li>
+</ol>
+</li>
+<li>
+<p>For CTS 2.3 R12 and beyond, the CTS media files must be copied to the device's external storage. Check section 4.2 of the latest CTS manual for further details on copying these files:</p>
+<ol>
+<li>
+<p>Unzip the CTS Media zip file.</p>
+</li>
+<li>
+<p>Run copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]. If no resolution is specified, the default maximum resolution of 480x360 is assumed.</p>
+</li>
+</ol>
+</li>
+<li>
+<p>Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:</p>
+<ul>
+<li>
+<p>The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.</p>
+</li>
+<li>
+<p>The test harness removes the .apk file from each device.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.</p>
+</li>
+</ol>
+<p>When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.</p>
+<h2 id="types-of-test-cases">Types of test cases</h2>
+<p>The CTS includes the following types of test cases:</p>
+<ul>
+<li>
+<p><em>Unit tests</em> test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap.</p>
+</li>
+<li>
+<p><em>Functional tests</em> test a combination of APIs together in a higher-level use-case.</p>
+</li>
+<li>
+<p><em>Reference application tests</em> instrument a complete sample application to exercise a full set of APIs and Android runtime services</p>
+</li>
+</ul>
+<p>Future versions of the CTS will include the following types of test cases:</p>
+<ul>
+<li>
+<p><em>Robustness tests</em> test the durability of the system under stress.</p>
+</li>
+<li>
+<p><em>Performance tests</em> test the performance of the system against defined benchmarks, for example rendering frames per second.</p>
+</li>
+</ul>
+<h2 id="areas-covered">Areas Covered</h2>
+<p>The unit test cases cover the following areas to ensure compatibility:</p>
+<table>
+<thead>
+<tr>
+<th>Area</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Signature tests</td>
+<td>For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.</td>
+</tr>
+<tr>
+<td>Platform API Tests</td>
+<td>Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK <a href="https://developer.android.com/reference/classes.html">Class Index</a> to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.</td>
+</tr>
+<tr>
+<td>Dalvik VM Tests</td>
+<td>The tests focus on testing the Dalvik VM</td>
+</tr>
+<tr>
+<td>Platform Data Model</td>
+<td>The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK <a href="https://developer.android.com/reference/android/provider/package-summary.html">android.provider</a> package: contacts, browser, settings, etc.</td>
+</tr>
+<tr>
+<td>Platform Intents</td>
+<td>The CTS tests the core platform intents, as documented in the SDK <a href="https://developer.android.com/guide/appendix/g-app-intents.html">Available Intents</a>.</td>
+</tr>
+<tr>
+<td>Platform Permissions</td>
+<td>The CTS tests the core platform permissions, as documented in the SDK <a href="https://developer.android.com/reference/android/Manifest.permission.html">Available Permissions</a>.</td>
+</tr>
+<tr>
+<td>Platform Resources</td>
+<td>The CTS tests for correct handling of the core platform resource types, as documented in the SDK <a href="https://developer.android.com/guide/topics/resources/available-resources.html">Available Resource Types</a>. This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.</td>
+</tr>
+</tbody>
+</table>
diff --git a/src/compatibility/cts-intro.md b/src/compatibility/cts-intro.md
deleted file mode 100644
index 842a583..0000000
--- a/src/compatibility/cts-intro.md
+++ /dev/null
@@ -1,96 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Compatibility Test Suite #
-
-## How does the CTS work? ##
-
-<div style="float: right">
- <img src="/images/cts-0.png">
-</div>
-
-The CTS is an automated testing harness that includes two major software components:
-
-- The CTS test harness runs on your desktop machine and manages test execution.
-
-- Individual test cases are executed on attached mobile devices or on an
-emulator. The test cases are written in Java as JUnit tests and packaged as
-Android .apk files to run on the actual device target.
-
-## Workflow ##
-
-1. [Download](downloads.html) the CTS and CTS media files.
-
-1. Attach at least one device (or emulator) to your machine.
-
-1. For CTS 2.1 R2 and beyond, setup your device (or emulator) to run the accessibility tests:
-
- 2. adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk
-
- 2. On the device, enable Settings > Accessibility > Accessibility > Delegating Accessibility Service
-
-1. For CTS 2.3 R4 and beyond, setup your device to run the device administration tests:
-
- 2. adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk
-
- 2. On the device, enable all the android.deviceadmin.cts.* device administrators under Settings > Location & security > Select device administrators
-
-1. For CTS 2.3 R12 and beyond, the CTS media files must be copied to the device's external storage. Check section 4.2 of the latest CTS manual for further details on copying these files:
-
- 2. Unzip the CTS Media zip file.
-
- 2. Run copy_media.sh [720x480|1280x720|1920x1080|all] [-s serial]. If no resolution is specified, the default maximum resolution of 480x360 is assumed.
-
-1. Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:
-
- - The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.
-
- - The test harness removes the .apk file from each device.
-
-1. Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.
-
-When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.
-
-## Types of test cases ##
-
-The CTS includes the following types of test cases:
-
-- *Unit tests* test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap.
-
-- *Functional tests* test a combination of APIs together in a higher-level use-case.
-
-- *Reference application tests* instrument a complete sample application to exercise a full set of APIs and Android runtime services
-
-Future versions of the CTS will include the following types of test cases:
-
-- *Robustness tests* test the durability of the system under stress.
-
-- *Performance tests* test the performance of the system against defined benchmarks, for example rendering frames per second.
-
-## Areas Covered ##
-
-The unit test cases cover the following areas to ensure compatibility:
-
-Area | Description
------|-------------
-Signature tests | For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
-Platform API Tests | Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK [Class Index](https://developer.android.com/reference/classes.html) to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.
-Dalvik VM Tests | The tests focus on testing the Dalvik VM
-Platform Data Model | The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK [android.provider](https://developer.android.com/reference/android/provider/package-summary.html) package: contacts, browser, settings, etc.
-Platform Intents | The CTS tests the core platform intents, as documented in the SDK [Available Intents](https://developer.android.com/guide/appendix/g-app-intents.html).
-Platform Permissions | The CTS tests the core platform permissions, as documented in the SDK [Available Permissions](https://developer.android.com/reference/android/Manifest.permission.html).
-Platform Resources | The CTS tests for correct handling of the core platform resource types, as documented in the SDK [Available Resource Types](https://developer.android.com/guide/topics/resources/available-resources.html). This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.
-
diff --git a/src/compatibility/downloads.jd b/src/compatibility/downloads.jd
new file mode 100644
index 0000000..1e5c3e6
--- /dev/null
+++ b/src/compatibility/downloads.jd
@@ -0,0 +1,97 @@
+page.title=Android Compatibility Downloads
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<p>Thanks for your interest in Android Compatibility! The links below allow
+you to access the key documents and information.</p>
+<h2 id="android-42">Android 4.2</h2>
+<p>Android 4.2 is the release of the development milestone code-named
+Jelly Bean-MR1. Android 4.2 is the current version of Android. Source code for
+Android 4.2 is found in the 'android-4.2_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.2/android-4.2-cdd.pdf">Android 4.2 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.2_r1-linux_x86-arm.zip">Android 4.2 R1 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.2_r1-linux_x86-arm.zip">Android 4.2 R1 CTS Verifier</a></li>
+</ul>
+<h2 id="android-41">Android 4.1</h2>
+<p>Android 4.1.1 is the release of the development milestone code-named
+Jelly Bean. Android 4.1.1 is the current version of Android. Source code for
+Android 4.1.1 is found in the 'android-4.1.1_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.1/android-4.1-cdd.pdf">Android 4.1 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.1_r1-linux_x86-arm.zip">Android 4.1 R1 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.1_r2-linux_x86-arm.zip">Android 4.1 R2 CTS Verifier</a></li>
+</ul>
+<h2 id="android-403">Android 4.0.3</h2>
+<p>Android 4.0.3 is the release of the development milestone code-named
+Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
+Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open-source tree.</p>
+<ul>
+<li><a href="4.0/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-4.0.3_r3-linux_x86-arm.zip">Android 4.0.3 R3 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r2-linux_x86-arm.zip">Android 4.0.3 R2 CTS Verifier</a></li>
+</ul>
+<h2 id="android-23">Android 2.3</h2>
+<p>Android 2.3 is the release of the development milestone code-named
+Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in
+the open-source tree.</p>
+<ul>
+<li><a href="2.3/android-2.3.3-cdd.pdf">Android 2.3 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip">Android 2.3 R13 Compatibility Test Suite (CTS)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-verifier-2.3_r3-linux_x86-armv5.zip">Android 2.3 R3 CTS Verifier</a></li>
+</ul>
+<h2 id="android-22">Android 2.2</h2>
+<p>Android 2.2 is the release of the development milestone code-named
+FroYo. Source code for Android 2.2 is found in the 'froyo' branch in the
+open-source tree.</p>
+<ul>
+<li><a href="2.2/android-2.2-cdd.pdf">Android 2.2 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.2_r8-linux_x86-arm.zip">Android 2.2 R8 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="android-21">Android 2.1</h2>
+<p>Android 2.1 is the release of the development milestone code-named
+Eclair. Source code for Android 2.1 is found in the 'eclair' branch in the
+open-source tree. Note that for technical reasons, there is no compatibility
+program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.</p>
+<ul>
+<li><a href="2.1/android-2.1-cdd.pdf">Android 2.1 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-2.1_r5-x86.zip">Android 2.1 R5 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="android-16">Android 1.6</h2>
+<p>Android 1.6 was the release of the development milestone code-named Donut.
+Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found
+in the 'donut' branch in the open-source tree.</p>
+<ul>
+<li><a href="1.6/android-1.6-cdd.pdf">Android 1.6 Compatibility Definition Document (CDD)</a></li>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-1.6_r1-x86.zip">Android 1.6 R1 Compatibility Test Suite (CTS)</a></li>
+</ul>
+<h2 id="compatibility-test-suite-manual">Compatibility Test Suite Manual</h2>
+<p>The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and
+beyond require <a href="cts-intro.html">additional steps</a> to run the accessibility tests.</p>
+<ul>
+<li><a href="android-cts-manual-r6.pdf">Compatibility Test Suite (CTS) User Manual</a></li>
+</ul>
+<h2 id="cts-media-files">CTS Media Files</h2>
+<p>These media files are required for the CTS media stress tests.</p>
+<ul>
+<li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip">CTS Media 1.0</a></li>
+</ul>
+<h2 id="older-android-versions">Older Android Versions</h2>
+<p>There is no Compatibility Program for older versions of Android, such as Android
+1.5 (known in development as Cupcake). New devices intended to be Android
+compatible must ship with Android 1.6 or later.</p>
diff --git a/src/compatibility/downloads.md b/src/compatibility/downloads.md
deleted file mode 100644
index 8f2dcf7..0000000
--- a/src/compatibility/downloads.md
+++ /dev/null
@@ -1,97 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Compatibility Downloads #
-
-Thanks for your interest in Android Compatibility! The links below allow
-you to access the key documents and information.
-
-## Android 4.1 ##
-
-Android 4.1.1 is the release of the development milestone code-named
-Jelly Bean. Android 4.1.1 is the current version of Android. Source code for
-Android 4.1.1 is found in the 'android-4.1.1_r1' branch in the open-source tree.
-
-- [Android 4.1 Compatibility Definition Document (CDD)](4.1/android-4.1-cdd.pdf)
-- [Android 4.1 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.1_r1-linux_x86-arm.zip)
-- [Android 4.1 R2 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.1_r2-linux_x86-arm.zip)
-
-
-## Android 4.0.3 ##
-
-Android 4.0.3 is the release of the development milestone code-named
-Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
-Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open-source tree.
-
-- [Android 4.0 Compatibility Definition Document (CDD)](4.0/android-4.0-cdd.pdf)
-- [Android 4.0.3 R3 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-4.0.3_r3-linux_x86-arm.zip)
-- [Android 4.0.3 R2 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r2-linux_x86-arm.zip)
-
-## Android 2.3 ##
-
-Android 2.3 is the release of the development milestone code-named
-Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in
-the open-source tree.
-
-- [Android 2.3 Compatibility Definition Document (CDD)](2.3/android-2.3.3-cdd.pdf)
-- [Android 2.3 R13 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip)
-- [Android 2.3 R3 CTS Verifier](https://dl.google.com/dl/android/cts/android-cts-verifier-2.3_r3-linux_x86-armv5.zip)
-
-## Android 2.2 ##
-
-Android 2.2 is the release of the development milestone code-named
-FroYo. Source code for Android 2.2 is found in the 'froyo' branch in the
-open-source tree.
-
-- [Android 2.2 Compatibility Definition Document (CDD)](2.2/android-2.2-cdd.pdf)
-- [Android 2.2 R8 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.2_r8-linux_x86-arm.zip)
-
-## Android 2.1 ##
-
-Android 2.1 is the release of the development milestone code-named
-Eclair. Source code for Android 2.1 is found in the 'eclair' branch in the
-open-source tree. Note that for technical reasons, there is no compatibility
-program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.
-
-- [Android 2.1 Compatibility Definition Document (CDD)](2.1/android-2.1-cdd.pdf)
-- [Android 2.1 R5 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-2.1_r5-x86.zip)
-
-## Android 1.6 ##
-
-Android 1.6 was the release of the development milestone code-named Donut.
-Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found
-in the 'donut' branch in the open-source tree.
-
-- [Android 1.6 Compatibility Definition Document (CDD)](1.6/android-1.6-cdd.pdf)
-- [Android 1.6 R1 Compatibility Test Suite (CTS)](https://dl.google.com/dl/android/cts/android-cts-1.6_r1-x86.zip)
-
-## Compatibility Test Suite Manual ##
-
-The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and
-beyond require [additional steps](cts-intro.html) to run the accessibility tests.
-
-- [Compatibility Test Suite (CTS) User Manual](android-cts-manual-r5.pdf)
-
-## CTS Media Files ##
-These media files are required for the CTS media stress tests.
-
-- [CTS Media 1.0](https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip)
-
-## Older Android Versions ##
-
-There is no Compatibility Program for older versions of Android, such as Android
-1.5 (known in development as Cupcake). New devices intended to be Android
-compatible must ship with Android 1.6 or later.
diff --git a/src/compatibility/index.jd b/src/compatibility/index.jd
new file mode 100644
index 0000000..d081d3c
--- /dev/null
+++ b/src/compatibility/index.jd
@@ -0,0 +1,69 @@
+page.title=Android Compatibility
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<p>Android's purpose is to establish an open platform for developers to build innovative apps.
+The Android Compatibility program defines the technical details of Android platform and provides
+tools used by OEMs to ensure that developers' apps run on a variety of devices. The Android SDK
+provides built-in tools that developers use to clearly state the device features their apps
+require. And Google Play shows apps only to those devices that can properly run them.
+</p>
+
+<h2 id="why-build-compatible-android-devices">Why build compatible Android devices?</h2>
+<h3 id="users-want-a-customizable-device">Users want a customizable device.</h3>
+<p>A mobile phone is a highly personal, always-on, always-present gateway to
+the Internet. We haven't met a user yet who didn't want to customize it by
+extending its functionality. That's why Android was designed as a robust
+platform for running after-market applications.</p>
+<h3 id="developers-outnumber-us-all">Developers outnumber us all.</h3>
+<p>No device manufacturer can hope to write all the software that a person could
+conceivably need. We need third-party developers to write the apps users want,
+so the Android Open Source Project aims to make it as easy and open as
+possible for developers to build apps.</p>
+<h3 id="everyone-needs-a-common-ecosystem">Everyone needs a common ecosystem.</h3>
+<p>Every line of code developers write to work around a particular phone's bug
+is a line of code that didn't add a new feature. The more compatible phones
+there are, the more apps there will be. By building a fully compatible Android
+device, you benefit from the huge pool of apps written for Android, while
+increasing the incentive for developers to build more of those apps.</p>
+<h2 id="android-compatibility-is-free-and-its-easy">Android compatibility is free, and it's easy.</h2>
+<p>If you are building a mobile device, you can follow these steps to make
+sure your device is compatible with Android. For more details about the
+Android compatibility program in general, see <a href="overview.html">the program overview</a>.</p>
+<p>Building a compatible device is a three-step process:</p>
+<ol>
+<li>
+<p><em>Obtain the Android software source code</em>.
+ This is <a href="/source/index.html">the source code for the Android platform</a>, that you port to your hardware.</p>
+</li>
+<li>
+<p><em>Comply with Android Compatibility Definition Document (CDD)</em>.
+ The CDD enumerates the software and hardware requirements of a compatible Android device.</p>
+</li>
+<li>
+<p><em>Pass the Compatibility Test Suite (CTS)</em>.
+ You can use the CTS (included in the Android source code) as an ongoing aid to compatibility during the development process.</p>
+</li>
+</ol>
+
+<h2 id="joining-the-ecosystem">Joining the Ecosystem</h2>
+<p>Once you've built a compatible device, you may wish to include Google
+Play to provide your users access to the third-party app ecosystem.
+Unfortunately, for a variety of legal and business reasons, we aren't able to
+automatically license Google Play to all compatible devices. To inquire
+about access about Google Play, you can <a href="contact-us.html">contact us</a>.</p>
\ No newline at end of file
diff --git a/src/compatibility/index.md b/src/compatibility/index.md
deleted file mode 100644
index 3edc47d..0000000
--- a/src/compatibility/index.md
+++ /dev/null
@@ -1,80 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Compatibility #
-
-Android's purpose is to establish an open platform for developers to build
-innovative mobile apps. Three key components work together to realize this
-platform.
-
-The Android Compatibility Program defines the technical details of Android
-platform and provides tools used by OEMs to ensure that developers' apps run
-on a variety of devices. The Android SDK provides built-in tools that
-Developers use to clearly state the device features their apps require. And
-Google Play shows apps only to those devices that can properly run
-them.
-
-These pages describe the Android Compatibility Program and how to get
-access to compatibility information and tools.
-
-## Why build compatible Android devices? ##
-
-### Users want a customizable device. ###
-
-A mobile phone is a highly personal, always-on, always-present gateway to
-the Internet. We haven't met a user yet who didn't want to customize it by
-extending its functionality. That's why Android was designed as a robust
-platform for running after-market applications.
-
-### Developers outnumber us all. ###
-
-No device manufacturer can hope to write all the software that a person could
-conceivably need. We need third-party developers to write the apps users want,
-so the Android Open Source Project aims to make it as easy and open as
-possible for developers to build apps.
-
-### Everyone needs a common ecosystem. ###
-
-Every line of code developers write to work around a particular phone's bug
-is a line of code that didn't add a new feature. The more compatible phones
-there are, the more apps there will be. By building a fully compatible Android
-device, you benefit from the huge pool of apps written for Android, while
-increasing the incentive for developers to build more of those apps.
-
-## Android compatibility is free, and it's easy. ##
-
-If you are building a mobile device, you can follow these steps to make
-sure your device is compatible with Android. For more details about the
-Android compatibility program in general, see [the program overview](overview.html).
-
-Building a compatible device is a three-step process:
-
-1. *Obtain the Android software source code*.
- This is [the source code for the Android platform](/source/index.html), that you port to your hardware.
-
-1. *Comply with Android Compatibility Definition Document (CDD)*.
- The CDD enumerates the software and hardware requirements of a compatible Android device.
-
-1. *Pass the Compatibility Test Suite (CTS)*.
- You can use the CTS (included in the Android source code) as an ongoing aid to compatibility during the development process.
-
-# Joining the Ecosystem #
-
-Once you've built a compatible device, you may wish to include Google
-Play to provide your users access to the third-party app ecosystem.
-Unfortunately, for a variety of legal and business reasons, we aren't able to
-automatically license Google Play to all compatible devices. To inquire
-about access about Google Play, you can [contact us](contact-us.html).
diff --git a/src/compatibility/overview.jd b/src/compatibility/overview.jd
new file mode 100644
index 0000000..184903a
--- /dev/null
+++ b/src/compatibility/overview.jd
@@ -0,0 +1,120 @@
+page.title=Compatibility Program Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<p>The Android compatibility program makes it easy for mobile device
+manufacturers to develop compatible Android devices.</p>
+<h1 id="program-goals">Program goals</h1>
+<p>The Android compatibility program works for the benefit of the entire
+Android community, including users, developers, and device manufacturers.</p>
+<p>Each group depends on the others. Users want a wide selection of devices
+and great apps; great apps come from developers motivated by a large market
+for their apps with many devices in users' hands; device manufacturers rely
+on a wide variety of great apps to increase their products' value for
+consumers.</p>
+<p>Our goals were designed to benefit each of these groups:</p>
+<ul>
+<li>
+<p><em>Provide a consistent application and hardware environment to application
+developers.</em>
+ Without a strong compatibility standard, devices can vary so
+greatly that developers must design different versions of their applications
+for different devices. The compatibility program provides a precise definition
+of what developers can expect from a compatible device in terms of APIs and
+capabilities. Developers can use this information to make good design
+decisions, and be confident that their apps will run well on any compatible
+device.</p>
+</li>
+<li>
+<p><em>Enable a consistent application experience for consumers.</em>
+ If an application runs well on one compatible Android device, it should run well on
+any other device that is compatible with the same Android platform version.
+Android devices will differ in hardware and software capabilities, so the
+compatibility program also provides the tools needed for distribution systems
+such as Google Play to implement appropriate filtering. This means that
+users can only see applications which they can actually run.</p>
+</li>
+<li>
+<p><em>Enable device manufacturers to differentiate while being
+compatible.</em>
+ The Android compatibility program focuses on the aspects of
+Android relevant to running third-party applications, which allows device
+manufacturers the flexibility to create unique devices that are nonetheless
+compatible.</p>
+</li>
+<li>
+<p><em>Minimize costs and overhead associated with compatibility.</em>
+ Ensuring compatibility should be easy and inexpensive to
+device manufacturers. The testing tool (CTS) is free, open source, and
+available for <a href="downloads.html">download</a>.
+CTS is designed to be used for continuous self-testing
+during the device development process to eliminate the cost of changing your
+workflow or sending your device to a third party for testing. Meanwhile, there
+are no required certifications, and thus no corresponding costs and
+fees.</p>
+</li>
+</ul>
+<p>The Android compatibility program consists of three key components:</p>
+<ul>
+<li>The source code to the Android software stack</li>
+<li>The Compatilbility Definition Document, representing the "policy" aspect of compatibility</li>
+<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li>
+</ul>
+<p>Just as each version of the Android platform exists in a separate branch in
+the source code tree, there is a separate CTS and CDD for each version as
+well. The CDD, CTS, and source code are -- along with your hardware and your
+software customizations -- everything you need to create a compatible device.</p>
+<h1 id="compatibility-definition-document-cdd">Compatibility Definition Document (CDD)</h1>
+<p>For each release of the Android platform, a detailed Compatibility
+Definition Document (CDD) will be provided. The CDD represents the "policy"
+aspect of Android compatibility.</p>
+<p>No test suite, including CTS, can truly be comprehensive. For instance, the
+CTS includes a test that checks for the presence and correct behavior of
+OpenGL graphics APIs, but no software test can verify that the graphics
+actually appear correctly on the screen. More generally, it's impossible to
+test the presence of hardware features such as keyboards, display density,
+WiFi, and Bluetooth.</p>
+<p>The CDD's role is to codify and clarify specific requirements, and
+eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
+Android is a single corpus of open-source code, the code itself is the
+comprehensive "specification" of the platform and its APIs. The CDD acts as a
+"hub", referencing other content (such as SDK API documentation) that provides
+a framework in which the Android source code may be used so that the end
+result is a compatible system.</p>
+<p>If you want to build a device compatible with a given Android version,
+start by checking out the source code for that version, and then read the
+corresponding CDD and stay within its guidelines. For additional details,
+simply examine <a href="4.2/android-4.2-cdd.pdf">the latest CDD</a>.</p>
+<h1 id="compatibility-test-suite-cts">Compatibility Test Suite (CTS)</h1>
+<p>The CTS is a free, commercial-grade test suite, available for
+<a href="downloads.html">download</a>.
+The CTS represents the "mechanism" of compatibility.</p>
+<p>The CTS runs on a desktop machine and executes test cases directly on
+attached devices or an emulator. The CTS is a set of unit tests designed to be
+integrated into the daily workflow (such as via a continuous build system) of
+the engineers building a device. Its intent is to reveal incompatibilities
+early on, and ensure that the software remains compatible throughout the
+development process.</p>
+<h1 id="compatibility-test-suite-verifier-cts-verifier">Compatibility Test Suite Verifier (CTS Verifier)</h1>
+<p>The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
+Compatibility Test Suite (CTS), available for <a href="downloads.html">download</a>.
+CTS Verifier provides tests for APIs and functions that cannot be tested on a
+stationary device without manual input (e.g. audio quality, accelerometer, etc).</p>
+<p>For details on the CTS, consult the <a href="cts-intro.html">CTS introduction</a>.</p>
+
+
diff --git a/src/compatibility/overview.md b/src/compatibility/overview.md
deleted file mode 100644
index 627334c..0000000
--- a/src/compatibility/overview.md
+++ /dev/null
@@ -1,127 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Compatibility Program Overview #
-
-The Android compatibility program makes it easy for mobile device
-manufacturers to develop compatible Android devices.
-
-# Program goals #
-
-The Android compatibility program works for the benefit of the entire
-Android community, including users, developers, and device manufacturers.
-
-Each group depends on the others. Users want a wide selection of devices
-and great apps; great apps come from developers motivated by a large market
-for their apps with many devices in users' hands; device manufacturers rely
-on a wide variety of great apps to increase their products' value for
-consumers.
-
-Our goals were designed to benefit each of these groups:
-
-- *Provide a consistent application and hardware environment to application
-developers.*
- Without a strong compatibility standard, devices can vary so
-greatly that developers must design different versions of their applications
-for different devices. The compatibility program provides a precise definition
-of what developers can expect from a compatible device in terms of APIs and
-capabilities. Developers can use this information to make good design
-decisions, and be confident that their apps will run well on any compatible
-device.
-
-- *Enable a consistent application experience for consumers.*
- If an application runs well on one compatible Android device, it should run well on
-any other device that is compatible with the same Android platform version.
-Android devices will differ in hardware and software capabilities, so the
-compatibility program also provides the tools needed for distribution systems
-such as Google Play to implement appropriate filtering. This means that
-users can only see applications which they can actually run.
-
-- *Enable device manufacturers to differentiate while being
-compatible.*
- The Android compatibility program focuses on the aspects of
-Android relevant to running third-party applications, which allows device
-manufacturers the flexibility to create unique devices that are nonetheless
-compatible.
-
-- *Minimize costs and overhead associated with compatibility.*
- Ensuring compatibility should be easy and inexpensive to
-device manufacturers. The testing tool (CTS) is free, open source, and
-available for [download](downloads.html).
-CTS is designed to be used for continuous self-testing
-during the device development process to eliminate the cost of changing your
-workflow or sending your device to a third party for testing. Meanwhile, there
-are no required certifications, and thus no corresponding costs and
-fees.
-
-The Android compatibility program consists of three key components:
-
-- The source code to the Android software stack
-- The Compatilbility Definition Document, representing the "policy" aspect of compatibility
-- The Compatilbility Test Suite, representing the "mechanism" of compatibility
-
-Just as each version of the Android platform exists in a separate branch in
-the source code tree, there is a separate CTS and CDD for each version as
-well. The CDD, CTS, and source code are -- along with your hardware and your
-software customizations -- everything you need to create a compatible device.
-
-# Compatibility Definition Document (CDD) #
-
-For each release of the Android platform, a detailed Compatibility
-Definition Document (CDD) will be provided. The CDD represents the "policy"
-aspect of Android compatibility.
-
-No test suite, including CTS, can truly be comprehensive. For instance, the
-CTS includes a test that checks for the presence and correct behavior of
-OpenGL graphics APIs, but no software test can verify that the graphics
-actually appear correctly on the screen. More generally, it's impossible to
-test the presence of hardware features such as keyboards, display density,
-WiFi, and Bluetooth.
-
-The CDD's role is to codify and clarify specific requirements, and
-eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
-Android is a single corpus of open-source code, the code itself is the
-comprehensive "specification" of the platform and its APIs. The CDD acts as a
-"hub", referencing other content (such as SDK API documentation) that provides
-a framework in which the Android source code may be used so that the end
-result is a compatible system.
-
-If you want to build a device compatible with a given Android version,
-start by checking out the source code for that version, and then read the
-corresponding CDD and stay within its guidelines. For additional details,
-simply examine [the latest CDD](4.1/android-4.1-cdd.pdf).
-
-# Compatibility Test Suite (CTS) #
-
-The CTS is a free, commercial-grade test suite, available for
-[download](downloads.html).
-The CTS represents the "mechanism" of compatibility.
-
-The CTS runs on a desktop machine and executes test cases directly on
-attached devices or an emulator. The CTS is a set of unit tests designed to be
-integrated into the daily workflow (such as via a continuous build system) of
-the engineers building a device. Its intent is to reveal incompatibilities
-early on, and ensure that the software remains compatible throughout the
-development process.
-
-
-# Compatibility Test Suite Verifier (CTS Verifier) #
-The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the
-Compatibility Test Suite (CTS), available for [download](downloads.html).
-CTS Verifier provides tests for APIs and functions that cannot be tested on a
-stationary device without manual input (e.g. audio quality, accelerometer, etc).
-
-For details on the CTS, consult the [CTS introduction](cts-intro.html).
diff --git a/src/compatibility/sidebar.md b/src/compatibility/sidebar.md
deleted file mode 100644
index 9df9f50..0000000
--- a/src/compatibility/sidebar.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Getting Started #
-- [Compatibility Overview](/compatibility/overview.html)
-- [Current CDD](/compatibility/4.1/android-4.1-cdd.pdf)
-- [CTS Introduction](/compatibility/cts-intro.html)
-- [CTS Development](/compatibility/cts-development.html)
-
-# More Information #
-- [Downloads](/compatibility/downloads.html)
-- [FAQs](/faqs.html#compatibility)
-- [Contact Us](/compatibility/contact-us.html)
-
-
diff --git a/src/devices/audio.jd b/src/devices/audio.jd
new file mode 100644
index 0000000..a160782
--- /dev/null
+++ b/src/devices/audio.jd
@@ -0,0 +1,346 @@
+page.title=Audio
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ Android's audio HAL connects the higher level, audio-specific
+ framework APIs in <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a>
+ to the underlying audio driver and hardware.
+</p>
+
+<p>
+ The following figure and list describe how audio functionality is implemented and the relevant
+ source code that is involved in the implementation:
+</p>
+<p>
+ <img src="images/audio_hal.png">
+</p>
+<dl>
+ <dt>
+ Application framework
+ </dt>
+ <dd>
+ At the application framework level is the app code, which utilizes the
+ <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a>
+ APIs to interact with the audio hardware. Internally, this code calls corresponding JNI glue
+ classes to access the native code that interacts with the auido hardware.
+ </dd>
+ <dt>
+ JNI
+ </dt>
+ <dd>
+ The JNI code associated with <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a> is located in the
+ <code>frameworks/base/core/jni/</code> and <code>frameworks/base/media/jni</code> directories.
+ This code calls the lower level native code to obtain access to the audio hardware.
+ </dd>
+ <dt>
+ Native framework
+ </dt>
+ <dd>
+ The native framework is defined in <code>frameworks/av/media/libmedia</code> and provides a
+ native equivalent to the <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a> package. The native framework calls the Binder
+ IPC proxies to obtain access to audio-specific services of the media server.
+ </dd>
+ <dt>
+ Binder IPC
+ </dt>
+ <dd>
+ The Binder IPC proxies facilitate communication over process boundaries. They are located in
+ the <code>frameworks/av/media/libmedia</code> directory and begin with the letter "I".
+ </dd>
+ <dt>
+ Media Server
+ </dt>
+ <dd>
+ The audio services in the media server, located in
+ <code>frameworks/av/services/audioflinger</code>, is the actual code that interacts with your
+ HAL implementations.
+ </dd>
+ <dt>
+ HAL
+ </dt>
+ <dd>
+ The hardware abstraction layer defines the standard interface that audio services calls into
+ and that you must implement to have your audio hardware function correctly. The audio HAL
+ interfaces are located in <code>hardware/libhardware/include/hardware</code>.
+ </dd>
+ <dt>
+ Kernel Driver
+ </dt>
+ <dd>
+ The audio driver interacts with the hardware and your implementation of the HAL. You can choose
+ to use ALSA, OSS, or a custom driver of your own at this level. The HAL is driver-agnostic.
+ <p>
+ <strong>Note:</strong> If you do choose ALSA, we recommend using <code>external/tinyalsa</code>
+ for the user portion of the driver because of its compatible licensing (The standard user-mode
+ library is GPL licensed).
+</p>
+ </dd>
+</dl>
+<h2 id="implementing">
+ Implementing the HAL
+</h2>
+<p>
+ The audio HAL is composed of three different interfaces that you must implement:
+</p>
+<ul>
+ <li>
+ <code>hardware/libhardware/include/hardware/audio.h</code> - represents the main functions of
+ an audio device.
+ </li>
+ <li>
+ <code>hardware/libhardware/include/hardware/audio_policy.h</code> - represents the audio policy
+ manager, which handles things like audio routing and volume control policies.
+ </li>
+ <li>
+ <code>hardware/libhardware/include/hardware/audio_effect.h</code> - represents effects that can
+ be applied to audio such as downmixing, echo, or noise supression.
+ </li>
+</ul>
+<p>See the implementation for the Galaxy Nexus at <code>device/samsung/tuna/audio</code> for an example.</p>
+
+<p>In addition to implementing the HAL, you need to create a
+ <code>device/<company_name>/<device_name>/audio/audio_policy.conf</code> file
+ that declares the audio devices present on your product. For an example, see the file for
+ the Galaxy Nexus audio hardware in <code>device/samsung/tuna/audio/audio_policy.conf</code>.
+Also, see
+ the <code>system/core/include/system/audio.h</code> and <code>system/core/include/system/audio_policy.h</code>
+ header files for a reference of the properties that you can define.
+</p>
+<h3 id="multichannel">Multi-channel support</h3>
+<p>If your hardware and driver supports multi-channel audio via HDMI, you can output the audio stream
+ directly to the audio hardware. This bypasses the AudioFlinger mixer so it doesn't get downmixed to two channels.
+
+ <p>
+ The audio HAL must expose whether an output stream profile supports multi-channel audio capabilities.
+ If the HAL exposes its capabilities, the default policy manager allows multichannel playback over
+ HDMI.</p>
+ <p>For more implementation details, see the <code>device/samsung/tuna/audio/audio_hw.c</code> in the Jellybean release.</p>
+
+ <p>
+ To specify that your product contains a multichannel audio output, edit the <code>audio_policy.conf</code> file to describe the multichannel
+ output for your product. The following is an example from the Galaxy Nexus that shows a "dynamic" channel mask, which means the audio policy manager
+ queries the actual channel masks supported by the HDMI sink after connection. You can also specify a static channel mask like <code>AUDIO_CHANNEL_OUT_5POINT1</code>
+ </p>
+<pre>
+audio_hw_modules {
+ primary {
+ outputs {
+ ...
+ hdmi {
+ sampling_rates 44100|48000
+ channel_masks dynamic
+ formats AUDIO_FORMAT_PCM_16_BIT
+ devices AUDIO_DEVICE_OUT_AUX_DIGITAL
+ flags AUDIO_OUTPUT_FLAG_DIRECT
+ }
+ ...
+ }
+ ...
+ }
+ ...
+}
+</pre>
+
+
+ <p>If your product does not support multichannel audio, AudioFlinger's mixer downmixes the content to stereo
+ automatically when sent to an audio device that does not support multichannel audio.</p>
+</p>
+
+<h3 id="codecs">Media Codecs</h3>
+
+<p>Ensure that the audio codecs that your hardware and drivers support are properly declared for your product. See
+ <a href="{@docRoot}guide/media.html#expose"> Exposing Codecs to the Framework</a> for information on how to do this.
+</p>
+
+<h2 id="configuring">
+ Configuring the Shared Library
+</h2>
+<p>
+ You need to package the HAL implementation into a shared library and copy it to the
+ appropriate location by creating an <code>Android.mk</code> file:
+</p>
+<ol>
+ <li>Create a <code>device/<company_name>/<device_name>/audio</code> directory
+ to contain your library's source files.
+ </li>
+ <li>Create an <code>Android.mk</code> file to build the shared library. Ensure that the
+ Makefile contains the following line:
+<pre>
+LOCAL_MODULE := audio.primary.<device_name>
+</pre>
+ <p>
+ Notice that your library must be named <code>audio_primary.<device_name>.so</code> so
+ that Android can correctly load the library. The "<code>primary</code>" portion of this
+ filename indicates that this shared library is for the primary audio hardware located on the
+ device. The module names <code>audio.a2dp.<device_name></code> and
+ <code>audio.usb.<device_name></code> are also available for bluetooth and USB audio
+ interfaces. Here is an example of an <code>Android.mk</code> from the Galaxy
+ Nexus audio hardware:
+ </p>
+ <pre>
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := audio.primary.tuna
+LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw
+LOCAL_SRC_FILES := audio_hw.c ril_interface.c
+LOCAL_C_INCLUDES += \
+ external/tinyalsa/include \
+ $(call include-path-for, audio-utils) \
+ $(call include-path-for, audio-effects)
+LOCAL_SHARED_LIBRARIES := liblog libcutils libtinyalsa libaudioutils libdl
+LOCAL_MODULE_TAGS := optional
+
+include $(BUILD_SHARED_LIBRARY)
+</pre>
+ </li>
+ <li>If your product supports low latency audio as specified by the Android CDD, copy the
+ corresponding XML feature file into your product. For example, in your product's
+ <code>device/<company_name>/<device_name>/device.mk</code>
+ Makefile:
+ <pre>
+PRODUCT_COPY_FILES := ...
+
+PRODUCT_COPY_FILES += \
+frameworks/native/data/etc/android.android.hardware.audio.low_latency.xml:system/etc/permissions/android.hardware.audio.low_latency.xml \
+</pre>
+ </li>
+
+ <li>Copy the <code>audio_policy.conf</code> file that you created earlier to the <code>system/etc/</code> directory
+ in your product's <code>device/<company_name>/<device_name>/device.mk</code>
+ Makefile. For example:
+ <pre>
+PRODUCT_COPY_FILES += \
+ device/samsung/tuna/audio/audio_policy.conf:system/etc/audio_policy.conf
+</pre>
+ </li>
+ <li>Declare the shared modules of your audio HAL that are required by your product in the product's
+ <code>device/<company_name>/<device_name>/device.mk</code> Makefile. For example, the
+ Galaxy Nexus requires the primary and bluetooth audio HAL modules:
+<pre>
+PRODUCT_PACKAGES += \
+ audio.primary.tuna \
+ audio.a2dp.default
+</pre>
+ </li>
+</ol>
+
+<h2>Audio preprocessing effects</h2>
+<p>You can expose audio preprocessing effects to application developers through your
+audio HAL so they can take advantage of platform features. Preprocessing effects
+are always paired with the use case mode in which the preprocessing is requested. In Android
+app development, a use case is referred to as an <code>AudioSource</code>, and app developers
+request to use the <code>AudioSource</code> abstraction instead of the actual audio hardware device to use.
+The following list shows the different
+<code>AudioSource</code> options available that an app developer can choose.
+</p>
+<ul>
+<code><li>android.media.MediaRecorder.AudioSource.CAMCORDER</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.VOICE_COMMUNICATION</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.VOICE_CALL</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.VOICE_DOWNLINK</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.VOICE_UPLINK</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.MIC</li></code>
+<code><li>android.media.MediaRecorder.AudioSource.DEFAULT</li></code>
+</ul>
+
+<p>The default preprocessing effects to be applied for each of the <code>AudioSource</code> is
+specified in the <code>/system/etc/audio_effects.conf</code> file. To specify
+your own effects, create a <code>/system/vendor/etc/audio_effects.conf</code> file
+and specify any preprocessing effects that you need to turn on for every <code>AudioSource</code> type.
+
+<p class="note"><strong>Note:</strong> Voice recognition does not have any preprocessing
+effects by default</p>
+
+The following example for Nexus 10 enables preprocessing for the VOIP <code>AudioSource</code> and Camcorder <code>AudioSource</code>.
+</p>
+
+<pre>
+effects {
+ agc {
+ library audience_pre_processing
+ uuid e9e87eb0-0b55-11e2-892e-0800200c9a66
+ }
+ ...
+}
+
+pre_processing {
+ voice_communication {
+ aec {}
+ ns {}
+ }
+ camcorder {
+ agc {}
+ }
+}
+</pre>
+
+<h3>Source tuning</h3>
+<p>For source tuning, there are no explicit requirements on audio gain or audio processing
+with the exception of voice recognition (<code>VOICE_RECOGNITION</code>).</p>
+
+<p>The Android Audio Policy Manager maps sources to devices with <code>AudioPolicyManagerBase::getDeviceForInputSource(int
+inputSource)</code>. In Android 4.2, the following sources are exposed to developers:
+</p>
+
+<pre>
+android.media.AcousticEchoCanceller
+android.media.AutomaticGainControl
+android.media.NoiseSuppressor
+</pre>
+
+<p>
+The audio preprocessing effects are developer facing APIs for platform effects that you
+can tune on a use case basis. For example, you can tune noise suppressor and wind noise suppressor for <code>CAMCORDER</code>
+or stationary noise suppressor for <code>VOICE_COMMUNICATION</code>.
+Similarly, you can tune Automatic Gain Control (<code>agc</code>) for close-talk for
+<code>VOICE_COMMUNICATION</code> and main phone mic for far-talk for <code>CAMCORDER</code>.
+</p>
+
+<h3>Voice recognition configuration and requirements</h3>
+<p>The following are the requirements for voice recognition:</p>
+
+<ul>
+<li>"flat" frequency response (+/- 3dB) from 100Hz to 4kHz</li>
+<li>close-talk config: 90dB SPL reads RMS of 2500 (16bit samples)</li>
+<li>level tracks linearly from -18dB to +12dB relative to 90dB SPL</li>
+<li>THD < 1% (90dB SPL in 100 to 4000Hz range)</li>
+<li>8kHz sampling rate (anti-aliasing)</li>
+<li>Effects / pre-processing must be disabled by default</li>
+</ul>
+
+<h3>Implementing audio preprocessing effects</h3>
+
+<h3>More information</h3>
+<p>For more information, see:</p>
+<ul>
+<li>Android Open Source Project documentation for
+<a href="http://developer.android.com/reference/android/media/audiofx/packagesummary.html">audio effects</a>.</li>
+<li>Android Open Source project documentation for <a href="http://developer.android.com/reference/android/media/audiofx/NoiseSuppressor.
+html">Noise Suppression audio effect</a></li>
+</ul>
diff --git a/src/devices/audio_latency.jd b/src/devices/audio_latency.jd
new file mode 100644
index 0000000..476842b
--- /dev/null
+++ b/src/devices/audio_latency.jd
@@ -0,0 +1,307 @@
+page.title=Audio Latency
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Audio latency is the time delay as an audio signal passes through a system.
+ For a complete description of audio latency for the purposes of Android
+ compatibility, see <em>Section 5.4 Audio Latency</em>
+ in the <a href="http://source.android.com/compatibility/index.html">Android CDD</a>.
+</p>
+
+<h2 id="contributors">Contributors to Latency</h2>
+
+<p>
+ This section focuses on the contributors to output latency,
+ but a similar discussion applies to input latency.
+</p>
+<p>
+ Assuming that the analog circuitry does not contribute significantly.
+ Then the major surface-level contributors to audio latency are the following:
+</p>
+
+<ul>
+ <li>Application</li>
+ <li>Total number of buffers in pipeline</li>
+ <li>Size of each buffer, in frames</li>
+ <li>Additional latency after the app processor, such as from a DSP</li>
+</ul>
+
+<p>
+ As accurate as the above list of contributors may be, it is also misleading.
+ The reason is that buffer count and buffer size are more of an
+ <em>effect</em> than a <em>cause</em>. What usually happens is that
+ a given buffer scheme is implemented and tested, but during testing, an audio
+ underrun is heard as a "click" or "pop". To compensate, the
+ system designer then increases buffer sizes or buffer counts.
+ This has the desired result of eliminating the underruns, but it also
+ has the undesired side effect of increasing latency.
+</p>
+
+<p>
+ A better approach is to understand the underlying causes of the
+ underruns and then correct those. This eliminates the
+ audible artifacts and may even permit even smaller or fewer buffers
+ and thus reduce latency.
+</p>
+
+<p>
+ In our experience, the most common causes of underruns include:
+</p>
+<ul>
+ <li>Linux CFS (Completely Fair Scheduler)</li>
+ <li>high-priority threads with SCHED_FIFO scheduling</li>
+ <li>long scheduling latency</li>
+ <li>long-running interrupt handlers</li>
+ <li>long interrupt disable time</li>
+</ul>
+
+<h3>Linux CFS and SCHED_FIFO scheduling</h3>
+<p>
+ The Linux CFS is designed to be fair to competing workloads sharing a common CPU
+ resource. This fairness is represented by a per-thread <em>nice</em> parameter.
+ The nice value ranges from -19 (least nice, or most CPU time allocated)
+ to 20 (nicest, or least CPU time allocated). In general, all threads with a given
+ nice value receive approximately equal CPU time and threads with a
+ numerically lower nice value should expect to
+ receive more CPU time. However, CFS is "fair" only over relatively long
+ periods of observation. Over short-term observation windows,
+ CFS may allocate the CPU resource in unexpected ways. For example, it
+ may take the CPU away from a thread with numerically low niceness
+ onto a thread with a numerically high niceness. In the case of audio,
+ this can result in an underrun.
+</p>
+
+<p>
+ The obvious solution is to avoid CFS for high-performance audio
+ threads. Beginning with Android 4.1 (Jelly Bean), such threads now use the
+ <code>SCHED_FIFO</code> scheduling policy rather than the <code>SCHED_NORMAL</code> (also called
+ <code>SCHED_OTHER</code>) scheduling policy implemented by CFS.
+</p>
+
+<p>
+ Though the high-performance audio threads now use <code>SCHED_FIFO</code>, they
+ are still susceptible to other higher priority <code>SCHED_FIFO</code> threads.
+ These are typically kernel worker threads, but there may also be a few
+ non-audio user threads with policy <code>SCHED_FIFO</code>. The available <code>SCHED_FIFO</code>
+ priorities range from 1 to 99. The audio threads run at priority
+ 2 or 3. This leaves priority 1 available for lower priority threads,
+ and priorities 4 to 99 for higher priority threads. We recommend that
+ you use priority 1 whenever possible, and reserve priorities 4 to 99 for
+ those threads that are guaranteed to complete within a bounded amount
+ of time, and are known to not interfere with scheduling of audio threads.
+</p>
+
+<h3>Scheduling latency</h3>
+<p>
+ Scheduling latency is the time between when a thread becomes
+ ready to run, and when the resulting context switch completes so that the
+ thread actually runs on a CPU. The shorter the latency the better and
+ anything over two milliseconds causes problems for audio. Long scheduling
+ latency is most likely to occur during mode transitions, such as
+ bringing up or shutting down a CPU, switching between a security kernel
+ and the normal kernel, switching from full power to low-power mode,
+ or adjusting the CPU clock frequency and voltage.
+</p>
+
+<h3>Interrupts</h3>
+<p>
+ In many designs, CPU 0 services all external interrupts. So a
+ long-running interrupt handler may delay other interrupts, in particular
+ audio DMA completion interrupts. Design interrupt handlers
+ to finish quickly and defer any lengthy work to a thread (preferably
+ a CFS thread or <code>SCHED_FIFO</code> thread of priority 1).
+</p>
+
+<p>
+ Equivalently, disabling interrupts on CPU 0 for a long period
+ has the same result of delaying the servicing of audio interrupts.
+ Long interrupt disable times typically happen while waiting for a kernel
+ <i>spin lock</i>. Review these spin locks to ensure that
+ they are bounded.
+</p>
+
+
+
+<h2 id="measuringOutput">Measuring Output Latency</h2>
+
+<p>
+ There are several techniques available to measure output latency,
+ with varying degrees of accuracy and ease of running.
+</p>
+
+<h3>LED and oscilloscope test</h3>
+<p>
+This test measures latency in relation to the device's LED indicator.
+If your production device does not have an LED, you can install the
+ LED on a prototype form factor device. For even better accuracy
+ on prototype devices with exposed circuity, connect one
+ oscilloscope probe to the LED directly to bypass the light
+ sensor latency.
+ </p>
+
+<p>
+ If you cannot install an LED on either your production or prototype device,
+ try the following workarounds:
+</p>
+
+<ul>
+ <li>Use a General Purpose Input/Output (GPIO) pin for the same purpose</li>
+ <li>Use JTAG or another debugging port</li>
+ <li>Use the screen backlight. This might be risky as the
+ backlight may have a non-neglible latency, and can contribute to
+ an inaccurate latency reading.
+ </li>
+</ul>
+
+<p>To conduct this test:</p>
+
+<ol>
+ <li>Run an app that periodically pulses the LED at
+ the same time it outputs audio.
+
+ <p class="note"><b>Note:</b> To get useful results, it is crucial to use the correct
+ APIs in the test app so that you're exercising the fast audio output path.
+ See the separate document "Application developer guidelines for reduced
+ audio latency". <!-- where is this ?-->
+ </p>
+ </li>
+ <li>Place a light sensor next to the LED.</li>
+ <li>Connect the probes of a dual-channel oscilloscope to both the wired headphone
+ jack (line output) and light sensor.</li>
+ <li>Use the oscilloscope to measure
+ the time difference between observing the line output signal versus the light
+ sensor signal.</li>
+</ol>
+
+ <p>The difference in time is the approximate audio output latency,
+ assuming that the LED latency and light sensor latency are both zero.
+ Typically, the LED and light sensor each have a relatively low latency
+ on the order of 1 millisecond or less, which is sufficiently low enough
+ to ignore.</p>
+
+<h3>Larsen test</h3>
+<p>
+ One of the easiest latency tests is an audio feedback
+ (Larsen effect) test. This provides a crude measure of combined output
+ and input latency by timing an impulse response loop. This test is not very useful
+ by itself because of the nature of the test, but</p>
+
+<p>To conduct this test:</p>
+<ol>
+ <li>Run an app that captures audio from the microphone and immediately plays the
+ captured data back over the speaker.</li>
+ <li>Create a sound externally,
+ such as tapping a pencil by the microphone. This noise generates a feedback loop.</li>
+ <li>Measure the time between feedback pulses to get the sum of the output latency, input latency, and application overhead.</li>
+</ol>
+
+ <p>This method does not break down the
+ component times, which is important when the output latency
+ and input latency are independent, so this method is not recommended for measuring output latency, but might be useful
+ to help measure output latency.</p>
+
+<h2 id="measuringInput">Measuring Input Latency</h2>
+
+<p>
+ Input latency is more difficult to measure than output latency. The following
+ tests might help.
+</p>
+
+<p>
+One approach is to first determine the output latency
+ using the LED and oscilloscope method and then use
+ the audio feedback (Larsen) test to determine the sum of output
+ latency and input latency. The difference between these two
+ measurements is the input latency.
+</p>
+
+<p>
+ Another technique is to use a GPIO pin on a prototype device.
+ Externally, pulse a GPIO input at the same time that you present
+ an audio signal to the device. Run an app that compares the
+ difference in arrival times of the GPIO signal and audio data.
+</p>
+
+<h2 id="reducing">Reducing Latency</h2>
+
+<p>To achieve low audio latency, pay special attention throughout the
+system to scheduling, interrupt handling, power management, and device
+driver design. Your goal is to prevent any part of the platform from
+blocking a <code>SCHED_FIFO</code> audio thread for more than a couple
+of milliseconds. By adopting such a systematic approach, you can reduce
+audio latency and get the side benefit of more predictable performance
+overall.
+</p>
+
+
+ <p>
+ Audio underruns, when they do occur, are often detectable only under certain
+ conditions or only at the transitions. Try stressing the system by launching
+ new apps and scrolling quickly through various displays. But be aware
+ that some test conditions are so stressful as to be beyond the design
+ goals. For example, taking a bugreport puts such enormous load on the
+ system that it may be acceptable to have an underrun in that case.
+</p>
+
+<p>
+ When testing for underruns:
+</p>
+ <ul>
+ <li>Configure any DSP after the app processor so that it adds
+ minimal latency</li>
+ <li>Run tests under different conditions
+ such as having the screen on or off, USB plugged in or unplugged,
+ WiFi on or off, Bluetooth on or off, and telephony and data radios
+ on or off.</li>
+ <li>Select relatively quiet music that you're very familiar with, and which is easy
+ to hear underruns in.</li>
+ <li>Use wired headphones for extra sensitivity.</li>
+ <li>Give yourself breaks so that you don't experience "ear fatigue".</li>
+ </ul>
+
+<p>
+ Once you find the underlying causes of underruns, reduce
+ the buffer counts and sizes to take advantage of this.
+ The eager approach of reducing buffer counts and sizes <i>before</i>
+ analyzing underruns and fixing the causes of underruns only
+ results in frustration.
+</p>
+
+<h3 id="tools">Tools</h3>
+<p>
+ <code>systrace</code> is an excellent general-purpose tool
+ for diagnosing system-level performance glitches.
+</p>
+
+<p>
+ The output of <code>dumpsys media.audio_flinger</code> also contains a
+ useful section called "simple moving statistics". This has a summary
+ of the variability of elapsed times for each audio mix and I/O cycle.
+ Ideally, all the time measurements should be about equal to the mean or
+ nominal cycle time. If you see a very low minimum or high maximum, this is an
+ indication of a problem, which is probably a high scheduling latency or interrupt
+ disable time. The <i>tail</i> part of the output is especially helpful,
+ as it highlights the variability beyond +/- 3 standard deviations.
+</p>
\ No newline at end of file
diff --git a/src/devices/audio_preprocessing.jd b/src/devices/audio_preprocessing.jd
new file mode 100644
index 0000000..4beb7e0
--- /dev/null
+++ b/src/devices/audio_preprocessing.jd
@@ -0,0 +1,111 @@
+page.title=Audio Warmup
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Audio warmup is the time for the audio amplifier circuit in your device to
+be fully powered and reach its normal operation state. The major contributors
+to audio warmup time are power management and any "de-pop" logic to stabilize
+the circuit.
+</p>
+
+<p>This document describes how to measure audio warmup time and possible ways to decrease
+warmup time.</p>
+
+<h2 id="measuringOutput">Measuring Output Warmup</h2>
+
+<p>
+ AudioFlinger's FastMixer thread automatically measures output warmup
+ and reports it as part of the output of the <code>dumpsys media.audio_flinger</code> command.
+ At warmup, FastMixer calls <code>write()</code>
+ repeatedly until the time between two <code>write()</code>s is the amount expected.
+ FastMixer determines audio warmup by seeing how long a HAL <code>write()</code> takes to stabilize.
+</p>
+
+<p>To measure audio warmup, do the following
+steps for the built-in speaker and wired headphones and at different times after booting.
+Warmup times are usually different for each output device and right after booting the device:</p>
+
+<ol>
+ <li>Ensure that FastMixer is enabled.</li>
+ <li>Enable touch sounds by selecting <b>Settings > Sound > Touch sounds</b> on the device.</li>
+ <li>Ensure that audio has been off for at least three seconds. Five seconds or more is better, because
+ the hardware itself might have its own power logic beyond the three seconds that AudioFlinger has.</li>
+ <li>Press Home, and you should hear a click sound.</li>
+ <li>Run the following command to receive the measured warmup:
+ <pre>adb shell dumpsys media.audio_flinger | grep measuredWarmup</code></pre>
+
+<p>
+You should see output like this:
+</p>
+
+<pre>
+sampleRate=44100 frameCount=256 measuredWarmup=X ms, warmupCycles=X
+</pre>
+
+<p>
+ The <code>measuredWarmup=X</code> is X number of milliseconds
+ it took for the first set of HAL <code>write()</code>s to complete.
+</p>
+
+<p>
+ The <code>warmupCycles=X</code> is how many HAL write requests it took
+ until the execution time of <code>write()</code> matches what is expected.
+</p>
+</li>
+<li>
+ Take five measurements and report them all, as well as the mean.
+ If they are not all approximately the same,
+ then it’s likely that a measurement is incorrect.
+ For example, if you don’t wait long enough after the audio has been off,
+ you will see a lower warmup time than the mean value.
+</li>
+</ol>
+
+
+<h2 id="measuringInput">Measuring Input Warmup</h2>
+
+<p>
+ There are currently no tools provided for measuring audio input warmup.
+ However, input warmup time can be estimated by observing
+ the time required for <a href="http://developer.android.com/reference/android/media/AudioRecord.html#startRecording()">startRecording()</a>
+ to return.
+</p>
+
+
+<h2 id="reducing">Reducing Warmup Time</h2>
+
+<p>
+ Warmup time can usually be reduced by a combination of:
+ <ul>
+ <li>Good circuit design</li>
+ <li>Accurate time delays in kernel device driver</li>
+ <li>Performing independent warmup operations concurrently rather than sequentially</li>
+ <li>Leaving circuits powered on or not reconfiguring clocks (increases idle power consumption).
+ <li>Caching computed parameters</li>
+ </ul>
+ However, beware of excessive optimization. You may find that you
+ need to tradeoff between low warmup time versus
+ lack of popping at power transitions.
+</p>
diff --git a/src/devices/audio_warmup.jd b/src/devices/audio_warmup.jd
new file mode 100644
index 0000000..4beb7e0
--- /dev/null
+++ b/src/devices/audio_warmup.jd
@@ -0,0 +1,111 @@
+page.title=Audio Warmup
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Audio warmup is the time for the audio amplifier circuit in your device to
+be fully powered and reach its normal operation state. The major contributors
+to audio warmup time are power management and any "de-pop" logic to stabilize
+the circuit.
+</p>
+
+<p>This document describes how to measure audio warmup time and possible ways to decrease
+warmup time.</p>
+
+<h2 id="measuringOutput">Measuring Output Warmup</h2>
+
+<p>
+ AudioFlinger's FastMixer thread automatically measures output warmup
+ and reports it as part of the output of the <code>dumpsys media.audio_flinger</code> command.
+ At warmup, FastMixer calls <code>write()</code>
+ repeatedly until the time between two <code>write()</code>s is the amount expected.
+ FastMixer determines audio warmup by seeing how long a HAL <code>write()</code> takes to stabilize.
+</p>
+
+<p>To measure audio warmup, do the following
+steps for the built-in speaker and wired headphones and at different times after booting.
+Warmup times are usually different for each output device and right after booting the device:</p>
+
+<ol>
+ <li>Ensure that FastMixer is enabled.</li>
+ <li>Enable touch sounds by selecting <b>Settings > Sound > Touch sounds</b> on the device.</li>
+ <li>Ensure that audio has been off for at least three seconds. Five seconds or more is better, because
+ the hardware itself might have its own power logic beyond the three seconds that AudioFlinger has.</li>
+ <li>Press Home, and you should hear a click sound.</li>
+ <li>Run the following command to receive the measured warmup:
+ <pre>adb shell dumpsys media.audio_flinger | grep measuredWarmup</code></pre>
+
+<p>
+You should see output like this:
+</p>
+
+<pre>
+sampleRate=44100 frameCount=256 measuredWarmup=X ms, warmupCycles=X
+</pre>
+
+<p>
+ The <code>measuredWarmup=X</code> is X number of milliseconds
+ it took for the first set of HAL <code>write()</code>s to complete.
+</p>
+
+<p>
+ The <code>warmupCycles=X</code> is how many HAL write requests it took
+ until the execution time of <code>write()</code> matches what is expected.
+</p>
+</li>
+<li>
+ Take five measurements and report them all, as well as the mean.
+ If they are not all approximately the same,
+ then it’s likely that a measurement is incorrect.
+ For example, if you don’t wait long enough after the audio has been off,
+ you will see a lower warmup time than the mean value.
+</li>
+</ol>
+
+
+<h2 id="measuringInput">Measuring Input Warmup</h2>
+
+<p>
+ There are currently no tools provided for measuring audio input warmup.
+ However, input warmup time can be estimated by observing
+ the time required for <a href="http://developer.android.com/reference/android/media/AudioRecord.html#startRecording()">startRecording()</a>
+ to return.
+</p>
+
+
+<h2 id="reducing">Reducing Warmup Time</h2>
+
+<p>
+ Warmup time can usually be reduced by a combination of:
+ <ul>
+ <li>Good circuit design</li>
+ <li>Accurate time delays in kernel device driver</li>
+ <li>Performing independent warmup operations concurrently rather than sequentially</li>
+ <li>Leaving circuits powered on or not reconfiguring clocks (increases idle power consumption).
+ <li>Caching computed parameters</li>
+ </ul>
+ However, beware of excessive optimization. You may find that you
+ need to tradeoff between low warmup time versus
+ lack of popping at power transitions.
+</p>
diff --git a/src/devices/bluetooth.jd b/src/devices/bluetooth.jd
new file mode 100644
index 0000000..c974227
--- /dev/null
+++ b/src/devices/bluetooth.jd
@@ -0,0 +1,116 @@
+page.title=Bluetooth
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+
+<p>Android provides a default Bluetooth stack, BlueDroid, that is divided into two layers: The Bluetooth Embedded System (BTE), which implements the core
+Bluetooth functionality and the Bluetooth Application Layer (BTA), which communicates
+with Android framework applications. A Bluetooth system service communicates with the Bluetooth stack through JNI and with applications through
+Binder IPC. The system service provides developers access to various Bluetooth profiles. The following
+diagram shows the general structure of the Bluetooth stack:
+</p>
+
+<p><img src="images/bt.png"></p>
+
+<dl>
+ <dt>Application framework</dt>
+ <dd>At the application framework level is the app's code, which utilizes the <a
+ href="http://developer.android.com/reference/android/bluetooth/package-summary.html">android.bluetooth</a>
+ APIs to interact with the bluetooth hardware. Internally, this code calls the Bluetooth process through
+ the Binder IPC mechanism.</dd>
+
+ <dt>Bluetooth system service</dt>
+ <dd>The Bluetooth system service, located in <code>packages/apps/Bluetooth</code>, is packaged as an Android
+ app and implements the Bluetooth service and profiles at the Android framework layer. This app
+ calls into the HAL layer via JNI.</p>
+
+ <dt>JNI</dt>
+ <dd>The JNI code associated with <a
+ href="http://developer.android.com/reference/android/bluetooth/package-summary.html">android.bluetooth</a> is located in
+ <code>packages/apps/Bluetooth/jni</code>. The JNI code calls into the HAL layer and receives
+ callbacks from the HAL when certain Bluetooth operations occur, such as when devices are
+ discovered.</dd>
+
+ <dt>HAL</dt>
+ <dd>The hardware abstraction layer defines the standard interface that the <a
+ href="http://developer.android.com/reference/android/bluetooth/package-summary.html">android.bluetooth</a> APIs
+ and Bluetooth process calls into and that you must implement to have your bluetooth hardware
+ function correctly. The header files for the Bluetooth HAL is located
+ in the <code>hardware/libhardware/include/hardware/bluetooth.h</code> and
+ <code>hardware/libhardware/include/hardware/bt_*.h</code> files.
+ </dd>
+
+ <dt>Bluetooth stack</dt>
+ <dd>The default Bluetooth stack is provided for you and is located in
+ <code>external/bluetooth/bluedroid</code>. The stack implements the generic Bluetooth HAL as well
+ as customizes it with extensions and configuration changes.
+ </dd>
+
+ <dt>Vendor extensions</dt>
+ <dd>To add custom extensions and an HCI layer for tracing, you can create a libbt-vendor module
+ and specify these components.
+ </dd>
+
+ </dl>
+
+
+<h2 id="implementing">Implementing the HAL</h2>
+<p>The Bluetooth HAL is located in the <code>hardware/libhardware/include/hardware/</code> directory
+ and consists of the following header files:
+
+<ul>
+ <li><code>bluetooth.h</code>: Contains the HAL for the Bluetooth hardware on the device</li>
+ <li><code>bt_av.h</code>: Contains the HAL for the advanced audio profile.</li>
+ <li><code>bt_hf.h</code>: Contains the HAL for the handsfree profile.</li>
+ <li><code>bt_hh.h</code>: Contains the HAL for the HID host profile</li>
+ <li><code>bt_hl.h</code>: Contains the HAL for the health profile</li>
+ <li><code>bt_pan.h</code>: Contains the HAL for the pan profile</li>
+ <li><code>bt_sock.h</code>: Contains the HAL for the socket profile.</li>
+</ul>
+
+</p>
+
+<p>Keep in mind that your Bluetooth implementation is not constrained to the features
+ and profiles exposed in the HAL. You can find the default implementation located
+ in the BlueDroid Bluetooth stack in the <code>external/bluetooth/bluedroid</code> directory,
+ which implements the default HAL and also extra features and customizations.</p>
+</p>
+
+<h2>Customizing the BlueDroid Stack</h2>
+
+<p>If you are using the default BlueDroid stack, but want to make a few customizations, you can
+ do the following things:</p>
+
+<ul>
+ <li>Custom Bluetooth profiles - If you want to add Bluetooth profiles that do not have
+ HAL interfaces provided by Android, you must supply an SDK add-on download to make the profile available to app developers,
+ make the APIs available in the Bluetooth system process app (<code>packages/apps/Bluetooth</code>), and add them
+ to the BlueDroid stack (<code>external/bluetooth/bluedroid</code>).</li>
+ <li>Custom vendor extensions and configuration changes - You can add things such as extra AT commands or device-specific configuration changes
+ by creating a <code>libbt-vendor</code> module. See the <code>vendor/broadcom/libbt-vendor</code> directory
+ for an example.</li>
+ <li>Host Controller Interface (HCI) - You can provide your own HCI by creating a <code>libbt-hci</code> module, which
+ is mainly used for debug tracing. See the <code>external/bluetooth/hci</code> directory for an example.</li>
+</ul>
diff --git a/src/devices/build_new_device.jd b/src/devices/build_new_device.jd
new file mode 100644
index 0000000..7f9cdd2
--- /dev/null
+++ b/src/devices/build_new_device.jd
@@ -0,0 +1,411 @@
+page.title=Configuring and Building a Product
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ There are many ways to organize the source files for your device. We'll briefly go over how the
+ Galaxy Nexus implementation was organized as an example, but you can organize your source files
+ and build the way you see fit.
+</p>
+<p>
+ Galaxy Nexus was implemented with a main device configuration named <code>tuna</code> that has
+ two specific variations: <code>maguro</code> for GSM and <code>toro</code> for CDMA. The two
+ device variations inherited common characteristics from <code>tuna</code> by calling
+ <code>tuna</code>'s device Makefile and then defined their own device-specific characteristics.
+ From these device configurations, a product is created with a product definition Makefile that
+ declares product-specific information about the device such as the name and model.
+ You can view the <code>device/samsung/tuna</code>, <code>device/samsung/maguro</code>, and
+ <code>device/samsung/toro</code> directories to see how all of this is setup.
+</p>
+<h2 id="configuring">
+ Configuring a Product
+</h2>
+<p>
+ The following steps describe how to set up products in a way similar to that of the Galaxy Nexus
+ product line:
+</p>
+<ol>
+ <li>Create a <code>device/<company_name>/<device_name></code> directory for your
+ product. For example, <code>device/samsung/tuna</code>. This directory will contain source code
+ for your device along with the Makefiles to build them.
+ </li>
+
+ <li>Create a <code>device.mk</code> Makefile that declares the files and modules needed for the
+ device. For an example, see <code>device/samsung/tuna/device.mk</code>.
+ </li>
+
+ <li>Create a product definition Makefile to create a specific product based on the device. The
+ following Makefile is taken from <code>device/samsung/tuna/full_tuna.mk</code> as an example.
+ Notice that the product is inheriting from the tuna and full (emulator) devices via their
+ Makefiles, while also declaring the product-specific information such as the name, brand, and model.
+
+<pre>
+# Inherit from those products. Most specific first.
+$(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk)
+# This is where we'd set a backup provider if we had one
+#$(call inherit-product, device/sample/products/backup_overlay.mk)
+# Inherit from tuna device
+$(call inherit-product, device/samsung/tuna/device.mk)
+
+# Set those variables here to overwrite the inherited values.
+PRODUCT_NAME := full_tuna
+PRODUCT_DEVICE := tuna
+PRODUCT_BRAND := Android
+PRODUCT_MODEL := Full AOSP on Tuna
+</pre>
+
+ <p>
+ See <a href="{@docRoot}devices/build_new_device.html#prod-def">Product Definition Variables</a> for additional product-specific
+ variables you can add to your Makefiles.
+ </p>
+ </li>
+
+ <li>Create an <code>AndroidProducts.mk</code> file that points to the product's Makefiles. In
+ this example, only the product definition Makefile is needed. The example below is from
+ <code>device/samsung/tuna/AndroidProducts.mk</code>:
+ <pre>
+#
+# This file should set PRODUCT_MAKEFILES to a list of product makefiles
+# to expose to the build system. LOCAL_DIR will already be set to
+# the directory containing this file.
+#
+# This file may not rely on the value of any variable other than
+# LOCAL_DIR; do not use any conditionals, and do not look up the
+# value of any variable that isn't set in this file or in a file that
+# it includes.
+#
+
+PRODUCT_MAKEFILES := \
+ $(LOCAL_DIR)/full_tuna.mk
+</pre>
+ </li>
+
+ <li>Create a <code>BoardConfig.mk</code> Makefile that contains board-specific configurations.
+ For an example, see <code>device/samsung/tuna/BoardConfig.mk</code>.
+ </li>
+
+ <li>Create a <code>vendorsetup.sh</code> file to add your product (a "lunch combo") to the build
+ along with a <a href="{@docRoot}devices/build_system.html#variants">build variant</a> separated by a dash. For example:
+<pre>
+add_lunch_combo <product_name>-userdebug
+</pre>
+ </li>
+
+ <li>At this point, you can create more product variants based on the same device, like how the
+ Galaxy Nexus does with the <code>maguro</code> and <code>toro</code> products. For a complete
+ example, see the Galaxy Nexus implementation in <code>device/samsung/tuna</code>,
+ <code>device/samsung/maguro</code>, and <code>device/samsung/toro</code>.
+ </li>
+
+</ol>
+
+<h3 id="prod-def">
+ Product Definition Variables
+</h3>
+<p>
+ Product-specific variables are defined in the product's Makefile. Variables maintained in a
+ product definition files include:
+</p>
+<table>
+ <tbody>
+ <tr>
+ <th>
+ Parameter
+ </th>
+ <th>
+ Description
+ </th>
+ <th>
+ Example
+ </th>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_AAPT_CONFIG
+ </td>
+ <td>
+ <code>aapt</code> configurations to use when creating packages
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_BRAND
+ </td>
+ <td>
+ The brand (e.g., carrier) the software is customized for, if any
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_CHARACTERISTICS
+ </td>
+ <td>
+ <code>aapt</code> characteristics to allow adding variant-specific resources to a package.
+ </td>
+ <td>
+ tablet,nosdcard
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_CONTRIBUTORS_FILE
+ </td>
+ <td>
+ HTML file containing the contributors to the project.
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_COPY_FILES
+ </td>
+ <td>
+ List of words like <code>source_path:destination_path</code>. The file at the source path
+ should be copied to the destination path when building this product. The rules for the copy
+ steps are defined in config/Makefile
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_DEVICE
+ </td>
+ <td>
+ Name of the industrial design
+ </td>
+ <td>
+ <code>tuna</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_LOCALES
+ </td>
+ <td>
+ A space-separated list of two-letter language code, two-letter country code pairs that
+ describe several settings for the user, such as the UI language and time, date and currency
+ formatting. The first locale listed in PRODUCT_LOCALES is is used if the locale has never
+ been set before.
+ </td>
+ <td>
+ <code>en_GB de_DE es_ES fr_CA</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_MANUFACTURER
+ </td>
+ <td>
+ Name of the manufacturer
+ </td>
+ <td>
+ <code>acme</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_MODEL
+ </td>
+ <td>
+ End-user-visible name for the end product
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_NAME
+ </td>
+ <td>
+ End-user-visible name for the overall product. Appears in the Settings > About screen.
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_OTA_PUBLIC_KEYS
+ </td>
+ <td>
+ List of Over the Air (OTA) public keys for the product
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_PACKAGES
+ </td>
+ <td>
+ Lists the APKs to install.
+ </td>
+ <td>
+ <code>Calendar Contacts</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_PACKAGE_OVERLAYS
+ </td>
+ <td>
+ Indicate whether to use default resources or add any product specific overlays
+ </td>
+ <td>
+ <code>vendor/acme/overlay</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_PROPERTY_OVERRIDES
+ </td>
+ <td>
+ List of property assignments in the format "key=value"
+ </td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>
+ PRODUCT_TAGS
+ </td>
+ <td>
+ list of space-separated words for a given product
+ </td>
+ <td></td>
+ </tr>
+ </tbody>
+</table>
+
+
+<h2 id="building">Building a Product</h2>
+<p>To eventually build your product, add your HAL implementations and drivers to
+ your device's source tree and execute the following commands.</p>
+ <p>
+ For a Fusion build for armv7 with NEON:
+ </p>
+<pre>
+ build/envsetup.sh
+ lunch your_lunch_combo
+ PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/platform/platform.zip make -j32
+</pre>
+ <p>
+ For a Fusion build for armv7:
+ </p>
+<pre>
+ build/envsetup.sh
+ lunch your_lunch_combo
+ PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a/mini_armv7a-userdebug/platform/platform.zip make -j32
+</pre>
+ <p>
+ For a non-Fusion build for both architectures, run <code>make</code> like this instead:
+ </p>
+<pre>
+TARGET_BUILD_PDK=true make -j32
+</pre>
+
+<p class="note"><strong>Important:</strong>
+If you are switching between different lunch combos or between fusion and non-fusion builds,
+run the following command
+to remove any remnants of the test build so that it doesn't interfere
+with your real product's build later on.
+
+<pre>make installclean</pre>
+</p>
+
+ <p>
+ You should find new binaries located in
+ <code>/out/target/product/<device_name></code>.
+ </p>
+ </li>
+</ol>
+
+
+<h2 id="managing">
+ Managing Makefiles
+</h2>
+<p>
+ Building with the PDK is different from normal product builds that have access to all of the
+ Android sources. Existing product Makefiles require changes to build the product. This section
+ provides an overview of the available workarounds in the PDK to support product builds.
+</p>
+<p>
+ For product Makefiles:
+</p>
+<ul>
+ <li>Use the <code>inherit-product-if-exists</code> macro instead of <code>inherit-product</code>
+ if the target product file does not exist in the PDK.
+ </li>
+ <li>For the <code>PRODUCT_COPY_FILES</code> variable, use the
+ <code>add-to-product-copy-files-if-exists</code> macro, which excludes the component if it does
+ not exist.
+ </li>
+ <li>For an include sentence, use <code>-include</code> to ignore the error if the included file
+ does not exist.
+ </li>
+ <li>You can also check the presence of necessary files and include it in a PDK based build with
+ the <code>$(wildcard ...)</code> macro. For example, the following if statement executes the code
+ block if <code>frameworks/base/Android.mk</code> exists:
+ <pre>
+ifneq ($(wildcard frameworks/base/Android.mk),)
+
+...
+
+endif
+</pre>
+ </li>
+</ul>
+<p>
+ For <code>Android.mk</code> files:
+</p>
+<ul>
+ <li>
+ <code>TARGET_BUILD_PDK</code> is set to true for PDK builds. If you have a component that
+ cannot be built in the PDK build, wrap the code to build the component in an if statement:
+ <pre>
+ifeq ($(TARGET_BUILD_PDK),)
+...
+endif
+</pre>
+ </li>
+ <li>For building Android framework apps, the PDK uses the
+ <code>TARGET_BUILD_JAVA_SUPPORT_LEVEL</code> variable to notify you if building apps is
+ supported. The variable is set to <code>platform</code> if the platform APIs are available. The
+ variable is set to <code>sdk</code> when only SDK based builds are supported. Because the PDK is
+ shared pre-release and is based on a development tree, earlier versions of the PDK may not
+ support a Java build and the variable is set to null. The following statements can enable a Java
+ build only when it is supported:
+ <pre>
+ifneq ($(TARGET_BUILD_JAVA_SUPPORT_LEVEL),)
+...
+endif
+</pre>
+ </li>
+
+ <li style="list-style: none">
+ <p class="note">
+ <strong>Note:</strong> You cannot use <code>TARGET_BUILD_...</code> variables in product
+ definition Makefiles, because these variables are checked after the build reads the product
+ definition Makefiles.
+ </p>
+ </li>
+</ul>
diff --git a/src/devices/build_system.jd b/src/devices/build_system.jd
new file mode 100644
index 0000000..19fd8a3
--- /dev/null
+++ b/src/devices/build_system.jd
@@ -0,0 +1,179 @@
+page.title=Building the PDK
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Android uses a custom build system to generate tools, binaries, and documentation.</p>
+
+<p>The build system is Make-based and requires a recent version of GNU Make (note that
+ Android uses advanced features of GNU Make that may not yet appear on the GNU Make web site).
+ Before continuing, check your version of make by running <code>% make -v</code>. If you
+ don't have version 3.80 or greater, you need to
+ <a href="http://www.gnu.org/software/make/">upgrade your version of make</a>.
+</p>
+
+
+<h2 id="layers">Build Layers</h2>
+
+<p>The build hierarchy includes the abstraction layers that correspond to the physical makeup of a device. These
+ layers are described in the table below. Each layer relates to the one above it in a one-to-many relationship.
+ For example, an architecture can have more than one board and each board can have more than one device.
+ You may define an element in a given layer as a specialization of an element in the same layer,
+ thus eliminating copying and simplifying maintenance.</p>
+
+<table>
+ <tbody><tr>
+ <th>Layer</th>
+ <th>Example</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>Product</td>
+ <td>myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk</td>
+ <td><p>The product layer defines the feature specification of a shipping product such as the modules to build,
+ locales supported, and the configuration for various locales. In other words, this is the name of the
+ overall product. Product-specific variables are defined in product definition Makefiles. A product
+ can inherit from other product definitions,
+ which simplifies maintenance. A common method is to create a base product that contains features that apply
+ for all products, then creating product variants based on that base product. For example, you can have
+ two products that differ only by their radios (CDMA vs GSM) inherit from the same base product that does not define a radio.
+ <p>For a full list of product definition variables, see the
+ <a href="{@docRoot}devices/build_new_device.html#prod-def">Product Definition Files</a> section.</p>
+</td>
+
+ </tr>
+ <tr>
+ <td>Device</td>
+ <td>myDevice, myDevice_eu, myDevice_eu_lite</td>
+ <td>The device layer represents the physical layer of plastic on the device (i.e. the industrial design of the device). For example, North American devices probably include QWERTY keyboards whereas devices sold in France probably include AZERTY keyboards.</td>
+ </tr>
+ <tr>
+ <td>Board</td>
+ <td>sardine, trout, goldfish </td>
+ <td>The board layer represents the bare schematics of a product. This includes the peripherals on the board and their
+ configuraiton.</td>
+ </tr>
+ <tr>
+ <td>Arch</td>
+ <td>arm (armv7-a-neon, armv7), x86, 68k </td>
+ <td>The architecture layer describes the processor configuration and ABI (Application Binary Interface) running on the board. </td>
+ </tr>
+</table>
+
+
+<h2 id="variants">Build Variants</h2>
+
+<p>
+When building for a particular product, it's often useful to have minor
+variations on what is ultimately the final release build. These are the
+currently-defined build variants:
+</p>
+
+<table border=1>
+<tr>
+ <td>
+ <code>eng<code>
+ </td>
+ <td>
+ This is the default flavor. A plain <code>make</code> is the
+ same as <code>make eng</code>.
+ <ul>
+ <li>Installs modules tagged with: <code>eng</code>, <code>debug</code>,
+ <code>user</code>, and/or <code>development</code>.
+ <li>Installs non-APK modules that have no tags specified.
+ <li>Installs APKs according to the product definition files, in
+ addition to tagged APKs.
+ <li><code>ro.secure=0</code>
+ <li><code>ro.debuggable=1</code>
+ <li><code>ro.kernel.android.checkjni=1</code>
+ <li><code>adb</code> is enabled by default.
+ </td>
+</tr>
+<tr>
+ <td>
+ <code>user<code>
+ </td>
+ <td>
+ <code>make user</code>
+ <p>
+ This is the flavor intended to be the final release bits.
+ <ul>
+ <li>Installs modules tagged with <code>user</code>.</li>
+ <li>Installs non-APK modules that have no tags specified.</li>
+ <li>Installs APKs according to the product definition files; tags
+ are ignored for APK modules.</li>
+ <li><code>ro.secure=1</code> </li>
+ <li><code>ro.debuggable=0</code> </li>
+ <li><code>adb</code> is disabled by default.</li>
+ </td>
+</tr>
+<tr>
+ <td>
+ <code>userdebug<code>
+ </td>
+ <td>
+ <code>make userdebug</code>
+ <p>
+ The same as <code>user</code>, except:
+ <ul>
+ <li>Also installs modules tagged with <code>debug</code>.
+ <li><code>ro.debuggable=1</code>
+ <li><code>adb</code> is enabled by default.
+ </td>
+</tr>
+</table>
+
+<p class="note"><strong>Note:</strong>
+If you build one flavor and then want to build another, you should run
+<code>make installclean</code> between the two makes to guarantee that
+you don't pick up files installed by the previous flavor. <code>make
+clean</code> also suffices, but it takes a lot longer.
+</p>
+
+<h2 id="pdk-build">The PDK Build</h2>
+<p>The PDK build differs from a normal platform build in that it does not contain the entire Android source tree.
+ A <code>platform.zip</code> binary is provided that contains the missing pieces that aren't in the PDK source tree.
+ The PDK supports two different build flavors, Fusion and non-Fusion:
+</p>
+<ul>
+ <li>The Fusion build includes the <code>platform.zip</code>
+ components and allows your device to boot up into a usable Android system with a UI.
+ </li>
+ <li>The non-Fusion build omits the <code>platform.zip</code> components and boots
+ your device without a UI. In this mode,
+ you can <code>adb shell</code> into the device to run command line programs to test your
+ hardware in the early stages of development. This is useful when you only have a few HAL
+ implementations and drivers to test initially.
+ </li>
+</ul>
+
+ <h3 id="running-pdk-build">Running a default PDK build</h3>
+<p>When you have the PDK source synced, you can run a default build for the PDK to verify that your environment
+ is setup correctly. To do this, run the following commands:</p>
+
+<pre>
+source build/envsetup.sh
+lunch mini_armv7a_neon-userdebug
+PDK_FUSION_PLATFORM_ZIP=vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/platform/platform.zip make -j32
+</pre>
\ No newline at end of file
diff --git a/src/devices/camera.jd b/src/devices/camera.jd
new file mode 100644
index 0000000..1e709c8
--- /dev/null
+++ b/src/devices/camera.jd
@@ -0,0 +1,174 @@
+page.title=Camera Version 1
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Android's camera HAL connects the higher level
+camera framework APIs in <a href="http://developer.android.com/reference/android/hardware/package-summary.html">android.hardware</a> to your underlying camera driver and hardware.
+The following figure and list describe the components involved and where to find the source for each:
+</p>
+
+<p><img src="images/camera_hal.png"></p>
+
+<dl>
+
+ <dt>Application framework</dt>
+ <dd>At the application framework level is the app's code, which utilizes the <a
+ href="http://developer.android.com/reference/android/hardware/Camera.html">android.hardware.Camera</a>
+ API to interact with the camera hardware. Internally, this code calls a corresponding JNI glue class
+ to access the native code that interacts with the camera.</dd>
+
+ <dt>JNI</dt>
+ <dd>The JNI code associated with <a
+ href="http://developer.android.com/reference/android/hardware/Camera.html">android.hardware.Camera</a> is located in
+ <code>frameworks/base/core/jni/android_hardware_Camera.cpp</code>. This code calls the lower level
+ native code to obtain access to the physical camera and returns data that is used to create the
+ <a href="http://developer.android.com/reference/android/hardware/Camera.html">android.hardware.Camera</a> object at the framework level.</dd>
+
+ <dt>Native framework<dt>
+ <dd>The native framework defined in <code>frameworks/av/camera/Camera.cpp</code> provides a native equivalent
+ to the <a href="http://developer.android.com/reference/android/hardware/Camera.html">android.hardware.Camera</a> class.
+ This class calls the IPC binder proxies to obtain access to the camera service.</dd>
+
+ <dt>Binder IPC proxies</dt>
+ <dd>The IPC binder proxies facilitate communication over process boundaries. There are three camera binder
+ classes that are located in the <code>frameworks/av/camera</code> directory that calls into
+ camera service. ICameraService is the interface to the camera service, ICamera is the interface
+ to a specific opened camera device, and ICameraClient is the device's interface back to the application framework.</dd>
+
+ <dt>Camera service</dt>
+ <dd>The camera service, located in <code>frameworks/av/services/camera/libcameraservice/CameraService.cpp</code>, is the actual code that interacts with the HAL.</p>
+
+ <dt>HAL</dt>
+ <dd>The hardware abstraction layer defines the standard interface that the camera service calls into and that
+ you must implement to have your camera hardware function correctly.
+ </dd>
+
+ <dt>Kernel driver</dt>
+ <dd>The camera's driver interacts with the actual camera hardware and your implementation of the HAL. The
+ camera and driver must support YV12 and NV21 image formats to provide support for
+ previewing the camera image on the display and video recording.</dd>
+ </dl>
+
+
+<h2 id="implementing">Implementing the HAL</h2>
+<p>The HAL sits between the camera driver and the higher level Android framework
+and defines an interface that you must implement so that apps can
+correctly operate the camera hardware. The HAL interface is defined in the
+<code>hardware/libhardware/include/hardware/camera.h</code> and
+<code>hardware/libhardware/include/hardware/camera_common.h</code> header files.
+</p>
+
+<p>
+<code>camera_common.h</code> defines an important struct, <code>camera_module</code>, which defines a standard
+structure to obtain general information about the camera, such as its ID and properties
+that are common to all cameras such as whether or not it is a front or back-facing camera.
+</p>
+
+<p>
+<code>camera.h</code> contains the code that corresponds mainly with
+<a href="http://developer.android.com/reference/android/hardware/Camera.html">android.hardware.Camera</a>. This header file declares a <code>camera_device</code>
+struct that contains a <code>camera_device_ops</code> struct with function pointers
+that point to functions that implement the HAL interface. For documentation on the
+different types of camera parameters that a developer can set,
+see the <code>frameworks/av/include/camera/CameraParameters.h</code> file.
+These parameters are set with the function pointed to by
+<code>int (*set_parameters)(struct camera_device *, const char *parms)</code> in the HAL.
+</p>
+
+<p>For an example of a HAL implementation, see the implementation for the Galaxy Nexus HAL in
+<code>hardware/ti/omap4xxx/camera</code>.</p>
+
+
+<h2 id="configuring">Configuring the Shared Library</h2>
+<p>You need to set up the Android build system to
+ correctly package the HAL implementation into a shared library and copy it to the
+ appropriate location by creating an <code>Android.mk</code> file:
+
+<ol>
+ <li>Create a <code>device/<company_name>/<device_name>/camera</code> directory to contain your
+ library's source files.</li>
+ <li>Create an <code>Android.mk</code> file to build the shared library. Ensure that the Makefile contains the following lines:
+<pre>
+LOCAL_MODULE := camera.<device_name>
+LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw
+</pre>
+<p>Notice that your library must be named <code>camera.<device_name></code> (<code>.so</code> is appended automatically),
+so that Android can correctly load the library. For an example, see the Makefile
+for the Galaxy Nexus camera located in <code>hardware/ti/omap4xxx/Android.mk</code>.</p>
+
+</li>
+<li>Specify that your device has camera features by copying the necessary feature XML files in the
+<code>frameworks/native/data/etc</code> directory with your
+device's Makefile. For example, to specify that your device has a camera flash and can autofocus,
+add the following lines in your device's
+<code><device>/<company_name>/<device_name>/device.mk</code> Makefile:
+
+<pre class="no-pretty-print">
+PRODUCT_COPY_FILES := \ ...
+
+PRODUCT_COPY_FILES += \
+frameworks/native/data/etc/android.hardware.camera.flash-autofocus.xml:system/etc/permissions/android.hardware.camera.flash-autofocus.xml \
+</pre>
+
+<p>For an example of a device Makefile, see <code>device/samsung/tuna/device.mk</code>.</p>
+</li>
+
+<li>Declare your camera’s media codec, format, and resolution capabilities in
+<code>device/<company_name>/<device_name>/media_profiles.xml</code> and
+<code>device/<company_name>/<device_name>/media_codecs.xml</code> XML files.
+ For more information, see <a href="{@docRoot}guide/media.html#expose"> Exposing
+ Codecs and Profiles to the Framework</a> for information on how to do this.
+</p></code>
+
+</li>
+
+<li>Add the following lines in your device's
+ <code>device/<company_name>/<device_name>/device.mk</code>
+ Makefile to copy the <code>media_profiles.xml</code>
+and <code>media_codecs.xml</code> files to the appropriate location:
+<pre>
+# media config xml file
+PRODUCT_COPY_FILES += \
+ <device>/<company_name>/<device_name>/media_profiles.xml:system/etc/media_profiles.xml
+
+# media codec config xml file
+PRODUCT_COPY_FILES += \
+ <device>/<company_name>/<device_name>/media_codecs.xml:system/etc/media_codecs.xml
+</pre>
+</li>
+
+<li>
+<p>Declare that you want to include the Camera app in your device's system image by
+specifying it in the <code>PRODUCT_PACKAGES</code> variable in your device's
+ <code>device/<company_name>/<device_name>/device.mk</code>
+ Makefile:</p>
+<pre>
+PRODUCT_PACKAGES := \
+Gallery2 \
+...
+</pre>
+</li>
+
+</ol>
\ No newline at end of file
diff --git a/src/devices/compatibility.jd b/src/devices/compatibility.jd
new file mode 100644
index 0000000..3c43041
--- /dev/null
+++ b/src/devices/compatibility.jd
@@ -0,0 +1,197 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+
+<p>Welcome to the Android Platform Development Kit (PDK) Guide! The Android PDK allows partners to port
+ their drivers as well as develop, optimize, and test against an upcoming Android platform release.
+ The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL),
+ platform sources for integration, a binary system image, and HAL and integration documentation.
+ In addition, the PDK also ships with the Android Compatibility Test Suite (CTS).
+</p>
+
+<h2 id="arch">Android Low-Level System Architecture</h2>
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree as well as the PDK.
+The following diagram shows a system level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="http://source.android.com/source/building-kernels.html" >Building Kernels</a>.
+</p>
+
+
+<h2 id="pdk">PDK Components</h2>
+<p>Now that you have a high-level overview of the Android system, we'll go over the PDK and what it provides
+ to port Android to your product. The PDK provides source files needed to implement
+ your product and a platform binary that lets you build a runnable system image. You can then install
+ this barebones image to test your product with the latest builds of Android. The most important source files
+ included in the PDK are located in the:</p>
+
+ <ul>
+ <li><code>frameworks/native</code> directory</li>
+ <li><code>frameworks/av</code> directory for media, camera, DRM, and the audio framework stack</code></li>
+ <li><code>hardware/libhardware/include/hardware</code> directory for the HAL interfaces </li>
+ <li><code>vendor/pdk/data/cts</code> directory for the CTS binaries</li>
+ </ul>
+</p>
+<p>In addition, the Android PDK includes the following source directories:</p>
+<ul>
+ <li>abi</li>
+ <li>bionic</li>
+ <li>bootable</li>
+ <li>build</li>
+ <li>device</li>
+ <li>external (Chromium and Webkit are not included)</li>
+ <li>hardware</li>
+ <li>libnativehelper</li>
+ <li>pdk</li>
+ <li>prebuilt</li>
+ <li>prebuilts</li>
+ <li>system</li>
+</ul>
+
+ <p>The PDK also contains documentation that is split into three different sections:</p>
+ <ul>
+ <li><a href="{@docRoot}guide/getting_started.html">Getting Started</a> - Explains how to download the PDK source, how the Android build system works, and how to configure a build for your specific product.</li>
+ <li><a href="{@docRoot}guide/hal.html">The Hardware Abstraction Layer</a> - Explains the various HALs provided by Android and the interfaces (C header files) that define them. </li>
+ <li><a href="{@docRoot}guide/reference/files.html">HAL reference</a> - A quick reference for the various HAL interfaces.</li>
+ </ul>
+
+<h3 id="cts">Compatibility Test Suite</h3>
+<p>CTS binaries for ARM, MIPS, and x86 are provided in the corresponding directories in <code>vendor/pdk/data/cts</code>. Only the ARM
+ variant is Google-verified as there is no Nexus device running on any other architecture. Not all of the CTS tests since the
+ complete Android platform is not present. The following CTS tests should work:</p>
+
+<ul>
+ <li>android.bluetooth</li>
+ <li>android.graphics</li>
+ <li>android.graphics2</li>
+ <li>android.hardware</li>
+ <li>android.location</li>
+ <li>android.opengl</li>
+ <li>android.openglperf</li>
+ <li>android.media</li>
+ <li>android.mediastress</li>
+ <li>android.nativemedia.sl</li>
+ <li>android.nativemedia.xa</li>
+ <li>android.net</li>
+ <li>android.renderscript</li>
+ </ul>
+ <p>You can run individual packages such as <code>android.media</code> with:</p>
+ <pre>cts-tradefed run singleCommand cts --skip-device-info --package android.media</pre>
+</ul>
+
+ <p>Because the PDK is missing many components compared to a full Android source tree,
+ there is a PDK test plan that is provided with CTS that limits the tests that are ran when using the PDK. You can run
+ this special test plan with the following command:</p>
+
+ <pre>run cts --plan PDK</pre>
+
+<p>CTS is always actively under development, so we expect some tests to fail. CTS results
+ for the Galaxy Nexus are provided for you in the
+ the <code>vendor/pdk/data/cts/</code> directory and will show which tests fail on that
+ device. You can safely ignore the failed tests for your devices as well.</p>
+
+ <p>See the <a href="http://source.android.com/compatibility/cts-intro.html">CTS manual</a> for more information on CTS.</p>
+
+<h2 id="inc-ex">PDK Inclusions and Exclusions</h2>
+<p>The PDK is a subset of the complete Android source tree and might be missing things that you might need. Here is a list of what the PDK supports
+ and does not support:</p>
+<ul>
+ <li>Supports building Android apps using the publicly available, standard SDK. Builds with non-public platform APIs are not supported. The JNI build is supported.</li>
+ <li>Supports only <code>en_US</code> locale.</li>
+ <li>Supports only phone layouts. Tablet layouts are not included.</li>
+ <li>Enables support for software navigation buttons by default, which you can disable by setting <code>qemu.jw.mainkeys=1</code>.</li>
+ <li>Builds all binaries with SMP (symmetric multiprocessing) features enabled. This might have a small performance impact on non-SMP CPUs.</li>
+ <li>Includes a minimal amount of Java libraries. Obtain any additional Java libraries from the publicly released Android source tree.</li>
+ <li>Contains a minimum number of applications. Build and install necessary applications as needed.</li>
+ <li>Does not support media streaming.</li>
+ <li>Does not include non-Latin fonts. (set by <code>MINIMAL_FONT_FOOTPRINT</code> variable in <code>BoardConfig.mk</code>).
+ An app might crash if it requires such fonts. </li>
+ <li>Does not support replacing framework resources by using the overlay mechanism.
+ This means all configurations controlled by framework resources are fixed.</li>
+ <li>Does not support NFC</li>
+ <li>Does not support DRM</li>
+</ul>
+
+<h2 id="knownissues">Support and Known Issues</h2>
+<p>
+For questions or to report issues related with the PDK, send a message to the <a href="https://groups.google.com/a/google.com/forum/?fromgroups#!forum/android-pdk-feedback">android-pdk@google.com</a> mailing list.</p>
+
+<p>The following list describes the known issues with the PDK:</p>
+<ul>
+ <li>After running the CTS (Compatibility Test Suite), <code>android.process.acore</code> crashes. This is caused by
+some missing components in PDK and does not affect the operation of CTS tests.</li>
+</p>
diff --git a/src/devices/debugtune.jd b/src/devices/debugtune.jd
new file mode 100644
index 0000000..c852073
--- /dev/null
+++ b/src/devices/debugtune.jd
@@ -0,0 +1,21 @@
+page.title=Debugging the Android platform
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The following sections contain information, documentation, tips and tricks
+about debugging Android at the platform level, typically during development
+of platform-level features.</p>
\ No newline at end of file
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
new file mode 100644
index 0000000..7138177
--- /dev/null
+++ b/src/devices/devices_toc.cs
@@ -0,0 +1,177 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+
+<!-- Porting Android -->
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/index.html">
+ <span class="en">Porting</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/media.html">Media</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/audio.html">
+ <span class="en">Audio</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/audio_latency.html">Latency</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio_warmup.html">Warmup</a></li>
+ </ul>
+ </li>
+ <li><a href="<?cs var:toroot ?>devices/camera.html">Camera v1</a></li>
+ <li><a href="<?cs var:toroot ?>devices/drm.html">DRM</a></li>
+ <li><a href="<?cs var:toroot ?>devices/graphics.html">Graphics</a></li>
+ <li><a href="<?cs var:toroot ?>devices/bluetooth.html">Bluetooth</a></li>
+ <!-- Find a better section for these -->
+ <li class="nav-section">
+ <div class="nav-section-header empty">
+ <a href="<?cs var:toroot ?>devices/reference/files.html">
+ <span class="en">Reference</span>
+ </a>
+ </div>
+ </li>
+ </ul>
+ </li>
+<!-- End Porting Android -->
+ </li>
+
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/index.html">
+ <span class="en">Technical Information</span>
+ </a>
+ </div>
+
+ <ul>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/dalvik/index.html">
+ <span class="en">Dalvik</span></a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/dalvik/dalvik-bytecode.html">Bytecode Format</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/dalvik/dex-format.html">.Dex Format</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/dalvik/instruction-formats.html">Instruction Formats</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/datausage/index.html">
+ <span class="en">Data Usage</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/iface-overview.html">Network interface statistics overview</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/excluding-network-types.html">Excluding Network Types from Data Usage</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/tethering-data.html">Tethering Data</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/usage-cycle-resets-dates.html">Usage Cycle Reset Dates</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/kernel-overview.html">Kernel Overview</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/tags-explained.html">Data Usage Tags Explained</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/datausage/kernel-changes.html">Kernel Changes</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/debugtune.html">
+ <span class="en">Debugging and Tuning</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tuning.html">Performance Tuning</a></li>
+ <li><a href="<?cs var:toroot ?>devices/native-memory.html">Native Memory Usage</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/encryption/index.html">
+ <span class="en">Encryption</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/encryption/android_crypto_implementation.html">Encryption Technical Information</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/input/index.html">
+ <span class="en">Input</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/overview.html">Overview</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/key-layout-files.html">Key Layout Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/key-character-map-files.html">Key Character Map Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/input-device-configuration-files.html">Input Device Configuration Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/migration-guide.html">Migration Guide</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/keyboard-devices.html">Keyboard Devices</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/touch-devices.html">Touch Devices</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/dumpsys.html">Dumpsys</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/getevent.html">Getevent</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/input/validate-keymaps.html">Validate Keymaps</a></li>
+ </ul>
+ </li>
+
+ <li>
+ <a href="<?cs var:toroot ?>devices/tech/kernel.html">
+ <span class="en">Kernel</span>
+ </a>
+ </li>
+
+ <li>
+ <a href="<?cs var:toroot ?>devices/tech/power.html">
+ <span class="en">Power</span>
+ </a>
+ </li>
+
+ <li>
+ <a href="<?cs var:toroot ?>devices/tech/security/index.html">
+ <span class="en">Security</span>
+ </a>
+ </li>
+
+
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/index.html">
+ <span class="en">Trade Federation Testing Infrastructure</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/tutorial.html">Tutorial</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/commandfile_format.html">Command File Format</a></li>
+ <li id="tradefed-tree-list" class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>reference/packages.html">
+ <span class="en">Reference</span>
+ </a>
+ <div>
+ </li>
+ </ul>
+ </li>
+
+ </ul>
+ </li>
+
+</ul>
\ No newline at end of file
diff --git a/src/devices/drm.jd b/src/devices/drm.jd
new file mode 100644
index 0000000..92beaa0
--- /dev/null
+++ b/src/devices/drm.jd
@@ -0,0 +1,178 @@
+page.title=DRM
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>This document introduces Widevine DRM security levels
+ and certification requirements. It explains how to integrate and distribute Widevine DRM
+ for your product. Android provides the Widevine DRM solution with a royalty-free
+ license and we recommend that you use it for
+ your protected playback solution. </p>
+
+<h2 id="overview">Overview</h2>
+<p>
+Availability of rich digital content is important to users on mobile devices. To make their content widely available,
+Android developers and digital content publishers need a consistent DRM implementation supported across the Android
+ecosystem. In order to make that digital content available on Android devices and to ensure that there is at least
+one consistent DRM available across all devices, Google provides Widevine DRM for free on compatible Android devices.
+On Android 3.0 and higher platforms, the Widevine DRM plugin is integrated with the Android DRM framework and uses
+hardware-backed protection to secure movie content and user credentials.
+</p>
+
+<p>
+The content protection provided by the Widevine DRM plugin depends on the security and content protection capabilities of the underlying hardware platform. The hardware capabilities of the device include hardware secure boot to establish a chain of trust of security and protection of cryptographic keys. Content protection capabilities of the device include protection of decrypted frames in the device and content output protection via a trusted output protection mechanism. Not all hardware platforms support all the above security and content protection features. Security is never implemented in a single place in the stack, but instead relies on the integration of hardware, software, and services. The combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to provide a secure device.</p>
+
+
+<h3 id="framework">Android DRM Framework</h3>
+<p>Android 3.0 and higher platforms provide an extensible DRM framework that lets applications manage protected content using a
+ choice of DRM mechanisms. For application developers, the framework offers an
+ abstract, unified API that simplifies the management of protected content.
+ The API hides the complexity of DRM operations and allows a consistent operation mode for both protected and unprotected
+ content across a variety of DRM schemes. For device manufacturers, content owners, and Internet digital media providers
+ the DRM framework plugin API provides a means of adding support for a DRM scheme of choice into the Android system, for
+ secure enforcement of content protection.
+
+ <p><strong>Note:</strong> We recommend that you integrate the Widevine
+ solution as it is already implemented and ready for you to use. </p>
+</p>
+
+<h3 id="plugin">Widevine DRM Plugin</h3>
+
+<p>
+Built on top of the Android DRM framework, the Widevine DRM plugin offers DRM and advanced copy protection features on Android devices. Widevine DRM is available in binary form under a royalty free license from Widevine. The Widevine DRM plugin provides the capability to license, securely distribute, and protect playback of multimedia content. Protected content is secured using an encryption scheme based on the open AES (Advanced Encryption Standard). An application can decrypt the content only if it obtains a license from the Widevine DRM licensing server for the current user. Widevine DRM functions on Android in the same way as it does on other platforms. Figure 1 shows how the WideVine Crypto Plugin fits into the Android stack:</p>
+
+
+ <img src="images/drm_hal.png" alt="" />
+
+ <p class="img-caption"><strong>Figure 1.</strong> Widevine Crypto Plugin</p>
+
+
+<h2 id="integrating">Integrating Widevine into Your Product</h2>
+
+<p>The following sections go over the different security levels that Widevine supports and the requirements that your product must meet to
+support Widevine. After reading the information, you need to determine the security level for your target hardware, integration, and Widevine keybox provisioning requirements.
+</p>
+<p >
+To integrate and distribute Widevine DRM on Android devices, contact your Android technical account manager to begin Widevine DRM integration.
+We recommend you engage early in your device development process with the Widevine team to provide the highest level of content protection on the device.
+Certify devices using the Widevine test player and submit results to your Android technical account manager for approval.
+</p>
+
+<h3 id="security">
+Widevine DRM security levels
+</h3>
+
+<p>Security is never implemented in a single place in the stack, but instead relies on the integration of hardware, software, and services. The combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to provide a secure device.</p>
+
+<p>
+At the system level, Android offers the core security features of the Linux kernel, extended and customized for mobile devices. In the application framework, Android provides an extensible DRM framework and system architecture for checking and enforcing digital rights. The Widevine DRM plugin integrates with the hardware platform to leverage the available security capabilities. The level of security offered is determined by a combination of the security capabilities of the hardware platform and the integration with Android and the Widevine DRM plugin. Widevine DRM security supports the three levels of security shown in the table below.
+</p>
+
+<table>
+
+<tr>
+<th>Security Level</th>
+<th>Secure Bootloader</th>
+<th>Widevine Key Provisioning</th>
+<th>Security Hardware or ARM Trust Zone</th>
+<th>Widevine Keybox and Video Key Processing</th>
+<th>Hardware Video Path</th>
+</tr>
+<tr>
+ <td>Level 1</td>
+ <td>Yes</td>
+ <td>Factory provisioned Widevine Keys</td>
+ <td>Yes</td>
+ <td>Keys never exposed in clear to host CPU</td>
+ <td>Hardware protected video path</td>
+<tr>
+
+<tr>
+ <td>Level 2</td>
+ <td>Yes</td>
+ <td>Factory provisioned Widevine Keys</td>
+ <td>Yes</td>
+ <td>Keys never exposed in clear to host CPU</td>
+ <td>Hardware protected video path</td>
+<tr>
+
+<tr>
+ <td>Level 3</td>
+ <td>Yes*</td>
+ <td>Field provisioned Widevine Keys</td>
+ <td>No</td>
+ <td>Clear keys exposed to host CPU</td>
+ <td>Clear video streams delivered to video decoder</td>
+<tr>
+
+</table>
+
+<p><superscript>*</superscript>Device implementations may use a trusted bootloader, where in the bootloader is authenticated via an OEM key stored on a system partition.</p>
+
+<h3 id="security-details">
+Security level details
+</h3>
+<h4>
+Level 1
+</h4>
+<p>In this implementation Widevine DRM keys and decrypted content are never exposed to the host CPU. Only security hardware or a protected security co-processor uses clear key values and the media content is decrypted by the secure hardware. This level of security requires factory provisioning of the Widevine key-box or requires the Widevine key-box to be protected by a device key installed at the time of manufacturing. The following describes some key points to this security level:
+</p>
+
+<ul>
+ <li>Device manufacturers must provide a secure bootloader. The chain of trust from the bootloader must extend through any software or firmware components involved in the security implementation, such as the ARM TrustZone protected application and any components involved in the enforcement of the secure video path. </li>
+ <li>The Widevine key-box must be encrypted with a device-unique secret key that is not visible to software or probing methods outside of the TrustZone.</li>
+ <li>The Widevine key-box must be installed in the factory or delivered to the device using an approved secure delivery mechanism.</li>
+ <li>Device manufacturers must provide an implementation of the Widevine Level 1 OEMCrypto API that performs all key processing and decryption in a trusted environment.</li>
+</ul>
+
+<h4>Level 2</h4>
+<p>
+ In this security level, the Widevine keys are never exposed to the host CPU. Only security hardware or a protected security co-processor uses clear key values. An AES crypto block performs the high throughput AES decryption of the media stream. The resulting clear media buffers are returned to the CPU for delivery to the video decoder. This level of security requires factory provisioning of the Widevine key-box or requires the Widevine key box to be protected by a key-box installed at the time of manufacturing.
+ The following list describes some key requirements of this security level:
+</p>
+
+<ul>
+ <li>Device manufacturers must provide a secure bootloader. The chain of trust from the bootloader must extend through any software or firmware components involved in the security implementation, such as the TrustZone protected application. </li>
+ <li>The Widevine key-box must be encrypted with a device-unique secret key that is not visible to software or probing methods outside of the TrustZone.</li>
+ <li>The Widevine key-box must be installed in the factory or delivered to the device using an approved secure delivery mechanism.</li>
+ <li>Device manufacturers must provide an implementation of the Widevine Level 2 OEMCrypto API that performs all key processing and decryption in a trusted environment.</li>
+ <li>Device manufacturers must provide a bootloader that loads signed system images only. For devices that allow users to load a custom operating system or gain root privileges on the device by unlocking the bootloader, device manufacturers must support the following:
+ <ul>
+ <li>Device manufacturers must provide a bootloader that allows a Widevine key-box to be written only when the bootloader is in a locked state.</li>
+ <li>The Widevine key-box must be stored in a region of memory that is erased or is inaccessible when the device bootloader is in an unlocked state.</li>
+ </ul>
+ </li>
+</ul>
+
+<h4>Level 3</h4>
+<p>
+This security level relies on the secure bootloader to verify the system image. An AES crypto block performs the AES decryption of the media stream and the resulting clear media buffers are returned to the CPU for delivery to the video decoder.
+</p>
+
+<p>Device manufacturers must provide a bootloader that loads signed system images only. For devices that allow users to load a custom operating system or gain root privileges on the device by unlocking the bootloader, device manufacturers must support the following:</p>
+ <ul>
+ <li>Device manufacturers must provide a bootloader that allows a Widevine key-box to be written only when the bootloader is in a locked state.</li>
+ <li>The Widevine key-box must be stored in a region of memory that is erased or is inaccessible when the device bootloader is in an unlocked state.</li>
+ </ul>
diff --git a/src/devices/getting_started.jd b/src/devices/getting_started.jd
new file mode 100644
index 0000000..df4fe89
--- /dev/null
+++ b/src/devices/getting_started.jd
@@ -0,0 +1,200 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android Platform Development Kit (PDK) Guide! The Android PDK allows partners to port
+ their drivers as well as develop, optimize, and test against an upcoming Android platform release.
+ The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL),
+ platform sources for integration, a binary system image, and HAL and integration documentation.
+ In addition, the PDK also ships with the Android Compatibility Test Suite (CTS).
+</p>
+
+<h2 id="arch">Android Low-Level System Architecture</h2>
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree as well as the PDK.
+The following diagram shows a system level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
+</p>
+
+
+<h2 id="pdk">PDK Components</h2>
+<p>Now that you have a high-level overview of the Android system, we'll go over the PDK and what it provides
+ to port Android to your product. The PDK provides source files needed to implement
+ your product and a platform binary that lets you build a runnable system image. You can then install
+ this barebones image to test your product with the latest builds of Android. The most important source files
+ included in the PDK are located in the:</p>
+
+ <ul>
+ <li><code>frameworks/native</code> directory</li>
+ <li><code>frameworks/av</code> directory for media, camera, DRM, and the audio framework stack</code></li>
+ <li><code>hardware/libhardware/include/hardware</code> directory for the HAL interfaces </li>
+ <li><code>vendor/pdk/data/cts</code> directory for the CTS binaries</li>
+ </ul>
+</p>
+<p>In addition, the Android PDK includes the following source directories:</p>
+<ul>
+ <li>abi</li>
+ <li>bionic</li>
+ <li>bootable</li>
+ <li>build</li>
+ <li>device</li>
+ <li>external (Chromium and Webkit are not included)</li>
+ <li>hardware</li>
+ <li>libnativehelper</li>
+ <li>pdk</li>
+ <li>prebuilt</li>
+ <li>prebuilts</li>
+ <li>system</li>
+</ul>
+
+ <p>The PDK also contains documentation that is split into the following sections:</p>
+ <ul>
+ <li><a href="{@docRoot}devices/getting_started.html">Getting Started</a> - Explains how to download
+ the PDK source, how the Android build system works, and how to configure a build for your specific product.</li>
+ <li><a href="{@docRoot}devices/porting.html">Porting</a> - Explains the various HALs provided by Android
+ and the interfaces (C header files) that define them. This section also provides reference documentation
+ for the various HAL interfaces.</li>
+ <li><a href="{@docRoot}devices/debugtune.html">Debugging and Tuning</a> - Explains the debugging and tuning features of the PDK.</li>
+ <li><a href="{@docRoot}devices/tech/index.html">Technical Information</a> - Explains important concepts of the Android platform.</li>
+ </ul>
+
+<h3 id="cts">Compatibility Test Suite</h3>
+<p>CTS binaries for ARM, MIPS, and x86 are provided in the corresponding directories in <code>vendor/pdk/data/cts</code>. Only the ARM
+ variant is Google-verified as there is no Nexus device running on any other architecture. Not all of the CTS tests since the
+ complete Android platform is not present. The following CTS tests should work:</p>
+
+<ul>
+ <li>android.bluetooth</li>
+ <li>android.graphics</li>
+ <li>android.graphics2</li>
+ <li>android.hardware</li>
+ <li>android.location</li>
+ <li>android.opengl</li>
+ <li>android.openglperf</li>
+ <li>android.media</li>
+ <li>android.mediastress</li>
+ <li>android.nativemedia.sl</li>
+ <li>android.nativemedia.xa</li>
+ <li>android.net</li>
+ <li>android.renderscript</li>
+ </ul>
+ <p>You can run individual packages such as <code>android.media</code> with:</p>
+ <pre>cts-tradefed run singleCommand cts --skip-device-info --package android.media</pre>
+</ul>
+
+ <p>Because the PDK is missing many components compared to a full Android source tree,
+ there is a PDK test plan that is provided with CTS that limits the tests that are ran when using the PDK. You can run
+ this special test plan with the following command:</p>
+
+ <pre>run cts --plan PDK</pre>
+
+<p>CTS is always actively under development, so we expect some tests to fail. CTS results
+ for the Galaxy Nexus are provided for you in the
+ the <code>vendor/pdk/data/cts/</code> directory and will show which tests fail on that
+ device. You can safely ignore the failed tests for your devices as well.</p>
+
+ <p>See <a href="{@docRoot}compatibility/index.html">Compatibility</a> for more information on CTS.</p>
+
+<h2 id="inc-ex">PDK Inclusions and Exclusions</h2>
+<p>The PDK is a subset of the complete Android source tree and might be missing things that you might need. Here is a list of what the PDK supports
+ and does not support:</p>
+<ul>
+ <li>Supports building Android apps using the publicly available, standard SDK. Builds with non-public platform APIs are not supported. The JNI build is supported.</li>
+ <li>Supports only <code>en_US</code> locale.</li>
+ <li>Supports only phone layouts. Tablet layouts are not included.</li>
+ <li>Enables support for software navigation buttons by default, which you can disable by setting <code>qemu.jw.mainkeys=1</code>.</li>
+ <li>Builds all binaries with SMP (symmetric multiprocessing) features enabled. This might have a small performance impact on non-SMP CPUs.</li>
+ <li>Includes a minimal amount of Java libraries. Obtain any additional Java libraries from the publicly released Android source tree.</li>
+ <li>Contains a minimum number of applications. Build and install necessary applications as needed.</li>
+ <li>Does not support media streaming.</li>
+ <li>Does not include non-Latin fonts. (set by <code>MINIMAL_FONT_FOOTPRINT</code> variable in <code>BoardConfig.mk</code>).
+ An app might crash if it requires such fonts. </li>
+ <li>Does not support replacing framework resources by using the overlay mechanism.
+ This means all configurations controlled by framework resources are fixed.</li>
+ <li>Does not support NFC</li>
+ <li>Does not support DRM</li>
+</ul>
+
+<h2 id="knownissues">Support and Known Issues</h2>
+<p>
+For questions or to report issues related with the PDK, send a message to the <a href="https://groups.google.com/a/google.com/forum/?fromgroups#!forum/android-pdk-feedback">android-pdk@google.com</a> mailing list.</p>
+
+<p>The following list describes the known issues with the PDK:</p>
+<ul>
+ <li>After running the CTS (Compatibility Test Suite), <code>android.process.acore</code> crashes. This is caused by
+some missing components in PDK and does not affect the operation of CTS tests.</li>
+</p>
diff --git a/src/devices/graphics.jd b/src/devices/graphics.jd
new file mode 100644
index 0000000..357e8f9
--- /dev/null
+++ b/src/devices/graphics.jd
@@ -0,0 +1,381 @@
+page.title=Graphics
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The Android framework has a variety of graphics rendering APIs for 2D and 3D that interact with
+ your HAL implementations and graphics drivers, so it is important to have a good understanding of
+ how they work at a higher level. There are two general ways that app developers can draw things
+ to the screen: with Canvas or OpenGL.
+</p>
+<p>
+ <a href="http://developer.android.com/reference/android/graphics/Canvas.html">android.graphics.Canvas</a>
+ is a 2D graphics API and is the most widely used graphics API by
+ developers. Canvas operations draw all the stock <a href="http://developer.android.com/reference/android/view/View.html">android.view.View</a>s
+ and custom <a href="http://developer.android.com/reference/android/view/View.html">android.view.View</a>s in Android. Prior to Android 3.0, Canvas used the Skia 2D drawing library to
+ draw, which could not take advantage of hardware acceleration.
+</p>
+<p>
+ Introduced in Android 3.0, hardware acceleration for Canvas APIs uses a new drawing library
+ called OpenGLRenderer that translates Canvas operations to OpenGL operations so that they can
+ execute on the GPU. Developers had to opt-in to this feature previously, but beginning in Android
+ 4.0, hardware-accelerated Canvas is enabled by default. Consequently, a hardware GPU that
+ supports OpenGL ES 2.0 is mandatory for Android 4.0 devices.
+</p>
+<p>
+ The OpenGLRenderer does not interact with Skia, so we
+ anticipate Skia to be slowly phased out without adverse effects to developers. Skia is currently
+ deprecated and in maintenance mode but will be neccessary for a while because most apps published
+ today still rely on non-hardware accelerated Canvas operations. In addition, not all Skia
+ operations are supported by OpenGL, so some operations are still done in software with Skia, even
+ with hardware acceleration turned on.
+</p>
+<p>
+ The other main way that developers render graphics is by using OpenGL ES 1.x or 2.0 to directly
+ render to a surface. Android provides OpenGL ES interfaces in the
+ <a href="http://developer.android.com/reference/android/opengl/package-summary.html">android.opengl</a> package
+ that a developer can use to call into your GL implementation with the SDK or with native APIs
+ provided in the Android NDK.
+
+ <p class="note"><strong>Note:</strong>A third option, Renderscript, was introduced in Android 3.0 to
+ serve as a platform-agnostic graphics rendering API (it used OpenGL ES 2.0 under the hood), but
+ will be deprecated starting in the Android 4.1 release.
+</p>
+<h2 id="render">
+ How Android Renders Graphics
+</h2>
+<p>
+ No matter what rendering API developers use, everything is rendered onto a buffer of pixel data
+ called a "surface." Every window that is created on the Android platform is backed by a surface.
+ All of the visible surfaces that are rendered to are composited onto the display
+ by the SurfaceFlinger, Android's system service that manages composition of surfaces.
+ Of course, there are more components that are involved in graphics rendering, and the
+ main ones are described below:
+</p>
+
+<dl>
+ <dt>
+ <strong>Image Stream Producers</strong>
+ </dt>
+ <dd>Image stream producers can be things such as an OpenGL ES game, video buffers from the media server,
+ a Canvas 2D application, or basically anything that produces graphic buffers for consumption.
+ </dd>
+
+ <dt>
+ <strong>Image Stream Consumers</strong>
+ </dt>
+ <dd>The most common consumer of image streams is SurfaceFlinger, the system service that consumes
+ the currently visible surfaces and composites them onto the display using
+ information provided by the Window Manager. SurfaceFlinger is the only service that can
+ modify the content of the display. SurfaceFlinger uses OpenGL and the
+ hardware composer to compose a group of surfaces. Other OpenGL ES apps can consume image
+ streams as well, such as the camera app consuming a camera preview image stream.
+ </dd>
+ <dt>
+ <strong>SurfaceTexture</strong>
+ </dt>
+ <dd>SurfaceTexture contains the logic that ties image stream producers and image stream consumers together
+ and is made of three parts: <code>SurfaceTextureClient</code>, <code>ISurfaceTexture</code>, and
+ <code>SurfaceTexture</code> (in this case, <code>SurfaceTexture</code> is the actual C++ class and not
+ the name of the overall component). These three parts facilitate the producer (<code>SurfaceTextureClient</code>),
+ binder (<code>ISurfaceTexture</code>), and consumer (<code>SurfaceTexture</code>)
+ components of SurfaceTexture in processes such as requesting memory from Gralloc,
+ sharing memory across process boundaries, synchronizing access to buffers, and pairing the appropriate consumer with the producer.
+ SurfaceTexture can operate in both asynchronous (producer never blocks waiting for consumer and drops frames) and
+ synchronous (producer waits for consumer to process textures) modes. Some examples of image
+ producers are the camera preview produced by the camera HAL or an OpenGL ES game. Some examples
+ of image consumers are SurfaceFlinger or another app that wants to display an OpenGL ES stream
+ such as the camera app displaying the camera viewfinder.
+ </dd>
+
+ <dt>
+ <strong>Window Manager</strong>
+ </dt>
+ <dd>
+ The Android system service that controls window lifecycles, input and focus events, screen
+ orientation, transitions, animations, position, transforms, z-order, and many other aspects of
+ a window (a container for views). A window is always backed by a surface. The Window Manager
+ sends all of the window metadata to SurfaceFlinger, so SurfaceFlinger can use that data
+ to figure out how to composite surfaces on the display.
+ </dd>
+
+ <dt>
+ <strong>Hardware Composer</strong>
+ </dt>
+ <dd>
+ The hardware abstraction for the display subsystem. SurfaceFlinger can delegate certain
+ composition work to the hardware composer to offload work from the OpenGL and the GPU. This makes
+ compositing faster than having SurfaceFlinger do all the work. Starting with Jellybean MR1,
+ new versions of the hardware composer have been introduced. See the <code>hardware/libhardware/include/hardware/gralloc.h</code> <a href="#hwc">Hardware composer</a> section
+ for more information.
+ </dd>
+
+ <dt>
+ <strong>Gralloc</strong>
+ </dt>
+ <dd>Allocates memory for graphics buffers. See the If you
+ are using version 1.1 or later of the <a href="#hwc">hardware composer</a>, this HAL is no longer needed.</dd>
+
+
+</dl>
+<p>
+ The following diagram shows how these components work together:
+</p><img src="images/graphics_surface.png">
+<p class="img-caption">
+ <strong>Figure 1.</strong> How surfaces are rendered
+</p>
+
+</p>
+<h2 id="provide">
+ What You Need to Provide
+</h2>
+<p>
+ The following list and sections describe what you need to provide to support graphics in your product:
+</p>
+<ul>
+ <li>OpenGL ES 1.x Driver
+ </li>
+ <li>OpenGL ES 2.0 Driver
+ </li>
+ <li>EGL Driver
+ </li>
+ <li>Gralloc HAL implementation
+ </li>
+ <li>Hardware Composer HAL implementation
+ </li>
+ <li>Framebuffer HAL implementation
+ </li>
+</ul>
+<h3 id="gl">
+ OpenGL and EGL drivers
+</h3>
+<p>
+ You must provide drivers for OpenGL ES 1.x, OpenGL ES 2.0, and EGL. Some key things to keep in
+ mind are:
+</p>
+<ul>
+ <li>The GL driver needs to be robust and conformant to OpenGL ES standards.
+ </li>
+ <li>Do not limit the number of GL contexts. Because Android allows apps in the background and
+ tries to keep GL contexts alive, you should not limit the number of contexts in your driver. It
+ is not uncommon to have 20-30 active GL contexts at once, so you should also be careful with the
+ amount of memory allocated for each context.
+ </li>
+ <li>Support the YV12 image format and any other YUV image formats that come from other
+ components in the system such as media codecs or the camera.
+ </li>
+ <li>Support the mandatory extensions: <code>GL_OES_texture_external</code>,
+ <code>EGL_ANDROID_image_native_buffer</code>, and <code>EGL_ANDROID_recordable</code>. We highly
+ recommend supporting <code>EGL_ANDROID_blob_cache</code> and <code>EGL_KHR_fence_sync</code> as
+ well.</li>
+</ul>
+
+<p>
+ Note that the OpenGL API exposed to app developers is different from the OpenGL interface that
+ you are implementing. Apps do not have access to the GL driver layer, and must go through the
+ interface provided by the APIs.
+</p>
+<h4>
+ Pre-rotation
+</h4>
+<p>Many times, hardware overlays do not support rotation, so the solution is to pre-transform the buffer before
+ it reaches SurfaceFlinger. A query hint in ANativeWindow was added (<code>NATIVE_WINDOW_TRANSFORM_HINT</code>)
+ that represents the most likely transform to be be applied to the buffer by SurfaceFlinger.
+
+ Your GL driver can use this hint to pre-transform the buffer before it reaches SurfaceFlinger, so when the buffer
+ actually reaches SurfaceFlinger, it is correctly transformed. See the ANativeWindow
+ interface defined in <code>system/core/include/system/window.h</code> for more details. The following
+ is some pseudo-code that implements this in the hardware composer:
+</p>
+
+<pre>
+ANativeWindow->query(ANativeWindow, NATIVE_WINDOW_DEFAULT_WIDTH, &w);
+ANativeWindow->query(ANativeWindow, NATIVE_WINDOW_DEFAULT_HEIGHT, &h);
+ANativeWindow->query(ANativeWindow, NATIVE_WINDOW_TRANSFORM_HINT, &hintTransform);
+if (hintTransform & HAL_TRANSFORM_ROT_90)
+swap(w, h);
+
+native_window_set_buffers_dimensions(anw, w, h);
+ANativeWindow->dequeueBuffer(...);
+
+// here GL driver renders content transformed by " hintTransform "
+
+int inverseTransform;
+inverseTransform = hintTransform;
+if (hintTransform & HAL_TRANSFORM_ROT_90)
+ inverseTransform ^= HAL_TRANSFORM_ROT_180;
+
+native_window_set_buffers_transform(anw, inverseTransform);
+
+ANativeWindow->queueBuffer(...);
+</pre>
+
+<h3 id="gralloc">
+ Gralloc HAL
+</h3>
+<p>
+ The graphics memory allocator is needed to allocate memory that is requested by
+ SurfaceTextureClient in image producers. You can find a stub implementation of the HAL at
+ <code>hardware/libhardware/modules/gralloc.h</code>
+</p>
+<h4>
+ Protected buffers
+</h4>
+<p>
+ There is a gralloc usage flag <code>GRALLOC_USAGE_PROTECTED</code> that allows
+ the graphics buffer to be displayed only through a hardware protected path.
+</p>
+<h3 id="hwc">
+ Hardware Composer HAL
+</h3>
+<p>
+ The hardware composer is used by SurfaceFlinger to composite surfaces to the screen. The hardware
+ composer abstracts things like overlays and 2D blitters and helps offload some things that would
+ normally be done with OpenGL.
+</p>
+
+<p>Jellybean MR1 introduces a new version of the HAL. We recommend that you start using version 1.1 of the hardware
+ composer HAL as it will provide support for the newest features (explicit synchronization, external displays, etc).
+ Keep in mind that in addition to 1.1 version, there is also a 1.0 version of the HAL that we used for internal
+ compatibility reasons and a 1.2 draft mode of the hardware composer HAL. We recommend that you implement
+ version 1.1 until 1.2 is out of draft mode.
+</p>
+
+ <p>Because the physical display hardware behind the hardware composer
+ abstraction layer can vary from device to device, it is difficult to define recommended features, but
+ here is some guidance:</p>
+
+<ul>
+ <li>The hardware composer should support at least 4 overlays (status bar, system bar, application,
+ and live wallpaper) for phones and 3 overlays for tablets (no status bar).</li>
+ <li>Layers can be bigger than the screen, so the hardware composer should be able to handle layers
+ that are larger than the display (For example, a wallpaper).</li>
+ <li>Pre-multiplied per-pixel alpha blending and per-plane alpha blending should be supported at the same time.</li>
+ <li>The hardware composer should be able to consume the same buffers that the GPU, camera, video decoder, and Skia buffers are producing,
+ so supporting some of the following properties is helpful:
+ <ul>
+ <li>RGBA packing order</li>
+ <li>YUV formats</li>
+ <li>Tiling, swizzling, and stride properties</li>
+ </ul>
+ </li>
+ <li>A hardware path for protected video playback must be present if you want to support protected content.</li>
+</ul>
+<p>
+ The general recommendation when implementing your hardware composer is to implement a no-op
+ hardware composer first. Once you have the structure done, implement a simple algorithm to
+ delegate composition to the hardware composer. For example, just delegate the first three or four
+ surfaces to the overlay hardware of the hardware composer. After that focus on common use cases,
+ such as:
+</p>
+<ul>
+ <li>Full-screen games in portrait and landscape mode
+ </li>
+ <li>Full-screen video with closed captioning and playback control
+ </li>
+ <li>The home screen (compositing the status bar, system bar, application window, and live
+ wallpapers)
+ </li>
+ <li>Protected video playback
+ </li>
+ <li>Multiple display support
+ </li>
+</ul>
+<p>
+ After implementing the common use cases, you can focus on optimizations such as intelligently
+ selecting the surfaces to send to the overlay hardware that maximizes the load taken off of the
+ GPU. Another optimization is to detect whether the screen is updating. If not, delegate composition
+ to OpenGL instead of the hardware composer to save power. When the screen updates again, contin`ue to
+ offload composition to the hardware composer.
+</p>
+
+<p>
+ You can find the HAL for the hardware composer in the
+ <code>hardware/libhardware/include/hardware/hwcomposer.h</code> and <code>hardware/libhardware/include/hardware/hwcomposer_defs.h</code>
+ files. A stub implementation is available in the <code>hardware/libhardware/modules/hwcomposer</code> directory.
+</p>
+
+<h4>
+ VSYNC
+</h4>
+<p>
+ VSYNC synchronizes certain events to the refresh cycle of the display. Applications always
+ start drawing on a VSYNC boundary and SurfaceFlinger always composites on a VSYNC boundary.
+ This eliminates stutters and improves visual performance of graphics.
+ The hardware composer has a function pointer</p>
+
+ <pre>int (waitForVsync*) (int64_t *timestamp)</pre>
+
+ <p>that points to a function you must implement for VSYNC. This function blocks until
+ a VSYNC happens and returns the timestamp of the actual VSYNC.
+ A client can receive a VSYNC timestamps once, at specified intervals, or continously (interval of 1).
+ You must implement VSYNC to have no more than a 1ms lag at the maximum (1/2ms or less is recommended), and
+ the timestamps returned must be extremely accurate.
+</p>
+
+<h4>Explicit synchronization</h4>
+<p>Explicit synchronization is required in Jellybean MR1 and later and provides a mechanism
+for Gralloc buffers to be acquired and released in a synchronized way.
+Explicit synchronization allows producers and consumers of graphics buffers to signal when
+they are done with a buffer. This allows the Android system to asynchronously queue buffers
+to be read or written with the certainty that another consumer or producer does not currently need them.</p>
+<p>
+This communication is facilitated with the use of synchronization fences, which are now required when requesting
+a buffer for consuming or producing. The
+ synchronization framework consists of three main parts:</p>
+<ul>
+ <li><code>sync_timeline</code>: a monotonically increasing timeline that should be implemented
+ for each driver instance. This basically is a counter of jobs submitted to the kernel for a particular piece of hardware.</li>
+ <li><code>sync_pt</code>: a single value or point on a <code>sync_timeline</code>. A point
+ has three states: active, signaled, and error. Points start in the active state and transition
+ to the signaled or error states. For instance, when a buffer is no longer needed by an image
+ consumer, this <code>sync_point</code> is signaled so that image producers
+ know that it is okay to write into the buffer again.</li>
+ <li><code>sync_fence</code>: a collection of <code>sync_pt</code>s that often have different
+ <code>sync_timeline</code> parents (such as for the display controller and GPU). This allows
+ multiple consumers or producers to signal that
+ they are using a buffer and to allow this information to be communicated with one function parameter.
+ Fences are backed by a file descriptor and can be passed from kernel-space to user-space.
+ For instance, a fence can contain two <code>sync_point</code>s that signify when two separate
+ image consumers are done reading a buffer. When the fence is signaled,
+ the image producers now know that both consumers are done consuming.</li>
+ </ul>
+
+<p>To implement explicit synchronization, you need to do provide the following:
+
+<ul>
+ <li>A kernel-space driver that implements a synchronization timeline for a particular piece of hardware. Drivers that
+ need to be fence-aware are generally anything that accesses or communicates with the hardware composer.
+ See the <code>system/core/include/sync/sync.h</code> file for more implementation details. The
+ <code>system/core/libsync</code> directory includes a library to communicate with the kernel-space </li>
+ <li>A hardware composer HAL module (version 1.1 or later) that supports the new synchronization functionality. You will need to provide
+ the appropriate synchronization fences as parameters to the <code>set()</code> and <code>prepare()</code> functions in the HAL. As a last resort,
+you can pass in -1 for the file descriptor parameters if you cannot support explicit synchronization for some reason. This
+is not recommended, however.</li>
+ <li>Two GL specific extensions related to fences, <code>EGL_ANDROID_native_fence_sync</code> and <code>EGL_ANDROID_wait_sync</code>,
+ along with incorporating fence support into your graphics drivers.</ul>
+
+
+
diff --git a/src/devices/hal.jd b/src/devices/hal.jd
new file mode 100644
index 0000000..5a53ef7
--- /dev/null
+++ b/src/devices/hal.jd
@@ -0,0 +1,124 @@
+page.title=The Hardware Abstraction Layer
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The hardware abstraction layer (HAL) defines a standard interface for hardware vendors to
+ implement and allows Android to be agnostic about lower-level driver
+ implementations. The HAL allows you to implement functionality
+ without affecting or modifying the higher level system. HAL implementations
+ are packaged into modules (<code>.so</code>) file and loaded by the Android
+ system at the appropriate time.
+<h2 id="structure">
+ Standard HAL structure
+</h2>
+<p>
+ Each hardware-specific HAL interface has properties that are common to all HAL interfaces. These
+ properties are defined in <code>hardware/libhardware/include/hardware/hardware.h</code> and
+ guarantees that HALs have a predictable structure.
+ This interface allows the Android system to load the correct versions of your
+ HAL modules in a consistent way. There are two general components
+ that a HAL interface consists of: a module and a device.
+</p>
+<p>
+ A module represents your packaged HAL implementation, which is stored as a shared library (<code>.so file</code>). It contains
+ metadata such as the version, name, and author of the module, which helps Android find and load it correctly. The
+ <code>hardware/libhardware/include/hardware/hardware.h</code> header file defines a
+ struct, <code>hw_module_t</code>, that represents a module and contains information such as
+ the module version, author, and name.</p>
+
+ <p>In addition, the <code>hw_module_t</code> struct contains
+ a pointer to another struct, <code>hw_module_methods_t</code>, that contains a pointer to
+ an "open" function for the module. This open function is used to initate communication with
+ the hardware that the HAL is serving as an abstraction for. Each hardware-specific HAL usually
+ extends the generic <code>hw_module_t</code> struct with additional information
+ for that specific piece of hardware. For example in the camera HAL, the <code>camera_module_t</code> struct
+ contains a <code>hw_module_t</code> struct along with other camera-specific function pointers:
+</p>
+
+<pre>
+typedef struct camera_module {
+ hw_module_t common;
+ int (*get_number_of_cameras)(void);
+ int (*get_camera_info)(int camera_id, struct camera_info *info);
+} camera_module_t;
+</pre>
+
+<p>When you implement a HAL and create the module struct, you must name it
+ <code>HAL_MODULE_INFO_SYM</code>. For instance, here is an example from the Galaxy Nexus audio HAL:</p>
+<pre>
+struct audio_module HAL_MODULE_INFO_SYM = {
+ .common = {
+ .tag = HARDWARE_MODULE_TAG,
+ .module_api_version = AUDIO_MODULE_API_VERSION_0_1,
+ .hal_api_version = HARDWARE_HAL_API_VERSION,
+ .id = AUDIO_HARDWARE_MODULE_ID,
+ .name = "Tuna audio HW HAL",
+ .author = "The Android Open Source Project",
+ .methods = &hal_module_methods,
+ },
+};
+</pre>
+<p>
+ A device abstracts the actual hardware of your product. For example, an audio module can contain
+ a primary audio device, a USB audio device, or a Bluetooth A2DP audio device. A device
+ is represented by the <code>hw_device_t</code> struct. Like a module, each type of device
+ defines a more-detailed version of the generic <code>hw_device_t</code> that contains
+ function pointers for specific features of the hardware. For example, the
+ <code>audio_hw_device_t</code> struct type contains function pointers to audio device operations:
+</p>
+
+<pre>
+struct audio_hw_device {
+ struct hw_device_t common;
+
+ /**
+ * used by audio flinger to enumerate what devices are supported by
+ * each audio_hw_device implementation.
+ *
+ * Return value is a bitmask of 1 or more values of audio_devices_t
+ */
+ uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
+ ...
+};
+typedef struct audio_hw_device audio_hw_device_t;
+</pre>
+
+<p>
+ In addition to these standard properties, each hardware-specific HAL interface can define more of its
+ own features and requirements. See the <a href="{@docRoot}guide/reference/files.html">HAL reference documentation</a>
+ as well as the individual instructions for each HAL for more information on how to implement a specific interface.
+</p>
+
+<h2 id="modules">HAL modules</h2>
+<p>HAL implementations are built into modules (<code>.so</code>) files and are dynamically linked by Android when appropriate.
+ You can build your modules by creating <code>Android.mk</code> files for each of your HAL implementations
+ and pointing to your source files. In general, your shared libraries must be named in a certain format, so that
+ they can be found and loaded properly. The naming scheme varies slightly from module to module, but they follow
+ the general pattern of: <code><module_type>.<device_name></code>.</p>
+
+ <p>For more information about setting up the build for each HAL, see its respective documentation.</p>
+
+</p>
\ No newline at end of file
diff --git a/src/devices/images/audio_hal.png b/src/devices/images/audio_hal.png
new file mode 100644
index 0000000..273ac81
--- /dev/null
+++ b/src/devices/images/audio_hal.png
Binary files differ
diff --git a/src/devices/images/bt.png b/src/devices/images/bt.png
new file mode 100644
index 0000000..d2d941a
--- /dev/null
+++ b/src/devices/images/bt.png
Binary files differ
diff --git a/src/devices/images/camera2_block.png b/src/devices/images/camera2_block.png
new file mode 100644
index 0000000..b7a58eb
--- /dev/null
+++ b/src/devices/images/camera2_block.png
Binary files differ
diff --git a/src/devices/images/camera2_hal.png b/src/devices/images/camera2_hal.png
new file mode 100644
index 0000000..28fa927
--- /dev/null
+++ b/src/devices/images/camera2_hal.png
Binary files differ
diff --git a/src/devices/images/camera_hal.png b/src/devices/images/camera_hal.png
new file mode 100644
index 0000000..48b3b69
--- /dev/null
+++ b/src/devices/images/camera_hal.png
Binary files differ
diff --git a/src/devices/images/drm_hal.png b/src/devices/images/drm_hal.png
new file mode 100644
index 0000000..ef6379b
--- /dev/null
+++ b/src/devices/images/drm_hal.png
Binary files differ
diff --git a/src/devices/images/graphics_arch.png b/src/devices/images/graphics_arch.png
new file mode 100644
index 0000000..8d1749a
--- /dev/null
+++ b/src/devices/images/graphics_arch.png
Binary files differ
diff --git a/src/devices/images/graphics_surface.png b/src/devices/images/graphics_surface.png
new file mode 100644
index 0000000..e32792d
--- /dev/null
+++ b/src/devices/images/graphics_surface.png
Binary files differ
diff --git a/src/devices/images/ihv_req.png b/src/devices/images/ihv_req.png
new file mode 100644
index 0000000..5191568
--- /dev/null
+++ b/src/devices/images/ihv_req.png
Binary files differ
diff --git a/src/devices/images/media.png b/src/devices/images/media.png
new file mode 100644
index 0000000..7aaee93
--- /dev/null
+++ b/src/devices/images/media.png
Binary files differ
diff --git a/src/devices/images/overview.png b/src/devices/images/overview.png
new file mode 100644
index 0000000..3e54d1a
--- /dev/null
+++ b/src/devices/images/overview.png
Binary files differ
diff --git a/src/devices/images/system-architecture.png b/src/devices/images/system-architecture.png
new file mode 100644
index 0000000..bbddec9
--- /dev/null
+++ b/src/devices/images/system-architecture.png
Binary files differ
diff --git a/src/devices/images/system_architecture.png b/src/devices/images/system_architecture.png
new file mode 100644
index 0000000..3e54d1a
--- /dev/null
+++ b/src/devices/images/system_architecture.png
Binary files differ
diff --git a/src/devices/index.jd b/src/devices/index.jd
new file mode 100644
index 0000000..a54d339
--- /dev/null
+++ b/src/devices/index.jd
@@ -0,0 +1,98 @@
+page.title=Porting Android to Devices
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+ <p>Android provides you with the freedom to implement your own device specifications
+ and the drivers to support them. The hardware abstraction layer (HAL) gives you a
+ standard way to create software hooks in between the Android
+ platform stack and your hardware. In addition, the Android operating system
+ is open-sourced to help you through your device's bringup.</p>
+
+ <p>To ensure that your devices maintain a high level of quality and offers a consistent
+ experience for your users, they must must also
+ pass the tests in the compatibility test suite (CTS). CTS ensures that anyone
+ building a device meets a quality standard that ensures apps run reliabaly well
+ and gives users a good experience. For more information, see the
+ <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p>
+
+ <h2>Android Low-Level System Architecture</h2>
+
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree. The following diagram shows a system
+level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
+</p>
\ No newline at end of file
diff --git a/src/devices/media.jd b/src/devices/media.jd
new file mode 100644
index 0000000..eed62c9
--- /dev/null
+++ b/src/devices/media.jd
@@ -0,0 +1,114 @@
+page.title=Media
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ Android provides a media playback engine at the native level called Stagefright that comes built-in with
+ software-based codecs for several popular media formats. Stagefright features for audio and video playback
+ include integration with OpenMAX codecs, session management, time-synchronized rendering, transport control,
+ and DRM. In addition, Stagefright supports integration with custom hardware codecs that you provide.
+ There actually isn't a HAL to implement for custom codecs, but to provide a hardware path to encode and
+ decode media, you must implement your hardware-based codec as an OpenMax IL (Integration Layer) component.
+</p>
+<h2 id="overview">
+Overview
+</h2>
+<p>The following diagram shows how media applications interact with the Android native multimedia framework.</p>
+<p>
+ <img src="images/media.png">
+</p>
+<dl>
+<dt>Application Framework</dt>
+ <dd>At the application framework level is the app's code, which utilizes the
+ <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a>
+ APIs to interact with the multimedia hardware.</dd>
+ <dt>Binder IPC</dt>
+ <dd>The Binder IPC proxies facilitate communication over process boundaries. They are located in
+ the <code>frameworks/av/media/libmedia</code> directory and begin with the letter "I".</dd>
+ <dt>Native Multimedia Framework</dt>
+ <dd>At the native level, Android provides a multimedia framework that utilizes the Stagefright engine for
+ audio and video recording and playback. Stagefright comes with a default list of supported software codecs
+ and you can implement your own hardware codec by using the OpenMax integration layer standard. For more
+ implementation details, see the various MediaPlayer and Stagefright components located in
+ <code>frameworks/av/media</code>.
+ </dd>
+ <dt>OpenMAX Integration Layer (IL)</dt>
+ <dd>The OpenMAX IL provides a standardized way for Stagefright to recognize and use custom hardware-based
+ multimedia codecs called components. You must provide an OpenMAX plugin in the form of a shared library
+ named <code>libstagefrighthw.so</code>. This plugin links your custom codec components to Stagefright.
+ Your custom codecs must be implemented according to the OpenMAX IL component standard.
+ </dd>
+</dl>
+
+
+<h2 id="codecs">
+Implementing Custom Codecs
+</h2>
+<p>Stagefright comes with built-in software codecs for common media formats, but you can also add your
+ own custom hardware codecs as OpenMAX components. To do this, you need to create OMX components and also an
+ OMX plugin that hooks together your custom codecs with the Stagefright framework. For an example, see
+ the <code>hardware/ti/omap4xxx/domx/</code> for example components and <code>hardware/ti/omap4xx/libstagefrighthw</code>
+ for an example plugin for the Galaxy Nexus.
+</p>
+ <p>To add your own codecs:</p>
+<ol>
+<li>Create your components according to the OpenMAX IL component standard. The component interface is located in the
+ <code>frameworks/native/include/media/OpenMAX/OMX_Component.h</code> file. To learn more about the
+ OpenMAX IL specification, see the <a href="http://www.khronos.org/openmax/">OpenMAX website</a>.</li>
+<li>Create a OpenMAX plugin that links your components with the Stagefright service.
+ See the <code>frameworks/native/include/media/hardware/OMXPluginBase.h</code> and <code>HardwareAPI.h</code> header
+ files for the interfaces to create the plugin.
+</li>
+<li>Build your plugin as a shared library with the name <code>libstagefrighthw.so</code> in your product Makefile. For example:
+<pre>LOCAL_MODULE := libstagefrighthw</pre>
+
+<p>In your device's Makefile, ensure that you declare the module as a product package:</p>
+<pre>
+PRODUCT_PACKAGES += \
+ libstagefrighthw \
+ ...
+</pre>
+</li>
+</ol>
+
+<h2 id="expose">Exposing Codecs to the Framework</h2>
+<p>The Stagefright service parses the <code>system/etc/media_codecs.xml</code> and <code>system/etc/media_profiles.xml</code>
+ to expose the supported codecs and profiles on the device to app developers via the <code>android.media.MediaCodecList</code> and
+ <code>android.media.CamcorderProfile</code> classes. You need to create both files in the
+ <code>device/<company_name>/<device_name>/</code> directory
+ and copy this over to the system image's <code>system/etc</code> directory in your device's Makefile.
+ For example:</p>
+
+ <pre>
+PRODUCT_COPY_FILES += \
+ device/samsung/tuna/media_profiles.xml:system/etc/media_profiles.xml \
+ device/samsung/tuna/media_codecs.xml:system/etc/media_codecs.xml \
+</pre>
+
+<p>See the <code>device/samsung/tuna/media_codecs.xml</code> and
+ <code>device/samsung/tuna/media_profiles.xml</code> file for complete examples.</p>
+
+<p class="note"><strong>Note:</strong> The <code><Quirk></code> element for media codecs is no longer supported
+ by Android starting in Jelly Bean.</p>
\ No newline at end of file
diff --git a/src/devices/native-memory.jd b/src/devices/native-memory.jd
new file mode 100644
index 0000000..d3beed7
--- /dev/null
+++ b/src/devices/native-memory.jd
@@ -0,0 +1,37 @@
+page.title=Debugging Native Memory Use
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>This tip assume that you are working with an eng
+or userdebug build of the platform, not on a production device.</p>
+<p>Android's native memory allocator has some useful debugging features. You
+can turn on memory tracking with:</p>
+<pre><code> $ adb shell setprop libc.debug.malloc 1
+ $ adb shell stop
+ $ adb shell start
+</code></pre>
+<p>You need to restart the runtime so that zygote and all processes launched from
+it are restarted with the property set. Now all Dalvik processes have memory
+tracking turned on. You can look at these with DDMS, but first you need to
+turn on its native memory UI:</p>
+<ul>
+<li>Open ~/.android/ddms.cfg</li>
+<li>Add a line "native=true"</li>
+</ul>
+<p>Upon relaunching DDMS and selecting a process, you can switch to the new
+native allocation tab and populate it with a list of allocations. This is
+especially useful for debugging memory leaks.</p>
diff --git a/src/devices/overview.jd b/src/devices/overview.jd
new file mode 100644
index 0000000..ddb34b9
--- /dev/null
+++ b/src/devices/overview.jd
@@ -0,0 +1,198 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>
+ In this document
+ </h2>
+ <ol>
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android Platform Development Kit (PDK) Guide! The Android PDK allows partners to port
+ their drivers as well as develop, optimize, and test against an upcoming Android platform release.
+ The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL),
+ platform sources for integration, a binary system image, and HAL and integration documentation.
+ In addition, the PDK also ships with the Android Compatibility Test Suite (CTS).
+</p>
+
+<h2 id="arch">Android Low-Level System Architecture</h2>
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree as well as the PDK.
+The following diagram shows a system level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="http://source.android.com/source/building-kernels.html" >Building Kernels</a>.
+</p>
+
+
+<h2 id="pdk">PDK Components</h2>
+<p>Now that you have a high-level overview of the Android system, we'll go over the PDK and what it provides
+ to port Android to your product. The PDK provides source files needed to implement
+ your product and a platform binary that lets you build a runnable system image. You can then install
+ this barebones image to test your product with the latest builds of Android. The most important source files
+ included in the PDK are located in the:</p>
+
+ <ul>
+ <li><code>frameworks/native</code> directory</li>
+ <li><code>frameworks/av</code> directory for media, camera, DRM, and the audio framework stack</code></li>
+ <li><code>hardware/libhardware/include/hardware</code> directory for the HAL interfaces </li>
+ <li><code>vendor/pdk/data/cts</code> directory for the CTS binaries</li>
+ </ul>
+</p>
+<p>In addition, the Android PDK includes the following source directories:</p>
+<ul>
+ <li>abi</li>
+ <li>bionic</li>
+ <li>bootable</li>
+ <li>build</li>
+ <li>device</li>
+ <li>external (Chromium and Webkit are not included)</li>
+ <li>hardware</li>
+ <li>libnativehelper</li>
+ <li>pdk</li>
+ <li>prebuilt</li>
+ <li>prebuilts</li>
+ <li>system</li>
+</ul>
+
+ <p>The PDK also contains documentation that is split into three different sections:</p>
+ <ul>
+ <li><a href="{@docRoot}guide/getting_started.html">Getting Started</a> - Explains how to download the PDK source, how the Android build system works, and how to configure a build for your specific product.</li>
+ <li><a href="{@docRoot}guide/hal.html">The Hardware Abstraction Layer</a> - Explains the various HALs provided by Android and the interfaces (C header files) that define them. </li>
+ <li><a href="{@docRoot}guide/reference/files.html">HAL reference</a> - A quick reference for the various HAL interfaces.</li>
+ </ul>
+
+<h3 id="cts">Compatibility Test Suite</h3>
+<p>CTS binaries for ARM, MIPS, and x86 are provided in the corresponding directories in <code>vendor/pdk/data/cts</code>. Only the ARM
+ variant is Google-verified as there is no Nexus device running on any other architecture. Not all of the CTS tests since the
+ complete Android platform is not present. The following CTS tests should work:</p>
+
+<ul>
+ <li>android.bluetooth</li>
+ <li>android.graphics</li>
+ <li>android.graphics2</li>
+ <li>android.hardware</li>
+ <li>android.location</li>
+ <li>android.opengl</li>
+ <li>android.openglperf</li>
+ <li>android.media</li>
+ <li>android.mediastress</li>
+ <li>android.nativemedia.sl</li>
+ <li>android.nativemedia.xa</li>
+ <li>android.net</li>
+ <li>android.renderscript</li>
+ </ul>
+ <p>You can run individual packages such as <code>android.media</code> with:</p>
+ <pre>cts-tradefed run singleCommand cts --skip-device-info --package android.media</pre>
+</ul>
+
+ <p>Because the PDK is missing many components compared to a full Android source tree,
+ there is a PDK test plan that is provided with CTS that limits the tests that are ran when using the PDK. You can run
+ this special test plan with the following command:</p>
+
+ <pre>run cts --plan PDK</pre>
+
+<p>CTS is always actively under development, so we expect some tests to fail. CTS results
+ for the Galaxy Nexus are provided for you in the
+ the <code>vendor/pdk/data/cts/</code> directory and will show which tests fail on that
+ device. You can safely ignore the failed tests for your devices as well.</p>
+
+ <p>See the <a href="http://source.android.com/compatibility/cts-intro.html">CTS manual</a> for more information on CTS.</p>
+
+<h2 id="inc-ex">PDK Inclusions and Exclusions</h2>
+<p>The PDK is a subset of the complete Android source tree and might be missing things that you might need. Here is a list of what the PDK supports
+ and does not support:</p>
+<ul>
+ <li>Supports building Android apps using the publicly available, standard SDK. Builds with non-public platform APIs are not supported. The JNI build is supported.</li>
+ <li>Supports only <code>en_US</code> locale.</li>
+ <li>Supports only phone layouts. Tablet layouts are not included.</li>
+ <li>Enables support for software navigation buttons by default, which you can disable by setting <code>qemu.jw.mainkeys=1</code>.</li>
+ <li>Builds all binaries with SMP (symmetric multiprocessing) features enabled. This might have a small performance impact on non-SMP CPUs.</li>
+ <li>Includes a minimal amount of Java libraries. Obtain any additional Java libraries from the publicly released Android source tree.</li>
+ <li>Contains a minimum number of applications. Build and install necessary applications as needed.</li>
+ <li>Does not support media streaming.</li>
+ <li>Does not include non-Latin fonts. (set by <code>MINIMAL_FONT_FOOTPRINT</code> variable in <code>BoardConfig.mk</code>).
+ An app might crash if it requires such fonts. </li>
+ <li>Does not support replacing framework resources by using the overlay mechanism.
+ This means all configurations controlled by framework resources are fixed.</li>
+ <li>Does not support NFC</li>
+ <li>Does not support DRM</li>
+</ul>
+
+<h2 id="knownissues">Support and Known Issues</h2>
+<p>
+For questions or to report issues related with the PDK, send a message to the <a href="https://groups.google.com/a/google.com/forum/?fromgroups#!forum/android-pdk-feedback">android-pdk@google.com</a> mailing list.</p>
+
+<p>The following list describes the known issues with the PDK:</p>
+<ul>
+ <li>After running the CTS (Compatibility Test Suite), <code>android.process.acore</code> crashes. This is caused by
+some missing components in PDK and does not affect the operation of CTS tests.</li>
+</p>
diff --git a/src/devices/porting.jd b/src/devices/porting.jd
new file mode 100644
index 0000000..e0b6eb8
--- /dev/null
+++ b/src/devices/porting.jd
@@ -0,0 +1,98 @@
+page.title=Porting
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+ <p>Android provides you with the freedom to implement your own device specifications
+ and the drivers to support them. The hardware abstraction layer (HAL) gives you a
+ standard way to create software hooks in between the Android
+ platform stack and your hardware. In addition, the Android operating system
+ is open-sourced to help you through your device's bringup.</p>
+
+ <p>To ensure that your devices maintain a high level of quality and offers a consistent
+ experience for your users, they must must also
+ pass the tests in the compatibility test suite (CTS). CTS ensures that anyone
+ building a device meets a quality standard that ensures apps run reliabaly well
+ and gives users a good experience. For more information, see the
+ <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p>
+
+ <h2>Android Low-Level System Architecture</h2>
+
+<p>Before you begin porting Android to your hardware, it is important to have an
+understanding of how Android works at a high level. Because your drivers and HAL code interact
+with many layers of Android code, this understanding can help you find
+your way through the many layers of code that are available to you through the AOSP
+(Android Open Source Project) source tree. The following diagram shows a system
+level view of how Android works:
+</p>
+
+<img src="images/system-architecture.png">
+
+<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p>
+
+ <h4>Application framework</h4>
+ <p>This is the level that most application developers concern themselves with. You should be
+ aware of the APIs available to developers as many of them map 1:1 to the underlying HAL
+ interfaces and can provide information as to how to implement your driver.
+ </p>
+
+ <h4>Binder IPC</h4>
+ <p>
+ The Binder Inter-Process Communication mechanism allows the application framework to
+ cross process boundaries and call into the Android system services code. This basically allows
+ high level framework APIs to interact with Android's system services. At the application framework level, all
+ of this communication is hidden from the developer and things appear to "just work."
+ </p>
+
+ <h4>System services</h4>
+ <p>Most of the functionality exposed through the application framework APIs must
+ communicate with some sort of system service to access the underlying hardware. Services
+ are divided into modular components with focused functionality
+ such as the Window Manager, Search Service, or Notification Manager. System services are grouped
+ into two buckets: system and media. The system services include things such as the Window or
+ Notification Manager. The media services include all the services involved in playing and
+ recording media.
+ </p>
+
+<h4>Hardware abstraction layer (HAL)</h4>
+<p>The HAL serves as a standard interface that allows the Android system to call into the device
+ driver layer while being agnostic about the lower-level implementations of your drivers and hardware.
+ You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product
+ provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so
+ you have free reign to do what is best for your situation. However, you must abide by the contract
+ defined in each hardware-specific HAL interface for the Android system to be able
+ to correctly interact with your hardware. HAL implementations are typically built into
+ shared library modules (<code>.so</code> files).
+</p>
+<h4>Linux Kernel</h4>
+<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver.
+ Android uses a specialized version of the Linux kernel with a few special additions such as
+ wakelocks, a memory management system that is more agressive in preserving memory,
+ the Binder IPC driver, and other features that are important for a mobile embedded platform like Android.
+ These additions have less to do with driver development than with the system's functionality. The PDK
+ does not provide kernel sources, so you must provide your own. You can use any version of the kernel that
+ you want as long as it supports the required features, such as the binder driver. However, we recommend
+ using the latest version of the Android kernel. For the latest Android kernel, see
+ <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>.
+</p>
\ No newline at end of file
diff --git a/src/devices/source.jd b/src/devices/source.jd
new file mode 100644
index 0000000..0b9bc7a
--- /dev/null
+++ b/src/devices/source.jd
@@ -0,0 +1,72 @@
+page.title=Getting the Source
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>
+ Before you can use the PDK, ensure that your <a href="{@docRoot}source/initializing.html">build environment
+ is set up</a>. When you are done, follow these steps to obtain the Android PDK source:
+</p>
+<ol>
+ <li>
+ <a href=
+ "https://accounts.google.com/SignUp?continue=https%3A%2F%2Faccounts.google.com%2FManageAccount">
+ Create a Google Account</a> with a corporate email address (e.g. @htc.com or @motorola.com and
+ not @gmail.com) for each individual who needs access to the partner source server. This should
+ be a relatively small number of users.
+ </li>
+ <li>Sign into the <a href="https://partner-android-review.googlesource.com">Android Gerrit
+ server</a> with the Google Account you just created and go to <strong>Settings > HTTP Password
+ > Obtain Password</strong> to get a password that you can use to authenticate to the Android
+ source servers. Follow the directions on that page for more information.
+ </li>
+ <li>Send a list of the Google Accounts that were created to Google to add them to our access
+ list.
+ </li>
+ <li>There are four variants of the source that you can sync to. For armv7a, run the following commands:
+<pre>
+repo init -u https://partner-android.googlesource.com/platform/vendor/pdk/mini_armv7a_neon/mini_armv7a_neon-userdebug/manifest.git -b <branch_name>
+repo sync
+</pre>
+<p>For armv7a with NEON support, run the following commands:</p>
+<pre>
+repo init -u https://partner-android.googlesource.com/platform/vendor/pdk/mini_armv7a/mini_armv7a-userdebug/manifest.git -b <branch_name>
+repo sync
+</pre>
+<p>For MIPS, run the following commands:</p>
+<pre>
+repo init -u https://partner-android.googlesource.com/a/platform/vendor/pdk/mini_mips/mini_mips-userdebug/manifest.git -b <branch_name>
+repo sync
+</pre>
+<p>For x86, run the following commands:</p>
+<pre>
+repo init -u https://partner-android.googlesource.com/a/platform/vendor/pdk/mini_x86/mini_x86-userdebug/manifest.git -b <branch_name>
+repo sync
+</pre>
+
+<p>For example, use the <code>jb-mr1-release</code> branch for the PDK release for Jelly Bean MR1.</p>
+</li>
+</ol>
+
+
+<p class="note"><strong>Note:</strong> The PDK repository might be updated many times a day,
+ so it might be a good idea to sync less often if bandwidth is a concern.
+ It is usually more beneficial to sync more frequently at the early development phases of a new platform release
+ as more drastic changes can happen. Additionally, any PDK repository update results in an
+ updated <code>manifest.xml</code> so if you manually change the <code>manifest.xml</code>
+to add your own projects, this blocks syncing of the repository.
+A solution to both these issues is to have a local repository set up that syncs with the PDK
+ repository and then have your developers sync with your local repository and not the main PDK one.</p>
\ No newline at end of file
diff --git a/src/tech/dalvik/dalvik-bytecode.css b/src/devices/tech/dalvik/dalvik-bytecode.css
similarity index 100%
rename from src/tech/dalvik/dalvik-bytecode.css
rename to src/devices/tech/dalvik/dalvik-bytecode.css
diff --git a/src/tech/dalvik/dalvik-bytecode.html b/src/devices/tech/dalvik/dalvik-bytecode.jd
similarity index 97%
rename from src/tech/dalvik/dalvik-bytecode.html
rename to src/devices/tech/dalvik/dalvik-bytecode.jd
index e848d9e..7883850 100644
--- a/src/tech/dalvik/dalvik-bytecode.html
+++ b/src/devices/tech/dalvik/dalvik-bytecode.jd
@@ -1,15 +1,21 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+page.title=Bytecode for the Dalvik VM
+@jd:body
-<html>
+<!--
+ Copyright 2010 The Android Open Source Project
-<head>
-<title>Bytecode for the Dalvik VM</title>
-<link rel=stylesheet href="dalvik-bytecode.css">
-</head>
+ 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
-<body>
+ http://www.apache.org/licenses/LICENSE-2.0
-<h1>Bytecode for the Dalvik VM</h1>
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
<p>Copyright © 2007 The Android Open Source Project
<h2>General Design</h2>
@@ -1545,7 +1551,4 @@
</td>
</tr>
</tbody>
-</table>
-
-</body>
-</html>
+</table>
\ No newline at end of file
diff --git a/src/tech/dalvik/dex-format.css b/src/devices/tech/dalvik/dex-format.css
similarity index 100%
rename from src/tech/dalvik/dex-format.css
rename to src/devices/tech/dalvik/dex-format.css
diff --git a/src/tech/dalvik/dex-format.html b/src/devices/tech/dalvik/dex-format.jd
similarity index 98%
rename from src/tech/dalvik/dex-format.html
rename to src/devices/tech/dalvik/dex-format.jd
index 81c0b36..6128b9b 100644
--- a/src/tech/dalvik/dex-format.html
+++ b/src/devices/tech/dalvik/dex-format.jd
@@ -1,15 +1,21 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+page.title=Dalvik Executable Format
+@jd:body
-<html>
+<!--
+ Copyright 2010 The Android Open Source Project
-<head>
-<title>.dex — Dalvik Executable Format</title>
-<link rel=stylesheet href="dex-format.css">
-</head>
+ 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
-<body>
+ http://www.apache.org/licenses/LICENSE-2.0
-<h1 class="title"><code>.dex</code> — Dalvik Executable Format</h1>
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
<p>Copyright © 2007 The Android Open Source Project
<p>This document describes the layout and contents of <code>.dex</code>
@@ -3044,6 +3050,3 @@
</tr>
</tbody>
</table>
-
-</body>
-</html>
diff --git a/src/devices/tech/dalvik/index.jd b/src/devices/tech/dalvik/index.jd
new file mode 100644
index 0000000..ed36231
--- /dev/null
+++ b/src/devices/tech/dalvik/index.jd
@@ -0,0 +1,25 @@
+page.title=Dalvik Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Dalvik is the managed runtime used by applications and some system
+services on Android. Dalvik was originally created specifically for
+the Android project.</p>
+<p>Much of the documentation in this directory is intended to help
+with the ongoing development of Dalvik, as opposed to most of the
+other documentation on this site, which is geared more towards
+application development.</p>
\ No newline at end of file
diff --git a/src/tech/dalvik/instruction-formats.css b/src/devices/tech/dalvik/instruction-formats.css
similarity index 100%
rename from src/tech/dalvik/instruction-formats.css
rename to src/devices/tech/dalvik/instruction-formats.css
diff --git a/src/tech/dalvik/instruction-formats.html b/src/devices/tech/dalvik/instruction-formats.jd
similarity index 94%
rename from src/tech/dalvik/instruction-formats.html
rename to src/devices/tech/dalvik/instruction-formats.jd
index f81b595..37a7438 100644
--- a/src/tech/dalvik/instruction-formats.html
+++ b/src/devices/tech/dalvik/instruction-formats.jd
@@ -1,15 +1,21 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+page.title=Dalvik VM Instruction Formats
+@jd:body
-<html>
+<!--
+ Copyright 2010 The Android Open Source Project
-<head>
-<title>Dalvik VM Instruction Formats</title>
-<link rel=stylesheet href="instruction-formats.css">
-</head>
+ 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
-<body>
+ http://www.apache.org/licenses/LICENSE-2.0
-<h1>Dalvik VM Instruction Formats</h1>
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
<p>Copyright © 2007 The Android Open Source Project
<h2>Introduction and Overview</h2>
@@ -455,7 +461,4 @@
<td>const-wide</td>
</tr>
</tbody>
-</table>
-
-</body>
-</html>
+</table>
\ No newline at end of file
diff --git a/src/devices/tech/datausage/excluding-network-types.jd b/src/devices/tech/datausage/excluding-network-types.jd
new file mode 100644
index 0000000..528b402
--- /dev/null
+++ b/src/devices/tech/datausage/excluding-network-types.jd
@@ -0,0 +1,30 @@
+page.title=Excluding Network Types from Usage Data
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>A mobile operator may wish to exclude specific network types from the
+total data usage calculated by a device. For example, network traffic
+over an MMS APN may be “zero-rated” by a mobile operator. To support
+this, the set of network types used to calculate total data usage can
+be configured through the <code>config_data_usage_network_types</code> resource
+at build time.</p>
+<p>Some mobile radio implementations may have unique Linux network
+interfaces for each active APN, while other radios may force multiple
+APNs to coexist on a single interface. Android can collect network
+statistics from both designs, but <code>config_data_usage_network_types</code> is
+not be effective at excluding APNs forced to coexist on a single
+interface.</p>
\ No newline at end of file
diff --git a/src/devices/tech/datausage/iface-overview.jd b/src/devices/tech/datausage/iface-overview.jd
new file mode 100644
index 0000000..7608aa8
--- /dev/null
+++ b/src/devices/tech/datausage/iface-overview.jd
@@ -0,0 +1,47 @@
+page.title=Network Interface Statistics Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>In Android 4.0, statistics reported by Linux network interfaces are
+recorded over time, and are used to enforce network quota limits,
+render user-visible charts, and more.</p>
+<p>Each network device driver (Wi-Fi included) must follow the standard
+kernel device lifecycle, and return correct statistics through
+<code>dev_get_stats()</code>. In particular, statistics returned must remain
+strictly monotonic while the interface is active. Drivers may reset
+statistics only after successfully completing an <code>unregister_netdev()</code>
+or the equivalent that generates a <code>NETDEV_UNREGISTER</code> event for
+callbacks registered with <code>register_netdevice_notifier()</code> /
+<code>register_inetaddr_notifier()</code> / <code>register_inet6addr_notifier()</code>.</p>
+<p>Mobile operators typically measure data usage at the Internet layer
+(IP). To match this approach in Android 4.0, we rely on the fact that
+for the kernel devices we care about the <code>rx_bytes</code> and <code>tx_bytes</code>
+values returned by <code>dev_get_stats()</code> return exactly the Internet layer
+(<code>IP</code>) bytes transferred. But we understand that for other devices it
+might not be the case. For now, the feature relies on this
+peculiarity. New drivers should have that property also, and the
+<code>dev_get_stats()</code> values must not include any encapsulation overhead
+of lower network layers (such as Ethernet headers), and should
+preferably not include other traffic (such as ARP) unless it is
+negligible.</p>
+<p>The Android framework only collects statistics from network interfaces
+associated with a <code>NetworkStateTracker</code> in <code>ConnectivityService</code>. This
+enables the framework to concretely identify each network interface,
+including its type (such as <code>TYPE_MOBILE</code> or <code>TYPE_WIFI</code>) and
+subscriber identity (such as IMSI). All network interfaces used to
+route data should be represented by a <code>NetworkStateTracker</code> so that
+statistics can be accounted correctly.</p>
diff --git a/src/devices/tech/datausage/index.jd b/src/devices/tech/datausage/index.jd
new file mode 100644
index 0000000..adce77c
--- /dev/null
+++ b/src/devices/tech/datausage/index.jd
@@ -0,0 +1,33 @@
+page.title=Data Usage Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Android 4.0 (Ice Cream Sandwich) introduces new features that help
+users understand and control how their device uses network data. It
+monitors overall data usage, and supports warning or limit thresholds
+which will trigger notifications or disable mobile data when usage
+exceeds a specific quota.</p>
+<p>Data usage is also tracked on a per-application basis, enabling users
+to visually explore historical usage in the Settings app. Users can
+also restrict how specific applications are allowed to use data when
+running in the background.</p>
+<p>The documentation in this section is intended for systems integrators
+and mobile operators, to help explain technical details they should be
+aware of when porting Android to specific devices. These details are
+summarized below, and the
+<a href="mailto:android-porting+subscribe@googlegroups.com">android-porting</a>
+mailing list is a good place for further discussion.</p>
diff --git a/src/devices/tech/datausage/kernel-changes.jd b/src/devices/tech/datausage/kernel-changes.jd
new file mode 100644
index 0000000..98624ed
--- /dev/null
+++ b/src/devices/tech/datausage/kernel-changes.jd
@@ -0,0 +1,32 @@
+page.title=Kernel Changes
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>This is a summary of the main changes in the kernel that diverge from mainline.</p>
+<ul>
+<li>added net/netfilter/xt_qtaguid*</li>
+<li>imported then modified net/netfilter/xt_quota2.c from xtables-addons project</li>
+<li>fixes in net/netfilter/ip6_tables.c</li>
+<li>modified ip*t_REJECT.c</li>
+<li>modified net/netfilter/xt_socket.c</li>
+</ul>
+<p>A few comments on the kernel configuration:</p>
+<ul>
+<li>xt_qtaguid masquerades as xt_owner and relies on xt_socket and itself relies on the connection tracker.</li>
+<li>The connection tracker can't handle large SIP packets, it must be disabled.</li>
+<li>The modified xt_quota2 uses the NFLOG support to notify userspace.</li>
+</ul>
diff --git a/src/devices/tech/datausage/kernel-overview.jd b/src/devices/tech/datausage/kernel-overview.jd
new file mode 100644
index 0000000..7d4248b
--- /dev/null
+++ b/src/devices/tech/datausage/kernel-overview.jd
@@ -0,0 +1,51 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The per-application/delegated data usage monitoring and tracking
+functionality relies on the xt_qtaguid module in the android-3.0 Linux
+kernel (<code>kernel/net/netfilter/xt_qtaguid</code>). The socket tagging
+functionality in the framework (<code>system/core/libcutils/qtaguid.c</code>)
+relies mainly on the existence of <code>/proc/net/xt_qtaguid/ctrl</code>
+interface exported by the <code>xt_qtaguid</code> kernel module.</p>
+<p>The <code>quota2</code> netfilter module (originally part of <code>xtables-addons</code>)
+allows the functionality to set named quota limits and was extended to
+support notifying userspace when certain limits are reached. Once the
+quota limit is reached, the <code>quota2</code> module discards all subsequent
+network traffic. The framework can also specify additional rules to
+restrict background data traffic for an application (refer to
+<code>com.android.server.NetworkManagementSocketTagger.setKernelCounterSet</code>
+and
+<code>android.net.NetworkPolicyManager.POLICY_REJECT_METERED_BACKGROUND</code>).</p>
+<h1 id="how-does-it-work">How does it work?</h1>
+<p>The <code>qtaguid</code> netfilter module tracks the network traffic on a
+per-socket basis for every application using the unique UID of the
+owning application. There are two tag components associated with any
+socket in the system. The first is the UID which uniquely identifies
+the application which is responsible for the data transfer (Linux
+allows the ability to ascribe the ownership of each network socket to
+the UID of the calling application). The second tag component is used
+to support additional characterization of the traffic into application
+developer specified categories. Using these application level tags, an
+application can profile the traffic into several sub-categories.</p>
+<p>In the case of applications that provide network data transfer as a
+service, such as the download manager, media streaming service, etc,
+it is possible to attribute the ownership of the network data transfer
+to the UID of the requesting application using the
+<code>TrafficStats.setThreadStatsUid()</code> function call. The caller must hold
+the “<code>android.permission.MODIFY_NETWORK_ACCOUNTING</code>” permission to
+re-assign the ownership of the network traffic.</p>
diff --git a/src/devices/tech/datausage/tags-explained.jd b/src/devices/tech/datausage/tags-explained.jd
new file mode 100644
index 0000000..bacd395
--- /dev/null
+++ b/src/devices/tech/datausage/tags-explained.jd
@@ -0,0 +1,45 @@
+page.title=Data Usage Tags Explained
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Tags represent one of the metrics the data usage counters will be
+tracked against. By default, and implicitly, a tag is just based on
+the UID. The UID is used as the base for policing, and cannot be
+ignored. So a tag will always at least represent a UID (uid_tag). A
+tag can be explicitly augmented with an "accounting tag" which is
+associated with a UID. User space can use
+<code>TrafficStats.setThreadStatsTag()</code> to set the acct_tag portion of the
+tag which is then used with sockets: all data belonging to that
+socket will be counted against the tag. The policing is then based on
+the tag's uid_tag portion, and stats are collected for the acct_tag
+portion separately.</p>
+<p>Without explicit tagging, the qtaguid module will assume the
+<code>default_tag: {acct_tag=0, uid_tag=10003}</code></p>
+<pre><code> a: {acct_tag=1, uid_tag=10003}
+ b: {acct_tag=2, uid_tag=10003}
+ c: {acct_tag=3, uid_tag=10003}
+</code></pre>
+<p><code>a, b, c…</code> represent explicit tags associated with specific sockets.</p>
+<p><code>default_tag (acct_tag=0)</code> is the default accounting tag that contains
+the total traffic for that uid, including all untagged
+traffic, and is typically used to enforce policing/quota rules.</p>
+<p>These tags can be used to profile the network traffic of an
+application into separate logical categories (at a network socket
+level). Such tags can be removed, reapplied, or modified during
+runtime.</p>
+<p>The qtaguid module has been implemented on <a href="https://android-review.googlesource.com/#/q/project:kernel/common+branch:android-3.0,n,z">kernel/common branch of
+android-3.0</a></p>
\ No newline at end of file
diff --git a/src/devices/tech/datausage/tethering-data.jd b/src/devices/tech/datausage/tethering-data.jd
new file mode 100644
index 0000000..62d1733
--- /dev/null
+++ b/src/devices/tech/datausage/tethering-data.jd
@@ -0,0 +1,22 @@
+page.title=Tethering data
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Tethering involves forwarding of traffic from one network interface to
+another using <code>iptables</code> forwarding rules. The framework periodically
+records tethering statistics between any interface pairs returned by
+<code>ConnectivityService.getTetheredIfacePairs()</code>.</p>
diff --git a/src/devices/tech/datausage/usage-cycle-resets-dates.jd b/src/devices/tech/datausage/usage-cycle-resets-dates.jd
new file mode 100644
index 0000000..f9bddbd
--- /dev/null
+++ b/src/devices/tech/datausage/usage-cycle-resets-dates.jd
@@ -0,0 +1,24 @@
+page.title=Usage Cycle Reset Dates
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Users can specify a day of month upon which their data usage
+resets. Internally, cycle boundaries are defined to end at midnight
+<code>(00:00) UTC</code> on the requested day. When a month is shorter than the
+requested day, the cycle resets on the first day of the subsequent
+month. For example, a cycle reset day of the 30th would cause a reset
+on January 30 at <code>00:00 UTC</code> and March 1 at <code>00:00 UTC</code>.</p>
\ No newline at end of file
diff --git a/src/devices/tech/encryption/android_crypto_implementation.jd b/src/devices/tech/encryption/android_crypto_implementation.jd
new file mode 100644
index 0000000..c81c4f5
--- /dev/null
+++ b/src/devices/tech/encryption/android_crypto_implementation.jd
@@ -0,0 +1,350 @@
+page.title=Notes on the implementation of encryption in Android 3.0
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<h2 id="quick-summary-for-3rd-parties">Quick summary for 3rd parties.</h2>
+<p>If you want to enable encryption on your device based on Android 3.0
+aka Honeycomb, there are only a few requirements:</p>
+<ol>
+<li>
+<p>The /data filesystem must be on a device that presents a block device
+ interface. eMMC is used in the first devices. This is because the
+ encryption is done by the dm-crypt layer in the kernel, which works
+ at the block device layer.</p>
+</li>
+<li>
+<p>The function get_fs_size() in system/vold/cryptfs.c assumes the filesystem
+ used for /data is ext4. It's just error checking code to make sure the
+ filesystem doesn't extend into the last 16 Kbytes of the partition where
+ the crypto footer is kept. It was useful for development when sizes were
+ changing, but should not be required for release. If you are not using
+ ext4, you can either delete it and the call to it, or fix it to understand
+ the filesystem you are using.</p>
+</li>
+<li>
+<p>Most of the code to handle the setup and teardown of the temporary framework
+ is in files that are not usually required to be changed on a per device
+ basis. However, the init.<device>.rc file will require some changes. All
+ services must be put in one of three classes: core, main or late_state.
+ Services in the core class are not shutdown and restarted when the
+ temporary framework gets the disk password. Services in the main class
+ are restarted when the framework is restarted. Services in late_start are
+ not started until after the temporary framework is restarted. Put services
+ here that are not required to be running while the temporary framework
+ gets the disk password.</p>
+<p>Also any directories that need to be created on /data that are device
+specific need to be in the Action for post-fs-data, and that Action must end
+with the command "setprop vold.post_fs_data_done 1". If your
+init.<device>.rc file does not have a post-fs-data Action, then the
+post-fs-data Action in the main init.rc file must end with the command
+"setprop vold.post_fs_data_done 1".</p>
+</li>
+</ol>
+<h2 id="how-android-encryption-works">How Android encryption works</h2>
+<p>Disk encryption on Android is based on dm-crypt, which is a kernel feature that
+works at the block device layer. Therefore, it is not usable with YAFFS, which
+talks directly to a raw nand flash chip, but does work with emmc and similar
+flash devices which present themselves to the kernel as a block device. The
+current preferred filesystem to use on these devices is ext4, though that is
+independent of whether encryption is used or not.</p>
+<p>While the actual encryption work is a standard linux kernel feature, enabling it
+on an Android device proved somewhat tricky. The Android system tries to avoid
+incorporating GPL components, so using the cryptsetup command or libdevmapper
+were not available options. So making the appropriate ioctl(2) calls into the
+kernel was the best choice. The Android volume daemon (vold) already did this
+to support moving apps to the SD card, so I chose to leverage that work
+for whole disk encryption. The actual encryption used for the filesystem for
+first release is 128 AES with CBC and ESSIV:SHA256. The master key is
+encrypted with 128 bit AES via calls to the openssl library.</p>
+<p>Once it was decided to put the smarts in vold, it became obvious that invoking
+the encryption features would be done like invoking other vold commands, by
+adding a new module to vold (called cryptfs) and teaching it various commands.
+The commands are checkpw, restart, enablecrypto, changepw and cryptocomplete.
+They will be described in more detail below.</p>
+<p>The other big issue was how to get the password from the user on boot. The
+initial plan was to implement a minimal UI that could be invoked from init
+in the initial ramdisk, and then init would decrypt and mount /data. However,
+the UI engineer said that was a lot of work, and suggested instead that init
+communicate upon startup to tell the framework to pop up the password entry
+screen, get the password, and then shutdown and have the real framework started.
+It was decided to go this route, and this then led to a host of other decisions
+described below. In particular, init set a property to tell the framework to go
+into the special password entry mode, and that set the stage for much
+communication between vold, init and the framework using properties. The
+details are described below.</p>
+<p>Finally, there were problems around killing and restarting various services
+so that /data could be unmounted and remounted. Bringing up the temporary
+framework to get the user password requires that a tmpfs /data filesystem be
+mounted, otherwise the framework will not run. But to unmount the tmpfs /data
+filesystem so the real decrypted /data filesystem could be mounted meant that
+every process that had open files on the tmpfs /data filesystem had to be killed
+and restarted on the real /data filesystem. This magic was accomplished by
+requiring all services to be in 1 of 3 groups: core, main and late_start.
+Core services are never shut down after starting. main services are shutdown
+and then restarted after the disk password is entered. late_start services
+are not started until after /data has been decrypted and mounted. The magic
+to trigger these actions is by setting the property vold.decrypt to various
+magic strings, which is described below. Also, a new init command "class_reset"
+was invented to stop a service, but allow it to be restarted with a
+"class_start" command. If the command "class_stop" was used instead of the
+new command "class_reset" the flag SVC_DISABLED was added to the state of
+any service stopped, which means it would not be started when the command
+class_start was used on its class.</p>
+<h2 id="booting-an-encrypted-system">Booting an encrypted system.</h2>
+<ol>
+<li>
+<p>When init fails to mount /data, it assumes the filesystem is encrypted,
+ and sets several properties:
+ ro.crypto.state = "encrypted"
+ vold.decrypt = 1
+ It then mounts a /data on a tmpfs ramdisk, using parameters it picks
+ up from ro.crypto.tmpfs_options, which is set in init.rc.</p>
+<p>If init was able to mount /data, it sets ro.crypto.state to "unencrypted".</p>
+<p>In either case, init then sets 5 properties to save the initial mount
+options given for /data in these properties:
+ ro.crypto.fs_type
+ ro.crypto.fs_real_blkdev
+ ro.crypto.fs_mnt_point
+ ro.crypto.fs_options
+ ro.crypto.fs_flags (saved as an ascii 8 digit hex number preceded by 0x)</p>
+</li>
+<li>
+<p>The framework starts up, and sees that vold.decrypt is set to "1". This
+ tells the framework that it is booting on a tmpfs /data disk, and it needs
+ to get the user password. First, however, it needs to make sure that the
+ disk was properly encrypted. It sends the command "cryptfs cryptocomplete"
+ to vold, and vold returns 0 if encryption was completed successfully, or -1
+ on internal error, or -2 if encryption was not completed successfully.
+ Vold determines this by looking in the crypto footer for the
+ CRYPTO_ENCRYPTION_IN_PROGRESS flag. If it's set, the encryption process
+ was interrupted, and there is no usable data on the device. If vold returns
+ an error, the UI should pop up a message saying the user needs to reboot and
+ factory reset the device, and give the user a button to press to do so.</p>
+</li>
+<li>
+<p>Assuming the "cryptfs cryptocomplete" command returned success, the
+ framework should pop up a UI asking for the disk password. The UI then
+ sends the command "cryptfs checkpw <passwd>" to vold. If the password
+ is correct (which is determined by successfully mounting the decrypted
+ at a temporary location, then unmounting it), vold saves the name of the
+ decrypted block device in the property ro.crypto.fs_crypto_blkdev, and
+ returns status 0 to the UI. If the password is incorrect, it returns -1
+ to the UI.</p>
+</li>
+<li>
+<p>The UI puts up a crypto boot graphic, and then calls vold with the command
+ "cryptfs restart". vold sets the property vold.decrypt to
+ "trigger_reset_main", which causes init.rc to do "class_reset main". This
+ stops all services in the main class, which allows the tmpfs /data to be
+ unmounted. vold then mounts the decrypted real /data partition, and then
+ preps the new partition (which may never have been prepped if it was
+ encrypted with the wipe option, which is not supported on first release).
+ It sets the property vold.post_fs_data_done to "0", and then sets
+ vold.decrypt to "trigger_post_fs_dat". This causes init.rc to run the
+ post-fs-data commands in init.rc and init.<device>.rc. They will create
+ any necessary directories, links, et al, and then set vold.post_fs_data_done
+ to "1". Vold waits until it sees the "1" in that property. Finally, vold
+ sets the property vold.decrypt to "trigger_restart_framework" which causes
+ init.rc to start services in class main again, and also start services
+ in class late_start for the first time since boot.</p>
+<p>Now the framework boots all its services using the decrypted /data
+filesystem, and the system is ready for use.</p>
+</li>
+</ol>
+<h2 id="enabling-encryption-on-the-device">Enabling encryption on the device.</h2>
+<p>For first release, we only support encrypt in place, which requires the
+framework to be shutdown, /data unmounted, and then every sector of the
+device encrypted, after which the device reboots to go through the process
+described above. Here are the details:</p>
+<ol>
+<li>
+<p>From the UI, the user selects to encrypt the device. The UI ensures that
+ there is a full charge on the battery, and the AC adapter is plugged in.
+ It does this to make sure there is enough power to finish the encryption
+ process, because if the device runs out of power and shuts down before it
+ has finished encrypting, file data is left in a partially encrypted state,
+ and the device must be factory reset (and all data lost).</p>
+<p>Once the user presses the final button to encrypt the device, the UI calls
+vold with the command "cryptfs enablecrypto inplace <passwd>" where passwd
+is the user's lock screen password.</p>
+</li>
+<li>
+<p>vold does some error checking, and returns -1 if it can't encrypt, and
+ prints a reason in the log. If it thinks it can, it sets the property
+ vold.decrypt to "trigger_shutdown_framework". This causes init.rc to
+ stop services in the classes late_start and main. vold then unmounts
+ /mnt/sdcard and then /data.</p>
+</li>
+<li>
+<p>If doing an inplace encryption, vold then mounts a tmpfs /data (using the
+ tmpfs options from ro.crypto.tmpfs_options) and sets the property
+ vold.encrypt_progress to "0". It then preps the tmpfs /data filesystem as
+ mentioned in step 3 for booting an encrypted system, and then sets the
+ property vold.decrypt to "trigger_restart_min_framework". This causes
+ init.rc to start the main class of services. When the framework sees that
+ vold.encrypt_progress is set to "0", it will bring up the progress bar UI,
+ which queries that property every 5 seconds and updates a progress bar.</p>
+</li>
+<li>
+<p>vold then sets up the crypto mapping, which creates a virtual crypto block
+ device that maps onto the real block device, but encrypts each sector as it
+ is written, and decrypts each sector as it is read. vold then creates and
+ writes out the crypto footer.</p>
+<p>The crypto footer contains details on the type of encryption, and an
+encrypted copy of the master key to decrypt the filesystem. The master key
+is a 128 bit number created by reading from /dev/urandom. It is encrypted
+with a hash of the user password created with the PBKDF2 function from the
+SSL library. The footer also contains a random salt (also read from
+/dev/urandom) used to add entropy to the hash from PBKDF2, and prevent
+rainbow table attacks on the password. Also, the flag
+CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure
+to complete the encryption process. See the file cryptfs.h for details
+on the crypto footer layout. The crypto footer is kept in the last 16
+Kbytes of the partition, and the /data filesystem cannot extend into that
+part of the partition.</p>
+</li>
+<li>
+<p>If told was to enable encryption with wipe, vold invokes the command
+ "make_ext4fs" on the crypto block device, taking care to not include
+ the last 16 Kbytes of the partition in the filesystem.</p>
+<p>If the command was to enable inplace, vold starts a loop to read each sector
+of the real block device, and then write it to the crypto block device.
+This takes about an hour on a 30 Gbyte partition on the Motorola Xoom.
+This will vary on other hardware. The loop updates the property
+vold.encrypt_progress every time it encrypts another 1 percent of the
+partition. The UI checks this property every 5 seconds and updates
+the progress bar when it changes.</p>
+</li>
+<li>
+<p>When either encryption method has finished successfully, vold clears the
+ flag ENCRYPTION_IN_PROGRESS in the footer, and reboots the system.
+ If the reboot fails for some reason, vold sets the property
+ vold.encrypt_progress to "error_reboot_failed" and the UI should
+ display a message asking the user to press a button to reboot.
+ This is not expected to ever occur.</p>
+</li>
+<li>
+<p>If vold detects an error during the encryption process, and if no data has
+ been destroyed yet and the framework is up, vold sets the property
+ vold.encrypt_progress to "error_not_encrypted" and the UI should give the
+ user the option to reboot, telling them that the encryption process
+ never started. If the error occurs after the framework has been torn
+ down, but before the progress bar UI is up, vold will just reboot the
+ system. If the reboot fails, it sets vold.encrypt_progress to
+ "error_shutting_down" and returns -1, but there will not be anyone
+ to catch the error. This is not expected to happen.</p>
+<p>If vold detects an error during the encryption process, it sets
+vold.encrypt_progress to "error_partially_encrypted" and returns -1.
+The UI should then display a message saying the encryption failed, and
+provide a button for the user to factory reset the device.</p>
+</li>
+</ol>
+<h2 id="changing-the-password">Changing the password</h2>
+<p>To change the password for the disk encryption, the UI sends the command
+"cryptfs changepw <newpw>" to vold, and vold re-encrypts the disk master
+key with the new password.</p>
+<h2 id="summary-of-related-properties">Summary of related properties</h2>
+<p>Here is a table summarizing the various properties, their possible values,
+and what they mean:</p>
+<pre><code>vold.decrypt 1 Set by init to tell the UI to ask
+ for the disk pw
+
+vold.decrypt trigger_reset_main Set by vold to shutdown the UI
+ asking for the disk password
+
+vold.decrypt trigger_post_fs_data Set by vold to prep /data with
+ necessary dirs, et al.
+
+vold.decrypt trigger_restart_framework Set by vold to start the real
+ framework and all services
+
+vold.decrypt trigger_shutdown_framework Set by vold to shutdown the full
+ framework to start encryption
+
+vold.decrypt trigger_restart_min_framework Set by vold to start the progress
+ bar UI for encryption.
+
+vold.enrypt_progress When the framework starts up, if
+ this property is set, enter the
+ progress bar UI mode.
+
+vold.encrypt_progress 0 to 100 The progress bar UI should display
+ the percentage value set.
+
+vold.encrypt_progress error_partially_encrypted The progress bar UI should
+ display a message that the
+ encryption failed, and give
+ the user an option to factory
+ reset the device.
+
+vold.encrypt_progress error_reboot_failed The progress bar UI should display
+ a message saying encryption
+ completed, and give the user a
+ button to reboot the device.
+ This error is not expected to
+ happen.
+
+vold.encrypt_progress error_not_encrypted The progress bar UI should display
+ a message saying an error occured,
+ and no data was encrypted or lost,
+ and give the user a button to
+ reboot the system.
+
+vold.encrypt_progress error_shutting_down The progress bar UI is not
+ running, so it's unclear who
+ will respond to this error,
+ and it should never happen
+ anyway.
+
+vold.post_fs_data_done 0 Set by vold just before setting
+ vold.decrypt to
+ trigger_post_fs_data.
+
+vold.post_fs_data_done 1 Set by init.rc or init.<device>.rc
+ just after finishing the task
+ post-fs-data.
+
+ro.crypto.fs_crypto_blkdev Set by the vold command checkpw
+ for later use by the vold command
+ restart.
+
+ro.crypto.state unencrypted Set by init to say this system is
+ running with an unencrypted /data
+
+ro.crypto.state encrypted Set by init to say this system is
+ running with an encrypted /data
+
+ro.crypto.fs_type These 5 properties are set by init
+ro.crypto.fs_real_blkdev when it tries to mount /data with
+ro.crypto.fs_mnt_point parameters passed in from init.rc.
+ro.crypto.fs_options vold uses these to setup the
+ro.crypto.fs_flags crypto mapping.
+
+ro.crypto.tmpfs_options Set by init.rc with the options
+ init should use when mounting
+ the tmpfs /data filesystem.
+</code></pre>
+<h2 id="summary-of-new-init-actions">Summary of new init actions</h2>
+<p>A list of the new Actions that are added to init.rc and/or init.<device>.rc:</p>
+<pre><code>on post-fs-data
+on nonencrypted
+on property:vold.decrypt=trigger_reset_main
+on property:vold.decrypt=trigger_post_fs_data
+on property:vold.decrypt=trigger_restart_min_framework
+on property:vold.decrypt=trigger_restart_framework
+on property:vold.decrypt=trigger_shutdown_framework
+</code></pre>
diff --git a/src/devices/tech/encryption/index.jd b/src/devices/tech/encryption/index.jd
new file mode 100644
index 0000000..42fce0d
--- /dev/null
+++ b/src/devices/tech/encryption/index.jd
@@ -0,0 +1,21 @@
+page.title=Encryption Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Encryption on Android uses the dm-crypt layer in the Linux kernel. Read the
+detailed description of how it is tied into the Android system and what must
+be done on a new device to get this feature working.</p>
\ No newline at end of file
diff --git a/src/devices/tech/index.jd b/src/devices/tech/index.jd
new file mode 100644
index 0000000..c528210
--- /dev/null
+++ b/src/devices/tech/index.jd
@@ -0,0 +1,82 @@
+page.title=Android Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+
+<p>Welcome to the Android 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.</p>
+
+<h2 id="dalvik-technical-information">Dalvik Technical Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/dalvik/index.html">» Dalvik Information</a></p>
+<h2 id="debugging">Debugging</h2>
+<p>Android is a large and complex system. This section includes tips and tricks
+about debugging at the platform level.</p>
+<p><a href="devices/tech/debugging/index.html">» Debugging Information</a></p>
+<h2 id="encryption-technical-information">Encryption Technical Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/encryption/index.html">» Encryption Information</a></p>
+<h2 id="security-technical-information">Security Technical Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/security/index.html">» Android Security Overview</a></p>
+<h2 id="input-technical-information">Input Technical Information</h2>
+<p>Android's input subsystem is responsible for supporting touch screens,
+keyboard, joysticks, mice and other devices.</p>
+
+<p><a href="{@docRoot}devices/tech/input/index.html">» Input Information</a></p>
+<h2 id="data-usage-technical-information">Data Usage Technical Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/datausage/index.html">» Data Usage Information</a></p>
+<h2 id="accessory-protocol-information">Accessory Protocol Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/accessories/index.html">» Accessory Protocol Information</a></p>
+<h2 id="external-storage-technical-information">External Storage Technical Information</h2>
+<p>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.</p>
+
+<p><a href="{@docRoot}devices/tech/storage/index.html">» External Storage Technical Information</a></p>
diff --git a/src/devices/tech/input/dumpsys.jd b/src/devices/tech/input/dumpsys.jd
new file mode 100644
index 0000000..a37584f
--- /dev/null
+++ b/src/devices/tech/input/dumpsys.jd
@@ -0,0 +1,344 @@
+page.title=Dumpsys
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The <code>dumpsys</code> tool runs on the device and dumps interesting information
+about the status of system services.</p>
+<h2 id="usage">Usage</h2>
+<p>The input system is part of the window manager. To dump its state,
+run the following command.</p>
+<pre><code>$ adb shell su -- dumpsys window
+
+WINDOW MANAGER INPUT (dumpsys window input)
+Event Hub State:
+ BuiltInKeyboardId: -1
+ Devices:
+...
+</code></pre>
+<p>The set of information that is reported varies depending on the version of Android.</p>
+<h3 id="event-hub-state">Event Hub State</h3>
+<p>The <code>EventHub</code> component is responsible for communicating with the kernel device
+drivers and identifying device capabilities. Accordingly, its state shows
+information about how devices are configured.</p>
+<pre><code>Event Hub State:
+ BuiltInKeyboardId: -1
+ Devices:
+ 3: tuna-gpio-keypad
+ Classes: 0x00000001
+ Path: /dev/input/event2
+ Location:
+ UniqueId:
+ Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
+ KeyLayoutFile: /system/usr/keylayout/tuna-gpio-keypad.kl
+ KeyCharacterMapFile: /system/usr/keychars/tuna-gpio-keypad.kcm
+ ConfigurationFile:
+ 5: Tuna Headset Jack
+ Classes: 0x00000080
+ Path: /dev/input/event5
+ Location: ALSA
+ UniqueId:
+ Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
+ KeyLayoutFile:
+ KeyCharacterMapFile:
+ ConfigurationFile:
+ 6: Melfas MMSxxx Touchscreen
+ Classes: 0x00000014
+ Path: /dev/input/event1
+ Location: 3-0048/input0
+ UniqueId:
+ Identifier: bus=0x0018, vendor=0x0000, product=0x0000, version=0x0000
+ KeyLayoutFile:
+ KeyCharacterMapFile:
+ ConfigurationFile: /system/usr/idc/Melfas_MMSxxx_Touchscreen.idc
+ 7: Motorola Bluetooth Wireless Keyboard
+ Classes: 0x8000000b
+ Path: /dev/input/event6
+ Location: 0C:DF:A4:B3:2D:BA
+ UniqueId: 00:0F:F6:80:02:CD
+ Identifier: bus=0x0005, vendor=0x22b8, product=0x093d, version=0x0288
+ KeyLayoutFile: /system/usr/keylayout/Vendor_22b8_Product_093d.kl
+ KeyCharacterMapFile: /system/usr/keychars/Generic.kcm
+ ConfigurationFile:
+</code></pre>
+<h4 id="things-to-look-for">Things To Look For</h4>
+<ol>
+<li>
+<p>All of the expected input devices are present.</p>
+</li>
+<li>
+<p>Each input device has an appropriate key layout file, key character map file
+ and input device configuration file. If the files are missing or contain
+ syntax errors, then they will not be loaded.</p>
+</li>
+<li>
+<p>Each input device is being classified correctly. The bits in the <code>Classes</code>
+ field correspond to flags in <code>EventHub.h</code> such as <code>INPUT_DEVICE_CLASS_TOUCH_MT</code>.</p>
+</li>
+<li>
+<p>The <code>BuiltInKeyboardId</code> is correct. If the device does not have a built-in keyboard,
+ then the id must be <code>-1</code>, otherwise it should be the id of the built-in keyboard.</p>
+<p>If you observe that the <code>BuiltInKeyboardId</code> is not <code>-1</code> but it should be, then
+you are missing a key character map file for a special function keypad somewhere.
+Special function keypad devices should have key character map files that contain
+just the line <code>type SPECIAL_FUNCTION</code> (that's what in the <code>tuna-gpio-keykad.kcm</code>
+file we see mentioned above).</p>
+</li>
+</ol>
+<h3 id="input-reader-state">Input Reader State</h3>
+<p>The <code>InputReader</code> is responsible for decoding input events from the kernel.
+Its state dump shows information about how each input device is configured
+and recent state changes that occurred, such as key presses or touches on
+the touch screen.</p>
+<p>This is what a special function keypad looks like:</p>
+<pre><code>Input Reader State:
+ Device 3: tuna-gpio-keypad
+ IsExternal: false
+ Sources: 0x00000101
+ KeyboardType: 1
+ Keyboard Input Mapper:
+ Parameters:
+ AssociatedDisplayId: -1
+ OrientationAware: false
+ KeyboardType: 1
+ Orientation: 0
+ KeyDowns: 0 keys currently down
+ MetaState: 0x0
+ DownTime: 75816923828000
+</code></pre>
+<p>Here is a touch screen. Notice all of the information about the resolution of
+the device and the calibration parameters that were used.</p>
+<pre><code> Device 6: Melfas MMSxxx Touchscreen
+ IsExternal: false
+ Sources: 0x00001002
+ KeyboardType: 0
+ Motion Ranges:
+ X: source=0x00001002, min=0.000, max=719.001, flat=0.000, fuzz=0.999
+ Y: source=0x00001002, min=0.000, max=1279.001, flat=0.000, fuzz=0.999
+ PRESSURE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
+ SIZE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
+ TOUCH_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
+ TOUCH_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
+ TOOL_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
+ TOOL_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
+ Touch Input Mapper:
+ Parameters:
+ GestureMode: spots
+ DeviceType: touchScreen
+ AssociatedDisplay: id=0, isExternal=false
+ OrientationAware: true
+ Raw Touch Axes:
+ X: min=0, max=720, flat=0, fuzz=0, resolution=0
+ Y: min=0, max=1280, flat=0, fuzz=0, resolution=0
+ Pressure: min=0, max=255, flat=0, fuzz=0, resolution=0
+ TouchMajor: min=0, max=30, flat=0, fuzz=0, resolution=0
+ TouchMinor: unknown range
+ ToolMajor: unknown range
+ ToolMinor: unknown range
+ Orientation: unknown range
+ Distance: unknown range
+ TiltX: unknown range
+ TiltY: unknown range
+ TrackingId: min=0, max=65535, flat=0, fuzz=0, resolution=0
+ Slot: min=0, max=9, flat=0, fuzz=0, resolution=0
+ Calibration:
+ touch.size.calibration: diameter
+ touch.size.scale: 10.000
+ touch.size.bias: 0.000
+ touch.size.isSummed: false
+ touch.pressure.calibration: amplitude
+ touch.pressure.scale: 0.005
+ touch.orientation.calibration: none
+ touch.distance.calibration: none
+ SurfaceWidth: 720px
+ SurfaceHeight: 1280px
+ SurfaceOrientation: 0
+ Translation and Scaling Factors:
+ XScale: 0.999
+ YScale: 0.999
+ XPrecision: 1.001
+ YPrecision: 1.001
+ GeometricScale: 0.999
+ PressureScale: 0.005
+ SizeScale: 0.033
+ OrientationCenter: 0.000
+ OrientationScale: 0.000
+ DistanceScale: 0.000
+ HaveTilt: false
+ TiltXCenter: 0.000
+ TiltXScale: 0.000
+ TiltYCenter: 0.000
+ TiltYScale: 0.000
+ Last Button State: 0x00000000
+ Last Raw Touch: pointerCount=0
+ Last Cooked Touch: pointerCount=0
+</code></pre>
+<p>Here is an external keyboard / mouse combo HID device. (This device doesn't actually
+have a mouse but its HID descriptor says it does.)</p>
+<pre><code> Device 7: Motorola Bluetooth Wireless Keyboard
+ IsExternal: true
+ Sources: 0x00002103
+ KeyboardType: 2
+ Motion Ranges:
+ X: source=0x00002002, min=0.000, max=719.000, flat=0.000, fuzz=0.000
+ Y: source=0x00002002, min=0.000, max=1279.000, flat=0.000, fuzz=0.000
+ PRESSURE: source=0x00002002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
+ VSCROLL: source=0x00002002, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
+ Keyboard Input Mapper:
+ Parameters:
+ AssociatedDisplayId: -1
+ OrientationAware: false
+ KeyboardType: 2
+ Orientation: 0
+ KeyDowns: 0 keys currently down
+ MetaState: 0x0
+ DownTime: 75868832946000
+ Cursor Input Mapper:
+ Parameters:
+ AssociatedDisplayId: 0
+ Mode: pointer
+ OrientationAware: false
+ XScale: 1.000
+ YScale: 1.000
+ XPrecision: 1.000
+ YPrecision: 1.000
+ HaveVWheel: true
+ HaveHWheel: false
+ VWheelScale: 1.000
+ HWheelScale: 1.000
+ Orientation: 0
+ ButtonState: 0x00000000
+ Down: false
+ DownTime: 0
+</code></pre>
+<p>Here is a joystick. Notice how all of the axes have been scaled to a normalized
+range. The axis mapping can be configured using key layout files.</p>
+<pre><code>Device 18: Logitech Logitech Cordless RumblePad 2
+ IsExternal: true
+ Sources: 0x01000511
+ KeyboardType: 1
+ Motion Ranges:
+ X: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
+ Y: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
+ Z: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
+ RZ: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
+ HAT_X: source=0x01000010, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
+ HAT_Y: source=0x01000010, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
+ Keyboard Input Mapper:
+ Parameters:
+ AssociatedDisplayId: -1
+ OrientationAware: false
+ KeyboardType: 1
+ Orientation: 0
+ KeyDowns: 0 keys currently down
+ MetaState: 0x0
+ DownTime: 675270841000
+ Joystick Input Mapper:
+ Axes:
+ X: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
+ scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
+ rawAxis=0, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
+ Y: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
+ scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
+ rawAxis=1, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
+ Z: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
+ scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
+ rawAxis=2, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
+ RZ: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
+ scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
+ rawAxis=5, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
+ HAT_X: min=-1.00000, max=1.00000, flat=0.00000, fuzz=0.00000
+ scale=1.00000, offset=0.00000, highScale=1.00000, highOffset=0.00000
+ rawAxis=16, rawMin=-1, rawMax=1, rawFlat=0, rawFuzz=0, rawResolution=0
+ HAT_Y: min=-1.00000, max=1.00000, flat=0.00000, fuzz=0.00000
+ scale=1.00000, offset=0.00000, highScale=1.00000, highOffset=0.00000
+ rawAxis=17, rawMin=-1, rawMax=1, rawFlat=0, rawFuzz=0, rawResolution=0
+</code></pre>
+<p>At the end of the input reader dump there is some information about global configuration
+parameters such as the mouse pointer speed.</p>
+<pre><code> Configuration:
+ ExcludedDeviceNames: []
+ VirtualKeyQuietTime: 0.0ms
+ PointerVelocityControlParameters: scale=1.000, lowThreshold=500.000, highThreshold=3000.000, acceleration=3.000
+ WheelVelocityControlParameters: scale=1.000, lowThreshold=15.000, highThreshold=50.000, acceleration=4.000
+ PointerGesture:
+ Enabled: true
+ QuietInterval: 100.0ms
+ DragMinSwitchSpeed: 50.0px/s
+ TapInterval: 150.0ms
+ TapDragInterval: 300.0ms
+ TapSlop: 20.0px
+ MultitouchSettleInterval: 100.0ms
+ MultitouchMinDistance: 15.0px
+ SwipeTransitionAngleCosine: 0.3
+ SwipeMaxWidthRatio: 0.2
+ MovementSpeedRatio: 0.8
+ ZoomSpeedRatio: 0.3
+</code></pre>
+<h4 id="things-to-look-for_1">Things To Look For</h4>
+<ol>
+<li>
+<p>All of the expected input devices are present.</p>
+</li>
+<li>
+<p>Each input device has been configured appropriately. Especially check the
+ touch screen and joystick axes.</p>
+</li>
+</ol>
+<h3 id="input-dispatcher-state">Input Dispatcher State</h3>
+<p>The <code>InputDispatcher</code> is responsible for sending input events to applications.
+Its state dump shows information about which window is being touched, the
+state of the input queue, whether an ANR is in progress, and so on.</p>
+<pre><code>Input Dispatcher State:
+ DispatchEnabled: 1
+ DispatchFrozen: 0
+ FocusedApplication: name='AppWindowToken{41b03a10 token=Token{41bdcf78 ActivityRecord{418ab728 com.android.settings/.Settings}}}', dispatchingTimeout=5000.000ms
+ FocusedWindow: name='Window{41908458 Keyguard paused=false}'
+ TouchDown: false
+ TouchSplit: false
+ TouchDeviceId: -1
+ TouchSource: 0x00000000
+ TouchedWindows: <none>
+ Windows:
+ 0: name='Window{41bd5b18 NavigationBar paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x05800068, type=0x000007e3, layer=181000, frame=[0,1184][720,1280], scale=1.000000, touchableRegion=[0,1184][720,1280], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 1: name='Window{41a19770 RecentsPanel paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01820100, type=0x000007de, layer=151000, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 2: name='Window{41a78768 StatusBar paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x00800048, type=0x000007d0, layer=141000, frame=[0,0][720,50], scale=1.000000, touchableRegion=[0,0][720,50], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 3: name='Window{41877570 StatusBarExpanded paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x01811328, type=0x000007e1, layer=131005, frame=[0,-1184][720,-114], scale=1.000000, touchableRegion=[0,-1184][720,-114], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 4: name='Window{41bedf20 TrackingView paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01020300, type=0x000007e1, layer=131000, frame=[0,-1032][720,102], scale=1.000000, touchableRegion=[0,-1032][720,102], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 5: name='Window{41908458 Keyguard paused=false}', paused=false, hasFocus=true, hasWallpaper=false, visible=true, canReceiveKeys=true, flags=0x15120800, type=0x000007d4, layer=111000, frame=[0,50][720,1184], scale=1.000000, touchableRegion=[0,50][720,1184], inputFeatures=0x00000000, ownerPid=205, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 6: name='Window{4192cc30 com.android.phasebeam.PhaseBeamWallpaper paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x00000308, type=0x000007dd, layer=21010, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=429, ownerUid=10046, dispatchingTimeout=5000.000ms
+ 7: name='Window{41866c00 com.android.settings/com.android.settings.Settings paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01810100, type=0x00000001, layer=21005, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=19000, ownerUid=1000, dispatchingTimeout=5000.000ms
+ 8: name='Window{4197c858 com.android.launcher/com.android.launcher2.Launcher paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01910100, type=0x00000001, layer=21000, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=515, ownerUid=10032, dispatchingTimeout=5000.000ms
+ MonitoringChannels: <none>
+ InboundQueue: length=0
+ ActiveConnections: <none>
+ AppSwitch: not pending
+ Configuration:
+ MaxEventsPerSecond: 90
+ KeyRepeatDelay: 50.0ms
+ KeyRepeatTimeout: 500.0ms
+</code></pre>
+<h4 id="things-to-look-for_2">Things To Look For</h4>
+<ol>
+<li>
+<p>In general, all input events are being processed as expected.</p>
+</li>
+<li>
+<p>If you touch the touch screen and run dumpsys at the same time, then the <code>TouchedWindows</code>
+ line should show the window that you are touching.</p>
+</li>
+</ol>
+
diff --git a/src/devices/tech/input/getevent.jd b/src/devices/tech/input/getevent.jd
new file mode 100644
index 0000000..19499d1
--- /dev/null
+++ b/src/devices/tech/input/getevent.jd
@@ -0,0 +1,103 @@
+page.title=Getevent
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The <code>getevent</code> tool runs on the device and provides information about input
+devices and a live dump of kernel input events.</p>
+<p>It is very useful tool for ensuring that device drivers are reporing the
+expected set of capabilities for each input device and are generating the
+desired stream of input events.</p>
+<h2 id="usage">Usage</h2>
+<h3 id="showing-device-capabilities">Showing Device Capabilities</h3>
+<p>It is often quite useful to see all of the keys and axes that a device reports.
+Use the <code>-p</code> option to do that.</p>
+<p>Here is a list of all of the Linux key codes and other events that a
+particular keyboard says it supports.</p>
+<pre><code>$ adb shell su -- getevent -p
+
+ name: "Motorola Bluetooth Wireless Keyboard"
+ events:
+ KEY (0001): 0001 0002 0003 0004 0005 0006 0007 0008
+ 0009 000a 000b 000c 000d 000e 000f 0010
+ 0011 0012 0013 0014 0015 0016 0017 0018
+ 0019 001a 001b 001c 001d 001e 001f 0020
+ 0021 0022 0023 0024 0025 0026 0027 0028
+ 0029 002a 002b 002c 002d 002e 002f 0030
+ 0031 0032 0033 0034 0035 0036 0037 0038
+ 0039 003a 003b 003c 003d 003e 003f 0040
+ 0041 0042 0043 0044 0045 0046 0047 0048
+ 0049 004a 004b 004c 004d 004e 004f 0050
+ 0051 0052 0053 0055 0056 0057 0058 0059
+ 005a 005b 005c 005d 005e 005f 0060 0061
+ 0062 0063 0064 0066 0067 0068 0069 006a
+ 006b 006c 006d 006e 006f 0071 0072 0073
+ 0074 0075 0077 0079 007a 007b 007c 007d
+ 007e 007f 0080 0081 0082 0083 0084 0085
+ 0086 0087 0088 0089 008a 008c 008e 0090
+ 0096 0098 009b 009c 009e 009f 00a1 00a3
+ 00a4 00a5 00a6 00ab 00ac 00ad 00b0 00b1
+ 00b2 00b3 00b4 00b7 00b8 00b9 00ba 00bb
+ 00bc 00bd 00be 00bf 00c0 00c1 00c2 00d9
+ 00f0 0110 0111 0112 01ba
+ REL (0002): 0000 0001 0008
+ ABS (0003): 0028 : value 223, min 0, max 255, fuzz 0, flat 0, resolution 0
+ 0029 : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
+ 002a : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
+ 002b : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
+ MSC (0004): 0004
+ LED (0011): 0000 0001 0002 0003 0004
+ input props:
+ <none>
+</code></pre>
+<p>The <code>-i</code> option shows even more information than <code>-p</code>, including HID mapping tables
+and debugging information.</p>
+<p>The <code>-l</code> option uses textual labels for all event codes, which is handy.</p>
+<pre><code>$ adb shell su -- getevent -lp /dev/input/event1
+
+ name: "Melfas MMSxxx Touchscreen"
+ events:
+ ABS (0003): ABS_MT_SLOT : value 0, min 0, max 9, fuzz 0, flat 0, resolution 0
+ ABS_MT_TOUCH_MAJOR : value 0, min 0, max 30, fuzz 0, flat 0, resolution 0
+ ABS_MT_POSITION_X : value 0, min 0, max 720, fuzz 0, flat 0, resolution 0
+ ABS_MT_POSITION_Y : value 0, min 0, max 1280, fuzz 0, flat 0, resolution 0
+ ABS_MT_TRACKING_ID : value 0, min 0, max 65535, fuzz 0, flat 0, resolution 0
+ ABS_MT_PRESSURE : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
+ input props:
+ INPUT_PROP_DIRECT
+</code></pre>
+<h3 id="showing-live-events">Showing Live Events</h3>
+<p>This is what a two finger multitouch gesture looks like for a touch screen
+that is using the Linux multitouch input protocol "B". We use the <code>-l</code> option
+to show textual labels and <code>-t</code> to show timestamps.</p>
+<pre><code>$ adb shell su -- getevent -lt /dev/input/event1
+
+[ 78826.389007] EV_ABS ABS_MT_TRACKING_ID 0000001f
+[ 78826.389038] EV_ABS ABS_MT_PRESSURE 000000ab
+[ 78826.389038] EV_ABS ABS_MT_POSITION_X 000000ab
+[ 78826.389068] EV_ABS ABS_MT_POSITION_Y 0000025b
+[ 78826.389068] EV_ABS ABS_MT_SLOT 00000001
+[ 78826.389068] EV_ABS ABS_MT_TRACKING_ID 00000020
+[ 78826.389068] EV_ABS ABS_MT_PRESSURE 000000b9
+[ 78826.389099] EV_ABS ABS_MT_POSITION_X 0000019e
+[ 78826.389099] EV_ABS ABS_MT_POSITION_Y 00000361
+[ 78826.389099] EV_SYN SYN_REPORT 00000000
+[ 78826.468688] EV_ABS ABS_MT_SLOT 00000000
+[ 78826.468688] EV_ABS ABS_MT_TRACKING_ID ffffffff
+[ 78826.468719] EV_ABS ABS_MT_SLOT 00000001
+[ 78826.468719] EV_ABS ABS_MT_TRACKING_ID ffffffff
+[ 78826.468719] EV_SYN SYN_REPORT 00000000
+</code></pre>
diff --git a/src/devices/tech/input/index.jd b/src/devices/tech/input/index.jd
new file mode 100644
index 0000000..80cc997
--- /dev/null
+++ b/src/devices/tech/input/index.jd
@@ -0,0 +1,22 @@
+page.title=Input Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android input subsystem supports many different device classes,
+including keyboard, joystick, trackball, mouse and touch screen.</p>
+<p>The documentation in this section describes how to configure,
+calibrate, test, and write drivers for input devices.</p>
\ No newline at end of file
diff --git a/src/devices/tech/input/input-device-configuration-files.jd b/src/devices/tech/input/input-device-configuration-files.jd
new file mode 100644
index 0000000..e5629c3
--- /dev/null
+++ b/src/devices/tech/input/input-device-configuration-files.jd
@@ -0,0 +1,127 @@
+page.title=Input Device Configuration Files
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Input device configuration files (<code>.idc</code> files) contain device-specific
+configuration properties that affect the behavior of input devices.</p>
+<p>Input device configuration files are typically not necessary for standard
+peripherals such as HID keyboards and mice since the default system behavior
+usually ensures that they will work out of the box. On the other hand,
+built-in embedded devices, particularly touch screens, almost always
+require input device configuration files to specify their behavior.</p>
+<h2 id="rationale">Rationale</h2>
+<p>Android automatically detects and configures most input device capabilities
+based on the event types and properties that are reported by the associated
+Linux kernel input device driver.</p>
+<p>For example, if an input device supports the <code>EV_REL</code> event type and codes
+<code>REL_X</code> and <code>REL_Y</code> as well as the <code>EV_KEY</code> event type and <code>BTN_MOUSE</code>,
+then Android will classify the input device as a mouse. The default behavior
+for a mouse is to present an on-screen cursor which tracks the mouse's movements
+and simulates touches when the mouse is clicked. Although the mouse can
+be configured differently, the default behavior is usually sufficient for
+standard mouse peripherals.</p>
+<p>Certain classes of input devices are more ambiguous. For example, multi-touch
+touch screens and touch pads both support the <code>EV_ABS</code> event type and codes
+<code>ABS_MT_POSITION_X</code> and <code>ABS_MT_POSITION_Y</code> at a minimum. However, the intended
+uses of these devices are quite different and cannot always be determined
+automatically. Also, additional information is required to make sense of the
+pressure and size information reported by touch devices. Hence touch devices,
+especially built-in touch screens, usually need IDC files.</p>
+<h2 id="location">Location</h2>
+<p>Input device configuration files are located by USB vendor, product (and
+optionally version) id or by input device name.</p>
+<p>The following paths are consulted in order.</p>
+<ul>
+<li><code>/system/usr/idc/Vendor_XXXX_Product_XXXX_Version_XXXX.idc</code></li>
+<li><code>/system/usr/idc/Vendor_XXXX_Product_XXXX.idc</code></li>
+<li><code>/system/usr/idc/DEVICE_NAME.idc</code></li>
+<li><code>/data/system/devices/idc/Vendor_XXXX_Product_XXXX_Version_XXXX.idc</code></li>
+<li><code>/data/system/devices/idc/Vendor_XXXX_Product_XXXX.idc</code></li>
+<li><code>/data/system/devices/idc/DEVICE_NAME.idc</code></li>
+</ul>
+<p>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 '_'.</p>
+<h2 id="syntax">Syntax</h2>
+<p>An input device configuration file is a plain text file consisting of property
+assignments and comments.</p>
+<h3 id="properties">Properties</h3>
+<p>Property assignments each consist of a property name, an <code>=</code>, a property value,
+and a new line. Like this:</p>
+<pre><code>property = value
+</code></pre>
+<p>Property names are non-empty literal text identifiers. They must not contain
+whitespace. Each components of the input system defines a set of properties
+that are used to configure its function.</p>
+<p>Property values are non-empty string literals, integers or floating point numbers.
+They must not contain whitespace or the reserved characters <code>\</code> or <code>"</code>.</p>
+<p>Property names and values are case-sensitive.</p>
+<h3 id="comments">Comments</h3>
+<p>Comment lines begin with '#' and continue to the end of the line. Like this:</p>
+<pre><code># A comment!
+</code></pre>
+<p>Blank lines are ignored.</p>
+<h3 id="example">Example</h3>
+<pre><code># This is an example of an input device configuration file.
+# It might be used to describe the characteristics of a built-in touch screen.
+
+# This is an internal device, not an external peripheral attached to the USB
+# or Bluetooth bus.
+device.internal = 1
+
+# The device should behave as a touch screen, which uses the same orientation
+# as the built-in display.
+touch.deviceType = touchScreen
+touch.orientationAware = 1
+
+# Additional calibration properties...
+# etc...
+</code></pre>
+<h2 id="common-properties">Common Properties</h2>
+<p>The following properties are common to all input device classes.</p>
+<p>Refer to the documentation of each input device class for information about the
+special properties used by each class.</p>
+<h4 id="deviceinternal"><code>device.internal</code></h4>
+<p><em>Definition:</em> <code>device.internal</code> = <code>0</code> | <code>1</code></p>
+<p>Specifies whether the input device is an internal built-in component as opposed to an
+externally attached (most likely removable) peripheral.</p>
+<ul>
+<li>
+<p>If the value is <code>0</code>, the device is external.</p>
+</li>
+<li>
+<p>If the value is <code>1</code>, the device is internal.</p>
+</li>
+<li>
+<p>If the value is not specified, the default value is <code>0</code> for all devices on the
+ USB (BUS_USB) or Bluetooth (BUS_BLUETOOTH) bus, <code>1</code> otherwise.</p>
+</li>
+</ul>
+<p>This property determines default policy decisions regarding wake events.</p>
+<p>Internal input devices generally do not wake the display from sleep unless explicitly
+configured to do so in the key layout file or in a hardcoded policy rule. This
+distinction prevents key presses and touches from spuriously waking up your phone
+when it is in your pocket. Usually there are only a small handful of wake keys defined.</p>
+<p>Conversely, external input devices usually wake the device more aggressively because
+they are assumed to be turned off or not plugged in during transport. For example,
+pressing any key on an external keyboard is a good indicator that the user wants the
+device to wake up and respond.</p>
+<p>It is important to ensure that the value of the <code>device.internal</code> property is set
+correctly for all internal input devices.</p>
+<h2 id="validation">Validation</h2>
+<p>Make sure to validate your input device configuration files using the
+<a href="/tech/input/validate-keymaps.html">Validate Keymaps</a> tool.</p>
+
diff --git a/src/devices/tech/input/key-character-map-files.jd b/src/devices/tech/input/key-character-map-files.jd
new file mode 100644
index 0000000..7b1ac5b
--- /dev/null
+++ b/src/devices/tech/input/key-character-map-files.jd
@@ -0,0 +1,425 @@
+page.title=Key Character Map Files
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Key character map files (<code>.kcm</code> files) are responsible for mapping combinations
+of Android key codes with modifiers to Unicode characters.</p>
+<p>Device-specific key layout files are <em>required</em> for all internal (built-in)
+input devices that have keys, if only to tell the system that the device
+is special purpose only (not a full keyboard).</p>
+<p>Device-specific key layout files are <em>optional</em> for external keyboards, and
+often aren't needed at all. The system provides a generic key character map
+that is suitable for many external keyboards.</p>
+<p>If no device-specific key layout file is available, then the system will
+choose a default instead.</p>
+<h2 id="location">Location</h2>
+<p>Key character map files are located by USB vendor, product (and optionally version)
+id or by input device name.</p>
+<p>The following paths are consulted in order.</p>
+<ul>
+<li><code>/system/usr/keychars/Vendor_XXXX_Product_XXXX_Version_XXXX.kcm</code></li>
+<li><code>/system/usr/keychars/Vendor_XXXX_Product_XXXX.kcm</code></li>
+<li><code>/system/usr/keychars/DEVICE_NAME.kcm</code></li>
+<li><code>/data/system/devices/keychars/Vendor_XXXX_Product_XXXX_Version_XXXX.kcm</code></li>
+<li><code>/data/system/devices/keychars/Vendor_XXXX_Product_XXXX.kcm</code></li>
+<li><code>/data/system/devices/keychars/DEVICE_NAME.kcm</code></li>
+<li><code>/system/usr/keychars/Generic.kcm</code></li>
+<li><code>/data/system/devices/keychars/Generic.kcm</code></li>
+<li><code>/system/usr/keychars/Virtual.kcm</code></li>
+<li><code>/data/system/devices/keychars/Virtual.kcm</code></li>
+</ul>
+<p>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 '<em>' are replaced by '</em>'.</p>
+<h2 id="generic-key-character-map-file">Generic Key Character Map File</h2>
+<p>The system provides a special built-in key character map file called <code>Generic.kcm</code>.
+This key character map is intended to support a variety of standard external
+keyboards.</p>
+<p><em>Do not modify the generic key character map!</em></p>
+<h2 id="virtual-key-character-map-file">Virtual Key Character Map File</h2>
+<p>The system provides a special built-in key character map file called <code>Virtual.kcm</code>
+that is used by the virtual keyboard devices.</p>
+<p>The virtual keyboard device is a synthetic input device whose id is -1
+(see <code>KeyCharacterMap.VIRTUAL_KEYBOARD</code>). It is present on all Android devices
+beginning with Android Honeycomb 3.0. The purpose of the virtual keyboard device
+is to provide a known built-in input device that can be used for injecting
+keystokes into applications by the IME or by test instrumentation, even
+for devices that do not have built-in keyboards.</p>
+<p>The virtual keyboard is assumed to have a full QWERTY layout that is the
+same on all devices. This makes it possible for applications to inject
+keystrokes using the virtual keyboard device and always get the same results.</p>
+<p><em>Do not modify the virtual key character map!</em></p>
+<h2 id="syntax">Syntax</h2>
+<p>A key character map file is a plain text file consisting of a keyboard type
+declaration and a set of key declarations.</p>
+<h3 id="keyboard-type-declaration">Keyboard Type Declaration</h3>
+<p>A keyboard type declaration describes the overall behavior of the keyboard.
+A character map file must contain a keyboard type declaration. For clarity,
+it is often placed at the top of the file.</p>
+<pre><code>type FULL
+</code></pre>
+<p>The following keyboard types are recognized:</p>
+<ul>
+<li>
+<p><code>NUMERIC</code>: A numeric (12-key) keyboard.</p>
+<p>A numeric keyboard supports text entry using a multi-tap approach.
+It may be necessary to tap a key multiple times to generate the desired letter or symbol.</p>
+<p>This type of keyboard is generally designed for thumb typing.</p>
+<p>Corresponds to <code>KeyCharacterMap.NUMERIC</code>.</p>
+</li>
+<li>
+<p><code>PREDICTIVE</code>: A keyboard with all the letters, but with more than one letter per key.</p>
+<p>This type of keyboard is generally designed for thumb typing.</p>
+<p>Corresponds to <code>KeyCharacterMap.PREDICTIVE</code>.</p>
+</li>
+<li>
+<p><code>ALPHA</code>: A keyboard with all the letters, and maybe some numbers.</p>
+<p>An alphabetic keyboard supports text entry directly but may have a condensed
+layout with a small form factor. In contrast to a <code>FULL</code> keyboard, some
+symbols may only be accessible using special on-screen character pickers.
+In addition, to improve typing speed and accuracy, the framework provides
+special affordances for alphabetic keyboards such as auto-capitalization
+and toggled / locked SHIFT and ALT keys.</p>
+<p>This type of keyboard is generally designed for thumb typing.</p>
+</li>
+<li>
+<p><code>FULL</code>: A full PC-style keyboard.</p>
+<p>A full keyboard behaves like a PC keyboard. All symbols are accessed directly
+by pressing keys on the keyboard without on-screen support or affordances such
+as auto-capitalization.</p>
+<p>This type of keyboard is generally designed for full two hand typing.</p>
+</li>
+<li>
+<p><code>SPECIAL_FUNCTION</code>: A keyboard that is only used to perform system control functions
+ rather than for typing.</p>
+<p>A special function keyboard consists only of non-printing keys such as
+HOME and POWER that are not actually used for typing.</p>
+</li>
+</ul>
+<p>The <code>Generic.kcm</code> and <code>Virtual.kcm</code> key character maps are both <code>FULL</code> keyboards.</p>
+<h3 id="key-declarations">Key Declarations</h3>
+<p>Key declarations each consist of the keyword <code>key</code> followed by an Android key code
+name, an open curly brace, a set of properties and behaviors and a close curly brace.</p>
+<pre><code>key A {
+ label: 'A'
+ base: 'a'
+ shift, capslock: 'A'
+ ctrl, alt, meta: none
+}
+</code></pre>
+<h4 id="properties">Properties</h4>
+<p>Each key property establishes a mapping from a key to a behavior. To make the
+key character map files more compact, several properties can be mapped to the
+same behavior by separating them with a comma.</p>
+<p>In the above example, the <code>label</code> property is assigned the <code>'A'</code> behavior.
+Likewise, the <code>ctrl</code>, <code>alt</code> and <code>meta</code> properties are all simultaneously assigned
+the <code>none</code> behavior.</p>
+<p>The following properties are recognized:</p>
+<ul>
+<li>
+<p><code>label</code>: Specifies the label that is physically printed on the key, when it
+ consists of a single character. This is the value that is returned by
+ the <code>KeyCharacterMap.getDisplayLabel</code> method.</p>
+</li>
+<li>
+<p><code>number</code>: Specifies the behavior (character that should be typed) when a numeric
+ text view has focus, such as when the user is typing a phone number.</p>
+<p>Compact keyboards often combine multiple symbols into a single key, such that
+the same key might be used to type <code>'1'</code> and <code>'a'</code> or <code>'#'</code> and <code>'q'</code>, perhaps.
+For these keys, the <code>number</code> property should be set to indicate which symbol
+should be typed in a numeric context, if any.</p>
+<p>Some typical "numeric" symbols are digits <code>'0'</code> through <code>'9'</code>, <code>'#'</code>, <code>'+'</code>,
+<code>'('</code>, <code>')'</code>, <code>','</code>, and <code>'.'</code>.</p>
+</li>
+<li>
+<p><code>base</code>: Specifies the behavior (character that should be typed) when no modifiers
+ are pressed.</p>
+</li>
+<li>
+<p><modifier> or <modifier1><code>+</code><modifier2><code>+</code>...: Specifies the
+ behavior (character that should be typed) when the key is pressed and all of the
+ specified modifiers are active.</p>
+<p>For example, the modifier property <code>shift</code> specifies a behavior that applies when
+the either the LEFT SHIFT or RIGHT SHIFT modifier is pressed.</p>
+<p>Similarly, the modifier property <code>rshift+ralt</code> specifies a behavior that applies
+when the both RIGHT SHIFT and RIGHT ALT modifiers are pressed together.</p>
+</li>
+</ul>
+<p>The following modifiers are recognized in modifier properties:</p>
+<ul>
+<li><code>shift</code>: Applies when either the LEFT SHIFT or RIGHT SHIFT modifier is pressed.</li>
+<li><code>lshift</code>: Applies when the LEFT SHIFT modifier is pressed.</li>
+<li><code>rshift</code>: Applies when the RIGHT SHIFT modifier is pressed.</li>
+<li><code>alt</code>: Applies when either the LEFT ALT or RIGHT ALT modifier is pressed.</li>
+<li><code>lalt</code>: Applies when the LEFT ALT modifier is pressed.</li>
+<li><code>ralt</code>: Applies when the RIGHT ALT modifier is pressed.</li>
+<li><code>ctrl</code>: Applies when either the LEFT CONTROL or RIGHT CONTROL modifier is pressed.</li>
+<li><code>lctrl</code>: Applies when the LEFT CONTROL modifier is pressed.</li>
+<li><code>rctrl</code>: Applies when the RIGHT CONTROL modifier is pressed.</li>
+<li><code>meta</code>: Applies when either the LEFT META or RIGHT META modifier is pressed.</li>
+<li><code>lmeta</code>: Applies when the LEFT META modifier is pressed.</li>
+<li><code>rmeta</code>: Applies when the RIGHT META modifier is pressed.</li>
+<li><code>sym</code>: Applies when the SYMBOL modifier is pressed.</li>
+<li><code>fn</code>: Applies when the FUNCTION modifier is pressed.</li>
+<li><code>capslock</code>: Applies when the CAPS LOCK modifier is locked.</li>
+<li><code>numlock</code>: Applies when the NUM LOCK modifier is locked.</li>
+<li><code>scrolllock</code>: Applies when the SCROLL LOCK modifier is locked.</li>
+</ul>
+<p>The order in which the properties are listed is significant. When mapping a key to
+a behavior, the system scans all relevant properties in order and returns the last
+applicable behavior that it found.</p>
+<p>Consequently, properties that are specified later override properties that are
+specified earlier for a given key.</p>
+<h4 id="behaviors">Behaviors</h4>
+<p>Each property maps to a behavior. The most common behavior is typing a character
+but there are others.</p>
+<p>The following behaviors are recognized:</p>
+<ul>
+<li>
+<p><code>none</code>: Don't type a character.</p>
+<p>This behavior is the default when no character is specified. Specifying <code>none</code>
+is optional but it improves clarity.</p>
+</li>
+<li>
+<p><code>'X'</code>: Type the specified character literal.</p>
+<p>This behavior causes the specified character to be entered into the focused
+text view. The character literal may be any ASCII character, or one of the
+following escape sequences:</p>
+<ul>
+<li><code>'\\'</code>: Type a backslash character.</li>
+<li><code>'\n'</code>: Type a new line character (use this for ENTER / RETURN).</li>
+<li><code>'\t'</code>: Type a TAB character.</li>
+<li><code>'\''</code>: Type an apostrophe character.</li>
+<li><code>'\"'</code>: Type a quote character.</li>
+<li><code>'\uXXXX'</code>: Type the Unicode character whose code point is given in hex by XXXX.</li>
+</ul>
+</li>
+<li>
+<p><code>fallback</code> <Android key code name>: Perform a default action if the key is not
+ handled by the application.</p>
+<p>This behavior causes the system to simulate a different key press when an application
+does not handle the specified key natively. It is used to support default behavior
+for new keys that not all applications know how to handle, such as ESCAPE or
+numeric keypad keys (when numlock is not pressed).</p>
+<p>When a fallback behavior is performed, the application will receive two key presses:
+one for the original key and another for the fallback key that was selected.
+If the application handles the original key during key up, then the fallback key
+event will be canceled (<code>KeyEvent.isCanceled</code> will return <code>true</code>).</p>
+</li>
+</ul>
+<p>The system reserves two Unicode characters to perform special functions:</p>
+<ul>
+<li>
+<p><code>'\uef00'</code>: When this behavior is performed, the text view consumes and removes the
+ four characters preceding the cursor, interprets them as hex digits, and inserts the
+ corresponding Unicode code point.</p>
+</li>
+<li>
+<p><code>'\uef01'</code>: When this behavior is performed, the text view displays a
+ character picker dialog that contains miscellaneous symbols.</p>
+</li>
+</ul>
+<p>The system recognizes the following Unicode characters as combining diacritical dead
+key characters:</p>
+<ul>
+<li><code>'\u0300'</code>: Grave accent.</li>
+<li><code>'\u0301'</code>: Acute accent.</li>
+<li><code>'\u0302'</code>: Circumflex accent.</li>
+<li><code>'\u0303'</code>: Tilde accent.</li>
+<li><code>'\u0308'</code>: Umlaut accent.</li>
+</ul>
+<p>When a dead key is typed followed by another character, the dead key and the following
+characters are composed. For example, when the user types a grave accent dead
+key followed by the letter 'a', the result is 'à'.</p>
+<p>Refer to <code>KeyCharacterMap.getDeadChar</code> for more information about dead key handling.</p>
+<h3 id="comments">Comments</h3>
+<p>Comment lines begin with '#' and continue to the end of the line. Like this:</p>
+<pre><code># A comment!
+</code></pre>
+<p>Blank lines are ignored.</p>
+<h3 id="how-key-combinations-are-mapped-to-behaviors">How Key Combinations are Mapped to Behaviors</h3>
+<p>When the user presses a key, the system looks up the behavior associated with
+the combination of that key press and the currently pressed modifiers.</p>
+<h4 id="shift-a">SHIFT + A</h4>
+<p>Suppose the user pressed A and SHIFT together. The system first locates
+the set of properties and behaviors associated with <code>KEYCODE_A</code>.</p>
+<pre><code>key A {
+ label: 'A'
+ base: 'a'
+ shift, capslock: 'A'
+ ctrl, alt, meta: none
+}
+</code></pre>
+<p>The system scans the properties from first to last and left to right, ignoring
+the <code>label</code> and <code>number</code> properties, which are special.</p>
+<p>The first property encountered is <code>base</code>. The <code>base</code> property always applies to
+a key, no matter what modifiers are pressed. It essentially specifies the default
+behavior for the key unless it is overridden by following properties.
+Since the <code>base</code> property applies to this key press, the system makes note
+of the fact that its behavior is <code>'a'</code> (type the character <code>a</code>).</p>
+<p>The system then continues to scan subsequent properties in case any of them
+are more specific than <code>base</code> and override it. It encounters <code>shift</code> which
+also applies to the key press SHIFT + A. So the system decides to ignore
+the <code>base</code> property's behavior and chooses the behavior associated with
+the <code>shift</code> property, which is <code>'A'</code> (type the character <code>A</code>).</p>
+<p>It then continues to scan the table, however no other properties apply to this
+key press (CAPS LOCK is not locked, neither CONTROL key is pressed, neither
+ALT key is pressed and neither META key is pressed).</p>
+<p>So the resulting behavior for the key combination SHIFT + A is <code>'A'</code>.</p>
+<h4 id="control-a">CONTROL + A</h4>
+<p>Now consider what would happen if the user pressed A and CONTROL together.</p>
+<p>As before, the system would scan the table of properties. It would notice
+that the <code>base</code> property applied but would also continue scanning until
+it eventually reached the <code>control</code> property. As it happens, the <code>control</code>
+property appears after <code>base</code> so its behavior overrides the <code>base</code> behavior.</p>
+<p>So the resulting behavior for the key combination CONTROL + A is <code>none</code>.</p>
+<h4 id="escape">ESCAPE</h4>
+<p>Now suppose the user pressed ESCAPE.</p>
+<pre><code>key ESCAPE {
+ base: fallback BACK
+ alt, meta: fallback HOME
+ ctrl: fallback MENU
+}
+</code></pre>
+<p>This time the system obtains the behavior <code>fallback BACK</code>, a fallback behavior.
+Because no character literal appears, no character will be typed.</p>
+<p>When processing the key, the system will first deliver <code>KEYCODE_ESCAPE</code> to the
+application. If the application does not handle it, then the system will try
+again but this time it will deliver <code>KEYCODE_BACK</code> to the application as
+requested by the fallback behavior.</p>
+<p>So applications that recognize and support <code>KEYCODE_ESCAPE</code> have the
+opportunity to handle it as is, but other applications that do not can instead
+perform the fallback action of treating the key as if it were <code>KEYCODE_BACK</code>.</p>
+<h4 id="numpad_0-with-or-without-num-lock">NUMPAD_0 with or without NUM LOCK</h4>
+<p>The numeric keypad keys have very different interpretations depending on whether
+the NUM LOCK key is locked.</p>
+<p>The following key declaration ensures that <code>KEYCODE_NUMPAD_0</code> types <code>0</code>
+when NUM LOCK is pressed. When NUM LOCK is not pressed, the key is delivered
+to the application as usual, and if it is not handled, then the fallback
+key <code>KEYCODE_INSERT</code> is delivered instead.</p>
+<pre><code>key NUMPAD_0 {
+ label, number: '0'
+ base: fallback INSERT
+ numlock: '0'
+ ctrl, alt, meta: none
+}
+</code></pre>
+<p>As we can see, fallback key declarations greatly improve compatibility
+with older applications that do not recognize or directly support all of the keys
+that are present on a full PC style keyboard.</p>
+<h3 id="examples">Examples</h3>
+<h4 id="full-keyboard">Full Keyboard</h4>
+<pre><code># This is an example of part of a key character map file for a full keyboard
+# include a few fallback behaviors for special keys that few applications
+# handle themselves.
+
+type FULL
+
+key C {
+ label: 'C'
+ base: 'c'
+ shift, capslock: 'C'
+ alt: '\u00e7'
+ shift+alt: '\u00c7'
+ ctrl, meta: none
+}
+
+key SPACE {
+ label: ' '
+ base: ' '
+ ctrl: none
+ alt, meta: fallback SEARCH
+}
+
+key NUMPAD_9 {
+ label, number: '9'
+ base: fallback PAGE_UP
+ numlock: '9'
+ ctrl, alt, meta: none
+}
+</code></pre>
+<h4 id="alphanumeric-keyboard">Alphanumeric Keyboard</h4>
+<pre><code># This is an example of part of a key character map file for an alphanumeric
+# thumb keyboard. Some keys are combined, such as `A` and `2`. Here we
+# specify `number` labels to tell the system what to do when the user is
+# typing a number into a dial pad.
+#
+# Also note the special character '\uef01' mapped to ALT+SPACE.
+# Pressing this combination of keys invokes an on-screen character picker.
+
+type ALPHA
+
+key A {
+ label: 'A'
+ number: '2'
+ base: 'a'
+ shift, capslock: 'A'
+ alt: '#'
+ shift+alt, capslock+alt: none
+}
+
+key SPACE {
+ label: ' '
+ number: ' '
+ base: ' '
+ shift: ' '
+ alt: '\uef01'
+ shift+alt: '\uef01'
+}
+</code></pre>
+<h4 id="game-pad">Game Pad</h4>
+<pre><code># This is an example of part of a key character map file for a game pad.
+# It defines fallback actions that enable the user to navigate the user interface
+# by pressing buttons.
+
+type SPECIAL_FUNCTION
+
+key BUTTON_A {
+ base: fallback BACK
+}
+
+key BUTTON_X {
+ base: fallback DPAD_CENTER
+}
+
+key BUTTON_START {
+ base: fallback HOME
+}
+
+key BUTTON_SELECT {
+ base: fallback MENU
+}
+</code></pre>
+<h2 id="compatibility-note">Compatibility Note</h2>
+<p>Prior to Android Honeycomb 3.0, the Android key character map was specified
+using a very different syntax and was compiled into a binary file format
+(<code>.kcm.bin</code>) at build time.</p>
+<p>Although the new format uses the same extension <code>.kcm</code>, the syntax is quite
+different (and much more powerful).</p>
+<p>As of Android Honeycomb 3.0, all Android key character map files must use
+the new syntax and plain text file format that is described in this document.
+The old syntax is not supported and the old <code>.kcm.bin</code> files are not recognized
+by the system.</p>
+<h2 id="language-note">Language Note</h2>
+<p>Android does not currently support multilingual keyboards. Moreover, the
+built-in generic key character map assumes a US English keyboard layout.</p>
+<p>OEMs are encouraged to provide custom key character maps for their keyboards
+if they are designed for other languages.</p>
+<p>Future versions of Android may provide better support for multilingual keyboards
+or user-selectable keyboard layouts.</p>
+<h2 id="validation">Validation</h2>
+<p>Make sure to validate your key character map files using the
+<a href="/tech/input/validate-keymaps.html">Validate Keymaps</a> tool.</p>
diff --git a/src/devices/tech/input/key-layout-files.jd b/src/devices/tech/input/key-layout-files.jd
new file mode 100644
index 0000000..d416341
--- /dev/null
+++ b/src/devices/tech/input/key-layout-files.jd
@@ -0,0 +1,277 @@
+page.title=Key Layout Files
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Key layout files (<code>.kl</code> files) are responsible for mapping Linux key codes
+and axis codes to Android key codes and axis codes and specifying associated
+policy flags.</p>
+<p>Device-specific key layout files are <em>required</em> for all internal (built-in)
+input devices that have keys, including special keys such as volume, power
+and headset media keys.</p>
+<p>Device-specific key layout files are <em>optional</em> for other input devices but
+they are <em>recommended</em> for special-purpose keyboards and joysticks.</p>
+<p>If no device-specific key layout file is available, then the system will
+choose a default instead.</p>
+<h2 id="location">Location</h2>
+<p>Key layout files are located by USB vendor, product (and optionally version)
+id or by input device name.</p>
+<p>The following paths are consulted in order.</p>
+<ul>
+<li><code>/system/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl</code></li>
+<li><code>/system/usr/keylayout/Vendor_XXXX_Product_XXXX.kl</code></li>
+<li><code>/system/usr/keylayout/DEVICE_NAME.kl</code></li>
+<li><code>/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl</code></li>
+<li><code>/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX.kl</code></li>
+<li><code>/data/system/devices/keylayout/DEVICE_NAME.kl</code></li>
+<li><code>/system/usr/keylayout/Generic.kl</code></li>
+<li><code>/data/system/devices/keylayout/Generic.kl</code></li>
+</ul>
+<p>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 '<em>' are replaced by '</em>'.</p>
+<h2 id="generic-key-layout-file">Generic Key Layout File</h2>
+<p>The system provides a special built-in generic key layout file called <code>Generic.kl</code>.
+This key layout is intended to support a variety of standard external
+keyboards and joysticks.</p>
+<p><em>Do not modify the generic key layout!</em></p>
+<h2 id="syntax">Syntax</h2>
+<p>A key layout file is a plain text file consisting of key or axis declarations
+and flags.</p>
+<h3 id="key-declarations">Key Declarations</h3>
+<p>Key declarations each consist of the keyword <code>key</code> followed by a Linux key code
+number, an Android key code name, and optional set of whitespace delimited policy flags.</p>
+<pre><code>key 1 ESCAPE
+key 114 VOLUME_DOWN WAKE
+key 16 Q VIRTUAL WAKE
+</code></pre>
+<p>The following policy flags are recognized:</p>
+<ul>
+<li><code>WAKE</code>: The key should wake the device when it is asleep. For historical reasons,
+ this flag behaves in the same manner as <code>WAKE_DROPPED</code> below.</li>
+<li><code>WAKE_DROPPED</code>: 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.</li>
+<li><code>SHIFT</code>: The key should be interpreted as if the SHIFT key were also pressed.</li>
+<li><code>CAPS_LOCK</code>: The key should be interpreted as if the CAPS LOCK key were also pressed.</li>
+<li><code>ALT</code>: The key should be interpreted as if the ALT key were also pressed.</li>
+<li><code>ALT_GR</code>: The key should be interpreted as if the RIGHT ALT key were also pressed.</li>
+<li><code>FUNCTION</code>: The key should be interpreted as if the FUNCTION key were also pressed.</li>
+<li><code>VIRTUAL</code>: 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.</li>
+<li><code>MENU</code>: Deprecated. Do not use.</li>
+<li><code>LAUNCHER</code>: Deprecated. Do not use.</li>
+</ul>
+<h3 id="axis-declarations">Axis Declarations</h3>
+<p>Axis declarations each consist of the keyword <code>axis</code> followed by a Linux axis code
+number, and qualifiers that control the behavior of the axis including at least
+one Android axis code name.</p>
+<h4 id="basic-axes">Basic Axes</h4>
+<p>A basic axis simply maps a Linux axis code to an Android axis code name.</p>
+<p>The following declaration maps <code>ABS_X</code> (indicated by <code>0x00</code>) to <code>AXIS_X</code> (indicated by <code>X</code>).</p>
+<pre><code>axis 0x00 X
+</code></pre>
+<p>In the above example, if the value of <code>ABS_X</code> is <code>5</code> then <code>AXIS_X</code> will be set to <code>5</code>.</p>
+<h4 id="split-axes">Split Axes</h4>
+<p>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.</p>
+<p>The following declaration maps values of the <code>ABS_Y</code> axis (indicated by <code>0x01</code>) to
+<code>AXIS_GAS</code> when less than <code>0x7f</code> or to <code>AXIS_BRAKE</code> when greater than <code>0x7f</code>.</p>
+<pre><code>axis 0x01 split 0x7f GAS BRAKE
+</code></pre>
+<p>In the above example, if the value of <code>ABS_Y</code> is <code>0x7d</code> then <code>AXIS_GAS</code> is set
+to <code>2</code> (<code>0x7f - 0x7d</code>) and <code>AXIS_BRAKE</code> is set to <code>0</code>. Conversely, if the value of
+<code>ABS_Y</code> is <code>0x83</code> then <code>AXIS_GAS</code> is set to <code>0</code> and <code>AXIS_BRAKE</code> is set to <code>4</code>
+(<code>0x83 - 0x7f</code>). Finally, if the value of <code>ABS_Y</code> equals the split value of <code>0x7f</code>
+then both <code>AXIS_GAS</code> and <code>AXIS_BRAKE</code> are set to <code>0</code>.</p>
+<h4 id="inverted-axes">Inverted Axes</h4>
+<p>An inverted axis inverts the sign of the axis value.</p>
+<p>The following declaration maps <code>ABS_RZ</code> (indicated by <code>0x05</code>) to <code>AXIS_BRAKE</code>
+(indicated by <code>BRAKE</code>), and inverts the output by negating it.</p>
+<pre><code>axis 0x05 invert AXIS_RZ
+</code></pre>
+<p>In the above example, if the value of <code>ABS_RZ</code> is <code>2</code> then <code>AXIS_RZ</code> is set to <code>-2</code>.</p>
+<h4 id="center-flat-position-option">Center Flat Position Option</h4>
+<p>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.</p>
+<p>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.</p>
+<p>To resolve this issue, an axis declaration may be followed by a <code>flat</code>
+option that specifies the value of the center flat position for the axis.</p>
+<pre><code>axis 0x03 Z flat 4096
+</code></pre>
+<p>In the above example, the center flat position is set to <code>4096</code>.</p>
+<h3 id="comments">Comments</h3>
+<p>Comment lines begin with '#' and continue to the end of the line. Like this:</p>
+<pre><code># A comment!
+</code></pre>
+<p>Blank lines are ignored.</p>
+<h3 id="examples">Examples</h3>
+<h4 id="keyboard">Keyboard</h4>
+<pre><code># 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...
+</code></pre>
+<h4 id="system-controls">System Controls</h4>
+<pre><code># 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
+</code></pre>
+<h4 id="capacitive-buttons">Capacitive Buttons</h4>
+<pre><code># 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
+</code></pre>
+<h4 id="headset-jack-media-controls">Headset Jack Media Controls</h4>
+<pre><code># 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
+</code></pre>
+<h4 id="joystick">Joystick</h4>
+<pre><code># 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
+</code></pre>
+<h2 id="wake-keys">Wake Keys</h2>
+<p>Wake keys are special keys that wake the device from sleep, such as the power key.</p>
+<p>By default, for internal keyboard devices, no key is a wake key. For external
+keyboard device, all keys are wake keys.</p>
+<p>To make a key be a wake key, set the <code>WAKE_DROPPED</code> flag in the key layout file
+for the keyboard device.</p>
+<p>Note that the <code>WindowManagerPolicy</code> 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
+<code>PhoneWindowManager.interceptKeyBeforeQueueing</code>.</p>
+<h2 id="virtual-soft-keys">Virtual Soft Keys</h2>
+<p>The input system provides special features for implementing virtual soft keys.</p>
+<p>There are three cases:</p>
+<ol>
+<li>
+<p>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.</p>
+<p>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.</p>
+</li>
+<li>
+<p>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.</p>
+<p>Refer to the section on <a href="/tech/input/touch-devices.html">Touch Devices</a>
+for more details about virtual key map files.</p>
+<p>The key layout file for the touch screen input device must specify the
+appropriate key mapping and include the <code>VIRTUAL</code> flag for each key.</p>
+</li>
+<li>
+<p>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.</p>
+<p>The key layout file for the capacitive button input device must specify the
+appropriate key mapping and include the <code>VIRTUAL</code> flag for each key.</p>
+</li>
+</ol>
+<p>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.</p>
+<p>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.</p>
+<p>To enable virtual soft key debouncing, we must do two things.</p>
+<p>First, we provide a key layout file for the touch screen or capacitive button
+input device with the <code>VIRTUAL</code> flag set for each key.</p>
+<pre><code>key 139 MENU VIRTUAL
+key 102 HOME VIRTUAL
+key 158 BACK VIRTUAL
+key 217 SEARCH VIRTUAL
+</code></pre>
+<p>Then, we set the value of the virtual key quiet time in a resource overlay
+for the framework <code>config.xml</code> resource.</p>
+<pre><code><!-- 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>
+</code></pre>
+<h2 id="validation">Validation</h2>
+<p>Make sure to validate your key layout files using the
+<a href="/tech/input/validate-keymaps.html">Validate Keymaps</a> tool.</p>
diff --git a/src/devices/tech/input/keyboard-devices.jd b/src/devices/tech/input/keyboard-devices.jd
new file mode 100644
index 0000000..aa968ac
--- /dev/null
+++ b/src/devices/tech/input/keyboard-devices.jd
@@ -0,0 +1,6438 @@
+page.title=Keyboard Devices
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Android supports a variety of keyboard devices including special function
+keypads (volume and power controls), compact embedded QWERTY keyboards,
+and fully featured PC-style external keyboards.</p>
+<p>This document decribes physical keyboards only. Refer to the Android SDK
+for information about soft keyboards (Input Method Editors).</p>
+<h2 id="keyboard-classification">Keyboard Classification</h2>
+<p>An input device is classified as a keyboard if either of the following
+conditions hold:</p>
+<ul>
+<li>
+<p>The input device reports the presence of any Linux key codes used on keyboards
+ including <code>0</code> through <code>0xff</code> or <code>KEY_OK</code> through <code>KEY_MAX</code>.</p>
+</li>
+<li>
+<p>The input device reports the presence of any Linux key codes used on joysticks
+ and gamepads including <code>BTN_0</code> through <code>BTN_9</code>, <code>BTN_TRIGGER</code> through <code>BTN_DEAD</code>,
+ or <code>BTN_A</code> through <code>BTN_THUMBR</code>.</p>
+</li>
+</ul>
+<p>Joysticks are currently classified as keyboards because joystick and gamepad buttons
+are reported by <code>EV_KEY</code> events in the same way keyboard keys are reported. Thus
+joysticks and gamepads also make use of key map files for configuration.
+Refer to the section on <a href="/tech/input/joystick-devices.html">Joystick Devices</a> for
+more information.</p>
+<p>Once an input device has been classified as a keyboard, the system loads the
+input device configuration file and keyboard layout for the keyboard.</p>
+<p>The system then tries to determine additional characteristics of the device.</p>
+<ul>
+<li>
+<p>If the input device has any keys that are mapped to <code>KEYCODE_Q</code>, then the
+ device is considered to have an alphabetic keypad (as opposed to numeric).
+ The alphabetic keypad capability is reported in the resource <code>Configuration</code>
+ object as <code>KEYBOARD_QWERTY</code>.</p>
+</li>
+<li>
+<p>If the input device has any keys that are mapped to <code>KEYCODE_DPAD_UP</code>,
+ <code>KEYCODE_DPAD_DOWN</code>, <code>KEYCODE_DPAD_LEFT</code>, <code>KEYCODE_DPAD_RIGHT</code>, and
+ <code>KEYCODE_DPAD_CENTER</code> (all must be present), then the device is considered
+ to have a directional keypad.
+ The directional keypad capability is reported in the resource <code>Configuration</code>
+ object as <code>NAVIGATION_DPAD</code>.</p>
+</li>
+<li>
+<p>If the input device has any keys that are mapped to <code>KEYCODE_BUTTON_A</code>
+ or other gamepad related keys, then the device is considered to have a gamepad.</p>
+</li>
+</ul>
+<h2 id="keyboard-driver-requirements">Keyboard Driver Requirements</h2>
+<ol>
+<li>
+<p>Keyboard drivers should only register key codes for the keys that they
+ actually support. Registering excess key codes may confuse the device
+ classification algorithm or cause the system to incorrectly detect
+ the supported keyboard capabilities of the device.</p>
+</li>
+<li>
+<p>Keyboard drivers should use <code>EV_KEY</code> to report key presses, using a value
+ of <code>0</code> to indicate that a key is released, a value of <code>1</code> to indicate that
+ a key is pressed, and a value greater than or equal to <code>2</code> to indicate that
+ the key is being repeated automatically.</p>
+</li>
+<li>
+<p>Android performs its own keyboard repeating. Auto-repeat functionality
+ should be disabled in the driver.</p>
+</li>
+<li>
+<p>Keyboard drivers may optionally indicate the HID usage or low-level scan
+ code by sending <code>EV_MSC</code> with <code>MSC_SCANCODE</code> and a valud indicating the usage
+ or scan code when the key is pressed. This information is not currently
+ used by Android.</p>
+</li>
+<li>
+<p>Keyboard drivers should support setting LED states when <code>EV_LED</code> is written
+ to the device. The <code>hid-input</code> driver handles this automatically.
+ At the time of this writing, Android uses <code>LED_CAPSLOCK</code>, <code>LED_SCROLLLOCK</code>,
+ and <code>LED_NUMLOCK</code>. These LEDs only need to be supported when the
+ keyboard actually has the associated indicator lights.</p>
+</li>
+<li>
+<p>Keyboard drivers for embedded keypads (for example, using a GPIO matrix)
+ should make sure to send <code>EV_KEY</code> events with a value of <code>0</code> for any keys that
+ are still pressed when the device is going to sleep. Otherwise keys might
+ get stuck down and will auto-repeat forever.</p>
+</li>
+</ol>
+<h2 id="keyboard-operation">Keyboard Operation</h2>
+<p>The following is a brief summary of the keyboard operation on Android.</p>
+<ol>
+<li>
+<p>The <code>EventHub</code> reads raw events from the <code>evdev</code> driver and maps Linux key codes
+ (sometimes referred to as scan codes) into Android key codes using the
+ keyboard's key layout map.</p>
+</li>
+<li>
+<p>The <code>InputReader</code> consumes the raw events and updates the meta key state.
+ For example, if the left shift key is pressed or released, the reader will
+ set or reset the <code>META_SHIFT_LEFT_ON</code> and <code>META_SHIFT_ON</code> bits accordingly.</p>
+</li>
+<li>
+<p>The <code>InputReader</code> notifies the <code>InputDispatcher</code> about the key event.</p>
+</li>
+<li>
+<p>The <code>InputDispatcher</code> asks the <code>WindowManagerPolicy</code> what to do with the key
+ event by calling <code>WindowManagerPolicy.interceptKeyBeforeQueueing</code>. This method
+ is part of a critical path that is responsible for waking the device when
+ certain keys are pressed. The <code>EventHub</code> effectively holds a wake lock
+ along this critical path to ensure that it will run to completion.</p>
+</li>
+<li>
+<p>If an <code>InputFilter</code> is currently in use, the <code>InputDispatcher</code> gives it a
+ chance to consume or transform the key. The <code>InputFilter</code> may be used to implement
+ low-level system-wide accessibility policies.</p>
+</li>
+<li>
+<p>The <code>InputDispatcher</code> enqueues the key for processing on the dispatch thread.</p>
+</li>
+<li>
+<p>When the <code>InputDispatcher</code> dequeues the key, it gives the <code>WindowManagerPolicy</code>
+ a second chance to intercept the key event by calling
+ <code>WindowManagerPolicy.interceptKeyBeforeDispatching</code>. This method handles system
+ shortcuts and other functions.</p>
+</li>
+<li>
+<p>The <code>InputDispatcher</code> then identifies the key event target (the focused window)
+ and waits for them to become ready. Then, the <code>InputDispatcher</code> delivers the
+ key event to the application.</p>
+</li>
+<li>
+<p>Inside the application, the key event propagates down the view hierarchy to
+ the focused view for pre-IME key dispatch.</p>
+</li>
+<li>
+<p>If the key event is not handled in the pre-IME dispatch and an IME is in use, the
+ key event is delivered to the IME.</p>
+</li>
+<li>
+<p>If the key event was not consumed by the IME, then the key event propagates
+ down the view hierarchy to the focused view for standard key dispatch.</p>
+</li>
+<li>
+<p>The application reports back to the <code>InputDispatcher</code> as to whether the key
+ event was consumed. If the event was not consumed, the <code>InputDispatcher</code>
+ calls <code>WindowManagerPolicy.dispatchUnhandledKey</code> to apply "fallback" behavior.
+ Depending on the fallback action, the key event dispatch cycle may be restarted
+ using a different key code. For example, if an application does not handle
+ <code>KEYCODE_ESCAPE</code>, the system may redispatch the key event as <code>KEYCODE_BACK</code> instead.</p>
+</li>
+</ol>
+<h2 id="keyboard-configuration">Keyboard Configuration</h2>
+<p>Keyboard behavior is determined by the keyboard's key layout, key character
+map and input device configuration.</p>
+<p>Refer to the following sections for more details about the files that
+participate in keyboard configuration:</p>
+<ul>
+<li><a href="/tech/input/key-layout-files.html">Key Layout Files</a></li>
+<li><a href="/tech/input/key-character-map-files.html">Key Character Map Files</a></li>
+<li><a href="/tech/input/input-device-configuration-files.html">Input Device Configuration Files</a></li>
+</ul>
+<h3 id="properties">Properties</h3>
+<p>The following input device configuration properties are used for keyboards.</p>
+<h4 id="keyboardlayout"><code>keyboard.layout</code></h4>
+<p><em>Definition:</em> <code>keyboard.layout</code> = <name></p>
+<p>Specifies the name of the key layout file associated with the input device,
+excluding the <code>.kl</code> extension. If this file is not found, the input system
+will use the default key layout instead.</p>
+<p>Spaces in the name are converted to underscores during lookup.</p>
+<p>Refer to the key layout file documentation for more details.</p>
+<h4 id="keyboardcharactermap"><code>keyboard.characterMap</code></h4>
+<p><em>Definition:</em> <code>keyboard.characterMap</code> = <name></p>
+<p>Specifies the name of the key character map file associated with the input device,
+excluding the <code>.kcm</code> extension. If this file is not found, the input system
+will use the default key character map instead.</p>
+<p>Spaces in the name are converted to underscores during lookup.</p>
+<p>Refer to the key character map file documentation for more details.</p>
+<h4 id="keyboardorientationaware"><code>keyboard.orientationAware</code></h4>
+<p><em>Definition:</em> <code>keyboard.orientationAware</code> = <code>0</code> | <code>1</code></p>
+<p>Specifies whether the keyboard should react to display orientation changes.</p>
+<ul>
+<li>
+<p>If the value is <code>1</code>, the directional keypad keys are rotated when the
+ associated display orientation changes.</p>
+</li>
+<li>
+<p>If the value is <code>0</code>, the keyboard is immune to display orientation changes.</p>
+</li>
+</ul>
+<p>The default value is <code>0</code>.</p>
+<p>Orientation awareness is used to support rotation of directional keypad keys,
+such as on the Motorola Droid. For example, when the device is rotated
+clockwise 90 degrees from its natural orientation, <code>KEYCODE_DPAD_UP</code> is
+remapped to produce <code>KEYCODE_DPAD_RIGHT</code> since the 'up' key ends up pointing
+'right' when the device is held in that orientation.</p>
+<h4 id="keyboardbuiltin"><code>keyboard.builtIn</code></h4>
+<p><em>Definition:</em> <code>keyboard.builtIn</code> = <code>0</code> | <code>1</code></p>
+<p>Specifies whether the keyboard is the built-in (physically attached)
+keyboard.</p>
+<p>The default value is <code>1</code> if the device name ends with <code>-keypad</code>, <code>0</code> otherwise.</p>
+<p>The built-in keyboard is always assigned a device id of <code>0</code>. Other keyboards
+that are not built-in are assigned unique non-zero device ids.</p>
+<p>Using an id of <code>0</code> for the built-in keyboard is important for maintaining
+compatibility with the <code>KeyCharacterMap.BUILT_IN_KEYBOARD</code> field, which specifies
+the id of the built-in keyboard and has a value of <code>0</code>. This field has been
+deprecated in the API but older applications might still be using it.</p>
+<p>A special-function keyboard (one whose key character map specifies a
+type of <code>SPECIAL_FUNCTION</code>) will never be registered as the built-in keyboard,
+regardless of the setting of this property. This is because a special-function
+keyboard is by definition not intended to be used for general purpose typing.</p>
+<h3 id="example-configurations">Example Configurations</h3>
+<pre><code># This is an example input device configuration file for a built-in
+# keyboard that has a DPad.
+
+# The keyboard is internal because it is part of the device.
+device.internal = 1
+
+# The keyboard is the default built-in keyboard so it should be assigned
+# an id of 0.
+keyboard.builtIn = 1
+
+# The keyboard includes a DPad which is mounted on the device. As the device
+# is rotated the orientation of the DPad rotates along with it, so the DPad must
+# be aware of the display orientation. This ensures that pressing 'up' on the
+# DPad always means 'up' from the perspective of the user, even when the entire
+# device has been rotated.
+keyboard.orientationAware = 1
+</code></pre>
+<h3 id="compatibility-notes">Compatibility Notes</h3>
+<p>Prior to Honeycomb, the keyboard input mapper did not use any configuration properties.
+All keyboards were assumed to be physically attached and orientation aware. The default
+key layout and key character map was named <code>qwerty</code> instead of <code>Generic</code>. The key
+character map format was also very different and the framework did not support
+PC-style full keyboards or external keyboards.</p>
+<p>When upgrading devices to Honeycomb, make sure to create or update the necessary
+configuration and key map files.</p>
+<h2 id="hid-usages-linux-key-codes-and-android-key-codes">HID Usages, Linux Key Codes and Android Key Codes</h2>
+<p>The system refers to keys using several different identifiers, depending on the
+layer of abstraction.</p>
+<p>For HID devices, each key has an associated HID usage. The Linux <code>hid-input</code>
+driver and related vendor and device-specific HID drivers are responsible
+for parsing HID reports and mapping HID usages to Linux key codes.</p>
+<p>As Android reads <code>EV_KEY</code> events from the Linux kernel, it translates each
+Linux key code into its corresponding Android key code according to the
+key layout file of the device.</p>
+<p>When the key event is dispatched to an application, the <code>android.view.KeyEvent</code>
+instance reports the Linux key code as the value of <code>getScanCode()</code> and the
+Android key code as the value of <code>getKeyCode()</code>. For the purposes of the
+framework, only the value of <code>getKeyCode()</code> is important.</p>
+<p>Note that the HID usage information is not used by Android itself or
+passed to applications.</p>
+<h2 id="code-tables">Code Tables</h2>
+<p>The following tables show how HID usages, Linux key codes and Android
+key codes are related to one another.</p>
+<p>The LKC column specifies the Linux key code in hexadecimal.</p>
+<p>The AKC column specifies the Android key code in hexadecimal.</p>
+<p>The Notes column refers to notes that are posted after the table.</p>
+<p>The Version column specifies the first version of the Android platform
+to have included this key in its default key map. Multiple rows are
+shown in cases where the default key map has changed between versions.
+The oldest version indicated is 1.6.</p>
+<ul>
+<li>
+<p>In Gingerbread (2.3) and earlier releases, the default key map was
+ <code>qwerty.kl</code>. This key map was only intended for use with the Android
+ Emulator and was not intended to be used to support arbitrary
+ external keyboards. Nevertheless, a few OEMs added Bluetooth
+ keyboard support to the platform and relied on <code>qwerty.kl</code> to
+ provide the necessary keyboard mappings. Consequently these
+ older mappings may be of interest to OEMs who are building
+ peripherals for these particular devices. Note that the mappings
+ are substantially different from the current ones, particularly
+ with respect to the treatment of the <code>HOME</code> key. It is recommended
+ that all new peripherals be developed according to the Honeycomb or more
+ recent key maps (ie. standard HID).</p>
+</li>
+<li>
+<p>As of Honeycomb (3.0), the default key map is <code>Generic.kl</code>.
+ This key map was designed to support full PC style keyboards.
+ Most functionality of standard HID keyboards should just work out
+ of the box.</p>
+</li>
+</ul>
+<p>The key code mapping may vary across versions of the Linux kernel and Android.
+When changes are known to have occurred in the Android default key maps,
+they are indicated in the version column.</p>
+<p>Device-specific HID drivers and key maps may apply different mappings
+than are indicated here.</p>
+<h3 id="hid-keyboard-and-keypad-page-0x07">HID Keyboard and Keypad Page (0x07)</h3>
+<table>
+<thead>
+<tr>
+<th>HID Usage</th>
+<th>HID Usage Name</th>
+<th>LKC</th>
+<th>Linux Key Code Name</th>
+<th>Version</th>
+<th>AKC</th>
+<th>Android Key Code Name</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>0x07 0x0001</td>
+<td>Keyboard Error Roll Over</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0002</td>
+<td>Keyboard POST Fail</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0003</td>
+<td>Keyboard Error Undefined</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0004</td>
+<td>Keyboard a and A</td>
+<td>0x001e</td>
+<td>KEY_A</td>
+<td>1.6</td>
+<td>0x001d</td>
+<td>KEYCODE_A</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0005</td>
+<td>Keyboard b and B</td>
+<td>0x0030</td>
+<td>KEY_B</td>
+<td>1.6</td>
+<td>0x001e</td>
+<td>KEYCODE_B</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0006</td>
+<td>Keyboard c and C</td>
+<td>0x002e</td>
+<td>KEY_C</td>
+<td>1.6</td>
+<td>0x001f</td>
+<td>KEYCODE_C</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0007</td>
+<td>Keyboard d and D</td>
+<td>0x0020</td>
+<td>KEY_D</td>
+<td>1.6</td>
+<td>0x0020</td>
+<td>KEYCODE_D</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0008</td>
+<td>Keyboard e and E</td>
+<td>0x0012</td>
+<td>KEY_E</td>
+<td>1.6</td>
+<td>0x0021</td>
+<td>KEYCODE_E</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0009</td>
+<td>Keyboard f and F</td>
+<td>0x0021</td>
+<td>KEY_F</td>
+<td>1.6</td>
+<td>0x0022</td>
+<td>KEYCODE_F</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000a</td>
+<td>Keyboard g and G</td>
+<td>0x0022</td>
+<td>KEY_G</td>
+<td>1.6</td>
+<td>0x0023</td>
+<td>KEYCODE_G</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000b</td>
+<td>Keyboard h and H</td>
+<td>0x0023</td>
+<td>KEY_H</td>
+<td>1.6</td>
+<td>0x0024</td>
+<td>KEYCODE_H</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000c</td>
+<td>Keyboard i and I</td>
+<td>0x0017</td>
+<td>KEY_I</td>
+<td>1.6</td>
+<td>0x0025</td>
+<td>KEYCODE_I</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000d</td>
+<td>Keyboard j and J</td>
+<td>0x0024</td>
+<td>KEY_J</td>
+<td>1.6</td>
+<td>0x0026</td>
+<td>KEYCODE_J</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000e</td>
+<td>Keyboard k and K</td>
+<td>0x0025</td>
+<td>KEY_K</td>
+<td>1.6</td>
+<td>0x0027</td>
+<td>KEYCODE_K</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x000f</td>
+<td>Keyboard l and L</td>
+<td>0x0026</td>
+<td>KEY_L</td>
+<td>1.6</td>
+<td>0x0028</td>
+<td>KEYCODE_L</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0010</td>
+<td>Keyboard m and M</td>
+<td>0x0032</td>
+<td>KEY_M</td>
+<td>1.6</td>
+<td>0x0029</td>
+<td>KEYCODE_M</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0011</td>
+<td>Keyboard n and N</td>
+<td>0x0031</td>
+<td>KEY_N</td>
+<td>1.6</td>
+<td>0x002a</td>
+<td>KEYCODE_N</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0012</td>
+<td>Keyboard o and O</td>
+<td>0x0018</td>
+<td>KEY_O</td>
+<td>1.6</td>
+<td>0x002b</td>
+<td>KEYCODE_O</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0013</td>
+<td>Keyboard p and P</td>
+<td>0x0019</td>
+<td>KEY_P</td>
+<td>1.6</td>
+<td>0x002c</td>
+<td>KEYCODE_P</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0014</td>
+<td>Keyboard q and Q</td>
+<td>0x0010</td>
+<td>KEY_Q</td>
+<td>1.6</td>
+<td>0x002d</td>
+<td>KEYCODE_Q</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0015</td>
+<td>Keyboard r and R</td>
+<td>0x0013</td>
+<td>KEY_R</td>
+<td>1.6</td>
+<td>0x002e</td>
+<td>KEYCODE_R</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0016</td>
+<td>Keyboard s and S</td>
+<td>0x001f</td>
+<td>KEY_S</td>
+<td>1.6</td>
+<td>0x002f</td>
+<td>KEYCODE_S</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0017</td>
+<td>Keyboard t and T</td>
+<td>0x0014</td>
+<td>KEY_T</td>
+<td>1.6</td>
+<td>0x0030</td>
+<td>KEYCODE_T</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0018</td>
+<td>Keyboard u and U</td>
+<td>0x0016</td>
+<td>KEY_U</td>
+<td>1.6</td>
+<td>0x0031</td>
+<td>KEYCODE_U</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0019</td>
+<td>Keyboard v and V</td>
+<td>0x002f</td>
+<td>KEY_V</td>
+<td>1.6</td>
+<td>0x0032</td>
+<td>KEYCODE_V</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001a</td>
+<td>Keyboard w and W</td>
+<td>0x0011</td>
+<td>KEY_W</td>
+<td>1.6</td>
+<td>0x0033</td>
+<td>KEYCODE_W</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001b</td>
+<td>Keyboard x and X</td>
+<td>0x002d</td>
+<td>KEY_X</td>
+<td>1.6</td>
+<td>0x0034</td>
+<td>KEYCODE_X</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001c</td>
+<td>Keyboard y and Y</td>
+<td>0x0015</td>
+<td>KEY_Y</td>
+<td>1.6</td>
+<td>0x0035</td>
+<td>KEYCODE_Y</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001d</td>
+<td>Keyboard z and Z</td>
+<td>0x002c</td>
+<td>KEY_Z</td>
+<td>1.6</td>
+<td>0x0036</td>
+<td>KEYCODE_Z</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001e</td>
+<td>Keyboard 1 and !</td>
+<td>0x0002</td>
+<td>KEY_1</td>
+<td>1.6</td>
+<td>0x0008</td>
+<td>KEYCODE_1</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x001f</td>
+<td>Keyboard 2 and @</td>
+<td>0x0003</td>
+<td>KEY_2</td>
+<td>1.6</td>
+<td>0x0009</td>
+<td>KEYCODE_2</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0020</td>
+<td>Keyboard 3 and #</td>
+<td>0x0004</td>
+<td>KEY_3</td>
+<td>1.6</td>
+<td>0x000a</td>
+<td>KEYCODE_3</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0021</td>
+<td>Keyboard 4 and $</td>
+<td>0x0005</td>
+<td>KEY_4</td>
+<td>1.6</td>
+<td>0x000b</td>
+<td>KEYCODE_4</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0022</td>
+<td>Keyboard 5 and %</td>
+<td>0x0006</td>
+<td>KEY_5</td>
+<td>1.6</td>
+<td>0x000c</td>
+<td>KEYCODE_5</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0023</td>
+<td>Keyboard 6 and ^</td>
+<td>0x0007</td>
+<td>KEY_6</td>
+<td>1.6</td>
+<td>0x000d</td>
+<td>KEYCODE_6</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0024</td>
+<td>Keyboard 7 and &</td>
+<td>0x0008</td>
+<td>KEY_7</td>
+<td>1.6</td>
+<td>0x000e</td>
+<td>KEYCODE_7</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0025</td>
+<td>Keyboard 8 and *</td>
+<td>0x0009</td>
+<td>KEY_8</td>
+<td>1.6</td>
+<td>0x000f</td>
+<td>KEYCODE_8</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0026</td>
+<td>Keyboard 9 and (</td>
+<td>0x000a</td>
+<td>KEY_9</td>
+<td>1.6</td>
+<td>0x0010</td>
+<td>KEYCODE_9</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0027</td>
+<td>Keyboard 0 and )</td>
+<td>0x000b</td>
+<td>KEY_0</td>
+<td>1.6</td>
+<td>0x0007</td>
+<td>KEYCODE_0</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0028</td>
+<td>Keyboard Return (ENTER)</td>
+<td>0x001c</td>
+<td>KEY_ENTER</td>
+<td>1.6</td>
+<td>0x0042</td>
+<td>KEYCODE_ENTER</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0029</td>
+<td>Keyboard ESCAPE</td>
+<td>0x0001</td>
+<td>KEY_ESC</td>
+<td>3.0</td>
+<td>0x006f</td>
+<td>KEYCODE_ESCAPE</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>2.3</td>
+<td>0x0004</td>
+<td>KEYCODE_BACK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x002a</td>
+<td>Keyboard DELETE (Backspace)</td>
+<td>0x000e</td>
+<td>KEY_BACKSPACE</td>
+<td>1.6</td>
+<td>0x0043</td>
+<td>KEYCODE_DEL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x002b</td>
+<td>Keyboard Tab</td>
+<td>0x000f</td>
+<td>KEY_TAB</td>
+<td>1.6</td>
+<td>0x003d</td>
+<td>KEYCODE_TAB</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x002c</td>
+<td>Keyboard Spacebar</td>
+<td>0x0039</td>
+<td>KEY_SPACE</td>
+<td>1.6</td>
+<td>0x003e</td>
+<td>KEYCODE_SPACE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x002d</td>
+<td>Keyboard - and _</td>
+<td>0x000c</td>
+<td>KEY_MINUS</td>
+<td>1.6</td>
+<td>0x0045</td>
+<td>KEYCODE_MINUS</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x002e</td>
+<td>Keyboard = and +</td>
+<td>0x000d</td>
+<td>KEY_EQUAL</td>
+<td>1.6</td>
+<td>0x0046</td>
+<td>KEYCODE_EQUALS</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x002f</td>
+<td>Keyboard [ and {</td>
+<td>0x001a</td>
+<td>KEY_LEFTBRACE</td>
+<td>1.6</td>
+<td>0x0047</td>
+<td>KEYCODE_LEFT_BRACKET</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0030</td>
+<td>Keyboard ] and }</td>
+<td>0x001b</td>
+<td>KEY_RIGHTBRACE</td>
+<td>1.6</td>
+<td>0x0048</td>
+<td>KEYCODE_RIGHT_BRACKET</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0031</td>
+<td>Keyboard \ and |</td>
+<td>0x002b</td>
+<td>KEY_BACKSLASH</td>
+<td>1.6</td>
+<td>0x0049</td>
+<td>KEYCODE_BACKSLASH</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0032</td>
+<td>Keyboard Non-US # and ~</td>
+<td>0x002b</td>
+<td>KEY_BACKSLASH</td>
+<td>1.6</td>
+<td>0x0049</td>
+<td>KEYCODE_BACKSLASH</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0033</td>
+<td>Keyboard ; and :</td>
+<td>0x0027</td>
+<td>KEY_SEMICOLON</td>
+<td>1.6</td>
+<td>0x004a</td>
+<td>KEYCODE_SEMICOLON</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0034</td>
+<td>Keyboard ' and "</td>
+<td>0x0028</td>
+<td>KEY_APOSTROPHE</td>
+<td>1.6</td>
+<td>0x004b</td>
+<td>KEYCODE_APOSTROPHE</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0035</td>
+<td>Keyboard ` and ~</td>
+<td>0x0029</td>
+<td>KEY_GRAVE</td>
+<td>3.0</td>
+<td>0x0044</td>
+<td>KEYCODE_GRAVE</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0036</td>
+<td>Keyboard , and <</td>
+<td>0x0033</td>
+<td>KEY_COMMA</td>
+<td>1.6</td>
+<td>0x0037</td>
+<td>KEYCODE_COMMA</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0037</td>
+<td>Keyboard . and ></td>
+<td>0x0034</td>
+<td>KEY_DOT</td>
+<td>1.6</td>
+<td>0x0038</td>
+<td>KEYCODE_PERIOD</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0038</td>
+<td>Keyboard / and ?</td>
+<td>0x0035</td>
+<td>KEY_SLASH</td>
+<td>1.6</td>
+<td>0x004c</td>
+<td>KEYCODE_SLASH</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0039</td>
+<td>Keyboard Caps Lock</td>
+<td>0x003a</td>
+<td>KEY_CAPSLOCK</td>
+<td>3.0</td>
+<td>0x0073</td>
+<td>KEYCODE_CAPS_LOCK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003a</td>
+<td>Keyboard F1</td>
+<td>0x003b</td>
+<td>KEY_F1</td>
+<td>3.0</td>
+<td>0x0083</td>
+<td>KEYCODE_F1</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0052</td>
+<td>KEYCODE_MENU</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003b</td>
+<td>Keyboard F2</td>
+<td>0x003c</td>
+<td>KEY_F2</td>
+<td>3.0</td>
+<td>0x0084</td>
+<td>KEYCODE_F2</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0002</td>
+<td>KEYCODE_SOFT_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003c</td>
+<td>Keyboard F3</td>
+<td>0x003d</td>
+<td>KEY_F3</td>
+<td>3.0</td>
+<td>0x0085</td>
+<td>KEYCODE_F3</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0005</td>
+<td>KEYCODE_CALL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003d</td>
+<td>Keyboard F4</td>
+<td>0x003e</td>
+<td>KEY_F4</td>
+<td>3.0</td>
+<td>0x0086</td>
+<td>KEYCODE_F4</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0006</td>
+<td>KEYCODE_ENDCALL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003e</td>
+<td>Keyboard F5</td>
+<td>0x003f</td>
+<td>KEY_F5</td>
+<td>3.0</td>
+<td>0x0087</td>
+<td>KEYCODE_F5</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x003f</td>
+<td>Keyboard F6</td>
+<td>0x0040</td>
+<td>KEY_F6</td>
+<td>3.0</td>
+<td>0x0088</td>
+<td>KEYCODE_F6</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0040</td>
+<td>Keyboard F7</td>
+<td>0x0041</td>
+<td>KEY_F7</td>
+<td>3.0</td>
+<td>0x0089</td>
+<td>KEYCODE_F7</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0041</td>
+<td>Keyboard F8</td>
+<td>0x0042</td>
+<td>KEY_F8</td>
+<td>3.0</td>
+<td>0x008a</td>
+<td>KEYCODE_F8</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0042</td>
+<td>Keyboard F9</td>
+<td>0x0043</td>
+<td>KEY_F9</td>
+<td>3.0</td>
+<td>0x008b</td>
+<td>KEYCODE_F9</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0043</td>
+<td>Keyboard F10</td>
+<td>0x0044</td>
+<td>KEY_F10</td>
+<td>3.0</td>
+<td>0x008c</td>
+<td>KEYCODE_F10</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>2.3</td>
+<td>0x0052</td>
+<td>KEYCODE_MENU</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0044</td>
+<td>Keyboard F11</td>
+<td>0x0057</td>
+<td>KEY_F11</td>
+<td>3.0</td>
+<td>0x008d</td>
+<td>KEYCODE_F11</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0045</td>
+<td>Keyboard F12</td>
+<td>0x0058</td>
+<td>KEY_F12</td>
+<td>3.0</td>
+<td>0x008e</td>
+<td>KEYCODE_F12</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0046</td>
+<td>Keyboard Print Screen</td>
+<td>0x0063</td>
+<td>KEY_SYSRQ</td>
+<td>3.0</td>
+<td>0x0078</td>
+<td>KEYCODE_SYSRQ</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0047</td>
+<td>Keyboard Scroll Lock</td>
+<td>0x0046</td>
+<td>KEY_SCROLLLOCK</td>
+<td>3.0</td>
+<td>0x0074</td>
+<td>KEYCODE_SCROLL_LOCK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0048</td>
+<td>Keyboard Pause</td>
+<td>0x0077</td>
+<td>KEY_PAUSE</td>
+<td>3.0</td>
+<td>0x0079</td>
+<td>KEYCODE_BREAK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0049</td>
+<td>Keyboard Insert</td>
+<td>0x006e</td>
+<td>KEY_INSERT</td>
+<td>3.0</td>
+<td>0x007c</td>
+<td>KEYCODE_INSERT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004a</td>
+<td>Keyboard Home</td>
+<td>0x0066</td>
+<td>KEY_HOME</td>
+<td>3.0</td>
+<td>0x007a</td>
+<td>KEYCODE_MOVE_HOME</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0003</td>
+<td>KEYCODE_HOME</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004b</td>
+<td>Keyboard Page Up</td>
+<td>0x0068</td>
+<td>KEY_PAGEUP</td>
+<td>3.0</td>
+<td>0x005c</td>
+<td>KEYCODE_PAGE_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004c</td>
+<td>Keyboard Delete Forward</td>
+<td>0x006f</td>
+<td>KEY_DELETE</td>
+<td>3.0</td>
+<td>0x0070</td>
+<td>KEYCODE_FORWARD_DEL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004d</td>
+<td>Keyboard End</td>
+<td>0x006b</td>
+<td>KEY_END</td>
+<td>3.0</td>
+<td>0x007b</td>
+<td>KEYCODE_MOVE_END</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0006</td>
+<td>KEYCODE_ENDCALL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004e</td>
+<td>Keyboard Page Down</td>
+<td>0x006d</td>
+<td>KEY_PAGEDOWN</td>
+<td>3.0</td>
+<td>0x005d</td>
+<td>KEYCODE_PAGE_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x004f</td>
+<td>Keyboard Right Arrow</td>
+<td>0x006a</td>
+<td>KEY_RIGHT</td>
+<td>1.6</td>
+<td>0x0016</td>
+<td>KEYCODE_DPAD_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0050</td>
+<td>Keyboard Left Arrow</td>
+<td>0x0069</td>
+<td>KEY_LEFT</td>
+<td>1.6</td>
+<td>0x0015</td>
+<td>KEYCODE_DPAD_LEFT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0051</td>
+<td>Keyboard Down Arrow</td>
+<td>0x006c</td>
+<td>KEY_DOWN</td>
+<td>1.6</td>
+<td>0x0014</td>
+<td>KEYCODE_DPAD_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0052</td>
+<td>Keyboard Up Arrow</td>
+<td>0x0067</td>
+<td>KEY_UP</td>
+<td>1.6</td>
+<td>0x0013</td>
+<td>KEYCODE_DPAD_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0053</td>
+<td>Keyboard Num Lock and Clear</td>
+<td>0x0045</td>
+<td>KEY_NUMLOCK</td>
+<td>3.0</td>
+<td>0x008f</td>
+<td>KEYCODE_NUM_LOCK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0054</td>
+<td>Keypad /</td>
+<td>0x0062</td>
+<td>KEY_KPSLASH</td>
+<td>3.0</td>
+<td>0x009a</td>
+<td>KEYCODE_NUMPAD_DIVIDE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0055</td>
+<td>Keypad *</td>
+<td>0x0037</td>
+<td>KEY_KPASTERISK</td>
+<td>3.0</td>
+<td>0x009b</td>
+<td>KEYCODE_NUMPAD_MULTIPLY</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0056</td>
+<td>Keypad -</td>
+<td>0x004a</td>
+<td>KEY_KPMINUS</td>
+<td>3.0</td>
+<td>0x009c</td>
+<td>KEYCODE_NUMPAD_SUBTRACT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0057</td>
+<td>Keypad +</td>
+<td>0x004e</td>
+<td>KEY_KPPLUS</td>
+<td>3.0</td>
+<td>0x009d</td>
+<td>KEYCODE_NUMPAD_ADD</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0058</td>
+<td>Keypad ENTER</td>
+<td>0x0060</td>
+<td>KEY_KPENTER</td>
+<td>3.0</td>
+<td>0x00a0</td>
+<td>KEYCODE_NUMPAD_ENTER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0059</td>
+<td>Keypad 1 and End</td>
+<td>0x004f</td>
+<td>KEY_KP1</td>
+<td>3.0</td>
+<td>0x0091</td>
+<td>KEYCODE_NUMPAD_1</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005a</td>
+<td>Keypad 2 and Down Arrow</td>
+<td>0x0050</td>
+<td>KEY_KP2</td>
+<td>3.0</td>
+<td>0x0092</td>
+<td>KEYCODE_NUMPAD_2</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005b</td>
+<td>Keypad 3 and PageDn</td>
+<td>0x0051</td>
+<td>KEY_KP3</td>
+<td>3.0</td>
+<td>0x0093</td>
+<td>KEYCODE_NUMPAD_3</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005c</td>
+<td>Keypad 4 and Left Arrow</td>
+<td>0x004b</td>
+<td>KEY_KP4</td>
+<td>3.0</td>
+<td>0x0094</td>
+<td>KEYCODE_NUMPAD_4</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005d</td>
+<td>Keypad 5</td>
+<td>0x004c</td>
+<td>KEY_KP5</td>
+<td>3.0</td>
+<td>0x0095</td>
+<td>KEYCODE_NUMPAD_5</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005e</td>
+<td>Keypad 6 and Right Arrow</td>
+<td>0x004d</td>
+<td>KEY_KP6</td>
+<td>3.0</td>
+<td>0x0096</td>
+<td>KEYCODE_NUMPAD_6</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x005f</td>
+<td>Keypad 7 and Home</td>
+<td>0x0047</td>
+<td>KEY_KP7</td>
+<td>3.0</td>
+<td>0x0097</td>
+<td>KEYCODE_NUMPAD_7</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0060</td>
+<td>Keypad 8 and Up Arrow</td>
+<td>0x0048</td>
+<td>KEY_KP8</td>
+<td>3.0</td>
+<td>0x0098</td>
+<td>KEYCODE_NUMPAD_8</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0061</td>
+<td>Keypad 9 and Page Up</td>
+<td>0x0049</td>
+<td>KEY_KP9</td>
+<td>3.0</td>
+<td>0x0099</td>
+<td>KEYCODE_NUMPAD_9</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0062</td>
+<td>Keypad 0 and Insert</td>
+<td>0x0052</td>
+<td>KEY_KP0</td>
+<td>3.0</td>
+<td>0x0090</td>
+<td>KEYCODE_NUMPAD_0</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0063</td>
+<td>Keypad . and Delete</td>
+<td>0x0053</td>
+<td>KEY_KPDOT</td>
+<td>3.0</td>
+<td>0x009e</td>
+<td>KEYCODE_NUMPAD_DOT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0064</td>
+<td>Keyboard Non-US \ and |</td>
+<td>0x0056</td>
+<td>KEY_102ND</td>
+<td>4.0</td>
+<td>0x0049</td>
+<td>KEYCODE_BACKSLASH</td>
+<td>1</td>
+</tr>
+<tr>
+<td>0x07 0x0065</td>
+<td>Keyboard Application</td>
+<td>0x007f</td>
+<td>KEY_COMPOSE</td>
+<td>3.0</td>
+<td>0x0052</td>
+<td>KEYCODE_MENU</td>
+<td></td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>""</td>
+<td>1.6</td>
+<td>0x0054</td>
+<td>KEYCODE_SEARCH</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0066</td>
+<td>Keyboard Power</td>
+<td>0x0074</td>
+<td>KEY_POWER</td>
+<td>1.6</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0067</td>
+<td>Keypad =</td>
+<td>0x0075</td>
+<td>KEY_KPEQUAL</td>
+<td>3.0</td>
+<td>0x00a1</td>
+<td>KEYCODE_NUMPAD_EQUALS</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0068</td>
+<td>Keyboard F13</td>
+<td>0x00b7</td>
+<td>KEY_F13</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0069</td>
+<td>Keyboard F14</td>
+<td>0x00b8</td>
+<td>KEY_F14</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006a</td>
+<td>Keyboard F15</td>
+<td>0x00b9</td>
+<td>KEY_F15</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006b</td>
+<td>Keyboard F16</td>
+<td>0x00ba</td>
+<td>KEY_F16</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006c</td>
+<td>Keyboard F17</td>
+<td>0x00bb</td>
+<td>KEY_F17</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006d</td>
+<td>Keyboard F18</td>
+<td>0x00bc</td>
+<td>KEY_F18</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006e</td>
+<td>Keyboard F19</td>
+<td>0x00bd</td>
+<td>KEY_F19</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x006f</td>
+<td>Keyboard F20</td>
+<td>0x00be</td>
+<td>KEY_F20</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0070</td>
+<td>Keyboard F21</td>
+<td>0x00bf</td>
+<td>KEY_F21</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0071</td>
+<td>Keyboard F22</td>
+<td>0x00c0</td>
+<td>KEY_F22</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0072</td>
+<td>Keyboard F23</td>
+<td>0x00c1</td>
+<td>KEY_F23</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0073</td>
+<td>Keyboard F24</td>
+<td>0x00c2</td>
+<td>KEY_F24</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0074</td>
+<td>Keyboard Execute</td>
+<td>0x0086</td>
+<td>KEY_OPEN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0075</td>
+<td>Keyboard Help</td>
+<td>0x008a</td>
+<td>KEY_HELP</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0076</td>
+<td>Keyboard Menu</td>
+<td>0x0082</td>
+<td>KEY_PROPS</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0077</td>
+<td>Keyboard Select</td>
+<td>0x0084</td>
+<td>KEY_FRONT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0078</td>
+<td>Keyboard Stop</td>
+<td>0x0080</td>
+<td>KEY_STOP</td>
+<td>3.0</td>
+<td>0x0056</td>
+<td>KEYCODE_MEDIA_STOP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0079</td>
+<td>Keyboard Again</td>
+<td>0x0081</td>
+<td>KEY_AGAIN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007a</td>
+<td>Keyboard Undo</td>
+<td>0x0083</td>
+<td>KEY_UNDO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007b</td>
+<td>Keyboard Cut</td>
+<td>0x0089</td>
+<td>KEY_CUT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007c</td>
+<td>Keyboard Copy</td>
+<td>0x0085</td>
+<td>KEY_COPY</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007d</td>
+<td>Keyboard Paste</td>
+<td>0x0087</td>
+<td>KEY_PASTE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007e</td>
+<td>Keyboard Find</td>
+<td>0x0088</td>
+<td>KEY_FIND</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x007f</td>
+<td>Keyboard Mute</td>
+<td>0x0071</td>
+<td>KEY_MUTE</td>
+<td>3.0</td>
+<td>0x00a4</td>
+<td>KEYCODE_VOLUME_MUTE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0080</td>
+<td>Keyboard Volume Up</td>
+<td>0x0073</td>
+<td>KEY_VOLUMEUP</td>
+<td>1.6</td>
+<td>0x0018</td>
+<td>KEYCODE_VOLUME_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0081</td>
+<td>Keyboard Volume Down</td>
+<td>0x0072</td>
+<td>KEY_VOLUMEDOWN</td>
+<td>1.6</td>
+<td>0x0019</td>
+<td>KEYCODE_VOLUME_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0082</td>
+<td>Keyboard Locking Caps Lock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0083</td>
+<td>Keyboard Locking Num Lock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0084</td>
+<td>Keyboard Locking Scroll Lock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0085</td>
+<td>Keypad Comma</td>
+<td>0x0079</td>
+<td>KEY_KPCOMMA</td>
+<td>3.0</td>
+<td>0x009f</td>
+<td>KEYCODE_NUMPAD_COMMA</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0086</td>
+<td>Keypad Equal Sign</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0087</td>
+<td>Keyboard International1</td>
+<td>0x0059</td>
+<td>KEY_RO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0088</td>
+<td>Keyboard International2</td>
+<td>0x005d</td>
+<td>KEY_KATAKANAHIRAGANA</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0089</td>
+<td>Keyboard International3</td>
+<td>0x007c</td>
+<td>KEY_YEN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008a</td>
+<td>Keyboard International4</td>
+<td>0x005c</td>
+<td>KEY_HENKAN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008b</td>
+<td>Keyboard International5</td>
+<td>0x005e</td>
+<td>KEY_MUHENKAN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008c</td>
+<td>Keyboard International6</td>
+<td>0x005f</td>
+<td>KEY_KPJPCOMMA</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008d</td>
+<td>Keyboard International7</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008e</td>
+<td>Keyboard International8</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x008f</td>
+<td>Keyboard International9</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0090</td>
+<td>Keyboard LANG1</td>
+<td>0x007a</td>
+<td>KEY_HANGEUL</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0091</td>
+<td>Keyboard LANG2</td>
+<td>0x007b</td>
+<td>KEY_HANJA</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0092</td>
+<td>Keyboard LANG3</td>
+<td>0x005a</td>
+<td>KEY_KATAKANA</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0093</td>
+<td>Keyboard LANG4</td>
+<td>0x005b</td>
+<td>KEY_HIRAGANA</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0094</td>
+<td>Keyboard LANG5</td>
+<td>0x0055</td>
+<td>KEY_ZENKAKUHANKAKU</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0095</td>
+<td>Keyboard LANG6</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0096</td>
+<td>Keyboard LANG7</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0097</td>
+<td>Keyboard LANG8</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0098</td>
+<td>Keyboard LANG9</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x0099</td>
+<td>Keyboard Alternate Erase</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009a</td>
+<td>Keyboard SysReq/Attention</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009b</td>
+<td>Keyboard Cancel</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009c</td>
+<td>Keyboard Clear</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009d</td>
+<td>Keyboard Prior</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009e</td>
+<td>Keyboard Return</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x009f</td>
+<td>Keyboard Separator</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00a0</td>
+<td>Keyboard Out</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00a1</td>
+<td>Keyboard Oper</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00a2</td>
+<td>Keyboard Clear/Again</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00a3</td>
+<td>Keyboard CrSel/Props</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00a4</td>
+<td>Keyboard ExSel</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b0</td>
+<td>Keypad 00</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b1</td>
+<td>Keypad 000</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b2</td>
+<td>Thousands Separator</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b3</td>
+<td>Decimal Separator</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b4</td>
+<td>Currency Unit</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b5</td>
+<td>Currency Sub-unit</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b6</td>
+<td>Keypad (</td>
+<td>0x00b3</td>
+<td>KEY_KPLEFTPAREN</td>
+<td>3.0</td>
+<td>0x00a2</td>
+<td>KEYCODE_NUMPAD_LEFT_PAREN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b7</td>
+<td>Keypad )</td>
+<td>0x00b4</td>
+<td>KEY_KPRIGHTPAREN</td>
+<td>3.0</td>
+<td>0x00a3</td>
+<td>KEYCODE_NUMPAD_RIGHT_PAREN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b8</td>
+<td>Keypad {</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00b9</td>
+<td>Keypad }</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ba</td>
+<td>Keypad Tab</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00bb</td>
+<td>Keypad Backspace</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00bc</td>
+<td>Keypad A</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00bd</td>
+<td>Keypad B</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00be</td>
+<td>Keypad C</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00bf</td>
+<td>Keypad D</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c0</td>
+<td>Keypad E</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c1</td>
+<td>Keypad F</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c2</td>
+<td>Keypad XOR</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c3</td>
+<td>Keypad ^</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c4</td>
+<td>Keypad %</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c5</td>
+<td>Keypad <</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c6</td>
+<td>Keypad ></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c7</td>
+<td>Keypad &</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c8</td>
+<td>Keypad &&</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00c9</td>
+<td>Keypad |</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ca</td>
+<td>Keypad ||</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00cb</td>
+<td>Keypad :</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00cc</td>
+<td>Keypad #</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00cd</td>
+<td>Keypad Space</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ce</td>
+<td>Keypad @</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00cf</td>
+<td>Keypad !</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d0</td>
+<td>Keypad Memory Store</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d1</td>
+<td>Keypad Memory Recall</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d2</td>
+<td>Keypad Memory Clear</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d3</td>
+<td>Keypad Memory Add</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d4</td>
+<td>Keypad Memory Subtract</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d5</td>
+<td>Keypad Memory Multiply</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d6</td>
+<td>Keypad Memory Divide</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d7</td>
+<td>Keypad +/-</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d8</td>
+<td>Keypad Clear</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00d9</td>
+<td>Keypad Clear Entry</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00da</td>
+<td>Keypad Binary</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00db</td>
+<td>Keypad Octal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00dc</td>
+<td>Keypad Decimal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00dd</td>
+<td>Keypad Hexadecimal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e0</td>
+<td>Keyboard Left Control</td>
+<td>0x001d</td>
+<td>KEY_LEFTCTRL</td>
+<td>3.0</td>
+<td>0x0071</td>
+<td>KEYCODE_CTRL_LEFT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e1</td>
+<td>Keyboard Left Shift</td>
+<td>0x002a</td>
+<td>KEY_LEFTSHIFT</td>
+<td>1.6</td>
+<td>0x003b</td>
+<td>KEYCODE_SHIFT_LEFT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e2</td>
+<td>Keyboard Left Alt</td>
+<td>0x0038</td>
+<td>KEY_LEFTALT</td>
+<td>1.6</td>
+<td>0x0039</td>
+<td>KEYCODE_ALT_LEFT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e3</td>
+<td>Keyboard Left GUI</td>
+<td>0x007d</td>
+<td>KEY_LEFTMETA</td>
+<td>3.0</td>
+<td>0x0075</td>
+<td>KEYCODE_META_LEFT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e4</td>
+<td>Keyboard Right Control</td>
+<td>0x0061</td>
+<td>KEY_RIGHTCTRL</td>
+<td>3.0</td>
+<td>0x0072</td>
+<td>KEYCODE_CTRL_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e5</td>
+<td>Keyboard Right Shift</td>
+<td>0x0036</td>
+<td>KEY_RIGHTSHIFT</td>
+<td>1.6</td>
+<td>0x003c</td>
+<td>KEYCODE_SHIFT_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e6</td>
+<td>Keyboard Right Alt</td>
+<td>0x0064</td>
+<td>KEY_RIGHTALT</td>
+<td>1.6</td>
+<td>0x003a</td>
+<td>KEYCODE_ALT_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e7</td>
+<td>Keyboard Right GUI</td>
+<td>0x007e</td>
+<td>KEY_RIGHTMETA</td>
+<td>3.0</td>
+<td>0x0076</td>
+<td>KEYCODE_META_RIGHT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e8</td>
+<td></td>
+<td>0x00a4</td>
+<td>KEY_PLAYPAUSE</td>
+<td>3.0</td>
+<td>0x0055</td>
+<td>KEYCODE_MEDIA_PLAY_PAUSE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00e9</td>
+<td></td>
+<td>0x00a6</td>
+<td>KEY_STOPCD</td>
+<td>3.0</td>
+<td>0x0056</td>
+<td>KEYCODE_MEDIA_STOP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ea</td>
+<td></td>
+<td>0x00a5</td>
+<td>KEY_PREVIOUSSONG</td>
+<td>3.0</td>
+<td>0x0058</td>
+<td>KEYCODE_MEDIA_PREVIOUS</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00eb</td>
+<td></td>
+<td>0x00a3</td>
+<td>KEY_NEXTSONG</td>
+<td>3.0</td>
+<td>0x0057</td>
+<td>KEYCODE_MEDIA_NEXT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ec</td>
+<td></td>
+<td>0x00a1</td>
+<td>KEY_EJECTCD</td>
+<td>3.0</td>
+<td>0x0081</td>
+<td>KEYCODE_MEDIA_EJECT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ed</td>
+<td></td>
+<td>0x0073</td>
+<td>KEY_VOLUMEUP</td>
+<td>1.6</td>
+<td>0x0018</td>
+<td>KEYCODE_VOLUME_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ee</td>
+<td></td>
+<td>0x0072</td>
+<td>KEY_VOLUMEDOWN</td>
+<td>1.6</td>
+<td>0x0019</td>
+<td>KEYCODE_VOLUME_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00ef</td>
+<td></td>
+<td>0x0071</td>
+<td>KEY_MUTE</td>
+<td>3.0</td>
+<td>0x00a4</td>
+<td>KEYCODE_VOLUME_MUTE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f0</td>
+<td></td>
+<td>0x0096</td>
+<td>KEY_WWW</td>
+<td>1.6</td>
+<td>0x0040</td>
+<td>KEYCODE_EXPLORER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f1</td>
+<td></td>
+<td>0x009e</td>
+<td>KEY_BACK</td>
+<td>1.6</td>
+<td>0x0004</td>
+<td>KEYCODE_BACK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f2</td>
+<td></td>
+<td>0x009f</td>
+<td>KEY_FORWARD</td>
+<td>3.0</td>
+<td>0x007d</td>
+<td>KEYCODE_FORWARD</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f3</td>
+<td></td>
+<td>0x0080</td>
+<td>KEY_STOP</td>
+<td>3.0</td>
+<td>0x0056</td>
+<td>KEYCODE_MEDIA_STOP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f4</td>
+<td></td>
+<td>0x0088</td>
+<td>KEY_FIND</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f5</td>
+<td></td>
+<td>0x00b1</td>
+<td>KEY_SCROLLUP</td>
+<td>3.0</td>
+<td>0x005c</td>
+<td>KEYCODE_PAGE_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f6</td>
+<td></td>
+<td>0x00b2</td>
+<td>KEY_SCROLLDOWN</td>
+<td>3.0</td>
+<td>0x005d</td>
+<td>KEYCODE_PAGE_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f7</td>
+<td></td>
+<td>0x00b0</td>
+<td>KEY_EDIT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f8</td>
+<td></td>
+<td>0x008e</td>
+<td>KEY_SLEEP</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00f9</td>
+<td></td>
+<td>0x0098</td>
+<td>KEY_COFFEE</td>
+<td>4.0</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00fa</td>
+<td></td>
+<td>0x00ad</td>
+<td>KEY_REFRESH</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x07 0x00fb</td>
+<td></td>
+<td>0x008c</td>
+<td>KEY_CALC</td>
+<td>4.0.3</td>
+<td>0x00d2</td>
+<td>KEYCODE_CALCULATOR</td>
+<td></td>
+</tr>
+</tbody>
+</table>
+<h3 id="hid-generic-desktop-page-0x01">HID Generic Desktop Page (0x01)</h3>
+<table>
+<thead>
+<tr>
+<th>HID Usage</th>
+<th>HID Usage Name</th>
+<th>LKC</th>
+<th>Linux Key Code Name</th>
+<th>Version</th>
+<th>AKC</th>
+<th>Android Key Code Name</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>0x01 0x0081</td>
+<td>System Power Down</td>
+<td>0x0074</td>
+<td>KEY_POWER</td>
+<td>1.6</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0082</td>
+<td>System Sleep</td>
+<td>0x008e</td>
+<td>KEY_SLEEP</td>
+<td>4.0</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0083</td>
+<td>System Wake Up</td>
+<td>0x008f</td>
+<td>KEY_WAKEUP</td>
+<td>4.0</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0084</td>
+<td>System Context Menu</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0085</td>
+<td>System Main Menu</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0086</td>
+<td>System App Menu</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0087</td>
+<td>System Menu Help</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0088</td>
+<td>System Menu Exit</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x0089</td>
+<td>System Menu Select</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008a</td>
+<td>System Menu Right</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008b</td>
+<td>System Menu Left</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008c</td>
+<td>System Menu Up</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008d</td>
+<td>System Menu Down</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008e</td>
+<td>System Cold Restart</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x008f</td>
+<td>System Warm Restart</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a0</td>
+<td>System Dock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a1</td>
+<td>System Undock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a2</td>
+<td>System Setup</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a3</td>
+<td>System Break</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a4</td>
+<td>System Debugger Break</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a5</td>
+<td>Application Break</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a6</td>
+<td>Application Debugger Break</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a7</td>
+<td>System Speaker Mute</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00a8</td>
+<td>System Hibernate</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b0</td>
+<td>System Display Invert</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b1</td>
+<td>System Display Internal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b2</td>
+<td>System Display External</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b3</td>
+<td>System Display Both</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b4</td>
+<td>System Display Dual</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b5</td>
+<td>System Display Toggle Int/Ext</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b6</td>
+<td>System Display Swap Prim./Sec.</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x01 0x00b7</td>
+<td>System Display LCD Autoscale</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+<h3 id="hid-consumer-page-0x0c">HID Consumer Page (0x0c)</h3>
+<table>
+<thead>
+<tr>
+<th>HID Usage</th>
+<th>HID Usage Name</th>
+<th>LKC</th>
+<th>Linux Key Code Name</th>
+<th>Version</th>
+<th>AKC</th>
+<th>Android Key Code Name</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>0x0c 0x0030</td>
+<td>Power</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0031</td>
+<td>Reset</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0032</td>
+<td>Sleep</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0033</td>
+<td>Sleep After</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0034</td>
+<td>Sleep Mode</td>
+<td>0x008e</td>
+<td>KEY_SLEEP</td>
+<td>4.0</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0040</td>
+<td>Menu</td>
+<td>0x008b</td>
+<td>KEY_MENU</td>
+<td>1.6</td>
+<td>0x0052</td>
+<td>KEYCODE_MENU</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0041</td>
+<td>Menu Pick</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0042</td>
+<td>Menu Up</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0043</td>
+<td>Menu Down</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0044</td>
+<td>Menu Left</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0045</td>
+<td>Menu Right</td>
+<td>0x0181</td>
+<td>KEY_RADIO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0046</td>
+<td>Menu Escape</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0047</td>
+<td>Menu Value Increase</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0048</td>
+<td>Menu Value Decrease</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0081</td>
+<td>Assign Selection</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0082</td>
+<td>Mode Step</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0083</td>
+<td>Recall Last</td>
+<td>0x0195</td>
+<td>KEY_LAST</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0084</td>
+<td>Enter Channel</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0085</td>
+<td>Order Movie</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0088</td>
+<td>Media Select Computer</td>
+<td>0x0178</td>
+<td>KEY_PC</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0089</td>
+<td>Media Select TV</td>
+<td>0x0179</td>
+<td>KEY_TV</td>
+<td>3.0</td>
+<td>0x00aa</td>
+<td>KEYCODE_TV</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008a</td>
+<td>Media Select WWW</td>
+<td>0x0096</td>
+<td>KEY_WWW</td>
+<td>1.6</td>
+<td>0x0040</td>
+<td>KEYCODE_EXPLORER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008b</td>
+<td>Media Select DVD</td>
+<td>0x0185</td>
+<td>KEY_DVD</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008c</td>
+<td>Media Select Telephone</td>
+<td>0x00a9</td>
+<td>KEY_PHONE</td>
+<td>3.0</td>
+<td>0x0005</td>
+<td>KEYCODE_CALL</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008d</td>
+<td>Media Select Program Guide</td>
+<td>0x016a</td>
+<td>KEY_PROGRAM</td>
+<td>3.0</td>
+<td>0x00ac</td>
+<td>KEYCODE_GUIDE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008e</td>
+<td>Media Select Video Phone</td>
+<td>0x01a0</td>
+<td>KEY_VIDEOPHONE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x008f</td>
+<td>Media Select Games</td>
+<td>0x01a1</td>
+<td>KEY_GAMES</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0090</td>
+<td>Media Select Messages</td>
+<td>0x018c</td>
+<td>KEY_MEMO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0091</td>
+<td>Media Select CD</td>
+<td>0x017f</td>
+<td>KEY_CD</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0092</td>
+<td>Media Select VCR</td>
+<td>0x017b</td>
+<td>KEY_VCR</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0093</td>
+<td>Media Select Tuner</td>
+<td>0x0182</td>
+<td>KEY_TUNER</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0094</td>
+<td>Quit</td>
+<td>0x00ae</td>
+<td>KEY_EXIT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0095</td>
+<td>Help</td>
+<td>0x008a</td>
+<td>KEY_HELP</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0096</td>
+<td>Media Select Tape</td>
+<td>0x0180</td>
+<td>KEY_TAPE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0097</td>
+<td>Media Select Cable</td>
+<td>0x017a</td>
+<td>KEY_TV2</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0098</td>
+<td>Media Select Satellite</td>
+<td>0x017d</td>
+<td>KEY_SAT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0099</td>
+<td>Media Select Security</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x009a</td>
+<td>Media Select Home</td>
+<td>0x016e</td>
+<td>KEY_PVR</td>
+<td>3.0</td>
+<td>0x00ad</td>
+<td>KEYCODE_DVR</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x009c</td>
+<td>Channel Increment</td>
+<td>0x0192</td>
+<td>KEY_CHANNELUP</td>
+<td>3.0</td>
+<td>0x00a6</td>
+<td>KEYCODE_CHANNEL_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x009d</td>
+<td>Channel Decrement</td>
+<td>0x0193</td>
+<td>KEY_CHANNELDOWN</td>
+<td>3.0</td>
+<td>0x00a7</td>
+<td>KEYCODE_CHANNEL_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x009e</td>
+<td>Media Select SAP</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00a0</td>
+<td>VCR Plus</td>
+<td>0x017c</td>
+<td>KEY_VCR2</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00a1</td>
+<td>Once</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00a2</td>
+<td>Daily</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00a3</td>
+<td>Weekly</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00a4</td>
+<td>Monthly</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b0</td>
+<td>Play</td>
+<td>0x00cf</td>
+<td>KEY_PLAY</td>
+<td>3.0</td>
+<td>0x007e</td>
+<td>KEYCODE_MEDIA_PLAY</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b1</td>
+<td>Pause</td>
+<td>0x0077</td>
+<td>KEY_PAUSE</td>
+<td>3.0</td>
+<td>0x0079</td>
+<td>KEYCODE_BREAK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b2</td>
+<td>Record</td>
+<td>0x00a7</td>
+<td>KEY_RECORD</td>
+<td>3.0</td>
+<td>0x0082</td>
+<td>KEYCODE_MEDIA_RECORD</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b3</td>
+<td>Fast Forward</td>
+<td>0x00d0</td>
+<td>KEY_FASTFORWARD</td>
+<td>3.0</td>
+<td>0x005a</td>
+<td>KEYCODE_MEDIA_FAST_FORWARD</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b4</td>
+<td>Rewind</td>
+<td>0x00a8</td>
+<td>KEY_REWIND</td>
+<td>3.0</td>
+<td>0x0059</td>
+<td>KEYCODE_MEDIA_REWIND</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b5</td>
+<td>Scan Next Track</td>
+<td>0x00a3</td>
+<td>KEY_NEXTSONG</td>
+<td>3.0</td>
+<td>0x0057</td>
+<td>KEYCODE_MEDIA_NEXT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b6</td>
+<td>Scan Previous Track</td>
+<td>0x00a5</td>
+<td>KEY_PREVIOUSSONG</td>
+<td>3.0</td>
+<td>0x0058</td>
+<td>KEYCODE_MEDIA_PREVIOUS</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b7</td>
+<td>Stop</td>
+<td>0x00a6</td>
+<td>KEY_STOPCD</td>
+<td>3.0</td>
+<td>0x0056</td>
+<td>KEYCODE_MEDIA_STOP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b8</td>
+<td>Eject</td>
+<td>0x00a1</td>
+<td>KEY_EJECTCD</td>
+<td>3.0</td>
+<td>0x0081</td>
+<td>KEYCODE_MEDIA_EJECT</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00b9</td>
+<td>Random Play</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00ba</td>
+<td>Select Disc</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00bb</td>
+<td>Enter Disc</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00bc</td>
+<td>Repeat</td>
+<td>0x01b7</td>
+<td>KEY_MEDIA_REPEAT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00be</td>
+<td>Track Normal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c0</td>
+<td>Frame Forward</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c1</td>
+<td>Frame Back</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c2</td>
+<td>Mark</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c3</td>
+<td>Clear Mark</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c4</td>
+<td>Repeat From Mark</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c5</td>
+<td>Return To Mark</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c6</td>
+<td>Search Mark Forward</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c7</td>
+<td>Search Mark Backwards</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c8</td>
+<td>Counter Reset</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00c9</td>
+<td>Show Counter</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00ca</td>
+<td>Tracking Increment</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00cb</td>
+<td>Tracking Decrement</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00cc</td>
+<td>Stop / Eject</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00cd</td>
+<td>Play / Pause</td>
+<td>0x00a4</td>
+<td>KEY_PLAYPAUSE</td>
+<td>3.0</td>
+<td>0x0055</td>
+<td>KEYCODE_MEDIA_PLAY_PAUSE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00ce</td>
+<td>Play / Skip</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e2</td>
+<td>Mute</td>
+<td>0x0071</td>
+<td>KEY_MUTE</td>
+<td>3.0</td>
+<td>0x00a4</td>
+<td>KEYCODE_VOLUME_MUTE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e5</td>
+<td>Bass Boost</td>
+<td>0x00d1</td>
+<td>KEY_BASSBOOST</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e6</td>
+<td>Surround Mode</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e7</td>
+<td>Loudness</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e8</td>
+<td>MPX</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00e9</td>
+<td>Volume Increment</td>
+<td>0x0073</td>
+<td>KEY_VOLUMEUP</td>
+<td>1.6</td>
+<td>0x0018</td>
+<td>KEYCODE_VOLUME_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x00ea</td>
+<td>Volume Decrement</td>
+<td>0x0072</td>
+<td>KEY_VOLUMEDOWN</td>
+<td>1.6</td>
+<td>0x0019</td>
+<td>KEYCODE_VOLUME_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0181</td>
+<td>AL Launch Button Config. Tool</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0182</td>
+<td>AL Programmable Button Config.</td>
+<td>0x009c</td>
+<td>KEY_BOOKMARKS</td>
+<td>3.0</td>
+<td>0x00ae</td>
+<td>KEYCODE_BOOKMARK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0183</td>
+<td>AL Consumer Control Config.</td>
+<td>0x00ab</td>
+<td>KEY_CONFIG</td>
+<td>4.0.3</td>
+<td>0x00d1</td>
+<td>KEYCODE_MUSIC</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0184</td>
+<td>AL Word Processor</td>
+<td>0x01a5</td>
+<td>KEY_WORDPROCESSOR</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0185</td>
+<td>AL Text Editor</td>
+<td>0x01a6</td>
+<td>KEY_EDITOR</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0186</td>
+<td>AL Spreadsheet</td>
+<td>0x01a7</td>
+<td>KEY_SPREADSHEET</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0187</td>
+<td>AL Graphics Editor</td>
+<td>0x01a8</td>
+<td>KEY_GRAPHICSEDITOR</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0188</td>
+<td>AL Presentation App</td>
+<td>0x01a9</td>
+<td>KEY_PRESENTATION</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0189</td>
+<td>AL Database App</td>
+<td>0x01aa</td>
+<td>KEY_DATABASE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018a</td>
+<td>AL Email Reader</td>
+<td>0x009b</td>
+<td>KEY_MAIL</td>
+<td>1.6</td>
+<td>0x0041</td>
+<td>KEYCODE_ENVELOPE</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018b</td>
+<td>AL Newsreader</td>
+<td>0x01ab</td>
+<td>KEY_NEWS</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018c</td>
+<td>AL Voicemail</td>
+<td>0x01ac</td>
+<td>KEY_VOICEMAIL</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018d</td>
+<td>AL Contacts / Address Book</td>
+<td>0x01ad</td>
+<td>KEY_ADDRESSBOOK</td>
+<td>4.0.3</td>
+<td>0x00cf</td>
+<td>KEYCODE_CONTACTS</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018e</td>
+<td>AL Calendar / Schedule</td>
+<td>0x018d</td>
+<td>KEY_CALENDAR</td>
+<td>4.0.3</td>
+<td>0x00d0</td>
+<td>KEYCODE_CALENDAR</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x018f</td>
+<td>AL Task / Project Manager</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0190</td>
+<td>AL Log / Journal / Timecard</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0191</td>
+<td>AL Checkbook / Finance</td>
+<td>0x00db</td>
+<td>KEY_FINANCE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0192</td>
+<td>AL Calculator</td>
+<td>0x008c</td>
+<td>KEY_CALC</td>
+<td>4.0.3</td>
+<td>0x00d2</td>
+<td>KEYCODE_CALCULATOR</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0193</td>
+<td>AL A/V Capture / Playback</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0194</td>
+<td>AL Local Machine Browser</td>
+<td>0x0090</td>
+<td>KEY_FILE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0195</td>
+<td>AL LAN/WAN Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0196</td>
+<td>AL Internet Browser</td>
+<td>0x0096</td>
+<td>KEY_WWW</td>
+<td>1.6</td>
+<td>0x0040</td>
+<td>KEYCODE_EXPLORER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0197</td>
+<td>AL Remote Networking/ISP Connect</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0198</td>
+<td>AL Network Conference</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0199</td>
+<td>AL Network Chat</td>
+<td>0x00d8</td>
+<td>KEY_CHAT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019a</td>
+<td>AL Telephony / Dialer</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019b</td>
+<td>AL Logon</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019c</td>
+<td>AL Logoff</td>
+<td>0x01b1</td>
+<td>KEY_LOGOFF</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019d</td>
+<td>AL Logon / Logoff</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019e</td>
+<td>AL Terminal Lock / Screensaver</td>
+<td>0x0098</td>
+<td>KEY_COFFEE</td>
+<td>4.0</td>
+<td>0x001a</td>
+<td>KEYCODE_POWER</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x019f</td>
+<td>AL Control Panel</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a0</td>
+<td>AL Command Line Processor / Run</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a1</td>
+<td>AL Process / Task Manager</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a2</td>
+<td>AL Select Task / Application</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a3</td>
+<td>AL Next Task / Application</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a4</td>
+<td>AL Previous Task / Application</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a5</td>
+<td>AL Preemptive Halt Task / App.</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a6</td>
+<td>AL Integrated Help Center</td>
+<td>0x008a</td>
+<td>KEY_HELP</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a7</td>
+<td>AL Documents</td>
+<td>0x00eb</td>
+<td>KEY_DOCUMENTS</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a8</td>
+<td>AL Thesaurus</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01a9</td>
+<td>AL Dictionary</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01aa</td>
+<td>AL Desktop</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01ab</td>
+<td>AL Spell Check</td>
+<td>0x01b0</td>
+<td>KEY_SPELLCHECK</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01ac</td>
+<td>AL Grammar Check</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01ad</td>
+<td>AL Wireless Status</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01ae</td>
+<td>AL Keyboard Layout</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01af</td>
+<td>AL Virus Protection</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b0</td>
+<td>AL Encryption</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b1</td>
+<td>AL Screen Saver</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b2</td>
+<td>AL Alarms</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b3</td>
+<td>AL Clock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b4</td>
+<td>AL File Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b5</td>
+<td>AL Power Status</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b6</td>
+<td>AL Image Browser</td>
+<td>0x00e2</td>
+<td>KEY_MEDIA</td>
+<td>3.0</td>
+<td>0x004f</td>
+<td>KEYCODE_HEADSETHOOK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b7</td>
+<td>AL Audio Browser</td>
+<td>0x00d5</td>
+<td>KEY_SOUND</td>
+<td>4.0.3</td>
+<td>0x00d1</td>
+<td>KEYCODE_MUSIC</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b8</td>
+<td>AL Movie Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01b9</td>
+<td>AL Digital Rights Manager</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01ba</td>
+<td>AL Digital Wallet</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01bc</td>
+<td>AL Instant Messaging</td>
+<td>0x01ae</td>
+<td>KEY_MESSENGER</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01bd</td>
+<td>AL OEM Features / Tips Browser</td>
+<td>0x0166</td>
+<td>KEY_INFO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01be</td>
+<td>AL OEM Help</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01bf</td>
+<td>AL Online Community</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c0</td>
+<td>AL Entertainment Content Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c1</td>
+<td>AL Online Shopping Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c2</td>
+<td>AL SmartCard Information / Help</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c3</td>
+<td>AL Market / Finance Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c4</td>
+<td>AL Customized Corp. News Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c5</td>
+<td>AL Online Activity Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c6</td>
+<td>AL Research / Search Browser</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x01c7</td>
+<td>AL Audio Player</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0201</td>
+<td>AC New</td>
+<td>0x00b5</td>
+<td>KEY_NEW</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0202</td>
+<td>AC Open</td>
+<td>0x0086</td>
+<td>KEY_OPEN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0203</td>
+<td>AC Close</td>
+<td>0x00ce</td>
+<td>KEY_CLOSE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0204</td>
+<td>AC Exit</td>
+<td>0x00ae</td>
+<td>KEY_EXIT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0205</td>
+<td>AC Maximize</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0206</td>
+<td>AC Minimize</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0207</td>
+<td>AC Save</td>
+<td>0x00ea</td>
+<td>KEY_SAVE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0208</td>
+<td>AC Print</td>
+<td>0x00d2</td>
+<td>KEY_PRINT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0209</td>
+<td>AC Properties</td>
+<td>0x0082</td>
+<td>KEY_PROPS</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021a</td>
+<td>AC Undo</td>
+<td>0x0083</td>
+<td>KEY_UNDO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021b</td>
+<td>AC Copy</td>
+<td>0x0085</td>
+<td>KEY_COPY</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021c</td>
+<td>AC Cut</td>
+<td>0x0089</td>
+<td>KEY_CUT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021d</td>
+<td>AC Paste</td>
+<td>0x0087</td>
+<td>KEY_PASTE</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021e</td>
+<td>AC Select All</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x021f</td>
+<td>AC Find</td>
+<td>0x0088</td>
+<td>KEY_FIND</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0220</td>
+<td>AC Find and Replace</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0221</td>
+<td>AC Search</td>
+<td>0x00d9</td>
+<td>KEY_SEARCH</td>
+<td>1.6</td>
+<td>0x0054</td>
+<td>KEYCODE_SEARCH</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0222</td>
+<td>AC Go To</td>
+<td>0x0162</td>
+<td>KEY_GOTO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0223</td>
+<td>AC Home</td>
+<td>0x00ac</td>
+<td>KEY_HOMEPAGE</td>
+<td>3.0</td>
+<td>0x0003</td>
+<td>KEYCODE_HOME</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0224</td>
+<td>AC Back</td>
+<td>0x009e</td>
+<td>KEY_BACK</td>
+<td>1.6</td>
+<td>0x0004</td>
+<td>KEYCODE_BACK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0225</td>
+<td>AC Forward</td>
+<td>0x009f</td>
+<td>KEY_FORWARD</td>
+<td>3.0</td>
+<td>0x007d</td>
+<td>KEYCODE_FORWARD</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0226</td>
+<td>AC Stop</td>
+<td>0x0080</td>
+<td>KEY_STOP</td>
+<td>3.0</td>
+<td>0x0056</td>
+<td>KEYCODE_MEDIA_STOP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0227</td>
+<td>AC Refresh</td>
+<td>0x00ad</td>
+<td>KEY_REFRESH</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0228</td>
+<td>AC Previous Link</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0229</td>
+<td>AC Next Link</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022a</td>
+<td>AC Bookmarks</td>
+<td>0x009c</td>
+<td>KEY_BOOKMARKS</td>
+<td>3.0</td>
+<td>0x00ae</td>
+<td>KEYCODE_BOOKMARK</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022b</td>
+<td>AC History</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022c</td>
+<td>AC Subscriptions</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022d</td>
+<td>AC Zoom In</td>
+<td>0x01a2</td>
+<td>KEY_ZOOMIN</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022e</td>
+<td>AC Zoom Out</td>
+<td>0x01a3</td>
+<td>KEY_ZOOMOUT</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x022f</td>
+<td>AC Zoom</td>
+<td>0x01a4</td>
+<td>KEY_ZOOMRESET</td>
+<td></td>
+<td></td>
+<td></td>
+<td>2</td>
+</tr>
+<tr>
+<td>0x0c 0x0230</td>
+<td>AC Full Screen View</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0231</td>
+<td>AC Normal View</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0232</td>
+<td>AC View Toggle</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0233</td>
+<td>AC Scroll Up</td>
+<td>0x00b1</td>
+<td>KEY_SCROLLUP</td>
+<td>3.0</td>
+<td>0x005c</td>
+<td>KEYCODE_PAGE_UP</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0234</td>
+<td>AC Scroll Down</td>
+<td>0x00b2</td>
+<td>KEY_SCROLLDOWN</td>
+<td>3.0</td>
+<td>0x005d</td>
+<td>KEYCODE_PAGE_DOWN</td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0236</td>
+<td>AC Pan Left</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0237</td>
+<td>AC Pan Right</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0239</td>
+<td>AC New Window</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023a</td>
+<td>AC Tile Horizontally</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023b</td>
+<td>AC Tile Vertically</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023c</td>
+<td>AC Format</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023d</td>
+<td>AC Edit</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023e</td>
+<td>AC Bold</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x023f</td>
+<td>AC Italics</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0240</td>
+<td>AC Underline</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0241</td>
+<td>AC Strikethrough</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0242</td>
+<td>AC Subscript</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0243</td>
+<td>AC Superscript</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0244</td>
+<td>AC All Caps</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0245</td>
+<td>AC Rotate</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0246</td>
+<td>AC Resize</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0247</td>
+<td>AC Flip horizontal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0248</td>
+<td>AC Flip Vertical</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0249</td>
+<td>AC Mirror Horizontal</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024a</td>
+<td>AC Mirror Vertical</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024b</td>
+<td>AC Font Select</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024c</td>
+<td>AC Font Color</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024d</td>
+<td>AC Font Size</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024e</td>
+<td>AC Justify Left</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x024f</td>
+<td>AC Justify Center H</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0250</td>
+<td>AC Justify Right</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0251</td>
+<td>AC Justify Block H</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0252</td>
+<td>AC Justify Top</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0253</td>
+<td>AC Justify Center V</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0254</td>
+<td>AC Justify Bottom</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0255</td>
+<td>AC Justify Block V</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0256</td>
+<td>AC Indent Decrease</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0257</td>
+<td>AC Indent Increase</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0258</td>
+<td>AC Numbered List</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0259</td>
+<td>AC Restart Numbering</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025a</td>
+<td>AC Bulleted List</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025b</td>
+<td>AC Promote</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025c</td>
+<td>AC Demote</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025d</td>
+<td>AC Yes</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025e</td>
+<td>AC No</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x025f</td>
+<td>AC Cancel</td>
+<td>0x00df</td>
+<td>KEY_CANCEL</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0260</td>
+<td>AC Catalog</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0261</td>
+<td>AC Buy / Checkout</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0262</td>
+<td>AC Add to Cart</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0263</td>
+<td>AC Expand</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0264</td>
+<td>AC Expand All</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0265</td>
+<td>AC Collapse</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0266</td>
+<td>AC Collapse All</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0267</td>
+<td>AC Print Preview</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0268</td>
+<td>AC Paste Special</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0269</td>
+<td>AC Insert Mode</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026a</td>
+<td>AC Delete</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026b</td>
+<td>AC Lock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026c</td>
+<td>AC Unlock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026d</td>
+<td>AC Protect</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026e</td>
+<td>AC Unprotect</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x026f</td>
+<td>AC Attach Comment</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0270</td>
+<td>AC Delete Comment</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0271</td>
+<td>AC View Comment</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0272</td>
+<td>AC Select Word</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0273</td>
+<td>AC Select Sentence</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0274</td>
+<td>AC Select Paragraph</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0275</td>
+<td>AC Select Column</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0276</td>
+<td>AC Select Row</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0277</td>
+<td>AC Select Table</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0278</td>
+<td>AC Select Object</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0279</td>
+<td>AC Redo / Repeat</td>
+<td>0x00b6</td>
+<td>KEY_REDO</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027a</td>
+<td>AC Sort</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027b</td>
+<td>AC Sort Ascending</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027c</td>
+<td>AC Sort Descending</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027d</td>
+<td>AC Filter</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027e</td>
+<td>AC Set Clock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x027f</td>
+<td>AC View Clock</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0280</td>
+<td>AC Select Time Zone</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0281</td>
+<td>AC Edit Time Zones</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0282</td>
+<td>AC Set Alarm</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0283</td>
+<td>AC Clear Alarm</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0284</td>
+<td>AC Snooze Alarm</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0285</td>
+<td>AC Reset Alarm</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0286</td>
+<td>AC Synchronize</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0287</td>
+<td>AC Send/Receive</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0288</td>
+<td>AC Send To</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0289</td>
+<td>AC Reply</td>
+<td>0x00e8</td>
+<td>KEY_REPLY</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028a</td>
+<td>AC Reply All</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028b</td>
+<td>AC Forward Msg</td>
+<td>0x00e9</td>
+<td>KEY_FORWARDMAIL</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028c</td>
+<td>AC Send</td>
+<td>0x00e7</td>
+<td>KEY_SEND</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028d</td>
+<td>AC Attach File</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028e</td>
+<td>AC Upload</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x028f</td>
+<td>AC Download (Save Target As)</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0290</td>
+<td>AC Set Borders</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0291</td>
+<td>AC Insert Row</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0292</td>
+<td>AC Insert Column</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0293</td>
+<td>AC Insert File</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0294</td>
+<td>AC Insert Picture</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0295</td>
+<td>AC Insert Object</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0296</td>
+<td>AC Insert Symbol</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0297</td>
+<td>AC Save and Close</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0298</td>
+<td>AC Rename</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x0299</td>
+<td>AC Merge</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x029a</td>
+<td>AC Split</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x029b</td>
+<td>AC Distribute Horizontally</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td>0x0c 0x029c</td>
+<td>AC Distribute Vertically</td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+<h3 id="additional-non-hid-mappings">Additional non-HID Mappings</h3>
+<p>These mappings describe functions that do not appear in HID but for which Linux
+key codes exist.</p>
+<table>
+<thead>
+<tr>
+<th>LKC</th>
+<th>Linux Key Code Name</th>
+<th>Version</th>
+<th>AKC</th>
+<th>Android Key Code Name</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>0x01d0</td>
+<td>KEY_FN</td>
+<td>3.0</td>
+<td>0x0077</td>
+<td>KEYCODE_FUNCTION</td>
+<td></td>
+</tr>
+<tr>
+<td>0x01d1</td>
+<td>KEY_FN_ESC</td>
+<td>3.0</td>
+<td>0x006f</td>
+<td>KEYCODE_ESCAPE</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d2</td>
+<td>KEY_FN_F1</td>
+<td>3.0</td>
+<td>0x0083</td>
+<td>KEYCODE_F1</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d3</td>
+<td>KEY_FN_F2</td>
+<td>3.0</td>
+<td>0x0084</td>
+<td>KEYCODE_F2</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d4</td>
+<td>KEY_FN_F3</td>
+<td>3.0</td>
+<td>0x0085</td>
+<td>KEYCODE_F3</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d5</td>
+<td>KEY_FN_F4</td>
+<td>3.0</td>
+<td>0x0086</td>
+<td>KEYCODE_F4</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d6</td>
+<td>KEY_FN_F5</td>
+<td>3.0</td>
+<td>0x0087</td>
+<td>KEYCODE_F5</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d7</td>
+<td>KEY_FN_F6</td>
+<td>3.0</td>
+<td>0x0088</td>
+<td>KEYCODE_F6</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d8</td>
+<td>KEY_FN_F7</td>
+<td>3.0</td>
+<td>0x0089</td>
+<td>KEYCODE_F7</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01d9</td>
+<td>KEY_FN_F8</td>
+<td>3.0</td>
+<td>0x008a</td>
+<td>KEYCODE_F8</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01da</td>
+<td>KEY_FN_F9</td>
+<td>3.0</td>
+<td>0x008b</td>
+<td>KEYCODE_F9</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01db</td>
+<td>KEY_FN_F10</td>
+<td>3.0</td>
+<td>0x008c</td>
+<td>KEYCODE_F10</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01dc</td>
+<td>KEY_FN_F11</td>
+<td>3.0</td>
+<td>0x008d</td>
+<td>KEYCODE_F11</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01dd</td>
+<td>KEY_FN_F12</td>
+<td>3.0</td>
+<td>0x008e</td>
+<td>KEYCODE_F12</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01de</td>
+<td>KEY_FN_1</td>
+<td>3.0</td>
+<td>0x0008</td>
+<td>KEYCODE_1</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01df</td>
+<td>KEY_FN_2</td>
+<td>3.0</td>
+<td>0x0009</td>
+<td>KEYCODE_2</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01e0</td>
+<td>KEY_FN_D</td>
+<td>3.0</td>
+<td>0x0020</td>
+<td>KEYCODE_D</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01e1</td>
+<td>KEY_FN_E</td>
+<td>3.0</td>
+<td>0x0021</td>
+<td>KEYCODE_E</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01e2</td>
+<td>KEY_FN_F</td>
+<td>3.0</td>
+<td>0x0022</td>
+<td>KEYCODE_F</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01e3</td>
+<td>KEY_FN_S</td>
+<td>3.0</td>
+<td>0x002f</td>
+<td>KEYCODE_S</td>
+<td>3</td>
+</tr>
+<tr>
+<td>0x01e4</td>
+<td>KEY_FN_B</td>
+<td>3.0</td>
+<td>0x001e</td>
+<td>KEYCODE_B</td>
+<td>3</td>
+</tr>
+</tbody>
+</table>
+<h3 id="legacy-unsupported-keys">Legacy Unsupported Keys</h3>
+<p>These mappings appeared in previous versions of Android but were inconsistent with
+HID or used non-standard Linux key codes. They are no longer supported.</p>
+<table>
+<thead>
+<tr>
+<th>LKC</th>
+<th>Linux Key Code Name</th>
+<th>Version</th>
+<th>AKC</th>
+<th>Android Key Code Name</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>0x00db</td>
+<td>KEY_EMAIL</td>
+<td>1.6</td>
+<td>0x004d</td>
+<td>KEYCODE_AT</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e3</td>
+<td>KEY_STAR</td>
+<td>1.6</td>
+<td>0x0011</td>
+<td>KEYCODE_STAR</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e4</td>
+<td>KEY_SHARP</td>
+<td>1.6</td>
+<td>0x0012</td>
+<td>KEYCODE_POUND</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e5</td>
+<td>KEY_SOFT1</td>
+<td>1.6</td>
+<td>0x0052</td>
+<td>KEYCODE_MENU</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e6</td>
+<td>KEY_SOFT2</td>
+<td>1.6</td>
+<td>0x0002</td>
+<td>KEYCODE_SOFT_RIGHT</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e7</td>
+<td>KEY_SEND</td>
+<td>1.6</td>
+<td>0x0005</td>
+<td>KEYCODE_CALL</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e8</td>
+<td>KEY_CENTER</td>
+<td>1.6</td>
+<td>0x0017</td>
+<td>KEYCODE_DPAD_CENTER</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00e9</td>
+<td>KEY_HEADSETHOOK</td>
+<td>1.6</td>
+<td>0x004f</td>
+<td>KEYCODE_HEADSETHOOK</td>
+<td>4</td>
+</tr>
+<tr>
+<td>""</td>
+<td>""</td>
+<td>4.0</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00ea</td>
+<td>KEY_0_5</td>
+<td>1.6</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+<tr>
+<td>0x00eb</td>
+<td>KEY_2_5</td>
+<td>1.6</td>
+<td></td>
+<td></td>
+<td>4</td>
+</tr>
+</tbody>
+</table>
+<h3 id="notes">Notes</h3>
+<ol>
+<li>
+<p>The Android key code associated with common alphanumeric and symbolic
+ keys may vary based on the keyboard layout and language.
+ For historical reasons, the physical scan codes and HID usages
+ associated with keys on a keyboard are often defined positionally
+ even though the labels printed on those keys may vary from one
+ language to another.</p>
+<p>On a US English (QWERTY) keyboard, the top-left alphabetic key is
+labeled Q. On a French (AZERTY) keyboard, the key in the same
+position is labeled A. Despite the label, on both keyboards the
+top-left alphabetic key is referred to using the HID usage
+0x07 0x0014 which is mapped to the Linux key code KEY_Q.</p>
+<p>When Android is configured with a US English keyboard layout, then
+the Linux key code KEY_Q will be mapped to the Android key code
+KEYCODE_Q and will produce the characters 'Q' and 'q'.
+However, when Android is configured with a French keyboard layout,
+then the Linux key code KEY_Q will be mapped to the Android key code
+KEYCODE_A and will produce the characters 'A' and 'a'.</p>
+<p>The Android key code typically reflects the language-specific
+interpretation of the key, so a different Android key code may
+be used for different languages.</p>
+</li>
+<li>
+<p><code>0x0c 0x022f AC Zoom</code> is defined in the HID as a linear control but
+ the kernel maps it as a key, which is probably incorrect.</p>
+</li>
+<li>
+<p>The Linux function keys <code>KEY_FN_*</code> are mapped to simpler
+ key codes but are dispatched with the <code>META_FUNCTION</code> meta state
+ bit set to true.</p>
+</li>
+<li>
+<p>Prior to Android Ice Cream Sandwich 4.0, the default key layout
+ contained mappings for some extra key codes that were not defined
+ in the mainline Linux kernel headers. These mappings have since
+ been removed because these previously undefined key codes have
+ since been assigned different meanings in more recent versions
+ of the Linux kernel.</p>
+</li>
+</ol>
+<h3 id="sources">Sources</h3>
+<ol>
+<li><a href="http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf">USB HID Usage Tables v1.12</a></li>
+<li>Linux 2.6.39 kernel: include/linux/input.h, drivers/hid/hid-input.c</li>
+<li>Android ICS: qwerty.kl, Generic.kl, KeyEvent.java</li>
+</ol>
diff --git a/src/devices/tech/input/migration-guide.jd b/src/devices/tech/input/migration-guide.jd
new file mode 100644
index 0000000..dbdf666
--- /dev/null
+++ b/src/devices/tech/input/migration-guide.jd
@@ -0,0 +1,55 @@
+page.title=Migration Guide
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>This document contains a few helpful tips when migrating to new Android releases.</p>
+<h2 id="migrating-to-android-gingerbread-23">Migrating to Android Gingerbread 2.3</h2>
+<p>In Gingerbread, we added the concept of input device configuration files
+(also referred to as input device calibration files in this release).</p>
+<p>Make sure to provide an input device configuration file for all touch screens.
+In particular, it is worth spending time providing a calibration reference for
+touch size information.</p>
+<h2 id="migrating-to-android-honeycomb-30">Migrating to Android Honeycomb 3.0</h2>
+<p>In Honeycomb, we revised the key character map file format and started making
+greater use of input device configuration files. We also added support for full
+PC-style keyboards and introduced a new "Generic" key map, which
+replaced the older emulator-specific "qwerty" key map (which was never
+intended to be used as a general-purpose key map.)</p>
+<p>Make sure to update all of your key character map files to use the new syntax.</p>
+<p>If your peripherals relied on the old "qwerty" key map, then you
+may need to provide new device-specific key maps to emulate the old behavior.
+You should create a new key map for each device identified either by
+USB product id / vendor id or by device name.</p>
+<p>It is especially important to provide key character map files for all special
+function input devices. These files should simple contain a line to set
+the keyboard type to <code>SPECIAL_FUNCTION</code>.</p>
+<p>A good way to ensure that all built-in input devices are appropriately configured
+is to run <a href="/tech/input/dumpsys.html">Dumpsys</a> and look for devices that
+are inappropriately using <code>Generic.kcm</code>.</p>
+<h2 id="migrating-to-android-honeycomb-32">Migrating to Android Honeycomb 3.2</h2>
+<p>In Honeycomb 3.2, we added support for joysticks and extended the key layout file
+format to enable joystick axis mapping.</p>
+<h2 id="migrating-to-android-ice-cream-sandwich-40">Migrating to Android Ice Cream Sandwich 4.0</h2>
+<p>In Ice Cream Sandwich 4.0, we changed the device driver requirements for touch screens
+to follow the standard Linux multitouch input protocol and added support for
+protocol "B". We also support digitizer tablets and stylus-based touch devices.</p>
+<p>You will probably need to update your input device driver to implement the Linux
+multitouch input protocol correctly according to the standard.</p>
+<p>You will also need to update your input device configuration files because some
+properties have been changed to be simpler and more systematic.</p>
+<p>Refer to <a href="/tech/input/touch-devices.html">Touch Devices</a> for more details about
+driver requirements.</p>
\ No newline at end of file
diff --git a/src/devices/tech/input/overview.jd b/src/devices/tech/input/overview.jd
new file mode 100644
index 0000000..cbf86b9
--- /dev/null
+++ b/src/devices/tech/input/overview.jd
@@ -0,0 +1,237 @@
+page.title=Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android input subsystem nominally consists of an event pipeline
+that traverses multiple layers of the system.</p>
+<h2 id="input-pipeline">Input Pipeline</h2>
+<p>At the lowest layer, the physical input device produces signals that
+describe state changes such as key presses and touch contact points.
+The device firmware encodes and transmits these signals in some way
+such as by sending USB HID reports to the system or by producing
+interrupts on an I2C bus.</p>
+<p>The signals are then decoded by a device driver in the Linux kernel.
+The Linux kernel provides drivers for many standard peripherals,
+particularly those that adhere to the HID protocol. However, an OEM
+must often provide custom drivers for embedded devices that are
+tightly integrated into the system at a low-level, such as touch screens.</p>
+<p>The input device drivers are responsible for translating device-specific
+signals into a standard input event format, by way of the Linux
+input protocol. The Linux input protocol defines a standard set of
+event types and codes in the <code>linux/input.h</code> kernel header file.
+In this way, components outside the kernel do not need to care about
+the details such as physical scan codes, HID usages, I2C messages,
+GPIO pins, and the like.</p>
+<p>Next, the Android <code>EventHub</code> component reads input events from the kernel
+by opening the <code>evdev</code> driver associated with each input device.
+The Android InputReader component then decodes the input events
+according to the device class and produces a stream of Android input
+events. As part of this process, the Linux input protocol event codes
+are translated into Android event codes according to the
+input device configuration, keyboard layout files, and various
+mapping tables.</p>
+<p>Finally, the <code>InputReader</code> sends input events to the InputDispatcher
+which forwards them to the appropriate window.</p>
+<h2 id="control-points">Control Points</h2>
+<p>There are several stages in the input pipeline which effect control
+over the behavior of the input device.</p>
+<h3 id="driver-and-firmware-configuration">Driver and Firmware Configuration</h3>
+<p>Input device drivers frequently configure the behavior of the input
+device by setting parameters in registers or even uploading the
+firmware itself. This is particularly the case for embedded
+devices such as touch screens where a large part of the calibration
+process involves tuning these parameters or fixing the firmware
+to provide the desired accuracy and responsiveness and to suppress
+noise.</p>
+<p>Driver configuration options are often specified as module parameters
+in the kernel board support package (BSP) so that the same driver
+can support multiple different hardware implementations.</p>
+<p>This documentation does attempt to describe driver or firmware
+configuration, but it does offer guidance as to device calibration
+in general.</p>
+<h3 id="board-configuration-properties">Board Configuration Properties</h3>
+<p>The kernel board support package (BSP) may export board configuration
+properties via SysFS that are used by the Android InputReader component,
+such as the placement of virtual keys on a touch screen.</p>
+<p>Refer to the device class sections for details about how different
+devices use board configuration properties.</p>
+<h3 id="resource-overlays">Resource Overlays</h3>
+<p>A few input behaviors are configured by way of resource overlays
+in <code>config.xml</code> such as the operation of lid switch.</p>
+<p>Here are a few examples:</p>
+<ul>
+<li>
+<p><code>config_lidKeyboardAccessibility</code>: Specifies the effect of the
+ lid switch on whether the hardware keyboard is accessible or hidden.</p>
+</li>
+<li>
+<p><code>config_lidNavigationAccessibility</code>: Specifies the effect of the
+ lid switch on whether the trackpad is accessible or hidden.</p>
+</li>
+<li>
+<p><code>config_longPressOnPowerBehavior</code>: Specifies what should happen when
+ the user holds down the power button.</p>
+</li>
+<li>
+<p><code>config_lidOpenRotation</code>: Specifies the effect of the lid switch
+ on screen orientation.</p>
+</li>
+</ul>
+<p>Refer to the documentation within <code>frameworks/base/core/res/res/values/config.xml</code>
+for details about each configuration option.</p>
+<h3 id="key-maps">Key Maps</h3>
+<p>Key maps are used by the Android <code>EventHub</code> and <code>InputReader</code> components
+to configure the mapping from Linux event codes to Android event codes
+for keys, joystick buttons and joystick axes. The mapping may
+be device or language dependent.</p>
+<p>Refer to the device class sections for details about how different
+devices use key maps.</p>
+<h3 id="input-device-configuration-files">Input Device Configuration Files</h3>
+<p>Input device configuration files are used by the Android <code>EventHub</code> and
+<code>InputReader</code> components to configure special device characteristics
+such as how touch size information is reported.</p>
+<p>Refer to the device class sections for details about how different
+devices use input device configuration maps.</p>
+<h2 id="understanding-hid-usages-and-event-codes">Understanding HID Usages and Event Codes</h2>
+<p>There are often several different identifiers used to refer to any
+given key on a keyboard, button on a game controller, joystick axis
+or other control. The relationships between these identifiers
+are not always the same: they are dependent on a set of mapping tables,
+some of which are fixed, and some which vary based on characteristics
+of the device, the device driver, the current locale, the system
+configuration, user preferences and other factors.</p>
+<dl>
+<dt>Physical Scan Code</dt>
+<dd>
+<p>A physical scan code is a device-specific identifier that is associated
+with each key, button or other control. Because physical scan codes
+often vary from one device to another, the firmware or device driver
+is responsible for mapping them to standard identifiers such as
+HID Usages or Linux key codes.</p>
+<p>Scan codes are mainly of interest for keyboards. Other devices
+typically communicate at a low-level using GPIO pins, I2C messages
+or other means. Consequently, the upper layers of the software
+stack rely on the device drivers to make sense of what is going on.</p>
+</dd>
+<dt>HID Usage</dt>
+<dd>
+<p>A HID usage is a standard identifier that is used to report the
+state of a control such as a keyboard key, joystick axis,
+mouse button, or touch contact point. Most USB and Bluetooth
+input devices conform to the HID specification, which enables
+the system to interface with them in a uniform manner.</p>
+<p>The Android Framework relies on the Linux kernel HID drivers to
+translate HID usage codes into Linux key codes and other identifiers.
+Therefore HID usages are mainly of interest to peripheral manufacturers.</p>
+</dd>
+<dt>Linux Key Code</dt>
+<dd>
+<p>A Linux key code is a standard identifier for a key or button.
+Linux key codes are defined in the <code>linux/input.h</code> header file using
+constants that begin with the prefix <code>KEY_</code> or <code>BTN_</code>. The Linux
+kernel input drivers are responsible for translating physical
+scan codes, HID usages and other device-specific signals into Linux
+key codes and delivering information about them as part of
+<code>EV_KEY</code> events.</p>
+<p>The Android API sometimes refers to the Linux key code associated
+with a key as its "scan code". This is technically incorrect in
+but it helps to distinguish Linux key codes from Android key codes
+in the API.</p>
+</dd>
+<dt>Linux Relative or Absolute Axis Code</dt>
+<dd>
+<p>A Linux relative or absolute axis code is a standard identifier
+for reporting relative movements or absolute positions along an
+axis, such as the relative movements of a mouse along its X axis
+or the absolute position of a joystick along its X axis.
+Linux axis code are defined in the <code>linux/input.h</code> header file using
+constants that begin with the prefix <code>REL_</code> or <code>ABS_</code>. The Linux
+kernel input drivers are responsible for translating HID usages
+and other device-specific signals into Linux axis codes and
+delivering information about them as part of <code>EV_REL</code> and
+<code>EV_ABS</code> events.</p>
+</dd>
+<dt>Linux Switch Code</dt>
+<dd>
+<p>A Linux switch code is a standard identifier for reporting the
+state of a switch on a device, such as a lid switch. Linux
+switch codes are defined in the <code>linux/input.h</code> header file
+using constants that begin with the prefix <code>SW_</code>. The Linux
+kernel input drivers report switch state changes as <code>EV_SW</code> events.</p>
+<p>Android applications generally do not receive events from switches,
+but the system may use them interally to control various
+device-specific functions.</p>
+</dd>
+<dt>Android Key Code</dt>
+<dd>
+<p>An Android key code is a standard identifier defined in the Android
+API for indicating a particular key such as 'HOME'. Android key codes
+are defined by the <code>android.view.KeyEvent</code> class as constants that
+begin with the prefix <code>KEYCODE_</code>.</p>
+<p>The key layout specifies how Linux key codes are mapped to Android
+key codes. Different key layouts may be used depending on the keyboard
+model, language, country, layout, or special functions.</p>
+<p>Combinations of Android key codes are transformed into character codes
+using a device and locale specific key character map. For example,
+when the keys identified as <code>KEYCODE_SHIFT</code> and <code>KEYCODE_A</code> are both
+pressed together, the system looks up the combination in the key
+character map and finds the capital letter 'A', which is then inserted
+into the currently focused text widget.</p>
+</dd>
+<dt>Android Axis Code</dt>
+<dd>
+<p>An Android axis code is a standard identifier defined in the Android
+API for indicating a particular device axis. Android axis codes are
+defined by the <code>android.view.MotionEvent</code> class as constants that
+begin with the prefix <code>AXIS_</code>.</p>
+<p>The key layout specifies how Linux Axis Codes are mapped to Android
+axis codes. Different key layouts may be used depending on the device
+model, language, country, layout, or special functions.</p>
+</dd>
+<dt>Android Meta State</dt>
+<dd>
+<p>An Android meta state is a standard identifier defined in the Android
+API for indicating which modifier keys are pressed. Android meta states
+are defined by the <code>android.view.KeyEvent</code> class as constants that
+begin with the prefix <code>META_</code>.</p>
+<p>The current meta state is determined by the Android InputReader
+component which monitors when modifier keys such as <code>KEYCODE_SHIFT_LEFT</code>
+are pressed / released and sets / resets the appropriate meta state flag.</p>
+<p>The relationship between modifier keys and meta states is hardcoded
+but the key layout can alter how the modifier keys themselves are
+mapped which in turns affects the meta states.</p>
+</dd>
+<dt>Android Button State</dt>
+<dd>
+<p>An Android button state is a standard identifier defined in the Android
+API for indicating which buttons (on a mouse or stylus) are pressed.
+Android button states are defined by the <code>android.view.MotionEvent</code>
+class as constants that begin with the prefix <code>BUTTON_</code>.</p>
+<p>The current button state is determined by the Android InputReader
+component which monitors when buttons (on a mouse or stylus) are
+pressed / released and sets / resets appropriate button state flag.</p>
+<p>The relationship between buttons and button states is hardcoded.</p>
+</dd>
+</dl>
+<h2 id="further-reading">Further Reading</h2>
+<ol>
+<li><a href="http://www.kernel.org/doc/Documentation/input/event-codes.txt">Linux input event codes</a></li>
+<li><a href="http://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt">Linux multi-touch protocol</a></li>
+<li><a href="http://www.kernel.org/doc/Documentation/input/input.txt">Linux input drivers</a></li>
+<li><a href="http://www.kernel.org/doc/Documentation/input/ff.txt">Linux force feedback</a></li>
+<li><a href="http://www.usb.org/developers/hidpage">HID information, including HID usage tables</a></li>
+</ol>
diff --git a/src/devices/tech/input/touch-devices.jd b/src/devices/tech/input/touch-devices.jd
new file mode 100644
index 0000000..21567d3
--- /dev/null
+++ b/src/devices/tech/input/touch-devices.jd
@@ -0,0 +1,1163 @@
+page.title=Touch Devices
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Android supports a variety of touch screens and touch pads, including
+stylus-based digitizer tablets.</p>
+<p>Touch screens are touch devices that are associated with a display such that
+the user has the impression of directly manipulating items on screen.</p>
+<p>Touch pads are touch devices that are not associated with a display such as a
+digitizer tablet. Touch pads are typically used for pointing or for
+absolute indirect positioning or gesture-based control of a user interface.</p>
+<p>Touch devices may have buttons whose functions are similar to mouse buttons.</p>
+<p>Touch devices can sometimes be manipulated using a variety of different tools
+such as fingers or a stylus depending on the underlying touch sensor technology.</p>
+<p>Touch devices are sometimes used to implement virtual keys. For example, on
+some Android devices, the touch screen sensor area extends beyond the edge of
+the display and serves dual purpose as part of a touch sensitive key pad.</p>
+<p>Due to the great variety of touch devices, Android relies on a large number of
+configuration properties to describe the characteristics and desired behavior
+of each device.</p>
+<h2 id="touch-device-classification">Touch Device Classification</h2>
+<p>An input device is classified as a <em>multi-touch</em> device if both of
+the following conditions hold:</p>
+<ul>
+<li>
+<p>The input device reports the presence of the <code>ABS_MT_POSITION_X</code> and
+ <code>ABS_MT_POSITION_Y</code> absolute axes.</p>
+</li>
+<li>
+<p>The input device does not have any gamepad buttons. This condition
+ resolves an ambiguity with certain gamepads that report axes with codes
+ that overlaps those of the MT axes.</p>
+</li>
+</ul>
+<p>An input device is classified as a <em>single-touch</em> device if both of the
+following conditions hold:</p>
+<ul>
+<li>
+<p>The input device is not classified as a multi-touch device. An input device
+ is either classified as a single-touch device or as a multi-touch device,
+ never both.</p>
+</li>
+<li>
+<p>The input device reports the presence of the <code>ABS_X</code> and <code>ABS_Y</code> absolute
+ axes, and the presence of the <code>BTN_TOUCH</code> key code.</p>
+</li>
+</ul>
+<p>Once an input device has been classified as a touch device, the presence
+of virtual keys is determined by attempting to load the virtual key map file
+for the device. If a virtual key map is available, then the key layout
+file for the device is also loaded.</p>
+<p>Refer to the section below about the location and format of virtual key map
+files.</p>
+<p>Next, the system loads the input device configuration file for the touch device.</p>
+<p><strong>All built-in touch devices should have input device configuration files.</strong>
+If no input device configuration file is present, the system will
+choose a default configuration that is appropriate for typical general-purpose
+touch peripherals such as external USB or Bluetooth HID touch screens
+or touch pads. These defaults are not designed for built-in touch screens and
+will most likely result in incorrect behavior.</p>
+<p>After the input device configuration loaded, the system will classify the
+input device as a <em>touch screen</em>, <em>touch pad</em> or <em>pointer</em> device.</p>
+<ul>
+<li>
+<p>A <em>touch screen</em> device is used for direct manipulation of objects on the
+ screen. Since the user is directly touching the screen, the system does
+ not require any additional affordances to indicate the objects being
+ manipulated.</p>
+</li>
+<li>
+<p>A <em>touch pad</em> device is used to provide absolute positioning information
+ to an application about touches on a given sensor area. It may be useful
+ for digitizer tablets.</p>
+</li>
+<li>
+<p>A <em>pointer</em> device is used for indirect manipulation of objects on the
+ screen using a cursor. Fingers are interpreted as multi-touch pointer
+ gestures. Other tools, such as styluses, are interpreted using
+ absolute positions.</p>
+<p>See <a href="#indirect-multi-touch-pointer-gestures">Indirect Multi-touch Pointer Gestures</a>
+for more information.</p>
+</li>
+</ul>
+<p>The following rules are used to classify the input device as a <em>touch screen</em>,
+<em>touch pad</em> or <em>pointer</em> device.</p>
+<ul>
+<li>
+<p>If the <code>touch.deviceType</code> property is set, then the device type will be
+ set as indicated.</p>
+</li>
+<li>
+<p>If the input device reports the presence of the <code>INPUT_PROP_DIRECT</code>
+ input property (via the <code>EVIOCGPROP</code> ioctl), then the device type will
+ be set to <em>touch screen</em>. This condition assumes that direct input touch
+ devices are attached to a display that is also connected.</p>
+</li>
+<li>
+<p>If the input device reports the presence of the <code>INPUT_PROP_POINTER</code>
+ input property (via the <code>EVIOCGPROP</code> ioctl), then the device type will
+ be set to <em>pointer</em>.</p>
+</li>
+<li>
+<p>If the input device reports the presence of the <code>REL_X</code> or <code>REL_Y</code> relative
+ axes, then the device type will be set to <em>touch pad</em>. This condition
+ resolves an ambiguity for input devices that consist of both a mouse and
+ a touch pad. In this case, the touch pad will not be used to control
+ the pointer because the mouse already controls it.</p>
+</li>
+<li>
+<p>Otherwise, the device type will be set to <em>pointer</em>. This default ensures
+ that touch pads that have not been designated any other special purpose
+ will serve to control the pointer.</p>
+</li>
+</ul>
+<h2 id="buttons">Buttons</h2>
+<p>Buttons are <em>optional</em> controls that may be used by applications to perform
+additional functions. Buttons on touch devices behave similarly to mouse
+buttons and are mainly of use with <em>pointer</em> type touch devices or with a
+stylus.</p>
+<p>The following buttons are supported:</p>
+<ul>
+<li>
+<p><code>BTN_LEFT</code>: mapped to <code>MotionEvent.BUTTON_PRIMARY</code>.</p>
+</li>
+<li>
+<p><code>BTN_RIGHT</code>: mapped to <code>MotionEvent.BUTTON_SECONDARY</code>.</p>
+</li>
+<li>
+<p><code>BTN_MIDDLE</code>: mapped to <code>MotionEvent.BUTTON_MIDDLE</code>.</p>
+</li>
+<li>
+<p><code>BTN_BACK</code> and <code>BTN_SIDE</code>: mapped to <code>MotionEvent.BUTTON_BACK</code>.
+ Pressing this button also synthesizes a key press with the key code
+ <code>KeyEvent.KEYCODE_BACK</code>.</p>
+</li>
+<li>
+<p><code>BTN_FORWARD</code> and <code>BTN_EXTRA</code>: mapped to <code>MotionEvent.BUTTON_FORWARD</code>.
+ Pressing this button also synthesizes a key press with the key code
+ <code>KeyEvent.KEYCODE_FORWARD</code>.</p>
+</li>
+<li>
+<p><code>BTN_STYLUS</code>: mapped to <code>MotionEvent.BUTTON_SECONDARY</code>.</p>
+</li>
+<li>
+<p><code>BTN_STYLUS2</code>: mapped to <code>MotionEvent.BUTTON_TERTIARY</code>.</p>
+</li>
+</ul>
+<h2 id="tools-and-tool-types">Tools and Tool Types</h2>
+<p>A <em>tool</em> is a finger, stylus or other apparatus that is used to interact with
+the touch device. Some touch devices can distinguish between different
+types of tools.</p>
+<p>Elsewhere in Android, as in the <code>MotionEvent</code> API, a <em>tool</em> is often referred
+to as a <em>pointer</em>.</p>
+<p>The following tool types are supported:</p>
+<ul>
+<li>
+<p><code>BTN_TOOL_FINGER</code> and <code>MT_TOOL_FINGER</code>: mapped to <code>MotionEvent.TOOL_TYPE_FINGER</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_PEN</code> and <code>MT_TOOL_PEN</code>: mapped to <code>MotionEvent.TOOL_TYPE_STYLUS</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_RUBBER</code>: mapped to <code>MotionEvent.TOOL_TYPE_ERASER</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_BRUSH</code>: mapped to <code>MotionEvent.TOOL_TYPE_STYLUS</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_PENCIL</code>: mapped to <code>MotionEvent.TOOL_TYPE_STYLUS</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_AIRBRUSH</code>: mapped to <code>MotionEvent.TOOL_TYPE_STYLUS</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_MOUSE</code>: mapped to <code>MotionEvent.TOOL_TYPE_MOUSE</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_LENS</code>: mapped to <code>MotionEvent.TOOL_TYPE_MOUSE</code>.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_DOUBLETAP</code>, <code>BTN_TOOL_TRIPLETAP</code>, and <code>BTN_TOOL_QUADTAP</code>:
+ mapped to <code>MotionEvent.TOOL_TYPE_FINGER</code>.</p>
+</li>
+</ul>
+<h2 id="hovering-vs-touching-tools">Hovering vs. Touching Tools</h2>
+<p>Tools can either be in contact with the touch device or in range and hovering
+above it. Not all touch devices are able to sense the presence of a tool
+hovering above the touch device. Those that do, such as RF-based stylus digitizers,
+can often detect when the tool is within a limited range of the digitizer.</p>
+<p>The <code>InputReader</code> component takes care to distinguish touching tools from hovering
+tools. Likewise, touching tools and hovering tools are reported to applications
+in different ways.</p>
+<p>Touching tools are reported to applications as touch events
+using <code>MotionEvent.ACTION_DOWN</code>, <code>MotionEvent.ACTION_MOVE</code>, <code>MotionEvent.ACTION_DOWN</code>,
+<code>MotionEvent.ACTION_POINTER_DOWN</code> and <code>MotionEvent.ACTION_POINTER_UP</code>.</p>
+<p>Hovering tools are reported to applications as generic motion events using
+<code>MotionEvent.ACTION_HOVER_ENTER</code>, <code>MotionEvent.ACTION_HOVER_MOVE</code>
+and <code>MotionEvent.ACTION_HOVER_EXIT</code>.</p>
+<h2 id="touch-device-driver-requirements">Touch Device Driver Requirements</h2>
+<ol>
+<li>
+<p>Touch device drivers should only register axes and key codes for the axes
+ and buttons that they actually support. Registering excess axes or key codes
+ may confuse the device classification algorithm or cause the system to incorrectly
+ detect the capabilities of the device.</p>
+<p>For example, if the device reports the <code>BTN_TOUCH</code> key code, the system will
+assume that <code>BTN_TOUCH</code> will always be used to indicate whether the tool is
+actually touching the screen or is merely in range and hovering.</p>
+</li>
+<li>
+<p>Single-touch devices use the following Linux input events:</p>
+<ul>
+<li>
+<p><code>ABS_X</code>: <em>(REQUIRED)</em> Reports the X coordinate of the tool.</p>
+</li>
+<li>
+<p><code>ABS_Y</code>: <em>(REQUIRED)</em> Reports the Y coordinate of the tool.</p>
+</li>
+<li>
+<p><code>ABS_PRESSURE</code>: <em>(optional)</em> Reports the physical pressure applied to the tip
+ of the tool or the signal strength of the touch contact.</p>
+</li>
+<li>
+<p><code>ABS_TOOL_WIDTH</code>: <em>(optional)</em> Reports the cross-sectional area or width of the
+ touch contact or of the tool itself.</p>
+</li>
+<li>
+<p><code>ABS_DISTANCE</code>: <em>(optional)</em> Reports the distance of the tool from the surface of
+ the touch device.</p>
+</li>
+<li>
+<p><code>ABS_TILT_X</code>: <em>(optional)</em> Reports the tilt of the tool from the surface of the
+ touch device along the X axis.</p>
+</li>
+<li>
+<p><code>ABS_TILT_Y</code>: <em>(optional)</em> Reports the tilt of the tool from the surface of the
+ touch device along the Y axis.</p>
+</li>
+<li>
+<p><code>BTN_TOUCH</code>: <em>(REQUIRED)</em> Indicates whether the tool is touching the device.</p>
+</li>
+<li>
+<p><code>BTN_LEFT</code>, <code>BTN_RIGHT</code>, <code>BTN_MIDDLE</code>, <code>BTN_BACK</code>, <code>BTN_SIDE</code>, <code>BTN_FORWARD</code>,
+ <code>BTN_EXTRA</code>, <code>BTN_STYLUS</code>, <code>BTN_STYLUS2</code>:
+ <em>(optional)</em> Reports <a href="#buttons">button</a> states.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_FINGER</code>, <code>BTN_TOOL_PEN</code>, <code>BTN_TOOL_RUBBER</code>, <code>BTN_TOOL_BRUSH</code>,
+ <code>BTN_TOOL_PENCIL</code>, <code>BTN_TOOL_AIRBRUSH</code>, <code>BTN_TOOL_MOUSE</code>, <code>BTN_TOOL_LENS</code>,
+ <code>BTN_TOOL_DOUBLETAP</code>, <code>BTN_TOOL_TRIPLETAP</code>, <code>BTN_TOOL_QUADTAP</code>:
+ <em>(optional)</em> Reports the <a href="#tools-and-tool-types">tool type</a>.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>Multi-touch devices use the following Linux input events:</p>
+<ul>
+<li>
+<p><code>ABS_MT_POSITION_X</code>: <em>(REQUIRED)</em> Reports the X coordinate of the tool.</p>
+</li>
+<li>
+<p><code>ABS_MT_POSITION_Y</code>: <em>(REQUIRED)</em> Reports the Y coordinate of the tool.</p>
+</li>
+<li>
+<p><code>ABS_MT_PRESSURE</code>: <em>(optional)</em> Reports the physical pressure applied to the
+ tip of the tool or the signal strength of the touch contact.</p>
+</li>
+<li>
+<p><code>ABS_MT_TOUCH_MAJOR</code>: <em>(optional)</em> Reports the cross-sectional area of the
+ touch contact, or the length of the longer dimension of the touch contact.</p>
+</li>
+<li>
+<p><code>ABS_MT_TOUCH_MINOR</code>: <em>(optional)</em> Reports the length of the shorter dimension of the
+ touch contact. This axis should not be used if <code>ABS_MT_TOUCH_MAJOR</code> is reporting an
+ area measurement.</p>
+</li>
+<li>
+<p><code>ABS_MT_WIDTH_MAJOR</code>: <em>(optional)</em> Reports the cross-sectional area of the tool itself,
+ or the length of the longer dimension of the tool itself.
+ This axis should not be used if the dimensions of the tool itself are unknown.</p>
+</li>
+<li>
+<p><code>ABS_MT_WIDTH_MINOR</code>: <em>(optional)</em> Reports the length of the shorter dimension of
+ the tool itself. This axis should not be used if <code>ABS_MT_WIDTH_MAJOR</code> is reporting
+ an area measurement or if the dimensions of the tool itself are unknown.</p>
+</li>
+<li>
+<p><code>ABS_MT_ORIENTATION</code>: <em>(optional)</em> Reports the orientation of the tool.</p>
+</li>
+<li>
+<p><code>ABS_MT_DISTANCE</code>: <em>(optional)</em> Reports the distance of the tool from the
+ surface of the touch device.</p>
+</li>
+<li>
+<p><code>ABS_MT_TOOL_TYPE</code>: <em>(optional)</em> Reports the <a href="#tools-and-tool-types">tool type</a> as
+ <code>MT_TOOL_FINGER</code> or <code>MT_TOOL_PEN</code>.</p>
+</li>
+<li>
+<p><code>ABS_MT_TRACKING_ID</code>: <em>(optional)</em> Reports the tracking id of the tool.
+ The tracking id is an arbitrary non-negative integer that is used to identify
+ and track each tool independently when multiple tools are active. For example,
+ when multiple fingers are touching the device, each finger should be assigned a distinct
+ tracking id that is used as long as the finger remains in contact. Tracking ids
+ may be reused when their associated tools move out of range.</p>
+</li>
+<li>
+<p><code>ABS_MT_SLOT</code>: <em>(optional)</em> Reports the slot id of the tool, when using the Linux
+ multi-touch protocol 'B'. Refer to the Linux multi-touch protocol documentation
+ for more details.</p>
+</li>
+<li>
+<p><code>BTN_TOUCH</code>: <em>(REQUIRED)</em> Indicates whether the tool is touching the device.</p>
+</li>
+<li>
+<p><code>BTN_LEFT</code>, <code>BTN_RIGHT</code>, <code>BTN_MIDDLE</code>, <code>BTN_BACK</code>, <code>BTN_SIDE</code>, <code>BTN_FORWARD</code>,
+ <code>BTN_EXTRA</code>, <code>BTN_STYLUS</code>, <code>BTN_STYLUS2</code>:
+ <em>(optional)</em> Reports <a href="#buttons">button</a> states.</p>
+</li>
+<li>
+<p><code>BTN_TOOL_FINGER</code>, <code>BTN_TOOL_PEN</code>, <code>BTN_TOOL_RUBBER</code>, <code>BTN_TOOL_BRUSH</code>,
+ <code>BTN_TOOL_PENCIL</code>, <code>BTN_TOOL_AIRBRUSH</code>, <code>BTN_TOOL_MOUSE</code>, <code>BTN_TOOL_LENS</code>,
+ <code>BTN_TOOL_DOUBLETAP</code>, <code>BTN_TOOL_TRIPLETAP</code>, <code>BTN_TOOL_QUADTAP</code>:
+ <em>(optional)</em> Reports the <a href="#tools-and-tool-types">tool type</a>.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>If axes for both the single-touch and multi-touch protocol are defined, then
+ only the multi-touch axes will be used and the single-touch axes will be ignored.</p>
+</li>
+<li>
+<p>The minimum and maximum values of the <code>ABS_X</code>, <code>ABS_Y</code>, <code>ABS_MT_POSITION_X</code>
+ and <code>ABS_MT_POSITION_Y</code> axes define the bounds of the active area of the device
+ in device-specific surface units. In the case of a touch screen, the active area
+ describes the part of the touch device that actually covers the display.</p>
+<p>For a touch screen, the system automatically interpolates the reported touch
+positions in surface units to obtain touch positions in display pixels according
+to the following calculation:</p>
+<pre><code>displayX = (x - minX) * displayWidth / (maxX - minX + 1)
+displayY = (y - minY) * displayHeight / (maxY - minY + 1)
+</code></pre>
+<p>A touch screen may report touches outside of the reported active area.</p>
+<p>Touches that are initiated outside the active area are not delivered to applications
+but may be used for virtual keys.</p>
+<p>Touches that are initiated inside the active area, or that enter and exit the display
+area are delivered to applications. Consequently, if a touch starts within the
+bounds of an application and then moves outside of the active area, the application
+may receive touch events with display coordinates that are negative or beyond the
+bounds of the display. This is expected behavior.</p>
+<p>A touch device should never clamp touch coordinates to the bounds of the active
+area. If a touch exits the active area, it should be reported as being outside of
+the active area, or it should not be reported at all.</p>
+<p>For example, if the user's finger is touching near the top-left corner of the
+touch screen, it may report a coordinate of (minX, minY). If the finger continues
+to move further outside of the active area, the touch screen should either start
+reporting coordinates with components less than minX and minY, such as
+(minX - 2, minY - 3), or it should stop reporting the touch altogether.
+In other words, the touch screen should <em>not</em> be reporting (minX, minY)
+when the user's finger is really touching outside of the active area.</p>
+<p>Clamping touch coordinates to the display edge creates an artificial
+hard boundary around the edge of the screen which prevents the system from
+smoothly tracking motions that enter or exit the bounds of the display area.</p>
+</li>
+<li>
+<p>The values reported by <code>ABS_PRESSURE</code> or <code>ABS_MT_PRESSURE</code>, if they
+ are reported at all, must be non-zero when the tool is touching the device
+ and zero otherwise to indicate that the tool is hovering.</p>
+<p>Reporting pressure information is <em>optional</em> but strongly recommended.
+Applications can use pressure information to implement pressure-sensitive drawing
+and other effects.</p>
+</li>
+<li>
+<p>The values reported by <code>ABS_TOOL_WIDTH</code>, <code>ABS_MT_TOUCH_MAJOR</code>, <code>ABS_MT_TOUCH_MINOR</code>,
+ <code>ABS_MT_WIDTH_MAJOR</code>, or <code>ABS_MT_WIDTH_MINOR</code> should be non-zero when the tool
+ is touching the device and zero otherwise, but this is not required.
+ For example, the touch device may be able to measure the size of finger touch
+ contacts but not stylus touch contacts.</p>
+<p>Reporting size information is <em>optional</em> but strongly recommended.
+Applications can use pressure information to implement size-sensitive drawing
+and other effects.</p>
+</li>
+<li>
+<p>The values reported by <code>ABS_DISTANCE</code> or <code>ABS_MT_DISTANCE</code> should approach
+ zero when the tool is touching the device. The distance may remain non-zero
+ even when the tool is in direct contact. The exact values reported depend
+ on the manner in which the hardware measures distance.</p>
+<p>Reporting distance information is <em>optional</em> but recommended for
+stylus devices.</p>
+</li>
+<li>
+<p>The values reported by <code>ABS_TILT_X</code> and <code>ABS_TILT_Y</code> should be zero when the
+ tool is perpendicular to the device. A non-zero tilt is taken as an indication
+ that the tool is held at an incline.</p>
+<p>The tilt angles along the X and Y axes are assumed to be specified in degrees
+from perpendicular. The center point (perfectly perpendicular) is given
+by <code>(max + min) / 2</code> for each axis. Values smaller than the center point
+represent a tilt up or to the left, values larger than the center point
+represent a tilt down or to the right.</p>
+<p>The <code>InputReader</code> converts the X and Y tilt components into a perpendicular
+tilt angle ranging from 0 to <code>PI / 2</code> radians and a planar orientation angle
+ranging from <code>-PI</code> to <code>PI</code> radians. This representation results in a
+description of orientation that is compatible with what is used to describe
+finger touches.</p>
+<p>Reporting tilt information is <em>optional</em> but recommended for stylus devices.</p>
+</li>
+<li>
+<p>If the tool type is reported by <code>ABS_MT_TOOL_TYPE</code>, it will supercede any tool
+ type information reported by <code>BTN_TOOL_*</code>.
+ If no tool type information is available at all, the tool type defaults to
+ <code>MotionEvent.TOOL_TYPE_FINGER</code>.</p>
+</li>
+<li>
+<p>A tool is determined to be active based on the following conditions:</p>
+<ul>
+<li>
+<p>When using the single-touch protocol, the tool is active if <code>BTN_TOUCH</code>,
+ or <code>BTN_TOOL_*</code> is 1.</p>
+<p>This condition implies that the <code>InputReader</code> needs to have at least some
+information about the nature of the tool, either whether it is touching,
+or at least its tool type. If no information is available,
+then the tool is assumed to be inactive (out of range).</p>
+</li>
+<li>
+<p>When using the multi-touch protocol 'A', the tool is active whenever it
+ appears in the most recent sync report. When the tool stops appearing in
+ sync reports, it ceases to exist.</p>
+</li>
+<li>
+<p>When using the multi-touch protocol 'B', the tool is active as long as
+ it has an active slot. When the slot it cleared, the tool ceases to exist.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>A tool is determined to be hovering based on the following conditions:</p>
+<ul>
+<li>
+<p>If the tool is <code>BTN_TOOL_MOUSE</code> or <code>BTN_TOOL_LENS</code>, then the tool
+ is not hovering, even if either of the following conditions are true.</p>
+</li>
+<li>
+<p>If the tool is active and the driver reports pressure information,
+ and the reported pressure is zero, then the tool is hovering.</p>
+</li>
+<li>
+<p>If the tool is active and the driver supports the <code>BTN_TOUCH</code> key code and
+ <code>BTN_TOUCH</code> has a value of zero, then the tool is hovering.</p>
+</li>
+</ul>
+</li>
+<li>
+<p>The <code>InputReader</code> supports both multi-touch protocol 'A' and 'B'. New drivers
+ should use the 'B' protocol but either will work.</p>
+</li>
+<li>
+<p><strong>As of Android Ice Cream Sandwich 4.0, touch screen drivers may need to be changed
+ to comply with the Linux input protocol specification.</strong></p>
+<p>The following changes may be required:</p>
+<ul>
+<li>
+<p>When a tool becomes inactive (finger goes "up"), it should stop appearing
+ in subsequent multi-touch sync reports. When all tools become inactive
+ (all fingers go "up"), the driver should send an empty sync report packet,
+ such as <code>SYN_MT_REPORT</code> followed by <code>SYN_REPORT</code>.</p>
+<p>Previous versions of Android expected "up" events to be reported by sending
+a pressure value of 0. The old behavior was incompatible with the
+Linux input protocol specification and is no longer supported.</p>
+</li>
+<li>
+<p>Physical pressure or signal strength information should be reported using
+ <code>ABS_MT_PRESSURE</code>.</p>
+<p>Previous versions of Android retrieved pressure information from
+<code>ABS_MT_TOUCH_MAJOR</code>. The old behavior was incompatible with the
+Linux input protocol specification and is no longer supported.</p>
+</li>
+<li>
+<p>Touch size information should be reported using <code>ABS_MT_TOUCH_MAJOR</code>.</p>
+<p>Previous versions of Android retrieved size information from
+<code>ABS_MT_TOOL_MAJOR</code>. The old behavior was incompatible with the
+Linux input protocol specification and is no longer supported.</p>
+</li>
+</ul>
+<p>Touch device drivers no longer need Android-specific customizations.
+By relying on the standard Linux input protocol, Android can support a
+wider variety of touch peripherals, such as external HID multi-touch
+touch screens, using unmodified drivers.</p>
+</li>
+</ol>
+<h2 id="touch-device-operation">Touch Device Operation</h2>
+<p>The following is a brief summary of the touch device operation on Android.</p>
+<ol>
+<li>
+<p>The <code>EventHub</code> reads raw events from the <code>evdev</code> driver.</p>
+</li>
+<li>
+<p>The <code>InputReader</code> consumes the raw events and updates internal state about
+ the position and other characteristics of each tool. It also tracks
+ button states.</p>
+</li>
+<li>
+<p>If the BACK or FORWARD buttons were pressed or released, the <code>InputReader</code>
+ notifies the <code>InputDispatcher</code> about the key event.</p>
+</li>
+<li>
+<p>The <code>InputReader</code> determines whether a virtual key press occurred. If so,
+ it notifies the <code>InputDispatcher</code> about the key event.</p>
+</li>
+<li>
+<p>The <code>InputReader</code> determines whether the touch was initiated within the
+ bounds of the display. If so, it notifies the <code>InputDispatcher</code> about
+ the touch event.</p>
+</li>
+<li>
+<p>If there are no touching tools but there is at least one hovering tool,
+ the <code>InputReader</code> notifies the <code>InputDispatcher</code> about the hover event.</p>
+</li>
+<li>
+<p>If the touch device type is <em>pointer</em>, the <code>InputReader</code> performs pointer
+ gesture detection, moves the pointer and spots accordingly and notifies
+ the <code>InputDispatcher</code> about the pointer event.</p>
+</li>
+<li>
+<p>The <code>InputDispatcher</code> uses the <code>WindowManagerPolicy</code> to determine whether
+ the events should be dispatched and whether they should wake the device.
+ Then, the <code>InputDispatcher</code> delivers the events to the appropriate applications.</p>
+</li>
+</ol>
+<h2 id="touch-device-configuration">Touch Device Configuration</h2>
+<p>Touch device behavior is determined by the device's axes, buttons, input properties,
+input device configuration, virtual key map and key layout.</p>
+<p>Refer to the following sections for more details about the files that
+participate in keyboard configuration:</p>
+<ul>
+<li><a href="/tech/input/input-device-configuration-files.html">Input Device Configuration Files</a></li>
+<li><a href="#virtual-key-map-files">Virtual Key Map Files</a></li>
+</ul>
+<h3 id="properties">Properties</h3>
+<p>The system relies on many input device configuration properties to configure
+and calibrate touch device behavior.</p>
+<p>One reason for this is that the device drivers for touch devices often report
+the characteristics of touches using device-specific units.</p>
+<p>For example, many touch devices measure the touch contact area
+using an internal device-specific scale, such as the total number of
+sensor nodes that were triggered by the touch. This raw size value would
+not be meaningful applications because they would need to know about the
+physical size and other characteristics of the touch device sensor nodes.</p>
+<p>The system uses calibration parameters encoded in input device configuration
+files to decode, transform, and normalize the values reported by the touch
+device into a simpler standard representation that applications can understand.</p>
+<h3 id="documentation-conventions">Documentation Conventions</h3>
+<p>For documentation purposes, we will use the following conventions to describe
+the values used by the system during the calibration process.</p>
+<h4 id="raw-axis-values">Raw Axis Values</h4>
+<p>The following expressions denote the raw values reported by the touch
+device driver as <code>EV_ABS</code> events.</p>
+<dl>
+<dt><code>raw.x</code></dt>
+<dd>The value of the <code>ABS_X</code> or <code>ABS_MT_POSITION_X</code> axis.</dd>
+<dt><code>raw.y</code></dt>
+<dd>The value of the <code>ABS_Y</code> or <code>ABS_MT_POSITION_Y</code> axis.</dd>
+<dt><code>raw.pressure</code></dt>
+<dd>The value of the <code>ABS_PRESSURE</code> or <code>ABS_MT_PRESSURE</code> axis, or 0 if not available.</dd>
+<dt><code>raw.touchMajor</code></dt>
+<dd>The value of the <code>ABS_MT_TOUCH_MAJOR</code> axis, or 0 if not available.</dd>
+<dt><code>raw.touchMinor</code></dt>
+<dd>The value of the <code>ABS_MT_TOUCH_MINOR</code> axis, or <code>raw.touchMajor</code> if not available.</dd>
+<dt><code>raw.toolMajor</code></dt>
+<dd>The value of the <code>ABS_TOOL_WIDTH</code> or <code>ABS_MT_WIDTH_MAJOR</code> axis, or 0 if not available.</dd>
+<dt><code>raw.toolMinor</code></dt>
+<dd>The value of the <code>ABS_MT_WIDTH_MINOR</code> axis, or <code>raw.toolMajor</code> if not available.</dd>
+<dt><code>raw.orientation</code></dt>
+<dd>The value of the <code>ABS_MT_ORIENTATION</code> axis, or 0 if not available.</dd>
+<dt><code>raw.distance</code></dt>
+<dd>The value of the <code>ABS_DISTANCE</code> or <code>ABS_MT_DISTANCE</code> axis, or 0 if not available.</dd>
+<dt><code>raw.tiltX</code></dt>
+<dd>The value of the <code>ABS_TILT_X</code> axis, or 0 if not available.</dd>
+<dt><code>raw.tiltY</code></dt>
+<dd>The value of the <code>ABS_TILT_Y</code> axis, or 0 if not available.</dd>
+</dl>
+<h4 id="raw-axis-ranges">Raw Axis Ranges</h4>
+<p>The following expressions denote the bounds of raw values. They are obtained
+by calling <code>EVIOCGABS</code> ioctl for each axis.</p>
+<dl>
+<dt><code>raw.*.min</code></dt>
+<dd>The inclusive minimum value of the raw axis.</dd>
+<dt><code>raw.*.max</code></dt>
+<dd>The inclusive maximum value of the raw axis.</dd>
+<dt><code>raw.*.range</code></dt>
+<dd>Equivalent to <code>raw.*.max - raw.*.min</code>.</dd>
+<dt><code>raw.*.fuzz</code></dt>
+<dd>The accuracy of the raw axis. eg. fuzz = 1 implies values are accurate to +/- 1 unit.</dd>
+<dt><code>raw.width</code></dt>
+<dd>The inclusive width of the touch area, equivalent to <code>raw.x.range + 1</code>.</dd>
+<dt><code>raw.height</code></dt>
+<dd>The inclusive height of the touch area, equivalent to <code>raw.y.range + 1</code>.</dd>
+</dl>
+<h4 id="output-ranges">Output Ranges</h4>
+<p>The following expressions denote the characteristics of the output coordinate system.
+The system uses linear interpolation to translate touch position information from
+the surface units used by the touch device into the output units that will
+be reported to applications such as display pixels.</p>
+<dl>
+<dt><code>output.width</code></dt>
+<dd>The output width. For touch screens (associated with a display), this
+is the display width in pixels. For touch pads (not associated with a display),
+the output width equals <code>raw.width</code>, indicating that no interpolation will
+be performed.</dd>
+<dt><code>output.height</code></dt>
+<dd>The output height. For touch screens (associated with a display), this
+is the display height in pixels. For touch pads (not associated with a display),
+the output height equals <code>raw.height</code>, indicating that no interpolation will
+be performed.</dd>
+<dt><code>output.diag</code></dt>
+<dd>The diagonal length of the output coordinate system, equivalent to
+<code>sqrt(output.width ^2 + output.height ^2)</code>.</dd>
+</dl>
+<h3 id="basic-configuration">Basic Configuration</h3>
+<p>The touch input mapper uses many configuration properties in the input device
+configuration file to specify calibration values. The following table describes
+some general purpose configuration properties. All other properties are described
+in the following sections along with the fields they are used to calibrate.</p>
+<h4 id="touchdevicetype"><code>touch.deviceType</code></h4>
+<p><em>Definition:</em> <code>touch.deviceType</code> = <code>touchScreen</code> | <code>touchPad</code> | <code>pointer</code> | <code>default</code></p>
+<p>Specifies the touch device type.</p>
+<ul>
+<li>
+<p>If the value is <code>touchScreen</code>, the touch device is a touch screen associated
+ with a display.</p>
+</li>
+<li>
+<p>If the value is <code>touchPad</code>, the touch device is a touch pad not associated
+ with a display.</p>
+</li>
+<li>
+<p>If the value is <code>pointer</code>, the touch device is a touch pad not associated
+ with a display, and its motions are used for
+ <a href="#indirect-multi-touch-pointer-gestures">indirect multi-touch pointer gestures</a>.</p>
+</li>
+<li>
+<p>If the value is <code>default</code>, the system automatically detects the device type
+ according to the classification algorithm.</p>
+</li>
+</ul>
+<p>Refer to the <a href="#touch-device-classification">Classification</a> section for more details
+about how the device type influences the behavior of the touch device.</p>
+<p>Prior to Honeycomb, all touch devices were assumed to be touch screens.</p>
+<h4 id="touchorientationaware"><code>touch.orientationAware</code></h4>
+<p><em>Definition:</em> <code>touch.orientationAware</code> = <code>0</code> | <code>1</code></p>
+<p>Specifies whether the touch device should react to display orientation changes.</p>
+<ul>
+<li>
+<p>If the value is <code>1</code>, touch positions reported by the touch device are rotated
+ whenever the display orientation changes.</p>
+</li>
+<li>
+<p>If the value is <code>0</code>, touch positions reported by the touch device are immune
+ to display orientation changes.</p>
+</li>
+</ul>
+<p>The default value is <code>1</code> if the device is a touch screen, <code>0</code> otherwise.</p>
+<p>The system distinguishes between internal and external touch screens and displays.
+An orientation aware internal touch screen is rotated based on the orientation
+of the internal display. An orientation aware external touch screen is rotated
+based on the orientation of the external display.</p>
+<p>Orientation awareness is used to support rotation of touch screens on devices
+like the Nexus One. For example, when the device is rotated clockwise 90 degrees
+from its natural orientation, the absolute positions of touches are remapped such
+that a touch in the top-left corner of the touch screen's absolute coordinate system
+is reported as a touch in the top-left corner of the display's rotated coordinate system.
+This is done so that touches are reported with the same coordinate system that
+applications use to draw their visual elements.</p>
+<p>Prior to Honeycomb, all touch devices were assumed to be orientation aware.</p>
+<h4 id="touchgesturemode"><code>touch.gestureMode</code></h4>
+<p><em>Definition:</em> <code>touch.gestureMode</code> = <code>pointer</code> | <code>spots</code> | <code>default</code></p>
+<p>Specifies the presentation mode for pointer gestures. This configuration property
+is only relevant when the touch device is of type <em>pointer</em>.</p>
+<ul>
+<li>
+<p>If the value is <code>pointer</code>, the touch pad gestures are presented by way of a cursor
+ similar to a mouse pointer.</p>
+</li>
+<li>
+<p>If the value is <code>spots</code>, the touch pad gestures are presented by an anchor
+ that represents the centroid of the gesture and a set of circular spots
+ that represent the position of individual fingers.</p>
+</li>
+</ul>
+<p>The default value is <code>pointer</code> when the <code>INPUT_PROP_SEMI_MT</code> input property
+is set, or <code>spots</code> otherwise.</p>
+<h3 id="x-and-y-fields"><code>X</code> and <code>Y</code> Fields</h3>
+<p>The X and Y fields provide positional information for the center of the contact area.</p>
+<h4 id="calculation">Calculation</h4>
+<p>The calculation is straightforward: positional information from the touch driver is
+linearly interpolated to the output coordinate system.</p>
+<pre><code>xScale = output.width / raw.width
+yScale = output.height / raw.height
+
+If not orientation aware or screen rotation is 0 degrees:
+output.x = (raw.x - raw.x.min) * xScale
+output.y = (raw.y - raw.y.min) * yScale
+Else If rotation is 90 degrees:
+ output.x = (raw.y - raw.y.min) * yScale
+ output.y = (raw.x.max - raw.x) * xScale
+Else If rotation is 180 degrees:
+ output.x = (raw.x.max - raw.x) * xScale
+ output.y = (raw.y.max - raw.y) * yScale
+Else If rotation is 270 degrees:
+ output.x = (raw.y.max - raw.y) * yScale
+ output.y = (raw.x - raw.x.min) * xScale
+End If
+</code></pre>
+<h3 id="touchmajor-touchminor-toolmajor-toolminor-size-fields"><code>TouchMajor</code>, <code>TouchMinor</code>, <code>ToolMajor</code>, <code>ToolMinor</code>, <code>Size</code> Fields</h3>
+<p>The <code>TouchMajor</code> and <code>TouchMinor</code> fields describe the approximate dimensions
+of the contact area in output units (pixels).</p>
+<p>The <code>ToolMajor</code> and <code>ToolMinor</code> fields describe the approximate dimensions
+of the <a href="#tools-and-tool-types">tool</a> itself in output units (pixels).</p>
+<p>The <code>Size</code> field describes the normalized size of the touch relative to
+the largest possible touch that the touch device can sense. The smallest
+possible normalized size is 0.0 (no contact, or it is unmeasurable), and the largest
+possible normalized size is 1.0 (sensor area is saturated).</p>
+<p>When both the approximate length and breadth can be measured, then the <code>TouchMajor</code> field
+specifies the longer dimension and the <code>TouchMinor</code> field specifies the shorter dimension
+of the contact area. When only the approximate diameter of the contact area can be measured,
+then the <code>TouchMajor</code> and <code>TouchMinor</code> fields will be equal.</p>
+<p>Likewise, the <code>ToolMajor</code> field specifies the longer dimension and the <code>ToolMinor</code>
+field specifies the shorter dimension of the tool's cross-sectional area.</p>
+<p>If the touch size is unavailable but the tool size is available, then the tool size
+will be set equal to the touch size. Conversely, if the tool size is unavailable
+but the touch size is available, then the touch size will be set equal to the tool size.</p>
+<p>Touch devices measure or report the touch size and tool size in various ways.
+The current implementation supports three different kinds of measurements:
+diameter, area, and geometric bounding box in surface units.</p>
+<h4 id="touchsizecalibration"><code>touch.size.calibration</code></h4>
+<p><em>Definition:</em> <code>touch.size.calibration</code> = <code>none</code> | <code>geometric</code> | <code>diameter</code>
+| <code>area</code> | <code>default</code></p>
+<p>Specifies the kind of measurement used by the touch driver to report the
+touch size and tool size.</p>
+<ul>
+<li>
+<p>If the value is <code>none</code>, the size is set to zero.</p>
+</li>
+<li>
+<p>If the value is <code>geometric</code>, the size is assumed to be specified in the same
+ surface units as the position, so it is scaled in the same manner.</p>
+</li>
+<li>
+<p>If the value is <code>diameter</code>, the size is assumed to be proportional to
+ the diameter (width) of the touch or tool.</p>
+</li>
+<li>
+<p>If the value is <code>area</code>, the size is assumed to be proportional to the
+ area of the touch or tool.</p>
+</li>
+<li>
+<p>If the value is <code>default</code>, the system uses the <code>geometric</code> calibration if the
+ <code>raw.touchMajor</code> or <code>raw.toolMajor</code> axis is available, otherwise it uses
+ the <code>none</code> calibration.</p>
+</li>
+</ul>
+<h4 id="touchsizescale"><code>touch.size.scale</code></h4>
+<p><em>Definition:</em> <code>touch.size.scale</code> = <a non-negative floating point number></p>
+<p>Specifies a constant scale factor used in the calibration.</p>
+<p>The default value is <code>1.0</code>.</p>
+<h4 id="touchsizebias"><code>touch.size.bias</code></h4>
+<p><em>Definition:</em> <code>touch.size.bias</code> = <a non-negative floating point number></p>
+<p>Specifies a constant bias value used in the calibration.</p>
+<p>The default value is <code>0.0</code>.</p>
+<h4 id="touchsizeissummed"><code>touch.size.isSummed</code></h4>
+<p><em>Definition:</em> <code>touch.size.isSummed</code> = <code>0</code> | <code>1</code></p>
+<p>Specifies whether the size is reported as the sum of the sizes of all
+active contacts, or is reported individually for each contact.</p>
+<ul>
+<li>
+<p>If the value is <code>1</code>, the reported size will be divided by the number
+ of contacts prior to use.</p>
+</li>
+<li>
+<p>If the value is <code>0</code>, the reported size will be used as is.</p>
+</li>
+</ul>
+<p>The default value is <code>0</code>.</p>
+<p>Some touch devices, particularly "Semi-MT" devices cannot distinguish the
+individual dimensions of multiple contacts so they report a size measurement
+that represents their total area or width. This property should only be set to
+<code>1</code> for such devices. If in doubt, set this value to <code>0</code>.</p>
+<h4 id="calculation_1">Calculation</h4>
+<p>The calculation of the <code>TouchMajor</code>, <code>TouchMinor</code>, <code>ToolMajor</code>, <code>ToolMinor</code>
+and <code>Size</code> fields depends on the specified calibration parameters.</p>
+<pre><code>If raw.touchMajor and raw.toolMajor are available:
+ touchMajor = raw.touchMajor
+ touchMinor = raw.touchMinor
+ toolMajor = raw.toolMajor
+ toolMinor = raw.toolMinor
+Else If raw.touchMajor is available:
+ toolMajor = touchMajor = raw.touchMajor
+ toolMinor = touchMinor = raw.touchMinor
+Else If raw.toolMajor is available:
+ touchMajor = toolMajor = raw.toolMajor
+ touchMinor = toolMinor = raw.toolMinor
+Else
+ touchMajor = toolMajor = 0
+ touchMinor = toolMinor = 0
+ size = 0
+End If
+
+size = avg(touchMajor, touchMinor)
+
+If touch.size.isSummed == 1:
+ touchMajor = touchMajor / numberOfActiveContacts
+ touchMinor = touchMinor / numberOfActiveContacts
+ toolMajor = toolMajor / numberOfActiveContacts
+ toolMinor = toolMinor / numberOfActiveContacts
+ size = size / numberOfActiveContacts
+End If
+
+If touch.size.calibration == "none":
+ touchMajor = toolMajor = 0
+ touchMinor = toolMinor = 0
+ size = 0
+Else If touch.size.calibration == "geometric":
+ outputScale = average(output.width / raw.width, output.height / raw.height)
+ touchMajor = touchMajor * outputScale
+ touchMinor = touchMinor * outputScale
+ toolMajor = toolMajor * outputScale
+ toolMinor = toolMinor * outputScale
+Else If touch.size.calibration == "area":
+ touchMajor = sqrt(touchMajor)
+ touchMinor = touchMajor
+ toolMajor = sqrt(toolMajor)
+ toolMinor = toolMajor
+Else If touch.size.calibration == "diameter":
+ touchMinor = touchMajor
+ toolMinor = toolMajor
+End If
+
+If touchMajor != 0:
+ output.touchMajor = touchMajor * touch.size.scale + touch.size.bias
+Else
+ output.touchMajor = 0
+End If
+
+If touchMinor != 0:
+ output.touchMinor = touchMinor * touch.size.scale + touch.size.bias
+Else
+ output.touchMinor = 0
+End If
+
+If toolMajor != 0:
+ output.toolMajor = toolMajor * touch.size.scale + touch.size.bias
+Else
+ output.toolMajor = 0
+End If
+
+If toolMinor != 0:
+ output.toolMinor = toolMinor * touch.size.scale + touch.size.bias
+Else
+ output.toolMinor = 0
+End If
+
+output.size = size
+</code></pre>
+<h3 id="pressure-field"><code>Pressure</code> Field</h3>
+<p>The <code>Pressure</code> field describes the approximate physical pressure applied to the
+touch device as a normalized value between 0.0 (no touch) and 1.0 (full force).</p>
+<p>A zero pressure indicates that the tool is hovering.</p>
+<h4 id="touchpressurecalibration"><code>touch.pressure.calibration</code></h4>
+<p><em>Definition:</em> <code>touch.pressure.calibration</code> = <code>none</code> | <code>physical</code> | <code>amplitude</code> | <code>default</code></p>
+<p>Specifies the kind of measurement used by the touch driver to report the pressure.</p>
+<ul>
+<li>
+<p>If the value is <code>none</code>, the pressure is unknown so it is set to 1.0 when
+ touching and 0.0 when hovering.</p>
+</li>
+<li>
+<p>If the value is <code>physical</code>, the pressure axis is assumed to measure the actual
+ physical intensity of pressure applied to the touch pad.</p>
+</li>
+<li>
+<p>If the value is <code>amplitude</code>, the pressure axis is assumed to measure the signal
+ amplitude, which is related to the size of the contact and the pressure applied.</p>
+</li>
+<li>
+<p>If the value is <code>default</code>, the system uses the <code>physical</code> calibration if the
+ pressure axis available, otherwise uses <code>none</code>.</p>
+</li>
+</ul>
+<h4 id="touchpressurescale"><code>touch.pressure.scale</code></h4>
+<p><em>Definition:</em> <code>touch.pressure.scale</code> = <a non-negative floating point number></p>
+<p>Specifies a constant scale factor used in the calibration.</p>
+<p>The default value is <code>1.0 / raw.pressure.max</code>.</p>
+<h4 id="calculation_2">Calculation</h4>
+<p>The calculation of the <code>Pressure</code> field depends on the specified calibration parameters.</p>
+<pre><code>If touch.pressure.calibration == "physical" or "amplitude":
+ output.pressure = raw.pressure * touch.pressure.scale
+Else
+ If hovering:
+ output.pressure = 0
+ Else
+ output.pressure = 1
+ End If
+End If
+</code></pre>
+<h3 id="orientation-and-tilt-fields"><code>Orientation</code> and <code>Tilt</code> Fields</h3>
+<p>The <code>Orientation</code> field describes the orientation of the touch and tool as an
+angular measurement. An orientation of <code>0</code> indicates that the major axis is
+oriented vertically, <code>-PI/2</code> indicates that the major axis is oriented to the left,
+<code>PI/2</code> indicates that the major axis is oriented to the right. When a stylus
+tool is present, the orientation range may be described in a full circle range
+from <code>-PI</code> or <code>PI</code>.</p>
+<p>The <code>Tilt</code> field describes the inclination of the tool as an angular measurement.
+A tilt of <code>0</code> indicates that the tool is perpendicular to the surface.
+A tilt of <code>PI/2</code> indicates that the tool is flat on the surface.</p>
+<h4 id="touchorientationcalibration"><code>touch.orientation.calibration</code></h4>
+<p><em>Definition:</em> <code>touch.orientation.calibration</code> = <code>none</code> | <code>interpolated</code> | <code>vector</code> | <code>default</code></p>
+<p>Specifies the kind of measurement used by the touch driver to report the orientation.</p>
+<ul>
+<li>
+<p>If the value is <code>none</code>, the orientation is unknown so it is set to 0.</p>
+</li>
+<li>
+<p>If the value is <code>interpolated</code>, the orientation is linearly interpolated such that a
+ raw value of <code>raw.orientation.min</code> maps to <code>-PI/2</code> and a raw value of
+ <code>raw.orientation.max</code> maps to <code>PI/2</code>. The center value of
+ <code>(raw.orientation.min + raw.orientation.max) / 2</code> maps to <code>0</code>.</p>
+</li>
+<li>
+<p>If the value is <code>vector</code>, the orientation is interpreted as a packed vector consisiting
+ of two signed 4-bit fields. This representation is used on Atmel Object Based Protocol
+ parts. When decoded, the vector yields an orientation angle and confidence
+ magnitude. The confidence magnitude is used to scale the size information,
+ unless it is geometric.</p>
+</li>
+<li>
+<p>If the value is <code>default</code>, the system uses the <code>interpolated</code> calibration if the
+ orientation axis available, otherwise uses <code>none</code>.</p>
+</li>
+</ul>
+<h4 id="calculation_3">Calculation</h4>
+<p>The calculation of the <code>Orientation</code> and <code>Tilt</code> fields depends on the specified
+calibration parameters and available input.</p>
+<pre><code>If touch.tiltX and touch.tiltY are available:
+ tiltXCenter = average(raw.tiltX.min, raw.tiltX.max)
+ tiltYCenter = average(raw.tiltY.min, raw.tiltY.max)
+ tiltXAngle = (raw.tiltX - tiltXCenter) * PI / 180
+ tiltYAngle = (raw.tiltY - tiltYCenter) * PI / 180
+ output.orientation = atan2(-sin(tiltXAngle), sinf(tiltYAngle))
+ output.tilt = acos(cos(tiltXAngle) * cos(tiltYAngle))
+Else If touch.orientation.calibration == "interpolated":
+ center = average(raw.orientation.min, raw.orientation.max)
+ output.orientation = PI / (raw.orientation.max - raw.orientation.min)
+ output.tilt = 0
+Else If touch.orientation.calibration == "vector":
+ c1 = (raw.orientation & 0xF0) >> 4
+ c2 = raw.orientation & 0x0F
+
+ If c1 != 0 or c2 != 0:
+ If c1 >= 8 Then c1 = c1 - 16
+ If c2 >= 8 Then c2 = c2 - 16
+ angle = atan2(c1, c2) / 2
+ confidence = sqrt(c1*c1 + c2*c2)
+
+ output.orientation = angle
+
+ If touch.size.calibration == "diameter" or "area":
+ scale = 1.0 + confidence / 16
+ output.touchMajor *= scale
+ output.touchMinor /= scale
+ output.toolMajor *= scale
+ output.toolMinor /= scale
+ End If
+ Else
+ output.orientation = 0
+ End If
+ output.tilt = 0
+Else
+ output.orientation = 0
+ output.tilt = 0
+End If
+
+If orientation aware:
+ If screen rotation is 90 degrees:
+ output.orientation = output.orientation - PI / 2
+ Else If screen rotation is 270 degrees:
+ output.orientation = output.orientation + PI / 2
+ End If
+End If
+</code></pre>
+<h3 id="distance-field"><code>Distance</code> Field</h3>
+<p>The <code>Distance</code> field describes the distance between the tool and the touch device
+surface. A value of 0.0 indicates direct contact and larger values indicate
+increasing distance from the surface.</p>
+<h4 id="touchdistancecalibration"><code>touch.distance.calibration</code></h4>
+<p><em>Definition:</em> <code>touch.distance.calibration</code> = <code>none</code> | <code>scaled</code> | <code>default</code></p>
+<p>Specifies the kind of measurement used by the touch driver to report the distance.</p>
+<ul>
+<li>
+<p>If the value is <code>none</code>, the distance is unknown so it is set to 0.</p>
+</li>
+<li>
+<p>If the value is <code>scaled</code>, the reported distance is multiplied by a
+ constant scale factor.</p>
+</li>
+<li>
+<p>If the value is <code>default</code>, the system uses the <code>scaled</code> calibration if the
+ distance axis available, otherwise uses <code>none</code>.</p>
+</li>
+</ul>
+<h4 id="touchdistancescale"><code>touch.distance.scale</code></h4>
+<p><em>Definition:</em> <code>touch.distance.scale</code> = <a non-negative floating point number></p>
+<p>Specifies a constant scale factor used in the calibration.</p>
+<p>The default value is <code>1.0</code>.</p>
+<h4 id="calculation_4">Calculation</h4>
+<p>The calculation of the <code>Distance</code> field depends on the specified calibration parameters.</p>
+<pre><code>If touch.distance.calibration == "scaled":
+ output.distance = raw.distance * touch.distance.scale
+Else
+ output.distance = 0
+End If
+</code></pre>
+<h3 id="example">Example</h3>
+<pre><code># Input device configuration file for a touch screen that supports pressure,
+# size and orientation. The pressure and size scale factors were obtained
+# by measuring the characteristics of the device itself and deriving
+# useful approximations based on the resolution of the touch sensor and the
+# display.
+#
+# Note that these parameters are specific to a particular device model.
+# Different parameters will need to be used for other devices.
+
+# Basic Parameters
+touch.deviceType = touchScreen
+touch.orientationAware = 1
+
+# Size
+# Based on empirical measurements, we estimate the size of the contact
+# using size = sqrt(area) * 28 + 0.
+touch.size.calibration = area
+touch.size.scale = 28
+touch.size.bias = 0
+touch.size.isSummed = 0
+
+# Pressure
+# Driver reports signal strength as pressure.
+#
+# A normal index finger touch typically registers about 80 signal strength
+# units although we don't expect these values to be accurate.
+touch.pressure.calibration = amplitude
+touch.pressure.scale = 0.0125
+
+# Orientation
+touch.orientation.calibration = vector
+</code></pre>
+<h3 id="compatibility-notes">Compatibility Notes</h3>
+<p>The configuration properties for touch devices changed significantly in
+Android Ice Cream Sandwich 4.0. <strong>All input device configuration files for touch
+devices must be updated to use the new configuration properties.</strong></p>
+<p>Older touch device <a href="#touch-device-driver-requirements">drivers</a> may also need to be
+updated.</p>
+<h2 id="virtual-key-map-files">Virtual Key Map Files</h2>
+<p>Touch devices are often used to implement virtual keys.</p>
+<p>There are several ways of doing this, depending on the capabilities of the
+touch controller. Some touch controllers can be directly configured to implement
+soft keys by setting firmware registers. Other times it is desirable to perform
+the mapping from touch coordinates to key codes in software.</p>
+<p>When virtual keys are implemented in software, the kernel must export a virtual key map
+file called <code>virtualkeys.<devicename></code> as a board property. For example,
+if the touch screen device drivers reports its name as "touchyfeely" then
+the virtual key map file must have the path <code>/sys/board_properties/virtualkeys.touchyfeely</code>.</p>
+<p>A virtual key map file describes the coordinates and Linux key codes of virtual keys
+on the touch screen.</p>
+<p>In addition to the virtual key map file, there must be a corresponding key layout
+file and key character map file to map the Linux key codes to Android key codes and
+to specify the type of the keyboard device (usually <code>SPECIAL_FUNCTION</code>).</p>
+<h3 id="syntax">Syntax</h3>
+<p>A virtual key map file is a plain text file consisting of a sequence of virtual key
+layout descriptions either separated by newlines or by colons.</p>
+<p>Comment lines begin with '#' and continue to the end of the line.</p>
+<p>Each virtual key is described by 6 colon-delimited components:</p>
+<ul>
+<li><code>0x01</code>: A version code. Must always be <code>0x01</code>.</li>
+<li><Linux key code>: The Linux key code of the virtual key.</li>
+<li><centerX>: The X pixel coordinate of the center of the virtual key.</li>
+<li><centerY>: The Y pixel coordinate of the center of the virtual key.</li>
+<li><width>: The width of the virtual key in pixels.</li>
+<li><height>: The height of the virtual key in pixels.</li>
+</ul>
+<p>All coordinates and sizes are specified in terms of the display coordinate system.</p>
+<p>Here is a virtual key map file all written on one line.</p>
+<pre><code># All on one line
+0x01:158:55:835:90:55:0x01:139:172:835:125:55:0x01:102:298:835:115:55:0x01:217:412:835:95:55
+</code></pre>
+<p>The same virtual key map file can also be written on multiple lines.</p>
+<pre><code># One key per line
+0x01:158:55:835:90:55
+0x01:139:172:835:125:55
+0x01:102:298:835:115:55
+0x01:217:412:835:95:55
+</code></pre>
+<p>In the above example, the touch screen has a resolution of 480x800. Accordingly, all of
+the virtual keys have a <centerY> coordinate of 835, which is a little bit below
+the visible area of the touch screen.</p>
+<p>The first key has a Linux scan code of <code>158</code> (<code>KEY_BACK</code>), centerX of <code>55</code>,
+centerY of <code>835</code>, width of <code>90</code> and height of <code>55</code>.</p>
+<h3 id="example_1">Example</h3>
+<p>Virtual key map file: <code>/sys/board_properties/virtualkeys.touchyfeely</code>.</p>
+<pre><code>0x01:158:55:835:90:55
+0x01:139:172:835:125:55
+0x01:102:298:835:115:55
+0x01:217:412:835:95:55
+</code></pre>
+<p>Key layout file: <code>/system/usr/keylayout/touchyfeely.kl</code>.</p>
+<pre><code>key 158 BACK
+key 139 MENU
+key 102 HOME
+key 217 SEARCH
+</code></pre>
+<p>Key character map file: <code>/system/usr/keychars/touchyfeely.kcm</code>.</p>
+<pre><code>type SPECIAL_FUNCTION
+</code></pre>
+<h2 id="indirect-multi-touch-pointer-gestures">Indirect Multi-touch Pointer Gestures</h2>
+<p>In pointer mode, the system interprets the following gestures:</p>
+<ol>
+<li>
+<p>Single finger tap: click.</p>
+</li>
+<li>
+<p>Single finger motion: move the pointer.</p>
+</li>
+<li>
+<p>Single finger motion plus button presses: drag the pointer.</p>
+</li>
+<li>
+<p>Two finger motion both fingers moving in the same direction: drag the area under the pointer
+ in that direction. The pointer itself does not move.</p>
+</li>
+<li>
+<p>Two finger motion both fingers moving towards each other or apart in
+ different directions: pan/scale/rotate the area surrounding the pointer.
+ The pointer itself does not move.</p>
+</li>
+<li>
+<p>Multiple finger motion: freeform gesture.</p>
+</li>
+</ol>
+<h2 id="further-reading">Further Reading</h2>
+<ol>
+<li><a href="http://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt">Linux multi-touch protocol</a></li>
+<li><a href="http://lii-enac.fr/en/architecture/linux-input/multitouch-devices.html">ENAC list of available multitouch devices on Linux</a></li>
+</ol>
diff --git a/src/devices/tech/input/validate-keymaps.jd b/src/devices/tech/input/validate-keymaps.jd
new file mode 100644
index 0000000..7730f11
--- /dev/null
+++ b/src/devices/tech/input/validate-keymaps.jd
@@ -0,0 +1,85 @@
+page.title=Validate Keymaps Tool
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android framework has a small tool called <code>validatekeymaps</code> to validate the
+syntax of input device configuration files, key layout files, key character
+maps files and virtual key definition files.</p>
+<h2 id="compilation">Compilation</h2>
+<p>To compile <code>validatekeymaps</code>, set up the development environment, download
+the Android source tree, compile it, then run:</p>
+<pre><code>$ mmm frameworks/base/tools/validatekeymaps
+</code></pre>
+<p>This command should compile a host tool called validatekeymaps into the
+<code>out/host/&lt;os&gt;/bin</code> directory.</p>
+<h2 id="usage">Usage</h2>
+<p>If you ran <code>envsetup.sh</code> to set up your development environment, then the
+<code>validatekeymaps</code> tool should already be on your path. You can verify
+this by running <code>validatekeymaps</code>.</p>
+<pre><code>$ validatekeymaps
+
+Keymap Validation Tool
+
+Usage:
+ validatekeymaps [*.kl] [*.kcm] [*.idc] [virtualkeys.*] [...]
+ Validates the specified key layouts, key character maps,
+ input device configurations, or virtual key definitions.
+</code></pre>
+<p>Then all you need to do is run <code>validatekeymaps</code> an give it the path of
+one or more files to validate.</p>
+<pre><code>$ validatekeymaps frameworks/base/data/keyboards/Generic.kl
+
+Validating file 'frameworks/base/data/keyboards/Generic.kl'...
+No errors.
+
+Success.
+</code></pre>
+<p>And if there is an error...</p>
+<pre><code>$ validatekeymaps Bad.kl
+
+Validating file 'Bad.kl'...
+E/KeyLayoutMap(87688): Bad.kl:24: Expected keyword, got 'ke'.
+Error -22 parsing key layout file.
+
+Failed!
+</code></pre>
+<h2 id="automation">Automation</h2>
+<p>It is a <em>very</em> good idea to run <code>validatekeymaps</code> on all configuration files
+before installing them on a device.</p>
+<p>The process can easily be automated as part of the build system by using a
+script or a makefile.</p>
+<p>The following sample makefile is based on the contents of
+<code>frameworks/base/data/keyboards/Android.mk</code>.</p>
+<pre><code># This makefile performs build time validation of framework keymap files.
+
+LOCAL_PATH := $(call my-dir)
+
+# Validate all key maps.
+include $(CLEAR_VARS)
+
+validatekeymaps := $(HOST_OUT_EXECUTABLES)/validatekeymaps$(HOST_EXECUTABLE_SUFFIX)
+files := MyKeyboard.kl MyKeyboard.kcm MyTouchScreen.idc
+
+LOCAL_MODULE := validate_framework_keymaps
+LOCAL_MODULE_TAGS := optional
+LOCAL_REQUIRED_MODULES := validatekeymaps
+
+validate_framework_keymaps: $(files)
+ $(hide) $(validatekeymaps) $(files)
+
+include $(BUILD_PHONY_PACKAGE)
+</code></pre>
diff --git a/src/devices/tech/kernel.jd b/src/devices/tech/kernel.jd
new file mode 100644
index 0000000..af4700b
--- /dev/null
+++ b/src/devices/tech/kernel.jd
@@ -0,0 +1,290 @@
+page.title=Android Kernel Configuration
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The kernel configuration settings in this document are meant to be used as a base for an Android kernel configuration. All devices should have the options in android-base configuration enabled. While not mandatory, the options in android-recommended configuration enable advanced Android
+features.</p>
+
+<p>
+Generating kernel config: Assuming you already have a minimalist defconfig for your device, a possible
+way to enable these options would be:</p>
+
+<pre>ARCH=<arch> scripts/kconfig/merge_config.sh <path_to>/<device>_defconfig android/configs/android-base.cfg
+android/configs/android-recommended.cfg</pre>
+<p>
+This will generate a .config that can then be used to save a new defconfig or
+compile a new kernel with Android features enabled.
+</p>
+<h3>
+Base Configuration
+</h3>
+<pre>
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_DEBUG=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_PM_AUTOSLEEP=y
+CONFIG_PM_WAKELOCKS=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_INET_ESP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6_PRIVACY=y
+CONFIG_IPV6_ROUTER_PREF=y
+CONFIG_IPV6_OPTIMISTIC_DAD=y
+CONFIG_INET6_AH=y
+CONFIG_INET6_ESP=y
+CONFIG_INET6_IPCOMP=y
+CONFIG_IPV6_MIP6=y
+CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CONNTRACK_EVENTS=y
+CONFIG_NF_CT_PROTO_DCCP=y
+CONFIG_NF_CT_PROTO_SCTP=y
+CONFIG_NF_CT_PROTO_UDPLITE=y
+CONFIG_NF_CONNTRACK_AMANDA=y
+CONFIG_NF_CONNTRACK_FTP=y
+CONFIG_NF_CONNTRACK_H323=y
+CONFIG_NF_CONNTRACK_IRC=y
+CONFIG_NF_CONNTRACK_NETBIOS_NS=y
+CONFIG_NF_CONNTRACK_PPTP=y
+CONFIG_NF_CONNTRACK_SANE=y
+CONFIG_NF_CONNTRACK_TFTP=y
+CONFIG_NF_CT_NETLINK=y
+CONFIG_NETFILTER_TPROXY=y
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
+CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
+CONFIG_NETFILTER_XT_TARGET_MARK=y
+CONFIG_NETFILTER_XT_TARGET_NFLOG=y
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
+CONFIG_NETFILTER_XT_TARGET_TPROXY=y
+CONFIG_NETFILTER_XT_TARGET_TRACE=y
+CONFIG_NETFILTER_XT_MATCH_COMMENT=y
+CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
+CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
+CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
+CONFIG_NETFILTER_XT_MATCH_HELPER=y
+CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
+CONFIG_NETFILTER_XT_MATCH_LENGTH=y
+CONFIG_NETFILTER_XT_MATCH_LIMIT=y
+CONFIG_NETFILTER_XT_MATCH_MAC=y
+CONFIG_NETFILTER_XT_MATCH_MARK=y
+CONFIG_NETFILTER_XT_MATCH_POLICY=y
+CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
+CONFIG_NETFILTER_XT_MATCH_QTAGUID=y
+CONFIG_NETFILTER_XT_MATCH_QUOTA=y
+CONFIG_NETFILTER_XT_MATCH_QUOTA2=y
+CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG=y
+CONFIG_NETFILTER_XT_MATCH_SOCKET=y
+CONFIG_NETFILTER_XT_MATCH_STATE=y
+CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
+CONFIG_NETFILTER_XT_MATCH_STRING=y
+CONFIG_NETFILTER_XT_MATCH_TIME=y
+CONFIG_NETFILTER_XT_MATCH_U32=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_MATCH_AH=y
+CONFIG_IP_NF_MATCH_ECN=y
+CONFIG_IP_NF_MATCH_TTL=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_TARGET_REJECT_SKERR=y
+CONFIG_NF_NAT=y
+CONFIG_IP_NF_TARGET_MASQUERADE=y
+CONFIG_IP_NF_TARGET_NETMAP=y
+CONFIG_IP_NF_TARGET_REDIRECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_IP_NF_RAW=y
+CONFIG_IP_NF_ARPTABLES=y
+CONFIG_IP_NF_ARPFILTER=y
+CONFIG_IP_NF_ARP_MANGLE=y
+CONFIG_NF_CONNTRACK_IPV6=y
+CONFIG_IP6_NF_IPTABLES=y
+CONFIG_IP6_NF_FILTER=y
+CONFIG_IP6_NF_TARGET_REJECT=y
+CONFIG_IP6_NF_TARGET_REJECT_SKERR=y
+CONFIG_IP6_NF_MANGLE=y
+CONFIG_IP6_NF_RAW=y
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_HTB=y
+CONFIG_NET_CLS_U32=y
+CONFIG_NET_EMATCH=y
+CONFIG_NET_EMATCH_U32=y
+CONFIG_NET_CLS_ACT=y
+CONFIG_NETDEVICES=y
+CONFIG_TUN=y
+CONFIG_PPP=y
+CONFIG_PPP_BSDCOMP=y
+CONFIG_PPP_DEFLATE=y
+CONFIG_PPP_MPPE=y
+CONFIG_PPPOLAC=y
+CONFIG_PPPOPNS=y
+CONFIG_FB=y
+CONFIG_SYNC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_G_ANDROID=y
+CONFIG_USB_OTG_WAKELOCK=y
+CONFIG_SWITCH=y
+CONFIG_RTC_CLASS=y
+CONFIG_STAGING=y
+CONFIG_ANDROID=y
+CONFIG_ANDROID_BINDER_IPC=y
+CONFIG_ASHMEM=y
+CONFIG_ANDROID_LOGGER=y
+CONFIG_ANDROID_LOW_MEMORY_KILLER=y
+CONFIG_ANDROID_INTF_ALARM_DEV=y
+</pre>
+
+<h3>Recommended Configuration</h3>
+
+<pre>
+CONFIG_PANIC_TIMEOUT=5
+CONFIG_KALLSYMS_ALL=y
+CONFIG_PERF_EVENTS=y
+CONFIG_COMPACTION=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_WAKELOCKS_LIMIT=0
+# CONFIG_PM_WAKELOCKS_GC is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_PM_DEBUG=y
+CONFIG_SUSPEND_TIME=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_UID_STAT=y
+CONFIG_MD=y
+CONFIG_DM_UEVENT=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_KEYRESET=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_JOYSTICK=y
+CONFIG_JOYSTICK_XPAD=y
+CONFIG_JOYSTICK_XPAD_FF=y
+CONFIG_JOYSTICK_XPAD_LEDS=y
+CONFIG_INPUT_TABLET=y
+CONFIG_TABLET_USB_ACECAD=y
+CONFIG_TABLET_USB_AIPTEK=y
+CONFIG_TABLET_USB_GTCO=y
+CONFIG_TABLET_USB_HANWANG=y
+CONFIG_TABLET_USB_KBTAB=y
+CONFIG_TABLET_USB_WACOM=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_KEYCHORD=y
+CONFIG_INPUT_UINPUT=y
+CONFIG_INPUT_GPIO=y
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_POWER_SUPPLY=y
+CONFIG_BATTERY_ANDROID=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_UHID=y
+CONFIG_USB_HIDDEV=y
+CONFIG_HID_A4TECH=y
+CONFIG_HID_ACRUX=y
+CONFIG_HID_ACRUX_FF=y
+CONFIG_HID_APPLE=y
+CONFIG_HID_BELKIN=y
+CONFIG_HID_CHERRY=y
+CONFIG_HID_CHICONY=y
+CONFIG_HID_PRODIKEYS=y
+CONFIG_HID_CYPRESS=y
+CONFIG_HID_DRAGONRISE=y
+CONFIG_DRAGONRISE_FF=y
+CONFIG_HID_EMS_FF=y
+CONFIG_HID_ELECOM=y
+CONFIG_HID_EZKEY=y
+CONFIG_HID_HOLTEK=y
+CONFIG_HID_KEYTOUCH=y
+CONFIG_HID_KYE=y
+CONFIG_HID_UCLOGIC=y
+CONFIG_HID_WALTOP=y
+CONFIG_HID_GYRATION=y
+CONFIG_HID_TWINHAN=y
+CONFIG_HID_KENSINGTON=y
+CONFIG_HID_LCPOWER=y
+CONFIG_HID_LOGITECH=y
+CONFIG_LOGITECH_FF=y
+CONFIG_LOGIRUMBLEPAD2_FF=y
+CONFIG_LOGIG940_FF=y
+CONFIG_HID_MAGICMOUSE=y
+CONFIG_HID_MICROSOFT=y
+CONFIG_HID_MONTEREY=y
+CONFIG_HID_MULTITOUCH=y
+CONFIG_HID_NTRIG=y
+CONFIG_HID_ORTEK=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_PANTHERLORD_FF=y
+CONFIG_HID_PETALYNX=y
+CONFIG_HID_PICOLCD=y
+CONFIG_HID_PRIMAX=y
+CONFIG_HID_ROCCAT=y
+CONFIG_HID_SAITEK=y
+CONFIG_HID_SAMSUNG=y
+CONFIG_HID_SONY=y
+CONFIG_HID_SPEEDLINK=y
+CONFIG_HID_SUNPLUS=y
+CONFIG_HID_GREENASIA=y
+CONFIG_GREENASIA_FF=y
+CONFIG_HID_SMARTJOYPLUS=y
+CONFIG_SMARTJOYPLUS_FF=y
+CONFIG_HID_TIVO=y
+CONFIG_HID_TOPSEED=y
+CONFIG_HID_THRUSTMASTER=y
+CONFIG_HID_WACOM=y
+CONFIG_HID_WIIMOTE=y
+CONFIG_HID_ZEROPLUS=y
+CONFIG_HID_ZYDACRON=y
+CONFIG_USB_USBNET=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_ION=y
+CONFIG_ANDROID_RAM_CONSOLE=y
+CONFIG_ANDROID_TIMED_GPIO=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_FUSE_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_SCHEDSTATS=y
+CONFIG_TIMER_STATS=y
+CONFIG_SCHED_TRACER=y
+</pre>
\ No newline at end of file
diff --git a/src/devices/tech/power.jd b/src/devices/tech/power.jd
new file mode 100644
index 0000000..3247fbb
--- /dev/null
+++ b/src/devices/tech/power.jd
@@ -0,0 +1,608 @@
+page.title=Power Profiles for Android
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<p>
+Battery usage information is derived from battery usage statistics and power profile
+values.
+</p>
+
+<h2>
+Battery Usage Statistics
+</h2>
+
+<p>
+Battery usage statistics are tracked by the framework. This involves keeping track of time
+spent by different device components in different states. This includes components such as
+WiFi chipset, Cellular Radio, Bluetooth, GPS, Display and CPU. When these components change
+state from off to on, or from idle to full power, low brightness to high brightness, etc.,
+their controlling service reports to the framework’s BatteryStats service, which collects
+such information over time and persists to storage so that it is available across reboots.
+</p>
+
+<p>
+The service isn’t keeping track of battery current draw information directly. It’s collecting
+mostly timing information so that it can be used to approximate battery consumption by
+different components.
+</p>
+
+<p>
+Consumption of these resources is also (where possible) attributed to the applications using
+the resources, sometimes sharing the blame across multiple applications using a resource
+simultaneously. For instance, multiple apps could be holding wakelocks, keeping the system
+from going into suspend state. Blame is shared across these apps (not necessarily equally).
+</p>
+
+<p>
+Statistics are persisted to flash periodically (approximately every half hour or so) to avoid
+losing the information on a shutdown (such as due to battery reaching zero remaining
+capacity, which may indicate a battery power consumption problem).
+</p>
+
+<p>
+Statistics gathering can happen in two ways - push or pull. When services are aware of
+changes happening to a component, they will push state changes to the BatteryStats service.
+With components such as the CPU usage by apps, we pull the data periodically (at certain
+transition points such as starting or stopping an activity, etc) to take a snapshot.
+</p>
+
+<p>
+All of the above is automatically done by the framework, and OEMs don’t need to do anything
+in addition to that.
+</p>
+
+<h2>
+Power Profile Values
+</h2>
+
+<p>
+The power profile is where the device manufacturer needs to provide current consumption
+values for various components and their states in order to approximate the actual battery
+drain caused by these components over time. The power consumption of a component is specified
+in units of milliamps (mA) of current draw (at a nominal voltage) in the power profile, and
+can be a fractional value specifying microamps. The value specified should be the mA consumed
+at the battery (and not a value applicable to a power rail that does not correspond to
+current consumed from the battery).
+</p>
+
+<p>
+For instance, to attribute the cost of keeping the display on for a duration of time, the
+framework gathers brightness levels and times spent at each level (quantized to some number
+of bins). The power profile values specify how many milliamps of current are required to keep
+the display on at minimum brightness and at maximum brightness. The time spent at each
+brightness level can then be multiplied by an interpolated display brightness cost to compute
+an approximation of how much battery was drained by the display component.
+</p>
+
+<p>
+Similarly, CPU time for each application is multiplied by the mA to keep the CPU running at a
+certain speed to get a comparative ranking of how much battery each app is consuming due to
+executing CPU code (time as the foreground app and total time including background activity
+are reported separately).
+</p>
+
+<h2>
+Computing power consumption for individual components
+</h2>
+
+<p class="note">
+<strong>Note:</strong> manufacturers usually supply information about how much current an
+individual component consumes. It may be possible to use these values if they are an accurate
+representation of the the current drawn from the device’s battery in practice. However, we
+encourage you validate manufacturer-provided values before entering them in your device’s
+power profile.
+</p>
+
+<p>
+Current consumption for an individual component is calculated by:
+</p>
+
+<ul>
+<li>
+Measuring the current drawn by the device when the component is in the desired state (e.g.,
+on, active, or scanning)
+</li>
+<li>
+Measuring the current drawn by the device when the component is
+off
+</li>
+<li>subtracting (2) from (1).</li>
+
+
+<img></img><p class="img-caption"></p>
+<p>
+We recommend that you measure the current (usually the average instantaneous current) drawn
+on the device at a nominal voltage. This can be accomplished using a bench power supply or
+using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and
+Power Tool software).
+</p>
+<p>
+Take the measurements with no external charger connected to the device, including no USB
+connection to a host (as used for connecting to development hosts via the adb Android Debug
+Bridge), which may draw current from the host and lower the measurements at the battery. If
+the device supports USB On The Go (OTG) then having an OTG device connected may draw
+additional power from the device being measured, so disconnect any such OTG device.
+</p>
+<p>
+While taking measurements, you’ll want to try to keep the rest of the system other than the
+component being measured running at a constant level of power consumption, to avoid
+introducing inaccuracies in the measurements due to changes in other components. System
+activities that may introduce unwanted changes to power measurements include:
+</p>
+<ul>
+<li>
+Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity. You may want to put
+the device into airplane mode when not measuring cell radio power, and individually enable
+Wi-Fi or Bluetooth when appropriate.
+</li>
+<li>
+Screen/backlight on or off. The colors displayed while screen is on can also affect power
+draw on certain screen technologies. Measurements for components other than the screen on
+values should be made with screen turned off. But see the next item for an important
+consideration when the screen is off.
+</p>
+<li>
+System suspended/resumed state. When the screen is off the system may enter a suspend state
+where much of the device may be powered off or placed in a low-power state, probably
+affecting power consumption of the component being measured and possibly introducing large
+variances in power readings as the system periodically resumes to service alarms and such.
+See Controlling and Measuring System Suspend State for more instructions.
+</li>
+<li>
+CPUs changing speed and entering/exiting low-power scheduler idle state. The system may make
+frequent adjustments to the speeds of CPUs, how many CPU cores are online, and other system
+core state such as memory bus speed and voltages of power rails associated with CPUs and
+memory. If these are changing during your measurements then you may want to prevent CPU speed
+scaling operations, which may also reduce the amount of clock and voltage scaling of memory
+busses and other system core components. Scheduling activity may also affect what percentage
+of the time the CPUs spend in low-power idle states. See Controlling and Measuring CPU Speeds
+for more instructions.
+</li>
+</ul>
+<p>
+For instance, to compute the value for <code>screen.on</code>, you would run the device in a stable state,
+with CPU speed held constant, device in airplane mode, with a partial wakelock held to
+prevent system suspend. The current readings in this state should be stable. Take the reading
+- say 200mA. Now turn on the screen at minimum brightness. If the power monitor shows 300mA,
+then <code>screen.on</code> = (300 - 200) = 100mA.
+</p>
+<p>
+For components that don’t have a flat waveform of current consumption when active (such as
+the cellular radio or wifi), you may need to measure an average current over a period of
+time. Your power monitoring tool may be able to compute this average for you.
+</p>
+<p>
+Replacing the battery with an external power source may require working around problems that
+can occur due to not connecting battery thermistor or integrated fuel gauge pins. For
+example, the system might take an invalid battery temperature reading or remaining battery
+capacity reading that could cause the kernel or Android system to shut down. Sometimes these
+problems are avoided through the use of “fake batteries” that replace normal batteries for
+power measurement purposes, constructed to match the dimensions and electrical properties of
+the batteries for the product being measured. Fake batteries can provide signals on
+thermistor or fuel gauge pins that mimic temperature and state of charge readings for a
+normally running system, and may also provide convenient leads for connecting to external
+power supplies. In other cases it may be easier to modify the system to ignore the invalid
+data from the missing battery.
+</p>
+<h3>
+Controlling and Measuring System Suspend State
+</h3>
+<p>
+As mentioned above, system suspend can introduce unwanted variance in power measurements and
+place system components in low power states not appropriate for measuring active power use.
+But at some point you’ll also need to measure the power draw of system suspend state. This
+section describes how to avoid system suspend state when you don’t want it to interfere with
+other measurements, and how to measure the power draw of system suspend state when you do
+want to measure it.
+</p>
+<p>
+To avoid system suspend you can temporarily connect the device to a development host and
+issue the following command to hold a “partial wakelock”:
+</p>
+<pre>
+$ adb shell "echo temporary > /sys/power/wake_lock"
+</pre>
+<p>
+which will prevent the system from suspending while the screen is off. Disconnect the USB
+cable before making measurements.
+</p>
+<p>
+You can undo the effect of this later with:
+</p>
+<pre>
+$ adb shell "echo temporary > /sys/power/wake_unlock"
+</pre>
+<p>
+The power consumption of the system suspend state is measured for the value of cpu.idle in
+the power profile. For this measurement it may be best to place the device in airplane mode
+to avoid any concurrent activity by the cellular radio, which may run on a processor separate
+from the portions of the SoC controlled by the system suspend. To ensure the measurement is
+made while the system is in the correct state, it may be necessary to first confirm the
+current readings settle to a steady value within the expected range for the consumption of
+the suspend state of the SoC entered plus the consumption of additional system components
+that remain powered (such as the USB PHY). A system console or other external indication of
+system status (such as turning off an LED when not in suspend) may also be observed during
+the measurement.
+</p>
+<h3>
+Controlling and Measuring CPU Speeds
+</h3>
+<p>
+While active, CPUs can be brought online or put offline, change clock speeds and associated
+voltages (possibly also affecting memory bus speeds and other system core power state), and
+can enter lower power idle states while in the kernel idle loop. Not only are these different
+CPU power states measured for the power profile, it may be necessary to avoid the power draw
+variance when measuring other parameters.
+</p>
+<p>
+The power profile currently assumes all CPUs have the same available speeds and power
+characteristics.
+</p>
+<p>
+While measuring CPU power, or holding CPU power constant in order to make other measurements,
+it may be best to hold the number of CPUs brought online constant, such as to have one CPU
+online and the rest offline / hotplugged out. Keeping all CPUs but one in scheduling idle may
+deliver acceptable results. Stopping the Android framework with adb shell stop can help
+reduce system scheduling activity.
+</p>
+<p>
+You’ll specify the available CPU speeds for your device in the power profile cpu.speeds
+entry. You can get a list of these using
+</p>
+<pre>
+adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
+</pre>
+<p>
+These speeds are matched with their corresponding power measurements in value <code>cpu.active</code>.
+</p>
+<p>
+If your platform’s power consumption is significantly affected by how many cores are brought
+online then you may need to modify the cpufreq driver or governor for your platform to
+control this. For many platforms, the easiest way to control CPU speed is to use the
+“userspace” cpufreq governor and use sysfs interfaces to set the speed. The exact commands
+differ depending on your platform’s cpufreq implementation. The following commands from the
+system console or adb shell could be used to set a speed for 200MHz on a system with only 1
+CPU, or all CPUs sharing a common cpufreq policy:
+</p>
+<pre>
+echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
+echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
+echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+</pre>
+<p>
+which makes sure the new speed is not outside the allowed bounds, sets the new speed, and
+then prints which speed the CPU is actually running at for verification. (If the current
+minimum speed prior to executing the above is above 200000, you may have to reverse the order
+of the first two lines, or execute the first line again, to drop the minimum speed prior to
+setting the maximum speed.)
+</p>
+<p>
+To measure current consumed by a CPU while running at various speeds, you may need to place a
+CPU in a CPU-bound loop such as:
+</p>
+<pre>
+# while true; do true; done
+</pre>
+<p>
+on the system console and take the measurement while the above runs.
+</p>
+<p>
+If your device may limit maximum CPU speed while thermal throttling due to a high temperature
+measurement, possibly as a result of running CPUs at high speeds for sustained periods, then
+watch out for this while taking measurements. You may need to watch system console output, or
+check the kernel log after measuring.
+</p>
+<p>
+For the <code>cpu.active</code> value you can measure the power consumed when the system is not in suspend
+but not executing tasks. The CPU should be in a low-power scheduler “idle loop”, possibly
+executing an ARM Wait For Event instruction or in an SoC-specific low power state with a fast
+exit latency suitable for idle use. There may be more than one idle state in use on your
+platform with differing levels of power consumption; choose a representative idle state for
+longer periods of scheduler idle (several milliseconds). You may need to examine the power
+graph on your measurement equipment and choose samples where the CPU is at its lowest
+consumption, discarding higher samples where the CPU exited idle.
+</p>
+<h3>
+Measuring Screen Power
+</h3>
+<p>
+Screen on power is typically measured with all other devices that are turned on with the
+screen also enabled. For example, the touchscreen and any display backlight would normally
+also be turned on during the measurement, to get a more realistic example of screen on power
+usage.
+</p>
+<p>
+Some display technologies vary in power consumption according to the colors displayed, and so
+power measurements may vary considerably depending on what is on the screen at the time. It’s
+best to choose to display something that has power characteristics of a realistic screen,
+somewhere between the extremes of an all-black screen (which consumes the lowest power for
+some technologies) and an all-white screen. A common choice is a view of a schedule in the
+calendar app, which has a mix of white background and non-white elements.
+</p>
+<p>
+The cost of having the screen on is measured at two points: at minimum display/backlight
+brightness, and at maximum brightness. Setting the display brightness to minimum using the
+Settings app Display Brightness slider might not produce accurate results. The Android UI
+will typically only allow you to set the brightness to a minimum of about 10-20% of the
+possible panel/backlight brightness -- it doesn't allow the user to set brightness so low
+that the screen might not be visible without great effort. If you have a sysfs file that
+controls panel brightness all the way down to the minimum brightness supported by the
+hardware then that's even better.
+</p>
+<p>
+If your platform provides sysfs files that turns the LCD panel, backlight, and touchscreen on
+and off then that’s a good way to take measurements with the screen on and off. Otherwise,
+holding a partial wakelock so the system doesn't go to suspend, and turning on and off the
+screen with the power button, should be fine.
+</p>
+<h3>
+Measuring Wi-Fi Power
+</h3>
+<p>
+It’s recommended to perform Wi-Fi measurements on a relatively quiet network, without
+introducing a lot of additional work processing high volumes of broadcast traffic unrelated
+to the activity being measured.
+</p>
+<p>
+The <code>wifi.on</code> value measures the power consumed when Wi-Fi is enabled but not actively
+transmitting or receiving. This is often measured as the delta between the current draw in
+system suspend (sleep) state with Wi-Fi enabled vs. disabled.
+</p>
+<p>
+The <code>wifi.scan</code> value measures the power consumed during a Wi-Fi scan for access points. Wi-Fi
+scans can be triggered by an app using the WifiManager class <code>startScan()</code> API, which is
+documented at http://developer.android.com/reference/android/net/wifi/WifiManager.html . You
+can also open Settings > Wi-Fi, which will perform scans for access points every few
+seconds with an apparent jump in power consumption, but the screen power must be subtracted
+from these measurements.
+</p>
+<p>
+Network receive and transmit traffic can be generated using controlled setup such as
+<a href="http://en.wikipedia.org/wiki/Iperf">iperf</a> if desired.
+</p>
+<h2>
+List of values and their meaning
+</h2>
+<table>
+<tr>
+ <th>Name</th>
+ <th>Meaning</th>
+ <th>Example value</th>
+ <th>Notes</th>
+</tr>
+<tr>
+ <td>none</td>
+ <td>Nothing</td>
+ <td>0</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>screen.on</td>
+ <td>Additional power used when screen is turned on at minimum brightness </td>
+ <td>200mA</td>
+ <td>Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%.</td>
+</tr>
+
+<tr>
+ <td>screen.full</td>
+ <td>Additional power used when screen is at maximum brightness, compared to screen at minimum brightness</td>
+ <td>100- 300mA</td>
+ <td>A fraction of this value (based on screen brightness) is added to the screen.on value to compute the power usage of the screen.</td>
+</tr>
+
+<tr>
+ <td>bluetooth.active </td>
+ <td>Additional power used when playing audio through bluetooth A2DP</td>
+ <td>14mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>bluetooth.on</td>
+ <td> Additional power used when bluetooth
+is turned on but idle </td>
+ <td>1.4mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>wifi.on </td>
+ <td>Additional power used when wifi is turned on but not
+receiving, transmitting, or scanning</td>
+ <td> 2mA </td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>wifi.active </td>
+ <td>Additional power used when transmitting
+or receiving over Wifi </td>
+ <td>31mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>wifi.scan </td>
+ <td>Additional power used when wifi is scanning for access
+points </td>
+ <td>100mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>dsp.audio </td>
+ <td>Additional power used when audio decoding/encoding via DSP </td>
+ <td>14.1mA </td>
+ <td>Not
+currently used</td>
+</tr>
+
+
+<tr>
+ <td>dsp.video </td>
+ <td>Additional power used when video decoding via DSP</td>
+ <td> 54mA</td>
+ <td> Not currently
+used </td>
+</tr>
+
+<tr>
+ <td>gps.on </td>
+ <td>Additional power used when GPS is acquiring a signal </td>
+ <td>50mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>radio.active </td>
+ <td>Additional
+power used when cellular radio is transmitting/receiving </td>
+ <td>100- 300mA </td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>radio.scanning </td>
+ <td>Additional
+power used when cellular radio is paging the tower </td>
+ <td>1.2mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>radio.on Additional power used when
+the cellular radio is on. </td>
+ <td>This is a multi-value entry, one per signal strength (no signal,
+weak, moderate, strong) </td>
+ <td>1.2mA </td>
+ <td>Some radios boost up their power when there’s no signal and
+they’re trying to find a cell tower. So these numbers could all be the same or decreasing
+with increasing signal strength. If you provide only one value, the same value will be used
+for all strengths. If you provide 2 values, the first will be for no-signal and the second
+for all other strengths, and so on.</td>
+</tr>
+
+<tr>
+ <td>cpu.speeds </td>
+ <td>Multi-value entry that lists each possible CPU
+speed in KHz </td>
+ <td>125000, 250000, 500000, 1000000, 1500000 </td>
+ <td>The number and order of entries need to
+correspond to the mA entries in cpu.active </td>
+</tr>
+
+<tr>
+ <td>cpu.idle </td>
+ <td>Total power drawn by the system when CPUs
+(and the SoC) are in system suspend state </td>
+ <td>3mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>cpu.awake
+</td>
+ <td>Additional power used when CPUs are
+in scheduling idle state (kernel idle loop); system is not in system suspend state </td>
+ <td>50mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>cpu.active </td>
+ <td>Additional power used by CPUs when running at different speeds </td>
+ <td>100, 120, 140, 160,
+200</td>
+ <td>Set the max speed in the kernel to each of the allowed speeds and peg the CPU at that
+speed. The number of entries here correspond to the number of entries in cpu.speeds, in the
+same order. </td>
+</tr>
+
+<tr>
+ <td>battery.capacity </td>
+ <td>The total battery capacity in mAh</td>
+ <td>3000mAh</td>
+ <td></td>
+</tr>
+
+</table>
+
+<p>
+The power_profile.xml file is placed in an overlay in
+device///frameworks/base/core/res/res/xml/power_profile.xml
+</p>
+<h3>
+Sample file
+</h3>
+<pre>
+<!-- Most values are the incremental current used by a feature, in mA (measured at
+nominal voltage). OEM's must measure and provide actual values before shipping a device.
+Example real-world values are given, but they are totally dependent on the platform
+and can vary significantly, so should be measured on the shipping platform with a power meter.
+-->
+0
+200
+160
+10
+<!-- Bluetooth stereo audio playback 10.0 mA -->
+1.3
+0.5
+30
+100
+12
+50
+50
+75
+1.1
+<!-- Strength 0 to BINS-1 (4) -->
+1.1
+
+<!-- Different CPU speeds as reported in
+/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state -->
+
+250000 <!-- 250 MHz -->
+500000 <!-- 500 MHz -->
+750000 <!-- 750 MHz -->
+1000000 <!-- 1 GHz -->
+1200000 <!-- 1.2 GHz -->
+
+<!-- Power consumption when CPU is idle -->
+3.0
+50.1
+<!-- Power consumption at different speeds -->
+
+100 <!-- 250 MHz -->
+120 <!-- 500 MHz -->
+140 <!-- 750 MHz -->
+155 <!-- 1 GHz -->
+175 <!-- 1.2 GHz -->
+
+<!-- This is the battery capacity in mAh -->
+3000
+<!-- Battery capacity is 3000 mAH (at 3.6 Volts) -->
+
+</pre>
\ No newline at end of file
diff --git a/src/tech/security/images/image00.png b/src/devices/tech/security/images/image00.png
similarity index 100%
rename from src/tech/security/images/image00.png
rename to src/devices/tech/security/images/image00.png
Binary files differ
diff --git a/src/tech/security/images/image02.png b/src/devices/tech/security/images/image02.png
similarity index 100%
rename from src/tech/security/images/image02.png
rename to src/devices/tech/security/images/image02.png
Binary files differ
diff --git a/src/tech/security/images/image03.png b/src/devices/tech/security/images/image03.png
similarity index 100%
rename from src/tech/security/images/image03.png
rename to src/devices/tech/security/images/image03.png
Binary files differ
diff --git a/src/tech/security/images/image_gmail_installed.png b/src/devices/tech/security/images/image_gmail_installed.png
similarity index 100%
rename from src/tech/security/images/image_gmail_installed.png
rename to src/devices/tech/security/images/image_gmail_installed.png
Binary files differ
diff --git a/src/tech/security/images/image_install.png b/src/devices/tech/security/images/image_install.png
similarity index 100%
rename from src/tech/security/images/image_install.png
rename to src/devices/tech/security/images/image_install.png
Binary files differ
diff --git a/src/devices/tech/security/index.jd b/src/devices/tech/security/index.jd
new file mode 100644
index 0000000..8c5a864
--- /dev/null
+++ b/src/devices/tech/security/index.jd
@@ -0,0 +1,749 @@
+page.title=Android Security Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<h2 id="introduction">Introduction</h2>
+<p>Android is a modern mobile platform that was designed to be truly open. Android
+applications make use of advanced hardware and software, as well as local and
+served data, exposed through the platform to bring innovation and value to
+consumers. To protect that value, the platform must offer an application
+environment that ensures the security of users, data, applications, the device,
+and the network.</p>
+<p>Securing an open platform requires a robust security architecture and rigorous
+security programs. Android was designed with multi-layered security that
+provides the flexibility required for an open platform, while providing
+protection for all users of the platform.</p>
+<p>Android was designed with developers in mind. Security controls were designed
+to reduce the burden on developers. Security-savvy developers can easily work
+with and rely on flexible security controls. Developers less familiar with
+security will be protected by safe defaults.</p>
+<p>Android was designed with device users in mind. Users are provided visibility
+into how applications work, and control over those applications. This design
+includes the expectation that attackers would attempt to perform common
+attacks, such as social engineering attacks to convince device users to install
+malware, and attacks on third-party applications on Android. Android was
+designed to both reduce the probability of these attacks and greatly limit the
+impact of the attack in the event it was successful.</p>
+<p>This document outlines the goals of the Android security program, describes the
+fundamentals of the Android security architecture, and answers the most
+pertinent questions for system architects and security analysts. This document
+focuses on the security features of Android's core platform and does not
+discuss security issues that are unique to specific applications, such as those
+related to the browser or SMS application. Recommended best practices for
+building Android devices, deploying Android devices, or developing applications
+for Android are not the goal of this document and are provided elsewhere.</p>
+<h1 id="background">Background</h1>
+<p>Android provides an open source platform and application environment for mobile
+devices.</p>
+<p>The main Android platform building blocks are:</p>
+<ul>
+<li>
+<p><strong>Device Hardware</strong>: Android runs on a wide range of hardware configurations
+including smart phones, tablets, and set-top-boxes. Android is
+processor-agnostic, but it does take advantage of some hardware-specific
+security capabilities such as ARM v6 eXecute-Never.</p>
+</li>
+<li>
+<p><strong>Android Operating System</strong>: The core operating system is built on top of
+the Linux kernel. All device resources, like camera functions, GPS data,
+Bluetooth functions, telephony functions, network connections, etc. are
+accessed through the operating system.</p>
+</li>
+<li>
+<p><strong>Android Application Runtime</strong>: Android applications are most often written
+in the Java programming language and run in the Dalvik virtual machine.
+However, many applications, including core Android services and applications
+are native applications or include native libraries. Both Dalvik and native
+applications run within the same security environment, contained within the
+Application Sandbox. Applications get a dedicated part of the filesystem in
+which they can write private data, including databases and raw files.</p>
+</li>
+</ul>
+<p>Android applications extend the core Android operating system. There are two
+primary sources for applications:</p>
+<ul>
+<li>
+<p><strong>Pre-Installed Applications</strong>: Android includes a set of pre-installed
+applications including phone, email, calendar, web browser, and contacts. These
+function both as user applications and to provide key device capabilities that
+can be accessed by other applications. Pre-installed applications may be part
+of the open source Android platform, or they may be developed by an OEM for a
+specific device.</p>
+</li>
+<li>
+<p><strong>User-Installed Applications</strong>: Android provides an open development
+environment supporting any third-party application. Google Play offers
+users hundreds of thousands of applications.</p>
+</li>
+</ul>
+<p>Google provides a set of cloud-based services that are available to any
+compatible Android device. The primary services are:</p>
+<ul>
+<li>
+<p><strong>Google Play</strong>: Google Play is a collection of services that
+allow users to discover, install, and purchase applications from their Android
+device or the web. Google Play makes it easy for developers to reach Android
+users and potential customers. Google Play also provides community review,
+application <a href="https://developer.android.com/guide/publishing/licensing.html">license
+verification</a>,
+and other security services.</p>
+</li>
+<li>
+<p><strong>Android Updates</strong>: The Android update service delivers new capabilities and
+security updates to Android devices, including updates through the web or over
+the air (OTA).</p>
+</li>
+<li>
+<p><strong>Application Services</strong>: Frameworks that allow Android applications to use
+cloud capabilities such as (<a href="https://developer.android.com/guide/topics/data/backup.html">backing
+up</a>) application
+data and settings and cloud-to-device messaging
+(<a href="https://code.google.com/android/c2dm/index.html">C2DM</a>)
+for push messaging.</p>
+</li>
+</ul>
+<p>These services are not part of the Android Open Source Project and are out
+of scope for this document. But they are relevant to the security of most
+Android devices, so a related security document titled “Google Services for
+Android: Security Overview” is available.</p>
+<h2 id="android-security-program-overview">Android Security Program Overview</h2>
+<p>Early on in development, the core Android development team recognized that a
+robust security model was required to enable a vigorous ecosystem of
+applications and devices built on and around the Android platform and supported
+by cloud services. As a result, through its entire development lifecycle,
+Android has been subjected to a professional security program. The Android team
+has had the opportunity to observe how other mobile, desktop, and server platforms
+prevented and reacted to security issues and built a security
+program to address weak points observed in other offerings.</p>
+<p>The key components of the Android Security Program include:</p>
+<ul>
+<li><strong>Design Review</strong>: The Android security process begins early in the
+development lifecycle with the creation of a rich and configurable security
+model and design. Each major feature of the platform is reviewed by engineering
+and security resources, with appropriate security controls integrated into the
+architecture of the system.</li>
+<li><strong>Penetration Testing and Code Review</strong>: During the development of the
+platform, Android-created and open-source components are subject to vigorous
+security reviews. These reviews are performed by the Android Security Team,
+Google’s Information Security Engineering team, and independent security
+consultants. The goal of these reviews is to identify weaknesses and possible
+vulnerabilities well before the platform is open-sourced, and to simulate the
+types of analysis that will be performed by external security experts upon
+release.</li>
+<li><strong>Open Source and Community Review</strong>: The Android Open Source Project enables
+broad security review by any interested party. Android also uses open source
+technologies that have undergone significant external security review,
+such as the Linux kernel. Google Play provides a forum for users and companies
+to provide information about specific applications directly to users.</li>
+<li><strong>Incident Response</strong>: Even with all of these precautions, security issues
+may occur after shipping, which is why the Android project has created a
+comprehensive security response process. A full-time Android security team
+constantly monitors Android-specific and the general security community for
+discussion of potential vulnerabilities. Upon the discovery of legitimate
+issues, the Android team has a response process that enables the rapid
+mitigation of vulnerabilities to ensure that potential risk to all Android
+users is minimized. These cloud-supported responses can include updating the
+Android platform (over-the-air updates), removing applications from Google
+Play, and removing applications from devices in the field.</li>
+</ul>
+<h2 id="android-platform-security-architecture">Android Platform Security Architecture</h2>
+<p>Android seeks to be the most secure and usable operating system for mobile
+platforms by re-purposing traditional operating system security controls to:</p>
+<ul>
+<li>Protect user data</li>
+<li>Protect system resources (including the network)</li>
+<li>Provide application isolation</li>
+</ul>
+<p>To achieve these objectives, Android provides these key security features:</p>
+<ul>
+<li>Robust security at the OS level through the Linux kernel</li>
+<li>Mandatory application sandbox for all applications</li>
+<li>Secure interprocess communication</li>
+<li>Application signing</li>
+<li>Application-defined and user-granted permissions</li>
+</ul>
+<p>The sections below describe these and other security features of the Android
+platform. <em>Figure 1</em> summarizes the security components and considerations of
+the various levels of the Android software stack. Each component assumes that
+the components below are properly secured. With the exception of a small amount
+of Android OS code running as root, all code above the Linux Kernel is
+restricted by the Application Sandbox.</p>
+<p><img alt="Figure 1: Android software stack" src="images/image00.png" /></p>
+<p><em>Figure 1: Android software stack.</em></p>
+<h1 id="system-and-kernel-level-security">System and Kernel Level Security</h1>
+<p>At the operating system level, the Android platform provides the security of
+the Linux kernel, as well as a secure inter-process communication (IPC)
+facility to enable secure communication between applications running in
+different processes. These security features at the OS level ensure that even
+native code is constrained by the Application Sandbox. Whether that code is
+the result of included application behavior or a exploitation of an application
+vulnerability, the system would prevent the rogue application from harming
+other applications, the Android system, or the device itself.</p>
+<h2 id="linux-security">Linux Security</h2>
+<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
+itself has been in widespread use for years, and is used in millions of
+security-sensitive environments. Through its history of constantly being
+researched, attacked, and fixed by thousands of developers, Linux has become a
+stable and secure kernel trusted by many corporations and security
+professionals.</p>
+<p>As the base for a mobile computing environment, the Linux kernel provides
+Android with several key security features, including:</p>
+<ul>
+<li>A user-based permissions model</li>
+<li>Process isolation</li>
+<li>Extensible mechanism for secure IPC</li>
+<li>The ability to remove unnecessary and potentially insecure parts of the kernel</li>
+</ul>
+<p>As a multiuser operating system, a fundamental security objective of the Linux
+kernel is to isolate user resources from one another. The Linux security
+philosophy is to protect user resources from one another. Thus, Linux:</p>
+<ul>
+<li>Prevents user A from reading user B's files</li>
+<li>Ensures that user A does not exhaust user B's memory</li>
+<li>Ensures that user A does not exhaust user B's CPU resources</li>
+<li>Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
+bluetooth)</li>
+</ul>
+<h2 id="the-application-sandbox">The Application Sandbox</h2>
+<p>The Android platform takes advantage of the Linux user-based protection as a
+means of identifying and isolating application resources. The Android system
+assigns a unique user ID (UID) to each Android application and runs it as that user
+in a separate process. This approach is different from other operating systems
+(including the traditional Linux configuration), where multiple applications
+run with the same user permissions.</p>
+<p>This sets up a kernel-level Application Sandbox. The kernel enforces security
+between applications and the system at the process level through standard Linux
+facilities, such as user and group IDs that are assigned to applications. By
+default, applications cannot interact with each other and applications have
+limited access to the operating system. If application A tries to do something
+malicious like read application B's data or dial the phone without permission
+(which is a separate application), then the operating system protects against
+this because application A does not have the appropriate user privileges. The
+sandbox is simple, auditable, and based on decades-old UNIX-style user
+separation of processes and file permissions.</p>
+<p>Since the Application Sandbox is in the kernel, this security model extends to
+native code and to operating system applications. All of the software above the
+kernel in <em>Figure 1</em>, including operating system libraries, application
+framework, application runtime, and all applications run within the Application
+Sandbox. On some platforms, developers are constrained to a specific
+development framework, set of APIs, or language in order to enforce security.
+On Android, there are no restrictions on how an application can be written that
+are required to enforce security; in this respect, native code is just as
+secure as interpreted code.</p>
+<p>In some operating systems, memory corruption errors generally lead to
+completely compromising the security of the device. This is not the case in
+Android due to all applications and their resources being sandboxed at the OS
+level. A memory corruption error will only allow arbitrary code execution in
+the context of that particular application, with the permissions established by
+the operating system.</p>
+<p>Like all security features, the Application Sandbox is not unbreakable.
+However, to break out of the Application Sandbox in a properly configured
+device, one must compromise the security of the the Linux kernel.</p>
+<h2 id="system-partition-and-safe-mode">System Partition and Safe Mode</h2>
+<p>The system partition contains Android's kernel as well as the operating system
+libraries, application runtime, application framework, and applications. This
+partition is set to read-only. When a user boots the device into Safe Mode,
+only core Android applications are available. This ensures that the user can
+boot their phone into an environment that is free of third-party software.</p>
+<h2 id="filesystem-permissions">Filesystem Permissions</h2>
+<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot
+alter or read another user's files. In the case of Android, each application
+runs as its own user. Unless the developer explicitly exposes files to other
+applications, files created by one application cannot be read or altered by
+another application.</p>
+<h2 id="filesystem-encryption">Filesystem Encryption</h2>
+<p>Android 3.0 and later provides full filesystem encryption, so all user data can
+be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
+and ESSIV:SHA256. The encryption key is protected by AES128 using a key
+derived from the user password, preventing unauthorized access to stored data
+without the user device password. To provide resistance against systematic
+password guessing attacks (e.g. “rainbow tables” or brute force), the
+password is combined with a random salt and hashed repeatedly with SHA1 using
+the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
+key. To provide resistance against dictionary password guessing attacks,
+Android provides password complexity rules that can be set by the device
+administrator and enforced by the operating system. Filesystem encryption
+requires the use of a user password, pattern-based screen lock is not supported.</p>
+<p>More details on implementation of filesystem encryption are available at
+<a href="/
+tech/encryption/android_crypto_implementation.html">https://source.android.com/tech/encryption/android_crypto_implementation.html</a></p>
+<h2 id="password-protection">Password Protection</h2>
+<p>Android can be configured to verify a user-supplied password prior to providing
+access to a device. In addition to preventing unauthorized use of the device,
+this password protects the cryptographic key for full filesystem encryption.</p>
+<p>Use of a password and/or password complexity rules can be required by a device
+administrator.</p>
+<h2 id="device-administration">Device Administration</h2>
+<p>Android 2.2 and later provide the Android Device Administration API, which
+provides device administration features at the system level. For example, the
+built-in Android Email application uses the APIs to improve Exchange support.
+Through the Email application, Exchange administrators can enforce password
+policies — including alphanumeric passwords or numeric PINs — across
+devices. Administrators can also remotely wipe (that is, restore factory
+defaults on) lost or stolen handsets.</p>
+<p>In addition to use in applications included with the Android system, these APIs
+are available to third-party providers of Device Management solutions. Details
+on the API are provided here:
+<a href="https://devel
+oper.android.com/guide/topics/admin/device-admin.html">https://developer.android.com/guide/topics/admin/device-admin.html</a>.</p>
+<h2 id="memory-management-security-enhancements">Memory Management Security Enhancements</h2>
+<p>Android includes many features that make common security issues harder to
+exploit. The Android SDK, compilers, and OS use tools to make common memory
+corruption issues significantly harder to exploit, including:</p>
+<p><strong>Android 1.5+</strong></p>
+<ul>
+<li>ProPolice to prevent stack buffer overruns (-fstack-protector)</li>
+<li>safe_iop to reduce integer overflows</li>
+<li>Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and
+to prevent chunk consolidation attacks. Chunk consolidation attacks are a
+common way to exploit heap corruption.</li>
+<li>OpenBSD calloc to prevent integer overflows during memory allocation</li>
+</ul>
+<p><strong>Android 2.3+</strong></p>
+<ul>
+<li>Format string vulnerability protections (-Wformat-security -Werror=format-security)</li>
+<li>Hardware-based No eXecute (NX) to prevent code execution on the stack and heap</li>
+<li>Linux mmap_min_addr to mitigate null pointer dereference privilege
+escalation (further enhanced in Android 4.1)</li>
+</ul>
+<p><strong>Android 4.0+</strong></p>
+<ul>
+<li>Address Space Layout Randomization (ASLR) to randomize key locations in memory</li>
+</ul>
+<p><strong>Android 4.1+</strong></p>
+<ul>
+<li>PIE (Position Independent Executable) support</li>
+<li>Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)</li>
+<li>dmesg_restrict enabled (avoid leaking kernel addresses)</li>
+<li>kptr_restrict enabled (avoid leaking kernel addresses)</li>
+</ul>
+<h2 id="rooting-of-devices">Rooting of Devices</h2>
+<p>By default, on Android only the kernel and a small subset of the core
+applications run with root permissions. Android does not prevent a user or
+application with root permissions from modifying the operating system, kernel,
+and any other application. In general, root has full access to all
+applications and all application data. Users that change the permissions on an
+Android device to grant root access to applications increase the security
+exposure to malicious applications and potential application flaws.</p>
+<p>The ability to modify an Android device they own is important to developers
+working with the Android platform. On many Android devices users have the
+ability to unlock the bootloader in order to allow installation of an alternate
+operating system. These alternate operating systems may allow an owner to gain
+root access for purposes of debugging applications and system components or to
+access features not presented to applications by Android APIs.</p>
+<p>On some devices, a person with physical control of a device and a USB cable is
+able to install a new operating system that provides root privileges to the
+user. To protect any existing user data from compromise the bootloader unlock
+mechanism requires that the bootloader erase any existing user data as part of
+the unlock step. Root access gained via exploiting a kernel bug or security
+hole can bypass this protection.</p>
+<p>Encrypting data with a key stored on-device does not protect the application
+data from root users. Applications can add a layer of data protection using
+encryption with a key stored off-device, such as on a server or a user
+password. This approach can provide temporary protection while the key is not
+present, but at some point the key must be provided to the application and it
+then becomes accessible to root users.</p>
+<p>A more robust approach to protecting data from root users is through the use of
+hardware solutions. OEMs may choose to implement hardware solutions that limit
+access to specific types of content such as DRM for video playback, or the
+NFC-related trusted storage for Google wallet.</p>
+<p>In the case of a lost or stolen device, full filesystem encryption on Android
+devices uses the device password to protect the encryption key, so modifying
+the bootloader or operating system is not sufficient to access user data
+without the user’s device password.</p>
+<h1 id="android-application-security">Android Application Security</h1>
+<h2 id="elements-of-applications">Elements of Applications</h2>
+<p>Android provides an open source platform and application environment for mobile
+devices. The core operating system is based on the Linux kernel. Android
+applications are most often written in the Java programming language and run in
+the Dalvik virtual machine. However, applications can also be written in native
+code. Applications are installed from a single file with the .apk file
+extension.</p>
+<p>The main Android application building blocks are:</p>
+<ul>
+<li>
+<p><strong>AndroidManifest.xml</strong>: The
+<a href="https://developer.android.com/guide/topics/manifest/manifes
+t-intro.html">AndroidManifest.xml</a> file is the control file that tells the system what to do with
+all the top-level components (specifically activities, services, broadcast
+receivers, and content providers described below) in an application. This also
+specifies which permissions are required.</p>
+</li>
+<li>
+<p><strong>Activities</strong>: An
+<a href="https://developer.android.com/guide/topics/fundamentals/activities.htm
+l">Activity</a> is, generally, the code for a single, user-focused task. It usually
+includes displaying a UI to the user, but it does not have to -- some
+Activities never display UIs. Typically, one of the application's Activities
+is the entry point to an application.</p>
+</li>
+<li>
+<p><strong>Services</strong>: A
+<a href="https://developer.android.com/guide/topics/fundamentals/services.html">Service</a>
+is a body of code that runs in the background. It can run in its own process,
+or in the context of another application's process. Other components "bind" to
+a Service and invoke methods on it via remote procedure calls. An example of a
+Service is a media player: even when the user quits the media-selection UI, the
+user probably still intends for music to keep playing. A Service keeps the
+music going even when the UI has completed.</p>
+</li>
+<li>
+<p><strong>Broadcast Receiver</strong>: A
+<a href="https://developer.android.com/reference/android/content/Broad
+castReceiver.html">BroadcastReceiver</a> is an object that is instantiated when an IPC mechanism
+known as an
+<a href="https://developer.android.com/reference/android/content/Intent.html">Intent</a>
+is issued by the operating system or another application. An application may
+register a receiver for the low battery message, for example, and change its
+behavior based on that information.</p>
+</li>
+</ul>
+<h2 id="the-android-permission-model-accessing-protected-apis">The Android Permission Model: Accessing Protected APIs</h2>
+<p>By default, an Android application can only access a limited range of system
+resources. The system manages Android application access to resources that, if
+used incorrectly or maliciously, could adversely impact the user experience,
+the network, or data on the device.</p>
+<p>These restrictions are implemented in a variety of different forms. Some
+capabilities are restricted by an intentional lack of APIs to the sensitive
+functionality (e.g. there is no Android API for directly manipulating the SIM
+card). In some instances, separation of roles provides a security measure, as
+with the per-application isolation of storage. In other instances, the
+sensitive APIs are intended for use by trusted applications and protected
+through a security mechanism known as Permissions.</p>
+<p>These protected APIs include:</p>
+<ul>
+<li>Camera functions</li>
+<li>Location data (GPS)</li>
+<li>Bluetooth functions</li>
+<li>Telephony functions</li>
+<li>SMS/MMS functions</li>
+<li>Network/data connections</li>
+</ul>
+<p>These resources are only accessible through the operating system. To make use
+of the protected APIs on the device, an application must define the
+capabilities it needs in its manifest. When preparing to install an
+application, the system displays a dialog to the user that indicates the
+permissions requested and asks whether to continue the installation. If the
+user continues with the installation, the system accepts that the user has
+granted all of the requested permissions. The user can not grant or deny
+individual permissions -- the user must grant or deny all of the requested
+permissions as a block.</p>
+<p>Once granted, the permissions are applied to the application as long as it is
+installed. To avoid user confusion, the system does not notify the user again
+of the permissions granted to the application, and applications that are
+included in the core operating system or bundled by an OEM do not request
+permissions from the user. Permissions are removed if an application is
+uninstalled, so a subsequent re-installation will again result in display of
+permissions.</p>
+<p>Within the device settings, users are able to view permissions for applications
+they have previously installed. Users can also turn off some functionality
+globally when they choose, such as disabling GPS, radio, or wi-fi.</p>
+<p>In the event that an application attempts to use a protected feature which has
+not been declared in the application's manifest, the permission failure will
+typically result in a security exception being thrown back to the application.
+Protected API permission checks are enforced at the lowest possible level to
+prevent circumvention. An example of the user messaging when an application is
+installed while requesting access to protected APIs is shown in <em>Figure 2</em>.</p>
+<p>The system default permissions are described at
+<a href="https://developer.android.com/reference/android/Manifest.permission.html">https://developer.android.com/reference/android/Manifest.permission.html</a>.
+Applications may declare their own permissions for other applications to use.
+Such permissions are not listed in the above location.</p>
+<p>When defining a permission a protectionLevel attribute tells the system how the
+user is to be informed of applications requiring the permission, or who is
+allowed to hold a permission. Details on creating and using application
+specific permissions are described at
+<a href="https://develo
+per.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
+<p>There are some device capabilities, such as the ability to send SMS broadcast
+intents, that are not available to third-party applications, but that may be
+used by applications pre-installed by the OEM. These permissions use the
+signatureOrSystem permission.</p>
+<h2 id="how-users-understand-third-party-applications">How Users Understand Third-Party Applications</h2>
+<p>Android strives to make it clear to users when they are interacting with
+third-party applications and inform the user of the capabilities those
+applications have. Prior to installation of any application, the user is shown
+a clear message about the different permissions the application is requesting.
+After install, the user is not prompted again to confirm any permissions.</p>
+<p>There are many reasons to show permissions immediately prior to installation
+time. This is when user is actively reviewing information about the
+application, developer, and functionality to determine whether it matches their
+needs and expectations. It is also important that they have not yet
+established a mental or financial commitment to the app, and can easily compare
+the application to other alternative applications.</p>
+<p>Some other platforms use a different approach to user notification, requesting
+permission at the start of each session or while applications are in use. The
+vision of Android is to have users switching seamlessly between applications at
+will. Providing confirmations each time would slow down the user and prevent
+Android from delivering a great user experience. Having the user review
+permissions at install time gives the user the option to not install the
+application if they feel uncomfortable.</p>
+<p>Also, many user interface studies have shown that over-prompting the user
+causes the user to start saying "OK" to any dialog that is shown. One of
+Android's security goals is to effectively convey important security
+information to the user, which cannot be done using dialogs that the user will
+be trained to ignore. By presenting the important information once, and only
+when it is important, the user is more likely to think about what they are
+agreeing to.</p>
+<p>Some platforms choose not to show any information at all about application
+functionality. That approach prevents users from easily understanding and
+discussing application capabilities. While it is not possible for all users to
+always make fully informed decisions, the Android permissions model makes
+information about applications easily accessible to a wide range of users. For
+example, unexpected permissions requests can prompt more sophisticated users to
+ask critical questions about application functionality and share their concerns
+in places such as <a href="htts://play.google.com">Google Play</a> where they
+are visible to all users.</p>
+<table>
+<tr>
+<td><strong>Permissions at Application Install -- Google Maps</strong></td>
+<td><strong>Permissions of an Installed Application -- gMail</strong></td>
+</tr>
+<tr>
+<td>
+<img alt="Permissions at Application Install -- Google Maps" width=250
+src="images/image_install.png"/>
+</td>
+<td>
+<img alt="Permissions of an Installed Application -- gMail" width=250
+src="images/image_gmail_installed.png"/>
+</td>
+</tr>
+</table>
+
+<p><em>Figure 2: Display of permissions for applications</em></p>
+<h2 id="interprocess-communication">Interprocess Communication</h2>
+<p>Processes can communicate using any of the traditional UNIX-type mechanisms.
+Examples include the filesystem, local sockets, or signals. However, the Linux
+permissions still apply.</p>
+<p>Android also provides new IPC mechanisms:</p>
+<ul>
+<li>
+<p><strong>Binder</strong>: A lightweight capability-based remote procedure call mechanism
+designed for high performance when performing in-process and cross-process
+calls. Binder is implemented using a custom Linux driver. See
+<a href="https://developer
+.android.com/reference/android/os/Binder.html">https://developer.android.com/reference/android/os/Binder.html</a>.</p>
+</li>
+<li>
+<p><strong>Services</strong>: Services (discussed above) can provide interfaces directly
+accessible using binder.</p>
+</li>
+<li>
+<p><strong>Intents</strong>: An Intent is a simple message object that represents an
+"intention" to do something. For example, if your application wants to display
+a web page, it expresses its "Intent" to view the URL by creating an Intent
+instance and handing it off to the system. The system locates some other piece
+of code (in this case, the Browser) that knows how to handle that Intent, and
+runs it. Intents can also be used to broadcast interesting events (such as a
+notification) system-wide. See
+[https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html.</p>
+</li>
+<li>
+<p><strong>ContentProviders</strong>: A ContentProvider is a data storehouse that provides
+access to data on the device; the classic example is the ContentProvider that
+is used to access the user's list of contacts. An application can access data
+that other applications have exposed via a ContentProvider, and an application
+can also define its own ContentProviders to expose data of its own. See
+<a href="https://developer.android.com/reference/android/content/ContentProvider.html">https://developer.android.com/reference/android/content/ContentProvider.html</a>.</p>
+</li>
+</ul>
+<p>While it is possible to implement IPC using other mechanisms such as network
+sockets or world-writable files, these are the recommended Android IPC
+frameworks. Android developers will be encouraged to use best practices around
+securing users' data and avoiding the introduction of security vulnerabilities.</p>
+<h2 id="cost-sensitive-apis">Cost-Sensitive APIs</h2>
+<p>A cost sensitive API is any function that might generate a cost for the user or
+the network. The Android platform has placed cost sensitive APIs in the list of
+protected APIs controlled by the OS. The user will have to grant explicit
+permission to third-party applications requesting use of cost sensitive APIs.
+These APIs include:</p>
+<ul>
+<li>Telephony</li>
+<li>SMS/MMS</li>
+<li>Network/Data</li>
+<li>In-App Billing</li>
+<li>NFC Access</li>
+</ul>
+<h2 id="sim-card-access">SIM Card Access</h2>
+<p>Low level access to the SIM card is not available to third-party apps. The OS
+handles all communications with the SIM card including access to personal
+information (contacts) on the SIM card memory. Applications also cannot access
+AT commands, as these are managed exclusively by the Radio Interface Layer
+(RIL). The RIL provides no high level APIs for these commands.</p>
+<h2 id="personal-information">Personal Information</h2>
+<p>Android has placed APIs that provide access to user data into the set of
+protected APIs. With normal usage, Android devices will also accumulate user
+data within third-party applications installed by users. Applications that
+choose to share this information can use Android OS permission checks to
+protect the data from third-party applications.</p>
+<p><img alt="Figure 3: Access to sensitive user data is only available through protected
+APIs" src="images/image03.png" /></p>
+<p><em>Figure 3: Access to sensitive user data is only available through protected
+APIs</em></p>
+<p>System content providers that are likely to contain personal or personally
+identifiable information such as contacts and calendar have been created with
+clearly identified permissions. This granularity provides the user with clear
+indication of the types of information that may be provided to the application.
+ During installation, a third-party application may request permission to
+access these resources. If permission is granted, the application can be
+installed and will have access to the data requested at any time when it is
+installed.</p>
+<p>Any applications which collect personal information will, by default, have that
+data restricted only to the specific application. If an application chooses to
+make the data available to other applications though IPC, the application
+granting access can apply permissions to the IPC mechanism that are enforced by
+the operating system.</p>
+<h2 id="sensitive-data-input-devices">Sensitive Data Input Devices</h2>
+<p>Android devices frequently provide sensitive data input devices that allow
+applications to interact with the surrounding environment, such as camera,
+microphone or GPS. For a third-party application to access these devices, it
+must first be explicitly provided access by the user through the use of Android
+OS Permissions. Upon installation, the installer will prompt the user
+requesting permission to the sensor by name.</p>
+<p>If an application wants to know the user's location, the application requires a
+permission to access the user's location. Upon installation, the installer will
+prompt the user asking if the application can access the user's location. At
+any time, if the user does not want any application to access their location,
+then the user can run the "Settings" application, go to "Location & Security",
+and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
+disable location based services for all applications on the user's device.</p>
+<h2 id="device-metadata">Device Metadata</h2>
+<p>Android also strives to restrict access to data that is not intrinsically
+sensitive, but may indirectly reveal characteristics about the user, user
+preferences, and the manner in which they use a device.</p>
+<p>By default applications do not have access to operating system logs,
+browser history, phone number, or hardware / network identification
+information. If an application requests access to this information at install
+time, the installer will prompt the user asking if the application can access
+the information. If the user does not grant access, the application will not be
+installed.</p>
+<h2 id="application-signing">Application Signing</h2>
+<p>Code signing allows developers to identify the author of the application and to
+update their application without creating complicated interfaces and
+permissions. Every application that is run on the Android platform must be
+signed by the developer. Applications that attempt to install without being
+signed will rejected by either Google Play or the package installer on
+the Android device.</p>
+<p>On Google Play, application signing bridges the trust Google has with the
+developer and the trust the developer has with their application. Developers
+know their application is provided, unmodified to the Android device; and
+developers can be held accountable for behavior of their application.</p>
+<p>On Android, application signing is the first step to placing an application in
+its Application Sandbox. The signed application certificate defines which user
+id is associated with which application; different applications run under
+different user IDs. Application signing ensures that one application cannot
+access any other application except through well-defined IPC.</p>
+<p>When an application (APK file) is installed onto an Android device, the Package
+Manager verifies that the APK has been properly signed with the certificate
+included in that APK. If the certificate (or, more accurately, the public key
+in the certificate) matches the key used to sign any other APK on the device,
+the new APK has the option to specify in the manifest that it will share a UID
+with the other similarly-signed APKs.</p>
+<p>Applications can be signed by a third-party (OEM, operator, alternative market)
+or self-signed. Android provides code signing using self-signed certificates
+that developers can generate without external assistance or permission.
+Applications do not have to be signed by a central authority. Android currently
+does not perform CA verification for application certificates.</p>
+<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
+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
+declare a shared UID in their manifest.</p>
+<h2 id="digital-rights-management">Digital Rights Management</h2>
+<p>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.</p>
+<p>The <a href="https://developer.android.com/reference/android/drm/package-summary.html">Android DRM
+framework</a>
+is implemented in two architectural layers (see figure below):</p>
+<ul>
+<li>
+<p>A DRM framework API, which is exposed to applications through the Android
+application framework and runs through the Dalvik VM for standard applications.</p>
+</li>
+<li>
+<p>A native code DRM manager, which implements the DRM framework and exposes an
+interface for DRM plug-ins (agents) to handle rights management and decryption
+for various DRM schemes</p>
+</li>
+</ul>
+<p><img alt="Figure 4: Architecture of Digital Rights Management on Android
+platform" src="images/image02.png" /></p>
+<p><em>Figure 4: Architecture of Digital Rights Management on Android platform</em></p>
+<h1 id="android-updates">Android Updates</h1>
+<p>Android provides system updates for both security and feature related purposes.</p>
+<p>There are two ways to update the code on most Android devices: over-the-air
+(OTA updates) or side-loaded updates. OTA updates can be rolled out over a
+defined time period or be pushed to all devices at once, depending on how the
+OEM and/or carrier would like to push the updates. Side-loaded updates can be
+provided from a central location for users to download as a zip file to their
+local desktop machine or directly to their handset. Once the update is copied
+or downloaded to the SD card on the device, Android will recognize the update,
+verify its integrity and authenticity, and automatically update the device.</p>
+<p>If a dangerous vulnerability is discovered internally or responsibly reported
+to Google or the Android Open Source Project, the Android security team will
+start the following process.</p>
+<ol>
+<li>The Android team will notify companies who have signed NDAs regarding the
+problem and begin discussing the solution.</li>
+<li>The owners of code will begin the fix.</li>
+<li>The Android team will fix Android-related security issues.</li>
+<li>When a patch is available, the fix is provided to the NDA companies.</li>
+<li>The Android team will publish the patch in the Android Open Source Project</li>
+<li>OEM/carrier will push an update to customers.</li>
+</ol>
+<p>The NDA is required to ensure that the security issue does not become public
+prior to availabilty of a fix and put users at risk. Many OHA members run their
+own code on Android devices such as the bootloader, wifi drivers, and the
+radio. Once the Android Security team is notified of a security issue in this
+partner code, they will consult with OHA partners to quickly find a fix for the
+problem at hand and similar problems. However, the OHA member who wrote the
+faulty code is ultimately responsible for fixing the problem.</p>
+<p>If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
+posted to a public forum without warning), then Google and/or the Android Open
+Source Project will work as quickly as possible to create a patch. The patch
+will released to the public (and any partners) when the patch is tested and
+ready for use.</p>
+<p>At Google I/O 2011, many of the largest OHA partners committed to providing
+updates to devices for 18 months after initial shipment. This will provide
+users with access to the most recent Android features, as well as security
+updates.</p>
+<p>Any developer, Android user, or security researcher can notify the Android
+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:
+<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
+<a href="https://source.android.com">https://source.android.com</a>.</p>
+<p>Information for Android application developers is here:
+<a href="https://developer.android.com">https://developer.android.com</a>.</p>
+<p>The Android Security team can be reached at
+<a href="mailto:security@android.com">security@android.com</a>.</p>
+<p>Security information exists throughout the Android Open Source and Developer
+Sites. A good place to start is here:
+<a href="https://developer.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
+<p>A Security FAQ for developers is located here:
+<a href="https://developer.android.com/resources/faq/security.html">https://developer.android.com/resources/faq/security.html</a>.</p>
+<p>Security Best Practices for developers is located here:
+<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>
diff --git a/src/devices/tech/storage/index.jd b/src/devices/tech/storage/index.jd
new file mode 100644
index 0000000..71ea31c
--- /dev/null
+++ b/src/devices/tech/storage/index.jd
@@ -0,0 +1,121 @@
+page.title=External Storage Technical Information
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Android supports devices with external storage, which is defined to be a
+case-insensitive and permissionless filesystem. External storage can be
+provided by physical media (such as an SD card), or by an emulation layer backed
+by internal storage. Devices may contain multiple instances of external
+storage, but currently only the primary external storage is exposed to
+developers through API.</p>
+<h2 id="device-specific-configuration">Device specific configuration</h2>
+<p>External storage is managed by a combination of the <code>vold</code> init service and
+<code>MountService</code> system service.</p>
+<p>Mounting of physical external storage volumes is handled by <code>vold</code>, which
+performs staging operations to prepare the media before exposing it to apps.
+The device-specific <code>vold.fstab</code> configuration file defines mappings from sysfs
+devices to filesystem mount points, and each line follows this format:</p>
+<pre><code>dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]
+</code></pre>
+<ul>
+<li><code>label</code>: Label for the volume.</li>
+<li><code>mount_point</code>: Filesystem path where the volume should be mounted.</li>
+<li><code>partition</code>: Partition number (1 based), or 'auto' for first usable partition.</li>
+<li><code>sysfs_path</code>: One or more sysfs paths to devices that can provide this mount
+point. Separated by spaces, and each must start with <code>/</code>.</li>
+<li><code>flags</code>: Optional comma separated list of flags, must not contain <code>/</code>.
+Possible values include <code>nonremovable</code> and <code>encryptable</code>.</li>
+</ul>
+<p>External storage interactions at and above the framework level are handled
+through <code>MountService</code>. The device-specific <code>storage_list.xml</code> configuration
+file, typically provided through a <code>frameworks/base</code> overlay, defines the
+attributes and constraints of storage devices. The <code><StorageList></code> element
+contains one or more <code><storage></code> elements, exactly one of which should be marked
+primary. <code><storage></code> attributes include:</p>
+<ul>
+<li><code>mountPoint</code>: filesystem path of this mount.</li>
+<li><code>storageDescription</code>: string resource that describes this mount.</li>
+<li><code>primary</code>: true if this mount is the primary external storage.</li>
+<li><code>removable</code>: true if this mount has removable media, such as a physical SD
+card.</li>
+<li><code>emulated</code>: true if this mount is emulated and is backed by internal storage,
+possibly using a FUSE daemon.</li>
+<li><code>mtp-reserve</code>: number of MB of storage that MTP should reserve for free
+storage. Only used when mount is marked as emulated.</li>
+<li><code>allowMassStorage</code>: true if this mount can be shared via USB mass storage.</li>
+<li><code>maxFileSize</code>: maximum file size in MB.</li>
+</ul>
+<p>Devices may provide external storage by emulating a case-insensitive,
+permissionless filesystem backed by internal storage. One possible
+implementation is provided by the FUSE daemon in <code>system/core/sdcard</code>, which can
+be added as a device-specific <code>init.rc</code> service:</p>
+<pre><code># virtual sdcard daemon running as media_rw (1023)
+service sdcard /system/bin/sdcard <source_path> <dest_path> 1023 1023
+ class late_start
+</code></pre>
+<p>Where <code>source_path</code> is the backing internal storage and <code>dest_path</code> is the
+target mount point.</p>
+<p>When configuring a device-specific <code>init.rc</code> script, the <code>EXTERNAL_STORAGE</code>
+environment variable must be defined as the path to the primary external
+storage. The <code>/sdcard</code> path must also resolve to the same location, possibly
+through a symlink. If a device adjusts the location of external storage between
+platform updates, symlinks should be created so that old paths continue working.</p>
+<p>As an example, here’s the storage configuration for Xoom, which uses a FUSE
+daemon to provide primary external storage, and includes a physical SD card as
+secondary external storage:</p>
+<ul>
+<li><a href="https://android.googlesource.com/device/moto/wingray/+/master/vold.fstab">vold.fstab</a></li>
+<li><a href="https://android.googlesource.com/device/moto/wingray/+/master/overlay/frameworks/base/core/res/res/xml/storage_list.xml">storage_list.xml</a></li>
+</ul>
+<p>Access to external storage is protected by various Android permissions.
+Starting in Android 1.0, write access is protected with the
+<code>WRITE_EXTERNAL_STORAGE</code> permission, implemented using the <code>sdcard_rw</code> GID.
+Starting in Android 4.1, read access is protected with the new
+<code>READ_EXTERNAL_STORAGE</code> permission, implemented using the <code>sdcard_r</code> GID. To
+implement the read permission, a new top-level <code>/storage</code> directory was created
+such that processes must hold the <code>sdcard_r</code> GID to traverse into it.</p>
+<p>Since external storage offers no support for traditional POSIX filesystem
+permissions, system code should not store sensitive data on external storage.
+Specifically, configuration and log files should only be stored on internal
+storage where they can be effectively protected.</p>
+<h2 id="multi-user-external-storage">Multi-user external storage</h2>
+<p>Starting in Android 4.2, devices can support multiple users, and external
+storage must meet the following constraints:</p>
+<ul>
+<li>Each user must have their own isolated primary external storage, and must not
+have access to the primary external storage of other users.</li>
+<li>The <code>/sdcard</code> path must resolve to the correct user-specific primary external
+storage based on the user a process is running as.</li>
+<li>Storage for large OBB files in the <code>Android/obb</code> directory may be shared
+between multiple users as an optimization.</li>
+<li>Secondary external storage must not be writable by apps.</li>
+</ul>
+<p>The default platform implementation of this feature leverages Linux kernel
+namespaces to create isolated mount tables for each Zygote-forked process, and
+then uses bind mounts to offer the correct user-specific primary external
+storage into that private namespace.</p>
+<p>At boot, the system mounts a single emulated external storage FUSE daemon at
+<code>EMULATED_STORAGE_SOURCE</code>, which is hidden from apps. After the Zygote forks,
+it bind mounts the appropriate user-specific subdirectory from under the FUSE
+daemon to <code>EMULATED_STORAGE_TARGET</code> so that external storage paths resolve
+correctly for the app. Because an app lacks accessible mount points for other
+users’ storage, they can only access storage for the user it was started as.</p>
+<p>This implementation also uses the shared subtree kernel feature to propagate
+mount events from the default root namespace into app namespaces, which ensures
+that features like ASEC containers and OBB mounting continue working correctly.
+It does this by mounting the rootfs as shared, and then remounting it as slave
+after each Zygote namespace is created.</p>
diff --git a/src/devices/tech/test_infra/tradefed/commandfile_format.jd b/src/devices/tech/test_infra/tradefed/commandfile_format.jd
new file mode 100644
index 0000000..cd5102a
--- /dev/null
+++ b/src/devices/tech/test_infra/tradefed/commandfile_format.jd
@@ -0,0 +1,121 @@
+page.title=Command File Format
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>A command file allows one to specify sets of TF commands (that is, configurations with their
+associated arguments) to be specified all at once. Further, the format used in the command file
+supports simple macro expansions, which makes it very useful without being unwieldy. You can see a
+relatively involved example at the bottom of the page, as well as more gradual documentation
+immediately below.</p>
+<h2 id="lines">Lines</h2>
+<p>The format is line-based.</p>
+<ul>
+<li>Each output line will be considered as the arguments for a single Configuration for Trade
+ Federation to run.</li>
+<li>Each input line will turn into one or more output lines.</li>
+</ul>
+<p>In essence, the command file format combinatorially creates a sequence of Configuration specifications that it passes to Trade Federation to run. Blank lines are ignored. Comments are delimited by the "#" character and may only be preceded by whitespace.</p>
+<h2 id="macros">Macros</h2>
+<p>The specific syntax for defining a macro is discussed below in the Short Macro and Long Macro sections. The following rules apply to all macros</p>
+<ul>
+<li>The name of a macro must begin with an alpha character. Each subsequent character may be any
+ alphanumeric, an underscore, or a hyphen.</li>
+<li>A macro with name "macro_name" is invoked by adding macro_name() as an argument on some subsequent
+ line.</li>
+<li>The macro format does not support passing arguments to macros. It allows only concatenation.</li>
+<li>A macro's expansion may contain invocations of other macros. Technically, a macro's expansion may
+ contain invocations of itself, but in that case, the macro will never fully expand.</li>
+<li>The parser currently has a hard limit of 10 iterations of expansion. This will be made
+ configurable at some point.</li>
+<li>During a single iteration of expansion:<ul>
+<li>All short macro invocations on a line will be expanded a single level — macro invocations
+ embedded within the first-level expansions will not be expanded yet</li>
+<li>Only one long macro invocation on a line will be expanded. This will be the left-most long
+ macro invocation.</li>
+</ul>
+</li>
+</ul>
+<h2 id="short-macros">Short Macros</h2>
+<p>A short macro can be defined with the syntax:</p>
+<pre><code>MACRO macro_name = this is the macro expansion
+</code></pre>
+<p>The macro expansion terminates at the end of the line. For multi-line expansion, see Long Macros
+below.</p>
+<h3 id="short-macro-expansion">Short Macro Expansion</h3>
+<ul>
+<li><code>a macro_name() invocation</code><br />
+ will be replaced by<br />
+ <code>a this is the macro expansion invocation</code></li>
+<li><code>three macro_name() A macro_name() B macro_name()</code><br />
+ will be replaced by (all during the first iteration)<br />
+ <code>three this is the macro expansion A this is the macro expansion B this is the macro expansion</code></li>
+</ul>
+<h2 id="long-macros">Long Macros</h2>
+<p>A long macro can be defined with the syntax:</p>
+<pre><code>LONG MACRO macro_name
+ expansion line 1
+ expansion line 2
+ expansion line 3
+END MACRO
+</code></pre>
+<p>The macro is then invoked with th enormal <code>macro_name()</code> syntax. Leading whitespace/indentation
+will be ignored.</p>
+<h3 id="long-macro-expansion">Long Macro Expansion</h3>
+<p>The output of a single input line will include one line for each combination of macro expansions on
+that line. That is, the number of output lines is multiplicatively related to the number of macro
+expansions on that line:</p>
+<ul>
+<li>Only a single long macro invocation per line will be expanded during a single iteration. This
+ means that a line may only contain 10 long macro invocations to stay under the iteration count
+ limit.</li>
+<li>
+<p>A single invocation of a long macro on a single line will cause that line to expand to the number
+ of lines of the long macro's expansion. On each expanded line, the invocation will be replaced
+ by the corresponding line of the macro's expansion.</p>
+</li>
+<li>
+<p>Example 1:</p>
+<pre><code>a macro_name() invocation
+</code></pre>
+<p>will be replaced by (in a single iteration)</p>
+<pre><code>a expansion line 1 invocation
+a expansion line 2 invocation
+a expansion line 3 invocation
+</code></pre>
+</li>
+<li>
+<p>Example 2:</p>
+<pre><code>alpha macro_name() beta macro_name()
+</code></pre>
+<p>will be replaced by (during the first iteration)</p>
+<pre><code>alpha expansion line 1 beta macro_name()
+alpha expansion line 2 beta macro_name()
+alpha expansion line 3 beta macro_name()
+</code></pre>
+<p>which will be replaced by (during the second iteration)</p>
+<pre><code>alpha expansion line 1 beta expansion line 1
+alpha expansion line 1 beta expansion line 2
+alpha expansion line 1 beta expansion line 3
+alpha expansion line 2 beta expansion line 1
+alpha expansion line 2 beta expansion line 2
+alpha expansion line 2 beta expansion line 3
+alpha expansion line 3 beta expansion line 1
+alpha expansion line 3 beta expansion line 2
+alpha expansion line 3 beta expansion line 3
+</code></pre>
+</li>
+</ul>
diff --git a/src/devices/tech/test_infra/tradefed/getting_started.jd b/src/devices/tech/test_infra/tradefed/getting_started.jd
new file mode 100644
index 0000000..8219ee7
--- /dev/null
+++ b/src/devices/tech/test_infra/tradefed/getting_started.jd
@@ -0,0 +1,203 @@
+page.title=Getting Started
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<h2 id="using-the-console">Using the console</h2>
+<p>TF is based around an interactive console. You can fire up the console by going to the
+<code>tools/tradefederation/</code> directory and running</p>
+<pre><code>$ ./tradefed.sh
+</code></pre>
+<p>You should end up at a <code>tf ></code> prompt.</p>
+<p>The console is self-documenting. Try entering "help"</p>
+<pre><code>tf >help
+Enter 'q' or 'exit' to exit
+Enter 'kill' to attempt to forcibly exit, by shutting down adb
+
+Enter 'help list' for help with 'list' commands
+[...]
+</code></pre>
+<p>As the help text suggests, the help menus are organized hierarchically</p>
+<pre><code>tf >help list
+l(?:ist)? help:
+ i[nvocations] List all invocation threads
+ d[evices] List all detected or known devices
+[...]
+</code></pre>
+<p>The majority of commands have a convenient short form, which the help text displays. The
+<code>l(?:ist)?</code> is a regular expression. As an example, here are the four equivalent ways to list
+invocations:
+<em> <code>list invocations</code>
+</em> <code>list i</code>
+<em> <code>l invocations</code>
+</em> <code>l i</code></p>
+<h2 id="running-a-configcommand">Running a config/command</h2>
+<p>This is documented by the <code>help run</code> command in the console.</p>
+<p>As a reminder, a command is a config along with all of its command-line arguments. A command <em>must</em>
+begin with the name of the respective config.</p>
+<p>As a quick example, you could run the calculator unit tests like so:</p>
+<pre><code>$./tradefed.sh
+tf >run instrument --package com.android.calculator2.tests
+</code></pre>
+<p>As a shortcut, if you specify any arguments to <code>tradefed.sh</code>, it will attempt to execute them as if
+they were typed on the commandline. So the short version of the above would be</p>
+<pre><code>$./tradefed.sh run instrument --package com.android.calculator2.tests
+</code></pre>
+<p>In both of these cases, the name of the config is "instrument", and
+"--class com.android.calculator2.tests" is a command-line argument. The command that is being run
+is "instrument --class com.android.calculator2.tests".</p>
+<p>TF can run both configs that are compiled in (such as the "instrument" config above), as well as
+configs that exist as xml files on the local filesystem. You can see a list of compiled-in configs
+with the <code>list configs</code> console command. Furthermore, you can investigate any config (compiled-in
+or local) by passing the "--help" or "--help-all" command-line arguments. The "--help" argument
+will only show "important" arguments, and "--help-all" will show all arguments, regardless of
+whether they've been marked as "important" or not. To take the final step, you can tell TF to print
+the contents of any config (compiled-in or local) with the <code>dump config <configname></code> console
+command.</p>
+<h3 id="so-lets-say-you-want-to-run-the-calculator-instrumentation-tests-but-dont-know-where-to-start">So, let's say you want to run the calculator instrumentation tests, but don't know where to start.</h3>
+<p>You could try something like this sequence of steps. First, look for a config that looks like it
+might do what you want:</p>
+<pre><code>tf >list configs
+Use 'run command --help <configuration_name>' to get list of options for a configuration
+Use 'dump config <configuration_name>' to display the configuration's XML content.
+
+Available configurations include:
+[...]
+ instrument: Runs a single Android instrumentation test on an existing device
+[...]
+</code></pre>
+<p>Now that you've found something reasonable-looking, see what options it takes. The <code>list configs</code> output suggests trying <code>run command instrument --help</code></p>
+<pre><code>tf >run command --help instrument
+'instrument' configuration: Runs a single Android instrumentation test on an existing device
+
+Printing help for only the important options. To see help for all options, use the --help-all flag
+[...]
+ 'instrumentation' test options:
+ -p, --package The manifest package name of the Android test application to run.
+</code></pre>
+<p>As the message suggests, if you need more options, use the "--help-all" flag instead of "--help". In this case, we've got all we need. You could figure out the package by checking with <code>runtest</code>, or reading testdefs.xml directly. We use <code>runtest -n</code> to simply show what would be run without actually running it:</p>
+<pre><code>$runtest -n calculator
+adb root
+ONE_SHOT_MAKEFILE="packages/apps/Calculator/Android.mk" make -j4 -C "/srv/xsdg/master2" files
+adb sync
+adb shell am instrument -w com.android.calculator2.tests/android.test.InstrumentationTestRunner
+</code></pre>
+<p>The argument to <code>am instrument</code> that comes before the slash is the manifest package. <code>android.test.InstrumentationTestRunner</code> is the default runner, so no need to set it if that's the
+right one. Otherwise, using "--help-all" will tell you about the "--runner" argument, which you can
+use to specify an alternate runner. Ok, so at this point, we've got the following command, which
+you'll recognize from above</p>
+<pre><code>tf >run instrument --package com.android.calculator2.tests
+</code></pre>
+<h2 id="interacting-with-a-device">Interacting with a device</h2>
+<h3 id="generic-device-behavior-in-tf">Generic device behavior in TF</h3>
+<p>The running version of a command is called in <code>invocation</code>. First and foremost, every invocation
+requires a device before it can run. In addition to physical Android devices, TF can run tests with
+a mock device (by specifying the "-n" argument for the command), or with the Android emulator (by
+specifying the "-e" argument").</p>
+<p>The primary console command to figure out what devices are up to is <code>list devices</code>:</p>
+<pre><code>$./tradefed.sh
+06-07 17:03:22 I/: Detected new device 016B756E03018007
+06-07 17:03:22 I/: Detected new device 1700614743c14397
+06-07 17:03:22 I/: Detected new device 3531C342606300EC
+tf >l d
+Serial State Product Variant Build Battery
+016B756E03018007 Available tuna toro MASTER 100
+1700614743c14397 Available stingray stingray MASTER 100
+3531C342606300EC Available herring crespo4g MASTER 92
+</code></pre>
+<p>As far as the invocations are concerned, there are three device states: available, unavailable, and
+allocated. An <code>Available</code> device is ready to be allocated for an invocation. An <code>Unavailable</code>
+device is not ready for allocation, for any of a variety of reasons — TF may have deemed to the
+device as unstable, the device may be critically low on storage, or something else may be amiss.
+Finally, an <code>Allocated</code> device is a device that is already being used by an invocation.</p>
+<p>When you start TF, all detected physical devices will be checked for responsiveness with a simple
+shell command. If the command completes successfully, the device will be listed as Available. If
+the command fails, the device state will be shown as Unavailable. Thereafter, a device will typically bounce between the Available and Allocated states as invocation requirements dictate.</p>
+<p>Finally, once invocations are already underway, you can see what's going on with the <code>list
+invocations</code> command</p>
+<pre><code>tf >run instrument --package com.android.calculator2.tests
+06-07 17:18:31 I/TestInvocation: Starting invocation for 'stub' on build '0' on device 1700614743c14397
+[...]
+tf >l d
+Serial State Product Variant Build Battery
+1700614743c14397 Allocated stingray stingray MASTER 100
+3531C342606300EC Available herring crespo4g JRN11 93
+016B756E03018007 Available tuna toro MASTER 100
+
+tf >l i
+Command Id Exec Time Device State
+1 0m:02 1700614743c14397 running stub on build 0
+</code></pre>
+<h3 id="running-invocations-on-specific-devices">Running invocations on specific devices</h3>
+<p>TF supports a number of filtering mechanisms for specifying which device or devices to use for a
+particular invocation. Since the filtering mechanisms are run before a command turns into an
+invocation, you can find all of the filtering options in the help for any config:</p>
+<p>tf >run instrument --help-all
+[...]
+ device_requirements options:
+ -s, --serial run this test on a specific device with given serial number(s).
+ --exclude-serial run this test on any device except those with this serial number(s).
+ --product-type run this test on device with this product type(s). May also filter by variant using product:variant.
+ --property run this test on device with this property value. Expected format <propertyname>=<propertyvalue>.
+ -e, --[no-]emulator force this test to run on emulator. Default: false.
+ -d, --[no-]device force this test to run on a physical device, not an emulator. Default: false.
+ --[no-]new-emulator allocate a placeholder emulator. Should be used when config intends to launch an emulator Default: false.
+ -n, --[no-]null-device
+ do not allocate a device for this test. Default: false.
+ --min-battery only run this test on a device whose battery level is at least the given amount. Scale: 0-100
+ --max-battery only run this test on a device whose battery level is strictly less than the given amount. Scale: 0-100
+[...]</p>
+<p>The built-in help should be pretty self-explanatory. All of the filtering options excluding "-n",
+"-e", and "-d" may be specified as many times as needed. So, for instance, to run an invocation
+using any Verizon Galaxy Nexus, you could do the following:</p>
+<pre><code>tf >run instrument --package com.android.calculator2.tests --product-type tuna:toro
+</code></pre>
+<p>As another example, to run on a GSM device with a SIM, you could do the following:</p>
+<pre><code>tf >run instrument --package com.android.calculator2.tests --property gsm.sim.state=READY
+</code></pre>
+<p>The filtering works by exclusion from the pool of Available devices, so the "--serial" option simply
+excludes devices that aren't in the list of required serials, and --exclude-serial excludes devices
+that <em>are</em> in its list. As such, an argument like --exclude-serial XXX --serial XXX will simply
+make the respective command un-runnable — it will never match any device, since all devices are
+excluded.</p>
+<h2 id="logging">Logging</h2>
+<p>There are a few different aspects to logging in TF. First and foremost, TF has a built-in logging
+infrastructure that's based on DDMLib's Log class. For the common case, where the log tag is just
+the classname of the current class, you can use our CLog convenience shim. In short, if you might
+have originally done this:</p>
+<pre><code>class ClassName {
+private static final LOG_TAG = "ClassName";
+[...]
+Log.v(LOG_TAG, "This is a simple verbose log message");
+Log.w(LOG_TAG, String.format("This warning message brought to you by the number %d", 17));
+</code></pre>
+<p>You can now accomplish the same thing with the shim like this:</p>
+<pre><code>class ClassName {
+[...]
+CLog.v("This is a simple verbose log message");
+CLog.w("This warning message brought to you by the number %d", 17);
+</code></pre>
+<p>Each Invocation has its own ThreadGroup. Any host-side logging that happens inside of that thread
+group is associated with the Invocation, and will be reported as that invocation's "host_log" after
+the Invocation completes.</p>
+<p>Device logging is performed as part of TradeFed's device wrapper. We keep a buffer of up to 20 MB
+that captures log data as the device churns it out. In particular, we are not limited by the size
+of the on-device logcat buffer.</p>
+<p>The next important piece is the ITestInvocationListener. This is one of the components of an
+Invocation that handles results reporting. Each reporter has the option to implement the #testLog
+method, which will be used to pass logfiles to that result reporter. Among the files that are
+passed by TF itself will be the aforementioned host_log, as well as the device logcat for the device
+associated with the Invocation.</p>
diff --git a/src/devices/tech/test_infra/tradefed/index.jd b/src/devices/tech/test_infra/tradefed/index.jd
new file mode 100644
index 0000000..9331369
--- /dev/null
+++ b/src/devices/tech/test_infra/tradefed/index.jd
@@ -0,0 +1,52 @@
+page.title=Trade Federation Overview
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>TradeFederation (tradefed or TF for short) is a continuous test framework designed for running tests
+on Android devices. Its a Java application which runs on a host computer, and communicates to one or
+more Android devices using ddmlib (the library behind DDMS) over adb.</p>
+<h2 id="features">Features</h2>
+<ul>
+<li>modular, flexible design</li>
+<li>has built in support for running many different types of Android tests: instrumentation, native/gtest, host-based JUnit, etc</li>
+<li>provides reliability and recovery mechanism on top of adb</li>
+<li>supports scheduling and running tests on multiple devices in parallel</li>
+</ul>
+<h2 id="fundamentals">Fundamentals</h2>
+<p>The lifecycle of a test executed using TradeFederation is composed of four separate stages, designed
+around formally defined interfaces.</p>
+<ul>
+<li><a href="bp.html">Build provider</a>: Provides a build to test, downloading appropriate files if necessary</li>
+<li><a href="tp.html">Target preparer</a>: Prepares the test environment, e.g. software installation and setup</li>
+<li><a href="test.html">Test</a>: Executes test(s) and gathers test results</li>
+<li><a href="result.html">Result reporter</a>: Listens for test results, usually for the purpose of forwarding
+ test results to a repository</li>
+</ul>
+<p>The fundamental entity in TradeFederation is a Configuration. A Configuration is an XML file that
+declares the lifecycle components of a test.</p>
+<p>This separation of the test's lifecycle is intended to allow for reuse. Using this design, you can
+create a Test, and then different Configurations to run it in different environments. For example,
+you could create a Configuration that will run a test on your local machine, and dump the result to
+stdout. You could then create a second Configuration that would execute that same test, but use a
+different Result reporter to store the test results in a database.</p>
+<h3 id="additional-components-of-a-configuration">Additional components of a configuration</h3>
+<ul>
+<li><a href="recovery.html">Device recovery</a>: mechanism to recover device communication if lost</li>
+<li><a href="logger.html">Logger</a>: collects tradefed logging data</li>
+</ul>
+<p>A complete TradeFederation test execution, across its entire lifecycle, is referred to as an
+Invocation.</p>
\ No newline at end of file
diff --git a/src/devices/tech/test_infra/tradefed/tutorial.jd b/src/devices/tech/test_infra/tradefed/tutorial.jd
new file mode 100644
index 0000000..eb42aa0
--- /dev/null
+++ b/src/devices/tech/test_infra/tradefed/tutorial.jd
@@ -0,0 +1,334 @@
+page.title=Tutorial
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>This tutorial guides you through the construction of a "hello world" Trade Federation test
+configuration, and gives you a hands-on introduction to the Trade Federation framework. Starting
+from the Tf development environment, it guides you through the process of creating a simple Trade
+Federation config and gradually adding more features to it.</p>
+<p>The tutorial presents the TF test development process as a set of exercises, each consisting of
+several steps. The exercises demonstrate how to gradually build and refine your configuration, and
+provide all the sample code you need to complete the test configuration.</p>
+<p>When you are finished with the tutorial, you will have created a functioning TF configuration and
+will have learned many of the most important concepts in the TF framework.</p>
+<h2 id="set-up-tradefederation-development-environment">Set up TradeFederation development environment</h2>
+<p>See (FIXME: link) for how to setup the development environment. The rest of this tutorial assumes you have a shell open that has been initialized to the TradeFederation environment. </p>
+<p>For simplicity, this tutorial will illustrate adding a configuration and its classes to the TradeFederation framework core library. Later tutorials/documentation will show how to create your own library that extends TradeFederation.</p>
+<h2 id="creating-a-test-class">Creating a test class</h2>
+<p>Lets create a hello world test that just dumps a message to stdout. A TradeFederation test must
+implement the (FIXME: link) IRemoteTest interface.</p>
+<p>Here's an implementation for the HelloWorldTest:</p>
+<pre><code>package com.android.tradefed.example;
+
+import com.android.tradefed.device.DeviceNotAvailableException;
+import com.android.tradefed.result.ITestInvocationListener;
+import com.android.tradefed.testtype.IRemoteTest;
+
+public class HelloWorldTest implements IRemoteTest {
+ @Override
+ public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
+ System.out.println("Hello, TF World!");
+ }
+}
+</code></pre>
+<p>FIXME: prod-tests
+Save this sample code to
+<code><git home>/tools/tradefederation/prod-tests/src/com/android/tradefed/example/HelloWorldTest.java</code>
+and rebuild tradefed from your shell:</p>
+<pre><code>m -j6
+</code></pre>
+<p>If the build does not succeed, please consult the (FIXME: link)Development Environment page to
+ensure you did not miss any steps.</p>
+<h2 id="creating-a-configuration">Creating a configuration</h2>
+<p>Trade Federation tests are defined in a "Configuration". A Configuration is an XML file that
+instructs tradefed which test (or set of tests) to run.</p>
+<p>Lets create a new Configuration for our HelloWorldTest.</p>
+<pre><code><configuration description="Runs the hello world test">
+ <test class="com.android.tradefed.example.HelloWorldTest" />
+</configuration>
+</code></pre>
+<p>TF will parse the Configuration XML file, load the specified class using reflection, instantiate it,
+cast it to a IRemoteTest, and call its 'run' method.</p>
+<p>Note that we've specified the full class name of the HelloWorldTest. Save this data to a
+<code>helloworld.xml</code> file anywhere on your local filesystem (eg <code>/tmp/helloworld.xml</code>).</p>
+<h2 id="running-the-configuration">Running the configuration</h2>
+<p>From your shell, launch the tradefed console</p>
+<pre><code>$ ./tradefed.sh
+</code></pre>
+<p>Ensure a device is connected to the host machine that is visible to tradefed</p>
+<pre><code>tf> list devices
+</code></pre>
+<p>Configurations can be run using the <code>run <config></code> console command. Try this now</p>
+<p>FIXME: redo this</p>
+<pre><code>tf> run /tmp/helloworld.xml
+05-12 13:19:36 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
+Hello, TF World!
+</code></pre>
+<p>You should see "Hello, TF World!" outputted on the terminal.</p>
+<h2 id="adding-the-configuration-to-the-classpath">Adding the configuration to the classpath</h2>
+<p>FIXME: prod-tests
+For convenience of deployment, you can also bundle configuration files into the TradeFederation jars
+themselves. Tradefed will automatically recognize all configurations placed in 'config' folders on
+the classpath.</p>
+<p>Lets illustrate this now by moving the helloworld.xml into the tradefed core library.</p>
+<p>Move the <code>helloworld.xml</code> file into
+<code><git root>/tools/tradefederation/prod-tests/res/config/example/helloworld.xml</code>.</p>
+<p>Rebuild tradefed, and restart the tradefed console. </p>
+<p>Ask tradefed to display the list of configurations on the classpath:</p>
+<pre><code>tf> list configs
+[…]
+example/helloworld: Runs the hello world test
+</code></pre>
+<p>You can now run the helloworld config via the following command</p>
+<pre><code>tf >run example/helloworld
+05-12 13:21:21 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
+Hello, TF World!
+</code></pre>
+<h2 id="interacting-with-a-device">Interacting with a device</h2>
+<p>So far our hello world test isn't doing anything interesting. Tradefed is intended to run tests using Android devices, so lets add an Android device to the test.</p>
+<p>Tests can get a reference to an Android device by implementing the IDeviceTest interface. </p>
+<p>Here's a sample implementation of what this looks like:</p>
+<pre><code>public class HelloWorldTest implements IRemoteTest, IDeviceTest {
+ private ITestDevice mDevice;
+ @Override
+ public void setDevice(ITestDevice device) {
+ mDevice = device;
+ }
+
+ @Override
+ public ITestDevice getDevice() {
+ return mDevice;
+ }
+…
+}
+</code></pre>
+<p>The TradeFederation framework will inject the ITestDevice reference into your test via the
+IDeviceTest#setDevice method, before the IRemoteTest#run method is called.</p>
+<p>Lets add an additional print message to the HelloWorldTest displaying the serial number of the
+device.</p>
+<pre><code>@Override
+public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
+ System.out.println("Hello, TF World! I have a device " + getDevice().getSerialNumber());
+}
+</code></pre>
+<p>Now rebuild tradefed, and do (FIXME: update)</p>
+<pre><code>$ tradefed.sh
+tf> list devices
+Available devices: [30315E38655500EC]
+…
+</code></pre>
+<p>Take note of the serial number listed in Available devices above. That is the device that should be allocated to HelloWorld.</p>
+<pre><code>tf >run example/helloworld
+05-12 13:26:18 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
+Hello world, TF! I have a device 30315E38655500EC
+</code></pre>
+<p>You should see the new print message displaying the serial number of the device.</p>
+<h2 id="sending-test-results">Sending test results</h2>
+<p>IRemoteTests report results by calling methods on the ITestInvocationListener instance provided to
+their <code>#run</code> method.</p>
+<p>The TradeFederation framework is responsible for reporting the start and end of an Invocation (via
+the ITestInvocationListener#invocationStarted and ITestInvocationListener#invocationEnded methods
+respectively).</p>
+<p>A <code>test run</code> is a logical collection of tests. To report test results, IRemoteTests are responsible
+for reporting the start of a test run, the start and end of each test, and the end of the test run.</p>
+<p>Here's what the HelloWorldTest implementation looks like with a single failed test result.</p>
+<pre><code>@SuppressWarnings("unchecked")
+@Override
+public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
+ System.out.println("Hello, TF World! I have a device " + getDevice().getSerialNumber());
+
+ TestIdentifier testId = new TestIdentifier("com.example.MyTestClassName", "sampleTest");
+ listener.testRunStarted("helloworldrun", 1);
+ listener.testStarted(testId);
+ listener.testFailed(TestFailure.FAILURE, testId, "oh noes, test failed");
+ listener.testEnded(testId, Collections.EMPTY_MAP);
+ listener.testRunEnded(0, Collections.EMPTY_MAP);
+}
+</code></pre>
+<p>Note that TradeFederation also includes several IRemoteTest implementations that you can reuse
+instead of writing your own from scratch. (such as InstrumentationTest, which can run an Android
+application's tests remotely on an Android device, parse the results, and forward them to the
+ITestInvocationListener). See the Test Types documentation for more details.</p>
+<h2 id="storing-test-results">Storing test results</h2>
+<p>By default, a TradeFederation configuration will use the TextResultReporter as the test listener
+implementation for the configuration. TextResultReporter will dump the results of an invocation to
+stdout. To illustrate, try running the hello-world config from previous section now:</p>
+<pre><code>$ ./tradefed.sh
+tf >run example/helloworld
+05-16 20:03:15 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
+Hello world, TF! I have a device 30315E38655500EC
+05-16 20:03:15 I/InvocationToJUnitResultForwarder: run helloworldrun started: 1 tests
+Test FAILURE: com.example.MyTestClassName#sampleTest
+ stack: oh noes, test failed
+05-16 20:03:15 I/InvocationToJUnitResultForwarder: run ended 0 ms
+</code></pre>
+<p>If you want to store the results of an invocation elsewhere, say to a file, you would need to
+specify a custom "result_reporter" in your configuration, that specifies the custom
+ITestInvocationListener class you want to use.</p>
+<p>The TradeFederation framework includes a result_reporter (XmlResultReporter) that will write test
+results to an XML file, in a format similar to the ant JUnit XML writer. </p>
+<p>Lets specify the result_reporter in the configuration now. Edit the
+<code>tools/tradefederation/res/config/example/helloworld.xml</code> like this:</p>
+<pre><code><configuration description="Runs the hello world test">
+ <test class="com.android.tradefed.example.HelloWorldTest" />
+ <result_reporter class="com.android.tradefed.result.XmlResultReporter" />
+</configuration>
+</code></pre>
+<p>Now rebuild tradefed and re-run the hello world sample:
+FIXME: paths</p>
+<pre><code>tf >run example/helloworld
+05-16 21:07:07 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
+Hello world, TF! I have a device 30315E38655500EC
+05-16 21:07:07 I/XmlResultReporter: Saved device_logcat log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/device_logcat_6999997036887173857.txt
+05-16 21:07:07 I/XmlResultReporter: Saved host_log log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/host_log_6307746032218561704.txt
+05-16 21:07:07 I/XmlResultReporter: XML test result file generated at /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/test_result_536358148261684076.xml. Total tests 1, Failed 1, Error 0
+</code></pre>
+<p>Notice the log message stating an XML file has been generated. The generated file should look like this:</p>
+<pre><code><?xml version='1.0' encoding='UTF-8' ?>
+<testsuite name="stub" tests="1" failures="1" errors="0" time="9" timestamp="2011-05-17T04:07:07" hostname="localhost">
+ <properties />
+ <testcase name="sampleTest" classname="com.example.MyTestClassName" time="0">
+ <failure>oh noes, test failed
+ </failure>
+ </testcase>
+</testsuite>
+</code></pre>
+<p>Note that you can write your own custom result_reporter. It just needs to implement the
+ITestInvocationListener interface. </p>
+<p>Also note that Tradefed supports multiple result_reporters, meaning that you can send test results
+to multiple independent destinations. Just specify multiple <result_reporter> tags in your config to
+do this.</p>
+<h2 id="logging">Logging</h2>
+<p>TradeFederation includes two logging facilities:</p>
+<ol>
+<li>ability to capture logs from the device (aka device logcat)</li>
+<li>ability to record logs from the TradeFederation framework running on the host machine (aka the
+ host log)</li>
+</ol>
+<p>Lets focus on 2 for now. Trade Federation's host logs are reported using the CLog wrapper for the
+ddmlib Log class. </p>
+<p>Lets convert the previous System.out.println call in HelloWorldTest to a CLog call:</p>
+<pre><code>@Override
+public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
+ CLog.i("Hello world, TF! I have a device " + getDevice().getSerialNumber());
+</code></pre>
+<p>Now rebuild and rerun. You should see the log message on stdout. </p>
+<pre><code>tf> run example/helloworld
+…
+05-16 21:30:46 I/HelloWorldTest: Hello world, TF! I have a device 30315E38655500EC
+…
+</code></pre>
+<p>By default, TradeFederation will output host log messages to stdout. TradeFederation also includes a
+log implementation that will write messages to a file: FileLogger. To add file logging, add a
+'logger' tag to the configuration xml, specifying the full class name of FileLogger.</p>
+<pre><code><configuration description="Runs the hello world test">
+ <test class="com.android.tradefed.example.HelloWorldTest" />
+ <result_reporter class="com.android.tradefed.result.XmlResultReporter" />
+ <logger class="com.android.tradefed.log.FileLogger" />
+</configuration>
+</code></pre>
+<p>Now rebuild and run the helloworld example again.</p>
+<pre><code>tf >run example/helloworld
+…
+05-16 21:38:21 I/XmlResultReporter: Saved device_logcat log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_6390011618174565918/device_logcat_1302097394309452308.txt
+05-16 21:38:21 I/XmlResultReporter: Saved host_log log to /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt
+…
+</code></pre>
+<p>Note the log message indicating the path of the host log. View the contents of that file, and you
+should see your HelloWorldTest log message</p>
+<pre><code>$ more /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt
+…
+05-16 21:38:21 I/HelloWorldTest: Hello world, TF! I have a device 30315E38655500EC
+</code></pre>
+<p>The TradeFederation framework will also automatically capture the logcat from the allocated device,
+and send it the the result_reporter for processing. XmlResultReporter will save the captured device
+logcat as a file.</p>
+<h2 id="command-line-options">Command line options</h2>
+<p>Objects loaded from a TradeFederation Configuration (aka "Configuration objects") also have the
+ability to receive data from command line arguments.</p>
+<p>This is accomplished via the <code>@Option</code> annotation. To participate, a Configuration object class
+would apply the <code>@Option</code> annotation to a member field, and provide it a unique name. This would
+allow that member field's value to be populated via a command line option, and would also
+automatically add that option to the configuration help system (Note: not all field types are
+supported: see the OptionSetter javadoc for a description of supported types).</p>
+<p>Lets add an Option to the HelloWorldTest.</p>
+<pre><code>@Option(name="my_option",
+ shortName='m',
+ description="this is the option's help text",
+ // always display this option in the default help text
+ importance=Importance.ALWAYS)
+private String mMyOption = "thisisthedefault";
+</code></pre>
+<p>And lets add a log message to display the value of the option in HelloWorldTest, so we can
+demonstrate that it was received correctly.</p>
+<pre><code>@SuppressWarnings("unchecked")
+@Override
+public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
+ …
+ Log.logAndDisplay(LogLevel.INFO, "HelloWorldTest", "I received this option " + mMyOption);
+</code></pre>
+<p>Rebuild TF and run helloworld: you should see a log message with the my_option's default value.</p>
+<pre><code>tf> run example/helloworld
+…
+05-24 18:30:05 I/HelloWorldTest: I received this option thisisthedefault
+</code></pre>
+<p>Now pass in a value for my_option: you should see my_option getting populated with that value</p>
+<pre><code>tf> run example/helloworld --my_option foo
+…
+05-24 18:33:44 I/HelloWorldTest: I received this option foo
+</code></pre>
+<p>TF configurations also include a help system, which automatically displays help text for @Option
+fields. Try it now, and you should see the help text for 'my_option':</p>
+<pre><code>tf> run --help example/helloworld
+Printing help for only the important options. To see help for all options, use the --help-all flag
+
+ cmd_options options:
+ --[no-]help display the help text for the most important/critical options. Default: false.
+ --[no-]help-all display the full help text for all options. Default: false.
+ --[no-]loop keep running continuously. Default: false.
+
+ test options:
+ -m, --my_option this is the option's help text Default: thisisthedefault.
+
+ 'file' logger options:
+ --log-level-display the minimum log level to display on stdout. Must be one of verbose, debug, info, warn, error, assert. Default: error.
+</code></pre>
+<p>FIXME: redo with enum help</p>
+<p>Note the message at the top about 'printing only the important options'. To reduce option help
+clutter, TF uses the Option#importance attribute to determine whether to show an Option's help text
+when '--help' is specified. '--help-all' will always show all options' help regardless of
+importance. See Option.Importance javadoc for details.</p>
+<p>You can also specify an Option's value within the configuration xml by adding a
+<code><option name="" value=""></code> element. Lets see how this looks in the helloworld.xml:</p>
+<pre><code><test class="com.android.tradefed.example.HelloWorldTest" >
+ <option name="my_option" value="fromxml" />
+</test>
+</code></pre>
+<p>Re-building and running helloworld should now produce this output:</p>
+<pre><code>05-24 20:38:25 I/HelloWorldTest: I received this option fromxml
+</code></pre>
+<p>The configuration help should also be updated to indicate my_option's new default value:</p>
+<pre><code>tf> run --help example/helloworld
+ test options:
+ -m, --my_option this is the option's help text Default: fromxml.
+</code></pre>
+<p>Also note that other configuration objects included in the helloworld config, like FileLogger, also have options. '--log-level-display' is of interest because it filters the logs that show up on stdout. You may have noticed from earlier in the tutorial the 'Hello world, TF! I have a device ..' log message stopped getting displayed on stdout once we switched to using FileLogger. You can increase the verbosity of logging to stdout by passing in log-level-display arg.</p>
+<p>Try this now, and you should see the 'I have a device' log message reappear on stdout, in addition to getting logged to a file.</p>
+<pre><code>tf >run --log-level-display info example/helloworld
+…
+05-24 18:53:50 I/HelloWorldTest: Hello world, TF! I have a device XXXXXX
+</code></pre>
diff --git a/src/devices/tuning.jd b/src/devices/tuning.jd
new file mode 100644
index 0000000..b33e453
--- /dev/null
+++ b/src/devices/tuning.jd
@@ -0,0 +1,181 @@
+page.title=Performance tuning
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>This document describes performance tuninig that you can do to get the most out of your
+ hardware.</p>
+
+<h2>OpenGLRenderer (libhwui) Properties</h2>
+<p>This document lists all the properties that you can use to control
+Android’s 2D hardware accelerated rendering pipeline. Set these properties
+in the <code>device.mk</code> as <code>PRODUCT_PROPERTY_OVERRIDES</code>.
+</p>
+
+<table>
+<tr>
+ <th>Property</th>
+ <th>Type</th>
+ <th>Default Value</th>
+ <th>Description</th>
+</tr>
+
+<tr>
+ <td><code>ro.hwui.disable_scissor_opt</code></td>
+ <td><code>boolean</code></td>
+ <td><code>false</code></td>
+ <td><p>Used to enable or disable scissor optimization. The accepted values are true and false. When scissor optimization is enabled, OpenGLRenderer attempts to minimize the use of scissoring by selectively enabling and disabling the GL scissor test.</p>
+ <p>When the optimization is disabled, OpenGLRenderer keeps the GL scissor test enabled and changes the scissor rect as needed. Some GPUs (for instance, the SGX 540) perform better when changing the scissor rect more often than enabling or disabling the scissor test often.</p>
+ </td>
+</tr>
+
+<tr>
+
+ <td><code>ro.hwui.texture_cache_size</code></td>
+ <td><code>float</code></td>
+ <td><code>24</code></td>
+ <td>Defines the size, in megabytes, of the per process texture cache. We
+ recommend using a cache large enough to hold several screens worth of 32-bit textures (for instance, on a 1280x800 display, a full screen buffer uses about 4 MB so the cache should be at least 20 MB.)</td>
+</tr>
+
+<tr>
+ <td><code>ro.hwui.layer_cache_size</code></td>
+ <td><code>float</code></td>
+ <td><code>16</code></td>
+ <td>Defines the size, in megabytes, of the per process layers cache. We recommend
+ using a cache large enough to hold 4 times the screen in 32 bits. For instance,
+ on a 1280x800 display, a full screen buffer uses about 4 MB, so the cache should be at least 16 MB.</td>
+</tr>
+<tr>
+ <td><code>ro.hwui.gradient_cache_size</code></td>
+ <td><code>0.5</code></td>
+ <td><code>float</code></td>
+ <td>Defines the size, in megabytes, of the per process gradients cache. A single
+ gradient generally occupies between 1 and 4 KB of memory. It is recommended to use a
+ cache large enough to hold at least twelve gradients.</td>
+</tr>
+
+<tr>
+ <td><code>ro.hwui.path_cache_size</code></td>
+ <td><code>float</code></td>
+ <td><code>4</code></td>
+ <td>Defines the size, in megabytes, of the per process paths cache. We recommended using a
+ cache large enough to hold at least one screen worth of 32-bit textures. For instance,
+ on a 1280x800 display, a full screen buffer uses about 4 MB, so the cache should be at least 4 MB.</td>
+</tr>
+<tr>
+ <td><code>ro.hwui.shape_cache_size</code></td>
+ <td><code>float</code></td>
+ <td><code>1</code></td>
+ <td>Defines the size, in megabytes, of the per process shapes caches. This value is used by
+ several caches such as circles and rounded rectangles. We recommend using a cache
+ large enough to hold at least one 8-bit screen. For instance, on a 1280x800 display,
+ a full screen buffer uses about 1 MB, so the cache should be at least 1 MB.</td>
+</tr>
+<tr>
+ <td><code>ro.hwui.drop_shadow_cache_size</code></td>
+ <td><code>float</code></td>
+ <td><code>2</code></td>
+ <td>Defines the size, in megabytes, of the per process text drop shadows cache. We recommend
+ using a cache large enough to hold two screens worth of 8-bit textures. For instance, on a 1280x800 display, a full screen buffer uses about 1 MB, so the cache should be at least 2 MB.</td>
+</tr>
+<tr>
+
+
+ <td><code>ro.hwui.fbo_cache_size</code></td>
+ <td><code>integer</code></td>
+ <td><code>16</code></td>
+ <td>Defines the number of FBO names the renderer can hold in the cache at any given time.
+ We recommend keeping this number low.</td>
+</tr>
+
+<tr>
+ <td><code>ro.hwui.texture_cache_flush_rate</code></td>
+ <td><code>float</code></td>
+ <td><code>0.6</code></td>
+ <td>Defines the percentage of the texture cache to keep after a memory flush. Memory flushes are triggered when the system needs to reclaim memory across all applications. We recommend releasing about 50% of the cache in such situations.</td>
+</tr>
+<tr>
+ <td><code>ro.hwui.text_small_cache_width</code></td>
+ <td><code>integer</code></td>
+ <td><code>1024</code></td>
+ <td>Defines the width in pixels of the default font cache. The upper bound depends on how fast the GPU can upload textures.
+ We recommend using at least 1024 pixels but at most 2048 pixels. You should also use a power of two value.</td>
+</tr>
+<tr>
+ <td><code>ro.hwui.text_small_cache_height</code></td>
+ <td><code>integer</code></td>
+ <td><code>256</code></td>
+ <td>Defines the height in pixels of the default font cache. The upper bound depends on how fast the GPU can upload textures.
+ We recommend using at least 256 pixels but at most 1024 pixels. </td>
+</tr>
+<tr>
+ <td><code>ro.hwui.text_large_cache_width</code></td>
+ <td><code>integer</code></td>
+ <td><code>2048</code></td>
+ <td>Defines the width in pixels of the large font cache. This cache is used for glyphs too large to fit in the default font cache. The upper bound depends on how fast the GPU can upload textures. We recommended using at least 2048 pixels but at most 4096 pixels. You should also use a power of two value.</td>
+</tr>
+
+<tr>
+ <td><code>ro.hwui.text_large_cache_height</code></td>
+ <td><code>integer</code></td>
+ <td><code>512</code></td>
+ <td>Defines the height in pixels of the large font cache. The large font cache is used for glyphs too large to fit in the default font cache. The upper bound depends on how fast the GPU can upload textures.
+ We recommend using at least 512 pixels but at most 2048 pixels. You should also use a power of two value.</td>
+</tr>
+
+<tr>
+ <td><code>hwui.text_gamma_correction</code></td>
+ <td><code>string</code></td>
+ <td><code>lookup</code></td>
+ <td>Selects the text gamma correction technique. There are four possible choices:
+ <ul>
+ <li><code>lookup3</code>: A correction based on lookup tables. Gamma correction is different for black
+ and white text (see thresholds below).</li>
+
+ <li><code>lookup</code>: A correction based on a single lookup table.</li>
+
+ <li><code>shader3</code>: A correction applied by a GLSL shader. Gamma correction is different
+ for black and white text (see thresholds below).</li>
+
+ <li><code>shader</code>: A correction applied by a GLSL shader.</li>
+ </ul>
+ Lookup gamma corrections function best on GPUs with limited shader math. Shader gamma corrections are best to save memory. We recommend using the default <code>lookup</code> technique, which offers a good compromise in terms of quality, speed, and memory usage.
+</td>
+</tr>
+
+<tr>
+ <td><code>hwui.text_gamma</code></td>
+ <td><code>float</code></td>
+ <td><code>1.4</code></td>
+ <td>Defines the gamma value used for text gamma correction.
+ This value can be adjusted based on the display that is used by the device.</td>
+</tr>
+<tr>
+ <td><code>hwui.text_gamma.black_threshold</code></td>
+ <td><code>integer</code></td>
+ <td><code>64</code></td>
+ <td>Defines the luminance threshold below which black gamma correction is applied.
+ The value must be defined in the range 0..255.</td>
+</tr>
+<tr>
+ <td><code>hwui.text_gamma.white_threshold</code></td>
+ <td><code>integer</code></td>
+ <td><code>192</code></td>
+ <td>Defines the luminance threshold above which white gamma correction is applied.
+ The value must be defined in the range 0..255.</td>
+</tr>
+</table>
\ No newline at end of file
diff --git a/src/faqs.md b/src/faqs.md
deleted file mode 100644
index b272a18..0000000
--- a/src/faqs.md
+++ /dev/null
@@ -1,400 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Frequently Asked Questions #
-
-[TOC]
-
-## Open Source ##
-
-### What is the Android Open Source Project? ###
-
-We use the phrase "Android Open Source Project" or "AOSP" to refer to the
-people, the processes, and the source code that make up Android.
-
-The people oversee the project and develop the actual source code. The
-processes refer to the tools and procedures we use to manage the development
-of the software. The net result is the source code that you can use to build
-cell phone and other devices.
-
-### Why did we open the Android source code? ###
-
-Google started the Android project in response to our own experiences
-launching mobile apps. We wanted to make sure that there would always be an
-open platform available for carriers, OEMs, and developers to use to make
-their innovative ideas a reality. We also wanted to make sure that there was no
-central point of failure, so that no single industry player could restrict or control
-the innovations of any other. The single most important goal of the Android
-Open-Source Project (AOSP) is to make sure that the open-source Android
-software is implemented as widely and compatibly as possible, to everyone's
-benefit.
-
-You can find more information on this topic at our Project Philosophy page.
-
-### What kind of open-source project is Android? ###
-
-Google oversees the development of the core Android open-source platform,
-and works to create robust developer and user communities. For the most part
-the Android source code is licensed under the permissive Apache Software
-License 2.0, rather than a "copyleft" license. The main reason for this is
-because our most important goal is widespread adoption of the software, and
-we believe that the ASL2.0 license best achieves that goal.
-
-You can find more information on this topic at our Project Philosophy and
-Licensing pages.
-
-### Why is Google in charge of Android? ###
-
-Launching a software platform is complex. Openness is vital to the
-long-term success of a platform, since openness is required to attract
-investment from developers and ensure a level playing field. However, the
-platform itself must also be a compelling product to end users.
-
-That's why Google has committed the professional engineering resources
-necessary to ensure that Android is a fully competitive software platform.
-Google treats the Android project as a full-scale product development
-operation, and strikes the business deals necessary to make sure that great
-devices running Android actually make it to market.
-
-By making sure that Android is a success with end users, we help ensure the
-vitality of Android as a platform, and as an open-source project. After all,
-who wants the source code to an unsuccessful product?
-
-Google's goal is to ensure a successful ecosystem around Android, but no
-one is required to participate, of course. We opened the Android source code
-so anyone can modify and distribute the software to meet their own needs.
-
-### What is Google's overall strategy for Android product development? ###
-
-We focus on releasing great devices into a competitive marketplace, and
-then incorporate the innovations and enhancements we made into the core
-platform, as the next version.
-
-In practice, this means that the Android engineering team typically focuses
-on a small number of "flagship" devices, and develops the next version of
-the Android software to support those product launches. These flagship
-devices absorb much of the product risk and blaze a trail for the broad OEM
-community, who follow up with many more devices that take advantage of the
-new features. In this way, we make sure that the Android platform evolves
-according to the actual needs of real-world devices.
-
-### How is the Android software developed? ###
-
-Each platform version of Android (such as 1.5, 1.6, and so on) has a
-corresponding branch in the open-source tree. At any given moment, the most
-recent such branch will be considered the "current stable" branch version.
-This current stable branch is the one that manufacturers port to their
-devices. This branch is kept suitable for release at all times.
-
-Simultaneously, there is also a "current experimental" branch, which is
-where speculative contributions, such as large next-generation features, are
-developed. Bug fixes and other contributions can be included in the current
-stable branch from the experimental branch as appropriate.
-
-Finally, Google works on the next version of the Android platform in tandem
-with developing a flagship device. This branch pulls in changes from the
-experimental and stable branches as appropriate.
-
-You can find more information on this topic at our [Branches and Releases](source/code-lines.html).
-
-### Why are parts of Android developed in private? ###
-
-It typically takes over a year to bring a device to market, but of course
-device manufacturers want to ship the latest software they can. Developers,
-meanwhile, don't want to have to constantly track new versions of the
-platform when writing apps. Both groups experience a tension between
-shipping products, and not wanting to fall behind.
-
-To address this, some parts of the next version of Android including the
-core platform APIs are developed in a private branch. These APIs constitute
-the next version of Android. Our aim is to focus attention on the current
-stable version of the Android source code, while we create the next version
-of the platform as driven by flagship Android devices. This allows developers
-and OEMs to focus on a single version without having to track unfinished
-future work just to keep up. Other parts of the Android system that aren't
-related to application compatibility are developed in the open, however.
-It's our intention to move more of these parts to open development over
-time.
-
-### When are source code releases made? ###
-
-When they are ready. Some parts of Android are developed in the open,
-so that source code is always available. Other parts are developed first in
-a private tree, and that source code is released when the next platform
-version is ready.
-
-In some releases, core platform APIs will be ready far enough in advance
-that we can push the source code out for an early look in advance of the
-device's release; however in others, this isn't possible. In all cases, we
-release the platform source when we feel the version has stabilized enough,
-and when the development process permits. Releasing the source code is a
-fairly complex process.
-
-### What is involved in releasing the source code for a new Android version? ###
-
-Releasing the source code for a new version of the Android platform is a
-significant process. First, the software gets built into a system image for
-a device, and put through various forms of certification, including
-government regulatory certification for the regions the phones will be
-deployed. It also goes through operator testing. This is an important phase
-of the process, since it helps shake out a lot of software bugs.</p>
-
-Once the release is approved by the regulators and operators, the
-manufacturer begins mass producing devices, and we turn to releasing the
-source code.
-
-Simultaneous to mass production the Google team kicks off several efforts
-to prepare the open source release. These efforts include final API changes
-and documentation (to reflect any changes that were made during
-qualification testing, for example), preparing an SDK for the new version,
-and launching the platform compatibility information.
-
-Also included is a final legal sign-off to release the code into open
-source. Just as open source contributors are required to sign a Contributors
-License Agreement attesting to their IP ownership of their contribution,
-Google too must verify that it is clear to make contributions.
-
-Starting at the time mass production begins, the software release process
-usually takes around a month, which often roughly places source code
-releases around the same time that the devices reach users.
-
-### How does the AOSP relate to the Android Compatibility Program? ###
-
-The Android Open-Source Project maintains the Android software, and
-develops new versions. Since it's open-source, this software can be used for
-any purpose, including to ship devices that are not compatible with other
-devices based on the same source.
-
-The function of the Android Compatibility Program is to define a baseline
-implementation of Android that is compatible with third-party apps written
-by developers. Devices that are "Android compatible" may participate in the
-Android ecosystem, including Google Play; devices that don't meet the
-compatibility requirements exist outside that ecosystem.
-
-In other words, the Android Compatibility Program is how we separate
-"Android compatible devices" from devices that merely run derivatives of the
-source code. We welcome all uses of the Android source code, but only
-Android compatible devices -- as defined and tested by the Android
-Compatibility Program -- may participate in the Android ecosystem.
-
-### How can I contribute to Android? ###
-
-There are a number of ways you can contribute to Android. You can report
-bugs, write apps for Android, or contribute source code to the Android
-Open-Source Project.
-
-There are some limits on the kinds of code contributions we are willing or
-able to accept. For instance, someone might want to contribute an
-alternative application API, such as a full C++-based environment. We would
-decline that contribution, since Android is focused on applications that run
-in the Dalvik VM. Alternatively, we won't accept contributions such as GPL
-or LGPL libraries that are incompatible with our licensing goals.
-
-We encourage those interested in contributing source code to contact us via
-the AOSP Community page prior to beginning any work. You can find more
-information on this topic at the Getting Involved page.
-
-### How do I become an Android committer? ###
-
-The Android Open Source Project doesn't really have a notion of a
-"committer". All contributions -- including those authored by Google
-employees -- go through a web-based system known as "gerrit" that's part of
-the Android engineering process. This system works in tandem with the git
-source code management system to cleanly manage source code
-contributions.
-
-Once submitted, changes need to be accepted by a designated Approver.
-Approvers are typically Google employees, but the same approvers are
-responsible for all submissions, regardless of origin.
-
-You can find more information on this topic at the [Submitting Patches](source/submit-patches.html) page.
-
-## Compatibility ##
-
-### What does "compatibility" mean? ###
-
-We define an "Android compatible" device as one that can run any
-application written by third-party developers using the Android SDK and NDK.
-We use this as a filter to separate devices that can participate in the
-Android app ecosystem, and those that cannot. Devices that are properly
-compatible can seek approval to use the Android trademark. Devices that are
-not compatible are merely derived from the Android source code and may not
-use the Android trademark.
-
-In other words, compatibility is a prerequisite to participate in the
-Android apps ecosystem. Anyone is welcome to use the Android source code,
-but if the device isn't compatible, it's not considered part of the Android
-ecosystem.
-
-### What is the role of Google Play in compatibility? ###
-
-Devices that are Android compatible may seek to license the Google Play
-client software. This allows them to become part of the Android app
-ecosystem, by allowing users to download developers' apps from a catalog
-shared by all compatible devices. This option isn't available to devices
-that aren't compatible.
-
-### What kinds of devices can be Android compatible? ###
-
-The Android software can be ported to a lot of different kinds of devices,
-including some on which third-party apps won't run properly. The Android
-Compatibility Definition Document (CDD) spells out the specific device
-configurations that will be considered compatible.
-
-For example, though the Android source code could be ported to run on a
-phone that doesn't have a camera, the CDD requires that in order to be
-compatible, all phones must have a camera. This allows developers to rely
-on a consistent set of capabilities when writing their apps.
-
-The CDD will evolve over time to reflect market realities. For instance,
-the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit
-telephony hardware, allowing for non-phone devices such as tablet-style
-music players to be compatible. As we make these changes, we will also
-augment Google Play to allow developers to retain control over where
-their apps are available. To continue the telephony example, an app that
-manages SMS text messages would not be useful on a media player, so Google
-Play allows the developer to restrict that app exclusively to phone
-devices.
-
-### If my device is compatible, does it automatically have access to Google Play and branding? ###
-
-Google Play is a service operated by Google. Achieving compatibility is
-a prerequisite for obtaining access to the Google Play software and branding.
-Device manufacturers should contact Google to obtain access to Google
-Play.
-
-### If I am not a manufacturer, how can I get Google Play? ###
-
-Google Play is only licensed to handset manufacturers shipping devices.
-For questions about specific cases, contact android-partnerships@google.com.
-
-### How can I get access to the Google apps for Android, such as Maps? ###
-
-The Google apps for Android, such as YouTube, Google Maps and Navigation,
-Gmail, and so on are Google properties that are not part of Android, and
-are licensed separately. Contact android-partnerships@google.com for
-inquiries related to those apps.
-
-### Is compatibility mandatory? ###
-
-No. The Android Compatibility Program is optional. Since the Android source
-code is open, anyone can use it to build any kind of device. However, if a
-manufacturer wishes to use the Android name with their product, or wants
-access to Google Play, they must first demonstrate that the device is
-compatible.
-
-### How much does compatibility certification cost? ###
-
-There is no cost to obtain Android compatibility for a device. The
-Compatibility Test Suite is open-source and available to anyone to use to
-test a device.
-
-### How long does compatibility take? ###
-
-The process is automated. The Compatibility Test Suite generates a report
-that can be provided to Google to verify compatibility. Eventually we intend
-to provide self-service tools to upload these reports to a public database.
-
-### Who determines what will be part of the compatibility definition? ###
-
-Since Google is responsible for the overall direction of Android as a
-platform and product, Google maintains the Compatibility Definition Document
-for each release. We draft the CDD for a new Android version in consultation
-with a number of OEMs, who provide input on its contents.
-
-### How long will each Android version be supported for new devices? ###
-
-Since Android's code is open-source, we can't prevent someone from using an
-old version to launch a device. Instead, Google chooses not to license the
-Google Play client software for use on versions that are considered
-obsolete. This allows anyone to continue to ship old versions of Android,
-but those devices won't use the Android name and will exist outside the
-Android apps ecosystem, just as if they were non-compatible.
-
-### Can a device have a different user interface and still be compatible? ###
-
-The Android Compatibility Program focuses on whether a device can run
-third-party applications. The user interface components shipped with a
-device (such as home screen, dialer, color scheme, and so on) does not
-generally have much effect on third-party apps. As such, device builders are
-free to customize the user interface as much as they like. The Compatibility
-Definition Document does restrict the degree to which OEMs may alter the
-system user interface for areas that do impact third-party apps.
-
-### When are compatibility definitions released for new Android versions? ###
-
-Our goal is to release new versions of Android Compatibility Definition
-Documents (CDDs) once the corresponding Android platform version has
-converged enough to permit it. While we can't release a final draft of a CDD
-for an Android software version before the first flagship device ships with
-that software, final CDDs will always be released after the first device.
-However, wherever practical we will make draft versions of CDDs available.
-
-### How are device manufacturers' compatibility claims validated? ###
-
-There is no validation process for Android device compatibility. However,
-if the device is to include Google Play, Google will typically validate
-the device for compatibility before agreeing to license the Google Play client
-software.
-
-### What happens if a device that claims compatibility is later found to have compatibility problems? ###
-
-Typically, Google's relationships with Google Play licensees allow us to
-ask them to release updated system images that fix the problems.
-
-## Compatibility Test Suite ##
-
-### What is the purpose of the CTS? ###
-
-The Compatibility Test Suite is a tool used by device manufacturers to help
-ensure their devices are compatible, and to report test results for
-validations. The CTS is intended to be run frequently by OEMs throughout the
-engineering process to catch compatibility issues early.
-
-### What kinds of things does the CTS test? ###
-
-The CTS currently tests that all of the supported Android strong-typed APIs
-are present and behave correctly. It also tests other non-API system
-behaviors such as application lifecycle and performance. We plan to add
-support in future CTS versions to test "soft" APIs such as Intents as
-well.
-
-### Will the CTS reports be made public? ###
-
-Yes. While not currently implemented, Google intends to provide web-based
-self-service tools for OEMs to publish CTS reports so that they can be
-viewed by anyone. CTS reports can be shared as widely as manufacturers
-prefer.
-
-### How is the CTS licensed? ###
-
-The CTS is licensed under the same Apache Software License 2.0 that the
-bulk of Android uses.
-
-### Does the CTS accept contributions? ###
-
-Yes please! The Android Open-Source Project accepts contributions to
-improve the CTS in the same way as for any other component. In fact,
-improving the coverage and quality of the CTS test cases is one of the best
-ways to help out Android.
-
-### Can anyone use the CTS on existing devices? ###
-
-The Compatibility Definition Document requires that compatible devices
-implement the 'adb' debugging utility. This means that any compatible device
--- including ones available at retail -- must be able to run the CTS
-tests.
-
diff --git a/src/index.jd b/src/index.jd
new file mode 100644
index 0000000..d977612
--- /dev/null
+++ b/src/index.jd
@@ -0,0 +1,86 @@
+fullpage=true
+no_footer_links=true
+landing.page=true
+page.metaDescription=The official site for the Android Open Source Project.
+header.hide=1
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div class="wrap">
+
+ <div class="landing-banner">
+ <h1 itemprop="name" style="margin-bottom:0;">Welcome to the Android Open Source Project!</h1>
+
+ <p>
+ Android is an open-source software stack for a wide range of devices and a corresponding open-source project led by Google.
+ Here you can find the information and source code you need to learn more about the Android platform. From there you can
+ create custom variants of the Android software stack, build devices and accessories that run on the Android platform,
+ and ensure that your devices are compatible with the Android compatibility definition.
+ </p>
+
+ </div>
+
+</div>
+
+
+<div class="wrap">
+
+ <div class="landing-docs">
+ <div class="col-8">
+ <h3>Updates</h3>
+ <a href="">
+ <h4>Source Code Available for Android 4.1</h4>
+ <p>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.</p>
+ </a>
+ <a href="">
+ <h4>Compatibility Definition for Android 4.0</h4>
+ <p>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.</p>
+ </a>
+ </div>
+
+ <div class="col-8">
+ <h3>Getting Started</h3>
+ <a href="{@docRoot}source/index.html">
+ <h4>Explore the Source</h4>
+ <p>Get the complete Android platform and modify and build it to suit your needs. You can
+ also contribute to the Open Source Project to make your changes available to everyone else in
+ the Android ecosystem.</p>
+ </a>
+ <a href="{@docRoot}devices/index.html">
+ <h4>Build Devices</h4>
+ <p>The Android PDK lets you build devices with the latest Android platform, before
+ it is released to the public. This gives you a headstart on creating the compelling
+ devices that your customers want.</p>
+ </a>
+
+ <a href="{@docRoot}accessories/index.html">
+ <h4>Build Accessories</h4>
+ <p>Sometimes, a device can't do it all. Tap into Android's open accessory standard and
+ build accessories to complement the wide variety of Android-powered devices.</p>
+ </a>
+
+ <a href="{@docRoot}compatibility/index.html">
+ <h4>Get Compatible</h4>
+ <p>Being Android-compatible lets you offer custom features but still give users and developers a consistent
+ and standard experience across all Android-powered devices. Android provides guidance
+ and a test suite to verify your Android compatibility.</p>
+ </a>
+ </div>
+
+ </div>
+
+</div>
\ No newline at end of file
diff --git a/src/index.md b/src/index.md
deleted file mode 100644
index 300b663..0000000
--- a/src/index.md
+++ /dev/null
@@ -1,98 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Welcome to Android #
-
-<div style="float: right; width: 35%;">
-
-## 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.
-
-</div>
-
-<img style="float: right; padding-right: 1.5em;" src="images/home-bugdroid.png" alt="Android Mascot"/>
-
-<div style="font-size: 1.3em;">
-
-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)
-
-</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/porting-removed.md b/src/porting-removed.md
deleted file mode 100644
index b6584f7..0000000
--- a/src/porting-removed.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Android Platform Developer's Guide #
-
-As the information in this guide was substantially out of date and
-consequently misleading, we have removed it for now. We will make similar
-information available as we create new materials. We apologize for any
-inconvenience.
diff --git a/src/assets/bg_fade.jpg b/src/source/assets/bg_fade.jpg
similarity index 100%
rename from src/assets/bg_fade.jpg
rename to src/source/assets/bg_fade.jpg
Binary files differ
diff --git a/src/assets/bg_images_sprite.png b/src/source/assets/bg_images_sprite.png
similarity index 100%
rename from src/assets/bg_images_sprite.png
rename to src/source/assets/bg_images_sprite.png
Binary files differ
diff --git a/src/assets/favicon.ico b/src/source/assets/favicon.ico
similarity index 100%
rename from src/assets/favicon.ico
rename to src/source/assets/favicon.ico
Binary files differ
diff --git a/src/assets/main.css b/src/source/assets/main.css
similarity index 100%
rename from src/assets/main.css
rename to src/source/assets/main.css
diff --git a/src/assets/rebox-gradient.gif b/src/source/assets/rebox-gradient.gif
similarity index 100%
rename from src/assets/rebox-gradient.gif
rename to src/source/assets/rebox-gradient.gif
Binary files differ
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
new file mode 100644
index 0000000..c9b6607
--- /dev/null
+++ b/src/source/build-numbers.jd
@@ -0,0 +1,524 @@
+page.title=Codenames, Tags, and Build Numbers
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>At a high level, Android development happens around families of
+releases, which use code names ordered alphabetically after tasty
+treats.</p>
+
+<h2 id="platform-code-names-versions-api-levels-and-ndk-releases">Platform Codenames, Versions, API Levels, and NDK Releases</h2>
+<p>The code names match the following version numbers, along with
+API levels and NDK releases provided for convenience:</p>
+<table>
+<thead>
+<tr>
+<th>Code name</th>
+<th>Version</th>
+<th>API level</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>(no code name)</td>
+<td>1.0</td>
+<td>API level 1</td>
+</tr>
+<tr>
+<td>(no code name)</td>
+<td>1.1</td>
+<td>API level 2</td>
+</tr>
+<tr>
+<td>Cupcake</td>
+<td>1.5</td>
+<td>API level 3, NDK 1</td>
+</tr>
+<tr>
+<td>Donut</td>
+<td>1.6</td>
+<td>API level 4, NDK 2</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.0</td>
+<td>API level 5</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.0.1</td>
+<td>API level 6</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.1</td>
+<td>API level 7, NDK 3</td>
+</tr>
+<tr>
+<td>Froyo</td>
+<td>2.2.x</td>
+<td>API level 8, NDK 4</td>
+</tr>
+<tr>
+<td>Gingerbread</td>
+<td>2.3 - 2.3.2</td>
+<td>API level 9, NDK 5</td>
+</tr>
+<tr>
+<td>Gingerbread</td>
+<td>2.3.3 - 2.3.7</td>
+<td>API level 10</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.0</td>
+<td>API level 11</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.1</td>
+<td>API level 12, NDK 6</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.2.x</td>
+<td>API level 13</td>
+</tr>
+<tr>
+<td>Ice Cream Sandwich</td>
+<td>4.0.1 - 4.0.2</td>
+<td>API level 14, NDK 7</td>
+</tr>
+<tr>
+<td>Ice Cream Sandwich</td>
+<td>4.0.3 - 4.0.4</td>
+<td>API level 15, NDK 8</td>
+</tr>
+<tr>
+<td>Jelly Bean</td>
+<td>4.1.x</td>
+<td>API level 16</td>
+</tr>
+<tr>
+<td>Jelly Bean</td>
+<td>4.2.x</td>
+<td>API level 17</td>
+</tr>
+</tbody>
+</table>
+<p>Starting with Cupcake, individual builds are identified with a short
+build code, e.g. FRF85B.</p>
+<p>The first letter is the code name of the release family, e.g. F is
+Froyo.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+
+<h2 id="source-code-tags-and-builds">Source Code Tags and Builds</h2>
+<p>Starting with Donut, the exact list of tags and builds is in the
+following table:</p>
+<table>
+<thead>
+<tr>
+<th>Build</th>
+<th>Tag</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>DRC83</td>
+<td>android-1.6_r1.1</td>
+<td>earliest Donut version, ADP1, ADP2</td>
+</tr>
+<tr>
+<td>DRC92</td>
+<td>android-1.6_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>DRD08</td>
+<td>android-1.6_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>DRD20</td>
+<td>android-1.6_r1.4</td>
+<td></td>
+</tr>
+<tr>
+<td>DMD64</td>
+<td>android-1.6_r1.5</td>
+<td>latest Donut version</td>
+</tr>
+<tr>
+<td>ESD20</td>
+<td>android-2.0_r1</td>
+<td>earliest Eclair version</td>
+</tr>
+<tr>
+<td>ESD56</td>
+<td>android-2.0.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>ERD79</td>
+<td>android-2.1_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>ERE27</td>
+<td>android-2.1_r2</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>EPE54B</td>
+<td>android-2.1_r2.1p</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>ESE81</td>
+<td>android-2.1_r2.1s</td>
+<td></td>
+</tr>
+<tr>
+<td>EPF21B</td>
+<td>android-2.1_r2.1p2</td>
+<td>latest Eclair version</td>
+</tr>
+<tr>
+<td>FRF85B</td>
+<td>android-2.2_r1</td>
+<td>earliest Froyo version, Nexus One</td>
+</tr>
+<tr>
+<td>FRF91</td>
+<td>android-2.2_r1.1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG01B</td>
+<td>android-2.2_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>FRG22D</td>
+<td>android-2.2_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>FRG83</td>
+<td>android-2.2.1_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG83D</td>
+<td>android-2.2.1_r2</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG83G</td>
+<td>android-2.2.2_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRK76</td>
+<td>android-2.2.3_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>FRK76C</td>
+<td>android-2.2.3_r2</td>
+<td>latest Froyo version</td>
+</tr>
+<tr>
+<td>GRH55</td>
+<td>android-2.3_r1</td>
+<td>earliest Gingerbread version, Nexus S</td>
+</tr>
+<tr>
+<td>GRH78</td>
+<td>android-2.3.1_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRH78C</td>
+<td>android-2.3.2_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRI40</td>
+<td>android-2.3.3_r1</td>
+<td>Nexus One, Nexus S</td>
+</tr>
+<tr>
+<td>GRI54</td>
+<td>android-2.3.3_r1.1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRJ06D</td>
+<td>android-2.3.4_r0.9</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRJ22</td>
+<td>android-2.3.4_r1</td>
+<td>Nexus One, Nexus S, Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRJ90</td>
+<td>android-2.3.5_r1</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRK39C</td>
+<td>android-2.3.6_r0.9</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRK39F</td>
+<td>android-2.3.6_r1</td>
+<td>Nexus One, Nexus S</td>
+</tr>
+<tr>
+<td>GWK74</td>
+<td>android-2.3.7_r1</td>
+<td>latest Gingerbread version, Nexus S 4G</td>
+</tr>
+<tr>
+<td>ITL41D</td>
+<td>android-4.0.1_r1</td>
+<td>earliest Ice Cream Sandwich version, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ITL41D</td>
+<td>android-4.0.1_r1.1</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ITL41F</td>
+<td>android-4.0.1_r1.2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ICL53F</td>
+<td>android-4.0.2_r1</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IML74K</td>
+<td>android-4.0.3_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>IML77</td>
+<td>android-4.0.3_r1.1</td>
+<td></td>
+</tr>
+<tr>
+<td>IMM76</td>
+<td>android-4.0.4_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>IMM76D</td>
+<td>android-4.0.4_r1.1</td>
+<td>Nexus S, Nexus S 4G, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76I</td>
+<td>android-4.0.4_r1.2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76K</td>
+<td>android-4.0.4_r2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76L</td>
+<td>android-4.0.4_r2.1</td>
+<td>latest Ice Cream Sandwich version</td>
+</tr>
+<tr>
+<td>JRO03C</td>
+<td>android-4.1.1_r1</td>
+<td>earliest Jelly Bean version, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>JRO03D</td>
+<td>android-4.1.1_r1.1</td>
+<td>Nexus 7</td>
+</tr>
+<tr>
+<td>JRO03E</td>
+<td>android-4.1.1_r2</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>JRO03H</td>
+<td>android-4.1.1_r3</td>
+<td></td>
+</tr>
+<tr>
+<td>JRO03L</td>
+<td>android-4.1.1_r4</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>JRO03O</td>
+<td>android-4.1.1_r5</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>JRO03R</td>
+<td>android-4.1.1_r6</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>JRO03S</td>
+<td>android-4.1.1_r6.1</td>
+<td>Nexus 7</td>
+</tr>
+<tr>
+<td>JZO54K</td>
+<td>android-4.1.2_r1</td>
+<td>Nexus S, Galaxy Nexus, Nexus 7</td>
+</tr>
+<tr>
+<td>JOP40C</td>
+<td>android-4.2_r1</td>
+<td>Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
+</tr>
+<tr>
+<td>JOP40D</td>
+<td>android-4.2.1_r1</td>
+<td>latest Jelly Bean version, Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
+</tr>
+</tbody>
+</table>
+<p>The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
+jb-mr1-dev,
+represent development
+branches that do not exactly match configurations that were tested
+by Google. They might contain a variety of changes in addition to
+the official tagged releases, and those haven't been as thoroughly
+tested.</p>
+
+<h2 id="honeycomb-gpl-modules">Honeycomb GPL Modules</h2>
+<p>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:</p>
+<table>
+<thead>
+<tr>
+<th>Build</th>
+<th>Tag</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>HRI39</td>
+<td>android-3.0_r1</td>
+<td>earliest Honeycomb version</td>
+</tr>
+<tr>
+<td>HRI66</td>
+<td>android-3.0_r1.1</td>
+<td></td>
+</tr>
+<tr>
+<td>HWI69</td>
+<td>android-3.0_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>HRI93</td>
+<td>android-3.0_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>HMJ37</td>
+<td>android-3.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTJ85B</td>
+<td>android-3.2_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTK55D</td>
+<td>android-3.2.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTK75D</td>
+<td>android-3.2.1_r2</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75C</td>
+<td>android-3.2.2_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75D</td>
+<td>android-3.2.2_r2</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75F</td>
+<td>android-3.2.4_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75H</td>
+<td>android-3.2.6_r1</td>
+<td>latest Honeycomb version</td>
+</tr>
+</tbody>
+</table>
+<p>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.</p>
+<pre><code>$ repo init -b master -m base-for-3.0-gpl.xml
+$ repo sync
+$ repo forall -c git checkout android-3.0_r1.1
+</code></pre>
+
diff --git a/src/source/build-numbers.md b/src/source/build-numbers.md
deleted file mode 100644
index 807152f..0000000
--- a/src/source/build-numbers.md
+++ /dev/null
@@ -1,162 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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
-
-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 | latest Jelly Bean version, Nexus S
-
-The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-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
-HRI93 | 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.jd b/src/source/building-devices.jd
new file mode 100644
index 0000000..077d448
--- /dev/null
+++ b/src/source/building-devices.jd
@@ -0,0 +1,274 @@
+page.title=Building for devices
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>This page complements the main page about
+<a href="building-running.html">Building and Running</a> with
+information that is specific to individual devices.</p>
+<p>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.</p>
+<p>All configurations of Nexus 10 can be used. On those devices, graphics, audio,
+Wi-Fi, Bluetooth, camera, NFC, GPS and orientation sensors are functional.</p>
+<p>Nexus 4 cannot be used at the moment.</p>
+<p>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.</p>
+<p>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.</p>
+<p>The Sprint CDMA/LTE configuration "toroplus" of Galaxy Nexus is supported
+experimentally. On that configuration, the cellular network is not functional,
+and the other peripherals work like they do on "toro".</p>
+<p>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.</p>
+<p>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.</p>
+<p>In addition, <a href="http://pandaboard.org">PandaBoard</a> a.k.a. "panda" can be used
+in the master branch, but is considered experimental.
+The specific details to use a PandaBoard with the Android Open-Source Project
+are in the file <code>device/ti/panda/README</code> in the source tree.</p>
+<p>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.</p>
+<p>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.</p>
+<h2 id="building-fastboot-and-adb">Building fastboot and adb</h2>
+<p>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
+<a href="building-running.html">Building and Running</a>, and replace the main <code>make</code> command with</p>
+<pre><code>$ make fastboot adb
+</code></pre>
+<h2 id="booting-into-fastboot-mode">Booting into fastboot mode</h2>
+<p>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:</p>
+<table>
+<thead>
+<tr>
+<th>Device</th>
+<th>Keys</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>manta</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>mako</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>grouper</td>
+<td>Press <em>Power</em> for a second, and press <em>Volume Down</em> when the bootloader logo appears</td>
+</tr>
+<tr>
+<td>tilapia</td>
+<td>Press <em>Power</em> for a second, and press <em>Volume Down</em> when the bootloader logo appears</td>
+</tr>
+<tr>
+<td>phantasm</td>
+<td>Power the device, cover it with one hand after the LEDs light up and until they turn red</td>
+</tr>
+<tr>
+<td>maguro</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>toro</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>toroplus</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>panda</td>
+<td>Press and hold <em>Input</em>, then press <em>Power</em></td>
+</tr>
+<tr>
+<td>wingray</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>crespo</td>
+<td>Press and hold <em>Volume Up</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>crespo4g</td>
+<td>Press and hold <em>Volume Up</em>, then press and hold <em>Power</em></td>
+</tr>
+</tbody>
+</table>
+<p>Also, the command <code>adb reboot bootloader</code> can be used to reboot from
+Android directly into the bootloader with no key combinations.</p>
+<h2 id="unlocking-the-bootloader">Unlocking the bootloader</h2>
+<p>It's only possible to flash a custom system if the bootloader allows it.</p>
+<p>The bootloader is locked by default. With the device in fastboot mode, the
+bootloader is unlocked with</p>
+<pre><code>$ fastboot oem unlock
+</code></pre>
+<p>The procedure must be confirmed on-screen, and deletes the user data for
+privacy reasons. It only needs to be run once.</p>
+<p>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.</p>
+<p>On Nexus 10, after unlocking the bootloader, the internal storage is
+left unformatted and must be formatted with</p>
+<pre><code>$ fastboot format cache
+$ fastboot format userdata
+</code></pre>
+<p>The bootloader can be locked back with</p>
+<pre><code>$ fastboot oem lock
+</code></pre>
+<p>Note that this erases user data on Xoom (including the shared USB data).</p>
+<h2 id="obtaining-proprietary-binaries">Obtaining proprietary binaries</h2>
+<p>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.</p>
+<p>Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, Nexus 4,
+Nexus 10 and PandaBoard
+can be downloaded from
+<a href="https://developers.google.com/android/nexus/drivers">Google's Nexus driver page</a>,
+which add access to additional hardware capabilities with non-Open-Source code.</p>
+<p>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.</p>
+<h3 id="extracting-the-proprietary-binaries">Extracting the proprietary binaries</h3>
+<p>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 <code>vendor/</code> hierarchy of the source tree.</p>
+<h3 id="cleaning-up-when-adding-proprietary-binaries">Cleaning up when adding proprietary binaries</h3>
+<p>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</p>
+<pre><code>$ make clobber
+</code></pre>
+<h2 id="picking-and-building-the-configuration-that-matches-a-device">Picking and building the configuration that matches a device</h2>
+<p>The steps to configure and build the Android Open-Source Project
+are described in the page about <a href="building-running.html">Building and Running</a>.</p>
+<p>The recommended builds for the various devices are available through
+the lunch menu, accessed when running the <code>lunch</code> command with no arguments:</p>
+<table>
+<thead>
+<tr>
+<th>Device</th>
+<th>Branch</th>
+<th>Build configuration</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>manta</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_manta-userdebug</td>
+</tr>
+<tr>
+<td>grouper</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_grouper-userdebug</td>
+</tr>
+<tr>
+<td>tipalia</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_tilapia-userdebug</td>
+</tr>
+<tr>
+<td>maguro</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_maguro-userdebug</td>
+</tr>
+<tr>
+<td>toro</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_toro-userdebug</td>
+</tr>
+<tr>
+<td>toroplus</td>
+<td>master</td>
+<td>full_toroplus-userdebug</td>
+</tr>
+<tr>
+<td>panda</td>
+<td>master</td>
+<td>full_panda-userdebug</td>
+</tr>
+<tr>
+<td>wingray</td>
+<td>android-4.1.2_r1</td>
+<td>full_wingray-userdebug</td>
+</tr>
+<tr>
+<td>crespo</td>
+<td>android-4.1.2_r1</td>
+<td>full_crespo-userdebug</td>
+</tr>
+<tr>
+<td>crespo4g</td>
+<td>android-4.1.2_r1</td>
+<td>full_crespo4g-userdebug</td>
+</tr>
+</tbody>
+</table>
+<p>Do not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2
+or newer.</p>
+<h2 id="flashing-a-device">Flashing a device</h2>
+<p>Set the device in fastboot mode if necessary (see above).</p>
+<p>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
+<code>fastboot oem unlock</code> mentioned earlier.</p>
+<pre><code>$ fastboot -w flashall
+</code></pre>
+<p>Note that filesystems created via fastboot on Motorola Xoom aren't working
+optimally, and it is strongly recommended to re-create them through recovery</p>
+<pre><code>$ adb reboot recovery
+</code></pre>
+<p>Once in recovery, open the menu (press Power + Volume Up), wipe the cache
+partition, then wipe data.</p>
+<h2 id="restoring-a-device-to-its-original-factory-state">Restoring a device to its original factory state</h2>
+<p>Factory images
+for Nexus 10,
+for Nexus 4,
+for Nexus Q,
+for Nexus 7 (all variants),
+for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju",
+and CDMA/LTE "mysid" and "mysidspr"),
+and
+for Nexus S and Nexus S 4G (all variants)
+are available from
+<a href="https://developers.google.com/android/nexus/images">Google's factory image page</a>.</p>
+<p>Factory images for the Motorola Xoom are distributed directly by Motorola.</p>
\ No newline at end of file
diff --git a/src/source/building-devices.md b/src/source/building-devices.md
deleted file mode 100644
index 9c2ab82..0000000
--- a/src/source/building-devices.md
+++ /dev/null
@@ -1,204 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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 7, for some
-variants of Galaxy Nexus, for a variant of the Motorola Xoom, and for
-all variants of Nexus S and Nexus S 4G. The exact level of functionality
-for each device depends on the availability of the relevant proprietary
-hardware-specific binaries.
-
-All variants of Nexus 7 can be used. On Nexus 7, graphics and audio are
-functional, as well as WiFi and Bluetooth.
-
-The variants of Galaxy Nexus that be used are the GSM/HSPA+ configuration
-"maguro" (only if it was originally sold with a "yakju" or "takju" operating
-system) and the VZW CDMA/LTE configuration "toro". On those devices, graphics
-and audio are functional, as well as WiFi, Bluetooth, and access to the
-respective cellular networks. The orientation sensors are functional.
-
-The Motorola Xoom is can be used in the Wi-Fi configuration "wingray"
-sold in the USA. Graphics and audio are functional as well as WiFi and
-Bluetooth and the orientation sensors.
-
-All configurations of Nexus S and Nexus S 4G can be used, and on those
-devices all the peripherals are functional: graphics, audio, Wifi, Bluetooth,
-cell networks, sensors, camera, hardware codecs, NFC, GPS.
-
-In addition, [PandaBoard](http://pandaboard.org) a.k.a. "panda" can be used
-in the master 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
----------|------
-grouper | Press *Power* for a second, and press *Volume Down* when the bootloader logo appears
-maguro | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
-toro | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
-panda | Press and hold *Input*, then press *Power*
-wingray | Press and hold *Volume Down*, then press and hold *Power*
-crespo | Press and hold *Volume Up*, then press and hold *Power*
-crespo4g | Press and hold *Volume Up*, then press and hold *Power*
-passion | Press and hold the trackball, then press *Power*
-sapphire | Press and hold *Back*, then press *Power*
-dream | Press and hold *Back*, then press *Power*
-
-Also, the command `adb reboot bootloader` can be used to reboot from
-Android directly into the bootloader with no key combinations.
-
-## Unlocking the bootloader ##
-
-It's only possible to flash a custom system if the bootloader allows it.
-
-This is the default setup on ADP1 and ADP2.
-
-On Nexus One, Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-the bootloader is locked by default. With the device in fastboot mode, the
-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.
-
-Note that on the Nexus S, Nexus S 4G, Motorola Xoom, Galaxy Nexus,
-and on Nexus 7,
-all data on the phone is erased, i.e. both the applications' private data
-and the shared data that is accessible over USB, including photos and
-movies. Be sure to make a backup of any precious files you have before
-unlocking the bootloader.
-
-On Nexus One, the operation voids the warranty and is irreversible.
-
-On Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-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 ##
-
-Starting with Ice Cream Sandwich, the Android Open-Source Project can't be used
-from pure source code only, and requires additional hardware-related proprietary
-libraries to run, specifically for hardware graphics acceleration.
-
-Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, and PandaBoard
-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.
-
-There are limited binaries for Nexus One, and none for ADP2 or ADP1.
-
-### Extracting the proprietary binaries ###
-
-Each set of binaries comes as a self-extracting script in a compressed archive.
-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
----------|------------------------------|------------------------
-grouper | android-4.1.1_r4 or master | full_grouper-userdebug
-maguro | android-4.1.1_r4 or master | full_maguro-userdebug
-toro | android-4.1.1_r4 or master | full_toro-userdebug
-panda | master | full_panda-userdebug
-wingray | android-4.1.1_r4 or master | full_wingray-userdebug
-crespo | android-4.1.1_r4 or master | full_crespo-userdebug
-crespo4g | android-4.1.1_r4 or master | full_crespo4g-userdebug
-passion | android-2.3.7_r1 | full_passion-userdebug
-sapphire | android-2.2.3_r1 | full_sapphire-userdebug
-dream | android-2.2.3_r1 | full_dream-userdebug
-
-## 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 7,
-for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju", and CDMA/LTE "mysid"),
-and
-for Nexus S and Nexus S 4G (all variants)
-are available from
-[Google's factory image page](https://developers.google.com/android/nexus/images).
-
-Factory images for the Motorola Xoom are distributed directly by Motorola.
-
-No factory images are available for Nexus One.
diff --git a/src/source/building-dream.jd b/src/source/building-dream.jd
new file mode 100644
index 0000000..b454ba8
--- /dev/null
+++ b/src/source/building-dream.jd
@@ -0,0 +1,62 @@
+page.title=Building for an Android Dev Phone
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p><em>The information on this page is a bit out of date. We'll update this
+page as soon as we can.</em></p>
+<p>The basic manifest for 1.6 defines which projects are
+needed to do a generic build for the emulator or for unlocked Dream devices
+(e.g. the Android Dev Phone 1). You need to have an appropriate device running
+a matching official image.</p>
+<p>To build donut for dream (your
+device needs to be an ADP1 running an official 1.6 system):</p>
+<ol>
+<li>
+<p>Follow the <a href="downloading.html">normal steps</a> to setup repo and check out the sources.</p>
+</li>
+<li>
+<p>At the root of your source tree, run <code>. build/envsetup.sh</code> like you normally would for an emulator build.</p>
+</li>
+<li>
+<p>Run <code>make adb</code> if you don't already have adb in your path.</p>
+</li>
+<li>
+<p>run <code>adb root</code>.</p>
+</li>
+<li>
+<p>in <code>vendor/htc/dream-open/</code> there is a script called "extract-files.sh" that must be run (from that directory) to extract some proprietary binaries from your device (*). You only need to do this once.</p>
+</li>
+<li>
+<p>run <code>lunch aosp_dream_us-eng</code> to specifically configure the build system for dream (the default is the equivalent of "lunch generic-eng", which doesn't contain dream-specific files).</p>
+</li>
+<li>
+<p>run make from the top of the source tree.</p>
+</li>
+<li>
+<p>from this point, the fastboot tool (which is put automatically in your path) can be used to flash a device: boot the device into the bootloader by holding the back key while pressing the power key, and run <code>fastboot -w flashall</code>.</p>
+</li>
+</ol>
+<p>Note: these instructions work for the sapphire (ADP2) build target, as
+well. Simply replace "dream" with "sapphire" above.</p>
\ No newline at end of file
diff --git a/src/source/building-dream.md b/src/source/building-dream.md
deleted file mode 100644
index 74f7521..0000000
--- a/src/source/building-dream.md
+++ /dev/null
@@ -1,48 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building for an Android Dev Phone #
-
-*The information on this page is a bit out of date. We'll update this
-page as soon as we can.*
-
-The basic manifest for 1.6 defines which projects are
-needed to do a generic build for the emulator or for unlocked Dream devices
-(e.g. the Android Dev Phone 1). You need to have an appropriate device running
-a matching official image.
-
-To build donut for dream (your
-device needs to be an ADP1 running an official 1.6 system):
-
-1. Follow the [normal steps](downloading.html) to setup repo and check out the sources.
-
-2. At the root of your source tree, run `. build/envsetup.sh` like you normally would for an emulator build.
-
-3. Run `make adb` if you don't already have adb in your path.
-
-4. run `adb root`.
-
-5. in `vendor/htc/dream-open/` there is a script called "extract-files.sh" that must be run (from that directory) to extract some proprietary binaries from your device (*). You only need to do this once.
-
-6. run `lunch aosp_dream_us-eng` to specifically configure the build system for dream (the default is the equivalent of "lunch generic-eng", which doesn't contain dream-specific files).
-
-7. run make from the top of the source tree.
-
-8. from this point, the fastboot tool (which is put automatically in your path) can be used to flash a device: boot the device into the bootloader by holding the back key while pressing the power key, and run `fastboot -w flashall`.
-
-Note: these instructions work for the sapphire (ADP2) build target, as
-well. Simply replace "dream" with "sapphire" above.
-
diff --git a/src/source/building-kernels.jd b/src/source/building-kernels.jd
new file mode 100644
index 0000000..0b20a50
--- /dev/null
+++ b/src/source/building-kernels.jd
@@ -0,0 +1,95 @@
+page.title=Building Kernels
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>If you are only interested in the kernel, you may use this guide
+to download and build the appropriate kernel.</p>
+<p>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.</p>
+<p>We will use the Pandaboard kernel in all the following examples.</p>
+<h2 id="figuring-out-which-kernel-to-build">Figuring out which kernel to build</h2>
+<p>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>.</p>
+<pre><code>$ git clone https://android.googlesource.com/device/ti/panda
+$ cd panda
+$ git log kernel
+</code></pre>
+<p>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.</p>
+<h2 id="downloading-sources">Downloading sources</h2>
+<p>Depending on which kernel you want,</p>
+<pre><code>$ 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
+</code></pre>
+<ul>
+<li>The <code>goldfish</code> project contains the kernel sources for the emulated
+platforms.</li>
+<li>The <code>msm</code> 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.</li>
+<li>The <code>omap</code> project is used for PandaBoard and Galaxy Nexus,
+and can be used as a starting point for work on TI OMAP chipsets.</li>
+<li>The <code>samsung</code> project is used for Nexus S,
+and can be used as a starting point for work on Samsung Hummingbird chipsets.</li>
+<li>The <code>tegra</code> project is for Xoom and Nexus 7,
+and can be used as a starting point for work on NVIDIA Tegra chipsets.</li>
+<li>The <code>exynos</code> project has the kernel sources for Nexus 10,
+and can be used as a starting point for work on Samsung Exynos chipsets.</li>
+</ul>
+<h2 id="downloading-a-prebuilt-gcc">Downloading a prebuilt gcc</h2>
+<p>Ensure that the prebuilt toolchain is in your path.</p>
+<pre><code>$ git clone https://android.googlesource.com/platform/prebuilt
+$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
+</code></pre>
+<h2 id="building">Building</h2>
+<p>As an example, we would build the panda kernel using the following commands:</p>
+<pre><code>$ export ARCH=arm
+$ export SUBARCH=arm
+$ export CROSS_COMPILE=arm-eabi-
+$ cd omap
+$ git checkout <commit_from_first_step>
+$ make panda_defconfig
+$ make
+</code></pre>
+<p>To build the tuna kernel, you may run the previous commands replacing all
+instances of "panda" with "tuna".</p>
+<ul>
+<li>The kernel for mantaray is <code>device/samsung/manta/kernel</code></li>
+<li>The kernel for mako is <code>device/lge/mako-kernel/kernel</code></li>
+<li>The kernel for grouper and tilapia is <code>device/asus/grouper/kernel</code></li>
+<li>The kernel for maguro and toro is <code>device/samsung/tuna/kernel</code></li>
+<li>The kernel for crespo and crespo4g is <code>device/samsung/crespo/kernel</code></li>
+<li>The kernel for stingray and wingray is <code>device/moto/wingray/kernel</code></li>
+</ul>
+<p>The image is output as <code>arch/arm/boot/zImage</code>. You may copy it as
+<code>device/<vendor>/<name>/kernel</code> or <code>device/ti/panda/kernel</code> in the case of this
+example.</p>
diff --git a/src/source/building-kernels.md b/src/source/building-kernels.md
deleted file mode 100644
index 5c3709d..0000000
--- a/src/source/building-kernels.md
+++ /dev/null
@@ -1,97 +0,0 @@
-<!--
- 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, and
-can be used as a starting point for work on Qualcomm MSM chipsets.
- - The `omap` project is used for PandaBoard and Galaxy Nexus, and
-can be used as a starting point for work on TI OMAP chipsets.
- - The `samsung` project is used for Nexus S and can be used as a
-starting point for work on Samsung Hummingbird chipsets.
- - The `tegra` project is for Xoom and Nexus 7, and can be used as
-a starting point for work on NVIDIA Tegra chipsets.
- - The `exynos` project can be used as a starting point for work
-on Samsung Exynos chipsets.
-
-## 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 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/building-running.jd b/src/source/building-running.jd
new file mode 100644
index 0000000..3fcd457
--- /dev/null
+++ b/src/source/building-running.jd
@@ -0,0 +1,193 @@
+page.title=Building the System
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+The following instructions to build the Android source tree apply to all branches, including master.
+
+<h2 id="choosing-a-branch">Choosing a Branch</h2>
+<p>Some of the requirements for your build environment are determined by which
+version of the source code you plan to compile. See
+<a href="build-numbers.html">Codenames, Tags, and Build Numbers</a> 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.</p>
+<p>Once you have selected a branch, follow the appropriate instructions below to
+set up your build environment.</p>
+
+
+<p>The basic sequence of build commands is as follows:</p>
+<h2 id="initialize">Initialize</h2>
+<p>Initialize the environment with the <code>envsetup.sh</code> script. Note
+that replacing "source" with a single dot saves a few characters,
+and the short form is more commonly used in documentation.</p>
+<pre><code>$ source build/envsetup.sh
+</code></pre>
+<p>or</p>
+<pre><code>$ . build/envsetup.sh
+</code></pre>
+<h2 id="choose-a-target">Choose a Target</h2>
+<p>Choose which target to build with <code>lunch</code>. The exact configuration can be passed as
+an argument, e.g. </p>
+<pre><code>$ lunch full-eng
+</code></pre>
+<p>The example above refers to a complete build for the emulator, with all debugging enabled.</p>
+<p>If run with no arguments <code>lunch</code> will prompt you to choose a target from the menu. </p>
+<p>All build targets take the form BUILD-BUILDTYPE, where the BUILD is a codename
+referring to the particular feature combination. Here's a partial list:</p>
+<table>
+<thead>
+<tr>
+<th>Build name</th>
+<th>Device</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>full</td>
+<td>emulator</td>
+<td>fully configured with all languages, apps, input methods</td>
+</tr>
+<tr>
+<td>full_maguro</td>
+<td>maguro</td>
+<td><code>full</code> build running on Galaxy Nexus GSM/HSPA+ ("maguro")</td>
+</tr>
+<tr>
+<td>full_panda</td>
+<td>panda</td>
+<td><code>full</code> build running on PandaBoard ("panda")</td>
+</tr>
+</tbody>
+</table>
+<p>and the BUILDTYPE is one of the following:</p>
+<table>
+<thead>
+<tr>
+<th>Buildtype</th>
+<th>Use</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>user</td>
+<td>limited access; suited for production</td>
+</tr>
+<tr>
+<td>userdebug</td>
+<td>like "user" but with root access and debuggability; preferred for debugging</td>
+</tr>
+<tr>
+<td>eng</td>
+<td>development configuration with additional debugging tools</td>
+</tr>
+</tbody>
+</table>
+<p>For more information about building for and running on actual hardware, see
+<a href="building-devices.html">Building for Devices</a>.</p>
+<h2 id="build-the-code">Build the Code</h2>
+<p>Build everything with <code>make</code>. GNU make can handle parallel
+tasks with a <code>-jN</code> argument, and it's common to use a number of
+tasks N that's between 1 and 2 times the number of hardware
+threads on the computer being used for the build. E.g. on a
+dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core),
+the fastest builds are made with commands between <code>make -j16</code> and
+<code>make -j32</code>.</p>
+<pre><code>$ make -j4
+</code></pre>
+<h2 id="run-it">Run It!</h2>
+<p>You can either run your build on an emulator or flash it on a device. Please note that you have already selected your build target with <code>lunch</code>, and it is unlikely at best to run on a different target than it was built for.</p>
+<h3 id="flash-a-device">Flash a Device</h3>
+<p>To flash a device, you will need to use <code>fastboot</code>, which should be included in your path after a successful build. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with</p>
+<pre><code>$ adb reboot bootloader
+</code></pre>
+<p>Once the device is in fastboot mode, run </p>
+<pre><code>$ fastboot flashall -w
+</code></pre>
+<p>The <code>-w</code> option wipes the <code>/data</code> partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.</p>
+<p>For more information about building for and running on actual hardware, see
+<a href="building-devices.html">Building for Devices.</a></p>
+<h3 id="emulate-an-android-device">Emulate an Android Device</h3>
+<p>The emulator is added to your path automatically by the build process. To run the emulator, type</p>
+<pre><code>$ emulator
+</code></pre>
+<h1 id="using-ccache">Using ccache</h1>
+<p>ccache is a compiler cache for C and C++ that can help make builds faster.
+In the root of the source tree, do the following:</p>
+<pre><code>$ export USE_CCACHE=1
+$ export CCACHE_DIR=/<path_of_your_choice>/.ccache
+$ prebuilts/misc/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>The suggested cache size is 50-100G.</p>
+<p>You can watch ccache being used by doing the following:</p>
+<pre><code>$ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
+</code></pre>
+<p>On OSX, you should replace <code>linux-x86</code> with <code>darwin-x86</code>.</p>
+<p>When using Ice Cream Sandwich (4.0.x) or older, you should replace
+<code>prebuilts/misc</code> with <code>prebuilt</code>.</p>
+<h1 id="troubleshooting-common-build-errors">Troubleshooting Common Build Errors</h1>
+<h2 id="wrong-java-version">Wrong Java Version</h2>
+<p>If you are attempting to build froyo or earlier with Java 1.6, or gingerbread or later
+with Java 1.5, <code>make</code> will abort with a message such as</p>
+<pre><code>************************************************************
+You are attempting to build with the incorrect version
+of java.
+
+Your version is: WRONG_VERSION.
+The correct version is: RIGHT_VERSION.
+
+Please follow the machine setup instructions at
+ https://source.android.com/source/download.html
+************************************************************
+</code></pre>
+<p>This may be caused by</p>
+<ul>
+<li>
+<p>failing to install the correct JDK as specified in <a href="initializing.html">Initializing the Build Environment</a>. Building Android requires Sun JDK 5 or 6 depending on which release you are building. </p>
+</li>
+<li>
+<p>another JDK that you previously installed appearing in your path. You can remove the offending JDK from your path with:</p>
+<pre><code>$ export PATH=${PATH/\/path\/to\/jdk\/dir:/}
+</code></pre>
+</li>
+</ul>
+<h2 id="python-version-3">Python Version 3</h2>
+<p>Repo is built on particular functionality from Python 2.x and is unfortunately incompatible with Python 3. In order to use repo, please install Python 2.x:</p>
+<pre><code>$ apt-get install python
+</code></pre>
+<h2 id="case-insensitive-filesystem">Case Insensitive Filesystem</h2>
+<p>If you are building on an HFS filesystem on Mac OS X, you may encounter an error such as</p>
+<pre><code>************************************************************
+You are building on a case-insensitive filesystem.
+Please move your source tree to a case-sensitive filesystem.
+************************************************************
+</code></pre>
+<p>Please follow the instructions in <a href="initializing.html">Initializing the Build Environment</a> for creating a case-sensitive disk image.</p>
+<h2 id="no-usb-permission">No USB Permission</h2>
+<p>On most Linux systems, unprivileged users cannot access USB ports by default. If you see a permission denied error, follow the instructions
+<a href="initializing.html">Initializing the Build Environment</a> for configuring USB access. </p>
+<p>If adb was already running and cannot connect to the device after
+getting those rules set up, it can be killed with <code>adb kill-server</code>.
+That will cause adb to restart with the new configuration.</p>
diff --git a/src/source/building.jd b/src/source/building.jd
new file mode 100644
index 0000000..09d7811
--- /dev/null
+++ b/src/source/building.jd
@@ -0,0 +1,60 @@
+page.title=Downloading and Building
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android build is routinely tested in-house on recent versions of
+Ubuntu LTS (10.04), but most distributions should have the required
+build tools available. We welcome reports of successes or failures on other
+distributions.</p>
+
+<p>Before you download and build the Android source, ensure your system meets the following requirements:</p>
+
+<ul>
+
+ <li>A Linux or Mac system. It is also possible
+ to build Android in a virtual machine on unsupported systems such as Windows.
+ If you are running Linux in a virtual machine, you need at
+ least 16GB of RAM/swap and 30GB or more of disk space in order to
+ build the Android tree.
+ </li>
+
+ <li>A 64-bit environment is required for Gingerbread (2.3.x) and newer versions, including the master
+ branch. You can compile older versions on 32-bit systems.
+ </li>
+
+ <li>30GB of free disk space to complete a single build and
+ up to 100GB or more for a full set of builds. The source download is approximately 8.5GB in size.</p>
+ </li>
+
+ <li>
+ Python 2.6 -- 2.7, which you can download from <a href="http://www.python.org/download/">python.org</a>.</p>
+ </li>
+
+ <li>
+ GNU Make 3.81 -- 3.82, which you can download from <a href="http://ftp.gnu.org/gnu/make/">gnu.org</a>,</p>
+ </li>
+
+ <li>
+ JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older.
+ You can download both from <a href="http://java.sun.com/javase/downloads/">java.sun.com</a>.</p>
+ </li>
+
+ <li>
+ Git 1.7 or newer. You can find it at <a href="http://git-scm.com/download">git-scm.com</a>.</p>
+ </li>
+
+</ul>
\ No newline at end of file
diff --git a/src/source/building.md b/src/source/building.md
deleted file mode 100644
index e2de012..0000000
--- a/src/source/building.md
+++ /dev/null
@@ -1,171 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building the System #
-
-The basic sequence of build commands is as follows:
-
-## Initialize ##
-
-Initialize the environment with the `envsetup.sh` script. Note
-that replacing "source" with a single dot saves a few characters,
-and the short form is more commonly used in documentation.
-
- $ source build/envsetup.sh
-
-or
-
- $ . build/envsetup.sh
-
-## Choose a Target ##
-
-Choose which target to build with `lunch`. The exact configuration can be passed as
-an argument, e.g.
-
- $ lunch full-eng
-
-The example above refers to a complete build for the emulator, with all debugging enabled.
-
-If run with no arguments `lunch` will prompt you to choose a target from the menu.
-
-All build targets take the form BUILD-BUILDTYPE, where the BUILD is a codename
-referring to the particular feature combination. Here's a partial list:
-
-Build name | Device | Notes
-------------|----------|---------------------------
-full | emulator | fully configured with all languages, apps, input methods
-full_maguro | maguro | `full` build running on Galaxy Nexus GSM/HSPA+ ("maguro")
-full_panda | panda | `full` build running on PandaBoard ("panda")
-
-and the BUILDTYPE is one of the following:
-
-Buildtype | Use
-------------|--------------------------------------
-user | limited access; suited for production
-userdebug | like "user" but with root access and debuggability; preferred for debugging
-eng | development configuration with additional debugging tools
-
-For more information about building for and running on actual hardware, see
-[Building for devices](building-devices.html)
-
-## Build the Code ##
-
-Build everything with `make`. GNU make can handle parallel
-tasks with a `-jN` argument, and it's common to use a number of
-tasks N that's between 1 and 2 times the number of hardware
-threads on the computer being used for the build. E.g. on a
-dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core),
-the fastest builds are made with commands between `make -j16` and
-`make -j32`.
-
- $ make -j4
-
-## Run It! ##
-
-You can either run your build on an emulator or flash it on a device. Please note that you have already selected your build target with `lunch`, and it is unlikely at best to run on a different target than it was built for.
-
-### Flash a Device ###
-
-To flash a device, you will need to use `fastboot`, which should be included in your path after a successful build. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with
-
- $ adb reboot bootloader
-
-Once the device is in fastboot mode, run
-
- $ fastboot flashall -w
-
-The `-w` option wipes the `/data` partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.
-
-For more information about building for and running on actual hardware, see
-[Building for devices](building-devices.html)
-
-### Emulate an Android Device ###
-
-The emulator is added to your path automatically by the build process. To run the emulator, type
-
- $ emulator
-
-# Using ccache #
-
-ccache is a compiler cache for C and C++ that can help make builds faster.
-In the root of the source tree, do the following:
-
- $ export USE_CCACHE=1
- $ export CCACHE_DIR=/<path_of_your_choice>/.ccache
- $ prebuilts/misc/linux-x86/ccache/ccache -M 50G
-
-The suggested cache size is 50-100G.
-
-You can watch ccache being used by doing the following:
-
- $ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
-
-On OSX, you should replace `linux-x86` with `darwin-x86`.
-
-When using Ice Cream Sandwich (4.0.x) or older, you should replace
-`prebuilts/misc` with `prebuilt`.
-
-# Troubleshooting Common Build Errors #
-
-## Wrong Java Version ##
-
-If you are attempting to build froyo or earlier with Java 1.6, or gingerbread or later
-with Java 1.5, `make` will abort with a message such as
-
- ************************************************************
- You are attempting to build with the incorrect version
- of java.
-
- Your version is: WRONG_VERSION.
- The correct version is: RIGHT_VERSION.
-
- Please follow the machine setup instructions at
- https://source.android.com/source/download.html
- ************************************************************
-
-This may be caused by
-
-- failing to install the correct JDK as specified on the [Initializing](initializing.html) page. Building Android requires Sun JDK 5 or 6 depending on which release you are building.
-
-- another JDK that you previously installed appearing in your path. You can remove the offending JDK from your path with:
-
- $ export PATH=${PATH/\/path\/to\/jdk\/dir:/}
-
-## Python Version 3 ##
-
-Repo is built on particular functionality from Python 2.x and is unfortunately incompatible with Python 3. In order to use repo, please install Python 2.x:
-
- $ apt-get install python
-
-## Case Insensitive Filesystem ##
-
-If you are building on an HFS filesystem on Mac OS X, you may encounter an error such as
-
- ************************************************************
- You are building on a case-insensitive filesystem.
- Please move your source tree to a case-sensitive filesystem.
- ************************************************************
-
-Please follow the instructions on the [Initializing](initializing.html) page for creating a case-sensitive disk image.
-
-## No USB Permission ##
-
-On most Linux systems, unprivileged users cannot access USB ports by default. If you see a permission denied error, follow the instructions on the [Initializing](initializing.html) page for configuring USB access.
-
-If adb was already running and cannot connect to the device after
-getting those rules set up, it can be killed with `adb kill-server`.
-That will cause adb to restart with the new configuration.
-
diff --git a/src/source/cla-corporate.jd b/src/source/cla-corporate.jd
new file mode 100644
index 0000000..9125a0c
--- /dev/null
+++ b/src/source/cla-corporate.jd
@@ -0,0 +1,81 @@
+page.title=Corporate Contributor License Agreement
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose.</p>
+<p>This version of the Grant allows an entity (the "Corporation") to submit Contributions to the Project Leads, to authorize Contributions submitted by its designated employees to the Project Leads, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Grant to</p>
+<blockquote>
+ Google Inc.<br/>
+ Attn: Open Source Program Office<br/>
+ 1600 Amphitheatre Pkwy<br/>
+ Building 43<br/>
+ Mountain View, CA 94043<br/>
+ U.S.A.
+</blockquote>
+
+<p>Scanned agreements may also be emailed in PDF form to cla-submissions@google.com.</p>
+<p>If necessary, you may send it by facsimile to (650) 887-1625. Please read this document carefully before signing and keep a copy for your records.</p>
+<pre>Corporation name: ___________________________________________________<br><br><br><br>Corporation address: ________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>Point of Contact: ___________________________________________________<br><br><br><br>E-Mail: ____________________________________________________________<br><br><br><br>Telephone: _____________________<br><br><br><br>Fax: ___________________________<br><br></pre>
+
+<p>You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.</p>
+<ol>
+<li>
+<p>Definitions.</p>
+<p>"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant to the Project Leads. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.</p>
+<p>"Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."</p>
+</li>
+<li>
+<p>Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.</p>
+</li>
+<li>
+<p>Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.</p>
+</li>
+<li>
+<p>You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.</p>
+</li>
+<li>
+<p>You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).</p>
+</li>
+<li>
+<p>You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.</p>
+</li>
+<li>
+<p>Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p></p>
+</li>
+<li>
+<p>It is your responsibility to notify the Project Leads when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with the Project.</p>
+</li>
+</ol>
+<pre>
+<br><br>
+Please sign: __________________________________ Date: _______________<br><br>
+Title: _______________________________________________________________<br><br>
+Corporation: __________________________________________________________
+</pre>
+
+<h3 id="schedule-a">Schedule A</h3>
+<p>[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]</p>
+<h3 id="schedule-b">Schedule B</h3>
+<p>[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]</p>
diff --git a/src/source/cla-corporate.md b/src/source/cla-corporate.md
deleted file mode 100644
index ffc193f..0000000
--- a/src/source/cla-corporate.md
+++ /dev/null
@@ -1,74 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Corporate Contributor License Agreement #
-
-In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose.
-
-This version of the Grant allows an entity (the "Corporation") to submit Contributions to the Project Leads, to authorize Contributions submitted by its designated employees to the Project Leads, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Grant to
-
-<blockquote>
- Google Inc.<br/>
- Attn: Open Source Program Office<br/>
- 1600 Amphitheatre Pkwy<br/>
- Building 43<br/>
- Mountain View, CA 94043<br/>
- U.S.A.
-</blockquote>
-
-Scanned agreements may also be emailed in PDF form to cla-submissions@google.com.
-
-If necessary, you may send it by facsimile to (650) 887-1625. Please read this document carefully before signing and keep a copy for your records.
-
-<pre>Corporation name: ___________________________________________________<br><br><br><br>Corporation address: ________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>Point of Contact: ___________________________________________________<br><br><br><br>E-Mail: ____________________________________________________________<br><br><br><br>Telephone: _____________________<br><br><br><br>Fax: ___________________________<br><br></pre>
-
-You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.
-
-1. Definitions.
-
- "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant to the Project Leads. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
-
- "Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
-
-1. Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
-
-1. Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.
-
-1. You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.
-
-1. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).
-
-1. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
-
-1. Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p>
-
-1. It is your responsibility to notify the Project Leads when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with the Project.
-
-<pre>
-<br><br>
-Please sign: __________________________________ Date: _______________<br><br>
-Title: _______________________________________________________________<br><br>
-Corporation: __________________________________________________________
-</pre>
-
-### Schedule A ###
-
-[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]
-
-### Schedule B ###
-
-[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]
-
diff --git a/src/source/cla-individual.jd b/src/source/cla-individual.jd
new file mode 100644
index 0000000..27f32cf
--- /dev/null
+++ b/src/source/cla-individual.jd
@@ -0,0 +1,63 @@
+page.title=Contributor License Agreement for Individuals
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p><em>Please visit the <a href="https://android-review.googlesource.com/#/settings/new-agreement">code review tool</a>
+to execute the grant online.This page provides the text of the Individual Contributor License Grant for your quick review.</em></p>
+<p>In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Grant to</p>
+<blockquote>
+ Google Inc.<br/>
+ Attn: Open Source Program Office<br/>
+ 1600 Amphitheatre Pkwy<br/>
+ Building 43<br/>
+ Mountain View, CA 94043<br/>
+ U.S.A.
+</blockquote>
+
+<p>Scanned agreements may also be emailed in PDF form to
+cla-submissions@google.com, sent by facsimile to (650) 887-1625, or
+<a href="https://android-review.googlesource.com/#/settings/new-agreement">signed electronically</a>.</p>
+<p>Please read this document carefully before signing and keep a copy for your records.</p>
+<pre>
+<br><br>
+Full name: ____________________________ E-Mail: ______________________<br><br>
+Mailing Address: ______________________ Telephone: ___________________<br><br>
+_______________________________________ Facsimile: ___________________<br><br>
+_______________________________________ Country: ___________________
+</pre>
+
+<p>You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.</p>
+<ol>
+<li>
+<p>Definitions. </p>
+<p>"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."</p>
+</li>
+<li>
+<p>Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.</p>
+</li>
+<li>
+<p>Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.</p>
+</li>
+<li>
+<p>You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project Leads, or that your employer has executed a separate Corporate Contributor License Grant with the Project Leads.</p>
+</li>
+<li>
+<p>You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.</p>
+</li>
+<li>
+<p>You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.</p>
+</li>
+<li>
+<p>Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p></p>
+</li>
+<li>
+<p>You agree to notify the Project Leads of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.</p>
+</li>
+</ol>
diff --git a/src/source/cla-individual.md b/src/source/cla-individual.md
deleted file mode 100644
index 34a1c28..0000000
--- a/src/source/cla-individual.md
+++ /dev/null
@@ -1,66 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Contributor License Agreement for Individuals #
-
-*Please visit the [code review tool](https://android-review.googlesource.com/#/settings/new-agreement)
-to execute the grant online.This page provides the text of the Individual Contributor License Grant for your quick review.*
-
-In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Grant to
-
-<blockquote>
- Google Inc.<br/>
- Attn: Open Source Program Office<br/>
- 1600 Amphitheatre Pkwy<br/>
- Building 43<br/>
- Mountain View, CA 94043<br/>
- U.S.A.
-</blockquote>
-
-Scanned agreements may also be emailed in PDF form to
-cla-submissions@google.com, sent by facsimile to (650) 887-1625, or
-[signed electronically](https://android-review.googlesource.com/#/settings/new-agreement).
-
-Please read this document carefully before signing and keep a copy for your records.
-
-<pre>
-<br><br>
-Full name: ____________________________ E-Mail: ______________________<br><br>
-Mailing Address: ______________________ Telephone: ___________________<br><br>
-_______________________________________ Facsimile: ___________________<br><br>
-_______________________________________ Country: ___________________
-</pre>
-
-You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.
-
-1. Definitions.
-
- "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
-
-1. Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
-
-1. Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.
-
-1. You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project Leads, or that your employer has executed a separate Corporate Contributor License Grant with the Project Leads.
-
-1. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
-
-1. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
-
-1. Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p>
-
-1. You agree to notify the Project Leads of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
-
diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd
new file mode 100644
index 0000000..e37e0cc
--- /dev/null
+++ b/src/source/code-lines.jd
@@ -0,0 +1,191 @@
+page.title=Codelines, Branches, and Releases
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The Android Open Source Project maintains a complete software stack intended to be ported by
+ OEMs and other device implementors to run on actual hardware. To maintain the quality of
+ Android, Google has contributed full-time engineers, product managers, UI designers, Quality
+ Assurance, and all the other roles required to bring modern devices to market.
+</p>
+
+<p>
+ Accordingly, we maintain a number of "code lines" to clearly separate the current stable
+ version of Android from unstable experimental work. We roll the open source administration
+ and maintenance of the Android code lines into the larger product development cycle.
+</p>
+
+<p>
+ The chart below depicts at a conceptual level how AOSP manages code and releases. We're
+ referring to these as "code lines" instead of "branches" simply because at any given moment
+ there may be more than one branch extant for a given "code line". For instance, when a
+ release is cut, sometimes that will become a new branch in git, and sometimes not, based on
+ the needs of the moment.
+</p>
+<ul>
+ <li>
+ <p>
+ At any given moment, there is a current latest release of the Android platform. This
+ typically takes the form of a branch in the tree.
+ </p>
+ </li>
+ <li>
+ <p>
+ Device builders and contributors work with the current latest release, fixing bugs,
+ launching new devices, experimenting with new features, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ In parallel, Google works internally on the next version of the Android platform and
+ framework, working according to the product's needs and goals. We develop the next
+ version of Android by working with a device partner on a flagship device whose
+ specifications are chosen to push Android in the direction we believe it should go.
+ </p>
+ </li>
+ <li>
+ <p>
+ When the "n+1"th version is ready, it will be published to the public source tree, and
+ become the new latest release.
+ </p>
+ </li>
+</ul>
+<p>
+ <img src="{@docRoot}images/code-lines.png" alt="code-line diagram">
+</p>
+
+<h2 id="notes-and-explanations">
+ Notes and Explanations
+</h2>
+<ul>
+ <li>
+ <p>
+ A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5,
+ 2.1, and so on. Generally speaking, a release of the platform corresponds to a version of
+ the <code>SdkVersion</code> field used in AndroidManifest.xml files, and defined in
+ <code>frameworks/base/api</code> in the source tree.
+ </p>
+ </li>
+ <li>
+ <p>
+ An <em>upstream</em> project is an open-source project from which the Android stack is
+ pulling code. These include obvious projects such as the Linux kernel and WebKit, but
+ over time we are migrating some of the semi-autonomous Android projects (such as Dalvik,
+ the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally,
+ these projects are developed entirely in the public tree. For some upstream projects,
+ development is done by contributing directly to the upstream project itself. See <a href=
+ "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases,
+ snapshots will be periodically pulled into releases.
+ </p>
+ </li>
+ <li>
+ <p>
+ The diagram refers to "Eclair" and "FroYo"; however, they are simply placeholders, and
+ the diagram actually reflects the overall release and branching strategy.
+ </p>
+ </li>
+ <li>
+ <p>
+ At all times, a release code-line (which may actually consist of more than one actual
+ branch in git) is considered the sole canonical source code for a given Android platform
+ version. OEMs and other groups building devices should pull only from a release branch.
+ </p>
+ </li>
+ <li>
+ <p>
+ We will set up "experimental" code-lines to capture changes from the community, so that
+ they can be iterated on, with an eye toward stability.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes that prove stable will eventually be pulled into a release branch. Note that this
+ will only apply to bug fixes, app improvements, and other things that do not affect the
+ APIs of the platform.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled into release branches from upstream projects (including the
+ Android "upstream" projects) as necessary.
+ </p>
+ </li>
+ <li>
+ <p>
+ The "n+1"th version (that is, next major version of the framework and platform APIs) will
+ be developed by Google internally. See below for details.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled from upstream, release, and experimental branches into Google's
+ private branch as necessary.
+ </p>
+ </li>
+ <li>
+ <p>
+ When the platform APIs for the next version have stabilized and been fully tested, Google
+ will cut a release of the next platform version. (This specifically refers to a new
+ <code>SdkVersion</code>.) This will also correspond to the internal code-line being made
+ a public release branch, and the new current platform code-line.
+ </p>
+ </li>
+ <li>
+ <p>
+ When a new platform version is cut, a corresponding experimental code-line will be
+ created at the same time.
+ </p>
+ </li>
+</ul>
+
+<h2 id="about-private-code-lines">
+ About Private Codelines
+</h2>
+<p>
+ The source management strategy above includes a code-line that Google will keep private. The
+ reason for this is to focus attention on the current public version of Android.
+</p>
+<p>
+ OEMs and other device builders naturally want to ship devices with the latest version of
+ Android. Similarly, application developers don't want to deal with more extant platform
+ versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
+ direction of Android as a platform and a product. Our approach is based on focusing on a
+ small number of flagship devices to drive features, and secure protections of Android-related
+ intellectual property.
+</p>
+<p>
+ As a result, Google frequently has possession of confidential information of third parties,
+ and we must refrain from revealing sensitive features until we've secured the appropriate
+ protections. Meanwhile, there are real risks to the platform arising from having too many
+ platform versions extant at once. For these reasons, we have structured the open-source
+ project -- including third-party contributions -- to focus on the currently-public stable
+ version of Android. "Deep development" on the next version of the platform will happen in
+ private, until it's ready to become an official release.
+</p>
+<p>
+ We recognize that many contributors will disagree with this approach. We respect that others
+ may have a different point of view; however, this is the approach that we feel is best, and
+ the one we've chosen to implement.
+</p>
\ No newline at end of file
diff --git a/src/source/code-lines.md b/src/source/code-lines.md
deleted file mode 100644
index 8b268f2..0000000
--- a/src/source/code-lines.md
+++ /dev/null
@@ -1,113 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Code-Lines #
-
-The Android Open Source Project maintains a complete software stack intended
-to be ported by OEMs and other device implementors to run on actual hardware.
-Accordingly, we maintain a number of "code lines" to clearly separate the
-current stable version of Android from unstable experimental work.
-
-The chart below depicts at a conceptual level how AOSP manages code and
-releases. We're referring to these as "code lines" instead of "branches"
-simply because at any given moment there may be more than one branch extant
-for a given "code line". For instance, when a release is cut, sometimes that
-will become a new branch in git, and sometimes not, based on the needs of the
-moment.
-
-<img src="/images/code-lines.png" alt="code-line diagram"/>
-
-## Notes and Explanations ##
-
-- A *release* corresponds to a formal version of the Android platform, such
-as 1.5, 2.1, and so on. Generally speaking, a release of the platform
-corresponds to a version of the `SdkVersion` field used in
-AndroidManifest.xml files, and defined in `frameworks/base/api` in
-the source tree.
-
-- An *upstream* project is an open-source project from which the Android
-stack is pulling code. These include obvious projects such as the Linux kernel
-and WebKit, but over time we are migrating some of the semi-autonomous
-Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to
-work as "upstream" projects. Generally, these projects are developed entirely in
-the public tree. For some upstream projects, development is done by contributing
-directly to the upstream project itself. See [Upstream Projects](submit-patches.html#upstream-projects)
-for details. In both cases, snapshots will be periodically pulled into releases.
-
-- The diagram refers to "Eclair" and "FroYo"; however, they are simply
-placeholders, and the diagram actually reflects the overall release and
-branching strategy.
-
-- At all times, a release code-line (which may actually consist of
-more than one actual branch in git) is considered the sole canonical source
-code for a given Android platform version. OEMs and other groups building devices
-should pull only from a release branch.
-
-- We will set up "experimental" code-lines to capture changes from
-the community, so that they can be iterated on, with an eye toward stability.
-
-- Changes that prove stable will eventually be pulled into a release
-branch. Note that this will only apply to bug fixes, app improvements, and
-other things that do not affect the APIs of the platform.
-
-- Changes will be pulled into release branches from upstream projects
-(including the Android "upstream" projects) as necessary.
-
-- The "n+1"th version (that is, next major version of the framework and
-platform APIs) will be developed by Google internally. See below for
-details.
-
-- Changes will be pulled from upstream, release, and experimental branches
-into Google's private branch as necessary.
-
-- When the platform APIs for the next version have stabilized and been fully
-tested, Google will cut a release of the next platform version. (This
-specifically refers to a new `SdkVersion`.) This will also
-correspond to the internal code-line being made a public release branch, and the
-new current platform code-line.
-
-- When a new platform version is cut, a corresponding experimental
-code-line will be created at the same time.
-
-## About Private Code-Lines ##
-
-The source management strategy above includes a code-line that Google will
-keep private. The reason for this is to focus attention on the current public
-version of Android.
-
-OEMs and other device builders naturally want to ship devices with the
-latest version of Android. Similarly, application developers don't want to
-deal with more extant platform versions than strictly necessary. Meanwhile,
-Google retains responsibility for the strategic direction of Android as a
-platform and a product. Our approach is based on focusing on a small number of
-flagship devices to drive features, and secure protections of Android-related
-intellectual property.
-
-As a result, Google frequently has possession of confidential
-information of third parties, and we must refrain from revealing sensitive
-features until we've secured the appropriate protections. Meanwhile, there are
-real risks to the platform arising from having too many platform versions
-extant at once. For these reasons, we have structured the open-source project
--- including third-party contributions -- to focus on the currently-public
-stable version of Android. "Deep development" on the next version of the
-platform will happen in private, until it's ready to become an official
-release.
-
-We recognize that many contributors will disagree with this approach. We
-respect that others may have a different point of view; however, this is the
-approach that we feel is best, and the one we've chosen to implement.
-
-
diff --git a/src/source/code-style.jd b/src/source/code-style.jd
new file mode 100644
index 0000000..e371aa7
--- /dev/null
+++ b/src/source/code-style.jd
@@ -0,0 +1,738 @@
+page.title=Code Style Guidelines for Contributors
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>The rules below are not guidelines or recommendations, but strict rules.
+Contributions to Android generally <em>will not be accepted</em> if they do not
+adhere to these rules.</p>
+
+<p>Not all existing code follows these rules, but all new code is expected to.</p>
+
+<h2 id="java-language-rules">Java Language Rules</h2>
+<p>We follow standard Java coding conventions. We add a few rules:</p>
+<h3 id="dont-ignore-exceptions">Don't Ignore Exceptions</h3>
+<p>Sometimes it is tempting to write code that completely ignores an exception
+like this:</p>
+<pre><code>void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) { }
+}
+</code></pre>
+<p>You must never do this. While you may think that your code will never
+encounter this error condition or that it is not important to handle it,
+ignoring exceptions like above creates mines in your code for someone else to
+trip over some day. You must handle every Exception in your code in some
+principled way. The specific handling varies depending on the case.</p>
+<p><em>Anytime somebody has an empty catch clause they should have a
+creepy feeling. There are definitely times when it is actually the correct
+thing to do, but at least you have to think about it. In Java you can't escape
+the creepy feeling.</em> -<a href="http://www.artima.com/intv/solid4.html">James Gosling</a></p>
+<p>Acceptable alternatives (in order of preference) are:</p>
+<ul>
+<li>
+<p>Throw the exception up to the caller of your method.</p>
+<pre><code>void setServerPort(String value) throws NumberFormatException {
+ serverPort = Integer.parseInt(value);
+}
+</code></pre>
+</li>
+<li>
+<p>Throw a new exception that's appropriate to your level of abstraction.</p>
+<pre><code>void setServerPort(String value) throws ConfigurationException {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ throw new ConfigurationException("Port " + value + " is not valid.");
+ }
+}
+</code></pre>
+</li>
+<li>
+<p>Handle the error gracefully and substitute an appropriate value in the
+catch {} block.</p>
+<pre><code>/** Set port. If value is not a valid number, 80 is substituted. */
+
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ serverPort = 80; // default port for server
+ }
+}
+</code></pre>
+</li>
+<li>
+<p>Catch the Exception and throw a new <code>RuntimeException</code>. This is dangerous:
+only do it if you are positive that if this error occurs, the appropriate
+thing to do is crash.</p>
+<pre><code>/** Set port. If value is not a valid number, die. */
+
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ throw new RuntimeException("port " + value " is invalid, ", e);
+ }
+}
+</code></pre>
+<p>Note that the original exception is passed to the constructor for
+RuntimeException. If your code must compile under Java 1.3, you will need to
+omit the exception that is the cause.</p>
+</li>
+<li>
+<p>Last resort: if you are confident that actually ignoring the exception is
+appropriate then you may ignore it, but you must also comment why with a good
+reason:</p>
+<pre><code>/** If value is not a valid number, original port number is used. */
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ // Method is documented to just ignore invalid user input.
+ // serverPort will just be unchanged.
+ }
+}
+</code></pre>
+</li>
+</ul>
+<h3 id="dont-catch-generic-exception">Don't Catch Generic Exception</h3>
+<p>Sometimes it is tempting to be lazy when catching exceptions and do
+something like this:</p>
+<pre><code>try {
+ someComplicatedIOFunction(); // may throw IOException
+ someComplicatedParsingFunction(); // may throw ParsingException
+ someComplicatedSecurityFunction(); // may throw SecurityException
+ // phew, made it all the way
+} catch (Exception e) { // I'll just catch all exceptions
+ handleError(); // with one generic handler!
+}
+</code></pre>
+<p>You should not do this. In almost all cases it is inappropriate to catch
+generic Exception or Throwable, preferably not Throwable, because it includes
+Error exceptions as well. It is very dangerous. It means that Exceptions you
+never expected (including RuntimeExceptions like ClassCastException) end up
+getting caught in application-level error handling. It obscures the failure
+handling properties of your code. It means if someone adds a new type of
+Exception in the code you're calling, the compiler won't help you realize you
+need to handle that error differently. And in most cases you shouldn't be
+handling different types of exception the same way, anyway.</p>
+<p>There are rare exceptions to this rule: certain test code and top-level
+code where you want to catch all kinds of errors (to prevent them from showing
+up in a UI, or to keep a batch job running). In that case you may catch
+generic Exception (or Throwable) and handle the error appropriately. You
+should think very carefully before doing this, though, and put in comments
+explaining why it is safe in this place.</p>
+<p>Alternatives to catching generic Exception:</p>
+<ul>
+<li>
+<p>Catch each exception separately as separate catch blocks after a single
+try. This can be awkward but is still preferable to catching all Exceptions.
+Beware repeating too much code in the catch blocks.</li></p>
+</li>
+<li>
+<p>Refactor your code to have more fine-grained error handling, with multiple
+try blocks. Split up the IO from the parsing, handle errors separately in each
+case.</p>
+</li>
+<li>
+<p>Rethrow the exception. Many times you don't need to catch the exception at
+this level anyway, just let the method throw it.</p>
+</li>
+</ul>
+<p>Remember: exceptions are your friend! When the compiler complains you're
+not catching an exception, don't scowl. Smile: the compiler just made it
+easier for you to catch runtime problems in your code.</p>
+<h3 id="dont-use-finalizers">Don't Use Finalizers</h3>
+<p>Finalizers are a way to have a chunk of code executed
+when an object is garbage collected.</p>
+<p>Pros: can be handy for doing cleanup, particularly of external resources.</p>
+<p>Cons: there are no guarantees as to when a finalizer will be called,
+or even that it will be called at all.</p>
+<p>Decision: we don't use finalizers. In most cases, you can do what
+you need from a finalizer with good exception handling. If you absolutely need
+it, define a close() method (or the like) and document exactly when that
+method needs to be called. See InputStream for an example. In this case it is
+appropriate but not required to print a short log message from the finalizer,
+as long as it is not expected to flood the logs.</p>
+<h3 id="fully-qualify-imports">Fully Qualify Imports</h3>
+<p>When you want to use class Bar from package foo,there
+are two possible ways to import it:</p>
+<ol>
+<li><code>import foo.*;</code></li>
+</ol>
+<p>Pros: Potentially reduces the number of import statements.</p>
+<ol>
+<li><code>import foo.Bar;</code></li>
+</ol>
+<p>Pros: Makes it obvious what classes are actually used. Makes
+code more readable for maintainers. </p>
+<p>Decision: Use the latter for importing all Android code. An explicit
+exception is made for java standard libraries (<code>java.util.*</code>, <code>java.io.*</code>, etc.)
+and unit test code (<code>junit.framework.*</code>)</p>
+<h2 id="java-library-rules">Java Library Rules</h2>
+<p>There are conventions for using Android's Java libraries and tools. In some
+cases, the convention has changed in important ways and older code might use a
+deprecated pattern or library. When working with such code, it's okay to
+continue the existing style (see <a href="#consistency">Consistency</a>). When
+creating new components never use deprecated libraries.</p>
+<h2 id="java-style-rules">Java Style Rules</h2>
+<h3 id="use-javadoc-standard-comments">Use Javadoc Standard Comments</h3>
+<p>Every file should have a copyright statement at the top. Then a package
+statement and import statements should follow, each block separated by a blank
+line. And then there is the class or interface declaration. In the Javadoc
+comments, describe what the class or interface does.</p>
+<pre><code>/*
+ * Copyright (C) 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.
+ */
+
+package com.android.internal.foo;
+
+import android.os.Blah;
+import android.view.Yada;
+
+import java.sql.ResultSet;
+import java.sql.SQLException;
+
+/**
+ * Does X and Y and provides an abstraction for Z.
+ */
+
+public class Foo {
+ ...
+}
+</code></pre>
+<p>Every class and nontrivial public method you write <em>must</em> contain a
+Javadoc comment with at least one sentence describing what the class or method
+does. This sentence should start with a 3rd person descriptive verb.</p>
+<p>Examples:</p>
+<pre><code>/** Returns the correctly rounded positive square root of a double value. */
+static double sqrt(double a) {
+ ...
+}
+</code></pre>
+<p>or</p>
+<pre><code>/**
+ * Constructs a new String by converting the specified array of
+ * bytes using the platform's default character encoding.
+ */
+public String(byte[] bytes) {
+ ...
+}
+</code></pre>
+<p>You do not need to write Javadoc for trivial get and set methods such as
+<code>setFoo()</code> if all your Javadoc would say is "sets Foo". If the method does
+something more complex (such as enforcing a constraint or having an important
+side effect), then you must document it. And if it's not obvious what the
+property "Foo" means, you should document it.</p>
+<p>Every method you write, whether public or otherwise, would benefit from
+Javadoc. Public methods are part of an API and therefore require Javadoc.</p>
+<p>Android does not currently enforce a specific style for writing Javadoc
+comments, but you should follow the
+<a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">Sun Javadoc conventions</a>.</p>
+<h3 id="write-short-methods">Write Short Methods</h3>
+<p>To the extent that it is feasible, methods should be kept small and
+focused. It is, however, recognized that long methods are sometimes
+appropriate, so no hard limit is placed on method length. If a method exceeds
+40 lines or so, think about whether it can be broken up without harming the
+structure of the program.</p>
+<h3 id="define-fields-in-standard-places">Define Fields in Standard Places</h3>
+<p>Fields should be defined either at the top of the file, or immediately before the methods that use them.</p>
+<h3 id="limit-variable-scope">Limit Variable Scope</h3>
+<p>The scope of local variables should be kept to a minimum (<em>Effective
+Java</em> Item 29). By doing so, you increase the readability and
+maintainability of your code and reduce the likelihood of error. Each variable
+should be declared in the innermost block that encloses all uses of the
+variable.</p>
+<p>Local variables should be declared at the point they are first used. Nearly
+every local variable declaration should contain an initializer. If you don't
+yet have enough information to initialize a variable sensibly, you should
+postpone the declaration until you do.</p>
+<p>One exception to this rule concerns try-catch statements. If a variable is
+initialized with the return value of a method that throws a checked exception,
+it must be initialized inside a try block. If the value must be used outside
+of the try block, then it must be declared before the try block, where it
+cannot yet be sensibly initialized:</p>
+<pre><code>// Instantiate class cl, which represents some sort of Set
+Set s = null;
+try {
+ s = (Set) cl.newInstance();
+} catch(IllegalAccessException e) {
+ throw new IllegalArgumentException(cl + " not accessible");
+} catch(InstantiationException e) {
+ throw new IllegalArgumentException(cl + " not instantiable");
+}
+
+// Exercise the set
+s.addAll(Arrays.asList(args));
+</code></pre>
+<p>But even this case can be avoided by encapsulating the try-catch block in a method:</p>
+<pre><code>Set createSet(Class cl) {
+ // Instantiate class cl, which represents some sort of Set
+ try {
+ return (Set) cl.newInstance();
+ } catch(IllegalAccessException e) {
+ throw new IllegalArgumentException(cl + " not accessible");
+ } catch(InstantiationException e) {
+ throw new IllegalArgumentException(cl + " not instantiable");
+ }
+}
+
+...
+
+// Exercise the set
+Set s = createSet(cl);
+s.addAll(Arrays.asList(args));
+</code></pre>
+<p>Loop variables should be declared in the for statement itself unless there
+is a compelling reason to do otherwise:</p>
+<pre><code>for (int i = 0; i n; i++) {
+ doSomething(i);
+}
+</code></pre>
+<p>and</p>
+<pre><code>for (Iterator i = c.iterator(); i.hasNext(); ) {
+ doSomethingElse(i.next());
+}
+</code></pre>
+<h3 id="order-import-statements">Order Import Statements</h3>
+<p>The ordering of import statements is:</p>
+<ol>
+<li>
+<p>Android imports</p>
+</li>
+<li>
+<p>Imports from third parties (<code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>)</p>
+</li>
+<li>
+<p><code>java</code> and <code>javax</code></p>
+</li>
+</ol>
+<p>To exactly match the IDE settings, the imports should be:</p>
+<ul>
+<li>
+<p>Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).</p>
+</li>
+<li>
+<p>There should be a blank line between each major grouping (<code>android</code>, <code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>, <code>java</code>, <code>javax</code>).</p>
+</li>
+</ul>
+<p>Originally there was no style requirement on the ordering. This meant that
+the IDE's were either always changing the ordering, or IDE developers had to
+disable the automatic import management features and maintain the imports by
+hand. This was deemed bad. When java-style was asked, the preferred styles
+were all over the map. It pretty much came down to our needing to "pick an
+ordering and be consistent." So we chose a style, updated the style guide, and
+made the IDEs obey it. We expect that as IDE users work on the code, the
+imports in all of the packages will end up matching this pattern without any
+extra engineering effort.</p>
+<p>This style was chosen such that:</p>
+<ul>
+<li>
+<p>The imports people want to look at first tend to be at the top (<code>android</code>)</p>
+</li>
+<li>
+<p>The imports people want to look at least tend to be at the bottom (<code>java</code>)</p>
+</li>
+<li>
+<p>Humans can easily follow the style</p>
+</li>
+<li>
+<p>IDEs can follow the style</p>
+</li>
+</ul>
+<p>The use and location of static imports have been mildly controversial
+issues. Some people would prefer static imports to be interspersed with the
+remaining imports, some would prefer them reside above or below all other
+imports. Additinally, we have not yet come up with a way to make all IDEs use
+the same ordering.</p>
+<p>Since most people consider this a low priority issue, just use your
+judgement and please be consistent.</p>
+<h3 id="use-spaces-for-indentation">Use Spaces for Indentation</h3>
+<p>We use 4 space indents for blocks. We never use tabs. When in doubt, be
+consistent with code around you.</p>
+<p>We use 8 space indents for line wraps, including function calls and
+assignments. For example, this is correct:</p>
+<pre><code>Instrument i =
+ someLongExpression(that, wouldNotFit, on, one, line);
+</code></pre>
+<p>and this is not correct:</p>
+<pre><code>Instrument i =
+ someLongExpression(that, wouldNotFit, on, one, line);
+</code></pre>
+<h3 id="follow-field-naming-conventions">Follow Field Naming Conventions</h3>
+<ul>
+<li>
+<p>Non-public, non-static field names start with m.</p>
+</li>
+<li>
+<p>Static field names start with s.</p>
+</li>
+<li>
+<p>Other fields start with a lower case letter.</p>
+</li>
+<li>
+<p>Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.</p>
+</li>
+</ul>
+<p>For example:</p>
+<pre><code>public class MyClass {
+ public static final int SOME_CONSTANT = 42;
+ public int publicField;
+ private static MyClass sSingleton;
+ int mPackagePrivate;
+ private int mPrivate;
+ protected int mProtected;
+}
+</code></pre>
+<h3 id="use-standard-brace-style">Use Standard Brace Style</h3>
+<p>Braces do not go on their own line; they go on the same line as the code
+before them. So:</p>
+<pre><code>class MyClass {
+ int func() {
+ if (something) {
+ // ...
+ } else if (somethingElse) {
+ // ...
+ } else {
+ // ...
+ }
+ }
+}
+</code></pre>
+<p>We require braces around the statements for a conditional. Except, if the
+entire conditional (the condition and the body) fit on one line, you may (but
+are not obligated to) put it all on one line. That is, this is legal:</p>
+<pre><code>if (condition) {
+ body();
+}
+</code></pre>
+<p>and this is legal:</p>
+<pre><code>if (condition) body();
+</code></pre>
+<p>but this is still illegal:</p>
+<pre><code>if (condition)
+ body(); // bad!
+</code></pre>
+<h3 id="limit-line-length">Limit Line Length</h3>
+<p>Each line of text in your code should be at most 100 characters long.</p>
+<p>There has been lots of discussion about this rule and the decision remains
+that 100 characters is the maximum.</p>
+<p>Exception: if a comment line contains an example command or a literal URL
+longer than 100 characters, that line may be longer than 100 characters for
+ease of cut and paste.</p>
+<p>Exception: import lines can go over the limit because humans rarely see
+them. This also simplifies tool writing.</p>
+<h3 id="use-standard-java-annotations">Use Standard Java Annotations</h3>
+<p>Annotations should precede other modifiers for the same language element.
+Simple marker annotations (e.g. @Override) can be listed on the same line with
+the language element. If there are multiple annotations, or parameterized
+annotations, they should each be listed one-per-line in alphabetical
+order.<</p>
+<p>Android standard practices for the three predefined annotations in Java are:</p>
+<ul>
+<li>
+<p><code>@Deprecated</code>: The @Deprecated annotation must be used whenever the use of the annotated
+element is discouraged. If you use the @Deprecated annotation, you must also
+have a @deprecated Javadoc tag and it should name an alternate implementation.
+In addition, remember that a @Deprecated method is <em>still supposed to
+work.</em></p>
+<p>If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.</p>
+</li>
+<li>
+<p><code>@Override</code>: The @Override annotation must be used whenever a method overrides the
+declaration or implementation from a super-class.</p>
+<p>For example, if you use the @inheritdocs Javadoc tag, and derive from a
+class (not an interface), you must also annotate that the method @Overrides
+the parent class's method.</p>
+</li>
+<li>
+<p><code>@SuppressWarnings</code>: The @SuppressWarnings annotation should only be used under circumstances
+where it is impossible to eliminate a warning. If a warning passes this
+"impossible to eliminate" test, the @SuppressWarnings annotation <em>must</em> be
+used, so as to ensure that all warnings reflect actual problems in the
+code.</p>
+<p>When a @SuppressWarnings annotation is necessary, it must be prefixed with
+a TODO comment that explains the "impossible to eliminate" condition. This
+will normally identify an offending class that has an awkward interface. For
+example:</p>
+<pre><code>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
+@SuppressWarnings("generic-cast")
+List<String> blix = Utility.rotate(blax);
+</code></pre>
+<p>When a @SuppressWarnings annotation is required, the code should be
+refactored to isolate the software elements where the annotation applies.</p>
+</li>
+</ul>
+<h3 id="treat-acronyms-as-words">Treat Acronyms as Words</h3>
+<p>Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable:</p>
+<table>
+<thead>
+<tr>
+<th>Good</th>
+<th>Bad</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>XmlHttpRequest</td>
+<td>XMLHTTPRequest</td>
+</tr>
+<tr>
+<td>getCustomerId</td>
+<td>getCustomerID</td>
+</tr>
+<tr>
+<td>class Html</td>
+<td>class HTML</td>
+</tr>
+<tr>
+<td>String url</td>
+<td>String URL</td>
+</tr>
+<tr>
+<td>long id</td>
+<td>long ID</td>
+</tr>
+</tbody>
+</table>
+<p>Both the JDK and the Android code bases are very inconsistent with regards
+to acronyms, therefore, it is virtually impossible to be consistent with the
+code around you. Bite the bullet, and treat acronyms as words.</p>
+<p>For further justifications of this style rule, see <em>Effective Java</em>
+Item 38 and <em>Java Puzzlers</em> Number 68.</p>
+<h3 id="use-todo-comments">Use TODO Comments</h3>
+<p>Use TODO comments for code that is temporary, a short-term solution, or
+good-enough but not perfect.</p>
+<p>TODOs should include the string TODO in all caps, followed by a colon:</p>
+<pre><code>// TODO: Remove this code after the UrlTable2 has been checked in.
+</code></pre>
+<p>and</p>
+<pre><code>// TODO: Change this to use a flag instead of a constant.
+</code></pre>
+<p>If your TODO is of the form "At a future date do something" make sure that
+you either include a very specific date ("Fix by November 2005") or a very
+specific event ("Remove this code after all production mixers understand
+protocol V7.").</p>
+<h3 id="log-sparingly">Log Sparingly</h3>
+<p>While logging is necessary it has a significantly negative impact on
+performance and quickly loses its usefulness if it's not kept reasonably
+terse. The logging facilities provides five different levels of logging. Below
+are the different levels and when and how they should be used.</p>
+<ul>
+<li>
+<p><code>ERROR</code>:
+This level of logging should be used when something fatal has happened,
+i.e. something that will have user-visible consequences and won't be
+recoverable without explicitly deleting some data, uninstalling applications,
+wiping the data partitions or reflashing the entire phone (or worse). This
+level is always logged. Issues that justify some logging at the ERROR level
+are typically good candidates to be reported to a statistics-gathering
+server.</p>
+</li>
+<li>
+<p><code>WARNING</code>:
+This level of logging should used when something serious and unexpected
+happened, i.e. something that will have user-visible consequences but is
+likely to be recoverable without data loss by performing some explicit action,
+ranging from waiting or restarting an app all the way to re-downloading a new
+version of an application or rebooting the device. This level is always
+logged. Issues that justify some logging at the WARNING level might also be
+considered for reporting to a statistics-gathering server.</p>
+</li>
+<li>
+<p><code>INFORMATIVE:</code>
+This level of logging should used be to note that something interesting to
+most people happened, i.e. when a situation is detected that is likely to have
+widespread impact, though isn't necessarily an error. Such a condition should
+only be logged by a module that reasonably believes that it is the most
+authoritative in that domain (to avoid duplicate logging by non-authoritative
+components). This level is always logged.</p>
+</li>
+<li>
+<p><code>DEBUG</code>:
+This level of logging should be used to further note what is happening on the
+device that could be relevant to investigate and debug unexpected behaviors.
+You should log only what is needed to gather enough information about what is
+going on about your component. If your debug logs are dominating the log then
+you probably should be using verbose logging. </p>
+<p>This level will be logged, even
+on release builds, and is required to be surrounded by an <code>if (LOCAL_LOG)</code> or <code>if
+(LOCAL_LOGD)</code> block, where <code>LOCAL_LOG[D]</code> is defined in your class or
+subcomponent, so that there can exist a possibility to disable all such
+logging. There must therefore be no active logic in an <code>if (LOCAL_LOG)</code> block.
+All the string building for the log also needs to be placed inside the <code>if
+(LOCAL_LOG)</code> block. The logging call should not be re-factored out into a
+method call if it is going to cause the string building to take place outside
+of the <code>if (LOCAL_LOG)</code> block. </p>
+<p>There is some code that still says <code>if
+(localLOGV)</code>. This is considered acceptable as well, although the name is
+nonstandard.</p>
+</li>
+<li>
+<p><code>VERBOSE</code>:
+This level of logging should be used for everything else. This level will only
+be logged on debug builds and should be surrounded by an <code>if (LOCAL_LOGV)</code> block
+(or equivalent) so that it can be compiled out by default. Any string building
+will be stripped out of release builds and needs to appear inside the <code>if (LOCAL_LOGV)</code> block.</p>
+</li>
+</ul>
+<p><em>Notes:</em> </p>
+<ul>
+<li>
+<p>Within a given module, other than at the VERBOSE level, an
+error should only be reported once if possible: within a single chain of
+function calls within a module, only the innermost function should return the
+error, and callers in the same module should only add some logging if that
+significantly helps to isolate the issue.</p>
+</li>
+<li>
+<p>In a chain of modules, other than at the VERBOSE level, when a
+lower-level module detects invalid data coming from a higher-level module, the
+lower-level module should only log this situation to the DEBUG log, and only
+if logging provides information that is not otherwise available to the caller.
+Specifically, there is no need to log situations where an exception is thrown
+(the exception should contain all the relevant information), or where the only
+information being logged is contained in an error code. This is especially
+important in the interaction between the framework and applications, and
+conditions caused by third-party applications that are properly handled by the
+framework should not trigger logging higher than the DEBUG level. The only
+situations that should trigger logging at the INFORMATIVE level or higher is
+when a module or application detects an error at its own level or coming from
+a lower level.</p>
+</li>
+<li>
+<p>When a condition that would normally justify some logging is
+likely to occur many times, it can be a good idea to implement some
+rate-limiting mechanism to prevent overflowing the logs with many duplicate
+copies of the same (or very similar) information.</p>
+</li>
+<li>
+<p>Losses of network connectivity are considered common and fully
+expected and should not be logged gratuitously. A loss of network connectivity
+that has consequences within an app should be logged at the DEBUG or VERBOSE
+level (depending on whether the consequences are serious enough and unexpected
+enough to be logged in a release build).</p>
+</li>
+<li>
+<p>A full filesystem on a filesystem that is acceessible to or on
+behalf of third-party applications should not be logged at a level higher than
+INFORMATIVE.</p>
+</li>
+<li>
+<p>Invalid data coming from any untrusted source (including any
+file on shared storage, or data coming through just about any network
+connections) is considered expected and should not trigger any logging at a
+level higher then DEBUG when it's detected to be invalid (and even then
+logging should be as limited as possible).</p>
+</li>
+<li>
+<p>Keep in mind that the <code>+</code> operator, when used on Strings,
+implicitly creates a <code>StringBuilder</code> with the default buffer size (16
+characters) and potentially quite a few other temporary String objects, i.e.
+that explicitly creating StringBuilders isn't more expensive than relying on
+the default '+' operator (and can be a lot more efficient in fact). Also keep
+in mind that code that calls <code>Log.v()</code> is compiled and executed on release
+builds, including building the strings, even if the logs aren't being
+read.</p>
+</li>
+<li>
+<p>Any logging that is meant to be read by other people and to be
+available in release builds should be terse without being cryptic, and should
+be reasonably understandable. This includes all logging up to the DEBUG
+level.</p>
+</li>
+<li>
+<p>When possible, logging should be kept on a single line if it
+makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
+while lengths longer than about 130 or 160 characters (including the length of
+the tag) should be avoided if possible.</p>
+</li>
+<li>
+<p>Logging that reports successes should never be used at levels
+higher than VERBOSE.</p>
+</li>
+<li>
+<p>Temporary logging that is used to diagnose an issue that's
+hard to reproduce should be kept at the DEBUG or VERBOSE level, and should be
+enclosed by if blocks that allow to disable it entirely at compile-time.</p>
+</li>
+<li>
+<p>Be careful about security leaks through the log. Private
+information should be avoided. Information about protected content must
+definitely be avoided. This is especially important when writing framework
+code as it's not easy to know in advance what will and will not be private
+information or protected content.</p>
+</li>
+<li>
+<p><code>System.out.println()</code> (or <code>printf()</code> for native code) should
+never be used. System.out and System.err get redirected to /dev/null, so your
+print statements will have no visible effects. However, all the string
+building that happens for these calls still gets executed.</p>
+</li>
+<li>
+<p><em>The golden rule of logging is that your logs may not
+unnecessarily push other logs out of the buffer, just as others may not push
+out yours.</em></p>
+</li>
+</ul>
+<h3 id="be-consistent">Be Consistent</h3>
+<p>Our parting thought: BE CONSISTENT. If you're editing code, take a few
+minutes to look at the code around you and determine its style. If they use
+spaces around their if clauses, you should too. If their comments have little
+boxes of stars around them, make your comments have little boxes of stars
+around them too.</p>
+<p>The point of having style guidelines is to have a common vocabulary of
+coding, so people can concentrate on what you're saying, rather than on how
+you're saying it. We present global style rules here so people know the
+vocabulary. But local style is also important. If code you add to a a file
+looks drastically different from the existing code around it, it throws
+readers out of their rhythm when they go to read it. Try to avoid this.</p></p>
+<h2 id="javatests-style-rules">Javatests Style Rules</h2>
+<h3 id="follow-test-method-naming-conventions">Follow Test Method Naming Conventions</h3>
+<p>When naming test methods, you can use an underscore to seperate what is
+being tested from the specific case being tested. This style makes it easier
+to see exactly what cases are being tested.</p>
+<p>For example:</p>
+<pre><code>testMethod_specificCase1 testMethod_specificCase2
+
+void testIsDistinguishable_protanopia() {
+ ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
+ assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
+ assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
+}
+</code></pre>
\ No newline at end of file
diff --git a/src/source/code-style.md b/src/source/code-style.md
deleted file mode 100644
index f4d34d4..0000000
--- a/src/source/code-style.md
+++ /dev/null
@@ -1,745 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Code Style Guidelines for Contributors #
-
-The rules below are not guidelines or recommendations, but strict rules.
-Contributions to Android generally *will not be accepted* if they do not
-adhere to these rules.
-
-Not all existing code follows these rules, but all new code is expected to.
-
-[TOC]
-
-## Java Language Rules ##
-
-We follow standard Java coding conventions. We add a few rules:
-
-### Don't Ignore Exceptions ###
-
-Sometimes it is tempting to write code that completely ignores an exception
-like this:
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) { }
- }
-
-You must never do this. While you may think that your code will never
-encounter this error condition or that it is not important to handle it,
-ignoring exceptions like above creates mines in your code for someone else to
-trip over some day. You must handle every Exception in your code in some
-principled way. The specific handling varies depending on the case.
-
-*Anytime somebody has an empty catch clause they should have a
-creepy feeling. There are definitely times when it is actually the correct
-thing to do, but at least you have to think about it. In Java you can't escape
-the creepy feeling.* -[James Gosling](http://www.artima.com/intv/solid4.html)
-
-Acceptable alternatives (in order of preference) are:
-
-- Throw the exception up to the caller of your method.
-
- void setServerPort(String value) throws NumberFormatException {
- serverPort = Integer.parseInt(value);
- }
-
-- Throw a new exception that's appropriate to your level of abstraction.
-
- void setServerPort(String value) throws ConfigurationException {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- throw new ConfigurationException("Port " + value + " is not valid.");
- }
- }
-
-- Handle the error gracefully and substitute an appropriate value in the
-catch {} block.
-
- /** Set port. If value is not a valid number, 80 is substituted. */
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- serverPort = 80; // default port for server
- }
- }
-
-- Catch the Exception and throw a new `RuntimeException`. This is dangerous:
-only do it if you are positive that if this error occurs, the appropriate
-thing to do is crash.
-
- /** Set port. If value is not a valid number, die. */
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- throw new RuntimeException("port " + value " is invalid, ", e);
- }
- }
-
- Note that the original exception is passed to the constructor for
- RuntimeException. If your code must compile under Java 1.3, you will need to
- omit the exception that is the cause.
-
-- Last resort: if you are confident that actually ignoring the exception is
-appropriate then you may ignore it, but you must also comment why with a good
-reason:
-
- /** If value is not a valid number, original port number is used. */
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- // Method is documented to just ignore invalid user input.
- // serverPort will just be unchanged.
- }
- }
-
-### Don't Catch Generic Exception ###
-
-Sometimes it is tempting to be lazy when catching exceptions and do
-something like this:
-
- try {
- someComplicatedIOFunction(); // may throw IOException
- someComplicatedParsingFunction(); // may throw ParsingException
- someComplicatedSecurityFunction(); // may throw SecurityException
- // phew, made it all the way
- } catch (Exception e) { // I'll just catch all exceptions
- handleError(); // with one generic handler!
- }
-
-You should not do this. In almost all cases it is inappropriate to catch
-generic Exception or Throwable, preferably not Throwable, because it includes
-Error exceptions as well. It is very dangerous. It means that Exceptions you
-never expected (including RuntimeExceptions like ClassCastException) end up
-getting caught in application-level error handling. It obscures the failure
-handling properties of your code. It means if someone adds a new type of
-Exception in the code you're calling, the compiler won't help you realize you
-need to handle that error differently. And in most cases you shouldn't be
-handling different types of exception the same way, anyway.
-
-There are rare exceptions to this rule: certain test code and top-level
-code where you want to catch all kinds of errors (to prevent them from showing
-up in a UI, or to keep a batch job running). In that case you may catch
-generic Exception (or Throwable) and handle the error appropriately. You
-should think very carefully before doing this, though, and put in comments
-explaining why it is safe in this place.
-
-Alternatives to catching generic Exception:
-
-- Catch each exception separately as separate catch blocks after a single
-try. This can be awkward but is still preferable to catching all Exceptions.
-Beware repeating too much code in the catch blocks.</li>
-
-- Refactor your code to have more fine-grained error handling, with multiple
-try blocks. Split up the IO from the parsing, handle errors separately in each
-case.
-
-- Rethrow the exception. Many times you don't need to catch the exception at
-this level anyway, just let the method throw it.
-
-Remember: exceptions are your friend! When the compiler complains you're
-not catching an exception, don't scowl. Smile: the compiler just made it
-easier for you to catch runtime problems in your code.
-
-### Don't Use Finalizers ###
-
-Finalizers are a way to have a chunk of code executed
-when an object is garbage collected.
-
-Pros: can be handy for doing cleanup, particularly of external resources.
-
-Cons: there are no guarantees as to when a finalizer will be called,
-or even that it will be called at all.
-
-Decision: we don't use finalizers. In most cases, you can do what
-you need from a finalizer with good exception handling. If you absolutely need
-it, define a close() method (or the like) and document exactly when that
-method needs to be called. See InputStream for an example. In this case it is
-appropriate but not required to print a short log message from the finalizer,
-as long as it is not expected to flood the logs.
-
-### Fully Qualify Imports ###
-
-When you want to use class Bar from package foo,there
-are two possible ways to import it:
-
-1. `import foo.*;`
-
-Pros: Potentially reduces the number of import statements.
-
-1. `import foo.Bar;`
-
-Pros: Makes it obvious what classes are actually used. Makes
-code more readable for maintainers.
-
-Decision: Use the latter for importing all Android code. An explicit
-exception is made for java standard libraries (`java.util.*`, `java.io.*`, etc.)
-and unit test code (`junit.framework.*`)
-
-## Java Library Rules ##
-
-There are conventions for using Android's Java libraries and tools. In some
-cases, the convention has changed in important ways and older code might use a
-deprecated pattern or library. When working with such code, it's okay to
-continue the existing style (see [Consistency](#consistency)). When
-creating new components never use deprecated libraries.
-
-## Java Style Rules ##
-
-### Use Javadoc Standard Comments ###
-
-Every file should have a copyright statement at the top. Then a package
-statement and import statements should follow, each block separated by a blank
-line. And then there is the class or interface declaration. In the Javadoc
-comments, describe what the class or interface does.
-
- /*
- * Copyright (C) 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.
- */
-
- package com.android.internal.foo;
-
- import android.os.Blah;
- import android.view.Yada;
-
- import java.sql.ResultSet;
- import java.sql.SQLException;
-
- /**
- * Does X and Y and provides an abstraction for Z.
- */
-
- public class Foo {
- ...
- }
-
-Every class and nontrivial public method you write *must* contain a
-Javadoc comment with at least one sentence describing what the class or method
-does. This sentence should start with a 3rd person descriptive verb.
-
-Examples:
-
- /** Returns the correctly rounded positive square root of a double value. */
- static double sqrt(double a) {
- ...
- }
-
-or
-
- /**
- * Constructs a new String by converting the specified array of
- * bytes using the platform's default character encoding.
- */
- public String(byte[] bytes) {
- ...
- }
-
-You do not need to write Javadoc for trivial get and set methods such as
-`setFoo()` if all your Javadoc would say is "sets Foo". If the method does
-something more complex (such as enforcing a constraint or having an important
-side effect), then you must document it. And if it's not obvious what the
-property "Foo" means, you should document it.
-
-Every method you write, whether public or otherwise, would benefit from
-Javadoc. Public methods are part of an API and therefore require Javadoc.
-
-Android does not currently enforce a specific style for writing Javadoc
-comments, but you should follow the
-[Sun Javadoc conventions](http://java.sun.com/j2se/javadoc/writingdoccomments/).
-
-### Write Short Methods ###
-
-To the extent that it is feasible, methods should be kept small and
-focused. It is, however, recognized that long methods are sometimes
-appropriate, so no hard limit is placed on method length. If a method exceeds
-40 lines or so, think about whether it can be broken up without harming the
-structure of the program.
-
-### Define Fields in Standard Places ###
-
-Fields should be defined either at the top of the file, or immediately before the methods that use them.
-
-### Limit Variable Scope ###
-
-The scope of local variables should be kept to a minimum (*Effective
-Java* Item 29). By doing so, you increase the readability and
-maintainability of your code and reduce the likelihood of error. Each variable
-should be declared in the innermost block that encloses all uses of the
-variable.
-
-Local variables should be declared at the point they are first used. Nearly
-every local variable declaration should contain an initializer. If you don't
-yet have enough information to initialize a variable sensibly, you should
-postpone the declaration until you do.
-
-One exception to this rule concerns try-catch statements. If a variable is
-initialized with the return value of a method that throws a checked exception,
-it must be initialized inside a try block. If the value must be used outside
-of the try block, then it must be declared before the try block, where it
-cannot yet be sensibly initialized:
-
- // Instantiate class cl, which represents some sort of Set
- Set s = null;
- try {
- s = (Set) cl.newInstance();
- } catch(IllegalAccessException e) {
- throw new IllegalArgumentException(cl + " not accessible");
- } catch(InstantiationException e) {
- throw new IllegalArgumentException(cl + " not instantiable");
- }
-
- // Exercise the set
- s.addAll(Arrays.asList(args));
-
-But even this case can be avoided by encapsulating the try-catch block in a method:
-
- Set createSet(Class cl) {
- // Instantiate class cl, which represents some sort of Set
- try {
- return (Set) cl.newInstance();
- } catch(IllegalAccessException e) {
- throw new IllegalArgumentException(cl + " not accessible");
- } catch(InstantiationException e) {
- throw new IllegalArgumentException(cl + " not instantiable");
- }
- }
-
- ...
-
- // Exercise the set
- Set s = createSet(cl);
- s.addAll(Arrays.asList(args));
-
-Loop variables should be declared in the for statement itself unless there
-is a compelling reason to do otherwise:
-
- for (int i = 0; i n; i++) {
- doSomething(i);
- }
-
-and
-
- for (Iterator i = c.iterator(); i.hasNext(); ) {
- doSomethingElse(i.next());
- }
-
-### Order Import Statements ###
-
-The ordering of import statements is:
-
-1. Android imports
-
-1. Imports from third parties (`com`, `junit`, `net`, `org`)
-
-1. `java` and `javax`
-
-To exactly match the IDE settings, the imports should be:
-
-- Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).
-
-- There should be a blank line between each major grouping (`android`, `com`, `junit`, `net`, `org`, `java`, `javax`).
-
-Originally there was no style requirement on the ordering. This meant that
-the IDE's were either always changing the ordering, or IDE developers had to
-disable the automatic import management features and maintain the imports by
-hand. This was deemed bad. When java-style was asked, the preferred styles
-were all over the map. It pretty much came down to our needing to "pick an
-ordering and be consistent." So we chose a style, updated the style guide, and
-made the IDEs obey it. We expect that as IDE users work on the code, the
-imports in all of the packages will end up matching this pattern without any
-extra engineering effort.
-
-This style was chosen such that:
-
-- The imports people want to look at first tend to be at the top (`android`)
-
-- The imports people want to look at least tend to be at the bottom (`java`)
-
-- Humans can easily follow the style
-
-- IDEs can follow the style
-
-The use and location of static imports have been mildly controversial
-issues. Some people would prefer static imports to be interspersed with the
-remaining imports, some would prefer them reside above or below all other
-imports. Additinally, we have not yet come up with a way to make all IDEs use
-the same ordering.
-
-Since most people consider this a low priority issue, just use your
-judgement and please be consistent.
-
-### Use Spaces for Indentation ###
-
-We use 4 space indents for blocks. We never use tabs. When in doubt, be
-consistent with code around you.
-
-We use 8 space indents for line wraps, including function calls and
-assignments. For example, this is correct:
-
- Instrument i =
- someLongExpression(that, wouldNotFit, on, one, line);
-
-and this is not correct:
-
- Instrument i =
- someLongExpression(that, wouldNotFit, on, one, line);
-
-### Follow Field Naming Conventions ###
-
-- Non-public, non-static field names start with m.
-
-- Static field names start with s.
-
-- Other fields start with a lower case letter.
-
-- Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
-
-For example:
-
- public class MyClass {
- public static final int SOME_CONSTANT = 42;
- public int publicField;
- private static MyClass sSingleton;
- int mPackagePrivate;
- private int mPrivate;
- protected int mProtected;
- }
-
-### Use Standard Brace Style ###
-
-Braces do not go on their own line; they go on the same line as the code
-before them. So:
-
- class MyClass {
- int func() {
- if (something) {
- // ...
- } else if (somethingElse) {
- // ...
- } else {
- // ...
- }
- }
- }
-
-We require braces around the statements for a conditional. Except, if the
-entire conditional (the condition and the body) fit on one line, you may (but
-are not obligated to) put it all on one line. That is, this is legal:
-
- if (condition) {
- body();
- }
-
-and this is legal:
-
- if (condition) body();
-
-but this is still illegal:
-
- if (condition)
- body(); // bad!
-
-### Limit Line Length ###
-
-Each line of text in your code should be at most 100 characters long.
-
-There has been lots of discussion about this rule and the decision remains
-that 100 characters is the maximum.
-
-Exception: if a comment line contains an example command or a literal URL
-longer than 100 characters, that line may be longer than 100 characters for
-ease of cut and paste.
-
-Exception: import lines can go over the limit because humans rarely see
-them. This also simplifies tool writing.
-
-### Use Standard Java Annotations ###
-
-Annotations should precede other modifiers for the same language element.
-Simple marker annotations (e.g. @Override) can be listed on the same line with
-the language element. If there are multiple annotations, or parameterized
-annotations, they should each be listed one-per-line in alphabetical
-order.<
-
-Android standard practices for the three predefined annotations in Java are:
-
-- `@Deprecated`: The @Deprecated annotation must be used whenever the use of the annotated
-element is discouraged. If you use the @Deprecated annotation, you must also
-have a @deprecated Javadoc tag and it should name an alternate implementation.
-In addition, remember that a @Deprecated method is *still supposed to
-work.*
-
- If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.
-
-- `@Override`: The @Override annotation must be used whenever a method overrides the
-declaration or implementation from a super-class.
-
- For example, if you use the @inheritdocs Javadoc tag, and derive from a
- class (not an interface), you must also annotate that the method @Overrides
- the parent class's method.
-
-- `@SuppressWarnings`: The @SuppressWarnings annotation should only be used under circumstances
-where it is impossible to eliminate a warning. If a warning passes this
-"impossible to eliminate" test, the @SuppressWarnings annotation *must* be
-used, so as to ensure that all warnings reflect actual problems in the
-code.
-
- When a @SuppressWarnings annotation is necessary, it must be prefixed with
- a TODO comment that explains the "impossible to eliminate" condition. This
- will normally identify an offending class that has an awkward interface. For
- example:
-
- // TODO: The third-party class com.third.useful.Utility.rotate() needs generics
- @SuppressWarnings("generic-cast")
- List<String> blix = Utility.rotate(blax);
-
- When a @SuppressWarnings annotation is required, the code should be
- refactored to isolate the software elements where the annotation applies.
-
-### Treat Acronyms as Words ###
-
-Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable:
-
-Good | Bad
----------------|-------
-XmlHttpRequest | XMLHTTPRequest
-getCustomerId | getCustomerID
-class Html | class HTML
-String url | String URL
-long id | long ID
-
-Both the JDK and the Android code bases are very inconsistent with regards
-to acronyms, therefore, it is virtually impossible to be consistent with the
-code around you. Bite the bullet, and treat acronyms as words.
-
-For further justifications of this style rule, see *Effective Java*
-Item 38 and *Java Puzzlers* Number 68.
-
-### Use TODO Comments ###
-
-Use TODO comments for code that is temporary, a short-term solution, or
-good-enough but not perfect.
-
-TODOs should include the string TODO in all caps, followed by a colon:
-
- // TODO: Remove this code after the UrlTable2 has been checked in.
-
-and
-
- // TODO: Change this to use a flag instead of a constant.
-
-If your TODO is of the form "At a future date do something" make sure that
-you either include a very specific date ("Fix by November 2005") or a very
-specific event ("Remove this code after all production mixers understand
-protocol V7.").
-
-### Log Sparingly ###
-
-While logging is necessary it has a significantly negative impact on
-performance and quickly loses its usefulness if it's not kept reasonably
-terse. The logging facilities provides five different levels of logging. Below
-are the different levels and when and how they should be used.
-
-- `ERROR`:
-This level of logging should be used when something fatal has happened,
-i.e. something that will have user-visible consequences and won't be
-recoverable without explicitly deleting some data, uninstalling applications,
-wiping the data partitions or reflashing the entire phone (or worse). This
-level is always logged. Issues that justify some logging at the ERROR level
-are typically good candidates to be reported to a statistics-gathering
-server.
-
-- `WARNING`:
-This level of logging should used when something serious and unexpected
-happened, i.e. something that will have user-visible consequences but is
-likely to be recoverable without data loss by performing some explicit action,
-ranging from waiting or restarting an app all the way to re-downloading a new
-version of an application or rebooting the device. This level is always
-logged. Issues that justify some logging at the WARNING level might also be
-considered for reporting to a statistics-gathering server.
-
-- `INFORMATIVE:`
-This level of logging should used be to note that something interesting to
-most people happened, i.e. when a situation is detected that is likely to have
-widespread impact, though isn't necessarily an error. Such a condition should
-only be logged by a module that reasonably believes that it is the most
-authoritative in that domain (to avoid duplicate logging by non-authoritative
-components). This level is always logged.
-
-- `DEBUG`:
-This level of logging should be used to further note what is happening on the
-device that could be relevant to investigate and debug unexpected behaviors.
-You should log only what is needed to gather enough information about what is
-going on about your component. If your debug logs are dominating the log then
-you probably should be using verbose logging.
-
- This level will be logged, even
-on release builds, and is required to be surrounded by an `if (LOCAL_LOG)` or `if
-(LOCAL_LOGD)` block, where `LOCAL_LOG[D]` is defined in your class or
-subcomponent, so that there can exist a possibility to disable all such
-logging. There must therefore be no active logic in an `if (LOCAL_LOG)` block.
-All the string building for the log also needs to be placed inside the `if
-(LOCAL_LOG)` block. The logging call should not be re-factored out into a
-method call if it is going to cause the string building to take place outside
-of the `if (LOCAL_LOG)` block.
-
- There is some code that still says `if
-(localLOGV)`. This is considered acceptable as well, although the name is
-nonstandard.
-
-- `VERBOSE`:
-This level of logging should be used for everything else. This level will only
-be logged on debug builds and should be surrounded by an `if (LOCAL_LOGV)` block
-(or equivalent) so that it can be compiled out by default. Any string building
-will be stripped out of release builds and needs to appear inside the `if (LOCAL_LOGV)` block.
-
-*Notes:*
-
-- Within a given module, other than at the VERBOSE level, an
-error should only be reported once if possible: within a single chain of
-function calls within a module, only the innermost function should return the
-error, and callers in the same module should only add some logging if that
-significantly helps to isolate the issue.
-
-- In a chain of modules, other than at the VERBOSE level, when a
-lower-level module detects invalid data coming from a higher-level module, the
-lower-level module should only log this situation to the DEBUG log, and only
-if logging provides information that is not otherwise available to the caller.
-Specifically, there is no need to log situations where an exception is thrown
-(the exception should contain all the relevant information), or where the only
-information being logged is contained in an error code. This is especially
-important in the interaction between the framework and applications, and
-conditions caused by third-party applications that are properly handled by the
-framework should not trigger logging higher than the DEBUG level. The only
-situations that should trigger logging at the INFORMATIVE level or higher is
-when a module or application detects an error at its own level or coming from
-a lower level.
-
-- When a condition that would normally justify some logging is
-likely to occur many times, it can be a good idea to implement some
-rate-limiting mechanism to prevent overflowing the logs with many duplicate
-copies of the same (or very similar) information.
-
-- Losses of network connectivity are considered common and fully
-expected and should not be logged gratuitously. A loss of network connectivity
-that has consequences within an app should be logged at the DEBUG or VERBOSE
-level (depending on whether the consequences are serious enough and unexpected
-enough to be logged in a release build).
-
-- A full filesystem on a filesystem that is acceessible to or on
-behalf of third-party applications should not be logged at a level higher than
-INFORMATIVE.
-
-- Invalid data coming from any untrusted source (including any
-file on shared storage, or data coming through just about any network
-connections) is considered expected and should not trigger any logging at a
-level higher then DEBUG when it's detected to be invalid (and even then
-logging should be as limited as possible).
-
-- Keep in mind that the `+` operator, when used on Strings,
-implicitly creates a `StringBuilder` with the default buffer size (16
-characters) and potentially quite a few other temporary String objects, i.e.
-that explicitly creating StringBuilders isn't more expensive than relying on
-the default '+' operator (and can be a lot more efficient in fact). Also keep
-in mind that code that calls `Log.v()` is compiled and executed on release
-builds, including building the strings, even if the logs aren't being
-read.
-
-- Any logging that is meant to be read by other people and to be
-available in release builds should be terse without being cryptic, and should
-be reasonably understandable. This includes all logging up to the DEBUG
-level.
-
-- When possible, logging should be kept on a single line if it
-makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
-while lengths longer than about 130 or 160 characters (including the length of
-the tag) should be avoided if possible.
-
-- Logging that reports successes should never be used at levels
-higher than VERBOSE.
-
-- Temporary logging that is used to diagnose an issue that's
-hard to reproduce should be kept at the DEBUG or VERBOSE level, and should be
-enclosed by if blocks that allow to disable it entirely at compile-time.
-
-- Be careful about security leaks through the log. Private
-information should be avoided. Information about protected content must
-definitely be avoided. This is especially important when writing framework
-code as it's not easy to know in advance what will and will not be private
-information or protected content.
-
-- `System.out.println()` (or `printf()` for native code) should
-never be used. System.out and System.err get redirected to /dev/null, so your
-print statements will have no visible effects. However, all the string
-building that happens for these calls still gets executed.
-
-- *The golden rule of logging is that your logs may not
-unnecessarily push other logs out of the buffer, just as others may not push
-out yours.*
-
-### Be Consistent ###
-
-Our parting thought: BE CONSISTENT. If you're editing code, take a few
-minutes to look at the code around you and determine its style. If they use
-spaces around their if clauses, you should too. If their comments have little
-boxes of stars around them, make your comments have little boxes of stars
-around them too.
-
-The point of having style guidelines is to have a common vocabulary of
-coding, so people can concentrate on what you're saying, rather than on how
-you're saying it. We present global style rules here so people know the
-vocabulary. But local style is also important. If code you add to a a file
-looks drastically different from the existing code around it, it throws
-readers out of their rhythm when they go to read it. Try to avoid this.</p>
-
-## Javatests Style Rules ##
-
-### Follow Test Method Naming Conventions ###
-
-When naming test methods, you can use an underscore to seperate what is
-being tested from the specific case being tested. This style makes it easier
-to see exactly what cases are being tested.
-
-For example:
-
- testMethod_specificCase1 testMethod_specificCase2
-
-
- void testIsDistinguishable_protanopia() {
- ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
- assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
- assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
- }
-
diff --git a/src/source/community/groups-charter.jd b/src/source/community/groups-charter.jd
new file mode 100644
index 0000000..d743041
--- /dev/null
+++ b/src/source/community/groups-charter.jd
@@ -0,0 +1,43 @@
+page.title=Android Discussion Groups Charter
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<h2 id="audience">Audience</h2>
+<p>
+These discussion groups are intended for developers working with the Android platform. Everyone is welcome to join in, provided you follow our community's policies described below. Our users help each other, and many experts post to these groups, including members of the Open Handset Alliance.
+</p>
+<p>
+No topic is off-limits, provided it relates to Android in some way. However, since these are very busy lists, search the archives before posting your question; you may find your question has already been answered.
+</p>
+
+<h2 id="mailing">Mailing list rules</h2>
+<p>We love simplicity and hate restrictions, so we keep our policies minimal. The rules
+below describe what's expected of subscribers to the Android mailing lists.</h2>
+
+<ul>
+ <li><em>Please be friendly</em>: Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive toward anyone; if you think there is, think again before you post. Mobile development is serious business, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source.
+ </li>
+ <li><em>Allowed discussion topics<em>: Most of our groups are for technical discussions of Android or users helping each other. Generally we don't put hard restrictions on the topics discussed in the group: as long as the topic is relevant to Android in some way, it's welcome on our groups. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news, but please do not cross-post. Post only to the most relevant group for your message. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen.
+ </li>
+ <li><em>Working Lists</em>: Some of our groups are considered "working lists", by which we mean that the list is intended to be used in support of the completion of specific tasks. On these groups, we don't welcome off-topic conversations, and will generally ask you to take general discussions to a different list. Since these are lists where people are trying to get work done, we will be pretty aggressive about keeping the noise level low. We ask that you respect our contributors' time and keep general discussions to appropriate lists.
+ </li>
+ <li><em>Spam</em>: We hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
+ </li>
+</ul>
+<p>
+The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one. That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
+</p>
+<h2 id="contacting">Contacting the moderators</h2>
+<p>
+If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
+</p>
+<p>
+But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
+</p>
\ No newline at end of file
diff --git a/src/source/community/index.jd b/src/source/community/index.jd
new file mode 100644
index 0000000..0af20a6
--- /dev/null
+++ b/src/source/community/index.jd
@@ -0,0 +1,171 @@
+page.title=Android Community
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android community!</p>
+<p>The key to any community is, obviously, communication. Like most projects,
+Android communicates via mailing lists. Because Android is an extremely large
+project with many components, we have many discussion forums, each focusing on
+a different topic.</p>
+<p>Please check out the groups below, and join any that seem interesting to
+you. 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 retailer
+for help with your phone.</p>
+<p>Please note that if you're looking for information about building
+applications for Android, you can find a separate set of groups for those at
+our sister site, developer.android.com: [https://developer.android.com/resources/community-groups.html]</p>
+
+<h2 id="open-source-project-discussions">Open Source Project discussions</h2>
+<ul>
+<li>
+<p><em>android-platform</em>:
+ This list is for general discussion about the Android open-source project or the platform technologies.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-platform">android-platform</a></li>
+<li>Subscribe via email: <a href="mailto:android-platform+subscribe@googlegroups.com">android-platform</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-building</em>:
+ Subscribe to this list for discussion and help on building the Android source code, and on the build system. If you've just checked out the source code and have questions about how to turn it into binaries, start here.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-building">android-building</a></li>
+<li>Subscribe via email: <a href="mailto:android-building+subscribe@googlegroups.com">android-building</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-porting</em>:
+ This list is for developers who want to port Android to a new device. If you're wondering how to combine the Android source code with your hardware, this is the right group for you. Discuss here the specifics of porting Android to individual devices, from obtaining toolchains and merging kernel drivers all the way to configuring or modifying applications for your specific
+configuration.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-porting">android-porting</a></li>
+<li>Subscribe via email: <a href="mailto:android-porting+subscribe@googlegroups.com">android-porting</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-contrib</em>:
+ This list is for developers who want to contribute code to Android. This is a working list, and is not appropriate for general discussion. We ask that general discussion go to android-platform. Note: contributors to the Android kernel should go to the android-kernel list, below.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-contrib">android-contrib</a></li>
+<li>Subscribe via email: <a href="mailto:android-contrib+subscribe@googlegroups.com">android-contrib</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-kernel</em>:
+ This list is for deveopers who want to contribute to the Linux kernel that Android devices use. If you've downloaded the kernel code, if you know how to compile it, if you want to write kernel code to specifically support Android,
+this is your place. This group isn't for user-space topics (see android-platform for that), and people will shake their fingers at you and call you naughty if you ask user-space questions here.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-kernel">android-kernel</a></li>
+<li>Subscribe via email: <a href="mailto:android-kernel+subscribe@googlegroups.com">android-kernel</a></li>
+</ul>
+</li>
+</ul>
+
+
+<h3 id="audience">Audience</h3>
+<p>
+These discussion groups are intended for developers working with the Android platform. Everyone is welcome to join in, provided you follow our community's policies described below. Our users help each other, and many experts post to these groups, including members of the Open Handset Alliance.
+</p>
+<p>
+No topic is off-limits, provided it relates to Android in some way. However, since these are very busy lists, search the archives before posting your question; you may find your question has already been answered.
+</p>
+
+
+<h3 id="getting-the-most-from-our-lists">Getting the Most from Our Lists</h3>
+<p>Please consider the following before you post to our lists.</p>
+<ul>
+<li>
+<p><em>Read the <a href="#mailing">Charter for our forums.</a></em> This explains the (few) rules and guidelines for our community.</p>
+</li>
+<li>
+<p><em>Search the group archives to see whether your questions have already been discussed.</em> This avoids time-wasting redundant discussions.</p>
+</li>
+<li>
+<p><em>Use a clear, relevant message subject.</em> This helps everyone, both those trying to answer your question as well as those who may be looking for information in the future.</p>
+</li>
+<li>
+<p><em>Give plenty of details in your post.</em> Code or log snippets, pointers to screenshots, and similar details will get better results and make for better discussions. For a great guide to phrasing your questions, read <a href="http://www.catb.org/%7Eesr/faqs/smart-questions.html">How to Ask Questions the Smart Way</a>.
+<img src="/images/external-link.png"></p>
+</li>
+</ul>
+
+<h3 id="mailing">Mailing list rules</h3>
+<p>We love simplicity and hate restrictions, so we keep our policies minimal. The rules
+below describe what's expected of subscribers to the Android mailing lists.</h2>
+
+<ul>
+ <li><em>Please be friendly</em>: Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive toward anyone; if you think there is, think again before you post. Mobile development is serious business, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source.
+ </li>
+ <li><em>Allowed discussion topics</em>: Most of our groups are for technical discussions of Android or users helping each other. Generally we don't put hard restrictions on the topics discussed in the group: as long as the topic is relevant to Android in some way, it's welcome on our groups. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news, but please do not cross-post. Post only to the most relevant group for your message. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen.
+ </li>
+ <li><em>Working Lists</em>: Some of our groups are considered "working lists", by which we mean that the list is intended to be used in support of the completion of specific tasks. On these groups, we don't welcome off-topic conversations, and will generally ask you to take general discussions to a different list. Since these are lists where people are trying to get work done, we will be pretty aggressive about keeping the noise level low. We ask that you respect our contributors' time and keep general discussions to appropriate lists.
+ </li>
+ <li><em>Spam</em>: We hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
+ </li>
+</ul>
+<p>
+The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one. That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
+</p>
+<h3 id="contacting">Contacting the moderators</h3>
+<p>
+If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
+</p>
+<p>
+But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
+</p>
+
+
+
+<h3 id="using-email-with-google-groups">Using email with Google Groups</h3>
+<p>Instead of using the <a href="https://groups.google.com/">Google groups</a> site, you can use your email client of choice to participate in the mailing lists.</p>
+<p>To subscribe to a group without using the Google Groups site, use the link under "subscribe via email" in the lists above.</p>
+<p>To set up how you receive mailing list postings by email:</p>
+<ol>
+<li>
+<p>Sign into the group via the Google Groups site. For example, for the android-platform group you would use [https://groups.google.com/forum/?fromgroups#!forum/android-platform].</p>
+</li>
+<li>
+<p>Click "My membership" on the right side.</p>
+</li>
+<li>
+<p>Under "How do you want to read this group?" select one of the email options.</p>
+</li>
+</ol>
+<h2 id="android-on-irc">Android on IRC</h2>
+<p>We also have a presence on IRC via <a href="http://freenode.net/">freenode</a>.
+We maintain two official IRC channels on <a href="irc://irc.freenode.net/">irc.freenode.net</a> (access via the web
+at <a href="http://webchat.freenode.net/">freenode webchat</a>)</p>
+<ul>
+<li>
+<p><a href="irc://irc.freenode.net/android">#android</a> - dedicated to general Android discussion and porting concerns</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-dev">#android-dev</a> - dedicated to discussion about writing Android applications</p>
+</li>
+</ul>
+<p>The channels above are official. There are a few other channels the
+community is using, but are not official. These aren't official or officially
+moderated/managed, so you use the channels below at your own risk. The Open
+Handset Alliance doesn't endorse these channels, there's no warranty express
+or implied, and so on. There may be more channels than just these listed.</p>
+<ul>
+<li>
+<p><a href="irc://irc.freenode.net/android-firehose">#android-firehose</a> - displays in real-time the commits to the Android Open Source Project</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-fr">#android-fr</a> - pour discuter d'Android en français</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-offtopic">#android-offtopic</a> - for, well, off-topic discussions</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-root">#android-root</a> - for discussion related to off-label uses of hardware</p>
+</li>
+</ul>
diff --git a/src/source/contributing.jd b/src/source/contributing.jd
new file mode 100644
index 0000000..377c449
--- /dev/null
+++ b/src/source/contributing.jd
@@ -0,0 +1,49 @@
+page.title=Contributing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Thanks for your interest in Android! Here are some ways you can get involved
+and help us improve Android. For background on the Android project and our
+goals, check out the <a href="/source/index.html">Overview</a> page.</p>
+<h2 id="report-bugs">Report Bugs</h2>
+
+<p>One of the easiest and most effective ways you can help improve Android is
+to file bugs. For more information, visit the <a href="report-bugs.html">Reporting Bugs</a> page.</p>
+<p>Please note that we can't guarantee that any particular bug will be fixed in
+any particular release. To see what happens to your bug once you report it,
+read <a href="life-of-a-bug.html">Life of a Bug</a>.</p>
+
+<h2 id="develop-apps">Develop Apps</h2>
+<p>We created Android so that all developers can distribute their applications
+to users on an open platform. One of the best ways you can help Android is to
+write cool apps that users love!</p>
+
+<p>To get started, visit <a href="https://developer.android.com">developer.android.com</a>. This site
+provides the information and tools you need to write applications for
+compatible Android devices, using the SDK.</p>
+
+<h2 id="contribute-to-the-code">Contribute to the Code</h2>
+<p>Code is King. We'd love to review any changes you submit, so please check
+out the source, pick a bug or feature, and get coding. Note that the smaller
+and more targetted your patch submissions, the easier it will be for us to
+review them.</p>
+
+<p>You can get started with Android by learning about the <a href="life-of-a-patch.html">Life of a Patch</a>,
+and by learning about <code>git</code>, <code>repo</code>, and other tools using the links to the left.
+You can also view the activity on all contributions on our
+<a href="https://android-review.googlesource.com/">Gerrit server</a>.
+If you need help along the way, you can join our <a href="/source/index.html">discussion groups</a>.</p>
\ No newline at end of file
diff --git a/src/source/developing.jd b/src/source/developing.jd
new file mode 100644
index 0000000..d8bfb05
--- /dev/null
+++ b/src/source/developing.jd
@@ -0,0 +1,159 @@
+page.title=Developing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>To work with the Android code, you will need to use both Git and Repo. In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however.</p>
+<p><strong>Git</strong> is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits. One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.</p>
+<p><strong>Repo</strong> is a repository management tool that we built on top of Git. Repo
+unifies the many Git repositories when necessary, does the uploads to our
+<a href="https://android-review.googlesource.com/">revision control system</a>, and
+automates parts of the Android development workflow. Repo is not meant to
+replace Git, only to make it easier to work with Git in the context of
+Android. The repo command is an executable Python script that you can put
+anywhere in your path. In working with the Android source files, you will
+use Repo for across-network operations. For example, with a single Repo
+command you can download files from multiple repositories into your local
+working directory.</p>
+<p><strong>Gerrit</strong> is a web-based code review system for projects that use git. Gerrit encourages more centralized use of Git by allowing all authorized users to submit changes, which are automatically merged if they pass code review. In addition, Gerrit makes reviewing easier by displaying changes side by side in-browser and enabling inline comments. </p>
+<h2 id="basic-workflow">Basic Workflow</h2>
+<div style="float:right">
+ <img src="{@docRoot}images/submit-patches-0.png" alt="basic workflow diagram">
+</div>
+
+<p>The basic pattern of interacting with the repositories is as follows:</p>
+<ol>
+<li>
+<p>Use <code>repo start</code> to start a new topic branch.</p>
+</li>
+<li>
+<p>Edit the files.</p>
+</li>
+<li>
+<p>Use <code>git add</code> to stage changes.</p>
+</li>
+<li>
+<p>Use <code>git commit</code> to commit changes.</p>
+</li>
+<li>
+<p>Use <code>repo upload</code> to upload changes to the review server.</p>
+</li>
+</ol>
+<h2 id="task-reference">Task reference</h2>
+<p>The task list below shows a summary of how to do common Repo and Git tasks.
+For information about using repo to download source, see <a href="{@docRoot}source/downloading.html">Downloading the Source</a> and
+<a href="{@docRoot}source/using-repo.html">Using Repo</a>.</p>
+<h2 id="synchronizing-your-client">Synchronizing your client</h2>
+<p>To synchronize the files for all available projects: </p>
+<pre><code>$ repo sync
+</code></pre>
+<p>To synchronize the files for selected projects:</p>
+<pre><code>$ repo sync PROJECT0 PROJECT1 PROJECT2 ...
+</code></pre>
+<h2 id="creating-topic-branches">Creating topic branches</h2>
+<p>Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature. A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you can isolate one aspect of your work from the others. For an interesting article about using topic branches, see <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt">Separating topic branches</a>.
+<img src="/images/external-link.png" alt=""></p>
+<p>To start a topic branch using Repo: </p>
+<pre><code>$ repo start BRANCH_NAME
+</code></pre>
+<p>To verify that your new branch was created:</p>
+<pre><code>$ repo status
+</code></pre>
+<h2 id="using-topic-branches">Using topic branches</h2>
+<p>To assign the branch to a particular project:</p>
+<pre><code>$ repo start BRANCH_NAME PROJECT
+</code></pre>
+<p>To switch to another branch that you have created in your local work environment:</p>
+<pre><code>$ git checkout BRANCH_NAME
+</code></pre>
+<p>To see a list of existing branches:</p>
+<pre><code>$ git branch
+</code></pre>
+<p>or </p>
+<pre><code>$ repo branches
+</code></pre>
+<p>The name of the current branch will be preceded by an asterisk.</p>
+<p><em>Note: A bug might be causing <code>repo sync</code> to reset the local topic branch. If <code>git branch</code> shows * (no branch) after you run <code>repo sync</code>, then run <code>git checkout</code> again.</em></p>
+<h2 id="staging-files">Staging files</h2>
+<p>By default, Git notices but does not track the changes you make in a project. In order to tell git to preserve your changes, you must mark them for inclusion in a commit. This is also called "staging". </p>
+<p>You can stage your changes by running</p>
+<pre><code>git add
+</code></pre>
+<p>which accepts as arguments any files or directories within the project directory. Despite the name, <code>git add</code> does not simply add files to the git repository; it can also be used to stage file modifications and deletions.</p>
+<h2 id="viewing-client-status">Viewing client status</h2>
+<p>To list the state of your files:</p>
+<pre><code>$ repo status
+</code></pre>
+<p>To see uncommitted edits:</p>
+<pre><code>$ repo diff
+</code></pre>
+<p>The <code>repo diff</code> command shows every local edit that you have made that would <em>not</em> go into the commit, if you were to commit right now. To see every edit that would go into the commit if you were to commit right now, you need a Git command, <code>git diff</code>. Before running it, be sure you are in the project directory:</p>
+<pre><code>$ cd ~/WORKING_DIRECTORY/PROJECT
+$ git diff --cached
+</code></pre>
+<h2 id="committing-changes">Committing changes</h2>
+<p>A commit is the basic unit of revision control in git, consisting of a snapshot of directory structure and file contents for the entire project. Creating a commit in git is as simple as typing</p>
+<pre><code>git commit
+</code></pre>
+<p>You will be prompted for a commit message in your favorite editor; please provide a helpful message for any changes you submit to the AOSP. If you do not add a log message, the commit will be aborted. </p>
+<h2 id="uploading-changes-to-gerrit">Uploading changes to Gerrit</h2>
+<p>Before uploading, update to the latest revisions:</p>
+<pre><code>repo sync
+</code></pre>
+<p>Next run</p>
+<pre><code>repo upload
+</code></pre>
+<p>This will list the changes you have committed and prompt you to select which branches to upload to the review server. If there is only one branch, you will see a simple <code>y/n</code> prompt.</p>
+<h2 id="recovering-sync-conflicts">Recovering sync conflicts</h2>
+<p>If a <code>repo sync</code> shows sync conflicts:</p>
+<ul>
+<li>View the files that are unmerged (status code = U).</li>
+<li>Edit the conflict regions as necessary.</li>
+<li>
+<p>Change into the relevant project directory, run <code>git add</code> and <code>git commit</code> for the files in question, and then "rebase" the changes. For example:</p>
+<pre><code>$ git add .
+$ git commit
+$ git rebase --continue
+</code></pre>
+</li>
+<li>
+<p>When the rebase is complete start the entire sync again:</p>
+<pre><code>$ repo sync PROJECT0 PROJECT1 ... PROJECTN
+</code></pre>
+</li>
+</ul>
+<h2 id="cleaning-up-your-client-files">Cleaning up your client files</h2>
+<p>To update your local working directory after changes are merged in Gerrit:</p>
+<pre><code>$ repo sync
+</code></pre>
+<p>To safely remove stale topic branches: </p>
+<pre><code>$ repo prune
+</code></pre>
+<h2 id="deleting-a-client">Deleting a client</h2>
+<p>Because all state information is stored in your client, you only need to delete the directory from your filesystem:</p>
+<pre><code>$ rm -rf WORKING_DIRECTORY
+</code></pre>
+<p>Deleting a client will <em>permanently delete</em> any changes you have not yet uploaded for review.</p>
+<h2 id="git-and-repo-cheatsheet">Git and Repo cheatsheet</h2>
+<p><img src="/images/git-repo-1.png" alt="list of basic git and repo commands"></p>
diff --git a/src/source/download.html b/src/source/download.html
deleted file mode 100644
index 0820f26..0000000
--- a/src/source/download.html
+++ /dev/null
@@ -1,8 +0,0 @@
-<!DOCTYPE html>
-<html>
-<head>
-<meta http-equiv="refresh" content="0;url=/source/initializing.html" />
-</head>
-<body>
-</body>
-</html>
diff --git a/src/source/downloading.jd b/src/source/downloading.jd
new file mode 100644
index 0000000..7376d41
--- /dev/null
+++ b/src/source/downloading.jd
@@ -0,0 +1,279 @@
+page.title=Downloading the Source
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The Android source tree is located in a Git repository hosted by Google. This document
+ describes how to download the source tree for a specific Android code-line.
+</p>
+<h2 id="installing-repo">
+ Installing Repo
+</h2>
+<p>
+ Repo is a tool that makes it easier to work with Git in the context of Android. For more
+ information about Repo, see the <a href="developing.html">Developing</a> section.
+</p>
+<p>
+ To install Repo:
+</p>
+<ol>
+ <li>
+ <p>
+ Make sure you have a bin/ directory in your home directory and that it is included in
+ your path:
+ </p>
+ <pre>
+<code>$ mkdir ~/bin
+$ PATH=~/bin:$PATH
+</code>
+</pre>
+ </li>
+ <li>
+ <p>
+ Download the Repo tool and ensure that it is executable:
+ </p>
+ <pre>
+$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
+$ chmod a+x ~/bin/repo
+</pre>
+ </li>
+</ol>
+<p>
+ For version 1.17, the SHA-1 checksum for repo is ddd79b6d5a7807e911b524cb223bc3544b661c28
+</p>
+<h2 id="initializing-a-repo-client">
+ Initializing a Repo client
+</h2>
+<p>
+ After installing Repo, set up your client to access the Android source repository:
+</p>
+<ol>
+ <li>
+ <p>
+ 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:
+ </p>
+<pre>
+$ mkdir WORKING_DIRECTORY
+$ cd WORKING_DIRECTORY
+</pre>
+ </li>
+ <li>
+ <p>
+ Run <code>repo init</code> 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.
+ </p>
+<pre>
+$ repo init -u https://android.googlesource.com/platform/manifest
+</pre>
+ <p>
+ To check out a branch other than "master", specify it with -b:
+ </p>
+<pre>
+$ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
+</pre>
+ </li>
+ <li>
+ <p>
+ When prompted, 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 <a href=
+ "https://www.google.com/accounts">registered Google account</a>. 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.
+ </p>
+ </li>
+</ol>
+<p>
+ A successful initialization will end with a message stating that Repo is initialized in your
+ working directory. Your client directory should now contain a <code>.repo</code> directory
+ where files such as the manifest will be kept.
+</p>
+<h2 id="getting-the-files">
+ Downloading the Android Source Tree
+</h2>
+<p>
+ To pull down the Android source tree to your working directory from the repositories as
+ specified in the default manifest, run
+</p>
+<pre>$ repo sync</pre>
+<p>
+ 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 <code>repo
+ sync</code> and other Repo commands, see the <a href="developing.html">Developing</a> section.
+</p>
+<h2 id="using-authentication">
+ Using Authentication
+</h2>
+<p>
+ 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.
+</p>
+<p>
+ 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).
+</p>
+<p>
+ In that case, it is possible to use authenticated access, which then uses a separate quota
+ for each user, regardless of the IP address.
+</p>
+<p>
+ The first step is to create a password from <a href=
+ "https://android.googlesource.com/new-password">the password generator</a> and to save it in
+ <code>~/.netrc</code> according to the instructions on that page.
+</p>
+<p>
+ The second step is to force authenticated access, by using the following manifest URI:
+ <code>https://android.googlesource.com/a/platform/manifest</code>. Notice how the
+ <code>/a/</code> directory prefix triggers mandatory authentication. You can convert an
+ existing client to use mandatory authentication with the following command:
+</p>
+<pre>
+$ repo init -u https://android.googlesource.com/a/platform/manifest
+</pre>
+<h2 id="troubleshooting-network-issues">
+ Troubleshooting network issues
+</h2>
+<p>
+ 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:
+</p>
+<pre>
+$ 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>
+</pre>
+<p>
+ 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:
+</p>
+<pre>
+$ sudo sysctl -w net.ipv4.tcp_window_scaling=0
+$ repo sync -j1
+</pre>
+<h2 id="using-a-local-mirror">
+ Using a local mirror
+</h2>
+<p>
+ 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.
+</p>
+<p>
+ These instructions assume that the mirror is created in <code>/usr/local/aosp/mirror</code>.
+ 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 <code>--mirror</code> flag, which
+ can only be specified when creating a new client:
+</p>
+<pre>
+$ mkdir -p /usr/local/aosp/mirror
+$ cd /usr/local/aosp/mirror
+$ repo init -u https://android.googlesource.com/mirror/manifest --mirror
+$ repo sync
+</pre>
+<p>
+ Once the mirror is synced, new clients can be created from it. Note that it's important to
+ specify an absolute path:
+</p>
+<pre>$ mkdir -p /usr/local/aosp/master
+$ cd /usr/local/aosp/master
+$ repo init -u /usr/local/aosp/mirror/platform/manifest.git
+$ repo sync
+</pre>
+<p>
+ Finally, to sync a client against the server, the mirror needs to be synced against the
+ server, then the client against the mirror:
+</p>
+<pre>
+$ cd /usr/local/aosp/mirror
+$ repo sync
+$ cd /usr/local/aosp/master
+$ repo sync
+</pre>
+<p>
+ 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.
+</p>
+<h2 id="verifying-git-tags">
+ Verifying Git Tags
+</h2>
+<p>
+ Load the following public key into your GnuPG key database. The key is used to sign annotated
+ tags that represent releases.
+</p>
+<pre>
+$ gpg --import
+</pre>
+<p>
+ Copy and paste the key(s) below, then enter EOF (Ctrl-D) to end the input and process the
+ keys.
+</p>
+<pre>
+-----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-----
+</pre>
+<p>
+ After importing the keys, you can verify any tag with
+</p>
+<pre>
+$ git tag -v TAG_NAME
+</pre>
+<p>
+ If you haven't <a href="initializing.html#ccache">set up ccache</a> yet, now would be a good
+ time to do it.
+</p>
\ No newline at end of file
diff --git a/src/source/downloading.md b/src/source/downloading.md
deleted file mode 100644
index 72dffee..0000000
--- a/src/source/downloading.md
+++ /dev/null
@@ -1,207 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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
-
-
-## 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/faqs.jd b/src/source/faqs.jd
new file mode 100644
index 0000000..84ee855
--- /dev/null
+++ b/src/source/faqs.jd
@@ -0,0 +1,445 @@
+page.title=Frequently Asked Questions
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<h2 id="open-source">Open Source</h2>
+<h3 id="what-is-the-android-open-source-project">What is the Android Open Source Project?</h3>
+<p>We use the phrase "Android Open Source Project" or "AOSP" to refer to the
+people, the processes, and the source code that make up Android.</p>
+<p>The people oversee the project and develop the actual source code. The
+processes refer to the tools and procedures we use to manage the development
+of the software. The net result is the source code that you can use to build
+cell phone and other devices.</p>
+<h3 id="why-did-we-open-the-android-source-code">Why did we open the Android source code?</h3>
+<p>Google started the Android project in response to our own experiences
+launching mobile apps. We wanted to make sure that there would always be an
+open platform available for carriers, OEMs, and developers to use to make
+their innovative ideas a reality. We also wanted to make sure that there was no
+central point of failure, so that no single industry player could restrict or control
+the innovations of any other. The single most important goal of the Android
+Open-Source Project (AOSP) is to make sure that the open-source Android
+software is implemented as widely and compatibly as possible, to everyone's
+benefit.</p>
+<p>You can find more information on this topic at our Project Philosophy page.</p>
+<h3 id="what-kind-of-open-source-project-is-android">What kind of open-source project is Android?</h3>
+<p>Google oversees the development of the core Android open-source platform,
+and works to create robust developer and user communities. For the most part
+the Android source code is licensed under the permissive Apache Software
+License 2.0, rather than a "copyleft" license. The main reason for this is
+because our most important goal is widespread adoption of the software, and
+we believe that the ASL2.0 license best achieves that goal.</p>
+<p>You can find more information on this topic at our Project Philosophy and
+Licensing pages. </p>
+<h3 id="why-is-google-in-charge-of-android">Why is Google in charge of Android?</h3>
+<p>Launching a software platform is complex. Openness is vital to the
+long-term success of a platform, since openness is required to attract
+investment from developers and ensure a level playing field. However, the
+platform itself must also be a compelling product to end users.</p>
+<p>That's why Google has committed the professional engineering resources
+necessary to ensure that Android is a fully competitive software platform.
+Google treats the Android project as a full-scale product development
+operation, and strikes the business deals necessary to make sure that great
+devices running Android actually make it to market.</p>
+<p>By making sure that Android is a success with end users, we help ensure the
+vitality of Android as a platform, and as an open-source project. After all,
+who wants the source code to an unsuccessful product?</p>
+<p>Google's goal is to ensure a successful ecosystem around Android, but no
+one is required to participate, of course. We opened the Android source code
+so anyone can modify and distribute the software to meet their own needs.</p>
+<h3 id="what-is-googles-overall-strategy-for-android-product-development">What is Google's overall strategy for Android product development?</h3>
+<p>We focus on releasing great devices into a competitive marketplace, and
+then incorporate the innovations and enhancements we made into the core
+platform, as the next version.</p>
+<p>In practice, this means that the Android engineering team typically focuses
+on a small number of "flagship" devices, and develops the next version of
+the Android software to support those product launches. These flagship
+devices absorb much of the product risk and blaze a trail for the broad OEM
+community, who follow up with many more devices that take advantage of the
+new features. In this way, we make sure that the Android platform evolves
+according to the actual needs of real-world devices.</p>
+<h3 id="how-is-the-android-software-developed">How is the Android software developed?</h3>
+<p>Each platform version of Android (such as 1.5, 1.6, and so on) has a
+corresponding branch in the open-source tree. At any given moment, the most
+recent such branch will be considered the "current stable" branch version.
+This current stable branch is the one that manufacturers port to their
+devices. This branch is kept suitable for release at all times.</p>
+<p>Simultaneously, there is also a "current experimental" branch, which is
+where speculative contributions, such as large next-generation features, are
+developed. Bug fixes and other contributions can be included in the current
+stable branch from the experimental branch as appropriate.</p>
+<p>Finally, Google works on the next version of the Android platform in tandem
+with developing a flagship device. This branch pulls in changes from the
+experimental and stable branches as appropriate.</p>
+<p>You can find more information on this topic at our <a href="source/code-lines.html">Branches and Releases</a>.</p>
+<h3 id="why-are-parts-of-android-developed-in-private">Why are parts of Android developed in private?</h3>
+<p>It typically takes over a year to bring a device to market, but of course
+device manufacturers want to ship the latest software they can. Developers,
+meanwhile, don't want to have to constantly track new versions of the
+platform when writing apps. Both groups experience a tension between
+shipping products, and not wanting to fall behind.</p>
+<p>To address this, some parts of the next version of Android including the
+core platform APIs are developed in a private branch. These APIs constitute
+the next version of Android. Our aim is to focus attention on the current
+stable version of the Android source code, while we create the next version
+of the platform as driven by flagship Android devices. This allows developers
+and OEMs to focus on a single version without having to track unfinished
+future work just to keep up. Other parts of the Android system that aren't
+related to application compatibility are developed in the open, however.
+It's our intention to move more of these parts to open development over
+time.</p>
+<h3 id="when-are-source-code-releases-made">When are source code releases made?</h3>
+<p>When they are ready. Some parts of Android are developed in the open,
+so that source code is always available. Other parts are developed first in
+a private tree, and that source code is released when the next platform
+version is ready.</p>
+<p>In some releases, core platform APIs will be ready far enough in advance
+that we can push the source code out for an early look in advance of the
+device's release; however in others, this isn't possible. In all cases, we
+release the platform source when we feel the version has stabilized enough,
+and when the development process permits. Releasing the source code is a
+fairly complex process.</p>
+<h3 id="what-is-involved-in-releasing-the-source-code-for-a-new-android-version">What is involved in releasing the source code for a new Android version?</h3>
+<p>Releasing the source code for a new version of the Android platform is a
+significant process. First, the software gets built into a system image for
+a device, and put through various forms of certification, including
+government regulatory certification for the regions the phones will be
+deployed. It also goes through operator testing. This is an important phase
+of the process, since it helps shake out a lot of software bugs.</p></p>
+<p>Once the release is approved by the regulators and operators, the
+manufacturer begins mass producing devices, and we turn to releasing the
+source code.</p>
+<p>Simultaneous to mass production the Google team kicks off several efforts
+to prepare the open source release. These efforts include final API changes
+and documentation (to reflect any changes that were made during
+qualification testing, for example), preparing an SDK for the new version,
+and launching the platform compatibility information.</p>
+<p>Also included is a final legal sign-off to release the code into open
+source. Just as open source contributors are required to sign a Contributors
+License Agreement attesting to their IP ownership of their contribution,
+Google too must verify that it is clear to make contributions.</p>
+<p>Starting at the time mass production begins, the software release process
+usually takes around a month, which often roughly places source code
+releases around the same time that the devices reach users.</p>
+<h3 id="how-does-the-aosp-relate-to-the-android-compatibility-program">How does the AOSP relate to the Android Compatibility Program?</h3>
+<p>The Android Open-Source Project maintains the Android software, and
+develops new versions. Since it's open-source, this software can be used for
+any purpose, including to ship devices that are not compatible with other
+devices based on the same source.</p>
+<p>The function of the Android Compatibility Program is to define a baseline
+implementation of Android that is compatible with third-party apps written
+by developers. Devices that are "Android compatible" may participate in the
+Android ecosystem, including Google Play; devices that don't meet the
+compatibility requirements exist outside that ecosystem.</p>
+<p>In other words, the Android Compatibility Program is how we separate
+"Android compatible devices" from devices that merely run derivatives of the
+source code. We welcome all uses of the Android source code, but only
+Android compatible devices -- as defined and tested by the Android
+Compatibility Program -- may participate in the Android ecosystem.</p>
+<h3 id="how-can-i-contribute-to-android">How can I contribute to Android?</h3>
+<p>There are a number of ways you can contribute to Android. You can report
+bugs, write apps for Android, or contribute source code to the Android
+Open-Source Project.</p>
+<p>There are some limits on the kinds of code contributions we are willing or
+able to accept. For instance, someone might want to contribute an
+alternative application API, such as a full C++-based environment. We would
+decline that contribution, since Android is focused on applications that run
+in the Dalvik VM. Alternatively, we won't accept contributions such as GPL
+or LGPL libraries that are incompatible with our licensing goals.</p>
+<p>We encourage those interested in contributing source code to contact us via
+the AOSP Community page prior to beginning any work. You can find more
+information on this topic at the Getting Involved page.</p>
+<h3 id="how-do-i-become-an-android-committer">How do I become an Android committer?</h3>
+<p>The Android Open Source Project doesn't really have a notion of a
+"committer". All contributions -- including those authored by Google
+employees -- go through a web-based system known as "gerrit" that's part of
+the Android engineering process. This system works in tandem with the git
+source code management system to cleanly manage source code
+contributions.</p>
+<p>Once submitted, changes need to be accepted by a designated Approver.
+Approvers are typically Google employees, but the same approvers are
+responsible for all submissions, regardless of origin.</p>
+<p>You can find more information on this topic at the <a href="source/submit-patches.html">Submitting Patches</a> page.</p>
+<h2 id="compatibility">Compatibility</h2>
+<h3 id="what-does-compatibility-mean">What does "compatibility" mean?</h3>
+<p>We define an "Android compatible" device as one that can run any
+application written by third-party developers using the Android SDK and NDK.
+We use this as a filter to separate devices that can participate in the
+Android app ecosystem, and those that cannot. Devices that are properly
+compatible can seek approval to use the Android trademark. Devices that are
+not compatible are merely derived from the Android source code and may not
+use the Android trademark.</p>
+<p>In other words, compatibility is a prerequisite to participate in the
+Android apps ecosystem. Anyone is welcome to use the Android source code,
+but if the device isn't compatible, it's not considered part of the Android
+ecosystem.</p>
+<h3 id="what-is-the-role-of-google-play-in-compatibility">What is the role of Google Play in compatibility?</h3>
+<p>Devices that are Android compatible may seek to license the Google Play
+client software. This allows them to become part of the Android app
+ecosystem, by allowing users to download developers' apps from a catalog
+shared by all compatible devices. This option isn't available to devices
+that aren't compatible.</p>
+<h3 id="what-kinds-of-devices-can-be-android-compatible">What kinds of devices can be Android compatible?</h3>
+<p>The Android software can be ported to a lot of different kinds of devices,
+including some on which third-party apps won't run properly. The Android
+Compatibility Definition Document (CDD) spells out the specific device
+configurations that will be considered compatible.</p>
+<p>For example, though the Android source code could be ported to run on a
+phone that doesn't have a camera, the CDD requires that in order to be
+compatible, all phones must have a camera. This allows developers to rely
+on a consistent set of capabilities when writing their apps.</p>
+<p>The CDD will evolve over time to reflect market realities. For instance,
+the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit
+telephony hardware, allowing for non-phone devices such as tablet-style
+music players to be compatible. As we make these changes, we will also
+augment Google Play to allow developers to retain control over where
+their apps are available. To continue the telephony example, an app that
+manages SMS text messages would not be useful on a media player, so Google
+Play allows the developer to restrict that app exclusively to phone
+devices.</p>
+<h3 id="if-my-device-is-compatible-does-it-automatically-have-access-to-google-play-and-branding">If my device is compatible, does it automatically have access to Google Play and branding?</h3>
+<p>Google Play is a service operated by Google. Achieving compatibility is
+a prerequisite for obtaining access to the Google Play software and branding.
+Device manufacturers should contact Google to obtain access to Google
+Play.</p>
+<h3 id="if-i-am-not-a-manufacturer-how-can-i-get-google-play">If I am not a manufacturer, how can I get Google Play?</h3>
+<p>Google Play is only licensed to handset manufacturers shipping devices.
+For questions about specific cases, contact android-partnerships@google.com.</p>
+<h3 id="how-can-i-get-access-to-the-google-apps-for-android-such-as-maps">How can I get access to the Google apps for Android, such as Maps?</h3>
+<p>The Google apps for Android, such as YouTube, Google Maps and Navigation,
+Gmail, and so on are Google properties that are not part of Android, and
+are licensed separately. Contact android-partnerships@google.com for
+inquiries related to those apps.</p>
+<h3 id="is-compatibility-mandatory">Is compatibility mandatory?</h3>
+<p>No. The Android Compatibility Program is optional. Since the Android source
+code is open, anyone can use it to build any kind of device. However, if a
+manufacturer wishes to use the Android name with their product, or wants
+access to Google Play, they must first demonstrate that the device is
+compatible.</p>
+<h3 id="how-much-does-compatibility-certification-cost">How much does compatibility certification cost?</h3>
+<p>There is no cost to obtain Android compatibility for a device. The
+Compatibility Test Suite is open-source and available to anyone to use to
+test a device.</p>
+<h3 id="how-long-does-compatibility-take">How long does compatibility take?</h3>
+<p>The process is automated. The Compatibility Test Suite generates a report
+that can be provided to Google to verify compatibility. Eventually we intend
+to provide self-service tools to upload these reports to a public database.</p>
+<h3 id="who-determines-what-will-be-part-of-the-compatibility-definition">Who determines what will be part of the compatibility definition?</h3>
+<p>Since Google is responsible for the overall direction of Android as a
+platform and product, Google maintains the Compatibility Definition Document
+for each release. We draft the CDD for a new Android version in consultation
+with a number of OEMs, who provide input on its contents.</p>
+<h3 id="how-long-will-each-android-version-be-supported-for-new-devices">How long will each Android version be supported for new devices?</h3>
+<p>Since Android's code is open-source, we can't prevent someone from using an
+old version to launch a device. Instead, Google chooses not to license the
+Google Play client software for use on versions that are considered
+obsolete. This allows anyone to continue to ship old versions of Android,
+but those devices won't use the Android name and will exist outside the
+Android apps ecosystem, just as if they were non-compatible.</p>
+<h3 id="can-a-device-have-a-different-user-interface-and-still-be-compatible">Can a device have a different user interface and still be compatible?</h3>
+<p>The Android Compatibility Program focuses on whether a device can run
+third-party applications. The user interface components shipped with a
+device (such as home screen, dialer, color scheme, and so on) does not
+generally have much effect on third-party apps. As such, device builders are
+free to customize the user interface as much as they like. The Compatibility
+Definition Document does restrict the degree to which OEMs may alter the
+system user interface for areas that do impact third-party apps.</p>
+<h3 id="when-are-compatibility-definitions-released-for-new-android-versions">When are compatibility definitions released for new Android versions?</h3>
+<p>Our goal is to release new versions of Android Compatibility Definition
+Documents (CDDs) once the corresponding Android platform version has
+converged enough to permit it. While we can't release a final draft of a CDD
+for an Android software version before the first flagship device ships with
+that software, final CDDs will always be released after the first device.
+However, wherever practical we will make draft versions of CDDs available.</p>
+<h3 id="how-are-device-manufacturers-compatibility-claims-validated">How are device manufacturers' compatibility claims validated?</h3>
+<p>There is no validation process for Android device compatibility. However,
+if the device is to include Google Play, Google will typically validate
+the device for compatibility before agreeing to license the Google Play client
+software.</p>
+<h3 id="what-happens-if-a-device-that-claims-compatibility-is-later-found-to-have-compatibility-problems">What happens if a device that claims compatibility is later found to have compatibility problems?</h3>
+<p>Typically, Google's relationships with Google Play licensees allow us to
+ask them to release updated system images that fix the problems.</p>
+<h2 id="compatibility-test-suite">Compatibility Test Suite</h2>
+<h3 id="what-is-the-purpose-of-the-cts">What is the purpose of the CTS?</h3>
+<p>The Compatibility Test Suite is a tool used by device manufacturers to help
+ensure their devices are compatible, and to report test results for
+validations. The CTS is intended to be run frequently by OEMs throughout the
+engineering process to catch compatibility issues early.</p>
+<h3 id="what-kinds-of-things-does-the-cts-test">What kinds of things does the CTS test?</h3>
+<p>The CTS currently tests that all of the supported Android strong-typed APIs
+are present and behave correctly. It also tests other non-API system
+behaviors such as application lifecycle and performance. We plan to add
+support in future CTS versions to test "soft" APIs such as Intents as
+well.</p>
+<h3 id="will-the-cts-reports-be-made-public">Will the CTS reports be made public?</h3>
+<p>Yes. While not currently implemented, Google intends to provide web-based
+self-service tools for OEMs to publish CTS reports so that they can be
+viewed by anyone. CTS reports can be shared as widely as manufacturers
+prefer.</p>
+<h3 id="how-is-the-cts-licensed">How is the CTS licensed?</h3>
+<p>The CTS is licensed under the same Apache Software License 2.0 that the
+bulk of Android uses.</p>
+<h3 id="does-the-cts-accept-contributions">Does the CTS accept contributions?</h3>
+<p>Yes please! The Android Open-Source Project accepts contributions to
+improve the CTS in the same way as for any other component. In fact,
+improving the coverage and quality of the CTS test cases is one of the best
+ways to help out Android.</p>
+<h3 id="can-anyone-use-the-cts-on-existing-devices">Can anyone use the CTS on existing devices?</h3>
+<p>The Compatibility Definition Document requires that compatible devices
+implement the 'adb' debugging utility. This means that any compatible device
+-- including ones available at retail -- must be able to run the CTS
+tests.</p>
+
+
+<h2>Security</h2>
+<h3 id="secure">Is Android secure?</h3>
+
+<p>The security and privacy of our users' data is of primary importance to the
+Android Open Source Project. We are dedicated to building and maintaining one
+of the most secure mobile platforms available while still fulfilling our goal
+of opening the mobile device space to innovation and competition.</p>
+
+<p> A comprehensive overview of the <a
+href="http://source.android.com/tech/security/index.html">Android
+security model and Android security processes</a> is provided in the Android
+Open Source Project Website.</p>
+
+<p>Application developers play an important part in the security of Android.
+The Android Platform provides developers with a rich <a
+href="http://code.google.com/android/devel/security.html">security model</a>
+that to request the capabilities, or access, needed by their
+application and to define new capabilities that other applications can request.
+The Android user can choose to grant or deny an application's request for
+certain capabilities on the handset.</p>
+
+<p>We have made great efforts to secure the Android platform, but it is
+inevitable that security bugs will be found in any system of this complexity.
+Therefore, the Android team works hard to find new bugs internally and responds
+quickly and professionally to vulnerability reports from external researchers.
+</p>
+
+
+<h3 id="issue">I think I found a security flaw. How do I
+report it?</h3>
+
+<p>You can reach the Android security team at <a
+href="mailto:security@android.com">security@android.com</a>. If you like, you
+can protect your message using our <a
+href="http://code.google.com/android/security_at_android_dot_com.txt">PGP
+key</a>.</p>
+
+<p>We appreciate researchers practicing responsible disclosure by emailing us
+with a detailed summary of the issue and keeping the issue confidential while
+users are at risk. In return, we will make sure to keep the researcher informed
+of our progress in issuing a fix. </p>
+
+
+<h3 id="informed">How can I stay informed about Android security?</h3>
+
+<p>For general discussion of Android platform security, or how to use
+security features in your Android application, please subscribe to <a
+href="http://groups.google.com/group/android-security-discuss">android-security-discuss</a>.
+</p>
+
+
+<h3 id="use">How do I securely use my Android phone?</h3>
+
+<p>Android was designed so that you can safely use your phone without making
+any changes to the device or installing any special software. Android applications
+run in an Application Sandbox that limits access to sensitive information or data
+with the users permission.</p>
+
+<p>To fully benefit from the security protections in Android, it is important that
+users only download and install software from known sources.</p>
+
+<p>As an open platform, Android allows users to visit any website and load
+software from any developer onto a device. As with a home PC, the user must be
+aware of who is providing the software they are downloading and must decide
+whether they want to grant the application the capabilities it requests.
+This decision can be informed by the user's judgment of the software
+developer's trustworthiness, and where the software came from.</p>
+
+
+<h3 id="malware">I think I found malicious software being
+distributed for Android. How can I help?</h3>
+
+<p>Like any other platform, it will be possible for unethical developers
+to create malicious software, known as <a
+href="http://en.wikipedia.org/wiki/Malware">malware</a>, for Android. If you
+think somebody is trying to spread malware, please let us know at <a
+href="mailto:security@android.com">security@android.com</a>. Please include as
+much detail about the application as possible, with the location it is
+being distributed from and why you suspect it of being malicious software.</p>
+
+<p>The term <i>malicious software</i> is subjective, and we cannot make an
+exhaustive definition. Some examples of what the Android Security Team believes
+to be malicious software is any application that:
+<ul>
+ <li>uses a bug or security vulnerability to gain permissions that have not
+ been granted by the user</li>
+ <li>shows the user unsolicited messages (especially messages urging the
+ user to buy something);</li>
+ <li>resists (or attempts to resist) the user's effort to uninstall it;</li>
+ <li>attempts to automatically spread itself to other devices;</li>
+ <li>hides its files and/or processes;</li>
+ <li>discloses the user's private information to a third party, without the
+ user's knowledge and consent;</li>
+ <li>destroys the user's data (or the device itself) without the user's
+ knowledge and consent;</li>
+ <li>impersonates the user (such as by sending email or buying things from a
+ web store) without the user's knowledge and consent; or</li>
+ <li>otherwise degrades the user's experience with the device.</li>
+</ul>
+</p>
+
+<h3 id="fixes">How do Android-powered devices receive security
+fixes?</h3>
+
+<p>The manufacturer of each device is responsible for distributing software
+upgrades for it, including security fixes. Many devices will update themselves
+automatically with software downloaded "over the air", while some devices
+require the user to upgrade them manually.</p>
+
+<p>Google provides software updates for a number of Android devices, including
+the <a href="http://www.google.com/nexus">Nexus</a>
+series of devices, using an "over the air" (OTA) update. These updates may include
+security fixes as well as new features.</p>
+
+<h3 id="directfix">Can I get a fix directly from the
+Android Platform Project?</h3>
+
+<p>Android is a mobile platform that is released as open source and
+available for free use by anybody. This means that there are many
+Android-based products available to consumers, and most of them are created
+without the knowledge or participation of the Android Open Source Project. Like
+the maintainers of other open source projects, we cannot build and release
+patches for the entire ecosystem of products using Android. Instead, we will
+work diligently to find and fix flaws as quickly as possible and to distribute
+those fixes to the manufacturers of the products through the open source project.</p>
+
+<p>If you are making an Android-powered device and would like to know how you can
+properly support your customers by keeping abreast of software updates, please
+contact us at <a
+href="mailto:info@openhandsetalliance.com">info@openhandsetalliance.com</a>.</p>
+
diff --git a/src/source/flashing.jd b/src/source/flashing.jd
new file mode 100644
index 0000000..fa99cf5
--- /dev/null
+++ b/src/source/flashing.jd
@@ -0,0 +1,29 @@
+page.title=Flashing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>To flash a device, you will need to use <code>fastboot</code>. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with</p>
+<pre><code>$ adb reboot bootloader
+</code></pre>
+<p>Once the device is in fastboot mode, run </p>
+<pre><code>$ fastboot flashall -w
+</code></pre>
+<p>The <code>-w</code> option wipes the <code>/data</code> partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.</p>
+<h1 id="emulating">Emulating</h1>
+<p>To run the emulator, type</p>
+<pre><code>$ emulator
+</code></pre>
\ No newline at end of file
diff --git a/src/source/flashing.md b/src/source/flashing.md
deleted file mode 100644
index 80f4979..0000000
--- a/src/source/flashing.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Flashing #
-
-To flash a device, you will need to use `fastboot`. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with
-
- $ adb reboot bootloader
-
-Once the device is in fastboot mode, run
-
- $ fastboot flashall -w
-
-The `-w` option wipes the `/data` partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.
-
-# Emulating #
-
-To run the emulator, type
-
- $ emulator
-
-
diff --git a/src/source/getting-started.jd b/src/source/getting-started.jd
new file mode 100644
index 0000000..bf87be8
--- /dev/null
+++ b/src/source/getting-started.jd
@@ -0,0 +1,22 @@
+page.title=Getting Started
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Thanks for your interest in Android! To begin working with the platform, whether
+you're creating a custom version of Android for existing devices or if you are
+building a hardware device from scratch, you'll need to set up your machine to download and build the
+source.
\ No newline at end of file
diff --git a/src/source/git-repo.html b/src/source/git-repo.html
index 83b2ee7..e85ebc2 100644
--- a/src/source/git-repo.html
+++ b/src/source/git-repo.html
@@ -1,7 +1,6 @@
-<!DOCTYPE html>
<html>
<head>
-<meta http-equiv="refresh" content="0;url=/source/version-control.html" />
+<meta http-equiv="refresh" content="0;url=/source/developing.html" />
</head>
<body>
</body>
diff --git a/src/source/git-resources.jd b/src/source/git-resources.jd
new file mode 100644
index 0000000..bced045
--- /dev/null
+++ b/src/source/git-resources.jd
@@ -0,0 +1,33 @@
+page.title=Git Resources
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>For further information on Git, check out these excellent off-site resources:</p>
+<ul>
+<li>
+<p>The <a href="http://book.git-scm.com">Git Community Book</a> (maintained by Scott Chacon) </p>
+</li>
+<li>
+<p><a href="http://git.or.cz/gitwiki/FrontPage">Git Wiki</a></p>
+</li>
+<li>
+<p><a href="http://www.kernel.org/pub/software/scm/git/docs">Git Manual Page</a> </p>
+</li>
+<li>
+<p><a href="http://www.gitcasts.com">GitCasts</a> (Git how-to videos)</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/source/git-resources.md b/src/source/git-resources.md
deleted file mode 100644
index fc33249..0000000
--- a/src/source/git-resources.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Git Resources #
-
-For further information on Git, check out these excellent off-site resources:
-
-- The [Git Community Book](http://book.git-scm.com) (maintained by Scott Chacon)
-
-- [Git Wiki](http://git.or.cz/gitwiki/FrontPage)
-
-- [Git Manual Page](http://www.kernel.org/pub/software/scm/git/docs)
-
-- [GitCasts](http://www.gitcasts.com) (Git how-to videos)
-
-
diff --git a/src/source/index.jd b/src/source/index.jd
new file mode 100644
index 0000000..e39c611
--- /dev/null
+++ b/src/source/index.jd
@@ -0,0 +1,65 @@
+page.title=The Android Source Code
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>
+Android is an open-source software stack created for a wide array of devices
+with different form factors. The primary purpose of Android is to create an
+open software platform available for carriers, OEMs, and developers to make
+their innovative ideas a reality and to create a successful,
+real-world product that improves the mobile experience for end users.
+
+We also wanted to make sure that there was
+no central point of failure, where one industry player could restrict or
+control the innovations of any other. The result is a full, production-quality
+consumer product whose source is open for customization and porting.
+</p>
+
+
+
+
+<h2 id="governance-philosophy">Governance Philosophy</h2
+<p>Android was originated by a group of companies known as the Open
+Handset Alliance, led by Google. Today, many companies -- both original members
+of the OHA and others -- have invested heavily in Android, typically in the form
+of allocating significant engineering resources to improve Android and bring Android devices to market.
+</p>
+<p>The companies that have invested in Android have done so on its merits,
+because we believe that an open platform is necessary. Android is
+intentionally and explicitly an open-source -- as opposed to free software --
+effort: a group of organizations with shared needs has pooled
+resources to collaborate on a single implementation of a shared product.
+The Android philosophy is pragmatic, first and foremost. The objective is
+a shared product that each contributor can tailor and customize.</p>
+
+<p>Uncontrolled customization can, of course, lead to incompatible
+implementations. To prevent this, the Android Open Source Project also maintains the <a href="{@docRoot}compatibility/index.html">Android
+Compatibility Program</a>, which spells out what it means to be "Android
+compatible", and what is required of device builders to achieve that status.
+Anyone can (and will!) use the Android source code for any purpose, and we
+welcome all such uses. However, in order to take part in the shared
+ecosystem of applications that we are building around Android, device builders
+must participate in the Android Compatibility Program.</p>
+
+<p>The Android Open Source Project is led by Google, who
+maintains and further develops Android.
+Although Android consists of multiple subprojects, this is strictly a
+project management technique. We view and manage Android as a single,
+holistic software product, not a "distribution", specification, or collection
+of replaceable parts. Our intent is that device builders port
+Android to a device; they don't implement a specification or curate a
+distribution.</p>
\ No newline at end of file
diff --git a/src/source/index.md b/src/source/index.md
deleted file mode 100644
index 5fdcd58..0000000
--- a/src/source/index.md
+++ /dev/null
@@ -1,53 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Get Involved #
-
-Thanks for your interest in Android! Here are some ways you can get involved
-and help us improve Android. For background on the Android project and our
-goals, check out the [Project Philosophy page](/about/philosophy.html).
-
-## Report Bugs ##
-
-One of the easiest and most effective ways you can help improve Android is
-to file bugs. For more information, visit the [Reporting Bugs](report-bugs.html) page.
-
-Please note that we can't guarantee that any particular bug will be fixed in
-any particular release. To see what happens to your bug once you report it,
-read [Life of a Bug](life-of-a-bug.html).
-
-## Develop Apps ##
-
-We created Android so that all developers can distribute their applications
-to users on an open platform. One of the best ways you can help Android is to
-write cool apps that users love!
-
-To get started, visit [developer.android.com](https://developer.android.com). This site
-provides the information and tools you need to write applications for
-compatible Android devices, using the SDK.
-
-## Contribute to the Code ##
-
-Code is King. We'd love to review any changes you submit, so please check
-out the source, pick a bug or feature, and get coding. Note that the smaller
-and more targetted your patch submissions, the easier it will be for us to
-review them.
-
-You can get started with Android by learning about the [Life of a Patch](life-of-a-patch.html),
-and by learning about `git`, `repo`, and other tools using the links to the left.
-You can also view the activity on all contributions on our
-[Gerrit server](https://android-review.googlesource.com/).
-If you need help along the way, you can join our [discussion groups](/community/index.html).
diff --git a/src/source/initializing.jd b/src/source/initializing.jd
new file mode 100644
index 0000000..029f308
--- /dev/null
+++ b/src/source/initializing.jd
@@ -0,0 +1,262 @@
+page.title=Initializing a Build Environment
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Before you begin, ensure that your system meets the <a href="{@docRoot}source/building.html">minimum requirements</a>.
+
+<h2 id="setup-linux">Setting up a Linux Build Environment</h2>
+
+<h3 id="installing-the-jdk">Installing the JDK</h3>
+<p>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.</p>
+<p>Java 6: for Gingerbread and newer</p>
+<pre><code>$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
+$ sudo apt-get update
+$ sudo apt-get install sun-java6-jdk
+</code></pre>
+<p>Java 5: for Froyo and older</p>
+<pre><code>$ 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
+</code></pre>
+<p><em>Note: The <code>lunch</code> command in the build step will ensure that the Sun JDK is
+used instead of any previously installed JDK.</em></p>
+<h3 id="installing-required-packages-ubuntu-1004-1110">Installing required packages (Ubuntu 10.04 -- 11.10)</h3>
+<p>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.</p>
+<pre><code>$ 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
+</code></pre>
+<p>On Ubuntu 10.10:</p>
+<pre><code>$ sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so
+</code></pre>
+<p>On Ubuntu 11.10:</p>
+<pre><code>$ sudo apt-get install libx11-dev:i386
+</code></pre>
+<h3 id="installing-required-packages-ubuntu-1204">Installing required packages (Ubuntu 12.04)</h3>
+<p>Building on Ubuntu 12.04 is currently only experimentally supported and is not
+guaranteed to work on branches other than master.</p>
+<pre><code>$ 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 openjdk-6-jdk 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
+</code></pre>
+<h3 id="configuring-usb-access">Configuring USB Access</h3>
+<p>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.</p>
+<p>The recommended approach is to create a file
+<code>/etc/udev/rules.d/51-android.rules</code> (as the root user) and to copy
+the following lines in it. <code><username></code> must be replaced by the
+actual username of the user who is authorized to access the phones
+over USB.</p>
+<pre><code># 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 mako/manta (Nexus 4, Nexus 10)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0600", OWNER="<username>"
+# fastboot protocol on mako/manta (Nexus 4, Nexus 10)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="0600", OWNER="<username>"
+</code></pre>
+<p>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.</p>
+<p>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.</p>
+<p><a name="ccache"></a></p>
+<h3 id="setting-up-ccache">Setting up ccache</h3>
+<p>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.</p>
+<p>Put the following in your .bashrc or equivalent.</p>
+<pre><code>export USE_CCACHE=1
+</code></pre>
+<p>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.</p>
+<pre><code>export CCACHE_DIR=<path-to-your-cache-directory>
+</code></pre>
+<p>The suggested cache size is 50-100GB.
+You will need to run the following command once you have downloaded
+the source code:</p>
+<pre><code>prebuilts/misc/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>When building Ice Cream Sandwich (4.0.x) or older, ccache is in
+a different location:</p>
+<pre><code>prebuilt/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>This setting is stored in the CCACHE_DIR and is persistent.</p>
+<h3 id="using-a-separate-output-directory">Using a separate output directory</h3>
+<p>By default, the output of each build is stored in the out/
+subdirectory of the matching source tree.</p>
+<p>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.</p>
+<p>To set this up, export the <code>OUT_DIR_COMMON_BASE</code> variable
+to point to the location where your output directories
+will be stored.</p>
+<pre><code>export OUT_DIR_COMMON_BASE=<path-to-your-out-directory>
+</code></pre>
+<p>The output directory for each separate source tree will be
+named after the directory holding the source tree.</p>
+<p>For instance, if you have source trees as <code>/source/master1</code>
+and <code>/source/master2</code> and <code>OUT_DIR_COMMON_BASE</code> is set to
+<code>/output</code>, the output directories will be <code>/output/master1</code>
+and <code>/output/master2</code>.</p>
+<p>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.</p>
+<p>This is only supported on Jelly Bean (4.1) and newer,
+including the master branch.</p>
+<h2 id="setting-up-a-mac-os-x-build-environment">Setting up a Mac OS X build environment</h2>
+<p>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.</p>
+<p>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.</p>
+<h3 id="creating-a-case-sensitive-disk-image">Creating a case-sensitive disk image</h3>
+<p>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.</p>
+<p>You can also create it from a shell with the following command:</p>
+<pre><code># hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg
+</code></pre>
+<p>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 <code>~/.bash_profile</code> to mount the image when you execute "mountAndroid":</p>
+<pre><code># mount the android file image
+function mountAndroid { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
+</code></pre>
+<p>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.</p>
+<h3 id="master-branch">Master branch</h3>
+<p>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.</p>
+<p>The remaining sections for Mac OS X only apply to those who wish to build
+earlier branches.</p>
+<h3 id="branch-40x-and-all-earlier-branches">Branch 4.0.x and all earlier branches</h3>
+<p>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.</p>
+<h3 id="installing-required-packages">Installing required packages</h3>
+<ul>
+<li>
+<p>Install Xcode from <a href="http://developer.apple.com/">the Apple developer site</a>.
+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.</p>
+</li>
+<li>
+<p>Install MacPorts from <a href="http://www.macports.org/install.php">macports.org</a>.</p>
+<p><em>Note: Make sure that <code>/opt/local/bin</code> appears in your path BEFORE <code>/usr/bin</code>. If not, add</em> </p>
+<pre><code>export PATH=/opt/local/bin:$PATH
+</code></pre>
+<p><em>to your <code>~/.bash_profile</code>.</em></p>
+</li>
+<li>
+<p>Get make, git, and GPG packages from MacPorts: </p>
+<pre><code>$ POSIXLY_CORRECT=1 sudo port install gmake libsdl git-core gnupg
+</code></pre>
+<p>If using Mac OS 10.4, also install bison:</p>
+<pre><code>$ POSIXLY_CORRECT=1 sudo port install bison
+</code></pre>
+</li>
+</ul>
+<h3 id="reverting-from-make-382">Reverting from make 3.82</h3>
+<p>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:</p>
+<ul>
+<li>
+<p>Edit <code>/opt/local/etc/macports/sources.conf</code> and add a line that says</p>
+<pre><code>file:///Users/Shared/dports
+</code></pre>
+<p>above the rsync line. Then create this directory: </p>
+<pre><code>$ mkdir /Users/Shared/dports
+</code></pre>
+</li>
+<li>
+<p>In the new <code>dports</code> directory, run </p>
+<pre><code>$ svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
+</code></pre>
+</li>
+<li>
+<p>Create a port index for your new local repository: </p>
+<pre><code>$ portindex /Users/Shared/dports
+</code></pre>
+</li>
+<li>
+<p>Finally, install the old version of gmake with </p>
+<pre><code>$ sudo port install gmake @3.81
+</code></pre>
+</li>
+</ul>
+<h3 id="setting-a-file-descriptor-limit">Setting a file descriptor limit</h3>
+<p>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. </p>
+<p>To increase the cap, add the following lines to your <code>~/.bash_profile</code>: </p>
+<pre><code># set the number of open files to be 1024
+ulimit -S -n 1024
+</code></pre>
diff --git a/src/source/initializing.md b/src/source/initializing.md
deleted file mode 100644
index ac50857..0000000
--- a/src/source/initializing.md
+++ /dev/null
@@ -1,340 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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.5 -- 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-core 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 openjdk-6-jdk 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 (Nexus 7)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0600", OWNER="<username>"
- # fastboot protocol on grouper (Nexus 7)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", 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.jd b/src/source/known-issues.jd
new file mode 100644
index 0000000..33ceb16
--- /dev/null
+++ b/src/source/known-issues.jd
@@ -0,0 +1,181 @@
+page.title=Known Issues
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Even with our best care, small problems sometimes slip in. This page keeps
+track of the known issues around using the Android source code.</p>
+<h2 id="missing-cts-native-xml-generator">Missing CTS Native XML Generator</h2>
+<p><strong>Symptom</strong>: On some builds of IceCreamSandwich and later, the following
+warning is printed early during the build:
+<code>/bin/bash: line 0: cd: cts/tools/cts-native-xml-generator/src/res: No
+such file or directory</code></p>
+<p><strong>Cause</strong>: Some makefile references that path, which doesn't exist.</p>
+<p><strong>Fix</strong>: None. This is a harmless warning.</p>
+<h2 id="black-gingerbread-emulator">Black Gingerbread Emulator</h2>
+<p><strong>Symptom</strong>: The emulator built directly from the gingerbread branch
+doesn't start and stays stuck on a black screen.</p>
+<p><strong>Cause</strong>: The gingerbread branch uses version R7 of the emulator,
+which doesn't have all the features necessary to run recent versions
+of gingerbread.</p>
+<p><strong>Fix</strong>: Use version R12 of the emulator, and a newer kernel that matches
+those tools. No need to do a clean build.</p>
+<pre><code>$ repo forall platform/external/qemu -c git checkout aosp/tools_r12
+$ make
+$ emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7
+</code></pre>
+<h2 id="emulator-built-on-macos-107-lion-doesnt-work">Emulator built on MacOS 10.7 Lion doesn't work.</h2>
+<p><strong>Symptom</strong>: The emulator (any version) built on MacOS 10.7 Lion
+and/or on XCode 4.x doesn't start.</p>
+<p><strong>Cause</strong>: Some change in the development environment causes
+the emulator to be compiled in a way that prevents it from working.</p>
+<p><strong>Fix</strong>: Use an emulator binary from the SDK, which is built on
+MacOS 10.6 with XCode 3 and works on MacOS 10.7.</p>
+<h2 id="difficulties-syncing-the-source-code-proxy-issues">Difficulties syncing the source code (proxy issues).</h2>
+<p><strong>Symptom</strong>: <code>repo init</code> or <code>repo sync</code> fail with http errors,
+typically 403 or 500.</p>
+<p><strong>Cause</strong>: There are quite a few possible causes, most often
+related to http proxies, which have difficulties handling the
+large amounts of data getting transfered.</p>
+<p><strong>Fix</strong>: While there's no general solution, using python 2.7
+and explicitly using <code>repo sync -j1</code> have been reported to
+improve the situation for some users.</p>
+<h2 id="difficulties-syncing-the-source-tree-virtualbox-ethernet-issues">Difficulties syncing the source tree (VirtualBox Ethernet issues).</h2>
+<p><strong>Symptom</strong>: When running <code>repo sync</code> in some VirtualBox installations,
+the process hangs or fails with a variety of possible symptoms.
+One such symptom is
+<code>DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble)</code>.</p>
+<p><strong>Cause</strong>: 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.</p>
+<p><strong>Fix</strong>: Configure VirtualBox to use bridged network instead of NAT.</p>
+<h2 id="difficulties-syncing-the-source-tree-dns-issues">Difficulties syncing the source tree (DNS issues).</h2>
+<p><strong>Symptom</strong>: When running <code>repo sync</code>, the process fails with
+various errors related to not recognizing the hostname. One such
+error is <code><urlopen error [Errno -2] Name or service not known></code>.</p>
+<p><strong>Cause</strong>: 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).</p>
+<p><strong>Fix</strong>: Manually resolve the relevant hostnames, and hard-code
+those results locally.</p>
+<p>You can resolve them with the <code>nslookup</code> command, which will give
+you one numerical IP address for each of those (typically in the
+"Address" part of the output).</p>
+<pre><code>$ nslookup googlesource.com
+$ nslookup android.googlesource.com
+</code></pre>
+<p>You can then hard-code them locally by editing <code>/etc/hosts</code>, and
+adding two lines in that file, of the form:</p>
+<pre><code>aaa.bbb.ccc.ddd googlesource.com
+eee.fff.ggg.hhh android.googlesource.com
+</code></pre>
+<p>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 <code>etc/hosts</code> accordingly.</p>
+<h2 id="difficulties-syncing-the-source-tree-tcp-issues">Difficulties syncing the source tree (TCP issues).</h2>
+<p><strong>Symptom</strong>: <code>repo sync</code> hangs while syncing, often when it's
+completed 99% of the sync.</p>
+<p><strong>Cause</strong>: Some settings in the TCP/IP stack cause difficulties
+in some network environments, such that <code>repo sync</code> neither completes
+nor fails.</p>
+<p><strong>Fix</strong>: On linux, <code>sysctl -w net.ipv4.tcp_window_scaling=0</code>. On
+MacOS, disable the rfc1323 extension in the network settings.</p>
+<h2 id="make-snod-and-emulator-builds"><code>make snod</code> and emulator builds.</h2>
+<p><strong>Symptom</strong>: When using <code>make snod</code> (make system no dependencies)
+on emulator builds, the resulting build doesn't work.</p>
+<p><strong>Cause</strong>: 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.</p>
+<p><strong>Fix</strong>: Locally disable Dex optimizations with
+<code>export WITH_DEXPREOPT=false</code>, delete the existing optimized
+versions with <code>make installclean</code> and run a full build to
+re-generate non-optimized versions. After that, <code>make snod</code>
+will work.</p>
+<h2 id="permission-denied-during-builds">"Permission Denied" during builds.</h2>
+<p><strong>Symptom</strong>: All builds fail with "Permission Denied", possibly
+along with anti-virus warnings.</p>
+<p><strong>Cause</strong>: Some anti-virus programs mistakenly recognize some
+source files in the Android source tree as if they contained
+viruses.</p>
+<p><strong>Fix</strong>: 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.</p>
+<h2 id="camera-and-gps-dont-work-on-galaxy-nexus">Camera and GPS don't work on Galaxy Nexus.</h2>
+<p><strong>Symptom</strong>: Camera and GPS don't work on Galaxy Nexus.
+As an example, the Camera application crashes as soon as it's
+launched.</p>
+<p><strong>Cause</strong>: Those hardware peripherals require proprietary
+libraries that aren't available in the Android Open Source
+Project.</p>
+<p><strong>Fix</strong>: None.</p>
+<h2 id="build-errors-related-to-using-the-wrong-compiler">Build errors related to using the wrong compiler.</h2>
+<p><strong>Symptom</strong>: The build fails with various symptoms. One
+such symptom is <code>cc1: error: unrecognized command line option "-m32"</code></p>
+<p><strong>Cause</strong>: 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.</p>
+<p><strong>Fix</strong>: Use a "clean" shell, in which no previous
+actions could have swapped the default compiler.</p>
+<h2 id="build-errors-caused-by-non-default-tool-settings">Build errors caused by non-default tool settings.</h2>
+<p><strong>Symptom</strong>: The build fails with various symptoms, possibly
+complinaing about missing files or files that have the
+wrong format. One such symptom is <code>member [...] in archive is not an object</code>.</p>
+<p><strong>Cause</strong>: 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 <code>CDPATH</code> and <code>GREP_OPTIONS</code>.</p>
+<p><strong>Fix</strong>: Build Android in an environment that has as few
+customizations as possible.</p>
+<h2 id="build-error-with-40x-and-earlier-on-macos-107">Build error with 4.0.x and earlier on MacOS 10.7.</h2>
+<p><strong>Symptom</strong>: Building IceCreamSandwich 4.0.x (and older
+versions) fails on MacOS 10.7 with errors similar to this:
+<code>Undefined symbols for architecture i386: "_SDL_Init"</code></p>
+<p><strong>Cause</strong>: 4.0.x is not compatible with MacOS 10.7.</p>
+<p><strong>Fix</strong>: Either downgrade to MacOS 10.6, or use the master
+branch, which can be built on MacOS 10.7.</p>
+<pre><code>$ repo init -b master
+$ repo sync
+</code></pre>
+<h2 id="build-error-on-macos-with-xcode-43">Build error on MacOS with XCode 4.3.</h2>
+<p><strong>Symptom</strong>: All builds fail when using XCode 4.3.</p>
+<p><strong>Cause</strong>: XCode 4.3 switched the default compiler from
+gcc to llvm, and llvm rejects code that used to be
+accepted by gcc.</p>
+<p><strong>Fix</strong>: Use XCode 4.2.</p>
+<h2 id="build-error-with-40x-and-earlier-on-ubuntu-1110">Build error with 4.0.x and earlier on Ubuntu 11.10.</h2>
+<p><strong>Symptom</strong>: Building IceCreamSandwich 4.0.x (and older
+versions) on Ubuntu 11.10 and newer fails with errors similar to this:
+<code><command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]</code></p>
+<p><strong>Cause</strong>: 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.</p>
+<p><strong>Fix</strong>: Either downgrade to Ubuntu 10.04, or use the master
+branch, which can be compiled on Ubuntu 11.10 and newer.</p>
+<pre><code>$ repo init -b master
+$ repo sync
+</code></pre>
diff --git a/src/source/known-issues.md b/src/source/known-issues.md
deleted file mode 100644
index 74579de..0000000
--- a/src/source/known-issues.md
+++ /dev/null
@@ -1,236 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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 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, GPS and NFC don't work on Galaxy Nexus. ##
-
-**Symptom**: Camera, GPS and NFC 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/licenses.jd b/src/source/licenses.jd
new file mode 100644
index 0000000..7db245c
--- /dev/null
+++ b/src/source/licenses.jd
@@ -0,0 +1,104 @@
+page.title=Licenses
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>The Android Open Source Project uses a few <a href="http://www.opensource.org/">open source initiative</a>
+approved open source licenses for our software.</p>
+<h2 id="android-open-source-project-license">Android Open Source Project license</h2>
+<p>The preferred license for the Android Open Source Project is the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
+Software License, 2.0</a> ("Apache 2.0"),
+and the majority of the Android software is licensed
+with Apache 2.0. While the project will strive to adhere to the preferred
+license, there may be exceptions which will be handled on a case-by-case
+basis. For example, the Linux kernel patches are under the GPLv2 license with
+system exceptions, which can be found on <a href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a>.</p>
+<h2 id="contributor-license-grants">Contributor License Grants</h2>
+<p>All <em>individual</em> contributors (that is, contributors making contributions
+only on their own behalf) of ideas, code, or documentation to the Android Open
+Source Project will be required to complete, sign, and submit an <a href="cla-individual.html">Individual
+Contributor License Grant</a>. The grant can be executed online through the
+<a href="https://android-review.googlesource.com/#/settings/agreements">code review tool</a>.
+The grant clearly defines the terms under which intellectual
+property has been contributed to the Android Open Source Project. This license
+is for your protection as a contributor as well as the protection of the
+project; it does not change your rights to use your own contributions for any
+other purpose.</p>
+<p>For a <em>corporation</em> (or other entity) that has assigned employees to
+work on the Android Open Source Project, a <a href="cla-corporate.pdf">Corporate
+Contributor License Grant</a> is available.
+This version of the grant allows a
+corporation to authorize contributions submitted by its designated employees
+and to grant copyright and patent licenses. Note that a Corporate Contributor
+License Grant does not remove the need for any developer to sign their own
+Individual Contributor License Grant as an individual, to cover any of their
+contributions which are <em>not</em> owned by the corporation signing the
+Corporate Contributor License Grant.</p>
+<p>Please note that we based our grants on the ones that the
+<a href="http://www.apache.org">Apache Software Foundation</a> uses, which can
+be found on <a href="http://www.apache.org/licenses/">the Apache web site</a>.</p>
+<h2 id="why-apache-software-license">Why Apache Software License?</h2>
+<p>We are sometimes asked why Apache Software License 2.0 is the preferred
+license for Android. For userspace (that is, non-kernel) software, we do in
+fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
+licenses such as LGPL.</p>
+<p>Android is about freedom and choice. The purpose of Android is promote
+openness in the mobile world, but we don't believe it's possible to predict or
+dictate all the uses to which people will want to put our software. So, while
+we encourage everyone to make devices that are open and modifiable, we don't
+believe it is our place to force them to do so. Using LGPL libraries would
+often force them to do so.</p>
+<p>Here are some of our specific concerns:</p>
+<ul>
+<li>
+<p>LGPL (in simplified terms) requires either: shipping of source to the
+application; a written offer for source; or linking the LGPL-ed library
+dynamically and allowing users to manually upgrade or replace the library.
+Since Android software is typically shipped in the form of a static system
+image, complying with these requirements ends up restricting OEMs' designs.
+(For instance, it's difficult for a user to replace a library on read-only
+flash storage.)</p>
+</li>
+<li>
+<p>LGPL requires allowance of customer modification and reverse
+engineering for debugging those modifications. Most device makers do
+not want to have to be bound by these terms, so to minimize the burden on
+these companies we minimize usage of LGPL software in userspace.</li></p>
+</li>
+<li>
+<p>Historically, LGPL libraries have been the source of a large number
+of compliance problems for downstream device makers and application
+developers. Educating engineers on these issues is difficult and slow-going,
+unfortunately. It's critical to Android's success that it be as easy as
+possible for device makers to comply with the licenses. Given the
+difficulties with complying with LGPL in the past, it is most prudent to
+simply not use LGPL libraries if we can avoid it.</p>
+</li>
+</ul>
+<p>The issues discussed above are our reasons for preferring ASL2.0 for
+our own code. They aren't criticisms of LGPL or other licenses. We do
+feel strongly on this topic, even to the point where we've gone out of our
+way to make sure as much code as possible is ASL2.0. However, we love all free
+and open source licenses, and respect others' opinions and preferences. We've
+simply decided that ASL2.0 is the right license for our goals.</p>
\ No newline at end of file
diff --git a/src/source/licenses.md b/src/source/licenses.md
deleted file mode 100644
index 0405e84..0000000
--- a/src/source/licenses.md
+++ /dev/null
@@ -1,103 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Licenses #
-
-The Android Open Source Project uses a few [open source initiative](http://www.opensource.org/)
-approved open source licenses for our software.
-
-## Android Open Source Project license ##
-
-The preferred license for the Android Open Source Project is the [Apache
-Software License, 2.0](http://www.apache.org/licenses/LICENSE-2.0) ("Apache 2.0"),
-and the majority of the Android software is licensed
-with Apache 2.0. While the project will strive to adhere to the preferred
-license, there may be exceptions which will be handled on a case-by-case
-basis. For example, the Linux kernel patches are under the GPLv2 license with
-system exceptions, which can be found on [kernel.org](http://www.kernel.org/pub/linux/kernel/COPYING).
-
-## Contributor License Grants ##
-
-All *individual* contributors (that is, contributors making contributions
-only on their own behalf) of ideas, code, or documentation to the Android Open
-Source Project will be required to complete, sign, and submit an [Individual
-Contributor License Grant](cla-individual.html). The grant can be executed online through the
-[code review tool](https://android-review.googlesource.com/#/settings/agreements).
-The grant clearly defines the terms under which intellectual
-property has been contributed to the Android Open Source Project. This license
-is for your protection as a contributor as well as the protection of the
-project; it does not change your rights to use your own contributions for any
-other purpose.
-
-For a *corporation* (or other entity) that has assigned employees to
-work on the Android Open Source Project, a [Corporate
-Contributor License Grant](cla-corporate.pdf) is available.
-This version of the grant allows a
-corporation to authorize contributions submitted by its designated employees
-and to grant copyright and patent licenses. Note that a Corporate Contributor
-License Grant does not remove the need for any developer to sign their own
-Individual Contributor License Grant as an individual, to cover any of their
-contributions which are *not* owned by the corporation signing the
-Corporate Contributor License Grant.
-
-Please note that we based our grants on the ones that the
-[Apache Software Foundation](http://www.apache.org) uses, which can
-be found on [the Apache web site](http://www.apache.org/licenses/).
-
-## Why Apache Software License? ##
-
-We are sometimes asked why Apache Software License 2.0 is the preferred
-license for Android. For userspace (that is, non-kernel) software, we do in
-fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
-licenses such as LGPL.
-
-Android is about freedom and choice. The purpose of Android is promote
-openness in the mobile world, but we don't believe it's possible to predict or
-dictate all the uses to which people will want to put our software. So, while
-we encourage everyone to make devices that are open and modifiable, we don't
-believe it is our place to force them to do so. Using LGPL libraries would
-often force them to do so.
-
-Here are some of our specific concerns:
-
-- LGPL (in simplified terms) requires either: shipping of source to the
-application; a written offer for source; or linking the LGPL-ed library
-dynamically and allowing users to manually upgrade or replace the library.
-Since Android software is typically shipped in the form of a static system
-image, complying with these requirements ends up restricting OEMs' designs.
-(For instance, it's difficult for a user to replace a library on read-only
-flash storage.)
-
-- LGPL requires allowance of customer modification and reverse
-engineering for debugging those modifications. Most device makers do
-not want to have to be bound by these terms, so to minimize the burden on
-these companies we minimize usage of LGPL software in userspace.</li>
-
-- Historically, LGPL libraries have been the source of a large number
-of compliance problems for downstream device makers and application
-developers. Educating engineers on these issues is difficult and slow-going,
-unfortunately. It's critical to Android's success that it be as easy as
-possible for device makers to comply with the licenses. Given the
-difficulties with complying with LGPL in the past, it is most prudent to
-simply not use LGPL libraries if we can avoid it.
-
-The issues discussed above are our reasons for preferring ASL2.0 for
-our own code. They aren't criticisms of LGPL or other licenses. We do
-feel strongly on this topic, even to the point where we've gone out of our
-way to make sure as much code as possible is ASL2.0. However, we love all free
-and open source licenses, and respect others' opinions and preferences. We've
-simply decided that ASL2.0 is the right license for our goals.
-
diff --git a/src/source/life-of-a-bug.jd b/src/source/life-of-a-bug.jd
new file mode 100644
index 0000000..6f3b2c3
--- /dev/null
+++ b/src/source/life-of-a-bug.jd
@@ -0,0 +1,189 @@
+page.title=Life of a Bug
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>The Android Open Source project maintains a public issue tracker where you
+can report bugs and request features for the Android software stack. (For
+details on this issue tracker, please see the <a href="report-bugs.html">Reporting Bugs</a> page).
+Reporting bugs is great (thank you!), but what happens to a bug report once
+you file it? This page describes the Life of a Bug.</p>
+<p>*Please note: the Android Open Source Project (AOSP) issue tracker is
+intended only for bugs and feature requests related to the Android software
+stack. Because many users find their way here looking for the Google apps for
+Android (such as Gmail and so on), we have components set up for their
+convenience. However, these apps are not part of Android, and any issues
+reported on these components are not guaranteed to to receive attention.
+Most notably, to report issues related to Google Play, you should visit the
+<a href="https://support.google.com/googleplay/">Google Play Support Forum</a>.</p>
+<p>Here's the life of a bug, in a nutshell:</p>
+<ol>
+<li>
+<p>A bug is filed, and has the state "New".</p>
+</li>
+<li>
+<p>An AOSP contributor periodically reviews and triages bugs. Bugs are
+triaged into one of four "buckets": New, Open, No-Action, or Resolved.</p>
+</li>
+<li>
+<p>Each bucket includes a number of states that provide more detail on the
+fate of the issue.</p>
+</li>
+<li>
+<p>Bugs in the "Resolved" bucket will eventually be included in a future
+release of the Android software.</p>
+</li>
+</ol>
+<h1 id="bucket-details">Bucket Details</h1>
+<p>Here is some additional information on each bucket, what it means, and how
+it's handled.</p>
+<h2 id="new-issues">New Issues</h2>
+<p>New issues include bug reports that are not yet being acted upon. The two
+states are:</p>
+<ul>
+<li>
+<p><em>New:</em>
+ The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)</p>
+</li>
+<li>
+<p><em>NeedsInfo:</em>
+ The bug report has insufficient information to act
+upon. The person who reported the bug needs to provide additional detail
+before it can be triaged. If enough time passes and no new information is
+provided, the bug may be closed by default, as one of the No-Action
+states.</p>
+</li>
+</ul>
+<h2 id="open-issues">Open Issues</h2>
+<p>This bucket contains bugs that need action, but which are still
+unresolved, pending a change to the source code.</p>
+<ul>
+<li>
+<p><em>Unassigned:</em>
+ The bug report has been recognized as an adequately
+detailed report of a legitimate issue, but has not yet been assigned to an
+AOSP contributor to be fixed. Typically, bugs in this state are considered low
+priority, at least insofar that if they were high priority, they'd be assigned
+to a contributor.</p>
+</li>
+<li>
+<p><em>Reviewed:</em>
+ Like <em>Unassigned</em>, but the issue
+represented is being tracked in a separate bug database. For example, the bug
+might have been reported via an internal bug-tracking system,
+which is considered the "master" copy. (For instance, Google maintains one
+such private issue tracker, intended primarily for bugs which contain
+sensitive information which can't be revealed publicly.)</p>
+</li>
+<li>
+<p><em>Assigned:</em>
+ Like <em>Unassigned</em>, but the bug has been
+actually assigned to a specific contributor to fix.</p>
+</li>
+</ul>
+<p>Typically, a given bug will start in <em>Unassigned</em>, where it
+will remain until it is associated with a specific upcoming release, at which
+point it will enter <em>Reviewed</em> or <em>Assigned</em>. However,
+note that this isn't a guarantee, and it's not uncommon for bugs to go from
+<em>Unassigned</em> to one of the Resolved states.</p>
+<p>In general, if a bug is in one of these Open states, the AOSP team has
+recognized it as a legitimate issue and will fix it according to the product
+priorities and milestones. However, it's impossible to guarantee a fix in time
+for any particular release.</p>
+<h2 id="no-action-issues">No-Action Issues</h2>
+<p>This bucket contains bugs that have for one reason or another been
+determined to not require any action.</p>
+<ul>
+<li>
+<p><em>Spam:</em>
+ A kind soul sent us some delicious pork products, that we,
+regrettably, do not want.</p>
+</li>
+<li>
+<p><em>Question:</em>
+ Someone mistook the issue tracker for a help forum.
+(This is not as uncommon as you might think: many users whose native language
+isn't English misunderstand the site and make this mistake.)</p>
+</li>
+<li>
+<p><em>Unreproducible:</em>
+ An AOSP contributor attempted to reproduce the
+behavior described, and was unable to do so. This sometimes means that the bug
+is legitimate but simply rare or difficult to reproduce, and sometimes means
+that the bug was fixed in a later release.</p>
+</li>
+<li>
+<p><em>WorkingAsIntended:</em>
+ An AOSP contributor has determined that the
+behavior described isn't a bug, but is the intended behavior. This state is
+also commonly referred to as "WAI".</p>
+</li>
+<li>
+<p><em>Declined:</em>
+ This is like <em>WorkingAsIntended</em>, except
+typically used for feature requests instead of bugs. That is, an AOSP
+contributor has determined that the request is not going to be implemented in
+Android.</p>
+</li>
+</ul>
+<h2 id="resolved-issues">Resolved Issues</h2>
+<p>This bucket contains bugs that have had action taken, and are now
+considered resolved.</p>
+<ul>
+<li>
+<p><em>FutureRelease:</em>
+ This bug has been fixed (or feature implemented) in
+a source tree, but has not yet been included in a formal Android
+platform release. (Note that this may also include fixes that exist in a
+private source tree that has not yet been contributed to a public
+tree.)</p>
+</li>
+<li>
+<p><em>Released:</em>
+ This bug has been fixed, and is included in a formal
+Android platform release. When this state is set, we try to also set a
+property indicating which release it was fixed in.</p>
+</li>
+<li>
+<p><em>Duplicate:</em>
+ This bug is a duplicate of another, existing bug report.</p>
+</li>
+</ul>
+<h1 id="other-stuff">Other Stuff</h1>
+<p>The states and lifecycle above are how we generally try to track software.
+However, Android contains a lot of software and gets a correspondingly large
+number of bugs. As a result, sometimes bugs don't make it through all the
+states in a formal progression. We do try to keep the system up to date, but
+we tend to do so in periodic "bug sweeps" where we review the database and
+make updates.</p>
+<p>Since the AOSP is essentially constantly evolving, we do make tweaks to
+the list of bug states and the lifecycle described above. When we do this,
+however, we'll be sure to update this page as well.</p>
+<p>Finally, you should be aware that for a variety of reasons, there are
+actually multiple issue trackers for Android-related issues. The
+<a href="https://code.google.com/p/android/issues/list">Google Code Project Hosting Issue Tracker</a>
+is the <em>only</em> official public issue tracker; however,
+Google also maintains a private issue tracker, own, as do most OEMs. We try to
+keep the public issue tracker in sync with private issue trackers
+wherever possible, but in cases where confidential information and security
+issues are involved, this isn't always possible.</p>
\ No newline at end of file
diff --git a/src/source/life-of-a-bug.md b/src/source/life-of-a-bug.md
deleted file mode 100644
index 64d2119..0000000
--- a/src/source/life-of-a-bug.md
+++ /dev/null
@@ -1,173 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Life of a Bug #
-
-The Android Open Source project maintains a public issue tracker where you
-can report bugs and request features for the Android software stack. (For
-details on this issue tracker, please see the [Reporting Bugs](report-bugs.html) page).
-Reporting bugs is great (thank you!), but what happens to a bug report once
-you file it? This page describes the Life of a Bug.
-
-*Please note: the Android Open Source Project (AOSP) issue tracker is
-intended only for bugs and feature requests related to the Android software
-stack. Because many users find their way here looking for the Google apps for
-Android (such as Gmail and so on), we have components set up for their
-convenience. However, these apps are not part of Android, and any issues
-reported on these components are not guaranteed to to receive attention.
-Most notably, to report issues related to Google Play, you should visit the
-[Google Play Support Forum](https://support.google.com/googleplay/).
-
-Here's the life of a bug, in a nutshell:
-
-1. A bug is filed, and has the state "New".
-
-1. An AOSP contributor periodically reviews and triages bugs. Bugs are
-triaged into one of four "buckets": New, Open, No-Action, or Resolved.
-
-1. Each bucket includes a number of states that provide more detail on the
-fate of the issue.
-
-1. Bugs in the "Resolved" bucket will eventually be included in a future
-release of the Android software.
-
-# Bucket Details #
-
-Here is some additional information on each bucket, what it means, and how
-it's handled.
-
-## New Issues ##
-
-New issues include bug reports that are not yet being acted upon. The two
-states are:
-
-- *New:*
- The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)
-
-- *NeedsInfo:*
- The bug report has insufficient information to act
-upon. The person who reported the bug needs to provide additional detail
-before it can be triaged. If enough time passes and no new information is
-provided, the bug may be closed by default, as one of the No-Action
-states.
-
-## Open Issues ##
-
-This bucket contains bugs that need action, but which are still
-unresolved, pending a change to the source code.
-
-- *Unassigned:*
- The bug report has been recognized as an adequately
-detailed report of a legitimate issue, but has not yet been assigned to an
-AOSP contributor to be fixed. Typically, bugs in this state are considered low
-priority, at least insofar that if they were high priority, they'd be assigned
-to a contributor.
-
-- *Reviewed:*
- Like *Unassigned*, but the issue
-represented is being tracked in a separate bug database. For example, the bug
-might have been reported via an internal bug-tracking system,
-which is considered the "master" copy. (For instance, Google maintains one
-such private issue tracker, intended primarily for bugs which contain
-sensitive information which can't be revealed publicly.)
-
-- *Assigned:*
- Like *Unassigned*, but the bug has been
-actually assigned to a specific contributor to fix.
-
-Typically, a given bug will start in *Unassigned*, where it
-will remain until it is associated with a specific upcoming release, at which
-point it will enter *Reviewed* or *Assigned*. However,
-note that this isn't a guarantee, and it's not uncommon for bugs to go from
-*Unassigned* to one of the Resolved states.
-
-In general, if a bug is in one of these Open states, the AOSP team has
-recognized it as a legitimate issue and will fix it according to the product
-priorities and milestones. However, it's impossible to guarantee a fix in time
-for any particular release.
-
-## No-Action Issues ##
-
-This bucket contains bugs that have for one reason or another been
-determined to not require any action.
-
-- *Spam:*
- A kind soul sent us some delicious pork products, that we,
-regrettably, do not want.
-
-- *Question:*
- Someone mistook the issue tracker for a help forum.
-(This is not as uncommon as you might think: many users whose native language
-isn't English misunderstand the site and make this mistake.)
-
-- *Unreproducible:*
- An AOSP contributor attempted to reproduce the
-behavior described, and was unable to do so. This sometimes means that the bug
-is legitimate but simply rare or difficult to reproduce, and sometimes means
-that the bug was fixed in a later release.
-
-- *WorkingAsIntended:*
- An AOSP contributor has determined that the
-behavior described isn't a bug, but is the intended behavior. This state is
-also commonly referred to as "WAI".
-
-- *Declined:*
- This is like *WorkingAsIntended*, except
-typically used for feature requests instead of bugs. That is, an AOSP
-contributor has determined that the request is not going to be implemented in
-Android.
-
-## Resolved Issues ##
-
-This bucket contains bugs that have had action taken, and are now
-considered resolved.
-
-- *FutureRelease:*
- This bug has been fixed (or feature implemented) in
-a source tree, but has not yet been included in a formal Android
-platform release. (Note that this may also include fixes that exist in a
-private source tree that has not yet been contributed to a public
-tree.)
-
-- *Released:*
- This bug has been fixed, and is included in a formal
-Android platform release. When this state is set, we try to also set a
-property indicating which release it was fixed in.
-
-- *Duplicate:*
- This bug is a duplicate of another, existing bug report.
-
-# Other Stuff #
-
-The states and lifecycle above are how we generally try to track software.
-However, Android contains a lot of software and gets a correspondingly large
-number of bugs. As a result, sometimes bugs don't make it through all the
-states in a formal progression. We do try to keep the system up to date, but
-we tend to do so in periodic "bug sweeps" where we review the database and
-make updates.
-
-Since the AOSP is essentially constantly evolving, we do make tweaks to
-the list of bug states and the lifecycle described above. When we do this,
-however, we'll be sure to update this page as well.
-
-Finally, you should be aware that for a variety of reasons, there are
-actually multiple issue trackers for Android-related issues. The
-[Google Code Project Hosting Issue Tracker](https://code.google.com/p/android/issues/list)
-is the *only* official public issue tracker; however,
-Google also maintains a private issue tracker, own, as do most OEMs. We try to
-keep the public issue tracker in sync with private issue trackers
-wherever possible, but in cases where confidential information and security
-issues are involved, this isn't always possible.
diff --git a/src/source/life-of-a-patch.jd b/src/source/life-of-a-patch.jd
new file mode 100644
index 0000000..a6fee4b
--- /dev/null
+++ b/src/source/life-of-a-patch.jd
@@ -0,0 +1,26 @@
+page.title=Life of a Patch
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android Open Source Project (AOSP) uses a web-based code review tool
+known as <a href="https://android-review.googlesource.com/">Gerrit</a>.
+The image below is a flowchart that details what happens to
+a patch, once it's been written. Though it may appear complex, the majority of
+the steps below are performed in the web application.</p>
+<p>For full instructions on how to get set up to use gerrit and git, please
+see the <a href="submit-patches.html">Submitting Patches</a> page.</p>
+<p><img src="/images/workflow-0.png" alt="workflow diagram"/></p>
\ No newline at end of file
diff --git a/src/source/life-of-a-patch.md b/src/source/life-of-a-patch.md
deleted file mode 100644
index f84ceac..0000000
--- a/src/source/life-of-a-patch.md
+++ /dev/null
@@ -1,28 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Life of a Patch #
-
-The Android Open Source Project (AOSP) uses a web-based code review tool
-known as [Gerrit](https://android-review.googlesource.com/).
-The image below is a flowchart that details what happens to
-a patch, once it's been written. Though it may appear complex, the majority of
-the steps below are performed in the web application.
-
-For full instructions on how to get set up to use gerrit and git, please
-see the [Submitting Patches](submit-patches.html) page.
-
-<img src="/images/workflow-0.png" alt="workflow diagram"/>
diff --git a/src/source/overview.html b/src/source/overview.html
new file mode 100644
index 0000000..b8f56fc
--- /dev/null
+++ b/src/source/overview.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/source/overview.md b/src/source/overview.md
deleted file mode 100644
index 804c1f0..0000000
--- a/src/source/overview.md
+++ /dev/null
@@ -1,70 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android 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.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/report-bugs.jd b/src/source/report-bugs.jd
new file mode 100644
index 0000000..9b85b08
--- /dev/null
+++ b/src/source/report-bugs.jd
@@ -0,0 +1,152 @@
+page.title=Report Bugs
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>Thanks for your interest in Android! One of the best ways you can help us
+improve Android is to let us know about any problems you find with it.</p>
+<p>First, though: if you think you've found a security vulnerability,
+<em>please don't use the forms below</em>. Using the public forms below may
+allow anyone to see your report, which may put users at risk until the bug is
+fixed. Please visit
+<a href="{@docRoot}source/faqs.html">our
+security faq</a> for more information on reporting security vulnerabilities
+to the Android security team.</p>
+<p>Here's how to report non-security bugs:</p>
+<ul>
+<li>
+<p><a href="https://code.google.com/p/android/issues/advsearch">Search for your bug</a> to see if anyone has already reported it.</p>
+</li>
+<li>
+<p>If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.</p>
+</li>
+<li>
+<p>If no one's reported your bug, file the bug. You can use one of these templates:</p>
+<ul>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=User%20bug%20report">Bug in your Device</a> - use this if you are a user reporting a bug in a device you own</p>
+</li>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report">Bug in the Software</a> - use this if you found a bug in the course of developing an app</p>
+</li>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=Feature%20request">Feature Request</a> - use this for a feature you'd like to see in a future verison</p>
+</li>
+</ul>
+</li>
+</ul>
+<p>Please note that we can't guarantee that any particular bug can be fixed in
+any particular release. To see what happens to your bug once you report it,
+read <a href="life-of-a-bug.html">Life of a Bug</a>.</p>
+<p>In general, please put as much info in bugs as you can. Just a one liner
+telling us something isn't working is usually useless, and will probably be
+closed without any action. The more detail you provide, the more likely your
+issue is to be resolved. Below, there are some examples of a good bug report
+and a poor bug report.</p>
+
+<h2 id="a-poor-bug-report">A Poor Bug Report</h2>
+<pre>
+Title: Error message
+
+When running Eclipse I get an "Internal Error" that says "See the .log file for more details".
+
+Steps to reproduce:
+Happens when "Object o = null". Doesn't happen when changed to "Object o".
+
+Expected results:
+I wouldn't get the error message--would work with Object o = null.
+
+Observed results:
+See above.
+</pre>
+<p>This is a poor bug report because it doesn't provide any context for the
+issue; is it a problem in the Dalvik virtual machine, the core framework, or
+something else? It also doesn't provide any code or hint on how to reproduce
+it. In other words, this bug report doesn't provide enough information for
+anyone to take action on, so it would be ignored.</p>
+<h2 id="a-good-bug-report">A Good Bug Report</h2>
+<pre>
+Title: Stepping over "Object o = null" causes Eclipse "Internal Error"
+
+Interesting bug, while using Eclipse 3.3.1.1 with m37a of android and the following code:
+
+package com.saville.android;
+
+import android.app.Activity;
+import android.os.Bundle;
+import android.util.Log;
+
+public class TestObjectNull extends Activity {
+ /** Called when the activity is first created. */
+ @Override
+ public void onCreate(Bundle icicle) {
+ super.onCreate(icicle);
+ setContentView(R.layout.main);
+
+ Object o = null;
+
+ o = "hi";
+
+ Log.v(TAG, "o=" + o);
+ }
+
+ static final String TAG = "TestObjectNull";
+}
+
+Eclipse indicates an "Internal Error" with "See the .log file for more
+details" and then asks if I want to exit the workbench. This occurs when I
+place a break point on "setContentView(R.layout.main);" and then single
+step over "Object o = null;"
+
+If I change "Object o = null;" to "Object o" all is well.
+
+The last lines of the .log file are:
+
+!ENTRY org.eclipse.core.jobs 4 2 2008-01-01 13:04:15.825
+!MESSAGE An internal error occurred during: "has children update".
+!STACK 0
+java.lang.InternalError: Invalid signature: "<null>"
+ at
+org.eclipse.jdi.internal.TypeImpl.signatureToTag(TypeImpl.java:307)
+ at
+org.eclipse.jdi.internal.LocalVariableImpl.tag(LocalVariableImpl.java:185)
+ at
+org.eclipse.jdi.internal.StackFrameImpl.getValues(StackFrameImpl.java:128)
+ at
+org.eclipse.jdi.internal.StackFrameImpl.getValue(StackFrameImpl.java:73)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDILocalVariable.retrieveValue(JDILocalVariable.java:57)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:66)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:88)
+ at
+org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.hasChildren(VariableContentProvider.java:62)
+ at
+org.eclipse.jdt.internal.debug.ui.variables.JavaVariableContentProvider.hasChildren(JavaVariableContentProvider.java:73)
+ at
+org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.updateHasChildren(ElementContentProvider.java:223)
+ at
+org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
+ at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
+</pre>
\ No newline at end of file
diff --git a/src/source/report-bugs.md b/src/source/report-bugs.md
deleted file mode 100644
index f4fd7e5..0000000
--- a/src/source/report-bugs.md
+++ /dev/null
@@ -1,139 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Report Bugs #
-
-Thanks for your interest in Android! One of the best ways you can help us
-improve Android is to let us know about any problems you find with it.
-
-First, though: if you think you've found a security vulnerability,
-*please don't use the forms below*. Using the public forms below may
-allow anyone to see your report, which may put users at risk until the bug is
-fixed. Please visit
-<a href="https://developer.android.com/resources/faq/security.html#issue">our
-security faq</a> for more information on reporting security vulnerabilities
-to the Android security team.
-
-Here's how to report non-security bugs:
-
-- [Search for your bug](https://code.google.com/p/android/issues/advsearch) to see if anyone has already reported it.
-
-- If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.
-
-- If no one's reported your bug, file the bug. You can use one of these templates:
-
- - [Bug in your Device](https://code.google.com/p/android/issues/entry?template=User%20bug%20report) - use this if you are a user reporting a bug in a device you own
-
- - [Bug in the Software](https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report) - use this if you found a bug in the course of developing an app
-
- - [Feature Request](https://code.google.com/p/android/issues/entry?template=Feature%20request) - use this for a feature you'd like to see in a future verison
-
-Please note that we can't guarantee that any particular bug can be fixed in
-any particular release. To see what happens to your bug once you report it,
-read [Life of a Bug](life-of-a-bug.html).
-
-In general, please put as much info in bugs as you can. Just a one liner
-telling us something isn't working is usually useless, and will probably be
-closed without any action. The more detail you provide, the more likely your
-issue is to be resolved. Below, there are some examples of a good bug report
-and a poor bug report.
-
-## A Poor Bug Report ##
- Title: Error message
-
- When running Eclipse I get an "Internal Error" that says "See the .log file for more details".
-
- Steps to reproduce:
- Happens when "Object o = null". Doesn't happen when changed to "Object o".
-
- Expected results:
- I wouldn't get the error message--would work with Object o = null.
-
- Observed results:
- See above.
-
-This is a poor bug report because it doesn't provide any context for the
-issue; is it a problem in the Dalvik virtual machine, the core framework, or
-something else? It also doesn't provide any code or hint on how to reproduce
-it. In other words, this bug report doesn't provide enough information for
-anyone to take action on, so it would be ignored.
-
-## A Good Bug Report ##
-
- Title: Stepping over "Object o = null" causes Eclipse "Internal Error"
-
- Interesting bug, while using Eclipse 3.3.1.1 with m37a of android and the following code:
-
- package com.saville.android;
-
- import android.app.Activity;
- import android.os.Bundle;
- import android.util.Log;
-
- public class TestObjectNull extends Activity {
- /** Called when the activity is first created. */
- @Override
- public void onCreate(Bundle icicle) {
- super.onCreate(icicle);
- setContentView(R.layout.main);
-
- Object o = null;
-
- o = "hi";
-
- Log.v(TAG, "o=" + o);
- }
-
- static final String TAG = "TestObjectNull";
- }
-
- Eclipse indicates an "Internal Error" with "See the .log file for more
- details" and then asks if I want to exit the workbench. This occurs when I
- place a break point on "setContentView(R.layout.main);" and then single
- step over "Object o = null;"
-
- If I change "Object o = null;" to "Object o" all is well.
-
- The last lines of the .log file are:
-
- !ENTRY org.eclipse.core.jobs 4 2 2008-01-01 13:04:15.825
- !MESSAGE An internal error occurred during: "has children update".
- !STACK 0
- java.lang.InternalError: Invalid signature: "<null>"
- at
- org.eclipse.jdi.internal.TypeImpl.signatureToTag(TypeImpl.java:307)
- at
- org.eclipse.jdi.internal.LocalVariableImpl.tag(LocalVariableImpl.java:185)
- at
- org.eclipse.jdi.internal.StackFrameImpl.getValues(StackFrameImpl.java:128)
- at
- org.eclipse.jdi.internal.StackFrameImpl.getValue(StackFrameImpl.java:73)
- at
- org.eclipse.jdt.internal.debug.core.model.JDILocalVariable.retrieveValue(JDILocalVariable.java:57)
- at
- org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:66)
- at
- org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:88)
- at
- org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.hasChildren(VariableContentProvider.java:62)
- at
- org.eclipse.jdt.internal.debug.ui.variables.JavaVariableContentProvider.hasChildren(JavaVariableContentProvider.java:73)
- at
- org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.updateHasChildren(ElementContentProvider.java:223)
- at
- org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
-
diff --git a/src/source/roles.jd b/src/source/roles.jd
new file mode 100644
index 0000000..9c93efc
--- /dev/null
+++ b/src/source/roles.jd
@@ -0,0 +1,100 @@
+page.title=Project Roles
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>The Android Open Source Project (AOSP) includes individuals working in a variety
+of roles. 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.</p>
+<p>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 <a href="/source/contributing.html">Contributing</a>.</p>
+<h2 id="contributor">Contributor</h2>
+<p>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.</p>
+<h2 id="developer">Developer</h2>
+<p>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.</p>
+<h2 id="verifier">Verifier</h2>
+<p>"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. <em>Note: at this
+time, generally Verifiers are the same as Approvers.</em></p>
+<h2 id="approver">Approver</h2>
+<p>"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.</p>
+<h2 id="project-leads">Project Leads</h2>
+<p>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:</p>
+<ul>
+<li>
+<p>Lead all technical aspects of the project; for example, the project roadmap,
+ development, release cycles, versioning, and QA.</p>
+</li>
+<li>
+<p>Ensure that the project is QA-ed in time for scheduled Android platform
+ releases.</p>
+</li>
+<li>
+<p>Designate Verifiers and Approvers for submitted patches.</p>
+</li>
+<li>
+<p>Be fair and unbiased while reviewing changes. Accept or reject patches
+ based on technical merit and alignment with the Android strategy.</p>
+</li>
+<li>
+<p>Review changes in a timely manner and make best efforts to communicate
+ when changes are not accepted.</p>
+</li>
+<li>
+<p>Optionally maintain a web site for the project for information and
+ documents specific to the project.</p>
+</li>
+<li>
+<p>Act as a facilitator in resolving technical conflicts.</p>
+</li>
+<li>
+<p>Be a public face for the project and the go-to person for questions
+ related to the project.</p>
+</li>
+</ul>
diff --git a/src/source/roles.md b/src/source/roles.md
deleted file mode 100644
index 5e7c62a..0000000
--- a/src/source/roles.md
+++ /dev/null
@@ -1,95 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# People and Roles #
-
-The Android Open Source Project (AOSP) includes individuals working in a variety
-of roles. As noted in [Our Philosophy](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/sidebar.md b/src/source/sidebar.md
deleted file mode 100644
index 5818d91..0000000
--- a/src/source/sidebar.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Getting Started #
-
-- [Initializing the Build Environment](initializing.html)
-- [Downloading the Source](downloading.html)
-- [Building and Running](building.html)
-- [Building for Devices](building-devices.html)
-- [Building Kernels](building-kernels.html)
-- [Known Issues](known-issues.html)
-
-# Navigating the Source #
-
-- [Platform Overview](overview.html)
-- [Branches & Releases](code-lines.html)
-- [Build Numbers](build-numbers.html)
-
-# Contributing #
-
-- [Life of a Patch](life-of-a-patch.html)
-- [Submitting Patches](submit-patches.html)
-- [View Patches](https://android-review.googlesource.com/)
-- [Life of a Bug](life-of-a-bug.html)
-- [Reporting Bugs](report-bugs.html)
-
-# Reference #
-
-- [Version Control](version-control.html)
- - [Repo Commands](using-repo.html)
- - [Git Resources](git-resources.html)
-- [Using Eclipse](using-eclipse.html)
-- [Code Style Guidelines](code-style.html)
-- [FAQs](/faqs.html)
-
-
-
diff --git a/src/source/source_toc.cs b/src/source/source_toc.cs
new file mode 100644
index 0000000..969a4fa
--- /dev/null
+++ b/src/source/source_toc.cs
@@ -0,0 +1,85 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--><?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/code-lines.html">Codelines, Branches, and Releases</a></li>
+ <li><a href="<?cs var:toroot ?>source/build-numbers.html">Codenames, Tags, and Build Numbers</a></li>
+ <li><a href="<?cs var:toroot ?>source/roles.html">Project Roles</a></li>
+ <li><a href="<?cs var:toroot ?>source/licenses.html">Licenses</a></li>
+ <li><a href="<?cs var:toroot ?>source/faqs.html">FAQ</a></li>
+ </ul>
+ </li>
+
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/building.html">
+ <span class="en">Downloading and Building</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/initializing.html">Initializing the Build Environment</a></li>
+ <li><a href="<?cs var:toroot ?>source/downloading.html">Downloading the Source</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-running.html">Building and Running</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-devices.html">Building for Devices</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-kernels.html">Building Kernels</a></li>
+ <li><a href="<?cs var:toroot ?>source/known-issues.html">Known Issues</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/developing.html">
+ <span class="en">Developing</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/using-repo.html">Using Repo</a></li>
+ <li><a href="<?cs var:toroot ?>source/using-eclipse.html">Using Eclipse</a></li>
+ <li><a href="<?cs var:toroot ?>source/git-resources.html">Git Resources</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/contributing.html">
+ <span class="en">Contributing</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-patch.html">Life of a Patch</a>
+ <li><a href="<?cs var:toroot ?>source/submit-patches.html">Submitting Patches</a></li>
+ <li><a href="http://android-review.googlesource.com">View Patches</a></li>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-bug.html">Life of a Bug</a></li>
+ <li><a href="<?cs var:toroot ?>source/report-bugs.html">Reporting Bugs</a></li>
+ <li><a href="<?cs var:toroot ?>source/code-style.html">Code Style Guidelines</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header empty">
+ <a href="<?cs var:toroot ?>source/community/index.html">
+ <span class="en">Community</span>
+ </a>
+ </div>
+ </li>
+
+</ul>
\ No newline at end of file
diff --git a/src/source/submit-patches.jd b/src/source/submit-patches.jd
new file mode 100644
index 0000000..6d555c5
--- /dev/null
+++ b/src/source/submit-patches.jd
@@ -0,0 +1,204 @@
+page.title=Submitting Patches
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>This page describes the full process of submitting a patch to the AOSP, including
+reviewing and tracking changes with <a href="https://android-review.googlesource.com/">Gerrit</a>.</p>
+<h2 id="prerequisites">Prerequisites</h2>
+<ul>
+<li>
+<p>Before you follow the instructions on this page, you need to <a href="">initialize your
+build environment</a> and <a href="{@docRoot}source/downloading.html">download the source</a>.</p>
+</li>
+<li>
+<p>For details about Repo and Git, see the <a href="version-control.html">Developing</a> section.</p>
+</li>
+<li>
+<p>For information about the different roles you can play within the Android
+Open Source community, see <a href="/source/roles.html">Project roles</a>.</p>
+</li>
+<li>
+<p>If you plan to contribute code to the Android platform, be sure to read
+the <a href="/source/licenses.html">AOSP's licensing information</a>.</p>
+</li>
+<li>
+<p>Note that changes to some of the upstream projects used by Android should be
+made directly to that project, as described in <a href="#upstream-projects">Upstream Projects</a>.</p>
+</li>
+</ul>
+<h1 id="for-contributors">For contributors</h1>
+<h2 id="authenticate-with-the-server">Authenticate with the server</h2>
+<p>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.</p>
+<ul>
+<li>
+<p>Sign in on the <a href="https://android-review.googlesource.com/">AOSP Gerrit Server</a>.</p>
+</li>
+<li>
+<p>Go to Settings -> HTTP Password -> Obtain Password</p>
+</li>
+<li>
+<p>Follow the instructions on the subsquent pages, and copy-paste your
+password in <code>~/.netrc</code>. If there are two password lines, copy both.</p>
+</li>
+</ul>
+<h2 id="start-a-repo-branch">Start a repo branch</h2>
+<p>For each change you intend to make, start a new branch within the relevant git repository:</p>
+<pre><code>$ repo start NAME .
+</code></pre>
+<p>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.</p>
+<h2 id="make-your-change">Make your change</h2>
+<p>Once you have modified the source files (and validated them, please) commit the changes to your local repository:</p>
+<pre><code>$ git add -A
+$ git commit -s
+</code></pre>
+<p>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: </p>
+<ul>
+<li>
+<p>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. </p>
+<pre><code>short description on first line
+
+more detailed description of your patch,
+which is likely to take up multiple lines.
+</code></pre>
+</li>
+<li>
+<p>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.</p>
+</li>
+<li>
+<p>Include a brief note of any assumptions or background information that may be important when another contributor works on this feature next year. </p>
+</li>
+</ul>
+<p>A unique change ID and your name and email as provided during <code>repo init</code> will be automatically added to your commit message. </p>
+<h2 id="upload-to-gerrit">Upload to gerrit</h2>
+<p>Once you have committed your change to your personal history, upload it to gerrit with</p>
+<pre><code>$ repo upload
+</code></pre>
+<p>If you have started multiple branches in the same repository, you will be prompted to select which one(s) to upload.</p>
+<p>After a successful upload, repo will provide you the URL of a new page on
+<a href="https://android-review.googlesource.com/">Gerrit</a>. Visit this link to view
+your patch on the review server, add comments, or request specific reviewers
+for your patch.</p>
+<h2 id="uploading-a-replacement-patch">Uploading a replacement patch</h2>
+<p>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.</p>
+<p><em>Note that if you have made other commits since uploading this patch, you will need to manually move your git HEAD.</em></p>
+<pre><code>$ git add -A
+$ git commit --amend
+</code></pre>
+<p>When you upload the amended patch, it will replace the original on gerrit and in your local git history.</p>
+<h2 id="resolving-sync-conflicts">Resolving sync conflicts</h2>
+<p>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</p>
+<pre><code>$ repo sync
+</code></pre>
+<p>This command first fetches the updates from the source server, then attempts to automatically rebase your HEAD onto the new remote HEAD.</p>
+<p>If the automatic rebase is unsuccessful, you will have to perform a manual rebase.</p>
+<pre><code>$ git rebase master
+</code></pre>
+<p>Using <code>git mergetool</code> may help you deal with the rebase conflict. Once you have successfully merged the conflicting files,</p>
+<pre><code>$ git rebase --continue
+</code></pre>
+<p>After either automatic or manual rebase is complete, run <code>repo upload</code> to submit your rebased patch.</p>
+<h2 id="after-a-submission-is-approved">After a submission is approved</h2>
+<p>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 <code>repo sync</code> to pull the update into their local client.</p>
+<h1 id="for-reviewers-and-verifiers">For reviewers and verifiers</h1>
+<h2 id="reviewing-a-change">Reviewing a change</h2>
+<p>If you are assigned to be the Approver for a change, you need to determine the following:</p>
+<ul>
+<li>
+<p>Does this change fit within this project's stated purpose?</p>
+</li>
+<li>
+<p>Is this change valid within the project's existing architecture?</p>
+</li>
+<li>
+<p>Does this change introduce design flaws that will cause problems in the future?</p>
+</li>
+<li>
+<p>Does this change follow the best practices that have been established for this project?</p>
+</li>
+<li>
+<p>Is this change a good way to perform the described function?</p>
+</li>
+<li>
+<p>Does this change introduce any security or instability risks?</p>
+</li>
+</ul>
+<p>If you approve of the change, mark it with LGTM ("Looks Good to Me") within Gerrit.</p>
+<h2 id="verifying-a-change">Verifying a change</h2>
+<p>If you are assigned to be the Verifier for a change, you need to do the following:</p>
+<ul>
+<li>
+<p>Patch the change into your local client using one of the Download commands.</p>
+</li>
+<li>
+<p>Build and test the change.</p>
+</li>
+<li>
+<p>Within Gerrit use Publish Comments to mark the commit as "Verified" or "Fails," and add a message explaining what problems were identified.</p>
+</li>
+</ul>
+<h2 id="downloading-changes-from-gerrit">Downloading changes from Gerrit</h2>
+<p>A submission that has been verified and merged will be downloaded with the next <code>repo sync</code>. If you wish to download a specific change that has not yet been approved, run</p>
+<pre><code>$ repo download TARGET CHANGE
+</code></pre>
+<p>where TARGET is the local directory into which the change should be downloaded and CHANGE is the
+change number as listed in <a href="https://android-review.googlesource.com/">Gerrit</a>. For more information,
+see the <a href="/source/using-repo.html">Repo reference</a>.</p>
+<h2 id="how-do-i-become-a-verifier-or-approver">How do I become a Verifier or Approver?</h2>
+<p>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 <a href="/source/roles.html">Project Roles</a>.</p>
+<h2 id="diffs-and-comments">Diffs and comments</h2>
+<p>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."</p>
+<h2 id="adding-comments">Adding comments</h2>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p><a name="upstream-projects"></a></p>
+<h1 id="upstream-projects">Upstream Projects</h1>
+<p>Android makes use of a number of other open-source projects, such as the Linux kernel and WebKit, as described in
+<a href="/source/code-lines.html">Codelines, Branches, and Releases</a>. For most projects under <code>external/</code>, 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.</p>
+<p>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.)</p>
+<h2 id="icu4c">ICU4C</h2>
+<p>All changes to the ICU4C project at <code>external/icu4c</code> should be made upstream at
+<a href="http://site.icu-project.org/">icu-project.org/</a>.
+See <a href="http://site.icu-project.org/bugs">Submitting ICU Bugs and Feature Requests</a> for more.</p>
+<h2 id="openssl">OpenSSL</h2>
+<p>All changes to the OpenSSL project at <code>external/openssl</code> should be made upstream at
+<a href="http://www.openssl.org">openssl.org</a>.</p>
+<h2 id="v8">V8</h2>
+<p>All changes to the V8 project at <code>external/v8</code> should be submitted upstream at
+<a href="https://code.google.com/p/v8">code.google.com/p/v8</a>. See <a href="https://code.google.com/p/v8/wiki/Contributing">Contributing to V8</a>
+for details.</p>
+<h2 id="webkit">WebKit</h2>
+<p>All changes to the WebKit project at <code>external/webkit</code> should be made
+upstream at <a href="http://www.webkit.org">webkit.org</a>. The process begins by filing a WebKit bug.
+This bug should use <code>Android</code> for the <code>Platform</code> and <code>OS</code>
+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
+<a href="http://webkit.org/coding/contributing.html">Contributing Code to WebKit</a> for details.</p>
+<h2 id="zlib">zlib</h2>
+<p>All changes to the zlib project at <code>external/zlib</code> should be made upstream at
+<a href="http://zlib.net">zlib.net</a>.</p>
diff --git a/src/source/submit-patches.md b/src/source/submit-patches.md
deleted file mode 100644
index 0ea530d..0000000
--- a/src/source/submit-patches.md
+++ /dev/null
@@ -1,225 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# 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.
-
-## 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/source/using-eclipse.jd b/src/source/using-eclipse.jd
new file mode 100644
index 0000000..d34084a
--- /dev/null
+++ b/src/source/using-eclipse.jd
@@ -0,0 +1,231 @@
+page.title=Using Eclipse
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>This document will help you set up the Eclipse IDE for Android platform development.</p>
+<p><em>Note: if you are looking for information on how to use
+Eclipse to develop applications that run on Android, this is not the right
+page for you. You probably would find <a href="https://developer.android.com/sdk/eclipse-adt.html">the Eclipse page on
+developer.android.com</a> more useful.</em></p>
+<h2 id="basic-setup">Basic setup</h2>
+<p>First, it's important to make sure the regular Android development system is set up.</p>
+<pre><code>cd /path/to/android/root
+make
+</code></pre>
+<p><strong>Important</strong>: You will still be using <code>make</code> to build the files you will actually run (in the emulator or on a device). You will be using Eclipse to edit files and verify that they compile, but when you want to run something you will need to make sure files are saved in Eclipse and run <code>make</code> in a shell. The Eclipse build is just for error checking.</p>
+<p>Eclipse needs a list of directories to search for Java files. This is called the "Java Build Path" and can be set with the <code>.classpath</code> file. We have a sample version to start you off.</p>
+<pre><code>cd /path/to/android/root
+cp development/ide/eclipse/.classpath .
+chmod u+w .classpath
+</code></pre>
+<p>Now edit that copy of <code>.classpath</code>, if necessary.</p>
+<h3 id="increase-eclipses-memory-settings">Increase Eclipse's Memory Settings</h3>
+<p>The Android project is large enough that Eclipse's Java VM sometimes runs out of memory while compiling it. Avoid this problem by editing the <code>eclipse.ini</code> file. On Apple OSX the eclipse.ini file is located at</p>
+<pre><code>/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
+</code></pre>
+<p>Memory-related defaults (as of Eclipse 3.4):</p>
+<pre><code>-Xms40m
+-Xmx256m
+-XX:MaxPermSize=256m
+</code></pre>
+<p>Recommended settings for Android development:</p>
+<pre><code>-Xms128m
+-Xmx512m
+-XX:MaxPermSize=256m
+</code></pre>
+<p>These settings set Eclipse's minimum Java heap size to 128MB, set the maximum Java heap size to 512MB, and keep the maximum permanent generation size at the default of 256MB.</p>
+<p>Now start Eclipse:</p>
+<pre><code>eclipse
+</code></pre>
+<p>Now create a project for Android development:</p>
+<ol>
+<li>
+<p>If Eclipse asks you for a workspace location, choose the default.</p>
+</li>
+<li>
+<p>If you have a "Welcome" screen, close it to reveal the Java perspective.</p>
+</li>
+<li>
+<p>File > New > Java Project</p>
+</li>
+<li>
+<p>Pick a project name, "android" or anything you like.</p>
+</li>
+<li>
+<p>Select "Create project from existing source", enter the path to your Android root directory, and click Finish.</p>
+</li>
+<li>
+<p>Wait while it sets up the project. (You'll see a subtle progress meter in the lower right corner.)</p>
+</li>
+</ol>
+<p>Once the project workspace is created, Eclipse should start building. In theory, it should build with no errors and you should be set to go. If necessary, uncheck and re-check Project Build Automatically to force a rebuild.</p>
+<p><em>Note:</em> Eclipse sometimes likes to add an <code>import android.R</code> statement at the top of your files that use resources, especially when you ask eclipse to sort or otherwise manage imports. This will cause your make to break. Look out for these erroneous import statements and delete them.</p>
+<h3 id="when-you-sync">When You Sync</h3>
+<p>Every time you repo sync, or otherwise change files outside of Eclipse (especially the .classpath), you need to refresh Eclipse's view of things:</p>
+<ol>
+<li>
+<p>Window > Show View > Navigator</p>
+</li>
+<li>
+<p>In the Navigator, right-click on the project name</p>
+</li>
+<li>
+<p>Click Refresh in the context menu</p>
+</li>
+</ol>
+<h3 id="adding-apps-to-the-build-path">Adding Apps to the Build Path</h3>
+<p>The default <code>.classpath</code> includes the source to the core system and a sample set of apps, but might not include the particular app you may want to work on. To add an app, you must add the app's source directory. To do this inside Eclipse:</p>
+<ol>
+<li>
+<p>Project > Properties</p>
+</li>
+<li>
+<p>Select "Java Build Path" from the left-hand menu.</p>
+</li>
+<li>
+<p>Choose the "Source" tab.</p>
+</li>
+<li>
+<p>Click "Add Folder..."</p>
+</li>
+<li>
+<p>Add your app's <code>src</code> directory.</p>
+</li>
+<li>
+<p>Click OK.</p>
+</li>
+</ol>
+<p>When you're done, the "source folder" path in the list should look like </p>
+<pre><code>android/packages/apps/YOURAPP/src
+</code></pre>
+<p>Depending on which app(s) you include, you may also need to include <code>othersrc/main/java</code> directories under <code>android/dalvik/libcore</code>. Do this if you find you cannot build with the default set.</p>
+<h2 id="eclipse-formatting">Eclipse formatting</h2>
+<p>You can import files in <code>development/ide/eclipse</code> to make Eclipse
+follow the Android style rules. </p>
+<ol>
+<li>
+<p>Select Window > Preferences > Java > Code Style.</p>
+</li>
+<li>
+<p>Use Formatter > Import to import <code>android-formatting.xml</code>.</p>
+</li>
+<li>
+<p>Organize Imports > Import to import <code>android.importorder</code>.</p>
+</li>
+</ol>
+<h2 id="debugging-the-emulator-with-eclipse">Debugging the emulator with Eclipse</h2>
+<p>You can also use eclipse to debug the emulator and step through code. First, start the emulator running:</p>
+<pre><code>cd /path/to/android/root
+. build/envsetup.sh
+lunch 1
+make
+emulator
+</code></pre>
+<p>If the emulator is running, you should see a picture of a phone.</p>
+<p>In another shell, start DDMS (the Dalvik debug manager):</p>
+<pre><code>cd /path/to/android/root
+ddms
+</code></pre>
+<p>You should see a splufty debugging console.</p>
+<p>Now, in eclipse, you can attach to the emulator:</p>
+<ol>
+<li>
+<p>Run > Open Debug Dialog...</p>
+</li>
+<li>
+<p>Right-click "Remote Java Application", select "New".</p>
+</li>
+<li>
+<p>Pick a name, i.e. "android-debug" or anything you like.</p>
+</li>
+<li>
+<p>Set the "Project" to your project name.</p>
+</li>
+<li>
+<p>Keep the Host set to "localhost", but change Port to 8700.</p>
+</li>
+<li>
+<p>Click the "Debug" button and you should be all set.</p>
+</li>
+</ol>
+<p>Note that port 8700 is attached to whatever process is currently selected in the DDMS console, so you need to sure that DDMS has selected the process you want to debug.</p>
+<p>You may need to open the Debug perspective (next to the "Java" perspective icon in the upper-right, click the small "Open Perspective" icon and select "Debug"). Once you do, you should see a list of threads; if you select one and break it (by clicking the "pause" icon), it should show the stack trace, source file, and line where execution is at. Breakpoints and whatnot should all work.</p>
+<h2 id="bonus-material">Bonus material</h2>
+<p>Replace Ctrl with the Apple key on Mac.</p>
+<table>
+<thead>
+<tr>
+<th>shortcut</th>
+<th>function</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Ctrl-Shift-o</td>
+<td>Organize imports</td>
+</tr>
+<tr>
+<td>Ctrl-Shift-t</td>
+<td>load class by name</td>
+</tr>
+<tr>
+<td>Ctrl-Shift-r</td>
+<td>load non-class resource by name</td>
+</tr>
+<tr>
+<td>Ctrl-1</td>
+<td>quick fix</td>
+</tr>
+<tr>
+<td>Ctrl-e</td>
+<td>Recently viewed files</td>
+</tr>
+<tr>
+<td>Ctrl-space</td>
+<td>auto complete</td>
+</tr>
+<tr>
+<td>Shift-Alt-r</td>
+<td>refactor:rename</td>
+</tr>
+<tr>
+<td>Shift-Alt-v</td>
+<td>refactor:move</td>
+</tr>
+</tbody>
+</table>
+<h2 id="eclipse-is-not-working-correctly-what-should-i-do">Eclipse is not working correctly, what should I do?</h2>
+<p>Make sure:</p>
+<ul>
+<li>
+<p>You followed the instructions on this page precisely.</p>
+</li>
+<li>
+<p>Your Problems view doesn't show any errors.</p>
+</li>
+<li>
+<p>Your application respects the package/directory structure.</p>
+</li>
+</ul>
+<p>If you're still having problems, please contact one of the Android mailing lists or IRC channels.</p>
diff --git a/src/source/using-eclipse.md b/src/source/using-eclipse.md
deleted file mode 100644
index 803b2cc..0000000
--- a/src/source/using-eclipse.md
+++ /dev/null
@@ -1,191 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Using Eclipse #
-
-This document will help you set up the Eclipse IDE for Android platform development.
-
-*Note: if you are looking for information on how to use
-Eclipse to develop applications that run on Android, this is not the right
-page for you. You probably would find [the Eclipse page on
-developer.android.com](https://developer.android.com/sdk/eclipse-adt.html) more useful.*
-
-## Basic setup ##
-
-First, it's important to make sure the regular Android development system is set up.
-
- cd /path/to/android/root
- make
-
-**Important**: You will still be using `make` to build the files you will actually run (in the emulator or on a device). You will be using Eclipse to edit files and verify that they compile, but when you want to run something you will need to make sure files are saved in Eclipse and run `make` in a shell. The Eclipse build is just for error checking.
-
-Eclipse needs a list of directories to search for Java files. This is called the "Java Build Path" and can be set with the `.classpath` file. We have a sample version to start you off.
-
- cd /path/to/android/root
- cp development/ide/eclipse/.classpath .
- chmod u+w .classpath
-
-Now edit that copy of `.classpath`, if necessary.
-
-### Increase Eclipse's Memory Settings ###
-
-The Android project is large enough that Eclipse's Java VM sometimes runs out of memory while compiling it. Avoid this problem by editing the `eclipse.ini` file. On Apple OSX the eclipse.ini file is located at
-
- /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
-
-Memory-related defaults (as of Eclipse 3.4):
-
- -Xms40m
- -Xmx256m
- -XX:MaxPermSize=256m
-
-Recommended settings for Android development:
-
- -Xms128m
- -Xmx512m
- -XX:MaxPermSize=256m
-
-These settings set Eclipse's minimum Java heap size to 128MB, set the maximum Java heap size to 512MB, and keep the maximum permanent generation size at the default of 256MB.
-
-Now start Eclipse:
-
- eclipse
-
-Now create a project for Android development:
-
-1. If Eclipse asks you for a workspace location, choose the default.
-
-2. If you have a "Welcome" screen, close it to reveal the Java perspective.
-
-3. File > New > Java Project
-
-4. Pick a project name, "android" or anything you like.
-
-5. Select "Create project from existing source", enter the path to your Android root directory, and click Finish.
-
-6. Wait while it sets up the project. (You'll see a subtle progress meter in the lower right corner.)
-
-Once the project workspace is created, Eclipse should start building. In theory, it should build with no errors and you should be set to go. If necessary, uncheck and re-check Project Build Automatically to force a rebuild.
-
-*Note:* Eclipse sometimes likes to add an `import android.R` statement at the top of your files that use resources, especially when you ask eclipse to sort or otherwise manage imports. This will cause your make to break. Look out for these erroneous import statements and delete them.
-
-### When You Sync ###
-
-Every time you repo sync, or otherwise change files outside of Eclipse (especially the .classpath), you need to refresh Eclipse's view of things:
-
-1. Window > Show View > Navigator
-
-1. In the Navigator, right-click on the project name
-
-1. Click Refresh in the context menu
-
-### Adding Apps to the Build Path ###
-
-The default `.classpath` includes the source to the core system and a sample set of apps, but might not include the particular app you may want to work on. To add an app, you must add the app's source directory. To do this inside Eclipse:
-
-1. Project > Properties
-
-1. Select "Java Build Path" from the left-hand menu.
-
-1. Choose the "Source" tab.
-
-1. Click "Add Folder..."
-
-1. Add your app's `src` directory.
-
-1. Click OK.
-
-When you're done, the "source folder" path in the list should look like
-
- android/packages/apps/YOURAPP/src
-
-Depending on which app(s) you include, you may also need to include `othersrc/main/java` directories under `android/dalvik/libcore`. Do this if you find you cannot build with the default set.
-
-## Eclipse formatting ##
-
-You can import files in `development/ide/eclipse` to make Eclipse
-follow the Android style rules.
-
-1. Select Window > Preferences > Java > Code Style.
-
-1. Use Formatter > Import to import `android-formatting.xml`.
-
-1. Organize Imports > Import to import `android.importorder`.
-
-## Debugging the emulator with Eclipse ##
-
-You can also use eclipse to debug the emulator and step through code. First, start the emulator running:
-
- cd /path/to/android/root
- . build/envsetup.sh
- lunch 1
- make
- emulator
-
-If the emulator is running, you should see a picture of a phone.
-
-In another shell, start DDMS (the Dalvik debug manager):
-
- cd /path/to/android/root
- ddms
-
-You should see a splufty debugging console.
-
-Now, in eclipse, you can attach to the emulator:
-
-1. Run > Open Debug Dialog...
-
-1. Right-click "Remote Java Application", select "New".
-
-1. Pick a name, i.e. "android-debug" or anything you like.
-
-1. Set the "Project" to your project name.
-
-1. Keep the Host set to "localhost", but change Port to 8700.
-
-1. Click the "Debug" button and you should be all set.
-
-Note that port 8700 is attached to whatever process is currently selected in the DDMS console, so you need to sure that DDMS has selected the process you want to debug.
-
-You may need to open the Debug perspective (next to the "Java" perspective icon in the upper-right, click the small "Open Perspective" icon and select "Debug"). Once you do, you should see a list of threads; if you select one and break it (by clicking the "pause" icon), it should show the stack trace, source file, and line where execution is at. Breakpoints and whatnot should all work.
-
-## Bonus material ##
-
-Replace Ctrl with the Apple key on Mac.
-
-shortcut | function
--------------|-----------------
-Ctrl-Shift-o | Organize imports
-Ctrl-Shift-t | load class by name
-Ctrl-Shift-r | load non-class resource by name
-Ctrl-1 | quick fix
-Ctrl-e | Recently viewed files
-Ctrl-space | auto complete
-Shift-Alt-r | refactor:rename
-Shift-Alt-v | refactor:move
-
-## Eclipse is not working correctly, what should I do? ##
-
-Make sure:
-
-- You followed the instructions on this page precisely.
-
-- Your Problems view doesn't show any errors.
-
-- Your application respects the package/directory structure.
-
-If you're still having problems, please contact one of the Android mailing lists or IRC channels.
-
diff --git a/src/source/using-repo.jd b/src/source/using-repo.jd
new file mode 100644
index 0000000..7dfd38f
--- /dev/null
+++ b/src/source/using-repo.jd
@@ -0,0 +1,265 @@
+page.title=Repo command reference
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>Repo usage takes the following form: </p>
+<pre><code>repo COMMAND OPTIONS
+</code></pre>
+<p>Optional elements are shown in brackets [ ]. Once Repo is installed, you can get information about any command by running </p>
+<pre><code>repo help COMMAND
+</code></pre>
+<p>Many commands take a project list as an argument. You can specify project-list as a list of names or a list of paths to local source directories for the projects:</p>
+<pre><code>repo sync [PROJECT0 PROJECT1 ... PROJECTN]
+repo sync [/PATH/TO/PROJECT0 ... /PATH/TO/PROJECTN]
+</code></pre>
+
+<h2 id="init">init</h2>
+<pre><code>$ repo init -u URL [OPTIONS]
+</code></pre>
+<p>Installs Repo in the current directory. This creates a <code>.repo/</code> directory that contains Git repositories for the Repo source code and the standard Android manifest files. The <code>.repo/</code> directory also contains <code>manifest.xml</code>, which is a symlink to the selected manifest in the <code>.repo/manifests/</code> directory.</p>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-u</code>: specify a URL from which to retrieve a manifest repository. The common manifest can be found at <code>https://android.googlesource.com/platform/manifest</code></p>
+</li>
+<li>
+<p><code>-m</code>: select a manifest file within the repository. If no manifest name is selected, the default is default.xml. </p>
+</li>
+<li>
+<p><code>-b</code>: specify a revision, i.e., a particular manifest-branch.</p>
+</li>
+</ul>
+<p><em>Note: For all remaining Repo commands, the current working directory must either be the parent directory of <code>.repo/</code> or a subdirectory of the parent directory.</em></p>
+<h2 id="sync">sync</h2>
+<pre><code>repo sync [PROJECT_LIST]
+</code></pre>
+<p>Downloads new changes and updates the working files in your local environment. If you run <code>repo sync</code> without any arguments, it will synchronize the files for all the projects.</p>
+<p>When you run <code>repo sync</code>, this is what happens:</p>
+<ul>
+<li>
+<p>If the project has never been synchronized, then <code>repo sync</code> is equivalent to <code>git clone</code>. All branches in the remote repository are copied to the local project directory.</p>
+</li>
+<li>
+<p>If the project has already been synchronized once, then <code>repo sync</code> is equivalent to:</p>
+<pre><code>git remote update
+git rebase origin/BRANCH
+</code></pre>
+<p>where <code>BRANCH</code> is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.</p>
+</li>
+<li>
+<p>If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, <code>git rebase --continue</code>) to resolve the conflicts.</p>
+</li>
+</ul>
+<p>After a successful <code>repo sync</code>, the code in specified projects will be up to date with the code in the remote repository.</p>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-d</code>: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.</p>
+</li>
+<li>
+<p><code>-s</code>: sync to a known good build as specified by the manifest-server element in the current manifest.</p>
+</li>
+<li>
+<p><code>-f</code>: proceed with syncing other projects even if a project fails to sync.</p>
+</li>
+</ul>
+<h2 id="upload">upload</h2>
+<pre><code>repo upload [PROJECT_LIST]
+</code></pre>
+<p>For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.</p>
+<p>After you select one or more branches, all commits on the selected branches
+are transmitted to Gerrit over an HTTPS connection. You will need to
+configure an HTTPS password to enable upload authorization. Visit the
+<a href="https://android-review.googlesource.com/new-password">Password Generator</a>
+to generate a new username/password pair to use over HTTPS.</p>
+<p>When Gerrit receives the object data over its server, it will turn each
+commit into a change so that reviewers can comment on each commit
+individually. To combine several "checkpoint" commits together into a
+single commit, use git rebase -i before you run repo upload.</p>
+<p>If you run repo upload without any arguments, it will search all the projects for changes to upload.</p>
+<p>To make edits to changes after they have been uploaded, you should use a tool like <code>git rebase -i</code> or <code>git commit --amend</code> to update your local commits. After your edits are complete:</p>
+<ul>
+<li>
+<p>Make sure the updated branch is the currently checked out branch.</p>
+</li>
+<li>
+<p>Use <code>repo upload --replace PROJECT</code> to open the change matching editor.</p>
+</li>
+<li>
+<p>For each commit in the series, enter the Gerrit change ID inside the brackets:</p>
+<pre><code># Replacing from branch foo
+[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
+[ 2829 ] ec18b4ba Update proto client to support patch set replacments
+[ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
+# Insert change numbers in the brackets to add a new patch set.
+# To create a new change record, leave the brackets empty.
+</code></pre>
+</li>
+</ul>
+<p>After the upload is complete the changes will have an additional Patch Set.</p>
+<h2 id="diff">diff</h2>
+<pre><code>repo diff [PROJECT_LIST]
+</code></pre>
+<p>Shows outstanding changes between commit and working tree using <code>git diff</code>. </p>
+<h2 id="download">download</h2>
+<pre><code>repo download TARGET CHANGE
+</code></pre>
+<p>Downloads the specified change from the review system and makes it available in your project's local working directory.</p>
+<p>For example, to download <a href="https://android-review.googlesource.com/23823">change 23823</a> into your platform/frameworks/base directory:</p>
+<pre><code>$ repo download platform/build 23823
+</code></pre>
+<p>A <code>repo sync</code> should effectively remove any commits retrieved via <code>repo download</code>. Or, you can check out the remote branch; e.g., <code>git checkout m/master</code>.</p>
+<p>*Note: There is a slight mirroring lag between when a change is visible on
+the web in <a href="https://android-review.googlesource.com/">Gerrit</a> and when
+<code>repo download</code> will be able to find it for all users, because of replication
+delays to all servers worldwide.</p>
+<h2 id="forall">forall</h2>
+<pre><code>repo forall [PROJECT_LIST] -c COMMAND
+</code></pre>
+<p>Executes the given shell command in each project. The following additional environment variables are made available by <code>repo forall</code>:</p>
+<ul>
+<li>
+<p><code>REPO_PROJECT</code> is set to the unique name of the project.</p>
+</li>
+<li>
+<p><code>REPO_PATH</code> is the path relative to the root of the client.</p>
+</li>
+<li>
+<p><code>REPO_REMOTE</code> is the name of the remote sstem from the manifest.</p>
+</li>
+<li>
+<p><code>REPO_LREV</code> is the name of the revision from the manifest, translated to a local tracking branch. Used if you need to pass the manifest revision to a locally executed git command.</p>
+</li>
+<li>
+<p><code>REPO_RREV</code> is the name of the revision from the manifest, exactly as written in the manifest.</p>
+</li>
+</ul>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-c</code>: command and arguments to execute. The command is evaluated through <code>/bin/sh</code> and any arguments after it are passed through as shell positional parameters.</p>
+</li>
+<li>
+<p><code>-p</code>: show project headers before output of the specified command. This is achieved by binding pipes to the command's stdin, stdout, and sterr streams, and piping all output into a continuous stream that is displayed in a single pager session.</p>
+</li>
+<li>
+<p><code>-v</code>: show messages the command writes to stderr. </p>
+</li>
+</ul>
+<h2 id="prune">prune</h2>
+<pre><code>repo prune [PROJECT_LIST]
+</code></pre>
+<p>Prunes (deletes) topics that are already merged.</p>
+<h2 id="start">start</h2>
+<pre><code>repo start BRANCH_NAME [PROJECT_LIST]
+</code></pre>
+<p>Begins a new branch for development, starting from the revision specified in the manifest.</p>
+<p>The <code>BRANCH_NAME</code> argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.</p>
+<p>The <code>PROJECT_LIST</code> specifies which projects will participate in this topic branch. </p>
+<p><em>Note: "." is a useful shorthand for the project in the current working directory.</em></p>
+<h2 id="status">status</h2>
+<pre><code>repo status [PROJECT_LIST]
+</code></pre>
+<p>Compares the working tree to the staging area (index) and the most recent commit on this branch (HEAD) in each project specified. Displays a summary line for each file where there is a difference between these three states.</p>
+<p>To see the status for only the current branch, run <code>repo status</code>. The status information will be listed by project. For each file in the project, a two-letter code is used:</p>
+<p>In the first column, an uppercase letter indicates how the staging area differs from the last committed state.</p>
+<table>
+<thead>
+<tr>
+<th>letter</th>
+<th>meaning</th>
+<th>description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>-</td>
+<td>no change</td>
+<td>same in HEAD and index</td>
+</tr>
+<tr>
+<td>A</td>
+<td>added</td>
+<td>not in HEAD, in index</td>
+</tr>
+<tr>
+<td>M</td>
+<td>modified</td>
+<td>in HEAD, modified in index</td>
+</tr>
+<tr>
+<td>D</td>
+<td>deleted</td>
+<td>in HEAD, not in index</td>
+</tr>
+<tr>
+<td>R</td>
+<td>renamed</td>
+<td>not in HEAD, path changed in index</td>
+</tr>
+<tr>
+<td>C</td>
+<td>copied</td>
+<td>not in HEAD, copied from another in index</td>
+</tr>
+<tr>
+<td>T</td>
+<td>mode changed</td>
+<td>same content in HEAD and index, mode changed</td>
+</tr>
+<tr>
+<td>U</td>
+<td>unmerged</td>
+<td>conflict between HEAD and index; resolution required</td>
+</tr>
+</tbody>
+</table>
+<p>In the second column, a lowercase letter indicates how the working directory differs from the index.</p>
+<table>
+<thead>
+<tr>
+<th>letter</th>
+<th>meaning</th>
+<th>description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>-</td>
+<td>new/unknown</td>
+<td>not in index, in work tree</td>
+</tr>
+<tr>
+<td>m</td>
+<td>modified</td>
+<td>in index, in work tree, modified</td>
+</tr>
+<tr>
+<td>d</td>
+<td>deleted</td>
+<td>in index, not in work tree</td>
+</tr>
+</tbody>
+</table>
diff --git a/src/source/using-repo.md b/src/source/using-repo.md
deleted file mode 100644
index b62f693..0000000
--- a/src/source/using-repo.md
+++ /dev/null
@@ -1,217 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Repo command reference #
-
-Repo usage takes the following form:
-
- repo COMMAND OPTIONS
-
-Optional elements are shown in brackets [ ]. Once Repo is installed, you can get information about any command by running
-
- repo help COMMAND
-
-Many commands take a project list as an argument. You can specify project-list as a list of names or a list of paths to local source directories for the projects:
-
- repo sync [PROJECT0 PROJECT1 ... PROJECTN]
- repo sync [/PATH/TO/PROJECT0 ... /PATH/TO/PROJECTN]
-
-[TOC]
-
-## init ##
-
- $ repo init -u URL [OPTIONS]
-
-Installs Repo in the current directory. This creates a `.repo/` directory that contains Git repositories for the Repo source code and the standard Android manifest files. The `.repo/` directory also contains `manifest.xml`, which is a symlink to the selected manifest in the `.repo/manifests/` directory.
-
-Options:
-
-* `-u`: specify a URL from which to retrieve a manifest repository. The common manifest can be found at `https://android.googlesource.com/platform/manifest`
-
-* `-m`: select a manifest file within the repository. If no manifest name is selected, the default is default.xml.
-
-* `-b`: specify a revision, i.e., a particular manifest-branch.
-
-*Note: For all remaining Repo commands, the current working directory must either be the parent directory of `.repo/` or a subdirectory of the parent directory.*
-
-
-## sync ##
-
- repo sync [PROJECT_LIST]
-
-Downloads new changes and updates the working files in your local environment. If you run `repo sync` without any arguments, it will synchronize the files for all the projects.
-
-When you run `repo sync`, this is what happens:
-
-- If the project has never been synchronized, then `repo sync` is equivalent to `git clone`. All branches in the remote repository are copied to the local project directory.
-
-- If the project has already been synchronized once, then `repo sync` is equivalent to:
-
- git remote update
- git rebase origin/BRANCH
-
- where `BRANCH` is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.
-
-- If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, `git rebase --continue`) to resolve the conflicts.
-
-After a successful `repo sync`, the code in specified projects will be up to date with the code in the remote repository.
-
-Options:
-
-* `-d`: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.
-
-* `-s`: sync to a known good build as specified by the manifest-server element in the current manifest.
-
-* `-f`: proceed with syncing other projects even if a project fails to sync.
-
-
-## upload ##
-
- repo upload [PROJECT_LIST]
-
-For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.
-
-After you select one or more branches, all commits on the selected branches
-are transmitted to Gerrit over an HTTPS connection. You will need to
-configure an HTTPS password to enable upload authorization. Visit the
-[Password Generator](https://android-review.googlesource.com/new-password)
-to generate a new username/password pair to use over HTTPS.
-
-When Gerrit receives the object data over its server, it will turn each
-commit into a change so that reviewers can comment on each commit
-individually. To combine several "checkpoint" commits together into a
-single commit, use git rebase -i before you run repo upload.
-
-If you run repo upload without any arguments, it will search all the projects for changes to upload.
-
-To make edits to changes after they have been uploaded, you should use a tool like `git rebase -i` or `git commit --amend` to update your local commits. After your edits are complete:
-
-- Make sure the updated branch is the currently checked out branch.
-
-- Use `repo upload --replace PROJECT` to open the change matching editor.
-
-- For each commit in the series, enter the Gerrit change ID inside the brackets:
-
- # Replacing from branch foo
- [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
- [ 2829 ] ec18b4ba Update proto client to support patch set replacments
- [ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
- # Insert change numbers in the brackets to add a new patch set.
- # To create a new change record, leave the brackets empty.
-
-After the upload is complete the changes will have an additional Patch Set.
-
-
-## diff ##
-
- repo diff [PROJECT_LIST]
-
-Shows outstanding changes between commit and working tree using `git diff`.
-
-
-## download ##
-
- repo download TARGET CHANGE
-
-Downloads the specified change from the review system and makes it available in your project's local working directory.
-
-For example, to download [change 23823](https://android-review.googlesource.com/23823) into your platform/frameworks/base directory:
-
- $ repo download platform/build 23823
-
-A `repo sync` should effectively remove any commits retrieved via `repo download`. Or, you can check out the remote branch; e.g., `git checkout m/master`.
-
-*Note: There is a slight mirroring lag between when a change is visible on
-the web in [Gerrit](https://android-review.googlesource.com/) and when
-`repo download` will be able to find it for all users, because of replication
-delays to all servers worldwide.
-
-
-## forall ##
-
- repo forall [PROJECT_LIST] -c COMMAND
-
-Executes the given shell command in each project. The following additional environment variables are made available by `repo forall`:
-
-* `REPO_PROJECT` is set to the unique name of the project.
-
-* `REPO_PATH` is the path relative to the root of the client.
-
-* `REPO_REMOTE` is the name of the remote sstem from the manifest.
-
-* `REPO_LREV` is the name of the revision from the manifest, translated to a local tracking branch. Used if you need to pass the manifest revision to a locally executed git command.
-
-* `REPO_RREV` is the name of the revision from the manifest, exactly as written in the manifest.
-
-Options:
-
-* `-c`: command and arguments to execute. The command is evaluated through `/bin/sh` and any arguments after it are passed through as shell positional parameters.
-
-* `-p`: show project headers before output of the specified command. This is achieved by binding pipes to the command's stdin, stdout, and sterr streams, and piping all output into a continuous stream that is displayed in a single pager session.
-
-* `-v`: show messages the command writes to stderr.
-
-
-## prune ##
-
- repo prune [PROJECT_LIST]
-
-Prunes (deletes) topics that are already merged.
-
-
-## start ##
-
- repo start BRANCH_NAME [PROJECT_LIST]
-
-Begins a new branch for development, starting from the revision specified in the manifest.
-
-The `BRANCH_NAME` argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.
-
-The `PROJECT_LIST` specifies which projects will participate in this topic branch.
-
-*Note: "." is a useful shorthand for the project in the current working directory.*
-
-
-## status ##
-
- repo status [PROJECT_LIST]
-
-Compares the working tree to the staging area (index) and the most recent commit on this branch (HEAD) in each project specified. Displays a summary line for each file where there is a difference between these three states.
-
-To see the status for only the current branch, run `repo status`. The status information will be listed by project. For each file in the project, a two-letter code is used:
-
-In the first column, an uppercase letter indicates how the staging area differs from the last committed state.
-
-letter | meaning | description
--------|----------------|-------------------------
-- | no change | same in HEAD and index
-A | added | not in HEAD, in index
-M | modified | in HEAD, modified in index
-D | deleted | in HEAD, not in index
-R | renamed | not in HEAD, path changed in index
-C | copied | not in HEAD, copied from another in index
-T | mode changed | same content in HEAD and index, mode changed
-U | unmerged | conflict between HEAD and index; resolution required
-
-In the second column, a lowercase letter indicates how the working directory differs from the index.
-
-letter | meaning | description
--------|----------------|----------------------------
-- | new/unknown | not in index, in work tree
-m | modified | in index, in work tree, modified
-d | deleted | in index, not in work tree
-
-
diff --git a/src/source/version-control.html b/src/source/version-control.html
new file mode 100644
index 0000000..e85ebc2
--- /dev/null
+++ b/src/source/version-control.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/developing.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/source/version-control.md b/src/source/version-control.md
deleted file mode 100644
index 302fb68..0000000
--- a/src/source/version-control.md
+++ /dev/null
@@ -1,187 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Version Control with Repo and Git #
-
-To work with the Android code, you will need to use both Git and Repo. In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however.
-
-**Git** is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits. One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.
-
-**Repo** is a repository management tool that we built on top of Git. Repo
-unifies the many Git repositories when necessary, does the uploads to our
-[revision control system](https://android-review.googlesource.com/), and
-automates parts of the Android development workflow. Repo is not meant to
-replace Git, only to make it easier to work with Git in the context of
-Android. The repo command is an executable Python script that you can put
-anywhere in your path. In working with the Android source files, you will
-use Repo for across-network operations. For example, with a single Repo
-command you can download files from multiple repositories into your local
-working directory.
-
-**Gerrit** is a web-based code review system for projects that use git. Gerrit encourages more centralized use of Git by allowing all authorized users to submit changes, which are automatically merged if they pass code review. In addition, Gerrit makes reviewing easier by displaying changes side by side in-browser and enabling inline comments.
-
-## Basic Workflow ##
-
-<div style="float:right">
- <img src="/images/submit-patches-0.png" alt="basic workflow diagram">
-</div>
-
-The basic pattern of interacting with the repositories is as follows:
-
-1. Use `repo start` to start a new topic branch.
-
-1. Edit the files.
-
-1. Use `git add` to stage changes.
-
-1. Use `git commit` to commit changes.
-
-1. Use `repo upload` to upload changes to the review server.
-
-# Task reference #
-
-The task list below shows a summary of how to do common Repo and Git tasks.
-For complete quick-start information and examples, see [Getting started](downloading.html).
-
-## Synchronizing your client ##
-
-To synchronize the files for all available projects:
-
- $ repo sync
-
-To synchronize the files for selected projects:
-
- $ repo sync PROJECT0 PROJECT1 PROJECT2 ...
-
-## Creating topic branches ##
-
-Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature. A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you can isolate one aspect of your work from the others. For an interesting article about using topic branches, see [Separating topic branches](http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt).
-<img src="/images/external-link.png" alt="">
-
-To start a topic branch using Repo:
-
- $ repo start BRANCH_NAME
-
-To verify that your new branch was created:
-
- $ repo status
-
-## Using topic branches ##
-
-To assign the branch to a particular project:
-
- $ repo start BRANCH_NAME PROJECT
-
-To switch to another branch that you have created in your local work environment:
-
- $ git checkout BRANCH_NAME
-
-To see a list of existing branches:
-
- $ git branch
-
-or
-
- $ repo branches
-
-The name of the current branch will be preceded by an asterisk.
-
-*Note: A bug might be causing `repo sync` to reset the local topic branch. If `git branch` shows \* (no branch) after you run `repo sync`, then run `git checkout` again.*
-
-## Staging files ##
-
-By default, Git notices but does not track the changes you make in a project. In order to tell git to preserve your changes, you must mark them for inclusion in a commit. This is also called "staging".
-
-You can stage your changes by running
-
- git add
-
-which accepts as arguments any files or directories within the project directory. Despite the name, `git add` does not simply add files to the git repository; it can also be used to stage file modifications and deletions.
-
-## Viewing client status ##
-
-To list the state of your files:
-
- $ repo status
-
-To see uncommitted edits:
-
- $ repo diff
-
-The `repo diff` command shows every local edit that you have made that would *not* go into the commit, if you were to commit right now. To see every edit that would go into the commit if you were to commit right now, you need a Git command, `git diff`. Before running it, be sure you are in the project directory:
-
- $ cd ~/WORKING_DIRECTORY/PROJECT
- $ git diff --cached
-
-## Committing changes ##
-
-A commit is the basic unit of revision control in git, consisting of a snapshot of directory structure and file contents for the entire project. Creating a commit in git is as simple as typing
-
- git commit
-
-You will be prompted for a commit message in your favorite editor; please provide a helpful message for any changes you submit to the AOSP. If you do not add a log message, the commit will be aborted.
-
-## Uploading changes to Gerrit ##
-
-Before uploading, update to the latest revisions:
-
- repo sync
-
-Next run
-
- repo upload
-
-This will list the changes you have committed and prompt you to select which branches to upload to the review server. If there is only one branch, you will see a simple `y/n` prompt.
-
-## Recovering sync conflicts ##
-
-If a `repo sync` shows sync conflicts:
-
-- View the files that are unmerged (status code = U).
-- Edit the conflict regions as necessary.
-- Change into the relevant project directory, run `git add` and `git commit` for the files in question, and then "rebase" the changes. For example:
-
- $ git add .
- $ git commit
- $ git rebase --continue
-
-- When the rebase is complete start the entire sync again:
-
- $ repo sync PROJECT0 PROJECT1 ... PROJECTN
-
-## Cleaning up your client files ##
-
-To update your local working directory after changes are merged in Gerrit:
-
- $ repo sync
-
-To safely remove stale topic branches:
-
- $ repo prune
-
-## Deleting a client ##
-
-Because all state information is stored in your client, you only need to delete the directory from your filesystem:
-
- $ rm -rf WORKING_DIRECTORY
-
-Deleting a client will *permanently delete* any changes you have not yet uploaded for review.
-
-# Git and Repo cheatsheet #
-
-<img src="/images/git-repo-1.png" alt="list of basic git and repo commands">
-
-
diff --git a/src/tech/bluetooth/sidebar2.md b/src/tech/bluetooth/sidebar2.md
deleted file mode 100644
index 2075d11..0000000
--- a/src/tech/bluetooth/sidebar2.md
+++ /dev/null
@@ -1 +0,0 @@
-# Bluetooth Topics #
diff --git a/src/tech/dalvik/index.md b/src/tech/dalvik/index.md
deleted file mode 100644
index a58b831..0000000
--- a/src/tech/dalvik/index.md
+++ /dev/null
@@ -1,26 +0,0 @@
-<!--
- 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.
--->
-
-# Dalvik Technical Information #
-
-Dalvik is the managed runtime used by applications and some system
-services on Android. Dalvik was originally created specifically for
-the Android project.
-
-Much of the documentation in this directory is intended to help
-with the ongoing development of Dalvik, as opposed to most of the
-other documentation on this site, which is geared more towards
-application development.
diff --git a/src/tech/dalvik/sidebar2.md b/src/tech/dalvik/sidebar2.md
deleted file mode 100644
index fa825b3..0000000
--- a/src/tech/dalvik/sidebar2.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Dalvik Topics #
-- [Bytecode Format](dalvik-bytecode.html)
-- [.Dex Format](dex-format.html)
-- [Instruction Formats](instruction-formats.html)
diff --git a/src/tech/datausage/excluding-network-types.md b/src/tech/datausage/excluding-network-types.md
deleted file mode 100644
index dcaf64f..0000000
--- a/src/tech/datausage/excluding-network-types.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-A mobile operator may wish to exclude specific network types from the
-total data usage calculated by a device. For example, network traffic
-over an MMS APN may be “zero-rated” by a mobile operator. To support
-this, the set of network types used to calculate total data usage can
-be configured through the `config_data_usage_network_types` resource
-at build time.
-
-Some mobile radio implementations may have unique Linux network
-interfaces for each active APN, while other radios may force multiple
-APNs to coexist on a single interface. Android can collect network
-statistics from both designs, but `config_data_usage_network_types` is
-not be effective at excluding APNs forced to coexist on a single
-interface.
diff --git a/src/tech/datausage/iface-overview.md b/src/tech/datausage/iface-overview.md
deleted file mode 100644
index fd1e3cc..0000000
--- a/src/tech/datausage/iface-overview.md
+++ /dev/null
@@ -1,49 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-
-In Android 4.0, statistics reported by Linux network interfaces are
-recorded over time, and are used to enforce network quota limits,
-render user-visible charts, and more.
-
-Each network device driver (Wi-Fi included) must follow the standard
-kernel device lifecycle, and return correct statistics through
-`dev_get_stats()`. In particular, statistics returned must remain
-strictly monotonic while the interface is active. Drivers may reset
-statistics only after successfully completing an `unregister_netdev()`
-or the equivalent that generates a `NETDEV_UNREGISTER` event for
-callbacks registered with `register_netdevice_notifier()` /
-`register_inetaddr_notifier()` / `register_inet6addr_notifier()`.
-
-Mobile operators typically measure data usage at the Internet layer
-(IP). To match this approach in Android 4.0, we rely on the fact that
-for the kernel devices we care about the `rx_bytes` and `tx_bytes`
-values returned by `dev_get_stats()` return exactly the Internet layer
-(`IP`) bytes transferred. But we understand that for other devices it
-might not be the case. For now, the feature relies on this
-peculiarity. New drivers should have that property also, and the
-`dev_get_stats()` values must not include any encapsulation overhead
-of lower network layers (such as Ethernet headers), and should
-preferably not include other traffic (such as ARP) unless it is
-negligible.
-
-The Android framework only collects statistics from network interfaces
-associated with a `NetworkStateTracker` in `ConnectivityService`. This
-enables the framework to concretely identify each network interface,
-including its type (such as `TYPE_MOBILE` or `TYPE_WIFI`) and
-subscriber identity (such as IMSI). All network interfaces used to
-route data should be represented by a `NetworkStateTracker` so that
-statistics can be accounted correctly.
diff --git a/src/tech/datausage/index.md b/src/tech/datausage/index.md
deleted file mode 100644
index 279f851..0000000
--- a/src/tech/datausage/index.md
+++ /dev/null
@@ -1,37 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Data Usage Technical Information #
-
-Android 4.0 (Ice Cream Sandwich) introduces new features that help
-users understand and control how their device uses network data. It
-monitors overall data usage, and supports warning or limit thresholds
-which will trigger notifications or disable mobile data when usage
-exceeds a specific quota.
-
-Data usage is also tracked on a per-application basis, enabling users
-to visually explore historical usage in the Settings app. Users can
-also restrict how specific applications are allowed to use data when
-running in the background.
-
-The documentation in this section is intended for systems integrators
-and mobile operators, to help explain technical details they should be
-aware of when porting Android to specific devices. These details are
-summarized below, and the
-[android-porting](mailto:android-porting+subscribe@googlegroups.com)
-mailing list is a good place for further discussion.
-
-
diff --git a/src/tech/datausage/kernel-changes.md b/src/tech/datausage/kernel-changes.md
deleted file mode 100644
index f89847f..0000000
--- a/src/tech/datausage/kernel-changes.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-This is a summary of the main changes in the kernel that diverge from mainline.
-
-* added net/netfilter/xt_qtaguid*
-* imported then modified net/netfilter/xt_quota2.c from xtables-addons project
-* fixes in net/netfilter/ip6_tables.c
-* modified ip*t_REJECT.c
-* modified net/netfilter/xt_socket.c
-
-A few comments on the kernel configuration:
-
-* xt_qtaguid masquerades as xt_owner and relies on xt_socket and itself relies on the connection tracker.
-* The connection tracker can't handle large SIP packets, it must be disabled.
-* The modified xt_quota2 uses the NFLOG support to notify userspace.
diff --git a/src/tech/datausage/kernel-overview.md b/src/tech/datausage/kernel-overview.md
deleted file mode 100644
index d21e0a3..0000000
--- a/src/tech/datausage/kernel-overview.md
+++ /dev/null
@@ -1,55 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Overview #
-
-The per-application/delegated data usage monitoring and tracking
-functionality relies on the xt_qtaguid module in the android-3.0 Linux
-kernel (`kernel/net/netfilter/xt_qtaguid`). The socket tagging
-functionality in the framework (`system/core/libcutils/qtaguid.c`)
-relies mainly on the existence of `/proc/net/xt_qtaguid/ctrl`
-interface exported by the `xt_qtaguid` kernel module.
-
-The `quota2` netfilter module (originally part of `xtables-addons`)
-allows the functionality to set named quota limits and was extended to
-support notifying userspace when certain limits are reached. Once the
-quota limit is reached, the `quota2` module discards all subsequent
-network traffic. The framework can also specify additional rules to
-restrict background data traffic for an application (refer to
-`com.android.server.NetworkManagementSocketTagger.setKernelCounterSet`
-and
-`android.net.NetworkPolicyManager.POLICY_REJECT_METERED_BACKGROUND`).
-
-# How does it work? #
-
-The `qtaguid` netfilter module tracks the network traffic on a
-per-socket basis for every application using the unique UID of the
-owning application. There are two tag components associated with any
-socket in the system. The first is the UID which uniquely identifies
-the application which is responsible for the data transfer (Linux
-allows the ability to ascribe the ownership of each network socket to
-the UID of the calling application). The second tag component is used
-to support additional characterization of the traffic into application
-developer specified categories. Using these application level tags, an
-application can profile the traffic into several sub-categories.
-
-In the case of applications that provide network data transfer as a
-service, such as the download manager, media streaming service, etc,
-it is possible to attribute the ownership of the network data transfer
-to the UID of the requesting application using the
-`TrafficStats.setThreadStatsUid()` function call. The caller must hold
-the “`android.permission.MODIFY_NETWORK_ACCOUNTING`” permission to
-re-assign the ownership of the network traffic.
diff --git a/src/tech/datausage/sidebar2.md b/src/tech/datausage/sidebar2.md
deleted file mode 100644
index 348c684..0000000
--- a/src/tech/datausage/sidebar2.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Network interface statistics #
-- [Overview](/tech/datausage/iface-overview.html)
-- [Excluding network types from data usage](/tech/datausage/excluding-network-types.html)
-- [Tethering data](/tech/datausage/tethering-data.html)
-- [Usage cycle reset dates](/tech/datausage/usage-cycle-resets-dates.html)
-
-# The xt_qtaguid netfilter kernel module #
-- [Overview](/tech/datausage/kernel-overview.html)
-- [Data usage tags explained](/tech/datausage/tags-explained.html)
-- [Kernel changes](/tech/datausage/kernel-changes.html)
-
diff --git a/src/tech/datausage/tags-explained.md b/src/tech/datausage/tags-explained.md
deleted file mode 100644
index 90b6a29..0000000
--- a/src/tech/datausage/tags-explained.md
+++ /dev/null
@@ -1,48 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-Tags represent one of the metrics the data usage counters will be
-tracked against. By default, and implicitly, a tag is just based on
-the UID. The UID is used as the base for policing, and cannot be
-ignored. So a tag will always at least represent a UID (uid_tag). A
-tag can be explicitly augmented with an "accounting tag" which is
-associated with a UID. User space can use
-`TrafficStats.setThreadStatsTag()` to set the acct_tag portion of the
-tag which is then used with sockets: all data belonging to that
-socket will be counted against the tag. The policing is then based on
-the tag's uid_tag portion, and stats are collected for the acct_tag
-portion separately.
-
-Without explicit tagging, the qtaguid module will assume the
-`default_tag: {acct_tag=0, uid_tag=10003}`
-
- a: {acct_tag=1, uid_tag=10003}
- b: {acct_tag=2, uid_tag=10003}
- c: {acct_tag=3, uid_tag=10003}
-
-`a, b, c…` represent explicit tags associated with specific sockets.
-
-`default_tag (acct_tag=0)` is the default accounting tag that contains
-the total traffic for that uid, including all untagged
-traffic, and is typically used to enforce policing/quota rules.
-
-These tags can be used to profile the network traffic of an
-application into separate logical categories (at a network socket
-level). Such tags can be removed, reapplied, or modified during
-runtime.
-
-The qtaguid module has been implemented on [kernel/common branch of
-android-3.0](https://android-review.googlesource.com/#/q/project:kernel/common+branch:android-3.0,n,z)
diff --git a/src/tech/datausage/tethering-data.md b/src/tech/datausage/tethering-data.md
deleted file mode 100644
index 0bc8f89..0000000
--- a/src/tech/datausage/tethering-data.md
+++ /dev/null
@@ -1,20 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-Tethering involves forwarding of traffic from one network interface to
-another using `iptables` forwarding rules. The framework periodically
-records tethering statistics between any interface pairs returned by
-`ConnectivityService.getTetheredIfacePairs()`.
diff --git a/src/tech/datausage/usage-cycle-resets-dates.md b/src/tech/datausage/usage-cycle-resets-dates.md
deleted file mode 100644
index 9bddad6..0000000
--- a/src/tech/datausage/usage-cycle-resets-dates.md
+++ /dev/null
@@ -1,22 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-Users can specify a day of month upon which their data usage
-resets. Internally, cycle boundaries are defined to end at midnight
-`(00:00) UTC` on the requested day. When a month is shorter than the
-requested day, the cycle resets on the first day of the subsequent
-month. For example, a cycle reset day of the 30th would cause a reset
-on January 30 at `00:00 UTC` and March 1 at `00:00 UTC`.
diff --git a/src/tech/debugging/index.md b/src/tech/debugging/index.md
deleted file mode 100644
index 4ae4fc9..0000000
--- a/src/tech/debugging/index.md
+++ /dev/null
@@ -1,23 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Debugging the Android platform #
-
-The following sections contain information, documentation, tips and tricks
-about debugging Android at the platform level, typically during development
-of platform-level features.
-
-[» Debugging Native Memory Use](/tech/debugging/native-memory.html)
diff --git a/src/tech/debugging/native-memory.md b/src/tech/debugging/native-memory.md
deleted file mode 100644
index 755a429..0000000
--- a/src/tech/debugging/native-memory.md
+++ /dev/null
@@ -1,39 +0,0 @@
-<!--
- 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.
--->
-
-# Debugging Native Memory Use #
-
-This tip assume that you are working with an eng
-or userdebug build of the platform, not on a production device.
-
-Android's native memory allocator has some useful debugging features. You
-can turn on memory tracking with:
-
- $ adb shell setprop libc.debug.malloc 1
- $ adb shell stop
- $ adb shell start
-
-You need to restart the runtime so that zygote and all processes launched from
-it are restarted with the property set. Now all Dalvik processes have memory
-tracking turned on. You can look at these with DDMS, but first you need to
-turn on its native memory UI:
-
- - Open ~/.android/ddms.cfg
- - Add a line "native=true"
-
-Upon relaunching DDMS and selecting a process, you can switch to the new
-native allocation tab and populate it with a list of allocations. This is
-especially useful for debugging memory leaks.
diff --git a/src/tech/debugging/sidebar2.md b/src/tech/debugging/sidebar2.md
deleted file mode 100644
index 3ab9f67..0000000
--- a/src/tech/debugging/sidebar2.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Debugging Topics #
-- [Native Memory Use](/tech/debugging/native-memory.html)
diff --git a/src/tech/encryption/android_crypto_implementation.md b/src/tech/encryption/android_crypto_implementation.md
deleted file mode 100644
index f3de9da..0000000
--- a/src/tech/encryption/android_crypto_implementation.md
+++ /dev/null
@@ -1,359 +0,0 @@
-<!--
- 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.
--->
-
-# Notes on the implementation of encryption in Android 3.0
-<br />
-
-## Quick summary for 3rd parties.
-
-If you want to enable encryption on your device based on Android 3.0
-aka Honeycomb, there are only a few requirements:
-
-1. The /data filesystem must be on a device that presents a block device
- interface. eMMC is used in the first devices. This is because the
- encryption is done by the dm-crypt layer in the kernel, which works
- at the block device layer.
-
-2. The function get_fs_size() in system/vold/cryptfs.c assumes the filesystem
- used for /data is ext4. It's just error checking code to make sure the
- filesystem doesn't extend into the last 16 Kbytes of the partition where
- the crypto footer is kept. It was useful for development when sizes were
- changing, but should not be required for release. If you are not using
- ext4, you can either delete it and the call to it, or fix it to understand
- the filesystem you are using.
-
-3. Most of the code to handle the setup and teardown of the temporary framework
- is in files that are not usually required to be changed on a per device
- basis. However, the init.<device>.rc file will require some changes. All
- services must be put in one of three classes: core, main or late_state.
- Services in the core class are not shutdown and restarted when the
- temporary framework gets the disk password. Services in the main class
- are restarted when the framework is restarted. Services in late_start are
- not started until after the temporary framework is restarted. Put services
- here that are not required to be running while the temporary framework
- gets the disk password.
-
- Also any directories that need to be created on /data that are device
- specific need to be in the Action for post-fs-data, and that Action must end
- with the command "setprop vold.post_fs_data_done 1". If your
- init.<device>.rc file does not have a post-fs-data Action, then the
- post-fs-data Action in the main init.rc file must end with the command
- "setprop vold.post_fs_data_done 1".
-
-
-## How Android encryption works
-
-Disk encryption on Android is based on dm-crypt, which is a kernel feature that
-works at the block device layer. Therefore, it is not usable with YAFFS, which
-talks directly to a raw nand flash chip, but does work with emmc and similar
-flash devices which present themselves to the kernel as a block device. The
-current preferred filesystem to use on these devices is ext4, though that is
-independent of whether encryption is used or not.
-
-While the actual encryption work is a standard linux kernel feature, enabling it
-on an Android device proved somewhat tricky. The Android system tries to avoid
-incorporating GPL components, so using the cryptsetup command or libdevmapper
-were not available options. So making the appropriate ioctl(2) calls into the
-kernel was the best choice. The Android volume daemon (vold) already did this
-to support moving apps to the SD card, so I chose to leverage that work
-for whole disk encryption. The actual encryption used for the filesystem for
-first release is 128 AES with CBC and ESSIV:SHA256. The master key is
-encrypted with 128 bit AES via calls to the openssl library.
-
-Once it was decided to put the smarts in vold, it became obvious that invoking
-the encryption features would be done like invoking other vold commands, by
-adding a new module to vold (called cryptfs) and teaching it various commands.
-The commands are checkpw, restart, enablecrypto, changepw and cryptocomplete.
-They will be described in more detail below.
-
-The other big issue was how to get the password from the user on boot. The
-initial plan was to implement a minimal UI that could be invoked from init
-in the initial ramdisk, and then init would decrypt and mount /data. However,
-the UI engineer said that was a lot of work, and suggested instead that init
-communicate upon startup to tell the framework to pop up the password entry
-screen, get the password, and then shutdown and have the real framework started.
-It was decided to go this route, and this then led to a host of other decisions
-described below. In particular, init set a property to tell the framework to go
-into the special password entry mode, and that set the stage for much
-communication between vold, init and the framework using properties. The
-details are described below.
-
-Finally, there were problems around killing and restarting various services
-so that /data could be unmounted and remounted. Bringing up the temporary
-framework to get the user password requires that a tmpfs /data filesystem be
-mounted, otherwise the framework will not run. But to unmount the tmpfs /data
-filesystem so the real decrypted /data filesystem could be mounted meant that
-every process that had open files on the tmpfs /data filesystem had to be killed
-and restarted on the real /data filesystem. This magic was accomplished by
-requiring all services to be in 1 of 3 groups: core, main and late_start.
-Core services are never shut down after starting. main services are shutdown
-and then restarted after the disk password is entered. late_start services
-are not started until after /data has been decrypted and mounted. The magic
-to trigger these actions is by setting the property vold.decrypt to various
-magic strings, which is described below. Also, a new init command "class_reset"
-was invented to stop a service, but allow it to be restarted with a
-"class_start" command. If the command "class_stop" was used instead of the
-new command "class_reset" the flag SVC_DISABLED was added to the state of
-any service stopped, which means it would not be started when the command
-class_start was used on its class.
-
-## Booting an encrypted system.
-
-1. When init fails to mount /data, it assumes the filesystem is encrypted,
- and sets several properties:
- ro.crypto.state = "encrypted"
- vold.decrypt = 1
- It then mounts a /data on a tmpfs ramdisk, using parameters it picks
- up from ro.crypto.tmpfs_options, which is set in init.rc.
-
- If init was able to mount /data, it sets ro.crypto.state to "unencrypted".
-
- In either case, init then sets 5 properties to save the initial mount
- options given for /data in these properties:
- ro.crypto.fs_type
- ro.crypto.fs_real_blkdev
- ro.crypto.fs_mnt_point
- ro.crypto.fs_options
- ro.crypto.fs_flags (saved as an ascii 8 digit hex number preceded by 0x)
-
-2. The framework starts up, and sees that vold.decrypt is set to "1". This
- tells the framework that it is booting on a tmpfs /data disk, and it needs
- to get the user password. First, however, it needs to make sure that the
- disk was properly encrypted. It sends the command "cryptfs cryptocomplete"
- to vold, and vold returns 0 if encryption was completed successfully, or -1
- on internal error, or -2 if encryption was not completed successfully.
- Vold determines this by looking in the crypto footer for the
- CRYPTO_ENCRYPTION_IN_PROGRESS flag. If it's set, the encryption process
- was interrupted, and there is no usable data on the device. If vold returns
- an error, the UI should pop up a message saying the user needs to reboot and
- factory reset the device, and give the user a button to press to do so.
-
-3. Assuming the "cryptfs cryptocomplete" command returned success, the
- framework should pop up a UI asking for the disk password. The UI then
- sends the command "cryptfs checkpw <passwd>" to vold. If the password
- is correct (which is determined by successfully mounting the decrypted
- at a temporary location, then unmounting it), vold saves the name of the
- decrypted block device in the property ro.crypto.fs_crypto_blkdev, and
- returns status 0 to the UI. If the password is incorrect, it returns -1
- to the UI.
-
-4. The UI puts up a crypto boot graphic, and then calls vold with the command
- "cryptfs restart". vold sets the property vold.decrypt to
- "trigger_reset_main", which causes init.rc to do "class_reset main". This
- stops all services in the main class, which allows the tmpfs /data to be
- unmounted. vold then mounts the decrypted real /data partition, and then
- preps the new partition (which may never have been prepped if it was
- encrypted with the wipe option, which is not supported on first release).
- It sets the property vold.post_fs_data_done to "0", and then sets
- vold.decrypt to "trigger_post_fs_dat". This causes init.rc to run the
- post-fs-data commands in init.rc and init.<device>.rc. They will create
- any necessary directories, links, et al, and then set vold.post_fs_data_done
- to "1". Vold waits until it sees the "1" in that property. Finally, vold
- sets the property vold.decrypt to "trigger_restart_framework" which causes
- init.rc to start services in class main again, and also start services
- in class late_start for the first time since boot.
-
- Now the framework boots all its services using the decrypted /data
- filesystem, and the system is ready for use.
-
-## Enabling encryption on the device.
-
-For first release, we only support encrypt in place, which requires the
-framework to be shutdown, /data unmounted, and then every sector of the
-device encrypted, after which the device reboots to go through the process
-described above. Here are the details:
-
-1. From the UI, the user selects to encrypt the device. The UI ensures that
- there is a full charge on the battery, and the AC adapter is plugged in.
- It does this to make sure there is enough power to finish the encryption
- process, because if the device runs out of power and shuts down before it
- has finished encrypting, file data is left in a partially encrypted state,
- and the device must be factory reset (and all data lost).
-
- Once the user presses the final button to encrypt the device, the UI calls
- vold with the command "cryptfs enablecrypto inplace <passwd>" where passwd
- is the user's lock screen password.
-
-2. vold does some error checking, and returns -1 if it can't encrypt, and
- prints a reason in the log. If it thinks it can, it sets the property
- vold.decrypt to "trigger_shutdown_framework". This causes init.rc to
- stop services in the classes late_start and main. vold then unmounts
- /mnt/sdcard and then /data.
-
-3. If doing an inplace encryption, vold then mounts a tmpfs /data (using the
- tmpfs options from ro.crypto.tmpfs_options) and sets the property
- vold.encrypt_progress to "0". It then preps the tmpfs /data filesystem as
- mentioned in step 3 for booting an encrypted system, and then sets the
- property vold.decrypt to "trigger_restart_min_framework". This causes
- init.rc to start the main class of services. When the framework sees that
- vold.encrypt_progress is set to "0", it will bring up the progress bar UI,
- which queries that property every 5 seconds and updates a progress bar.
-
-4. vold then sets up the crypto mapping, which creates a virtual crypto block
- device that maps onto the real block device, but encrypts each sector as it
- is written, and decrypts each sector as it is read. vold then creates and
- writes out the crypto footer.
-
- The crypto footer contains details on the type of encryption, and an
- encrypted copy of the master key to decrypt the filesystem. The master key
- is a 128 bit number created by reading from /dev/urandom. It is encrypted
- with a hash of the user password created with the PBKDF2 function from the
- SSL library. The footer also contains a random salt (also read from
- /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent
- rainbow table attacks on the password. Also, the flag
- CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure
- to complete the encryption process. See the file cryptfs.h for details
- on the crypto footer layout. The crypto footer is kept in the last 16
- Kbytes of the partition, and the /data filesystem cannot extend into that
- part of the partition.
-
-5. If told was to enable encryption with wipe, vold invokes the command
- "make_ext4fs" on the crypto block device, taking care to not include
- the last 16 Kbytes of the partition in the filesystem.
-
- If the command was to enable inplace, vold starts a loop to read each sector
- of the real block device, and then write it to the crypto block device.
- This takes about an hour on a 30 Gbyte partition on the Motorola Xoom.
- This will vary on other hardware. The loop updates the property
- vold.encrypt_progress every time it encrypts another 1 percent of the
- partition. The UI checks this property every 5 seconds and updates
- the progress bar when it changes.
-
-6. When either encryption method has finished successfully, vold clears the
- flag ENCRYPTION_IN_PROGRESS in the footer, and reboots the system.
- If the reboot fails for some reason, vold sets the property
- vold.encrypt_progress to "error_reboot_failed" and the UI should
- display a message asking the user to press a button to reboot.
- This is not expected to ever occur.
-
-7. If vold detects an error during the encryption process, and if no data has
- been destroyed yet and the framework is up, vold sets the property
- vold.encrypt_progress to "error_not_encrypted" and the UI should give the
- user the option to reboot, telling them that the encryption process
- never started. If the error occurs after the framework has been torn
- down, but before the progress bar UI is up, vold will just reboot the
- system. If the reboot fails, it sets vold.encrypt_progress to
- "error_shutting_down" and returns -1, but there will not be anyone
- to catch the error. This is not expected to happen.
-
- If vold detects an error during the encryption process, it sets
- vold.encrypt_progress to "error_partially_encrypted" and returns -1.
- The UI should then display a message saying the encryption failed, and
- provide a button for the user to factory reset the device.
-
-## Changing the password
-
-To change the password for the disk encryption, the UI sends the command
-"cryptfs changepw <newpw>" to vold, and vold re-encrypts the disk master
-key with the new password.
-
-## Summary of related properties
-
-Here is a table summarizing the various properties, their possible values,
-and what they mean:
-
-
- vold.decrypt 1 Set by init to tell the UI to ask
- for the disk pw
-
- vold.decrypt trigger_reset_main Set by vold to shutdown the UI
- asking for the disk password
-
- vold.decrypt trigger_post_fs_data Set by vold to prep /data with
- necessary dirs, et al.
-
- vold.decrypt trigger_restart_framework Set by vold to start the real
- framework and all services
-
- vold.decrypt trigger_shutdown_framework Set by vold to shutdown the full
- framework to start encryption
-
- vold.decrypt trigger_restart_min_framework Set by vold to start the progress
- bar UI for encryption.
-
- vold.enrypt_progress When the framework starts up, if
- this property is set, enter the
- progress bar UI mode.
-
- vold.encrypt_progress 0 to 100 The progress bar UI should display
- the percentage value set.
-
- vold.encrypt_progress error_partially_encrypted The progress bar UI should
- display a message that the
- encryption failed, and give
- the user an option to factory
- reset the device.
-
- vold.encrypt_progress error_reboot_failed The progress bar UI should display
- a message saying encryption
- completed, and give the user a
- button to reboot the device.
- This error is not expected to
- happen.
-
- vold.encrypt_progress error_not_encrypted The progress bar UI should display
- a message saying an error occured,
- and no data was encrypted or lost,
- and give the user a button to
- reboot the system.
-
- vold.encrypt_progress error_shutting_down The progress bar UI is not
- running, so it's unclear who
- will respond to this error,
- and it should never happen
- anyway.
-
- vold.post_fs_data_done 0 Set by vold just before setting
- vold.decrypt to
- trigger_post_fs_data.
-
- vold.post_fs_data_done 1 Set by init.rc or init.<device>.rc
- just after finishing the task
- post-fs-data.
-
- ro.crypto.fs_crypto_blkdev Set by the vold command checkpw
- for later use by the vold command
- restart.
-
- ro.crypto.state unencrypted Set by init to say this system is
- running with an unencrypted /data
-
- ro.crypto.state encrypted Set by init to say this system is
- running with an encrypted /data
-
- ro.crypto.fs_type These 5 properties are set by init
- ro.crypto.fs_real_blkdev when it tries to mount /data with
- ro.crypto.fs_mnt_point parameters passed in from init.rc.
- ro.crypto.fs_options vold uses these to setup the
- ro.crypto.fs_flags crypto mapping.
-
- ro.crypto.tmpfs_options Set by init.rc with the options
- init should use when mounting
- the tmpfs /data filesystem.
-
-## Summary of new init actions
-
-A list of the new Actions that are added to init.rc and/or init.<device>.rc:
-
- on post-fs-data
- on nonencrypted
- on property:vold.decrypt=trigger_reset_main
- on property:vold.decrypt=trigger_post_fs_data
- on property:vold.decrypt=trigger_restart_min_framework
- on property:vold.decrypt=trigger_restart_framework
- on property:vold.decrypt=trigger_shutdown_framework
-
-
diff --git a/src/tech/encryption/index.md b/src/tech/encryption/index.md
deleted file mode 100644
index 084f0da..0000000
--- a/src/tech/encryption/index.md
+++ /dev/null
@@ -1,22 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Encryption Technical Information #
-
-Encryption on Android uses the dm-crypt layer in the Linux kernel. Read the
-detailed description of how it is tied into the Android system and what must
-be done on a new device to get this feature working.
-
diff --git a/src/tech/encryption/sidebar2.md b/src/tech/encryption/sidebar2.md
deleted file mode 100644
index f201414..0000000
--- a/src/tech/encryption/sidebar2.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Encryption Topics #
-- [Android Encryption Implementation](/tech/encryption/android_crypto_implementation.html)
-
diff --git a/src/tech/index.md b/src/tech/index.md
deleted file mode 100644
index 42908be..0000000
--- a/src/tech/index.md
+++ /dev/null
@@ -1,76 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android 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)
-
-## 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/dumpsys.md b/src/tech/input/dumpsys.md
deleted file mode 100644
index 883e8c4..0000000
--- a/src/tech/input/dumpsys.md
+++ /dev/null
@@ -1,347 +0,0 @@
-<!--
- 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.
--->
-
-# Dumpsys #
-
-The `dumpsys` tool runs on the device and dumps interesting information
-about the status of system services.
-
-## Usage ##
-
-The input system is part of the window manager. To dump its state,
-run the following command.
-
- $ adb shell su -- dumpsys window
-
- WINDOW MANAGER INPUT (dumpsys window input)
- Event Hub State:
- BuiltInKeyboardId: -1
- Devices:
- ...
-
-The set of information that is reported varies depending on the version of Android.
-
-### Event Hub State ###
-
-The `EventHub` component is responsible for communicating with the kernel device
-drivers and identifying device capabilities. Accordingly, its state shows
-information about how devices are configured.
-
- Event Hub State:
- BuiltInKeyboardId: -1
- Devices:
- 3: tuna-gpio-keypad
- Classes: 0x00000001
- Path: /dev/input/event2
- Location:
- UniqueId:
- Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
- KeyLayoutFile: /system/usr/keylayout/tuna-gpio-keypad.kl
- KeyCharacterMapFile: /system/usr/keychars/tuna-gpio-keypad.kcm
- ConfigurationFile:
- 5: Tuna Headset Jack
- Classes: 0x00000080
- Path: /dev/input/event5
- Location: ALSA
- UniqueId:
- Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
- KeyLayoutFile:
- KeyCharacterMapFile:
- ConfigurationFile:
- 6: Melfas MMSxxx Touchscreen
- Classes: 0x00000014
- Path: /dev/input/event1
- Location: 3-0048/input0
- UniqueId:
- Identifier: bus=0x0018, vendor=0x0000, product=0x0000, version=0x0000
- KeyLayoutFile:
- KeyCharacterMapFile:
- ConfigurationFile: /system/usr/idc/Melfas_MMSxxx_Touchscreen.idc
- 7: Motorola Bluetooth Wireless Keyboard
- Classes: 0x8000000b
- Path: /dev/input/event6
- Location: 0C:DF:A4:B3:2D:BA
- UniqueId: 00:0F:F6:80:02:CD
- Identifier: bus=0x0005, vendor=0x22b8, product=0x093d, version=0x0288
- KeyLayoutFile: /system/usr/keylayout/Vendor_22b8_Product_093d.kl
- KeyCharacterMapFile: /system/usr/keychars/Generic.kcm
- ConfigurationFile:
-
-#### Things To Look For ####
-
-1. All of the expected input devices are present.
-
-2. Each input device has an appropriate key layout file, key character map file
- and input device configuration file. If the files are missing or contain
- syntax errors, then they will not be loaded.
-
-3. Each input device is being classified correctly. The bits in the `Classes`
- field correspond to flags in `EventHub.h` such as `INPUT_DEVICE_CLASS_TOUCH_MT`.
-
-4. The `BuiltInKeyboardId` is correct. If the device does not have a built-in keyboard,
- then the id must be `-1`, otherwise it should be the id of the built-in keyboard.
-
- If you observe that the `BuiltInKeyboardId` is not `-1` but it should be, then
- you are missing a key character map file for a special function keypad somewhere.
- Special function keypad devices should have key character map files that contain
- just the line `type SPECIAL_FUNCTION` (that's what in the `tuna-gpio-keykad.kcm`
- file we see mentioned above).
-
-### Input Reader State ###
-
-The `InputReader` is responsible for decoding input events from the kernel.
-Its state dump shows information about how each input device is configured
-and recent state changes that occurred, such as key presses or touches on
-the touch screen.
-
-This is what a special function keypad looks like:
-
- Input Reader State:
- Device 3: tuna-gpio-keypad
- IsExternal: false
- Sources: 0x00000101
- KeyboardType: 1
- Keyboard Input Mapper:
- Parameters:
- AssociatedDisplayId: -1
- OrientationAware: false
- KeyboardType: 1
- Orientation: 0
- KeyDowns: 0 keys currently down
- MetaState: 0x0
- DownTime: 75816923828000
-
-Here is a touch screen. Notice all of the information about the resolution of
-the device and the calibration parameters that were used.
-
- Device 6: Melfas MMSxxx Touchscreen
- IsExternal: false
- Sources: 0x00001002
- KeyboardType: 0
- Motion Ranges:
- X: source=0x00001002, min=0.000, max=719.001, flat=0.000, fuzz=0.999
- Y: source=0x00001002, min=0.000, max=1279.001, flat=0.000, fuzz=0.999
- PRESSURE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
- SIZE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
- TOUCH_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
- TOUCH_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
- TOOL_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
- TOOL_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
- Touch Input Mapper:
- Parameters:
- GestureMode: spots
- DeviceType: touchScreen
- AssociatedDisplay: id=0, isExternal=false
- OrientationAware: true
- Raw Touch Axes:
- X: min=0, max=720, flat=0, fuzz=0, resolution=0
- Y: min=0, max=1280, flat=0, fuzz=0, resolution=0
- Pressure: min=0, max=255, flat=0, fuzz=0, resolution=0
- TouchMajor: min=0, max=30, flat=0, fuzz=0, resolution=0
- TouchMinor: unknown range
- ToolMajor: unknown range
- ToolMinor: unknown range
- Orientation: unknown range
- Distance: unknown range
- TiltX: unknown range
- TiltY: unknown range
- TrackingId: min=0, max=65535, flat=0, fuzz=0, resolution=0
- Slot: min=0, max=9, flat=0, fuzz=0, resolution=0
- Calibration:
- touch.size.calibration: diameter
- touch.size.scale: 10.000
- touch.size.bias: 0.000
- touch.size.isSummed: false
- touch.pressure.calibration: amplitude
- touch.pressure.scale: 0.005
- touch.orientation.calibration: none
- touch.distance.calibration: none
- SurfaceWidth: 720px
- SurfaceHeight: 1280px
- SurfaceOrientation: 0
- Translation and Scaling Factors:
- XScale: 0.999
- YScale: 0.999
- XPrecision: 1.001
- YPrecision: 1.001
- GeometricScale: 0.999
- PressureScale: 0.005
- SizeScale: 0.033
- OrientationCenter: 0.000
- OrientationScale: 0.000
- DistanceScale: 0.000
- HaveTilt: false
- TiltXCenter: 0.000
- TiltXScale: 0.000
- TiltYCenter: 0.000
- TiltYScale: 0.000
- Last Button State: 0x00000000
- Last Raw Touch: pointerCount=0
- Last Cooked Touch: pointerCount=0
-
-Here is an external keyboard / mouse combo HID device. (This device doesn't actually
-have a mouse but its HID descriptor says it does.)
-
- Device 7: Motorola Bluetooth Wireless Keyboard
- IsExternal: true
- Sources: 0x00002103
- KeyboardType: 2
- Motion Ranges:
- X: source=0x00002002, min=0.000, max=719.000, flat=0.000, fuzz=0.000
- Y: source=0x00002002, min=0.000, max=1279.000, flat=0.000, fuzz=0.000
- PRESSURE: source=0x00002002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
- VSCROLL: source=0x00002002, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
- Keyboard Input Mapper:
- Parameters:
- AssociatedDisplayId: -1
- OrientationAware: false
- KeyboardType: 2
- Orientation: 0
- KeyDowns: 0 keys currently down
- MetaState: 0x0
- DownTime: 75868832946000
- Cursor Input Mapper:
- Parameters:
- AssociatedDisplayId: 0
- Mode: pointer
- OrientationAware: false
- XScale: 1.000
- YScale: 1.000
- XPrecision: 1.000
- YPrecision: 1.000
- HaveVWheel: true
- HaveHWheel: false
- VWheelScale: 1.000
- HWheelScale: 1.000
- Orientation: 0
- ButtonState: 0x00000000
- Down: false
- DownTime: 0
-
-Here is a joystick. Notice how all of the axes have been scaled to a normalized
-range. The axis mapping can be configured using key layout files.
-
- Device 18: Logitech Logitech Cordless RumblePad 2
- IsExternal: true
- Sources: 0x01000511
- KeyboardType: 1
- Motion Ranges:
- X: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
- Y: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
- Z: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
- RZ: source=0x01000010, min=-1.000, max=1.000, flat=0.118, fuzz=0.000
- HAT_X: source=0x01000010, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
- HAT_Y: source=0x01000010, min=-1.000, max=1.000, flat=0.000, fuzz=0.000
- Keyboard Input Mapper:
- Parameters:
- AssociatedDisplayId: -1
- OrientationAware: false
- KeyboardType: 1
- Orientation: 0
- KeyDowns: 0 keys currently down
- MetaState: 0x0
- DownTime: 675270841000
- Joystick Input Mapper:
- Axes:
- X: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
- scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
- rawAxis=0, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
- Y: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
- scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
- rawAxis=1, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
- Z: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
- scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
- rawAxis=2, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
- RZ: min=-1.00000, max=1.00000, flat=0.11765, fuzz=0.00000
- scale=0.00784, offset=-1.00000, highScale=0.00784, highOffset=-1.00000
- rawAxis=5, rawMin=0, rawMax=255, rawFlat=15, rawFuzz=0, rawResolution=0
- HAT_X: min=-1.00000, max=1.00000, flat=0.00000, fuzz=0.00000
- scale=1.00000, offset=0.00000, highScale=1.00000, highOffset=0.00000
- rawAxis=16, rawMin=-1, rawMax=1, rawFlat=0, rawFuzz=0, rawResolution=0
- HAT_Y: min=-1.00000, max=1.00000, flat=0.00000, fuzz=0.00000
- scale=1.00000, offset=0.00000, highScale=1.00000, highOffset=0.00000
- rawAxis=17, rawMin=-1, rawMax=1, rawFlat=0, rawFuzz=0, rawResolution=0
-
-At the end of the input reader dump there is some information about global configuration
-parameters such as the mouse pointer speed.
-
- Configuration:
- ExcludedDeviceNames: []
- VirtualKeyQuietTime: 0.0ms
- PointerVelocityControlParameters: scale=1.000, lowThreshold=500.000, highThreshold=3000.000, acceleration=3.000
- WheelVelocityControlParameters: scale=1.000, lowThreshold=15.000, highThreshold=50.000, acceleration=4.000
- PointerGesture:
- Enabled: true
- QuietInterval: 100.0ms
- DragMinSwitchSpeed: 50.0px/s
- TapInterval: 150.0ms
- TapDragInterval: 300.0ms
- TapSlop: 20.0px
- MultitouchSettleInterval: 100.0ms
- MultitouchMinDistance: 15.0px
- SwipeTransitionAngleCosine: 0.3
- SwipeMaxWidthRatio: 0.2
- MovementSpeedRatio: 0.8
- ZoomSpeedRatio: 0.3
-
-#### Things To Look For ####
-
-1. All of the expected input devices are present.
-
-2. Each input device has been configured appropriately. Especially check the
- touch screen and joystick axes.
-
-### Input Dispatcher State ###
-
-The `InputDispatcher` is responsible for sending input events to applications.
-Its state dump shows information about which window is being touched, the
-state of the input queue, whether an ANR is in progress, and so on.
-
- Input Dispatcher State:
- DispatchEnabled: 1
- DispatchFrozen: 0
- FocusedApplication: name='AppWindowToken{41b03a10 token=Token{41bdcf78 ActivityRecord{418ab728 com.android.settings/.Settings}}}', dispatchingTimeout=5000.000ms
- FocusedWindow: name='Window{41908458 Keyguard paused=false}'
- TouchDown: false
- TouchSplit: false
- TouchDeviceId: -1
- TouchSource: 0x00000000
- TouchedWindows: <none>
- Windows:
- 0: name='Window{41bd5b18 NavigationBar paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x05800068, type=0x000007e3, layer=181000, frame=[0,1184][720,1280], scale=1.000000, touchableRegion=[0,1184][720,1280], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
- 1: name='Window{41a19770 RecentsPanel paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01820100, type=0x000007de, layer=151000, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
- 2: name='Window{41a78768 StatusBar paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x00800048, type=0x000007d0, layer=141000, frame=[0,0][720,50], scale=1.000000, touchableRegion=[0,0][720,50], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
- 3: name='Window{41877570 StatusBarExpanded paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x01811328, type=0x000007e1, layer=131005, frame=[0,-1184][720,-114], scale=1.000000, touchableRegion=[0,-1184][720,-114], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
- 4: name='Window{41bedf20 TrackingView paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01020300, type=0x000007e1, layer=131000, frame=[0,-1032][720,102], scale=1.000000, touchableRegion=[0,-1032][720,102], inputFeatures=0x00000000, ownerPid=306, ownerUid=1000, dispatchingTimeout=5000.000ms
- 5: name='Window{41908458 Keyguard paused=false}', paused=false, hasFocus=true, hasWallpaper=false, visible=true, canReceiveKeys=true, flags=0x15120800, type=0x000007d4, layer=111000, frame=[0,50][720,1184], scale=1.000000, touchableRegion=[0,50][720,1184], inputFeatures=0x00000000, ownerPid=205, ownerUid=1000, dispatchingTimeout=5000.000ms
- 6: name='Window{4192cc30 com.android.phasebeam.PhaseBeamWallpaper paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x00000308, type=0x000007dd, layer=21010, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=429, ownerUid=10046, dispatchingTimeout=5000.000ms
- 7: name='Window{41866c00 com.android.settings/com.android.settings.Settings paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01810100, type=0x00000001, layer=21005, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=19000, ownerUid=1000, dispatchingTimeout=5000.000ms
- 8: name='Window{4197c858 com.android.launcher/com.android.launcher2.Launcher paused=false}', paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01910100, type=0x00000001, layer=21000, frame=[0,0][720,1184], scale=1.000000, touchableRegion=[0,0][720,1184], inputFeatures=0x00000000, ownerPid=515, ownerUid=10032, dispatchingTimeout=5000.000ms
- MonitoringChannels: <none>
- InboundQueue: length=0
- ActiveConnections: <none>
- AppSwitch: not pending
- Configuration:
- MaxEventsPerSecond: 90
- KeyRepeatDelay: 50.0ms
- KeyRepeatTimeout: 500.0ms
-
-#### Things To Look For ####
-
-1. In general, all input events are being processed as expected.
-
-2. If you touch the touch screen and run dumpsys at the same time, then the `TouchedWindows`
- line should show the window that you are touching.
diff --git a/src/tech/input/getevent.md b/src/tech/input/getevent.md
deleted file mode 100644
index 5807753..0000000
--- a/src/tech/input/getevent.md
+++ /dev/null
@@ -1,112 +0,0 @@
-<!--
- 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.
--->
-
-# Getevent #
-
-The `getevent` tool runs on the device and provides information about input
-devices and a live dump of kernel input events.
-
-It is very useful tool for ensuring that device drivers are reporing the
-expected set of capabilities for each input device and are generating the
-desired stream of input events.
-
-## Usage ##
-
-### Showing Device Capabilities ###
-
-It is often quite useful to see all of the keys and axes that a device reports.
-Use the `-p` option to do that.
-
-Here is a list of all of the Linux key codes and other events that a
-particular keyboard says it supports.
-
- $ adb shell su -- getevent -p
-
- name: "Motorola Bluetooth Wireless Keyboard"
- events:
- KEY (0001): 0001 0002 0003 0004 0005 0006 0007 0008
- 0009 000a 000b 000c 000d 000e 000f 0010
- 0011 0012 0013 0014 0015 0016 0017 0018
- 0019 001a 001b 001c 001d 001e 001f 0020
- 0021 0022 0023 0024 0025 0026 0027 0028
- 0029 002a 002b 002c 002d 002e 002f 0030
- 0031 0032 0033 0034 0035 0036 0037 0038
- 0039 003a 003b 003c 003d 003e 003f 0040
- 0041 0042 0043 0044 0045 0046 0047 0048
- 0049 004a 004b 004c 004d 004e 004f 0050
- 0051 0052 0053 0055 0056 0057 0058 0059
- 005a 005b 005c 005d 005e 005f 0060 0061
- 0062 0063 0064 0066 0067 0068 0069 006a
- 006b 006c 006d 006e 006f 0071 0072 0073
- 0074 0075 0077 0079 007a 007b 007c 007d
- 007e 007f 0080 0081 0082 0083 0084 0085
- 0086 0087 0088 0089 008a 008c 008e 0090
- 0096 0098 009b 009c 009e 009f 00a1 00a3
- 00a4 00a5 00a6 00ab 00ac 00ad 00b0 00b1
- 00b2 00b3 00b4 00b7 00b8 00b9 00ba 00bb
- 00bc 00bd 00be 00bf 00c0 00c1 00c2 00d9
- 00f0 0110 0111 0112 01ba
- REL (0002): 0000 0001 0008
- ABS (0003): 0028 : value 223, min 0, max 255, fuzz 0, flat 0, resolution 0
- 0029 : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
- 002a : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
- 002b : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
- MSC (0004): 0004
- LED (0011): 0000 0001 0002 0003 0004
- input props:
- <none>
-
-The `-i` option shows even more information than `-p`, including HID mapping tables
-and debugging information.
-
-The `-l` option uses textual labels for all event codes, which is handy.
-
- $ adb shell su -- getevent -lp /dev/input/event1
-
- name: "Melfas MMSxxx Touchscreen"
- events:
- ABS (0003): ABS_MT_SLOT : value 0, min 0, max 9, fuzz 0, flat 0, resolution 0
- ABS_MT_TOUCH_MAJOR : value 0, min 0, max 30, fuzz 0, flat 0, resolution 0
- ABS_MT_POSITION_X : value 0, min 0, max 720, fuzz 0, flat 0, resolution 0
- ABS_MT_POSITION_Y : value 0, min 0, max 1280, fuzz 0, flat 0, resolution 0
- ABS_MT_TRACKING_ID : value 0, min 0, max 65535, fuzz 0, flat 0, resolution 0
- ABS_MT_PRESSURE : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
- input props:
- INPUT_PROP_DIRECT
-
-### Showing Live Events ###
-
-This is what a two finger multitouch gesture looks like for a touch screen
-that is using the Linux multitouch input protocol "B". We use the `-l` option
-to show textual labels and `-t` to show timestamps.
-
- $ adb shell su -- getevent -lt /dev/input/event1
-
- [ 78826.389007] EV_ABS ABS_MT_TRACKING_ID 0000001f
- [ 78826.389038] EV_ABS ABS_MT_PRESSURE 000000ab
- [ 78826.389038] EV_ABS ABS_MT_POSITION_X 000000ab
- [ 78826.389068] EV_ABS ABS_MT_POSITION_Y 0000025b
- [ 78826.389068] EV_ABS ABS_MT_SLOT 00000001
- [ 78826.389068] EV_ABS ABS_MT_TRACKING_ID 00000020
- [ 78826.389068] EV_ABS ABS_MT_PRESSURE 000000b9
- [ 78826.389099] EV_ABS ABS_MT_POSITION_X 0000019e
- [ 78826.389099] EV_ABS ABS_MT_POSITION_Y 00000361
- [ 78826.389099] EV_SYN SYN_REPORT 00000000
- [ 78826.468688] EV_ABS ABS_MT_SLOT 00000000
- [ 78826.468688] EV_ABS ABS_MT_TRACKING_ID ffffffff
- [ 78826.468719] EV_ABS ABS_MT_SLOT 00000001
- [ 78826.468719] EV_ABS ABS_MT_TRACKING_ID ffffffff
- [ 78826.468719] EV_SYN SYN_REPORT 00000000
diff --git a/src/tech/input/index.md b/src/tech/input/index.md
deleted file mode 100644
index e01f200..0000000
--- a/src/tech/input/index.md
+++ /dev/null
@@ -1,24 +0,0 @@
-<!--
- 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.
--->
-
-# Input Technical Information #
-
-The Android input subsystem supports many different device classes,
-including keyboard, joystick, trackball, mouse and touch screen.
-
-The documentation in this section describes how to configure,
-calibrate, test, and write drivers for input devices.
-
diff --git a/src/tech/input/input-device-configuration-files.md b/src/tech/input/input-device-configuration-files.md
deleted file mode 100644
index be6900a..0000000
--- a/src/tech/input/input-device-configuration-files.md
+++ /dev/null
@@ -1,152 +0,0 @@
-<!--
- 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.
--->
-
-# Input Device Configuration Files #
-
-Input device configuration files (`.idc` files) contain device-specific
-configuration properties that affect the behavior of input devices.
-
-Input device configuration files are typically not necessary for standard
-peripherals such as HID keyboards and mice since the default system behavior
-usually ensures that they will work out of the box. On the other hand,
-built-in embedded devices, particularly touch screens, almost always
-require input device configuration files to specify their behavior.
-
-## Rationale ##
-
-Android automatically detects and configures most input device capabilities
-based on the event types and properties that are reported by the associated
-Linux kernel input device driver.
-
-For example, if an input device supports the `EV_REL` event type and codes
-`REL_X` and `REL_Y` as well as the `EV_KEY` event type and `BTN_MOUSE`,
-then Android will classify the input device as a mouse. The default behavior
-for a mouse is to present an on-screen cursor which tracks the mouse's movements
-and simulates touches when the mouse is clicked. Although the mouse can
-be configured differently, the default behavior is usually sufficient for
-standard mouse peripherals.
-
-Certain classes of input devices are more ambiguous. For example, multi-touch
-touch screens and touch pads both support the `EV_ABS` event type and codes
-`ABS_MT_POSITION_X` and `ABS_MT_POSITION_Y` at a minimum. However, the intended
-uses of these devices are quite different and cannot always be determined
-automatically. Also, additional information is required to make sense of the
-pressure and size information reported by touch devices. Hence touch devices,
-especially built-in touch screens, usually need IDC files.
-
-## Location ##
-
-Input device configuration 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/idc/Vendor_XXXX_Product_XXXX_Version_XXXX.idc`
-* `/system/usr/idc/Vendor_XXXX_Product_XXXX.idc`
-* `/system/usr/idc/DEVICE_NAME.idc`
-* `/data/system/devices/idc/Vendor_XXXX_Product_XXXX_Version_XXXX.idc`
-* `/data/system/devices/idc/Vendor_XXXX_Product_XXXX.idc`
-* `/data/system/devices/idc/DEVICE_NAME.idc`
-
-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 '\_'.
-
-## Syntax ##
-
-An input device configuration file is a plain text file consisting of property
-assignments and comments.
-
-### Properties ###
-
-Property assignments each consist of a property name, an `=`, a property value,
-and a new line. Like this:
-
- property = value
-
-Property names are non-empty literal text identifiers. They must not contain
-whitespace. Each components of the input system defines a set of properties
-that are used to configure its function.
-
-Property values are non-empty string literals, integers or floating point numbers.
-They must not contain whitespace or the reserved characters `\` or `"`.
-
-Property names and values are case-sensitive.
-
-### Comments ###
-
-Comment lines begin with '#' and continue to the end of the line. Like this:
-
- # A comment!
-
-Blank lines are ignored.
-
-### Example ###
-
- # This is an example of an input device configuration file.
- # It might be used to describe the characteristics of a built-in touch screen.
-
- # This is an internal device, not an external peripheral attached to the USB
- # or Bluetooth bus.
- device.internal = 1
-
- # The device should behave as a touch screen, which uses the same orientation
- # as the built-in display.
- touch.deviceType = touchScreen
- touch.orientationAware = 1
-
- # Additional calibration properties...
- # etc...
-
-## Common Properties ##
-
-The following properties are common to all input device classes.
-
-Refer to the documentation of each input device class for information about the
-special properties used by each class.
-
-#### `device.internal` ####
-
-*Definition:* `device.internal` = `0` | `1`
-
-Specifies whether the input device is an internal built-in component as opposed to an
-externally attached (most likely removable) peripheral.
-
-* If the value is `0`, the device is external.
-
-* If the value is `1`, the device is internal.
-
-* If the value is not specified, the default value is `0` for all devices on the
- USB (BUS_USB) or Bluetooth (BUS_BLUETOOTH) bus, `1` otherwise.
-
-This property determines default policy decisions regarding wake events.
-
-Internal input devices generally do not wake the display from sleep unless explicitly
-configured to do so in the key layout file or in a hardcoded policy rule. This
-distinction prevents key presses and touches from spuriously waking up your phone
-when it is in your pocket. Usually there are only a small handful of wake keys defined.
-
-Conversely, external input devices usually wake the device more aggressively because
-they are assumed to be turned off or not plugged in during transport. For example,
-pressing any key on an external keyboard is a good indicator that the user wants the
-device to wake up and respond.
-
-It is important to ensure that the value of the `device.internal` property is set
-correctly for all internal input devices.
-
-## Validation ##
-
-Make sure to validate your input device configuration files using the
-[Validate Keymaps](/tech/input/validate-keymaps.html) tool.
diff --git a/src/tech/input/key-character-map-files.md b/src/tech/input/key-character-map-files.md
deleted file mode 100644
index 4a9ec34..0000000
--- a/src/tech/input/key-character-map-files.md
+++ /dev/null
@@ -1,493 +0,0 @@
-<!--
- 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 Character Map Files #
-
-Key character map files (`.kcm` files) are responsible for mapping combinations
-of Android key codes with modifiers to Unicode characters.
-
-Device-specific key layout files are *required* for all internal (built-in)
-input devices that have keys, if only to tell the system that the device
-is special purpose only (not a full keyboard).
-
-Device-specific key layout files are *optional* for external keyboards, and
-often aren't needed at all. The system provides a generic key character map
-that is suitable for many external keyboards.
-
-If no device-specific key layout file is available, then the system will
-choose a default instead.
-
-## Location ##
-
-Key character map 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/keychars/Vendor_XXXX_Product_XXXX_Version_XXXX.kcm`
-* `/system/usr/keychars/Vendor_XXXX_Product_XXXX.kcm`
-* `/system/usr/keychars/DEVICE_NAME.kcm`
-* `/data/system/devices/keychars/Vendor_XXXX_Product_XXXX_Version_XXXX.kcm`
-* `/data/system/devices/keychars/Vendor_XXXX_Product_XXXX.kcm`
-* `/data/system/devices/keychars/DEVICE_NAME.kcm`
-* `/system/usr/keychars/Generic.kcm`
-* `/data/system/devices/keychars/Generic.kcm`
-* `/system/usr/keychars/Virtual.kcm`
-* `/data/system/devices/keychars/Virtual.kcm`
-
-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 Character Map File ##
-
-The system provides a special built-in key character map file called `Generic.kcm`.
-This key character map is intended to support a variety of standard external
-keyboards.
-
-*Do not modify the generic key character map!*
-
-## Virtual Key Character Map File ##
-
-The system provides a special built-in key character map file called `Virtual.kcm`
-that is used by the virtual keyboard devices.
-
-The virtual keyboard device is a synthetic input device whose id is -1
-(see `KeyCharacterMap.VIRTUAL_KEYBOARD`). It is present on all Android devices
-beginning with Android Honeycomb 3.0. The purpose of the virtual keyboard device
-is to provide a known built-in input device that can be used for injecting
-keystokes into applications by the IME or by test instrumentation, even
-for devices that do not have built-in keyboards.
-
-The virtual keyboard is assumed to have a full QWERTY layout that is the
-same on all devices. This makes it possible for applications to inject
-keystrokes using the virtual keyboard device and always get the same results.
-
-*Do not modify the virtual key character map!*
-
-## Syntax ##
-
-A key character map file is a plain text file consisting of a keyboard type
-declaration and a set of key declarations.
-
-### Keyboard Type Declaration ###
-
-A keyboard type declaration describes the overall behavior of the keyboard.
-A character map file must contain a keyboard type declaration. For clarity,
-it is often placed at the top of the file.
-
- type FULL
-
-The following keyboard types are recognized:
-
-* `NUMERIC`: A numeric (12-key) keyboard.
-
- A numeric keyboard supports text entry using a multi-tap approach.
- It may be necessary to tap a key multiple times to generate the desired letter or symbol.
-
- This type of keyboard is generally designed for thumb typing.
-
- Corresponds to `KeyCharacterMap.NUMERIC`.
-
-* `PREDICTIVE`: A keyboard with all the letters, but with more than one letter per key.
-
- This type of keyboard is generally designed for thumb typing.
-
- Corresponds to `KeyCharacterMap.PREDICTIVE`.
-
-* `ALPHA`: A keyboard with all the letters, and maybe some numbers.
-
- An alphabetic keyboard supports text entry directly but may have a condensed
- layout with a small form factor. In contrast to a `FULL` keyboard, some
- symbols may only be accessible using special on-screen character pickers.
- In addition, to improve typing speed and accuracy, the framework provides
- special affordances for alphabetic keyboards such as auto-capitalization
- and toggled / locked SHIFT and ALT keys.
-
- This type of keyboard is generally designed for thumb typing.
-
-* `FULL`: A full PC-style keyboard.
-
- A full keyboard behaves like a PC keyboard. All symbols are accessed directly
- by pressing keys on the keyboard without on-screen support or affordances such
- as auto-capitalization.
-
- This type of keyboard is generally designed for full two hand typing.
-
-* `SPECIAL_FUNCTION`: A keyboard that is only used to perform system control functions
- rather than for typing.
-
- A special function keyboard consists only of non-printing keys such as
- HOME and POWER that are not actually used for typing.
-
-The `Generic.kcm` and `Virtual.kcm` key character maps are both `FULL` keyboards.
-
-### Key Declarations ###
-
-Key declarations each consist of the keyword `key` followed by an Android key code
-name, an open curly brace, a set of properties and behaviors and a close curly brace.
-
- key A {
- label: 'A'
- base: 'a'
- shift, capslock: 'A'
- ctrl, alt, meta: none
- }
-
-#### Properties ####
-
-Each key property establishes a mapping from a key to a behavior. To make the
-key character map files more compact, several properties can be mapped to the
-same behavior by separating them with a comma.
-
-In the above example, the `label` property is assigned the `'A'` behavior.
-Likewise, the `ctrl`, `alt` and `meta` properties are all simultaneously assigned
-the `none` behavior.
-
-The following properties are recognized:
-
-* `label`: Specifies the label that is physically printed on the key, when it
- consists of a single character. This is the value that is returned by
- the `KeyCharacterMap.getDisplayLabel` method.
-
-* `number`: Specifies the behavior (character that should be typed) when a numeric
- text view has focus, such as when the user is typing a phone number.
-
- Compact keyboards often combine multiple symbols into a single key, such that
- the same key might be used to type `'1'` and `'a'` or `'#'` and `'q'`, perhaps.
- For these keys, the `number` property should be set to indicate which symbol
- should be typed in a numeric context, if any.
-
- Some typical "numeric" symbols are digits `'0'` through `'9'`, `'#'`, `'+'`,
- `'('`, `')'`, `','`, and `'.'`.
-
-* `base`: Specifies the behavior (character that should be typed) when no modifiers
- are pressed.
-
-* <modifier> or <modifier1>`+`<modifier2>`+`...: Specifies the
- behavior (character that should be typed) when the key is pressed and all of the
- specified modifiers are active.
-
- For example, the modifier property `shift` specifies a behavior that applies when
- the either the LEFT SHIFT or RIGHT SHIFT modifier is pressed.
-
- Similarly, the modifier property `rshift+ralt` specifies a behavior that applies
- when the both RIGHT SHIFT and RIGHT ALT modifiers are pressed together.
-
-The following modifiers are recognized in modifier properties:
-
-* `shift`: Applies when either the LEFT SHIFT or RIGHT SHIFT modifier is pressed.
-* `lshift`: Applies when the LEFT SHIFT modifier is pressed.
-* `rshift`: Applies when the RIGHT SHIFT modifier is pressed.
-* `alt`: Applies when either the LEFT ALT or RIGHT ALT modifier is pressed.
-* `lalt`: Applies when the LEFT ALT modifier is pressed.
-* `ralt`: Applies when the RIGHT ALT modifier is pressed.
-* `ctrl`: Applies when either the LEFT CONTROL or RIGHT CONTROL modifier is pressed.
-* `lctrl`: Applies when the LEFT CONTROL modifier is pressed.
-* `rctrl`: Applies when the RIGHT CONTROL modifier is pressed.
-* `meta`: Applies when either the LEFT META or RIGHT META modifier is pressed.
-* `lmeta`: Applies when the LEFT META modifier is pressed.
-* `rmeta`: Applies when the RIGHT META modifier is pressed.
-* `sym`: Applies when the SYMBOL modifier is pressed.
-* `fn`: Applies when the FUNCTION modifier is pressed.
-* `capslock`: Applies when the CAPS LOCK modifier is locked.
-* `numlock`: Applies when the NUM LOCK modifier is locked.
-* `scrolllock`: Applies when the SCROLL LOCK modifier is locked.
-
-The order in which the properties are listed is significant. When mapping a key to
-a behavior, the system scans all relevant properties in order and returns the last
-applicable behavior that it found.
-
-Consequently, properties that are specified later override properties that are
-specified earlier for a given key.
-
-#### Behaviors ####
-
-Each property maps to a behavior. The most common behavior is typing a character
-but there are others.
-
-The following behaviors are recognized:
-
-* `none`: Don't type a character.
-
- This behavior is the default when no character is specified. Specifying `none`
- is optional but it improves clarity.
-
-* `'X'`: Type the specified character literal.
-
- This behavior causes the specified character to be entered into the focused
- text view. The character literal may be any ASCII character, or one of the
- following escape sequences:
-
- * `'\\'`: Type a backslash character.
- * `'\n'`: Type a new line character (use this for ENTER / RETURN).
- * `'\t'`: Type a TAB character.
- * `'\''`: Type an apostrophe character.
- * `'\"'`: Type a quote character.
- * `'\uXXXX'`: Type the Unicode character whose code point is given in hex by XXXX.
-
-* `fallback` <Android key code name>: Perform a default action if the key is not
- handled by the application.
-
- This behavior causes the system to simulate a different key press when an application
- does not handle the specified key natively. It is used to support default behavior
- for new keys that not all applications know how to handle, such as ESCAPE or
- numeric keypad keys (when numlock is not pressed).
-
- When a fallback behavior is performed, the application will receive two key presses:
- one for the original key and another for the fallback key that was selected.
- If the application handles the original key during key up, then the fallback key
- event will be canceled (`KeyEvent.isCanceled` will return `true`).
-
-The system reserves two Unicode characters to perform special functions:
-
-* `'\uef00'`: When this behavior is performed, the text view consumes and removes the
- four characters preceding the cursor, interprets them as hex digits, and inserts the
- corresponding Unicode code point.
-
-* `'\uef01'`: When this behavior is performed, the text view displays a
- character picker dialog that contains miscellaneous symbols.
-
-The system recognizes the following Unicode characters as combining diacritical dead
-key characters:
-
-* `'\u0300'`: Grave accent.
-* `'\u0301'`: Acute accent.
-* `'\u0302'`: Circumflex accent.
-* `'\u0303'`: Tilde accent.
-* `'\u0308'`: Umlaut accent.
-
-When a dead key is typed followed by another character, the dead key and the following
-characters are composed. For example, when the user types a grave accent dead
-key followed by the letter 'a', the result is 'à'.
-
-Refer to `KeyCharacterMap.getDeadChar` for more information about dead key handling.
-
-### Comments ###
-
-Comment lines begin with '#' and continue to the end of the line. Like this:
-
- # A comment!
-
-Blank lines are ignored.
-
-### How Key Combinations are Mapped to Behaviors ###
-
-When the user presses a key, the system looks up the behavior associated with
-the combination of that key press and the currently pressed modifiers.
-
-#### SHIFT + A ####
-
-Suppose the user pressed A and SHIFT together. The system first locates
-the set of properties and behaviors associated with `KEYCODE_A`.
-
- key A {
- label: 'A'
- base: 'a'
- shift, capslock: 'A'
- ctrl, alt, meta: none
- }
-
-The system scans the properties from first to last and left to right, ignoring
-the `label` and `number` properties, which are special.
-
-The first property encountered is `base`. The `base` property always applies to
-a key, no matter what modifiers are pressed. It essentially specifies the default
-behavior for the key unless it is overridden by following properties.
-Since the `base` property applies to this key press, the system makes note
-of the fact that its behavior is `'a'` (type the character `a`).
-
-The system then continues to scan subsequent properties in case any of them
-are more specific than `base` and override it. It encounters `shift` which
-also applies to the key press SHIFT + A. So the system decides to ignore
-the `base` property's behavior and chooses the behavior associated with
-the `shift` property, which is `'A'` (type the character `A`).
-
-It then continues to scan the table, however no other properties apply to this
-key press (CAPS LOCK is not locked, neither CONTROL key is pressed, neither
-ALT key is pressed and neither META key is pressed).
-
-So the resulting behavior for the key combination SHIFT + A is `'A'`.
-
-#### CONTROL + A ####
-
-Now consider what would happen if the user pressed A and CONTROL together.
-
-As before, the system would scan the table of properties. It would notice
-that the `base` property applied but would also continue scanning until
-it eventually reached the `control` property. As it happens, the `control`
-property appears after `base` so its behavior overrides the `base` behavior.
-
-So the resulting behavior for the key combination CONTROL + A is `none`.
-
-#### ESCAPE ####
-
-Now suppose the user pressed ESCAPE.
-
- key ESCAPE {
- base: fallback BACK
- alt, meta: fallback HOME
- ctrl: fallback MENU
- }
-
-This time the system obtains the behavior `fallback BACK`, a fallback behavior.
-Because no character literal appears, no character will be typed.
-
-When processing the key, the system will first deliver `KEYCODE_ESCAPE` to the
-application. If the application does not handle it, then the system will try
-again but this time it will deliver `KEYCODE_BACK` to the application as
-requested by the fallback behavior.
-
-So applications that recognize and support `KEYCODE_ESCAPE` have the
-opportunity to handle it as is, but other applications that do not can instead
-perform the fallback action of treating the key as if it were `KEYCODE_BACK`.
-
-#### NUMPAD_0 with or without NUM LOCK ####
-
-The numeric keypad keys have very different interpretations depending on whether
-the NUM LOCK key is locked.
-
-The following key declaration ensures that `KEYCODE_NUMPAD_0` types `0`
-when NUM LOCK is pressed. When NUM LOCK is not pressed, the key is delivered
-to the application as usual, and if it is not handled, then the fallback
-key `KEYCODE_INSERT` is delivered instead.
-
- key NUMPAD_0 {
- label, number: '0'
- base: fallback INSERT
- numlock: '0'
- ctrl, alt, meta: none
- }
-
-As we can see, fallback key declarations greatly improve compatibility
-with older applications that do not recognize or directly support all of the keys
-that are present on a full PC style keyboard.
-
-### Examples ###
-
-#### Full Keyboard ####
-
- # This is an example of part of a key character map file for a full keyboard
- # include a few fallback behaviors for special keys that few applications
- # handle themselves.
-
- type FULL
-
- key C {
- label: 'C'
- base: 'c'
- shift, capslock: 'C'
- alt: '\u00e7'
- shift+alt: '\u00c7'
- ctrl, meta: none
- }
-
- key SPACE {
- label: ' '
- base: ' '
- ctrl: none
- alt, meta: fallback SEARCH
- }
-
- key NUMPAD_9 {
- label, number: '9'
- base: fallback PAGE_UP
- numlock: '9'
- ctrl, alt, meta: none
- }
-
-#### Alphanumeric Keyboard ####
-
- # This is an example of part of a key character map file for an alphanumeric
- # thumb keyboard. Some keys are combined, such as `A` and `2`. Here we
- # specify `number` labels to tell the system what to do when the user is
- # typing a number into a dial pad.
- #
- # Also note the special character '\uef01' mapped to ALT+SPACE.
- # Pressing this combination of keys invokes an on-screen character picker.
-
- type ALPHA
-
- key A {
- label: 'A'
- number: '2'
- base: 'a'
- shift, capslock: 'A'
- alt: '#'
- shift+alt, capslock+alt: none
- }
-
- key SPACE {
- label: ' '
- number: ' '
- base: ' '
- shift: ' '
- alt: '\uef01'
- shift+alt: '\uef01'
- }
-
-#### Game Pad ####
-
- # This is an example of part of a key character map file for a game pad.
- # It defines fallback actions that enable the user to navigate the user interface
- # by pressing buttons.
-
- type SPECIAL_FUNCTION
-
- key BUTTON_A {
- base: fallback BACK
- }
-
- key BUTTON_X {
- base: fallback DPAD_CENTER
- }
-
- key BUTTON_START {
- base: fallback HOME
- }
-
- key BUTTON_SELECT {
- base: fallback MENU
- }
-
-## Compatibility Note ##
-
-Prior to Android Honeycomb 3.0, the Android key character map was specified
-using a very different syntax and was compiled into a binary file format
-(`.kcm.bin`) at build time.
-
-Although the new format uses the same extension `.kcm`, the syntax is quite
-different (and much more powerful).
-
-As of Android Honeycomb 3.0, all Android key character map files must use
-the new syntax and plain text file format that is described in this document.
-The old syntax is not supported and the old `.kcm.bin` files are not recognized
-by the system.
-
-## Language Note ##
-
-Android does not currently support multilingual keyboards. Moreover, the
-built-in generic key character map assumes a US English keyboard layout.
-
-OEMs are encouraged to provide custom key character maps for their keyboards
-if they are designed for other languages.
-
-Future versions of Android may provide better support for multilingual keyboards
-or user-selectable keyboard layouts.
-
-## Validation ##
-
-Make sure to validate your key character map files using the
-[Validate Keymaps](/tech/input/validate-keymaps.html) tool.
diff --git a/src/tech/input/key-layout-files.md b/src/tech/input/key-layout-files.md
deleted file mode 100644
index 9a2760d..0000000
--- a/src/tech/input/key-layout-files.md
+++ /dev/null
@@ -1,332 +0,0 @@
-<!--
- 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, an Android key code name, and optional set of whitespace delimited policy flags.
-
- key 1 ESCAPE
- key 114 VOLUME_DOWN WAKE
- key 16 Q VIRTUAL WAKE
-
-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/input/keyboard-devices.md b/src/tech/input/keyboard-devices.md
deleted file mode 100644
index 955d579..0000000
--- a/src/tech/input/keyboard-devices.md
+++ /dev/null
@@ -1,1002 +0,0 @@
-<!--
- 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.
--->
-
-# Keyboard Devices #
-
-Android supports a variety of keyboard devices including special function
-keypads (volume and power controls), compact embedded QWERTY keyboards,
-and fully featured PC-style external keyboards.
-
-This document decribes physical keyboards only. Refer to the Android SDK
-for information about soft keyboards (Input Method Editors).
-
-## Keyboard Classification ##
-
-An input device is classified as a keyboard if either of the following
-conditions hold:
-
-* The input device reports the presence of any Linux key codes used on keyboards
- including `0` through `0xff` or `KEY_OK` through `KEY_MAX`.
-
-* The input device reports the presence of any Linux key codes used on joysticks
- and gamepads including `BTN_0` through `BTN_9`, `BTN_TRIGGER` through `BTN_DEAD`,
- or `BTN_A` through `BTN_THUMBR`.
-
-Joysticks are currently classified as keyboards because joystick and gamepad buttons
-are reported by `EV_KEY` events in the same way keyboard keys are reported. Thus
-joysticks and gamepads also make use of key map files for configuration.
-Refer to the section on [Joystick Devices](/tech/input/joystick-devices.html) for
-more information.
-
-Once an input device has been classified as a keyboard, the system loads the
-input device configuration file and keyboard layout for the keyboard.
-
-The system then tries to determine additional characteristics of the device.
-
-* If the input device has any keys that are mapped to `KEYCODE_Q`, then the
- device is considered to have an alphabetic keypad (as opposed to numeric).
- The alphabetic keypad capability is reported in the resource `Configuration`
- object as `KEYBOARD_QWERTY`.
-
-* If the input device has any keys that are mapped to `KEYCODE_DPAD_UP`,
- `KEYCODE_DPAD_DOWN`, `KEYCODE_DPAD_LEFT`, `KEYCODE_DPAD_RIGHT`, and
- `KEYCODE_DPAD_CENTER` (all must be present), then the device is considered
- to have a directional keypad.
- The directional keypad capability is reported in the resource `Configuration`
- object as `NAVIGATION_DPAD`.
-
-* If the input device has any keys that are mapped to `KEYCODE_BUTTON_A`
- or other gamepad related keys, then the device is considered to have a gamepad.
-
-## Keyboard Driver Requirements ##
-
-1. Keyboard drivers should only register key codes for the keys that they
- actually support. Registering excess key codes may confuse the device
- classification algorithm or cause the system to incorrectly detect
- the supported keyboard capabilities of the device.
-
-2. Keyboard drivers should use `EV_KEY` to report key presses, using a value
- of `0` to indicate that a key is released, a value of `1` to indicate that
- a key is pressed, and a value greater than or equal to `2` to indicate that
- the key is being repeated automatically.
-
-3. Android performs its own keyboard repeating. Auto-repeat functionality
- should be disabled in the driver.
-
-4. Keyboard drivers may optionally indicate the HID usage or low-level scan
- code by sending `EV_MSC` with `MSC_SCANCODE` and a valud indicating the usage
- or scan code when the key is pressed. This information is not currently
- used by Android.
-
-5. Keyboard drivers should support setting LED states when `EV_LED` is written
- to the device. The `hid-input` driver handles this automatically.
- At the time of this writing, Android uses `LED_CAPSLOCK`, `LED_SCROLLLOCK`,
- and `LED_NUMLOCK`. These LEDs only need to be supported when the
- keyboard actually has the associated indicator lights.
-
-6. Keyboard drivers for embedded keypads (for example, using a GPIO matrix)
- should make sure to send `EV_KEY` events with a value of `0` for any keys that
- are still pressed when the device is going to sleep. Otherwise keys might
- get stuck down and will auto-repeat forever.
-
-## Keyboard Operation ##
-
-The following is a brief summary of the keyboard operation on Android.
-
-1. The `EventHub` reads raw events from the `evdev` driver and maps Linux key codes
- (sometimes referred to as scan codes) into Android key codes using the
- keyboard's key layout map.
-
-2. The `InputReader` consumes the raw events and updates the meta key state.
- For example, if the left shift key is pressed or released, the reader will
- set or reset the `META_SHIFT_LEFT_ON` and `META_SHIFT_ON` bits accordingly.
-
-3. The `InputReader` notifies the `InputDispatcher` about the key event.
-
-4. The `InputDispatcher` asks the `WindowManagerPolicy` what to do with the key
- event by calling `WindowManagerPolicy.interceptKeyBeforeQueueing`. This method
- is part of a critical path that is responsible for waking the device when
- certain keys are pressed. The `EventHub` effectively holds a wake lock
- along this critical path to ensure that it will run to completion.
-
-5. If an `InputFilter` is currently in use, the `InputDispatcher` gives it a
- chance to consume or transform the key. The `InputFilter` may be used to implement
- low-level system-wide accessibility policies.
-
-6. The `InputDispatcher` enqueues the key for processing on the dispatch thread.
-
-7. When the `InputDispatcher` dequeues the key, it gives the `WindowManagerPolicy`
- a second chance to intercept the key event by calling
- `WindowManagerPolicy.interceptKeyBeforeDispatching`. This method handles system
- shortcuts and other functions.
-
-8. The `InputDispatcher` then identifies the key event target (the focused window)
- and waits for them to become ready. Then, the `InputDispatcher` delivers the
- key event to the application.
-
-9. Inside the application, the key event propagates down the view hierarchy to
- the focused view for pre-IME key dispatch.
-
-10. If the key event is not handled in the pre-IME dispatch and an IME is in use, the
- key event is delivered to the IME.
-
-11. If the key event was not consumed by the IME, then the key event propagates
- down the view hierarchy to the focused view for standard key dispatch.
-
-12. The application reports back to the `InputDispatcher` as to whether the key
- event was consumed. If the event was not consumed, the `InputDispatcher`
- calls `WindowManagerPolicy.dispatchUnhandledKey` to apply "fallback" behavior.
- Depending on the fallback action, the key event dispatch cycle may be restarted
- using a different key code. For example, if an application does not handle
- `KEYCODE_ESCAPE`, the system may redispatch the key event as `KEYCODE_BACK` instead.
-
-## Keyboard Configuration ##
-
-Keyboard behavior is determined by the keyboard's key layout, key character
-map and input device configuration.
-
-Refer to the following sections for more details about the files that
-participate in keyboard configuration:
-
-* [Key Layout Files](/tech/input/key-layout-files.html)
-* [Key Character Map Files](/tech/input/key-character-map-files.html)
-* [Input Device Configuration Files](/tech/input/input-device-configuration-files.html)
-
-### Properties ###
-
-The following input device configuration properties are used for keyboards.
-
-#### `keyboard.layout` ####
-
-*Definition:* `keyboard.layout` = <name>
-
-Specifies the name of the key layout file associated with the input device,
-excluding the `.kl` extension. If this file is not found, the input system
-will use the default key layout instead.
-
-Spaces in the name are converted to underscores during lookup.
-
-Refer to the key layout file documentation for more details.
-
-#### `keyboard.characterMap` ####
-
-*Definition:* `keyboard.characterMap` = <name>
-
-Specifies the name of the key character map file associated with the input device,
-excluding the `.kcm` extension. If this file is not found, the input system
-will use the default key character map instead.
-
-Spaces in the name are converted to underscores during lookup.
-
-Refer to the key character map file documentation for more details.
-
-#### `keyboard.orientationAware` ####
-
-*Definition:* `keyboard.orientationAware` = `0` | `1`
-
-Specifies whether the keyboard should react to display orientation changes.
-
-* If the value is `1`, the directional keypad keys are rotated when the
- associated display orientation changes.
-
-* If the value is `0`, the keyboard is immune to display orientation changes.
-
-The default value is `0`.
-
-Orientation awareness is used to support rotation of directional keypad keys,
-such as on the Motorola Droid. For example, when the device is rotated
-clockwise 90 degrees from its natural orientation, `KEYCODE_DPAD_UP` is
-remapped to produce `KEYCODE_DPAD_RIGHT` since the 'up' key ends up pointing
-'right' when the device is held in that orientation.
-
-#### `keyboard.builtIn` ####
-
-*Definition:* `keyboard.builtIn` = `0` | `1`
-
-Specifies whether the keyboard is the built-in (physically attached)
-keyboard.
-
-The default value is `1` if the device name ends with `-keypad`, `0` otherwise.
-
-The built-in keyboard is always assigned a device id of `0`. Other keyboards
-that are not built-in are assigned unique non-zero device ids.
-
-Using an id of `0` for the built-in keyboard is important for maintaining
-compatibility with the `KeyCharacterMap.BUILT_IN_KEYBOARD` field, which specifies
-the id of the built-in keyboard and has a value of `0`. This field has been
-deprecated in the API but older applications might still be using it.
-
-A special-function keyboard (one whose key character map specifies a
-type of `SPECIAL_FUNCTION`) will never be registered as the built-in keyboard,
-regardless of the setting of this property. This is because a special-function
-keyboard is by definition not intended to be used for general purpose typing.
-
-### Example Configurations ###
-
- # This is an example input device configuration file for a built-in
- # keyboard that has a DPad.
-
- # The keyboard is internal because it is part of the device.
- device.internal = 1
-
- # The keyboard is the default built-in keyboard so it should be assigned
- # an id of 0.
- keyboard.builtIn = 1
-
- # The keyboard includes a DPad which is mounted on the device. As the device
- # is rotated the orientation of the DPad rotates along with it, so the DPad must
- # be aware of the display orientation. This ensures that pressing 'up' on the
- # DPad always means 'up' from the perspective of the user, even when the entire
- # device has been rotated.
- keyboard.orientationAware = 1
-
-### Compatibility Notes ###
-
-Prior to Honeycomb, the keyboard input mapper did not use any configuration properties.
-All keyboards were assumed to be physically attached and orientation aware. The default
-key layout and key character map was named `qwerty` instead of `Generic`. The key
-character map format was also very different and the framework did not support
-PC-style full keyboards or external keyboards.
-
-When upgrading devices to Honeycomb, make sure to create or update the necessary
-configuration and key map files.
-
-## HID Usages, Linux Key Codes and Android Key Codes ##
-
-The system refers to keys using several different identifiers, depending on the
-layer of abstraction.
-
-For HID devices, each key has an associated HID usage. The Linux `hid-input`
-driver and related vendor and device-specific HID drivers are responsible
-for parsing HID reports and mapping HID usages to Linux key codes.
-
-As Android reads `EV_KEY` events from the Linux kernel, it translates each
-Linux key code into its corresponding Android key code according to the
-key layout file of the device.
-
-When the key event is dispatched to an application, the `android.view.KeyEvent`
-instance reports the Linux key code as the value of `getScanCode()` and the
-Android key code as the value of `getKeyCode()`. For the purposes of the
-framework, only the value of `getKeyCode()` is important.
-
-Note that the HID usage information is not used by Android itself or
-passed to applications.
-
-## Code Tables ##
-
-The following tables show how HID usages, Linux key codes and Android
-key codes are related to one another.
-
-The LKC column specifies the Linux key code in hexadecimal.
-
-The AKC column specifies the Android key code in hexadecimal.
-
-The Notes column refers to notes that are posted after the table.
-
-The Version column specifies the first version of the Android platform
-to have included this key in its default key map. Multiple rows are
-shown in cases where the default key map has changed between versions.
-The oldest version indicated is 1.6.
-
-* In Gingerbread (2.3) and earlier releases, the default key map was
- `qwerty.kl`. This key map was only intended for use with the Android
- Emulator and was not intended to be used to support arbitrary
- external keyboards. Nevertheless, a few OEMs added Bluetooth
- keyboard support to the platform and relied on `qwerty.kl` to
- provide the necessary keyboard mappings. Consequently these
- older mappings may be of interest to OEMs who are building
- peripherals for these particular devices. Note that the mappings
- are substantially different from the current ones, particularly
- with respect to the treatment of the `HOME` key. It is recommended
- that all new peripherals be developed according to the Honeycomb or more
- recent key maps (ie. standard HID).
-
-* As of Honeycomb (3.0), the default key map is `Generic.kl`.
- This key map was designed to support full PC style keyboards.
- Most functionality of standard HID keyboards should just work out
- of the box.
-
-The key code mapping may vary across versions of the Linux kernel and Android.
-When changes are known to have occurred in the Android default key maps,
-they are indicated in the version column.
-
-Device-specific HID drivers and key maps may apply different mappings
-than are indicated here.
-
-### HID Keyboard and Keypad Page (0x07) ###
-
-| HID Usage | HID Usage Name | LKC | Linux Key Code Name | Version | AKC | Android Key Code Name | Notes |
-| ----------- | -------------------------------- | ------ | -------------------------------- | ------- | ------ | -------------------------------- | ----- |
-| 0x07 0x0001 | Keyboard Error Roll Over | | | | | | |
-| 0x07 0x0002 | Keyboard POST Fail | | | | | | |
-| 0x07 0x0003 | Keyboard Error Undefined | | | | | | |
-| 0x07 0x0004 | Keyboard a and A | 0x001e | KEY_A | 1.6 | 0x001d | KEYCODE_A | 1 |
-| 0x07 0x0005 | Keyboard b and B | 0x0030 | KEY_B | 1.6 | 0x001e | KEYCODE_B | 1 |
-| 0x07 0x0006 | Keyboard c and C | 0x002e | KEY_C | 1.6 | 0x001f | KEYCODE_C | 1 |
-| 0x07 0x0007 | Keyboard d and D | 0x0020 | KEY_D | 1.6 | 0x0020 | KEYCODE_D | 1 |
-| 0x07 0x0008 | Keyboard e and E | 0x0012 | KEY_E | 1.6 | 0x0021 | KEYCODE_E | 1 |
-| 0x07 0x0009 | Keyboard f and F | 0x0021 | KEY_F | 1.6 | 0x0022 | KEYCODE_F | 1 |
-| 0x07 0x000a | Keyboard g and G | 0x0022 | KEY_G | 1.6 | 0x0023 | KEYCODE_G | 1 |
-| 0x07 0x000b | Keyboard h and H | 0x0023 | KEY_H | 1.6 | 0x0024 | KEYCODE_H | 1 |
-| 0x07 0x000c | Keyboard i and I | 0x0017 | KEY_I | 1.6 | 0x0025 | KEYCODE_I | 1 |
-| 0x07 0x000d | Keyboard j and J | 0x0024 | KEY_J | 1.6 | 0x0026 | KEYCODE_J | 1 |
-| 0x07 0x000e | Keyboard k and K | 0x0025 | KEY_K | 1.6 | 0x0027 | KEYCODE_K | 1 |
-| 0x07 0x000f | Keyboard l and L | 0x0026 | KEY_L | 1.6 | 0x0028 | KEYCODE_L | 1 |
-| 0x07 0x0010 | Keyboard m and M | 0x0032 | KEY_M | 1.6 | 0x0029 | KEYCODE_M | 1 |
-| 0x07 0x0011 | Keyboard n and N | 0x0031 | KEY_N | 1.6 | 0x002a | KEYCODE_N | 1 |
-| 0x07 0x0012 | Keyboard o and O | 0x0018 | KEY_O | 1.6 | 0x002b | KEYCODE_O | 1 |
-| 0x07 0x0013 | Keyboard p and P | 0x0019 | KEY_P | 1.6 | 0x002c | KEYCODE_P | 1 |
-| 0x07 0x0014 | Keyboard q and Q | 0x0010 | KEY_Q | 1.6 | 0x002d | KEYCODE_Q | 1 |
-| 0x07 0x0015 | Keyboard r and R | 0x0013 | KEY_R | 1.6 | 0x002e | KEYCODE_R | 1 |
-| 0x07 0x0016 | Keyboard s and S | 0x001f | KEY_S | 1.6 | 0x002f | KEYCODE_S | 1 |
-| 0x07 0x0017 | Keyboard t and T | 0x0014 | KEY_T | 1.6 | 0x0030 | KEYCODE_T | 1 |
-| 0x07 0x0018 | Keyboard u and U | 0x0016 | KEY_U | 1.6 | 0x0031 | KEYCODE_U | 1 |
-| 0x07 0x0019 | Keyboard v and V | 0x002f | KEY_V | 1.6 | 0x0032 | KEYCODE_V | 1 |
-| 0x07 0x001a | Keyboard w and W | 0x0011 | KEY_W | 1.6 | 0x0033 | KEYCODE_W | 1 |
-| 0x07 0x001b | Keyboard x and X | 0x002d | KEY_X | 1.6 | 0x0034 | KEYCODE_X | 1 |
-| 0x07 0x001c | Keyboard y and Y | 0x0015 | KEY_Y | 1.6 | 0x0035 | KEYCODE_Y | 1 |
-| 0x07 0x001d | Keyboard z and Z | 0x002c | KEY_Z | 1.6 | 0x0036 | KEYCODE_Z | 1 |
-| 0x07 0x001e | Keyboard 1 and ! | 0x0002 | KEY_1 | 1.6 | 0x0008 | KEYCODE_1 | 1 |
-| 0x07 0x001f | Keyboard 2 and @ | 0x0003 | KEY_2 | 1.6 | 0x0009 | KEYCODE_2 | 1 |
-| 0x07 0x0020 | Keyboard 3 and # | 0x0004 | KEY_3 | 1.6 | 0x000a | KEYCODE_3 | 1 |
-| 0x07 0x0021 | Keyboard 4 and $ | 0x0005 | KEY_4 | 1.6 | 0x000b | KEYCODE_4 | 1 |
-| 0x07 0x0022 | Keyboard 5 and % | 0x0006 | KEY_5 | 1.6 | 0x000c | KEYCODE_5 | 1 |
-| 0x07 0x0023 | Keyboard 6 and ^ | 0x0007 | KEY_6 | 1.6 | 0x000d | KEYCODE_6 | 1 |
-| 0x07 0x0024 | Keyboard 7 and & | 0x0008 | KEY_7 | 1.6 | 0x000e | KEYCODE_7 | 1 |
-| 0x07 0x0025 | Keyboard 8 and * | 0x0009 | KEY_8 | 1.6 | 0x000f | KEYCODE_8 | 1 |
-| 0x07 0x0026 | Keyboard 9 and ( | 0x000a | KEY_9 | 1.6 | 0x0010 | KEYCODE_9 | 1 |
-| 0x07 0x0027 | Keyboard 0 and ) | 0x000b | KEY_0 | 1.6 | 0x0007 | KEYCODE_0 | 1 |
-| 0x07 0x0028 | Keyboard Return (ENTER) | 0x001c | KEY_ENTER | 1.6 | 0x0042 | KEYCODE_ENTER | 1 |
-| 0x07 0x0029 | Keyboard ESCAPE | 0x0001 | KEY_ESC | 3.0 | 0x006f | KEYCODE_ESCAPE | |
-| "" | "" | "" | "" | 2.3 | 0x0004 | KEYCODE_BACK | |
-| 0x07 0x002a | Keyboard DELETE (Backspace) | 0x000e | KEY_BACKSPACE | 1.6 | 0x0043 | KEYCODE_DEL | |
-| 0x07 0x002b | Keyboard Tab | 0x000f | KEY_TAB | 1.6 | 0x003d | KEYCODE_TAB | |
-| 0x07 0x002c | Keyboard Spacebar | 0x0039 | KEY_SPACE | 1.6 | 0x003e | KEYCODE_SPACE | |
-| 0x07 0x002d | Keyboard - and _ | 0x000c | KEY_MINUS | 1.6 | 0x0045 | KEYCODE_MINUS | 1 |
-| 0x07 0x002e | Keyboard = and + | 0x000d | KEY_EQUAL | 1.6 | 0x0046 | KEYCODE_EQUALS | 1 |
-| 0x07 0x002f | Keyboard \[ and \{ | 0x001a | KEY_LEFTBRACE | 1.6 | 0x0047 | KEYCODE_LEFT_BRACKET | 1 |
-| 0x07 0x0030 | Keyboard \] and \} | 0x001b | KEY_RIGHTBRACE | 1.6 | 0x0048 | KEYCODE_RIGHT_BRACKET | 1 |
-| 0x07 0x0031 | Keyboard \\ and | | 0x002b | KEY_BACKSLASH | 1.6 | 0x0049 | KEYCODE_BACKSLASH | 1 |
-| 0x07 0x0032 | Keyboard Non-US # and ~ | 0x002b | KEY_BACKSLASH | 1.6 | 0x0049 | KEYCODE_BACKSLASH | 1 |
-| 0x07 0x0033 | Keyboard ; and : | 0x0027 | KEY_SEMICOLON | 1.6 | 0x004a | KEYCODE_SEMICOLON | 1 |
-| 0x07 0x0034 | Keyboard ' and " | 0x0028 | KEY_APOSTROPHE | 1.6 | 0x004b | KEYCODE_APOSTROPHE | 1 |
-| 0x07 0x0035 | Keyboard \` and ~ | 0x0029 | KEY_GRAVE | 3.0 | 0x0044 | KEYCODE_GRAVE | 1 |
-| 0x07 0x0036 | Keyboard , and < | 0x0033 | KEY_COMMA | 1.6 | 0x0037 | KEYCODE_COMMA | 1 |
-| 0x07 0x0037 | Keyboard . and > | 0x0034 | KEY_DOT | 1.6 | 0x0038 | KEYCODE_PERIOD | 1 |
-| 0x07 0x0038 | Keyboard / and ? | 0x0035 | KEY_SLASH | 1.6 | 0x004c | KEYCODE_SLASH | 1 |
-| 0x07 0x0039 | Keyboard Caps Lock | 0x003a | KEY_CAPSLOCK | 3.0 | 0x0073 | KEYCODE_CAPS_LOCK | |
-| 0x07 0x003a | Keyboard F1 | 0x003b | KEY_F1 | 3.0 | 0x0083 | KEYCODE_F1 | |
-| "" | "" | "" | "" | 1.6 | 0x0052 | KEYCODE_MENU | |
-| 0x07 0x003b | Keyboard F2 | 0x003c | KEY_F2 | 3.0 | 0x0084 | KEYCODE_F2 | |
-| "" | "" | "" | "" | 1.6 | 0x0002 | KEYCODE_SOFT_RIGHT | |
-| 0x07 0x003c | Keyboard F3 | 0x003d | KEY_F3 | 3.0 | 0x0085 | KEYCODE_F3 | |
-| "" | "" | "" | "" | 1.6 | 0x0005 | KEYCODE_CALL | |
-| 0x07 0x003d | Keyboard F4 | 0x003e | KEY_F4 | 3.0 | 0x0086 | KEYCODE_F4 | |
-| "" | "" | "" | "" | 1.6 | 0x0006 | KEYCODE_ENDCALL | |
-| 0x07 0x003e | Keyboard F5 | 0x003f | KEY_F5 | 3.0 | 0x0087 | KEYCODE_F5 | |
-| 0x07 0x003f | Keyboard F6 | 0x0040 | KEY_F6 | 3.0 | 0x0088 | KEYCODE_F6 | |
-| 0x07 0x0040 | Keyboard F7 | 0x0041 | KEY_F7 | 3.0 | 0x0089 | KEYCODE_F7 | |
-| 0x07 0x0041 | Keyboard F8 | 0x0042 | KEY_F8 | 3.0 | 0x008a | KEYCODE_F8 | |
-| 0x07 0x0042 | Keyboard F9 | 0x0043 | KEY_F9 | 3.0 | 0x008b | KEYCODE_F9 | |
-| 0x07 0x0043 | Keyboard F10 | 0x0044 | KEY_F10 | 3.0 | 0x008c | KEYCODE_F10 | |
-| "" | "" | "" | "" | 2.3 | 0x0052 | KEYCODE_MENU | |
-| 0x07 0x0044 | Keyboard F11 | 0x0057 | KEY_F11 | 3.0 | 0x008d | KEYCODE_F11 | |
-| 0x07 0x0045 | Keyboard F12 | 0x0058 | KEY_F12 | 3.0 | 0x008e | KEYCODE_F12 | |
-| 0x07 0x0046 | Keyboard Print Screen | 0x0063 | KEY_SYSRQ | 3.0 | 0x0078 | KEYCODE_SYSRQ | |
-| 0x07 0x0047 | Keyboard Scroll Lock | 0x0046 | KEY_SCROLLLOCK | 3.0 | 0x0074 | KEYCODE_SCROLL_LOCK | |
-| 0x07 0x0048 | Keyboard Pause | 0x0077 | KEY_PAUSE | 3.0 | 0x0079 | KEYCODE_BREAK | |
-| 0x07 0x0049 | Keyboard Insert | 0x006e | KEY_INSERT | 3.0 | 0x007c | KEYCODE_INSERT | |
-| 0x07 0x004a | Keyboard Home | 0x0066 | KEY_HOME | 3.0 | 0x007a | KEYCODE_MOVE_HOME | |
-| "" | "" | "" | "" | 1.6 | 0x0003 | KEYCODE_HOME | |
-| 0x07 0x004b | Keyboard Page Up | 0x0068 | KEY_PAGEUP | 3.0 | 0x005c | KEYCODE_PAGE_UP | |
-| 0x07 0x004c | Keyboard Delete Forward | 0x006f | KEY_DELETE | 3.0 | 0x0070 | KEYCODE_FORWARD_DEL | |
-| 0x07 0x004d | Keyboard End | 0x006b | KEY_END | 3.0 | 0x007b | KEYCODE_MOVE_END | |
-| "" | "" | "" | "" | 1.6 | 0x0006 | KEYCODE_ENDCALL | |
-| 0x07 0x004e | Keyboard Page Down | 0x006d | KEY_PAGEDOWN | 3.0 | 0x005d | KEYCODE_PAGE_DOWN | |
-| 0x07 0x004f | Keyboard Right Arrow | 0x006a | KEY_RIGHT | 1.6 | 0x0016 | KEYCODE_DPAD_RIGHT | |
-| 0x07 0x0050 | Keyboard Left Arrow | 0x0069 | KEY_LEFT | 1.6 | 0x0015 | KEYCODE_DPAD_LEFT | |
-| 0x07 0x0051 | Keyboard Down Arrow | 0x006c | KEY_DOWN | 1.6 | 0x0014 | KEYCODE_DPAD_DOWN | |
-| 0x07 0x0052 | Keyboard Up Arrow | 0x0067 | KEY_UP | 1.6 | 0x0013 | KEYCODE_DPAD_UP | |
-| 0x07 0x0053 | Keyboard Num Lock and Clear | 0x0045 | KEY_NUMLOCK | 3.0 | 0x008f | KEYCODE_NUM_LOCK | |
-| 0x07 0x0054 | Keypad / | 0x0062 | KEY_KPSLASH | 3.0 | 0x009a | KEYCODE_NUMPAD_DIVIDE | |
-| 0x07 0x0055 | Keypad * | 0x0037 | KEY_KPASTERISK | 3.0 | 0x009b | KEYCODE_NUMPAD_MULTIPLY | |
-| 0x07 0x0056 | Keypad - | 0x004a | KEY_KPMINUS | 3.0 | 0x009c | KEYCODE_NUMPAD_SUBTRACT | |
-| 0x07 0x0057 | Keypad + | 0x004e | KEY_KPPLUS | 3.0 | 0x009d | KEYCODE_NUMPAD_ADD | |
-| 0x07 0x0058 | Keypad ENTER | 0x0060 | KEY_KPENTER | 3.0 | 0x00a0 | KEYCODE_NUMPAD_ENTER | |
-| 0x07 0x0059 | Keypad 1 and End | 0x004f | KEY_KP1 | 3.0 | 0x0091 | KEYCODE_NUMPAD_1 | |
-| 0x07 0x005a | Keypad 2 and Down Arrow | 0x0050 | KEY_KP2 | 3.0 | 0x0092 | KEYCODE_NUMPAD_2 | |
-| 0x07 0x005b | Keypad 3 and PageDn | 0x0051 | KEY_KP3 | 3.0 | 0x0093 | KEYCODE_NUMPAD_3 | |
-| 0x07 0x005c | Keypad 4 and Left Arrow | 0x004b | KEY_KP4 | 3.0 | 0x0094 | KEYCODE_NUMPAD_4 | |
-| 0x07 0x005d | Keypad 5 | 0x004c | KEY_KP5 | 3.0 | 0x0095 | KEYCODE_NUMPAD_5 | |
-| 0x07 0x005e | Keypad 6 and Right Arrow | 0x004d | KEY_KP6 | 3.0 | 0x0096 | KEYCODE_NUMPAD_6 | |
-| 0x07 0x005f | Keypad 7 and Home | 0x0047 | KEY_KP7 | 3.0 | 0x0097 | KEYCODE_NUMPAD_7 | |
-| 0x07 0x0060 | Keypad 8 and Up Arrow | 0x0048 | KEY_KP8 | 3.0 | 0x0098 | KEYCODE_NUMPAD_8 | |
-| 0x07 0x0061 | Keypad 9 and Page Up | 0x0049 | KEY_KP9 | 3.0 | 0x0099 | KEYCODE_NUMPAD_9 | |
-| 0x07 0x0062 | Keypad 0 and Insert | 0x0052 | KEY_KP0 | 3.0 | 0x0090 | KEYCODE_NUMPAD_0 | |
-| 0x07 0x0063 | Keypad . and Delete | 0x0053 | KEY_KPDOT | 3.0 | 0x009e | KEYCODE_NUMPAD_DOT | |
-| 0x07 0x0064 | Keyboard Non-US \\ and | | 0x0056 | KEY_102ND | 4.0 | 0x0049 | KEYCODE_BACKSLASH | 1 |
-| 0x07 0x0065 | Keyboard Application | 0x007f | KEY_COMPOSE | 3.0 | 0x0052 | KEYCODE_MENU | |
-| "" | "" | "" | "" | 1.6 | 0x0054 | KEYCODE_SEARCH | |
-| 0x07 0x0066 | Keyboard Power | 0x0074 | KEY_POWER | 1.6 | 0x001a | KEYCODE_POWER | |
-| 0x07 0x0067 | Keypad = | 0x0075 | KEY_KPEQUAL | 3.0 | 0x00a1 | KEYCODE_NUMPAD_EQUALS | |
-| 0x07 0x0068 | Keyboard F13 | 0x00b7 | KEY_F13 | | | | |
-| 0x07 0x0069 | Keyboard F14 | 0x00b8 | KEY_F14 | | | | |
-| 0x07 0x006a | Keyboard F15 | 0x00b9 | KEY_F15 | | | | |
-| 0x07 0x006b | Keyboard F16 | 0x00ba | KEY_F16 | | | | |
-| 0x07 0x006c | Keyboard F17 | 0x00bb | KEY_F17 | | | | |
-| 0x07 0x006d | Keyboard F18 | 0x00bc | KEY_F18 | | | | |
-| 0x07 0x006e | Keyboard F19 | 0x00bd | KEY_F19 | | | | |
-| 0x07 0x006f | Keyboard F20 | 0x00be | KEY_F20 | | | | |
-| 0x07 0x0070 | Keyboard F21 | 0x00bf | KEY_F21 | | | | |
-| 0x07 0x0071 | Keyboard F22 | 0x00c0 | KEY_F22 | | | | |
-| 0x07 0x0072 | Keyboard F23 | 0x00c1 | KEY_F23 | | | | |
-| 0x07 0x0073 | Keyboard F24 | 0x00c2 | KEY_F24 | | | | |
-| 0x07 0x0074 | Keyboard Execute | 0x0086 | KEY_OPEN | | | | |
-| 0x07 0x0075 | Keyboard Help | 0x008a | KEY_HELP | | | | |
-| 0x07 0x0076 | Keyboard Menu | 0x0082 | KEY_PROPS | | | | |
-| 0x07 0x0077 | Keyboard Select | 0x0084 | KEY_FRONT | | | | |
-| 0x07 0x0078 | Keyboard Stop | 0x0080 | KEY_STOP | 3.0 | 0x0056 | KEYCODE_MEDIA_STOP | |
-| 0x07 0x0079 | Keyboard Again | 0x0081 | KEY_AGAIN | | | | |
-| 0x07 0x007a | Keyboard Undo | 0x0083 | KEY_UNDO | | | | |
-| 0x07 0x007b | Keyboard Cut | 0x0089 | KEY_CUT | | | | |
-| 0x07 0x007c | Keyboard Copy | 0x0085 | KEY_COPY | | | | |
-| 0x07 0x007d | Keyboard Paste | 0x0087 | KEY_PASTE | | | | |
-| 0x07 0x007e | Keyboard Find | 0x0088 | KEY_FIND | | | | |
-| 0x07 0x007f | Keyboard Mute | 0x0071 | KEY_MUTE | 3.0 | 0x00a4 | KEYCODE_VOLUME_MUTE | |
-| 0x07 0x0080 | Keyboard Volume Up | 0x0073 | KEY_VOLUMEUP | 1.6 | 0x0018 | KEYCODE_VOLUME_UP | |
-| 0x07 0x0081 | Keyboard Volume Down | 0x0072 | KEY_VOLUMEDOWN | 1.6 | 0x0019 | KEYCODE_VOLUME_DOWN | |
-| 0x07 0x0082 | Keyboard Locking Caps Lock | | | | | | |
-| 0x07 0x0083 | Keyboard Locking Num Lock | | | | | | |
-| 0x07 0x0084 | Keyboard Locking Scroll Lock | | | | | | |
-| 0x07 0x0085 | Keypad Comma | 0x0079 | KEY_KPCOMMA | 3.0 | 0x009f | KEYCODE_NUMPAD_COMMA | |
-| 0x07 0x0086 | Keypad Equal Sign | | | | | | |
-| 0x07 0x0087 | Keyboard International1 | 0x0059 | KEY_RO | | | | |
-| 0x07 0x0088 | Keyboard International2 | 0x005d | KEY_KATAKANAHIRAGANA | | | | |
-| 0x07 0x0089 | Keyboard International3 | 0x007c | KEY_YEN | | | | |
-| 0x07 0x008a | Keyboard International4 | 0x005c | KEY_HENKAN | | | | |
-| 0x07 0x008b | Keyboard International5 | 0x005e | KEY_MUHENKAN | | | | |
-| 0x07 0x008c | Keyboard International6 | 0x005f | KEY_KPJPCOMMA | | | | |
-| 0x07 0x008d | Keyboard International7 | | | | | | |
-| 0x07 0x008e | Keyboard International8 | | | | | | |
-| 0x07 0x008f | Keyboard International9 | | | | | | |
-| 0x07 0x0090 | Keyboard LANG1 | 0x007a | KEY_HANGEUL | | | | |
-| 0x07 0x0091 | Keyboard LANG2 | 0x007b | KEY_HANJA | | | | |
-| 0x07 0x0092 | Keyboard LANG3 | 0x005a | KEY_KATAKANA | | | | |
-| 0x07 0x0093 | Keyboard LANG4 | 0x005b | KEY_HIRAGANA | | | | |
-| 0x07 0x0094 | Keyboard LANG5 | 0x0055 | KEY_ZENKAKUHANKAKU | | | | |
-| 0x07 0x0095 | Keyboard LANG6 | | | | | | |
-| 0x07 0x0096 | Keyboard LANG7 | | | | | | |
-| 0x07 0x0097 | Keyboard LANG8 | | | | | | |
-| 0x07 0x0098 | Keyboard LANG9 | | | | | | |
-| 0x07 0x0099 | Keyboard Alternate Erase | | | | | | |
-| 0x07 0x009a | Keyboard SysReq/Attention | | | | | | |
-| 0x07 0x009b | Keyboard Cancel | | | | | | |
-| 0x07 0x009c | Keyboard Clear | | | | | | |
-| 0x07 0x009d | Keyboard Prior | | | | | | |
-| 0x07 0x009e | Keyboard Return | | | | | | |
-| 0x07 0x009f | Keyboard Separator | | | | | | |
-| 0x07 0x00a0 | Keyboard Out | | | | | | |
-| 0x07 0x00a1 | Keyboard Oper | | | | | | |
-| 0x07 0x00a2 | Keyboard Clear/Again | | | | | | |
-| 0x07 0x00a3 | Keyboard CrSel/Props | | | | | | |
-| 0x07 0x00a4 | Keyboard ExSel | | | | | | |
-| 0x07 0x00b0 | Keypad 00 | | | | | | |
-| 0x07 0x00b1 | Keypad 000 | | | | | | |
-| 0x07 0x00b2 | Thousands Separator | | | | | | |
-| 0x07 0x00b3 | Decimal Separator | | | | | | |
-| 0x07 0x00b4 | Currency Unit | | | | | | |
-| 0x07 0x00b5 | Currency Sub-unit | | | | | | |
-| 0x07 0x00b6 | Keypad ( | 0x00b3 | KEY_KPLEFTPAREN | 3.0 | 0x00a2 | KEYCODE_NUMPAD_LEFT_PAREN | |
-| 0x07 0x00b7 | Keypad ) | 0x00b4 | KEY_KPRIGHTPAREN | 3.0 | 0x00a3 | KEYCODE_NUMPAD_RIGHT_PAREN | |
-| 0x07 0x00b8 | Keypad \{ | | | | | | |
-| 0x07 0x00b9 | Keypad \} | | | | | | |
-| 0x07 0x00ba | Keypad Tab | | | | | | |
-| 0x07 0x00bb | Keypad Backspace | | | | | | |
-| 0x07 0x00bc | Keypad A | | | | | | |
-| 0x07 0x00bd | Keypad B | | | | | | |
-| 0x07 0x00be | Keypad C | | | | | | |
-| 0x07 0x00bf | Keypad D | | | | | | |
-| 0x07 0x00c0 | Keypad E | | | | | | |
-| 0x07 0x00c1 | Keypad F | | | | | | |
-| 0x07 0x00c2 | Keypad XOR | | | | | | |
-| 0x07 0x00c3 | Keypad ^ | | | | | | |
-| 0x07 0x00c4 | Keypad % | | | | | | |
-| 0x07 0x00c5 | Keypad < | | | | | | |
-| 0x07 0x00c6 | Keypad > | | | | | | |
-| 0x07 0x00c7 | Keypad & | | | | | | |
-| 0x07 0x00c8 | Keypad && | | | | | | |
-| 0x07 0x00c9 | Keypad | | | | | | | |
-| 0x07 0x00ca | Keypad || | | | | | | |
-| 0x07 0x00cb | Keypad : | | | | | | |
-| 0x07 0x00cc | Keypad # | | | | | | |
-| 0x07 0x00cd | Keypad Space | | | | | | |
-| 0x07 0x00ce | Keypad @ | | | | | | |
-| 0x07 0x00cf | Keypad ! | | | | | | |
-| 0x07 0x00d0 | Keypad Memory Store | | | | | | |
-| 0x07 0x00d1 | Keypad Memory Recall | | | | | | |
-| 0x07 0x00d2 | Keypad Memory Clear | | | | | | |
-| 0x07 0x00d3 | Keypad Memory Add | | | | | | |
-| 0x07 0x00d4 | Keypad Memory Subtract | | | | | | |
-| 0x07 0x00d5 | Keypad Memory Multiply | | | | | | |
-| 0x07 0x00d6 | Keypad Memory Divide | | | | | | |
-| 0x07 0x00d7 | Keypad +/- | | | | | | |
-| 0x07 0x00d8 | Keypad Clear | | | | | | |
-| 0x07 0x00d9 | Keypad Clear Entry | | | | | | |
-| 0x07 0x00da | Keypad Binary | | | | | | |
-| 0x07 0x00db | Keypad Octal | | | | | | |
-| 0x07 0x00dc | Keypad Decimal | | | | | | |
-| 0x07 0x00dd | Keypad Hexadecimal | | | | | | |
-| 0x07 0x00e0 | Keyboard Left Control | 0x001d | KEY_LEFTCTRL | 3.0 | 0x0071 | KEYCODE_CTRL_LEFT | |
-| 0x07 0x00e1 | Keyboard Left Shift | 0x002a | KEY_LEFTSHIFT | 1.6 | 0x003b | KEYCODE_SHIFT_LEFT | |
-| 0x07 0x00e2 | Keyboard Left Alt | 0x0038 | KEY_LEFTALT | 1.6 | 0x0039 | KEYCODE_ALT_LEFT | |
-| 0x07 0x00e3 | Keyboard Left GUI | 0x007d | KEY_LEFTMETA | 3.0 | 0x0075 | KEYCODE_META_LEFT | |
-| 0x07 0x00e4 | Keyboard Right Control | 0x0061 | KEY_RIGHTCTRL | 3.0 | 0x0072 | KEYCODE_CTRL_RIGHT | |
-| 0x07 0x00e5 | Keyboard Right Shift | 0x0036 | KEY_RIGHTSHIFT | 1.6 | 0x003c | KEYCODE_SHIFT_RIGHT | |
-| 0x07 0x00e6 | Keyboard Right Alt | 0x0064 | KEY_RIGHTALT | 1.6 | 0x003a | KEYCODE_ALT_RIGHT | |
-| 0x07 0x00e7 | Keyboard Right GUI | 0x007e | KEY_RIGHTMETA | 3.0 | 0x0076 | KEYCODE_META_RIGHT | |
-| 0x07 0x00e8 | | 0x00a4 | KEY_PLAYPAUSE | 3.0 | 0x0055 | KEYCODE_MEDIA_PLAY_PAUSE | |
-| 0x07 0x00e9 | | 0x00a6 | KEY_STOPCD | 3.0 | 0x0056 | KEYCODE_MEDIA_STOP | |
-| 0x07 0x00ea | | 0x00a5 | KEY_PREVIOUSSONG | 3.0 | 0x0058 | KEYCODE_MEDIA_PREVIOUS | |
-| 0x07 0x00eb | | 0x00a3 | KEY_NEXTSONG | 3.0 | 0x0057 | KEYCODE_MEDIA_NEXT | |
-| 0x07 0x00ec | | 0x00a1 | KEY_EJECTCD | 3.0 | 0x0081 | KEYCODE_MEDIA_EJECT | |
-| 0x07 0x00ed | | 0x0073 | KEY_VOLUMEUP | 1.6 | 0x0018 | KEYCODE_VOLUME_UP | |
-| 0x07 0x00ee | | 0x0072 | KEY_VOLUMEDOWN | 1.6 | 0x0019 | KEYCODE_VOLUME_DOWN | |
-| 0x07 0x00ef | | 0x0071 | KEY_MUTE | 3.0 | 0x00a4 | KEYCODE_VOLUME_MUTE | |
-| 0x07 0x00f0 | | 0x0096 | KEY_WWW | 1.6 | 0x0040 | KEYCODE_EXPLORER | |
-| 0x07 0x00f1 | | 0x009e | KEY_BACK | 1.6 | 0x0004 | KEYCODE_BACK | |
-| 0x07 0x00f2 | | 0x009f | KEY_FORWARD | 3.0 | 0x007d | KEYCODE_FORWARD | |
-| 0x07 0x00f3 | | 0x0080 | KEY_STOP | 3.0 | 0x0056 | KEYCODE_MEDIA_STOP | |
-| 0x07 0x00f4 | | 0x0088 | KEY_FIND | | | | |
-| 0x07 0x00f5 | | 0x00b1 | KEY_SCROLLUP | 3.0 | 0x005c | KEYCODE_PAGE_UP | |
-| 0x07 0x00f6 | | 0x00b2 | KEY_SCROLLDOWN | 3.0 | 0x005d | KEYCODE_PAGE_DOWN | |
-| 0x07 0x00f7 | | 0x00b0 | KEY_EDIT | | | | |
-| 0x07 0x00f8 | | 0x008e | KEY_SLEEP | | | | |
-| 0x07 0x00f9 | | 0x0098 | KEY_COFFEE | 4.0 | 0x001a | KEYCODE_POWER | |
-| 0x07 0x00fa | | 0x00ad | KEY_REFRESH | | | | |
-| 0x07 0x00fb | | 0x008c | KEY_CALC | 4.0.3 | 0x00d2 | KEYCODE_CALCULATOR | |
-
-### HID Generic Desktop Page (0x01) ###
-
-| HID Usage | HID Usage Name | LKC | Linux Key Code Name | Version | AKC | Android Key Code Name | Notes |
-| ----------- | -------------------------------- | ------ | -------------------------------- | ------- | ------ | -------------------------------- | ----- |
-| 0x01 0x0081 | System Power Down | 0x0074 | KEY_POWER | 1.6 | 0x001a | KEYCODE_POWER | |
-| 0x01 0x0082 | System Sleep | 0x008e | KEY_SLEEP | 4.0 | 0x001a | KEYCODE_POWER | |
-| 0x01 0x0083 | System Wake Up | 0x008f | KEY_WAKEUP | 4.0 | 0x001a | KEYCODE_POWER | |
-| 0x01 0x0084 | System Context Menu | | | | | | |
-| 0x01 0x0085 | System Main Menu | | | | | | |
-| 0x01 0x0086 | System App Menu | | | | | | |
-| 0x01 0x0087 | System Menu Help | | | | | | |
-| 0x01 0x0088 | System Menu Exit | | | | | | |
-| 0x01 0x0089 | System Menu Select | | | | | | |
-| 0x01 0x008a | System Menu Right | | | | | | |
-| 0x01 0x008b | System Menu Left | | | | | | |
-| 0x01 0x008c | System Menu Up | | | | | | |
-| 0x01 0x008d | System Menu Down | | | | | | |
-| 0x01 0x008e | System Cold Restart | | | | | | |
-| 0x01 0x008f | System Warm Restart | | | | | | |
-| 0x01 0x00a0 | System Dock | | | | | | |
-| 0x01 0x00a1 | System Undock | | | | | | |
-| 0x01 0x00a2 | System Setup | | | | | | |
-| 0x01 0x00a3 | System Break | | | | | | |
-| 0x01 0x00a4 | System Debugger Break | | | | | | |
-| 0x01 0x00a5 | Application Break | | | | | | |
-| 0x01 0x00a6 | Application Debugger Break | | | | | | |
-| 0x01 0x00a7 | System Speaker Mute | | | | | | |
-| 0x01 0x00a8 | System Hibernate | | | | | | |
-| 0x01 0x00b0 | System Display Invert | | | | | | |
-| 0x01 0x00b1 | System Display Internal | | | | | | |
-| 0x01 0x00b2 | System Display External | | | | | | |
-| 0x01 0x00b3 | System Display Both | | | | | | |
-| 0x01 0x00b4 | System Display Dual | | | | | | |
-| 0x01 0x00b5 | System Display Toggle Int/Ext | | | | | | |
-| 0x01 0x00b6 | System Display Swap Prim./Sec. | | | | | | |
-| 0x01 0x00b7 | System Display LCD Autoscale | | | | | | |
-
-### HID Consumer Page (0x0c) ###
-
-| HID Usage | HID Usage Name | LKC | Linux Key Code Name | Version | AKC | Android Key Code Name | Notes |
-| ----------- | -------------------------------- | ------ | -------------------------------- | ------- | ------ | -------------------------------- | ----- |
-| 0x0c 0x0030 | Power | | | | | | |
-| 0x0c 0x0031 | Reset | | | | | | |
-| 0x0c 0x0032 | Sleep | | | | | | |
-| 0x0c 0x0033 | Sleep After | | | | | | |
-| 0x0c 0x0034 | Sleep Mode | 0x008e | KEY_SLEEP | 4.0 | 0x001a | KEYCODE_POWER | |
-| 0x0c 0x0040 | Menu | 0x008b | KEY_MENU | 1.6 | 0x0052 | KEYCODE_MENU | |
-| 0x0c 0x0041 | Menu Pick | | | | | | |
-| 0x0c 0x0042 | Menu Up | | | | | | |
-| 0x0c 0x0043 | Menu Down | | | | | | |
-| 0x0c 0x0044 | Menu Left | | | | | | |
-| 0x0c 0x0045 | Menu Right | 0x0181 | KEY_RADIO | | | | |
-| 0x0c 0x0046 | Menu Escape | | | | | | |
-| 0x0c 0x0047 | Menu Value Increase | | | | | | |
-| 0x0c 0x0048 | Menu Value Decrease | | | | | | |
-| 0x0c 0x0081 | Assign Selection | | | | | | |
-| 0x0c 0x0082 | Mode Step | | | | | | |
-| 0x0c 0x0083 | Recall Last | 0x0195 | KEY_LAST | | | | |
-| 0x0c 0x0084 | Enter Channel | | | | | | |
-| 0x0c 0x0085 | Order Movie | | | | | | |
-| 0x0c 0x0088 | Media Select Computer | 0x0178 | KEY_PC | | | | |
-| 0x0c 0x0089 | Media Select TV | 0x0179 | KEY_TV | 3.0 | 0x00aa | KEYCODE_TV | |
-| 0x0c 0x008a | Media Select WWW | 0x0096 | KEY_WWW | 1.6 | 0x0040 | KEYCODE_EXPLORER | |
-| 0x0c 0x008b | Media Select DVD | 0x0185 | KEY_DVD | | | | |
-| 0x0c 0x008c | Media Select Telephone | 0x00a9 | KEY_PHONE | 3.0 | 0x0005 | KEYCODE_CALL | |
-| 0x0c 0x008d | Media Select Program Guide | 0x016a | KEY_PROGRAM | 3.0 | 0x00ac | KEYCODE_GUIDE | |
-| 0x0c 0x008e | Media Select Video Phone | 0x01a0 | KEY_VIDEOPHONE | | | | |
-| 0x0c 0x008f | Media Select Games | 0x01a1 | KEY_GAMES | | | | |
-| 0x0c 0x0090 | Media Select Messages | 0x018c | KEY_MEMO | | | | |
-| 0x0c 0x0091 | Media Select CD | 0x017f | KEY_CD | | | | |
-| 0x0c 0x0092 | Media Select VCR | 0x017b | KEY_VCR | | | | |
-| 0x0c 0x0093 | Media Select Tuner | 0x0182 | KEY_TUNER | | | | |
-| 0x0c 0x0094 | Quit | 0x00ae | KEY_EXIT | | | | |
-| 0x0c 0x0095 | Help | 0x008a | KEY_HELP | | | | |
-| 0x0c 0x0096 | Media Select Tape | 0x0180 | KEY_TAPE | | | | |
-| 0x0c 0x0097 | Media Select Cable | 0x017a | KEY_TV2 | | | | |
-| 0x0c 0x0098 | Media Select Satellite | 0x017d | KEY_SAT | | | | |
-| 0x0c 0x0099 | Media Select Security | | | | | | |
-| 0x0c 0x009a | Media Select Home | 0x016e | KEY_PVR | 3.0 | 0x00ad | KEYCODE_DVR | |
-| 0x0c 0x009c | Channel Increment | 0x0192 | KEY_CHANNELUP | 3.0 | 0x00a6 | KEYCODE_CHANNEL_UP | |
-| 0x0c 0x009d | Channel Decrement | 0x0193 | KEY_CHANNELDOWN | 3.0 | 0x00a7 | KEYCODE_CHANNEL_DOWN | |
-| 0x0c 0x009e | Media Select SAP | | | | | | |
-| 0x0c 0x00a0 | VCR Plus | 0x017c | KEY_VCR2 | | | | |
-| 0x0c 0x00a1 | Once | | | | | | |
-| 0x0c 0x00a2 | Daily | | | | | | |
-| 0x0c 0x00a3 | Weekly | | | | | | |
-| 0x0c 0x00a4 | Monthly | | | | | | |
-| 0x0c 0x00b0 | Play | 0x00cf | KEY_PLAY | 3.0 | 0x007e | KEYCODE_MEDIA_PLAY | |
-| 0x0c 0x00b1 | Pause | 0x0077 | KEY_PAUSE | 3.0 | 0x0079 | KEYCODE_BREAK | |
-| 0x0c 0x00b2 | Record | 0x00a7 | KEY_RECORD | 3.0 | 0x0082 | KEYCODE_MEDIA_RECORD | |
-| 0x0c 0x00b3 | Fast Forward | 0x00d0 | KEY_FASTFORWARD | 3.0 | 0x005a | KEYCODE_MEDIA_FAST_FORWARD | |
-| 0x0c 0x00b4 | Rewind | 0x00a8 | KEY_REWIND | 3.0 | 0x0059 | KEYCODE_MEDIA_REWIND | |
-| 0x0c 0x00b5 | Scan Next Track | 0x00a3 | KEY_NEXTSONG | 3.0 | 0x0057 | KEYCODE_MEDIA_NEXT | |
-| 0x0c 0x00b6 | Scan Previous Track | 0x00a5 | KEY_PREVIOUSSONG | 3.0 | 0x0058 | KEYCODE_MEDIA_PREVIOUS | |
-| 0x0c 0x00b7 | Stop | 0x00a6 | KEY_STOPCD | 3.0 | 0x0056 | KEYCODE_MEDIA_STOP | |
-| 0x0c 0x00b8 | Eject | 0x00a1 | KEY_EJECTCD | 3.0 | 0x0081 | KEYCODE_MEDIA_EJECT | |
-| 0x0c 0x00b9 | Random Play | | | | | | |
-| 0x0c 0x00ba | Select Disc | | | | | | |
-| 0x0c 0x00bb | Enter Disc | | | | | | |
-| 0x0c 0x00bc | Repeat | 0x01b7 | KEY_MEDIA_REPEAT | | | | |
-| 0x0c 0x00be | Track Normal | | | | | | |
-| 0x0c 0x00c0 | Frame Forward | | | | | | |
-| 0x0c 0x00c1 | Frame Back | | | | | | |
-| 0x0c 0x00c2 | Mark | | | | | | |
-| 0x0c 0x00c3 | Clear Mark | | | | | | |
-| 0x0c 0x00c4 | Repeat From Mark | | | | | | |
-| 0x0c 0x00c5 | Return To Mark | | | | | | |
-| 0x0c 0x00c6 | Search Mark Forward | | | | | | |
-| 0x0c 0x00c7 | Search Mark Backwards | | | | | | |
-| 0x0c 0x00c8 | Counter Reset | | | | | | |
-| 0x0c 0x00c9 | Show Counter | | | | | | |
-| 0x0c 0x00ca | Tracking Increment | | | | | | |
-| 0x0c 0x00cb | Tracking Decrement | | | | | | |
-| 0x0c 0x00cc | Stop / Eject | | | | | | |
-| 0x0c 0x00cd | Play / Pause | 0x00a4 | KEY_PLAYPAUSE | 3.0 | 0x0055 | KEYCODE_MEDIA_PLAY_PAUSE | |
-| 0x0c 0x00ce | Play / Skip | | | | | | |
-| 0x0c 0x00e2 | Mute | 0x0071 | KEY_MUTE | 3.0 | 0x00a4 | KEYCODE_VOLUME_MUTE | |
-| 0x0c 0x00e5 | Bass Boost | 0x00d1 | KEY_BASSBOOST | | | | |
-| 0x0c 0x00e6 | Surround Mode | | | | | | |
-| 0x0c 0x00e7 | Loudness | | | | | | |
-| 0x0c 0x00e8 | MPX | | | | | | |
-| 0x0c 0x00e9 | Volume Increment | 0x0073 | KEY_VOLUMEUP | 1.6 | 0x0018 | KEYCODE_VOLUME_UP | |
-| 0x0c 0x00ea | Volume Decrement | 0x0072 | KEY_VOLUMEDOWN | 1.6 | 0x0019 | KEYCODE_VOLUME_DOWN | |
-| 0x0c 0x0181 | AL Launch Button Config. Tool | | | | | | |
-| 0x0c 0x0182 | AL Programmable Button Config. | 0x009c | KEY_BOOKMARKS | 3.0 | 0x00ae | KEYCODE_BOOKMARK | |
-| 0x0c 0x0183 | AL Consumer Control Config. | 0x00ab | KEY_CONFIG | 4.0.3 | 0x00d1 | KEYCODE_MUSIC | |
-| 0x0c 0x0184 | AL Word Processor | 0x01a5 | KEY_WORDPROCESSOR | | | | |
-| 0x0c 0x0185 | AL Text Editor | 0x01a6 | KEY_EDITOR | | | | |
-| 0x0c 0x0186 | AL Spreadsheet | 0x01a7 | KEY_SPREADSHEET | | | | |
-| 0x0c 0x0187 | AL Graphics Editor | 0x01a8 | KEY_GRAPHICSEDITOR | | | | |
-| 0x0c 0x0188 | AL Presentation App | 0x01a9 | KEY_PRESENTATION | | | | |
-| 0x0c 0x0189 | AL Database App | 0x01aa | KEY_DATABASE | | | | |
-| 0x0c 0x018a | AL Email Reader | 0x009b | KEY_MAIL | 1.6 | 0x0041 | KEYCODE_ENVELOPE | |
-| 0x0c 0x018b | AL Newsreader | 0x01ab | KEY_NEWS | | | | |
-| 0x0c 0x018c | AL Voicemail | 0x01ac | KEY_VOICEMAIL | | | | |
-| 0x0c 0x018d | AL Contacts / Address Book | 0x01ad | KEY_ADDRESSBOOK | 4.0.3 | 0x00cf | KEYCODE_CONTACTS | |
-| 0x0c 0x018e | AL Calendar / Schedule | 0x018d | KEY_CALENDAR | 4.0.3 | 0x00d0 | KEYCODE_CALENDAR | |
-| 0x0c 0x018f | AL Task / Project Manager | | | | | | |
-| 0x0c 0x0190 | AL Log / Journal / Timecard | | | | | | |
-| 0x0c 0x0191 | AL Checkbook / Finance | 0x00db | KEY_FINANCE | | | | |
-| 0x0c 0x0192 | AL Calculator | 0x008c | KEY_CALC | 4.0.3 | 0x00d2 | KEYCODE_CALCULATOR | |
-| 0x0c 0x0193 | AL A/V Capture / Playback | | | | | | |
-| 0x0c 0x0194 | AL Local Machine Browser | 0x0090 | KEY_FILE | | | | |
-| 0x0c 0x0195 | AL LAN/WAN Browser | | | | | | |
-| 0x0c 0x0196 | AL Internet Browser | 0x0096 | KEY_WWW | 1.6 | 0x0040 | KEYCODE_EXPLORER | |
-| 0x0c 0x0197 | AL Remote Networking/ISP Connect | | | | | | |
-| 0x0c 0x0198 | AL Network Conference | | | | | | |
-| 0x0c 0x0199 | AL Network Chat | 0x00d8 | KEY_CHAT | | | | |
-| 0x0c 0x019a | AL Telephony / Dialer | | | | | | |
-| 0x0c 0x019b | AL Logon | | | | | | |
-| 0x0c 0x019c | AL Logoff | 0x01b1 | KEY_LOGOFF | | | | |
-| 0x0c 0x019d | AL Logon / Logoff | | | | | | |
-| 0x0c 0x019e | AL Terminal Lock / Screensaver | 0x0098 | KEY_COFFEE | 4.0 | 0x001a | KEYCODE_POWER | |
-| 0x0c 0x019f | AL Control Panel | | | | | | |
-| 0x0c 0x01a0 | AL Command Line Processor / Run | | | | | | |
-| 0x0c 0x01a1 | AL Process / Task Manager | | | | | | |
-| 0x0c 0x01a2 | AL Select Task / Application | | | | | | |
-| 0x0c 0x01a3 | AL Next Task / Application | | | | | | |
-| 0x0c 0x01a4 | AL Previous Task / Application | | | | | | |
-| 0x0c 0x01a5 | AL Preemptive Halt Task / App. | | | | | | |
-| 0x0c 0x01a6 | AL Integrated Help Center | 0x008a | KEY_HELP | | | | |
-| 0x0c 0x01a7 | AL Documents | 0x00eb | KEY_DOCUMENTS | | | | |
-| 0x0c 0x01a8 | AL Thesaurus | | | | | | |
-| 0x0c 0x01a9 | AL Dictionary | | | | | | |
-| 0x0c 0x01aa | AL Desktop | | | | | | |
-| 0x0c 0x01ab | AL Spell Check | 0x01b0 | KEY_SPELLCHECK | | | | |
-| 0x0c 0x01ac | AL Grammar Check | | | | | | |
-| 0x0c 0x01ad | AL Wireless Status | | | | | | |
-| 0x0c 0x01ae | AL Keyboard Layout | | | | | | |
-| 0x0c 0x01af | AL Virus Protection | | | | | | |
-| 0x0c 0x01b0 | AL Encryption | | | | | | |
-| 0x0c 0x01b1 | AL Screen Saver | | | | | | |
-| 0x0c 0x01b2 | AL Alarms | | | | | | |
-| 0x0c 0x01b3 | AL Clock | | | | | | |
-| 0x0c 0x01b4 | AL File Browser | | | | | | |
-| 0x0c 0x01b5 | AL Power Status | | | | | | |
-| 0x0c 0x01b6 | AL Image Browser | 0x00e2 | KEY_MEDIA | 3.0 | 0x004f | KEYCODE_HEADSETHOOK | |
-| 0x0c 0x01b7 | AL Audio Browser | 0x00d5 | KEY_SOUND | 4.0.3 | 0x00d1 | KEYCODE_MUSIC | |
-| 0x0c 0x01b8 | AL Movie Browser | | | | | | |
-| 0x0c 0x01b9 | AL Digital Rights Manager | | | | | | |
-| 0x0c 0x01ba | AL Digital Wallet | | | | | | |
-| 0x0c 0x01bc | AL Instant Messaging | 0x01ae | KEY_MESSENGER | | | | |
-| 0x0c 0x01bd | AL OEM Features / Tips Browser | 0x0166 | KEY_INFO | | | | |
-| 0x0c 0x01be | AL OEM Help | | | | | | |
-| 0x0c 0x01bf | AL Online Community | | | | | | |
-| 0x0c 0x01c0 | AL Entertainment Content Browser | | | | | | |
-| 0x0c 0x01c1 | AL Online Shopping Browser | | | | | | |
-| 0x0c 0x01c2 | AL SmartCard Information / Help | | | | | | |
-| 0x0c 0x01c3 | AL Market / Finance Browser | | | | | | |
-| 0x0c 0x01c4 | AL Customized Corp. News Browser | | | | | | |
-| 0x0c 0x01c5 | AL Online Activity Browser | | | | | | |
-| 0x0c 0x01c6 | AL Research / Search Browser | | | | | | |
-| 0x0c 0x01c7 | AL Audio Player | | | | | | |
-| 0x0c 0x0201 | AC New | 0x00b5 | KEY_NEW | | | | |
-| 0x0c 0x0202 | AC Open | 0x0086 | KEY_OPEN | | | | |
-| 0x0c 0x0203 | AC Close | 0x00ce | KEY_CLOSE | | | | |
-| 0x0c 0x0204 | AC Exit | 0x00ae | KEY_EXIT | | | | |
-| 0x0c 0x0205 | AC Maximize | | | | | | |
-| 0x0c 0x0206 | AC Minimize | | | | | | |
-| 0x0c 0x0207 | AC Save | 0x00ea | KEY_SAVE | | | | |
-| 0x0c 0x0208 | AC Print | 0x00d2 | KEY_PRINT | | | | |
-| 0x0c 0x0209 | AC Properties | 0x0082 | KEY_PROPS | | | | |
-| 0x0c 0x021a | AC Undo | 0x0083 | KEY_UNDO | | | | |
-| 0x0c 0x021b | AC Copy | 0x0085 | KEY_COPY | | | | |
-| 0x0c 0x021c | AC Cut | 0x0089 | KEY_CUT | | | | |
-| 0x0c 0x021d | AC Paste | 0x0087 | KEY_PASTE | | | | |
-| 0x0c 0x021e | AC Select All | | | | | | |
-| 0x0c 0x021f | AC Find | 0x0088 | KEY_FIND | | | | |
-| 0x0c 0x0220 | AC Find and Replace | | | | | | |
-| 0x0c 0x0221 | AC Search | 0x00d9 | KEY_SEARCH | 1.6 | 0x0054 | KEYCODE_SEARCH | |
-| 0x0c 0x0222 | AC Go To | 0x0162 | KEY_GOTO | | | | |
-| 0x0c 0x0223 | AC Home | 0x00ac | KEY_HOMEPAGE | 3.0 | 0x0003 | KEYCODE_HOME | |
-| 0x0c 0x0224 | AC Back | 0x009e | KEY_BACK | 1.6 | 0x0004 | KEYCODE_BACK | |
-| 0x0c 0x0225 | AC Forward | 0x009f | KEY_FORWARD | 3.0 | 0x007d | KEYCODE_FORWARD | |
-| 0x0c 0x0226 | AC Stop | 0x0080 | KEY_STOP | 3.0 | 0x0056 | KEYCODE_MEDIA_STOP | |
-| 0x0c 0x0227 | AC Refresh | 0x00ad | KEY_REFRESH | | | | |
-| 0x0c 0x0228 | AC Previous Link | | | | | | |
-| 0x0c 0x0229 | AC Next Link | | | | | | |
-| 0x0c 0x022a | AC Bookmarks | 0x009c | KEY_BOOKMARKS | 3.0 | 0x00ae | KEYCODE_BOOKMARK | |
-| 0x0c 0x022b | AC History | | | | | | |
-| 0x0c 0x022c | AC Subscriptions | | | | | | |
-| 0x0c 0x022d | AC Zoom In | 0x01a2 | KEY_ZOOMIN | | | | |
-| 0x0c 0x022e | AC Zoom Out | 0x01a3 | KEY_ZOOMOUT | | | | |
-| 0x0c 0x022f | AC Zoom | 0x01a4 | KEY_ZOOMRESET | | | | 2 |
-| 0x0c 0x0230 | AC Full Screen View | | | | | | |
-| 0x0c 0x0231 | AC Normal View | | | | | | |
-| 0x0c 0x0232 | AC View Toggle | | | | | | |
-| 0x0c 0x0233 | AC Scroll Up | 0x00b1 | KEY_SCROLLUP | 3.0 | 0x005c | KEYCODE_PAGE_UP | |
-| 0x0c 0x0234 | AC Scroll Down | 0x00b2 | KEY_SCROLLDOWN | 3.0 | 0x005d | KEYCODE_PAGE_DOWN | |
-| 0x0c 0x0236 | AC Pan Left | | | | | | |
-| 0x0c 0x0237 | AC Pan Right | | | | | | |
-| 0x0c 0x0239 | AC New Window | | | | | | |
-| 0x0c 0x023a | AC Tile Horizontally | | | | | | |
-| 0x0c 0x023b | AC Tile Vertically | | | | | | |
-| 0x0c 0x023c | AC Format | | | | | | |
-| 0x0c 0x023d | AC Edit | | | | | | |
-| 0x0c 0x023e | AC Bold | | | | | | |
-| 0x0c 0x023f | AC Italics | | | | | | |
-| 0x0c 0x0240 | AC Underline | | | | | | |
-| 0x0c 0x0241 | AC Strikethrough | | | | | | |
-| 0x0c 0x0242 | AC Subscript | | | | | | |
-| 0x0c 0x0243 | AC Superscript | | | | | | |
-| 0x0c 0x0244 | AC All Caps | | | | | | |
-| 0x0c 0x0245 | AC Rotate | | | | | | |
-| 0x0c 0x0246 | AC Resize | | | | | | |
-| 0x0c 0x0247 | AC Flip horizontal | | | | | | |
-| 0x0c 0x0248 | AC Flip Vertical | | | | | | |
-| 0x0c 0x0249 | AC Mirror Horizontal | | | | | | |
-| 0x0c 0x024a | AC Mirror Vertical | | | | | | |
-| 0x0c 0x024b | AC Font Select | | | | | | |
-| 0x0c 0x024c | AC Font Color | | | | | | |
-| 0x0c 0x024d | AC Font Size | | | | | | |
-| 0x0c 0x024e | AC Justify Left | | | | | | |
-| 0x0c 0x024f | AC Justify Center H | | | | | | |
-| 0x0c 0x0250 | AC Justify Right | | | | | | |
-| 0x0c 0x0251 | AC Justify Block H | | | | | | |
-| 0x0c 0x0252 | AC Justify Top | | | | | | |
-| 0x0c 0x0253 | AC Justify Center V | | | | | | |
-| 0x0c 0x0254 | AC Justify Bottom | | | | | | |
-| 0x0c 0x0255 | AC Justify Block V | | | | | | |
-| 0x0c 0x0256 | AC Indent Decrease | | | | | | |
-| 0x0c 0x0257 | AC Indent Increase | | | | | | |
-| 0x0c 0x0258 | AC Numbered List | | | | | | |
-| 0x0c 0x0259 | AC Restart Numbering | | | | | | |
-| 0x0c 0x025a | AC Bulleted List | | | | | | |
-| 0x0c 0x025b | AC Promote | | | | | | |
-| 0x0c 0x025c | AC Demote | | | | | | |
-| 0x0c 0x025d | AC Yes | | | | | | |
-| 0x0c 0x025e | AC No | | | | | | |
-| 0x0c 0x025f | AC Cancel | 0x00df | KEY_CANCEL | | | | |
-| 0x0c 0x0260 | AC Catalog | | | | | | |
-| 0x0c 0x0261 | AC Buy / Checkout | | | | | | |
-| 0x0c 0x0262 | AC Add to Cart | | | | | | |
-| 0x0c 0x0263 | AC Expand | | | | | | |
-| 0x0c 0x0264 | AC Expand All | | | | | | |
-| 0x0c 0x0265 | AC Collapse | | | | | | |
-| 0x0c 0x0266 | AC Collapse All | | | | | | |
-| 0x0c 0x0267 | AC Print Preview | | | | | | |
-| 0x0c 0x0268 | AC Paste Special | | | | | | |
-| 0x0c 0x0269 | AC Insert Mode | | | | | | |
-| 0x0c 0x026a | AC Delete | | | | | | |
-| 0x0c 0x026b | AC Lock | | | | | | |
-| 0x0c 0x026c | AC Unlock | | | | | | |
-| 0x0c 0x026d | AC Protect | | | | | | |
-| 0x0c 0x026e | AC Unprotect | | | | | | |
-| 0x0c 0x026f | AC Attach Comment | | | | | | |
-| 0x0c 0x0270 | AC Delete Comment | | | | | | |
-| 0x0c 0x0271 | AC View Comment | | | | | | |
-| 0x0c 0x0272 | AC Select Word | | | | | | |
-| 0x0c 0x0273 | AC Select Sentence | | | | | | |
-| 0x0c 0x0274 | AC Select Paragraph | | | | | | |
-| 0x0c 0x0275 | AC Select Column | | | | | | |
-| 0x0c 0x0276 | AC Select Row | | | | | | |
-| 0x0c 0x0277 | AC Select Table | | | | | | |
-| 0x0c 0x0278 | AC Select Object | | | | | | |
-| 0x0c 0x0279 | AC Redo / Repeat | 0x00b6 | KEY_REDO | | | | |
-| 0x0c 0x027a | AC Sort | | | | | | |
-| 0x0c 0x027b | AC Sort Ascending | | | | | | |
-| 0x0c 0x027c | AC Sort Descending | | | | | | |
-| 0x0c 0x027d | AC Filter | | | | | | |
-| 0x0c 0x027e | AC Set Clock | | | | | | |
-| 0x0c 0x027f | AC View Clock | | | | | | |
-| 0x0c 0x0280 | AC Select Time Zone | | | | | | |
-| 0x0c 0x0281 | AC Edit Time Zones | | | | | | |
-| 0x0c 0x0282 | AC Set Alarm | | | | | | |
-| 0x0c 0x0283 | AC Clear Alarm | | | | | | |
-| 0x0c 0x0284 | AC Snooze Alarm | | | | | | |
-| 0x0c 0x0285 | AC Reset Alarm | | | | | | |
-| 0x0c 0x0286 | AC Synchronize | | | | | | |
-| 0x0c 0x0287 | AC Send/Receive | | | | | | |
-| 0x0c 0x0288 | AC Send To | | | | | | |
-| 0x0c 0x0289 | AC Reply | 0x00e8 | KEY_REPLY | | | | |
-| 0x0c 0x028a | AC Reply All | | | | | | |
-| 0x0c 0x028b | AC Forward Msg | 0x00e9 | KEY_FORWARDMAIL | | | | |
-| 0x0c 0x028c | AC Send | 0x00e7 | KEY_SEND | | | | |
-| 0x0c 0x028d | AC Attach File | | | | | | |
-| 0x0c 0x028e | AC Upload | | | | | | |
-| 0x0c 0x028f | AC Download (Save Target As) | | | | | | |
-| 0x0c 0x0290 | AC Set Borders | | | | | | |
-| 0x0c 0x0291 | AC Insert Row | | | | | | |
-| 0x0c 0x0292 | AC Insert Column | | | | | | |
-| 0x0c 0x0293 | AC Insert File | | | | | | |
-| 0x0c 0x0294 | AC Insert Picture | | | | | | |
-| 0x0c 0x0295 | AC Insert Object | | | | | | |
-| 0x0c 0x0296 | AC Insert Symbol | | | | | | |
-| 0x0c 0x0297 | AC Save and Close | | | | | | |
-| 0x0c 0x0298 | AC Rename | | | | | | |
-| 0x0c 0x0299 | AC Merge | | | | | | |
-| 0x0c 0x029a | AC Split | | | | | | |
-| 0x0c 0x029b | AC Distribute Horizontally | | | | | | |
-| 0x0c 0x029c | AC Distribute Vertically | | | | | | |
-
-### Additional non-HID Mappings ###
-
-These mappings describe functions that do not appear in HID but for which Linux
-key codes exist.
-
-| LKC | Linux Key Code Name | Version | AKC | Android Key Code Name | Notes |
-| ------ | -------------------------------- | ------- | ------ | -------------------------------- | ----- |
-| 0x01d0 | KEY_FN | 3.0 | 0x0077 | KEYCODE_FUNCTION | |
-| 0x01d1 | KEY_FN_ESC | 3.0 | 0x006f | KEYCODE_ESCAPE | 3 |
-| 0x01d2 | KEY_FN_F1 | 3.0 | 0x0083 | KEYCODE_F1 | 3 |
-| 0x01d3 | KEY_FN_F2 | 3.0 | 0x0084 | KEYCODE_F2 | 3 |
-| 0x01d4 | KEY_FN_F3 | 3.0 | 0x0085 | KEYCODE_F3 | 3 |
-| 0x01d5 | KEY_FN_F4 | 3.0 | 0x0086 | KEYCODE_F4 | 3 |
-| 0x01d6 | KEY_FN_F5 | 3.0 | 0x0087 | KEYCODE_F5 | 3 |
-| 0x01d7 | KEY_FN_F6 | 3.0 | 0x0088 | KEYCODE_F6 | 3 |
-| 0x01d8 | KEY_FN_F7 | 3.0 | 0x0089 | KEYCODE_F7 | 3 |
-| 0x01d9 | KEY_FN_F8 | 3.0 | 0x008a | KEYCODE_F8 | 3 |
-| 0x01da | KEY_FN_F9 | 3.0 | 0x008b | KEYCODE_F9 | 3 |
-| 0x01db | KEY_FN_F10 | 3.0 | 0x008c | KEYCODE_F10 | 3 |
-| 0x01dc | KEY_FN_F11 | 3.0 | 0x008d | KEYCODE_F11 | 3 |
-| 0x01dd | KEY_FN_F12 | 3.0 | 0x008e | KEYCODE_F12 | 3 |
-| 0x01de | KEY_FN_1 | 3.0 | 0x0008 | KEYCODE_1 | 3 |
-| 0x01df | KEY_FN_2 | 3.0 | 0x0009 | KEYCODE_2 | 3 |
-| 0x01e0 | KEY_FN_D | 3.0 | 0x0020 | KEYCODE_D | 3 |
-| 0x01e1 | KEY_FN_E | 3.0 | 0x0021 | KEYCODE_E | 3 |
-| 0x01e2 | KEY_FN_F | 3.0 | 0x0022 | KEYCODE_F | 3 |
-| 0x01e3 | KEY_FN_S | 3.0 | 0x002f | KEYCODE_S | 3 |
-| 0x01e4 | KEY_FN_B | 3.0 | 0x001e | KEYCODE_B | 3 |
-
-### Legacy Unsupported Keys ###
-
-These mappings appeared in previous versions of Android but were inconsistent with
-HID or used non-standard Linux key codes. They are no longer supported.
-
-| LKC | Linux Key Code Name | Version | AKC | Android Key Code Name | Notes |
-| ------ | -------------------------------- | ------- | ------ | -------------------------------- | ----- |
-| 0x00db | KEY_EMAIL | 1.6 | 0x004d | KEYCODE_AT | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e3 | KEY_STAR | 1.6 | 0x0011 | KEYCODE_STAR | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e4 | KEY_SHARP | 1.6 | 0x0012 | KEYCODE_POUND | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e5 | KEY_SOFT1 | 1.6 | 0x0052 | KEYCODE_MENU | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e6 | KEY_SOFT2 | 1.6 | 0x0002 | KEYCODE_SOFT_RIGHT | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e7 | KEY_SEND | 1.6 | 0x0005 | KEYCODE_CALL | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e8 | KEY_CENTER | 1.6 | 0x0017 | KEYCODE_DPAD_CENTER | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00e9 | KEY_HEADSETHOOK | 1.6 | 0x004f | KEYCODE_HEADSETHOOK | 4 |
-| "" | "" | 4.0 | | | 4 |
-| 0x00ea | KEY_0_5 | 1.6 | | | 4 |
-| 0x00eb | KEY_2_5 | 1.6 | | | 4 |
-
-### Notes ###
-
-1. The Android key code associated with common alphanumeric and symbolic
- keys may vary based on the keyboard layout and language.
- For historical reasons, the physical scan codes and HID usages
- associated with keys on a keyboard are often defined positionally
- even though the labels printed on those keys may vary from one
- language to another.
-
- On a US English (QWERTY) keyboard, the top-left alphabetic key is
- labeled Q. On a French (AZERTY) keyboard, the key in the same
- position is labeled A. Despite the label, on both keyboards the
- top-left alphabetic key is referred to using the HID usage
- 0x07 0x0014 which is mapped to the Linux key code KEY_Q.
-
- When Android is configured with a US English keyboard layout, then
- the Linux key code KEY_Q will be mapped to the Android key code
- KEYCODE_Q and will produce the characters 'Q' and 'q'.
- However, when Android is configured with a French keyboard layout,
- then the Linux key code KEY_Q will be mapped to the Android key code
- KEYCODE_A and will produce the characters 'A' and 'a'.
-
- The Android key code typically reflects the language-specific
- interpretation of the key, so a different Android key code may
- be used for different languages.
-
-2. `0x0c 0x022f AC Zoom` is defined in the HID as a linear control but
- the kernel maps it as a key, which is probably incorrect.
-
-3. The Linux function keys `KEY_FN_*` are mapped to simpler
- key codes but are dispatched with the `META_FUNCTION` meta state
- bit set to true.
-
-4. Prior to Android Ice Cream Sandwich 4.0, the default key layout
- contained mappings for some extra key codes that were not defined
- in the mainline Linux kernel headers. These mappings have since
- been removed because these previously undefined key codes have
- since been assigned different meanings in more recent versions
- of the Linux kernel.
-
-### Sources ###
-
-1. [USB HID Usage Tables v1.12](http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf)
-2. Linux 2.6.39 kernel: include/linux/input.h, drivers/hid/hid-input.c
-3. Android ICS: qwerty.kl, Generic.kl, KeyEvent.java
diff --git a/src/tech/input/migration-guide.md b/src/tech/input/migration-guide.md
deleted file mode 100644
index e2aee60..0000000
--- a/src/tech/input/migration-guide.md
+++ /dev/null
@@ -1,71 +0,0 @@
-<!--
- 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.
--->
-
-# Migration Guide #
-
-This document contains a few helpful tips when migrating to new Android releases.
-
-## Migrating to Android Gingerbread 2.3 ##
-
-In Gingerbread, we added the concept of input device configuration files
-(also referred to as input device calibration files in this release).
-
-Make sure to provide an input device configuration file for all touch screens.
-In particular, it is worth spending time providing a calibration reference for
-touch size information.
-
-## Migrating to Android Honeycomb 3.0 ##
-
-In Honeycomb, we revised the key character map file format and started making
-greater use of input device configuration files. We also added support for full
-PC-style keyboards and introduced a new "Generic" key map, which
-replaced the older emulator-specific "qwerty" key map (which was never
-intended to be used as a general-purpose key map.)
-
-Make sure to update all of your key character map files to use the new syntax.
-
-If your peripherals relied on the old "qwerty" key map, then you
-may need to provide new device-specific key maps to emulate the old behavior.
-You should create a new key map for each device identified either by
-USB product id / vendor id or by device name.
-
-It is especially important to provide key character map files for all special
-function input devices. These files should simple contain a line to set
-the keyboard type to `SPECIAL_FUNCTION`.
-
-A good way to ensure that all built-in input devices are appropriately configured
-is to run [Dumpsys](/tech/input/dumpsys.html) and look for devices that
-are inappropriately using `Generic.kcm`.
-
-## Migrating to Android Honeycomb 3.2 ##
-
-In Honeycomb 3.2, we added support for joysticks and extended the key layout file
-format to enable joystick axis mapping.
-
-## Migrating to Android Ice Cream Sandwich 4.0 ##
-
-In Ice Cream Sandwich 4.0, we changed the device driver requirements for touch screens
-to follow the standard Linux multitouch input protocol and added support for
-protocol "B". We also support digitizer tablets and stylus-based touch devices.
-
-You will probably need to update your input device driver to implement the Linux
-multitouch input protocol correctly according to the standard.
-
-You will also need to update your input device configuration files because some
-properties have been changed to be simpler and more systematic.
-
-Refer to [Touch Devices](/tech/input/touch-devices.html) for more details about
-driver requirements.
diff --git a/src/tech/input/overview.md b/src/tech/input/overview.md
deleted file mode 100644
index 79e3de7..0000000
--- a/src/tech/input/overview.md
+++ /dev/null
@@ -1,259 +0,0 @@
-<!--
- 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.
--->
-
-# Overview #
-
-The Android input subsystem nominally consists of an event pipeline
-that traverses multiple layers of the system.
-
-## Input Pipeline ##
-
-At the lowest layer, the physical input device produces signals that
-describe state changes such as key presses and touch contact points.
-The device firmware encodes and transmits these signals in some way
-such as by sending USB HID reports to the system or by producing
-interrupts on an I2C bus.
-
-The signals are then decoded by a device driver in the Linux kernel.
-The Linux kernel provides drivers for many standard peripherals,
-particularly those that adhere to the HID protocol. However, an OEM
-must often provide custom drivers for embedded devices that are
-tightly integrated into the system at a low-level, such as touch screens.
-
-The input device drivers are responsible for translating device-specific
-signals into a standard input event format, by way of the Linux
-input protocol. The Linux input protocol defines a standard set of
-event types and codes in the `linux/input.h` kernel header file.
-In this way, components outside the kernel do not need to care about
-the details such as physical scan codes, HID usages, I2C messages,
-GPIO pins, and the like.
-
-Next, the Android `EventHub` component reads input events from the kernel
-by opening the `evdev` driver associated with each input device.
-The Android InputReader component then decodes the input events
-according to the device class and produces a stream of Android input
-events. As part of this process, the Linux input protocol event codes
-are translated into Android event codes according to the
-input device configuration, keyboard layout files, and various
-mapping tables.
-
-Finally, the `InputReader` sends input events to the InputDispatcher
-which forwards them to the appropriate window.
-
-## Control Points ##
-
-There are several stages in the input pipeline which effect control
-over the behavior of the input device.
-
-### Driver and Firmware Configuration ###
-
-Input device drivers frequently configure the behavior of the input
-device by setting parameters in registers or even uploading the
-firmware itself. This is particularly the case for embedded
-devices such as touch screens where a large part of the calibration
-process involves tuning these parameters or fixing the firmware
-to provide the desired accuracy and responsiveness and to suppress
-noise.
-
-Driver configuration options are often specified as module parameters
-in the kernel board support package (BSP) so that the same driver
-can support multiple different hardware implementations.
-
-This documentation does attempt to describe driver or firmware
-configuration, but it does offer guidance as to device calibration
-in general.
-
-### Board Configuration Properties ###
-
-The kernel board support package (BSP) may export board configuration
-properties via SysFS that are used by the Android InputReader component,
-such as the placement of virtual keys on a touch screen.
-
-Refer to the device class sections for details about how different
-devices use board configuration properties.
-
-### Resource Overlays ###
-
-A few input behaviors are configured by way of resource overlays
-in `config.xml` such as the operation of lid switch.
-
-Here are a few examples:
-
-* `config_lidKeyboardAccessibility`: Specifies the effect of the
- lid switch on whether the hardware keyboard is accessible or hidden.
-
-* `config_lidNavigationAccessibility`: Specifies the effect of the
- lid switch on whether the trackpad is accessible or hidden.
-
-* `config_longPressOnPowerBehavior`: Specifies what should happen when
- the user holds down the power button.
-
-* `config_lidOpenRotation`: Specifies the effect of the lid switch
- on screen orientation.
-
-Refer to the documentation within `frameworks/base/core/res/res/values/config.xml`
-for details about each configuration option.
-
-### Key Maps ###
-
-Key maps are used by the Android `EventHub` and `InputReader` components
-to configure the mapping from Linux event codes to Android event codes
-for keys, joystick buttons and joystick axes. The mapping may
-be device or language dependent.
-
-Refer to the device class sections for details about how different
-devices use key maps.
-
-### Input Device Configuration Files ###
-
-Input device configuration files are used by the Android `EventHub` and
-`InputReader` components to configure special device characteristics
-such as how touch size information is reported.
-
-Refer to the device class sections for details about how different
-devices use input device configuration maps.
-
-## Understanding HID Usages and Event Codes ##
-
-There are often several different identifiers used to refer to any
-given key on a keyboard, button on a game controller, joystick axis
-or other control. The relationships between these identifiers
-are not always the same: they are dependent on a set of mapping tables,
-some of which are fixed, and some which vary based on characteristics
-of the device, the device driver, the current locale, the system
-configuration, user preferences and other factors.
-
-Physical Scan Code
-: A physical scan code is a device-specific identifier that is associated
- with each key, button or other control. Because physical scan codes
- often vary from one device to another, the firmware or device driver
- is responsible for mapping them to standard identifiers such as
- HID Usages or Linux key codes.
-
- Scan codes are mainly of interest for keyboards. Other devices
- typically communicate at a low-level using GPIO pins, I2C messages
- or other means. Consequently, the upper layers of the software
- stack rely on the device drivers to make sense of what is going on.
-
-HID Usage
-: A HID usage is a standard identifier that is used to report the
- state of a control such as a keyboard key, joystick axis,
- mouse button, or touch contact point. Most USB and Bluetooth
- input devices conform to the HID specification, which enables
- the system to interface with them in a uniform manner.
-
- The Android Framework relies on the Linux kernel HID drivers to
- translate HID usage codes into Linux key codes and other identifiers.
- Therefore HID usages are mainly of interest to peripheral manufacturers.
-
-Linux Key Code
-: A Linux key code is a standard identifier for a key or button.
- Linux key codes are defined in the `linux/input.h` header file using
- constants that begin with the prefix `KEY_` or `BTN_`. The Linux
- kernel input drivers are responsible for translating physical
- scan codes, HID usages and other device-specific signals into Linux
- key codes and delivering information about them as part of
- `EV_KEY` events.
-
- The Android API sometimes refers to the Linux key code associated
- with a key as its "scan code". This is technically incorrect in
- but it helps to distinguish Linux key codes from Android key codes
- in the API.
-
-Linux Relative or Absolute Axis Code
-: A Linux relative or absolute axis code is a standard identifier
- for reporting relative movements or absolute positions along an
- axis, such as the relative movements of a mouse along its X axis
- or the absolute position of a joystick along its X axis.
- Linux axis code are defined in the `linux/input.h` header file using
- constants that begin with the prefix `REL_` or `ABS_`. The Linux
- kernel input drivers are responsible for translating HID usages
- and other device-specific signals into Linux axis codes and
- delivering information about them as part of `EV_REL` and
- `EV_ABS` events.
-
-Linux Switch Code
-: A Linux switch code is a standard identifier for reporting the
- state of a switch on a device, such as a lid switch. Linux
- switch codes are defined in the `linux/input.h` header file
- using constants that begin with the prefix `SW_`. The Linux
- kernel input drivers report switch state changes as `EV_SW` events.
-
- Android applications generally do not receive events from switches,
- but the system may use them interally to control various
- device-specific functions.
-
-Android Key Code
-: An Android key code is a standard identifier defined in the Android
- API for indicating a particular key such as 'HOME'. Android key codes
- are defined by the `android.view.KeyEvent` class as constants that
- begin with the prefix `KEYCODE_`.
-
- The key layout specifies how Linux key codes are mapped to Android
- key codes. Different key layouts may be used depending on the keyboard
- model, language, country, layout, or special functions.
-
- Combinations of Android key codes are transformed into character codes
- using a device and locale specific key character map. For example,
- when the keys identified as `KEYCODE_SHIFT` and `KEYCODE_A` are both
- pressed together, the system looks up the combination in the key
- character map and finds the capital letter 'A', which is then inserted
- into the currently focused text widget.
-
-Android Axis Code
-: An Android axis code is a standard identifier defined in the Android
- API for indicating a particular device axis. Android axis codes are
- defined by the `android.view.MotionEvent` class as constants that
- begin with the prefix `AXIS_`.
-
- The key layout specifies how Linux Axis Codes are mapped to Android
- axis codes. Different key layouts may be used depending on the device
- model, language, country, layout, or special functions.
-
-Android Meta State
-: An Android meta state is a standard identifier defined in the Android
- API for indicating which modifier keys are pressed. Android meta states
- are defined by the `android.view.KeyEvent` class as constants that
- begin with the prefix `META_`.
-
- The current meta state is determined by the Android InputReader
- component which monitors when modifier keys such as `KEYCODE_SHIFT_LEFT`
- are pressed / released and sets / resets the appropriate meta state flag.
-
- The relationship between modifier keys and meta states is hardcoded
- but the key layout can alter how the modifier keys themselves are
- mapped which in turns affects the meta states.
-
-Android Button State
-: An Android button state is a standard identifier defined in the Android
- API for indicating which buttons (on a mouse or stylus) are pressed.
- Android button states are defined by the `android.view.MotionEvent`
- class as constants that begin with the prefix `BUTTON_`.
-
- The current button state is determined by the Android InputReader
- component which monitors when buttons (on a mouse or stylus) are
- pressed / released and sets / resets appropriate button state flag.
-
- The relationship between buttons and button states is hardcoded.
-
-## Further Reading ##
-
-1. [Linux input event codes](http://www.kernel.org/doc/Documentation/input/event-codes.txt)
-2. [Linux multi-touch protocol](http://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt)
-3. [Linux input drivers](http://www.kernel.org/doc/Documentation/input/input.txt)
-4. [Linux force feedback](http://www.kernel.org/doc/Documentation/input/ff.txt)
-5. [HID information, including HID usage tables](http://www.usb.org/developers/hidpage)
-
diff --git a/src/tech/input/sidebar2.md b/src/tech/input/sidebar2.md
deleted file mode 100644
index 6746bcd..0000000
--- a/src/tech/input/sidebar2.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Input Concepts #
-
-- [Overview](/tech/input/overview.html)
-- [Key Layout Files](/tech/input/key-layout-files.html)
-- [Key Character Map Files](/tech/input/key-character-map-files.html)
-- [Input Device Configuration Files](/tech/input/input-device-configuration-files.html)
-- [Migration Guide](/tech/input/migration-guide.html)
-
-# Input Device Classes #
-
-- [Keyboard Devices](/tech/input/keyboard-devices.html)
-- [Touch Devices](/tech/input/touch-devices.html)
-
-# Tools #
-
-- [Dumpsys](/tech/input/dumpsys.html)
-- [Getevent](/tech/input/getevent.html)
-- [Validate Keymaps](/tech/input/validate-keymaps.html)
diff --git a/src/tech/input/touch-devices.md b/src/tech/input/touch-devices.md
deleted file mode 100644
index 234188f..0000000
--- a/src/tech/input/touch-devices.md
+++ /dev/null
@@ -1,1186 +0,0 @@
-<!--
- 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.
--->
-
-# Touch Devices #
-
-Android supports a variety of touch screens and touch pads, including
-stylus-based digitizer tablets.
-
-Touch screens are touch devices that are associated with a display such that
-the user has the impression of directly manipulating items on screen.
-
-Touch pads are touch devices that are not associated with a display such as a
-digitizer tablet. Touch pads are typically used for pointing or for
-absolute indirect positioning or gesture-based control of a user interface.
-
-Touch devices may have buttons whose functions are similar to mouse buttons.
-
-Touch devices can sometimes be manipulated using a variety of different tools
-such as fingers or a stylus depending on the underlying touch sensor technology.
-
-Touch devices are sometimes used to implement virtual keys. For example, on
-some Android devices, the touch screen sensor area extends beyond the edge of
-the display and serves dual purpose as part of a touch sensitive key pad.
-
-Due to the great variety of touch devices, Android relies on a large number of
-configuration properties to describe the characteristics and desired behavior
-of each device.
-
-## Touch Device Classification ##
-
-An input device is classified as a *multi-touch* device if both of
-the following conditions hold:
-
-* The input device reports the presence of the `ABS_MT_POSITION_X` and
- `ABS_MT_POSITION_Y` absolute axes.
-
-* The input device does not have any gamepad buttons. This condition
- resolves an ambiguity with certain gamepads that report axes with codes
- that overlaps those of the MT axes.
-
-An input device is classified as a *single-touch* device if both of the
-following conditions hold:
-
-* The input device is not classified as a multi-touch device. An input device
- is either classified as a single-touch device or as a multi-touch device,
- never both.
-
-* The input device reports the presence of the `ABS_X` and `ABS_Y` absolute
- axes, and the presence of the `BTN_TOUCH` key code.
-
-Once an input device has been classified as a touch device, the presence
-of virtual keys is determined by attempting to load the virtual key map file
-for the device. If a virtual key map is available, then the key layout
-file for the device is also loaded.
-
-Refer to the section below about the location and format of virtual key map
-files.
-
-Next, the system loads the input device configuration file for the touch device.
-
-**All built-in touch devices should have input device configuration files.**
-If no input device configuration file is present, the system will
-choose a default configuration that is appropriate for typical general-purpose
-touch peripherals such as external USB or Bluetooth HID touch screens
-or touch pads. These defaults are not designed for built-in touch screens and
-will most likely result in incorrect behavior.
-
-After the input device configuration loaded, the system will classify the
-input device as a *touch screen*, *touch pad* or *pointer* device.
-
-* A *touch screen* device is used for direct manipulation of objects on the
- screen. Since the user is directly touching the screen, the system does
- not require any additional affordances to indicate the objects being
- manipulated.
-
-* A *touch pad* device is used to provide absolute positioning information
- to an application about touches on a given sensor area. It may be useful
- for digitizer tablets.
-
-* A *pointer* device is used for indirect manipulation of objects on the
- screen using a cursor. Fingers are interpreted as multi-touch pointer
- gestures. Other tools, such as styluses, are interpreted using
- absolute positions.
-
- See [Indirect Multi-touch Pointer Gestures](#indirect-multi-touch-pointer-gestures)
- for more information.
-
-The following rules are used to classify the input device as a *touch screen*,
-*touch pad* or *pointer* device.
-
-* If the `touch.deviceType` property is set, then the device type will be
- set as indicated.
-
-* If the input device reports the presence of the `INPUT_PROP_DIRECT`
- input property (via the `EVIOCGPROP` ioctl), then the device type will
- be set to *touch screen*. This condition assumes that direct input touch
- devices are attached to a display that is also connected.
-
-* If the input device reports the presence of the `INPUT_PROP_POINTER`
- input property (via the `EVIOCGPROP` ioctl), then the device type will
- be set to *pointer*.
-
-* If the input device reports the presence of the `REL_X` or `REL_Y` relative
- axes, then the device type will be set to *touch pad*. This condition
- resolves an ambiguity for input devices that consist of both a mouse and
- a touch pad. In this case, the touch pad will not be used to control
- the pointer because the mouse already controls it.
-
-* Otherwise, the device type will be set to *pointer*. This default ensures
- that touch pads that have not been designated any other special purpose
- will serve to control the pointer.
-
-## Buttons ##
-
-Buttons are *optional* controls that may be used by applications to perform
-additional functions. Buttons on touch devices behave similarly to mouse
-buttons and are mainly of use with *pointer* type touch devices or with a
-stylus.
-
-The following buttons are supported:
-
-* `BTN_LEFT`: mapped to `MotionEvent.BUTTON_PRIMARY`.
-
-* `BTN_RIGHT`: mapped to `MotionEvent.BUTTON_SECONDARY`.
-
-* `BTN_MIDDLE`: mapped to `MotionEvent.BUTTON_MIDDLE`.
-
-* `BTN_BACK` and `BTN_SIDE`: mapped to `MotionEvent.BUTTON_BACK`.
- Pressing this button also synthesizes a key press with the key code
- `KeyEvent.KEYCODE_BACK`.
-
-* `BTN_FORWARD` and `BTN_EXTRA`: mapped to `MotionEvent.BUTTON_FORWARD`.
- Pressing this button also synthesizes a key press with the key code
- `KeyEvent.KEYCODE_FORWARD`.
-
-* `BTN_STYLUS`: mapped to `MotionEvent.BUTTON_SECONDARY`.
-
-* `BTN_STYLUS2`: mapped to `MotionEvent.BUTTON_TERTIARY`.
-
-## Tools and Tool Types ##
-
-A *tool* is a finger, stylus or other apparatus that is used to interact with
-the touch device. Some touch devices can distinguish between different
-types of tools.
-
-Elsewhere in Android, as in the `MotionEvent` API, a *tool* is often referred
-to as a *pointer*.
-
-The following tool types are supported:
-
-* `BTN_TOOL_FINGER` and `MT_TOOL_FINGER`: mapped to `MotionEvent.TOOL_TYPE_FINGER`.
-
-* `BTN_TOOL_PEN` and `MT_TOOL_PEN`: mapped to `MotionEvent.TOOL_TYPE_STYLUS`.
-
-* `BTN_TOOL_RUBBER`: mapped to `MotionEvent.TOOL_TYPE_ERASER`.
-
-* `BTN_TOOL_BRUSH`: mapped to `MotionEvent.TOOL_TYPE_STYLUS`.
-
-* `BTN_TOOL_PENCIL`: mapped to `MotionEvent.TOOL_TYPE_STYLUS`.
-
-* `BTN_TOOL_AIRBRUSH`: mapped to `MotionEvent.TOOL_TYPE_STYLUS`.
-
-* `BTN_TOOL_MOUSE`: mapped to `MotionEvent.TOOL_TYPE_MOUSE`.
-
-* `BTN_TOOL_LENS`: mapped to `MotionEvent.TOOL_TYPE_MOUSE`.
-
-* `BTN_TOOL_DOUBLETAP`, `BTN_TOOL_TRIPLETAP`, and `BTN_TOOL_QUADTAP`:
- mapped to `MotionEvent.TOOL_TYPE_FINGER`.
-
-## Hovering vs. Touching Tools ##
-
-Tools can either be in contact with the touch device or in range and hovering
-above it. Not all touch devices are able to sense the presence of a tool
-hovering above the touch device. Those that do, such as RF-based stylus digitizers,
-can often detect when the tool is within a limited range of the digitizer.
-
-The `InputReader` component takes care to distinguish touching tools from hovering
-tools. Likewise, touching tools and hovering tools are reported to applications
-in different ways.
-
-Touching tools are reported to applications as touch events
-using `MotionEvent.ACTION_DOWN`, `MotionEvent.ACTION_MOVE`, `MotionEvent.ACTION_DOWN`,
-`MotionEvent.ACTION_POINTER_DOWN` and `MotionEvent.ACTION_POINTER_UP`.
-
-Hovering tools are reported to applications as generic motion events using
-`MotionEvent.ACTION_HOVER_ENTER`, `MotionEvent.ACTION_HOVER_MOVE`
-and `MotionEvent.ACTION_HOVER_EXIT`.
-
-## Touch Device Driver Requirements ##
-
-1. Touch device drivers should only register axes and key codes for the axes
- and buttons that they actually support. Registering excess axes or key codes
- may confuse the device classification algorithm or cause the system to incorrectly
- detect the capabilities of the device.
-
- For example, if the device reports the `BTN_TOUCH` key code, the system will
- assume that `BTN_TOUCH` will always be used to indicate whether the tool is
- actually touching the screen or is merely in range and hovering.
-
-2. Single-touch devices use the following Linux input events:
-
- * `ABS_X`: *(REQUIRED)* Reports the X coordinate of the tool.
-
- * `ABS_Y`: *(REQUIRED)* Reports the Y coordinate of the tool.
-
- * `ABS_PRESSURE`: *(optional)* Reports the physical pressure applied to the tip
- of the tool or the signal strength of the touch contact.
-
- * `ABS_TOOL_WIDTH`: *(optional)* Reports the cross-sectional area or width of the
- touch contact or of the tool itself.
-
- * `ABS_DISTANCE`: *(optional)* Reports the distance of the tool from the surface of
- the touch device.
-
- * `ABS_TILT_X`: *(optional)* Reports the tilt of the tool from the surface of the
- touch device along the X axis.
-
- * `ABS_TILT_Y`: *(optional)* Reports the tilt of the tool from the surface of the
- touch device along the Y axis.
-
- * `BTN_TOUCH`: *(REQUIRED)* Indicates whether the tool is touching the device.
-
- * `BTN_LEFT`, `BTN_RIGHT`, `BTN_MIDDLE`, `BTN_BACK`, `BTN_SIDE`, `BTN_FORWARD`,
- `BTN_EXTRA`, `BTN_STYLUS`, `BTN_STYLUS2`:
- *(optional)* Reports [button](#buttons) states.
-
- * `BTN_TOOL_FINGER`, `BTN_TOOL_PEN`, `BTN_TOOL_RUBBER`, `BTN_TOOL_BRUSH`,
- `BTN_TOOL_PENCIL`, `BTN_TOOL_AIRBRUSH`, `BTN_TOOL_MOUSE`, `BTN_TOOL_LENS`,
- `BTN_TOOL_DOUBLETAP`, `BTN_TOOL_TRIPLETAP`, `BTN_TOOL_QUADTAP`:
- *(optional)* Reports the [tool type](#tools-and-tool-types).
-
-3. Multi-touch devices use the following Linux input events:
-
- * `ABS_MT_POSITION_X`: *(REQUIRED)* Reports the X coordinate of the tool.
-
- * `ABS_MT_POSITION_Y`: *(REQUIRED)* Reports the Y coordinate of the tool.
-
- * `ABS_MT_PRESSURE`: *(optional)* Reports the physical pressure applied to the
- tip of the tool or the signal strength of the touch contact.
-
- * `ABS_MT_TOUCH_MAJOR`: *(optional)* Reports the cross-sectional area of the
- touch contact, or the length of the longer dimension of the touch contact.
-
- * `ABS_MT_TOUCH_MINOR`: *(optional)* Reports the length of the shorter dimension of the
- touch contact. This axis should not be used if `ABS_MT_TOUCH_MAJOR` is reporting an
- area measurement.
-
- * `ABS_MT_WIDTH_MAJOR`: *(optional)* Reports the cross-sectional area of the tool itself,
- or the length of the longer dimension of the tool itself.
- This axis should not be used if the dimensions of the tool itself are unknown.
-
- * `ABS_MT_WIDTH_MINOR`: *(optional)* Reports the length of the shorter dimension of
- the tool itself. This axis should not be used if `ABS_MT_WIDTH_MAJOR` is reporting
- an area measurement or if the dimensions of the tool itself are unknown.
-
- * `ABS_MT_ORIENTATION`: *(optional)* Reports the orientation of the tool.
-
- * `ABS_MT_DISTANCE`: *(optional)* Reports the distance of the tool from the
- surface of the touch device.
-
- * `ABS_MT_TOOL_TYPE`: *(optional)* Reports the [tool type](#tools-and-tool-types) as
- `MT_TOOL_FINGER` or `MT_TOOL_PEN`.
-
- * `ABS_MT_TRACKING_ID`: *(optional)* Reports the tracking id of the tool.
- The tracking id is an arbitrary non-negative integer that is used to identify
- and track each tool independently when multiple tools are active. For example,
- when multiple fingers are touching the device, each finger should be assigned a distinct
- tracking id that is used as long as the finger remains in contact. Tracking ids
- may be reused when their associated tools move out of range.
-
- * `ABS_MT_SLOT`: *(optional)* Reports the slot id of the tool, when using the Linux
- multi-touch protocol 'B'. Refer to the Linux multi-touch protocol documentation
- for more details.
-
- * `BTN_TOUCH`: *(REQUIRED)* Indicates whether the tool is touching the device.
-
- * `BTN_LEFT`, `BTN_RIGHT`, `BTN_MIDDLE`, `BTN_BACK`, `BTN_SIDE`, `BTN_FORWARD`,
- `BTN_EXTRA`, `BTN_STYLUS`, `BTN_STYLUS2`:
- *(optional)* Reports [button](#buttons) states.
-
- * `BTN_TOOL_FINGER`, `BTN_TOOL_PEN`, `BTN_TOOL_RUBBER`, `BTN_TOOL_BRUSH`,
- `BTN_TOOL_PENCIL`, `BTN_TOOL_AIRBRUSH`, `BTN_TOOL_MOUSE`, `BTN_TOOL_LENS`,
- `BTN_TOOL_DOUBLETAP`, `BTN_TOOL_TRIPLETAP`, `BTN_TOOL_QUADTAP`:
- *(optional)* Reports the [tool type](#tools-and-tool-types).
-
-4. If axes for both the single-touch and multi-touch protocol are defined, then
- only the multi-touch axes will be used and the single-touch axes will be ignored.
-
-5. The minimum and maximum values of the `ABS_X`, `ABS_Y`, `ABS_MT_POSITION_X`
- and `ABS_MT_POSITION_Y` axes define the bounds of the active area of the device
- in device-specific surface units. In the case of a touch screen, the active area
- describes the part of the touch device that actually covers the display.
-
- For a touch screen, the system automatically interpolates the reported touch
- positions in surface units to obtain touch positions in display pixels according
- to the following calculation:
-
- displayX = (x - minX) * displayWidth / (maxX - minX + 1)
- displayY = (y - minY) * displayHeight / (maxY - minY + 1)
-
- A touch screen may report touches outside of the reported active area.
-
- Touches that are initiated outside the active area are not delivered to applications
- but may be used for virtual keys.
-
- Touches that are initiated inside the active area, or that enter and exit the display
- area are delivered to applications. Consequently, if a touch starts within the
- bounds of an application and then moves outside of the active area, the application
- may receive touch events with display coordinates that are negative or beyond the
- bounds of the display. This is expected behavior.
-
- A touch device should never clamp touch coordinates to the bounds of the active
- area. If a touch exits the active area, it should be reported as being outside of
- the active area, or it should not be reported at all.
-
- For example, if the user's finger is touching near the top-left corner of the
- touch screen, it may report a coordinate of (minX, minY). If the finger continues
- to move further outside of the active area, the touch screen should either start
- reporting coordinates with components less than minX and minY, such as
- (minX - 2, minY - 3), or it should stop reporting the touch altogether.
- In other words, the touch screen should *not* be reporting (minX, minY)
- when the user's finger is really touching outside of the active area.
-
- Clamping touch coordinates to the display edge creates an artificial
- hard boundary around the edge of the screen which prevents the system from
- smoothly tracking motions that enter or exit the bounds of the display area.
-
-6. The values reported by `ABS_PRESSURE` or `ABS_MT_PRESSURE`, if they
- are reported at all, must be non-zero when the tool is touching the device
- and zero otherwise to indicate that the tool is hovering.
-
- Reporting pressure information is *optional* but strongly recommended.
- Applications can use pressure information to implement pressure-sensitive drawing
- and other effects.
-
-7. The values reported by `ABS_TOOL_WIDTH`, `ABS_MT_TOUCH_MAJOR`, `ABS_MT_TOUCH_MINOR`,
- `ABS_MT_WIDTH_MAJOR`, or `ABS_MT_WIDTH_MINOR` should be non-zero when the tool
- is touching the device and zero otherwise, but this is not required.
- For example, the touch device may be able to measure the size of finger touch
- contacts but not stylus touch contacts.
-
- Reporting size information is *optional* but strongly recommended.
- Applications can use pressure information to implement size-sensitive drawing
- and other effects.
-
-8. The values reported by `ABS_DISTANCE` or `ABS_MT_DISTANCE` should approach
- zero when the tool is touching the device. The distance may remain non-zero
- even when the tool is in direct contact. The exact values reported depend
- on the manner in which the hardware measures distance.
-
- Reporting distance information is *optional* but recommended for
- stylus devices.
-
-9. The values reported by `ABS_TILT_X` and `ABS_TILT_Y` should be zero when the
- tool is perpendicular to the device. A non-zero tilt is taken as an indication
- that the tool is held at an incline.
-
- The tilt angles along the X and Y axes are assumed to be specified in degrees
- from perpendicular. The center point (perfectly perpendicular) is given
- by `(max + min) / 2` for each axis. Values smaller than the center point
- represent a tilt up or to the left, values larger than the center point
- represent a tilt down or to the right.
-
- The `InputReader` converts the X and Y tilt components into a perpendicular
- tilt angle ranging from 0 to `PI / 2` radians and a planar orientation angle
- ranging from `-PI` to `PI` radians. This representation results in a
- description of orientation that is compatible with what is used to describe
- finger touches.
-
- Reporting tilt information is *optional* but recommended for stylus devices.
-
-10. If the tool type is reported by `ABS_MT_TOOL_TYPE`, it will supercede any tool
- type information reported by `BTN_TOOL_*`.
- If no tool type information is available at all, the tool type defaults to
- `MotionEvent.TOOL_TYPE_FINGER`.
-
-11. A tool is determined to be active based on the following conditions:
-
- * When using the single-touch protocol, the tool is active if `BTN_TOUCH`,
- or `BTN_TOOL_*` is 1.
-
- This condition implies that the `InputReader` needs to have at least some
- information about the nature of the tool, either whether it is touching,
- or at least its tool type. If no information is available,
- then the tool is assumed to be inactive (out of range).
-
- * When using the multi-touch protocol 'A', the tool is active whenever it
- appears in the most recent sync report. When the tool stops appearing in
- sync reports, it ceases to exist.
-
- * When using the multi-touch protocol 'B', the tool is active as long as
- it has an active slot. When the slot it cleared, the tool ceases to exist.
-
-12. A tool is determined to be hovering based on the following conditions:
-
- * If the tool is `BTN_TOOL_MOUSE` or `BTN_TOOL_LENS`, then the tool
- is not hovering, even if either of the following conditions are true.
-
- * If the tool is active and the driver reports pressure information,
- and the reported pressure is zero, then the tool is hovering.
-
- * If the tool is active and the driver supports the `BTN_TOUCH` key code and
- `BTN_TOUCH` has a value of zero, then the tool is hovering.
-
-13. The `InputReader` supports both multi-touch protocol 'A' and 'B'. New drivers
- should use the 'B' protocol but either will work.
-
-14. **As of Android Ice Cream Sandwich 4.0, touch screen drivers may need to be changed
- to comply with the Linux input protocol specification.**
-
- The following changes may be required:
-
- * When a tool becomes inactive (finger goes "up"), it should stop appearing
- in subsequent multi-touch sync reports. When all tools become inactive
- (all fingers go "up"), the driver should send an empty sync report packet,
- such as `SYN_MT_REPORT` followed by `SYN_REPORT`.
-
- Previous versions of Android expected "up" events to be reported by sending
- a pressure value of 0. The old behavior was incompatible with the
- Linux input protocol specification and is no longer supported.
-
- * Physical pressure or signal strength information should be reported using
- `ABS_MT_PRESSURE`.
-
- Previous versions of Android retrieved pressure information from
- `ABS_MT_TOUCH_MAJOR`. The old behavior was incompatible with the
- Linux input protocol specification and is no longer supported.
-
- * Touch size information should be reported using `ABS_MT_TOUCH_MAJOR`.
-
- Previous versions of Android retrieved size information from
- `ABS_MT_TOOL_MAJOR`. The old behavior was incompatible with the
- Linux input protocol specification and is no longer supported.
-
- Touch device drivers no longer need Android-specific customizations.
- By relying on the standard Linux input protocol, Android can support a
- wider variety of touch peripherals, such as external HID multi-touch
- touch screens, using unmodified drivers.
-
-## Touch Device Operation ##
-
-The following is a brief summary of the touch device operation on Android.
-
-1. The `EventHub` reads raw events from the `evdev` driver.
-
-2. The `InputReader` consumes the raw events and updates internal state about
- the position and other characteristics of each tool. It also tracks
- button states.
-
-3. If the BACK or FORWARD buttons were pressed or released, the `InputReader`
- notifies the `InputDispatcher` about the key event.
-
-4. The `InputReader` determines whether a virtual key press occurred. If so,
- it notifies the `InputDispatcher` about the key event.
-
-5. The `InputReader` determines whether the touch was initiated within the
- bounds of the display. If so, it notifies the `InputDispatcher` about
- the touch event.
-
-6. If there are no touching tools but there is at least one hovering tool,
- the `InputReader` notifies the `InputDispatcher` about the hover event.
-
-7. If the touch device type is *pointer*, the `InputReader` performs pointer
- gesture detection, moves the pointer and spots accordingly and notifies
- the `InputDispatcher` about the pointer event.
-
-8. The `InputDispatcher` uses the `WindowManagerPolicy` to determine whether
- the events should be dispatched and whether they should wake the device.
- Then, the `InputDispatcher` delivers the events to the appropriate applications.
-
-## Touch Device Configuration ##
-
-Touch device behavior is determined by the device's axes, buttons, input properties,
-input device configuration, virtual key map and key layout.
-
-Refer to the following sections for more details about the files that
-participate in keyboard configuration:
-
-* [Input Device Configuration Files](/tech/input/input-device-configuration-files.html)
-* [Virtual Key Map Files](#virtual-key-map-files)
-
-### Properties ###
-
-The system relies on many input device configuration properties to configure
-and calibrate touch device behavior.
-
-One reason for this is that the device drivers for touch devices often report
-the characteristics of touches using device-specific units.
-
-For example, many touch devices measure the touch contact area
-using an internal device-specific scale, such as the total number of
-sensor nodes that were triggered by the touch. This raw size value would
-not be meaningful applications because they would need to know about the
-physical size and other characteristics of the touch device sensor nodes.
-
-The system uses calibration parameters encoded in input device configuration
-files to decode, transform, and normalize the values reported by the touch
-device into a simpler standard representation that applications can understand.
-
-### Documentation Conventions ###
-
-For documentation purposes, we will use the following conventions to describe
-the values used by the system during the calibration process.
-
-#### Raw Axis Values ####
-
-The following expressions denote the raw values reported by the touch
-device driver as `EV_ABS` events.
-
-`raw.x`
-: The value of the `ABS_X` or `ABS_MT_POSITION_X` axis.
-
-`raw.y`
-: The value of the `ABS_Y` or `ABS_MT_POSITION_Y` axis.
-
-`raw.pressure`
-: The value of the `ABS_PRESSURE` or `ABS_MT_PRESSURE` axis, or 0 if not available.
-
-`raw.touchMajor`
-: The value of the `ABS_MT_TOUCH_MAJOR` axis, or 0 if not available.
-
-`raw.touchMinor`
-: The value of the `ABS_MT_TOUCH_MINOR` axis, or `raw.touchMajor` if not available.
-
-`raw.toolMajor`
-: The value of the `ABS_TOOL_WIDTH` or `ABS_MT_WIDTH_MAJOR` axis, or 0 if not available.
-
-`raw.toolMinor`
-: The value of the `ABS_MT_WIDTH_MINOR` axis, or `raw.toolMajor` if not available.
-
-`raw.orientation`
-: The value of the `ABS_MT_ORIENTATION` axis, or 0 if not available.
-
-`raw.distance`
-: The value of the `ABS_DISTANCE` or `ABS_MT_DISTANCE` axis, or 0 if not available.
-
-`raw.tiltX`
-: The value of the `ABS_TILT_X` axis, or 0 if not available.
-
-`raw.tiltY`
-: The value of the `ABS_TILT_Y` axis, or 0 if not available.
-
-#### Raw Axis Ranges ####
-
-The following expressions denote the bounds of raw values. They are obtained
-by calling `EVIOCGABS` ioctl for each axis.
-
-`raw.*.min`
-: The inclusive minimum value of the raw axis.
-
-`raw.*.max`
-: The inclusive maximum value of the raw axis.
-
-`raw.*.range`
-: Equivalent to `raw.*.max - raw.*.min`.
-
-`raw.*.fuzz`
-: The accuracy of the raw axis. eg. fuzz = 1 implies values are accurate to +/- 1 unit.
-
-`raw.width`
-: The inclusive width of the touch area, equivalent to `raw.x.range + 1`.
-
-`raw.height`
-: The inclusive height of the touch area, equivalent to `raw.y.range + 1`.
-
-#### Output Ranges ####
-
-The following expressions denote the characteristics of the output coordinate system.
-The system uses linear interpolation to translate touch position information from
-the surface units used by the touch device into the output units that will
-be reported to applications such as display pixels.
-
-`output.width`
-: The output width. For touch screens (associated with a display), this
- is the display width in pixels. For touch pads (not associated with a display),
- the output width equals `raw.width`, indicating that no interpolation will
- be performed.
-
-`output.height`
-: The output height. For touch screens (associated with a display), this
- is the display height in pixels. For touch pads (not associated with a display),
- the output height equals `raw.height`, indicating that no interpolation will
- be performed.
-
-`output.diag`
-: The diagonal length of the output coordinate system, equivalent to
- `sqrt(output.width ^2 + output.height ^2)`.
-
-### Basic Configuration ###
-
-The touch input mapper uses many configuration properties in the input device
-configuration file to specify calibration values. The following table describes
-some general purpose configuration properties. All other properties are described
-in the following sections along with the fields they are used to calibrate.
-
-#### `touch.deviceType` ####
-
-*Definition:* `touch.deviceType` = `touchScreen` | `touchPad` | `pointer` | `default`
-
-Specifies the touch device type.
-
-* If the value is `touchScreen`, the touch device is a touch screen associated
- with a display.
-
-* If the value is `touchPad`, the touch device is a touch pad not associated
- with a display.
-
-* If the value is `pointer`, the touch device is a touch pad not associated
- with a display, and its motions are used for
- [indirect multi-touch pointer gestures](#indirect-multi-touch-pointer-gestures).
-
-* If the value is `default`, the system automatically detects the device type
- according to the classification algorithm.
-
-Refer to the [Classification](#touch-device-classification) section for more details
-about how the device type influences the behavior of the touch device.
-
-Prior to Honeycomb, all touch devices were assumed to be touch screens.
-
-#### `touch.orientationAware` ####
-
-*Definition:* `touch.orientationAware` = `0` | `1`
-
-Specifies whether the touch device should react to display orientation changes.
-
-* If the value is `1`, touch positions reported by the touch device are rotated
- whenever the display orientation changes.
-
-* If the value is `0`, touch positions reported by the touch device are immune
- to display orientation changes.
-
-The default value is `1` if the device is a touch screen, `0` otherwise.
-
-The system distinguishes between internal and external touch screens and displays.
-An orientation aware internal touch screen is rotated based on the orientation
-of the internal display. An orientation aware external touch screen is rotated
-based on the orientation of the external display.
-
-Orientation awareness is used to support rotation of touch screens on devices
-like the Nexus One. For example, when the device is rotated clockwise 90 degrees
-from its natural orientation, the absolute positions of touches are remapped such
-that a touch in the top-left corner of the touch screen's absolute coordinate system
-is reported as a touch in the top-left corner of the display's rotated coordinate system.
-This is done so that touches are reported with the same coordinate system that
-applications use to draw their visual elements.
-
-Prior to Honeycomb, all touch devices were assumed to be orientation aware.
-
-#### `touch.gestureMode` ####
-
-*Definition:* `touch.gestureMode` = `pointer` | `spots` | `default`
-
-Specifies the presentation mode for pointer gestures. This configuration property
-is only relevant when the touch device is of type *pointer*.
-
-* If the value is `pointer`, the touch pad gestures are presented by way of a cursor
- similar to a mouse pointer.
-
-* If the value is `spots`, the touch pad gestures are presented by an anchor
- that represents the centroid of the gesture and a set of circular spots
- that represent the position of individual fingers.
-
-The default value is `pointer` when the `INPUT_PROP_SEMI_MT` input property
-is set, or `spots` otherwise.
-
-### `X` and `Y` Fields ###
-
-The X and Y fields provide positional information for the center of the contact area.
-
-#### Calculation ####
-
-The calculation is straightforward: positional information from the touch driver is
-linearly interpolated to the output coordinate system.
-
- xScale = output.width / raw.width
- yScale = output.height / raw.height
-
- If not orientation aware or screen rotation is 0 degrees:
- output.x = (raw.x - raw.x.min) * xScale
- output.y = (raw.y - raw.y.min) * yScale
- Else If rotation is 90 degrees:
- output.x = (raw.y - raw.y.min) * yScale
- output.y = (raw.x.max - raw.x) * xScale
- Else If rotation is 180 degrees:
- output.x = (raw.x.max - raw.x) * xScale
- output.y = (raw.y.max - raw.y) * yScale
- Else If rotation is 270 degrees:
- output.x = (raw.y.max - raw.y) * yScale
- output.y = (raw.x - raw.x.min) * xScale
- End If
-
-### `TouchMajor`, `TouchMinor`, `ToolMajor`, `ToolMinor`, `Size` Fields ###
-
-The `TouchMajor` and `TouchMinor` fields describe the approximate dimensions
-of the contact area in output units (pixels).
-
-The `ToolMajor` and `ToolMinor` fields describe the approximate dimensions
-of the [tool](#tools-and-tool-types) itself in output units (pixels).
-
-The `Size` field describes the normalized size of the touch relative to
-the largest possible touch that the touch device can sense. The smallest
-possible normalized size is 0.0 (no contact, or it is unmeasurable), and the largest
-possible normalized size is 1.0 (sensor area is saturated).
-
-When both the approximate length and breadth can be measured, then the `TouchMajor` field
-specifies the longer dimension and the `TouchMinor` field specifies the shorter dimension
-of the contact area. When only the approximate diameter of the contact area can be measured,
-then the `TouchMajor` and `TouchMinor` fields will be equal.
-
-Likewise, the `ToolMajor` field specifies the longer dimension and the `ToolMinor`
-field specifies the shorter dimension of the tool's cross-sectional area.
-
-If the touch size is unavailable but the tool size is available, then the tool size
-will be set equal to the touch size. Conversely, if the tool size is unavailable
-but the touch size is available, then the touch size will be set equal to the tool size.
-
-Touch devices measure or report the touch size and tool size in various ways.
-The current implementation supports three different kinds of measurements:
-diameter, area, and geometric bounding box in surface units.
-
-#### `touch.size.calibration` ####
-
-*Definition:* `touch.size.calibration` = `none` | `geometric` | `diameter`
-| `area` | `default`
-
-Specifies the kind of measurement used by the touch driver to report the
-touch size and tool size.
-
-* If the value is `none`, the size is set to zero.
-
-* If the value is `geometric`, the size is assumed to be specified in the same
- surface units as the position, so it is scaled in the same manner.
-
-* If the value is `diameter`, the size is assumed to be proportional to
- the diameter (width) of the touch or tool.
-
-* If the value is `area`, the size is assumed to be proportional to the
- area of the touch or tool.
-
-* If the value is `default`, the system uses the `geometric` calibration if the
- `raw.touchMajor` or `raw.toolMajor` axis is available, otherwise it uses
- the `none` calibration.
-
-#### `touch.size.scale` ####
-
-*Definition:* `touch.size.scale` = <a non-negative floating point number>
-
-Specifies a constant scale factor used in the calibration.
-
-The default value is `1.0`.
-
-#### `touch.size.bias` ####
-
-*Definition:* `touch.size.bias` = <a non-negative floating point number>
-
-Specifies a constant bias value used in the calibration.
-
-The default value is `0.0`.
-
-#### `touch.size.isSummed` ####
-
-*Definition:* `touch.size.isSummed` = `0` | `1`
-
-Specifies whether the size is reported as the sum of the sizes of all
-active contacts, or is reported individually for each contact.
-
-* If the value is `1`, the reported size will be divided by the number
- of contacts prior to use.
-
-* If the value is `0`, the reported size will be used as is.
-
-The default value is `0`.
-
-Some touch devices, particularly "Semi-MT" devices cannot distinguish the
-individual dimensions of multiple contacts so they report a size measurement
-that represents their total area or width. This property should only be set to
-`1` for such devices. If in doubt, set this value to `0`.
-
-#### Calculation ####
-
-The calculation of the `TouchMajor`, `TouchMinor`, `ToolMajor`, `ToolMinor`
-and `Size` fields depends on the specified calibration parameters.
-
- If raw.touchMajor and raw.toolMajor are available:
- touchMajor = raw.touchMajor
- touchMinor = raw.touchMinor
- toolMajor = raw.toolMajor
- toolMinor = raw.toolMinor
- Else If raw.touchMajor is available:
- toolMajor = touchMajor = raw.touchMajor
- toolMinor = touchMinor = raw.touchMinor
- Else If raw.toolMajor is available:
- touchMajor = toolMajor = raw.toolMajor
- touchMinor = toolMinor = raw.toolMinor
- Else
- touchMajor = toolMajor = 0
- touchMinor = toolMinor = 0
- size = 0
- End If
-
- size = avg(touchMajor, touchMinor)
-
- If touch.size.isSummed == 1:
- touchMajor = touchMajor / numberOfActiveContacts
- touchMinor = touchMinor / numberOfActiveContacts
- toolMajor = toolMajor / numberOfActiveContacts
- toolMinor = toolMinor / numberOfActiveContacts
- size = size / numberOfActiveContacts
- End If
-
- If touch.size.calibration == "none":
- touchMajor = toolMajor = 0
- touchMinor = toolMinor = 0
- size = 0
- Else If touch.size.calibration == "geometric":
- outputScale = average(output.width / raw.width, output.height / raw.height)
- touchMajor = touchMajor * outputScale
- touchMinor = touchMinor * outputScale
- toolMajor = toolMajor * outputScale
- toolMinor = toolMinor * outputScale
- Else If touch.size.calibration == "area":
- touchMajor = sqrt(touchMajor)
- touchMinor = touchMajor
- toolMajor = sqrt(toolMajor)
- toolMinor = toolMajor
- Else If touch.size.calibration == "diameter":
- touchMinor = touchMajor
- toolMinor = toolMajor
- End If
-
- If touchMajor != 0:
- output.touchMajor = touchMajor * touch.size.scale + touch.size.bias
- Else
- output.touchMajor = 0
- End If
-
- If touchMinor != 0:
- output.touchMinor = touchMinor * touch.size.scale + touch.size.bias
- Else
- output.touchMinor = 0
- End If
-
- If toolMajor != 0:
- output.toolMajor = toolMajor * touch.size.scale + touch.size.bias
- Else
- output.toolMajor = 0
- End If
-
- If toolMinor != 0:
- output.toolMinor = toolMinor * touch.size.scale + touch.size.bias
- Else
- output.toolMinor = 0
- End If
-
- output.size = size
-
-### `Pressure` Field ###
-
-The `Pressure` field describes the approximate physical pressure applied to the
-touch device as a normalized value between 0.0 (no touch) and 1.0 (full force).
-
-A zero pressure indicates that the tool is hovering.
-
-#### `touch.pressure.calibration` ####
-
-*Definition:* `touch.pressure.calibration` = `none` | `physical` | `amplitude` | `default`
-
-Specifies the kind of measurement used by the touch driver to report the pressure.
-
-* If the value is `none`, the pressure is unknown so it is set to 1.0 when
- touching and 0.0 when hovering.
-
-* If the value is `physical`, the pressure axis is assumed to measure the actual
- physical intensity of pressure applied to the touch pad.
-
-* If the value is `amplitude`, the pressure axis is assumed to measure the signal
- amplitude, which is related to the size of the contact and the pressure applied.
-
-* If the value is `default`, the system uses the `physical` calibration if the
- pressure axis available, otherwise uses `none`.
-
-#### `touch.pressure.scale` ####
-
-*Definition:* `touch.pressure.scale` = <a non-negative floating point number>
-
-Specifies a constant scale factor used in the calibration.
-
-The default value is `1.0 / raw.pressure.max`.
-
-#### Calculation ####
-
-The calculation of the `Pressure` field depends on the specified calibration parameters.
-
- If touch.pressure.calibration == "physical" or "amplitude":
- output.pressure = raw.pressure * touch.pressure.scale
- Else
- If hovering:
- output.pressure = 0
- Else
- output.pressure = 1
- End If
- End If
-
-### `Orientation` and `Tilt` Fields ###
-
-The `Orientation` field describes the orientation of the touch and tool as an
-angular measurement. An orientation of `0` indicates that the major axis is
-oriented vertically, `-PI/2` indicates that the major axis is oriented to the left,
-`PI/2` indicates that the major axis is oriented to the right. When a stylus
-tool is present, the orientation range may be described in a full circle range
-from `-PI` or `PI`.
-
-The `Tilt` field describes the inclination of the tool as an angular measurement.
-A tilt of `0` indicates that the tool is perpendicular to the surface.
-A tilt of `PI/2` indicates that the tool is flat on the surface.
-
-#### `touch.orientation.calibration` ####
-
-*Definition:* `touch.orientation.calibration` = `none` | `interpolated` | `vector` | `default`
-
-Specifies the kind of measurement used by the touch driver to report the orientation.
-
-* If the value is `none`, the orientation is unknown so it is set to 0.
-
-* If the value is `interpolated`, the orientation is linearly interpolated such that a
- raw value of `raw.orientation.min` maps to `-PI/2` and a raw value of
- `raw.orientation.max` maps to `PI/2`. The center value of
- `(raw.orientation.min + raw.orientation.max) / 2` maps to `0`.
-
-* If the value is `vector`, the orientation is interpreted as a packed vector consisiting
- of two signed 4-bit fields. This representation is used on Atmel Object Based Protocol
- parts. When decoded, the vector yields an orientation angle and confidence
- magnitude. The confidence magnitude is used to scale the size information,
- unless it is geometric.
-
-* If the value is `default`, the system uses the `interpolated` calibration if the
- orientation axis available, otherwise uses `none`.
-
-#### Calculation ####
-
-The calculation of the `Orientation` and `Tilt` fields depends on the specified
-calibration parameters and available input.
-
- If touch.tiltX and touch.tiltY are available:
- tiltXCenter = average(raw.tiltX.min, raw.tiltX.max)
- tiltYCenter = average(raw.tiltY.min, raw.tiltY.max)
- tiltXAngle = (raw.tiltX - tiltXCenter) * PI / 180
- tiltYAngle = (raw.tiltY - tiltYCenter) * PI / 180
- output.orientation = atan2(-sin(tiltXAngle), sinf(tiltYAngle))
- output.tilt = acos(cos(tiltXAngle) * cos(tiltYAngle))
- Else If touch.orientation.calibration == "interpolated":
- center = average(raw.orientation.min, raw.orientation.max)
- output.orientation = PI / (raw.orientation.max - raw.orientation.min)
- output.tilt = 0
- Else If touch.orientation.calibration == "vector":
- c1 = (raw.orientation & 0xF0) >> 4
- c2 = raw.orientation & 0x0F
-
- If c1 != 0 or c2 != 0:
- If c1 >= 8 Then c1 = c1 - 16
- If c2 >= 8 Then c2 = c2 - 16
- angle = atan2(c1, c2) / 2
- confidence = sqrt(c1*c1 + c2*c2)
-
- output.orientation = angle
-
- If touch.size.calibration == "diameter" or "area":
- scale = 1.0 + confidence / 16
- output.touchMajor *= scale
- output.touchMinor /= scale
- output.toolMajor *= scale
- output.toolMinor /= scale
- End If
- Else
- output.orientation = 0
- End If
- output.tilt = 0
- Else
- output.orientation = 0
- output.tilt = 0
- End If
-
- If orientation aware:
- If screen rotation is 90 degrees:
- output.orientation = output.orientation - PI / 2
- Else If screen rotation is 270 degrees:
- output.orientation = output.orientation + PI / 2
- End If
- End If
-
-### `Distance` Field ###
-
-The `Distance` field describes the distance between the tool and the touch device
-surface. A value of 0.0 indicates direct contact and larger values indicate
-increasing distance from the surface.
-
-#### `touch.distance.calibration` ####
-
-*Definition:* `touch.distance.calibration` = `none` | `scaled` | `default`
-
-Specifies the kind of measurement used by the touch driver to report the distance.
-
-* If the value is `none`, the distance is unknown so it is set to 0.
-
-* If the value is `scaled`, the reported distance is multiplied by a
- constant scale factor.
-
-* If the value is `default`, the system uses the `scaled` calibration if the
- distance axis available, otherwise uses `none`.
-
-#### `touch.distance.scale` ####
-
-*Definition:* `touch.distance.scale` = <a non-negative floating point number>
-
-Specifies a constant scale factor used in the calibration.
-
-The default value is `1.0`.
-
-#### Calculation ####
-
-The calculation of the `Distance` field depends on the specified calibration parameters.
-
- If touch.distance.calibration == "scaled":
- output.distance = raw.distance * touch.distance.scale
- Else
- output.distance = 0
- End If
-
-### Example ###
-
- # Input device configuration file for a touch screen that supports pressure,
- # size and orientation. The pressure and size scale factors were obtained
- # by measuring the characteristics of the device itself and deriving
- # useful approximations based on the resolution of the touch sensor and the
- # display.
- #
- # Note that these parameters are specific to a particular device model.
- # Different parameters will need to be used for other devices.
-
- # Basic Parameters
- touch.deviceType = touchScreen
- touch.orientationAware = 1
-
- # Size
- # Based on empirical measurements, we estimate the size of the contact
- # using size = sqrt(area) * 28 + 0.
- touch.size.calibration = area
- touch.size.scale = 28
- touch.size.bias = 0
- touch.size.isSummed = 0
-
- # Pressure
- # Driver reports signal strength as pressure.
- #
- # A normal index finger touch typically registers about 80 signal strength
- # units although we don't expect these values to be accurate.
- touch.pressure.calibration = amplitude
- touch.pressure.scale = 0.0125
-
- # Orientation
- touch.orientation.calibration = vector
-
-### Compatibility Notes ###
-
-The configuration properties for touch devices changed significantly in
-Android Ice Cream Sandwich 4.0. **All input device configuration files for touch
-devices must be updated to use the new configuration properties.**
-
-Older touch device [drivers](#touch-device-driver-requirements) may also need to be
-updated.
-
-## Virtual Key Map Files ##
-
-Touch devices are often used to implement virtual keys.
-
-There are several ways of doing this, depending on the capabilities of the
-touch controller. Some touch controllers can be directly configured to implement
-soft keys by setting firmware registers. Other times it is desirable to perform
-the mapping from touch coordinates to key codes in software.
-
-When virtual keys are implemented in software, the kernel must export a virtual key map
-file called `virtualkeys.<devicename>` as a board property. For example,
-if the touch screen device drivers reports its name as "touchyfeely" then
-the virtual key map file must have the path `/sys/board_properties/virtualkeys.touchyfeely`.
-
-A virtual key map file describes the coordinates and Linux key codes of virtual keys
-on the touch screen.
-
-In addition to the virtual key map file, there must be a corresponding key layout
-file and key character map file to map the Linux key codes to Android key codes and
-to specify the type of the keyboard device (usually `SPECIAL_FUNCTION`).
-
-### Syntax ###
-
-A virtual key map file is a plain text file consisting of a sequence of virtual key
-layout descriptions either separated by newlines or by colons.
-
-Comment lines begin with '#' and continue to the end of the line.
-
-Each virtual key is described by 6 colon-delimited components:
-
-* `0x01`: A version code. Must always be `0x01`.
-* <Linux key code>: The Linux key code of the virtual key.
-* <centerX>: The X pixel coordinate of the center of the virtual key.
-* <centerY>: The Y pixel coordinate of the center of the virtual key.
-* <width>: The width of the virtual key in pixels.
-* <height>: The height of the virtual key in pixels.
-
-All coordinates and sizes are specified in terms of the display coordinate system.
-
-Here is a virtual key map file all written on one line.
-
- # All on one line
- 0x01:158:55:835:90:55:0x01:139:172:835:125:55:0x01:102:298:835:115:55:0x01:217:412:835:95:55
-
-The same virtual key map file can also be written on multiple lines.
-
- # One key per line
- 0x01:158:55:835:90:55
- 0x01:139:172:835:125:55
- 0x01:102:298:835:115:55
- 0x01:217:412:835:95:55
-
-In the above example, the touch screen has a resolution of 480x800. Accordingly, all of
-the virtual keys have a <centerY> coordinate of 835, which is a little bit below
-the visible area of the touch screen.
-
-The first key has a Linux scan code of `158` (`KEY_BACK`), centerX of `55`,
-centerY of `835`, width of `90` and height of `55`.
-
-### Example ###
-
-Virtual key map file: `/sys/board_properties/virtualkeys.touchyfeely`.
-
- 0x01:158:55:835:90:55
- 0x01:139:172:835:125:55
- 0x01:102:298:835:115:55
- 0x01:217:412:835:95:55
-
-Key layout file: `/system/usr/keylayout/touchyfeely.kl`.
-
- key 158 BACK
- key 139 MENU
- key 102 HOME
- key 217 SEARCH
-
-Key character map file: `/system/usr/keychars/touchyfeely.kcm`.
-
- type SPECIAL_FUNCTION
-
-## Indirect Multi-touch Pointer Gestures ##
-
-In pointer mode, the system interprets the following gestures:
-
-1. Single finger tap: click.
-
-2. Single finger motion: move the pointer.
-
-3. Single finger motion plus button presses: drag the pointer.
-
-4. Two finger motion both fingers moving in the same direction: drag the area under the pointer
- in that direction. The pointer itself does not move.
-
-5. Two finger motion both fingers moving towards each other or apart in
- different directions: pan/scale/rotate the area surrounding the pointer.
- The pointer itself does not move.
-
-6. Multiple finger motion: freeform gesture.
-
-## Further Reading ##
-
-1. [Linux multi-touch protocol](http://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt)
-2. [ENAC list of available multitouch devices on Linux](http://lii-enac.fr/en/architecture/linux-input/multitouch-devices.html)
diff --git a/src/tech/input/validate-keymaps.md b/src/tech/input/validate-keymaps.md
deleted file mode 100644
index 8d8df9a..0000000
--- a/src/tech/input/validate-keymaps.md
+++ /dev/null
@@ -1,96 +0,0 @@
-<!--
- 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.
--->
-
-# Validate Keymaps Tool #
-
-The Android framework has a small tool called `validatekeymaps` to validate the
-syntax of input device configuration files, key layout files, key character
-maps files and virtual key definition files.
-
-## Compilation ##
-
-To compile `validatekeymaps`, set up the development environment, download
-the Android source tree, compile it, then run:
-
- $ mmm frameworks/base/tools/validatekeymaps
-
-This command should compile a host tool called validatekeymaps into the
-`out/host/<os>/bin` directory.
-
-## Usage ##
-
-If you ran `envsetup.sh` to set up your development environment, then the
-`validatekeymaps` tool should already be on your path. You can verify
-this by running `validatekeymaps`.
-
- $ validatekeymaps
-
- Keymap Validation Tool
-
- Usage:
- validatekeymaps [*.kl] [*.kcm] [*.idc] [virtualkeys.*] [...]
- Validates the specified key layouts, key character maps,
- input device configurations, or virtual key definitions.
-
-Then all you need to do is run `validatekeymaps` an give it the path of
-one or more files to validate.
-
- $ validatekeymaps frameworks/base/data/keyboards/Generic.kl
-
- Validating file 'frameworks/base/data/keyboards/Generic.kl'...
- No errors.
-
- Success.
-
-And if there is an error...
-
- $ validatekeymaps Bad.kl
-
- Validating file 'Bad.kl'...
- E/KeyLayoutMap(87688): Bad.kl:24: Expected keyword, got 'ke'.
- Error -22 parsing key layout file.
-
- Failed!
-
-## Automation ##
-
-It is a *very* good idea to run `validatekeymaps` on all configuration files
-before installing them on a device.
-
-The process can easily be automated as part of the build system by using a
-script or a makefile.
-
-The following sample makefile is based on the contents of
-`frameworks/base/data/keyboards/Android.mk`.
-
- # This makefile performs build time validation of framework keymap files.
-
- LOCAL_PATH := $(call my-dir)
-
- # Validate all key maps.
- include $(CLEAR_VARS)
-
- validatekeymaps := $(HOST_OUT_EXECUTABLES)/validatekeymaps$(HOST_EXECUTABLE_SUFFIX)
- files := MyKeyboard.kl MyKeyboard.kcm MyTouchScreen.idc
-
- LOCAL_MODULE := validate_framework_keymaps
- LOCAL_MODULE_TAGS := optional
- LOCAL_REQUIRED_MODULES := validatekeymaps
-
- validate_framework_keymaps: $(files)
- $(hide) $(validatekeymaps) $(files)
-
- include $(BUILD_PHONY_PACKAGE)
diff --git a/src/tech/nfc/sidebar2.md b/src/tech/nfc/sidebar2.md
deleted file mode 100644
index 8579d80..0000000
--- a/src/tech/nfc/sidebar2.md
+++ /dev/null
@@ -1 +0,0 @@
-# NFC Topics #
diff --git a/src/tech/security/android_4_2_security_enhancements.md b/src/tech/security/android_4_2_security_enhancements.md
deleted file mode 100644
index ad00374..0000000
--- a/src/tech/security/android_4_2_security_enhancements.md
+++ /dev/null
@@ -1,55 +0,0 @@
-#Security Enhancements in Android 4.2
-
-Android provides a multi-layered security model described in the [Android
-Security Overview](index.html). Each update to Android includes dozens of
-security enhancements to protect users. The following are some of the security
-enhancements introduced in Android 4.2:
-
-+ **Application verification.** Users can choose to enable “Verify Apps" and
-have applications screened 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.
-
-+ **More control of premium SMS.** Android will provide a notification if an
-application attempts to send SMS to a short code that uses premium services
-which might cause additional charges. The user can choose whether to allow the
-application to send the message or block it.
-
-+ **Always-on VPN.** VPN can be configured so that applications will not have
-access to the network until a VPN connection is established. This prevents
-applications from sending data across other networks.
-
-+ **Certificate Pinning.** The Android core libraries now support
-[certificate pinning](https://developer.android.com/reference/android/net/http/X509TrustManagerExtensions.html). Pinned domains will receive a certificate validation
-failure if the certificate does not chain to a set of expected certificates.
-This protects against possible compromise of Certificate Authorities.
-
-+ **Improved display of Android permissions.** Permissions have been organized
-into groups that are more easily understood by users. During review of the
-permissions, the user can click on the permission to see more detailed
-information about the permission.
-
-+ **installd hardening.** The installd daemon does not run as the root user,
-reducing potential attack surface for root privilege escalation.
-
-+ **init script hardening.** init scripts now apply O_NOFOLLOW semantics to
-prevent symlink related attacks.
-
-+ **FORTIFY_SOURCE.** Android now implements FORTIFY_SOURCE. This is used by
-system libraries and applications to prevent memory corruption.
-
-+ **ContentProvider default configuration.** Applications which target API
-level 17 will have "export" set to "false" by default for each
-[ContentProvider](https://developer.android.com/reference/android/content/ContentProvider.html),
-reducing default attack surface for applications.
-
-+ **Cryptography.** Modified the default implementations of SecureRandom and
-Cipher.RSA to use OpenSSL. Added SSL Socket support for TLSv1.1 and TLSv1.2
-using OpenSSL 1.0.1
-
-+ **Security Fixes.** Upgraded open source libraries with security fixes include
-WebKit, libpng, OpenSSL, and LibXML. Android 4.2 also includes fixes for
-Android-specific vulnerabilities. Information about these vulnerabilities has
-been provided to Open Handset Alliance members and fixes are available in
-Android Open Source Project. To improve security, some devices with earlier
-versions of Android may also include these fixes.
diff --git a/src/tech/security/index.md b/src/tech/security/index.md
deleted file mode 100644
index db5f140..0000000
--- a/src/tech/security/index.md
+++ /dev/null
@@ -1,873 +0,0 @@
-[TOC]
-#Android Security Overview
-
-##Introduction
-
-Android is a modern mobile platform that was designed to be truly open. Android
-applications make use of advanced hardware and software, as well as local and
-served data, exposed through the platform to bring innovation and value to
-consumers. To protect that value, the platform must offer an application
-environment that ensures the security of users, data, applications, the device,
-and the network.
-
-Securing an open platform requires a robust security architecture and rigorous
-security programs. Android was designed with multi-layered security that
-provides the flexibility required for an open platform, while providing
-protection for all users of the platform.
-
-Android was designed with developers in mind. Security controls were designed
-to reduce the burden on developers. Security-savvy developers can easily work
-with and rely on flexible security controls. Developers less familiar with
-security will be protected by safe defaults.
-
-Android was designed with device users in mind. Users are provided visibility
-into how applications work, and control over those applications. This design
-includes the expectation that attackers would attempt to perform common
-attacks, such as social engineering attacks to convince device users to install
-malware, and attacks on third-party applications on Android. Android was
-designed to both reduce the probability of these attacks and greatly limit the
-impact of the attack in the event it was successful.
-
-This document outlines the goals of the Android security program, describes the
-fundamentals of the Android security architecture, and answers the most
-pertinent questions for system architects and security analysts. This document
-focuses on the security features of Android's core platform and does not
-discuss security issues that are unique to specific applications, such as those
-related to the browser or SMS application. Recommended best practices for
-building Android devices, deploying Android devices, or developing applications
-for Android are not the goal of this document and are provided elsewhere.
-
-# Background
-
-Android provides an open source platform and application environment for mobile
-devices.
-
-The main Android platform building blocks are:
-
-+ **Device Hardware**: Android runs on a wide range of hardware configurations
-including smart phones, tablets, and set-top-boxes. Android is
-processor-agnostic, but it does take advantage of some hardware-specific
-security capabilities such as ARM v6 eXecute-Never.
-
-+ **Android Operating System**: The core operating system is built on top of
-the Linux kernel. All device resources, like camera functions, GPS data,
-Bluetooth functions, telephony functions, network connections, etc. are
-accessed through the operating system.
-
-+ **Android Application Runtime**: Android applications are most often written
-in the Java programming language and run in the Dalvik virtual machine.
-However, many applications, including core Android services and applications
-are native applications or include native libraries. Both Dalvik and native
-applications run within the same security environment, contained within the
-Application Sandbox. Applications get a dedicated part of the filesystem in
-which they can write private data, including databases and raw files.
-
-Android applications extend the core Android operating system. There are two
-primary sources for applications:
-
-+ **Pre-Installed Applications**: Android includes a set of pre-installed
-applications including phone, email, calendar, web browser, and contacts. These
-function both as user applications and to provide key device capabilities that
-can be accessed by other applications. Pre-installed applications may be part
-of the open source Android platform, or they may be developed by an OEM for a
-specific device.
-
-+ **User-Installed Applications**: Android provides an open development
-environment supporting any third-party application. Google Play offers
-users hundreds of thousands of applications.
-
-Google provides a set of cloud-based services that are available to any
-compatible Android device. The primary services are:
-
-+ **Google Play**: Google Play is a collection of services that
-allow users to discover, install, and purchase applications from their Android
-device or the web. Google Play makes it easy for developers to reach Android
-users and potential customers. Google Play also provides community review,
-application [license
-verification](https://developer.android.com/guide/publishing/licensing.html),
-application security scanning, and other security services.
-
-+ **Android Updates**: The Android update service delivers new capabilities and
-security updates to Android devices, including updates through the web or over
-the air (OTA).
-
-+ **Application Services**: Frameworks that allow Android applications to use
-cloud capabilities such as ([backing
-up](https://developer.android.com/guide/topics/data/backup.html)) application
-data and settings and cloud-to-device messaging
-([C2DM](https://code.google.com/android/c2dm/index.html))
-for push messaging.
-
-These services are not part of the Android Open Source Project and are out
-of scope for this document. But they are relevant to the security of most
-Android devices, so a related security document titled “Google Services for
-Android: Security Overview” is available.
-
-##Android Security Program Overview
-
-Early on in development, the core Android development team recognized that a
-robust security model was required to enable a vigorous ecosystem of
-applications and devices built on and around the Android platform and supported
-by cloud services. As a result, through its entire development lifecycle,
-Android has been subjected to a professional security program. The Android team
-has had the opportunity to observe how other mobile, desktop, and server platforms
-prevented and reacted to security issues and built a security
-program to address weak points observed in other offerings.
-
-The key components of the Android Security Program include:
-
-+ **Design Review**: The Android security process begins early in the
-development lifecycle with the creation of a rich and configurable security
-model and design. Each major feature of the platform is reviewed by engineering
-and security resources, with appropriate security controls integrated into the
-architecture of the system.
-+ **Penetration Testing and Code Review**: During the development of the
-platform, Android-created and open-source components are subject to vigorous
-security reviews. These reviews are performed by the Android Security Team,
-Google’s Information Security Engineering team, and independent security
-consultants. The goal of these reviews is to identify weaknesses and possible
-vulnerabilities well before the platform is open-sourced, and to simulate the
-types of analysis that will be performed by external security experts upon
-release.
-+ **Open Source and Community Review**: The Android Open Source Project enables
-broad security review by any interested party. Android also uses open source
-technologies that have undergone significant external security review,
-such as the Linux kernel. Google Play provides a forum for users and companies
-to provide information about specific applications directly to users.
-+ **Incident Response**: Even with all of these precautions, security issues
-may occur after shipping, which is why the Android project has created a
-comprehensive security response process. A full-time Android security team
-constantly monitors Android-specific and the general security community for
-discussion of potential vulnerabilities. Upon the discovery of legitimate
-issues, the Android team has a response process that enables the rapid
-mitigation of vulnerabilities to ensure that potential risk to all Android
-users is minimized. These cloud-supported responses can include updating the
-Android platform (over-the-air updates), removing applications from Google
-Play, and removing applications from devices in the field.
-
-##Android Platform Security Architecture
-
-Android seeks to be the most secure and usable operating system for mobile
-platforms by re-purposing traditional operating system security controls to:
-
-+ Protect user data
-+ Protect system resources (including the network)
-+ Provide application isolation
-
-To achieve these objectives, Android provides these key security features:
-
-+ Robust security at the OS level through the Linux kernel
-+ Mandatory application sandbox for all applications
-+ Secure interprocess communication
-+ Application signing
-+ Application-defined and user-granted permissions
-
-The sections below describe these and other security features of the Android
-platform. *Figure 1* summarizes the security components and considerations of
-the various levels of the Android software stack. Each component assumes that
-the components below are properly secured. With the exception of a small amount
-of Android OS code running as root, all code above the Linux Kernel is
-restricted by the Application Sandbox.
-
-
-
-*Figure 1: Android software stack.*
-
-#System and Kernel Level Security
-
-At the operating system level, the Android platform provides the security of
-the Linux kernel, as well as a secure inter-process communication (IPC)
-facility to enable secure communication between applications running in
-different processes. These security features at the OS level ensure that even
-native code is constrained by the Application Sandbox. Whether that code is
-the result of included application behavior or a exploitation of an application
-vulnerability, the system would prevent the rogue application from harming
-other applications, the Android system, or the device itself.
-
-##Linux Security
-
-The foundation of the Android platform is the Linux kernel. The Linux kernel
-itself has been in widespread use for years, and is used in millions of
-security-sensitive environments. Through its history of constantly being
-researched, attacked, and fixed by thousands of developers, Linux has become a
-stable and secure kernel trusted by many corporations and security
-professionals.
-
-As the base for a mobile computing environment, the Linux kernel provides
-Android with several key security features, including:
-
-+ A user-based permissions model
-+ Process isolation
-+ Extensible mechanism for secure IPC
-+ The ability to remove unnecessary and potentially insecure parts of the kernel
-
-As a multiuser operating system, a fundamental security objective of the Linux
-kernel is to isolate user resources from one another. The Linux security
-philosophy is to protect user resources from one another. Thus, Linux:
-
-+ Prevents user A from reading user B's files
-+ Ensures that user A does not exhaust user B's memory
-+ Ensures that user A does not exhaust user B's CPU resources
-+ Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
-bluetooth)
-
-##The Application Sandbox
-
-The Android platform takes advantage of the Linux user-based protection as a
-means of identifying and isolating application resources. The Android system
-assigns a unique user ID (UID) to each Android application and runs it as that user
-in a separate process. This approach is different from other operating systems
-(including the traditional Linux configuration), where multiple applications
-run with the same user permissions.
-
-This sets up a kernel-level Application Sandbox. The kernel enforces security
-between applications and the system at the process level through standard Linux
-facilities, such as user and group IDs that are assigned to applications. By
-default, applications cannot interact with each other and applications have
-limited access to the operating system. If application A tries to do something
-malicious like read application B's data or dial the phone without permission
-(which is a separate application), then the operating system protects against
-this because application A does not have the appropriate user privileges. The
-sandbox is simple, auditable, and based on decades-old UNIX-style user
-separation of processes and file permissions.
-
-Since the Application Sandbox is in the kernel, this security model extends to
-native code and to operating system applications. All of the software above the
-kernel in *Figure 1*, including operating system libraries, application
-framework, application runtime, and all applications run within the Application
-Sandbox. On some platforms, developers are constrained to a specific
-development framework, set of APIs, or language in order to enforce security.
-On Android, there are no restrictions on how an application can be written that
-are required to enforce security; in this respect, native code is just as
-secure as interpreted code.
-
-In some operating systems, memory corruption errors generally lead to
-completely compromising the security of the device. This is not the case in
-Android due to all applications and their resources being sandboxed at the OS
-level. A memory corruption error will only allow arbitrary code execution in
-the context of that particular application, with the permissions established by
-the operating system.
-
-Like all security features, the Application Sandbox is not unbreakable.
-However, to break out of the Application Sandbox in a properly configured
-device, one must compromise the security of the the Linux kernel.
-
-##System Partition and Safe Mode
-
-The system partition contains Android's kernel as well as the operating system
-libraries, application runtime, application framework, and applications. This
-partition is set to read-only. When a user boots the device into Safe Mode,
-only core Android applications are available. This ensures that the user can
-boot their phone into an environment that is free of third-party software.
-
-##Filesystem Permissions
-
-In a UNIX-style environment, filesystem permissions ensure that one user cannot
-alter or read another user's files. In the case of Android, each application
-runs as its own user. Unless the developer explicitly exposes files to other
-applications, files created by one application cannot be read or altered by
-another application.
-
-##Cryptography
-
-Android provides a set of cryptographic APIs for use by applications. These
-include implementations of standard and commonly used cryptographic primitives
-such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level
-protocols such as SSL and HTTPS.
-
-Android 4.0 introduced the
-[KeyChain](http://developer.android.com/reference/android/security/KeyChain.html)
-class to allow applications to use the system credential storage for private
-keys and certificate chains.
-
-##Memory Management Security Enhancements
-
-Android includes many features that make common security issues harder to
-exploit. The Android SDK, compilers, and OS use tools to make common memory
-corruption issues significantly harder to exploit, including:
-
-**Android 1.5+**
-
-+ ProPolice to prevent stack buffer overruns (-fstack-protector)
-+ safe_iop to reduce integer overflows
-+ Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and
-to prevent chunk consolidation attacks. Chunk consolidation attacks are a
-common way to exploit heap corruption.
-+ OpenBSD calloc to prevent integer overflows during memory allocation
-
-**Android 2.3+**
-
-+ Format string vulnerability protections (-Wformat-security -Werror=format-security)
-+ Hardware-based No eXecute (NX) to prevent code execution on the stack and heap
-+ Linux mmap_min_addr to mitigate null pointer dereference privilege
-escalation (further enhanced in Android 4.1)
-
-**Android 4.0+**
-
-+ Address Space Layout Randomization (ASLR) to randomize key locations in memory
-
-**Android 4.1+**
-
-+ PIE (Position Independent Executable) support
-+ Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)
-+ dmesg_restrict enabled (avoid leaking kernel addresses)
-+ kptr_restrict enabled (avoid leaking kernel addresses)
-
-** Android 4.2+**
-
-+ FORTIFY_SOURCE for system code
-
-##Rooting of Devices
-
-By default, on Android only the kernel and a small subset of the core
-applications run with root permissions. Android does not prevent a user or
-application with root permissions from modifying the operating system, kernel,
-and any other application. In general, root has full access to all
-applications and all application data. Users that change the permissions on an
-Android device to grant root access to applications increase the security
-exposure to malicious applications and potential application flaws.
-
-The ability to modify an Android device they own is important to developers
-working with the Android platform. On many Android devices users have the
-ability to unlock the bootloader in order to allow installation of an alternate
-operating system. These alternate operating systems may allow an owner to gain
-root access for purposes of debugging applications and system components or to
-access features not presented to applications by Android APIs.
-
-On some devices, a person with physical control of a device and a USB cable is
-able to install a new operating system that provides root privileges to the
-user. To protect any existing user data from compromise the bootloader unlock
-mechanism requires that the bootloader erase any existing user data as part of
-the unlock step. Root access gained via exploiting a kernel bug or security
-hole can bypass this protection.
-
-Encrypting data with a key stored on-device does not protect the application
-data from root users. Applications can add a layer of data protection using
-encryption with a key stored off-device, such as on a server or a user
-password. This approach can provide temporary protection while the key is not
-present, but at some point the key must be provided to the application and it
-then becomes accessible to root users.
-
-A more robust approach to protecting data from root users is through the use of
-hardware solutions. OEMs may choose to implement hardware solutions that limit
-access to specific types of content such as DRM for video playback, or the
-NFC-related trusted storage for Google wallet.
-
-In the case of a lost or stolen device, full filesystem encryption on Android
-devices uses the device password to protect the encryption key, so modifying
-the bootloader or operating system is not sufficient to access user data
-without the user’s device password.
-
-#User Security Features
-
-##Filesystem Encryption
-
-Android 3.0 and later provides full filesystem encryption, so all user data can
-be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
-and ESSIV:SHA256. The encryption key is protected by AES128 using a key
-derived from the user password, preventing unauthorized access to stored data
-without the user device password. To provide resistance against systematic
-password guessing attacks (e.g. “rainbow tables” or brute force), the
-password is combined with a random salt and hashed repeatedly with SHA1 using
-the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
-key. To provide resistance against dictionary password guessing attacks,
-Android provides password complexity rules that can be set by the device
-administrator and enforced by the operating system. Filesystem encryption
-requires the use of a user password, pattern-based screen lock is not supported.
-
-More details on implementation of filesystem encryption are available at
-[https://source.android.com/tech/encryption/android_crypto_implementation.html](/
-tech/encryption/android_crypto_implementation.html)
-
-##Password Protection
-
-Android can be configured to verify a user-supplied password prior to providing
-access to a device. In addition to preventing unauthorized use of the device,
-this password protects the cryptographic key for full filesystem encryption.
-
-Use of a password and/or password complexity rules can be required by a device
-administrator.
-
-##Device Administration
-
-Android 2.2 and later provide the Android Device Administration API, which
-provides device administration features at the system level. For example, the
-built-in Android Email application uses the APIs to improve Exchange support.
-Through the Email application, Exchange administrators can enforce password
-policies — including alphanumeric passwords or numeric PINs — across
-devices. Administrators can also remotely wipe (that is, restore factory
-defaults on) lost or stolen handsets.
-
-In addition to use in applications included with the Android system, these APIs
-are available to third-party providers of Device Management solutions. Details
-on the API are provided here:
-[https://developer.android.com/guide/topics/admin/device-admin.html](https://devel
-oper.android.com/guide/topics/admin/device-admin.html).
-
-##Credential Storage
-
-By default, Android includes a set of predefined Certificate Authorities (CAs)
-that are trusted for operations such as establishing SSL connections within the
-browser. In Android 4.0 and later, users can disable preinstalled CAs within
-the system settings. Users can also add trusted CAs or certificates to the
-system by importing them from USB storage. Android 4.1 and later adds the
-ability for OEMs to add hardware-backed KeyChain storage which binds
-private keys to the device on which they are stored.
-
-##Virtual Private Network
-
-Android provides a built-in VPN client with support for PPTP, L2TP, and IPsec VPNs.
-In addition, Android 4.0 introduced the
-[VpnService](http://developer.android.com/reference/android/net/VpnService.html) class
-to support third-party VPN solutions. Android 4.2 introduced the ability for a
-user to configure the VPN as "always on" to indicate that applications can connect
-to the network only through the connected VPN.
-
-#Android Application Security
-
-##Elements of Applications
-
-Android provides an open source platform and application environment for mobile
-devices. The core operating system is based on the Linux kernel. Android
-applications are most often written in the Java programming language and run in
-the Dalvik virtual machine. However, applications can also be written in native
-code. Applications are installed from a single file with the .apk file
-extension.
-
-The main Android application building blocks are:
-
-+ **AndroidManifest.xml**: The
-[AndroidManifest.xml](https://developer.android.com/guide/topics/manifest/manifes
-t-intro.html) file is the control file that tells the system what to do with
-all the top-level components (specifically activities, services, broadcast
-receivers, and content providers described below) in an application. This also
-specifies which permissions are required.
-
-+ **Activities**: An
-[Activity](https://developer.android.com/guide/topics/fundamentals/activities.htm
-l) is, generally, the code for a single, user-focused task. It usually
-includes displaying a UI to the user, but it does not have to -- some
-Activities never display UIs. Typically, one of the application's Activities
-is the entry point to an application.
-
-+ **Services**: A
-[Service](https://developer.android.com/guide/topics/fundamentals/services.html)
-is a body of code that runs in the background. It can run in its own process,
-or in the context of another application's process. Other components "bind" to
-a Service and invoke methods on it via remote procedure calls. An example of a
-Service is a media player: even when the user quits the media-selection UI, the
-user probably still intends for music to keep playing. A Service keeps the
-music going even when the UI has completed.
-
-+ **Broadcast Receiver**: A
-[BroadcastReceiver](https://developer.android.com/reference/android/content/Broad
-castReceiver.html) is an object that is instantiated when an IPC mechanism
-known as an
-[Intent](https://developer.android.com/reference/android/content/Intent.html)
-is issued by the operating system or another application. An application may
-register a receiver for the low battery message, for example, and change its
-behavior based on that information.
-
-
-##The Android Permission Model: Accessing Protected APIs
-
-All applications on Android run in an Application Sandbox, described earlier in
-this document. By default, an Android application can only access a limited
-range of system resources. The system manages Android application access to
-resources that, if used incorrectly or maliciously, could adversely impact the
-user experience, the network, or data on the device.
-
-These restrictions are implemented in a variety of different forms. Some
-capabilities are restricted by an intentional lack of APIs to the sensitive
-functionality (e.g. there is no Android API for directly manipulating the SIM
-card). In some instances, separation of roles provides a security measure, as
-with the per-application isolation of storage. In other instances, the
-sensitive APIs are intended for use by trusted applications and protected
-through a security mechanism known as Permissions.
-
-These protected APIs include:
-
-+ Camera functions
-+ Location data (GPS)
-+ Bluetooth functions
-+ Telephony functions
-+ SMS/MMS functions
-+ Network/data connections
-
-These resources are only accessible through the operating system. To make use
-of the protected APIs on the device, an application must define the
-capabilities it needs in its manifest. When preparing to install an
-application, the system displays a dialog to the user that indicates the
-permissions requested and asks whether to continue the installation. If the
-user continues with the installation, the system accepts that the user has
-granted all of the requested permissions. The user can not grant or deny
-individual permissions -- the user must grant or deny all of the requested
-permissions as a block.
-
-Once granted, the permissions are applied to the application as long as it is
-installed. To avoid user confusion, the system does not notify the user again
-of the permissions granted to the application, and applications that are
-included in the core operating system or bundled by an OEM do not request
-permissions from the user. Permissions are removed if an application is
-uninstalled, so a subsequent re-installation will again result in display of
-permissions.
-
-Within the device settings, users are able to view permissions for applications
-they have previously installed. Users can also turn off some functionality
-globally when they choose, such as disabling GPS, radio, or wi-fi.
-
-In the event that an application attempts to use a protected feature which has
-not been declared in the application's manifest, the permission failure will
-typically result in a security exception being thrown back to the application.
-Protected API permission checks are enforced at the lowest possible level to
-prevent circumvention. An example of the user messaging when an application is
-installed while requesting access to protected APIs is shown in *Figure 2*.
-
-The system default permissions are described at
-[https://developer.android.com/reference/android/Manifest.permission.html](https://developer.android.com/reference/android/Manifest.permission.html).
-Applications may declare their own permissions for other applications to use.
-Such permissions are not listed in the above location.
-
-When defining a permission a protectionLevel attribute tells the system how the
-user is to be informed of applications requiring the permission, or who is
-allowed to hold a permission. Details on creating and using application
-specific permissions are described at
-[https://developer.android.com/guide/topics/security/security.html](https://develo
-per.android.com/guide/topics/security/security.html).
-
-There are some device capabilities, such as the ability to send SMS broadcast
-intents, that are not available to third-party applications, but that may be
-used by applications pre-installed by the OEM. These permissions use the
-signatureOrSystem permission.
-
-##How Users Understand Third-Party Applications
-
-Android strives to make it clear to users when they are interacting with
-third-party applications and inform the user of the capabilities those
-applications have. Prior to installation of any application, the user is shown
-a clear message about the different permissions the application is requesting.
-After install, the user is not prompted again to confirm any permissions.
-
-There are many reasons to show permissions immediately prior to installation
-time. This is when user is actively reviewing information about the
-application, developer, and functionality to determine whether it matches their
-needs and expectations. It is also important that they have not yet
-established a mental or financial commitment to the app, and can easily compare
-the application to other alternative applications.
-
-Some other platforms use a different approach to user notification, requesting
-permission at the start of each session or while applications are in use. The
-vision of Android is to have users switching seamlessly between applications at
-will. Providing confirmations each time would slow down the user and prevent
-Android from delivering a great user experience. Having the user review
-permissions at install time gives the user the option to not install the
-application if they feel uncomfortable.
-
-Also, many user interface studies have shown that over-prompting the user
-causes the user to start saying "OK" to any dialog that is shown. One of
-Android's security goals is to effectively convey important security
-information to the user, which cannot be done using dialogs that the user will
-be trained to ignore. By presenting the important information once, and only
-when it is important, the user is more likely to think about what they are
-agreeing to.
-
-Some platforms choose not to show any information at all about application
-functionality. That approach prevents users from easily understanding and
-discussing application capabilities. While it is not possible for all users to
-always make fully informed decisions, the Android permissions model makes
-information about applications easily accessible to a wide range of users. For
-example, unexpected permissions requests can prompt more sophisticated users to
-ask critical questions about application functionality and share their concerns
-in places such as [Google Play](htts://play.google.com) where they
-are visible to all users.
-
-<table>
-<tr>
-<td><strong>Permissions at Application Install -- Google Maps</strong></td>
-<td><strong>Permissions of an Installed Application -- gMail</strong></td>
-</tr>
-<tr>
-<td>
-<img alt="Permissions at Application Install -- Google Maps" width=250
-src="images/image_install.png"/>
-</td>
-<td>
-<img alt="Permissions of an Installed Application -- gMail" width=250
-src="images/image_gmail_installed.png"/>
-</td>
-</tr>
-</table>
-*Figure 2: Display of permissions for applications*
-
-##Interprocess Communication
-
-Processes can communicate using any of the traditional UNIX-type mechanisms.
-Examples include the filesystem, local sockets, or signals. However, the Linux
-permissions still apply.
-
-Android also provides new IPC mechanisms:
-
-+ **Binder**: A lightweight capability-based remote procedure call mechanism
-designed for high performance when performing in-process and cross-process
-calls. Binder is implemented using a custom Linux driver. See
-[https://developer.android.com/reference/android/os/Binder.html](https://developer
-.android.com/reference/android/os/Binder.html).
-
-+ **Services**: Services (discussed above) can provide interfaces directly
-accessible using binder.
-
-+ **Intents**: An Intent is a simple message object that represents an
-"intention" to do something. For example, if your application wants to display
-a web page, it expresses its "Intent" to view the URL by creating an Intent
-instance and handing it off to the system. The system locates some other piece
-of code (in this case, the Browser) that knows how to handle that Intent, and
-runs it. Intents can also be used to broadcast interesting events (such as a
-notification) system-wide. See
-[https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html).
-
-+ **ContentProviders**: A ContentProvider is a data storehouse that provides
-access to data on the device; the classic example is the ContentProvider that
-is used to access the user's list of contacts. An application can access data
-that other applications have exposed via a ContentProvider, and an application
-can also define its own ContentProviders to expose data of its own. See
-[https://developer.android.com/reference/android/content/ContentProvider.html](https://developer.android.com/reference/android/content/ContentProvider.html).
-
-While it is possible to implement IPC using other mechanisms such as network
-sockets or world-writable files, these are the recommended Android IPC
-frameworks. Android developers will be encouraged to use best practices around
-securing users' data and avoiding the introduction of security vulnerabilities.
-
-##Cost-Sensitive APIs
-
-A cost sensitive API is any function that might generate a cost for the user or
-the network. The Android platform has placed cost sensitive APIs in the list of
-protected APIs controlled by the OS. The user will have to grant explicit
-permission to third-party applications requesting use of cost sensitive APIs.
-These APIs include:
-
-+ Telephony
-+ SMS/MMS
-+ Network/Data
-+ In-App Billing
-+ NFC Access
-
-Android 4.2 adds further control on the use of SMS. Android will provide a
-notification if an application attempts to send SMS to a short code that uses
-premium services which might cause additional charges. The user can choose
-whether to allow the application to send the message or block it.
-
-##SIM Card Access
-
-Low level access to the SIM card is not available to third-party apps. The OS
-handles all communications with the SIM card including access to personal
-information (contacts) on the SIM card memory. Applications also cannot access
-AT commands, as these are managed exclusively by the Radio Interface Layer
-(RIL). The RIL provides no high level APIs for these commands.
-
-##Personal Information
-
-Android has placed APIs that provide access to user data into the set of
-protected APIs. With normal usage, Android devices will also accumulate user
-data within third-party applications installed by users. Applications that
-choose to share this information can use Android OS permission checks to
-protect the data from third-party applications.
-
-
-
-*Figure 3: Access to sensitive user data is only available through protected
-APIs*
-
-System content providers that are likely to contain personal or personally
-identifiable information such as contacts and calendar have been created with
-clearly identified permissions. This granularity provides the user with clear
-indication of the types of information that may be provided to the application.
- During installation, a third-party application may request permission to
-access these resources. If permission is granted, the application can be
-installed and will have access to the data requested at any time when it is
-installed.
-
-Any applications which collect personal information will, by default, have that
-data restricted only to the specific application. If an application chooses to
-make the data available to other applications though IPC, the application
-granting access can apply permissions to the IPC mechanism that are enforced by
-the operating system.
-
-##Sensitive Data Input Devices
-
-Android devices frequently provide sensitive data input devices that allow
-applications to interact with the surrounding environment, such as camera,
-microphone or GPS. For a third-party application to access these devices, it
-must first be explicitly provided access by the user through the use of Android
-OS Permissions. Upon installation, the installer will prompt the user
-requesting permission to the sensor by name.
-
-If an application wants to know the user's location, the application requires a
-permission to access the user's location. Upon installation, the installer will
-prompt the user asking if the application can access the user's location. At
-any time, if the user does not want any application to access their location,
-then the user can run the "Settings" application, go to "Location & Security",
-and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
-disable location based services for all applications on the user's device.
-
-##Device Metadata
-
-Android also strives to restrict access to data that is not intrinsically
-sensitive, but may indirectly reveal characteristics about the user, user
-preferences, and the manner in which they use a device.
-
-By default applications do not have access to operating system logs,
-browser history, phone number, or hardware / network identification
-information. If an application requests access to this information at install
-time, the installer will prompt the user asking if the application can access
-the information. If the user does not grant access, the application will not be
-installed.
-
-##Application Signing
-
-Code signing allows developers to identify the author of the application and to
-update their application without creating complicated interfaces and
-permissions. Every application that is run on the Android platform must be
-signed by the developer. Applications that attempt to install without being
-signed will rejected by either Google Play or the package installer on
-the Android device.
-
-On Google Play, application signing bridges the trust Google has with the
-developer and the trust the developer has with their application. Developers
-know their application is provided, unmodified to the Android device; and
-developers can be held accountable for behavior of their application.
-
-On Android, application signing is the first step to placing an application in
-its Application Sandbox. The signed application certificate defines which user
-id is associated with which application; different applications run under
-different user IDs. Application signing ensures that one application cannot
-access any other application except through well-defined IPC.
-
-When an application (APK file) is installed onto an Android device, the Package
-Manager verifies that the APK has been properly signed with the certificate
-included in that APK. If the certificate (or, more accurately, the public key
-in the certificate) matches the key used to sign any other APK on the device,
-the new APK has the option to specify in the manifest that it will share a UID
-with the other similarly-signed APKs.
-
-Applications can be signed by a third-party (OEM, operator, alternative market)
-or self-signed. Android provides code signing using self-signed certificates
-that developers can generate without external assistance or permission.
-Applications do not have to be signed by a central authority. Android currently
-does not perform CA verification for application certificates.
-
-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
-relationship with a shared Application Sandbox is allowed via the [shared UID
-feature](https://developer.android.com/guide/topics/manifest/manifest-element.htm
-l#uid) where two or more applications signed with same developer key can
-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.ht
-ml) 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
-interface for DRM plug-ins (agents) to handle rights management and decryption
-for various DRM schemes
-
-
-
-*Figure 4: Architecture of Digital Rights Management on Android platform*
-
-#Android Updates
-
-Android provides system updates for both security and feature related purposes.
-
-There are two ways to update the code on most Android devices: over-the-air
-(OTA updates) or side-loaded updates. OTA updates can be rolled out over a
-defined time period or be pushed to all devices at once, depending on how the
-OEM and/or carrier would like to push the updates. Side-loaded updates can be
-provided from a central location for users to download as a zip file to their
-local desktop machine or directly to their handset. Once the update is copied
-or downloaded to the SD card on the device, Android will recognize the update,
-verify its integrity and authenticity, and automatically update the device.
-
-If a dangerous vulnerability is discovered internally or responsibly reported
-to Google or the Android Open Source Project, the Android security team will
-start the following process.
-
-1. The Android team will notify companies who have signed NDAs regarding the
-problem and begin discussing the solution.
-2. The owners of code will begin the fix.
-3. The Android team will fix Android-related security issues.
-4. When a patch is available, the fix is provided to the NDA companies.
-5. The Android team will publish the patch in the Android Open Source Project
-6. OEM/carrier will push an update to customers.
-
-The NDA is required to ensure that the security issue does not become public
-prior to availabilty of a fix and put users at risk. Many OHA members run their
-own code on Android devices such as the bootloader, wifi drivers, and the
-radio. Once the Android Security team is notified of a security issue in this
-partner code, they will consult with OHA partners to quickly find a fix for the
-problem at hand and similar problems. However, the OHA member who wrote the
-faulty code is ultimately responsible for fixing the problem.
-
-If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
-posted to a public forum without warning), then Google and/or the Android Open
-Source Project will work as quickly as possible to create a patch. The patch
-will released to the public (and any partners) when the patch is tested and
-ready for use.
-
-At Google I/O 2011, many of the largest OHA partners committed to providing
-updates to devices for 18 months after initial shipment. This will provide
-users with access to the most recent Android features, as well as security
-updates.
-
-Any developer, Android user, or security researcher can notify the Android
-security team of potential security issues by sending email to
-security@android.com. If desired, communication can be encrypted using the
-Android security team PGP key available here:
-[https://developer.android.com/security_at_android_dot_com.txt](https://develope
-r.android.com/security_at_android_dot_com.txt).
-
-#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://develo
-per.android.com/guide/topics/security/security.html).
-
-A Security FAQ for developers is located here:
-[https://developer.android.com/resources/faq/security.html](https://developer.andr
-oid.com/resources/faq/security.html).
-
-A community resource for discussion about Android security exists here:
-[https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss](https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss).
-
diff --git a/src/tech/security/sidebar2.md b/src/tech/security/sidebar2.md
deleted file mode 100644
index a751c77..0000000
--- a/src/tech/security/sidebar2.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Security Topics #
-- [Security Overview](/tech/security/index.html)
-- [Android 4.2](/tech/security/android_4_2_security_enhancements.html)
-
-
diff --git a/src/tech/sidebar.md b/src/tech/sidebar.md
deleted file mode 100644
index c3701fd..0000000
--- a/src/tech/sidebar.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# 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)
diff --git a/src/tech/storage/index.md b/src/tech/storage/index.md
deleted file mode 100644
index 016cb6c..0000000
--- a/src/tech/storage/index.md
+++ /dev/null
@@ -1,132 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# External Storage Technical Information
-
-Android supports devices with external storage, which is defined to be a
-case-insensitive and permissionless filesystem. External storage can be
-provided by physical media (such as an SD card), or by an emulation layer backed
-by internal storage. Devices may contain multiple instances of external
-storage, but currently only the primary external storage is exposed to
-developers through API.
-
-## Device specific configuration
-
-External storage is managed by a combination of the `vold` init service and
-`MountService` system service.
-
-Mounting of physical external storage volumes is handled by `vold`, which
-performs staging operations to prepare the media before exposing it to apps.
-The device-specific `vold.fstab` configuration file defines mappings from sysfs
-devices to filesystem mount points, and each line follows this format:
-
- dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]
-
-* `label`: Label for the volume.
-* `mount_point`: Filesystem path where the volume should be mounted.
-* `partition`: Partition number (1 based), or 'auto' for first usable partition.
-* `sysfs_path`: One or more sysfs paths to devices that can provide this mount
-point. Separated by spaces, and each must start with `/`.
-* `flags`: Optional comma separated list of flags, must not contain `/`.
-Possible values include `nonremovable` and `encryptable`.
-
-External storage interactions at and above the framework level are handled
-through `MountService`. The device-specific `storage_list.xml` configuration
-file, typically provided through a `frameworks/base` overlay, defines the
-attributes and constraints of storage devices. The `<StorageList>` element
-contains one or more `<storage>` elements, exactly one of which should be marked
-primary. `<storage>` attributes include:
-
-* `mountPoint`: filesystem path of this mount.
-* `storageDescription`: string resource that describes this mount.
-* `primary`: true if this mount is the primary external storage.
-* `removable`: true if this mount has removable media, such as a physical SD
-card.
-* `emulated`: true if this mount is emulated and is backed by internal storage,
-possibly using a FUSE daemon.
-* `mtp-reserve`: number of MB of storage that MTP should reserve for free
-storage. Only used when mount is marked as emulated.
-* `allowMassStorage`: true if this mount can be shared via USB mass storage.
-* `maxFileSize`: maximum file size in MB.
-
-Devices may provide external storage by emulating a case-insensitive,
-permissionless filesystem backed by internal storage. One possible
-implementation is provided by the FUSE daemon in `system/core/sdcard`, which can
-be added as a device-specific `init.rc` service:
-
- # virtual sdcard daemon running as media_rw (1023)
- service sdcard /system/bin/sdcard <source_path> <dest_path> 1023 1023
- class late_start
-
-Where `source_path` is the backing internal storage and `dest_path` is the
-target mount point.
-
-When configuring a device-specific `init.rc` script, the `EXTERNAL_STORAGE`
-environment variable must be defined as the path to the primary external
-storage. The `/sdcard` path must also resolve to the same location, possibly
-through a symlink. If a device adjusts the location of external storage between
-platform updates, symlinks should be created so that old paths continue working.
-
-As an example, here’s the storage configuration for Xoom, which uses a FUSE
-daemon to provide primary external storage, and includes a physical SD card as
-secondary external storage:
-
-* [vold.fstab](https://android.googlesource.com/device/moto/wingray/+/master/vold.fstab)
-* [storage_list.xml](https://android.googlesource.com/device/moto/wingray/+/master/overlay/frameworks/base/core/res/res/xml/storage_list.xml)
-
-Access to external storage is protected by various Android permissions.
-Starting in Android 1.0, write access is protected with the
-`WRITE_EXTERNAL_STORAGE` permission, implemented using the `sdcard_rw` GID.
-Starting in Android 4.1, read access is protected with the new
-`READ_EXTERNAL_STORAGE` permission, implemented using the `sdcard_r` GID. To
-implement the read permission, a new top-level `/storage` directory was created
-such that processes must hold the `sdcard_r` GID to traverse into it.
-
-Since external storage offers no support for traditional POSIX filesystem
-permissions, system code should not store sensitive data on external storage.
-Specifically, configuration and log files should only be stored on internal
-storage where they can be effectively protected.
-
-## Multi-user external storage
-
-Starting in Android 4.2, devices can support multiple users, and external
-storage must meet the following constraints:
-
-* Each user must have their own isolated primary external storage, and must not
-have access to the primary external storage of other users.
-* The `/sdcard` path must resolve to the correct user-specific primary external
-storage based on the user a process is running as.
-* Storage for large OBB files in the `Android/obb` directory may be shared
-between multiple users as an optimization.
-* Secondary external storage must not be writable by apps.
-
-The default platform implementation of this feature leverages Linux kernel
-namespaces to create isolated mount tables for each Zygote-forked process, and
-then uses bind mounts to offer the correct user-specific primary external
-storage into that private namespace.
-
-At boot, the system mounts a single emulated external storage FUSE daemon at
-`EMULATED_STORAGE_SOURCE`, which is hidden from apps. After the Zygote forks,
-it bind mounts the appropriate user-specific subdirectory from under the FUSE
-daemon to `EMULATED_STORAGE_TARGET` so that external storage paths resolve
-correctly for the app. Because an app lacks accessible mount points for other
-users’ storage, they can only access storage for the user it was started as.
-
-This implementation also uses the shared subtree kernel feature to propagate
-mount events from the default root namespace into app namespaces, which ensures
-that features like ASEC containers and OBB mounting continue working correctly.
-It does this by mounting the rootfs as shared, and then remounting it as slave
-after each Zygote namespace is created.
diff --git a/src/tech/test_infra/index.md b/src/tech/test_infra/index.md
deleted file mode 100644
index 39ed155..0000000
--- a/src/tech/test_infra/index.md
+++ /dev/null
@@ -1,20 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Test Infrastructure Technical Information #
-
-We make tests go vroom.
-
diff --git a/src/tech/test_infra/sidebar2.md b/src/tech/test_infra/sidebar2.md
deleted file mode 100644
index 1ddf988..0000000
--- a/src/tech/test_infra/sidebar2.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Infrastructure Components #
-
-- [Trade Federation](/tech/test_infra/tradefed/index.html)
-- [Notifilter](/tech/test_infra/notifilter.html)
-
diff --git a/src/tech/test_infra/tradefed/commandfile_format.md b/src/tech/test_infra/tradefed/commandfile_format.md
deleted file mode 100644
index 88c0a74..0000000
--- a/src/tech/test_infra/tradefed/commandfile_format.md
+++ /dev/null
@@ -1,133 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Command File Format
-
-A command file allows one to specify sets of TF commands (that is, configurations with their
-associated arguments) to be specified all at once. Further, the format used in the command file
-supports simple macro expansions, which makes it very useful without being unwieldy. You can see a
-relatively involved example at the bottom of the page, as well as more gradual documentation
-immediately below.
-
-
-## Lines
-
-The format is line-based.
-
-* Each output line will be considered as the arguments for a single Configuration for Trade
- Federation to run.
-* Each input line will turn into one or more output lines.
-
-In essence, the command file format combinatorially creates a sequence of Configuration specifications that it passes to Trade Federation to run. Blank lines are ignored. Comments are delimited by the "#" character and may only be preceded by whitespace.
-
-
-## Macros
-
-The specific syntax for defining a macro is discussed below in the Short Macro and Long Macro sections. The following rules apply to all macros
-
-* The name of a macro must begin with an alpha character. Each subsequent character may be any
- alphanumeric, an underscore, or a hyphen.
-* A macro with name "macro_name" is invoked by adding macro_name() as an argument on some subsequent
- line.
-* The macro format does not support passing arguments to macros. It allows only concatenation.
-* A macro's expansion may contain invocations of other macros. Technically, a macro's expansion may
- contain invocations of itself, but in that case, the macro will never fully expand.
-* The parser currently has a hard limit of 10 iterations of expansion. This will be made
- configurable at some point.
-* During a single iteration of expansion:
- * All short macro invocations on a line will be expanded a single level — macro invocations
- embedded within the first-level expansions will not be expanded yet
- * Only one long macro invocation on a line will be expanded. This will be the left-most long
- macro invocation.
-
-
-## Short Macros
-
-A short macro can be defined with the syntax:
-
- MACRO macro_name = this is the macro expansion
-
-The macro expansion terminates at the end of the line. For multi-line expansion, see Long Macros
-below.
-
-### Short Macro Expansion
-
-* `a macro_name() invocation`<br />
- will be replaced by<br />
- `a this is the macro expansion invocation`
-* `three macro_name() A macro_name() B macro_name()`<br />
- will be replaced by (all during the first iteration)<br />
- `three this is the macro expansion A this is the macro expansion B this is the macro expansion`
-
-
-## Long Macros
-
-A long macro can be defined with the syntax:
-
- LONG MACRO macro_name
- expansion line 1
- expansion line 2
- expansion line 3
- END MACRO
-
-The macro is then invoked with th enormal `macro_name()` syntax. Leading whitespace/indentation
-will be ignored.
-
-### Long Macro Expansion
-
-The output of a single input line will include one line for each combination of macro expansions on
-that line. That is, the number of output lines is multiplicatively related to the number of macro
-expansions on that line:
-
-* Only a single long macro invocation per line will be expanded during a single iteration. This
- means that a line may only contain 10 long macro invocations to stay under the iteration count
- limit.
-* A single invocation of a long macro on a single line will cause that line to expand to the number
- of lines of the long macro's expansion. On each expanded line, the invocation will be replaced
- by the corresponding line of the macro's expansion.
-
-* Example 1:
-
- a macro_name() invocation
-
- will be replaced by (in a single iteration)
-
- a expansion line 1 invocation
- a expansion line 2 invocation
- a expansion line 3 invocation
-
-* Example 2:
-
- alpha macro_name() beta macro_name()
-
- will be replaced by (during the first iteration)
-
- alpha expansion line 1 beta macro_name()
- alpha expansion line 2 beta macro_name()
- alpha expansion line 3 beta macro_name()
-
- which will be replaced by (during the second iteration)
-
- alpha expansion line 1 beta expansion line 1
- alpha expansion line 1 beta expansion line 2
- alpha expansion line 1 beta expansion line 3
- alpha expansion line 2 beta expansion line 1
- alpha expansion line 2 beta expansion line 2
- alpha expansion line 2 beta expansion line 3
- alpha expansion line 3 beta expansion line 1
- alpha expansion line 3 beta expansion line 2
- alpha expansion line 3 beta expansion line 3
-
diff --git a/src/tech/test_infra/tradefed/getting_started.md b/src/tech/test_infra/tradefed/getting_started.md
deleted file mode 100644
index 4735aa5..0000000
--- a/src/tech/test_infra/tradefed/getting_started.md
+++ /dev/null
@@ -1,249 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Getting Started
-
-## Using the console
-
-TF is based around an interactive console. You can fire up the console by going to the
-`tools/tradefederation/` directory and running
-
- $ ./tradefed.sh
-
-You should end up at a `tf >` prompt.
-
-The console is self-documenting. Try entering "help"
-
- tf >help
- Enter 'q' or 'exit' to exit
- Enter 'kill' to attempt to forcibly exit, by shutting down adb
-
- Enter 'help list' for help with 'list' commands
- [...]
-
-As the help text suggests, the help menus are organized hierarchically
-
- tf >help list
- l(?:ist)? help:
- i[nvocations] List all invocation threads
- d[evices] List all detected or known devices
- [...]
-
-The majority of commands have a convenient short form, which the help text displays. The
-`l(?:ist)?` is a regular expression. As an example, here are the four equivalent ways to list
-invocations:
-* `list invocations`
-* `list i`
-* `l invocations`
-* `l i`
-
-
-## Running a config/command
-
-This is documented by the `help run` command in the console.
-
-As a reminder, a command is a config along with all of its command-line arguments. A command *must*
-begin with the name of the respective config.
-
-As a quick example, you could run the calculator unit tests like so:
-
- $./tradefed.sh
- tf >run instrument --package com.android.calculator2.tests
-
-As a shortcut, if you specify any arguments to `tradefed.sh`, it will attempt to execute them as if
-they were typed on the commandline. So the short version of the above would be
-
- $./tradefed.sh run instrument --package com.android.calculator2.tests
-
-In both of these cases, the name of the config is "instrument", and
-"--class com.android.calculator2.tests" is a command-line argument. The command that is being run
-is "instrument --class com.android.calculator2.tests".
-
-TF can run both configs that are compiled in (such as the "instrument" config above), as well as
-configs that exist as xml files on the local filesystem. You can see a list of compiled-in configs
-with the `list configs` console command. Furthermore, you can investigate any config (compiled-in
-or local) by passing the "--help" or "--help-all" command-line arguments. The "--help" argument
-will only show "important" arguments, and "--help-all" will show all arguments, regardless of
-whether they've been marked as "important" or not. To take the final step, you can tell TF to print
-the contents of any config (compiled-in or local) with the `dump config <configname>` console
-command.
-
-### So, let's say you want to run the calculator instrumentation tests, but don't know where to start.
-
-You could try something like this sequence of steps. First, look for a config that looks like it
-might do what you want:
-
- tf >list configs
- Use 'run command --help <configuration_name>' to get list of options for a configuration
- Use 'dump config <configuration_name>' to display the configuration's XML content.
-
- Available configurations include:
- [...]
- instrument: Runs a single Android instrumentation test on an existing device
- [...]
-
-Now that you've found something reasonable-looking, see what options it takes. The `list configs` output suggests trying `run command instrument --help`
-
- tf >run command --help instrument
- 'instrument' configuration: Runs a single Android instrumentation test on an existing device
-
- Printing help for only the important options. To see help for all options, use the --help-all flag
- [...]
- 'instrumentation' test options:
- -p, --package The manifest package name of the Android test application to run.
-
-As the message suggests, if you need more options, use the "--help-all" flag instead of "--help". In this case, we've got all we need. You could figure out the package by checking with `runtest`, or reading testdefs.xml directly. We use `runtest -n` to simply show what would be run without actually running it:
-
- $runtest -n calculator
- adb root
- ONE_SHOT_MAKEFILE="packages/apps/Calculator/Android.mk" make -j4 -C "/srv/xsdg/master2" files
- adb sync
- adb shell am instrument -w com.android.calculator2.tests/android.test.InstrumentationTestRunner
-
-The argument to `am instrument` that comes before the slash is the manifest package. `android.test.InstrumentationTestRunner` is the default runner, so no need to set it if that's the
-right one. Otherwise, using "--help-all" will tell you about the "--runner" argument, which you can
-use to specify an alternate runner. Ok, so at this point, we've got the following command, which
-you'll recognize from above
-
- tf >run instrument --package com.android.calculator2.tests
-
-
-## Interacting with a device
-
-### Generic device behavior in TF
-
-The running version of a command is called in `invocation`. First and foremost, every invocation
-requires a device before it can run. In addition to physical Android devices, TF can run tests with
-a mock device (by specifying the "-n" argument for the command), or with the Android emulator (by
-specifying the "-e" argument").
-
-The primary console command to figure out what devices are up to is `list devices`:
-
- $./tradefed.sh
- 06-07 17:03:22 I/: Detected new device 016B756E03018007
- 06-07 17:03:22 I/: Detected new device 1700614743c14397
- 06-07 17:03:22 I/: Detected new device 3531C342606300EC
- tf >l d
- Serial State Product Variant Build Battery
- 016B756E03018007 Available tuna toro MASTER 100
- 1700614743c14397 Available stingray stingray MASTER 100
- 3531C342606300EC Available herring crespo4g MASTER 92
-
-As far as the invocations are concerned, there are three device states: available, unavailable, and
-allocated. An `Available` device is ready to be allocated for an invocation. An `Unavailable`
-device is not ready for allocation, for any of a variety of reasons — TF may have deemed to the
-device as unstable, the device may be critically low on storage, or something else may be amiss.
-Finally, an `Allocated` device is a device that is already being used by an invocation.
-
-When you start TF, all detected physical devices will be checked for responsiveness with a simple
-shell command. If the command completes successfully, the device will be listed as Available. If
-the command fails, the device state will be shown as Unavailable. Thereafter, a device will typically bounce between the Available and Allocated states as invocation requirements dictate.
-
-Finally, once invocations are already underway, you can see what's going on with the `list
-invocations` command
-
- tf >run instrument --package com.android.calculator2.tests
- 06-07 17:18:31 I/TestInvocation: Starting invocation for 'stub' on build '0' on device 1700614743c14397
- [...]
- tf >l d
- Serial State Product Variant Build Battery
- 1700614743c14397 Allocated stingray stingray MASTER 100
- 3531C342606300EC Available herring crespo4g JRN11 93
- 016B756E03018007 Available tuna toro MASTER 100
-
- tf >l i
- Command Id Exec Time Device State
- 1 0m:02 1700614743c14397 running stub on build 0
-
-
-### Running invocations on specific devices
-
-TF supports a number of filtering mechanisms for specifying which device or devices to use for a
-particular invocation. Since the filtering mechanisms are run before a command turns into an
-invocation, you can find all of the filtering options in the help for any config:
-
-tf >run instrument --help-all
-[...]
- device_requirements options:
- -s, --serial run this test on a specific device with given serial number(s).
- --exclude-serial run this test on any device except those with this serial number(s).
- --product-type run this test on device with this product type(s). May also filter by variant using product:variant.
- --property run this test on device with this property value. Expected format <propertyname>=<propertyvalue>.
- -e, --[no-]emulator force this test to run on emulator. Default: false.
- -d, --[no-]device force this test to run on a physical device, not an emulator. Default: false.
- --[no-]new-emulator allocate a placeholder emulator. Should be used when config intends to launch an emulator Default: false.
- -n, --[no-]null-device
- do not allocate a device for this test. Default: false.
- --min-battery only run this test on a device whose battery level is at least the given amount. Scale: 0-100
- --max-battery only run this test on a device whose battery level is strictly less than the given amount. Scale: 0-100
-[...]
-
-The built-in help should be pretty self-explanatory. All of the filtering options excluding "-n",
-"-e", and "-d" may be specified as many times as needed. So, for instance, to run an invocation
-using any Verizon Galaxy Nexus, you could do the following:
-
- tf >run instrument --package com.android.calculator2.tests --product-type tuna:toro
-
-As another example, to run on a GSM device with a SIM, you could do the following:
-
- tf >run instrument --package com.android.calculator2.tests --property gsm.sim.state=READY
-
-The filtering works by exclusion from the pool of Available devices, so the "--serial" option simply
-excludes devices that aren't in the list of required serials, and --exclude-serial excludes devices
-that *are* in its list. As such, an argument like --exclude-serial XXX --serial XXX will simply
-make the respective command un-runnable — it will never match any device, since all devices are
-excluded.
-
-
-## Logging
-
-There are a few different aspects to logging in TF. First and foremost, TF has a built-in logging
-infrastructure that's based on DDMLib's Log class. For the common case, where the log tag is just
-the classname of the current class, you can use our CLog convenience shim. In short, if you might
-have originally done this:
-
- class ClassName {
- private static final LOG_TAG = "ClassName";
- [...]
- Log.v(LOG_TAG, "This is a simple verbose log message");
- Log.w(LOG_TAG, String.format("This warning message brought to you by the number %d", 17));
-
-You can now accomplish the same thing with the shim like this:
-
- class ClassName {
- [...]
- CLog.v("This is a simple verbose log message");
- CLog.w("This warning message brought to you by the number %d", 17);
-
-Each Invocation has its own ThreadGroup. Any host-side logging that happens inside of that thread
-group is associated with the Invocation, and will be reported as that invocation's "host_log" after
-the Invocation completes.
-
-Device logging is performed as part of TradeFed's device wrapper. We keep a buffer of up to 20 MB
-that captures log data as the device churns it out. In particular, we are not limited by the size
-of the on-device logcat buffer.
-
-The next important piece is the ITestInvocationListener. This is one of the components of an
-Invocation that handles results reporting. Each reporter has the option to implement the #testLog
-method, which will be used to pass logfiles to that result reporter. Among the files that are
-passed by TF itself will be the aforementioned host_log, as well as the device logcat for the device
-associated with the Invocation.
-
-<!--
-FIXME: discuss test result reporting, retrieving builds, doing things continuously, target prep and
-FIXME: flashing builds, extending tradefed (like CTS).
--->
-
diff --git a/src/tech/test_infra/tradefed/index.md b/src/tech/test_infra/tradefed/index.md
deleted file mode 100644
index ef7ab7f..0000000
--- a/src/tech/test_infra/tradefed/index.md
+++ /dev/null
@@ -1,55 +0,0 @@
-<!--
- 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.
--->
-
-# Trade Federation Overview #
-
-TradeFederation (tradefed or TF for short) is a continuous test framework designed for running tests
-on Android devices. Its a Java application which runs on a host computer, and communicates to one or
-more Android devices using ddmlib (the library behind DDMS) over adb.
-
-## Features
-
-- modular, flexible design
-- has built in support for running many different types of Android tests: instrumentation, native/gtest, host-based JUnit, etc
-- provides reliability and recovery mechanism on top of adb
-- supports scheduling and running tests on multiple devices in parallel
-
-## Fundamentals
-The lifecycle of a test executed using TradeFederation is composed of four separate stages, designed
-around formally defined interfaces.
-
-- [Build provider](bp.html): Provides a build to test, downloading appropriate files if necessary
-- [Target preparer](tp.html): Prepares the test environment, e.g. software installation and setup
-- [Test](test.html): Executes test(s) and gathers test results
-- [Result reporter](result.html): Listens for test results, usually for the purpose of forwarding
- test results to a repository
-
-The fundamental entity in TradeFederation is a Configuration. A Configuration is an XML file that
-declares the lifecycle components of a test.
-
-This separation of the test's lifecycle is intended to allow for reuse. Using this design, you can
-create a Test, and then different Configurations to run it in different environments. For example,
-you could create a Configuration that will run a test on your local machine, and dump the result to
-stdout. You could then create a second Configuration that would execute that same test, but use a
-different Result reporter to store the test results in a database.
-
-### Additional components of a configuration
-
-- [Device recovery](recovery.html): mechanism to recover device communication if lost
-- [Logger](logger.html): collects tradefed logging data
-
-A complete TradeFederation test execution, across its entire lifecycle, is referred to as an
-Invocation.
diff --git a/src/tech/test_infra/tradefed/sidebar3.md b/src/tech/test_infra/tradefed/sidebar3.md
deleted file mode 100644
index 2aa2b1d..0000000
--- a/src/tech/test_infra/tradefed/sidebar3.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Trade Federation Docs #
-
-- [Getting Started](getting_started.html)
-- [Tutorial](tutorial.html)
-- [Command Files](commandfile_format.html)
diff --git a/src/tech/test_infra/tradefed/tutorial.md b/src/tech/test_infra/tradefed/tutorial.md
deleted file mode 100644
index e9b5e5f..0000000
--- a/src/tech/test_infra/tradefed/tutorial.md
+++ /dev/null
@@ -1,424 +0,0 @@
-<!--
- Copyright 2012 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.
--->
-
-# Tutorial
-
-This tutorial guides you through the construction of a "hello world" Trade Federation test
-configuration, and gives you a hands-on introduction to the Trade Federation framework. Starting
-from the Tf development environment, it guides you through the process of creating a simple Trade
-Federation config and gradually adding more features to it.
-
-The tutorial presents the TF test development process as a set of exercises, each consisting of
-several steps. The exercises demonstrate how to gradually build and refine your configuration, and
-provide all the sample code you need to complete the test configuration.
-
-When you are finished with the tutorial, you will have created a functioning TF configuration and
-will have learned many of the most important concepts in the TF framework.
-
-
-## Set up TradeFederation development environment
-
-See (FIXME: link) for how to setup the development environment. The rest of this tutorial assumes you have a shell open that has been initialized to the TradeFederation environment.
-
-For simplicity, this tutorial will illustrate adding a configuration and its classes to the TradeFederation framework core library. Later tutorials/documentation will show how to create your own library that extends TradeFederation.
-
-
-## Creating a test class
-
-Lets create a hello world test that just dumps a message to stdout. A TradeFederation test must
-implement the (FIXME: link) IRemoteTest interface.
-
-Here's an implementation for the HelloWorldTest:
-
- package com.android.tradefed.example;
-
- import com.android.tradefed.device.DeviceNotAvailableException;
- import com.android.tradefed.result.ITestInvocationListener;
- import com.android.tradefed.testtype.IRemoteTest;
-
-
- public class HelloWorldTest implements IRemoteTest {
- @Override
- public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
- System.out.println("Hello, TF World!");
- }
- }
-
-FIXME: prod-tests
-Save this sample code to
-`<git home>/tools/tradefederation/prod-tests/src/com/android/tradefed/example/HelloWorldTest.java`
-and rebuild tradefed from your shell:
-
- m -j6
-
-If the build does not succeed, please consult the (FIXME: link)Development Environment page to
-ensure you did not miss any steps.
-
-
-## Creating a configuration
-
-Trade Federation tests are defined in a "Configuration". A Configuration is an XML file that
-instructs tradefed which test (or set of tests) to run.
-
-Lets create a new Configuration for our HelloWorldTest.
-
- <configuration description="Runs the hello world test">
- <test class="com.android.tradefed.example.HelloWorldTest" />
- </configuration>
-
-TF will parse the Configuration XML file, load the specified class using reflection, instantiate it,
-cast it to a IRemoteTest, and call its 'run' method.
-
-Note that we've specified the full class name of the HelloWorldTest. Save this data to a
-`helloworld.xml` file anywhere on your local filesystem (eg `/tmp/helloworld.xml`).
-
-
-## Running the configuration
-
-From your shell, launch the tradefed console
-
- $ ./tradefed.sh
-
-Ensure a device is connected to the host machine that is visible to tradefed
-
- tf> list devices
-
-Configurations can be run using the `run <config>` console command. Try this now
-
-FIXME: redo this
-
- tf> run /tmp/helloworld.xml
- 05-12 13:19:36 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
- Hello, TF World!
-
-You should see "Hello, TF World!" outputted on the terminal.
-
-
-## Adding the configuration to the classpath
-FIXME: prod-tests
-For convenience of deployment, you can also bundle configuration files into the TradeFederation jars
-themselves. Tradefed will automatically recognize all configurations placed in 'config' folders on
-the classpath.
-
-Lets illustrate this now by moving the helloworld.xml into the tradefed core library.
-
-Move the `helloworld.xml` file into
-`<git root>/tools/tradefederation/prod-tests/res/config/example/helloworld.xml`.
-
-Rebuild tradefed, and restart the tradefed console.
-
-Ask tradefed to display the list of configurations on the classpath:
-
- tf> list configs
- […]
- example/helloworld: Runs the hello world test
-
-You can now run the helloworld config via the following command
-
- tf >run example/helloworld
- 05-12 13:21:21 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
- Hello, TF World!
-
-
-## Interacting with a device
-
-So far our hello world test isn't doing anything interesting. Tradefed is intended to run tests using Android devices, so lets add an Android device to the test.
-
-Tests can get a reference to an Android device by implementing the IDeviceTest interface.
-
-Here's a sample implementation of what this looks like:
-
- public class HelloWorldTest implements IRemoteTest, IDeviceTest {
- private ITestDevice mDevice;
- @Override
- public void setDevice(ITestDevice device) {
- mDevice = device;
- }
-
- @Override
- public ITestDevice getDevice() {
- return mDevice;
- }
- …
- }
-
-The TradeFederation framework will inject the ITestDevice reference into your test via the
-IDeviceTest#setDevice method, before the IRemoteTest#run method is called.
-
-Lets add an additional print message to the HelloWorldTest displaying the serial number of the
-device.
-
- @Override
- public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
- System.out.println("Hello, TF World! I have a device " + getDevice().getSerialNumber());
- }
-
-Now rebuild tradefed, and do (FIXME: update)
-
- $ tradefed.sh
- tf> list devices
- Available devices: [30315E38655500EC]
- …
-
-Take note of the serial number listed in Available devices above. That is the device that should be allocated to HelloWorld.
-
- tf >run example/helloworld
- 05-12 13:26:18 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
- Hello world, TF! I have a device 30315E38655500EC
-
-You should see the new print message displaying the serial number of the device.
-
-
-## Sending test results
-
-IRemoteTests report results by calling methods on the ITestInvocationListener instance provided to
-their `#run` method.
-
-The TradeFederation framework is responsible for reporting the start and end of an Invocation (via
-the ITestInvocationListener#invocationStarted and ITestInvocationListener#invocationEnded methods
-respectively).
-
-A `test run` is a logical collection of tests. To report test results, IRemoteTests are responsible
-for reporting the start of a test run, the start and end of each test, and the end of the test run.
-
-Here's what the HelloWorldTest implementation looks like with a single failed test result.
-
- @SuppressWarnings("unchecked")
- @Override
- public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
- System.out.println("Hello, TF World! I have a device " + getDevice().getSerialNumber());
-
- TestIdentifier testId = new TestIdentifier("com.example.MyTestClassName", "sampleTest");
- listener.testRunStarted("helloworldrun", 1);
- listener.testStarted(testId);
- listener.testFailed(TestFailure.FAILURE, testId, "oh noes, test failed");
- listener.testEnded(testId, Collections.EMPTY_MAP);
- listener.testRunEnded(0, Collections.EMPTY_MAP);
- }
-
-Note that TradeFederation also includes several IRemoteTest implementations that you can reuse
-instead of writing your own from scratch. (such as InstrumentationTest, which can run an Android
-application's tests remotely on an Android device, parse the results, and forward them to the
-ITestInvocationListener). See the Test Types documentation for more details.
-
-
-## Storing test results
-
-By default, a TradeFederation configuration will use the TextResultReporter as the test listener
-implementation for the configuration. TextResultReporter will dump the results of an invocation to
-stdout. To illustrate, try running the hello-world config from previous section now:
-
- $ ./tradefed.sh
- tf >run example/helloworld
- 05-16 20:03:15 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
- Hello world, TF! I have a device 30315E38655500EC
- 05-16 20:03:15 I/InvocationToJUnitResultForwarder: run helloworldrun started: 1 tests
- Test FAILURE: com.example.MyTestClassName#sampleTest
- stack: oh noes, test failed
- 05-16 20:03:15 I/InvocationToJUnitResultForwarder: run ended 0 ms
-
-If you want to store the results of an invocation elsewhere, say to a file, you would need to
-specify a custom "result_reporter" in your configuration, that specifies the custom
-ITestInvocationListener class you want to use.
-
-The TradeFederation framework includes a result_reporter (XmlResultReporter) that will write test
-results to an XML file, in a format similar to the ant JUnit XML writer.
-
-Lets specify the result_reporter in the configuration now. Edit the
-`tools/tradefederation/res/config/example/helloworld.xml` like this:
-
- <configuration description="Runs the hello world test">
- <test class="com.android.tradefed.example.HelloWorldTest" />
- <result_reporter class="com.android.tradefed.result.XmlResultReporter" />
- </configuration>
-
-Now rebuild tradefed and re-run the hello world sample:
-FIXME: paths
-
- tf >run example/helloworld
- 05-16 21:07:07 I/TestInvocation: Starting invocation for target stub on build 0 on device 30315E38655500EC
- Hello world, TF! I have a device 30315E38655500EC
- 05-16 21:07:07 I/XmlResultReporter: Saved device_logcat log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/device_logcat_6999997036887173857.txt
- 05-16 21:07:07 I/XmlResultReporter: Saved host_log log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/host_log_6307746032218561704.txt
- 05-16 21:07:07 I/XmlResultReporter: XML test result file generated at /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_2991649128735283633/test_result_536358148261684076.xml. Total tests 1, Failed 1, Error 0
-
-Notice the log message stating an XML file has been generated. The generated file should look like this:
-
- <?xml version='1.0' encoding='UTF-8' ?>
- <testsuite name="stub" tests="1" failures="1" errors="0" time="9" timestamp="2011-05-17T04:07:07" hostname="localhost">
- <properties />
- <testcase name="sampleTest" classname="com.example.MyTestClassName" time="0">
- <failure>oh noes, test failed
- </failure>
- </testcase>
- </testsuite>
-
-Note that you can write your own custom result_reporter. It just needs to implement the
-ITestInvocationListener interface.
-
-Also note that Tradefed supports multiple result_reporters, meaning that you can send test results
-to multiple independent destinations. Just specify multiple <result_reporter> tags in your config to
-do this.
-
-
-## Logging
-
-TradeFederation includes two logging facilities:
-
-1. ability to capture logs from the device (aka device logcat)
-2. ability to record logs from the TradeFederation framework running on the host machine (aka the
- host log)
-
-Lets focus on 2 for now. Trade Federation's host logs are reported using the CLog wrapper for the
-ddmlib Log class.
-
-Lets convert the previous System.out.println call in HelloWorldTest to a CLog call:
-
- @Override
- public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
- CLog.i("Hello world, TF! I have a device " + getDevice().getSerialNumber());
-
-Now rebuild and rerun. You should see the log message on stdout.
-
- tf> run example/helloworld
- …
- 05-16 21:30:46 I/HelloWorldTest: Hello world, TF! I have a device 30315E38655500EC
- …
-
-By default, TradeFederation will output host log messages to stdout. TradeFederation also includes a
-log implementation that will write messages to a file: FileLogger. To add file logging, add a
-'logger' tag to the configuration xml, specifying the full class name of FileLogger.
-
- <configuration description="Runs the hello world test">
- <test class="com.android.tradefed.example.HelloWorldTest" />
- <result_reporter class="com.android.tradefed.result.XmlResultReporter" />
- <logger class="com.android.tradefed.log.FileLogger" />
- </configuration>
-
-Now rebuild and run the helloworld example again.
-
- tf >run example/helloworld
- …
- 05-16 21:38:21 I/XmlResultReporter: Saved device_logcat log to /var/folders/++/++2Pz+++6+0++4RjPqRgNE+-4zk/-Tmp-/0/inv_6390011618174565918/device_logcat_1302097394309452308.txt
- 05-16 21:38:21 I/XmlResultReporter: Saved host_log log to /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt
- …
-
-Note the log message indicating the path of the host log. View the contents of that file, and you
-should see your HelloWorldTest log message
-
- $ more /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt
- …
- 05-16 21:38:21 I/HelloWorldTest: Hello world, TF! I have a device 30315E38655500EC
-
-The TradeFederation framework will also automatically capture the logcat from the allocated device,
-and send it the the result_reporter for processing. XmlResultReporter will save the captured device
-logcat as a file.
-
-
-## Command line options
-Objects loaded from a TradeFederation Configuration (aka "Configuration objects") also have the
-ability to receive data from command line arguments.
-
-This is accomplished via the `@Option` annotation. To participate, a Configuration object class
-would apply the `@Option` annotation to a member field, and provide it a unique name. This would
-allow that member field's value to be populated via a command line option, and would also
-automatically add that option to the configuration help system (Note: not all field types are
-supported: see the OptionSetter javadoc for a description of supported types).
-
-Lets add an Option to the HelloWorldTest.
-
- @Option(name="my_option",
- shortName='m',
- description="this is the option's help text",
- // always display this option in the default help text
- importance=Importance.ALWAYS)
- private String mMyOption = "thisisthedefault";
-
-And lets add a log message to display the value of the option in HelloWorldTest, so we can
-demonstrate that it was received correctly.
-
- @SuppressWarnings("unchecked")
- @Override
- public void run(ITestInvocationListener listener) throws DeviceNotAvailableException {
- …
- Log.logAndDisplay(LogLevel.INFO, "HelloWorldTest", "I received this option " + mMyOption);
-
-Rebuild TF and run helloworld: you should see a log message with the my_option's default value.
-
- tf> run example/helloworld
- …
- 05-24 18:30:05 I/HelloWorldTest: I received this option thisisthedefault
-
-Now pass in a value for my_option: you should see my_option getting populated with that value
-
- tf> run example/helloworld --my_option foo
- …
- 05-24 18:33:44 I/HelloWorldTest: I received this option foo
-
-TF configurations also include a help system, which automatically displays help text for @Option
-fields. Try it now, and you should see the help text for 'my_option':
-
- tf> run --help example/helloworld
- Printing help for only the important options. To see help for all options, use the --help-all flag
-
- cmd_options options:
- --[no-]help display the help text for the most important/critical options. Default: false.
- --[no-]help-all display the full help text for all options. Default: false.
- --[no-]loop keep running continuously. Default: false.
-
- test options:
- -m, --my_option this is the option's help text Default: thisisthedefault.
-
- 'file' logger options:
- --log-level-display the minimum log level to display on stdout. Must be one of verbose, debug, info, warn, error, assert. Default: error.
-FIXME: redo with enum help
-
-Note the message at the top about 'printing only the important options'. To reduce option help
-clutter, TF uses the Option#importance attribute to determine whether to show an Option's help text
-when '--help' is specified. '--help-all' will always show all options' help regardless of
-importance. See Option.Importance javadoc for details.
-
-You can also specify an Option's value within the configuration xml by adding a
-`<option name="" value="">` element. Lets see how this looks in the helloworld.xml:
-
- <test class="com.android.tradefed.example.HelloWorldTest" >
- <option name="my_option" value="fromxml" />
- </test>
-
-Re-building and running helloworld should now produce this output:
-
- 05-24 20:38:25 I/HelloWorldTest: I received this option fromxml
-
-The configuration help should also be updated to indicate my_option's new default value:
-
- tf> run --help example/helloworld
- test options:
- -m, --my_option this is the option's help text Default: fromxml.
-
-Also note that other configuration objects included in the helloworld config, like FileLogger, also have options. '--log-level-display' is of interest because it filters the logs that show up on stdout. You may have noticed from earlier in the tutorial the 'Hello world, TF! I have a device ..' log message stopped getting displayed on stdout once we switched to using FileLogger. You can increase the verbosity of logging to stdout by passing in log-level-display arg.
-
-Try this now, and you should see the 'I have a device' log message reappear on stdout, in addition to getting logged to a file.
-
- tf >run --log-level-display info example/helloworld
- …
- 05-24 18:53:50 I/HelloWorldTest: Hello world, TF! I have a device XXXXXX
-
-<!-- To make future debugging in this tutorial easier, edit the helloworld.xml to default log-level-display to debug:
-
- <logger class="com.android.tradefed.log.FileLogger" >
- <option name="log-level-display" value="debug" />
- </logger>
--->
