From 3027576c42897037427a7e0ce4c100206f74490c Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Mon, 20 Nov 2017 08:43:57 -0800 Subject: Docs: Changes to source.android.com - 176365996 Devsite localized content from translation request 36fc3b... by Android Partner Docs - 176365994 Devsite localized content from translation request 29ecb2... by Android Partner Docs - 176318336 Devsite localized content from translation request d25ba3... by Android Partner Docs - 176195455 Add note to CTS section "GPS/GNSS" about port availability. by Christina Nguyen - 176110625 Devsite localized content from translation request aec37a... by Android Partner Docs - 176110530 Devsite localized content from translation request ac14a0... by Android Partner Docs - 176110525 Devsite localized content from translation request 7d4488... by Android Partner Docs - 176001918 Update displayed error message to reflect "what is". (Tho... by Billy Lamberta - 175980378 Update Motorola link by Android Partner Docs - 175972776 Devsite localized content from translation request 21d570... by Android Partner Docs - 175925123 Publish localized security bulletins by Danielle Roberts - 175921366 Update CTS/CTS-Verifier downloads for CTS-Dec-2017 Releases by Billy Lamberta - 175915069 Put CTS supported platforms in a more distinct call-out. by Christina Nguyen - 175908691 Update FMQ doc for indentations by Android Partner Docs - 175905935 Devsite localized content from translation request 266989... by Android Partner Docs - 175905631 Devsite localized content from translation request 255121... by Android Partner Docs - 175905617 Devsite localized content from translation request 7e5691... by Android Partner Docs - 175874683 Rename links from /source/... to /setup/... by Billy Lamberta - 175774898 Devsite localized content from translation request 23a854... by Android Partner Docs - 175754894 Update continuous localization for Setup tab by Danielle Roberts - 175754691 Top-level _translation.yaml: Ignore /setup/ directory (fo... by Billy Lamberta - 175744774 Updating ril images and text flow by Heidi von Markham - 175733952 Rename top-level 'Source' tab to 'Setup' tab. by Billy Lamberta - 175720207 Moving layout summary to interfaces page by Heidi von Markham - 175706780 Devsite localized content from translation request 0dea26... by Android Partner Docs - 175703999 Changing GCM to FCM and links by Heidi von Markham - 175698764 Point the "Year in Review" link to the latest available r... by Android Partner Docs - 175599600 Fix missing and unnecessary tags. by Christina Nguyen - 175589733 Remove unused tag by Christina Nguyen PiperOrigin-RevId: 176365996 Change-Id: I3f5dcfd9b8c953b642b752c9c4e04313126eeee4 --- en/_book.yaml | 6 +- en/_index.yaml | 4 +- en/_translation.yaml | 2 +- en/compatibility/contact-us.html | 4 +- en/compatibility/cts/development.html | 7 +- en/compatibility/cts/downloads.html | 56 +- en/compatibility/cts/rotation-vector.html | 6 +- en/compatibility/cts/setup.html | 14 +- en/compatibility/cts/usb-audio.html | 6 +- en/compatibility/index.html | 2 +- .../accessories/headset/usb-headset-spec.html | 5 +- en/devices/architecture/dto/implement.html | 4 +- en/devices/architecture/hidl/binder-ipc.html | 5 +- en/devices/architecture/hidl/fmq.html | 16 +- en/devices/architecture/hidl/interfaces.html | 112 +- en/devices/architecture/index.html | 2 +- .../architecture/kernel/modular-kernels.html | 10 +- en/devices/architecture/kernel/network_tests.html | 6 +- en/devices/audio/latency_measurements.html | 2 +- en/devices/bluetooth/verifying_debugging.html | 9 +- en/devices/sensors/sensor-stack.html | 2 +- en/devices/tech/admin/testing-provision.html | 7 +- en/devices/tech/admin/testing-setup.html | 2 +- .../images/ril-refactor-scenario-1-solution-1.png | Bin 79748 -> 51029 bytes .../images/ril-refactor-scenario-1-solution-2.png | Bin 55546 -> 31108 bytes .../connect/images/ril-refactor-scenario-1.png | Bin 64610 -> 36302 bytes .../images/ril-refactor-scenario-2-solution.png | Bin 29752 -> 17084 bytes .../connect/images/ril-refactor-scenario-2.png | Bin 36008 -> 18986 bytes en/devices/tech/connect/ril.html | 344 ++- en/devices/tech/dalvik/configure.html | 8 +- en/devices/tech/dalvik/index.html | 12 +- en/devices/tech/debug/index.html | 2 +- en/devices/tech/debug/kasan-kcov.html | 14 +- en/devices/tech/display/circular-icons.html | 2 +- en/devices/tech/ota/device_code.html | 2 +- en/devices/tech/power/mgmt.html | 76 +- .../tech/test_infra/tradefed/full_example.html | 2 +- .../test_infra/tradefed/fundamentals/index.html | 2 +- .../tradefed/fundamentals/machine_setup.html | 2 +- en/devices/tv/reference-tv-app.html | 5 +- en/legal.html | 4 +- en/security/bulletin/index.html | 15 +- en/security/bulletin/pixel/index.html | 4 +- en/security/index.html | 2 +- en/security/selinux/customize.html | 2 +- en/setup/64-bit-builds.html | 227 ++ en/setup/_toc.yaml | 71 + en/setup/_translation.yaml | 10 + en/setup/add-device.html | 475 ++++ en/setup/assets/bg_fade.jpg | Bin 0 -> 300 bytes en/setup/assets/bg_images_sprite.png | Bin 0 -> 2008 bytes en/setup/assets/images/sac_logo.png | Bin 0 -> 2298 bytes en/setup/assets/rebox-gradient.gif | Bin 0 -> 848 bytes en/setup/brands.html | 157 ++ en/setup/build-numbers.html | 2281 ++++++++++++++++++++ en/setup/building-kernels.html | 277 +++ en/setup/building.html | 228 ++ en/setup/code-lines.html | 187 ++ en/setup/code-style.html | 718 ++++++ en/setup/community.html | 361 ++++ en/setup/contributing.html | 58 + en/setup/developing.html | 189 ++ en/setup/devices.html | 357 +++ en/setup/downloading.html | 296 +++ en/setup/faqs.html | 328 +++ en/setup/git-resources.html | 47 + en/setup/images/8100-TM-example.png | Bin 0 -> 35583 bytes en/setup/images/Android_Robot_100.png | Bin 0 -> 4075 bytes en/setup/images/JB-TM-example.png | Bin 0 -> 22776 bytes en/setup/images/No_PeaceBot_200.jpg | Bin 0 -> 5773 bytes en/setup/images/XBrand-TM-example.jpg | Bin 0 -> 37074 bytes en/setup/images/android_logo_new_crossed_out.png | Bin 0 -> 7721 bytes en/setup/images/android_logo_old_crossed_out.png | Bin 0 -> 4027 bytes en/setup/images/hikey-board.png | Bin 0 -> 98708 bytes en/setup/images/hikey620.png | Bin 0 -> 254778 bytes en/setup/images/hikey960.png | Bin 0 -> 267973 bytes en/setup/images/jack_jill.png | Bin 0 -> 24908 bytes en/setup/images/jack_library.png | Bin 0 -> 17629 bytes en/setup/images/jack_overview.png | Bin 0 -> 15210 bytes en/setup/images/jack_predex.png | Bin 0 -> 14835 bytes en/setup/images/mobile-view.png | Bin 0 -> 98399 bytes en/setup/images/neonkey-sensorhub.png | Bin 0 -> 346473 bytes en/setup/index.html | 81 + en/setup/initializing.html | 460 ++++ en/setup/jack.html | 358 +++ en/setup/known-issues.html | 78 + en/setup/licenses.html | 110 + en/setup/life-of-a-bug.html | 151 ++ en/setup/life-of-a-patch.html | 38 + en/setup/read-bug-reports.html | 1018 +++++++++ en/setup/report-bugs.html | 314 +++ en/setup/requirements.html | 173 ++ en/setup/roles.html | 102 + en/setup/running.html | 446 ++++ en/setup/site-updates.html | 683 ++++++ en/setup/submit-patches.html | 238 ++ en/setup/using-repo.html | 305 +++ en/setup/view-patches.html | 141 ++ en/source/64-bit-builds.html | 227 -- en/source/_toc.yaml | 71 - en/source/_translation.yaml | 10 - en/source/add-device.html | 475 ---- en/source/assets/bg_fade.jpg | Bin 300 -> 0 bytes en/source/assets/bg_images_sprite.png | Bin 2008 -> 0 bytes en/source/assets/images/sac_logo.png | Bin 2298 -> 0 bytes en/source/assets/rebox-gradient.gif | Bin 848 -> 0 bytes en/source/brands.html | 157 -- en/source/build-numbers.html | 2281 -------------------- en/source/building-kernels.html | 277 --- en/source/building.html | 228 -- en/source/code-lines.html | 187 -- en/source/code-style.html | 718 ------ en/source/community.html | 361 ---- en/source/contributing.html | 58 - en/source/developing.html | 189 -- en/source/devices.html | 357 --- en/source/downloading.html | 296 --- en/source/faqs.html | 328 --- en/source/git-resources.html | 47 - en/source/images/8100-TM-example.png | Bin 35583 -> 0 bytes en/source/images/Android_Robot_100.png | Bin 4075 -> 0 bytes en/source/images/JB-TM-example.png | Bin 22776 -> 0 bytes en/source/images/No_PeaceBot_200.jpg | Bin 5773 -> 0 bytes en/source/images/XBrand-TM-example.jpg | Bin 37074 -> 0 bytes en/source/images/android_logo_new_crossed_out.png | Bin 7721 -> 0 bytes en/source/images/android_logo_old_crossed_out.png | Bin 4027 -> 0 bytes en/source/images/hikey-board.png | Bin 98708 -> 0 bytes en/source/images/hikey620.png | Bin 254778 -> 0 bytes en/source/images/hikey960.png | Bin 267973 -> 0 bytes en/source/images/jack_jill.png | Bin 24908 -> 0 bytes en/source/images/jack_library.png | Bin 17629 -> 0 bytes en/source/images/jack_overview.png | Bin 15210 -> 0 bytes en/source/images/jack_predex.png | Bin 14835 -> 0 bytes en/source/images/mobile-view.png | Bin 98399 -> 0 bytes en/source/images/neonkey-sensorhub.png | Bin 346473 -> 0 bytes en/source/index.html | 81 - en/source/initializing.html | 460 ---- en/source/jack.html | 358 --- en/source/known-issues.html | 78 - en/source/licenses.html | 110 - en/source/life-of-a-bug.html | 151 -- en/source/life-of-a-patch.html | 38 - en/source/read-bug-reports.html | 1018 --------- en/source/report-bugs.html | 314 --- en/source/requirements.html | 173 -- en/source/roles.html | 102 - en/source/running.html | 446 ---- en/source/site-updates.html | 683 ------ en/source/submit-patches.html | 238 -- en/source/using-repo.html | 305 --- en/source/view-patches.html | 142 -- 151 files changed, 11375 insertions(+), 11339 deletions(-) create mode 100644 en/setup/64-bit-builds.html create mode 100644 en/setup/_toc.yaml create mode 100644 en/setup/_translation.yaml create mode 100644 en/setup/add-device.html create mode 100644 en/setup/assets/bg_fade.jpg create mode 100644 en/setup/assets/bg_images_sprite.png create mode 100644 en/setup/assets/images/sac_logo.png create mode 100644 en/setup/assets/rebox-gradient.gif create mode 100644 en/setup/brands.html create mode 100644 en/setup/build-numbers.html create mode 100644 en/setup/building-kernels.html create mode 100644 en/setup/building.html create mode 100644 en/setup/code-lines.html create mode 100644 en/setup/code-style.html create mode 100644 en/setup/community.html create mode 100644 en/setup/contributing.html create mode 100644 en/setup/developing.html create mode 100644 en/setup/devices.html create mode 100644 en/setup/downloading.html create mode 100644 en/setup/faqs.html create mode 100644 en/setup/git-resources.html create mode 100644 en/setup/images/8100-TM-example.png create mode 100644 en/setup/images/Android_Robot_100.png create mode 100644 en/setup/images/JB-TM-example.png create mode 100644 en/setup/images/No_PeaceBot_200.jpg create mode 100644 en/setup/images/XBrand-TM-example.jpg create mode 100644 en/setup/images/android_logo_new_crossed_out.png create mode 100644 en/setup/images/android_logo_old_crossed_out.png create mode 100644 en/setup/images/hikey-board.png create mode 100644 en/setup/images/hikey620.png create mode 100644 en/setup/images/hikey960.png create mode 100644 en/setup/images/jack_jill.png create mode 100644 en/setup/images/jack_library.png create mode 100644 en/setup/images/jack_overview.png create mode 100644 en/setup/images/jack_predex.png create mode 100644 en/setup/images/mobile-view.png create mode 100644 en/setup/images/neonkey-sensorhub.png create mode 100644 en/setup/index.html create mode 100644 en/setup/initializing.html create mode 100644 en/setup/jack.html create mode 100644 en/setup/known-issues.html create mode 100644 en/setup/licenses.html create mode 100644 en/setup/life-of-a-bug.html create mode 100644 en/setup/life-of-a-patch.html create mode 100644 en/setup/read-bug-reports.html create mode 100644 en/setup/report-bugs.html create mode 100644 en/setup/requirements.html create mode 100644 en/setup/roles.html create mode 100644 en/setup/running.html create mode 100644 en/setup/site-updates.html create mode 100644 en/setup/submit-patches.html create mode 100644 en/setup/using-repo.html create mode 100644 en/setup/view-patches.html delete mode 100644 en/source/64-bit-builds.html delete mode 100644 en/source/_toc.yaml delete mode 100644 en/source/_translation.yaml delete mode 100644 en/source/add-device.html delete mode 100644 en/source/assets/bg_fade.jpg delete mode 100644 en/source/assets/bg_images_sprite.png delete mode 100644 en/source/assets/images/sac_logo.png delete mode 100644 en/source/assets/rebox-gradient.gif delete mode 100644 en/source/brands.html delete mode 100644 en/source/build-numbers.html delete mode 100644 en/source/building-kernels.html delete mode 100644 en/source/building.html delete mode 100644 en/source/code-lines.html delete mode 100644 en/source/code-style.html delete mode 100644 en/source/community.html delete mode 100644 en/source/contributing.html delete mode 100644 en/source/developing.html delete mode 100644 en/source/devices.html delete mode 100644 en/source/downloading.html delete mode 100644 en/source/faqs.html delete mode 100644 en/source/git-resources.html delete mode 100644 en/source/images/8100-TM-example.png delete mode 100644 en/source/images/Android_Robot_100.png delete mode 100644 en/source/images/JB-TM-example.png delete mode 100644 en/source/images/No_PeaceBot_200.jpg delete mode 100644 en/source/images/XBrand-TM-example.jpg delete mode 100644 en/source/images/android_logo_new_crossed_out.png delete mode 100644 en/source/images/android_logo_old_crossed_out.png delete mode 100644 en/source/images/hikey-board.png delete mode 100644 en/source/images/hikey620.png delete mode 100644 en/source/images/hikey960.png delete mode 100644 en/source/images/jack_jill.png delete mode 100644 en/source/images/jack_library.png delete mode 100644 en/source/images/jack_overview.png delete mode 100644 en/source/images/jack_predex.png delete mode 100644 en/source/images/mobile-view.png delete mode 100644 en/source/images/neonkey-sensorhub.png delete mode 100644 en/source/index.html delete mode 100644 en/source/initializing.html delete mode 100644 en/source/jack.html delete mode 100644 en/source/known-issues.html delete mode 100644 en/source/licenses.html delete mode 100644 en/source/life-of-a-bug.html delete mode 100644 en/source/life-of-a-patch.html delete mode 100644 en/source/read-bug-reports.html delete mode 100644 en/source/report-bugs.html delete mode 100644 en/source/requirements.html delete mode 100644 en/source/roles.html delete mode 100644 en/source/running.html delete mode 100644 en/source/site-updates.html delete mode 100644 en/source/submit-patches.html delete mode 100644 en/source/using-repo.html delete mode 100644 en/source/view-patches.html (limited to 'en') diff --git a/en/_book.yaml b/en/_book.yaml index b7d534d0..065b9fa4 100644 --- a/en/_book.yaml +++ b/en/_book.yaml @@ -1,10 +1,10 @@ upper_tabs: -- name: Source +- name: Setup lower_tabs: other: - - name: Source + - name: Setup contents: - - include: /source/_toc.yaml + - include: /setup/_toc.yaml - name: Security lower_tabs: other: diff --git a/en/_index.yaml b/en/_index.yaml index 9c226531..24c39733 100644 --- a/en/_index.yaml +++ b/en/_index.yaml @@ -4,7 +4,7 @@ landing_page: header: buttons: - label: Get source - path: /source/downloading + path: /setup/downloading rows: - items: - heading: 8.0 interfaces and architecture @@ -99,4 +99,4 @@ landing_page: - buttons: - classname: button button-primary label: More Updates - path: /source/site-updates + path: /setup/site-updates diff --git a/en/_translation.yaml b/en/_translation.yaml index cf395ffe..cf0d9878 100644 --- a/en/_translation.yaml +++ b/en/_translation.yaml @@ -4,7 +4,7 @@ ignore_paths: - /images/... - /reference/... - /security/... -- /source/... +- /setup/... enable_continuous_translation: True title: Android Open Source Project description: Translations for source.android.com diff --git a/en/compatibility/contact-us.html b/en/compatibility/contact-us.html index e0462c0e..29d58528 100644 --- a/en/compatibility/contact-us.html +++ b/en/compatibility/contact-us.html @@ -25,7 +25,7 @@

This page describes the contact methods for inquiries regarding the Android compatibility program, including the Compatibility Definition Document (CDD) and Compatibility Test -Suite (CTS). See the Community +Suite (CTS). See the Community page for communication channels regarding other topics.

android-compatibi

To make best use of this list, please first read Getting +href="/setup/community.html#getting-the-most-from-our-lists">Getting the Most from Our Lists on the Community page. Users looking for help with Android devices should contact their carrier or manufacturer for help.

diff --git a/en/compatibility/cts/development.html b/en/compatibility/cts/development.html index 249f1539..1329c2cc 100644 --- a/en/compatibility/cts/development.html +++ b/en/compatibility/cts/development.html @@ -24,7 +24,7 @@

Initializing your Repo client

-

Follow the instructions +

Follow the instructions to get and build the Android source code but specify a particular CTS branch name, for example-b android-5.0_r2, when issuing the repo init command. This assures your CTS changes will be included in the @@ -41,7 +41,7 @@ for TARGET_PRODUCT to build for different architectures: cd /path/to/android/root make cts -j32 TARGET_PRODUCT=aosp_arm64 cts-tradefed - +

At the cts-tf console, enter e.g.:

@@ -232,7 +232,7 @@ include $(call all-makefiles-under,$(LOCAL_PATH))
 remove tests annotated with "BrokenTest" or "KnownFailure."

 
 
Submitting your changes

-
Follow the Submitting Patches workflow
+
Follow the Submitting Patches workflow
 to contribute changes to CTS. A reviewer
 will be assigned to your change, and your change should be reviewed shortly!

 
@@ -244,6 +244,7 @@ will be assigned to your change, and your change should be reviewed shortly!

 updated from time to time as CTS for the given Android version matures.

 
 
+
diff --git a/en/compatibility/cts/downloads.html b/en/compatibility/cts/downloads.html
index 0c022d44..d6741f03 100644
--- a/en/compatibility/cts/downloads.html
+++ b/en/compatibility/cts/downloads.html
@@ -29,60 +29,60 @@ updated, new versions are added to this page. CTS versions are denoted by
 R<number> in the link name.
Android 8.0

-
Android 8.0 is the release of the development milestone code-named Oreo. 
+
Android 8.0 is the release of the development milestone code-named Oreo.
 The source code for the following tests can be synced with the
-'android-cts-8.0_r3' tag in the open-source tree.

+'android-cts-8.0_r4' tag in the open-source tree.
Android 7.1
Android 7.1 is the release of the development milestone code-named Nougat-MR1.
 The source code for the following tests can be synced with the
-'android-cts-7.1_r11' tag in the open-source tree.

+'android-cts-7.1_r12' tag in the open-source tree.
Android 7.0
Android 7.0 is the release of the development milestone code-named Nougat.
 The source code for the following tests can be synced with the
-'android-cts-7.0_r15' tag in the open-source tree.

+'android-cts-7.0_r16' tag in the open-source tree.
Android 6.0

diff --git a/en/compatibility/cts/rotation-vector.html b/en/compatibility/cts/rotation-vector.html
index 9abff4eb..b10c4203 100644
--- a/en/compatibility/cts/rotation-vector.html
+++ b/en/compatibility/cts/rotation-vector.html
@@ -30,9 +30,9 @@ full-resolution image linked above.
   
This page provides the steps to properly test the compatibility of your rotation
-vector sensor implementation. This test should be run when the device declares
-the TYPE_ROTATION_VECTOR composite sensor feature. See this rotation vector
+sensor implementation. This test should be run when the device declares the
+TYPE_ROTATION_VECTOR composite sensor feature. See this video tutorial for
 additional details.

 
diff --git a/en/compatibility/cts/setup.html b/en/compatibility/cts/setup.html
index 16cc43a0..cb235b63 100644
--- a/en/compatibility/cts/setup.html
+++ b/en/compatibility/cts/setup.html
@@ -40,6 +40,12 @@ be of any kind, ranging from a satellite simulator, to a GPS/GNSS repeater of
 outdoor signals, simply to placement of the DUT close enough to a window such that
 it can directly receive enough GPS/GNSS signal.

 
+
+
 
Wi-Fi and IPv6
CTS tests require a Wi-Fi network that supports IPv6, can treat the Device
 Under Test (DUT) as an isolated client, and has an internet
@@ -56,7 +62,8 @@ href="http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers">list of IPv6
 tunnel brokers.
Desktop machine setup

-
CTS currently supports 64-bit Linux and Mac OS host machines.

+
ADB and AAPT
Before running the CTS, make sure you have recent versions of both 
   8u45 or newer.
 
 

-For details, see the JDK
-requirements.
+For details, see the JDK requirements.
 
CTS files

@@ -121,7 +127,7 @@ file for Ubuntu Linux.
A compatible device is defined as a device with a user/release-key signed
 build, so your device should be running a system image based on the known to be
 compatible user build (Android 4.0 and later) from Codenames, Tags, and Build
+href="/setup/build-numbers.html">Codenames, Tags, and Build
 Numbers.

 
 
Caution: When used to confirm Android
diff --git a/en/compatibility/cts/usb-audio.html b/en/compatibility/cts/usb-audio.html
index b81a8909..4ef581d6 100644
--- a/en/compatibility/cts/usb-audio.html
+++ b/en/compatibility/cts/usb-audio.html
@@ -23,9 +23,9 @@
 
 

 Several Android Compatibility Test Suite (CTS)
-tests for Android USB audio
-require human intervention and the physical connection of USB audio
-peripherals. For these, additional CTS Verifier tests have been implemented.
+tests for Android USB audio require human
+intervention and the physical connection of USB audio peripherals. For these,
+additional CTS Verifier tests have been implemented.
 The requirements and protocols for these tests are explained in this document.
 

 
diff --git a/en/compatibility/index.html b/en/compatibility/index.html
index d053a587..a9051705 100644
--- a/en/compatibility/index.html
+++ b/en/compatibility/index.html
@@ -70,7 +70,7 @@ free, and it's easy
To build an Android-compatible mobile device, follow this three-step
 process:
    
-
  1. Obtain the Android software source
+
  2. Obtain the Android software source
 code. This is the source code for the Android platform that you port
 to your hardware.
    3. 
 
  3. Comply with the Android Compatibility Definition Document (CDD)
diff --git a/en/devices/accessories/headset/usb-headset-spec.html b/en/devices/accessories/headset/usb-headset-spec.html
index c83f7eac..3279eee1 100644
--- a/en/devices/accessories/headset/usb-headset-spec.html
+++ b/en/devices/accessories/headset/usb-headset-spec.html
@@ -28,9 +28,8 @@ This documentation specifies USB headset buttons behavior to function uniformly
 across the Android ecosystem. Device manufacturers should also consult the
 USB
 Digital Audio page for more information about USB implementation on Android
-and the Android
-Compatibility Definition Document (CDD) for requirements related to Android
-devices.
+and the Android Compatibility
+Definition Document (CDD) for requirements related to Android devices.
 
    
 
    There are also specifications for
 3.5 mm headsets for accessory manufacturers and
diff --git a/en/devices/architecture/dto/implement.html b/en/devices/architecture/dto/implement.html
index 5d10a92c..52906fc8 100644
--- a/en/devices/architecture/dto/implement.html
+++ b/en/devices/architecture/dto/implement.html
@@ -108,8 +108,8 @@ top of the main DT blob. Typically, 8 MB is more than enough and allows room to
 grow in the future if required.
    
 
 
    For devices that support
-seamless
-(A/B) updates, A/B the main DT and overlay DT partitions:
    
+seamless (A/B) updates, A/B the
+main DT and overlay DT partitions:
    
 
 
    
 
    
diff --git a/en/devices/architecture/hidl/binder-ipc.html b/en/devices/architecture/hidl/binder-ipc.html
index 811bc3b7..22c38a11 100644
--- a/en/devices/architecture/hidl/binder-ipc.html
+++ b/en/devices/architecture/hidl/binder-ipc.html
@@ -255,9 +255,8 @@ need renaming.
    
 
    To fulfill requirement 4, you must make changes in the way service names,
 service labels, and rules are handled.
    
 
-
    For details on SELinux, see
-Security-Enhanced Linux
-in Android. For details on SELinux in Android 8.0, see
+
    For details on SELinux, see Security-Enhanced
+Linux in Android. For details on SELinux in Android 8.0, see
 SELinux for Android
 8.0.
    
 
diff --git a/en/devices/architecture/hidl/fmq.html b/en/devices/architecture/hidl/fmq.html
index 13a79610..db4055b5 100644
--- a/en/devices/architecture/hidl/fmq.html
+++ b/en/devices/architecture/hidl/fmq.html
@@ -353,17 +353,17 @@ const MemRegion& getSecondRegion(); // get a reference to the second MemRegi
 
     MessageQueueSync::MemTransaction tx;
 if (mQueue->beginRead(dataLen, &tx)) {
-auto first = tx.getFirstRegion();
-auto second = tx.getSecondRegion();
+    auto first = tx.getFirstRegion();
+    auto second = tx.getSecondRegion();
 
-foo(first.getAddress(), first.getLength()); // method that performs the data write
-foo(second.getAddress(), second.getLength()); // method that performs the data write
+    foo(first.getAddress(), first.getLength()); // method that performs the data write
+    foo(second.getAddress(), second.getLength()); // method that performs the data write
 
-if(commitWrite(dataLen) == false) {
-//report error
-}
+    if(commitWrite(dataLen) == false) {
+       // report error
+    }
 } else {
-//report error
+   // report error
 }
 
    
 
diff --git a/en/devices/architecture/hidl/interfaces.html b/en/devices/architecture/hidl/interfaces.html
index a044abde..6fc1cb1b 100644
--- a/en/devices/architecture/hidl/interfaces.html
+++ b/en/devices/architecture/hidl/interfaces.html
@@ -75,7 +75,7 @@ interface in the package.
    
 
 
    Interface definition
    
 
    Aside from types.hal, every other .hal file defines
-an interface. For example, an interface is typically defined as follows:
    
+an interface. An interface is typically defined as follows:
    
 
 
     interface IBar extends IFoo { // IFoo is another interface
@@ -101,7 +101,7 @@ include:
    
 
  4. interfaceDescriptor
    5. 
 
  5. notifySyspropsChanged
    6. 
 
  6. linkToDeath
    7. 
-
  7. unlinkToDeath
    8. unlinkToDeath
    8. 
 
  8. setHALInstrumentation
    9. 
 
  9. getDebugInfo
    10. 
 
  10. debug
    11. 
@@ -136,13 +136,13 @@ For fully-qualified values, the following import cases are supported:
    
 
  11. Whole-package imports. If the value is a package name and a
 version (syntax described below), then the entire package is imported into the
 importing entity.
    12. 
-
  12. Partial imports.
+
  13. Partial imports. If the value is:
 
      
-
    • If the value is an interface, the package's types.hal and that
-interface are imported into the importing entity.
      • 
-
    • If the value is an UDT defined in types.hal, then only that UDT
-is imported into the importing entity (other types in types.hal are
-not imported).
      • 
+
    • An interface, the package's types.hal and that interface are
+imported into the importing entity.
      • 
+
    • A UDT defined in types.hal, then only that UDT is imported into
+the importing entity (other types in types.hal are not imported).
+
      • 
 
    
 
  14. Types-only imports. If the value uses the syntax of a
 partial import described above, but with the keyword types instead
@@ -208,7 +208,7 @@ be registered under the base HAL name and version, and under the extension's
 Versions are expressed in two integers, major.minor.
    
 
      
 
    • Major versions are not backwards compatible. Incrementing
-the major version number resets the minor version to 0.
      • 
+the major version number resets the minor version number to 0.
 
    • Minor versions are backwards compatible. Incrementing the
 minor number indicates the newer version is fully backward compatible with the
 previous version. New data structures and methods can be added, but no existing
@@ -219,10 +219,98 @@ data structures or method signatures may be changed.
      • 
 can be present on a device simultaneously. While multiple minor versions can
 also be present on a device, as minor versions are backwards compatible no
 reason exists to support more than the latest minor version for each major
-version.
      
-
-
      For more details on versioning and vendor extensions, see
+version. For more details on versioning and vendor extensions, see
 HIDL Versioning.
      
 
+
      Interface layout summary
      
+
      This section summarizes how to manage a HIDL interface package (such as
+hardware/interfaces) and consolidates information presented
+throughout the HIDL section. Before reading, ensure you are familiar with
+HIDL Versioning, the hashing
+concepts in Hashing with
+hidl-gen, the details of working with
+HIDL in general, and the following definitions:
      
+
+

 

   Version
   Branch
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
TermDefinition
Application Binary Interface (ABI)Application programming interface + any binary linkages required.
Fully-qualified name (fqName)Name to distinguish a hidl type. Example:
+android.hardware.foo@1.0::IFoo.
PackagePackage containing a HIDL interface and types. Example:
+android.hardware.foo@1.0.
 Package rootRoot package that contains the HIDL interfaces. Example: the HIDL interface
+android.hardware is in the package root
+android.hardware.foo@1.0.
Package root pathLocation in the Android source tree where a package root maps to.

+
+
For more definitions, see HIDL
+Terminology.
+

+
+
Every file can be found from the package root mapping and
+its fully-qualified name

+
Package roots are specified to hidl-gen as the argument
+-r android.hardware:hardware/interfaces. For example, if the
+package is vendor.awesome.foo@1.0::IFoo and hidl-gen
+is sent -r vendor.awesome:some/device/independent/path/interfaces,
+then the interface file should be located in
+$ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal.
+

+
In practice, it is recommended for a vendor or OEM named awesome
+to put their standard interfaces in vendor.awesome. After a package
+path has been selected, it must not be changed as this is baked into the ABI of
+the interface.

+
+
Package path mapping should be unique

+
For example, if you have -rsome.package:$PATH_A and
+-rsome.package:$PATH_B, $PATH_A must be equal to
+$PATH_B for a consistent interface directory (this also makes
+versioning interfaces much
+easier).

+
+
Package root must have a versioning file

+
If you create a package path such as
+-r vendor.awesome:vendor/awesome/interfaces, you should also
+create the file
+$ANDROID_BUILD_TOP/vendor/awesome/interfaces/current.txt, which
+should contain hashes of interfaces made using the -Lhash option in
+hidl-gen (this is discussed extensively in
+Hashing with
+hidl-gen).

+
+
+
+
Interfaces go in device-independent
+locations

+
In practice, it is recommended to share interfaces between branches. This
+allows for maximum code re-usage and maximum testing of code across different
+devices and use cases.

+
   
 
diff --git a/en/devices/architecture/index.html b/en/devices/architecture/index.html
index 38f494a7..592198ff 100644
--- a/en/devices/architecture/index.html
+++ b/en/devices/architecture/index.html
@@ -75,7 +75,7 @@ primarily for system functionality and do not affect driver development.

 
You can use any version of the kernel 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 details, see
-Building Kernels.

+Building Kernels.

 
   
 
diff --git a/en/devices/architecture/kernel/modular-kernels.html b/en/devices/architecture/kernel/modular-kernels.html
index 5c4b54c3..70debebe 100644
--- a/en/devices/architecture/kernel/modular-kernels.html
+++ b/en/devices/architecture/kernel/modular-kernels.html
@@ -181,8 +181,8 @@ mounted in Recovery mode.
 partitions are not mounted early. In Android 8.0, to make
 module loading from these partitions possible, provisions have been made to
 mount partitions early for both
-non-A/B and A/B
-devices. This also ensures the partitions are mounted in both Android and
+non-A/B and A/B devices. This also
+ensures the partitions are mounted in both Android and
 Charger modes.

 
 
Android build system support

@@ -604,9 +604,9 @@ see DTB/DTBO Partitions.
 The assumption is that bootloader already knows where and how to load the
 SoC–specific DTB.
 
  • Overlay DT partition should be
-A/B-ed
-for A/B devices. For these devices, the recovery kernel is the same as Android
-kernel, but the partition must be A/B-ed as it can be updated via OTA.
    • 
+A/B-ed for A/B devices. For these
+devices, the recovery kernel is the same as Android kernel, but the partition
+must be A/B-ed as it can be updated via OTA.
 
  • Partition size is board–specific.
  
      
  
    • The DT overlay partition size depends on the device and the amount of
diff --git a/en/devices/architecture/kernel/network_tests.html b/en/devices/architecture/kernel/network_tests.html
index bc437ad2..39329d2b 100644
--- a/en/devices/architecture/kernel/network_tests.html
+++ b/en/devices/architecture/kernel/network_tests.html
@@ -45,9 +45,9 @@ Suite (CTS) tests.
      
 
 
      Using the tests
       
      The tests use User-Mode Linux to boot the
-kernel as a process on a Linux host machine. See Establishing a Build
-Environment for suitable operating system versions. The unit test framework
+kernel as a process on a Linux host machine. See
+Establishing a Build Environment for
+suitable operating system versions. The unit test framework
 boots the kernel with an appropriate disk image and runs the tests from the
 host file system. The tests are written in Python 2.x and use TAP interfaces to
 exercise kernel behaviour and the socket API.
      
diff --git a/en/devices/audio/latency_measurements.html b/en/devices/audio/latency_measurements.html
index d8483c0c..9ec6e256 100644
--- a/en/devices/audio/latency_measurements.html
+++ b/en/devices/audio/latency_measurements.html
@@ -97,7 +97,7 @@ and
 
      Example measurements
      
 
 
      The measurements listed below are specific to a
-build number. Devices are listed in
+build number. Devices are listed in
 approximate order of initial release and by platform version; you can also
 view latencies in a chart. The test application uses the
 Android native audio API based on OpenSL ES.
      
diff --git a/en/devices/bluetooth/verifying_debugging.html b/en/devices/bluetooth/verifying_debugging.html
index 40fcfc34..691894b6 100644
--- a/en/devices/bluetooth/verifying_debugging.html
+++ b/en/devices/bluetooth/verifying_debugging.html
@@ -79,11 +79,12 @@
           tools/test/connectivity/acts/tests/google/bt/pts.
      
 
       
      CTS Tests
      
-        
      The 
-          Compatibility Test Suite (CTS) includes tests for the
-          Bluetooth stack. These are located in 
+        The Compatibility Test Suite (CTS)
+        includes tests for the Bluetooth stack. These are located in 
-            cts/apps/CtsVerifier/src/com/android/cts/verifier/bluetooth.
      
+        cts/apps/CtsVerifier/src/com/android/cts/verifier/bluetooth.
+      
      
 
     
      Debugging options
      
       
      AOSP provides different methods of debugging a device's
diff --git a/en/devices/sensors/sensor-stack.html b/en/devices/sensors/sensor-stack.html
index 2522f02f..00c19a86 100644
--- a/en/devices/sensors/sensor-stack.html
+++ b/en/devices/sensors/sensor-stack.html
@@ -157,7 +157,7 @@ href="batching.html">Batching for more information.
      
 
 
      Note: To develop new ContextHub features that
 use new sensors or LEDs, you can also use a
-Neonkey SensorHub connected to a
+Neonkey SensorHub connected to a
 Hikey or Hikey960 development board.
      
 
 
      How the sensor hub is materialized depends on the architecture. It is sometimes
diff --git a/en/devices/tech/admin/testing-provision.html b/en/devices/tech/admin/testing-provision.html
index af303a01..0891ffa4 100644
--- a/en/devices/tech/admin/testing-provision.html
+++ b/en/devices/tech/admin/testing-provision.html
@@ -32,18 +32,17 @@ for Device Administration.
      
 
 
      Note: Building and running the AfW Test Harness
 is similar to building and running the Android
-Compatibility
-Test Suite (CTS).
      
+Compatibility Test Suite (CTS).
      
 
 
      Setting up a development environment
      
 
      The development environment for the AfW Test Harness is similar to Android
 OS. Follow the steps in
-Requirements to set up a
+Requirements to set up a
 development machine.
      
 
 
      Downloading source code
      
 
      Download the AfW Test Harness source code using the steps in
-Downloading the Source. The AfW
+Downloading the Source. The AfW
 Test Harness source code is in the ./test/AfwTestHarness project.
 The branch name determines the version of AfW Test Harness to download (each
 Android platform has a separate version of AfW Test Harness). For Android 7.0,
diff --git a/en/devices/tech/admin/testing-setup.html b/en/devices/tech/admin/testing-setup.html
index 131ade86..06e4dcc1 100644
--- a/en/devices/tech/admin/testing-setup.html
+++ b/en/devices/tech/admin/testing-setup.html
@@ -84,7 +84,7 @@ the bug report is collected, the user is prompted to give consent to send the
 bug report data. Results are received by
 DeviceAdminReceiver.onBugreport[Failed|Shared|SharingDeclined]. For
 details on bug report contents, see
-Reading Bug Reports.
      
+Reading Bug Reports.
      
 
 
      In addition, device owner DPCs can also collect logs related to actions a
 user has taken on a managed device. Enterprise process logging is required for
diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png
index c3b406f8..c252daad 100644
Binary files a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png and b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png differ
diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png
index c144afcf..6871336e 100644
Binary files a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png and b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png differ
diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1.png b/en/devices/tech/connect/images/ril-refactor-scenario-1.png
index f35fec9d..2d4e4b06 100644
Binary files a/en/devices/tech/connect/images/ril-refactor-scenario-1.png and b/en/devices/tech/connect/images/ril-refactor-scenario-1.png differ
diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png b/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png
index d25ace5c..565ac214 100644
Binary files a/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png and b/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png differ
diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-2.png b/en/devices/tech/connect/images/ril-refactor-scenario-2.png
index d52c1746..85d44a51 100644
Binary files a/en/devices/tech/connect/images/ril-refactor-scenario-2.png and b/en/devices/tech/connect/images/ril-refactor-scenario-2.png differ
diff --git a/en/devices/tech/connect/ril.html b/en/devices/tech/connect/ril.html
index 6367fb1f..56e7f9b9 100644
--- a/en/devices/tech/connect/ril.html
+++ b/en/devices/tech/connect/ril.html
@@ -23,267 +23,209 @@
 
 
 
-
      Android 7.0 included a refactoring of the Radio Interface Layer (RIL), using a set of
-subfeatures to improve RIL functionality. Partner code changes are required to implement these
-features, which are optional but encouraged. Refactoring changes are backward compatible, so prior
-implementations of the refactored features continue to work.
      
+
      Android 7.0 refactored the Radio Interface Layer (RIL) using a set of
+features to improve RIL functionality. Partner code changes are required to
+implement these features, which are optional but encouraged. Refactoring changes
+are backward compatible, so prior implementations of the refactored features
+continue to work.
      
 
-
      The following subfeatures are included in the RIL refactoring feature. You
-can implement any or all of the subfeatures:
      
+
      RIL refactoring includes the following improvements:
      
 
 
        
-
      • Enhanced RIL error codes: Code can return more specific error codes
-than the existing GENERIC_FAILURE code. This enhances error
-troubleshooting by providing more specific information about the cause
-of errors.
        • 
-
-
      • Enhanced RIL versioning: The RIL versioning mechanism is enhanced to
-provide more accurate and easier to configure version information.
        • 
-
-
      • Redesigned RIL communication using wakelocks: RIL communication using
-wakelocks is enhanced to improve device battery performance.
        • 
+
      • RIL error codes. Enables specific error codes
+in addition to the existing GENERIC_FAILURE code. This aids in
+error troubleshooting by providing more specific information about the cause of
+errors.
        • 
+
      • RIL versioning. Provides more accurate and easier
+to configure version information.
        • 
+
      • RIL communication using wakelocks. Improves
+device battery performance.
        • 
 
      
 
-
      Examples and source
      
-
-
      Documentation for RIL versioning is also in code comments in https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h.
      
-
-
      Implementation
      
+
      You can implement any or all of the above improvements. For more details,
+refer to code comments on RIL versioning in
+https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h.
      
 
-
      The following sections describe how to implement the subfeatures of the
-RIL refactoring feature.
      
-
-
      Implementing enhanced RIL error codes
      
-
-
      Problem
      
+
      Implementing enhanced RIL error codes
      
 
 
      Almost all RIL request calls can return the GENERIC_FAILURE
 error code in response to an error. This is an issue with all solicited
-responses returned by the OEMs. It is difficult to debug an issue from
-the bug report if the same GENERIC_FAILURE error code is
+responses returned by the OEMs, which can make it difficult to debug an issue
+from the bug report if the same GENERIC_FAILURE error code is
 returned by RIL calls for different reasons. It can take considerable time
 for vendors to even identify what part of the code could have returned a
 GENERIC_FAILURE code.
      
 
-
      Solution
      
-
-
      OEMs should return a distinct error code value associated
-with each of the different errors that are currently categorized as
-GENERIC_FAILURE.
      
-
-
      If OEMs do not want to publicly reveal their custom error codes, they may
-return errors as a distinct set of integers (for example, from 1 to x) that
-are mapped as OEM_ERROR_1 to OEM_ERROR_X. The
-vendor should make sure each such masked error code returned maps to a unique
-error reason in their code. The purpose of doing this is
-to speed up debugging RIL issues whenever generic errors are returned
-by the OEM. It can take too much time to identify what exactly caused
-GENERIC_FAILURE, and sometimes it's impossible to figure out.
      
-
-
      In ril.h, more error codes are
-added for enums RIL_LastCallFailCause and
-RIL_DataCallFailCause so that vendor code avoids returning
-generic errors like CALL_FAIL_ERROR_UNSPECIFIED and
+
      In Android 7.x and higher, OEMs can return a distinct error code value
+associated with each different error that is currently categorized as
+GENERIC_FAILURE. OEMs that do not want to publicly reveal their
+custom error codes can return errors as a distinct set of integers (such as 1 to
+x) mapped as OEM_ERROR_1 to OEM_ERROR_X. Vendors
+should ensure each such masked error code returned maps to a unique error reason
+in the code. Using specific error codes can speed up RIL debugging whenever
+generic errors are returned by the OEM, as it can often take too much time to
+identify the exact cause of a GENERIC_FAILURE error code (and
+sometimes it's impossible to figure out).
      
+
+
      In addition, ril.h adds more error codes for the enums
+RIL_LastCallFailCause and RIL_DataCallFailCause so
+vendor code can avoid returning generic errors such as
+CALL_FAIL_ERROR_UNSPECIFIED and
 PDP_FAIL_ERROR_UNSPECIFIED.
      
 
-
      Implementing enhanced RIL versioning
      
+
      Validating enhanced RIL error codes
      
 
-
      Problem
      
+
      After adding new error codes to replace the GENERIC_FAILURE
+code, verify the new error codes are returned by the RIL call instead
+of GENERIC_FAILURE.
      
 
-
      RIL versioning is not accurate enough. The mechanism for vendors to
-report their RIL version is not clear, causing vendors to report an incorrect
-version. A workaround method of estimating the version is used, but it can
-be inaccurate.
      
+
      Implementing enhanced RIL versioning
      
 
-
      Solution
      
+
      RIL versioning in older Android releases was problematic: the version itself
+was imprecise, the mechanism for reporting a RIL version was unclear (causing
+some vendors to report an incorrect version), and the workaround for estimating
+the version was prone to inaccuracy.
      
 
-
      There is a documented section in ril.h describing what a
-particular RIL version value corresponds to. Each
-RIL version is documented, including what changes correspond
-to that version. Vendors must update their version in code when making
-changes corresponding to that version, and return that version while doing
+
      In Android 7.x and higher, ril.h documents all RIL version
+values, describes the corresponding RIL version, and lists all changes for that
+version. When making changes that correspond to a RIL version, vendors must
+update their version in code and return that version in
 RIL_REGISTER.
      
 
-
      Implementing redesigned RIL communication using
-wakelocks
      
-
-
      Problem summary
      
-
-
      Timed wakelocks are used in RIL communication in an imprecise way,
-which negatively affects battery performance. RIL requests can be either
-solicited or unsolicited. Solicited requests should be classified as one of
-the following:
      
+
      Validating enhanced RIL versioning
      
 
-
        
-
      • synchronous: Those that do not take considerable time to respond back. For
-example, RIL_REQUEST_GET_SIM_STATUS.
        • 
+
        Verify that the RIL version corresponding to your RIL code is returned
+during RIL_REGISTER (rather than the RIL_VERSION
+defined in ril.h).
        
 
-
      • asynchronous: Those that take considerable time to respond back. For
-example, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
        • 
-
      
+
      Implementing RIL communication using wakelocks
      
 
-
      Follow these steps to implement redesigned wakelocks:
      
+
      Timed wakelocks are used in RIL communication in an imprecise way,
+which negatively affects battery performance. In Android 7.x and higher, you can
+improve performance by classifying RIL requests and updating code to handle
+wakelocks differently for different request types.
      
 
-
        
-
      1. 
-Classify solicited RIL commands as either synchronous or asynchronous
-depending on how much time they take to respond.
-
        Here are some things to consider while making
-that decision:
        
+
        Classifying RIL requests
        
+
        RIL requests can be either solicited or unsolicited. Vendors should further
+classify solicited requests as one of the following:
        
 
 
          
-
        • As explained in the solution of asynchronous solicited RIL requests,
-because the requests take considerable time, RIL Java releases the wakelock
-after receiving ack from vendor code. This might cause the application
-processor to go from idle to suspend state. When the response is available
-from vendor code, RIL Java (the application processor) will re-acquire the
-wakelock and process the response, and later go to idle state again. This
-process of moving from idle to suspend state and back to idle can consume
-a lot of power.
          • 
-
-
        • If the response time isn't long enough then holding the wakelock and
-staying in idle state for the entire time it takes to respond can be more
-power efficient than going in suspend state by releasing the wakelock and
-then waking up when the response arrives. So vendors should use
-platform-specific power measurement to find out the threshold value of time 't' when
-power consumed by staying in idle state for the entire time 't' consumes
-more power than moving from idle to suspend and back to idle in same time
-'t'. When that time 't' is discovered, RIL commands that take more than time
-'t' can be classified as asynchronous, and the rest of the RIL commands can
-be classified as synchronous.
          • 
-
        
+
      2. synchronous. Requests that do not take considerable time to
+respond back. For example, RIL_REQUEST_GET_SIM_STATUS.
        3. 
+ 
      3. asynchronous. Requests that take considerable time to
+respond back. For example, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
 
        4. 
+
    
 
-
  • Understand the RIL communications scenarios described in the RIL communication scenarios section.
    • 
-
-
  • Follow the solutions in the scenarios by modifying your code to handle
-RIL solicited and unsolicited requests.
    • 
-
-
-
    RIL communication scenarios
    
-
-
    For implementation details of the functions used in the
-following diagrams, see the source code of ril.cpp:
-acquireWakeLock(), decrementWakeLock(),
-clearWakeLock()
    
-
-
    Scenario 1: RIL request from Java APIs and solicited asynchronous response
-to that request
    
+
    Asynchronous solicited RIL requests can take considerable time. After
+receiving an ack from vendor code, RIL Java releases the wakelock, which might
+cause the application processor to go from idle to suspend state. When the
+response is available from vendor code, RIL Java (the application processor)
+re-acquires the wakelock, processes the response, then returns to idle. Such
+moving from idle to suspend to idle can consume a lot of power.
    
+
+
    If the response time isn't long enough, holding the wakelock and staying in
+idle for the entire time it takes to respond can be more power efficient than
+going into suspend state by releasing the wakelock and waking when the response
+arrives. Vendors should use platform-specific power measurements to determine
+the threshold value of time T when the power consumed by
+staying in idle for the entire time T is greater than the power
+consumed by moving from idle to suspend and to idle in same time T.
+When time T is known, RIL commands that take more than time
+T can be classified as asynchronous and the remaining commands
+classified as synchronous.
    
+
+
    RIL communication scenarios
    
+
    The following diagrams illustrate common RIL communication scenarios and
+provide solutions for modifying code to handle RIL solicited and unsolicited
+requests.
    
+
+
    Note: For implementation details on functions
+used in the following diagrams, refer to the acquireWakeLock(),
+decrementWakeLock(), and clearWakeLock() methods in
+ril.cpp.
    
+
+
    Scenario: RIL request and solicited asynchronous response
    
+
+
    In this scenario, if the RIL solicited response is expected to take
+considerable time (i.e. a response to
+RIL_REQUEST_GET_AVAILABLE_NETWORKS), the wakelock is held for a
+long time on the application processor side. Modem problems can also result in a
+long wait.
    
 
 
    
+
    Figure 1. RIL solicited asynchronous
+response.
    
 
-
    Problem
    
-
-
    If the RIL solicited response is expected to take considerable time (for
-example, RIL_REQUEST_GET_AVAILABLE_NETWORKS), then wakelock
-is held for a long time on the Application processor side, which is a
-problem. Also, modem problems result in a long wait.
    
-
-
    Solution part 1
    
-
-
    In this scenario, wakelock equivalent is held by Modem code (RIL request
-and asynchronous response back).
    
+
    Solution 1: The modem holds the wakelock for the RIL request
+and asynchronous response.
    
 
 
    
-
-
    As shown in the above sequence diagram:
    
+
    Figure 2. Wakelock held by modem.
    
 
 
      
-
    1. RIL request is sent, and the modem needs to acquire wakelock to process
-the request.
      2. 
-
-
    2. The modem code sends acknowledgement that causes the Java side to decrement
-the wakelock counter and release it if the wakelock counter value is 0.
      3. 
-
-
    3. After the modem processes the request, it sends an interrupt to the
-vendor code that acquires wakelock and sends a response to ril.cpp. ril.cpp
-then acquires wakelock and sends a response to the Java side.
      4. 
-
-
    4. When the response reaches the Java side, wakelock is acquired and response
-is sent back to caller.
      5. 
-
-
    5. After that response is processed by all modules, acknowledgement is
-sent back to ril.cpp over a socket. ril.cpp then
-releases the wakelock that was acquired in step 3.
      6. 
+
    6. RIL request is sent and the modem acquires wakelock to process that
+request.
      7. 
+
    7. Modem sends acknowledgement that causes the Java side to decrement
+the wakelock counter and release it when the counter value is 0.
+
      Note: The wakelock timeout duration for the
+request-ack sequence would be smallerthan the currently used timeout duration
+because the ack should be received fairly quickly.
      
+
      8. 
+
    8. After processing the request, the modem sends an interrupt to the vendor
+code that acquires wakelock and sends a response to ril.cpp, which in turn
+acquires wakelock and sends a response to the Java side.
      9. 
+
    9. When the response reaches the Java side, wakelock is acquired and a response
+is returned to the caller.
      10. 
+
    10. After the response is processed by all modules, acknowledgement is
+sent (via socket) back to ril.cpp, which then releases the wakelock
+acquired in step 3.
      11. 
 
    
 
-
    Note that the wakelock timeout duration for the request-ack sequence
-would be smaller than the currently used timeout duration because the ack
-should be received back fairly quickly.
    
-
-
    Solution part 2
    
-
-
    In this scenario, wakelock is not held by modem and response is quick
-(synchronous RIL request and response).
    
+
    Solution 2: The modem does not hold the wakelock and the
+response is quick (synchronous RIL request and response). The synchronous vs.
+asynchronous behavior is hardcoded for a specific RIL command and decided on a
+call-by-callbasis.
    
 
 
    
-
-
    As shown in the above sequence diagram:
    
+
    Figure 3. Wakelock not held by modem.
    
 
 
      
 
    1. RIL request is sent by calling acquireWakeLock() on the
 Java side.
      2. 
-
 
    2. Vendor code doesn't need to acquire wakelock and can process the request
 and respond quickly.
      3. 
-
 
    3. When the response is received by the Java side,
 decrementWakeLock() is called, which decreases wakelock counter
 and releases wakelock if the counter value is 0.
      4. 
 
    
 
-
    Note that this synchronous vs. asynchronous behavior is hardcoded for a
-particular RIL command and decided on a call-by-call basis.
    
-
-
    Scenario 2: RIL unsolicited response
    
+
    Scenario: RIL unsolicited response
    
+
    In this scenario, RIL unsolicited responses have a wakelock type flag in the
+that indicates whether a wakelock needs to be acquired for the vendor response.
+If the flag is set, a timed wakelock is set and the response is sent over a
+socket to the Java side. When the timer expires, the wakelock is released. The
+timed wakelock could be too long or too short for different RIL unsolicited
+responses.
    
 
 
    
+
    Figure 4. RIL unsolicited response.
    
 
-
    As shown in the above diagram, RIL unsolicited responses have a wakelock
-type flag in the response that indicates whether a wakelock needs to be
-acquired or not for the particular response received from the vendor. If
-the flag is set, then a timed wakelock is set and response is sent over a
-socket to the Java side. When the timer expires, the wakelock is released.
    
-
-
    Problem
    
-
-
    The timed wakelock illustrated in Scenario 2 could be too long or too
-short for different RIL unsolicited responses.
    
-
-
    Solution
    
+
    Solution: An acknowledgement is sent from the Java code to
+the native side (ril.cpp) instead of holding a timed wakelock on
+the native side while sending an unsolicited response.
    
 
 
    
+
    Figure 5. Using ack instead of timed wakelock.
+
    
 
-
    As shown, the problem can be solved by sending an acknowledgement from
-the Java code to the native side (ril.cpp), instead of holding
-a timed wakelock on the native side while sending an unsolicited response.
    
-
-
    Validation
    
-
-
    The following sections describe how to validate the implementation of
-the RIL refactoring feature's subfeatures.
    
-
-
    Validating enhanced RIL error codes
    
-
-
    After adding new error codes to replace the GENERIC_FAILURE
-code, verify that the new error codes are returned by the RIL call instead
-of GENERIC_FAILURE.
    
-
-
    Validating enhanced RIL versioning
    
-
-
    Verify that the RIL version corresponding to your RIL code is returned
-during RIL_REGISTER rather than the RIL_VERSION
-defined in ril.h.
    
 
 
    Validating redesigned wakelocks
    
 
-
    Verify that RIL calls are identified as synchronous or asynchronous.
    
-
-
    Because battery power consumption can be hardware/platform dependent,
-vendors should do some internal testing to find out if using the new wakelock
-semantics for asynchronous calls leads to battery power savings.
    
+
    Verify that RIL calls are identified as synchronous or asynchronous. Because
+battery power consumption can be hardware/platform dependent, vendors should do
+some internal testing to find out if using the new wakelock semantics for
+asynchronous calls leads to battery power savings.
    
 
   
 
diff --git a/en/devices/tech/dalvik/configure.html b/en/devices/tech/dalvik/configure.html
index b7e80e18..6a5fa86e 100644
--- a/en/devices/tech/dalvik/configure.html
+++ b/en/devices/tech/dalvik/configure.html
@@ -27,11 +27,9 @@
 include configuration of pre-compilation of the system image, dex2oat compilation options,
 and how to trade off system partition space, data partition space, and performance.
    
 
-
    See ART
-and Dalvik, the Dalvik
-Executable format, and the remaining pages on source.android.com to work
-with ART. See See ART and Dalvik, the Dalvik Executable format, and the
+remaining pages on source.android.com to work with ART. See Verifying
 App Behavior on the Android Runtime (ART) to ensure your apps work
 properly.
    
diff --git a/en/devices/tech/dalvik/index.html b/en/devices/tech/dalvik/index.html
index 2c84a8e5..5604d6a6 100644
--- a/en/devices/tech/dalvik/index.html
+++ b/en/devices/tech/dalvik/index.html
@@ -46,11 +46,11 @@ performance. ART also has tighter install-time verification than Dalvik.
    
 
 
    At install time, ART compiles apps using the on-device
 dex2oat tool. This utility accepts DEX files as input and
-generates a compiled app executable for the target device. The utility should be
-able to compile all valid DEX files without difficulty. However, some
-post-processing tools produce invalid files that may be tolerated by Dalvik but
-cannot be compiled by ART. For more information, see  DEX files as input and generates
+a compiled app executable for the target device. The utility should be able to
+compile all valid DEX files without difficulty. However, some post-processing
+tools produce invalid files that may be tolerated by Dalvik but cannot be
+compiled by ART. For more information, see  Addressing
 Garbage Collection Issues.
    
 
@@ -144,7 +144,7 @@ by including both Java and native stack information. 
    
 
    Reporting Problems
    
 
 
    If you run into any issues that aren’t due to app JNI issues, please report
-them through the Android Open Source
+them through the Android Open Source
 Project Issue Tracker. Include an adb bugreport and link to
 the app in Google Play store if available. Otherwise, if possible, attach an
 APK that reproduces the issue.
    
diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html
index 1c493637..90922b0b 100644
--- a/en/devices/tech/debug/index.html
+++ b/en/devices/tech/debug/index.html
@@ -159,7 +159,7 @@ directly without taking up anywhere near as much space as an unstripped version.
 
 
    You can also stack an entire tombstone. Example:
    
 
    -stack < FS/data/tombstones/tombstone_05
+stack < FS/data/tombstones/tombstone_05
 
    
 
    This is useful if you've just unzipped a bugreport in the current directory.
 For more information about diagnosing native crashes and tombstones, see
diff --git a/en/devices/tech/debug/kasan-kcov.html b/en/devices/tech/debug/kasan-kcov.html
index 20ba7fce..438cd027 100644
--- a/en/devices/tech/debug/kasan-kcov.html
+++ b/en/devices/tech/debug/kasan-kcov.html
@@ -49,16 +49,16 @@ Pixel's kernel source to boot with KASAN and KCOV turned on.
 environment
 
    
 Follow the steps in the Downloading and
+href="/setup/requirements">Downloading and
 Building section to set up your build environment.
 
    
 
    Building AOSP
    
 
    
-Download the Android source code. For the
+Download the Android source code. For the
 purpose of building KASAN images, choose a stable build that is not in active
 development. Often, the latest available release/stable branch is a good choice.
 More information about build and branch can be found at Source
+href="/setup/build-numbers#source-code-tags-and-builds">Source
 Code Tags and Builds.
 
    
 
@@ -72,13 +72,13 @@ downloaded tarballs, run the scripts they contain, and accept the licenses.
 
    
 
 
    
 Then clean up, set up your build environment, and choose your build target,
 following the steps in
-Preparing to Build.
+Preparing to Build.
 
    
 
 
    
@@ -255,7 +255,7 @@ kernel.
 
    
 
    Reconfiguring the kernel
    
 
    
-Set up your build environment.
+Set up your build environment.
 Build your modified defconfig and check if the newly added flags
 are present in the produced .config file.
 
    
@@ -363,7 +363,7 @@ index 31533fb9..81caf05d 100644
 If you do not wish to modify the BoardConfig.mk
 file, you could instead create a new lunch target that contains the name
 marlin_kasan. For more information about this process, see
-Adding a New Device.
+Adding a New Device.
 
    
 
 
    Adjusting the kernel
diff --git a/en/devices/tech/display/circular-icons.html b/en/devices/tech/display/circular-icons.html
index eed152a9..9e9c71e5 100644
--- a/en/devices/tech/display/circular-icons.html
+++ b/en/devices/tech/display/circular-icons.html
@@ -28,7 +28,7 @@
   icons are supported in Android 7.1.1 and later. Circular launcher icons
 are not enabled by default. To use circular icons in your device
 implementation, you must edit the resource
+  href="/setup/add-device.html#use-resource-overlays">resource
   overlay on your device to enable them.
    
 
 
    The resource file you are using an overlay on is at:
diff --git a/en/devices/tech/ota/device_code.html b/en/devices/tech/ota/device_code.html
index 98f37f0f..3b3d9d6c 100644
--- a/en/devices/tech/ota/device_code.html
+++ b/en/devices/tech/ota/device_code.html
@@ -121,7 +121,7 @@ format.
    
 Things console to have the images included in the selected product.
    
 
 
    Note: These images must meet Android brand guidelines.
    
+href="/setup/brands">brand guidelines.
    
 
 
    Recovery UI
    
 
    To support devices with different available hardware (physical buttons,
diff --git a/en/devices/tech/power/mgmt.html b/en/devices/tech/power/mgmt.html
index 7dd0862b..c54821f0 100644
--- a/en/devices/tech/power/mgmt.html
+++ b/en/devices/tech/power/mgmt.html
@@ -35,8 +35,9 @@ access and deferring syncs and jobs for those applications.
 
  • Doze. The platform can enter a state of
 deep sleep (periodically resuming normal operations) if users have not actively
 used their device (screen off and stationary) for extended periods of time.
-Android 7.0 and later also enables Doze to trigger a lighter set of optimizations when
-users turn off the device screen yet continue to move around.
    • 
+Android 7.0 and higher also enables Doze to trigger a lighter set of
+optimizations when users turn off the device screen yet continue to move around.
+
 
  • Exemptions. System apps and
 cloud messaging services preloaded on a device are typically exempted from App
 Standby and Doze by default (although app developers can intent their
@@ -95,7 +96,8 @@ a period of time.
 
    
 
 
    Testing App Standby
    
-
    You can manually test App Standby using the following adb commands:
    
+
    You can manually test App Standby using the following adb
+commands:
    
 
 
     adb shell dumpsys battery unplug
@@ -110,37 +112,39 @@ a period of time.
 network activity when a device is unused for long periods.
    
 
 
    Idle devices in Doze periodically enter a maintenance window, during which
-apps can complete pending activities (syncs, jobs, etc.). Doze then resumes sleep
-for a longer period of time, followed by another maintenance window. The
+apps can complete pending activities (syncs, jobs, etc.). Doze then resumes
+sleep for a longer period of time, followed by another maintenance window. The
 platform continues the Doze sleep/maintenance sequence, increasing the length of
 idle each time, until a maximum of a few hours of sleep time is reached. At all
 times, a device in Doze remains aware of motion and immediately leaves Doze
 if motion is detected.
    
 
-
    Android 7.0 and later extends Doze to trigger a lighter set of optimizations every time
-a user turns off the device screen, even when the user continues to move around,
-enabling longer lasting battery life.
    
+
    Android 7.0 and higher extends Doze to trigger a lighter set of optimizations
+every time a user turns off the device screen, even when the user continues to
+move around, enabling longer lasting battery life.
    
 
 
    System services (such as telephony) may be preloaded and exempted from Doze
 by default. Users can also exempt specific applications from Doze in the
-Settings menu. By default, Doze is disabled in AOSP; for details on
-enabling Doze, see Integrating Doze.
    
+Settings menu. By default, Doze is disabled in AOSP; for
+details on enabling Doze, see Integrating Doze.
+
    
 
 
    Doze requirements
    
 
    Doze support requires the device has a cloud messaging service, such as
-Google Cloud Messaging
-(GCM). This enables the device to know when to wake from Doze.
    
+Firebase Cloud
+Messaging (FCM). This enables the device to know when to wake from Doze.
    
+
 
    Full Doze support also requires a
 Significant
 Motion Detector (SMD) on the device; however, the lightweight Doze mode in
-Android 7.0 and later does not require an SMD. If Doze is enabled on a device that:
    
+Android 7.0 and higher does not require an SMD. If Doze is enabled on a device
+that:
    
 
      
 
    • Has an SMD, full Doze optimizations occur (includes lightweight
 optimizations).
      • 
 
    • Does not have an SMD, only the lightweight Doze optimizations occur.
      • 
 
    
 
-
 
    Doze lifecycle
    
 
 
    Doze begins when the platform detects the device is idle and
@@ -193,11 +197,12 @@ they can complete their processing.
    • 
 
 
 
-
    Android 7.0 and later extends Doze by enabling a lightweight sleep mode during screen
-off, before the device is idle.
    
+
    Android 7.0 and higher extends Doze by enabling a lightweight sleep mode
+during screen off, before the device is idle.
    
+
 
    
-
    Figure 1. Doze modes for non-stationary and stationary
-devices.
    
+
    Figure 1. Doze modes for non-stationary and
+stationary devices.
    
 
 
@@ -218,14 +223,16 @@ devices.
    
-
-
+
+
-
+
@@ -279,14 +286,14 @@ optimizing applications.
 
 
    Tips
      
-
    • If possible, use GCM for
-downstream
+
    • If possible, use FCM for
+downstream
 messaging.
      • 
 
    • If your users must see a notification right away, use a
-GCM
+FCM
 high priority message.
      • 
 
    • Provide sufficient information within the initial
-message
+message
 payload (to avoid unnecessary subsequent network access).
      • 
 
    • Set critical alarms with
 setAndAllowWhileIdle()
@@ -309,9 +316,9 @@ mode.
      
 
      You can exempt applications from being subject to Doze or App Standby.
 Exemptions may be needed in the following use cases:
      
 
        
-
      • OEM using non-GCM Cloud Messaging platform
        • 
-
      • Carrier using non-GCM Cloud Messaging platform
        • 
-
      • Third-party application using non-GCM Cloud Messaging platform
        • 
+
      • OEM using non-FCM Cloud Messaging platform
        • 
+
      • Carrier using non-FCM Cloud Messaging platform
        • 
+
      • Third-party application using non-FCM Cloud Messaging platform
        • 
 
      
 
 
      Warning: Do not exempt apps to avoid testing
@@ -325,14 +332,15 @@ these reasons, we strongly recommend that you do not exempt third-party
 applications and instead exempt only cloud messaging services or apps with
 similar functions.
      
 
-
      Apps exempted by default are listed in a single view in Settings > Battery.
-This list is used for exempting the app from both Doze and App
+
      Apps exempted by default are listed in a single view in Settings >
+Battery. This list is used for exempting the app from both Doze and App
 Standby modes. To provide transparency to the user, the Settings menu
 MUST show all exempted applications.
      
 
-
      Users can manually exempt apps via Settings > Battery > Battery optimization > All apps
-and then selecting the app to turn off (or back on) optimization. However, users cannot unexempt
-any application or service that is exempted by default in the system image.
      
+
      Users can manually exempt apps via Settings > Battery > Battery
+optimization > All apps and then selecting the app to turn off (or back on)
+optimization. However, users cannot unexempt any application or service that is
+exempted by default in the system image.
      
 
   
 
diff --git a/en/devices/tech/test_infra/tradefed/full_example.html b/en/devices/tech/test_infra/tradefed/full_example.html
index 0d3574e1..a6527aa0 100644
--- a/en/devices/tech/test_infra/tradefed/full_example.html
+++ b/en/devices/tech/test_infra/tradefed/full_example.html
@@ -507,7 +507,7 @@ tf> run example/helloworld --log-level-display info
 Trade
 Federation source code has a lot of useful information that isn't exposed in
 the documentation. If all else fails, try asking on the
-android-platform Google Group,
+android-platform Google Group,
 with "Trade Federation" in the message subject.
      
 
   
diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/index.html b/en/devices/tech/test_infra/tradefed/fundamentals/index.html
index f4d83f1b..c7958648 100644
--- a/en/devices/tech/test_infra/tradefed/fundamentals/index.html
+++ b/en/devices/tech/test_infra/tradefed/fundamentals/index.html
@@ -76,7 +76,7 @@ things that aren't directly discussed in the documentation.
      
 
      If you've gotten through everything here and still have unanswered questions, first try taking
 a look at the Trade Federation source code.  Beyond that, feel free to try asking on the
-android-platform Google Group.  For best results, make
+android-platform Google Group.  For best results, make
 sure to mention "Trade Federation" (or "tradefed", or "TF") in the message subject.
      
 
 
diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html b/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html
index 47b99bde..a15c4333 100644
--- a/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html
+++ b/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html
@@ -23,7 +23,7 @@
 
 
      
   Trade Federation is distributed with the AOSP and uses the Android build system
-  to create its binary. Make sure you've established a build environment to compile and run packages from the
   Android source tree.
 
      
diff --git a/en/devices/tv/reference-tv-app.html b/en/devices/tv/reference-tv-app.html
index 7a35de56..a8a5105f 100644
--- a/en/devices/tv/reference-tv-app.html
+++ b/en/devices/tv/reference-tv-app.html
@@ -123,7 +123,10 @@ adb push $OUT/system/priv-app/LiveTv/LiveTv.apk  /system/priv-app/LiveTv/
 
 
 
      Once Live TV is on your device, you should test that it is properly
-integrated. In addition to running the Compatibility test suite and the CTS Verifier tests for the TV app, you can use these tests below:
      
+integrated. In addition to running the Compatibility test suite and the CTS Verifier tests for the TV app,
+you can use these tests below:
      
 
 
      Unit tests
      
 
diff --git a/en/legal.html b/en/legal.html
index 71f688c2..733675e4 100644
--- a/en/legal.html
+++ b/en/legal.html
@@ -36,11 +36,11 @@
 
 
      Android Brands
      
 
-
      The "Android" name, the AndroidThe "Android" name, the Android logo, and
 other trademarks are property of Google Inc.
      
 
-
      See the Brand Guidelines for additional details.
      
+
      See the Brand Guidelines for additional details.
      
 
 
      Web Site Content
      
 
diff --git a/en/security/bulletin/index.html b/en/security/bulletin/index.html
index 1e337a14..987801e4 100644
--- a/en/security/bulletin/index.html
+++ b/en/security/bulletin/index.html
@@ -30,7 +30,8 @@ vulnerability details specific to their products, such as:
      
 
 
@@ -85,15 +86,13 @@ Android Open Source Project (AOSP), the upstream Linux kernel, and system-on-chi
  
    
-    
-    
-    
-    
diff --git a/en/security/index.html b/en/security/index.html
index 5d62e5d1..ca4e45e3 100644
--- a/en/security/index.html
+++ b/en/security/index.html
@@ -158,7 +158,7 @@ Android devices with Google Mobile
 Services. While these services are not part of the Android Open Source
 Project, they are included on many Android devices. For more information on
 some of these services, see Android Security’s
-2015
+2016
 Year in Review.
 
    
diff --git a/en/security/selinux/customize.html b/en/security/selinux/customize.html
index 98eafa4c..47f287a6 100644
--- a/en/security/selinux/customize.html
+++ b/en/security/selinux/customize.html
@@ -97,7 +97,7 @@ the OEM, before turning on enforcing mode.
    To prevent unnecessary issues, it is better to be overbroad and over-compatible
 than too restrictive and incompatible, which results in broken device
 functions. Conversely, if a manufacturer's changes will benefit others, it
-should supply the modifications to the default SELinux policy as a patch. If the patch is applied to the default security policy, the manufacturer will no longer need to make this change with each new Android release.
    
+should supply the modifications to the default SELinux policy as a patch. If the patch is applied to the default security policy, the manufacturer will no longer need to make this change with each new Android release.
    Example policy statements
    
 
diff --git a/en/setup/64-bit-builds.html b/en/setup/64-bit-builds.html
new file mode 100644
index 00000000..30b51d6f
--- /dev/null
+++ b/en/setup/64-bit-builds.html
@@ -0,0 +1,227 @@
+
+  
+    Understanding 64-bit Builds
+    
+    
+  
+  
+  
+
+
+
+
    Overview
    
+
+
    From the build system’s perspective, the most noticeable change is that now it
+supports building binaries for two target CPU architectures (64-bit and 32-bit)
+in the same build. That’s also known as Multilib build.
    
+
+
    For native static libraries and shared libraries, the build system sets up
+rules to build binaries for both architectures. The product configuration
+(PRODUCT_PACKAGES), together with the dependency graph, determines which
+binaries are built and installed to the system image.
    
+
+
    For executables and apps, the build system builds only the 64-bit version by
+default, but you can override this setting by using a global
+BoardConfig.mk variable or a module-scoped variable.
    
+
+
    Caution: If an app exposes an API to other
+apps that can be either 32- or 64-bit, the app must have the
+android:multiarch property set to a value of true
+within its manifest to avoid potential errors.
    
+
+
    Product Configuration
    
+
+
+
    In BoardConfig.mk, we added the following variables to
+configure the second CPU architecture and ABI:
    
+
+
    +TARGET_2ND_ARCH
+TARGET_2ND_ARCH_VARIANT
+TARGET_2ND_CPU_VARIANT
+TARGET_2ND_CPU_ABI
+TARGET_2ND_CPU_ABI2
+
    
+
+
+
    You can see an example in build/target/board/generic_arm64/BoardConfig.mk.
    
+
+
    If you want the build system to build 32-bit executables and apps by default,
+set the following variable:
    
+
+
    +TARGET_PREFER_32_BIT := true
+
    
+
+
    However, you can override this setting  by using module-specific variables in
+Android.mk.
    
+
+
    In a Multilib build, module names in PRODUCT_PACKAGES cover
+both the 32-bit and 64-bit binaries, as long as they are defined by the build
+system. For libraries pulled in by dependency, a 32-bit library is installed
+only if it’s required by another 32-bit library or executable. The same is true
+for 64-bit libraries.
    
+
+
    However, module names on the make command line cover only the
+64-bit version. For example, after running lunch
+aosp_arm64-eng,make libc builds only the 64-bit libc. To
+build the 32-bit libc, you need to run make libc_32.
    
+
+
    Module Definition in Android.mk
    
+
+
    You can use the LOCAL_MULTILIB variable to configure your build
+for 32-bit and/or 64-bit and override the global
+TARGET_PREFER_32_BIT.
    
+
+
    Set LOCAL_MULTILIB to one of the following:
    
+
+
      
+  
    • "both”: build both 32-bit and 64-bit.
      • 
+  
    • “32”: build only 32-bit.
      • 
+  
    • “64”: build only 64-bit.
      • 
+  
    • “first”: build for only the first arch (32-bit in 32-bit devices and 64-bit
+in 64-bit devices).
      • 
+  
    • “”: the default; the build system decides what arch to build based on the
+module class and other LOCAL_ variables, such as LOCAL_MODULE_TARGET_ARCH,
+LOCAL_32_BIT_ONLY, etc.
      • 
+
    
+
+
    In a Multilib build, conditionals like ifeq $(TARGET_ARCH) don’t work any
+more. 
    
+
+
    If you want to build your module for some specific arch(s), the following
+variables can help you:
    
+
+
      
+  
    • LOCAL_MODULE_TARGET_ARCH
      It can be set to a list of archs, something
+like “arm x86 arm64”. Only if the arch being built is among that list will the
+current module be included by the build system.
      • 
+
+  
    • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH
      The opposite of
+LOCAL_MODULE_TARGET_ARCH. Only if the arch being built is not among the list,
+the current module will be included.
      • 
+
    
+
+
    There are minor variants of the above two variables:
    
+
+
      
+  
    • LOCAL_MODULE_TARGET_ARCH_WARN
      • 
+  
    • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
      • 
+
    
+
+
    The build system will give warning if the current module is skipped due to
+archs limited by them.
    
+
+
    To set up arch-specific build flags, use the arch-specific LOCAL_ variables. An
+arch-specific LOCAL_ variable is a normal LOCAL_ variable with an arch suffix,
+for example:
    
+
+
      
+  
    •  LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
+  
    •  LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
+  
    •  LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,
+
    
+
+
    Those variables will be applied only if a binary is  currently being built for
+that arch.
    
+
+
    Sometimes it’s more convenient to set up flags based on whether the binary is
+currently being built for 32-bit or 64-bit. In that case you can use the LOCAL_
+variable with a _32 or _64 suffix, for example:
    
+
+
      
+  
    •  LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
+  
    •  LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
+  
    •  LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,
+
    
+
+
    Note that not all of the LOCAL_ variables support the arch-specific variants.
+For an up-to-date list of such variables, refer to build/core/clear_vars.mk.
    
+
+
    Install path
    
+
+
+
    In the past, you could use LOCAL_MODULE_PATH to install a library to a
+location other than the default one. For example, LOCAL_MODULE_PATH :=
+$(TARGET_OUT_SHARED_LIBRARIES)/hw.
    
+
+
    In Multilib build, use LOCAL_MODULE_RELATIVE_PATH instead:
    
+
+
    +LOCAL_MODULE_RELATIVE_PATH := hw
+
    
+
+
+
    so that both the 64-bit and 32-bit libraries can be installed to the right
+place.
    
+
+
    If you build an executable as both 32-bit and 64-bit, you’ll need to use one of
+the following variables to distinguish the install path:
    
+
+
      
+  
    • LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64
      Specifies the installed file name.
+  
    • LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64
      Specifies the install path.
+
    
+
+
    Generated sources 
    
+
+
    In a Multilib build,  if you generate source files to
+$(local-intermediates-dir) (or $(intermediates-dir-for)
+with explicit variables), it won’t reliably work any more. That’s
+because the intermediate generated sources will be required by both 32-bit and
+64-bit build, but $(local-intermediates-dir) only points to one of
+the two intermediate directories.
    
+
+
    Happily, the build system now provides a dedicated, Multilib-friendly,
+intermediate directory for generating sources. You can call
+$(local-generated-sources-dir) or
+$(generated-sources-dir-for) to get the directory’s path. Their
+usages are similar to $(local-intermediates-dir) and
+$(intermediates-dir-for). 
    
+
+
    If a source file is generated to the new dedicated directory and picked up
+by LOCAL_GENERATED_SOURCES, it is built for both 32-bit and 64-bit
+in multilib build.
    
+
+
    Prebuilts
    
+
+
+
    In Multilib, you can’t use TARGET_ARCH (or together with
+TARGET_2ND_ARCH) to tell the build system what arch the prebuilt
+binary is targeted for. Use the aforementioned LOCAL_ variable
+LOCAL_MODULE_TARGET_ARCH or
+LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH instead.
    
+
+
    With these variables, the build system can choose the corresponding 32-bit
+prebuilt binary even if it’s currently doing a 64-bit Multilib build.
    
+
+
    If you want to use the chosen arch to compute the source path for the prebuilt
+binary , you can call $(get-prebuilt-src-arch).
    
+
+
    Dex-preopt
    
+
+
+
    For 64-bit devices, by default we generate both 32-bit and 64-bit odex files
+for the boot image and any Java libraries. For APKs, by default we generate
+odex only for the primary 64-bit arch. If an app will be launched in both
+32-bit and 64-bit processes, please use LOCAL_MULTILIB := both to make sure
+both 32-bit and 64-bit odex files are generated. That flag also tells the build
+system to include both 32-bit and 64-bit JNI libraries, if the app has any.
    
+
+
+  
+
diff --git a/en/setup/_toc.yaml b/en/setup/_toc.yaml
new file mode 100644
index 00000000..cccaa49e
--- /dev/null
+++ b/en/setup/_toc.yaml
@@ -0,0 +1,71 @@
+toc:
+- title: Getting Started
+  section:
+  - title: Overview
+    path: /setup/
+  - title: Codelines, Branches, and Releases
+    path: /setup/code-lines
+  - title: Codenames, Tags, and Build Numbers
+    path: /setup/build-numbers
+  - title: Project Roles
+    path: /setup/roles
+  - title: Brand Guidelines
+    path: /setup/brands
+  - title: Licenses
+    path: /setup/licenses
+  - title: FAQ
+    path: /setup/faqs
+  - title: Site Updates
+    path: /setup/site-updates
+- title: Downloading and Building
+  section:
+  - title: Requirements
+    path: /setup/requirements
+  - title: Establishing a Build Environment
+    path: /setup/initializing
+  - title: Downloading the Source
+    path: /setup/downloading
+  - title: Preparing to Build
+    path: /setup/building
+  - title: Compiling with Jack
+    path: /setup/jack
+  - title: Using Reference Boards
+    path: /setup/devices
+  - title: Running Builds
+    path: /setup/running
+  - title: Building Kernels
+    path: /setup/building-kernels
+  - title: Known Issues
+    path: /setup/known-issues
+- title: Developing
+  section:
+  - title: Overview
+    path: /setup/developing
+  - title: Using Repo
+    path: /setup/using-repo
+  - title: Learning Git
+    path: /setup/git-resources
+  - title: Adding a New Device
+    path: /setup/add-device
+  - title: Understanding 64-bit Builds
+    path: /setup/64-bit-builds
+- title: Contributing
+  section:
+  - title: Overview
+    path: /setup/contributing
+  - title: Life of a Patch
+    path: /setup/life-of-a-patch
+  - title: Submitting Patches
+    path: /setup/submit-patches
+  - title: View Patches
+    path: /setup/view-patches
+  - title: Life of a Bug
+    path: /setup/life-of-a-bug
+  - title: Reporting Bugs
+    path: /setup/report-bugs
+  - title: Reading Bug Reports
+    path: /setup/read-bug-reports
+  - title: Java Code Style Rules
+    path: /setup/code-style
+- title: Community
+  path: /setup/community
diff --git a/en/setup/_translation.yaml b/en/setup/_translation.yaml
new file mode 100644
index 00000000..de17f36f
--- /dev/null
+++ b/en/setup/_translation.yaml
@@ -0,0 +1,10 @@
+enable_continuous_translation: True
+title: Android Open Source Project Setup tab
+description: Translations for SAC Setup tab
+language:
+- zh-CN
+cc:
+- sac-doc-leads+translation@google.com
+reviewer:
+- daroberts
+product: Android
diff --git a/en/setup/add-device.html b/en/setup/add-device.html
new file mode 100644
index 00000000..bd869f97
--- /dev/null
+++ b/en/setup/add-device.html
@@ -0,0 +1,475 @@
+
+  
+    Adding a New Device
+    
+    
+  
+  
+  
+
+
+
+
    Use the information in this page to create the Makefiles for your device and
+product. Please note, unlike the other pages in this section, the contents here
+are applicable only when creating an entirely new device type and are intended
+for company build and product teams only.
    
+
+
    Understand Build Layers
    
+
+
    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 product. 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.
    
+
+
    
 
 
 
    
 RestrictionsNo network access, wake lock, or GPS/Wi-FI scan. Alarms and jobs/syncs deferred.No network access. Jobs/syncs deferred except during maintenance windows.No network access, wake lock, or GPS/Wi-FI scan. Alarms and jobs/syncs
+deferred.No network access. Jobs/syncs deferred except during maintenance windows.
+
 
    
 
    
 Behavior
 Only high-priority push notification messages received.All real-time messages (instant messages, calls, etc.) received. High-priority push
-  notification message enables temporary network access.All real-time messages (instant messages, calls, etc.) received.
+High-priority push notification message enables temporary network access.
 
    
 
    
 Exit
 
    
  
    
     October 2017Coming soon
-     
     
     October 2, 2017
     2017-10-01
    
@@ -101,15 +100,13 @@ Android Open Source Project (AOSP), the upstream Linux kernel, and system-on-chi
  
    
  
    
     September 2017Coming soon
-     
     
     September 5, 2017
     2017-09-01
    
@@ -117,15 +114,13 @@ Android Open Source Project (AOSP), the upstream Linux kernel, and system-on-chi
  
    
  
    
     August 2017Coming soon
-     
     
     August 7, 2017
     2017-08-01
    
diff --git a/en/security/bulletin/pixel/index.html b/en/security/bulletin/pixel/index.html
index 2df49896..4b18dd6e 100644
--- a/en/security/bulletin/pixel/index.html
+++ b/en/security/bulletin/pixel/index.html
@@ -75,15 +75,13 @@ AOSP 24–48 hours after the Pixel / Nexus bulletin is release
  
    
  
    
     October 2017Coming soon
-     
     
     October 2, 2017
     2017-10-05
 
 
 
 
    
+ 
+  
+  
+  
+ 
+  
+    
+    
+    
+
+  
+ 
+    
+    
+    
+  
+
+    
+    
+    
+  
+
    LayerExampleDescription
    ProductmyProduct, myProduct_eu, myProduct_eu_fr, j2, sdkThe 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.
+
    Board/Devicesardine, trout, goldfishThe device/board 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. This layer also represents the bare
+    schematics of a product. These include the peripherals on the board and their
+    configuration. The names used are merely codes for different board/device
+    configurations.
    Archarm, x86, mips, arm64, x86_64, mips64The architecture layer describes the processor configuration and ABI
+    (Application Binary Interface) running on the board. 
    
+
+
    Use Build Variants
    
+
+
    When building for a particular product, it's often useful to have minor
+variations on what is ultimately the final release build. In a module
+definition, the module can specify tags with LOCAL_MODULE_TAGS,
+which can be one or more values of optional (default),
+debug, eng.
    
+
+
    If a module doesn't specify a tag (by LOCAL_MODULE_TAGS), its
+tag defaults to optional. An optional module is installed only if
+it is required by product configuration with PRODUCT_PACKAGES.
+
+
    These are the currently-defined build variants:
    
+
+
+
+    
+    
+
+
+    
+    
+
+
+    
+    
+
+
    
+        eng
+    
+        This is the default flavor.
+
      
+
    • Installs modules tagged with: eng and/or debug.
      • 
+
    • Installs modules according to the product definition files, in
+addition to tagged modules.
      • 
+
    • ro.secure=0
      • 
+
    • ro.debuggable=1
      • 
+
    • ro.kernel.android.checkjni=1
      • 
+
    • adb is enabled by default.
      • 
+
    
+    
    
+        user
+    
+        This is the flavor intended to be the final release bits.
+
      
+
    • Installs modules tagged with user.
      • 
+
    • Installs modules according to the product definition files, in
+addition to tagged modules.
      • 
+
    • ro.secure=1 
      • 
+
    • ro.debuggable=0 
      • 
+
    • adb is disabled by default.
      • 
+
    
+    
    
+        userdebug
+    
+        The same as user, except:
+
      
+
    • Also installs modules tagged with debug.
      • 
+
    • ro.debuggable=1
      • 
+
    • adb is enabled by default.
      • 
+
    
+    
    
+
+
    Customize the Build with Resource Overlays
    
+
+
    The Android build system uses resource overlays to customize
+a product at build time. Resource overlays specify resource
+files that are applied on top of the defaults. To use resource overlays, modify the project
+buildfile to set PRODUCT_PACKAGE_OVERLAYS to a
+path relative to your top-level directory. That path becomes a shadow root searched along with
+the current root  when the build system searches for resources.
    
+
+
    The most commonly customized settings are contained in the file frameworks/base/core/res/res/config.xml.
    
+
+
     To set up a resource overlay on this file, add the overlay directory to the
+project buildfile, as follows:
    
+
+
    +PRODUCT_PACKAGE_OVERLAYS := device/DEVICE_IMPLEMENTER/DEVICE_NAME/overlay
+
    
+
+
    or
    
+
+
    +PRODUCT_PACKAGE_OVERLAYS := vendor/VENDOR_NAME/overlay
+
    
+
+
     Then, add an overlay file to the directory, for example:
    
+
+
    +vendor/foobar/overlay/frameworks/base/core/res/res/config.xml
+
    
+
+
     Any strings or string arrays found in the overlay config.xml file replace
+those found in the original file.
    
+
+
    Build a Product
    
+
+
    
+There are many ways to organize the source files for your device. We'll briefly
+go over how the Nexus 6 implementation was organized as an example, but you can
+organize your source files and build the way you see fit.
+
    
+
    
+Nexus 6 was implemented with a main device configuration named
+shamu. From this device configuration, 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
+device/moto/shamu directory to see how all of this is setup.
+
    
+
    Write the Makefiles
    
+
    
+  The following steps describe how to set up product Makefiles in a way similar
+to that of the Nexus 6 product line:
+
    
+
      
+  
    1. Create a device/<company_name>/<device_name> directory for your
+  product. For example, device/moto/shamu. This directory will contain source code
+  for your device along with the Makefiles to build them.
+  
      2. 
+
+  
    2. Create a device.mk Makefile that declares the files and modules needed for the
+  device. For an example, see device/moto/shamu/device.mk.
+  
      3. 
+
+  
    3. Create a product definition Makefile to create a specific product based on the device. The
+  following Makefile is taken from device/moto/shamu/aosp_shamu.mk as an example.
+  Notice the product is inheriting from the
+  device/moto/shamu/device.mk and
+  vendor/moto/shamu/device-vendor.mk files via the Makefile while
+  also declaring the product-specific information such as name, brand, and model.
+
+
      +# Inherit from the common Open Source product configuration
+$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
+
+PRODUCT_NAME := aosp_shamu
+PRODUCT_DEVICE := shamu
+PRODUCT_BRAND := Android
+PRODUCT_MODEL := AOSP on Shamu
+PRODUCT_MANUFACTURER := motorola
+PRODUCT_RESTRICT_VENDOR_FILES := true
+
+$(call inherit-product, device/moto/shamu/device.mk)
+$(call inherit-product-if-exists, vendor/moto/shamu/device-vendor.mk)
+
+PRODUCT_NAME := aosp_shamu
+
+PRODUCT_PACKAGES += \
+    Launcher3
+
      
+
+    
      
+      See Product Definition Variables for additional product-specific
+      variables you can add to your Makefiles.
+    
      
+  
      4. 
+
+  
    4. Create an AndroidProducts.mk file that points to the product's Makefiles. In
+  this example, only the product definition Makefile is needed. The example below is from
+  device/moto/shamu/AndroidProducts.mk:
+
      +#
+# 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)/aosp_shamu.mk
+
      
+  
      5. 
+
+  
    5. Create a BoardConfig.mk Makefile that contains board-specific configurations.
+  For an example, see device/moto/shamu/BoardConfig.mk.
+  
      6. 
+
+  
    6. Create a vendorsetup.sh file to add your product (a "lunch combo") to the build
+  along with a build variant separated by a dash. For example:
+
      +add_lunch_combo <PRODUCT_NAME>-userdebug
+
      
+  
      7. 
+
+  
    7. At this point, you can create more product variants based on the same device.
+  
      8. 
+
+
    
+
    Set Product Definition Variables
    
+
    
+  Product-specific variables are defined in the product's Makefile. Variables maintained in a
+  product definition files include:
+
    
+
+  
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+      
+      
+    
+  
+
    
+        Parameter
+      
+        Description
+      
+        Example
+      
    
+        PRODUCT_AAPT_CONFIG
+      
+        aapt configurations to use when creating packages
+      
    
+        PRODUCT_BRAND
+      
+        The brand (e.g., carrier) the software is customized for, if any
+      
    
+        PRODUCT_CHARACTERISTICS
+      
+        aapt characteristics to allow adding variant-specific resources to a package.
+      
+        tablet,nosdcard
+      
    
+        PRODUCT_COPY_FILES
+      
+        List of words like source_path:destination_path. 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
+      
    
+        PRODUCT_DEVICE
+      
+        Name of the industrial design. This is also the board name, and the build system uses it to locate the BoardConfig.mk.
+      
+        tuna
+      
    
+        PRODUCT_LOCALES
+      
+        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 used as the product's default locale.
+      
+        en_GB de_DE es_ES fr_CA
+      
    
+        PRODUCT_MANUFACTURER
+      
+        Name of the manufacturer
+      
+        acme
+      
    
+        PRODUCT_MODEL
+      
+        End-user-visible name for the end product
+      
    
+        PRODUCT_NAME
+      
+        End-user-visible name for the overall product. Appears in the Settings > About screen.
+      
    
+        PRODUCT_OTA_PUBLIC_KEYS
+      
+        List of Over the Air (OTA) public keys for the product
+      
    
+        PRODUCT_PACKAGES
+      
+        Lists the APKs and modules to install.
+      
+        Calendar Contacts
+      
    
+        PRODUCT_PACKAGE_OVERLAYS
+      
+        Indicate whether to use default resources or add any product specific overlays
+      
+        vendor/acme/overlay
+      
    
+        PRODUCT_PROPERTY_OVERRIDES
+      
+        List of system property assignments in the format "key=value"
+      
    
+
+
    Set ANDROID_VENDOR_KEYS to connect over USB
    
+
+
    The ANDROID_VENDOR_KEYS environment variable enables device
+manufacturers to access production builds over adb. Generate a key
+for each release that every device will accept, store those internally (such as at
+vendor/oem-name/security/adb/), and then use
+ANDROID_VENDOR_KEYS to tell adb to use these canonical
+keys rather than random keys.
    
+
+
    Use the ANDROID_VENDOR_KEYS environment variable to
+point to the directory containing the generated adb public and
+private keys used for encryption. The private key is stored in file. The public
+key is stored in file.pub. The ANDROID_VENDOR_KEYS environment
+variable points to a file or directory where the generated key pairs are
+stored.
    
+
+
    This variable is set to a file or directory that contains 2048-bit RSA
+authentication key pairs generated with the adb keygen file command.
+These key pairs are in addition to the RSA key pairs generated by the ADB
+server. An RSA key pair is needed when you use adb to connect over
+USB for the first time.
    
+
+
    You must accept the host computer's RSA key to explicitly grant
+adb access to the device. By default key pairs generated by the
+ADB server are stored in the following key store directories as
+adbkey (private key) and adbkey.pub (public key):
    
+
+
    For file locations, on MacOS, this will likely be:
+$HOME/.android.  On Windows and Linux, this will be:
+%USERPOFILE%\.android. On Windows, RSA authentication keys can
+also be in C:\Windows\System32\config\systemprofile\.android in
+some cases. When the ADB server needs a key, it first searches the ADB server
+key store directory. If no keys are found, it then checks the
+ANDROID_VENDOR_KEYS environment variable. If no keys are found,
+the local ADB server generates and saves a new key pair in the ADB server key
+store directory.
    
+
+
    Note: You can override the default directory
+where the ADB server stores RSA keys by setting the
+ANDROID_SDK_HOME environment variable. On the device, keys are
+stored in the /data/misc/adb/adb_keys/ file, and new authorized
+keys are appended to the same file as you accept them.
    
+
+  
+
diff --git a/en/setup/assets/bg_fade.jpg b/en/setup/assets/bg_fade.jpg
new file mode 100644
index 00000000..c6c70b6f
Binary files /dev/null and b/en/setup/assets/bg_fade.jpg differ
diff --git a/en/setup/assets/bg_images_sprite.png b/en/setup/assets/bg_images_sprite.png
new file mode 100644
index 00000000..84437e79
Binary files /dev/null and b/en/setup/assets/bg_images_sprite.png differ
diff --git a/en/setup/assets/images/sac_logo.png b/en/setup/assets/images/sac_logo.png
new file mode 100644
index 00000000..4ad113c4
Binary files /dev/null and b/en/setup/assets/images/sac_logo.png differ
diff --git a/en/setup/assets/rebox-gradient.gif b/en/setup/assets/rebox-gradient.gif
new file mode 100644
index 00000000..124e844c
Binary files /dev/null and b/en/setup/assets/rebox-gradient.gif differ
diff --git a/en/setup/brands.html b/en/setup/brands.html
new file mode 100644
index 00000000..17927169
--- /dev/null
+++ b/en/setup/brands.html
@@ -0,0 +1,157 @@
+
+  
+    Brand Guidelines
+    
+    
+  
+  
+  
+
+
+
+
    The "Android" name, the  logo,
+the "Google Play" brand, and other trademarks are property of Google Inc. and
+not part of the assets available through the Android Open Source Project.
    
+
+
    If you are interested in using these brands to indicate their association
+with your device, adhere to the guidelines on this page. These guidelines
+correspond to and complement the
+Brand
+Guidelines for Android App Developers and
+Google Brand Permissions.
    
+
+
    Android
    
+
+
    Here are manufacturer guidelines for the Android brand and related
+assets.
    
+
+
    Android in text
    
+
      
+  
    • Android™ should have a trademark symbol the first time it appears in
+  a creative.
      • 
+  
    • "Android" should always be capitalized and is never plural or possessive.
+  
      • 
+  
    • The use of “Android” on hardware, packaging or marketing materials of
+  device is restricted to
+  Android-compatible devices
+  only.
      • 
+  
    • “Android” should never be used in the name of your product or as the
+  primary or dominant mark on your packaging or device.
      • 
+  
    • "Android” should be used only as a term to refer to the operating system
+  (OS) of your device. If you are unsure whether your use meets our guidelines,
+  follow this simple test: If you can replace "Android" with "the Android
+  platform" and the text still makes sense, then you may use this term.
+  
        
+    
      • Incorrect: "Android XBrand Phone"
        • 
+    
      • Correct: "XBrand phone on Android"
        • 
+  
      
+  
      • 
+  
    • You may use “with Android” in plain black text with your logo. If used
+  with your logo, "with Android" should be no larger than 90% of your logo’s
+  size. First or most prominent instance of this use should be followed by a
+  ™ symbol.
      • 
+  
    • Android may be used only as a descriptor, as long as it is
+  followed by a proper generic term. It cannot be framed as the product name or
+  brand of your device.
+  
        
+    
      • Incorrect: "Android XBrand Phone"
        • 
+    
      • Correct: "Android mobile device"
        • 
+  
      
+  
      Any use of the Android name must include this attribution in your
+  communication:
      
+  
      Android is a trademark of Google Inc.
      
+  
      • 
+
    
+
+
    Acceptable examples
    
+Jelly Bean trademark example
+8100 series trademark example
+
+
    Unacceptable example
    
+XBrand trademark example
+
+
    Android logo
    
+
    Unless expressly authorized by Google through written agreement, the Android
+logo and custom typeface may not be used (with or without the Android robot).
    
+No Logo
+No Logo
+
+
    Android robot
    
+
+
    
+
    
+  android-robot
+  
    
+  100x118
    
+  200x237
    
+  Illustrator
+  
    
+
    
+
    
+
    The Android robot can be used, reproduced, and
+modified freely in marketing communications with proper attribution. For
+details, refer to
+App
+Developers Brand Guidelines and the
+Creative Commons
+license.
    
+
    
+
    
+
+
    
+
    
+no-peace-robot
+
    
+
    
+
    The Android Peace Robot or any variation of the
+Android Peace Robot (such as the Android robot with a peace sign) may not be
+used in partner marketing.
    
+
    
+
    
+
+
    
+
    Google Play
    
+
+
    Use of the “Google Play” name and the Google Play Store icon on the
+packaging of the hardware, marketing materials of the hardware, or the hardware
+itself is allowed only on devices
+licensed
+to access Google Play. For a list of devices licensed to use Google Play,
+refer to
+Supported
+devices.
    
+
+
+
    Other brands
    
+
    Android Auto,
+Android TV, and
+Android Wear are brands owned by
+Google. These brands require Google proprietary software that runs on top of
+Android and is available only through a license with Google. For information on
+how to request a license, see
+Contact Us.
+
+
    Questions
    
+
+
    For additional brand usage information, contact the Android Partner
+Marketing team by submitting the Partner
+Brand Inquiry Form.
    
+
+  
+
diff --git a/en/setup/build-numbers.html b/en/setup/build-numbers.html
new file mode 100644
index 00000000..1236ec35
--- /dev/null
+++ b/en/setup/build-numbers.html
@@ -0,0 +1,2281 @@
+
+  
+    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 Codenames, 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 nameVersionAPI level
    Oreo8.0.0API level 26
    Nougat7.1API level 25
    Nougat7.0API level 24
    Marshmallow6.0API level 23
    Lollipop5.1API level 22
    Lollipop5.0API level 21
    KitKat4.4 - 4.4.4API level 19
    Jelly Bean4.3.xAPI level 18
    Jelly Bean4.2.xAPI level 17
    Jelly Bean4.1.xAPI level 16
    Ice Cream Sandwich4.0.3 - 4.0.4API level 15, NDK 8
    Ice Cream Sandwich4.0.1 - 4.0.2API level 14, NDK 7
    Honeycomb3.2.xAPI level 13
    Honeycomb3.1API level 12, NDK 6
    Honeycomb3.0API level 11
    Gingerbread2.3.3 - 2.3.7API level 10
    Gingerbread2.3 - 2.3.2API level 9, NDK 5
    Froyo2.2.xAPI level 8, NDK 4
    Eclair2.1API level 7, NDK 3
    Eclair2.0.1API level 6
    Eclair2.0API level 5
    Donut1.6API level 4, NDK 2
    Cupcake1.5API level 3, NDK 1
    (no code name)1.1API level 2
    (no code name)1.0API level 1
    
+
    Starting with Oreo, individual builds are identified with a new build ID format, in the form of PVBB.YYMMDD.bbb.
    
+
    The P part represents the first letter of the code name of the platform release, e.g. O is Oreo.
    
+
    The V part represents a supported vertical. By convention, 'P' represents the primary platform branch.
    
+
    The BB part represents a alpha numeric code which allows Google to identify the exact code branch that the build was made from.
    
+
    The YYMMDD part identifies the date when the release is branched from or synced with the development branch.  It 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.
    
+
    The bbb part identifies individual versions related to the same date code, sequentially starting with 001.
    
+
    Older Android releases from Cupcake to Nougat uses a different build ID scheme.  These Android 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. Factory images, binaries, and full OTA images for
+Nexus and Pixel devices can be downloaded from the Android Developer
+site:
    
+
    Images
    
+
    Drivers
    
+
    OTA
    
+
+  
+    
+      
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+
    BuildBranchVersionSupported devices
    OPD3.170816.023android-8.0.0_r34OreoPixel 2 XL, Pixel 2
    OPD1.170816.025android-8.0.0_r33OreoPixel 2 XL, Pixel 2
    OPR6.170623.023android-8.0.0_r32OreoNexus 5X
    OPR5.170623.011android-8.0.0_r31OreoNexus 6P
    OPR3.170623.013android-8.0.0_r30OreoPixel XL, Pixel
    OPR2.170623.027android-8.0.0_r29OreoNexus Player
    OPR1.170623.032android-8.0.0_r28OreoPixel XL, Pixel, Pixel C
    OPD3.170816.016android-8.0.0_r27OreoPixel 2
    OPD2.170816.015android-8.0.0_r26OreoPixel 2
    OPD1.170816.018android-8.0.0_r25OreoPixel 2
    OPD3.170816.012android-8.0.0_r24OreoPixel 2 XL, Pixel 2
    OPD1.170816.012android-8.0.0_r23OreoPixel 2 XL, Pixel 2
    OPD1.170816.011android-8.0.0_r22OreoPixel 2 XL, Pixel 2
    OPD1.170816.010android-8.0.0_r21OreoPixel 2 XL, Pixel 2
    OPR5.170623.007android-8.0.0_r17OreoNexus 6P
    OPR4.170623.009android-8.0.0_r16OreoNexus 5X
    OPR3.170623.008android-8.0.0_r15OreoPixel XL, Pixel
    OPR1.170623.027android-8.0.0_r13OreoPixel XL, Pixel, Pixel C
    OPR6.170623.021android-8.0.0_r12OreoNexus Player
    OPR6.170623.019android-8.0.0_r11OreoNexus 6P
    OPR4.170623.006android-8.0.0_r10OreoNexus 5X
    OPR3.170623.007android-8.0.0_r9OreoPixel XL, Pixel
    OPR1.170623.026android-8.0.0_r7OreoPixel XL, Pixel, Pixel C
    OPR6.170623.013android-8.0.0_r4OreoNexus 5X, Nexus 6P
    OPR6.170623.012android-8.0.0_r3OreoPixel XL, Pixel
    OPR6.170623.011android-8.0.0_r2OreoPixel XL, Pixel
    OPR6.170623.010android-8.0.0_r1OreoPixel C
    NZH54Dandroid-7.1.2_r33NougatPixel XL, Pixel
    NKG47Sandroid-7.1.2_r32NougatPixel XL, Pixel
    NHG47Qandroid-7.1.2_r30NougatPixel XL, Pixel
    NJH47Fandroid-7.1.2_r29NougatPixel XL, Pixel
    N2G48Candroid-7.1.2_r28NougatNexus 5X, Nexus 6P, Nexus Player, Pixel C
    NZH54Bandroid-7.1.2_r27NougatPixel XL, Pixel
    NKG47Mandroid-7.1.2_r25NougatPixel XL, Pixel
    NJH47Dandroid-7.1.2_r24NougatPixel XL, Pixel
    NHG47Oandroid-7.1.2_r23NougatPixel XL, Pixel
    N2G48Bandroid-7.1.2_r19NougatNexus 6P, Nexus Player, Pixel C
    N2G47Zandroid-7.1.2_r18NougatNexus 5X
    NJH47Bandroid-7.1.2_r17NougatPixel XL, Pixel
    NJH34Candroid-7.1.2_r16NougatPixel XL, Pixel
    NKG47Landroid-7.1.2_r15NougatPixel XL, Pixel
    NHG47Nandroid-7.1.2_r14NougatPixel XL, Pixel
    N2G47Xandroid-7.1.2_r13NougatNexus Player
    N2G47Wandroid-7.1.2_r12NougatNexus 5X, Nexus 6P, Pixel C
    NHG47Landroid-7.1.2_r11NougatPixel XL, Pixel
    N2G47Tandroid-7.1.2_r10NougatPixel XL, Pixel
    N2G47Randroid-7.1.2_r9NougatNexus Player
    N2G47Oandroid-7.1.2_r8NougatNexus 5X, Nexus 6P, Pixel XL, Pixel, Pixel C
    NHG47Kandroid-7.1.2_r6NougatPixel XL, Pixel
    N2G47Jandroid-7.1.2_r5NougatPixel XL, Pixel
    N2G47Handroid-7.1.2_r4NougatNexus 6P, Nexus Player
    N2G47Fandroid-7.1.2_r3NougatNexus 5X
    N2G47Eandroid-7.1.2_r2NougatPixel XL, Pixel
    N2G47Dandroid-7.1.2_r1NougatPixel C
    N9F27Mandroid-7.1.1_r58NougatNexus 9 (volantis)
    NGI77Bandroid-7.1.1_r57NougatNexus 6
    N6F27Mandroid-7.1.1_r55NougatNexus 6
    N4F27Pandroid-7.1.1_r54NougatNexus 9 (volantisg)
    N9F27Landroid-7.1.1_r53NougatNexus 9
    NGI55Dandroid-7.1.1_r52NougatNexus 6
    N4F27Oandroid-7.1.1_r51NougatNexus 9 (volantisg)
    N8I11Bandroid-7.1.1_r50NougatNexus 6
    N9F27Handroid-7.1.1_r49NougatNexus 9 (volantis)
    N6F27Iandroid-7.1.1_r48NougatNexus 6
    N4F27Kandroid-7.1.1_r47NougatNexus 9 (volantisg)
    N9F27Fandroid-7.1.1_r46NougatNexus 9 (volantis)
    N6F27Handroid-7.1.1_r45NougatNexus 6
    N4F27Iandroid-7.1.1_r44NougatNexus 9 (volantisg)
    N9F27Candroid-7.1.1_r43NougatNexus 9 (volantis)
    N6F27Eandroid-7.1.1_r42NougatNexus 6
    N4F27Eandroid-7.1.1_r41NougatNexus 9 (volantisg)
    N6F27Candroid-7.1.1_r40NougatNexus 6
    N4F27Bandroid-7.1.1_r39NougatNexus 9 (volantis/volantisg)
    N6F26Yandroid-7.1.1_r38NougatNexus 6
    NOF27Dandroid-7.1.1_r35NougatPixel XL, Pixel
    N4F26Xandroid-7.1.1_r33NougatNexus 9 (volantis/volantisg)
    N4F26Uandroid-7.1.1_r31NougatNexus 5X, Nexus 6P
    N6F26Uandroid-7.1.1_r28NougatNexus 6
    NUF26Nandroid-7.1.1_r27NougatNexus 6P
    NOF27Candroid-7.1.1_r26NougatPixel XL, Pixel
    NOF27Bandroid-7.1.1_r25NougatPixel XL, Pixel
    N4F26Tandroid-7.1.1_r24NougatNexus 5X, Nexus 6P, Nexus 9 (volantis/volantisg), Pixel C
    NMF27Dandroid-7.1.1_r23NougatNexus Player
    NMF26Xandroid-7.1.1_r22NougatNexus Player
    NOF26Wandroid-7.1.1_r21NougatPixel XL, Pixel
    NOF26Vandroid-7.1.1_r20NougatPixel XL, Pixel
    N6F26Randroid-7.1.1_r17NougatNexus 6
    NUF26Kandroid-7.1.1_r16NougatNexus 6P
    N4F26Qandroid-7.1.1_r15NougatNexus 9 (volantis/volantisg)
    N4F26Oandroid-7.1.1_r14NougatNexus 5X, Nexus 6P, Pixel C
    N6F26Qandroid-7.1.1_r13NougatNexus 6
    N4F26Mandroid-7.1.1_r12NougatNexus 9 (volantis)
    N4F26Jandroid-7.1.1_r11NougatNexus 5X, Nexus 6P
    N4F26Iandroid-7.1.1_r10NougatNexus 5X, Nexus 6P, Pixel C
    NMF26Vandroid-7.1.1_r9NougatPixel XL, Pixel
    NMF26Uandroid-7.1.1_r8NougatPixel XL, Pixel
    NMF26Randroid-7.1.1_r7NougatNexus Player
    NMF26Qandroid-7.1.1_r6NougatPixel XL, Pixel
    NMF26Oandroid-7.1.1_r4NougatPixel XL, Pixel
    NMF26Jandroid-7.1.1_r3NougatNexus Player
    NMF26Handroid-7.1.1_r2NougatPixel C
    NMF26Fandroid-7.1.1_r1NougatNexus 5X, Nexus 6P, Nexus 9 (volantis/volantisg)
    NDE63Xandroid-7.1.0_r7NougatPixel XL, Pixel
    NDE63Vandroid-7.1.0_r6NougatPixel XL, Pixel
    NDE63Uandroid-7.1.0_r5NougatPixel XL, Pixel
    NDE63Pandroid-7.1.0_r4NougatPixel XL, Pixel
    NDE63Landroid-7.1.0_r2NougatPixel XL, Pixel
    NDE63Handroid-7.1.0_r1NougatPixel XL, Pixel
    NBD92Nandroid-7.0.0_r34Nougat
    NBD92Gandroid-7.0.0_r33NougatNexus 6
    NBD92Fandroid-7.0.0_r32NougatNexus 6
    NBD92Eandroid-7.0.0_r31NougatNexus 6
    NBD92Dandroid-7.0.0_r30NougatNexus 6
    NBD91Zandroid-7.0.0_r29NougatNexus 6
    NBD91Yandroid-7.0.0_r28NougatNexus 6
    NBD91Xandroid-7.0.0_r27NougatNexus 6
    NBD91Uandroid-7.0.0_r24NougatNexus 6
    N5D91Landroid-7.0.0_r21NougatNexus 5X
    NBD91Pandroid-7.0.0_r19NougatNexus 6
    NRD91Kandroid-7.0.0_r17NougatNexus 6P
    NRD91Nandroid-7.0.0_r15NougatNexus 5X, Pixel C, Nexus Player, Nexus 9 (volantis/volantisg)
    NBD90Zandroid-7.0.0_r14NougatNexus 6
    NBD90Xandroid-7.0.0_r13NougatNexus 6P
    NBD90Wandroid-7.0.0_r12NougatNexus 5X
    NRD91Dandroid-7.0.0_r7NougatPixel C, Nexus Player, Nexus 9 (Wi-Fi)
    NRD90Uandroid-7.0.0_r6NougatNexus 6P
    NRD90Tandroid-7.0.0_r5NougatNexus 6P
    NRD90Sandroid-7.0.0_r4NougatNexus 5X
    NRD90Randroid-7.0.0_r3NougatNexus 5X, Nexus 9 (volantis), Nexus Player, Pixel C
    NRD90Mandroid-7.0.0_r1NougatNexus 5X, Nexus 9 (volantis), Nexus Player, Pixel C
    MOI10Eandroid-6.0.1_r81Marshmallow
    MOB31Zandroid-6.0.1_r80Marshmallow
    MOB31Tandroid-6.0.1_r79MarshmallowNexus 6
    MOB31Sandroid-6.0.1_r78MarshmallowNexus 6
    M4B30Zandroid-6.0.1_r77MarshmallowNexus 5
    MOB31Kandroid-6.0.1_r74MarshmallowNexus 6
    MMB31Candroid-6.0.1_r73MarshmallowNexus 6
    M4B30Xandroid-6.0.1_r72MarshmallowNexus 5
    MOB31Handroid-6.0.1_r70MarshmallowNexus 6
    MMB30Yandroid-6.0.1_r69MarshmallowNexus 6
    MTC20Kandroid-6.0.1_r67MarshmallowNexus 5X
    MOB31Eandroid-6.0.1_r66MarshmallowNexus 5, Nexus 6, Nexus 9 (volantis)
    MMB30Wandroid-6.0.1_r65MarshmallowNexus 6
    MXC89Landroid-6.0.1_r63MarshmallowPixel C
    MTC20Fandroid-6.0.1_r62MarshmallowNexus 5X, Nexus 6P
    MOB30Yandroid-6.0.1_r60MarshmallowNexus 5
    MOB30Xandroid-6.0.1_r59MarshmallowNexus 7 (flo/deb)
    MOB30Wandroid-6.0.1_r58MarshmallowNexus 6, Nexus 9 (volantis/volantisg), Nexus Player
    MMB30Sandroid-6.0.1_r57MarshmallowNexus 7 (deb)
    MMB30Randroid-6.0.1_r56MarshmallowNexus 6
    MXC89Kandroid-6.0.1_r55MarshmallowPixel C
    MTC19Zandroid-6.0.1_r54MarshmallowNexus 5X
    MTC19Xandroid-6.0.1_r53MarshmallowNexus 6P
    MOB30Pandroid-6.0.1_r50MarshmallowNexus 5, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MOB30Oandroid-6.0.1_r49MarshmallowNexus 6
    MMB30Mandroid-6.0.1_r48MarshmallowNexus 7 (deb)
    MMB30Kandroid-6.0.1_r47MarshmallowNexus 6
    MOB30Mandroid-6.0.1_r46MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MTC19Vandroid-6.0.1_r45MarshmallowNexus 5X, Nexus 6P
    MOB30Jandroid-6.0.1_r43MarshmallowNexus 7 (flo/deb)
    MOB30Iandroid-6.0.1_r42MarshmallowNexus 6
    MOB30Handroid-6.0.1_r41MarshmallowNexus 5
    MOB30Gandroid-6.0.1_r40MarshmallowNexus 9 (volantis/volantisg), Nexus Player
    MXC89Handroid-6.0.1_r33MarshmallowPixel C
    MXC89Fandroid-6.0.1_r32MarshmallowPixel C
    MMB30Jandroid-6.0.1_r28MarshmallowNexus 6, Nexus 7 (deb)
    MTC19Tandroid-6.0.1_r25MarshmallowNexus 5X, Nexus 6P
    M5C14Jandroid-6.0.1_r31MarshmallowPixel C
    MOB30Dandroid-6.0.1_r30MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MHC19Qandroid-6.0.1_r24MarshmallowNexus 5X, Nexus 6P
    MHC19Jandroid-6.0.1_r22MarshmallowNexus 5X
    MHC19Iandroid-6.0.1_r21MarshmallowNexus 6P
    MMB29Xandroid-6.0.1_r20MarshmallowNexus 5, Nexus 6, Nexus 7 (deb), Nexus 9 (volantisg)
    MXC14Gandroid-6.0.1_r18MarshmallowPixel C
    MMB29Vandroid-6.0.1_r17MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 6P, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
    MXB48Tandroid-6.0.1_r16MarshmallowPixel C
    MMB29Uandroid-6.0.1_r13MarshmallowNexus Player
    MMB29Randroid-6.0.1_r12MarshmallowNexus 9 (volantis/volantisg)
    MMB29Qandroid-6.0.1_r11MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 6P, Nexus 7 (flo/deb)
    MMB29Tandroid-6.0.1_r10MarshmallowNexus Player
    MMB29Sandroid-6.0.1_r9MarshmallowNexus 5, Nexus 6, Nexus 9 (volantis/volantisg)
    MMB29Pandroid-6.0.1_r8MarshmallowNexus 5X, Nexus 6P
    MMB29Oandroid-6.0.1_r7MarshmallowNexus 7 (flo/deb)
    MXB48Kandroid-6.0.1_r5MarshmallowPixel C
    MXB48Jandroid-6.0.1_r4MarshmallowPixel C
    MMB29Mandroid-6.0.1_r3MarshmallowNexus 6P, Nexus Player
    MMB29Kandroid-6.0.1_r1MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
    MMB29Nandroid-6.0.0_r41MarshmallowNexus 6P
    MDB08Mandroid-6.0.0_r26MarshmallowNexus 5X, Nexus 6P
    MDB08Landroid-6.0.0_r25MarshmallowNexus 5X, Nexus 6P
    MDB08Kandroid-6.0.0_r24MarshmallowNexus 6P
    MDB08Iandroid-6.0.0_r23MarshmallowNexus 5X
    MDA89Eandroid-6.0.0_r12MarshmallowNexus 5X
    MDA89Dandroid-6.0.0_r11MarshmallowNexus 6P
    MRA59Bandroid-6.0.0_r7MarshmallowNexus 7 (deb)
    MRA58Xandroid-6.0.0_r6MarshmallowNexus 6
    MRA58Vandroid-6.0.0_r5MarshmallowNexus 7 (flo/deb)
    MRA58Uandroid-6.0.0_r4MarshmallowNexus 7 (flo)
    MRA58Nandroid-6.0.0_r2MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MRA58Kandroid-6.0.0_r1MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    LMY49Mandroid-5.1.1_r38LollipopNexus 10
    LMY49Jandroid-5.1.1_r37LollipopNexus 10
    LMY49Iandroid-5.1.1_r36LollipopNexus 10
    LMY49Handroid-5.1.1_r35LollipopNexus 10
    LMY49Gandroid-5.1.1_r34LollipopNexus 10
    LMY49Fandroid-5.1.1_r33LollipopNexus 9 (volantisg), Nexus 10
    LMY48Zandroid-5.1.1_r30LollipopNexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10
    LYZ28Nandroid-5.1.1_r28LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Yandroid-5.1.1_r26LollipopNexus 6
    LMY48Xandroid-5.1.1_r25LollipopNexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10
    LMY48Wandroid-5.1.1_r24LollipopNexus 6
    LVY48Handroid-5.1.1_r23LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Mandroid-5.1.1_r22LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Uandroid-5.1.1_r20LollipopNexus 7 (deb)
    LMY48Tandroid-5.1.1_r19LollipopNexus 4, Nexus 6, Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Fandroid-5.1.1_r18LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Kandroid-5.1.1_r17LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Pandroid-5.1.1_r16LollipopNexus 7 (deb)
    LMY48Nandroid-5.1.1_r15LollipopNexus Player
    LMY48Mandroid-5.1.1_r14LollipopNexus 4, Nexus 5, Nexus 6, Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Eandroid-5.1.1_r13LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Jandroid-5.1.1_r12LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Jandroid-5.1.1_r10LollipopNexus Player
    LMY48Iandroid-5.1.1_r9LollipopNexus 4, Nexus 5, Nexus 6, Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Candroid-5.1.1_r8LollipopNexus 6 (For Project Fi ONLY)
    LMY48Gandroid-5.1.1_r6LollipopNexus 7 (flo)
    LYZ28Eandroid-5.1.1_r5LollipopNexus 6 (For T-Mobile ONLY)
    LMY47Zandroid-5.1.1_r4LollipopNexus 6 (All carriers except T-Mobile US)
    LMY48Bandroid-5.1.1_r3LollipopNexus 5
    LMY47Xandroid-5.1.1_r2LollipopNexus 9 (volantis)
    LMY47Vandroid-5.1.1_r1LollipopNexus 7 (flo/grouper), Nexus 10, Nexus Player
    LMY47Oandroid-5.1.0_r5LollipopNexus 4, Nexus 7 (flo/deb)
    LMY47Mandroid-5.1.0_r4LollipopNexus 6 (For T-Mobile ONLY)
    LMY47Iandroid-5.1.0_r3LollipopNexus 5, Nexus 6
    LMY47Eandroid-5.1.0_r2LollipopNexus 6
    LMY47Dandroid-5.1.0_r1LollipopNexus 5, Nexus 6, Nexus 7 (grouper/tilapia), Nexus 10, Nexus Player
    LRX22Landroid-5.0.2_r3LollipopNexus 9 (volantis/volantisg)
    LRX22Gandroid-5.0.2_r1LollipopNexus 7 (flo/deb/grouper/tilapia), Nexus 10
    LRX22Candroid-5.0.1_r1LollipopNexus 4, Nexus 5, Nexus 6 (shamu), Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LRX21Vandroid-5.0.0_r7.0.1LollipopNexus Player (fugu)
    LRX21Tandroid-5.0.0_r6.0.1LollipopNexus 4
    LRX21Randroid-5.0.0_r5.1.0.1LollipopNexus 9 (volantis)
    LRX21Qandroid-5.0.0_r5.0.1LollipopNexus 9 (volantis)
    LRX21Pandroid-5.0.0_r4.0.1LollipopNexus 7 (flo/grouper), Nexus 10
    LRX21Oandroid-5.0.0_r3.0.1LollipopNexus 5 (hammerhead), Nexus 6 (shamu)
    LRX21Mandroid-5.0.0_r2.0.1LollipopNexus Player (fugu)
    LRX21Landroid-5.0.0_r1.0.1LollipopNexus 9 (volantis)
    KTU84Qandroid-4.4.4_r2KitKatNexus 5 (hammerhead) (For 2Degrees/NZ, Telstra/AUS and India ONLY)
    KTU84Pandroid-4.4.4_r1KitKatNexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KTU84Mandroid-4.4.3_r1.1KitKatNexus 5 (hammerhead)
    KTU84Landroid-4.4.3_r1KitKatNexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KVT49Landroid-4.4.2_r2KitKatNexus 7 (deb Verizon)
    KOT49Handroid-4.4.2_r1KitKat Nexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KOT49Eandroid-4.4.1_r1KitKatNexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KRT16Sandroid-4.4_r1.2KitKatNexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KRT16Mandroid-4.4_r1KitKatNexus 5 (hammerhead)
    JLS36Iandroid-4.3.1_r1Jelly BeanNexus 7 (deb)
    JLS36Candroid-4.3_r3Jelly Bean Nexus 7 (deb)
    JSS15Randroid-4.3_r2.3Jelly BeanNexus 7 (flo)
    JSS15Qandroid-4.3_r2.2Jelly BeanNexus 7 (flo)
    JSS15Jandroid-4.3_r2.1Jelly BeanNexus 7 (flo/deb)
    JSR78Dandroid-4.3_r2Jelly BeanNexus 7 (deb)
    JWR66Yandroid-4.3_r1.1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia), Nexus 4, Nexus 10
    JWR66Vandroid-4.3_r1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia), Nexus 4, Nexus 10
    JWR66Nandroid-4.3_r0.9.1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia/flo), Nexus 4, Nexus 10
    JWR66Landroid-4.3_r0.9Jelly BeanNexus 7
    JDQ39Eandroid-4.2.2_r1.2Jelly BeanNexus 4
    JDQ39Bandroid-4.2.2_r1.1Jelly BeanNexus 7
    JDQ39android-4.2.2_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JOP40Gandroid-4.2.1_r1.2Jelly BeanNexus 4
    JOP40Fandroid-4.2.1_r1.1Jelly BeanNexus 10
    JOP40Dandroid-4.2.1_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JOP40Candroid-4.2_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JZO54Mandroid-4.1.2_r2.1Jelly Bean
    JZO54Landroid-4.1.2_r2Jelly Bean
    JZO54Kandroid-4.1.2_r1Jelly BeanNexus S, Galaxy Nexus, Nexus 7
    JRO03Sandroid-4.1.1_r6.1Jelly BeanNexus 7
    JRO03Randroid-4.1.1_r6Jelly BeanNexus S 4G
    JRO03Oandroid-4.1.1_r5Jelly BeanGalaxy Nexus
    JRO03Landroid-4.1.1_r4Jelly BeanNexus S
    JRO03Handroid-4.1.1_r3Jelly Bean
    JRO03Eandroid-4.1.1_r2Jelly BeanNexus S
    JRO03Dandroid-4.1.1_r1.1Jelly BeanNexus 7
    JRO03Candroid-4.1.1_r1Jelly BeanGalaxy Nexus
    IMM76Landroid-4.0.4_r2.1Ice Cream Sandwich 
    IMM76Kandroid-4.0.4_r2Ice Cream SandwichGalaxy Nexus
    IMM76Iandroid-4.0.4_r1.2Ice Cream SandwichGalaxy Nexus
    IMM76Dandroid-4.0.4_r1.1Ice Cream SandwichNexus S, Nexus S 4G, Galaxy Nexus
    IMM76android-4.0.4_r1Ice Cream Sandwich
    IML77android-4.0.3_r1.1Ice Cream Sandwich
    IML74Kandroid-4.0.3_r1Ice Cream SandwichNexus S
    ICL53Fandroid-4.0.2_r1Ice Cream SandwichGalaxy Nexus
    ITL41Fandroid-4.0.1_r1.2Ice Cream SandwichGalaxy Nexus
    ITL41Dandroid-4.0.1_r1.1Ice Cream SandwichGalaxy Nexus
    ITL41Dandroid-4.0.1_r1Ice Cream SandwichGalaxy Nexus
    GWK74android-2.3.7_r1GingerbreadNexus S 4G
    GRK39Fandroid-2.3.6_r1GingerbreadNexus One, Nexus S
    GRK39Candroid-2.3.6_r0.9GingerbreadNexus S
    GRJ90android-2.3.5_r1GingerbreadNexus S 4G
    GRJ22android-2.3.4_r1GingerbreadNexus One, Nexus S, Nexus S 4G
    GRJ06Dandroid-2.3.4_r0.9GingerbreadNexus S 4G
    GRI54android-2.3.3_r1.1GingerbreadNexus S
    GRI40android-2.3.3_r1GingerbreadNexus One, Nexus S
    GRH78Candroid-2.3.2_r1GingerbreadNexus S
    GRH78android-2.3.1_r1GingerbreadNexus S
    GRH55android-2.3_r1Gingerbreadearliest Gingerbread version, Nexus S
    FRK76Candroid-2.2.3_r2Froyo 
    FRK76android-2.2.3_r1Froyo
    FRG83Gandroid-2.2.2_r1FroyoNexus One
    FRG83Dandroid-2.2.1_r2FroyoNexus One
    FRG83android-2.2.1_r1FroyoNexus One
    FRG22Dandroid-2.2_r1.3Froyo
    FRG01Bandroid-2.2_r1.2Froyo
    FRF91android-2.2_r1.1FroyoNexus One
    FRF85Bandroid-2.2_r1FroyoNexus One
    EPF21Bandroid-2.1_r2.1p2Eclair 
    ESE81android-2.1_r2.1sEclair
    EPE54Bandroid-2.1_r2.1pEclairNexus One
    ERE27android-2.1_r2EclairNexus One
    ERD79android-2.1_r1EclairNexus One
    ESD56android-2.0.1_r1Eclair
    ESD20android-2.0_r1Eclair 
    DMD64android-1.6_r1.5Donut 
    DRD20android-1.6_r1.4
    DRD08android-1.6_r1.3
    DRC92android-1.6_r1.2
    
+
    The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
+jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-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.
    
+
+
    To differentiate between releases, you may obtain a list of changes
+associated with each project by issuing the following command and passing it
+the two branch tags:
    
+
+
    repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'
    
+
+
    For example:
    
+
+
    repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'
    
+
+
    And to output to a text file:
    
+
+
    repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-android-4.4.2_r1-diff.txt
    
+
+
    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:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    BuildTagNotes
    HRI39android-3.0_r1earliest Honeycomb version
    HRI66android-3.0_r1.1
    HWI69android-3.0_r1.2
    HRI83android-3.0_r1.3
    HMJ37android-3.1_r1
    HTJ85Bandroid-3.2_r1
    HTK55Dandroid-3.2.1_r1
    HTK75Dandroid-3.2.1_r2
    HLK75Candroid-3.2.2_r1
    HLK75Dandroid-3.2.2_r2
    HLK75Fandroid-3.2.4_r1
    HLK75Handroid-3.2.6_r1latest 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/en/setup/building-kernels.html b/en/setup/building-kernels.html
new file mode 100644
index 00000000..527e1d4a
--- /dev/null
+++ b/en/setup/building-kernels.html
@@ -0,0 +1,277 @@
+
+  
+    Building Kernels
+    
+    
+  
+  
+  
+
+
+
+
    This page details how to build only the kernel. The following instructions
+assume you have not downloaded all of AOSP; if you have already done so, you can
+skip the git clone steps except the step that downloads the kernel
+sources.
    
+
+
    All examples in this section use the
+hikey kernel.
    
+
+
    Selecting a kernel
    
+
    This table lists the name and locations of the kernel sources and binaries:
+
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+  
+
    DeviceBinary locationSource locationBuild configuration
    marlindevice/google/marlin-kernelkernel/msmmarlin_defconfig
    sailfishdevice/google/marlin-kernelkernel/msmmarlin_defconfig
    hikeydevice/linaro/hikey-kernelkernel/hikey-linarohikey_defconfig
    anglerdevice/huawei/angler-kernelkernel/msmangler_defconfig
    bullheaddevice/lge/bullhead-kernelkernel/msmbullhead_defconfig
    shamudevice/moto/shamu-kernelkernel/msmshamu_defconfig
    fugudevice/asus/fugu-kernelkernel/x86_64fugu_defconfig
    volantisdevice/htc/flounder-kernelkernel/tegraflounder_defconfig
    hammerheaddevice/lge/hammerhead-kernelkernel/msmhammerhead_defconfig
    flodevice/asus/flo-kernel/kernelkernel/msmflo_defconfig
    debdevice/asus/flo-kernel/kernelkernel/msmflo_defconfig
    mantadevice/samsung/manta/kernelkernel/exynosmanta_defconfig
    makodevice/lge/mako-kernel/kernelkernel/msmmako_defconfig
    grouperdevice/asus/grouper/kernelkernel/tegrategra3_android_defconfig
    tilapiadevice/asus/grouper/kernelkernel/tegrategra3_android_defconfig
    magurodevice/samsung/tuna/kernelkernel/omaptuna_defconfig
    torodevice/samsung/tuna/kernelkernel/omaptuna_defconfig
    pandadevice/ti/panda/kernelkernel/omappanda_defconfig
    stingraydevice/moto/wingray/kernelkernel/tegrastingray_defconfig
    wingraydevice/moto/wingray/kernel kernel/tegrastingray_defconfig
    crespodevice/samsung/crespo/kernelkernel/samsungherring_defconfig
    crespo4gdevice/samsung/crespo/kernelkernel/samsungherring_defconfig
    
+
+
    After determining the device project you want to work with, view the git log
+for the kernel binary. Device projects use the form
+device/VENDOR/NAME.
    
+
+
    +git clone https://android.googlesource.com/kernel/hikey-linaro
+cd hikey-linaro
+git log --max-count=1 kernel
+
    
+
+
    The commit message for the kernel binary contains a partial git log of the
+kernel sources used to build the binary. The first entry in the log is the most
+recent (the one used to build the kernel). Make a note of the commit message
+as you will need it in a later step.
    
+
+
    Identifying kernel version
    
+
+
    To determine the kernel version used in a system image, run the following
+command against the kernel file:
    
+
+
    +dd if=kernel bs=1 skip=$(LC_ALL=C grep -a -b -o $'\x1f\x8b\x08\x00\x00\x00\x00\x00' kernel | cut -d ':' -f 1) | zgrep -a 'Linux version'
+
    
+
+
    For Nexus 5 (hammerhead), the command is:
    
+
    +dd if=zImage-dtb bs=1 skip=$(LC_ALL=C od -Ad -x -w2 zImage-dtb | grep 8b1f | cut -d ' ' -f1 | head -1) | zgrep -a 'Linux version'
+
    
+
+
+
    Downloading sources
    
+
    Download the source for the kernel you want to build using the appropriate
+git clone command. For example, the following command clones the common kernel, a generic, customizable kernel:
    
+
    +git clone https://android.googlesource.com/kernel/common
+
    
+
+
    A full list of the kernel projects can be found in the Kernel directory. Below are some of the commonly used kernels and their respective git clone commands.
    
+
+
    The exynos project has the kernel sources for Nexus 10, and can be used as a starting point for work on Samsung Exynos chipsets.
    
+
    git clone https://android.googlesource.com/kernel/exynos
    
+
+
    The goldfish project contains the kernel sources for the emulated platforms.
    
+
    git clone https://android.googlesource.com/kernel/goldfish
    
+
+
    The hikey-linaro project is used for HiKey reference boards, and can be used as a starting point for work on HiSilicon 620 chipsets.
    
+
    git clone https://android.googlesource.com/kernel/hikey-linaro
    
+
+
    The msm project has the sources for ADP1, ADP2, Nexus One, Nexus 4, Nexus 5, Nexus 6, Nexus 5X, Nexus 6P, Nexus 7 (2013), Pixel, and Pixel XL, and can be used as a starting point for work on Qualcomm MSM chipsets.
    
+
    git clone https://android.googlesource.com/kernel/msm
    
+
+
    The omap project is used for PandaBoard and Galaxy Nexus, and can be used as a starting point for work on TI OMAP chipsets.
    
+
    git clone https://android.googlesource.com/kernel/omap
    
+
+
    The samsung project is used for Nexus S, and can be used as a starting point for work on Samsung Hummingbird chipsets.
    
+
    git clone https://android.googlesource.com/kernel/samsung
    
+
+
    The tegra project is for Xoom, Nexus 7 (2012), Nexus 9, and can be used as a starting point for work on NVIDIA Tegra chipsets.
    
+
    git clone https://android.googlesource.com/kernel/tegra
    
+
+
    The x86_64 project has the kernel sources for Nexus Player, and can be used as a starting point for work on Intel x86_64 chipsets.
    
+
    git clone https://android.googlesource.com/kernel/x86_64
    
+
+
    Building the kernel
    
+
    When you know the last commit message for a kernel and have successfully
+downloaded the kernel source and prebuilt gcc, you are ready to build the
+kernel. The following build commands use the hikey kernel:
    
+
    +export ARCH=arm64
+export CROSS_COMPILE=aarch64-linux-android-
+cd hikey-linaro
+git checkout -b android-hikey-linaro-4.1 origin/android-hikey-linaro-4.1
+make hikey_defconfig
+make
+
    
+
+
    To build a different kernel, simply replace hikey-linaro with
+the name of the kernel you want to build.
    
+
+
    The image outputs to the arch/arm64/boot/Image directory; the
+kernel binary outputs to the
+arch/arm64/boot/dts/hisilicon/hi6220-hikey.dtb fle. Copy the
+Image directory and the hi6220-hikey.dtb file to the
+hikey-kernel directory.
    
+
+
    Alternatively, you can include the TARGET_PREBUILT_KERNEL
+variable while using make bootimage (or any other make
+command line that builds a boot image). This variable is supported by all
+devices as it is set up via device/common/populate-new-device.sh.
+For example:
    
+
+
    +export TARGET_PREBUILT_KERNEL=$your_kernel_path/arch/arm/boot/zImage-dtb
+
    
+
+
    Note: Kernel names differ by device. To locate
+the correct filename for your kernel, refer to
+device/VENDOR/NAME in the kernel source.
    
+
+  
+
diff --git a/en/setup/building.html b/en/setup/building.html
new file mode 100644
index 00000000..246d1460
--- /dev/null
+++ b/en/setup/building.html
@@ -0,0 +1,228 @@
+
+  
+    Preparing to Build
+    
+    
+  
+  
+  
+
+
+
+
    The following instructions to build the Android source tree apply to all
+branches, including master. The basic sequence of build commands
+is as follows:
    
+
+
    Obtain proprietary binaries
    
+
+
    AOSP cannot be used from pure source code only and requires additional
+hardware-related proprietary libraries to run, such as for hardware
+graphics acceleration. See the sections below for download links and Device binaries for additional
+resources.
    
+
+
    Some devices package these proprietary binaries on their
+/vendor partition.
    
+
+
    Download proprietary binaries
    
+
+
    You can download official binaries for the supported devices running tagged
+AOSP release branches from Google's
+drivers. These binaries add access to additional hardware capabilities
+with non-open source code. To instead build the AOSP master branch, use the
+Binaries
+Preview. When building the master branch for a device, use
+the binaries for the most recent
+numbered release or with the most recent date.
    
+
+
    Extract proprietary binaries
    
+
+
    Each set of binaries comes as a self-extracting script in a compressed
+archive. Uncompress each archive, run the included self-extracting script from
+the root of the source tree, then confirm that you agree to the terms
+of the enclosed license agreement. The binaries and their matching makefiles
+will be installed in the vendor/ hierarchy of the source tree.
    
+
+
    Clean up
    
+
+
    To ensure the newly installed binaries are properly taken into account after
+being extracted, delete the existing output of any previous build using:
    
+
    +make clobber
+
    
+
+
    Set up environment
    
+
    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. For example, the following command:
    
+
    +lunch aosp_arm-eng
+
    
+
    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.
    
+
+
    The BUILDTYPE is one of the following:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    BuildtypeUse
    userlimited access; suited for production
    userdebuglike "user" but with root access and debuggability; preferred for debugging
    engdevelopment configuration with additional debugging tools
    
+
    For more information about building for and running on actual hardware, see
+Running Builds.
    
+
+
    Build the code
    
+
+
    Please note, this section is merely a summary to ensure setup is complete. See
+Running Builds for detailed instructions on building
+Android.
    
+
+
    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. For example, 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.
    
+
+
    Note: Remember to obtain proprietary binaries or your
+build will not boot successfully on your target hardware. If you obtain binary
+blobs at this point you will need to unpack them, make clobber and
+rebuild.
    
+
+
    Flash with fastboot
    
+
+
    To flash a device, you will need to use fastboot, which should
+be included in your path after a successful build. See Flashing a device for
+instructions.
    
+
+
    Emulate an Android Device
    
+
+
    The emulator is added to your path automatically by the build process. To
+run the emulator, type:
    
+
+
    +emulator
+
    
+
+
    Troubleshooting Common Build Errors
    
+
+
    Wrong Java Version
    
+
+
    If you are attempting to build a version of Android inconsistent with your
+version of Java, 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/initializing.html
+************************************************************
+
    
+
+
    This may be caused by:
    
+
+
      
+
    • Failing to install the correct JDK as specified in JDK Requirements.
      • 
+
    • Another JDK previously installed appearing in your path. Prepend the
+correct JDK to the beginning of your PATH or remove the problematic JDK.
      • 
+
    
+
+
    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, 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 in Initializing
+the Build Environment 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
+Initializing the Build Environment 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/en/setup/code-lines.html b/en/setup/code-lines.html
new file mode 100644
index 00000000..b4040abd
--- /dev/null
+++ b/en/setup/code-lines.html
@@ -0,0 +1,187 @@
+
+  
+    Codelines, Branches, and Releases
+    
+    
+  
+  
+  
+
+
+
+
    
+  The Android Open Source Project (AOSP) maintains a complete software stack to be ported by
+  OEMs and other device implementors and run on their own hardware. To maintain the quality of
+  Android, Google has contributed full-time engineers, product managers, user interface designers,
+  quality assurance testers, and all the other roles required to bring modern devices to market.
+
    
+
+
    
+  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.
+
    
+
+
    
+  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 for a given "code line". For instance, when a
+  release is cut, it may or may not become a new branch based on the needs of the moment.
+
    
+
      
+  
    1. 
+	
      
+	  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.
+	
      
+  
      2. 
+  
    2. 
+	
      
+	  Device builders and contributors work with the current latest release, fixing bugs,
+	  launching new devices, experimenting with new features, and so on.
+	
      
+  
      3. 
+  
    3. 
+	
      
+	  In parallel, Google works internally on the next version of the Android platform and
+	  framework 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.
+	
      
+  
      4. 
+  
    4. 
+	
      
+	  When the "n+1"th version is ready, it will be published to the public source tree and
+	  become the new latest release.
+	
      
+  
      5. 
+
    
+  code-line diagram
+
    
+  Figure 1. AOSP code and releases
+
    
+
    
+  Terms and Caveats
+
    
+
      
+  
    • 
+	
      
+	  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 the version in
+	  the SdkVersion field of AndroidManifest.xml files and defined within
+	  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.
+	  Over time we are migrating some of the semi-autonomous Android projects (such as ART,
+	  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 for details. In both cases,
+	  snapshots will be periodically pulled into releases.
+	
      
+  
      • 
+  
    • 
+	
      
+	  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.
+	
      
+  
      • 
+  
    • 
+	
      
+	  "Experimental" code-lines are established to capture changes from the community so they can
+          be iterated on with an eye toward stability.
+	
      
+  
      • 
+  
    • 
+	
      
+	  Changes that prove stable will eventually be pulled into a release branch. Note this
+	  applies only to bug fixes, application improvements, and other changes 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 About Private Codelines 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 Codelines
+
    
+
    
+  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 platform
+  versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
+  direction of Android as a platform and a product. Our approach focuses on a small number of
+  flagship devices to drive features while securing protections of Android-related intellectual
+  property. 
+
    
+
    
+  As a result, Google frequently has possession of confidential information from third parties.
+  And we must refrain from revealing sensitive features until we've secured the appropriate
+  protections. In addition, 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 many contributors will disagree with this approach. We respect others
+  may have a different point of view; however, this is the approach we feel is best, and
+  the one we've chosen to implement.
+
    
+
+  
+
diff --git a/en/setup/code-style.html b/en/setup/code-style.html
new file mode 100644
index 00000000..5367bd68
--- /dev/null
+++ b/en/setup/code-style.html
@@ -0,0 +1,718 @@
+
+  
+    AOSP Java Code Style for Contributors
+    
+    
+  
+  
+  
+
+
+
+
    The code styles below are strict rules for contributing Java code to the
+Android Open Source Project (AOSP).  Contributions to the Android platform that
+do not adhere to these rules are generally not accepted. We recognize
+that not all existing code follows these rules, but we expect all new code to
+be compliant.
    
+
+
    Note: These rules are intended for the Android
+platform and are not required of Android app developers. App developers may
+follow the standard of their choosing, such as the Google Java Style
+Guide.
    
+
+
    Java Language Rules
    
+
    Android follows standard Java coding conventions with the additional rules
+described below.
    
+
+
    Don't Ignore Exceptions
    
+
    It can be tempting to write code that completely ignores an exception, such
+as:
    
+
    void setServerPort(String value) {
+    try {
+        serverPort = Integer.parseInt(value);
+    } catch (NumberFormatException e) { }
+}
+
    
+
    Do not do this. While you may think your code will never encounter this error
+condition or that it is not important to handle it, ignoring exceptions as above
+creates mines in your code for someone else to trigger some day. You must handle
+every Exception in your code in a 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
    
+
    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, so do it only 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 The original exception is passed to the
+constructor for RuntimeException. If your code must compile under Java 1.3, you
+must omit the exception that is the cause.
      
+
      • 
+
    • As a last resort, if you are confident that 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
    
+
    It can also be 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!
+}
+
    
+
    Do not do this. In almost all cases it is inappropriate to catch generic
+Exception or Throwable (preferably not Throwable because it includes Error
+exceptions). It is very dangerous because it means that Exceptions
+you never expected (including RuntimeExceptions like ClassCastException) get
+caught in application-level error handling. It obscures the failure handling
+properties of your code, meaning 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 the
+error differently. In most cases you shouldn't be handling different types of
+exception the same way.
    
+
    The rare exception to this rule is 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 these cases you may catch generic Exception
+(or Throwable) and handle the error appropriately. 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.
      • 
+
+
    • 
+
      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. While they can be handy for doing cleanup (particularly of
+external resources), there are no guarantees as to when a finalizer will be
+called (or even that it will be called at all).
    
+
    Android doesn'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:
    
+
      
+
    • import foo.*;
+
      Potentially reduces the number of import statements.
      • 
+
    • import foo.Bar;
+
      Makes it obvious what classes are actually used and the code is more readable
+for maintainers.
    
+
    Use import foo.Bar; 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. When creating new components however, never use
+deprecated libraries.
    
+
+
    Java Style Rules
    
+
+
    Use Javadoc Standard Comments
    
+
    Every file should have a copyright statement at the top, followed by package
+and import statements (each block separated by a blank line) and finally the
+class or interface declaration. In the Javadoc comments, describe what the class
+or interface does.
    
+
    /*
+ * Copyright (C) 2015 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 third 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 has an important
+side effect), then you must document it. If it's not obvious what the property
+"Foo" means, you should document it.
+
    Every method you write, 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 instructions How
+to Write Doc Comments for the Javadoc Tool.
    
+
+
    Write Short Methods
    
+
    When feasible, keep methods small and focused. We recognize 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
    
+
    Define fields either at the top of the file or immediately before the
+methods that use them.
    
+
+
    Limit Variable Scope
    
+
    Keep the scope of local variables to a minimum. 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, postpone the
+declaration until you do.
    
+
    The exception is 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));
+
    
+
    However, 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
      
+
      2. 
+
    2. 
+
      Imports from third parties (com, junit,
+net, org)
      
+
      3. 
+
    3. 
+
      java and javax
      
+
      4. 
+
    
+
    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).
      
+
      • 
+
    • 
+
      Separated by a blank line between each major grouping (android,
+com, junit, net, org,
+java, javax).
      
+
      • 
+
    
+
    Originally, there was no style requirement on the ordering, meaning IDEs were
+either always changing the ordering or IDE developers had to disable the
+automatic import management features and manually maintain the imports. This was
+deemed bad. When java-style was asked, the preferred styles varied wildly and it
+came down to Android needing to simply "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, imports in all packages will match this
+pattern without 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 prefer static imports to be interspersed with the
+remaining imports, while some prefer them to reside above or below all
+other imports. Additionally, we have not yet determined how to make all IDEs use
+the same ordering. Since many consider this a low priority issue, just use your
+judgement and be consistent.
    
+
+
    Use Spaces for Indentation
    
+
    We use four (4) space indents for blocks and never tabs. When in doubt, be
+consistent with the surrounding code.
    
+
    We use eight (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:
    
+
    class MyClass {
+    int func() {
+        if (something) {
+            // ...
+        } else if (somethingElse) {
+            // ...
+        } else {
+            // ...
+        }
+    }
+}
+
    
+
    We require braces around the statements for a conditional. Exception: 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. For example, this is acceptable:
    
+
    if (condition) {
+    body();
+}
+
    
+
    and this is acceptable:
    
+
    if (condition) body();
+
    
+
    but this is not acceptable:
    
+
    if (condition)
+    body();  // bad!
+
    
+
+
    Limit Line Length
    
+
    Each line of text in your code should be at most 100 characters long. While
+much discussion has surrounded this rule, the decision remains that 100
+characters is the maximum with the following exceptions:
    
+
      
+
    • 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.
      • 
+
    • 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 be
+used only 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 to make names more readable:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    GoodBad
    XmlHttpRequestXMLHTTPRequest
    getCustomerIdgetCustomerID
    class Htmlclass HTML
    String urlString URL
    long idlong ID
    
+
    As both the JDK and the Android code bases are very inconsistent around
+acronyms, it is virtually impossible to be consistent with the surrounding
+code. Therefore, always treat acronyms as words.
    
+
+
    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 not kept reasonably
+terse. The logging facilities provides five different levels of logging:
    
+
      
+
    • ERROR:
+Use when something fatal has happened, i.e. something 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
+device (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:
+Use 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:
+Use 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:
+Use 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:
+Use 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
+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, 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).
      • 
+
    • Having a full filesystem on a filesystem that is accessible 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
+connection) is considered expected and should not trigger any logging at a
+level higher than 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 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). 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 used to diagnose an issue that is hard to reproduce should
+be kept at the DEBUG or VERBOSE level and should be enclosed by if blocks that
+allow for disabling 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 surrounding code and determine its style. If that code
+uses spaces around the if clauses, you should too. If the code 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 the code you add to 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.
    
+
+
    Javatests Style Rules
    
+
    Follow test method naming conventions and use an underscore to separate 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/en/setup/community.html b/en/setup/community.html
new file mode 100644
index 00000000..af0d17ec
--- /dev/null
+++ b/en/setup/community.html
@@ -0,0 +1,361 @@
+
+  
+    Android Community
+    
+    
+  
+  
+  
+
+
+
+
    Welcome to the Android community!
    
+
+
    The key to any community is 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. View the available groups
+and join any that seem interesting to you. You can also discuss Android on
+IRC.
    
+
+
    If you are a user looking for help with the Android UI or an Android device,
+details on Android updates or security issues, or how to build applications for
+Android, see the list of resources below.
    
+
+
    Resources
    
+
+
    This site covers creating custom Android stacks, porting devices and
+accessories, and meeting compatibility requirements. The Android OS is a Git
+repository of files and not a single file (.zip/tar/exe/etc.) to download. You
+can get started with the Android source code by following the instructions on
+the Downloading the Source
+page. For other information about Android, refer to the following resources.
    
+
+
+
+
+
+
+
    
+
    Using Android
    
+
+
    Help centers
    
+General
    
+Pixel phones
    
+Nexus phones/tablets
    
+Google Play Edition
    
+Auto
    
+TV
    
+Wear
    
+Apps
+
    
+
+
    Communities
    
+AOSP communities
    
+Developer communities
+
    
+
+
    Send feedback
    
+Report AOSP bug
    
+
    
+
+    		
+
+
    Updates & security
    
+
+
    Android releases
    
+Android history
    
+Current release
+
    
+
+
    Device images
    
+Nexus and Pixel devices
    
+Other devices
+
    
+
+
    Security assistance
    
+Google Safety Center
    
+Tips for users
    
+Tips
+for developers
    
+Platform security
+
    
+
+
    Security announcements
    
+Release
+enhancements
    
+Bulletins
+
    
+
+    		
+
+
    Getting involved
    
+
+
    Developer resources
    
+Developer.android.com
    
+Developer support
    
+Android developers blog
    
+Google Developer Groups (GDGs)
    
+Google Mobile Services (GMS)
+
    
+
+
    Training
    
+Google
    
+Udacity
+
+
    
+
+
+
    Open Source Project discussions
    
+
      
+
    • 
+
      android-platform:
+This list is for general discussion about the Android Open Source Project or
+the platform technologies.
      
+
+
      • 
+
    • 
+
      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.
      
+
+
      • 
+
    • 
+
      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.
      
+
+
      • 
+
    • 
+
      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 (and contributors to the Android
+kernel should go to android-kernel).
      
+
+
      • 
+
    • 
+
      android-kernel:
+This list is for developers who want to contribute to the Linux kernel used by
+Android devices. If you've downloaded the kernel code, know how to compile it,
+and want to write kernel code to support Android, this is your place. This
+group is not for user-space topics (see android-platform); people
+will shake their fingers at you and call you naughty if you ask user-space
+questions here.
      
+
+
    • 
+
      android-ota:
+This list is for developers working on the Android OTA system (the recovery
+image and the scripts that generate OTAs).
      
+
+
      • 
+
    
+
+
    Audience
    
+
    These discussion groups are intended for developers working with the Android
+platform. Everyone is welcome to join in, provided you follow the community
+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.
    
+
+
+
    Getting the Most from Our Lists
    
+
    Please consider the following before you post to our lists.
    
+
      
+
    • 
+
      Read the Charter for our forums. 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.
      
+
      • 
+
    
+
+
    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 strongly
+about something, or just want to chat, then contact the mailing list owners.
+It's what we're here for!
    
+
+
    Using email with Google Groups
    
+
    Instead of using the Google groups
+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.
      
+
      2. 
+
    2. 
+
      Click "My membership" on the right side.
      
+
      3. 
+
    3. 
+
      Under "How do you want to read this group?" select one of the email options.
      
+
      4. 
+
    
+
    Android on IRC
    
+
    Android has a presence on IRC via
+freenode. We maintain two official IRC
+channels on irc.freenode.net (access via
+the web at freenode webchat)
    
+
      
+
    • 
+
      #android - dedicated to
+general Android discussion and porting concerns
      
+
      • 
+
    • 
+
      #android-dev - dedicated to discussion about writing Android applications
      
+
      • 
+
    
+
    The community also uses several unofficial channels that are not not officially moderated or managed. The Open Handset Alliance does not endorse unofficial channels and there's no warranty express or implied, so use them at your own risk. Here's a list of a few unofficial channels (many more may exist):
    
+
+
+
+  
+
diff --git a/en/setup/contributing.html b/en/setup/contributing.html
new file mode 100644
index 00000000..ec212f99
--- /dev/null
+++ b/en/setup/contributing.html
@@ -0,0 +1,58 @@
+
+  
+    Contributing
+    
+    
+  
+  
+  
+
+
+
    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 Overview page.
    
+
    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 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.
    
+
+
    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. 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, 
+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.
+If you need help along the way, you can join our discussion groups.
    
+
+  
+
diff --git a/en/setup/developing.html b/en/setup/developing.html
new file mode 100644
index 00000000..59565e75
--- /dev/null
+++ b/en/setup/developing.html
@@ -0,0 +1,189 @@
+
+  
+    Developing
+    
+    
+  
+  
+  
+
+
+
+
    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 hobbyist 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, 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. 
    
+
    Android Studio is the official integrated development environment (IDE) for Android application development. See the Android Studio Overview for details.
+
+
    Basic Workflow
    
+
    
+  basic workflow diagram
+  
    
+    Figure 1. Basic Android workflow
+  
    
+
    
+
+
    The basic pattern of interacting with the repositories is as follows:
    
+
      
+
    1. 
+
      Use repo start to start a new topic branch.
      
+
      2. 
+
    2. 
+
      Edit the files.
      
+
      3. 
+
    3. 
+
      Use git add to stage changes.
      
+
      4. 
+
    4. 
+
      Use git commit to commit changes.
      
+
      5. 
+
    5. 
+
      Use repo upload to upload changes to the review server.
      
+
      6. 
+
    
+
    Task reference
    
+
    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 Downloading the Source and
+Using Repo.
    
+
    Synchronizing your client
    
+
    To synchronize the files for all available projects: 
    
+
    +repo sync
+
    
+
    To synchronize the files for selected projects:
    
+
    +repo sync PROJECT0 PROJECT1 ... PROJECTN
+
    
+
    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.
    
+
    To start a topic branch using Repo, navigate into the project to be modified and issue: 
    
+
    +repo start BRANCH_NAME .
+
    
+
    Please note, the period represents the project in the current working directory. To verify your new branch was created:
    
+
    +repo status .
+
    
+
    Using topic branches
    
+
    To assign the branch to a particular project:
    
+
    +repo start BRANCH_NAME PROJECT_NAME
+
    
+
    See android.googlesource.com for a list of all projects. Again, if you've already navigated into a particular project directory, you may simply pass a period to represent the current 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
    
+list of basic git and repo commands
+
    
+  Figure 2. Basic git and repo commands
+
    
+
+  
+
diff --git a/en/setup/devices.html b/en/setup/devices.html
new file mode 100644
index 00000000..c8bbbe75
--- /dev/null
+++ b/en/setup/devices.html
@@ -0,0 +1,357 @@
+
+  
+    Using Reference Boards
+    
+    
+  
+  
+  
+
+
+
    You can create builds for Nexus devices using Android Open Source Project
+(AOSP) builds and the relevant hardware-specific binaries. For available
+Android builds and targeted devices, see
+Source Code,
+Tags, and Builds.
    
+
+
    You can also create builds for
+HiKey
+Android reference boards, which are designed to help non-Nexus component vendors
+develop and port drivers to Android releases. Using a reference board can ease
+upgrade efforts, reduce time-to-market for new Android devices, lower device
+costs by enabling ODM/OEMs to choose from a wider range of compatible
+components, and increase the speed of innovation among component suppliers.
    
+
+
    Google supports HiKey960 and
+HiKey certified
+96Boards
+as Android reference boards. AOSP provides kernel source and board support for
+HiKey so developers can easily create and debug new and existing peripheral
+drivers, do kernel development, and perform other tasks with fewer OEM
+encumbrances. To develop new ContextHub features that use new sensors or LEDs,
+you can also use a Neonkey SensorHub connected to a HiKey
+or HiKey960 development board.
    
+
+
    HiKey960 boards
    
+
+
    The HiKey960 board is available in a 3GB RAM configuration from LeMaker (via
+Amazon.com)
+and from Lenovator.
+
    
+
+HiKey960 board image
+
    Figure 1. HiKey960 board by Lenovator
    
+
+
    Additional resources:
    
+    
+
+
    Use the following commands to download, build, and run Android on the
+HiKey960 board.
    
+
+
    Compiling userspace
    
+
      
+  
    1. Download the Android source tree:
+
      +repo init -u https://android.googlesource.com/platform/manifest -b master
+repo sync -j24
+
      
+  
      2. 
+  
    2. Download and extract binaries into the Android source tree:
+
      +wget https://dl.google.com/dl/android/aosp/arm-hikey960-OPR-cf4e0c80.tgz
+tar xzf arm-hikey960-OPR-cf4e0c80.tgz
+./extract-arm-hikey960.sh
+
      
+  
      3. 
+  
    3. Build:
+
      +. ./build/envsetup.sh
+lunch hikey960-userdebug
+make -j32
+
      
+  
      4. 
+
    
+
+
    Installing initial images
    
+
      
+  
    1. Select fastboot mode turning ON switch 1 and 3 (for details, refer to the
+HiKey960 user guide).
      2. 
+  
    2. Power the board.
      3. 
+  
    3. Flash initial images:
+
      +cd device/linaro/hikey/installer/hikey960
+./flash-all.sh
+
      
+  
      4. 
+  
    4. Turn OFF switch 3 and power cycle the board.
      5. 
+
    
+
+
    Flashing images
    
+
      
+  
    1. Enter fastboot mode by turning ON switch 1 and 3.
      2. 
+  
    2. Flash images by running the following commands:
+
      +fastboot flash boot out/target/product/hikey960/boot.img
+fastboot flash dts out/target/product/hikey960/dt.img
+fastboot flash system out/target/product/hikey960/system.img
+fastboot flash cache out/target/product/hikey960/cache.img
+fastboot flash userdata out/target/product/hikey960/userdata.img
+
      
+  
      3. 
+  
    3. Turn OFF switch 3 and power cycle the board.
      4. 
+
    
+
+
    Building the kernel
    
+
      
+  
    1. Run the following commands:
+
      +git clone https://android.googlesource.com/kernel/hikey-linaro
+cd hikey-linaro
+git checkout -b android-hikey-linaro-4.9 origin/android-hikey-linaro-4.9
+make ARCH=arm64 hikey960_defconfig
+make ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- -j24
+
      
+  
      2. 
+  
    2. Update the kernel in the boot image.
+    
        
+      
      • Copy hi3660-hikey960.dtb
+        (arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dtb) to the
+        hikey-kernel directory as file:
+      hi3660-hikey960.dtb-4.9
        • 
+      
      • Copy the Image file (arch/arm64/boot/Image.gz) to the
+        hikey-kernel directory as file:
+        Image.gz-hikey960-4.9
        • 
+    
      
+  
    3. Make the boot image:
+
      +make bootimage -j24
+
      
+  
      4. 
+
    
+
+
    Setting serial number
    
+
    To set random serial number, run:
+
    +fastboot getvar nve:SN@16_DIGIT_NUMBER
+
    
+
    Bootloader exports the generated serial number to kernel via
+androidboot.serialno=.
+
+
    Setting monitor resolution
    
+
    Edit the device/linaro/hikey/hikey960/BoardConfig.mk parameter
+BOARD_KERNEL_CMDLINE and configure the video setting.
+Example setting for a 24" monitor is video=HDMI-A-1:1280x800@60.
+
    
+
+
    HiKey boards
    
+
+
    The HiKey board (also known as HiKey620) is available in
+1GB RAM
+and 2GB
+RAM configurations from Lenovator:
+
    
+
+HiKey620 board image
+
    Figure 2. HiKey board by Lenovator
    
+
+
    Additional resources:
    
+
+
+
    Use the following commands to download, build, and run Android on the HiKey
+board.
    
+
+
    Compiling userspace
    
+
      
+  
    1. Download the Android source tree:
+
      +repo init -u https://android.googlesource.com/platform/manifest -b master
+repo sync -j24
+
      
+  
      2. 
+  
    2. Download and extract HDMI binaries into the Android source tree:
+
      +wget https://dl.google.com/dl/android/aosp/linaro-hikey-20170523-4b9ebaff.tgz
+tar xzf linaro-hikey-20170523-4b9ebaff.tgz
+./extract-linaro-hikey.sh
+
      
+  
      3. 
+  
    3. Install mcopy utility:
+
      +apt-get install mtools
+
      
+  
      4. 
+  
    4. Build:
+
      +. ./build/envsetup.sh
+lunch hikey-userdebug
+make -j32
+
      
+  
      5. 
+
    
+
+
    Note: For 4GB eMMC, instead of $ make -j32
+use: $ make -j32 TARGET_USERDATAIMAGE_4GB=true.
    
+
+
    Installing initial fastboot and ptable
    
+
      
+  
    1. Select special bootloader mode by linking J15 1-2 and 3-4 pins (for details,
+refer to the
+HiKey
+user guide).
      2. 
+  
    2. Connect USB to PC to get ttyUSB device (ex: /dev/ttyUSB1).
      3. 
+  
    3. Power the board:
+
      +cd device/linaro/hikey/installer/hikey
+./flash-all.sh /dev/ttyUSB1 [4g]
+
      
+  
      4. 
+  
    4. Remove jumper 3-4 and power the board.
      5. 
+
    
+
+
    Flashing images
    
+
      
+  
    1. Enter fastboot mode by linking J15 1-2 and 5-6 pins.
      2. 
+  
    2. Run the following commands:
+
      +fastboot flash boot out/target/product/hikey/boot.img
+fastboot flash -w system out/target/product/hikey/system.img
+
      
+  
      3. 
+  
    3. Remove jumper 5-6 and power the board.
      4. 
+
    
+
+
    Building the kernel
    
+
      
+  
    1. Run the following commands:
+
      +git clone https://android.googlesource.com/kernel/hikey-linaro
+cd hikey-linaro
+git checkout -b android-hikey-linaro-4.9 origin/android-hikey-linaro-4.9
+make ARCH=arm64 hikey_defconfig
+make ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- -j24
+
      
+  
      2. 
+  
    2. Copy output to the hikey kernel directory (/kernel/hikey-linaro):
+    
        
+      
      • Copy hi6220-hikey.dtb (arch/arm64/boot/dts/hisilicon/hi6220-hikey.dtb) to the
+hikey-kernel directory as file hi6220-hikey.dtb-4.9.
        • 
+  
      • Copy the Image file (arch/arm64/boot/Image-dtb) to the
+hikey-kernel directory as file Image-dtb-4.9.
        • 
+    
      
+  
    3. Make the boot image:
+
      +make bootimage -j24
+
      
+  
      4. 
+
    
+
+
    Setting monitor resolution
    
+
    Edit device/linaro/hikey/hikey/BoardConfig.mk parameter
+BOARD_KERNEL_CMDLINE and configure the video setting.
+Example setting for a 24" monitor: video=HDMI-A-1:1280x800@60.
    
+
+
    Configuring kernel serial output (uart3)
    
+
    Set the J2 low speed expansion connector to 1 - Gnd, 11 - Rx, 13 - Tx. For
+details, refer to the
+HiKey
+user guide.
    
+
+
    Neonkey SensorHub
    
+
    To develop new ContextHub features that use new sensors or LEDs, you can use
+Neonkey
+SensorHub connected to a Hikey or Hikey960 development board.
    
+
+Neonkey Sensorhub image
+
    Figure 3. Neonkey SensorHub
    
+
+
    Neonkey is a certified 96Boards
+mezzanine base on STM32F411CE with the following components:
    
+
+
      
+
    • Pressure sensor: BMP280
      • 
+
    • ALS/Proximity sensor: RPR-0521RS
      • 
+
    • ARM Hall sensor: MRMS501A
      • 
+
    • LED driver with 15 LEDs: LP3943
      • 
+
    • Accel/Gyro + Geomagnetic sensors: BMI160 + BMM150
      • 
+
    • Temp/Humidity sensor: SI7034-A10
      • 
+
    • 4 GPIO-driven LEDs, I2C expansion, GPIO (2 lines) expansion, JTAG connector
      • 
+
    • NOR Flash: 512KB
      • 
+
    • SRAM: 128 KB, 96boards LS Expansion connector
      • 
+
    
+
+
    Kernel source and ContextHub board support is available in AOSP to help
+developers create and debug new sensors, make new HAL and kernel changes, etc.
+with fewer OEM encumbrances.
    
+
+
    To build, enable, and upload Neonkey:
    
+
+
      
+
    1. Pull AOSP source:
+
      +repo init -u https://android.googlesource.com/platform/manifest -b master & repo sync -j24
+
      
+
      2. 
+
    2. Build:
+
      +. ./build/envsetup.sh
+lunch hikey-userdebug
+. device/google/contexthub/firmware/toolchain-setup.sh
+make -C device/google/contexthub/firmware/variant/neonkey
+adb push device/google/contexthub/firmware/out/nanohub/neonkey/full.bin /data/local/tmp
+
      
+
      3. 
+
    3. To enable Neonkey, enter boot mode using the following method:
+
        
+
      1. Connect BOOT0 to 1V8 (link JTAG P4 1-5 pins)
        2. 
+
      2. Hold USR button
        3. 
+
      3. Push RST button
        4. 
+
      
+
      4. 
+
    4. To upload the firmware:
+
      +adb root
+adb shell stm32_flash -u -d /dev/ttyAMA2 -e 0xffff -w /data/local/tmp/full.bin
+
      
+
      5. 
+
    5. To build userspace HAL:
+
      +make TARGET_SENSOR_MEZZANINE=neonkey -j24
+fastboot flashall
+
      
+
      6. 
+
    
+
+  
+
diff --git a/en/setup/downloading.html b/en/setup/downloading.html
new file mode 100644
index 00000000..7599338b
--- /dev/null
+++ b/en/setup/downloading.html
@@ -0,0 +1,296 @@
+
+  
+    Downloading the Source
+    
+    
+  
+  
+  
+
+
+
+
    
+  The Android source tree is located in a Git repository hosted by Google. The Git repository
+  includes metadata for the Android source, including those related to changes to the source
+  and the date they were made. This document describes how to download the source tree for a
+  specific Android code-line.
+
    
+
    
+ To instead start with a factory image for a specific device, see
+ Selecting a device build.
+
    
+
    
+  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 the Developing section.
+
    
+
    
+  To install Repo:
+
    
+
      
+  
    1. 
+    
      
+      Make sure you have a bin/ directory in your home directory and that it is included in
+      your path:
+    
      
+
      +mkdir ~/bin
+PATH=~/bin:$PATH
+
      
+  
      2. 
+  
    2. 
+    
      
+      Download the Repo tool and ensure that it is executable:
+    
      
+
      +curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
+chmod a+x ~/bin/repo
+
      
+  
      3. 
+
    
+
    
+  For version 1.21, the SHA-1 checksum for repo is b8bd1804f432ecf1bab730949c82b93b0fc5fede
+
    
+
    
+  For version 1.22, the SHA-1 checksum for repo is da0514e484f74648a890c0467d61ca415379f791
+
    
+
    
+  For version 1.23, the SHA-256 checksum for repo is e147f0392686c40cfd7d5e6f332c6ee74c4eab4d24e2694b3b0a0c037bf51dc5
+
    
+
    
+  Initializing a Repo client
+
    
+
    
+  After installing Repo, set up your client to access the Android source repository:
+
    
+
      
+  
    1. 
+    
      
+      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
+
      
+  
      2. 
+  
    2. 
+    
      
+      Configure git 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. 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.
+    
      
+
      +git config --global user.name "Your Name"
+git config --global user.email "you@example.com"
+
      
+  
      3. 
+  
    3. 
+    
      
+      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. For a list of branches, see Source Code Tags and Builds.
+    
      
+
      +repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
+
      
+  
      4. 
+
    
+
    
+  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.
+
    
+
    
+  Downloading the Android Source Tree
+
    
+
    
+  To pull down the Android source tree 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 the Developing section.
+
    
+
    
+  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 with the password generator
+  and follow the instructions on the password generator 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. Notice the --mirror flag, which
+  can be specified only 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 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 yet, now would be a good
+  time to do it.
+
    
+
+  
+
diff --git a/en/setup/faqs.html b/en/setup/faqs.html
new file mode 100644
index 00000000..938f07c5
--- /dev/null
+++ b/en/setup/faqs.html
@@ -0,0 +1,328 @@
+
+  
+    Frequently Asked Questions
+    
+    
+  
+  
+  
+
+
+
+
+
    Please see the Android FAQs on
+developer.android.com for answers to other common questions.
+
+
    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 you can use to build
+mobile phones 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 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 there was no
+central point of failure, so 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.
    
+
    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 on our Licenses page.
    
+
    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 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 great
+devices running Android actually make it to market.
    
+
    By making sure Android is a success with 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. Of course, no
+one is required to participate. 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 aim to release great devices into a competitive marketplace. We
+then incorporate the innovations and enhancements we made into the core
+platform as the next version.
    
+
    In practice, this means 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 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 Codelines,
+Branches and Releases page.
    
+
    Why are parts of Android developed in private?
    
+
    It typically takes more than a year to bring a device to market. And, of course,
+device manufacturers want to ship the latest software they can. Developers,
+meanwhile, don't want 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. This allows developers
+and OEMs to use a single version without tracking 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. Releasing the source code is a fairly complex process.
+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 prior to the
+device's release; however in other releases, 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.
    
+
    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.
    
+
    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 making final API changes,
+updating documentation (to reflect any modifications 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 intellectual property ownership of their
+contribution, Google too must verify it is clear to make contributions.
    
+
    From the time mass production begins, the software release process
+usually takes around a month. This often places source code releases
+around the same time 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 develop 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 to 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 encourages applications to be run
+in the ART runtime. Similarly, 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 channels listed on the 
+Android Community page prior to beginning any work. You can find more
+information on this topic from the 
+Contributing 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 page.
    
+Back to top
+
    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, enabling their 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 many 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 all phones to 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,
+version 1.6 of the CDD supports only cell phones. But the 2.1 CDD allows devices
+to omit telephony hardware, enabling 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 complete the contact form included in licensing Google Mobile
+Services to seek access to Google Play. We will be in contact if we can
+help you.
    
+
    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,
+Gmail, and more, 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 manufacturers
+wish to use the Android name with their products, or want access to Google Play,
+they must first demonstrate their devices are 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 for device testing.
    
+
    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 various 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 determines 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) do 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.
    
+Back to top
+
    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.
    
+
    Are codecs verified by CTS?
    
+
    Yes. All mandatory codecs are verified by CTS.
    
+
+Back to top
+
+  
+
diff --git a/en/setup/git-resources.html b/en/setup/git-resources.html
new file mode 100644
index 00000000..4d5530d0
--- /dev/null
+++ b/en/setup/git-resources.html
@@ -0,0 +1,47 @@
+
+  
+    Learning Git
+    
+    
+  
+  
+  
+
+
+
    For further information on Git, check out these excellent off-site resources:
    
+
+
+  
+
diff --git a/en/setup/images/8100-TM-example.png b/en/setup/images/8100-TM-example.png
new file mode 100644
index 00000000..b347e6cc
Binary files /dev/null and b/en/setup/images/8100-TM-example.png differ
diff --git a/en/setup/images/Android_Robot_100.png b/en/setup/images/Android_Robot_100.png
new file mode 100644
index 00000000..946ee3ab
Binary files /dev/null and b/en/setup/images/Android_Robot_100.png differ
diff --git a/en/setup/images/JB-TM-example.png b/en/setup/images/JB-TM-example.png
new file mode 100644
index 00000000..0df3c6d0
Binary files /dev/null and b/en/setup/images/JB-TM-example.png differ
diff --git a/en/setup/images/No_PeaceBot_200.jpg b/en/setup/images/No_PeaceBot_200.jpg
new file mode 100644
index 00000000..739f9682
Binary files /dev/null and b/en/setup/images/No_PeaceBot_200.jpg differ
diff --git a/en/setup/images/XBrand-TM-example.jpg b/en/setup/images/XBrand-TM-example.jpg
new file mode 100644
index 00000000..8a3ab590
Binary files /dev/null and b/en/setup/images/XBrand-TM-example.jpg differ
diff --git a/en/setup/images/android_logo_new_crossed_out.png b/en/setup/images/android_logo_new_crossed_out.png
new file mode 100644
index 00000000..646935ee
Binary files /dev/null and b/en/setup/images/android_logo_new_crossed_out.png differ
diff --git a/en/setup/images/android_logo_old_crossed_out.png b/en/setup/images/android_logo_old_crossed_out.png
new file mode 100644
index 00000000..a256d938
Binary files /dev/null and b/en/setup/images/android_logo_old_crossed_out.png differ
diff --git a/en/setup/images/hikey-board.png b/en/setup/images/hikey-board.png
new file mode 100644
index 00000000..be8d715d
Binary files /dev/null and b/en/setup/images/hikey-board.png differ
diff --git a/en/setup/images/hikey620.png b/en/setup/images/hikey620.png
new file mode 100644
index 00000000..1e98aeaa
Binary files /dev/null and b/en/setup/images/hikey620.png differ
diff --git a/en/setup/images/hikey960.png b/en/setup/images/hikey960.png
new file mode 100644
index 00000000..c69f8f45
Binary files /dev/null and b/en/setup/images/hikey960.png differ
diff --git a/en/setup/images/jack_jill.png b/en/setup/images/jack_jill.png
new file mode 100644
index 00000000..445edf4b
Binary files /dev/null and b/en/setup/images/jack_jill.png differ
diff --git a/en/setup/images/jack_library.png b/en/setup/images/jack_library.png
new file mode 100644
index 00000000..bf0361b9
Binary files /dev/null and b/en/setup/images/jack_library.png differ
diff --git a/en/setup/images/jack_overview.png b/en/setup/images/jack_overview.png
new file mode 100644
index 00000000..a315fc20
Binary files /dev/null and b/en/setup/images/jack_overview.png differ
diff --git a/en/setup/images/jack_predex.png b/en/setup/images/jack_predex.png
new file mode 100644
index 00000000..25638141
Binary files /dev/null and b/en/setup/images/jack_predex.png differ
diff --git a/en/setup/images/mobile-view.png b/en/setup/images/mobile-view.png
new file mode 100644
index 00000000..1b3ff7b8
Binary files /dev/null and b/en/setup/images/mobile-view.png differ
diff --git a/en/setup/images/neonkey-sensorhub.png b/en/setup/images/neonkey-sensorhub.png
new file mode 100644
index 00000000..61f4e22b
Binary files /dev/null and b/en/setup/images/neonkey-sensorhub.png differ
diff --git a/en/setup/index.html b/en/setup/index.html
new file mode 100644
index 00000000..3728eb2f
--- /dev/null
+++ b/en/setup/index.html
@@ -0,0 +1,81 @@
+
+  
+    The Android Source Code
+    
+    
+  
+  
+  
+
+
+
    
+Android is an open source software stack created for a wide array of devices
+with different form factors. The primary purposes of Android are to create an
+open software platform available for carriers, OEMs, and developers to make
+their innovative ideas a reality and to introduce a successful,
+real-world product that improves the mobile experience for users.
+
    
+
+
    
+We also wanted to make sure 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 with source code open for customization and porting.
+
    
+
+
    
+  Android framework details
+  
    
+    Figure 1. Android stack
+  
    
+
    
+
+
    Governance Philosophy
    
+
    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. These companies have
+allocated significant engineering resources to improve Android and bring Android
+devices to market.
+
    
+
    The companies that have invested in Android have done so on its merits
+because we believe an open platform is necessary. Android is
+intentionally and explicitly an open source -- as opposed to a 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 Android Open Source Project 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 legitimate uses. However, in order to take part in the shared
+ecosystem of applications we are building around Android, device builders
+must participate in the Android Compatibility Program.
    
+
+
    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.
    
+
+  
+
diff --git a/en/setup/initializing.html b/en/setup/initializing.html
new file mode 100644
index 00000000..662862be
--- /dev/null
+++ b/en/setup/initializing.html
@@ -0,0 +1,460 @@
+
+  
+    Establishing a Build Environment
+    
+    
+  
+  
+  
+
+
    This section describes how to set up your local work environment to build
+the Android source files. You will need to use Linux or Mac OS. Building under
+Windows is not currently supported.
    
+
    For an overview of the entire code-review and code-update process, see Life of a Patch.
    
+
    Note: All commands in this site are preceded
+by a dollar sign ($) to differentiate them from output or entries within files.
+You may use the Click to copy feature at the top right of each command
+box to copy all lines without the dollar signs or triple-click each line to
+copy it individually without the dollar sign.
    
+
    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 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 (14.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: See the Requirements for the complete list of hardware and
+software requirements. Then follow the detailed instructions for Ubuntu and Mac
+OS below.
    
+
+
    Installing the JDK
    
+
    The master branch of Android in the Android Open Source Project (AOSP)
+comes with a prebuilt version of OpenJDK in
+platform/prebuilts/jdk/jdk8. So no additional installation is
+required.
    
+
+
    Older versions of Android require a separate installation of the JDK. On
+Ubuntu, use OpenJDK. See  JDK Requirements for precise versions and the
+sections below for instructions.
    
+
+
    For Ubuntu >= 15.04
    
+
    Run the following:
    
+
    +sudo apt-get update
+sudo apt-get install openjdk-8-jdk
+
    
+
+
    For Ubuntu LTS 14.04
    
+
    There are no available supported OpenJDK 8 packages for Ubuntu 14.04. The
+Ubuntu 15.04 OpenJDK 8 packages have been used successfully
+with Ubuntu 14.04. Newer package versions (e.g. those for 15.10, 16.04) were
+found not to work on 14.04 using the instructions below.
    
+
      
+
    1. 
+
      Download the .deb packages for 64-bit architecture from
+archive.ubuntu.com:
      
+
+
      2. 
+
    2. 
+
      Optionally, confirm the checksums of the downloaded files against the SHA256
+string listed with each package above.
      
+
      For example, with the sha256sum tool:
      
+
      +sha256sum {downloaded.deb file}
+
      
+
      3. 
+
    3. 
+
      Install the packages:
      
+
      +sudo apt-get update
+
      
+
      Run dpkg for each of the .deb files you downloaded. It may produce errors due to
+missing dependencies:
      
+
      +sudo dpkg -i {downloaded.deb file}
+
      
+
      To fix missing dependencies:
      
+
      +sudo apt-get -f install
+
      
+
      4. 
+
    
+
+
    Update the default Java version - optional
    
+
+
    Optionally, for the Ubuntu versions above update the default Java version by
+running:
    
+
    +sudo update-alternatives --config java
+sudo update-alternatives --config javac
+
    
+
+
    If, during a build, you encounter version errors for Java, set its
+path as described in the Wrong
+Java Version section.
    
+
+
    Installing required packages (Ubuntu 14.04)
    
+
+
    You will need a 64-bit version of Ubuntu. Ubuntu 14.04 is recommended.
    
+
+
    +sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip
+
    
+
+
    Note: To use SELinux tools for policy
+analysis, also install the python-networkx package.
    
+
+
    Note: If you are using LDAP and want
+to run ART host tests, also install the libnss-sss:i386
+package.
    
+
+
    Installing required packages
+(Ubuntu 12.04)
    
+
+
    You may use Ubuntu 12.04 to build older versions of Android. Version 12.04
+is not supported on master or recent releases.
    
+
+
    +sudo apt-get install git gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
+sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
+
    
+
+
    Installing required
+packages (Ubuntu 10.04 -- 11.10)
    
+
    Building on Ubuntu 10.04-11.10 is no longer supported, but may be useful for
+building older releases of AOSP.
    
+
+
    +sudo apt-get install git 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
+
    
+
+
    Configuring USB Access
    
+
+
    Install a community-maintained default set of udev rules for
+all Android devices by following the instructions to Set up a device for development.
+
+
    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 build
+environment
    
+
+
    In a default installation, Mac OS 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 Mac OS environment is very straightforward. Earlier
+branches require some additional tools and SDKs.
    
+
+
    Creating a case-sensitive disk image
    
+
+
    You can create a case-sensitive filesystem within your existing Mac OS 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.sparseimage) file which, once mounted, acts as a drive with
+the required formatting for Android development.
    
+
+
    If you need a larger volume later, you can also resize the sparse image with
+the following command:
    
+
+
    +# hdiutil resize -size <new-size-you-want>g ~/android.dmg.sparseimage
+
    
+
+
    For a disk image named android.dmg stored in your home
+directory, you can add helper functions to your ~/.bash_profile:
    
+
+
      
+
    • 
+To mount the image when you execute mountAndroid:
+
+
      +# mount the android file image
+mountAndroid() { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
+
      
+
+
      Note: If your system created a
+.dmg.sparseimage file, replace ~/android.dmg with
+~/android.dmg.sparseimage.
      
+
      • 
+
+
    • 
+
      To unmount it when you execute umountAndroid:
      
+
      +# unmount the android file image
+umountAndroid() { hdiutil detach /Volumes/android; }
+
      
+
      • 
+
    
+
+
    Once you've mounted the android volume, you'll do all your work
+there. You can eject it (unmount it) just like you would with an external
+drive.
    
+
+
    Installing the JDK
    
+
+
    See Requirements for the version of Java to
+use when developing various versions of Android.
    
+
+
    Installing required packages
    
+
+
      
+
    1. 
+
      Install Xcode command line tools with:
+
      +xcode-select --install
+
      
+
+
      For older versions of Mac OS (10.8 or earlier), you need to install Xcode from
+the Apple developer site.
+If you are not already registered as an Apple developer, you will have to
+create an Apple ID in order to download.
      
+
      2. 
+
+
    2. 
+
      Install MacPorts from macports.org.
      
+
+
      Note: Make sure that
+/opt/local/bin appears in your path before
+/usr/bin. If not, please add the following to your
+~/.bash_profile file:
      
+
+
      +export PATH=/opt/local/bin:$PATH
+
      
+
+
      Note: If you do not have a
+.bash_profile file in your home directory, create one.
      
+
      3. 
+
+
    3. 
+
      Get make, git, and GPG packages from MacPorts:
      
+
+
      +POSIXLY_CORRECT=1 sudo port install gmake libsdl git gnupg
+
      
+
+
      If using Mac OS X v10.4, also install bison:
      
+
      +POSIXLY_CORRECT=1 sudo port install bison
+
      
+
      4. 
+
    
+
+
    Reverting from make 3.82
    
+
+
    In Android 4.0.x (Ice Cream Sandwich) and earlier, a bug exists in gmake 3.82
+that prevents android from building. You can install version 3.81 using
+MacPorts with these steps:
    
+
+
      
+
    1. 
+
      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
+
      
+
      2. 
+
+
    2. 
+
      In the new dports directory, run:
      
+
      +svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
+
      
+
      3. 
+
+
    3. 
+
      Create a port index for your new local repository:
      
+
+
      +portindex /Users/Shared/dports
+
      
+
      4. 
+
+
    4. 
+
      Install the old version of gmake with:
      
+
      +sudo port install gmake @3.81
+
      
+
      5. 
+
    
+
+
    Setting a file descriptor limit
    
+
+
    On Mac OS, 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
+
    
+
+
    Optimizing a build environment (optional)
    
+
+
    Setting up ccache
    
+
+
    You can optionally tell the build to use the ccache compilation tool, which
+is a compiler cache for C and C++ that can help make builds faster. It
+is especially useful for build servers and other high-volume production
+environments. Ccache acts as a compiler cache that can be used to speed up rebuilds.
+This works very well if you use make clean often, or if you frequently
+switch between different build products.
    
+
+
    Note: If you're instead conducting incremental
+builds (such as an individual developer rather than a build server), ccache may
+slow your builds down by making you pay for cache misses.
    
+
+
    To use ccache, issue these commands in the root of the source tree:
    
+
+
    +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.
    
+
+
    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 file too.
    
+
+
    On Mac OS, you should replace linux-x86 with darwin-x86:
    
+
+
    +prebuilts/misc/darwin-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.
    
+
+
    On Linux, you can watch ccache being used by doing the following:
    
+
+
    +watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
+
    
+
+
    Next: Download the source
    
+
+
    Your build environment is good to go! Proceed to downloading the source.
    
+
+  
+
diff --git a/en/setup/jack.html b/en/setup/jack.html
new file mode 100644
index 00000000..558eef73
--- /dev/null
+++ b/en/setup/jack.html
@@ -0,0 +1,358 @@
+
+  
+    Compiling with Jack
+    
+    
+  
+  
+  
+
+
+
+
    Jack is an Android toolchain that compiles Java source into Android dex
+bytecode. It replaces the previous Android toolchain that consisted of multiple
+tools such as javac, ProGuard, jarjar, and dx. As Jack is the default Android
+build toolchain for Android 6.x, you don’t have to do anything differently to
+use Jack—just use your standard makefile commands to compile the tree or
+your project.
    
+
+
    About Jack
    
+
    The Jack toolchain provides the following advantages:
    
+
+Jack overview
+
    Figure 1. Jack overview.
    
+
+
      
+
    • Completely open source. Jack is available in AOSP and users
+are welcome to contribute.
      • 
+
    • Speeds compilation time. Jack has specific support for
+reducing compilation time using pre-dexing, incremental compilation, and a Jack
+compilation server.
      • 
+
    • Handles shrinking, obfuscation, repackaging, and multidex.
+Using a separate package (such as ProGuard) is no longer necessary.
      • 
+
    
+
+
    As of Android 7.0, Jack supports code coverage with JaCoCo. For details,
+refer to
+Code
+Coverage with JaCoCo and
+Java
+8 Language Features.
    
+
+
    Jack library format
    
+
+
    Jack has its own .jack file format that contains the pre-compiled dex code
+for the library, allowing for faster compilation (pre-dex).
    
+
+Jack library file contents
+
    Figure 2. Jack library file contents.
    
+
+
    Jill
    
+
+
    The Jill tool translates the existing .jar libraries into the new library
+format, as shown below.
    
+
+Importing .jar libraries with Jill
+
    Figure 3. Workflow to import an existing .jar
+library.
    
+
+
    Jack compilation server
    
+
+
+
+
    The first time Jack is used, it launches a local Jack compilation server on
+your computer. This server:
    
+
+
      
+
    • Brings an intrinsic speedup because it avoids launching a new host JRE JVM,
+loading Jack code, initializing Jack, and warming up the JIT at each
+compilation. It also provides very good compilation times during small
+compilations (e.g. in incremental mode).
      • 
+
    • Is a short-term solution to control the number of parallel Jack
+compilations. It avoids overloading your computer (memory or disk issue) because
+it limits the number of parallel compilations.
      • 
+
    
+
+
    The Jack server shuts itself down after an idle time without any compilation.
+It uses two TCP ports on the localhost interface and is not available
+externally. All parameters (number of parallel compilations, timeout, ports
+number, etc.) can be modified by editing the $HOME/.jack file.
    
+
+
    $HOME/.jack file
    
+
+
    The $HOME/.jack file contains the following settings for Jack
+server variables in a full bash syntax:
    
+
+
      
+
    • SERVER=true. Enable the server feature of Jack.
      • 
+
    • SERVER_PORT_SERVICE=8072. Set the TCP port number of the server
+for compilation purposes.
      • 
+
    • SERVER_PORT_ADMIN=8073. Set the TCP port number of the server
+for admin purposes.
      • 
+
    • SERVER_COUNT=1. Unused.
+
    • SERVER_NB_COMPILE=4. Set the maximum number of allowed parallel
+compilations.
      • 
+
    • SERVER_TIMEOUT=60. Set the number of idle seconds the server
+must wait without any compilation before shutting itself down.
      • 
+
    • SERVER_LOG=${SERVER_LOG:=$SERVER_DIR/jack-$SERVER_PORT_SERVICE.log}.
+Set the file where server logs are written. By default, this variable can be
+overloaded by an environment variable.
      • 
+
    • JACK_VM_COMMAND=${JACK_VM_COMMAND:=java}. Set the default
+command used to launch a JVM on the host. By default, this variable can be
+overloaded by environment variable.
      • 
+
    
+
+
    Troubleshooting Jack compilations
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    ProblemAction
    Your computer becomes unresponsive during compilation or you experience
+Jack compilations failing on “Out of memory error”You can improve the situation by reducing the number of simultaneous Jack
+compilations by editing $HOME/.jack and changing
+SERVER_NB_COMPILE to a lower value.
    Compilations are failing on “Cannot launch background server”The most likely cause is TCP ports are already used on your computer. Change
+ports by editing $HOME/.jack (SERVER_PORT_SERVICE and
+SERVER_PORT_ADMIN variables).
+
+

    If it doesn’t solve the problem, report the error (be sure to attach
+your compilation log and the Jack server log). To
+unblock the situation, disable the Jack compilation server by editing
+$HOME/.jack and changing SERVER to false.
+Unfortunately this will significantly slow down your compilation and may force
+you to launch make -j with load control (option -l
+of make).
+
    Compilation gets stuck without any progressReport and provide the following information when possible:
+
    
+
      
+
    • Command line at which you are stuck.
      • 
+
    • Output of this command line.
      • 
+
    • Result of executing jack-admin server-stat.
      • 
+
    • $HOME/.jack file.
      • 
+
    • Content of the Jack server log with the server state
+dumped. To get the server log:
+ 
        
+ 
      • Find the Jack background server process by running
+ jack-admin list-server.
        • 
+ 
      • Send a kill -3 command to this server to dump its state into
+ the log file.
        • 
+ 
      
+
      • 
+
    • Result of executing ls -lR $TMPDIR/jack-$USER.
      • 
+
    • Result of running ps j -U $USER.
      • 
+
    
+
+To unblock the situation, kill the Jack background server using
+jack-admin kill-server) then remove the temporary directories
+contained in jack-$USER of your temporary directory
+(/tmp or $TMPDIR).
+
    Other issuesTo report bugs or request features, use the public issue tracker at
+http://b.android.com.
+Use the
+Jack
+tool bug report or
+Jack
+tool feature request templates and remember to attach the Jack log to the
+bug report.
    
+
+
    Finding the Jack log
    
+If you ran a make command with a dist target, the Jack log is
+located at $ANDROID_BUILD_TOP/out/dist/logs/jack-server.log.
+Otherwise, you can find the log by running jack-admin server-log.
+In case of reproducible Jack failures, you can get a more detailed log by
+setting the following variable:
    
+
+
    +export ANDROID_JACK_EXTRA_ARGS="--verbose debug --sanity-checks on -D sched.runner=single-threaded"
+
    
+
+
    Use standard makefile commands to compile the tree (or your project) and
+attach standard output and error. To remove detailed build logs, run:
    
+
+
    +unset ANDROID_JACK_EXTRA_ARGS
+
    
+
+
    Jack limitations
    
+
+
      
+
    • By default, the Jack server is mono-user and can be used by only one user on
+a computer. To support additional users, select different port numbers for each
+user and adjust SERVER_NB_COMPILE accordingly. You can also disable
+the Jack server by setting SERVER=false in
+$HOME/.jack.
      • 
+
    • CTS compilation is slow due to current vm-tests-tf integration.
+
    • Bytecode manipulation tools (such as JaCoCo) are not supported.
      • 
+
    
+
+
    Using Jack
    
+
+
    Jack supports Java programming language 1.7 and integrates the additional
+features described below.
    
+
+
    Predexing
    
+
+
    When generating a Jack library file, the .dex of the library is generated and
+stored inside the .jack library file as a pre-dex. When compiling, Jack reuses
+the pre-dex from each library. All libraries are pre-dexed:
    
+
+Jack libraries with pre-dex
+
    Figure 4. Jack libraries with pre-dex.
    
+
+
    Jack does not reuse the library pre-dex if shrinking, obfuscation, or
+repackaging is used in the compilation.
    
+
+
    Incremental compilation
    
+
+
    Incremental compilation means that only the components touched since the last
+compilation (and their dependencies) are recompiled. Incremental compilation can
+be significantly faster than a full compilation when changes are limited to a
+set of components.
    
+
+
    Incremental compilation is not enabled by default (and is automatically
+deactivated when shrinking, obfuscation, repackaging or multi-dex legacy is
+enabled). To enable incremental builds, add the following line to the
+Android.mk file of the project you want to build incrementally:
    
+
+
    LOCAL_JACK_ENABLED := incremental
    
+
+
+
+
    Shrinking and obfuscation
    
+
+
    Jack uses proguard configuration files to enable shrinking and obfuscation.
    
+
+
    Common options include the following:
    
+
+
      
+  
    •  @
+  
    •  -include
+  
    •  -basedirectory
+  
    •  -injars
+  
    •  -outjars // only 1 output jar supported
+  
    •  -libraryjars
+  
    •  -keep
+  
    •  -keepclassmembers
+  
    •  -keepclasseswithmembers
+  
    •  -keepnames
+  
    •  -keepclassmembernames
+  
    •  -keepclasseswithmembernames
+  
    •  -printseeds
+
    
+
+
    Shrinking options include the following:
    
+
+
      
+  
    • -dontshrink
+
    
+
+
    Obfuscation options include the following:
    
+
+
      
+  
    •  -dontobfuscate
+  
    •  -printmapping
+  
    •  -applymapping
+  
    •  -obfuscationdictionary
+  
    •  -classobfuscationdictionary
+  
    •  -packageobfuscationdictionary
+  
    •  -useuniqueclassmembernames
+  
    •  -dontusemixedcaseclassnames
+  
    •  -keeppackagenames
+  
    •  -flattenpackagehierarchy
+  
    •  -repackageclasses
+  
    •  -keepattributes
+  
    •  -adaptclassstrings
+
    
+
+
    Ignored options include the following:
    
+
+
      
+  
    •  -dontoptimize // Jack does not optimize
+  
    •  -dontpreverify // Jack does not preverify
+  
    •  -skipnonpubliclibraryclasses
+  
    •  -dontskipnonpubliclibraryclasses
+  
    •  -dontskipnonpubliclibraryclassmembers
+  
    •  -keepdirectories
+  
    •  -target
+  
    •  -forceprocessing
+  
    •  -printusage
+  
    •  -whyareyoukeeping
+  
    •  -optimizations
+  
    •  -optimizationpasses
+  
    •  -assumenosideeffects
+  
    •  -allowaccessmodification
+  
    •  -mergeinterfacesaggressively
+  
    •  -overloadaggressively
+  
    •  -microedition
+  
    •  -verbose
+  
    •  -dontnote
+  
    •  -dontwarn
+  
    •  -ignorewarnings
+  
    •  -printconfiguration
+  
    •  -dump
+
    
+
+
+
+
    Repackaging
    
+
+
    Jack uses jarjar configuration files to do repackaging. While Jack is
+compatible with "rule" rule types, it is not compatible with "zap" or
+"keep" rule types. If you need "zap" or "keep" rule types, file a feature
+request with a description of how you use the feature in your app.
    
+
+
    Multidex support
    
+
+
    Jack offers native and legacy multidex support. Since dex files are limited
+to 65K methods, apps with over 65K methods must be split into multiple dex
+files. For more details, refer to
+Building
+Apps with Over 65K Methods.
    
+
+  
+
diff --git a/en/setup/known-issues.html b/en/setup/known-issues.html
new file mode 100644
index 00000000..e72de555
--- /dev/null
+++ b/en/setup/known-issues.html
@@ -0,0 +1,78 @@
+
+  
+    Source Sync Issues
+    
+    
+  
+  
+  
+
+  
    Even with our best care, small problems sometimes slip in. This page details
+   some known issues you may encounter while trying to sync the Android source code.
+
+
    
+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 transferred.
    
+
    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 (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, enter the command:
    
+
    sysctl -w net.ipv4.tcp_window_scaling=0
    
+
    On MacOS, disable the rfc1323 extension in the network settings.
    
+
+
+  
+
diff --git a/en/setup/licenses.html b/en/setup/licenses.html
new file mode 100644
index 00000000..a2114a2b
--- /dev/null
+++ b/en/setup/licenses.html
@@ -0,0 +1,110 @@
+
+  
+    Content License
+    
+    
+  
+  
+  
+
+
+
+
    The Android Open Source Project uses a few 
+open source initiative
+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, Version 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 that 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.
    
+
    Contributor License Agreements
    
+
    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 Agreement. The agreement can be executed online through the
+code review tool.
+The agreement 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 Agreement is available.
+This version of the agreement allows a
+corporation to authorize contributions submitted by its designated employees
+and to grant copyright and patent licenses. Note that a Corporate Contributor
+License Agreement does not remove the need for any developer to sign their own
+Individual Contributor License Agreement as an individual. The individual
+agreement is needed to cover any of their contributions that are not
+owned by the corporation signing the Corporate Contributor License Agreement.
    
+
    Please note we based our agreements on the ones the
+Apache Software Foundation uses, which can
+be found on the Apache web site.
    
+
    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, and 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 just that.
    
+
    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.
      • 
+
+
    • 
+
      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 are
+passionate about 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 licensed. However, we love all free
+and open source licenses, and respect others' opinions and preferences. We've
+simply decided ASL2.0 is the right license for our goals.
    
+
+  
+
diff --git a/en/setup/life-of-a-bug.html b/en/setup/life-of-a-bug.html
new file mode 100644
index 00000000..571b7cd6
--- /dev/null
+++ b/en/setup/life-of-a-bug.html
@@ -0,0 +1,151 @@
+
+  
+    Life of a Bug
+    
+    
+  
+  
+  
+
+
+
    The Android Open Source Project maintains a public issue tracker where you
+can report bugs and request features for the core Android software stack.
+(For details on this issue tracker, please see the
+Reporting Bugs 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.
    
+
+
    The Android Open Source Project (AOSP) issue tracker is
+intended only for bugs and feature requests related to the core Android
+software stack, and is a technical tool for the Open Source community.
    
+
+
    This is not a customer support forum. For support information, see the
+Nexus and 
+Pixel help centers.
+Support for other devices is provided by the device manufacturers or by the
+carriers selling those devices.
    
+
+
    Support for Google applications is through
+Google's support site. Support
+for third-party applications is with each application's developer, e.g.
+through the contact information provided on Google Play.
    
+
+
    Here's the life of a bug, in a nutshell:
    
+
      
+
    1. A bug is filed, and has the state "New".
      2. 
+
    2. An AOSP maintainer periodically reviews and triages bugs. Bugs are
+triaged into one of four buckets: New, Open, No-Action, or Resolved.
      3. 
+
    3. Each bucket includes a number of states that provide more detail on the
+fate of the issue.
      4. 
+
    4. Bugs marked as "Resolved" will eventually be included in a future
+release of the Android software.
      5. 
+
    
+
+
+
    Bucket details
    
+
    
+We use the Status field in Issue Tracker to specify the status
+of an issue in the resolution process. This is consistent with the definitions
+specified in the Issue
+    Tracker documentation.
+
    
+
    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 maintainer.)
      • 
+ 
    • New + Hotlist: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.
+
    
+
      
+ 
    • Assigned: The bug report has been recognized as an
+ adequately detailed report of a legitimate issue and the bug has been assigned
+ to a specific contributor to assess and analyze.
      • 
+ 
    • Accepted: The assignee has acknowledged the issue and has
+ started to work on it.
      • 
+
    
+
    
+Typically, a bug starts in Assigned, and remains there until
+someone intends to resolve it, at which point it enters
+Accepted. However, note that this isn't a guarantee, and it's
+not uncommon for bugs to go from Assigned 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 a high-quality contribution fixing that
+bug is likely to get accepted. However, it's impossible to guarantee a fix in
+time for any particular release.
+
    
+
    No-Action issues
    
+
    
+This bucket contains bugs that are deemed to not require any action.
+
    
+
      
+ 
    • Won't Fix (Not reproducible): 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, or
+ there was not enough information to fix the issue.
      • 
+ 
    • Won't Fix (Intended behavior): An AOSP maintainer has
+ determined that the behavior described isn't a bug, but is the intended
+ behavior. This state is also commonly referred to as working as
+ intended (WAI). For feature requests, an AOSP maintainer has determined
+ that the request is not going to be implemented in Android.
      • 
+ 
    • Won't Fix (Obsolete): The issue is no longer relevant due
+ to changes in the product.
      • 
+ 
    • Won't Fix (Infeasible): The changes that are needed to
+ address the issue are not reasonably possible. This status is also used for
+ issues reported that cannot be handled in AOSP, typically because it is related
+ to a customized device or to an external application, or the reporter mistook
+ this tracker as a help forum.
      • 
+ 
    • Duplicate: There was already an identical report in the
+ issue tracker. Any actual action will be reported on that report.
      • 
+
    
+
    Resolved issues
    
+
    
+This bucket contains bugs that have had action taken, and are now considered
+resolved.
+
    
+
      
+ 
    • Fixed (verified): This bug has been fixed, and is included
+ in a formal release. When this state is set, we try to also set a property
+ indicating which release it was fixed in.
      • 
+ 
    • Fixed: This bug has been fixed (or feature implemented) in
+ a source tree, but might not yet been included in a formal release.
      • 
+
    
+
    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.
    
+  
+
diff --git a/en/setup/life-of-a-patch.html b/en/setup/life-of-a-patch.html
new file mode 100644
index 00000000..6f8d144a
--- /dev/null
+++ b/en/setup/life-of-a-patch.html
@@ -0,0 +1,38 @@
+
+  
+    Life of a Patch
+    
+    
+  
+  
+  
+
+
+
    The Android Open Source Project (AOSP) uses a web-based code review tool
+known as Gerrit.
+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 page.
    
+workflow diagram
+
    
+  Figure 1. Patch workflow
+
    
+
+  
+
diff --git a/en/setup/read-bug-reports.html b/en/setup/read-bug-reports.html
new file mode 100644
index 00000000..63ff5cc0
--- /dev/null
+++ b/en/setup/read-bug-reports.html
@@ -0,0 +1,1018 @@
+
+  
+    Reading Bug Reports
+    
+    
+  
+  
+  
+
+
+
+
    Bugs are a reality in any type of development—and bug reports are
+critical to identifying and solving problems. All versions of Android support
+capturing bug reports with Android
+Debug Bridge (adb); Android versions 4.2 and higher support a
+Developer
+Option for taking bug reports and sharing via email, Drive, etc.
    
+
+
    Android bug reports contain dumpsys, dumpstate, and
+logcat data in text (.txt) format, enabling you to easily search
+for specific content. The following sections detail bug report components,
+describe common problems, and give helpful tips and grep commands
+for finding logs associated with those bugs. Most sections also include examples
+for grep command and output and/or dumpsys output.
    
+
+
    Logcat
    
+
    The logcat log is a string-based dump of all logcat
+information. The system part is reserved for the framework and
+has a longer history than main which contains everything else.
+Each line starts with timestamp PID TID log-level.
    
+
+  
+
+
    Viewing the event log
    
+
    This log contains string representations of binary-formatted log messages. It
+is less noisy than the logcat log but also a little harder to read.
+When viewing event logs, you can search this section for specific process ID
+(PID) to see what a process has been doing. The basic format is:
+timestamp PID TID log-level log-tag tag-values.
    
+
+
    Log levels include the following:
    
+
      
+
    • V: verbose
      • 
+
    • D: debug
      • 
+
    • I: information
      • 
+
    • W: warning
      • 
+
    • E: error
      • 
+
    
+
+  
+
     
    
+
    For other useful event log tags, refer to
+/services/core/java/com/android/server/EventLogTags.logtags.
    
+
+
    ANRs and deadlocks
    
+
    Bugreports can help you identify what's causing
+Application
+Not Responding (ANR) errors and deadlock events.
    
+
+
    Identifying unresponsive apps
    
+
    When an application does not respond within a certain time, usually due to a
+blocked or busy main thread, the system kills the process and dumps the stack to
+/data/anr. To discover the culprit behind an ANR, grep for
+am_anr in the binary event log.
    
+
+  
+
+
    
+
    You can also grep for ANR in in the logcat log,
+which contains more information about what was using CPU at the time of the ANR.
+
    
+
+  
+
+
    Finding stack traces
    
+
    You can often find stack traces that correspond to an ANR. Make sure the
+timestamp and PID on the VM traces match the ANR you are investigating, then
+check the main thread of the process. Keep in mind:
    
+
      
+
    • The main thread tells you only what the thread was doing at the time of the
+ANR, which may or may not correspond to the true cause of the ANR. (The stack in
+the bug report may be innocent; something else may have been stuck for a long
+time—but not quite long enough to ANR—before becoming unstuck.)
+
      • 
+
    • More than one set of stack traces (VM TRACES JUST NOW and
+VM TRACES AT LAST ANR) might exist. Make sure you are viewing the
+correct section.
      • 
+
    
+
+  
+
+
    Finding deadlocks
    
+
    Deadlocks often first appear as ANRs because threads are getting stuck. If
+the deadlock hits the system server, the watchdog will eventually kill it,
+leading to an entry in the log similar to:
+WATCHDOG KILLING SYSTEM PROCESS. From the user perspective, the
+device reboots, although technically this is a runtime restart rather than a
+true reboot.
    
+
+
      
+
    • In a runtime restart, the system server dies and is
+restarted; the user sees the device return to the boot animation.
      • 
+
    • In a reboot, the kernel has crashed; the user sees the
+device return to the Google boot logo.
      • 
+
    
+
+
    To find deadlocks, check the VM traces sections for a pattern of thread A
+waiting on something held by thread B, which in turn is waiting on something
+held by thread A.
    
+
+  
+
+
+
    Activities
    
+
    An Activity
+is an application component that provides a screen users interact with to do
+something such as dial a number, take a photo, send an email, etc. From a bug
+report perspective, an
+activity
+is a single, focused thing a user can do, which makes locating the activity that
+was in focus during a crash very important. Activities (via ActivityManager)
+run processes, so locating all process stops and starts for a given activity can
+also aid troubleshooting.
    
+
+
    Viewing focused activities
    
+
    To view a history of focused activities, search for
+am_focused_activity.
    
+
+  
+
+
    Viewing process starts
    
+
    To view a history of process starts, search for Start proc.
    
+
+  
+
+
    Is the device thrashing?
    
+
    To determine if the device is
+thrashing,
+check for an abnormal increase in activity around am_proc_died and
+am_proc_start in a short amount of time.
    
+
+  
+
+
    Memory
    
+
    Because Android devices often have constrained physical memory, managing
+random-access memory (RAM) is critical. Bug reports contain several indicators
+of low memory as well as a dumpstate that provides a memory snapshot.
    
+
+
    Identifying low memory
    
+
    Low memory can cause the system to thrash as it kills some processes to free
+memory but continues to start other processes. To view corroborating evidence of
+low memory, check for concentrations of am_proc_died and
+am_proc_start entries in the binary event log.
    
+
+
    Low memory can also slow task switching and thwart return attempts (because
+the task the user was trying to return to was killed). If the launcher was
+killed, it restarts when the user touches the home button and logs show the
+launcher reload its content.
    
+
+
    Viewing historical indicators
    
+
    The am_low_memory entry in the binary event log indicates the
+last cached process has died. After this, the system starts killing services.
+
+  
    
+
+
    Viewing thrashing indicators
    
+
    Other indicators of system thrashing (paging, direct reclaim, etc.) include
+kswapd, kworker, and mmcqd consuming
+cycles. (Keep in mind the bugreport being gathered can influence thrashing
+indicators.)
    
+
+  
+
    
+
+
    ANR logs can provide a similar memory snapshot.
    
+
+  
+
+
    Getting a memory snapshot
    
+
    The memory snapshot is a dumpstate that lists running Java and native
+processes (for details, refer to
+Viewing
+Overall Memory Allocations). Keep in mind the snapshot gives only the state
+at a specific moment in time; the system might have been in better (or worse)
+shape before the snapshot.
    
+
+
+  
+
+
    Broadcasts
    
+
    Applications generate broadcasts to send events within the current
+application or to another application. Broadcast receivers subscribe to specific
+messages (via filters), enabling them to both listen and respond to a broadcast.
+Bug reports contain information about sent broadcasts and unsent broadcasts, as
+well as a dumpsys of all receivers listening to a specific broadcast.
    
+
+
    Viewing historical broadcasts
    
+
    Historical broadcasts are those that have already been sent, listed in
+reverse chronological order.
    
+
+
    The summary section is an overview of the last 300
+foreground broadcasts and the last 300 background broadcasts.
    
+
+  
+
    
+
+
    The detail section contains complete information for the
+last 50 foreground broadcasts and the last 50 background broadcasts, as well as
+the receivers for each broadcast. Receivers that have a:
    
+
      
+
    • BroadcastRecord entry are registered at runtime and are sent
+only to already running processes.
      • 
+
    • ResolveInfo entry are registered through manifest entries. The
+ActivityManager starts the process for each ResolveInfo if it is
+not already running.
      • 
+
    
+
+  
+
+
    Viewing active broadcasts
    
+
    Active broadcasts are those that have yet to be sent. A large number in the
+queue means the system can't dispatch the broadcasts fast enough to keep up.
    
+
+  
+
+
    Viewing broadcast listeners
    
+
    To view a list of receivers listening for a broadcast, check the Receiver
+Resolver Table in the dumpsys activity broadcasts. The following
+example displays all receivers listening for USER_PRESENT.
    
+
+  
+
+
    Monitor contention
    
+
    Monitor contention logging can sometimes indicate actual monitor contention,
+but most often indicates the system is so loaded that everything has slowed down.
+You might see long monitor events logged by ART in system or event log.
    
+
+
    In the system log:
    
+
    10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s
    
+
+
    In the event log:
    
+
    10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]
    
+
+
    Background compilation
    
+
    Compilation can be expensive and load the device.
    
+
+  
+
    
+
+
    Compilation might occur in the background when Google Play store updates are
+downloading. In this case, messages from the Google Play store app
+(finsky) and installd appear prior to
+dex2oat messages.
    
+
+  
+
    
+
+
    Compilation might also occur in the background when an application is loading
+a dex file that has not yet been compiled. In this case, you won't see
+finsky or installd logging.
    
+
+  
+
+
    Narrative
    
+
    Establishing the narrative of a problem (how it started, what happened, how
+the system reacted) requires a solid timeline of events. You can use the
+information in the bug report to sync timelines across multiple logs and
+determine the exact timestamp of the bug report.
    
+
+
    Syncing timelines
    
+
    A bugreport reflects multiple parallel timelines: system log, event log,
+kernel log, and multiple specialized timelines for broadcasts, battery stats,
+etc. Unfortunately, timelines are often reported using different time bases.
    
+
+
    The system and event log timestamps are in the same timezone as the user (as
+are most other timestamps). For example, when user taps the home button, the
+system log reports:
    
+
    10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0
    
+
+
    For the same action, the event log reports:
    
+
    10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
    
+
+
    Kernel (dmesg) logs use a different time base, tagging log items
+with seconds since bootloader completes. To register this timescale to other
+timescales, search for suspend exit and suspend entry messages:
    
+
    <6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
+…
+<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC
    
+
+
    Because kernel logs might not include time while in suspend, you should
+piecewise register the log between the suspend entry and exit messages.
+Additionally, kernel logs use UTC timezone and must be adjusted to the user
+timezone.
    
+
+
    Identifying bugreport time
    
+
    To determine when a bugreport was taken, first check the system log (Logcat)
+for the dumpstate: begin:
    
+
    10-03 17:19:54.322 19398 19398 I dumpstate: begin
    
+
+
    Next, check the kernel log (dmesg) timestamps for the Starting service
+'bugreport' message:
    
+
    <5>[207064.285315] init: Starting service 'bugreport'...
    
+
+
    Work backwards to correlate the two events, keeping in mind the caveats
+mentioned in Syncing timelines. While there's a lot
+happening after the bugreport is initiated, most activity isn't very useful as
+the act of taking the bugreport loads the system substantially.
    
+
+
    Power
    
+
+
    The event log contains screen power status, where 0 is screen off, 1 is
+screen on, and 2 is for keyguard done.
    
+
+  
+
+
    
+
    Bug reports also contain statistics about wake locks, a mechanism used by
+application developers to indicate their application needs to have the device
+stay on. (For details on wake locks, refer to
+PowerManager.WakeLock
+and Keep
+the CPU on.)
+
+
    The aggregated wake lock duration statistics track only the
+time a wake lock is actually responsible for keeping the device awake and
+do not include time with the screen on. In addition, if
+multiple wake locks are held simultaneously, the wake lock duration time is
+distributed across those wake locks.
    
+
+
    For more help visualizing power status, use
+Battery Historian, a
+Google open source tool to analyze battery consumers using Android bugreport
+files.
    
+
+
    Packages
    
+
    The DUMP OF SERVICE package contains application versions (and other useful
+info).
    
+
+  
+
+
    Processes
    
+
    Bug reports contain a huge amount of data for processes, including start and
+stop time, runtime length, associated services, oom_adj score, etc.
+For details on how Android manages processes, refer to
+Processes
+and Threads.
    
+
+
    Determining process runtime
    
+
    The procstats section contains complete statistics on how long
+processes and associated services have been running. For a quick, human-readable
+summary, search for AGGREGATED OVER to view data from either the
+last three or 24 hours, then search for Summary: to view the list
+of processes, how long those processes have run at various priorities, and their
+RAM usage formatted as min-average-max PSS/min-average-max USS.
    
+
+  
+
+
    Why is a process running?
    
+
    The dumpsys activity processes section lists all currently
+running processes ordered by oom_adj score (Android indicates
+process importance by assigning the process an oom_adj value, which
+can be dynamically updated by ActivityManager). The output is similar to that of
+a memory snapshot but includes additional
+information about what is causing the process to run. In the example below,
+the bolded entries indicate the gms.persistent process is running
+at vis (visible) priority because the system process is bound to
+its NetworkLocationService.
    
+
+  
+
+
    Scans
    
+
    Use the following steps to identify applications performing excessive
+Bluetooth Low Energy (BLE) scans:
    
+
      
+
    • Find log messages for BluetoothLeScanner:
+
      +$ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
+07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
+
      • 
+
    • Locate the PID in the log messages. In this example, "24840" and
+"24851" are PID (process ID) and TID (thread ID).
      • 
+
    • Locate the application associated with the PID:
+
      +PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
+
      
+
      In this example, the package name is com.badapp.
      • 
+
    • Look up the package name on Google Play to identify the responsible
+application:
+https://play.google.com/store/apps/details?id=com.badapp.
      • 
+
    
+
    Note: For devices running Android 7.0, the
+system collects data for BLE scans and associates these activities
+with the initiating application. For details, see
+Low Energy (LE)
+and Bluetooth scans.
    
+
+  
+
diff --git a/en/setup/report-bugs.html b/en/setup/report-bugs.html
new file mode 100644
index 00000000..85ea2fd4
--- /dev/null
+++ b/en/setup/report-bugs.html
@@ -0,0 +1,314 @@
+
+  
+    Reporting Bugs
+    
+    
+  
+  
+  
+
    
+Thank you for your interest in Android! You can help improve Android by
+reporting issues and feature requests in the
+Android Issue Tracker. The Android Issue Tracker
+contains a list of pending technical tasks across a variety of topics,
+information relevant to those tasks, and information about progress on those
+tasks, including which ones might get worked on in the short term.
+
    
+
    For more information about why we switched to Issue Tracker, see this
+blog post.
    
+
    
+Issue Tracker is not a customer support forum. For support information, see the
+Nexus and
+Pixel help centers. Support for
+other devices is provided by the device manufacturers or by the carriers selling
+those devices.
+
    
+
    
+Support for Google applications is through
+Google's support site. Support for
+third-party applications is provided by the application's developer, e.g.
+through the contact information provided on Google Play. For a list of more
+Android support resources, see our Community page.
+
    
+
    
+There are no guarantees 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.
+
    
+
    Filing a bug
    
+
      
+
    1. Search
+for your bug to see if anyone has already reported it. Don't forget to
+search for all issues, not just open ones, as your issue might already have been
+reported and closed. To help you find the most popular results, sort the result
+by number of stars.
      2. 
+
    2. If you find your issue and it's important to you,
+star
+it! The number of
+stars on a bug helps us know which bugs are most important to fix.
      3. 
+
    3. If no one has reported your bug, file the bug. First,
+browse for the correct
+component, such as Framework
+or Networking,
+and fill out the provided template. Or select the desired bug queue from the
+tables below.
+
      
+Tip: Some components contain sub-components, like Network >
+Messaging and Framework > Storage.
+
      
+
      4. 
+
    4. Include as much information in bugs as you can, following the instructions
+for the bug queue you're targeting. A bug that simply says something isn't
+working doesn't help much, and will probably be closed without any action. The
+amount of detail you provide, such as log files, repro steps, and even a patch
+set, helps us address your issue.
      5. 
+
    
+
    Bug queues
    
+
    
+The Android Issue Tracker has a variety of sub-components in a number of
+categories related to Android. There are subcomponents for security, the
+platform, Android Developer Tools, documentation, and more.
+
    
+
+
    Security
    
+
    
+If you find an issue that impacts the security of Android or components in Nexus
+or Pixel devices, follow the instructions
+here.
+Additionally, security bugs are eligible for the
+Android
+Security Vulnerability Rewards Program.
+
    
+
    
+Because of the sensitive nature of security bugs, you won't be able to browse
+open issues, only closed issues or issues that have been made public.
+
    
+
+
+
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+
    Browse bugsDetailsFile a bug
    SecurityAndroid Security details
+   bug_report
    
+
+
    Platform
    
+
    
+If you find an issue that impacts an aspect of the Android platform, file your
+bug in one of these components.
+
    
+
    Browse all platform issues
    
+
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+
    Browse bugsFile a bug
    ARTbug_report
    Browserbug_report
    CTSbug_report
    Frameworkbug_report
    GfxMediabug_report
    Instant Appsbug_report
    Jackbug_report
    Libcorebug_report
    Networkingbug_report
    Securitybug_report
    Systembug_report
    Textbug_report
    Thingsbug_report
    Wearbug_report
    
+
+
    Android Developer Tools
    
+
    
+If you find an issue that impacts one of the Android Developer tools, such as
+Android Studio, SDK, Emulator, System Images, or Support Library, file a bug in
+one of these components.
+
    
+
    
+As the tools have different requirements, read the
+General Bug filing
+details and the linked details for the tool.
+
    
+
+Browse all
+Developer Tools issues
+
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+
    Browse bugsDetailsFile a bug
    Android
+StudioAndroid
+Studio details
+   bug_report
    C++Issues in Android Studio
+   bug_report
    Emulator or
+System ImagesEmulator
+    details
+   bug_report
    GradleGradle
+   details
+   bug_report
    Instant
+RunInstant
+   Run details
+   bug_report
    Lint
+   bug_report
    NDKStandalone NDK issuesbug_report
    Profilers
+   bug_report
    Support
+Library
+   bug_report
    Test
+Support Library 
+   bug_report
    
+
+
    Documentation
    
+
    
+If you find an issue with this site or with
+developer.android.com,
+file a bug and a writer will help.
+
    
+
+
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+
    Browse bugsFile a bug
    developer.android.com
+   bug_report
    source.android.com
+   bug_report
    
+
+ 
+
diff --git a/en/setup/requirements.html b/en/setup/requirements.html
new file mode 100644
index 00000000..ced64cd3
--- /dev/null
+++ b/en/setup/requirements.html
@@ -0,0 +1,173 @@
+
+  
+    Requirements
+    
+    
+  
+  
+  
+
+
+
+
    Before you download and build the Android source, ensure your system meets
+  the following requirements. Then see Establishing a
+  Build Environment for installation instructions by operating system.
    
+
+
    Hardware requirements
    
+
+
    Your development workstation should meet or exceed these hardware requirements:
    
+
+
      
+
+  
    • 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.
+  
      • 
+
+  
    • At least 100GB of free disk space to checkout the code and an extra 150GB
+  to build it. If you conduct multiple builds or employ ccache, you will need
+  even more space.
      
+  
      • 
+
+  
    • If you are running Linux in a virtual machine, you need at
+  least 16GB of RAM/swap.
+  
      • 
+
+
    
+
+
    Software requirements
    
+
+
    The Android Open Source Project
+  (AOSP) master branch is traditionally developed and tested
+  on Ubuntu Long Term Support (LTS) releases, but other distributions may be
+  used. See the list below for recommended versions.
    
+
+
    You workstation must have the software listed below. See Establishing a Build Environment for
+  additional required packages and the commands to install them.
    
+
+
    OS and JDK
    
+
+
    If you are developing against the AOSP master branch, use one
+of these operating systems: Ubuntu 14.04 (Trusty) or Mac OS v10.10 (Yosemite)
+or later with Xcode 4.5.2 and Command Line Tools.
    
+
+
    For the Java Development Kit (JDK), note the master branch of
+Android in AOSP comes with a prebuilt version of OpenJDK; so no additional
+installation is required. Older versions require a separate install.
    
+
+
    See Packages for older versions.
+
+
    Key packages
    
+  
+
+
    Device binaries
    
+
    Download previews, factory images, drivers, over-the-air (OTA) updates, and
+other blobs below. See Obtaining
+  proprietary binaries for additional details.
    
+  
+
+  
    Build toolchain
    
+
+  
    Android 8.0 and later support only Clang/LLVM
+ for building the Android platform. Join the android-llvm
+ group to pose questions and get help. Report NDK/compiler issues at the NDK GitHub.
    
+
+
    For the
+Native
+Development Kit (NDK) and legacy kernels, GCC 4.9 included
+in the AOSP master branch (under prebuilts/) may also be used.
    
+
+
    Packages for older versions
    
+
+
    The sections below provide relevant operating systems and JDK packages for
+older versions of Android.
    
+
+
    Operating system
    
+
+
    Android is typically built with a GNU/Linux or Mac OS operating system. It is
+  also possible to build Android in a virtual machine on unsupported systems such
+  as Windows.
    
+
+  
    GNU/Linux
    
+
+  
      
+    
    • Android 6.0 (Marshmallow) - AOSP master: Ubuntu 14.04 (Trusty)
      • 
+    
    • Android 2.3.x (Gingerbread) - Android 5.x (Lollipop): Ubuntu 12.04 (Precise)
      • 
+    
    • Android 1.5 (Cupcake) - Android 2.2.x (Froyo): Ubuntu 10.04 (Lucid)
      • 
+  
    
+
+
    Mac OS (Intel/x86)
    
+
+  
      
+    
    • Android 6.0 (Marshmallow) - AOSP master: Mac OS v10.10 (Yosemite) or
+    later with Xcode 4.5.2 and Command Line Tools
      • 
+    
    • Android 5.x (Lollipop): Mac OS v10.8 (Mountain Lion) with Xcode 4.5.2
+    and Command Line Tools
      • 
+    
    • Android 4.1.x-4.3.x (Jelly Bean) - Android 4.4.x (KitKat): Mac OS v10.6
+    (Snow Leopard) or Mac OS X v10.7 (Lion) and Xcode 4.2 (Apple's Developer
+    Tools)
      • 
+    
    • Android 1.5 (Cupcake) - Android 4.0.x (Ice Cream Sandwich): Mac OS
+    v10.5 (Leopard) or Mac OS X v10.6 (Snow Leopard) and the Mac OS X v10.5
+    SDK
      • 
+  
    
+
+
    JDK
    
+
+
    See Installing the JDK
+for the prebuilt path and installation instructions for older versions.
    
+  
+
+  
    Make
    
+  
     Android 4.0.x (Ice Cream Sandwich) and earlier will need to revert from make 3.82
+  to avoid build errors
    .
+
+  
+
diff --git a/en/setup/roles.html b/en/setup/roles.html
new file mode 100644
index 00000000..03e2b826
--- /dev/null
+++ b/en/setup/roles.html
@@ -0,0 +1,102 @@
+
+  
+    Project Roles
+    
+    
+  
+  
+  
+
+
+
    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.
    
+
    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 Contributing.
    
+
    Contributor
    
+
    "Contributors" are those making contributions to the AOSP source code,
+including both employees of Google or other companies, as well as individual
+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
    
+
    "Developers" are engineers writing applications that run on Android
+devices. There is often little 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
+(along with users) are the "customers" of the platform 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, verifiers act similarly to 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 Lead
    
+
    Android consists of a number of sub-projects; you can see these in the git
+repository as individual .git files. "Project leads" are senior contributors who
+oversee the engineering for individual Android projects. Typically these project
+leads are Google employees. A project lead for an individual project is
+responsible for the following:
    
+
      
+
    • 
+
      Lead all technical aspects of the project, including the project roadmap,
+  development, release cycles, versioning, and quality assurance (QA).
      
+
      • 
+
    • 
+
      Ensure the project is tested by QA 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/en/setup/running.html b/en/setup/running.html
new file mode 100644
index 00000000..e3d9f62d
--- /dev/null
+++ b/en/setup/running.html
@@ -0,0 +1,446 @@
+
+  
+    Running Builds
+    
+    
+  
+  
+  
+
+
+
+
    This page provides details for running builds on specific devices and
+complements the information in Building the
+System.
    
+
+
    Building fastboot and adb
    
+
    If you don't already have fastboot and adb, you can
+build them with the regular build system. Use the instructions in
+Building a System and replace the
+main make command with:
    
+
    make fastboot adb
    
+
+
    Booting into fastboot mode
    
+
    Fastboot is a bootloader mode in which you can flash a device.
+During a cold boot of a device, use the following key combinations to boot into
+fastboot mode:
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    DeviceCode nameKeys
    Pixel XLmarlinPress and hold Volume Down, then press and hold Power.
    PixelsailfishPress and hold Volume Down, then press and hold Power.
    hikeyhikeyLink pins 1 - 2 and 5 - 6 of J15.
    Nexus 6PanglerPress and hold Volume Down, then press and hold Power.
    Nexus 5XbullheadPress and hold Volume Down, then press and hold Power.
    Nexus 6shamuPress and hold Volume Down, then press and hold Power.
    Nexus PlayerfuguPress and hold Power.
    Nexus 9volantisPress and hold Volume Down, then press and hold Power.
    Nexus 5hammerheadPress and hold both Volume Up and Volume Down, then press
+and hold Power.
    Nexus 7floPress and hold Volume Down, then press and hold Power.
    Nexus 7 3GdebPress and hold Volume Down, then press and hold Power.
    Nexus 10mantaPress and hold both Volume Up and Volume Down, then press
+and hold Power.
    Nexus 4makoPress and hold Volume Down, then press and hold Power.
    Nexus 7 (2012)grouperPress and hold Volume Down, then press and hold Power.
    Nexus 7 3G (2012)tilapiaPress and hold Volume Down, then press and hold Power.
    Nexus QphantasmPower the device then cover it with one hand after the LEDs light up and
+until they turn red.
    Galaxy Nexus GSMmaguroPress and hold both Volume Up and Volume Down, then press
+and hold Power.
    Galaxy Nexus (Verizon)toroPress and hold both Volume Up and Volume Down, then press
+and hold Power.
    Galaxy Nexus (Sprint)toroplusPress and hold both Volume Up and Volume Down, then press
+and hold Power.
    Motorola XoomwingrayPress and hold Volume Down, then press and hold Power.
    Nexus ScrespoPress and hold Volume Up, then press and hold Power.
    Nexus SGcrespo4gPress and hold Volume Up, then press and hold Power.
    
+
+
    You can also use the command adb reboot bootloader to reboot
+from Android directly into the bootloader with no key combinations.
    
+
+
    Unlocking the bootloader
    
+
+
    You can flash a custom system only if the bootloader allows it, and the
+bootloader is locked by default. You can unlock the bootloader, but doing so
+deletes user data for privacy reasons. After unlocking, all data on the
+device is erased, i.e. both application private data and shared data accessible
+over USB (including photos and movies). Before attempting to unlock the
+bootloader, be sure to back up any important files on the device.
    
+
+
    You need to unlock the bootloader only once, and you can re-lock it if
+necessary.
    
+
+
    Unlocking recent devices
    
+
    All Nexus and Pixel devices released since 2014 (starting with Nexus 6 and
+Nexus 9) have factory reset protection and require a multi-step process to
+unlock the bootloader.
    
+
+
      
+
    1. To enable OEM unlocking on the device:
+  
        
+  
      1. In Settings, tap About phone, then tap Build
+  number seven (7) times.
        2. 
+  
      2. When you see the message "You are a developer", tap the back button.
        3. 
+  
      3. Tap Developer options and enable
+  OEM unlocking and USB debugging. (If OEM
+  unlocking is disabled, connect to the Internet so the device can check in at
+  least once. If it remains disabled, your device may be SIM locked by your
+  carrier and the bootloader cannot be unlocked.)
        4. 
+  
      
+
      2. 
+
    2. Reboot into the bootloader and use fastboot to unlock it.
+  
        
+  
      • For new devices (2015 and later):
+  
        fastboot flashing unlock
        
+  
        • 
+  
      • For older devices (2014 and earlier):
+  
        fastboot oem unlock
        
+  
        • 
+  
      
+
      3. 
+
    3. Confirm the unlock onscreen.
      4. 
+
    
+
+
+
+
    Re-locking the bootloader
    
+
    To re-lock the bootloader:
    
+
      
+
    • For new devices (2015 and later):
+
      fastboot flashing lock
      
+
      • 
+
    • For older devices (2014 and earlier):
+
      fastboot oem lock
      
+
      • 
+
    
+
+
+
+
    Using Flash Unlock
    
+
    The getFlashLockState() system API transmits the bootloader
+state and the PersistentDataBlockManager.getFlashLockState() system
+API returns the bootloader’s lock status on compliant devices.
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    Return valueConditions
    FLASH_LOCK_UNKNOWNReturned only by devices upgrading to Android 7.x or higher that did not
+previously support the bootloader changes required to get the flash lock
+status if they supported flashing lock/unlock capability.
    
+
      
+
    • New devices running Android 7.x or higher must be in either
+FLASH_LOCK_LOCKED or FLASH_LOCK_UNLOCKED state.
      • 
+
    • Devices upgrading to Android 7.x or higher that do not support flashing
+unlock/lock capability should return FLASH_LOCK_LOCKED state.
      • 
+
    
+
    FLASH_LOCK_LOCKEDShould be returned by any device that does not support flashing
+lock/unlock (i.e. the device is always locked), or any device that does support
+flashing lock/unlock and is in the locked state.
    FLASH_LOCK_UNLOCKEDReturned by any device that supports flashing lock/unlock and is currently
+in the unlocked state.
    
+
+
    Manufacturers should test the values returned by devices with locked and
+unlocked bootloaders. For an example, the Android Open Source Project (AOSP)
+contains a reference implementation that returns a value based on the
+ro.boot.flash.locked boot property. Example code is located in the
+following directories:
    
+
+
      
+
    • frameworks/base/services/core/java/com/android/server/PersistentDataBlockService.java
      • 
+
    • frameworks/base/core/java/android/service/persistentdata/PersistentDataBlockManager.java
      • 
+
    
+
+
    Selecting a device build
    
+
+
    The recommended builds for devices are available from the lunch
+menu, accessed when running the lunch command with no arguments.
+You can download factory images and binaries for Nexus devices from
+developers.google.com. See Device
+binaries for downloads. For details and additional resources, see Obtaining proprietary
+binaries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    DeviceCode nameBuild configuration
    Pixel XLmarlinaosp_marlin-userdebug
    Pixelsailfishaosp_sailfish-userdebug
    HiKeyhikeyhikey-userdebug
    Nexus 6Pangleraosp_angler-userdebug
    Nexus 5Xbullheadaosp_bullhead-userdebug
    Nexus 6shamuaosp_shamu-userdebug
    Nexus Playerfuguaosp_fugu-userdebug
    Nexus 9volantis (flounder)aosp_flounder-userdebug
    Nexus 5 (GSM/LTE)hammerheadaosp_hammerhead-userdebug
    Nexus 7 (Wi-Fi)razor (flo)aosp_flo-userdebug
    Nexus 7 (Mobile)razorg (deb)aosp_deb-userdebug
    Nexus 10mantaray (manta)full_manta-userdebug
    Nexus 4occam (mako)full_mako-userdebug
    Nexus 7 (Wi-Fi)nakasi (grouper)full_grouper-userdebug
    Nexus 7 (Mobile)nakasig (tilapia)full_tilapia-userdebug
    Galaxy Nexus (GSM/HSPA+)yakju (maguro)full_maguro-userdebug
    Galaxy Nexus (Verizon)mysid (toro)aosp_toro-userdebug
    Galaxy Nexus (Experimental)mysidspr (toroplus)aosp_toroplus-userdebug
    Motorola Xoom (U.S. Wi-Fi)wingrayfull_wingray-userdebug
    Nexus Ssoju (crespo)full_crespo-userdebug
    Nexus S 4Gsojus (crespo4g)full_crespo4g-userdebug
    
+
+
    
+
+
    Flashing a device
    
+
+
    You can flash an entire Android system in a single command; doing so verifies
+the system being flashed is compatible with the installed bootloader and radio,
+writes the boot, recovery, and system partitions together, then reboots the
+system. Flashing also erases all user data, similarly to fastboot oem
+unlock.
    
+
+
    To flash a device:
    
+
      
+
    1. Place the device in fastboot mode by holding the appropriate
+key combination at boot or using the following command:
+
      adb reboot bootloader
      2. 
+
    2. After 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.
      3. 
+
    
+
+
+
+
    Restoring devices to factory
+state
    
+
+
    Factory images for Google devices are available from
+Factory
+Images for Nexus and Pixel Devices. Factory images for the Motorola Xoom are
+distributed directly by Motorola.
    
+
+  
+
diff --git a/en/setup/site-updates.html b/en/setup/site-updates.html
new file mode 100644
index 00000000..0ebe54b1
--- /dev/null
+++ b/en/setup/site-updates.html
@@ -0,0 +1,683 @@
+
+  
+    Site Updates
+    
+    
+  
+  
+  
+
+
+
    This page describes significant revisions to source.android.com. Please see the Android
+Open Source Project (AOSP) docs/source.android.com log for the complete
+list of changes to this site.
+
+
    September 2017
    
+
+
    This site has been released in China at source.android.google.cn. All
+  non-reference materials have also been translated into Simplified Chinese for
+  ease of use.
    
+
+
    August 2017
    
+
+
    Android 8.0 has been released! This section describes the major new features in the Android 8.0 platform.
    
+
+
    Architecture
    
+
+
    Treble
    
+
    
+Android 8.0 includes support for Treble, a major re-architect of the
+Android OS framework designed to make it easier, faster, and less costly
+for manufacturers to update devices to a new version of Android. Documentation
+includes details on the HAL interface definition
+language (HIDL), a new ConfigStore HAL,
+Device Tree Overlays,
+the Vendor Native Development
+Kit (VNDK), Vendor
+  Interface Objects (VINTF), 
+Modular Kernel requirements, and the 
+Vendor Test Suite (VTS) and Infrastructure.
+
    
+
+
    FunctionFS support
    
+
    
+FunctionFS
+(FFS) is a USB gadget function that is designed and controlled through user space.
+Its support allows all of the function- and protocol-specific code to live in
+user space, while all of the USB transport code lives in the kernel. Using
+     FFS moves Media Transfer Protocol (MTP) implementation into user space.
+
    
+
+
    
+On the frameworks side, most of the major changes exist in MtpServer. The
+USB driver interface has been refactored into two different classes, one that
+uses the old kernel driver and one that uses FFS. MtpServer is then able
+to use that driver interface without needing to know the details of
+implementation. The FFS driver writes the USB descriptors to a file when
+the server starts up; it then writes data to endpoint files similar to the
+kernel driver use.
+
    
+
+
    Kernel enhancements to LLDB/C++ debugging
    
+
    
+The Android 8.0 release includes kernel enhancements that help developers create
+better applications by improving their debugging experience. For more
+information, see Implementing
+kernel enhancements to LLDB/C++ debugging.
+
    
+
+
    Kernel Hardening
    
+
    
+Upstreamed kernel hardening features and tools to find bugs in kernel drivers.
+For more information, see Kernel Hardening.
+
    
+
+
    Optimizing SquashFS at the Kernel Level
    
+
    
+SquashFS is a compressed read-only filesystem for Linux, suitable for use on the
+system partition. The optimizations in this document help improve the
+performance of SquashFS. For more information, see Optimizing
+SquashFS at the Kernel Level.
+
    
+
+
    ART and Dalvik
    
+
    Fuzz Testing
    
+
    
+The Android Open Source Project (AOSP) offers a new fuzzing testing suite for
+testing the Android
+runtime (ART) infrastructure. The new toolset, JFuzz and an improved
+DexFuzz, are directly available in AOSP now with accompanying documentation.
+See:
+https://android.googlesource.com/platform/art/+/master/tools/jfuzz/README.md
+https://android.googlesource.com/platform/art/+/master/tools/dexfuzz/README
+
    
+
    
+Nothing is required to implement or use the new tools. You may make changes
+to the tools if required, just like you can make changes to the
+runtime/compiler already.
+
    
+
+
    VDEX files: Improve System Update Performance
    
+
    
+VDEX files improve the performance and user experience of software updates. VDEX
+files store pre-validated DEX files with verifier dependencies so that during
+system updates ART does not need to extract and verify the DEX files again. No
+action is needed to implement this feature. It is enabled by default. To
+disable the feature, set the ART_ENABLE_VDEX environment variable
+to false.
+
    
+
+
    ART performance improvements
    
+
    
+The Android runtime (ART) has been improved significantly in the Android 8.0
+release. This document summarizes enhancements device manufacturers can expect
+in ART. For more information, see Improving
+ART Performance in Android 8.0.
+
    
+
+
    Android A/B OTA Updates
    
+
    
+This update answers common questions device manufacturers have regarding Android
+A/B (seamless) system updates. For more information, see A/B
+(Seamless) System Updates Frequently asked questions.
+
    
+
+
    Automotive
    
+
+
    Bluetooth connection management
    
+
    
+Android 8.0 provides Bluetooth connection management in in-vehicle infotainment
+systems for a more seamless Bluetooth user experience. For more information, see
+
+Bluetooth connection management.
+
    
+
+
    Bluetooth multi-device HFP
    
+
    
+Bluetooth multi-device connectivity lets users connect multiple devices to telephony profiles in
+an Android Automotive IVI Bluetooth. For more information, see
+
+IVI Connectivity.
+
    
+
+
    Vehicle Camera HAL
    
+
    
+Describes the design of an exterior view system (EVS) stack and provides the HAL
+specification for supporting the acquisition and presentation of vehicle camera
+data. For more information, see Exterior
+View System (EVS) Vehicle Camera HAL.
+
    
+
+
    Bluetooth
    
+
    
+See the updated Bluetooth
+overview.
+
    
+
+
    Verifying and debugging Bluetooth
    
+
    
+A new page about how to verify and debug the native Bluetooth stack. See this page at
+Verifying and Debugging.
+
    
+
+
    Bluetooth services
    
+
    
+Bluetooth provides a variety of features that enable core services between devices,
+such as audio streaming, phone calls, and messaging. For more information about the Android
+Bluetooth services, see 
+Bluetooth Services.
+
    
+
+
    BLE advertising
    
+
    
+Bluetooth 5 supports different modes of data advertisements for Bluetooth Low Energy,
+including higher bandwidth or increased range. For more information, see
+
+Bluetooth Low Energy Advertising.
+
    
+
+
+
    Bluetooth support for audio codecs
    
+
    
+The Android 8.0 release includes support for Bluetooth high-definition audio
+codecs. For more information, see Advanced audio codecs.
+
    
+
+
+
    Camera
    
+
+
    Critical camera features
    
+
    
+The Android 8.0 release contains these key enhancements to the Camera service:
+shared surfaces, enable multiple surfaces sharing the same OutputConfiguration
+System API for custom camera modes, and onCaptureQueueEmpty. For more
+information, see Camera Version
+Support.
+
    
+
+
    Configuration
    
+
+
    Ambient Capabilities
    
+
    
+Capabilities allow Linux processes to drop most root-like privileges, while
+retaining the subset of privileges that they require to perform their function.
+Ambient capabilities allows system services to configure capabilities in their
+.rc files, bringing all their configuration into a single file. For
+more information, see Implementing
+Ambient Capabilities.
+
    
+
+
    Privileged Permission Whitelist Requirement
    
+
    
+Starting in Android 8.0, all privileged apps must be explicitly whitelisted in
+system configuration XML files in the /etc/permissions directory.
+If they are not, then the device will boot, but the device implementation will
+not pass CTS. For more information, see Privileged
+Permission Whitelist Requirement.
+
    
+
+
    Implementing USB HAL
    
+
    
+The Android 8.0 release moves handling of USB commands out of init scripts and
+into a native USB daemon for better configuration and code reliability. For more
+information, see Implementing
+USB HAL.
+
    
+
+
    Connectivity
    
+
+
    Customizing Device Behavior for Out-of-balance Users
    
+
    
+Android devices with no data balance allow network traffic through, requiring
+carriers and telecoms to implement mitigation protocols. This feature implements
+a generic solution that allows carriers and telcos to indicate when a device has
+run out of balance. For more information, see Customizing
+device behavior for out-of-balance users.
+
    
+
+
    Debugging
    
+
+
    Enabling sanitizers in the Android build system
    
+
    
+Sanitizers are compiler-based instrumentation components to use during
+development and testing in order to identify bugs and make Android better.
+Android's current set of sanitizers can discover and diagnose memory misuse bugs
+and potentially dangerous undefined behavior. For more information, see Enabling
+Sanitizers in the Android Build System.
+
    
+
+
    Recover devices in reboot loops
    
+
    
+Android 8.0 includes a feature that sends out a "rescue party" when it notices
+core system components stuck in crash loops. Rescue Party then escalates through
+a series of actions to recover the device. For more information, see Rescue
+Party.
+
    
+
+
    Storaged
    
+
    
+Android 8.0 adds support for storaged, an Android native daemon that
+collects and publishes storage metrics on Android devices. For more information,
+see Implementing
+Storaged.
+
    
+
+
    Display
    
+
+
    Air Traffic Control for floating windows
    
+
    
+Android 8.0 introduces Air Traffic Control for floating windows in order to
+simplify and unify how apps display on top of other apps. Everything necessary
+to use the feature is included in the Android Open Source Project (AOSP).
+
    
+
    
+Air Traffic Control allows developers to create a new (managed) floating
+layer/window type for apps to use to display windows on-top of other apps. The
+feature displays ongoing notifications for all apps using a floating layer that
+lets the user manage the alert window.
+
    
+
    
+The Android Compatibility Test Suite (CTS) confirms:
+
     
      
+ 
    • The current alert window types are: TYPE_PHONE, TYPE_PRIORITY_PHONE,
+TYPE_SYSTEM_ALERT, TYPE_SYSTEM_OVERLAY, or TYPE_SYSTEM_ERROR
+ 
    • Apps targeting the O SDK won't be able to use the window types above to
+display windows above other apps. They will need to use a new window type
+TYPE_APPLICATION_OVERLAY.
+ 
    • Apps targeting older SDKs can still use the current window types; however,
+the windows will be z-ordered below the new TYPE_APPLICATION_OVERLAY windows.
+ 
    • The system can move or resize windows in the new layer to reduce clutter.
+ 
    • Device manufacturers must keep the notification that lets users control
+what is displayed over other apps.
      •  
    
+
+
    Launching activities on secondary displays
    
+
    
+Virtual displays are available to everyone, and they don't require any special
+hardware. Any application can create an instance of virtual display; and in the
+Android 8.0 release, activities can be launched on that virtual display if the
+associated feature is enabled.
+
    
+
    
+To support multi-display features, you should either use one of the
+existing supported ways of connecting secondary devices or build new hardware.
+The supported ways of connecting displays on Nexus and Pixel devices are Google
+Cast and virtual
+displays inside apps. Support of other ways depends on kernel driver support
+for each particular case (like MHL or DisplayPort over USB-C) and fully
+implementing interface definitions that are related to displays in
+HardwareComposer HAL (IComposerCallback.hal and IComposerClient.hal).
+
    
+
    
+Each of the ways may require SoC or OEM support. For example, to enable
+DisplayPort over USB-C, both hardware (SOC) and software (drivers) support is
+required. You might need to implement drivers for your hardware to support
+connecting external displays.
+
    
+
    
+The default implementation will allow launching fullscreen stacks of activities
+on secondary displays. You can customize the stacks and System UI and
+behavior on secondary displays.
+
    
+
+
    Support for generic tooltip
    
+
    
+Android 8.0 allows developers to provide descriptive action names and other
+helpful information on mouse hover over buttons and other icons. Device
+manufacturers may style the tooltip popup. Its layout is defined in
+android/frameworks/base/core/res/res/layout/tooltip.xml.
+
+
    
+
    
+OEMs may replace the layout or change its dimensions and style parameters. Use
+only text and keep the size reasonably small. The feature is implemented
+entirely inside the View class, and there are quite exhaustive CTS tests that
+check many aspects of Tooltip behavior.
+
    
+
    
+
+
    Support for extended aspect ratio
    
+
    
+Android 8.0 includes a new manifest attribute, maxAspectRatio,
+which lets an activity or app specify the maximum aspect ratio it supports.
+maxAspectRatio replaces the previous meta-data tag with a first-class API and
+allows devices to support an aspect ratio greater than 16:9.
+
      
+
    • If an activity or app is resizable,
+allow the activity to fill the screen.
+
    • If an activity or app is non-resizeable or the platform is force resizing
+the activity, allow the app window to display up to the maximum aspect ratio,
+according to the maxAspectRatio
+value. 
        
+ 
      • For applications on devices running Android 8.0, the default value is the
+aspect ratio of the current device.
+ 
      • For applications on devices running earlier versions of Android, the
+default value is 16:9.
        •  
      
+
      •  
    
+
+
    Implementing Adaptive Icons
    
+
    
+Adaptive Icons maintain a consistent shape intra-device but vary from device to
+device with only one icon asset provided by the developer. Additionally, icons
+support two layers (foreground and background) that can be used for motion to
+provide visual delight to users. For more information, see Implementing
+Adaptive Icons.
+
    
+
+
    Night Light
    
+
    
+Night Light, introduced in Android 7.0.1, allows users to reduce the amount of
+blue light that their screen emits. Android 8.0 gives users more control over the
+intensity of this effect. For more information, see Implementing
+Night Light.
+
    
+
+
    Picture-in-picture
    
+
    
+Android 8.0 includes support for picture-in-picture (PIP) on Android handheld
+devices. PIP allows users to resize an app with an ongoing activity, such as a
+video, into a small window. For more information, see Picture-in-Picture
+on Android handsets.
+
    
+
+
    Better Split-Screen Interactions
    
+
    
+Multi-window lets multiple apps simultaneously display on users' device screens.
+Android 8.0 improves the default mode, split-screen, by compressing the top pane
+and resizing the launcher if a user taps Home after entering split-screen. For
+more information, see Better
+Split-Screen Interactions.
+
    
+
+
    Add Widgets/Shortcuts
    
+
    
+A new API in Android 8.0 allows application developers to add shortcuts and
+widgets from inside the app instead of relying on the widget tray. The older
+method of adding shortcuts by sending a broadcast has been deprecated for
+security reasons. For more information, see Implementing
+Add Widgets/Shortcuts.
+
    
+
+
    Downloading and Building
    
+
+
    Android LLVM Toolchain improvements
    
+
    
+OEMs who wish to use our latest toolchain/tools will need to ensure that any of
+their private code compiles successfully with the updated toolchains. This may
+require them to fix existing issues in their code with undefined behavior. (Of
+course, they are free to use whatever tools they prefer to compile their own
+code too.)
+
    
+
    
+They must ensure their code is free of undefined behavior (by using tools like
+UBSan), so they are less susceptible to problems caused by newer toolchains. All
+of the toolchains are always updated directly in AOSP. Everything will be
+available well before OC even ships, so OEMs should be following along
+already.
+
    
+
    
+See the public Clang/LLVM documentation for
+general instructions and the Android
+Clang/LLVM documentation set within AOSP for Android-specific guidance.
+Finally, join the android-llvm
+public group to get help and take part in development.
+
    
+
+
    DRM / KMS
    
+
+
    DRM/KMS in Linux Kernel Version 4.9
    
+
    
+The Direct Rendering Manager (DRM)/Kernel Mode Setting (KMS) framework used by
+Android is developed and maintained by Linux kernel developers in the Linux
+kernel. Android merges down from the Linux kernel. By merging down from our
+common kernel, device manufacturers gain the DRM/KMS framework automatically.
+
    
+
    
+DRM/KMS became viable in Linux kernel version 4.9, and Android strongly
+encourages OEM partners to use DRM/KMS starting with this kernel
+version. Atomic Display Framework
+(ADF), the display framework officially supported by Android today, will not
+be supported in 4.9 and higher versions of the common Android kernel; instead,
+Android will support DRM/KMS from this version. OEMs can continue to use ADF (or
+any other framework), but Android will not support them in the common Android
+kernel.
+
    
+
    
+To implement DRM/KMS, you will need to write your own drivers using
+DRM/KMS in addition to merging down the DRM/KMS framework from the android
+common kernel.
+
    
+
+
    Keystore
    
+
+
    Keymaster 3
    
+
    
+Android 8.0 updates Keymaster, the keystore HAL, by extending the capabilities of
+hardware-backed key storage on Android devices. This builds upon the Android 7.1.2
+updates to Keymaster 2. For more information, see Keymaster 3 documentation.
+
    
+
+
    Security Enhancements
    
+
+
    Insecure TLS Version Fallback removed from HttpsURLConnection
    
+
    
+Insecure TLS/SSL protocol version fallback is a workaround for buggy
+implementations of TLS protocol downgrade negotiation in some servers. This is
+vulnerable to POODLE. When Chrome 45 dropped the insecure fallback in September
+2015, less than 0.01% of servers relied on it. To improve security, insecure TLS
+version fallback has been removed from HttpsURLConnection
+in Android 8.0. For more details, see this blog post.
+
    
+
    
+To test this feature on devices with Android 8.0, run this CTS test case:
+
    
+
+
    +cts-tradefed run cts -m CtsLibcoreOkHttpTestCases
    
+
+
    Performance
    
+
+
    Flash Wear Management
    
+
    
+Describes eMMC behavior and new features to help OEMs lower the risk of a
+failing eMMC in the automotive environment. For more information, see Flash Wear
+Management in Android Automotive.
+
    
+
+
    Optimizing Boot Times
    
+
    
+Guidance for improving boot times for specific Android devices. For more
+information, see Optimizing
+boot times.
+
    
+
+
    Task Snapshots
    
+
    
+Task Snapshots is infrastructure introduced in Android 8.0 that combines
+screenshots for Recents Thumbnails as well as Saved Surfaces from Window Manager
+to save memory. For more information, see Task
+Snapshots.
+
    
+
+
    Peripherals
    
+
+
    Default Print Services
    
+
    
+A print
+service is an app that discovers and presents printers to a device's print
+framework. In earlier Android versions, users had to search for and install
+third-party print services to be able to print.
+
    
+
    
+Android 8.0 includes a default print service in platform/packages/services/BuiltInPrintService/
+that lets users print on modern printers without installing any additional apps.
+This implementation supports printers that use the Internet Printing Protocol
+(IPP) to communicate with the printer and use PCLm, PWG-Raster, or PDF to send
+printable content. For older printers, users should install the app recommended
+by the PrintRecommendationService
+as seen in this this I/O presentation.
+
+
    Reference Updates
    
+
+
    
+The Reference section has been added to the top-level
+navigation. As part of the Treble
+release, a HIDL reference section was added.
+The Trade Federation and the
+legacy HAL reference documentation has been updated.
+
    
+
+
    Settings menu
    
+
+
    Settings: Patterns and Components
    
+
    
+In Android 8.0, the Settings menu gains several components and widgets that
+cover common uses. For more information, see Patterns
+and Components.
+
    
+
+
    Settings: Updated information architecture
    
+
    
+Android 8.0 introduces a new information architecture for the Settings app. The
+goal of the new information architecture is to simplify the way settings are
+organized and make it easier for users to quickly find the settings needed to
+customize their Android devices. For more information, see Implementing Updated
+Information Architecture.
+
    
+
+
    Personalized Settings
    
+
    
+The Android Settings app provides a list of suggestions to the users. This
+feature provides ranking for suggestions, based on any contextual signal or the
+user's past interactions with suggestions.  For more information, see Personalized
+Settings.
+
    
+
+
    Implementing Settings: Universal Search
    
+
    
+Android 8.0 adds expanded search capabilities for the Settings menu. This document
+describes how to add a setting and ensure it is properly indexed for Settings.
+For more information, see Universal
+Search.
+
    
+
+
    Storage
    
+
+
    Faster storage statistics
    
+
    
+Android 8.0 leverages the ext4 filesystem's "quota" support to return disk usage
+statistics almost instantly. For more information, see Implementing
+faster storage statistics.
+
    
+
+
    April 2017
    
+
    Welcome to a new source.android.com! The site has been overhauled to make it
+easier for you to navigate, search, and read its ever-growing set of information.
+Here is a summary of enhancements:
    
+
+
    More screen real estate, larger type size
    
+
    The entire site is wider, allowing you to view more content at once. Code
+samples and commands are more visible, and all text has been enlarged.
    
+
+
    Mobile-ready view
    
+
    The new site renders more cleanly on handheld devices with a dedicated
+mobile view.
    
+
+
    
+  new mobile view
+  
    
+    Figure 1. Site's new mobile view
+  
    
+
    
+
+
    New top-level tabs
    
+
    The former Devices tab has been renamed Porting, while the old Core Technologies
+subtab has been renamed Tuning and moved to the top
+of the site for better exposure.
    
+
+
    Security at the forefront
    
+
    With an ever-increasing focus on security in Android, the Security tab has been moved forward (next to Source) to reflect its importance.
    
+
+
    Better reference materials
    
+
    Hardware Abstraction Layer and Trade Federation reference
+materials are available directly from a top-level Reference tab.
    
+
+
+
    The AOSP code
+repository is always just a click away with the Go to Code
+button at the top right of every page.
    
+
+
    Comprehensive footers
    
+
    In addition to the existing About, Community, and
+Legal footers, you can now find a complete list of links at the bottom
+of every page for building Android, connecting with the ecosystem, and getting
+help with the operating system's use.
    
+
+  
+
diff --git a/en/setup/submit-patches.html b/en/setup/submit-patches.html
new file mode 100644
index 00000000..c9b7b404
--- /dev/null
+++ b/en/setup/submit-patches.html
@@ -0,0 +1,238 @@
+
+  
+    Submitting Patches
+    
+    
+  
+  
+  
+
+
+
    This page describes the full process of submitting a patch to the AOSP,
+including
+reviewing and tracking changes with Gerrit.
    
+
    Prerequisites
    
+
+
+
    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. Follow the instructions on the password
+generator page. You need to do this only once. See Using
+Authentication for additional details.
    
+
    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 (50 characters maximum), followed by a
+blank line.
+This format is used by git and Gerrit for various displays.
      
+
      • 
+
+
    • 
+
      Starting on the third line, enter a longer description, which must
+hard-wrap at 72 characters maximum. This description should focus on what
+issue the change 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.
      
+
      • 
+
    
+
+
    Here is an example commit message:
    
+
    short description on first line
+
+more detailed description of your patch,
+which is likely to take up multiple lines.
+
    
+
+
    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. 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.
    
+
+
    +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.
    
+
    +repo rebase
+
    
+
    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.
    
+
+
    Upstream Projects
    
+
    Android makes use of a number of other open source projects, such as the
+Linux kernel and WebKit, as described in
+Codelines, Branches, and
+Releases. 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/.
+See Submitting ICU Bugs and
+Feature Requests for more.
    
+
+
    LLVM/Clang/Compiler-rt
    
+
    All changes to LLVM-related projects (external/clang,
+external/compiler-rt,
+external/llvm) should be made upstream at
+llvm.org/.
    
+
+
    mksh
    
+
    All changes to the MirBSD Korn Shell project at external/mksh
+should be made upstream
+either by sending an email to miros-mksh on the mirbsd.org domain (no
+subscription
+required to submit there) or (optionally) at Launchpad.
+
    
+
    OpenSSL
    
+
    All changes to the OpenSSL project at external/openssl
+should be made upstream at
+openssl.org.
    
+
    V8
    
+
    All changes to the V8 project at external/v8 should be
+submitted upstream at
+code.google.com/p/v8. See Contributing to V8
+for details.
    
+
    WebKit
    
+
    All changes to the WebKit project at external/webkit should
+be made
+upstream at 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 for details.
    
+
    zlib
    
+
    All changes to the zlib project at external/zlib should be
+made upstream at
+zlib.net.
    
+
+
+  
+
diff --git a/en/setup/using-repo.html b/en/setup/using-repo.html
new file mode 100644
index 00000000..b84d9d2f
--- /dev/null
+++ b/en/setup/using-repo.html
@@ -0,0 +1,305 @@
+
+  
+    Repo command reference
+    
+    
+  
+  
+  
+
+
+
    Repo usage takes the following form: 
    
+
    +repo <COMMAND> <OPTIONS>
+
    
+
    Optional elements are shown in brackets [ ]. For example, 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>]
+
    
+
+
    help
    
+
    Once Repo is installed, you can find the latest documentation starting with a summary of all commands by running:
    
+
    +repo help
+
    
+
    You can get information about any command by running this within a Repo tree:
    
+
    +repo help <COMMAND>
+
    
+
+
    For example, the following command yields a description and list of options
+for the init argument of Repo, which initializes Repo in the
+current directory. (See init for more details.)
    
+
    +repo help init
+
    
+
+
+
    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. See manifest-format.txt for instructions on updating the
+   manifest.
    
+
    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
+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.
      
+
      • 
+
    • 
+
      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
+# 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.
    
+
    If you only want to upload the currently checked out Git branch, you can use the flag --current-branch (or --cbr for short).
    
+
+
    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 into your platform/build 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 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 system 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.
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    lettermeaningdescription
    -no changesame in HEAD and index
    Aaddednot in HEAD, in index
    Mmodifiedin HEAD, modified in index
    Ddeletedin HEAD, not in index
    Rrenamednot in HEAD, path changed in index
    Ccopiednot in HEAD, copied from another in index
    Tmode changedsame content in HEAD and index, mode changed
    Uunmergedconflict between HEAD and index; resolution required
    
+
    In the second column, a lowercase letter indicates how the working directory differs from the index.
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    lettermeaningdescription
    -new/unknownnot in index, in work tree
    mmodifiedin index, in work tree, modified
    ddeletedin index, not in work tree
    
+
+  
+
diff --git a/en/setup/view-patches.html b/en/setup/view-patches.html
new file mode 100644
index 00000000..c14c3149
--- /dev/null
+++ b/en/setup/view-patches.html
@@ -0,0 +1,141 @@
+
+  
+    View Patches
+    
+    
+  
+  
+  
+
+    
    
+      If you want to view all patches to the Android Open Source Project, or
+      if you are reviewing or verifying a change, look in the 
+      AOSP Gerrit. For more information on how to find a specific change, see 
+      Gerrit Code Review - Searching Changes.
+    
    
+
+    
    Reviewing a change
    
+
+      
    
+        If you are assigned to be the Reviewer 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 select the Reply button. This
+        brings up a comment box where you can mark the change as
+        Verified or not, 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. For more information, see the Repo reference.
+      
    
+
+    
    How do I become a Verifier
+      or Reviewer?
    
+
+      
    
+        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.
+      
    
+
+    
    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.
+      
    
+
+  
+
+
diff --git a/en/source/64-bit-builds.html b/en/source/64-bit-builds.html
deleted file mode 100644
index 30b51d6f..00000000
--- a/en/source/64-bit-builds.html
+++ /dev/null
@@ -1,227 +0,0 @@
-
-  
-    Understanding 64-bit Builds
-    
-    
-  
-  
-  
-
-
-
-
    Overview
    
-
-
    From the build system’s perspective, the most noticeable change is that now it
-supports building binaries for two target CPU architectures (64-bit and 32-bit)
-in the same build. That’s also known as Multilib build.
    
-
-
    For native static libraries and shared libraries, the build system sets up
-rules to build binaries for both architectures. The product configuration
-(PRODUCT_PACKAGES), together with the dependency graph, determines which
-binaries are built and installed to the system image.
    
-
-
    For executables and apps, the build system builds only the 64-bit version by
-default, but you can override this setting by using a global
-BoardConfig.mk variable or a module-scoped variable.
    
-
-
    Caution: If an app exposes an API to other
-apps that can be either 32- or 64-bit, the app must have the
-android:multiarch property set to a value of true
-within its manifest to avoid potential errors.
    
-
-
    Product Configuration
    
-
-
-
    In BoardConfig.mk, we added the following variables to
-configure the second CPU architecture and ABI:
    
-
-
    -TARGET_2ND_ARCH
-TARGET_2ND_ARCH_VARIANT
-TARGET_2ND_CPU_VARIANT
-TARGET_2ND_CPU_ABI
-TARGET_2ND_CPU_ABI2
-
    
-
-
-
    You can see an example in build/target/board/generic_arm64/BoardConfig.mk.
    
-
-
    If you want the build system to build 32-bit executables and apps by default,
-set the following variable:
    
-
-
    -TARGET_PREFER_32_BIT := true
-
    
-
-
    However, you can override this setting  by using module-specific variables in
-Android.mk.
    
-
-
    In a Multilib build, module names in PRODUCT_PACKAGES cover
-both the 32-bit and 64-bit binaries, as long as they are defined by the build
-system. For libraries pulled in by dependency, a 32-bit library is installed
-only if it’s required by another 32-bit library or executable. The same is true
-for 64-bit libraries.
    
-
-
    However, module names on the make command line cover only the
-64-bit version. For example, after running lunch
-aosp_arm64-eng,make libc builds only the 64-bit libc. To
-build the 32-bit libc, you need to run make libc_32.
    
-
-
    Module Definition in Android.mk
    
-
-
    You can use the LOCAL_MULTILIB variable to configure your build
-for 32-bit and/or 64-bit and override the global
-TARGET_PREFER_32_BIT.
    
-
-
    Set LOCAL_MULTILIB to one of the following:
    
-
-
      
-  
    • "both”: build both 32-bit and 64-bit.
      • 
-  
    • “32”: build only 32-bit.
      • 
-  
    • “64”: build only 64-bit.
      • 
-  
    • “first”: build for only the first arch (32-bit in 32-bit devices and 64-bit
-in 64-bit devices).
      • 
-  
    • “”: the default; the build system decides what arch to build based on the
-module class and other LOCAL_ variables, such as LOCAL_MODULE_TARGET_ARCH,
-LOCAL_32_BIT_ONLY, etc.
      • 
-
    
-
-
    In a Multilib build, conditionals like ifeq $(TARGET_ARCH) don’t work any
-more. 
    
-
-
    If you want to build your module for some specific arch(s), the following
-variables can help you:
    
-
-
      
-  
    • LOCAL_MODULE_TARGET_ARCH
      It can be set to a list of archs, something
-like “arm x86 arm64”. Only if the arch being built is among that list will the
-current module be included by the build system.
      • 
-
-  
    • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH
      The opposite of
-LOCAL_MODULE_TARGET_ARCH. Only if the arch being built is not among the list,
-the current module will be included.
      • 
-
    
-
-
    There are minor variants of the above two variables:
    
-
-
      
-  
    • LOCAL_MODULE_TARGET_ARCH_WARN
      • 
-  
    • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
      • 
-
    
-
-
    The build system will give warning if the current module is skipped due to
-archs limited by them.
    
-
-
    To set up arch-specific build flags, use the arch-specific LOCAL_ variables. An
-arch-specific LOCAL_ variable is a normal LOCAL_ variable with an arch suffix,
-for example:
    
-
-
      
-  
    •  LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
-  
    •  LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
-  
    •  LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,
-
    
-
-
    Those variables will be applied only if a binary is  currently being built for
-that arch.
    
-
-
    Sometimes it’s more convenient to set up flags based on whether the binary is
-currently being built for 32-bit or 64-bit. In that case you can use the LOCAL_
-variable with a _32 or _64 suffix, for example:
    
-
-
      
-  
    •  LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
-  
    •  LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
-  
    •  LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,
-
    
-
-
    Note that not all of the LOCAL_ variables support the arch-specific variants.
-For an up-to-date list of such variables, refer to build/core/clear_vars.mk.
    
-
-
    Install path
    
-
-
-
    In the past, you could use LOCAL_MODULE_PATH to install a library to a
-location other than the default one. For example, LOCAL_MODULE_PATH :=
-$(TARGET_OUT_SHARED_LIBRARIES)/hw.
    
-
-
    In Multilib build, use LOCAL_MODULE_RELATIVE_PATH instead:
    
-
-
    -LOCAL_MODULE_RELATIVE_PATH := hw
-
    
-
-
-
    so that both the 64-bit and 32-bit libraries can be installed to the right
-place.
    
-
-
    If you build an executable as both 32-bit and 64-bit, you’ll need to use one of
-the following variables to distinguish the install path:
    
-
-
      
-  
    • LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64
      Specifies the installed file name.
-  
    • LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64
      Specifies the install path.
-
    
-
-
    Generated sources 
    
-
-
    In a Multilib build,  if you generate source files to
-$(local-intermediates-dir) (or $(intermediates-dir-for)
-with explicit variables), it won’t reliably work any more. That’s
-because the intermediate generated sources will be required by both 32-bit and
-64-bit build, but $(local-intermediates-dir) only points to one of
-the two intermediate directories.
    
-
-
    Happily, the build system now provides a dedicated, Multilib-friendly,
-intermediate directory for generating sources. You can call
-$(local-generated-sources-dir) or
-$(generated-sources-dir-for) to get the directory’s path. Their
-usages are similar to $(local-intermediates-dir) and
-$(intermediates-dir-for). 
    
-
-
    If a source file is generated to the new dedicated directory and picked up
-by LOCAL_GENERATED_SOURCES, it is built for both 32-bit and 64-bit
-in multilib build.
    
-
-
    Prebuilts
    
-
-
-
    In Multilib, you can’t use TARGET_ARCH (or together with
-TARGET_2ND_ARCH) to tell the build system what arch the prebuilt
-binary is targeted for. Use the aforementioned LOCAL_ variable
-LOCAL_MODULE_TARGET_ARCH or
-LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH instead.
    
-
-
    With these variables, the build system can choose the corresponding 32-bit
-prebuilt binary even if it’s currently doing a 64-bit Multilib build.
    
-
-
    If you want to use the chosen arch to compute the source path for the prebuilt
-binary , you can call $(get-prebuilt-src-arch).
    
-
-
    Dex-preopt
    
-
-
-
    For 64-bit devices, by default we generate both 32-bit and 64-bit odex files
-for the boot image and any Java libraries. For APKs, by default we generate
-odex only for the primary 64-bit arch. If an app will be launched in both
-32-bit and 64-bit processes, please use LOCAL_MULTILIB := both to make sure
-both 32-bit and 64-bit odex files are generated. That flag also tells the build
-system to include both 32-bit and 64-bit JNI libraries, if the app has any.
    
-
-
-  
-
diff --git a/en/source/_toc.yaml b/en/source/_toc.yaml
deleted file mode 100644
index 8572b0ac..00000000
--- a/en/source/_toc.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-toc:
-- title: Getting Started
-  section:
-  - title: Overview
-    path: /source/
-  - title: Codelines, Branches, and Releases
-    path: /source/code-lines
-  - title: Codenames, Tags, and Build Numbers
-    path: /source/build-numbers
-  - title: Project Roles
-    path: /source/roles
-  - title: Brand Guidelines
-    path: /source/brands
-  - title: Licenses
-    path: /source/licenses
-  - title: FAQ
-    path: /source/faqs
-  - title: Site Updates
-    path: /source/site-updates
-- title: Downloading and Building
-  section:
-  - title: Requirements
-    path: /source/requirements
-  - title: Establishing a Build Environment
-    path: /source/initializing
-  - title: Downloading the Source
-    path: /source/downloading
-  - title: Preparing to Build
-    path: /source/building
-  - title: Compiling with Jack
-    path: /source/jack
-  - title: Using Reference Boards
-    path: /source/devices
-  - title: Running Builds
-    path: /source/running
-  - title: Building Kernels
-    path: /source/building-kernels
-  - title: Known Issues
-    path: /source/known-issues
-- title: Developing
-  section:
-  - title: Overview
-    path: /source/developing
-  - title: Using Repo
-    path: /source/using-repo
-  - title: Learning Git
-    path: /source/git-resources
-  - title: Adding a New Device
-    path: /source/add-device
-  - title: Understanding 64-bit Builds
-    path: /source/64-bit-builds
-- title: Contributing
-  section:
-  - title: Overview
-    path: /source/contributing
-  - title: Life of a Patch
-    path: /source/life-of-a-patch
-  - title: Submitting Patches
-    path: /source/submit-patches
-  - title: View Patches
-    path: /source/view-patches
-  - title: Life of a Bug
-    path: /source/life-of-a-bug
-  - title: Reporting Bugs
-    path: /source/report-bugs
-  - title: Reading Bug Reports
-    path: /source/read-bug-reports
-  - title: Java Code Style Rules
-    path: /source/code-style
-- title: Community
-  path: /source/community
diff --git a/en/source/_translation.yaml b/en/source/_translation.yaml
deleted file mode 100644
index 33538a7a..00000000
--- a/en/source/_translation.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-enable_continuous_translation: True
-title: Android Open Source Project Source tab
-description: Translations for SAC source tab
-language:
-- zh-CN
-cc:
-- sac-doc-leads+translation@google.com
-reviewer:
-- daroberts
-product: Android
diff --git a/en/source/add-device.html b/en/source/add-device.html
deleted file mode 100644
index bd869f97..00000000
--- a/en/source/add-device.html
+++ /dev/null
@@ -1,475 +0,0 @@
-
-  
-    Adding a New Device
-    
-    
-  
-  
-  
-
-
-
-
    Use the information in this page to create the Makefiles for your device and
-product. Please note, unlike the other pages in this section, the contents here
-are applicable only when creating an entirely new device type and are intended
-for company build and product teams only.
    
-
-
    Understand Build Layers
    
-
-
    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 product. 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.
    
-
-
- 
-  
-  
-  
- 
-  
-    
-    
-    
-
-  
- 
-    
-    
-    
-  
-
-    
-    
-    
-  
-
    LayerExampleDescription
    ProductmyProduct, myProduct_eu, myProduct_eu_fr, j2, sdkThe 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.
-
    Board/Devicesardine, trout, goldfishThe device/board 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. This layer also represents the bare
-    schematics of a product. These include the peripherals on the board and their
-    configuration. The names used are merely codes for different board/device
-    configurations.
    Archarm, x86, mips, arm64, x86_64, mips64The architecture layer describes the processor configuration and ABI
-    (Application Binary Interface) running on the board. 
    
-
-
    Use Build Variants
    
-
-
    When building for a particular product, it's often useful to have minor
-variations on what is ultimately the final release build. In a module
-definition, the module can specify tags with LOCAL_MODULE_TAGS,
-which can be one or more values of optional (default),
-debug, eng.
    
-
-
    If a module doesn't specify a tag (by LOCAL_MODULE_TAGS), its
-tag defaults to optional. An optional module is installed only if
-it is required by product configuration with PRODUCT_PACKAGES.
-
-
    These are the currently-defined build variants:
    
-
-
-
-    
-    
-
-
-    
-    
-
-
-    
-    
-
-
    
-        eng
-    
-        This is the default flavor.
-
      
-
    • Installs modules tagged with: eng and/or debug.
      • 
-
    • Installs modules according to the product definition files, in
-addition to tagged modules.
      • 
-
    • ro.secure=0
      • 
-
    • ro.debuggable=1
      • 
-
    • ro.kernel.android.checkjni=1
      • 
-
    • adb is enabled by default.
      • 
-
    
-    
    
-        user
-    
-        This is the flavor intended to be the final release bits.
-
      
-
    • Installs modules tagged with user.
      • 
-
    • Installs modules according to the product definition files, in
-addition to tagged modules.
      • 
-
    • ro.secure=1 
      • 
-
    • ro.debuggable=0 
      • 
-
    • adb is disabled by default.
      • 
-
    
-    
    
-        userdebug
-    
-        The same as user, except:
-
      
-
    • Also installs modules tagged with debug.
      • 
-
    • ro.debuggable=1
      • 
-
    • adb is enabled by default.
      • 
-
    
-    
    
-
-
    Customize the Build with Resource Overlays
    
-
-
    The Android build system uses resource overlays to customize
-a product at build time. Resource overlays specify resource
-files that are applied on top of the defaults. To use resource overlays, modify the project
-buildfile to set PRODUCT_PACKAGE_OVERLAYS to a
-path relative to your top-level directory. That path becomes a shadow root searched along with
-the current root  when the build system searches for resources.
    
-
-
    The most commonly customized settings are contained in the file frameworks/base/core/res/res/config.xml.
    
-
-
     To set up a resource overlay on this file, add the overlay directory to the
-project buildfile, as follows:
    
-
-
    -PRODUCT_PACKAGE_OVERLAYS := device/DEVICE_IMPLEMENTER/DEVICE_NAME/overlay
-
    
-
-
    or
    
-
-
    -PRODUCT_PACKAGE_OVERLAYS := vendor/VENDOR_NAME/overlay
-
    
-
-
     Then, add an overlay file to the directory, for example:
    
-
-
    -vendor/foobar/overlay/frameworks/base/core/res/res/config.xml
-
    
-
-
     Any strings or string arrays found in the overlay config.xml file replace
-those found in the original file.
    
-
-
    Build a Product
    
-
-
    
-There are many ways to organize the source files for your device. We'll briefly
-go over how the Nexus 6 implementation was organized as an example, but you can
-organize your source files and build the way you see fit.
-
    
-
    
-Nexus 6 was implemented with a main device configuration named
-shamu. From this device configuration, 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
-device/moto/shamu directory to see how all of this is setup.
-
    
-
    Write the Makefiles
    
-
    
-  The following steps describe how to set up product Makefiles in a way similar
-to that of the Nexus 6 product line:
-
    
-
      
-  
    1. Create a device/<company_name>/<device_name> directory for your
-  product. For example, device/moto/shamu. This directory will contain source code
-  for your device along with the Makefiles to build them.
-  
      2. 
-
-  
    2. Create a device.mk Makefile that declares the files and modules needed for the
-  device. For an example, see device/moto/shamu/device.mk.
-  
      3. 
-
-  
    3. Create a product definition Makefile to create a specific product based on the device. The
-  following Makefile is taken from device/moto/shamu/aosp_shamu.mk as an example.
-  Notice the product is inheriting from the
-  device/moto/shamu/device.mk and
-  vendor/moto/shamu/device-vendor.mk files via the Makefile while
-  also declaring the product-specific information such as name, brand, and model.
-
-
      -# Inherit from the common Open Source product configuration
-$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
-
-PRODUCT_NAME := aosp_shamu
-PRODUCT_DEVICE := shamu
-PRODUCT_BRAND := Android
-PRODUCT_MODEL := AOSP on Shamu
-PRODUCT_MANUFACTURER := motorola
-PRODUCT_RESTRICT_VENDOR_FILES := true
-
-$(call inherit-product, device/moto/shamu/device.mk)
-$(call inherit-product-if-exists, vendor/moto/shamu/device-vendor.mk)
-
-PRODUCT_NAME := aosp_shamu
-
-PRODUCT_PACKAGES += \
-    Launcher3
-
      
-
-    
      
-      See Product Definition Variables for additional product-specific
-      variables you can add to your Makefiles.
-    
      
-  
      4. 
-
-  
    4. Create an AndroidProducts.mk file that points to the product's Makefiles. In
-  this example, only the product definition Makefile is needed. The example below is from
-  device/moto/shamu/AndroidProducts.mk:
-
      -#
-# 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)/aosp_shamu.mk
-
      
-  
      5. 
-
-  
    5. Create a BoardConfig.mk Makefile that contains board-specific configurations.
-  For an example, see device/moto/shamu/BoardConfig.mk.
-  
      6. 
-
-  
    6. Create a vendorsetup.sh file to add your product (a "lunch combo") to the build
-  along with a build variant separated by a dash. For example:
-
      -add_lunch_combo <PRODUCT_NAME>-userdebug
-
      
-  
      7. 
-
-  
    7. At this point, you can create more product variants based on the same device.
-  
      8. 
-
-
    
-
    Set Product Definition Variables
    
-
    
-  Product-specific variables are defined in the product's Makefile. Variables maintained in a
-  product definition files include:
-
    
-
-  
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-  
-
    
-        Parameter
-      
-        Description
-      
-        Example
-      
    
-        PRODUCT_AAPT_CONFIG
-      
-        aapt configurations to use when creating packages
-      
    
-        PRODUCT_BRAND
-      
-        The brand (e.g., carrier) the software is customized for, if any
-      
    
-        PRODUCT_CHARACTERISTICS
-      
-        aapt characteristics to allow adding variant-specific resources to a package.
-      
-        tablet,nosdcard
-      
    
-        PRODUCT_COPY_FILES
-      
-        List of words like source_path:destination_path. 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
-      
    
-        PRODUCT_DEVICE
-      
-        Name of the industrial design. This is also the board name, and the build system uses it to locate the BoardConfig.mk.
-      
-        tuna
-      
    
-        PRODUCT_LOCALES
-      
-        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 used as the product's default locale.
-      
-        en_GB de_DE es_ES fr_CA
-      
    
-        PRODUCT_MANUFACTURER
-      
-        Name of the manufacturer
-      
-        acme
-      
    
-        PRODUCT_MODEL
-      
-        End-user-visible name for the end product
-      
    
-        PRODUCT_NAME
-      
-        End-user-visible name for the overall product. Appears in the Settings > About screen.
-      
    
-        PRODUCT_OTA_PUBLIC_KEYS
-      
-        List of Over the Air (OTA) public keys for the product
-      
    
-        PRODUCT_PACKAGES
-      
-        Lists the APKs and modules to install.
-      
-        Calendar Contacts
-      
    
-        PRODUCT_PACKAGE_OVERLAYS
-      
-        Indicate whether to use default resources or add any product specific overlays
-      
-        vendor/acme/overlay
-      
    
-        PRODUCT_PROPERTY_OVERRIDES
-      
-        List of system property assignments in the format "key=value"
-      
    
-
-
    Set ANDROID_VENDOR_KEYS to connect over USB
    
-
-
    The ANDROID_VENDOR_KEYS environment variable enables device
-manufacturers to access production builds over adb. Generate a key
-for each release that every device will accept, store those internally (such as at
-vendor/oem-name/security/adb/), and then use
-ANDROID_VENDOR_KEYS to tell adb to use these canonical
-keys rather than random keys.
    
-
-
    Use the ANDROID_VENDOR_KEYS environment variable to
-point to the directory containing the generated adb public and
-private keys used for encryption. The private key is stored in file. The public
-key is stored in file.pub. The ANDROID_VENDOR_KEYS environment
-variable points to a file or directory where the generated key pairs are
-stored.
    
-
-
    This variable is set to a file or directory that contains 2048-bit RSA
-authentication key pairs generated with the adb keygen file command.
-These key pairs are in addition to the RSA key pairs generated by the ADB
-server. An RSA key pair is needed when you use adb to connect over
-USB for the first time.
    
-
-
    You must accept the host computer's RSA key to explicitly grant
-adb access to the device. By default key pairs generated by the
-ADB server are stored in the following key store directories as
-adbkey (private key) and adbkey.pub (public key):
    
-
-
    For file locations, on MacOS, this will likely be:
-$HOME/.android.  On Windows and Linux, this will be:
-%USERPOFILE%\.android. On Windows, RSA authentication keys can
-also be in C:\Windows\System32\config\systemprofile\.android in
-some cases. When the ADB server needs a key, it first searches the ADB server
-key store directory. If no keys are found, it then checks the
-ANDROID_VENDOR_KEYS environment variable. If no keys are found,
-the local ADB server generates and saves a new key pair in the ADB server key
-store directory.
    
-
-
    Note: You can override the default directory
-where the ADB server stores RSA keys by setting the
-ANDROID_SDK_HOME environment variable. On the device, keys are
-stored in the /data/misc/adb/adb_keys/ file, and new authorized
-keys are appended to the same file as you accept them.
    
-
-  
-
diff --git a/en/source/assets/bg_fade.jpg b/en/source/assets/bg_fade.jpg
deleted file mode 100644
index c6c70b6f..00000000
Binary files a/en/source/assets/bg_fade.jpg and /dev/null differ
diff --git a/en/source/assets/bg_images_sprite.png b/en/source/assets/bg_images_sprite.png
deleted file mode 100644
index 84437e79..00000000
Binary files a/en/source/assets/bg_images_sprite.png and /dev/null differ
diff --git a/en/source/assets/images/sac_logo.png b/en/source/assets/images/sac_logo.png
deleted file mode 100644
index 4ad113c4..00000000
Binary files a/en/source/assets/images/sac_logo.png and /dev/null differ
diff --git a/en/source/assets/rebox-gradient.gif b/en/source/assets/rebox-gradient.gif
deleted file mode 100644
index 124e844c..00000000
Binary files a/en/source/assets/rebox-gradient.gif and /dev/null differ
diff --git a/en/source/brands.html b/en/source/brands.html
deleted file mode 100644
index 032c7e4a..00000000
--- a/en/source/brands.html
+++ /dev/null
@@ -1,157 +0,0 @@
-
-  
-    Brand Guidelines
-    
-    
-  
-  
-  
-
-
-
-
    The "Android" name, the  logo,
-the "Google Play" brand, and other trademarks are property of Google Inc. and
-not part of the assets available through the Android Open Source Project.
    
-
-
    If you are interested in using these brands to indicate their association
-with your device, adhere to the guidelines on this page. These guidelines
-correspond to and complement the
-Brand
-Guidelines for Android App Developers and
-Google Brand Permissions.
    
-
-
    Android
    
-
-
    Here are manufacturer guidelines for the Android brand and related
-assets.
    
-
-
    Android in text
    
-
      
-  
    • Android™ should have a trademark symbol the first time it appears in
-  a creative.
      • 
-  
    • "Android" should always be capitalized and is never plural or possessive.
-  
      • 
-  
    • The use of “Android” on hardware, packaging or marketing materials of
-  device is restricted to
-  Android-compatible devices
-  only.
      • 
-  
    • “Android” should never be used in the name of your product or as the
-  primary or dominant mark on your packaging or device.
      • 
-  
    • "Android” should be used only as a term to refer to the operating system
-  (OS) of your device. If you are unsure whether your use meets our guidelines,
-  follow this simple test: If you can replace "Android" with "the Android
-  platform" and the text still makes sense, then you may use this term.
-  
        
-    
      • Incorrect: "Android XBrand Phone"
        • 
-    
      • Correct: "XBrand phone on Android"
        • 
-  
      
-  
      • 
-  
    • You may use “with Android” in plain black text with your logo. If used
-  with your logo, "with Android" should be no larger than 90% of your logo’s
-  size. First or most prominent instance of this use should be followed by a
-  ™ symbol.
      • 
-  
    • Android may be used only as a descriptor, as long as it is
-  followed by a proper generic term. It cannot be framed as the product name or
-  brand of your device.
-  
        
-    
      • Incorrect: "Android XBrand Phone"
        • 
-    
      • Correct: "Android mobile device"
        • 
-  
      
-  
      Any use of the Android name must include this attribution in your
-  communication:
      
-  
      Android is a trademark of Google Inc.
      
-  
      • 
-
    
-
-
    Acceptable examples
    
-Jelly Bean trademark example
-8100 series trademark example
-
-
    Unacceptable example
    
-XBrand trademark example
-
-
    Android logo
    
-
    Unless expressly authorized by Google through written agreement, the Android
-logo and custom typeface may not be used (with or without the Android robot).
    
-No Logo
-No Logo
-
-
    Android robot
    
-
-
    
-
    
-  android-robot
-  
    
-  100x118
    
-  200x237
    
-  Illustrator
-  
    
-
    
-
    
-
    The Android robot can be used, reproduced, and
-modified freely in marketing communications with proper attribution. For
-details, refer to
-App
-Developers Brand Guidelines and the
-Creative Commons
-license.
    
-
    
-
    
-
-
    
-
    
-no-peace-robot
-
    
-
    
-
    The Android Peace Robot or any variation of the
-Android Peace Robot (such as the Android robot with a peace sign) may not be
-used in partner marketing.
    
-
    
-
    
-
-
    
-
    Google Play
    
-
-
    Use of the “Google Play” name and the Google Play Store icon on the
-packaging of the hardware, marketing materials of the hardware, or the hardware
-itself is allowed only on devices
-licensed
-to access Google Play. For a list of devices licensed to use Google Play,
-refer to
-Supported
-devices.
    
-
-
-
    Other brands
    
-
    Android Auto,
-Android TV, and
-Android Wear are brands owned by
-Google. These brands require Google proprietary software that runs on top of
-Android and is available only through a license with Google. For information on
-how to request a license, see
-Contact Us.
-
-
    Questions
    
-
-
    For additional brand usage information, contact the Android Partner
-Marketing team by submitting the Partner
-Brand Inquiry Form.
    
-
-  
-
diff --git a/en/source/build-numbers.html b/en/source/build-numbers.html
deleted file mode 100644
index 1236ec35..00000000
--- a/en/source/build-numbers.html
+++ /dev/null
@@ -1,2281 +0,0 @@
-
-  
-    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 Codenames, 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 nameVersionAPI level
    Oreo8.0.0API level 26
    Nougat7.1API level 25
    Nougat7.0API level 24
    Marshmallow6.0API level 23
    Lollipop5.1API level 22
    Lollipop5.0API level 21
    KitKat4.4 - 4.4.4API level 19
    Jelly Bean4.3.xAPI level 18
    Jelly Bean4.2.xAPI level 17
    Jelly Bean4.1.xAPI level 16
    Ice Cream Sandwich4.0.3 - 4.0.4API level 15, NDK 8
    Ice Cream Sandwich4.0.1 - 4.0.2API level 14, NDK 7
    Honeycomb3.2.xAPI level 13
    Honeycomb3.1API level 12, NDK 6
    Honeycomb3.0API level 11
    Gingerbread2.3.3 - 2.3.7API level 10
    Gingerbread2.3 - 2.3.2API level 9, NDK 5
    Froyo2.2.xAPI level 8, NDK 4
    Eclair2.1API level 7, NDK 3
    Eclair2.0.1API level 6
    Eclair2.0API level 5
    Donut1.6API level 4, NDK 2
    Cupcake1.5API level 3, NDK 1
    (no code name)1.1API level 2
    (no code name)1.0API level 1
    
-
    Starting with Oreo, individual builds are identified with a new build ID format, in the form of PVBB.YYMMDD.bbb.
    
-
    The P part represents the first letter of the code name of the platform release, e.g. O is Oreo.
    
-
    The V part represents a supported vertical. By convention, 'P' represents the primary platform branch.
    
-
    The BB part represents a alpha numeric code which allows Google to identify the exact code branch that the build was made from.
    
-
    The YYMMDD part identifies the date when the release is branched from or synced with the development branch.  It 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.
    
-
    The bbb part identifies individual versions related to the same date code, sequentially starting with 001.
    
-
    Older Android releases from Cupcake to Nougat uses a different build ID scheme.  These Android 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. Factory images, binaries, and full OTA images for
-Nexus and Pixel devices can be downloaded from the Android Developer
-site:
    
-
    Images
    
-
    Drivers
    
-
    OTA
    
-
-  
-    
-      
-      
-      
-      
-    
-  
-  
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-    
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-  
-  
-  
-  
-
-
-
    BuildBranchVersionSupported devices
    OPD3.170816.023android-8.0.0_r34OreoPixel 2 XL, Pixel 2
    OPD1.170816.025android-8.0.0_r33OreoPixel 2 XL, Pixel 2
    OPR6.170623.023android-8.0.0_r32OreoNexus 5X
    OPR5.170623.011android-8.0.0_r31OreoNexus 6P
    OPR3.170623.013android-8.0.0_r30OreoPixel XL, Pixel
    OPR2.170623.027android-8.0.0_r29OreoNexus Player
    OPR1.170623.032android-8.0.0_r28OreoPixel XL, Pixel, Pixel C
    OPD3.170816.016android-8.0.0_r27OreoPixel 2
    OPD2.170816.015android-8.0.0_r26OreoPixel 2
    OPD1.170816.018android-8.0.0_r25OreoPixel 2
    OPD3.170816.012android-8.0.0_r24OreoPixel 2 XL, Pixel 2
    OPD1.170816.012android-8.0.0_r23OreoPixel 2 XL, Pixel 2
    OPD1.170816.011android-8.0.0_r22OreoPixel 2 XL, Pixel 2
    OPD1.170816.010android-8.0.0_r21OreoPixel 2 XL, Pixel 2
    OPR5.170623.007android-8.0.0_r17OreoNexus 6P
    OPR4.170623.009android-8.0.0_r16OreoNexus 5X
    OPR3.170623.008android-8.0.0_r15OreoPixel XL, Pixel
    OPR1.170623.027android-8.0.0_r13OreoPixel XL, Pixel, Pixel C
    OPR6.170623.021android-8.0.0_r12OreoNexus Player
    OPR6.170623.019android-8.0.0_r11OreoNexus 6P
    OPR4.170623.006android-8.0.0_r10OreoNexus 5X
    OPR3.170623.007android-8.0.0_r9OreoPixel XL, Pixel
    OPR1.170623.026android-8.0.0_r7OreoPixel XL, Pixel, Pixel C
    OPR6.170623.013android-8.0.0_r4OreoNexus 5X, Nexus 6P
    OPR6.170623.012android-8.0.0_r3OreoPixel XL, Pixel
    OPR6.170623.011android-8.0.0_r2OreoPixel XL, Pixel
    OPR6.170623.010android-8.0.0_r1OreoPixel C
    NZH54Dandroid-7.1.2_r33NougatPixel XL, Pixel
    NKG47Sandroid-7.1.2_r32NougatPixel XL, Pixel
    NHG47Qandroid-7.1.2_r30NougatPixel XL, Pixel
    NJH47Fandroid-7.1.2_r29NougatPixel XL, Pixel
    N2G48Candroid-7.1.2_r28NougatNexus 5X, Nexus 6P, Nexus Player, Pixel C
    NZH54Bandroid-7.1.2_r27NougatPixel XL, Pixel
    NKG47Mandroid-7.1.2_r25NougatPixel XL, Pixel
    NJH47Dandroid-7.1.2_r24NougatPixel XL, Pixel
    NHG47Oandroid-7.1.2_r23NougatPixel XL, Pixel
    N2G48Bandroid-7.1.2_r19NougatNexus 6P, Nexus Player, Pixel C
    N2G47Zandroid-7.1.2_r18NougatNexus 5X
    NJH47Bandroid-7.1.2_r17NougatPixel XL, Pixel
    NJH34Candroid-7.1.2_r16NougatPixel XL, Pixel
    NKG47Landroid-7.1.2_r15NougatPixel XL, Pixel
    NHG47Nandroid-7.1.2_r14NougatPixel XL, Pixel
    N2G47Xandroid-7.1.2_r13NougatNexus Player
    N2G47Wandroid-7.1.2_r12NougatNexus 5X, Nexus 6P, Pixel C
    NHG47Landroid-7.1.2_r11NougatPixel XL, Pixel
    N2G47Tandroid-7.1.2_r10NougatPixel XL, Pixel
    N2G47Randroid-7.1.2_r9NougatNexus Player
    N2G47Oandroid-7.1.2_r8NougatNexus 5X, Nexus 6P, Pixel XL, Pixel, Pixel C
    NHG47Kandroid-7.1.2_r6NougatPixel XL, Pixel
    N2G47Jandroid-7.1.2_r5NougatPixel XL, Pixel
    N2G47Handroid-7.1.2_r4NougatNexus 6P, Nexus Player
    N2G47Fandroid-7.1.2_r3NougatNexus 5X
    N2G47Eandroid-7.1.2_r2NougatPixel XL, Pixel
    N2G47Dandroid-7.1.2_r1NougatPixel C
    N9F27Mandroid-7.1.1_r58NougatNexus 9 (volantis)
    NGI77Bandroid-7.1.1_r57NougatNexus 6
    N6F27Mandroid-7.1.1_r55NougatNexus 6
    N4F27Pandroid-7.1.1_r54NougatNexus 9 (volantisg)
    N9F27Landroid-7.1.1_r53NougatNexus 9
    NGI55Dandroid-7.1.1_r52NougatNexus 6
    N4F27Oandroid-7.1.1_r51NougatNexus 9 (volantisg)
    N8I11Bandroid-7.1.1_r50NougatNexus 6
    N9F27Handroid-7.1.1_r49NougatNexus 9 (volantis)
    N6F27Iandroid-7.1.1_r48NougatNexus 6
    N4F27Kandroid-7.1.1_r47NougatNexus 9 (volantisg)
    N9F27Fandroid-7.1.1_r46NougatNexus 9 (volantis)
    N6F27Handroid-7.1.1_r45NougatNexus 6
    N4F27Iandroid-7.1.1_r44NougatNexus 9 (volantisg)
    N9F27Candroid-7.1.1_r43NougatNexus 9 (volantis)
    N6F27Eandroid-7.1.1_r42NougatNexus 6
    N4F27Eandroid-7.1.1_r41NougatNexus 9 (volantisg)
    N6F27Candroid-7.1.1_r40NougatNexus 6
    N4F27Bandroid-7.1.1_r39NougatNexus 9 (volantis/volantisg)
    N6F26Yandroid-7.1.1_r38NougatNexus 6
    NOF27Dandroid-7.1.1_r35NougatPixel XL, Pixel
    N4F26Xandroid-7.1.1_r33NougatNexus 9 (volantis/volantisg)
    N4F26Uandroid-7.1.1_r31NougatNexus 5X, Nexus 6P
    N6F26Uandroid-7.1.1_r28NougatNexus 6
    NUF26Nandroid-7.1.1_r27NougatNexus 6P
    NOF27Candroid-7.1.1_r26NougatPixel XL, Pixel
    NOF27Bandroid-7.1.1_r25NougatPixel XL, Pixel
    N4F26Tandroid-7.1.1_r24NougatNexus 5X, Nexus 6P, Nexus 9 (volantis/volantisg), Pixel C
    NMF27Dandroid-7.1.1_r23NougatNexus Player
    NMF26Xandroid-7.1.1_r22NougatNexus Player
    NOF26Wandroid-7.1.1_r21NougatPixel XL, Pixel
    NOF26Vandroid-7.1.1_r20NougatPixel XL, Pixel
    N6F26Randroid-7.1.1_r17NougatNexus 6
    NUF26Kandroid-7.1.1_r16NougatNexus 6P
    N4F26Qandroid-7.1.1_r15NougatNexus 9 (volantis/volantisg)
    N4F26Oandroid-7.1.1_r14NougatNexus 5X, Nexus 6P, Pixel C
    N6F26Qandroid-7.1.1_r13NougatNexus 6
    N4F26Mandroid-7.1.1_r12NougatNexus 9 (volantis)
    N4F26Jandroid-7.1.1_r11NougatNexus 5X, Nexus 6P
    N4F26Iandroid-7.1.1_r10NougatNexus 5X, Nexus 6P, Pixel C
    NMF26Vandroid-7.1.1_r9NougatPixel XL, Pixel
    NMF26Uandroid-7.1.1_r8NougatPixel XL, Pixel
    NMF26Randroid-7.1.1_r7NougatNexus Player
    NMF26Qandroid-7.1.1_r6NougatPixel XL, Pixel
    NMF26Oandroid-7.1.1_r4NougatPixel XL, Pixel
    NMF26Jandroid-7.1.1_r3NougatNexus Player
    NMF26Handroid-7.1.1_r2NougatPixel C
    NMF26Fandroid-7.1.1_r1NougatNexus 5X, Nexus 6P, Nexus 9 (volantis/volantisg)
    NDE63Xandroid-7.1.0_r7NougatPixel XL, Pixel
    NDE63Vandroid-7.1.0_r6NougatPixel XL, Pixel
    NDE63Uandroid-7.1.0_r5NougatPixel XL, Pixel
    NDE63Pandroid-7.1.0_r4NougatPixel XL, Pixel
    NDE63Landroid-7.1.0_r2NougatPixel XL, Pixel
    NDE63Handroid-7.1.0_r1NougatPixel XL, Pixel
    NBD92Nandroid-7.0.0_r34Nougat
    NBD92Gandroid-7.0.0_r33NougatNexus 6
    NBD92Fandroid-7.0.0_r32NougatNexus 6
    NBD92Eandroid-7.0.0_r31NougatNexus 6
    NBD92Dandroid-7.0.0_r30NougatNexus 6
    NBD91Zandroid-7.0.0_r29NougatNexus 6
    NBD91Yandroid-7.0.0_r28NougatNexus 6
    NBD91Xandroid-7.0.0_r27NougatNexus 6
    NBD91Uandroid-7.0.0_r24NougatNexus 6
    N5D91Landroid-7.0.0_r21NougatNexus 5X
    NBD91Pandroid-7.0.0_r19NougatNexus 6
    NRD91Kandroid-7.0.0_r17NougatNexus 6P
    NRD91Nandroid-7.0.0_r15NougatNexus 5X, Pixel C, Nexus Player, Nexus 9 (volantis/volantisg)
    NBD90Zandroid-7.0.0_r14NougatNexus 6
    NBD90Xandroid-7.0.0_r13NougatNexus 6P
    NBD90Wandroid-7.0.0_r12NougatNexus 5X
    NRD91Dandroid-7.0.0_r7NougatPixel C, Nexus Player, Nexus 9 (Wi-Fi)
    NRD90Uandroid-7.0.0_r6NougatNexus 6P
    NRD90Tandroid-7.0.0_r5NougatNexus 6P
    NRD90Sandroid-7.0.0_r4NougatNexus 5X
    NRD90Randroid-7.0.0_r3NougatNexus 5X, Nexus 9 (volantis), Nexus Player, Pixel C
    NRD90Mandroid-7.0.0_r1NougatNexus 5X, Nexus 9 (volantis), Nexus Player, Pixel C
    MOI10Eandroid-6.0.1_r81Marshmallow
    MOB31Zandroid-6.0.1_r80Marshmallow
    MOB31Tandroid-6.0.1_r79MarshmallowNexus 6
    MOB31Sandroid-6.0.1_r78MarshmallowNexus 6
    M4B30Zandroid-6.0.1_r77MarshmallowNexus 5
    MOB31Kandroid-6.0.1_r74MarshmallowNexus 6
    MMB31Candroid-6.0.1_r73MarshmallowNexus 6
    M4B30Xandroid-6.0.1_r72MarshmallowNexus 5
    MOB31Handroid-6.0.1_r70MarshmallowNexus 6
    MMB30Yandroid-6.0.1_r69MarshmallowNexus 6
    MTC20Kandroid-6.0.1_r67MarshmallowNexus 5X
    MOB31Eandroid-6.0.1_r66MarshmallowNexus 5, Nexus 6, Nexus 9 (volantis)
    MMB30Wandroid-6.0.1_r65MarshmallowNexus 6
    MXC89Landroid-6.0.1_r63MarshmallowPixel C
    MTC20Fandroid-6.0.1_r62MarshmallowNexus 5X, Nexus 6P
    MOB30Yandroid-6.0.1_r60MarshmallowNexus 5
    MOB30Xandroid-6.0.1_r59MarshmallowNexus 7 (flo/deb)
    MOB30Wandroid-6.0.1_r58MarshmallowNexus 6, Nexus 9 (volantis/volantisg), Nexus Player
    MMB30Sandroid-6.0.1_r57MarshmallowNexus 7 (deb)
    MMB30Randroid-6.0.1_r56MarshmallowNexus 6
    MXC89Kandroid-6.0.1_r55MarshmallowPixel C
    MTC19Zandroid-6.0.1_r54MarshmallowNexus 5X
    MTC19Xandroid-6.0.1_r53MarshmallowNexus 6P
    MOB30Pandroid-6.0.1_r50MarshmallowNexus 5, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MOB30Oandroid-6.0.1_r49MarshmallowNexus 6
    MMB30Mandroid-6.0.1_r48MarshmallowNexus 7 (deb)
    MMB30Kandroid-6.0.1_r47MarshmallowNexus 6
    MOB30Mandroid-6.0.1_r46MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MTC19Vandroid-6.0.1_r45MarshmallowNexus 5X, Nexus 6P
    MOB30Jandroid-6.0.1_r43MarshmallowNexus 7 (flo/deb)
    MOB30Iandroid-6.0.1_r42MarshmallowNexus 6
    MOB30Handroid-6.0.1_r41MarshmallowNexus 5
    MOB30Gandroid-6.0.1_r40MarshmallowNexus 9 (volantis/volantisg), Nexus Player
    MXC89Handroid-6.0.1_r33MarshmallowPixel C
    MXC89Fandroid-6.0.1_r32MarshmallowPixel C
    MMB30Jandroid-6.0.1_r28MarshmallowNexus 6, Nexus 7 (deb)
    MTC19Tandroid-6.0.1_r25MarshmallowNexus 5X, Nexus 6P
    M5C14Jandroid-6.0.1_r31MarshmallowPixel C
    MOB30Dandroid-6.0.1_r30MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MHC19Qandroid-6.0.1_r24MarshmallowNexus 5X, Nexus 6P
    MHC19Jandroid-6.0.1_r22MarshmallowNexus 5X
    MHC19Iandroid-6.0.1_r21MarshmallowNexus 6P
    MMB29Xandroid-6.0.1_r20MarshmallowNexus 5, Nexus 6, Nexus 7 (deb), Nexus 9 (volantisg)
    MXC14Gandroid-6.0.1_r18MarshmallowPixel C
    MMB29Vandroid-6.0.1_r17MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 6P, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
    MXB48Tandroid-6.0.1_r16MarshmallowPixel C
    MMB29Uandroid-6.0.1_r13MarshmallowNexus Player
    MMB29Randroid-6.0.1_r12MarshmallowNexus 9 (volantis/volantisg)
    MMB29Qandroid-6.0.1_r11MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 6P, Nexus 7 (flo/deb)
    MMB29Tandroid-6.0.1_r10MarshmallowNexus Player
    MMB29Sandroid-6.0.1_r9MarshmallowNexus 5, Nexus 6, Nexus 9 (volantis/volantisg)
    MMB29Pandroid-6.0.1_r8MarshmallowNexus 5X, Nexus 6P
    MMB29Oandroid-6.0.1_r7MarshmallowNexus 7 (flo/deb)
    MXB48Kandroid-6.0.1_r5MarshmallowPixel C
    MXB48Jandroid-6.0.1_r4MarshmallowPixel C
    MMB29Mandroid-6.0.1_r3MarshmallowNexus 6P, Nexus Player
    MMB29Kandroid-6.0.1_r1MarshmallowNexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
    MMB29Nandroid-6.0.0_r41MarshmallowNexus 6P
    MDB08Mandroid-6.0.0_r26MarshmallowNexus 5X, Nexus 6P
    MDB08Landroid-6.0.0_r25MarshmallowNexus 5X, Nexus 6P
    MDB08Kandroid-6.0.0_r24MarshmallowNexus 6P
    MDB08Iandroid-6.0.0_r23MarshmallowNexus 5X
    MDA89Eandroid-6.0.0_r12MarshmallowNexus 5X
    MDA89Dandroid-6.0.0_r11MarshmallowNexus 6P
    MRA59Bandroid-6.0.0_r7MarshmallowNexus 7 (deb)
    MRA58Xandroid-6.0.0_r6MarshmallowNexus 6
    MRA58Vandroid-6.0.0_r5MarshmallowNexus 7 (flo/deb)
    MRA58Uandroid-6.0.0_r4MarshmallowNexus 7 (flo)
    MRA58Nandroid-6.0.0_r2MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    MRA58Kandroid-6.0.0_r1MarshmallowNexus 5, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), Nexus Player
    LMY49Mandroid-5.1.1_r38LollipopNexus 10
    LMY49Jandroid-5.1.1_r37LollipopNexus 10
    LMY49Iandroid-5.1.1_r36LollipopNexus 10
    LMY49Handroid-5.1.1_r35LollipopNexus 10
    LMY49Gandroid-5.1.1_r34LollipopNexus 10
    LMY49Fandroid-5.1.1_r33LollipopNexus 9 (volantisg), Nexus 10
    LMY48Zandroid-5.1.1_r30LollipopNexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10
    LYZ28Nandroid-5.1.1_r28LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Yandroid-5.1.1_r26LollipopNexus 6
    LMY48Xandroid-5.1.1_r25LollipopNexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10
    LMY48Wandroid-5.1.1_r24LollipopNexus 6
    LVY48Handroid-5.1.1_r23LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Mandroid-5.1.1_r22LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Uandroid-5.1.1_r20LollipopNexus 7 (deb)
    LMY48Tandroid-5.1.1_r19LollipopNexus 4, Nexus 6, Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Fandroid-5.1.1_r18LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Kandroid-5.1.1_r17LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Pandroid-5.1.1_r16LollipopNexus 7 (deb)
    LMY48Nandroid-5.1.1_r15LollipopNexus Player
    LMY48Mandroid-5.1.1_r14LollipopNexus 4, Nexus 5, Nexus 6, Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Eandroid-5.1.1_r13LollipopNexus 6 (For Project Fi ONLY)
    LYZ28Jandroid-5.1.1_r12LollipopNexus 6 (For T-Mobile ONLY)
    LMY48Jandroid-5.1.1_r10LollipopNexus Player
    LMY48Iandroid-5.1.1_r9LollipopNexus 4, Nexus 5, Nexus 6, Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LVY48Candroid-5.1.1_r8LollipopNexus 6 (For Project Fi ONLY)
    LMY48Gandroid-5.1.1_r6LollipopNexus 7 (flo)
    LYZ28Eandroid-5.1.1_r5LollipopNexus 6 (For T-Mobile ONLY)
    LMY47Zandroid-5.1.1_r4LollipopNexus 6 (All carriers except T-Mobile US)
    LMY48Bandroid-5.1.1_r3LollipopNexus 5
    LMY47Xandroid-5.1.1_r2LollipopNexus 9 (volantis)
    LMY47Vandroid-5.1.1_r1LollipopNexus 7 (flo/grouper), Nexus 10, Nexus Player
    LMY47Oandroid-5.1.0_r5LollipopNexus 4, Nexus 7 (flo/deb)
    LMY47Mandroid-5.1.0_r4LollipopNexus 6 (For T-Mobile ONLY)
    LMY47Iandroid-5.1.0_r3LollipopNexus 5, Nexus 6
    LMY47Eandroid-5.1.0_r2LollipopNexus 6
    LMY47Dandroid-5.1.0_r1LollipopNexus 5, Nexus 6, Nexus 7 (grouper/tilapia), Nexus 10, Nexus Player
    LRX22Landroid-5.0.2_r3LollipopNexus 9 (volantis/volantisg)
    LRX22Gandroid-5.0.2_r1LollipopNexus 7 (flo/deb/grouper/tilapia), Nexus 10
    LRX22Candroid-5.0.1_r1LollipopNexus 4, Nexus 5, Nexus 6 (shamu), Nexus 7 (flo), Nexus 9 (volantis/volantisg), Nexus 10
    LRX21Vandroid-5.0.0_r7.0.1LollipopNexus Player (fugu)
    LRX21Tandroid-5.0.0_r6.0.1LollipopNexus 4
    LRX21Randroid-5.0.0_r5.1.0.1LollipopNexus 9 (volantis)
    LRX21Qandroid-5.0.0_r5.0.1LollipopNexus 9 (volantis)
    LRX21Pandroid-5.0.0_r4.0.1LollipopNexus 7 (flo/grouper), Nexus 10
    LRX21Oandroid-5.0.0_r3.0.1LollipopNexus 5 (hammerhead), Nexus 6 (shamu)
    LRX21Mandroid-5.0.0_r2.0.1LollipopNexus Player (fugu)
    LRX21Landroid-5.0.0_r1.0.1LollipopNexus 9 (volantis)
    KTU84Qandroid-4.4.4_r2KitKatNexus 5 (hammerhead) (For 2Degrees/NZ, Telstra/AUS and India ONLY)
    KTU84Pandroid-4.4.4_r1KitKatNexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KTU84Mandroid-4.4.3_r1.1KitKatNexus 5 (hammerhead)
    KTU84Landroid-4.4.3_r1KitKatNexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KVT49Landroid-4.4.2_r2KitKatNexus 7 (deb Verizon)
    KOT49Handroid-4.4.2_r1KitKat Nexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KOT49Eandroid-4.4.1_r1KitKatNexus 5, Nexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KRT16Sandroid-4.4_r1.2KitKatNexus 7 (flo/deb/grouper/tilapia), Nexus 4, Nexus 10
    KRT16Mandroid-4.4_r1KitKatNexus 5 (hammerhead)
    JLS36Iandroid-4.3.1_r1Jelly BeanNexus 7 (deb)
    JLS36Candroid-4.3_r3Jelly Bean Nexus 7 (deb)
    JSS15Randroid-4.3_r2.3Jelly BeanNexus 7 (flo)
    JSS15Qandroid-4.3_r2.2Jelly BeanNexus 7 (flo)
    JSS15Jandroid-4.3_r2.1Jelly BeanNexus 7 (flo/deb)
    JSR78Dandroid-4.3_r2Jelly BeanNexus 7 (deb)
    JWR66Yandroid-4.3_r1.1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia), Nexus 4, Nexus 10
    JWR66Vandroid-4.3_r1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia), Nexus 4, Nexus 10
    JWR66Nandroid-4.3_r0.9.1Jelly BeanGalaxy Nexus, Nexus 7 (grouper/tilapia/flo), Nexus 4, Nexus 10
    JWR66Landroid-4.3_r0.9Jelly BeanNexus 7
    JDQ39Eandroid-4.2.2_r1.2Jelly BeanNexus 4
    JDQ39Bandroid-4.2.2_r1.1Jelly BeanNexus 7
    JDQ39android-4.2.2_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JOP40Gandroid-4.2.1_r1.2Jelly BeanNexus 4
    JOP40Fandroid-4.2.1_r1.1Jelly BeanNexus 10
    JOP40Dandroid-4.2.1_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JOP40Candroid-4.2_r1Jelly BeanGalaxy Nexus, Nexus 7, Nexus 4, Nexus 10
    JZO54Mandroid-4.1.2_r2.1Jelly Bean
    JZO54Landroid-4.1.2_r2Jelly Bean
    JZO54Kandroid-4.1.2_r1Jelly BeanNexus S, Galaxy Nexus, Nexus 7
    JRO03Sandroid-4.1.1_r6.1Jelly BeanNexus 7
    JRO03Randroid-4.1.1_r6Jelly BeanNexus S 4G
    JRO03Oandroid-4.1.1_r5Jelly BeanGalaxy Nexus
    JRO03Landroid-4.1.1_r4Jelly BeanNexus S
    JRO03Handroid-4.1.1_r3Jelly Bean
    JRO03Eandroid-4.1.1_r2Jelly BeanNexus S
    JRO03Dandroid-4.1.1_r1.1Jelly BeanNexus 7
    JRO03Candroid-4.1.1_r1Jelly BeanGalaxy Nexus
    IMM76Landroid-4.0.4_r2.1Ice Cream Sandwich 
    IMM76Kandroid-4.0.4_r2Ice Cream SandwichGalaxy Nexus
    IMM76Iandroid-4.0.4_r1.2Ice Cream SandwichGalaxy Nexus
    IMM76Dandroid-4.0.4_r1.1Ice Cream SandwichNexus S, Nexus S 4G, Galaxy Nexus
    IMM76android-4.0.4_r1Ice Cream Sandwich
    IML77android-4.0.3_r1.1Ice Cream Sandwich
    IML74Kandroid-4.0.3_r1Ice Cream SandwichNexus S
    ICL53Fandroid-4.0.2_r1Ice Cream SandwichGalaxy Nexus
    ITL41Fandroid-4.0.1_r1.2Ice Cream SandwichGalaxy Nexus
    ITL41Dandroid-4.0.1_r1.1Ice Cream SandwichGalaxy Nexus
    ITL41Dandroid-4.0.1_r1Ice Cream SandwichGalaxy Nexus
    GWK74android-2.3.7_r1GingerbreadNexus S 4G
    GRK39Fandroid-2.3.6_r1GingerbreadNexus One, Nexus S
    GRK39Candroid-2.3.6_r0.9GingerbreadNexus S
    GRJ90android-2.3.5_r1GingerbreadNexus S 4G
    GRJ22android-2.3.4_r1GingerbreadNexus One, Nexus S, Nexus S 4G
    GRJ06Dandroid-2.3.4_r0.9GingerbreadNexus S 4G
    GRI54android-2.3.3_r1.1GingerbreadNexus S
    GRI40android-2.3.3_r1GingerbreadNexus One, Nexus S
    GRH78Candroid-2.3.2_r1GingerbreadNexus S
    GRH78android-2.3.1_r1GingerbreadNexus S
    GRH55android-2.3_r1Gingerbreadearliest Gingerbread version, Nexus S
    FRK76Candroid-2.2.3_r2Froyo 
    FRK76android-2.2.3_r1Froyo
    FRG83Gandroid-2.2.2_r1FroyoNexus One
    FRG83Dandroid-2.2.1_r2FroyoNexus One
    FRG83android-2.2.1_r1FroyoNexus One
    FRG22Dandroid-2.2_r1.3Froyo
    FRG01Bandroid-2.2_r1.2Froyo
    FRF91android-2.2_r1.1FroyoNexus One
    FRF85Bandroid-2.2_r1FroyoNexus One
    EPF21Bandroid-2.1_r2.1p2Eclair 
    ESE81android-2.1_r2.1sEclair
    EPE54Bandroid-2.1_r2.1pEclairNexus One
    ERE27android-2.1_r2EclairNexus One
    ERD79android-2.1_r1EclairNexus One
    ESD56android-2.0.1_r1Eclair
    ESD20android-2.0_r1Eclair 
    DMD64android-1.6_r1.5Donut 
    DRD20android-1.6_r1.4
    DRD08android-1.6_r1.3
    DRC92android-1.6_r1.2
    
-
    The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
-jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-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.
    
-
-
    To differentiate between releases, you may obtain a list of changes
-associated with each project by issuing the following command and passing it
-the two branch tags:
    
-
-
    repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'
    
-
-
    For example:
    
-
-
    repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'
    
-
-
    And to output to a text file:
    
-
-
    repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-android-4.4.2_r1-diff.txt
    
-
-
    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:
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    BuildTagNotes
    HRI39android-3.0_r1earliest Honeycomb version
    HRI66android-3.0_r1.1
    HWI69android-3.0_r1.2
    HRI83android-3.0_r1.3
    HMJ37android-3.1_r1
    HTJ85Bandroid-3.2_r1
    HTK55Dandroid-3.2.1_r1
    HTK75Dandroid-3.2.1_r2
    HLK75Candroid-3.2.2_r1
    HLK75Dandroid-3.2.2_r2
    HLK75Fandroid-3.2.4_r1
    HLK75Handroid-3.2.6_r1latest 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/en/source/building-kernels.html b/en/source/building-kernels.html
deleted file mode 100644
index 1ddfe4fa..00000000
--- a/en/source/building-kernels.html
+++ /dev/null
@@ -1,277 +0,0 @@
-
-  
-    Building Kernels
-    
-    
-  
-  
-  
-
-
-
-
    This page details how to build only the kernel. The following instructions
-assume you have not downloaded all of AOSP; if you have already done so, you can
-skip the git clone steps except the step that downloads the kernel
-sources.
    
-
-
    All examples in this section use the
-hikey kernel.
    
-
-
    Selecting a kernel
    
-
    This table lists the name and locations of the kernel sources and binaries:
-
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-  
-    
-    
-    
-    
-  
-
    DeviceBinary locationSource locationBuild configuration
    marlindevice/google/marlin-kernelkernel/msmmarlin_defconfig
    sailfishdevice/google/marlin-kernelkernel/msmmarlin_defconfig
    hikeydevice/linaro/hikey-kernelkernel/hikey-linarohikey_defconfig
    anglerdevice/huawei/angler-kernelkernel/msmangler_defconfig
    bullheaddevice/lge/bullhead-kernelkernel/msmbullhead_defconfig
    shamudevice/moto/shamu-kernelkernel/msmshamu_defconfig
    fugudevice/asus/fugu-kernelkernel/x86_64fugu_defconfig
    volantisdevice/htc/flounder-kernelkernel/tegraflounder_defconfig
    hammerheaddevice/lge/hammerhead-kernelkernel/msmhammerhead_defconfig
    flodevice/asus/flo-kernel/kernelkernel/msmflo_defconfig
    debdevice/asus/flo-kernel/kernelkernel/msmflo_defconfig
    mantadevice/samsung/manta/kernelkernel/exynosmanta_defconfig
    makodevice/lge/mako-kernel/kernelkernel/msmmako_defconfig
    grouperdevice/asus/grouper/kernelkernel/tegrategra3_android_defconfig
    tilapiadevice/asus/grouper/kernelkernel/tegrategra3_android_defconfig
    magurodevice/samsung/tuna/kernelkernel/omaptuna_defconfig
    torodevice/samsung/tuna/kernelkernel/omaptuna_defconfig
    pandadevice/ti/panda/kernelkernel/omappanda_defconfig
    stingraydevice/moto/wingray/kernelkernel/tegrastingray_defconfig
    wingraydevice/moto/wingray/kernel kernel/tegrastingray_defconfig
    crespodevice/samsung/crespo/kernelkernel/samsungherring_defconfig
    crespo4gdevice/samsung/crespo/kernelkernel/samsungherring_defconfig
    
-
-
    After determining the device project you want to work with, view the git log
-for the kernel binary. Device projects use the form
-device/VENDOR/NAME.
    
-
-
    -git clone https://android.googlesource.com/kernel/hikey-linaro
-cd hikey-linaro
-git log --max-count=1 kernel
-
    
-
-
    The commit message for the kernel binary contains a partial git log of the
-kernel sources used to build the binary. The first entry in the log is the most
-recent (the one used to build the kernel). Make a note of the commit message
-as you will need it in a later step.
    
-
-
    Identifying kernel version
    
-
-
    To determine the kernel version used in a system image, run the following
-command against the kernel file:
    
-
-
    -dd if=kernel bs=1 skip=$(LC_ALL=C grep -a -b -o $'\x1f\x8b\x08\x00\x00\x00\x00\x00' kernel | cut -d ':' -f 1) | zgrep -a 'Linux version'
-
    
-
-
    For Nexus 5 (hammerhead), the command is:
    
-
    -dd if=zImage-dtb bs=1 skip=$(LC_ALL=C od -Ad -x -w2 zImage-dtb | grep 8b1f | cut -d ' ' -f1 | head -1) | zgrep -a 'Linux version'
-
    
-
-
-
    Downloading sources
    
-
    Download the source for the kernel you want to build using the appropriate
-git clone command. For example, the following command clones the common kernel, a generic, customizable kernel:
    
-
    -git clone https://android.googlesource.com/kernel/common
-
    
-
-
    A full list of the kernel projects can be found in the Kernel directory. Below are some of the commonly used kernels and their respective git clone commands.
    
-
-
    The exynos project has the kernel sources for Nexus 10, and can be used as a starting point for work on Samsung Exynos chipsets.
    
-
    git clone https://android.googlesource.com/kernel/exynos
    
-
-
    The goldfish project contains the kernel sources for the emulated platforms.
    
-
    git clone https://android.googlesource.com/kernel/goldfish
    
-
-
    The hikey-linaro project is used for HiKey reference boards, and can be used as a starting point for work on HiSilicon 620 chipsets.
    
-
    git clone https://android.googlesource.com/kernel/hikey-linaro
    
-
-
    The msm project has the sources for ADP1, ADP2, Nexus One, Nexus 4, Nexus 5, Nexus 6, Nexus 5X, Nexus 6P, Nexus 7 (2013), Pixel, and Pixel XL, and can be used as a starting point for work on Qualcomm MSM chipsets.
    
-
    git clone https://android.googlesource.com/kernel/msm
    
-
-
    The omap project is used for PandaBoard and Galaxy Nexus, and can be used as a starting point for work on TI OMAP chipsets.
    
-
    git clone https://android.googlesource.com/kernel/omap
    
-
-
    The samsung project is used for Nexus S, and can be used as a starting point for work on Samsung Hummingbird chipsets.
    
-
    git clone https://android.googlesource.com/kernel/samsung
    
-
-
    The tegra project is for Xoom, Nexus 7 (2012), Nexus 9, and can be used as a starting point for work on NVIDIA Tegra chipsets.
    
-
    git clone https://android.googlesource.com/kernel/tegra
    
-
-
    The x86_64 project has the kernel sources for Nexus Player, and can be used as a starting point for work on Intel x86_64 chipsets.
    
-
    git clone https://android.googlesource.com/kernel/x86_64
    
-
-
    Building the kernel
    
-
    When you know the last commit message for a kernel and have successfully
-downloaded the kernel source and prebuilt gcc, you are ready to build the
-kernel. The following build commands use the hikey kernel:
    
-
    -export ARCH=arm64
-export CROSS_COMPILE=aarch64-linux-android-
-cd hikey-linaro
-git checkout -b android-hikey-linaro-4.1 origin/android-hikey-linaro-4.1
-make hikey_defconfig
-make
-
    
-
-
    To build a different kernel, simply replace hikey-linaro with
-the name of the kernel you want to build.
    
-
-
    The image outputs to the arch/arm64/boot/Image directory; the
-kernel binary outputs to the
-arch/arm64/boot/dts/hisilicon/hi6220-hikey.dtb fle. Copy the
-Image directory and the hi6220-hikey.dtb file to the
-hikey-kernel directory.
    
-
-
    Alternatively, you can include the TARGET_PREBUILT_KERNEL
-variable while using make bootimage (or any other make
-command line that builds a boot image). This variable is supported by all
-devices as it is set up via device/common/populate-new-device.sh.
-For example:
    
-
-
    -export TARGET_PREBUILT_KERNEL=$your_kernel_path/arch/arm/boot/zImage-dtb
-
    
-
-
    Note: Kernel names differ by device. To locate
-the correct filename for your kernel, refer to
-device/VENDOR/NAME in the kernel source.
    
-
-  
-
diff --git a/en/source/building.html b/en/source/building.html
deleted file mode 100644
index 4a4bf567..00000000
--- a/en/source/building.html
+++ /dev/null
@@ -1,228 +0,0 @@
-
-  
-    Preparing to Build
-    
-    
-  
-  
-  
-
-
-
-
    The following instructions to build the Android source tree apply to all
-branches, including master. The basic sequence of build commands
-is as follows:
    
-
-
    Obtain proprietary binaries
    
-
-
    AOSP cannot be used from pure source code only and requires additional
-hardware-related proprietary libraries to run, such as for hardware
-graphics acceleration. See the sections below for download links and Device binaries for additional
-resources.
    
-
-
    Some devices package these proprietary binaries on their
-/vendor partition.
    
-
-
    Download proprietary binaries
    
-
-
    You can download official binaries for the supported devices running tagged
-AOSP release branches from Google's
-drivers. These binaries add access to additional hardware capabilities
-with non-open source code. To instead build the AOSP master branch, use the
-Binaries
-Preview. When building the master branch for a device, use
-the binaries for the most recent
-numbered release or with the most recent date.
    
-
-
    Extract proprietary binaries
    
-
-
    Each set of binaries comes as a self-extracting script in a compressed
-archive. Uncompress each archive, run the included self-extracting script from
-the root of the source tree, then confirm that you agree to the terms
-of the enclosed license agreement. The binaries and their matching makefiles
-will be installed in the vendor/ hierarchy of the source tree.
    
-
-
    Clean up
    
-
-
    To ensure the newly installed binaries are properly taken into account after
-being extracted, delete the existing output of any previous build using:
    
-
    -make clobber
-
    
-
-
    Set up environment
    
-
    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. For example, the following command:
    
-
    -lunch aosp_arm-eng
-
    
-
    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.
    
-
-
    The BUILDTYPE is one of the following:
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    BuildtypeUse
    userlimited access; suited for production
    userdebuglike "user" but with root access and debuggability; preferred for debugging
    engdevelopment configuration with additional debugging tools
    
-
    For more information about building for and running on actual hardware, see
-Running Builds.
    
-
-
    Build the code
    
-
-
    Please note, this section is merely a summary to ensure setup is complete. See
-Running Builds for detailed instructions on building
-Android.
    
-
-
    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. For example, 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.
    
-
-
    Note: Remember to obtain proprietary binaries or your
-build will not boot successfully on your target hardware. If you obtain binary
-blobs at this point you will need to unpack them, make clobber and
-rebuild.
    
-
-
    Flash with fastboot
    
-
-
    To flash a device, you will need to use fastboot, which should
-be included in your path after a successful build. See Flashing a device for
-instructions.
    
-
-
    Emulate an Android Device
    
-
-
    The emulator is added to your path automatically by the build process. To
-run the emulator, type:
    
-
-
    -emulator
-
    
-
-
    Troubleshooting Common Build Errors
    
-
-
    Wrong Java Version
    
-
-
    If you are attempting to build a version of Android inconsistent with your
-version of Java, 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/initializing.html
-************************************************************
-
    
-
-
    This may be caused by:
    
-
-
      
-
    • Failing to install the correct JDK as specified in JDK Requirements.
      • 
-
    • Another JDK previously installed appearing in your path. Prepend the
-correct JDK to the beginning of your PATH or remove the problematic JDK.
      • 
-
    
-
-
    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, 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 in Initializing
-the Build Environment 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
-Initializing the Build Environment 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/en/source/code-lines.html b/en/source/code-lines.html
deleted file mode 100644
index b4040abd..00000000
--- a/en/source/code-lines.html
+++ /dev/null
@@ -1,187 +0,0 @@
-
-  
-    Codelines, Branches, and Releases
-    
-    
-  
-  
-  
-
-
-
-
    
-  The Android Open Source Project (AOSP) maintains a complete software stack to be ported by
-  OEMs and other device implementors and run on their own hardware. To maintain the quality of
-  Android, Google has contributed full-time engineers, product managers, user interface designers,
-  quality assurance testers, and all the other roles required to bring modern devices to market.
-
    
-
-
    
-  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.
-
    
-
-
    
-  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 for a given "code line". For instance, when a
-  release is cut, it may or may not become a new branch based on the needs of the moment.
-
    
-
      
-  
    1. 
-	
      
-	  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.
-	
      
-  
      2. 
-  
    2. 
-	
      
-	  Device builders and contributors work with the current latest release, fixing bugs,
-	  launching new devices, experimenting with new features, and so on.
-	
      
-  
      3. 
-  
    3. 
-	
      
-	  In parallel, Google works internally on the next version of the Android platform and
-	  framework 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.
-	
      
-  
      4. 
-  
    4. 
-	
      
-	  When the "n+1"th version is ready, it will be published to the public source tree and
-	  become the new latest release.
-	
      
-  
      5. 
-
    
-  code-line diagram
-
    
-  Figure 1. AOSP code and releases
-
    
-
    
-  Terms and Caveats
-
    
-
      
-  
    • 
-	
      
-	  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 the version in
-	  the SdkVersion field of AndroidManifest.xml files and defined within
-	  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.
-	  Over time we are migrating some of the semi-autonomous Android projects (such as ART,
-	  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 for details. In both cases,
-	  snapshots will be periodically pulled into releases.
-	
      
-  
      • 
-  
    • 
-	
      
-	  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.
-	
      
-  
      • 
-  
    • 
-	
      
-	  "Experimental" code-lines are established to capture changes from the community so they can
-          be iterated on with an eye toward stability.
-	
      
-  
      • 
-  
    • 
-	
      
-	  Changes that prove stable will eventually be pulled into a release branch. Note this
-	  applies only to bug fixes, application improvements, and other changes 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 About Private Codelines 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 Codelines
-
    
-
    
-  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 platform
-  versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
-  direction of Android as a platform and a product. Our approach focuses on a small number of
-  flagship devices to drive features while securing protections of Android-related intellectual
-  property. 
-
    
-
    
-  As a result, Google frequently has possession of confidential information from third parties.
-  And we must refrain from revealing sensitive features until we've secured the appropriate
-  protections. In addition, 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 many contributors will disagree with this approach. We respect others
-  may have a different point of view; however, this is the approach we feel is best, and
-  the one we've chosen to implement.
-
    
-
-  
-
diff --git a/en/source/code-style.html b/en/source/code-style.html
deleted file mode 100644
index 5367bd68..00000000
--- a/en/source/code-style.html
+++ /dev/null
@@ -1,718 +0,0 @@
-
-  
-    AOSP Java Code Style for Contributors
-    
-    
-  
-  
-  
-
-
-
-
    The code styles below are strict rules for contributing Java code to the
-Android Open Source Project (AOSP).  Contributions to the Android platform that
-do not adhere to these rules are generally not accepted. We recognize
-that not all existing code follows these rules, but we expect all new code to
-be compliant.
    
-
-
    Note: These rules are intended for the Android
-platform and are not required of Android app developers. App developers may
-follow the standard of their choosing, such as the Google Java Style
-Guide.
    
-
-
    Java Language Rules
    
-
    Android follows standard Java coding conventions with the additional rules
-described below.
    
-
-
    Don't Ignore Exceptions
    
-
    It can be tempting to write code that completely ignores an exception, such
-as:
    
-
    void setServerPort(String value) {
-    try {
-        serverPort = Integer.parseInt(value);
-    } catch (NumberFormatException e) { }
-}
-
    
-
    Do not do this. While you may think your code will never encounter this error
-condition or that it is not important to handle it, ignoring exceptions as above
-creates mines in your code for someone else to trigger some day. You must handle
-every Exception in your code in a 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
    
-
    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, so do it only 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 The original exception is passed to the
-constructor for RuntimeException. If your code must compile under Java 1.3, you
-must omit the exception that is the cause.
      
-
      • 
-
    • As a last resort, if you are confident that 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
    
-
    It can also be 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!
-}
-
    
-
    Do not do this. In almost all cases it is inappropriate to catch generic
-Exception or Throwable (preferably not Throwable because it includes Error
-exceptions). It is very dangerous because it means that Exceptions
-you never expected (including RuntimeExceptions like ClassCastException) get
-caught in application-level error handling. It obscures the failure handling
-properties of your code, meaning 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 the
-error differently. In most cases you shouldn't be handling different types of
-exception the same way.
    
-
    The rare exception to this rule is 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 these cases you may catch generic Exception
-(or Throwable) and handle the error appropriately. 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.
      • 
-
-
    • 
-
      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. While they can be handy for doing cleanup (particularly of
-external resources), there are no guarantees as to when a finalizer will be
-called (or even that it will be called at all).
    
-
    Android doesn'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:
    
-
      
-
    • import foo.*;
-
      Potentially reduces the number of import statements.
      • 
-
    • import foo.Bar;
-
      Makes it obvious what classes are actually used and the code is more readable
-for maintainers.
    
-
    Use import foo.Bar; 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. When creating new components however, never use
-deprecated libraries.
    
-
-
    Java Style Rules
    
-
-
    Use Javadoc Standard Comments
    
-
    Every file should have a copyright statement at the top, followed by package
-and import statements (each block separated by a blank line) and finally the
-class or interface declaration. In the Javadoc comments, describe what the class
-or interface does.
    
-
    /*
- * Copyright (C) 2015 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 third 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 has an important
-side effect), then you must document it. If it's not obvious what the property
-"Foo" means, you should document it.
-
    Every method you write, 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 instructions How
-to Write Doc Comments for the Javadoc Tool.
    
-
-
    Write Short Methods
    
-
    When feasible, keep methods small and focused. We recognize 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
    
-
    Define fields either at the top of the file or immediately before the
-methods that use them.
    
-
-
    Limit Variable Scope
    
-
    Keep the scope of local variables to a minimum. 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, postpone the
-declaration until you do.
    
-
    The exception is 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));
-
    
-
    However, 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
      
-
      2. 
-
    2. 
-
      Imports from third parties (com, junit,
-net, org)
      
-
      3. 
-
    3. 
-
      java and javax
      
-
      4. 
-
    
-
    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).
      
-
      • 
-
    • 
-
      Separated by a blank line between each major grouping (android,
-com, junit, net, org,
-java, javax).
      
-
      • 
-
    
-
    Originally, there was no style requirement on the ordering, meaning IDEs were
-either always changing the ordering or IDE developers had to disable the
-automatic import management features and manually maintain the imports. This was
-deemed bad. When java-style was asked, the preferred styles varied wildly and it
-came down to Android needing to simply "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, imports in all packages will match this
-pattern without 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 prefer static imports to be interspersed with the
-remaining imports, while some prefer them to reside above or below all
-other imports. Additionally, we have not yet determined how to make all IDEs use
-the same ordering. Since many consider this a low priority issue, just use your
-judgement and be consistent.
    
-
-
    Use Spaces for Indentation
    
-
    We use four (4) space indents for blocks and never tabs. When in doubt, be
-consistent with the surrounding code.
    
-
    We use eight (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:
    
-
    class MyClass {
-    int func() {
-        if (something) {
-            // ...
-        } else if (somethingElse) {
-            // ...
-        } else {
-            // ...
-        }
-    }
-}
-
    
-
    We require braces around the statements for a conditional. Exception: 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. For example, this is acceptable:
    
-
    if (condition) {
-    body();
-}
-
    
-
    and this is acceptable:
    
-
    if (condition) body();
-
    
-
    but this is not acceptable:
    
-
    if (condition)
-    body();  // bad!
-
    
-
-
    Limit Line Length
    
-
    Each line of text in your code should be at most 100 characters long. While
-much discussion has surrounded this rule, the decision remains that 100
-characters is the maximum with the following exceptions:
    
-
      
-
    • 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.
      • 
-
    • 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 be
-used only 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 to make names more readable:
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    GoodBad
    XmlHttpRequestXMLHTTPRequest
    getCustomerIdgetCustomerID
    class Htmlclass HTML
    String urlString URL
    long idlong ID
    
-
    As both the JDK and the Android code bases are very inconsistent around
-acronyms, it is virtually impossible to be consistent with the surrounding
-code. Therefore, always treat acronyms as words.
    
-
-
    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 not kept reasonably
-terse. The logging facilities provides five different levels of logging:
    
-
      
-
    • ERROR:
-Use when something fatal has happened, i.e. something 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
-device (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:
-Use 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:
-Use 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:
-Use 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:
-Use 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
-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, 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).
      • 
-
    • Having a full filesystem on a filesystem that is accessible 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
-connection) is considered expected and should not trigger any logging at a
-level higher than 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 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). 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 used to diagnose an issue that is hard to reproduce should
-be kept at the DEBUG or VERBOSE level and should be enclosed by if blocks that
-allow for disabling 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 surrounding code and determine its style. If that code
-uses spaces around the if clauses, you should too. If the code 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 the code you add to 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.
    
-
-
    Javatests Style Rules
    
-
    Follow test method naming conventions and use an underscore to separate 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/en/source/community.html b/en/source/community.html
deleted file mode 100644
index 2e78a9c8..00000000
--- a/en/source/community.html
+++ /dev/null
@@ -1,361 +0,0 @@
-
-  
-    Android Community
-    
-    
-  
-  
-  
-
-
-
-
    Welcome to the Android community!
    
-
-
    The key to any community is 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. View the available groups
-and join any that seem interesting to you. You can also discuss Android on
-IRC.
    
-
-
    If you are a user looking for help with the Android UI or an Android device,
-details on Android updates or security issues, or how to build applications for
-Android, see the list of resources below.
    
-
-
    Resources
    
-
-
    This site covers creating custom Android stacks, porting devices and
-accessories, and meeting compatibility requirements. The Android OS is a Git
-repository of files and not a single file (.zip/tar/exe/etc.) to download. You
-can get started with the Android source code by following the instructions on
-the Downloading the Source
-page. For other information about Android, refer to the following resources.
    
-
-
-
-
-
-
-
    
-
    Using Android
    
-
-
    Help centers
    
-General
    
-Pixel phones
    
-Nexus phones/tablets
    
-Google Play Edition
    
-Auto
    
-TV
    
-Wear
    
-Apps
-
    
-
-
    Communities
    
-AOSP communities
    
-Developer communities
-
    
-
-
    Send feedback
    
-Report AOSP bug
    
-
    
-
-    		
-
-
    Updates & security
    
-
-
    Android releases
    
-Android history
    
-Current release
-
    
-
-
    Device images
    
-Nexus and Pixel devices
    
-Other devices
-
    
-
-
    Security assistance
    
-Google Safety Center
    
-Tips for users
    
-Tips
-for developers
    
-Platform security
-
    
-
-
    Security announcements
    
-Release
-enhancements
    
-Bulletins
-
    
-
-    		
-
-
    Getting involved
    
-
-
    Developer resources
    
-Developer.android.com
    
-Developer support
    
-Android developers blog
    
-Google Developer Groups (GDGs)
    
-Google Mobile Services (GMS)
-
    
-
-
    Training
    
-Google
    
-Udacity
-
-
    
-
-
-
    Open Source Project discussions
    
-
      
-
    • 
-
      android-platform:
-This list is for general discussion about the Android Open Source Project or
-the platform technologies.
      
-
-
      • 
-
    • 
-
      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.
      
-
-
      • 
-
    • 
-
      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.
      
-
-
      • 
-
    • 
-
      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 (and contributors to the Android
-kernel should go to android-kernel).
      
-
-
      • 
-
    • 
-
      android-kernel:
-This list is for developers who want to contribute to the Linux kernel used by
-Android devices. If you've downloaded the kernel code, know how to compile it,
-and want to write kernel code to support Android, this is your place. This
-group is not for user-space topics (see android-platform); people
-will shake their fingers at you and call you naughty if you ask user-space
-questions here.
      
-
-
    • 
-
      android-ota:
-This list is for developers working on the Android OTA system (the recovery
-image and the scripts that generate OTAs).
      
-
-
      • 
-
    
-
-
    Audience
    
-
    These discussion groups are intended for developers working with the Android
-platform. Everyone is welcome to join in, provided you follow the community
-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.
    
-
-
-
    Getting the Most from Our Lists
    
-
    Please consider the following before you post to our lists.
    
-
      
-
    • 
-
      Read the Charter for our forums. 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.
      
-
      • 
-
    
-
-
    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 strongly
-about something, or just want to chat, then contact the mailing list owners.
-It's what we're here for!
    
-
-
    Using email with Google Groups
    
-
    Instead of using the Google groups
-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.
      
-
      2. 
-
    2. 
-
      Click "My membership" on the right side.
      
-
      3. 
-
    3. 
-
      Under "How do you want to read this group?" select one of the email options.
      
-
      4. 
-
    
-
    Android on IRC
    
-
    Android has a presence on IRC via
-freenode. We maintain two official IRC
-channels on irc.freenode.net (access via
-the web at freenode webchat)
    
-
      
-
    • 
-
      #android - dedicated to
-general Android discussion and porting concerns
      
-
      • 
-
    • 
-
      #android-dev - dedicated to discussion about writing Android applications
      
-
      • 
-
    
-
    The community also uses several unofficial channels that are not not officially moderated or managed. The Open Handset Alliance does not endorse unofficial channels and there's no warranty express or implied, so use them at your own risk. Here's a list of a few unofficial channels (many more may exist):
    
-
-
-
-  
-
diff --git a/en/source/contributing.html b/en/source/contributing.html
deleted file mode 100644
index 6221bfeb..00000000
--- a/en/source/contributing.html
+++ /dev/null
@@ -1,58 +0,0 @@
-
-  
-    Contributing
-    
-    
-  
-  
-  
-
-
-
    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 Overview page.
    
-
    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 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.
    
-
-
    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. 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, 
-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.
-If you need help along the way, you can join our discussion groups.
    
-
-  
-
diff --git a/en/source/developing.html b/en/source/developing.html
deleted file mode 100644
index 0535776b..00000000
--- a/en/source/developing.html
+++ /dev/null
@@ -1,189 +0,0 @@
-
-  
-    Developing
-    
-    
-  
-  
-  
-
-
-
-
    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 hobbyist 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, 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. 
    
-
    Android Studio is the official integrated development environment (IDE) for Android application development. See the Android Studio Overview for details.
-
-
    Basic Workflow
    
-
    
-  basic workflow diagram
-  
    
-    Figure 1. Basic Android workflow
-  
    
-
    
-
-
    The basic pattern of interacting with the repositories is as follows:
    
-
      
-
    1. 
-
      Use repo start to start a new topic branch.
      
-
      2. 
-
    2. 
-
      Edit the files.
      
-
      3. 
-
    3. 
-
      Use git add to stage changes.
      
-
      4. 
-
    4. 
-
      Use git commit to commit changes.
      
-
      5. 
-
    5. 
-
      Use repo upload to upload changes to the review server.
      
-
      6. 
-
    
-
    Task reference
    
-
    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 Downloading the Source and
-Using Repo.
    
-
    Synchronizing your client
    
-
    To synchronize the files for all available projects: 
    
-
    -repo sync
-
    
-
    To synchronize the files for selected projects:
    
-
    -repo sync PROJECT0 PROJECT1 ... PROJECTN
-
    
-
    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.
    
-
    To start a topic branch using Repo, navigate into the project to be modified and issue: 
    
-
    -repo start BRANCH_NAME .
-
    
-
    Please note, the period represents the project in the current working directory. To verify your new branch was created:
    
-
    -repo status .
-
    
-
    Using topic branches
    
-
    To assign the branch to a particular project:
    
-
    -repo start BRANCH_NAME PROJECT_NAME
-
    
-
    See android.googlesource.com for a list of all projects. Again, if you've already navigated into a particular project directory, you may simply pass a period to represent the current 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
    
-list of basic git and repo commands
-
    
-  Figure 2. Basic git and repo commands
-
    
-
-  
-
diff --git a/en/source/devices.html b/en/source/devices.html
deleted file mode 100644
index a6fe0849..00000000
--- a/en/source/devices.html
+++ /dev/null
@@ -1,357 +0,0 @@
-
-  
-    Using Reference Boards
-    
-    
-  
-  
-  
-
-
-
    You can create builds for Nexus devices using Android Open Source Project
-(AOSP) builds and the relevant hardware-specific binaries. For available
-Android builds and targeted devices, see
-Source Code,
-Tags, and Builds.
    
-
-
    You can also create builds for
-HiKey
-Android reference boards, which are designed to help non-Nexus component vendors
-develop and port drivers to Android releases. Using a reference board can ease
-upgrade efforts, reduce time-to-market for new Android devices, lower device
-costs by enabling ODM/OEMs to choose from a wider range of compatible
-components, and increase the speed of innovation among component suppliers.
    
-
-
    Google supports HiKey960 and
-HiKey certified
-96Boards
-as Android reference boards. AOSP provides kernel source and board support for
-HiKey so developers can easily create and debug new and existing peripheral
-drivers, do kernel development, and perform other tasks with fewer OEM
-encumbrances. To develop new ContextHub features that use new sensors or LEDs,
-you can also use a Neonkey SensorHub connected to a HiKey
-or HiKey960 development board.
    
-
-
    HiKey960 boards
    
-
-
    The HiKey960 board is available in a 3GB RAM configuration from LeMaker (via
-Amazon.com)
-and from Lenovator.
-
    
-
-HiKey960 board image
-
    Figure 1. HiKey960 board by Lenovator
    
-
-
    Additional resources:
    
-    
-
-
    Use the following commands to download, build, and run Android on the
-HiKey960 board.
    
-
-
    Compiling userspace
    
-
      
-  
    1. Download the Android source tree:
-
      -repo init -u https://android.googlesource.com/platform/manifest -b master
-repo sync -j24
-
      
-  
      2. 
-  
    2. Download and extract binaries into the Android source tree:
-
      -wget https://dl.google.com/dl/android/aosp/arm-hikey960-OPR-cf4e0c80.tgz
-tar xzf arm-hikey960-OPR-cf4e0c80.tgz
-./extract-arm-hikey960.sh
-
      
-  
      3. 
-  
    3. Build:
-
      -. ./build/envsetup.sh
-lunch hikey960-userdebug
-make -j32
-
      
-  
      4. 
-
    
-
-
    Installing initial images
    
-
      
-  
    1. Select fastboot mode turning ON switch 1 and 3 (for details, refer to the
-HiKey960 user guide).
      2. 
-  
    2. Power the board.
      3. 
-  
    3. Flash initial images:
-
      -cd device/linaro/hikey/installer/hikey960
-./flash-all.sh
-
      
-  
      4. 
-  
    4. Turn OFF switch 3 and power cycle the board.
      5. 
-
    
-
-
    Flashing images
    
-
      
-  
    1. Enter fastboot mode by turning ON switch 1 and 3.
      2. 
-  
    2. Flash images by running the following commands:
-
      -fastboot flash boot out/target/product/hikey960/boot.img
-fastboot flash dts out/target/product/hikey960/dt.img
-fastboot flash system out/target/product/hikey960/system.img
-fastboot flash cache out/target/product/hikey960/cache.img
-fastboot flash userdata out/target/product/hikey960/userdata.img
-
      
-  
      3. 
-  
    3. Turn OFF switch 3 and power cycle the board.
      4. 
-
    
-
-
    Building the kernel
    
-
      
-  
    1. Run the following commands:
-
      -git clone https://android.googlesource.com/kernel/hikey-linaro
-cd hikey-linaro
-git checkout -b android-hikey-linaro-4.9 origin/android-hikey-linaro-4.9
-make ARCH=arm64 hikey960_defconfig
-make ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- -j24
-
      
-  
      2. 
-  
    2. Update the kernel in the boot image.
-    
        
-      
      • Copy hi3660-hikey960.dtb
-        (arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dtb) to the
-        hikey-kernel directory as file:
-      hi3660-hikey960.dtb-4.9
        • 
-      
      • Copy the Image file (arch/arm64/boot/Image.gz) to the
-        hikey-kernel directory as file:
-        Image.gz-hikey960-4.9
        • 
-    
      
-  
    3. Make the boot image:
-
      -make bootimage -j24
-
      
-  
      4. 
-
    
-
-
    Setting serial number
    
-
    To set random serial number, run:
-
    -fastboot getvar nve:SN@16_DIGIT_NUMBER
-
    
-
    Bootloader exports the generated serial number to kernel via
-androidboot.serialno=.
-
-
    Setting monitor resolution
    
-
    Edit the device/linaro/hikey/hikey960/BoardConfig.mk parameter
-BOARD_KERNEL_CMDLINE and configure the video setting.
-Example setting for a 24" monitor is video=HDMI-A-1:1280x800@60.
-
    
-
-
    HiKey boards
    
-
-
    The HiKey board (also known as HiKey620) is available in
-1GB RAM
-and 2GB
-RAM configurations from Lenovator:
-
    
-
-HiKey620 board image
-
    Figure 2. HiKey board by Lenovator
    
-
-
    Additional resources:
    
-
-
-
    Use the following commands to download, build, and run Android on the HiKey
-board.
    
-
-
    Compiling userspace
    
-
      
-  
    1. Download the Android source tree:
-
      -repo init -u https://android.googlesource.com/platform/manifest -b master
-repo sync -j24
-
      
-  
      2. 
-  
    2. Download and extract HDMI binaries into the Android source tree:
-
      -wget https://dl.google.com/dl/android/aosp/linaro-hikey-20170523-4b9ebaff.tgz
-tar xzf linaro-hikey-20170523-4b9ebaff.tgz
-./extract-linaro-hikey.sh
-
      
-  
      3. 
-  
    3. Install mcopy utility:
-
      -apt-get install mtools
-
      
-  
      4. 
-  
    4. Build:
-
      -. ./build/envsetup.sh
-lunch hikey-userdebug
-make -j32
-
      
-  
      5. 
-
    
-
-
    Note: For 4GB eMMC, instead of $ make -j32
-use: $ make -j32 TARGET_USERDATAIMAGE_4GB=true.
    
-
-
    Installing initial fastboot and ptable
    
-
      
-  
    1. Select special bootloader mode by linking J15 1-2 and 3-4 pins (for details,
-refer to the
-HiKey
-user guide).
      2. 
-  
    2. Connect USB to PC to get ttyUSB device (ex: /dev/ttyUSB1).
      3. 
-  
    3. Power the board:
-
      -cd device/linaro/hikey/installer/hikey
-./flash-all.sh /dev/ttyUSB1 [4g]
-
      
-  
      4. 
-  
    4. Remove jumper 3-4 and power the board.
      5. 
-
    
-
-
    Flashing images
    
-
      
-  
    1. Enter fastboot mode by linking J15 1-2 and 5-6 pins.
      2. 
-  
    2. Run the following commands:
-
      -fastboot flash boot out/target/product/hikey/boot.img
-fastboot flash -w system out/target/product/hikey/system.img
-
      
-  
      3. 
-  
    3. Remove jumper 5-6 and power the board.
      4. 
-
    
-
-
    Building the kernel
    
-
      
-  
    1. Run the following commands:
-
      -git clone https://android.googlesource.com/kernel/hikey-linaro
-cd hikey-linaro
-git checkout -b android-hikey-linaro-4.9 origin/android-hikey-linaro-4.9
-make ARCH=arm64 hikey_defconfig
-make ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- -j24
-
      
-  
      2. 
-  
    2. Copy output to the hikey kernel directory (/kernel/hikey-linaro):
-    
        
-      
      • Copy hi6220-hikey.dtb (arch/arm64/boot/dts/hisilicon/hi6220-hikey.dtb) to the
-hikey-kernel directory as file hi6220-hikey.dtb-4.9.
        • 
-  
      • Copy the Image file (arch/arm64/boot/Image-dtb) to the
-hikey-kernel directory as file Image-dtb-4.9.
        • 
-    
      
-  
    3. Make the boot image:
-
      -make bootimage -j24
-
      
-  
      4. 
-
    
-
-
    Setting monitor resolution
    
-
    Edit device/linaro/hikey/hikey/BoardConfig.mk parameter
-BOARD_KERNEL_CMDLINE and configure the video setting.
-Example setting for a 24" monitor: video=HDMI-A-1:1280x800@60.
    
-
-
    Configuring kernel serial output (uart3)
    
-
    Set the J2 low speed expansion connector to 1 - Gnd, 11 - Rx, 13 - Tx. For
-details, refer to the
-HiKey
-user guide.
    
-
-
    Neonkey SensorHub
    
-
    To develop new ContextHub features that use new sensors or LEDs, you can use
-Neonkey
-SensorHub connected to a Hikey or Hikey960 development board.
    
-
-Neonkey Sensorhub image
-
    Figure 3. Neonkey SensorHub
    
-
-
    Neonkey is a certified 96Boards
-mezzanine base on STM32F411CE with the following components:
    
-
-
      
-
    • Pressure sensor: BMP280
      • 
-
    • ALS/Proximity sensor: RPR-0521RS
      • 
-
    • ARM Hall sensor: MRMS501A
      • 
-
    • LED driver with 15 LEDs: LP3943
      • 
-
    • Accel/Gyro + Geomagnetic sensors: BMI160 + BMM150
      • 
-
    • Temp/Humidity sensor: SI7034-A10
      • 
-
    • 4 GPIO-driven LEDs, I2C expansion, GPIO (2 lines) expansion, JTAG connector
      • 
-
    • NOR Flash: 512KB
      • 
-
    • SRAM: 128 KB, 96boards LS Expansion connector
      • 
-
    
-
-
    Kernel source and ContextHub board support is available in AOSP to help
-developers create and debug new sensors, make new HAL and kernel changes, etc.
-with fewer OEM encumbrances.
    
-
-
    To build, enable, and upload Neonkey:
    
-
-
      
-
    1. Pull AOSP source:
-
      -repo init -u https://android.googlesource.com/platform/manifest -b master & repo sync -j24
-
      
-
      2. 
-
    2. Build:
-
      -. ./build/envsetup.sh
-lunch hikey-userdebug
-. device/google/contexthub/firmware/toolchain-setup.sh
-make -C device/google/contexthub/firmware/variant/neonkey
-adb push device/google/contexthub/firmware/out/nanohub/neonkey/full.bin /data/local/tmp
-
      
-
      3. 
-
    3. To enable Neonkey, enter boot mode using the following method:
-
        
-
      1. Connect BOOT0 to 1V8 (link JTAG P4 1-5 pins)
        2. 
-
      2. Hold USR button
        3. 
-
      3. Push RST button
        4. 
-
      
-
      4. 
-
    4. To upload the firmware:
-
      -adb root
-adb shell stm32_flash -u -d /dev/ttyAMA2 -e 0xffff -w /data/local/tmp/full.bin
-
      
-
      5. 
-
    5. To build userspace HAL:
-
      -make TARGET_SENSOR_MEZZANINE=neonkey -j24
-fastboot flashall
-
      
-
      6. 
-
    
-
-  
-
diff --git a/en/source/downloading.html b/en/source/downloading.html
deleted file mode 100644
index 7599338b..00000000
--- a/en/source/downloading.html
+++ /dev/null
@@ -1,296 +0,0 @@
-
-  
-    Downloading the Source
-    
-    
-  
-  
-  
-
-
-
-
    
-  The Android source tree is located in a Git repository hosted by Google. The Git repository
-  includes metadata for the Android source, including those related to changes to the source
-  and the date they were made. This document describes how to download the source tree for a
-  specific Android code-line.
-
    
-
    
- To instead start with a factory image for a specific device, see
- Selecting a device build.
-
    
-
    
-  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 the Developing section.
-
    
-
    
-  To install Repo:
-
    
-
      
-  
    1. 
-    
      
-      Make sure you have a bin/ directory in your home directory and that it is included in
-      your path:
-    
      
-
      -mkdir ~/bin
-PATH=~/bin:$PATH
-
      
-  
      2. 
-  
    2. 
-    
      
-      Download the Repo tool and ensure that it is executable:
-    
      
-
      -curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
-chmod a+x ~/bin/repo
-
      
-  
      3. 
-
    
-
    
-  For version 1.21, the SHA-1 checksum for repo is b8bd1804f432ecf1bab730949c82b93b0fc5fede
-
    
-
    
-  For version 1.22, the SHA-1 checksum for repo is da0514e484f74648a890c0467d61ca415379f791
-
    
-
    
-  For version 1.23, the SHA-256 checksum for repo is e147f0392686c40cfd7d5e6f332c6ee74c4eab4d24e2694b3b0a0c037bf51dc5
-
    
-
    
-  Initializing a Repo client
-
    
-
    
-  After installing Repo, set up your client to access the Android source repository:
-
    
-
      
-  
    1. 
-    
      
-      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
-
      
-  
      2. 
-  
    2. 
-    
      
-      Configure git 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. 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.
-    
      
-
      -git config --global user.name "Your Name"
-git config --global user.email "you@example.com"
-
      
-  
      3. 
-  
    3. 
-    
      
-      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. For a list of branches, see Source Code Tags and Builds.
-    
      
-
      -repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
-
      
-  
      4. 
-
    
-
    
-  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.
-
    
-
    
-  Downloading the Android Source Tree
-
    
-
    
-  To pull down the Android source tree 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 the Developing section.
-
    
-
    
-  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 with the password generator
-  and follow the instructions on the password generator 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. Notice the --mirror flag, which
-  can be specified only 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 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 yet, now would be a good
-  time to do it.
-
    
-
-  
-
diff --git a/en/source/faqs.html b/en/source/faqs.html
deleted file mode 100644
index ff301ea8..00000000
--- a/en/source/faqs.html
+++ /dev/null
@@ -1,328 +0,0 @@
-
-  
-    Frequently Asked Questions
-    
-    
-  
-  
-  
-
-
-
-
-
    Please see the Android FAQs on
-developer.android.com for answers to other common questions.
-
-
    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 you can use to build
-mobile phones 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 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 there was no
-central point of failure, so 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.
    
-
    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 on our Licenses page.
    
-
    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 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 great
-devices running Android actually make it to market.
    
-
    By making sure Android is a success with 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. Of course, no
-one is required to participate. 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 aim to release great devices into a competitive marketplace. We
-then incorporate the innovations and enhancements we made into the core
-platform as the next version.
    
-
    In practice, this means 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 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 Codelines,
-Branches and Releases page.
    
-
    Why are parts of Android developed in private?
    
-
    It typically takes more than a year to bring a device to market. And, of course,
-device manufacturers want to ship the latest software they can. Developers,
-meanwhile, don't want 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. This allows developers
-and OEMs to use a single version without tracking 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. Releasing the source code is a fairly complex process.
-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 prior to the
-device's release; however in other releases, 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.
    
-
    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.
    
-
    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 making final API changes,
-updating documentation (to reflect any modifications 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 intellectual property ownership of their
-contribution, Google too must verify it is clear to make contributions.
    
-
    From the time mass production begins, the software release process
-usually takes around a month. This often places source code releases
-around the same time 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 develop 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 to 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 encourages applications to be run
-in the ART runtime. Similarly, 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 channels listed on the 
-Android Community page prior to beginning any work. You can find more
-information on this topic from the 
-Contributing 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 page.
    
-Back to top
-
    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, enabling their 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 many 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 all phones to 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,
-version 1.6 of the CDD supports only cell phones. But the 2.1 CDD allows devices
-to omit telephony hardware, enabling 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 complete the contact form included in licensing Google Mobile
-Services to seek access to Google Play. We will be in contact if we can
-help you.
    
-
    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,
-Gmail, and more, 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 manufacturers
-wish to use the Android name with their products, or want access to Google Play,
-they must first demonstrate their devices are 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 for device testing.
    
-
    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 various 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 determines 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) do 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.
    
-Back to top
-
    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.
    
-
    Are codecs verified by CTS?
    
-
    Yes. All mandatory codecs are verified by CTS.
    
-
-Back to top
-
-  
-
diff --git a/en/source/git-resources.html b/en/source/git-resources.html
deleted file mode 100644
index 4d5530d0..00000000
--- a/en/source/git-resources.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  
-    Learning Git
-    
-    
-  
-  
-  
-
-
-
    For further information on Git, check out these excellent off-site resources:
    
-
-
-  
-
diff --git a/en/source/images/8100-TM-example.png b/en/source/images/8100-TM-example.png
deleted file mode 100644
index b347e6cc..00000000
Binary files a/en/source/images/8100-TM-example.png and /dev/null differ
diff --git a/en/source/images/Android_Robot_100.png b/en/source/images/Android_Robot_100.png
deleted file mode 100644
index 946ee3ab..00000000
Binary files a/en/source/images/Android_Robot_100.png and /dev/null differ
diff --git a/en/source/images/JB-TM-example.png b/en/source/images/JB-TM-example.png
deleted file mode 100644
index 0df3c6d0..00000000
Binary files a/en/source/images/JB-TM-example.png and /dev/null differ
diff --git a/en/source/images/No_PeaceBot_200.jpg b/en/source/images/No_PeaceBot_200.jpg
deleted file mode 100644
index 739f9682..00000000
Binary files a/en/source/images/No_PeaceBot_200.jpg and /dev/null differ
diff --git a/en/source/images/XBrand-TM-example.jpg b/en/source/images/XBrand-TM-example.jpg
deleted file mode 100644
index 8a3ab590..00000000
Binary files a/en/source/images/XBrand-TM-example.jpg and /dev/null differ
diff --git a/en/source/images/android_logo_new_crossed_out.png b/en/source/images/android_logo_new_crossed_out.png
deleted file mode 100644
index 646935ee..00000000
Binary files a/en/source/images/android_logo_new_crossed_out.png and /dev/null differ
diff --git a/en/source/images/android_logo_old_crossed_out.png b/en/source/images/android_logo_old_crossed_out.png
deleted file mode 100644
index a256d938..00000000
Binary files a/en/source/images/android_logo_old_crossed_out.png and /dev/null differ
diff --git a/en/source/images/hikey-board.png b/en/source/images/hikey-board.png
deleted file mode 100644
index be8d715d..00000000
Binary files a/en/source/images/hikey-board.png and /dev/null differ
diff --git a/en/source/images/hikey620.png b/en/source/images/hikey620.png
deleted file mode 100644
index 1e98aeaa..00000000
Binary files a/en/source/images/hikey620.png and /dev/null differ
diff --git a/en/source/images/hikey960.png b/en/source/images/hikey960.png
deleted file mode 100644
index c69f8f45..00000000
Binary files a/en/source/images/hikey960.png and /dev/null differ
diff --git a/en/source/images/jack_jill.png b/en/source/images/jack_jill.png
deleted file mode 100644
index 445edf4b..00000000
Binary files a/en/source/images/jack_jill.png and /dev/null differ
diff --git a/en/source/images/jack_library.png b/en/source/images/jack_library.png
deleted file mode 100644
index bf0361b9..00000000
Binary files a/en/source/images/jack_library.png and /dev/null differ
diff --git a/en/source/images/jack_overview.png b/en/source/images/jack_overview.png
deleted file mode 100644
index a315fc20..00000000
Binary files a/en/source/images/jack_overview.png and /dev/null differ
diff --git a/en/source/images/jack_predex.png b/en/source/images/jack_predex.png
deleted file mode 100644
index 25638141..00000000
Binary files a/en/source/images/jack_predex.png and /dev/null differ
diff --git a/en/source/images/mobile-view.png b/en/source/images/mobile-view.png
deleted file mode 100644
index 1b3ff7b8..00000000
Binary files a/en/source/images/mobile-view.png and /dev/null differ
diff --git a/en/source/images/neonkey-sensorhub.png b/en/source/images/neonkey-sensorhub.png
deleted file mode 100644
index 61f4e22b..00000000
Binary files a/en/source/images/neonkey-sensorhub.png and /dev/null differ
diff --git a/en/source/index.html b/en/source/index.html
deleted file mode 100644
index 3728eb2f..00000000
--- a/en/source/index.html
+++ /dev/null
@@ -1,81 +0,0 @@
-
-  
-    The Android Source Code
-    
-    
-  
-  
-  
-
-
-
    
-Android is an open source software stack created for a wide array of devices
-with different form factors. The primary purposes of Android are to create an
-open software platform available for carriers, OEMs, and developers to make
-their innovative ideas a reality and to introduce a successful,
-real-world product that improves the mobile experience for users.
-
    
-
-
    
-We also wanted to make sure 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 with source code open for customization and porting.
-
    
-
-
    
-  Android framework details
-  
    
-    Figure 1. Android stack
-  
    
-
    
-
-
    Governance Philosophy
    
-
    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. These companies have
-allocated significant engineering resources to improve Android and bring Android
-devices to market.
-
    
-
    The companies that have invested in Android have done so on its merits
-because we believe an open platform is necessary. Android is
-intentionally and explicitly an open source -- as opposed to a 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 Android Open Source Project 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 legitimate uses. However, in order to take part in the shared
-ecosystem of applications we are building around Android, device builders
-must participate in the Android Compatibility Program.
    
-
-
    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.
    
-
-  
-
diff --git a/en/source/initializing.html b/en/source/initializing.html
deleted file mode 100644
index 662862be..00000000
--- a/en/source/initializing.html
+++ /dev/null
@@ -1,460 +0,0 @@
-
-  
-    Establishing a Build Environment
-    
-    
-  
-  
-  
-
-
    This section describes how to set up your local work environment to build
-the Android source files. You will need to use Linux or Mac OS. Building under
-Windows is not currently supported.
    
-
    For an overview of the entire code-review and code-update process, see Life of a Patch.
    
-
    Note: All commands in this site are preceded
-by a dollar sign ($) to differentiate them from output or entries within files.
-You may use the Click to copy feature at the top right of each command
-box to copy all lines without the dollar signs or triple-click each line to
-copy it individually without the dollar sign.
    
-
    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 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 (14.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: See the Requirements for the complete list of hardware and
-software requirements. Then follow the detailed instructions for Ubuntu and Mac
-OS below.
    
-
-
    Installing the JDK
    
-
    The master branch of Android in the Android Open Source Project (AOSP)
-comes with a prebuilt version of OpenJDK in
-platform/prebuilts/jdk/jdk8. So no additional installation is
-required.
    
-
-
    Older versions of Android require a separate installation of the JDK. On
-Ubuntu, use OpenJDK. See  JDK Requirements for precise versions and the
-sections below for instructions.
    
-
-
    For Ubuntu >= 15.04
    
-
    Run the following:
    
-
    -sudo apt-get update
-sudo apt-get install openjdk-8-jdk
-
    
-
-
    For Ubuntu LTS 14.04
    
-
    There are no available supported OpenJDK 8 packages for Ubuntu 14.04. The
-Ubuntu 15.04 OpenJDK 8 packages have been used successfully
-with Ubuntu 14.04. Newer package versions (e.g. those for 15.10, 16.04) were
-found not to work on 14.04 using the instructions below.
    
-
      
-
    1. 
-
      Download the .deb packages for 64-bit architecture from
-archive.ubuntu.com:
      
-
-
      2. 
-
    2. 
-
      Optionally, confirm the checksums of the downloaded files against the SHA256
-string listed with each package above.
      
-
      For example, with the sha256sum tool:
      
-
      -sha256sum {downloaded.deb file}
-
      
-
      3. 
-
    3. 
-
      Install the packages:
      
-
      -sudo apt-get update
-
      
-
      Run dpkg for each of the .deb files you downloaded. It may produce errors due to
-missing dependencies:
      
-
      -sudo dpkg -i {downloaded.deb file}
-
      
-
      To fix missing dependencies:
      
-
      -sudo apt-get -f install
-
      
-
      4. 
-
    
-
-
    Update the default Java version - optional
    
-
-
    Optionally, for the Ubuntu versions above update the default Java version by
-running:
    
-
    -sudo update-alternatives --config java
-sudo update-alternatives --config javac
-
    
-
-
    If, during a build, you encounter version errors for Java, set its
-path as described in the Wrong
-Java Version section.
    
-
-
    Installing required packages (Ubuntu 14.04)
    
-
-
    You will need a 64-bit version of Ubuntu. Ubuntu 14.04 is recommended.
    
-
-
    -sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip
-
    
-
-
    Note: To use SELinux tools for policy
-analysis, also install the python-networkx package.
    
-
-
    Note: If you are using LDAP and want
-to run ART host tests, also install the libnss-sss:i386
-package.
    
-
-
    Installing required packages
-(Ubuntu 12.04)
    
-
-
    You may use Ubuntu 12.04 to build older versions of Android. Version 12.04
-is not supported on master or recent releases.
    
-
-
    -sudo apt-get install git gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
-sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
-
    
-
-
    Installing required
-packages (Ubuntu 10.04 -- 11.10)
    
-
    Building on Ubuntu 10.04-11.10 is no longer supported, but may be useful for
-building older releases of AOSP.
    
-
-
    -sudo apt-get install git 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
-
    
-
-
    Configuring USB Access
    
-
-
    Install a community-maintained default set of udev rules for
-all Android devices by following the instructions to Set up a device for development.
-
-
    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 build
-environment
    
-
-
    In a default installation, Mac OS 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 Mac OS environment is very straightforward. Earlier
-branches require some additional tools and SDKs.
    
-
-
    Creating a case-sensitive disk image
    
-
-
    You can create a case-sensitive filesystem within your existing Mac OS 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.sparseimage) file which, once mounted, acts as a drive with
-the required formatting for Android development.
    
-
-
    If you need a larger volume later, you can also resize the sparse image with
-the following command:
    
-
-
    -# hdiutil resize -size <new-size-you-want>g ~/android.dmg.sparseimage
-
    
-
-
    For a disk image named android.dmg stored in your home
-directory, you can add helper functions to your ~/.bash_profile:
    
-
-
      
-
    • 
-To mount the image when you execute mountAndroid:
-
-
      -# mount the android file image
-mountAndroid() { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
-
      
-
-
      Note: If your system created a
-.dmg.sparseimage file, replace ~/android.dmg with
-~/android.dmg.sparseimage.
      
-
      • 
-
-
    • 
-
      To unmount it when you execute umountAndroid:
      
-
      -# unmount the android file image
-umountAndroid() { hdiutil detach /Volumes/android; }
-
      
-
      • 
-
    
-
-
    Once you've mounted the android volume, you'll do all your work
-there. You can eject it (unmount it) just like you would with an external
-drive.
    
-
-
    Installing the JDK
    
-
-
    See Requirements for the version of Java to
-use when developing various versions of Android.
    
-
-
    Installing required packages
    
-
-
      
-
    1. 
-
      Install Xcode command line tools with:
-
      -xcode-select --install
-
      
-
-
      For older versions of Mac OS (10.8 or earlier), you need to install Xcode from
-the Apple developer site.
-If you are not already registered as an Apple developer, you will have to
-create an Apple ID in order to download.
      
-
      2. 
-
-
    2. 
-
      Install MacPorts from macports.org.
      
-
-
      Note: Make sure that
-/opt/local/bin appears in your path before
-/usr/bin. If not, please add the following to your
-~/.bash_profile file:
      
-
-
      -export PATH=/opt/local/bin:$PATH
-
      
-
-
      Note: If you do not have a
-.bash_profile file in your home directory, create one.
      
-
      3. 
-
-
    3. 
-
      Get make, git, and GPG packages from MacPorts:
      
-
-
      -POSIXLY_CORRECT=1 sudo port install gmake libsdl git gnupg
-
      
-
-
      If using Mac OS X v10.4, also install bison:
      
-
      -POSIXLY_CORRECT=1 sudo port install bison
-
      
-
      4. 
-
    
-
-
    Reverting from make 3.82
    
-
-
    In Android 4.0.x (Ice Cream Sandwich) and earlier, a bug exists in gmake 3.82
-that prevents android from building. You can install version 3.81 using
-MacPorts with these steps:
    
-
-
      
-
    1. 
-
      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
-
      
-
      2. 
-
-
    2. 
-
      In the new dports directory, run:
      
-
      -svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
-
      
-
      3. 
-
-
    3. 
-
      Create a port index for your new local repository:
      
-
-
      -portindex /Users/Shared/dports
-
      
-
      4. 
-
-
    4. 
-
      Install the old version of gmake with:
      
-
      -sudo port install gmake @3.81
-
      
-
      5. 
-
    
-
-
    Setting a file descriptor limit
    
-
-
    On Mac OS, 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
-
    
-
-
    Optimizing a build environment (optional)
    
-
-
    Setting up ccache
    
-
-
    You can optionally tell the build to use the ccache compilation tool, which
-is a compiler cache for C and C++ that can help make builds faster. It
-is especially useful for build servers and other high-volume production
-environments. Ccache acts as a compiler cache that can be used to speed up rebuilds.
-This works very well if you use make clean often, or if you frequently
-switch between different build products.
    
-
-
    Note: If you're instead conducting incremental
-builds (such as an individual developer rather than a build server), ccache may
-slow your builds down by making you pay for cache misses.
    
-
-
    To use ccache, issue these commands in the root of the source tree:
    
-
-
    -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.
    
-
-
    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 file too.
    
-
-
    On Mac OS, you should replace linux-x86 with darwin-x86:
    
-
-
    -prebuilts/misc/darwin-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.
    
-
-
    On Linux, you can watch ccache being used by doing the following:
    
-
-
    -watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
-
    
-
-
    Next: Download the source
    
-
-
    Your build environment is good to go! Proceed to downloading the source.
    
-
-  
-
diff --git a/en/source/jack.html b/en/source/jack.html
deleted file mode 100644
index 558eef73..00000000
--- a/en/source/jack.html
+++ /dev/null
@@ -1,358 +0,0 @@
-
-  
-    Compiling with Jack
-    
-    
-  
-  
-  
-
-
-
-
    Jack is an Android toolchain that compiles Java source into Android dex
-bytecode. It replaces the previous Android toolchain that consisted of multiple
-tools such as javac, ProGuard, jarjar, and dx. As Jack is the default Android
-build toolchain for Android 6.x, you don’t have to do anything differently to
-use Jack—just use your standard makefile commands to compile the tree or
-your project.
    
-
-
    About Jack
    
-
    The Jack toolchain provides the following advantages:
    
-
-Jack overview
-
    Figure 1. Jack overview.
    
-
-
      
-
    • Completely open source. Jack is available in AOSP and users
-are welcome to contribute.
      • 
-
    • Speeds compilation time. Jack has specific support for
-reducing compilation time using pre-dexing, incremental compilation, and a Jack
-compilation server.
      • 
-
    • Handles shrinking, obfuscation, repackaging, and multidex.
-Using a separate package (such as ProGuard) is no longer necessary.
      • 
-
    
-
-
    As of Android 7.0, Jack supports code coverage with JaCoCo. For details,
-refer to
-Code
-Coverage with JaCoCo and
-Java
-8 Language Features.
    
-
-
    Jack library format
    
-
-
    Jack has its own .jack file format that contains the pre-compiled dex code
-for the library, allowing for faster compilation (pre-dex).
    
-
-Jack library file contents
-
    Figure 2. Jack library file contents.
    
-
-
    Jill
    
-
-
    The Jill tool translates the existing .jar libraries into the new library
-format, as shown below.
    
-
-Importing .jar libraries with Jill
-
    Figure 3. Workflow to import an existing .jar
-library.
    
-
-
    Jack compilation server
    
-
-
-
-
    The first time Jack is used, it launches a local Jack compilation server on
-your computer. This server:
    
-
-
      
-
    • Brings an intrinsic speedup because it avoids launching a new host JRE JVM,
-loading Jack code, initializing Jack, and warming up the JIT at each
-compilation. It also provides very good compilation times during small
-compilations (e.g. in incremental mode).
      • 
-
    • Is a short-term solution to control the number of parallel Jack
-compilations. It avoids overloading your computer (memory or disk issue) because
-it limits the number of parallel compilations.
      • 
-
    
-
-
    The Jack server shuts itself down after an idle time without any compilation.
-It uses two TCP ports on the localhost interface and is not available
-externally. All parameters (number of parallel compilations, timeout, ports
-number, etc.) can be modified by editing the $HOME/.jack file.
    
-
-
    $HOME/.jack file
    
-
-
    The $HOME/.jack file contains the following settings for Jack
-server variables in a full bash syntax:
    
-
-
      
-
    • SERVER=true. Enable the server feature of Jack.
      • 
-
    • SERVER_PORT_SERVICE=8072. Set the TCP port number of the server
-for compilation purposes.
      • 
-
    • SERVER_PORT_ADMIN=8073. Set the TCP port number of the server
-for admin purposes.
      • 
-
    • SERVER_COUNT=1. Unused.
-
    • SERVER_NB_COMPILE=4. Set the maximum number of allowed parallel
-compilations.
      • 
-
    • SERVER_TIMEOUT=60. Set the number of idle seconds the server
-must wait without any compilation before shutting itself down.
      • 
-
    • SERVER_LOG=${SERVER_LOG:=$SERVER_DIR/jack-$SERVER_PORT_SERVICE.log}.
-Set the file where server logs are written. By default, this variable can be
-overloaded by an environment variable.
      • 
-
    • JACK_VM_COMMAND=${JACK_VM_COMMAND:=java}. Set the default
-command used to launch a JVM on the host. By default, this variable can be
-overloaded by environment variable.
      • 
-
    
-
-
    Troubleshooting Jack compilations
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    ProblemAction
    Your computer becomes unresponsive during compilation or you experience
-Jack compilations failing on “Out of memory error”You can improve the situation by reducing the number of simultaneous Jack
-compilations by editing $HOME/.jack and changing
-SERVER_NB_COMPILE to a lower value.
    Compilations are failing on “Cannot launch background server”The most likely cause is TCP ports are already used on your computer. Change
-ports by editing $HOME/.jack (SERVER_PORT_SERVICE and
-SERVER_PORT_ADMIN variables).
-
-

    If it doesn’t solve the problem, report the error (be sure to attach
-your compilation log and the Jack server log). To
-unblock the situation, disable the Jack compilation server by editing
-$HOME/.jack and changing SERVER to false.
-Unfortunately this will significantly slow down your compilation and may force
-you to launch make -j with load control (option -l
-of make).
-
    Compilation gets stuck without any progressReport and provide the following information when possible:
-
    
-
      
-
    • Command line at which you are stuck.
      • 
-
    • Output of this command line.
      • 
-
    • Result of executing jack-admin server-stat.
      • 
-
    • $HOME/.jack file.
      • 
-
    • Content of the Jack server log with the server state
-dumped. To get the server log:
- 
        
- 
      • Find the Jack background server process by running
- jack-admin list-server.
        • 
- 
      • Send a kill -3 command to this server to dump its state into
- the log file.
        • 
- 
      
-
      • 
-
    • Result of executing ls -lR $TMPDIR/jack-$USER.
      • 
-
    • Result of running ps j -U $USER.
      • 
-
    
-
-To unblock the situation, kill the Jack background server using
-jack-admin kill-server) then remove the temporary directories
-contained in jack-$USER of your temporary directory
-(/tmp or $TMPDIR).
-
    Other issuesTo report bugs or request features, use the public issue tracker at
-http://b.android.com.
-Use the
-Jack
-tool bug report or
-Jack
-tool feature request templates and remember to attach the Jack log to the
-bug report.
    
-
-
    Finding the Jack log
    
-If you ran a make command with a dist target, the Jack log is
-located at $ANDROID_BUILD_TOP/out/dist/logs/jack-server.log.
-Otherwise, you can find the log by running jack-admin server-log.
-In case of reproducible Jack failures, you can get a more detailed log by
-setting the following variable:
    
-
-
    -export ANDROID_JACK_EXTRA_ARGS="--verbose debug --sanity-checks on -D sched.runner=single-threaded"
-
    
-
-
    Use standard makefile commands to compile the tree (or your project) and
-attach standard output and error. To remove detailed build logs, run:
    
-
-
    -unset ANDROID_JACK_EXTRA_ARGS
-
    
-
-
    Jack limitations
    
-
-
      
-
    • By default, the Jack server is mono-user and can be used by only one user on
-a computer. To support additional users, select different port numbers for each
-user and adjust SERVER_NB_COMPILE accordingly. You can also disable
-the Jack server by setting SERVER=false in
-$HOME/.jack.
      • 
-
    • CTS compilation is slow due to current vm-tests-tf integration.
-
    • Bytecode manipulation tools (such as JaCoCo) are not supported.
      • 
-
    
-
-
    Using Jack
    
-
-
    Jack supports Java programming language 1.7 and integrates the additional
-features described below.
    
-
-
    Predexing
    
-
-
    When generating a Jack library file, the .dex of the library is generated and
-stored inside the .jack library file as a pre-dex. When compiling, Jack reuses
-the pre-dex from each library. All libraries are pre-dexed:
    
-
-Jack libraries with pre-dex
-
    Figure 4. Jack libraries with pre-dex.
    
-
-
    Jack does not reuse the library pre-dex if shrinking, obfuscation, or
-repackaging is used in the compilation.
    
-
-
    Incremental compilation
    
-
-
    Incremental compilation means that only the components touched since the last
-compilation (and their dependencies) are recompiled. Incremental compilation can
-be significantly faster than a full compilation when changes are limited to a
-set of components.
    
-
-
    Incremental compilation is not enabled by default (and is automatically
-deactivated when shrinking, obfuscation, repackaging or multi-dex legacy is
-enabled). To enable incremental builds, add the following line to the
-Android.mk file of the project you want to build incrementally:
    
-
-
    LOCAL_JACK_ENABLED := incremental
    
-
-
-
-
    Shrinking and obfuscation
    
-
-
    Jack uses proguard configuration files to enable shrinking and obfuscation.
    
-
-
    Common options include the following:
    
-
-
      
-  
    •  @
-  
    •  -include
-  
    •  -basedirectory
-  
    •  -injars
-  
    •  -outjars // only 1 output jar supported
-  
    •  -libraryjars
-  
    •  -keep
-  
    •  -keepclassmembers
-  
    •  -keepclasseswithmembers
-  
    •  -keepnames
-  
    •  -keepclassmembernames
-  
    •  -keepclasseswithmembernames
-  
    •  -printseeds
-
    
-
-
    Shrinking options include the following:
    
-
-
      
-  
    • -dontshrink
-
    
-
-
    Obfuscation options include the following:
    
-
-
      
-  
    •  -dontobfuscate
-  
    •  -printmapping
-  
    •  -applymapping
-  
    •  -obfuscationdictionary
-  
    •  -classobfuscationdictionary
-  
    •  -packageobfuscationdictionary
-  
    •  -useuniqueclassmembernames
-  
    •  -dontusemixedcaseclassnames
-  
    •  -keeppackagenames
-  
    •  -flattenpackagehierarchy
-  
    •  -repackageclasses
-  
    •  -keepattributes
-  
    •  -adaptclassstrings
-
    
-
-
    Ignored options include the following:
    
-
-
      
-  
    •  -dontoptimize // Jack does not optimize
-  
    •  -dontpreverify // Jack does not preverify
-  
    •  -skipnonpubliclibraryclasses
-  
    •  -dontskipnonpubliclibraryclasses
-  
    •  -dontskipnonpubliclibraryclassmembers
-  
    •  -keepdirectories
-  
    •  -target
-  
    •  -forceprocessing
-  
    •  -printusage
-  
    •  -whyareyoukeeping
-  
    •  -optimizations
-  
    •  -optimizationpasses
-  
    •  -assumenosideeffects
-  
    •  -allowaccessmodification
-  
    •  -mergeinterfacesaggressively
-  
    •  -overloadaggressively
-  
    •  -microedition
-  
    •  -verbose
-  
    •  -dontnote
-  
    •  -dontwarn
-  
    •  -ignorewarnings
-  
    •  -printconfiguration
-  
    •  -dump
-
    
-
-
-
-
    Repackaging
    
-
-
    Jack uses jarjar configuration files to do repackaging. While Jack is
-compatible with "rule" rule types, it is not compatible with "zap" or
-"keep" rule types. If you need "zap" or "keep" rule types, file a feature
-request with a description of how you use the feature in your app.
    
-
-
    Multidex support
    
-
-
    Jack offers native and legacy multidex support. Since dex files are limited
-to 65K methods, apps with over 65K methods must be split into multiple dex
-files. For more details, refer to
-Building
-Apps with Over 65K Methods.
    
-
-  
-
diff --git a/en/source/known-issues.html b/en/source/known-issues.html
deleted file mode 100644
index e72de555..00000000
--- a/en/source/known-issues.html
+++ /dev/null
@@ -1,78 +0,0 @@
-
-  
-    Source Sync Issues
-    
-    
-  
-  
-  
-
-  
    Even with our best care, small problems sometimes slip in. This page details
-   some known issues you may encounter while trying to sync the Android source code.
-
-
    
-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 transferred.
    
-
    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 (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, enter the command:
    
-
    sysctl -w net.ipv4.tcp_window_scaling=0
    
-
    On MacOS, disable the rfc1323 extension in the network settings.
    
-
-
-  
-
diff --git a/en/source/licenses.html b/en/source/licenses.html
deleted file mode 100644
index a2114a2b..00000000
--- a/en/source/licenses.html
+++ /dev/null
@@ -1,110 +0,0 @@
-
-  
-    Content License
-    
-    
-  
-  
-  
-
-
-
-
    The Android Open Source Project uses a few 
-open source initiative
-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, Version 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 that 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.
    
-
    Contributor License Agreements
    
-
    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 Agreement. The agreement can be executed online through the
-code review tool.
-The agreement 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 Agreement is available.
-This version of the agreement allows a
-corporation to authorize contributions submitted by its designated employees
-and to grant copyright and patent licenses. Note that a Corporate Contributor
-License Agreement does not remove the need for any developer to sign their own
-Individual Contributor License Agreement as an individual. The individual
-agreement is needed to cover any of their contributions that are not
-owned by the corporation signing the Corporate Contributor License Agreement.
    
-
    Please note we based our agreements on the ones the
-Apache Software Foundation uses, which can
-be found on the Apache web site.
    
-
    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, and 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 just that.
    
-
    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.
      • 
-
-
    • 
-
      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 are
-passionate about 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 licensed. However, we love all free
-and open source licenses, and respect others' opinions and preferences. We've
-simply decided ASL2.0 is the right license for our goals.
    
-
-  
-
diff --git a/en/source/life-of-a-bug.html b/en/source/life-of-a-bug.html
deleted file mode 100644
index 571b7cd6..00000000
--- a/en/source/life-of-a-bug.html
+++ /dev/null
@@ -1,151 +0,0 @@
-
-  
-    Life of a Bug
-    
-    
-  
-  
-  
-
-
-
    The Android Open Source Project maintains a public issue tracker where you
-can report bugs and request features for the core Android software stack.
-(For details on this issue tracker, please see the
-Reporting Bugs 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.
    
-
-
    The Android Open Source Project (AOSP) issue tracker is
-intended only for bugs and feature requests related to the core Android
-software stack, and is a technical tool for the Open Source community.
    
-
-
    This is not a customer support forum. For support information, see the
-Nexus and 
-Pixel help centers.
-Support for other devices is provided by the device manufacturers or by the
-carriers selling those devices.
    
-
-
    Support for Google applications is through
-Google's support site. Support
-for third-party applications is with each application's developer, e.g.
-through the contact information provided on Google Play.
    
-
-
    Here's the life of a bug, in a nutshell:
    
-
      
-
    1. A bug is filed, and has the state "New".
      2. 
-
    2. An AOSP maintainer periodically reviews and triages bugs. Bugs are
-triaged into one of four buckets: New, Open, No-Action, or Resolved.
      3. 
-
    3. Each bucket includes a number of states that provide more detail on the
-fate of the issue.
      4. 
-
    4. Bugs marked as "Resolved" will eventually be included in a future
-release of the Android software.
      5. 
-
    
-
-
-
    Bucket details
    
-
    
-We use the Status field in Issue Tracker to specify the status
-of an issue in the resolution process. This is consistent with the definitions
-specified in the Issue
-    Tracker documentation.
-
    
-
    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 maintainer.)
      • 
- 
    • New + Hotlist: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.
-
    
-
      
- 
    • Assigned: The bug report has been recognized as an
- adequately detailed report of a legitimate issue and the bug has been assigned
- to a specific contributor to assess and analyze.
      • 
- 
    • Accepted: The assignee has acknowledged the issue and has
- started to work on it.
      • 
-
    
-
    
-Typically, a bug starts in Assigned, and remains there until
-someone intends to resolve it, at which point it enters
-Accepted. However, note that this isn't a guarantee, and it's
-not uncommon for bugs to go from Assigned 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 a high-quality contribution fixing that
-bug is likely to get accepted. However, it's impossible to guarantee a fix in
-time for any particular release.
-
    
-
    No-Action issues
    
-
    
-This bucket contains bugs that are deemed to not require any action.
-
    
-
      
- 
    • Won't Fix (Not reproducible): 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, or
- there was not enough information to fix the issue.
      • 
- 
    • Won't Fix (Intended behavior): An AOSP maintainer has
- determined that the behavior described isn't a bug, but is the intended
- behavior. This state is also commonly referred to as working as
- intended (WAI). For feature requests, an AOSP maintainer has determined
- that the request is not going to be implemented in Android.
      • 
- 
    • Won't Fix (Obsolete): The issue is no longer relevant due
- to changes in the product.
      • 
- 
    • Won't Fix (Infeasible): The changes that are needed to
- address the issue are not reasonably possible. This status is also used for
- issues reported that cannot be handled in AOSP, typically because it is related
- to a customized device or to an external application, or the reporter mistook
- this tracker as a help forum.
      • 
- 
    • Duplicate: There was already an identical report in the
- issue tracker. Any actual action will be reported on that report.
      • 
-
    
-
    Resolved issues
    
-
    
-This bucket contains bugs that have had action taken, and are now considered
-resolved.
-
    
-
      
- 
    • Fixed (verified): This bug has been fixed, and is included
- in a formal release. When this state is set, we try to also set a property
- indicating which release it was fixed in.
      • 
- 
    • Fixed: This bug has been fixed (or feature implemented) in
- a source tree, but might not yet been included in a formal release.
      • 
-
    
-
    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.
    
-  
-
diff --git a/en/source/life-of-a-patch.html b/en/source/life-of-a-patch.html
deleted file mode 100644
index 6f8d144a..00000000
--- a/en/source/life-of-a-patch.html
+++ /dev/null
@@ -1,38 +0,0 @@
-
-  
-    Life of a Patch
-    
-    
-  
-  
-  
-
-
-
    The Android Open Source Project (AOSP) uses a web-based code review tool
-known as Gerrit.
-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 page.
    
-workflow diagram
-
    
-  Figure 1. Patch workflow
-
    
-
-  
-
diff --git a/en/source/read-bug-reports.html b/en/source/read-bug-reports.html
deleted file mode 100644
index 63ff5cc0..00000000
--- a/en/source/read-bug-reports.html
+++ /dev/null
@@ -1,1018 +0,0 @@
-
-  
-    Reading Bug Reports
-    
-    
-  
-  
-  
-
-
-
-
    Bugs are a reality in any type of development—and bug reports are
-critical to identifying and solving problems. All versions of Android support
-capturing bug reports with Android
-Debug Bridge (adb); Android versions 4.2 and higher support a
-Developer
-Option for taking bug reports and sharing via email, Drive, etc.
    
-
-
    Android bug reports contain dumpsys, dumpstate, and
-logcat data in text (.txt) format, enabling you to easily search
-for specific content. The following sections detail bug report components,
-describe common problems, and give helpful tips and grep commands
-for finding logs associated with those bugs. Most sections also include examples
-for grep command and output and/or dumpsys output.
    
-
-
    Logcat
    
-
    The logcat log is a string-based dump of all logcat
-information. The system part is reserved for the framework and
-has a longer history than main which contains everything else.
-Each line starts with timestamp PID TID log-level.
    
-
-  
-
-
    Viewing the event log
    
-
    This log contains string representations of binary-formatted log messages. It
-is less noisy than the logcat log but also a little harder to read.
-When viewing event logs, you can search this section for specific process ID
-(PID) to see what a process has been doing. The basic format is:
-timestamp PID TID log-level log-tag tag-values.
    
-
-
    Log levels include the following:
    
-
      
-
    • V: verbose
      • 
-
    • D: debug
      • 
-
    • I: information
      • 
-
    • W: warning
      • 
-
    • E: error
      • 
-
    
-
-  
-
     
    
-
    For other useful event log tags, refer to
-/services/core/java/com/android/server/EventLogTags.logtags.
    
-
-
    ANRs and deadlocks
    
-
    Bugreports can help you identify what's causing
-Application
-Not Responding (ANR) errors and deadlock events.
    
-
-
    Identifying unresponsive apps
    
-
    When an application does not respond within a certain time, usually due to a
-blocked or busy main thread, the system kills the process and dumps the stack to
-/data/anr. To discover the culprit behind an ANR, grep for
-am_anr in the binary event log.
    
-
-  
-
-
    
-
    You can also grep for ANR in in the logcat log,
-which contains more information about what was using CPU at the time of the ANR.
-
    
-
-  
-
-
    Finding stack traces
    
-
    You can often find stack traces that correspond to an ANR. Make sure the
-timestamp and PID on the VM traces match the ANR you are investigating, then
-check the main thread of the process. Keep in mind:
    
-
      
-
    • The main thread tells you only what the thread was doing at the time of the
-ANR, which may or may not correspond to the true cause of the ANR. (The stack in
-the bug report may be innocent; something else may have been stuck for a long
-time—but not quite long enough to ANR—before becoming unstuck.)
-
      • 
-
    • More than one set of stack traces (VM TRACES JUST NOW and
-VM TRACES AT LAST ANR) might exist. Make sure you are viewing the
-correct section.
      • 
-
    
-
-  
-
-
    Finding deadlocks
    
-
    Deadlocks often first appear as ANRs because threads are getting stuck. If
-the deadlock hits the system server, the watchdog will eventually kill it,
-leading to an entry in the log similar to:
-WATCHDOG KILLING SYSTEM PROCESS. From the user perspective, the
-device reboots, although technically this is a runtime restart rather than a
-true reboot.
    
-
-
      
-
    • In a runtime restart, the system server dies and is
-restarted; the user sees the device return to the boot animation.
      • 
-
    • In a reboot, the kernel has crashed; the user sees the
-device return to the Google boot logo.
      • 
-
    
-
-
    To find deadlocks, check the VM traces sections for a pattern of thread A
-waiting on something held by thread B, which in turn is waiting on something
-held by thread A.
    
-
-  
-
-
-
    Activities
    
-
    An Activity
-is an application component that provides a screen users interact with to do
-something such as dial a number, take a photo, send an email, etc. From a bug
-report perspective, an
-activity
-is a single, focused thing a user can do, which makes locating the activity that
-was in focus during a crash very important. Activities (via ActivityManager)
-run processes, so locating all process stops and starts for a given activity can
-also aid troubleshooting.
    
-
-
    Viewing focused activities
    
-
    To view a history of focused activities, search for
-am_focused_activity.
    
-
-  
-
-
    Viewing process starts
    
-
    To view a history of process starts, search for Start proc.
    
-
-  
-
-
    Is the device thrashing?
    
-
    To determine if the device is
-thrashing,
-check for an abnormal increase in activity around am_proc_died and
-am_proc_start in a short amount of time.
    
-
-  
-
-
    Memory
    
-
    Because Android devices often have constrained physical memory, managing
-random-access memory (RAM) is critical. Bug reports contain several indicators
-of low memory as well as a dumpstate that provides a memory snapshot.
    
-
-
    Identifying low memory
    
-
    Low memory can cause the system to thrash as it kills some processes to free
-memory but continues to start other processes. To view corroborating evidence of
-low memory, check for concentrations of am_proc_died and
-am_proc_start entries in the binary event log.
    
-
-
    Low memory can also slow task switching and thwart return attempts (because
-the task the user was trying to return to was killed). If the launcher was
-killed, it restarts when the user touches the home button and logs show the
-launcher reload its content.
    
-
-
    Viewing historical indicators
    
-
    The am_low_memory entry in the binary event log indicates the
-last cached process has died. After this, the system starts killing services.
-
-  
    
-
-
    Viewing thrashing indicators
    
-
    Other indicators of system thrashing (paging, direct reclaim, etc.) include
-kswapd, kworker, and mmcqd consuming
-cycles. (Keep in mind the bugreport being gathered can influence thrashing
-indicators.)
    
-
-  
-
    
-
-
    ANR logs can provide a similar memory snapshot.
    
-
-  
-
-
    Getting a memory snapshot
    
-
    The memory snapshot is a dumpstate that lists running Java and native
-processes (for details, refer to
-Viewing
-Overall Memory Allocations). Keep in mind the snapshot gives only the state
-at a specific moment in time; the system might have been in better (or worse)
-shape before the snapshot.
    
-
-
-  
-
-
    Broadcasts
    
-
    Applications generate broadcasts to send events within the current
-application or to another application. Broadcast receivers subscribe to specific
-messages (via filters), enabling them to both listen and respond to a broadcast.
-Bug reports contain information about sent broadcasts and unsent broadcasts, as
-well as a dumpsys of all receivers listening to a specific broadcast.
    
-
-
    Viewing historical broadcasts
    
-
    Historical broadcasts are those that have already been sent, listed in
-reverse chronological order.
    
-
-
    The summary section is an overview of the last 300
-foreground broadcasts and the last 300 background broadcasts.
    
-
-  
-
    
-
-
    The detail section contains complete information for the
-last 50 foreground broadcasts and the last 50 background broadcasts, as well as
-the receivers for each broadcast. Receivers that have a:
    
-
      
-
    • BroadcastRecord entry are registered at runtime and are sent
-only to already running processes.
      • 
-
    • ResolveInfo entry are registered through manifest entries. The
-ActivityManager starts the process for each ResolveInfo if it is
-not already running.
      • 
-
    
-
-  
-
-
    Viewing active broadcasts
    
-
    Active broadcasts are those that have yet to be sent. A large number in the
-queue means the system can't dispatch the broadcasts fast enough to keep up.
    
-
-  
-
-
    Viewing broadcast listeners
    
-
    To view a list of receivers listening for a broadcast, check the Receiver
-Resolver Table in the dumpsys activity broadcasts. The following
-example displays all receivers listening for USER_PRESENT.
    
-
-  
-
-
    Monitor contention
    
-
    Monitor contention logging can sometimes indicate actual monitor contention,
-but most often indicates the system is so loaded that everything has slowed down.
-You might see long monitor events logged by ART in system or event log.
    
-
-
    In the system log:
    
-
    10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s
    
-
-
    In the event log:
    
-
    10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]
    
-
-
    Background compilation
    
-
    Compilation can be expensive and load the device.
    
-
-  
-
    
-
-
    Compilation might occur in the background when Google Play store updates are
-downloading. In this case, messages from the Google Play store app
-(finsky) and installd appear prior to
-dex2oat messages.
    
-
-  
-
    
-
-
    Compilation might also occur in the background when an application is loading
-a dex file that has not yet been compiled. In this case, you won't see
-finsky or installd logging.
    
-
-  
-
-
    Narrative
    
-
    Establishing the narrative of a problem (how it started, what happened, how
-the system reacted) requires a solid timeline of events. You can use the
-information in the bug report to sync timelines across multiple logs and
-determine the exact timestamp of the bug report.
    
-
-
    Syncing timelines
    
-
    A bugreport reflects multiple parallel timelines: system log, event log,
-kernel log, and multiple specialized timelines for broadcasts, battery stats,
-etc. Unfortunately, timelines are often reported using different time bases.
    
-
-
    The system and event log timestamps are in the same timezone as the user (as
-are most other timestamps). For example, when user taps the home button, the
-system log reports:
    
-
    10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0
    
-
-
    For the same action, the event log reports:
    
-
    10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
    
-
-
    Kernel (dmesg) logs use a different time base, tagging log items
-with seconds since bootloader completes. To register this timescale to other
-timescales, search for suspend exit and suspend entry messages:
    
-
    <6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
-…
-<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC
    
-
-
    Because kernel logs might not include time while in suspend, you should
-piecewise register the log between the suspend entry and exit messages.
-Additionally, kernel logs use UTC timezone and must be adjusted to the user
-timezone.
    
-
-
    Identifying bugreport time
    
-
    To determine when a bugreport was taken, first check the system log (Logcat)
-for the dumpstate: begin:
    
-
    10-03 17:19:54.322 19398 19398 I dumpstate: begin
    
-
-
    Next, check the kernel log (dmesg) timestamps for the Starting service
-'bugreport' message:
    
-
    <5>[207064.285315] init: Starting service 'bugreport'...
    
-
-
    Work backwards to correlate the two events, keeping in mind the caveats
-mentioned in Syncing timelines. While there's a lot
-happening after the bugreport is initiated, most activity isn't very useful as
-the act of taking the bugreport loads the system substantially.
    
-
-
    Power
    
-
-
    The event log contains screen power status, where 0 is screen off, 1 is
-screen on, and 2 is for keyguard done.
    
-
-  
-
-
    
-
    Bug reports also contain statistics about wake locks, a mechanism used by
-application developers to indicate their application needs to have the device
-stay on. (For details on wake locks, refer to
-PowerManager.WakeLock
-and Keep
-the CPU on.)
-
-
    The aggregated wake lock duration statistics track only the
-time a wake lock is actually responsible for keeping the device awake and
-do not include time with the screen on. In addition, if
-multiple wake locks are held simultaneously, the wake lock duration time is
-distributed across those wake locks.
    
-
-
    For more help visualizing power status, use
-Battery Historian, a
-Google open source tool to analyze battery consumers using Android bugreport
-files.
    
-
-
    Packages
    
-
    The DUMP OF SERVICE package contains application versions (and other useful
-info).
    
-
-  
-
-
    Processes
    
-
    Bug reports contain a huge amount of data for processes, including start and
-stop time, runtime length, associated services, oom_adj score, etc.
-For details on how Android manages processes, refer to
-Processes
-and Threads.
    
-
-
    Determining process runtime
    
-
    The procstats section contains complete statistics on how long
-processes and associated services have been running. For a quick, human-readable
-summary, search for AGGREGATED OVER to view data from either the
-last three or 24 hours, then search for Summary: to view the list
-of processes, how long those processes have run at various priorities, and their
-RAM usage formatted as min-average-max PSS/min-average-max USS.
    
-
-  
-
-
    Why is a process running?
    
-
    The dumpsys activity processes section lists all currently
-running processes ordered by oom_adj score (Android indicates
-process importance by assigning the process an oom_adj value, which
-can be dynamically updated by ActivityManager). The output is similar to that of
-a memory snapshot but includes additional
-information about what is causing the process to run. In the example below,
-the bolded entries indicate the gms.persistent process is running
-at vis (visible) priority because the system process is bound to
-its NetworkLocationService.
    
-
-  
-
-
    Scans
    
-
    Use the following steps to identify applications performing excessive
-Bluetooth Low Energy (BLE) scans:
    
-
      
-
    • Find log messages for BluetoothLeScanner:
-
      -$ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
-07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
-
      • 
-
    • Locate the PID in the log messages. In this example, "24840" and
-"24851" are PID (process ID) and TID (thread ID).
      • 
-
    • Locate the application associated with the PID:
-
      -PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
-
      
-
      In this example, the package name is com.badapp.
      • 
-
    • Look up the package name on Google Play to identify the responsible
-application:
-https://play.google.com/store/apps/details?id=com.badapp.
      • 
-
    
-
    Note: For devices running Android 7.0, the
-system collects data for BLE scans and associates these activities
-with the initiating application. For details, see
-Low Energy (LE)
-and Bluetooth scans.
    
-
-  
-
diff --git a/en/source/report-bugs.html b/en/source/report-bugs.html
deleted file mode 100644
index 848a50d9..00000000
--- a/en/source/report-bugs.html
+++ /dev/null
@@ -1,314 +0,0 @@
-
-  
-    Reporting Bugs
-    
-    
-  
-  
-  
-
    
-Thank you for your interest in Android! You can help improve Android by
-reporting issues and feature requests in the
-Android Issue Tracker. The Android Issue Tracker
-contains a list of pending technical tasks across a variety of topics,
-information relevant to those tasks, and information about progress on those
-tasks, including which ones might get worked on in the short term.
-
    
-
    For more information about why we switched to Issue Tracker, see this
-blog post.
    
-
    
-Issue Tracker is not a customer support forum. For support information, see the
-Nexus and
-Pixel help centers. Support for
-other devices is provided by the device manufacturers or by the carriers selling
-those devices.
-
    
-
    
-Support for Google applications is through
-Google's support site. Support for
-third-party applications is provided by the application's developer, e.g.
-through the contact information provided on Google Play. For a list of more
-Android support resources, see our Community page.
-
    
-
    
-There are no guarantees 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.
-
    
-
    Filing a bug
    
-
      
-
    1. Search
-for your bug to see if anyone has already reported it. Don't forget to
-search for all issues, not just open ones, as your issue might already have been
-reported and closed. To help you find the most popular results, sort the result
-by number of stars.
      2. 
-
    2. If you find your issue and it's important to you,
-star
-it! The number of
-stars on a bug helps us know which bugs are most important to fix.
      3. 
-
    3. If no one has reported your bug, file the bug. First,
-browse for the correct
-component, such as Framework
-or Networking,
-and fill out the provided template. Or select the desired bug queue from the
-tables below.
-
      
-Tip: Some components contain sub-components, like Network >
-Messaging and Framework > Storage.
-
      
-
      4. 
-
    4. Include as much information in bugs as you can, following the instructions
-for the bug queue you're targeting. A bug that simply says something isn't
-working doesn't help much, and will probably be closed without any action. The
-amount of detail you provide, such as log files, repro steps, and even a patch
-set, helps us address your issue.
      5. 
-
    
-
    Bug queues
    
-
    
-The Android Issue Tracker has a variety of sub-components in a number of
-categories related to Android. There are subcomponents for security, the
-platform, Android Developer Tools, documentation, and more.
-
    
-
-
    Security
    
-
    
-If you find an issue that impacts the security of Android or components in Nexus
-or Pixel devices, follow the instructions
-here.
-Additionally, security bugs are eligible for the
-Android
-Security Vulnerability Rewards Program.
-
    
-
    
-Because of the sensitive nature of security bugs, you won't be able to browse
-open issues, only closed issues or issues that have been made public.
-
    
-
-
-
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-
    Browse bugsDetailsFile a bug
    SecurityAndroid Security details
-   bug_report
    
-
-
    Platform
    
-
    
-If you find an issue that impacts an aspect of the Android platform, file your
-bug in one of these components.
-
    
-
    Browse all platform issues
    
-
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-
    Browse bugsFile a bug
    ARTbug_report
    Browserbug_report
    CTSbug_report
    Frameworkbug_report
    GfxMediabug_report
    Instant Appsbug_report
    Jackbug_report
    Libcorebug_report
    Networkingbug_report
    Securitybug_report
    Systembug_report
    Textbug_report
    Thingsbug_report
    Wearbug_report
    
-
-
    Android Developer Tools
    
-
    
-If you find an issue that impacts one of the Android Developer tools, such as
-Android Studio, SDK, Emulator, System Images, or Support Library, file a bug in
-one of these components.
-
    
-
    
-As the tools have different requirements, read the
-General Bug filing
-details and the linked details for the tool.
-
    
-
-Browse all
-Developer Tools issues
-
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-
    Browse bugsDetailsFile a bug
    Android
-StudioAndroid
-Studio details
-   bug_report
    C++Issues in Android Studio
-   bug_report
    Emulator or
-System ImagesEmulator
-    details
-   bug_report
    GradleGradle
-   details
-   bug_report
    Instant
-RunInstant
-   Run details
-   bug_report
    Lint
-   bug_report
    NDKStandalone NDK issuesbug_report
    Profilers
-   bug_report
    Support
-Library
-   bug_report
    Test
-Support Library 
-   bug_report
    
-
-
    Documentation
    
-
    
-If you find an issue with this site or with
-developer.android.com,
-file a bug and a writer will help.
-
    
-
-
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
-
    Browse bugsFile a bug
    developer.android.com
-   bug_report
    source.android.com
-   bug_report
    
-
- 
-
diff --git a/en/source/requirements.html b/en/source/requirements.html
deleted file mode 100644
index d8351e58..00000000
--- a/en/source/requirements.html
+++ /dev/null
@@ -1,173 +0,0 @@
-
-  
-    Requirements
-    
-    
-  
-  
-  
-
-
-
-
    Before you download and build the Android source, ensure your system meets
-  the following requirements. Then see Establishing a
-  Build Environment for installation instructions by operating system.
    
-
-
    Hardware requirements
    
-
-
    Your development workstation should meet or exceed these hardware requirements:
    
-
-
      
-
-  
    • 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.
-  
      • 
-
-  
    • At least 100GB of free disk space to checkout the code and an extra 150GB
-  to build it. If you conduct multiple builds or employ ccache, you will need
-  even more space.
      
-  
      • 
-
-  
    • If you are running Linux in a virtual machine, you need at
-  least 16GB of RAM/swap.
-  
      • 
-
-
    
-
-
    Software requirements
    
-
-
    The Android Open Source Project
-  (AOSP) master branch is traditionally developed and tested
-  on Ubuntu Long Term Support (LTS) releases, but other distributions may be
-  used. See the list below for recommended versions.
    
-
-
    You workstation must have the software listed below. See Establishing a Build Environment for
-  additional required packages and the commands to install them.
    
-
-
    OS and JDK
    
-
-
    If you are developing against the AOSP master branch, use one
-of these operating systems: Ubuntu 14.04 (Trusty) or Mac OS v10.10 (Yosemite)
-or later with Xcode 4.5.2 and Command Line Tools.
    
-
-
    For the Java Development Kit (JDK), note the master branch of
-Android in AOSP comes with a prebuilt version of OpenJDK; so no additional
-installation is required. Older versions require a separate install.
    
-
-
    See Packages for older versions.
-
-
    Key packages
    
-  
-
-
    Device binaries
    
-
    Download previews, factory images, drivers, over-the-air (OTA) updates, and
-other blobs below. See Obtaining
-  proprietary binaries for additional details.
    
-  
-
-  
    Build toolchain
    
-
-  
    Android 8.0 and later support only Clang/LLVM
- for building the Android platform. Join the android-llvm
- group to pose questions and get help. Report NDK/compiler issues at the NDK GitHub.
    
-
-
    For the
-Native
-Development Kit (NDK) and legacy kernels, GCC 4.9 included
-in the AOSP master branch (under prebuilts/) may also be used.
    
-
-
    Packages for older versions
    
-
-
    The sections below provide relevant operating systems and JDK packages for
-older versions of Android.
    
-
-
    Operating system
    
-
-
    Android is typically built with a GNU/Linux or Mac OS operating system. It is
-  also possible to build Android in a virtual machine on unsupported systems such
-  as Windows.
    
-
-  
    GNU/Linux
    
-
-  
      
-    
    • Android 6.0 (Marshmallow) - AOSP master: Ubuntu 14.04 (Trusty)
      • 
-    
    • Android 2.3.x (Gingerbread) - Android 5.x (Lollipop): Ubuntu 12.04 (Precise)
      • 
-    
    • Android 1.5 (Cupcake) - Android 2.2.x (Froyo): Ubuntu 10.04 (Lucid)
      • 
-  
    
-
-
    Mac OS (Intel/x86)
    
-
-  
      
-    
    • Android 6.0 (Marshmallow) - AOSP master: Mac OS v10.10 (Yosemite) or
-    later with Xcode 4.5.2 and Command Line Tools
      • 
-    
    • Android 5.x (Lollipop): Mac OS v10.8 (Mountain Lion) with Xcode 4.5.2
-    and Command Line Tools
      • 
-    
    • Android 4.1.x-4.3.x (Jelly Bean) - Android 4.4.x (KitKat): Mac OS v10.6
-    (Snow Leopard) or Mac OS X v10.7 (Lion) and Xcode 4.2 (Apple's Developer
-    Tools)
      • 
-    
    • Android 1.5 (Cupcake) - Android 4.0.x (Ice Cream Sandwich): Mac OS
-    v10.5 (Leopard) or Mac OS X v10.6 (Snow Leopard) and the Mac OS X v10.5
-    SDK
      • 
-  
    
-
-
    JDK
    
-
-
    See Installing the JDK
-for the prebuilt path and installation instructions for older versions.
    
-  
-
-  
    Make
    
-  
     Android 4.0.x (Ice Cream Sandwich) and earlier will need to revert from make 3.82
-  to avoid build errors
    .
-
-  
-
diff --git a/en/source/roles.html b/en/source/roles.html
deleted file mode 100644
index 39f48794..00000000
--- a/en/source/roles.html
+++ /dev/null
@@ -1,102 +0,0 @@
-
-  
-    Project Roles
-    
-    
-  
-  
-  
-
-
-
    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.
    
-
    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 Contributing.
    
-
    Contributor
    
-
    "Contributors" are those making contributions to the AOSP source code,
-including both employees of Google or other companies, as well as individual
-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
    
-
    "Developers" are engineers writing applications that run on Android
-devices. There is often little 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
-(along with users) are the "customers" of the platform 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, verifiers act similarly to 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 Lead
    
-
    Android consists of a number of sub-projects; you can see these in the git
-repository as individual .git files. "Project leads" are senior contributors who
-oversee the engineering for individual Android projects. Typically these project
-leads are Google employees. A project lead for an individual project is
-responsible for the following:
    
-
      
-
    • 
-
      Lead all technical aspects of the project, including the project roadmap,
-  development, release cycles, versioning, and quality assurance (QA).
      
-
      • 
-
    • 
-
      Ensure the project is tested by QA 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/en/source/running.html b/en/source/running.html
deleted file mode 100644
index c4314de3..00000000
--- a/en/source/running.html
+++ /dev/null
@@ -1,446 +0,0 @@
-
-  
-    Running Builds
-    
-    
-  
-  
-  
-
-
-
-
    This page provides details for running builds on specific devices and
-complements the information in Building the
-System.
    
-
-
    Building fastboot and adb
    
-
    If you don't already have fastboot and adb, you can
-build them with the regular build system. Use the instructions in
-Building a System and replace the
-main make command with:
    
-
    make fastboot adb
    
-
-
    Booting into fastboot mode
    
-
    Fastboot is a bootloader mode in which you can flash a device.
-During a cold boot of a device, use the following key combinations to boot into
-fastboot mode:
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    DeviceCode nameKeys
    Pixel XLmarlinPress and hold Volume Down, then press and hold Power.
    PixelsailfishPress and hold Volume Down, then press and hold Power.
    hikeyhikeyLink pins 1 - 2 and 5 - 6 of J15.
    Nexus 6PanglerPress and hold Volume Down, then press and hold Power.
    Nexus 5XbullheadPress and hold Volume Down, then press and hold Power.
    Nexus 6shamuPress and hold Volume Down, then press and hold Power.
    Nexus PlayerfuguPress and hold Power.
    Nexus 9volantisPress and hold Volume Down, then press and hold Power.
    Nexus 5hammerheadPress and hold both Volume Up and Volume Down, then press
-and hold Power.
    Nexus 7floPress and hold Volume Down, then press and hold Power.
    Nexus 7 3GdebPress and hold Volume Down, then press and hold Power.
    Nexus 10mantaPress and hold both Volume Up and Volume Down, then press
-and hold Power.
    Nexus 4makoPress and hold Volume Down, then press and hold Power.
    Nexus 7 (2012)grouperPress and hold Volume Down, then press and hold Power.
    Nexus 7 3G (2012)tilapiaPress and hold Volume Down, then press and hold Power.
    Nexus QphantasmPower the device then cover it with one hand after the LEDs light up and
-until they turn red.
    Galaxy Nexus GSMmaguroPress and hold both Volume Up and Volume Down, then press
-and hold Power.
    Galaxy Nexus (Verizon)toroPress and hold both Volume Up and Volume Down, then press
-and hold Power.
    Galaxy Nexus (Sprint)toroplusPress and hold both Volume Up and Volume Down, then press
-and hold Power.
    Motorola XoomwingrayPress and hold Volume Down, then press and hold Power.
    Nexus ScrespoPress and hold Volume Up, then press and hold Power.
    Nexus SGcrespo4gPress and hold Volume Up, then press and hold Power.
    
-
-
    You can also use the command adb reboot bootloader to reboot
-from Android directly into the bootloader with no key combinations.
    
-
-
    Unlocking the bootloader
    
-
-
    You can flash a custom system only if the bootloader allows it, and the
-bootloader is locked by default. You can unlock the bootloader, but doing so
-deletes user data for privacy reasons. After unlocking, all data on the
-device is erased, i.e. both application private data and shared data accessible
-over USB (including photos and movies). Before attempting to unlock the
-bootloader, be sure to back up any important files on the device.
    
-
-
    You need to unlock the bootloader only once, and you can re-lock it if
-necessary.
    
-
-
    Unlocking recent devices
    
-
    All Nexus and Pixel devices released since 2014 (starting with Nexus 6 and
-Nexus 9) have factory reset protection and require a multi-step process to
-unlock the bootloader.
    
-
-
      
-
    1. To enable OEM unlocking on the device:
-  
        
-  
      1. In Settings, tap About phone, then tap Build
-  number seven (7) times.
        2. 
-  
      2. When you see the message "You are a developer", tap the back button.
        3. 
-  
      3. Tap Developer options and enable
-  OEM unlocking and USB debugging. (If OEM
-  unlocking is disabled, connect to the Internet so the device can check in at
-  least once. If it remains disabled, your device may be SIM locked by your
-  carrier and the bootloader cannot be unlocked.)
        4. 
-  
      
-
      2. 
-
    2. Reboot into the bootloader and use fastboot to unlock it.
-  
        
-  
      • For new devices (2015 and later):
-  
        fastboot flashing unlock
        
-  
        • 
-  
      • For older devices (2014 and earlier):
-  
        fastboot oem unlock
        
-  
        • 
-  
      
-
      3. 
-
    3. Confirm the unlock onscreen.
      4. 
-
    
-
-
-
-
    Re-locking the bootloader
    
-
    To re-lock the bootloader:
    
-
      
-
    • For new devices (2015 and later):
-
      fastboot flashing lock
      
-
      • 
-
    • For older devices (2014 and earlier):
-
      fastboot oem lock
      
-
      • 
-
    
-
-
-
-
    Using Flash Unlock
    
-
    The getFlashLockState() system API transmits the bootloader
-state and the PersistentDataBlockManager.getFlashLockState() system
-API returns the bootloader’s lock status on compliant devices.
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    Return valueConditions
    FLASH_LOCK_UNKNOWNReturned only by devices upgrading to Android 7.x or higher that did not
-previously support the bootloader changes required to get the flash lock
-status if they supported flashing lock/unlock capability.
    
-
      
-
    • New devices running Android 7.x or higher must be in either
-FLASH_LOCK_LOCKED or FLASH_LOCK_UNLOCKED state.
      • 
-
    • Devices upgrading to Android 7.x or higher that do not support flashing
-unlock/lock capability should return FLASH_LOCK_LOCKED state.
      • 
-
    
-
    FLASH_LOCK_LOCKEDShould be returned by any device that does not support flashing
-lock/unlock (i.e. the device is always locked), or any device that does support
-flashing lock/unlock and is in the locked state.
    FLASH_LOCK_UNLOCKEDReturned by any device that supports flashing lock/unlock and is currently
-in the unlocked state.
    
-
-
    Manufacturers should test the values returned by devices with locked and
-unlocked bootloaders. For an example, the Android Open Source Project (AOSP)
-contains a reference implementation that returns a value based on the
-ro.boot.flash.locked boot property. Example code is located in the
-following directories:
    
-
-
      
-
    • frameworks/base/services/core/java/com/android/server/PersistentDataBlockService.java
      • 
-
    • frameworks/base/core/java/android/service/persistentdata/PersistentDataBlockManager.java
      • 
-
    
-
-
    Selecting a device build
    
-
-
    The recommended builds for devices are available from the lunch
-menu, accessed when running the lunch command with no arguments.
-You can download factory images and binaries for Nexus devices from
-developers.google.com. See Device
-binaries for downloads. For details and additional resources, see Obtaining proprietary
-binaries.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    DeviceCode nameBuild configuration
    Pixel XLmarlinaosp_marlin-userdebug
    Pixelsailfishaosp_sailfish-userdebug
    HiKeyhikeyhikey-userdebug
    Nexus 6Pangleraosp_angler-userdebug
    Nexus 5Xbullheadaosp_bullhead-userdebug
    Nexus 6shamuaosp_shamu-userdebug
    Nexus Playerfuguaosp_fugu-userdebug
    Nexus 9volantis (flounder)aosp_flounder-userdebug
    Nexus 5 (GSM/LTE)hammerheadaosp_hammerhead-userdebug
    Nexus 7 (Wi-Fi)razor (flo)aosp_flo-userdebug
    Nexus 7 (Mobile)razorg (deb)aosp_deb-userdebug
    Nexus 10mantaray (manta)full_manta-userdebug
    Nexus 4occam (mako)full_mako-userdebug
    Nexus 7 (Wi-Fi)nakasi (grouper)full_grouper-userdebug
    Nexus 7 (Mobile)nakasig (tilapia)full_tilapia-userdebug
    Galaxy Nexus (GSM/HSPA+)yakju (maguro)full_maguro-userdebug
    Galaxy Nexus (Verizon)mysid (toro)aosp_toro-userdebug
    Galaxy Nexus (Experimental)mysidspr (toroplus)aosp_toroplus-userdebug
    Motorola Xoom (U.S. Wi-Fi)wingrayfull_wingray-userdebug
    Nexus Ssoju (crespo)full_crespo-userdebug
    Nexus S 4Gsojus (crespo4g)full_crespo4g-userdebug
    
-
-
    
-
-
    Flashing a device
    
-
-
    You can flash an entire Android system in a single command; doing so verifies
-the system being flashed is compatible with the installed bootloader and radio,
-writes the boot, recovery, and system partitions together, then reboots the
-system. Flashing also erases all user data, similarly to fastboot oem
-unlock.
    
-
-
    To flash a device:
    
-
      
-
    1. Place the device in fastboot mode by holding the appropriate
-key combination at boot or using the following command:
-
      adb reboot bootloader
      2. 
-
    2. After 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.
      3. 
-
    
-
-
-
-
    Restoring devices to factory
-state
    
-
-
    Factory images for Google devices are available from
-Factory
-Images for Nexus and Pixel Devices. Factory images for the Motorola Xoom are
-distributed directly by Motorola.
    
-
-  
-
diff --git a/en/source/site-updates.html b/en/source/site-updates.html
deleted file mode 100644
index 8142f137..00000000
--- a/en/source/site-updates.html
+++ /dev/null
@@ -1,683 +0,0 @@
-
-  
-    Site Updates
-    
-    
-  
-  
-  
-
-
-
    This page describes significant revisions to source.android.com. Please see the Android
-Open Source Project (AOSP) docs/source.android.com log for the complete
-list of changes to this site.
-
-
    September 2017
    
-
-
    This site has been released in China at source.android.google.cn. All
-  non-reference materials have also been translated into Simplified Chinese for
-  ease of use.
    
-
-
    August 2017
    
-
-
    Android 8.0 has been released! This section describes the major new features in the Android 8.0 platform.
    
-
-
    Architecture
    
-
-
    Treble
    
-
    
-Android 8.0 includes support for Treble, a major re-architect of the
-Android OS framework designed to make it easier, faster, and less costly
-for manufacturers to update devices to a new version of Android. Documentation
-includes details on the HAL interface definition
-language (HIDL), a new ConfigStore HAL,
-Device Tree Overlays,
-the Vendor Native Development
-Kit (VNDK), Vendor
-  Interface Objects (VINTF), 
-Modular Kernel requirements, and the 
-Vendor Test Suite (VTS) and Infrastructure.
-
    
-
-
    FunctionFS support
    
-
    
-FunctionFS
-(FFS) is a USB gadget function that is designed and controlled through user space.
-Its support allows all of the function- and protocol-specific code to live in
-user space, while all of the USB transport code lives in the kernel. Using
-     FFS moves Media Transfer Protocol (MTP) implementation into user space.
-
    
-
-
    
-On the frameworks side, most of the major changes exist in MtpServer. The
-USB driver interface has been refactored into two different classes, one that
-uses the old kernel driver and one that uses FFS. MtpServer is then able
-to use that driver interface without needing to know the details of
-implementation. The FFS driver writes the USB descriptors to a file when
-the server starts up; it then writes data to endpoint files similar to the
-kernel driver use.
-
    
-
-
    Kernel enhancements to LLDB/C++ debugging
    
-
    
-The Android 8.0 release includes kernel enhancements that help developers create
-better applications by improving their debugging experience. For more
-information, see Implementing
-kernel enhancements to LLDB/C++ debugging.
-
    
-
-
    Kernel Hardening
    
-
    
-Upstreamed kernel hardening features and tools to find bugs in kernel drivers.
-For more information, see Kernel Hardening.
-
    
-
-
    Optimizing SquashFS at the Kernel Level
    
-
    
-SquashFS is a compressed read-only filesystem for Linux, suitable for use on the
-system partition. The optimizations in this document help improve the
-performance of SquashFS. For more information, see Optimizing
-SquashFS at the Kernel Level.
-
    
-
-
    ART and Dalvik
    
-
    Fuzz Testing
    
-
    
-The Android Open Source Project (AOSP) offers a new fuzzing testing suite for
-testing the Android
-runtime (ART) infrastructure. The new toolset, JFuzz and an improved
-DexFuzz, are directly available in AOSP now with accompanying documentation.
-See:
-https://android.googlesource.com/platform/art/+/master/tools/jfuzz/README.md
-https://android.googlesource.com/platform/art/+/master/tools/dexfuzz/README
-
    
-
    
-Nothing is required to implement or use the new tools. You may make changes
-to the tools if required, just like you can make changes to the
-runtime/compiler already.
-
    
-
-
    VDEX files: Improve System Update Performance
    
-
    
-VDEX files improve the performance and user experience of software updates. VDEX
-files store pre-validated DEX files with verifier dependencies so that during
-system updates ART does not need to extract and verify the DEX files again. No
-action is needed to implement this feature. It is enabled by default. To
-disable the feature, set the ART_ENABLE_VDEX environment variable
-to false.
-
    
-
-
    ART performance improvements
    
-
    
-The Android runtime (ART) has been improved significantly in the Android 8.0
-release. This document summarizes enhancements device manufacturers can expect
-in ART. For more information, see Improving
-ART Performance in Android 8.0.
-
    
-
-
    Android A/B OTA Updates
    
-
    
-This update answers common questions device manufacturers have regarding Android
-A/B (seamless) system updates. For more information, see A/B
-(Seamless) System Updates Frequently asked questions.
-
    
-
-
    Automotive
    
-
-
    Bluetooth connection management
    
-
    
-Android 8.0 provides Bluetooth connection management in in-vehicle infotainment
-systems for a more seamless Bluetooth user experience. For more information, see
-
-Bluetooth connection management.
-
    
-
-
    Bluetooth multi-device HFP
    
-
    
-Bluetooth multi-device connectivity lets users connect multiple devices to telephony profiles in
-an Android Automotive IVI Bluetooth. For more information, see
-
-IVI Connectivity.
-
    
-
-
    Vehicle Camera HAL
    
-
    
-Describes the design of an exterior view system (EVS) stack and provides the HAL
-specification for supporting the acquisition and presentation of vehicle camera
-data. For more information, see Exterior
-View System (EVS) Vehicle Camera HAL.
-
    
-
-
    Bluetooth
    
-
    
-See the updated Bluetooth
-overview.
-
    
-
-
    Verifying and debugging Bluetooth
    
-
    
-A new page about how to verify and debug the native Bluetooth stack. See this page at
-Verifying and Debugging.
-
    
-
-
    Bluetooth services
    
-
    
-Bluetooth provides a variety of features that enable core services between devices,
-such as audio streaming, phone calls, and messaging. For more information about the Android
-Bluetooth services, see 
-Bluetooth Services.
-
    
-
-
    BLE advertising
    
-
    
-Bluetooth 5 supports different modes of data advertisements for Bluetooth Low Energy,
-including higher bandwidth or increased range. For more information, see
-
-Bluetooth Low Energy Advertising.
-
    
-
-
-
    Bluetooth support for audio codecs
    
-
    
-The Android 8.0 release includes support for Bluetooth high-definition audio
-codecs. For more information, see Advanced audio codecs.
-
    
-
-
-
    Camera
    
-
-
    Critical camera features
    
-
    
-The Android 8.0 release contains these key enhancements to the Camera service:
-shared surfaces, enable multiple surfaces sharing the same OutputConfiguration
-System API for custom camera modes, and onCaptureQueueEmpty. For more
-information, see Camera Version
-Support.
-
    
-
-
    Configuration
    
-
-
    Ambient Capabilities
    
-
    
-Capabilities allow Linux processes to drop most root-like privileges, while
-retaining the subset of privileges that they require to perform their function.
-Ambient capabilities allows system services to configure capabilities in their
-.rc files, bringing all their configuration into a single file. For
-more information, see Implementing
-Ambient Capabilities.
-
    
-
-
    Privileged Permission Whitelist Requirement
    
-
    
-Starting in Android 8.0, all privileged apps must be explicitly whitelisted in
-system configuration XML files in the /etc/permissions directory.
-If they are not, then the device will boot, but the device implementation will
-not pass CTS. For more information, see Privileged
-Permission Whitelist Requirement.
-
    
-
-
    Implementing USB HAL
    
-
    
-The Android 8.0 release moves handling of USB commands out of init scripts and
-into a native USB daemon for better configuration and code reliability. For more
-information, see Implementing
-USB HAL.
-
    
-
-
    Connectivity
    
-
-
    Customizing Device Behavior for Out-of-balance Users
    
-
    
-Android devices with no data balance allow network traffic through, requiring
-carriers and telecoms to implement mitigation protocols. This feature implements
-a generic solution that allows carriers and telcos to indicate when a device has
-run out of balance. For more information, see Customizing
-device behavior for out-of-balance users.
-
    
-
-
    Debugging
    
-
-
    Enabling sanitizers in the Android build system
    
-
    
-Sanitizers are compiler-based instrumentation components to use during
-development and testing in order to identify bugs and make Android better.
-Android's current set of sanitizers can discover and diagnose memory misuse bugs
-and potentially dangerous undefined behavior. For more information, see Enabling
-Sanitizers in the Android Build System.
-
    
-
-
    Recover devices in reboot loops
    
-
    
-Android 8.0 includes a feature that sends out a "rescue party" when it notices
-core system components stuck in crash loops. Rescue Party then escalates through
-a series of actions to recover the device. For more information, see Rescue
-Party.
-
    
-
-
    Storaged
    
-
    
-Android 8.0 adds support for storaged, an Android native daemon that
-collects and publishes storage metrics on Android devices. For more information,
-see Implementing
-Storaged.
-
    
-
-
    Display
    
-
-
    Air Traffic Control for floating windows
    
-
    
-Android 8.0 introduces Air Traffic Control for floating windows in order to
-simplify and unify how apps display on top of other apps. Everything necessary
-to use the feature is included in the Android Open Source Project (AOSP).
-
    
-
    
-Air Traffic Control allows developers to create a new (managed) floating
-layer/window type for apps to use to display windows on-top of other apps. The
-feature displays ongoing notifications for all apps using a floating layer that
-lets the user manage the alert window.
-
    
-
    
-The Android Compatibility Test Suite (CTS) confirms:
-
     
      
- 
    • The current alert window types are: TYPE_PHONE, TYPE_PRIORITY_PHONE,
-TYPE_SYSTEM_ALERT, TYPE_SYSTEM_OVERLAY, or TYPE_SYSTEM_ERROR
- 
    • Apps targeting the O SDK won't be able to use the window types above to
-display windows above other apps. They will need to use a new window type
-TYPE_APPLICATION_OVERLAY.
- 
    • Apps targeting older SDKs can still use the current window types; however,
-the windows will be z-ordered below the new TYPE_APPLICATION_OVERLAY windows.
- 
    • The system can move or resize windows in the new layer to reduce clutter.
- 
    • Device manufacturers must keep the notification that lets users control
-what is displayed over other apps.
      •  
    
-
-
    Launching activities on secondary displays
    
-
    
-Virtual displays are available to everyone, and they don't require any special
-hardware. Any application can create an instance of virtual display; and in the
-Android 8.0 release, activities can be launched on that virtual display if the
-associated feature is enabled.
-
    
-
    
-To support multi-display features, you should either use one of the
-existing supported ways of connecting secondary devices or build new hardware.
-The supported ways of connecting displays on Nexus and Pixel devices are Google
-Cast and virtual
-displays inside apps. Support of other ways depends on kernel driver support
-for each particular case (like MHL or DisplayPort over USB-C) and fully
-implementing interface definitions that are related to displays in
-HardwareComposer HAL (IComposerCallback.hal and IComposerClient.hal).
-
    
-
    
-Each of the ways may require SoC or OEM support. For example, to enable
-DisplayPort over USB-C, both hardware (SOC) and software (drivers) support is
-required. You might need to implement drivers for your hardware to support
-connecting external displays.
-
    
-
    
-The default implementation will allow launching fullscreen stacks of activities
-on secondary displays. You can customize the stacks and System UI and
-behavior on secondary displays.
-
    
-
-
    Support for generic tooltip
    
-
    
-Android 8.0 allows developers to provide descriptive action names and other
-helpful information on mouse hover over buttons and other icons. Device
-manufacturers may style the tooltip popup. Its layout is defined in
-android/frameworks/base/core/res/res/layout/tooltip.xml.
-
-
    
-
    
-OEMs may replace the layout or change its dimensions and style parameters. Use
-only text and keep the size reasonably small. The feature is implemented
-entirely inside the View class, and there are quite exhaustive CTS tests that
-check many aspects of Tooltip behavior.
-
    
-
    
-
-
    Support for extended aspect ratio
    
-
    
-Android 8.0 includes a new manifest attribute, maxAspectRatio,
-which lets an activity or app specify the maximum aspect ratio it supports.
-maxAspectRatio replaces the previous meta-data tag with a first-class API and
-allows devices to support an aspect ratio greater than 16:9.
-
      
-
    • If an activity or app is resizable,
-allow the activity to fill the screen.
-
    • If an activity or app is non-resizeable or the platform is force resizing
-the activity, allow the app window to display up to the maximum aspect ratio,
-according to the maxAspectRatio
-value. 
        
- 
      • For applications on devices running Android 8.0, the default value is the
-aspect ratio of the current device.
- 
      • For applications on devices running earlier versions of Android, the
-default value is 16:9.
        •  
      
-
      •  
    
-
-
    Implementing Adaptive Icons
    
-
    
-Adaptive Icons maintain a consistent shape intra-device but vary from device to
-device with only one icon asset provided by the developer. Additionally, icons
-support two layers (foreground and background) that can be used for motion to
-provide visual delight to users. For more information, see Implementing
-Adaptive Icons.
-
    
-
-
    Night Light
    
-
    
-Night Light, introduced in Android 7.0.1, allows users to reduce the amount of
-blue light that their screen emits. Android 8.0 gives users more control over the
-intensity of this effect. For more information, see Implementing
-Night Light.
-
    
-
-
    Picture-in-picture
    
-
    
-Android 8.0 includes support for picture-in-picture (PIP) on Android handheld
-devices. PIP allows users to resize an app with an ongoing activity, such as a
-video, into a small window. For more information, see Picture-in-Picture
-on Android handsets.
-
    
-
-
    Better Split-Screen Interactions
    
-
    
-Multi-window lets multiple apps simultaneously display on users' device screens.
-Android 8.0 improves the default mode, split-screen, by compressing the top pane
-and resizing the launcher if a user taps Home after entering split-screen. For
-more information, see Better
-Split-Screen Interactions.
-
    
-
-
    Add Widgets/Shortcuts
    
-
    
-A new API in Android 8.0 allows application developers to add shortcuts and
-widgets from inside the app instead of relying on the widget tray. The older
-method of adding shortcuts by sending a broadcast has been deprecated for
-security reasons. For more information, see Implementing
-Add Widgets/Shortcuts.
-
    
-
-
    Downloading and Building
    
-
-
    Android LLVM Toolchain improvements
    
-
    
-OEMs who wish to use our latest toolchain/tools will need to ensure that any of
-their private code compiles successfully with the updated toolchains. This may
-require them to fix existing issues in their code with undefined behavior. (Of
-course, they are free to use whatever tools they prefer to compile their own
-code too.)
-
    
-
    
-They must ensure their code is free of undefined behavior (by using tools like
-UBSan), so they are less susceptible to problems caused by newer toolchains. All
-of the toolchains are always updated directly in AOSP. Everything will be
-available well before OC even ships, so OEMs should be following along
-already.
-
    
-
    
-See the public Clang/LLVM documentation for
-general instructions and the Android
-Clang/LLVM documentation set within AOSP for Android-specific guidance.
-Finally, join the android-llvm
-public group to get help and take part in development.
-
    
-
-
    DRM / KMS
    
-
-
    DRM/KMS in Linux Kernel Version 4.9
    
-
    
-The Direct Rendering Manager (DRM)/Kernel Mode Setting (KMS) framework used by
-Android is developed and maintained by Linux kernel developers in the Linux
-kernel. Android merges down from the Linux kernel. By merging down from our
-common kernel, device manufacturers gain the DRM/KMS framework automatically.
-
    
-
    
-DRM/KMS became viable in Linux kernel version 4.9, and Android strongly
-encourages OEM partners to use DRM/KMS starting with this kernel
-version. Atomic Display Framework
-(ADF), the display framework officially supported by Android today, will not
-be supported in 4.9 and higher versions of the common Android kernel; instead,
-Android will support DRM/KMS from this version. OEMs can continue to use ADF (or
-any other framework), but Android will not support them in the common Android
-kernel.
-
    
-
    
-To implement DRM/KMS, you will need to write your own drivers using
-DRM/KMS in addition to merging down the DRM/KMS framework from the android
-common kernel.
-
    
-
-
    Keystore
    
-
-
    Keymaster 3
    
-
    
-Android 8.0 updates Keymaster, the keystore HAL, by extending the capabilities of
-hardware-backed key storage on Android devices. This builds upon the Android 7.1.2
-updates to Keymaster 2. For more information, see Keymaster 3 documentation.
-
    
-
-
    Security Enhancements
    
-
-
    Insecure TLS Version Fallback removed from HttpsURLConnection
    
-
    
-Insecure TLS/SSL protocol version fallback is a workaround for buggy
-implementations of TLS protocol downgrade negotiation in some servers. This is
-vulnerable to POODLE. When Chrome 45 dropped the insecure fallback in September
-2015, less than 0.01% of servers relied on it. To improve security, insecure TLS
-version fallback has been removed from HttpsURLConnection
-in Android 8.0. For more details, see this blog post.
-
    
-
    
-To test this feature on devices with Android 8.0, run this CTS test case:
-
    
-
-
    -cts-tradefed run cts -m CtsLibcoreOkHttpTestCases
    
-
-
    Performance
    
-
-
    Flash Wear Management
    
-
    
-Describes eMMC behavior and new features to help OEMs lower the risk of a
-failing eMMC in the automotive environment. For more information, see Flash Wear
-Management in Android Automotive.
-
    
-
-
    Optimizing Boot Times
    
-
    
-Guidance for improving boot times for specific Android devices. For more
-information, see Optimizing
-boot times.
-
    
-
-
    Task Snapshots
    
-
    
-Task Snapshots is infrastructure introduced in Android 8.0 that combines
-screenshots for Recents Thumbnails as well as Saved Surfaces from Window Manager
-to save memory. For more information, see Task
-Snapshots.
-
    
-
-
    Peripherals
    
-
-
    Default Print Services
    
-
    
-A print
-service is an app that discovers and presents printers to a device's print
-framework. In earlier Android versions, users had to search for and install
-third-party print services to be able to print.
-
    
-
    
-Android 8.0 includes a default print service in platform/packages/services/BuiltInPrintService/
-that lets users print on modern printers without installing any additional apps.
-This implementation supports printers that use the Internet Printing Protocol
-(IPP) to communicate with the printer and use PCLm, PWG-Raster, or PDF to send
-printable content. For older printers, users should install the app recommended
-by the PrintRecommendationService
-as seen in this this I/O presentation.
-
-
    Reference Updates
    
-
-
    
-The Reference section has been added to the top-level
-navigation. As part of the Treble
-release, a HIDL reference section was added.
-The Trade Federation and the
-legacy HAL reference documentation has been updated.
-
    
-
-
    Settings menu
    
-
-
    Settings: Patterns and Components
    
-
    
-In Android 8.0, the Settings menu gains several components and widgets that
-cover common uses. For more information, see Patterns
-and Components.
-
    
-
-
    Settings: Updated information architecture
    
-
    
-Android 8.0 introduces a new information architecture for the Settings app. The
-goal of the new information architecture is to simplify the way settings are
-organized and make it easier for users to quickly find the settings needed to
-customize their Android devices. For more information, see Implementing Updated
-Information Architecture.
-
    
-
-
    Personalized Settings
    
-
    
-The Android Settings app provides a list of suggestions to the users. This
-feature provides ranking for suggestions, based on any contextual signal or the
-user's past interactions with suggestions.  For more information, see Personalized
-Settings.
-
    
-
-
    Implementing Settings: Universal Search
    
-
    
-Android 8.0 adds expanded search capabilities for the Settings menu. This document
-describes how to add a setting and ensure it is properly indexed for Settings.
-For more information, see Universal
-Search.
-
    
-
-
    Storage
    
-
-
    Faster storage statistics
    
-
    
-Android 8.0 leverages the ext4 filesystem's "quota" support to return disk usage
-statistics almost instantly. For more information, see Implementing
-faster storage statistics.
-
    
-
-
    April 2017
    
-
    Welcome to a new source.android.com! The site has been overhauled to make it
-easier for you to navigate, search, and read its ever-growing set of information.
-Here is a summary of enhancements:
    
-
-
    More screen real estate, larger type size
    
-
    The entire site is wider, allowing you to view more content at once. Code
-samples and commands are more visible, and all text has been enlarged.
    
-
-
    Mobile-ready view
    
-
    The new site renders more cleanly on handheld devices with a dedicated
-mobile view.
    
-
-
    
-  new mobile view
-  
    
-    Figure 1. Site's new mobile view
-  
    
-
    
-
-
    New top-level tabs
    
-
    The former Devices tab has been renamed Porting, while the old Core Technologies
-subtab has been renamed Tuning and moved to the top
-of the site for better exposure.
    
-
-
    Security at the forefront
    
-
    With an ever-increasing focus on security in Android, the Security tab has been moved forward (next to Source) to reflect its importance.
    
-
-
    Better reference materials
    
-
    Hardware Abstraction Layer and Trade Federation reference
-materials are available directly from a top-level Reference tab.
    
-
-
-
    The AOSP code
-repository is always just a click away with the Go to Code
-button at the top right of every page.
    
-
-
    Comprehensive footers
    
-
    In addition to the existing About, Community, and
-Legal footers, you can now find a complete list of links at the bottom
-of every page for building Android, connecting with the ecosystem, and getting
-help with the operating system's use.
    
-
-  
-
diff --git a/en/source/submit-patches.html b/en/source/submit-patches.html
deleted file mode 100644
index c61fb2c7..00000000
--- a/en/source/submit-patches.html
+++ /dev/null
@@ -1,238 +0,0 @@
-
-  
-    Submitting Patches
-    
-    
-  
-  
-  
-
-
-
    This page describes the full process of submitting a patch to the AOSP,
-including
-reviewing and tracking changes with Gerrit.
    
-
    Prerequisites
    
-
-
-
    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. Follow the instructions on the password
-generator page. You need to do this only once. See Using
-Authentication for additional details.
    
-
    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 (50 characters maximum), followed by a
-blank line.
-This format is used by git and Gerrit for various displays.
      
-
      • 
-
-
    • 
-
      Starting on the third line, enter a longer description, which must
-hard-wrap at 72 characters maximum. This description should focus on what
-issue the change 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.
      
-
      • 
-
    
-
-
    Here is an example commit message:
    
-
    short description on first line
-
-more detailed description of your patch,
-which is likely to take up multiple lines.
-
    
-
-
    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. 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.
    
-
-
    -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.
    
-
    -repo rebase
-
    
-
    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.
    
-
-
    Upstream Projects
    
-
    Android makes use of a number of other open source projects, such as the
-Linux kernel and WebKit, as described in
-Codelines, Branches, and
-Releases. 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/.
-See Submitting ICU Bugs and
-Feature Requests for more.
    
-
-
    LLVM/Clang/Compiler-rt
    
-
    All changes to LLVM-related projects (external/clang,
-external/compiler-rt,
-external/llvm) should be made upstream at
-llvm.org/.
    
-
-
    mksh
    
-
    All changes to the MirBSD Korn Shell project at external/mksh
-should be made upstream
-either by sending an email to miros-mksh on the mirbsd.org domain (no
-subscription
-required to submit there) or (optionally) at Launchpad.
-
    
-
    OpenSSL
    
-
    All changes to the OpenSSL project at external/openssl
-should be made upstream at
-openssl.org.
    
-
    V8
    
-
    All changes to the V8 project at external/v8 should be
-submitted upstream at
-code.google.com/p/v8. See Contributing to V8
-for details.
    
-
    WebKit
    
-
    All changes to the WebKit project at external/webkit should
-be made
-upstream at 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 for details.
    
-
    zlib
    
-
    All changes to the zlib project at external/zlib should be
-made upstream at
-zlib.net.
    
-
-
-  
-
diff --git a/en/source/using-repo.html b/en/source/using-repo.html
deleted file mode 100644
index b84d9d2f..00000000
--- a/en/source/using-repo.html
+++ /dev/null
@@ -1,305 +0,0 @@
-
-  
-    Repo command reference
-    
-    
-  
-  
-  
-
-
-
    Repo usage takes the following form: 
    
-
    -repo <COMMAND> <OPTIONS>
-
    
-
    Optional elements are shown in brackets [ ]. For example, 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>]
-
    
-
-
    help
    
-
    Once Repo is installed, you can find the latest documentation starting with a summary of all commands by running:
    
-
    -repo help
-
    
-
    You can get information about any command by running this within a Repo tree:
    
-
    -repo help <COMMAND>
-
    
-
-
    For example, the following command yields a description and list of options
-for the init argument of Repo, which initializes Repo in the
-current directory. (See init for more details.)
    
-
    -repo help init
-
    
-
-
-
    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. See manifest-format.txt for instructions on updating the
-   manifest.
    
-
    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
-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.
      
-
      • 
-
    • 
-
      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
-# 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.
    
-
    If you only want to upload the currently checked out Git branch, you can use the flag --current-branch (or --cbr for short).
    
-
-
    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 into your platform/build 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 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 system 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.
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    lettermeaningdescription
    -no changesame in HEAD and index
    Aaddednot in HEAD, in index
    Mmodifiedin HEAD, modified in index
    Ddeletedin HEAD, not in index
    Rrenamednot in HEAD, path changed in index
    Ccopiednot in HEAD, copied from another in index
    Tmode changedsame content in HEAD and index, mode changed
    Uunmergedconflict between HEAD and index; resolution required
    
-
    In the second column, a lowercase letter indicates how the working directory differs from the index.
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    lettermeaningdescription
    -new/unknownnot in index, in work tree
    mmodifiedin index, in work tree, modified
    ddeletedin index, not in work tree
    
-
-  
-
diff --git a/en/source/view-patches.html b/en/source/view-patches.html
deleted file mode 100644
index 6b69f3cc..00000000
--- a/en/source/view-patches.html
+++ /dev/null
@@ -1,142 +0,0 @@
-
-  
-    View Patches
-    
-    
-  
-  
-  
-
-    
    
-      If you want to view all patches to the Android Open Source Project, or
-      if you are reviewing or verifying a change, look in the 
-      AOSP Gerrit. For more information on how to find a specific change, see 
-      Gerrit Code Review - Searching Changes.
-    
    
-
-    
    Reviewing a change
    
-
-      
    
-        If you are assigned to be the Reviewer 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 select the Reply button. This
-        brings up a comment box where you can mark the change as
-        Verified or not, 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. For more information, see the Repo reference
-      .
-      
    
-
-    
    How do I become a Verifier
-      or Reviewer?
    
-
-      
    
-        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.
-      
    
-
-    
    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.
-      
    
-
-  
-
-
-- 
cgit v1.2.3