s.a.c. redesign, first checkin
Change-Id: I4dead2f18bc5e4a38f204c92198a267c286e775d
diff --git a/src/source/assets/bg_fade.jpg b/src/source/assets/bg_fade.jpg
new file mode 100644
index 0000000..c6c70b6
--- /dev/null
+++ b/src/source/assets/bg_fade.jpg
Binary files differ
diff --git a/src/source/assets/bg_images_sprite.png b/src/source/assets/bg_images_sprite.png
new file mode 100644
index 0000000..84437e7
--- /dev/null
+++ b/src/source/assets/bg_images_sprite.png
Binary files differ
diff --git a/src/source/assets/favicon.ico b/src/source/assets/favicon.ico
new file mode 100644
index 0000000..d8884b7
--- /dev/null
+++ b/src/source/assets/favicon.ico
Binary files differ
diff --git a/src/source/assets/main.css b/src/source/assets/main.css
new file mode 100644
index 0000000..18662a1
--- /dev/null
+++ b/src/source/assets/main.css
@@ -0,0 +1,321 @@
+/* reset styles */
+html,
+body,
+div,
+h1, h2, h3, h4, h5, h6,
+p,
+img,
+dl, dt, dd,
+table, tbody, tfoot, thead, tr, th, td {
+ border: 0;
+ margin: 0;
+ padding: 0;
+}
+
+/* OVERALL */
+
+html,
+body {
+ background-color: white;
+ overflow: auto;
+}
+
+body {
+ background: white url(bg_fade.jpg) repeat-x;
+ font-family: Arial, Helvetica, sans-serif;
+ font-size: 13px;
+}
+
+a {
+ color: #069;
+}
+
+a.visited {
+ color: #036;
+}
+
+p, ul, ol, li {
+ line-height: 1.3em;
+}
+
+table {
+ border-collapse: collapse;
+ border-width: 0;
+ empty-cells: show;
+ font-size: 1em;
+ margin: 0 0 1em 0;
+ padding: 0;
+}
+
+td, th {
+ background-color: inherit;
+ border: 1px solid #ccc;
+ padding: 6px 12px;
+
+ text-align: left;
+ vertical-align: top;
+}
+
+th {
+ background-color: #dee8f1;
+}
+
+/* HEADER */
+
+#header {
+ border-bottom: 3px solid #94b922;
+ height: 111px;
+ padding: 0 10px;
+}
+
+#header ul {
+ height: 29px;
+ list-style: none;
+ margin: 7px 0 0;
+ padding: 0;
+}
+
+#header li {
+ float: left;
+ margin: 0px 2px 0px 0px;
+ padding: 0;
+}
+
+#header li a {
+ background: url(bg_images_sprite.png) no-repeat 0 -58px;
+ color: #666;
+ display: block;
+ font-size: 13px;
+ font-weight: bold;
+ height: 29px;
+ margin: 0px;
+ text-decoration: none;
+ text-align: center;
+ width: 94px;
+}
+
+#header li a:hover
+{
+ background: url(bg_images_sprite.png) no-repeat 0 -29px;
+}
+
+/* tab highlighting */
+.home #home-link a,
+.community #community-link a,
+.tech #tech-link a,
+.source #source-link a,
+.about #about-link a,
+.compatibility #compatibility-link a {
+ background: green url(bg_images_sprite.png) no-repeat 0 0;
+ color: #fff;
+ cursor:default;
+ font-weight: bold;
+}
+
+#header li a span {
+ position: relative;
+ top: 7px;
+}
+
+#headerLeft {
+ padding-top: 25px;
+}
+
+#headerLeft img {
+ height: 50px;
+ width: 349px;
+}
+
+#headerRight {
+ position: absolute; right: 0; top: 0;
+ text-align: right;
+}
+
+#headerLinks {
+ font-size: 11px;
+ height: 13px;
+ margin: 10px 10px 0 0;
+ vertical-align: top;
+}
+
+#headerLinks a {
+ color: #7FA9B5;
+}
+
+#headerLinks img {
+ vertical-align: middle;
+}
+
+/* SIDEBAR */
+
+#sidebar {
+ background-color: #fff;
+ float: left;
+ font-size: 12px;
+ margin-top: 1em;
+ padding-left: 6px;
+ width: 250px;
+}
+
+#sidebar h1 {
+ font-size: 12px;
+ font-weight: bold;
+ margin: .5em 0 0 0;
+ padding: 3px 0 1px 9px;
+}
+
+#sidebar ul {
+ list-style: none;
+ margin: 0;
+ padding: 0 0 5px 18px;
+}
+
+#sidebar ul ul {
+ margin-top: .35em;
+}
+
+#sidebar li {
+ line-height: 16px;
+ padding: 0;
+}
+
+#sidebar li a {
+ text-decoration: none;
+}
+
+#sidebar li a:hover {
+ text-decoration: underline;
+}
+
+/* FOOTER */
+
+#footer {
+ clear: both;
+ font-size: 80%;
+ margin: 0 3em;
+}
+
+#footerLeft {
+ float: left;
+}
+
+#footerRight {
+ float: right;
+}
+
+/* MAIN */
+
+#main {
+ margin: 1em;
+ overflow: hidden;
+}
+
+#main h1 {
+ color: #5d7d99;
+ font-size: 150%;
+}
+
+#main h2 {
+ color: #435a6e;
+ font-size: 120%;
+}
+
+#main h3 {
+ color: #1f2a33;
+ font-size: 110%;
+}
+
+p {
+ margin: 1em 0 1em 0;
+}
+
+code {
+ font-family: "Lucida Console", Monaco, monospace;
+}
+
+pre {
+ color: #007000;
+ background-color: #fafafa;
+ border: solid 1px #ccc;
+ margin: 1em 0 1em 0;
+ padding: 1em;
+}
+
+dt {
+ color: #1f2a33;
+ font-size: 110%;
+}
+
+dd {
+ margin: 1em 1em 1em 1em;
+}
+
+/* TABLE OF CONTENTS */
+
+.toc {
+ background-color: #fafafa;
+ border: 1px solid #94b922;
+ display: inline-block;
+ padding: 1em;
+ margin: 1em 0;
+}
+
+.toctitle {
+ color: #007000;
+ font-size: 110%;
+}
+
+.toc ul {
+ list-style: none;
+ margin-left: 0;
+ padding: 0;
+}
+
+.toc li {
+ margin-left: 1em;
+ padding: 0;
+}
+
+
+/* REBOX (the little blue boxes on the home page) */
+
+.rebox {
+ background: #daf3fc;
+ border-collapse: collapse;
+ border-width: 0px;
+ float: left;
+ font-size: 13px;
+ margin: 1em 1em 1.5em 1em;
+ -moz-border-radius: 5px;
+ -webkit-border-radius: 5px;
+ width: 30%;
+}
+
+.rebox p img {
+ display: block;
+ margin-bottom: 2em;
+}
+
+.rebox p {
+ line-height: 1.25em;
+ margin-bottom: 16px;
+}
+
+.rebox h2, .rebox h3 {
+ background: url('rebox-gradient.gif') no-repeat center bottom #95c0d0;
+ color: white;
+ display: block;
+ font-size: 16px;
+ padding: .5em .5em .5em .75em;
+ -moz-border-radius-topright: 5px;
+ -moz-border-radius-topleft: 5px;
+ -webkit-border-top-right-radius: 5px;
+ -webkit-border-top-left-radius: 5px;
+}
+
+.rebox img {
+ float: left;
+ margin: 1em; margin-bottom: 5em;
+ padding: 0 0 3em 0;
+}
+
diff --git a/src/source/assets/rebox-gradient.gif b/src/source/assets/rebox-gradient.gif
new file mode 100644
index 0000000..124e844
--- /dev/null
+++ b/src/source/assets/rebox-gradient.gif
Binary files differ
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
new file mode 100644
index 0000000..c9b6607
--- /dev/null
+++ b/src/source/build-numbers.jd
@@ -0,0 +1,524 @@
+page.title=Codenames, Tags, and Build Numbers
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>At a high level, Android development happens around families of
+releases, which use code names ordered alphabetically after tasty
+treats.</p>
+
+<h2 id="platform-code-names-versions-api-levels-and-ndk-releases">Platform Codenames, Versions, API Levels, and NDK Releases</h2>
+<p>The code names match the following version numbers, along with
+API levels and NDK releases provided for convenience:</p>
+<table>
+<thead>
+<tr>
+<th>Code name</th>
+<th>Version</th>
+<th>API level</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>(no code name)</td>
+<td>1.0</td>
+<td>API level 1</td>
+</tr>
+<tr>
+<td>(no code name)</td>
+<td>1.1</td>
+<td>API level 2</td>
+</tr>
+<tr>
+<td>Cupcake</td>
+<td>1.5</td>
+<td>API level 3, NDK 1</td>
+</tr>
+<tr>
+<td>Donut</td>
+<td>1.6</td>
+<td>API level 4, NDK 2</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.0</td>
+<td>API level 5</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.0.1</td>
+<td>API level 6</td>
+</tr>
+<tr>
+<td>Eclair</td>
+<td>2.1</td>
+<td>API level 7, NDK 3</td>
+</tr>
+<tr>
+<td>Froyo</td>
+<td>2.2.x</td>
+<td>API level 8, NDK 4</td>
+</tr>
+<tr>
+<td>Gingerbread</td>
+<td>2.3 - 2.3.2</td>
+<td>API level 9, NDK 5</td>
+</tr>
+<tr>
+<td>Gingerbread</td>
+<td>2.3.3 - 2.3.7</td>
+<td>API level 10</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.0</td>
+<td>API level 11</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.1</td>
+<td>API level 12, NDK 6</td>
+</tr>
+<tr>
+<td>Honeycomb</td>
+<td>3.2.x</td>
+<td>API level 13</td>
+</tr>
+<tr>
+<td>Ice Cream Sandwich</td>
+<td>4.0.1 - 4.0.2</td>
+<td>API level 14, NDK 7</td>
+</tr>
+<tr>
+<td>Ice Cream Sandwich</td>
+<td>4.0.3 - 4.0.4</td>
+<td>API level 15, NDK 8</td>
+</tr>
+<tr>
+<td>Jelly Bean</td>
+<td>4.1.x</td>
+<td>API level 16</td>
+</tr>
+<tr>
+<td>Jelly Bean</td>
+<td>4.2.x</td>
+<td>API level 17</td>
+</tr>
+</tbody>
+</table>
+<p>Starting with Cupcake, individual builds are identified with a short
+build code, e.g. FRF85B.</p>
+<p>The first letter is the code name of the release family, e.g. F is
+Froyo.</p>
+<p>The second letter is a branch code that allows Google to identify
+the exact code branch that the build was made from, and R is by
+convention the primary release branch.</p>
+<p>The next letter and two digits are a date code. The letter counts
+quarters, with A being Q1 2009. Therefore, F is Q2 2010. The two
+digits count days within the quarter, so F85 is June 24 2010.</p>
+<p>Finally, the last letter identifies individual versions related to
+the same date code, sequentially starting with A; A is actually
+implicit and usually omitted for brevity.</p>
+<p>The date code is not guaranteed to be the exact date at which a build
+was made, and it is common that minor variations added to an existing
+build re-use the same date code as that existing build.</p>
+
+<h2 id="source-code-tags-and-builds">Source Code Tags and Builds</h2>
+<p>Starting with Donut, the exact list of tags and builds is in the
+following table:</p>
+<table>
+<thead>
+<tr>
+<th>Build</th>
+<th>Tag</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>DRC83</td>
+<td>android-1.6_r1.1</td>
+<td>earliest Donut version, ADP1, ADP2</td>
+</tr>
+<tr>
+<td>DRC92</td>
+<td>android-1.6_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>DRD08</td>
+<td>android-1.6_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>DRD20</td>
+<td>android-1.6_r1.4</td>
+<td></td>
+</tr>
+<tr>
+<td>DMD64</td>
+<td>android-1.6_r1.5</td>
+<td>latest Donut version</td>
+</tr>
+<tr>
+<td>ESD20</td>
+<td>android-2.0_r1</td>
+<td>earliest Eclair version</td>
+</tr>
+<tr>
+<td>ESD56</td>
+<td>android-2.0.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>ERD79</td>
+<td>android-2.1_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>ERE27</td>
+<td>android-2.1_r2</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>EPE54B</td>
+<td>android-2.1_r2.1p</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>ESE81</td>
+<td>android-2.1_r2.1s</td>
+<td></td>
+</tr>
+<tr>
+<td>EPF21B</td>
+<td>android-2.1_r2.1p2</td>
+<td>latest Eclair version</td>
+</tr>
+<tr>
+<td>FRF85B</td>
+<td>android-2.2_r1</td>
+<td>earliest Froyo version, Nexus One</td>
+</tr>
+<tr>
+<td>FRF91</td>
+<td>android-2.2_r1.1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG01B</td>
+<td>android-2.2_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>FRG22D</td>
+<td>android-2.2_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>FRG83</td>
+<td>android-2.2.1_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG83D</td>
+<td>android-2.2.1_r2</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRG83G</td>
+<td>android-2.2.2_r1</td>
+<td>Nexus One</td>
+</tr>
+<tr>
+<td>FRK76</td>
+<td>android-2.2.3_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>FRK76C</td>
+<td>android-2.2.3_r2</td>
+<td>latest Froyo version</td>
+</tr>
+<tr>
+<td>GRH55</td>
+<td>android-2.3_r1</td>
+<td>earliest Gingerbread version, Nexus S</td>
+</tr>
+<tr>
+<td>GRH78</td>
+<td>android-2.3.1_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRH78C</td>
+<td>android-2.3.2_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRI40</td>
+<td>android-2.3.3_r1</td>
+<td>Nexus One, Nexus S</td>
+</tr>
+<tr>
+<td>GRI54</td>
+<td>android-2.3.3_r1.1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRJ06D</td>
+<td>android-2.3.4_r0.9</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRJ22</td>
+<td>android-2.3.4_r1</td>
+<td>Nexus One, Nexus S, Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRJ90</td>
+<td>android-2.3.5_r1</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>GRK39C</td>
+<td>android-2.3.6_r0.9</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>GRK39F</td>
+<td>android-2.3.6_r1</td>
+<td>Nexus One, Nexus S</td>
+</tr>
+<tr>
+<td>GWK74</td>
+<td>android-2.3.7_r1</td>
+<td>latest Gingerbread version, Nexus S 4G</td>
+</tr>
+<tr>
+<td>ITL41D</td>
+<td>android-4.0.1_r1</td>
+<td>earliest Ice Cream Sandwich version, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ITL41D</td>
+<td>android-4.0.1_r1.1</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ITL41F</td>
+<td>android-4.0.1_r1.2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>ICL53F</td>
+<td>android-4.0.2_r1</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IML74K</td>
+<td>android-4.0.3_r1</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>IML77</td>
+<td>android-4.0.3_r1.1</td>
+<td></td>
+</tr>
+<tr>
+<td>IMM76</td>
+<td>android-4.0.4_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>IMM76D</td>
+<td>android-4.0.4_r1.1</td>
+<td>Nexus S, Nexus S 4G, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76I</td>
+<td>android-4.0.4_r1.2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76K</td>
+<td>android-4.0.4_r2</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>IMM76L</td>
+<td>android-4.0.4_r2.1</td>
+<td>latest Ice Cream Sandwich version</td>
+</tr>
+<tr>
+<td>JRO03C</td>
+<td>android-4.1.1_r1</td>
+<td>earliest Jelly Bean version, Galaxy Nexus</td>
+</tr>
+<tr>
+<td>JRO03D</td>
+<td>android-4.1.1_r1.1</td>
+<td>Nexus 7</td>
+</tr>
+<tr>
+<td>JRO03E</td>
+<td>android-4.1.1_r2</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>JRO03H</td>
+<td>android-4.1.1_r3</td>
+<td></td>
+</tr>
+<tr>
+<td>JRO03L</td>
+<td>android-4.1.1_r4</td>
+<td>Nexus S</td>
+</tr>
+<tr>
+<td>JRO03O</td>
+<td>android-4.1.1_r5</td>
+<td>Galaxy Nexus</td>
+</tr>
+<tr>
+<td>JRO03R</td>
+<td>android-4.1.1_r6</td>
+<td>Nexus S 4G</td>
+</tr>
+<tr>
+<td>JRO03S</td>
+<td>android-4.1.1_r6.1</td>
+<td>Nexus 7</td>
+</tr>
+<tr>
+<td>JZO54K</td>
+<td>android-4.1.2_r1</td>
+<td>Nexus S, Galaxy Nexus, Nexus 7</td>
+</tr>
+<tr>
+<td>JOP40C</td>
+<td>android-4.2_r1</td>
+<td>Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
+</tr>
+<tr>
+<td>JOP40D</td>
+<td>android-4.2.1_r1</td>
+<td>latest Jelly Bean version, Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10</td>
+</tr>
+</tbody>
+</table>
+<p>The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
+jb-mr1-dev,
+represent development
+branches that do not exactly match configurations that were tested
+by Google. They might contain a variety of changes in addition to
+the official tagged releases, and those haven't been as thoroughly
+tested.</p>
+
+<h2 id="honeycomb-gpl-modules">Honeycomb GPL Modules</h2>
+<p>For Honeycomb, the entire platform source code isn't available.
+However, the parts of Honeycomb licensed under the GPL and LGPL
+are available under the following tags:</p>
+<table>
+<thead>
+<tr>
+<th>Build</th>
+<th>Tag</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>HRI39</td>
+<td>android-3.0_r1</td>
+<td>earliest Honeycomb version</td>
+</tr>
+<tr>
+<td>HRI66</td>
+<td>android-3.0_r1.1</td>
+<td></td>
+</tr>
+<tr>
+<td>HWI69</td>
+<td>android-3.0_r1.2</td>
+<td></td>
+</tr>
+<tr>
+<td>HRI93</td>
+<td>android-3.0_r1.3</td>
+<td></td>
+</tr>
+<tr>
+<td>HMJ37</td>
+<td>android-3.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTJ85B</td>
+<td>android-3.2_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTK55D</td>
+<td>android-3.2.1_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HTK75D</td>
+<td>android-3.2.1_r2</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75C</td>
+<td>android-3.2.2_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75D</td>
+<td>android-3.2.2_r2</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75F</td>
+<td>android-3.2.4_r1</td>
+<td></td>
+</tr>
+<tr>
+<td>HLK75H</td>
+<td>android-3.2.6_r1</td>
+<td>latest Honeycomb version</td>
+</tr>
+</tbody>
+</table>
+<p>There is no manifest that contains exactly those. However, there
+are manifests that allow building those components. The following
+commands work for 3.0_r1.1, and using other versions can be done by
+switching the git checkout paramater, and if necessary the -m parameter in
+repo init. The git checkout command outputs an error for the non-GPL
+projects, where it can't find the tag in question.</p>
+<pre><code>$ repo init -b master -m base-for-3.0-gpl.xml
+$ repo sync
+$ repo forall -c git checkout android-3.0_r1.1
+</code></pre>
+
diff --git a/src/source/build-numbers.md b/src/source/build-numbers.md
deleted file mode 100644
index 807152f..0000000
--- a/src/source/build-numbers.md
+++ /dev/null
@@ -1,162 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Codenames, Tags, and Build Numbers #
-
-At a high level, Android development happens around families of
-releases, which use code names ordered alphabetically after tasty
-treats.
-
-## Platform code names, versions, API levels, and NDK releases ##
-
-The code names match the following version numbers, along with
-API levels and NDK releases provided for convenience:
-
-Code name | Version | API level
------------------|---------------|--------------------
-(no code name) | 1.0 | API level 1
-(no code name) | 1.1 | API level 2
-Cupcake | 1.5 | API level 3, NDK 1
-Donut | 1.6 | API level 4, NDK 2
-Eclair | 2.0 | API level 5
-Eclair | 2.0.1 | API level 6
-Eclair | 2.1 | API level 7, NDK 3
-Froyo | 2.2.x | API level 8, NDK 4
-Gingerbread | 2.3 - 2.3.2 | API level 9, NDK 5
-Gingerbread | 2.3.3 - 2.3.7 | API level 10
-Honeycomb | 3.0 | API level 11
-Honeycomb | 3.1 | API level 12, NDK 6
-Honeycomb | 3.2.x | API level 13
-Ice Cream Sandwich | 4.0.1 - 4.0.2 | API level 14, NDK 7
-Ice Cream Sandwich | 4.0.3 - 4.0.4 | API level 15, NDK 8
-Jelly Bean | 4.1.x | API level 16
-
-Starting with Cupcake, individual builds are identified with a short
-build code, e.g. FRF85B.
-
-The first letter is the code name of the release family, e.g. F is
-Froyo.
-
-The second letter is a branch code that allows Google to identify
-the exact code branch that the build was made from, and R is by
-convention the primary release branch.
-
-The next letter and two digits are a date code. The letter counts
-quarters, with A being Q1 2009. Therefore, F is Q2 2010. The two
-digits count days within the quarter, so F85 is June 24 2010.
-
-Finally, the last letter identifies individual versions related to
-the same date code, sequentially starting with A; A is actually
-implicit and usually omitted for brevity.
-
-The date code is not guaranteed to be the exact date at which a build
-was made, and it is common that minor variations added to an existing
-build re-use the same date code as that existing build.
-
-## Source code tags and builds ##
-
-Starting with Donut, the exact list of tags and builds is in the
-following table:
-
-Build | Tag | Notes
--------|--------------------|-----------------------------------
-DRC83 | android-1.6_r1.1 | earliest Donut version, ADP1, ADP2
-DRC92 | android-1.6_r1.2
-DRD08 | android-1.6_r1.3
-DRD20 | android-1.6_r1.4
-DMD64 | android-1.6_r1.5 | latest Donut version
-ESD20 | android-2.0_r1 | earliest Eclair version
-ESD56 | android-2.0.1_r1
-ERD79 | android-2.1_r1 | Nexus One
-ERE27 | android-2.1_r2 | Nexus One
-EPE54B | android-2.1_r2.1p | Nexus One
-ESE81 | android-2.1_r2.1s
-EPF21B | android-2.1_r2.1p2 | latest Eclair version
-FRF85B | android-2.2_r1 | earliest Froyo version, Nexus One
-FRF91 | android-2.2_r1.1 | Nexus One
-FRG01B | android-2.2_r1.2
-FRG22D | android-2.2_r1.3
-FRG83 | android-2.2.1_r1 | Nexus One
-FRG83D | android-2.2.1_r2 | Nexus One
-FRG83G | android-2.2.2_r1 | Nexus One
-FRK76 | android-2.2.3_r1
-FRK76C | android-2.2.3_r2 | latest Froyo version
-GRH55 | android-2.3_r1 | earliest Gingerbread version, Nexus S
-GRH78 | android-2.3.1_r1 | Nexus S
-GRH78C | android-2.3.2_r1 | Nexus S
-GRI40 | android-2.3.3_r1 | Nexus One, Nexus S
-GRI54 | android-2.3.3_r1.1 | Nexus S
-GRJ06D | android-2.3.4_r0.9 | Nexus S 4G
-GRJ22 | android-2.3.4_r1 | Nexus One, Nexus S, Nexus S 4G
-GRJ90 | android-2.3.5_r1 | Nexus S 4G
-GRK39C | android-2.3.6_r0.9 | Nexus S
-GRK39F | android-2.3.6_r1 | Nexus One, Nexus S
-GWK74 | android-2.3.7_r1 | latest Gingerbread version, Nexus S 4G
-ITL41D | android-4.0.1_r1 | earliest Ice Cream Sandwich version, Galaxy Nexus
-ITL41D | android-4.0.1_r1.1 | Galaxy Nexus
-ITL41F | android-4.0.1_r1.2 | Galaxy Nexus
-ICL53F | android-4.0.2_r1 | Galaxy Nexus
-IML74K | android-4.0.3_r1 | Nexus S
-IML77 | android-4.0.3_r1.1 |
-IMM76 | android-4.0.4_r1 |
-IMM76D | android-4.0.4_r1.1 | Nexus S, Nexus S 4G, Galaxy Nexus
-IMM76I | android-4.0.4_r1.2 | Galaxy Nexus
-IMM76K | android-4.0.4_r2 | Galaxy Nexus
-IMM76L | android-4.0.4_r2.1 | latest Ice Cream Sandwich version
-JRO03C | android-4.1.1_r1 | earliest Jelly Bean version, Galaxy Nexus
-JRO03D | android-4.1.1_r1.1 | Nexus 7
-JRO03E | android-4.1.1_r2 | Nexus S
-JRO03H | android-4.1.1_r3 |
-JRO03L | android-4.1.1_r4 | latest Jelly Bean version, Nexus S
-
-The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev,
-represent development
-branches that do not exactly match configurations that were tested
-by Google. They might contain a variety of changes in addition to
-the official tagged releases, and those haven't been as thoroughly
-tested.
-
-## Honeycomb GPL modules ##
-
-For Honeycomb, the entire platform source code isn't available.
-However, the parts of Honeycomb licensed under the GPL and LGPL
-are available under the following tags:
-
-Build | Tag | Notes
--------|--------------------|-----------------------------------
-HRI39 | android-3.0_r1 | earliest Honeycomb version
-HRI66 | android-3.0_r1.1
-HWI69 | android-3.0_r1.2
-HRI93 | android-3.0_r1.3
-HMJ37 | android-3.1_r1
-HTJ85B | android-3.2_r1
-HTK55D | android-3.2.1_r1
-HTK75D | android-3.2.1_r2
-HLK75C | android-3.2.2_r1
-HLK75D | android-3.2.2_r2
-HLK75F | android-3.2.4_r1
-HLK75H | android-3.2.6_r1 | latest Honeycomb version
-
-There is no manifest that contains exactly those. However, there
-are manifests that allow building those components. The following
-commands work for 3.0_r1.1, and using other versions can be done by
-switching the git checkout paramater, and if necessary the -m parameter in
-repo init. The git checkout command outputs an error for the non-GPL
-projects, where it can't find the tag in question.
-
- $ repo init -b master -m base-for-3.0-gpl.xml
- $ repo sync
- $ repo forall -c git checkout android-3.0_r1.1
diff --git a/src/source/building-devices.jd b/src/source/building-devices.jd
new file mode 100644
index 0000000..077d448
--- /dev/null
+++ b/src/source/building-devices.jd
@@ -0,0 +1,274 @@
+page.title=Building for devices
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>This page complements the main page about
+<a href="building-running.html">Building and Running</a> with
+information that is specific to individual devices.</p>
+<p>With the current release, it is possible to build for
+Nexus 10, for Nexus 7 (Wi-Fi), and for some variants of Galaxy Nexus.
+The exact level of functionality for each device depends on the availability
+of the relevant proprietary hardware-specific binaries.</p>
+<p>All configurations of Nexus 10 can be used. On those devices, graphics, audio,
+Wi-Fi, Bluetooth, camera, NFC, GPS and orientation sensors are functional.</p>
+<p>Nexus 4 cannot be used at the moment.</p>
+<p>The Wi-Fi variants of Nexus 7 can be used. On Nexus 7, graphics and audio are
+functional, as well as Wi-Fi and Bluetooth. Due to hardware differences, do
+not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2 or newer.
+The Mobile variant is not supported.</p>
+<p>The variants of Galaxy Nexus that can be used are the GSM/HSPA+ configuration
+"maguro" (only if it was originally sold with a "yakju" or "takju" operating
+system) and the VZW CDMA/LTE configuration "toro". On those devices, graphics
+and audio are functional, as well as Wi-Fi, Bluetooth, and access to the
+respective cellular networks. NFC and the orientation sensors are functional.</p>
+<p>The Sprint CDMA/LTE configuration "toroplus" of Galaxy Nexus is supported
+experimentally. On that configuration, the cellular network is not functional,
+and the other peripherals work like they do on "toro".</p>
+<p>The Motorola Xoom can be used in the Wi-Fi configuration "wingray"
+sold in the USA, with Android 4.1.2. Graphics and audio are functional
+as well as Wi-Fi and Bluetooth and the orientation sensors.</p>
+<p>All configurations of Nexus S and Nexus S 4G can be used with Android 4.1.2.
+On those devices all the peripherals are functional: graphics, audio, Wi-Fi,
+Bluetooth, cell networks, sensors, camera, hardware codecs, NFC, GPS.</p>
+<p>In addition, <a href="http://pandaboard.org">PandaBoard</a> a.k.a. "panda" can be used
+in the master branch, but is considered experimental.
+The specific details to use a PandaBoard with the Android Open-Source Project
+are in the file <code>device/ti/panda/README</code> in the source tree.</p>
+<p>Nexus One a.k.a. "passion" is obsolete, was experimental in gingerbread,
+and can't be used with newer versions of the Android Open-Source
+Project.</p>
+<p>Android Developer Phones (ADP1 and ADP2, a.k.a. "dream" and "sapphire") are
+obsolete, were experimental in froyo, and can't be used with
+newer versions of the Android Open-Source Project.</p>
+<h2 id="building-fastboot-and-adb">Building fastboot and adb</h2>
+<p>If you don't already have those tools, fastboot and adb can be built with
+the regular build system. Follow the instructions on the page about
+<a href="building-running.html">Building and Running</a>, and replace the main <code>make</code> command with</p>
+<pre><code>$ make fastboot adb
+</code></pre>
+<h2 id="booting-into-fastboot-mode">Booting into fastboot mode</h2>
+<p>During a cold boot, the following key combinations can be used to boot into fastboot mode,
+which is a mode in the bootloader that can be used to flash the devices:</p>
+<table>
+<thead>
+<tr>
+<th>Device</th>
+<th>Keys</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>manta</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>mako</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>grouper</td>
+<td>Press <em>Power</em> for a second, and press <em>Volume Down</em> when the bootloader logo appears</td>
+</tr>
+<tr>
+<td>tilapia</td>
+<td>Press <em>Power</em> for a second, and press <em>Volume Down</em> when the bootloader logo appears</td>
+</tr>
+<tr>
+<td>phantasm</td>
+<td>Power the device, cover it with one hand after the LEDs light up and until they turn red</td>
+</tr>
+<tr>
+<td>maguro</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>toro</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>toroplus</td>
+<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>panda</td>
+<td>Press and hold <em>Input</em>, then press <em>Power</em></td>
+</tr>
+<tr>
+<td>wingray</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>crespo</td>
+<td>Press and hold <em>Volume Up</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>crespo4g</td>
+<td>Press and hold <em>Volume Up</em>, then press and hold <em>Power</em></td>
+</tr>
+</tbody>
+</table>
+<p>Also, the command <code>adb reboot bootloader</code> can be used to reboot from
+Android directly into the bootloader with no key combinations.</p>
+<h2 id="unlocking-the-bootloader">Unlocking the bootloader</h2>
+<p>It's only possible to flash a custom system if the bootloader allows it.</p>
+<p>The bootloader is locked by default. With the device in fastboot mode, the
+bootloader is unlocked with</p>
+<pre><code>$ fastboot oem unlock
+</code></pre>
+<p>The procedure must be confirmed on-screen, and deletes the user data for
+privacy reasons. It only needs to be run once.</p>
+<p>All data on the phone is erased, i.e. both the applications' private data
+and the shared data that is accessible over USB, including photos and
+movies. Be sure to make a backup of any precious files you have before
+unlocking the bootloader.</p>
+<p>On Nexus 10, after unlocking the bootloader, the internal storage is
+left unformatted and must be formatted with</p>
+<pre><code>$ fastboot format cache
+$ fastboot format userdata
+</code></pre>
+<p>The bootloader can be locked back with</p>
+<pre><code>$ fastboot oem lock
+</code></pre>
+<p>Note that this erases user data on Xoom (including the shared USB data).</p>
+<h2 id="obtaining-proprietary-binaries">Obtaining proprietary binaries</h2>
+<p>The Android Open-Source Project can't be used
+from pure source code only, and requires additional hardware-related proprietary
+libraries to run, specifically for hardware graphics acceleration.</p>
+<p>Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, Nexus 4,
+Nexus 10 and PandaBoard
+can be downloaded from
+<a href="https://developers.google.com/android/nexus/drivers">Google's Nexus driver page</a>,
+which add access to additional hardware capabilities with non-Open-Source code.</p>
+<p>When using the master branch for a device, the binaries for the most
+recent numbered release are the ones that should be used in the master
+branch.</p>
+<h3 id="extracting-the-proprietary-binaries">Extracting the proprietary binaries</h3>
+<p>Each set of binaries comes as a self-extracting script in a compressed archive.
+After uncompressing each archive, run the included self-extracting script
+from the root of the source tree, confirm that you agree to the terms of the
+enclosed license agreement, and the binaries and their matching makefiles
+will get installed in the <code>vendor/</code> hierarchy of the source tree.</p>
+<h3 id="cleaning-up-when-adding-proprietary-binaries">Cleaning up when adding proprietary binaries</h3>
+<p>In order to make sure that the newly installed binaries are properly
+taken into account after being extracted, the existing output of any previous
+build needs to be deleted with</p>
+<pre><code>$ make clobber
+</code></pre>
+<h2 id="picking-and-building-the-configuration-that-matches-a-device">Picking and building the configuration that matches a device</h2>
+<p>The steps to configure and build the Android Open-Source Project
+are described in the page about <a href="building-running.html">Building and Running</a>.</p>
+<p>The recommended builds for the various devices are available through
+the lunch menu, accessed when running the <code>lunch</code> command with no arguments:</p>
+<table>
+<thead>
+<tr>
+<th>Device</th>
+<th>Branch</th>
+<th>Build configuration</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>manta</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_manta-userdebug</td>
+</tr>
+<tr>
+<td>grouper</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_grouper-userdebug</td>
+</tr>
+<tr>
+<td>tipalia</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_tilapia-userdebug</td>
+</tr>
+<tr>
+<td>maguro</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_maguro-userdebug</td>
+</tr>
+<tr>
+<td>toro</td>
+<td>android-4.2.1_r1 or master</td>
+<td>full_toro-userdebug</td>
+</tr>
+<tr>
+<td>toroplus</td>
+<td>master</td>
+<td>full_toroplus-userdebug</td>
+</tr>
+<tr>
+<td>panda</td>
+<td>master</td>
+<td>full_panda-userdebug</td>
+</tr>
+<tr>
+<td>wingray</td>
+<td>android-4.1.2_r1</td>
+<td>full_wingray-userdebug</td>
+</tr>
+<tr>
+<td>crespo</td>
+<td>android-4.1.2_r1</td>
+<td>full_crespo-userdebug</td>
+</tr>
+<tr>
+<td>crespo4g</td>
+<td>android-4.1.2_r1</td>
+<td>full_crespo4g-userdebug</td>
+</tr>
+</tbody>
+</table>
+<p>Do not use 4.1.1 on a Nexus 7 that was originally sold with 4.1.2
+or newer.</p>
+<h2 id="flashing-a-device">Flashing a device</h2>
+<p>Set the device in fastboot mode if necessary (see above).</p>
+<p>An entire Android system can be flashed in a single command: this writes
+the boot, recovery and system partitions together after verifying that the
+system being flashed is compatible with the installed bootloader and radio,
+and reboots the system. This also erases all the user data, similarly to
+<code>fastboot oem unlock</code> mentioned earlier.</p>
+<pre><code>$ fastboot -w flashall
+</code></pre>
+<p>Note that filesystems created via fastboot on Motorola Xoom aren't working
+optimally, and it is strongly recommended to re-create them through recovery</p>
+<pre><code>$ adb reboot recovery
+</code></pre>
+<p>Once in recovery, open the menu (press Power + Volume Up), wipe the cache
+partition, then wipe data.</p>
+<h2 id="restoring-a-device-to-its-original-factory-state">Restoring a device to its original factory state</h2>
+<p>Factory images
+for Nexus 10,
+for Nexus 4,
+for Nexus Q,
+for Nexus 7 (all variants),
+for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju",
+and CDMA/LTE "mysid" and "mysidspr"),
+and
+for Nexus S and Nexus S 4G (all variants)
+are available from
+<a href="https://developers.google.com/android/nexus/images">Google's factory image page</a>.</p>
+<p>Factory images for the Motorola Xoom are distributed directly by Motorola.</p>
\ No newline at end of file
diff --git a/src/source/building-devices.md b/src/source/building-devices.md
deleted file mode 100644
index 9c2ab82..0000000
--- a/src/source/building-devices.md
+++ /dev/null
@@ -1,204 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building for devices #
-
-This page complements the main page about [Building](building.html) with
-information that is specific to individual devices.
-
-With the current release, it is possible to build for Nexus 7, for some
-variants of Galaxy Nexus, for a variant of the Motorola Xoom, and for
-all variants of Nexus S and Nexus S 4G. The exact level of functionality
-for each device depends on the availability of the relevant proprietary
-hardware-specific binaries.
-
-All variants of Nexus 7 can be used. On Nexus 7, graphics and audio are
-functional, as well as WiFi and Bluetooth.
-
-The variants of Galaxy Nexus that be used are the GSM/HSPA+ configuration
-"maguro" (only if it was originally sold with a "yakju" or "takju" operating
-system) and the VZW CDMA/LTE configuration "toro". On those devices, graphics
-and audio are functional, as well as WiFi, Bluetooth, and access to the
-respective cellular networks. The orientation sensors are functional.
-
-The Motorola Xoom is can be used in the Wi-Fi configuration "wingray"
-sold in the USA. Graphics and audio are functional as well as WiFi and
-Bluetooth and the orientation sensors.
-
-All configurations of Nexus S and Nexus S 4G can be used, and on those
-devices all the peripherals are functional: graphics, audio, Wifi, Bluetooth,
-cell networks, sensors, camera, hardware codecs, NFC, GPS.
-
-In addition, [PandaBoard](http://pandaboard.org) a.k.a. "panda" can be used
-in the master branch, but is considered experimental.
-The specific details to use a PandaBoard with the Android Open-Source Project
-are in the file `device/ti/panda/README` in the source tree.
-
-Nexus One a.k.a. "passion" is obsolete, was experimental in gingerbread,
-and can't be used with newer versions of the Android Open-Source
-Project.
-
-Android Developer Phones (ADP1 and ADP2, a.k.a. "dream" and "sapphire") are
-obsolete, were experimental in froyo, and can't be used with
-newer versions of the Android Open-Source Project.
-
-## Building fastboot and adb ##
-
-If you don't already have those tools, fastboot and adb can be built with
-the regular build system. Follow the instructions on the page about
-[building](building.html), and replace the main `make` command with
-
- $ make fastboot adb
-
-## Booting into fastboot mode ##
-
-During a cold boot, the following key combinations can be used to boot into fastboot mode,
-which is a mode in the bootloader that can be used to flash the devices:
-
-Device | Keys
----------|------
-grouper | Press *Power* for a second, and press *Volume Down* when the bootloader logo appears
-maguro | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
-toro | Press and hold both *Volume Up* and *Volume Down*, then press and hold *Power*
-panda | Press and hold *Input*, then press *Power*
-wingray | Press and hold *Volume Down*, then press and hold *Power*
-crespo | Press and hold *Volume Up*, then press and hold *Power*
-crespo4g | Press and hold *Volume Up*, then press and hold *Power*
-passion | Press and hold the trackball, then press *Power*
-sapphire | Press and hold *Back*, then press *Power*
-dream | Press and hold *Back*, then press *Power*
-
-Also, the command `adb reboot bootloader` can be used to reboot from
-Android directly into the bootloader with no key combinations.
-
-## Unlocking the bootloader ##
-
-It's only possible to flash a custom system if the bootloader allows it.
-
-This is the default setup on ADP1 and ADP2.
-
-On Nexus One, Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-the bootloader is locked by default. With the device in fastboot mode, the
-bootloader is unlocked with
-
- $ fastboot oem unlock
-
-The procedure must be confirmed on-screen, and deletes the user data for
-privacy reasons. It only needs to be run once.
-
-Note that on the Nexus S, Nexus S 4G, Motorola Xoom, Galaxy Nexus,
-and on Nexus 7,
-all data on the phone is erased, i.e. both the applications' private data
-and the shared data that is accessible over USB, including photos and
-movies. Be sure to make a backup of any precious files you have before
-unlocking the bootloader.
-
-On Nexus One, the operation voids the warranty and is irreversible.
-
-On Nexus S, Nexus S 4G, Xoom, Galaxy Nexus, and Nexus 7,
-the bootloader can be locked back with
-
- $ fastboot oem lock
-
-Note that this erases user data on Xoom (including the shared USB data).
-
-## Obtaining proprietary binaries ##
-
-Starting with Ice Cream Sandwich, the Android Open-Source Project can't be used
-from pure source code only, and requires additional hardware-related proprietary
-libraries to run, specifically for hardware graphics acceleration.
-
-Official binaries for Nexus S, Nexus S 4G, Galaxy Nexus, Nexus 7, and PandaBoard
-can be downloaded from
-[Google's Nexus driver page](https://developers.google.com/android/nexus/drivers),
-which add access to additional hardware capabilities with non-Open-Source code.
-
-When using the master branch for a device, the binaries for the most
-recent numbered release are the ones that should be used in the master
-branch.
-
-There are limited binaries for Nexus One, and none for ADP2 or ADP1.
-
-### Extracting the proprietary binaries ###
-
-Each set of binaries comes as a self-extracting script in a compressed archive.
-After uncompressing each archive, run the included self-extracting script
-from the root of the source tree, confirm that you agree to the terms of the
-enclosed license agreement, and the binaries and their matching makefiles
-will get installed in the `vendor/` hierarchy of the source tree.
-
-### Cleaning up when adding proprietary binaries ###
-
-In order to make sure that the newly installed binaries are properly
-taken into account after being extracted, the existing output of any previous
-build needs to be deleted with
-
- $ make clobber
-
-## Picking and building the configuration that matches a device ##
-
-The steps to configure and build the Android Open-Source Project
-are described in the page about [Building](building.html).
-
-The recommended builds for the various devices are available through
-the lunch menu, accessed when running the `lunch` command with no arguments:
-
-Device | Branch | Build configuration
----------|------------------------------|------------------------
-grouper | android-4.1.1_r4 or master | full_grouper-userdebug
-maguro | android-4.1.1_r4 or master | full_maguro-userdebug
-toro | android-4.1.1_r4 or master | full_toro-userdebug
-panda | master | full_panda-userdebug
-wingray | android-4.1.1_r4 or master | full_wingray-userdebug
-crespo | android-4.1.1_r4 or master | full_crespo-userdebug
-crespo4g | android-4.1.1_r4 or master | full_crespo4g-userdebug
-passion | android-2.3.7_r1 | full_passion-userdebug
-sapphire | android-2.2.3_r1 | full_sapphire-userdebug
-dream | android-2.2.3_r1 | full_dream-userdebug
-
-## Flashing a device ##
-
-Set the device in fastboot mode if necessary (see above).
-
-An entire Android system can be flashed in a single command: this writes
-the boot, recovery and system partitions together after verifying that the
-system being flashed is compatible with the installed bootloader and radio,
-and reboots the system. This also erases all the user data, similarly to
-`fastboot oem unlock` mentioned earlier.
-
- $ fastboot -w flashall
-
-Note that filesystems created via fastboot on Motorola Xoom aren't working
-optimally, and it is strongly recommended to re-create them through recovery
-
- $ adb reboot recovery
-
-Once in recovery, open the menu (press Power + Volume Up), wipe the cache
-partition, then wipe data.
-
-## Restoring a device to its original factory state ##
-
-Factory images
-for Nexus 7,
-for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju", and CDMA/LTE "mysid"),
-and
-for Nexus S and Nexus S 4G (all variants)
-are available from
-[Google's factory image page](https://developers.google.com/android/nexus/images).
-
-Factory images for the Motorola Xoom are distributed directly by Motorola.
-
-No factory images are available for Nexus One.
diff --git a/src/source/building-dream.jd b/src/source/building-dream.jd
new file mode 100644
index 0000000..b454ba8
--- /dev/null
+++ b/src/source/building-dream.jd
@@ -0,0 +1,62 @@
+page.title=Building for an Android Dev Phone
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p><em>The information on this page is a bit out of date. We'll update this
+page as soon as we can.</em></p>
+<p>The basic manifest for 1.6 defines which projects are
+needed to do a generic build for the emulator or for unlocked Dream devices
+(e.g. the Android Dev Phone 1). You need to have an appropriate device running
+a matching official image.</p>
+<p>To build donut for dream (your
+device needs to be an ADP1 running an official 1.6 system):</p>
+<ol>
+<li>
+<p>Follow the <a href="downloading.html">normal steps</a> to setup repo and check out the sources.</p>
+</li>
+<li>
+<p>At the root of your source tree, run <code>. build/envsetup.sh</code> like you normally would for an emulator build.</p>
+</li>
+<li>
+<p>Run <code>make adb</code> if you don't already have adb in your path.</p>
+</li>
+<li>
+<p>run <code>adb root</code>.</p>
+</li>
+<li>
+<p>in <code>vendor/htc/dream-open/</code> there is a script called "extract-files.sh" that must be run (from that directory) to extract some proprietary binaries from your device (*). You only need to do this once.</p>
+</li>
+<li>
+<p>run <code>lunch aosp_dream_us-eng</code> to specifically configure the build system for dream (the default is the equivalent of "lunch generic-eng", which doesn't contain dream-specific files).</p>
+</li>
+<li>
+<p>run make from the top of the source tree.</p>
+</li>
+<li>
+<p>from this point, the fastboot tool (which is put automatically in your path) can be used to flash a device: boot the device into the bootloader by holding the back key while pressing the power key, and run <code>fastboot -w flashall</code>.</p>
+</li>
+</ol>
+<p>Note: these instructions work for the sapphire (ADP2) build target, as
+well. Simply replace "dream" with "sapphire" above.</p>
\ No newline at end of file
diff --git a/src/source/building-dream.md b/src/source/building-dream.md
deleted file mode 100644
index 74f7521..0000000
--- a/src/source/building-dream.md
+++ /dev/null
@@ -1,48 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building for an Android Dev Phone #
-
-*The information on this page is a bit out of date. We'll update this
-page as soon as we can.*
-
-The basic manifest for 1.6 defines which projects are
-needed to do a generic build for the emulator or for unlocked Dream devices
-(e.g. the Android Dev Phone 1). You need to have an appropriate device running
-a matching official image.
-
-To build donut for dream (your
-device needs to be an ADP1 running an official 1.6 system):
-
-1. Follow the [normal steps](downloading.html) to setup repo and check out the sources.
-
-2. At the root of your source tree, run `. build/envsetup.sh` like you normally would for an emulator build.
-
-3. Run `make adb` if you don't already have adb in your path.
-
-4. run `adb root`.
-
-5. in `vendor/htc/dream-open/` there is a script called "extract-files.sh" that must be run (from that directory) to extract some proprietary binaries from your device (*). You only need to do this once.
-
-6. run `lunch aosp_dream_us-eng` to specifically configure the build system for dream (the default is the equivalent of "lunch generic-eng", which doesn't contain dream-specific files).
-
-7. run make from the top of the source tree.
-
-8. from this point, the fastboot tool (which is put automatically in your path) can be used to flash a device: boot the device into the bootloader by holding the back key while pressing the power key, and run `fastboot -w flashall`.
-
-Note: these instructions work for the sapphire (ADP2) build target, as
-well. Simply replace "dream" with "sapphire" above.
-
diff --git a/src/source/building-kernels.jd b/src/source/building-kernels.jd
new file mode 100644
index 0000000..0b20a50
--- /dev/null
+++ b/src/source/building-kernels.jd
@@ -0,0 +1,95 @@
+page.title=Building Kernels
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>If you are only interested in the kernel, you may use this guide
+to download and build the appropriate kernel.</p>
+<p>The following instructions assume that you have not downloaded all
+of AOSP. If you have downloaded all of AOSP, you may skip the git
+clone steps other than the step to download the actual kernel sources.</p>
+<p>We will use the Pandaboard kernel in all the following examples.</p>
+<h2 id="figuring-out-which-kernel-to-build">Figuring out which kernel to build</h2>
+<p>You will want to look at the git log for the kernel in the device project that
+you are interested in.
+Device projects are of the form device/<vendor>/<name>.</p>
+<pre><code>$ git clone https://android.googlesource.com/device/ti/panda
+$ cd panda
+$ git log kernel
+</code></pre>
+<p>The log should contain notes of the commit SHA1 for the appropriate
+kernel project. Keep this value at hand so that you can use it in
+a later step.</p>
+<h2 id="downloading-sources">Downloading sources</h2>
+<p>Depending on which kernel you want,</p>
+<pre><code>$ git clone https://android.googlesource.com/kernel/common.git
+$ git clone https://android.googlesource.com/kernel/exynos.git
+$ git clone https://android.googlesource.com/kernel/goldfish.git
+$ git clone https://android.googlesource.com/kernel/msm.git
+$ git clone https://android.googlesource.com/kernel/omap.git
+$ git clone https://android.googlesource.com/kernel/samsung.git
+$ git clone https://android.googlesource.com/kernel/tegra.git
+</code></pre>
+<ul>
+<li>The <code>goldfish</code> project contains the kernel sources for the emulated
+platforms.</li>
+<li>The <code>msm</code> project has the sources for ADP1, ADP2, Nexus One, Nexus 4,
+and can be used as a starting point for work on Qualcomm MSM chipsets.</li>
+<li>The <code>omap</code> project is used for PandaBoard and Galaxy Nexus,
+and can be used as a starting point for work on TI OMAP chipsets.</li>
+<li>The <code>samsung</code> project is used for Nexus S,
+and can be used as a starting point for work on Samsung Hummingbird chipsets.</li>
+<li>The <code>tegra</code> project is for Xoom and Nexus 7,
+and can be used as a starting point for work on NVIDIA Tegra chipsets.</li>
+<li>The <code>exynos</code> project has the kernel sources for Nexus 10,
+and can be used as a starting point for work on Samsung Exynos chipsets.</li>
+</ul>
+<h2 id="downloading-a-prebuilt-gcc">Downloading a prebuilt gcc</h2>
+<p>Ensure that the prebuilt toolchain is in your path.</p>
+<pre><code>$ git clone https://android.googlesource.com/platform/prebuilt
+$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
+</code></pre>
+<h2 id="building">Building</h2>
+<p>As an example, we would build the panda kernel using the following commands:</p>
+<pre><code>$ export ARCH=arm
+$ export SUBARCH=arm
+$ export CROSS_COMPILE=arm-eabi-
+$ cd omap
+$ git checkout <commit_from_first_step>
+$ make panda_defconfig
+$ make
+</code></pre>
+<p>To build the tuna kernel, you may run the previous commands replacing all
+instances of "panda" with "tuna".</p>
+<ul>
+<li>The kernel for mantaray is <code>device/samsung/manta/kernel</code></li>
+<li>The kernel for mako is <code>device/lge/mako-kernel/kernel</code></li>
+<li>The kernel for grouper and tilapia is <code>device/asus/grouper/kernel</code></li>
+<li>The kernel for maguro and toro is <code>device/samsung/tuna/kernel</code></li>
+<li>The kernel for crespo and crespo4g is <code>device/samsung/crespo/kernel</code></li>
+<li>The kernel for stingray and wingray is <code>device/moto/wingray/kernel</code></li>
+</ul>
+<p>The image is output as <code>arch/arm/boot/zImage</code>. You may copy it as
+<code>device/<vendor>/<name>/kernel</code> or <code>device/ti/panda/kernel</code> in the case of this
+example.</p>
diff --git a/src/source/building-kernels.md b/src/source/building-kernels.md
deleted file mode 100644
index 5c3709d..0000000
--- a/src/source/building-kernels.md
+++ /dev/null
@@ -1,97 +0,0 @@
-<!--
- Copyright 2011 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building Kernels #
-
-If you are only interested in the kernel, you may use this guide
-to download and build the appropriate kernel.
-
-The following instructions assume that you have not downloaded all
-of AOSP. If you have downloaded all of AOSP, you may skip the git
-clone steps other than the step to download the actual kernel sources.
-
-We will use the Pandaboard kernel in all the following examples.
-
-
-## Figuring out which kernel to build ##
-
-You will want to look at the git log for the kernel in the device project that
-you are interested in.
-Device projects are of the form device/<vendor>/<name>.
-
- $ git clone https://android.googlesource.com/device/ti/panda
- $ cd panda
- $ git log kernel
-
-The log should contain notes of the commit SHA1 for the appropriate
-kernel project. Keep this value at hand so that you can use it in
-a later step.
-
-## Downloading sources ##
-
-Depending on which kernel you want,
-
- $ git clone https://android.googlesource.com/kernel/common.git
- $ git clone https://android.googlesource.com/kernel/exynos.git
- $ git clone https://android.googlesource.com/kernel/goldfish.git
- $ git clone https://android.googlesource.com/kernel/msm.git
- $ git clone https://android.googlesource.com/kernel/omap.git
- $ git clone https://android.googlesource.com/kernel/samsung.git
- $ git clone https://android.googlesource.com/kernel/tegra.git
-
- - The `goldfish` project contains the kernel sources for the emulated
-platforms.
- - The `msm` project has the sources for ADP1, ADP2, Nexus One, and
-can be used as a starting point for work on Qualcomm MSM chipsets.
- - The `omap` project is used for PandaBoard and Galaxy Nexus, and
-can be used as a starting point for work on TI OMAP chipsets.
- - The `samsung` project is used for Nexus S and can be used as a
-starting point for work on Samsung Hummingbird chipsets.
- - The `tegra` project is for Xoom and Nexus 7, and can be used as
-a starting point for work on NVIDIA Tegra chipsets.
- - The `exynos` project can be used as a starting point for work
-on Samsung Exynos chipsets.
-
-## Downloading a prebuilt gcc ##
-
-Ensure that the prebuilt toolchain is in your path.
-
- $ git clone https://android.googlesource.com/platform/prebuilt
- $ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
-
-
-## Building ##
-
-As an example, we would build the panda kernel using the following commands:
-
- $ export ARCH=arm
- $ export SUBARCH=arm
- $ export CROSS_COMPILE=arm-eabi-
- $ cd omap
- $ git checkout <commit_from_first_step>
- $ make panda_defconfig
- $ make
-
-To build the tuna kernel, you may run the previous commands replacing all
-instances of "panda" with "tuna".
-
- - The kernel for maguro and toro is `device/samsung/tuna/kernel`
- - The kernel for crespo and crespo4g is `device/samsung/crespo/kernel`
- - The kernel for stingray and wingray is `device/moto/wingray/kernel`
-
-The image is output as `arch/arm/boot/zImage`. You may copy it as
-`device/<vendor>/<name>/kernel` or `device/ti/panda/kernel` in the case of this
-example.
diff --git a/src/source/building-running.jd b/src/source/building-running.jd
new file mode 100644
index 0000000..3fcd457
--- /dev/null
+++ b/src/source/building-running.jd
@@ -0,0 +1,193 @@
+page.title=Building the System
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+The following instructions to build the Android source tree apply to all branches, including master.
+
+<h2 id="choosing-a-branch">Choosing a Branch</h2>
+<p>Some of the requirements for your build environment are determined by which
+version of the source code you plan to compile. See
+<a href="build-numbers.html">Codenames, Tags, and Build Numbers</a> for a full listing of branches you may
+choose from. You may also choose to download and build the latest source code
+(called "master"), in which case you will simply omit the branch specification
+when you initialize the repository.</p>
+<p>Once you have selected a branch, follow the appropriate instructions below to
+set up your build environment.</p>
+
+
+<p>The basic sequence of build commands is as follows:</p>
+<h2 id="initialize">Initialize</h2>
+<p>Initialize the environment with the <code>envsetup.sh</code> script. Note
+that replacing "source" with a single dot saves a few characters,
+and the short form is more commonly used in documentation.</p>
+<pre><code>$ source build/envsetup.sh
+</code></pre>
+<p>or</p>
+<pre><code>$ . build/envsetup.sh
+</code></pre>
+<h2 id="choose-a-target">Choose a Target</h2>
+<p>Choose which target to build with <code>lunch</code>. The exact configuration can be passed as
+an argument, e.g. </p>
+<pre><code>$ lunch full-eng
+</code></pre>
+<p>The example above refers to a complete build for the emulator, with all debugging enabled.</p>
+<p>If run with no arguments <code>lunch</code> will prompt you to choose a target from the menu. </p>
+<p>All build targets take the form BUILD-BUILDTYPE, where the BUILD is a codename
+referring to the particular feature combination. Here's a partial list:</p>
+<table>
+<thead>
+<tr>
+<th>Build name</th>
+<th>Device</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>full</td>
+<td>emulator</td>
+<td>fully configured with all languages, apps, input methods</td>
+</tr>
+<tr>
+<td>full_maguro</td>
+<td>maguro</td>
+<td><code>full</code> build running on Galaxy Nexus GSM/HSPA+ ("maguro")</td>
+</tr>
+<tr>
+<td>full_panda</td>
+<td>panda</td>
+<td><code>full</code> build running on PandaBoard ("panda")</td>
+</tr>
+</tbody>
+</table>
+<p>and the BUILDTYPE is one of the following:</p>
+<table>
+<thead>
+<tr>
+<th>Buildtype</th>
+<th>Use</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>user</td>
+<td>limited access; suited for production</td>
+</tr>
+<tr>
+<td>userdebug</td>
+<td>like "user" but with root access and debuggability; preferred for debugging</td>
+</tr>
+<tr>
+<td>eng</td>
+<td>development configuration with additional debugging tools</td>
+</tr>
+</tbody>
+</table>
+<p>For more information about building for and running on actual hardware, see
+<a href="building-devices.html">Building for Devices</a>.</p>
+<h2 id="build-the-code">Build the Code</h2>
+<p>Build everything with <code>make</code>. GNU make can handle parallel
+tasks with a <code>-jN</code> argument, and it's common to use a number of
+tasks N that's between 1 and 2 times the number of hardware
+threads on the computer being used for the build. E.g. on a
+dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core),
+the fastest builds are made with commands between <code>make -j16</code> and
+<code>make -j32</code>.</p>
+<pre><code>$ make -j4
+</code></pre>
+<h2 id="run-it">Run It!</h2>
+<p>You can either run your build on an emulator or flash it on a device. Please note that you have already selected your build target with <code>lunch</code>, and it is unlikely at best to run on a different target than it was built for.</p>
+<h3 id="flash-a-device">Flash a Device</h3>
+<p>To flash a device, you will need to use <code>fastboot</code>, which should be included in your path after a successful build. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with</p>
+<pre><code>$ adb reboot bootloader
+</code></pre>
+<p>Once the device is in fastboot mode, run </p>
+<pre><code>$ fastboot flashall -w
+</code></pre>
+<p>The <code>-w</code> option wipes the <code>/data</code> partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.</p>
+<p>For more information about building for and running on actual hardware, see
+<a href="building-devices.html">Building for Devices.</a></p>
+<h3 id="emulate-an-android-device">Emulate an Android Device</h3>
+<p>The emulator is added to your path automatically by the build process. To run the emulator, type</p>
+<pre><code>$ emulator
+</code></pre>
+<h1 id="using-ccache">Using ccache</h1>
+<p>ccache is a compiler cache for C and C++ that can help make builds faster.
+In the root of the source tree, do the following:</p>
+<pre><code>$ export USE_CCACHE=1
+$ export CCACHE_DIR=/<path_of_your_choice>/.ccache
+$ prebuilts/misc/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>The suggested cache size is 50-100G.</p>
+<p>You can watch ccache being used by doing the following:</p>
+<pre><code>$ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
+</code></pre>
+<p>On OSX, you should replace <code>linux-x86</code> with <code>darwin-x86</code>.</p>
+<p>When using Ice Cream Sandwich (4.0.x) or older, you should replace
+<code>prebuilts/misc</code> with <code>prebuilt</code>.</p>
+<h1 id="troubleshooting-common-build-errors">Troubleshooting Common Build Errors</h1>
+<h2 id="wrong-java-version">Wrong Java Version</h2>
+<p>If you are attempting to build froyo or earlier with Java 1.6, or gingerbread or later
+with Java 1.5, <code>make</code> will abort with a message such as</p>
+<pre><code>************************************************************
+You are attempting to build with the incorrect version
+of java.
+
+Your version is: WRONG_VERSION.
+The correct version is: RIGHT_VERSION.
+
+Please follow the machine setup instructions at
+ https://source.android.com/source/download.html
+************************************************************
+</code></pre>
+<p>This may be caused by</p>
+<ul>
+<li>
+<p>failing to install the correct JDK as specified in <a href="initializing.html">Initializing the Build Environment</a>. Building Android requires Sun JDK 5 or 6 depending on which release you are building. </p>
+</li>
+<li>
+<p>another JDK that you previously installed appearing in your path. You can remove the offending JDK from your path with:</p>
+<pre><code>$ export PATH=${PATH/\/path\/to\/jdk\/dir:/}
+</code></pre>
+</li>
+</ul>
+<h2 id="python-version-3">Python Version 3</h2>
+<p>Repo is built on particular functionality from Python 2.x and is unfortunately incompatible with Python 3. In order to use repo, please install Python 2.x:</p>
+<pre><code>$ apt-get install python
+</code></pre>
+<h2 id="case-insensitive-filesystem">Case Insensitive Filesystem</h2>
+<p>If you are building on an HFS filesystem on Mac OS X, you may encounter an error such as</p>
+<pre><code>************************************************************
+You are building on a case-insensitive filesystem.
+Please move your source tree to a case-sensitive filesystem.
+************************************************************
+</code></pre>
+<p>Please follow the instructions in <a href="initializing.html">Initializing the Build Environment</a> for creating a case-sensitive disk image.</p>
+<h2 id="no-usb-permission">No USB Permission</h2>
+<p>On most Linux systems, unprivileged users cannot access USB ports by default. If you see a permission denied error, follow the instructions
+<a href="initializing.html">Initializing the Build Environment</a> for configuring USB access. </p>
+<p>If adb was already running and cannot connect to the device after
+getting those rules set up, it can be killed with <code>adb kill-server</code>.
+That will cause adb to restart with the new configuration.</p>
diff --git a/src/source/building.jd b/src/source/building.jd
new file mode 100644
index 0000000..09d7811
--- /dev/null
+++ b/src/source/building.jd
@@ -0,0 +1,60 @@
+page.title=Downloading and Building
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android build is routinely tested in-house on recent versions of
+Ubuntu LTS (10.04), but most distributions should have the required
+build tools available. We welcome reports of successes or failures on other
+distributions.</p>
+
+<p>Before you download and build the Android source, ensure your system meets the following requirements:</p>
+
+<ul>
+
+ <li>A Linux or Mac system. It is also possible
+ to build Android in a virtual machine on unsupported systems such as Windows.
+ If you are running Linux in a virtual machine, you need at
+ least 16GB of RAM/swap and 30GB or more of disk space in order to
+ build the Android tree.
+ </li>
+
+ <li>A 64-bit environment is required for Gingerbread (2.3.x) and newer versions, including the master
+ branch. You can compile older versions on 32-bit systems.
+ </li>
+
+ <li>30GB of free disk space to complete a single build and
+ up to 100GB or more for a full set of builds. The source download is approximately 8.5GB in size.</p>
+ </li>
+
+ <li>
+ Python 2.6 -- 2.7, which you can download from <a href="http://www.python.org/download/">python.org</a>.</p>
+ </li>
+
+ <li>
+ GNU Make 3.81 -- 3.82, which you can download from <a href="http://ftp.gnu.org/gnu/make/">gnu.org</a>,</p>
+ </li>
+
+ <li>
+ JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older.
+ You can download both from <a href="http://java.sun.com/javase/downloads/">java.sun.com</a>.</p>
+ </li>
+
+ <li>
+ Git 1.7 or newer. You can find it at <a href="http://git-scm.com/download">git-scm.com</a>.</p>
+ </li>
+
+</ul>
\ No newline at end of file
diff --git a/src/source/building.md b/src/source/building.md
deleted file mode 100644
index e2de012..0000000
--- a/src/source/building.md
+++ /dev/null
@@ -1,171 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Building the System #
-
-The basic sequence of build commands is as follows:
-
-## Initialize ##
-
-Initialize the environment with the `envsetup.sh` script. Note
-that replacing "source" with a single dot saves a few characters,
-and the short form is more commonly used in documentation.
-
- $ source build/envsetup.sh
-
-or
-
- $ . build/envsetup.sh
-
-## Choose a Target ##
-
-Choose which target to build with `lunch`. The exact configuration can be passed as
-an argument, e.g.
-
- $ lunch full-eng
-
-The example above refers to a complete build for the emulator, with all debugging enabled.
-
-If run with no arguments `lunch` will prompt you to choose a target from the menu.
-
-All build targets take the form BUILD-BUILDTYPE, where the BUILD is a codename
-referring to the particular feature combination. Here's a partial list:
-
-Build name | Device | Notes
-------------|----------|---------------------------
-full | emulator | fully configured with all languages, apps, input methods
-full_maguro | maguro | `full` build running on Galaxy Nexus GSM/HSPA+ ("maguro")
-full_panda | panda | `full` build running on PandaBoard ("panda")
-
-and the BUILDTYPE is one of the following:
-
-Buildtype | Use
-------------|--------------------------------------
-user | limited access; suited for production
-userdebug | like "user" but with root access and debuggability; preferred for debugging
-eng | development configuration with additional debugging tools
-
-For more information about building for and running on actual hardware, see
-[Building for devices](building-devices.html)
-
-## Build the Code ##
-
-Build everything with `make`. GNU make can handle parallel
-tasks with a `-jN` argument, and it's common to use a number of
-tasks N that's between 1 and 2 times the number of hardware
-threads on the computer being used for the build. E.g. on a
-dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core),
-the fastest builds are made with commands between `make -j16` and
-`make -j32`.
-
- $ make -j4
-
-## Run It! ##
-
-You can either run your build on an emulator or flash it on a device. Please note that you have already selected your build target with `lunch`, and it is unlikely at best to run on a different target than it was built for.
-
-### Flash a Device ###
-
-To flash a device, you will need to use `fastboot`, which should be included in your path after a successful build. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with
-
- $ adb reboot bootloader
-
-Once the device is in fastboot mode, run
-
- $ fastboot flashall -w
-
-The `-w` option wipes the `/data` partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.
-
-For more information about building for and running on actual hardware, see
-[Building for devices](building-devices.html)
-
-### Emulate an Android Device ###
-
-The emulator is added to your path automatically by the build process. To run the emulator, type
-
- $ emulator
-
-# Using ccache #
-
-ccache is a compiler cache for C and C++ that can help make builds faster.
-In the root of the source tree, do the following:
-
- $ export USE_CCACHE=1
- $ export CCACHE_DIR=/<path_of_your_choice>/.ccache
- $ prebuilts/misc/linux-x86/ccache/ccache -M 50G
-
-The suggested cache size is 50-100G.
-
-You can watch ccache being used by doing the following:
-
- $ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
-
-On OSX, you should replace `linux-x86` with `darwin-x86`.
-
-When using Ice Cream Sandwich (4.0.x) or older, you should replace
-`prebuilts/misc` with `prebuilt`.
-
-# Troubleshooting Common Build Errors #
-
-## Wrong Java Version ##
-
-If you are attempting to build froyo or earlier with Java 1.6, or gingerbread or later
-with Java 1.5, `make` will abort with a message such as
-
- ************************************************************
- You are attempting to build with the incorrect version
- of java.
-
- Your version is: WRONG_VERSION.
- The correct version is: RIGHT_VERSION.
-
- Please follow the machine setup instructions at
- https://source.android.com/source/download.html
- ************************************************************
-
-This may be caused by
-
-- failing to install the correct JDK as specified on the [Initializing](initializing.html) page. Building Android requires Sun JDK 5 or 6 depending on which release you are building.
-
-- another JDK that you previously installed appearing in your path. You can remove the offending JDK from your path with:
-
- $ export PATH=${PATH/\/path\/to\/jdk\/dir:/}
-
-## Python Version 3 ##
-
-Repo is built on particular functionality from Python 2.x and is unfortunately incompatible with Python 3. In order to use repo, please install Python 2.x:
-
- $ apt-get install python
-
-## Case Insensitive Filesystem ##
-
-If you are building on an HFS filesystem on Mac OS X, you may encounter an error such as
-
- ************************************************************
- You are building on a case-insensitive filesystem.
- Please move your source tree to a case-sensitive filesystem.
- ************************************************************
-
-Please follow the instructions on the [Initializing](initializing.html) page for creating a case-sensitive disk image.
-
-## No USB Permission ##
-
-On most Linux systems, unprivileged users cannot access USB ports by default. If you see a permission denied error, follow the instructions on the [Initializing](initializing.html) page for configuring USB access.
-
-If adb was already running and cannot connect to the device after
-getting those rules set up, it can be killed with `adb kill-server`.
-That will cause adb to restart with the new configuration.
-
diff --git a/src/source/cla-corporate.jd b/src/source/cla-corporate.jd
new file mode 100644
index 0000000..9125a0c
--- /dev/null
+++ b/src/source/cla-corporate.jd
@@ -0,0 +1,81 @@
+page.title=Corporate Contributor License Agreement
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose.</p>
+<p>This version of the Grant allows an entity (the "Corporation") to submit Contributions to the Project Leads, to authorize Contributions submitted by its designated employees to the Project Leads, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Grant to</p>
+<blockquote>
+ Google Inc.<br/>
+ Attn: Open Source Program Office<br/>
+ 1600 Amphitheatre Pkwy<br/>
+ Building 43<br/>
+ Mountain View, CA 94043<br/>
+ U.S.A.
+</blockquote>
+
+<p>Scanned agreements may also be emailed in PDF form to cla-submissions@google.com.</p>
+<p>If necessary, you may send it by facsimile to (650) 887-1625. Please read this document carefully before signing and keep a copy for your records.</p>
+<pre>Corporation name: ___________________________________________________<br><br><br><br>Corporation address: ________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>Point of Contact: ___________________________________________________<br><br><br><br>E-Mail: ____________________________________________________________<br><br><br><br>Telephone: _____________________<br><br><br><br>Fax: ___________________________<br><br></pre>
+
+<p>You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.</p>
+<ol>
+<li>
+<p>Definitions.</p>
+<p>"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant to the Project Leads. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.</p>
+<p>"Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."</p>
+</li>
+<li>
+<p>Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.</p>
+</li>
+<li>
+<p>Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.</p>
+</li>
+<li>
+<p>You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.</p>
+</li>
+<li>
+<p>You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).</p>
+</li>
+<li>
+<p>You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.</p>
+</li>
+<li>
+<p>Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p></p>
+</li>
+<li>
+<p>It is your responsibility to notify the Project Leads when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with the Project.</p>
+</li>
+</ol>
+<pre>
+<br><br>
+Please sign: __________________________________ Date: _______________<br><br>
+Title: _______________________________________________________________<br><br>
+Corporation: __________________________________________________________
+</pre>
+
+<h3 id="schedule-a">Schedule A</h3>
+<p>[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]</p>
+<h3 id="schedule-b">Schedule B</h3>
+<p>[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]</p>
diff --git a/src/source/cla-corporate.md b/src/source/cla-corporate.md
deleted file mode 100644
index ffc193f..0000000
--- a/src/source/cla-corporate.md
+++ /dev/null
@@ -1,74 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Corporate Contributor License Agreement #
-
-In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose.
-
-This version of the Grant allows an entity (the "Corporation") to submit Contributions to the Project Leads, to authorize Contributions submitted by its designated employees to the Project Leads, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Grant to
-
-<blockquote>
- Google Inc.<br/>
- Attn: Open Source Program Office<br/>
- 1600 Amphitheatre Pkwy<br/>
- Building 43<br/>
- Mountain View, CA 94043<br/>
- U.S.A.
-</blockquote>
-
-Scanned agreements may also be emailed in PDF form to cla-submissions@google.com.
-
-If necessary, you may send it by facsimile to (650) 887-1625. Please read this document carefully before signing and keep a copy for your records.
-
-<pre>Corporation name: ___________________________________________________<br><br><br><br>Corporation address: ________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>_____________________________________________________________________<br><br><br><br>Point of Contact: ___________________________________________________<br><br><br><br>E-Mail: ____________________________________________________________<br><br><br><br>Telephone: _____________________<br><br><br><br>Fax: ___________________________<br><br></pre>
-
-You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.
-
-1. Definitions.
-
- "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant to the Project Leads. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
-
- "Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
-
-1. Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
-
-1. Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.
-
-1. You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.
-
-1. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).
-
-1. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
-
-1. Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p>
-
-1. It is your responsibility to notify the Project Leads when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with the Project.
-
-<pre>
-<br><br>
-Please sign: __________________________________ Date: _______________<br><br>
-Title: _______________________________________________________________<br><br>
-Corporation: __________________________________________________________
-</pre>
-
-### Schedule A ###
-
-[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]
-
-### Schedule B ###
-
-[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]
-
diff --git a/src/source/cla-individual.jd b/src/source/cla-individual.jd
new file mode 100644
index 0000000..27f32cf
--- /dev/null
+++ b/src/source/cla-individual.jd
@@ -0,0 +1,63 @@
+page.title=Contributor License Agreement for Individuals
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p><em>Please visit the <a href="https://android-review.googlesource.com/#/settings/new-agreement">code review tool</a>
+to execute the grant online.This page provides the text of the Individual Contributor License Grant for your quick review.</em></p>
+<p>In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Grant to</p>
+<blockquote>
+ Google Inc.<br/>
+ Attn: Open Source Program Office<br/>
+ 1600 Amphitheatre Pkwy<br/>
+ Building 43<br/>
+ Mountain View, CA 94043<br/>
+ U.S.A.
+</blockquote>
+
+<p>Scanned agreements may also be emailed in PDF form to
+cla-submissions@google.com, sent by facsimile to (650) 887-1625, or
+<a href="https://android-review.googlesource.com/#/settings/new-agreement">signed electronically</a>.</p>
+<p>Please read this document carefully before signing and keep a copy for your records.</p>
+<pre>
+<br><br>
+Full name: ____________________________ E-Mail: ______________________<br><br>
+Mailing Address: ______________________ Telephone: ___________________<br><br>
+_______________________________________ Facsimile: ___________________<br><br>
+_______________________________________ Country: ___________________
+</pre>
+
+<p>You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.</p>
+<ol>
+<li>
+<p>Definitions. </p>
+<p>"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."</p>
+</li>
+<li>
+<p>Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.</p>
+</li>
+<li>
+<p>Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.</p>
+</li>
+<li>
+<p>You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project Leads, or that your employer has executed a separate Corporate Contributor License Grant with the Project Leads.</p>
+</li>
+<li>
+<p>You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.</p>
+</li>
+<li>
+<p>You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.</p>
+</li>
+<li>
+<p>Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p></p>
+</li>
+<li>
+<p>You agree to notify the Project Leads of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.</p>
+</li>
+</ol>
diff --git a/src/source/cla-individual.md b/src/source/cla-individual.md
deleted file mode 100644
index 34a1c28..0000000
--- a/src/source/cla-individual.md
+++ /dev/null
@@ -1,66 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Contributor License Agreement for Individuals #
-
-*Please visit the [code review tool](https://android-review.googlesource.com/#/settings/new-agreement)
-to execute the grant online.This page provides the text of the Individual Contributor License Grant for your quick review.*
-
-In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Grant to
-
-<blockquote>
- Google Inc.<br/>
- Attn: Open Source Program Office<br/>
- 1600 Amphitheatre Pkwy<br/>
- Building 43<br/>
- Mountain View, CA 94043<br/>
- U.S.A.
-</blockquote>
-
-Scanned agreements may also be emailed in PDF form to
-cla-submissions@google.com, sent by facsimile to (650) 887-1625, or
-[signed electronically](https://android-review.googlesource.com/#/settings/new-agreement).
-
-Please read this document carefully before signing and keep a copy for your records.
-
-<pre>
-<br><br>
-Full name: ____________________________ E-Mail: ______________________<br><br>
-Mailing Address: ______________________ Telephone: ___________________<br><br>
-_______________________________________ Facsimile: ___________________<br><br>
-_______________________________________ Country: ___________________
-</pre>
-
-You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Project. Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions.
-
-1. Definitions.
-
- "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Grant. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Project Leads for inclusion in, or documentation of, any of the products managed or maintained by the Project Leads (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Project Leads or their representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project Leads for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
-
-1. Grant of Copyright License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
-
-1. Grant of Patent License. Subject to the terms and conditions of this Grant, You hereby grant to the Project Leads and to recipients of software distributed by the Project Leads a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Grant for that Contribution or Work shall terminate as of the date such litigation is filed.
-
-1. You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project Leads, or that your employer has executed a separate Corporate Contributor License Grant with the Project Leads.
-
-1. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
-
-1. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
-
-1. Should You wish to submit work that is not Your original creation, You may submit it to the Project Leads separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".<br></p>
-
-1. You agree to notify the Project Leads of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
-
diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd
new file mode 100644
index 0000000..e37e0cc
--- /dev/null
+++ b/src/source/code-lines.jd
@@ -0,0 +1,191 @@
+page.title=Codelines, Branches, and Releases
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The Android Open Source Project maintains a complete software stack intended to be ported by
+ OEMs and other device implementors to run on actual hardware. To maintain the quality of
+ Android, Google has contributed full-time engineers, product managers, UI designers, Quality
+ Assurance, and all the other roles required to bring modern devices to market.
+</p>
+
+<p>
+ Accordingly, we maintain a number of "code lines" to clearly separate the current stable
+ version of Android from unstable experimental work. We roll the open source administration
+ and maintenance of the Android code lines into the larger product development cycle.
+</p>
+
+<p>
+ The chart below depicts at a conceptual level how AOSP manages code and releases. We're
+ referring to these as "code lines" instead of "branches" simply because at any given moment
+ there may be more than one branch extant for a given "code line". For instance, when a
+ release is cut, sometimes that will become a new branch in git, and sometimes not, based on
+ the needs of the moment.
+</p>
+<ul>
+ <li>
+ <p>
+ At any given moment, there is a current latest release of the Android platform. This
+ typically takes the form of a branch in the tree.
+ </p>
+ </li>
+ <li>
+ <p>
+ Device builders and contributors work with the current latest release, fixing bugs,
+ launching new devices, experimenting with new features, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ In parallel, Google works internally on the next version of the Android platform and
+ framework, working according to the product's needs and goals. We develop the next
+ version of Android by working with a device partner on a flagship device whose
+ specifications are chosen to push Android in the direction we believe it should go.
+ </p>
+ </li>
+ <li>
+ <p>
+ When the "n+1"th version is ready, it will be published to the public source tree, and
+ become the new latest release.
+ </p>
+ </li>
+</ul>
+<p>
+ <img src="{@docRoot}images/code-lines.png" alt="code-line diagram">
+</p>
+
+<h2 id="notes-and-explanations">
+ Notes and Explanations
+</h2>
+<ul>
+ <li>
+ <p>
+ A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5,
+ 2.1, and so on. Generally speaking, a release of the platform corresponds to a version of
+ the <code>SdkVersion</code> field used in AndroidManifest.xml files, and defined in
+ <code>frameworks/base/api</code> in the source tree.
+ </p>
+ </li>
+ <li>
+ <p>
+ An <em>upstream</em> project is an open-source project from which the Android stack is
+ pulling code. These include obvious projects such as the Linux kernel and WebKit, but
+ over time we are migrating some of the semi-autonomous Android projects (such as Dalvik,
+ the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally,
+ these projects are developed entirely in the public tree. For some upstream projects,
+ development is done by contributing directly to the upstream project itself. See <a href=
+ "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases,
+ snapshots will be periodically pulled into releases.
+ </p>
+ </li>
+ <li>
+ <p>
+ The diagram refers to "Eclair" and "FroYo"; however, they are simply placeholders, and
+ the diagram actually reflects the overall release and branching strategy.
+ </p>
+ </li>
+ <li>
+ <p>
+ At all times, a release code-line (which may actually consist of more than one actual
+ branch in git) is considered the sole canonical source code for a given Android platform
+ version. OEMs and other groups building devices should pull only from a release branch.
+ </p>
+ </li>
+ <li>
+ <p>
+ We will set up "experimental" code-lines to capture changes from the community, so that
+ they can be iterated on, with an eye toward stability.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes that prove stable will eventually be pulled into a release branch. Note that this
+ will only apply to bug fixes, app improvements, and other things that do not affect the
+ APIs of the platform.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled into release branches from upstream projects (including the
+ Android "upstream" projects) as necessary.
+ </p>
+ </li>
+ <li>
+ <p>
+ The "n+1"th version (that is, next major version of the framework and platform APIs) will
+ be developed by Google internally. See below for details.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled from upstream, release, and experimental branches into Google's
+ private branch as necessary.
+ </p>
+ </li>
+ <li>
+ <p>
+ When the platform APIs for the next version have stabilized and been fully tested, Google
+ will cut a release of the next platform version. (This specifically refers to a new
+ <code>SdkVersion</code>.) This will also correspond to the internal code-line being made
+ a public release branch, and the new current platform code-line.
+ </p>
+ </li>
+ <li>
+ <p>
+ When a new platform version is cut, a corresponding experimental code-line will be
+ created at the same time.
+ </p>
+ </li>
+</ul>
+
+<h2 id="about-private-code-lines">
+ About Private Codelines
+</h2>
+<p>
+ The source management strategy above includes a code-line that Google will keep private. The
+ reason for this is to focus attention on the current public version of Android.
+</p>
+<p>
+ OEMs and other device builders naturally want to ship devices with the latest version of
+ Android. Similarly, application developers don't want to deal with more extant platform
+ versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
+ direction of Android as a platform and a product. Our approach is based on focusing on a
+ small number of flagship devices to drive features, and secure protections of Android-related
+ intellectual property.
+</p>
+<p>
+ As a result, Google frequently has possession of confidential information of third parties,
+ and we must refrain from revealing sensitive features until we've secured the appropriate
+ protections. Meanwhile, there are real risks to the platform arising from having too many
+ platform versions extant at once. For these reasons, we have structured the open-source
+ project -- including third-party contributions -- to focus on the currently-public stable
+ version of Android. "Deep development" on the next version of the platform will happen in
+ private, until it's ready to become an official release.
+</p>
+<p>
+ We recognize that many contributors will disagree with this approach. We respect that others
+ may have a different point of view; however, this is the approach that we feel is best, and
+ the one we've chosen to implement.
+</p>
\ No newline at end of file
diff --git a/src/source/code-lines.md b/src/source/code-lines.md
deleted file mode 100644
index 8b268f2..0000000
--- a/src/source/code-lines.md
+++ /dev/null
@@ -1,113 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Code-Lines #
-
-The Android Open Source Project maintains a complete software stack intended
-to be ported by OEMs and other device implementors to run on actual hardware.
-Accordingly, we maintain a number of "code lines" to clearly separate the
-current stable version of Android from unstable experimental work.
-
-The chart below depicts at a conceptual level how AOSP manages code and
-releases. We're referring to these as "code lines" instead of "branches"
-simply because at any given moment there may be more than one branch extant
-for a given "code line". For instance, when a release is cut, sometimes that
-will become a new branch in git, and sometimes not, based on the needs of the
-moment.
-
-<img src="/images/code-lines.png" alt="code-line diagram"/>
-
-## Notes and Explanations ##
-
-- A *release* corresponds to a formal version of the Android platform, such
-as 1.5, 2.1, and so on. Generally speaking, a release of the platform
-corresponds to a version of the `SdkVersion` field used in
-AndroidManifest.xml files, and defined in `frameworks/base/api` in
-the source tree.
-
-- An *upstream* project is an open-source project from which the Android
-stack is pulling code. These include obvious projects such as the Linux kernel
-and WebKit, but over time we are migrating some of the semi-autonomous
-Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to
-work as "upstream" projects. Generally, these projects are developed entirely in
-the public tree. For some upstream projects, development is done by contributing
-directly to the upstream project itself. See [Upstream Projects](submit-patches.html#upstream-projects)
-for details. In both cases, snapshots will be periodically pulled into releases.
-
-- The diagram refers to "Eclair" and "FroYo"; however, they are simply
-placeholders, and the diagram actually reflects the overall release and
-branching strategy.
-
-- At all times, a release code-line (which may actually consist of
-more than one actual branch in git) is considered the sole canonical source
-code for a given Android platform version. OEMs and other groups building devices
-should pull only from a release branch.
-
-- We will set up "experimental" code-lines to capture changes from
-the community, so that they can be iterated on, with an eye toward stability.
-
-- Changes that prove stable will eventually be pulled into a release
-branch. Note that this will only apply to bug fixes, app improvements, and
-other things that do not affect the APIs of the platform.
-
-- Changes will be pulled into release branches from upstream projects
-(including the Android "upstream" projects) as necessary.
-
-- The "n+1"th version (that is, next major version of the framework and
-platform APIs) will be developed by Google internally. See below for
-details.
-
-- Changes will be pulled from upstream, release, and experimental branches
-into Google's private branch as necessary.
-
-- When the platform APIs for the next version have stabilized and been fully
-tested, Google will cut a release of the next platform version. (This
-specifically refers to a new `SdkVersion`.) This will also
-correspond to the internal code-line being made a public release branch, and the
-new current platform code-line.
-
-- When a new platform version is cut, a corresponding experimental
-code-line will be created at the same time.
-
-## About Private Code-Lines ##
-
-The source management strategy above includes a code-line that Google will
-keep private. The reason for this is to focus attention on the current public
-version of Android.
-
-OEMs and other device builders naturally want to ship devices with the
-latest version of Android. Similarly, application developers don't want to
-deal with more extant platform versions than strictly necessary. Meanwhile,
-Google retains responsibility for the strategic direction of Android as a
-platform and a product. Our approach is based on focusing on a small number of
-flagship devices to drive features, and secure protections of Android-related
-intellectual property.
-
-As a result, Google frequently has possession of confidential
-information of third parties, and we must refrain from revealing sensitive
-features until we've secured the appropriate protections. Meanwhile, there are
-real risks to the platform arising from having too many platform versions
-extant at once. For these reasons, we have structured the open-source project
--- including third-party contributions -- to focus on the currently-public
-stable version of Android. "Deep development" on the next version of the
-platform will happen in private, until it's ready to become an official
-release.
-
-We recognize that many contributors will disagree with this approach. We
-respect that others may have a different point of view; however, this is the
-approach that we feel is best, and the one we've chosen to implement.
-
-
diff --git a/src/source/code-style.jd b/src/source/code-style.jd
new file mode 100644
index 0000000..e371aa7
--- /dev/null
+++ b/src/source/code-style.jd
@@ -0,0 +1,738 @@
+page.title=Code Style Guidelines for Contributors
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>The rules below are not guidelines or recommendations, but strict rules.
+Contributions to Android generally <em>will not be accepted</em> if they do not
+adhere to these rules.</p>
+
+<p>Not all existing code follows these rules, but all new code is expected to.</p>
+
+<h2 id="java-language-rules">Java Language Rules</h2>
+<p>We follow standard Java coding conventions. We add a few rules:</p>
+<h3 id="dont-ignore-exceptions">Don't Ignore Exceptions</h3>
+<p>Sometimes it is tempting to write code that completely ignores an exception
+like this:</p>
+<pre><code>void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) { }
+}
+</code></pre>
+<p>You must never do this. While you may think that your code will never
+encounter this error condition or that it is not important to handle it,
+ignoring exceptions like above creates mines in your code for someone else to
+trip over some day. You must handle every Exception in your code in some
+principled way. The specific handling varies depending on the case.</p>
+<p><em>Anytime somebody has an empty catch clause they should have a
+creepy feeling. There are definitely times when it is actually the correct
+thing to do, but at least you have to think about it. In Java you can't escape
+the creepy feeling.</em> -<a href="http://www.artima.com/intv/solid4.html">James Gosling</a></p>
+<p>Acceptable alternatives (in order of preference) are:</p>
+<ul>
+<li>
+<p>Throw the exception up to the caller of your method.</p>
+<pre><code>void setServerPort(String value) throws NumberFormatException {
+ serverPort = Integer.parseInt(value);
+}
+</code></pre>
+</li>
+<li>
+<p>Throw a new exception that's appropriate to your level of abstraction.</p>
+<pre><code>void setServerPort(String value) throws ConfigurationException {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ throw new ConfigurationException("Port " + value + " is not valid.");
+ }
+}
+</code></pre>
+</li>
+<li>
+<p>Handle the error gracefully and substitute an appropriate value in the
+catch {} block.</p>
+<pre><code>/** Set port. If value is not a valid number, 80 is substituted. */
+
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ serverPort = 80; // default port for server
+ }
+}
+</code></pre>
+</li>
+<li>
+<p>Catch the Exception and throw a new <code>RuntimeException</code>. This is dangerous:
+only do it if you are positive that if this error occurs, the appropriate
+thing to do is crash.</p>
+<pre><code>/** Set port. If value is not a valid number, die. */
+
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ throw new RuntimeException("port " + value " is invalid, ", e);
+ }
+}
+</code></pre>
+<p>Note that the original exception is passed to the constructor for
+RuntimeException. If your code must compile under Java 1.3, you will need to
+omit the exception that is the cause.</p>
+</li>
+<li>
+<p>Last resort: if you are confident that actually ignoring the exception is
+appropriate then you may ignore it, but you must also comment why with a good
+reason:</p>
+<pre><code>/** If value is not a valid number, original port number is used. */
+void setServerPort(String value) {
+ try {
+ serverPort = Integer.parseInt(value);
+ } catch (NumberFormatException e) {
+ // Method is documented to just ignore invalid user input.
+ // serverPort will just be unchanged.
+ }
+}
+</code></pre>
+</li>
+</ul>
+<h3 id="dont-catch-generic-exception">Don't Catch Generic Exception</h3>
+<p>Sometimes it is tempting to be lazy when catching exceptions and do
+something like this:</p>
+<pre><code>try {
+ someComplicatedIOFunction(); // may throw IOException
+ someComplicatedParsingFunction(); // may throw ParsingException
+ someComplicatedSecurityFunction(); // may throw SecurityException
+ // phew, made it all the way
+} catch (Exception e) { // I'll just catch all exceptions
+ handleError(); // with one generic handler!
+}
+</code></pre>
+<p>You should not do this. In almost all cases it is inappropriate to catch
+generic Exception or Throwable, preferably not Throwable, because it includes
+Error exceptions as well. It is very dangerous. It means that Exceptions you
+never expected (including RuntimeExceptions like ClassCastException) end up
+getting caught in application-level error handling. It obscures the failure
+handling properties of your code. It means if someone adds a new type of
+Exception in the code you're calling, the compiler won't help you realize you
+need to handle that error differently. And in most cases you shouldn't be
+handling different types of exception the same way, anyway.</p>
+<p>There are rare exceptions to this rule: certain test code and top-level
+code where you want to catch all kinds of errors (to prevent them from showing
+up in a UI, or to keep a batch job running). In that case you may catch
+generic Exception (or Throwable) and handle the error appropriately. You
+should think very carefully before doing this, though, and put in comments
+explaining why it is safe in this place.</p>
+<p>Alternatives to catching generic Exception:</p>
+<ul>
+<li>
+<p>Catch each exception separately as separate catch blocks after a single
+try. This can be awkward but is still preferable to catching all Exceptions.
+Beware repeating too much code in the catch blocks.</li></p>
+</li>
+<li>
+<p>Refactor your code to have more fine-grained error handling, with multiple
+try blocks. Split up the IO from the parsing, handle errors separately in each
+case.</p>
+</li>
+<li>
+<p>Rethrow the exception. Many times you don't need to catch the exception at
+this level anyway, just let the method throw it.</p>
+</li>
+</ul>
+<p>Remember: exceptions are your friend! When the compiler complains you're
+not catching an exception, don't scowl. Smile: the compiler just made it
+easier for you to catch runtime problems in your code.</p>
+<h3 id="dont-use-finalizers">Don't Use Finalizers</h3>
+<p>Finalizers are a way to have a chunk of code executed
+when an object is garbage collected.</p>
+<p>Pros: can be handy for doing cleanup, particularly of external resources.</p>
+<p>Cons: there are no guarantees as to when a finalizer will be called,
+or even that it will be called at all.</p>
+<p>Decision: we don't use finalizers. In most cases, you can do what
+you need from a finalizer with good exception handling. If you absolutely need
+it, define a close() method (or the like) and document exactly when that
+method needs to be called. See InputStream for an example. In this case it is
+appropriate but not required to print a short log message from the finalizer,
+as long as it is not expected to flood the logs.</p>
+<h3 id="fully-qualify-imports">Fully Qualify Imports</h3>
+<p>When you want to use class Bar from package foo,there
+are two possible ways to import it:</p>
+<ol>
+<li><code>import foo.*;</code></li>
+</ol>
+<p>Pros: Potentially reduces the number of import statements.</p>
+<ol>
+<li><code>import foo.Bar;</code></li>
+</ol>
+<p>Pros: Makes it obvious what classes are actually used. Makes
+code more readable for maintainers. </p>
+<p>Decision: Use the latter for importing all Android code. An explicit
+exception is made for java standard libraries (<code>java.util.*</code>, <code>java.io.*</code>, etc.)
+and unit test code (<code>junit.framework.*</code>)</p>
+<h2 id="java-library-rules">Java Library Rules</h2>
+<p>There are conventions for using Android's Java libraries and tools. In some
+cases, the convention has changed in important ways and older code might use a
+deprecated pattern or library. When working with such code, it's okay to
+continue the existing style (see <a href="#consistency">Consistency</a>). When
+creating new components never use deprecated libraries.</p>
+<h2 id="java-style-rules">Java Style Rules</h2>
+<h3 id="use-javadoc-standard-comments">Use Javadoc Standard Comments</h3>
+<p>Every file should have a copyright statement at the top. Then a package
+statement and import statements should follow, each block separated by a blank
+line. And then there is the class or interface declaration. In the Javadoc
+comments, describe what the class or interface does.</p>
+<pre><code>/*
+ * Copyright (C) 2010 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package com.android.internal.foo;
+
+import android.os.Blah;
+import android.view.Yada;
+
+import java.sql.ResultSet;
+import java.sql.SQLException;
+
+/**
+ * Does X and Y and provides an abstraction for Z.
+ */
+
+public class Foo {
+ ...
+}
+</code></pre>
+<p>Every class and nontrivial public method you write <em>must</em> contain a
+Javadoc comment with at least one sentence describing what the class or method
+does. This sentence should start with a 3rd person descriptive verb.</p>
+<p>Examples:</p>
+<pre><code>/** Returns the correctly rounded positive square root of a double value. */
+static double sqrt(double a) {
+ ...
+}
+</code></pre>
+<p>or</p>
+<pre><code>/**
+ * Constructs a new String by converting the specified array of
+ * bytes using the platform's default character encoding.
+ */
+public String(byte[] bytes) {
+ ...
+}
+</code></pre>
+<p>You do not need to write Javadoc for trivial get and set methods such as
+<code>setFoo()</code> if all your Javadoc would say is "sets Foo". If the method does
+something more complex (such as enforcing a constraint or having an important
+side effect), then you must document it. And if it's not obvious what the
+property "Foo" means, you should document it.</p>
+<p>Every method you write, whether public or otherwise, would benefit from
+Javadoc. Public methods are part of an API and therefore require Javadoc.</p>
+<p>Android does not currently enforce a specific style for writing Javadoc
+comments, but you should follow the
+<a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">Sun Javadoc conventions</a>.</p>
+<h3 id="write-short-methods">Write Short Methods</h3>
+<p>To the extent that it is feasible, methods should be kept small and
+focused. It is, however, recognized that long methods are sometimes
+appropriate, so no hard limit is placed on method length. If a method exceeds
+40 lines or so, think about whether it can be broken up without harming the
+structure of the program.</p>
+<h3 id="define-fields-in-standard-places">Define Fields in Standard Places</h3>
+<p>Fields should be defined either at the top of the file, or immediately before the methods that use them.</p>
+<h3 id="limit-variable-scope">Limit Variable Scope</h3>
+<p>The scope of local variables should be kept to a minimum (<em>Effective
+Java</em> Item 29). By doing so, you increase the readability and
+maintainability of your code and reduce the likelihood of error. Each variable
+should be declared in the innermost block that encloses all uses of the
+variable.</p>
+<p>Local variables should be declared at the point they are first used. Nearly
+every local variable declaration should contain an initializer. If you don't
+yet have enough information to initialize a variable sensibly, you should
+postpone the declaration until you do.</p>
+<p>One exception to this rule concerns try-catch statements. If a variable is
+initialized with the return value of a method that throws a checked exception,
+it must be initialized inside a try block. If the value must be used outside
+of the try block, then it must be declared before the try block, where it
+cannot yet be sensibly initialized:</p>
+<pre><code>// Instantiate class cl, which represents some sort of Set
+Set s = null;
+try {
+ s = (Set) cl.newInstance();
+} catch(IllegalAccessException e) {
+ throw new IllegalArgumentException(cl + " not accessible");
+} catch(InstantiationException e) {
+ throw new IllegalArgumentException(cl + " not instantiable");
+}
+
+// Exercise the set
+s.addAll(Arrays.asList(args));
+</code></pre>
+<p>But even this case can be avoided by encapsulating the try-catch block in a method:</p>
+<pre><code>Set createSet(Class cl) {
+ // Instantiate class cl, which represents some sort of Set
+ try {
+ return (Set) cl.newInstance();
+ } catch(IllegalAccessException e) {
+ throw new IllegalArgumentException(cl + " not accessible");
+ } catch(InstantiationException e) {
+ throw new IllegalArgumentException(cl + " not instantiable");
+ }
+}
+
+...
+
+// Exercise the set
+Set s = createSet(cl);
+s.addAll(Arrays.asList(args));
+</code></pre>
+<p>Loop variables should be declared in the for statement itself unless there
+is a compelling reason to do otherwise:</p>
+<pre><code>for (int i = 0; i n; i++) {
+ doSomething(i);
+}
+</code></pre>
+<p>and</p>
+<pre><code>for (Iterator i = c.iterator(); i.hasNext(); ) {
+ doSomethingElse(i.next());
+}
+</code></pre>
+<h3 id="order-import-statements">Order Import Statements</h3>
+<p>The ordering of import statements is:</p>
+<ol>
+<li>
+<p>Android imports</p>
+</li>
+<li>
+<p>Imports from third parties (<code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>)</p>
+</li>
+<li>
+<p><code>java</code> and <code>javax</code></p>
+</li>
+</ol>
+<p>To exactly match the IDE settings, the imports should be:</p>
+<ul>
+<li>
+<p>Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).</p>
+</li>
+<li>
+<p>There should be a blank line between each major grouping (<code>android</code>, <code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>, <code>java</code>, <code>javax</code>).</p>
+</li>
+</ul>
+<p>Originally there was no style requirement on the ordering. This meant that
+the IDE's were either always changing the ordering, or IDE developers had to
+disable the automatic import management features and maintain the imports by
+hand. This was deemed bad. When java-style was asked, the preferred styles
+were all over the map. It pretty much came down to our needing to "pick an
+ordering and be consistent." So we chose a style, updated the style guide, and
+made the IDEs obey it. We expect that as IDE users work on the code, the
+imports in all of the packages will end up matching this pattern without any
+extra engineering effort.</p>
+<p>This style was chosen such that:</p>
+<ul>
+<li>
+<p>The imports people want to look at first tend to be at the top (<code>android</code>)</p>
+</li>
+<li>
+<p>The imports people want to look at least tend to be at the bottom (<code>java</code>)</p>
+</li>
+<li>
+<p>Humans can easily follow the style</p>
+</li>
+<li>
+<p>IDEs can follow the style</p>
+</li>
+</ul>
+<p>The use and location of static imports have been mildly controversial
+issues. Some people would prefer static imports to be interspersed with the
+remaining imports, some would prefer them reside above or below all other
+imports. Additinally, we have not yet come up with a way to make all IDEs use
+the same ordering.</p>
+<p>Since most people consider this a low priority issue, just use your
+judgement and please be consistent.</p>
+<h3 id="use-spaces-for-indentation">Use Spaces for Indentation</h3>
+<p>We use 4 space indents for blocks. We never use tabs. When in doubt, be
+consistent with code around you.</p>
+<p>We use 8 space indents for line wraps, including function calls and
+assignments. For example, this is correct:</p>
+<pre><code>Instrument i =
+ someLongExpression(that, wouldNotFit, on, one, line);
+</code></pre>
+<p>and this is not correct:</p>
+<pre><code>Instrument i =
+ someLongExpression(that, wouldNotFit, on, one, line);
+</code></pre>
+<h3 id="follow-field-naming-conventions">Follow Field Naming Conventions</h3>
+<ul>
+<li>
+<p>Non-public, non-static field names start with m.</p>
+</li>
+<li>
+<p>Static field names start with s.</p>
+</li>
+<li>
+<p>Other fields start with a lower case letter.</p>
+</li>
+<li>
+<p>Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.</p>
+</li>
+</ul>
+<p>For example:</p>
+<pre><code>public class MyClass {
+ public static final int SOME_CONSTANT = 42;
+ public int publicField;
+ private static MyClass sSingleton;
+ int mPackagePrivate;
+ private int mPrivate;
+ protected int mProtected;
+}
+</code></pre>
+<h3 id="use-standard-brace-style">Use Standard Brace Style</h3>
+<p>Braces do not go on their own line; they go on the same line as the code
+before them. So:</p>
+<pre><code>class MyClass {
+ int func() {
+ if (something) {
+ // ...
+ } else if (somethingElse) {
+ // ...
+ } else {
+ // ...
+ }
+ }
+}
+</code></pre>
+<p>We require braces around the statements for a conditional. Except, if the
+entire conditional (the condition and the body) fit on one line, you may (but
+are not obligated to) put it all on one line. That is, this is legal:</p>
+<pre><code>if (condition) {
+ body();
+}
+</code></pre>
+<p>and this is legal:</p>
+<pre><code>if (condition) body();
+</code></pre>
+<p>but this is still illegal:</p>
+<pre><code>if (condition)
+ body(); // bad!
+</code></pre>
+<h3 id="limit-line-length">Limit Line Length</h3>
+<p>Each line of text in your code should be at most 100 characters long.</p>
+<p>There has been lots of discussion about this rule and the decision remains
+that 100 characters is the maximum.</p>
+<p>Exception: if a comment line contains an example command or a literal URL
+longer than 100 characters, that line may be longer than 100 characters for
+ease of cut and paste.</p>
+<p>Exception: import lines can go over the limit because humans rarely see
+them. This also simplifies tool writing.</p>
+<h3 id="use-standard-java-annotations">Use Standard Java Annotations</h3>
+<p>Annotations should precede other modifiers for the same language element.
+Simple marker annotations (e.g. @Override) can be listed on the same line with
+the language element. If there are multiple annotations, or parameterized
+annotations, they should each be listed one-per-line in alphabetical
+order.<</p>
+<p>Android standard practices for the three predefined annotations in Java are:</p>
+<ul>
+<li>
+<p><code>@Deprecated</code>: The @Deprecated annotation must be used whenever the use of the annotated
+element is discouraged. If you use the @Deprecated annotation, you must also
+have a @deprecated Javadoc tag and it should name an alternate implementation.
+In addition, remember that a @Deprecated method is <em>still supposed to
+work.</em></p>
+<p>If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.</p>
+</li>
+<li>
+<p><code>@Override</code>: The @Override annotation must be used whenever a method overrides the
+declaration or implementation from a super-class.</p>
+<p>For example, if you use the @inheritdocs Javadoc tag, and derive from a
+class (not an interface), you must also annotate that the method @Overrides
+the parent class's method.</p>
+</li>
+<li>
+<p><code>@SuppressWarnings</code>: The @SuppressWarnings annotation should only be used under circumstances
+where it is impossible to eliminate a warning. If a warning passes this
+"impossible to eliminate" test, the @SuppressWarnings annotation <em>must</em> be
+used, so as to ensure that all warnings reflect actual problems in the
+code.</p>
+<p>When a @SuppressWarnings annotation is necessary, it must be prefixed with
+a TODO comment that explains the "impossible to eliminate" condition. This
+will normally identify an offending class that has an awkward interface. For
+example:</p>
+<pre><code>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
+@SuppressWarnings("generic-cast")
+List<String> blix = Utility.rotate(blax);
+</code></pre>
+<p>When a @SuppressWarnings annotation is required, the code should be
+refactored to isolate the software elements where the annotation applies.</p>
+</li>
+</ul>
+<h3 id="treat-acronyms-as-words">Treat Acronyms as Words</h3>
+<p>Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable:</p>
+<table>
+<thead>
+<tr>
+<th>Good</th>
+<th>Bad</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>XmlHttpRequest</td>
+<td>XMLHTTPRequest</td>
+</tr>
+<tr>
+<td>getCustomerId</td>
+<td>getCustomerID</td>
+</tr>
+<tr>
+<td>class Html</td>
+<td>class HTML</td>
+</tr>
+<tr>
+<td>String url</td>
+<td>String URL</td>
+</tr>
+<tr>
+<td>long id</td>
+<td>long ID</td>
+</tr>
+</tbody>
+</table>
+<p>Both the JDK and the Android code bases are very inconsistent with regards
+to acronyms, therefore, it is virtually impossible to be consistent with the
+code around you. Bite the bullet, and treat acronyms as words.</p>
+<p>For further justifications of this style rule, see <em>Effective Java</em>
+Item 38 and <em>Java Puzzlers</em> Number 68.</p>
+<h3 id="use-todo-comments">Use TODO Comments</h3>
+<p>Use TODO comments for code that is temporary, a short-term solution, or
+good-enough but not perfect.</p>
+<p>TODOs should include the string TODO in all caps, followed by a colon:</p>
+<pre><code>// TODO: Remove this code after the UrlTable2 has been checked in.
+</code></pre>
+<p>and</p>
+<pre><code>// TODO: Change this to use a flag instead of a constant.
+</code></pre>
+<p>If your TODO is of the form "At a future date do something" make sure that
+you either include a very specific date ("Fix by November 2005") or a very
+specific event ("Remove this code after all production mixers understand
+protocol V7.").</p>
+<h3 id="log-sparingly">Log Sparingly</h3>
+<p>While logging is necessary it has a significantly negative impact on
+performance and quickly loses its usefulness if it's not kept reasonably
+terse. The logging facilities provides five different levels of logging. Below
+are the different levels and when and how they should be used.</p>
+<ul>
+<li>
+<p><code>ERROR</code>:
+This level of logging should be used when something fatal has happened,
+i.e. something that will have user-visible consequences and won't be
+recoverable without explicitly deleting some data, uninstalling applications,
+wiping the data partitions or reflashing the entire phone (or worse). This
+level is always logged. Issues that justify some logging at the ERROR level
+are typically good candidates to be reported to a statistics-gathering
+server.</p>
+</li>
+<li>
+<p><code>WARNING</code>:
+This level of logging should used when something serious and unexpected
+happened, i.e. something that will have user-visible consequences but is
+likely to be recoverable without data loss by performing some explicit action,
+ranging from waiting or restarting an app all the way to re-downloading a new
+version of an application or rebooting the device. This level is always
+logged. Issues that justify some logging at the WARNING level might also be
+considered for reporting to a statistics-gathering server.</p>
+</li>
+<li>
+<p><code>INFORMATIVE:</code>
+This level of logging should used be to note that something interesting to
+most people happened, i.e. when a situation is detected that is likely to have
+widespread impact, though isn't necessarily an error. Such a condition should
+only be logged by a module that reasonably believes that it is the most
+authoritative in that domain (to avoid duplicate logging by non-authoritative
+components). This level is always logged.</p>
+</li>
+<li>
+<p><code>DEBUG</code>:
+This level of logging should be used to further note what is happening on the
+device that could be relevant to investigate and debug unexpected behaviors.
+You should log only what is needed to gather enough information about what is
+going on about your component. If your debug logs are dominating the log then
+you probably should be using verbose logging. </p>
+<p>This level will be logged, even
+on release builds, and is required to be surrounded by an <code>if (LOCAL_LOG)</code> or <code>if
+(LOCAL_LOGD)</code> block, where <code>LOCAL_LOG[D]</code> is defined in your class or
+subcomponent, so that there can exist a possibility to disable all such
+logging. There must therefore be no active logic in an <code>if (LOCAL_LOG)</code> block.
+All the string building for the log also needs to be placed inside the <code>if
+(LOCAL_LOG)</code> block. The logging call should not be re-factored out into a
+method call if it is going to cause the string building to take place outside
+of the <code>if (LOCAL_LOG)</code> block. </p>
+<p>There is some code that still says <code>if
+(localLOGV)</code>. This is considered acceptable as well, although the name is
+nonstandard.</p>
+</li>
+<li>
+<p><code>VERBOSE</code>:
+This level of logging should be used for everything else. This level will only
+be logged on debug builds and should be surrounded by an <code>if (LOCAL_LOGV)</code> block
+(or equivalent) so that it can be compiled out by default. Any string building
+will be stripped out of release builds and needs to appear inside the <code>if (LOCAL_LOGV)</code> block.</p>
+</li>
+</ul>
+<p><em>Notes:</em> </p>
+<ul>
+<li>
+<p>Within a given module, other than at the VERBOSE level, an
+error should only be reported once if possible: within a single chain of
+function calls within a module, only the innermost function should return the
+error, and callers in the same module should only add some logging if that
+significantly helps to isolate the issue.</p>
+</li>
+<li>
+<p>In a chain of modules, other than at the VERBOSE level, when a
+lower-level module detects invalid data coming from a higher-level module, the
+lower-level module should only log this situation to the DEBUG log, and only
+if logging provides information that is not otherwise available to the caller.
+Specifically, there is no need to log situations where an exception is thrown
+(the exception should contain all the relevant information), or where the only
+information being logged is contained in an error code. This is especially
+important in the interaction between the framework and applications, and
+conditions caused by third-party applications that are properly handled by the
+framework should not trigger logging higher than the DEBUG level. The only
+situations that should trigger logging at the INFORMATIVE level or higher is
+when a module or application detects an error at its own level or coming from
+a lower level.</p>
+</li>
+<li>
+<p>When a condition that would normally justify some logging is
+likely to occur many times, it can be a good idea to implement some
+rate-limiting mechanism to prevent overflowing the logs with many duplicate
+copies of the same (or very similar) information.</p>
+</li>
+<li>
+<p>Losses of network connectivity are considered common and fully
+expected and should not be logged gratuitously. A loss of network connectivity
+that has consequences within an app should be logged at the DEBUG or VERBOSE
+level (depending on whether the consequences are serious enough and unexpected
+enough to be logged in a release build).</p>
+</li>
+<li>
+<p>A full filesystem on a filesystem that is acceessible to or on
+behalf of third-party applications should not be logged at a level higher than
+INFORMATIVE.</p>
+</li>
+<li>
+<p>Invalid data coming from any untrusted source (including any
+file on shared storage, or data coming through just about any network
+connections) is considered expected and should not trigger any logging at a
+level higher then DEBUG when it's detected to be invalid (and even then
+logging should be as limited as possible).</p>
+</li>
+<li>
+<p>Keep in mind that the <code>+</code> operator, when used on Strings,
+implicitly creates a <code>StringBuilder</code> with the default buffer size (16
+characters) and potentially quite a few other temporary String objects, i.e.
+that explicitly creating StringBuilders isn't more expensive than relying on
+the default '+' operator (and can be a lot more efficient in fact). Also keep
+in mind that code that calls <code>Log.v()</code> is compiled and executed on release
+builds, including building the strings, even if the logs aren't being
+read.</p>
+</li>
+<li>
+<p>Any logging that is meant to be read by other people and to be
+available in release builds should be terse without being cryptic, and should
+be reasonably understandable. This includes all logging up to the DEBUG
+level.</p>
+</li>
+<li>
+<p>When possible, logging should be kept on a single line if it
+makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
+while lengths longer than about 130 or 160 characters (including the length of
+the tag) should be avoided if possible.</p>
+</li>
+<li>
+<p>Logging that reports successes should never be used at levels
+higher than VERBOSE.</p>
+</li>
+<li>
+<p>Temporary logging that is used to diagnose an issue that's
+hard to reproduce should be kept at the DEBUG or VERBOSE level, and should be
+enclosed by if blocks that allow to disable it entirely at compile-time.</p>
+</li>
+<li>
+<p>Be careful about security leaks through the log. Private
+information should be avoided. Information about protected content must
+definitely be avoided. This is especially important when writing framework
+code as it's not easy to know in advance what will and will not be private
+information or protected content.</p>
+</li>
+<li>
+<p><code>System.out.println()</code> (or <code>printf()</code> for native code) should
+never be used. System.out and System.err get redirected to /dev/null, so your
+print statements will have no visible effects. However, all the string
+building that happens for these calls still gets executed.</p>
+</li>
+<li>
+<p><em>The golden rule of logging is that your logs may not
+unnecessarily push other logs out of the buffer, just as others may not push
+out yours.</em></p>
+</li>
+</ul>
+<h3 id="be-consistent">Be Consistent</h3>
+<p>Our parting thought: BE CONSISTENT. If you're editing code, take a few
+minutes to look at the code around you and determine its style. If they use
+spaces around their if clauses, you should too. If their comments have little
+boxes of stars around them, make your comments have little boxes of stars
+around them too.</p>
+<p>The point of having style guidelines is to have a common vocabulary of
+coding, so people can concentrate on what you're saying, rather than on how
+you're saying it. We present global style rules here so people know the
+vocabulary. But local style is also important. If code you add to a a file
+looks drastically different from the existing code around it, it throws
+readers out of their rhythm when they go to read it. Try to avoid this.</p></p>
+<h2 id="javatests-style-rules">Javatests Style Rules</h2>
+<h3 id="follow-test-method-naming-conventions">Follow Test Method Naming Conventions</h3>
+<p>When naming test methods, you can use an underscore to seperate what is
+being tested from the specific case being tested. This style makes it easier
+to see exactly what cases are being tested.</p>
+<p>For example:</p>
+<pre><code>testMethod_specificCase1 testMethod_specificCase2
+
+void testIsDistinguishable_protanopia() {
+ ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
+ assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
+ assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
+}
+</code></pre>
\ No newline at end of file
diff --git a/src/source/code-style.md b/src/source/code-style.md
deleted file mode 100644
index f4d34d4..0000000
--- a/src/source/code-style.md
+++ /dev/null
@@ -1,745 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Code Style Guidelines for Contributors #
-
-The rules below are not guidelines or recommendations, but strict rules.
-Contributions to Android generally *will not be accepted* if they do not
-adhere to these rules.
-
-Not all existing code follows these rules, but all new code is expected to.
-
-[TOC]
-
-## Java Language Rules ##
-
-We follow standard Java coding conventions. We add a few rules:
-
-### Don't Ignore Exceptions ###
-
-Sometimes it is tempting to write code that completely ignores an exception
-like this:
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) { }
- }
-
-You must never do this. While you may think that your code will never
-encounter this error condition or that it is not important to handle it,
-ignoring exceptions like above creates mines in your code for someone else to
-trip over some day. You must handle every Exception in your code in some
-principled way. The specific handling varies depending on the case.
-
-*Anytime somebody has an empty catch clause they should have a
-creepy feeling. There are definitely times when it is actually the correct
-thing to do, but at least you have to think about it. In Java you can't escape
-the creepy feeling.* -[James Gosling](http://www.artima.com/intv/solid4.html)
-
-Acceptable alternatives (in order of preference) are:
-
-- Throw the exception up to the caller of your method.
-
- void setServerPort(String value) throws NumberFormatException {
- serverPort = Integer.parseInt(value);
- }
-
-- Throw a new exception that's appropriate to your level of abstraction.
-
- void setServerPort(String value) throws ConfigurationException {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- throw new ConfigurationException("Port " + value + " is not valid.");
- }
- }
-
-- Handle the error gracefully and substitute an appropriate value in the
-catch {} block.
-
- /** Set port. If value is not a valid number, 80 is substituted. */
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- serverPort = 80; // default port for server
- }
- }
-
-- Catch the Exception and throw a new `RuntimeException`. This is dangerous:
-only do it if you are positive that if this error occurs, the appropriate
-thing to do is crash.
-
- /** Set port. If value is not a valid number, die. */
-
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- throw new RuntimeException("port " + value " is invalid, ", e);
- }
- }
-
- Note that the original exception is passed to the constructor for
- RuntimeException. If your code must compile under Java 1.3, you will need to
- omit the exception that is the cause.
-
-- Last resort: if you are confident that actually ignoring the exception is
-appropriate then you may ignore it, but you must also comment why with a good
-reason:
-
- /** If value is not a valid number, original port number is used. */
- void setServerPort(String value) {
- try {
- serverPort = Integer.parseInt(value);
- } catch (NumberFormatException e) {
- // Method is documented to just ignore invalid user input.
- // serverPort will just be unchanged.
- }
- }
-
-### Don't Catch Generic Exception ###
-
-Sometimes it is tempting to be lazy when catching exceptions and do
-something like this:
-
- try {
- someComplicatedIOFunction(); // may throw IOException
- someComplicatedParsingFunction(); // may throw ParsingException
- someComplicatedSecurityFunction(); // may throw SecurityException
- // phew, made it all the way
- } catch (Exception e) { // I'll just catch all exceptions
- handleError(); // with one generic handler!
- }
-
-You should not do this. In almost all cases it is inappropriate to catch
-generic Exception or Throwable, preferably not Throwable, because it includes
-Error exceptions as well. It is very dangerous. It means that Exceptions you
-never expected (including RuntimeExceptions like ClassCastException) end up
-getting caught in application-level error handling. It obscures the failure
-handling properties of your code. It means if someone adds a new type of
-Exception in the code you're calling, the compiler won't help you realize you
-need to handle that error differently. And in most cases you shouldn't be
-handling different types of exception the same way, anyway.
-
-There are rare exceptions to this rule: certain test code and top-level
-code where you want to catch all kinds of errors (to prevent them from showing
-up in a UI, or to keep a batch job running). In that case you may catch
-generic Exception (or Throwable) and handle the error appropriately. You
-should think very carefully before doing this, though, and put in comments
-explaining why it is safe in this place.
-
-Alternatives to catching generic Exception:
-
-- Catch each exception separately as separate catch blocks after a single
-try. This can be awkward but is still preferable to catching all Exceptions.
-Beware repeating too much code in the catch blocks.</li>
-
-- Refactor your code to have more fine-grained error handling, with multiple
-try blocks. Split up the IO from the parsing, handle errors separately in each
-case.
-
-- Rethrow the exception. Many times you don't need to catch the exception at
-this level anyway, just let the method throw it.
-
-Remember: exceptions are your friend! When the compiler complains you're
-not catching an exception, don't scowl. Smile: the compiler just made it
-easier for you to catch runtime problems in your code.
-
-### Don't Use Finalizers ###
-
-Finalizers are a way to have a chunk of code executed
-when an object is garbage collected.
-
-Pros: can be handy for doing cleanup, particularly of external resources.
-
-Cons: there are no guarantees as to when a finalizer will be called,
-or even that it will be called at all.
-
-Decision: we don't use finalizers. In most cases, you can do what
-you need from a finalizer with good exception handling. If you absolutely need
-it, define a close() method (or the like) and document exactly when that
-method needs to be called. See InputStream for an example. In this case it is
-appropriate but not required to print a short log message from the finalizer,
-as long as it is not expected to flood the logs.
-
-### Fully Qualify Imports ###
-
-When you want to use class Bar from package foo,there
-are two possible ways to import it:
-
-1. `import foo.*;`
-
-Pros: Potentially reduces the number of import statements.
-
-1. `import foo.Bar;`
-
-Pros: Makes it obvious what classes are actually used. Makes
-code more readable for maintainers.
-
-Decision: Use the latter for importing all Android code. An explicit
-exception is made for java standard libraries (`java.util.*`, `java.io.*`, etc.)
-and unit test code (`junit.framework.*`)
-
-## Java Library Rules ##
-
-There are conventions for using Android's Java libraries and tools. In some
-cases, the convention has changed in important ways and older code might use a
-deprecated pattern or library. When working with such code, it's okay to
-continue the existing style (see [Consistency](#consistency)). When
-creating new components never use deprecated libraries.
-
-## Java Style Rules ##
-
-### Use Javadoc Standard Comments ###
-
-Every file should have a copyright statement at the top. Then a package
-statement and import statements should follow, each block separated by a blank
-line. And then there is the class or interface declaration. In the Javadoc
-comments, describe what the class or interface does.
-
- /*
- * Copyright (C) 2010 The Android Open Source Project
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
- package com.android.internal.foo;
-
- import android.os.Blah;
- import android.view.Yada;
-
- import java.sql.ResultSet;
- import java.sql.SQLException;
-
- /**
- * Does X and Y and provides an abstraction for Z.
- */
-
- public class Foo {
- ...
- }
-
-Every class and nontrivial public method you write *must* contain a
-Javadoc comment with at least one sentence describing what the class or method
-does. This sentence should start with a 3rd person descriptive verb.
-
-Examples:
-
- /** Returns the correctly rounded positive square root of a double value. */
- static double sqrt(double a) {
- ...
- }
-
-or
-
- /**
- * Constructs a new String by converting the specified array of
- * bytes using the platform's default character encoding.
- */
- public String(byte[] bytes) {
- ...
- }
-
-You do not need to write Javadoc for trivial get and set methods such as
-`setFoo()` if all your Javadoc would say is "sets Foo". If the method does
-something more complex (such as enforcing a constraint or having an important
-side effect), then you must document it. And if it's not obvious what the
-property "Foo" means, you should document it.
-
-Every method you write, whether public or otherwise, would benefit from
-Javadoc. Public methods are part of an API and therefore require Javadoc.
-
-Android does not currently enforce a specific style for writing Javadoc
-comments, but you should follow the
-[Sun Javadoc conventions](http://java.sun.com/j2se/javadoc/writingdoccomments/).
-
-### Write Short Methods ###
-
-To the extent that it is feasible, methods should be kept small and
-focused. It is, however, recognized that long methods are sometimes
-appropriate, so no hard limit is placed on method length. If a method exceeds
-40 lines or so, think about whether it can be broken up without harming the
-structure of the program.
-
-### Define Fields in Standard Places ###
-
-Fields should be defined either at the top of the file, or immediately before the methods that use them.
-
-### Limit Variable Scope ###
-
-The scope of local variables should be kept to a minimum (*Effective
-Java* Item 29). By doing so, you increase the readability and
-maintainability of your code and reduce the likelihood of error. Each variable
-should be declared in the innermost block that encloses all uses of the
-variable.
-
-Local variables should be declared at the point they are first used. Nearly
-every local variable declaration should contain an initializer. If you don't
-yet have enough information to initialize a variable sensibly, you should
-postpone the declaration until you do.
-
-One exception to this rule concerns try-catch statements. If a variable is
-initialized with the return value of a method that throws a checked exception,
-it must be initialized inside a try block. If the value must be used outside
-of the try block, then it must be declared before the try block, where it
-cannot yet be sensibly initialized:
-
- // Instantiate class cl, which represents some sort of Set
- Set s = null;
- try {
- s = (Set) cl.newInstance();
- } catch(IllegalAccessException e) {
- throw new IllegalArgumentException(cl + " not accessible");
- } catch(InstantiationException e) {
- throw new IllegalArgumentException(cl + " not instantiable");
- }
-
- // Exercise the set
- s.addAll(Arrays.asList(args));
-
-But even this case can be avoided by encapsulating the try-catch block in a method:
-
- Set createSet(Class cl) {
- // Instantiate class cl, which represents some sort of Set
- try {
- return (Set) cl.newInstance();
- } catch(IllegalAccessException e) {
- throw new IllegalArgumentException(cl + " not accessible");
- } catch(InstantiationException e) {
- throw new IllegalArgumentException(cl + " not instantiable");
- }
- }
-
- ...
-
- // Exercise the set
- Set s = createSet(cl);
- s.addAll(Arrays.asList(args));
-
-Loop variables should be declared in the for statement itself unless there
-is a compelling reason to do otherwise:
-
- for (int i = 0; i n; i++) {
- doSomething(i);
- }
-
-and
-
- for (Iterator i = c.iterator(); i.hasNext(); ) {
- doSomethingElse(i.next());
- }
-
-### Order Import Statements ###
-
-The ordering of import statements is:
-
-1. Android imports
-
-1. Imports from third parties (`com`, `junit`, `net`, `org`)
-
-1. `java` and `javax`
-
-To exactly match the IDE settings, the imports should be:
-
-- Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).
-
-- There should be a blank line between each major grouping (`android`, `com`, `junit`, `net`, `org`, `java`, `javax`).
-
-Originally there was no style requirement on the ordering. This meant that
-the IDE's were either always changing the ordering, or IDE developers had to
-disable the automatic import management features and maintain the imports by
-hand. This was deemed bad. When java-style was asked, the preferred styles
-were all over the map. It pretty much came down to our needing to "pick an
-ordering and be consistent." So we chose a style, updated the style guide, and
-made the IDEs obey it. We expect that as IDE users work on the code, the
-imports in all of the packages will end up matching this pattern without any
-extra engineering effort.
-
-This style was chosen such that:
-
-- The imports people want to look at first tend to be at the top (`android`)
-
-- The imports people want to look at least tend to be at the bottom (`java`)
-
-- Humans can easily follow the style
-
-- IDEs can follow the style
-
-The use and location of static imports have been mildly controversial
-issues. Some people would prefer static imports to be interspersed with the
-remaining imports, some would prefer them reside above or below all other
-imports. Additinally, we have not yet come up with a way to make all IDEs use
-the same ordering.
-
-Since most people consider this a low priority issue, just use your
-judgement and please be consistent.
-
-### Use Spaces for Indentation ###
-
-We use 4 space indents for blocks. We never use tabs. When in doubt, be
-consistent with code around you.
-
-We use 8 space indents for line wraps, including function calls and
-assignments. For example, this is correct:
-
- Instrument i =
- someLongExpression(that, wouldNotFit, on, one, line);
-
-and this is not correct:
-
- Instrument i =
- someLongExpression(that, wouldNotFit, on, one, line);
-
-### Follow Field Naming Conventions ###
-
-- Non-public, non-static field names start with m.
-
-- Static field names start with s.
-
-- Other fields start with a lower case letter.
-
-- Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
-
-For example:
-
- public class MyClass {
- public static final int SOME_CONSTANT = 42;
- public int publicField;
- private static MyClass sSingleton;
- int mPackagePrivate;
- private int mPrivate;
- protected int mProtected;
- }
-
-### Use Standard Brace Style ###
-
-Braces do not go on their own line; they go on the same line as the code
-before them. So:
-
- class MyClass {
- int func() {
- if (something) {
- // ...
- } else if (somethingElse) {
- // ...
- } else {
- // ...
- }
- }
- }
-
-We require braces around the statements for a conditional. Except, if the
-entire conditional (the condition and the body) fit on one line, you may (but
-are not obligated to) put it all on one line. That is, this is legal:
-
- if (condition) {
- body();
- }
-
-and this is legal:
-
- if (condition) body();
-
-but this is still illegal:
-
- if (condition)
- body(); // bad!
-
-### Limit Line Length ###
-
-Each line of text in your code should be at most 100 characters long.
-
-There has been lots of discussion about this rule and the decision remains
-that 100 characters is the maximum.
-
-Exception: if a comment line contains an example command or a literal URL
-longer than 100 characters, that line may be longer than 100 characters for
-ease of cut and paste.
-
-Exception: import lines can go over the limit because humans rarely see
-them. This also simplifies tool writing.
-
-### Use Standard Java Annotations ###
-
-Annotations should precede other modifiers for the same language element.
-Simple marker annotations (e.g. @Override) can be listed on the same line with
-the language element. If there are multiple annotations, or parameterized
-annotations, they should each be listed one-per-line in alphabetical
-order.<
-
-Android standard practices for the three predefined annotations in Java are:
-
-- `@Deprecated`: The @Deprecated annotation must be used whenever the use of the annotated
-element is discouraged. If you use the @Deprecated annotation, you must also
-have a @deprecated Javadoc tag and it should name an alternate implementation.
-In addition, remember that a @Deprecated method is *still supposed to
-work.*
-
- If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.
-
-- `@Override`: The @Override annotation must be used whenever a method overrides the
-declaration or implementation from a super-class.
-
- For example, if you use the @inheritdocs Javadoc tag, and derive from a
- class (not an interface), you must also annotate that the method @Overrides
- the parent class's method.
-
-- `@SuppressWarnings`: The @SuppressWarnings annotation should only be used under circumstances
-where it is impossible to eliminate a warning. If a warning passes this
-"impossible to eliminate" test, the @SuppressWarnings annotation *must* be
-used, so as to ensure that all warnings reflect actual problems in the
-code.
-
- When a @SuppressWarnings annotation is necessary, it must be prefixed with
- a TODO comment that explains the "impossible to eliminate" condition. This
- will normally identify an offending class that has an awkward interface. For
- example:
-
- // TODO: The third-party class com.third.useful.Utility.rotate() needs generics
- @SuppressWarnings("generic-cast")
- List<String> blix = Utility.rotate(blax);
-
- When a @SuppressWarnings annotation is required, the code should be
- refactored to isolate the software elements where the annotation applies.
-
-### Treat Acronyms as Words ###
-
-Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable:
-
-Good | Bad
----------------|-------
-XmlHttpRequest | XMLHTTPRequest
-getCustomerId | getCustomerID
-class Html | class HTML
-String url | String URL
-long id | long ID
-
-Both the JDK and the Android code bases are very inconsistent with regards
-to acronyms, therefore, it is virtually impossible to be consistent with the
-code around you. Bite the bullet, and treat acronyms as words.
-
-For further justifications of this style rule, see *Effective Java*
-Item 38 and *Java Puzzlers* Number 68.
-
-### Use TODO Comments ###
-
-Use TODO comments for code that is temporary, a short-term solution, or
-good-enough but not perfect.
-
-TODOs should include the string TODO in all caps, followed by a colon:
-
- // TODO: Remove this code after the UrlTable2 has been checked in.
-
-and
-
- // TODO: Change this to use a flag instead of a constant.
-
-If your TODO is of the form "At a future date do something" make sure that
-you either include a very specific date ("Fix by November 2005") or a very
-specific event ("Remove this code after all production mixers understand
-protocol V7.").
-
-### Log Sparingly ###
-
-While logging is necessary it has a significantly negative impact on
-performance and quickly loses its usefulness if it's not kept reasonably
-terse. The logging facilities provides five different levels of logging. Below
-are the different levels and when and how they should be used.
-
-- `ERROR`:
-This level of logging should be used when something fatal has happened,
-i.e. something that will have user-visible consequences and won't be
-recoverable without explicitly deleting some data, uninstalling applications,
-wiping the data partitions or reflashing the entire phone (or worse). This
-level is always logged. Issues that justify some logging at the ERROR level
-are typically good candidates to be reported to a statistics-gathering
-server.
-
-- `WARNING`:
-This level of logging should used when something serious and unexpected
-happened, i.e. something that will have user-visible consequences but is
-likely to be recoverable without data loss by performing some explicit action,
-ranging from waiting or restarting an app all the way to re-downloading a new
-version of an application or rebooting the device. This level is always
-logged. Issues that justify some logging at the WARNING level might also be
-considered for reporting to a statistics-gathering server.
-
-- `INFORMATIVE:`
-This level of logging should used be to note that something interesting to
-most people happened, i.e. when a situation is detected that is likely to have
-widespread impact, though isn't necessarily an error. Such a condition should
-only be logged by a module that reasonably believes that it is the most
-authoritative in that domain (to avoid duplicate logging by non-authoritative
-components). This level is always logged.
-
-- `DEBUG`:
-This level of logging should be used to further note what is happening on the
-device that could be relevant to investigate and debug unexpected behaviors.
-You should log only what is needed to gather enough information about what is
-going on about your component. If your debug logs are dominating the log then
-you probably should be using verbose logging.
-
- This level will be logged, even
-on release builds, and is required to be surrounded by an `if (LOCAL_LOG)` or `if
-(LOCAL_LOGD)` block, where `LOCAL_LOG[D]` is defined in your class or
-subcomponent, so that there can exist a possibility to disable all such
-logging. There must therefore be no active logic in an `if (LOCAL_LOG)` block.
-All the string building for the log also needs to be placed inside the `if
-(LOCAL_LOG)` block. The logging call should not be re-factored out into a
-method call if it is going to cause the string building to take place outside
-of the `if (LOCAL_LOG)` block.
-
- There is some code that still says `if
-(localLOGV)`. This is considered acceptable as well, although the name is
-nonstandard.
-
-- `VERBOSE`:
-This level of logging should be used for everything else. This level will only
-be logged on debug builds and should be surrounded by an `if (LOCAL_LOGV)` block
-(or equivalent) so that it can be compiled out by default. Any string building
-will be stripped out of release builds and needs to appear inside the `if (LOCAL_LOGV)` block.
-
-*Notes:*
-
-- Within a given module, other than at the VERBOSE level, an
-error should only be reported once if possible: within a single chain of
-function calls within a module, only the innermost function should return the
-error, and callers in the same module should only add some logging if that
-significantly helps to isolate the issue.
-
-- In a chain of modules, other than at the VERBOSE level, when a
-lower-level module detects invalid data coming from a higher-level module, the
-lower-level module should only log this situation to the DEBUG log, and only
-if logging provides information that is not otherwise available to the caller.
-Specifically, there is no need to log situations where an exception is thrown
-(the exception should contain all the relevant information), or where the only
-information being logged is contained in an error code. This is especially
-important in the interaction between the framework and applications, and
-conditions caused by third-party applications that are properly handled by the
-framework should not trigger logging higher than the DEBUG level. The only
-situations that should trigger logging at the INFORMATIVE level or higher is
-when a module or application detects an error at its own level or coming from
-a lower level.
-
-- When a condition that would normally justify some logging is
-likely to occur many times, it can be a good idea to implement some
-rate-limiting mechanism to prevent overflowing the logs with many duplicate
-copies of the same (or very similar) information.
-
-- Losses of network connectivity are considered common and fully
-expected and should not be logged gratuitously. A loss of network connectivity
-that has consequences within an app should be logged at the DEBUG or VERBOSE
-level (depending on whether the consequences are serious enough and unexpected
-enough to be logged in a release build).
-
-- A full filesystem on a filesystem that is acceessible to or on
-behalf of third-party applications should not be logged at a level higher than
-INFORMATIVE.
-
-- Invalid data coming from any untrusted source (including any
-file on shared storage, or data coming through just about any network
-connections) is considered expected and should not trigger any logging at a
-level higher then DEBUG when it's detected to be invalid (and even then
-logging should be as limited as possible).
-
-- Keep in mind that the `+` operator, when used on Strings,
-implicitly creates a `StringBuilder` with the default buffer size (16
-characters) and potentially quite a few other temporary String objects, i.e.
-that explicitly creating StringBuilders isn't more expensive than relying on
-the default '+' operator (and can be a lot more efficient in fact). Also keep
-in mind that code that calls `Log.v()` is compiled and executed on release
-builds, including building the strings, even if the logs aren't being
-read.
-
-- Any logging that is meant to be read by other people and to be
-available in release builds should be terse without being cryptic, and should
-be reasonably understandable. This includes all logging up to the DEBUG
-level.
-
-- When possible, logging should be kept on a single line if it
-makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
-while lengths longer than about 130 or 160 characters (including the length of
-the tag) should be avoided if possible.
-
-- Logging that reports successes should never be used at levels
-higher than VERBOSE.
-
-- Temporary logging that is used to diagnose an issue that's
-hard to reproduce should be kept at the DEBUG or VERBOSE level, and should be
-enclosed by if blocks that allow to disable it entirely at compile-time.
-
-- Be careful about security leaks through the log. Private
-information should be avoided. Information about protected content must
-definitely be avoided. This is especially important when writing framework
-code as it's not easy to know in advance what will and will not be private
-information or protected content.
-
-- `System.out.println()` (or `printf()` for native code) should
-never be used. System.out and System.err get redirected to /dev/null, so your
-print statements will have no visible effects. However, all the string
-building that happens for these calls still gets executed.
-
-- *The golden rule of logging is that your logs may not
-unnecessarily push other logs out of the buffer, just as others may not push
-out yours.*
-
-### Be Consistent ###
-
-Our parting thought: BE CONSISTENT. If you're editing code, take a few
-minutes to look at the code around you and determine its style. If they use
-spaces around their if clauses, you should too. If their comments have little
-boxes of stars around them, make your comments have little boxes of stars
-around them too.
-
-The point of having style guidelines is to have a common vocabulary of
-coding, so people can concentrate on what you're saying, rather than on how
-you're saying it. We present global style rules here so people know the
-vocabulary. But local style is also important. If code you add to a a file
-looks drastically different from the existing code around it, it throws
-readers out of their rhythm when they go to read it. Try to avoid this.</p>
-
-## Javatests Style Rules ##
-
-### Follow Test Method Naming Conventions ###
-
-When naming test methods, you can use an underscore to seperate what is
-being tested from the specific case being tested. This style makes it easier
-to see exactly what cases are being tested.
-
-For example:
-
- testMethod_specificCase1 testMethod_specificCase2
-
-
- void testIsDistinguishable_protanopia() {
- ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
- assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
- assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
- }
-
diff --git a/src/source/community/groups-charter.jd b/src/source/community/groups-charter.jd
new file mode 100644
index 0000000..d743041
--- /dev/null
+++ b/src/source/community/groups-charter.jd
@@ -0,0 +1,43 @@
+page.title=Android Discussion Groups Charter
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<h2 id="audience">Audience</h2>
+<p>
+These discussion groups are intended for developers working with the Android platform. Everyone is welcome to join in, provided you follow our community's policies described below. Our users help each other, and many experts post to these groups, including members of the Open Handset Alliance.
+</p>
+<p>
+No topic is off-limits, provided it relates to Android in some way. However, since these are very busy lists, search the archives before posting your question; you may find your question has already been answered.
+</p>
+
+<h2 id="mailing">Mailing list rules</h2>
+<p>We love simplicity and hate restrictions, so we keep our policies minimal. The rules
+below describe what's expected of subscribers to the Android mailing lists.</h2>
+
+<ul>
+ <li><em>Please be friendly</em>: Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive toward anyone; if you think there is, think again before you post. Mobile development is serious business, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source.
+ </li>
+ <li><em>Allowed discussion topics<em>: Most of our groups are for technical discussions of Android or users helping each other. Generally we don't put hard restrictions on the topics discussed in the group: as long as the topic is relevant to Android in some way, it's welcome on our groups. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news, but please do not cross-post. Post only to the most relevant group for your message. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen.
+ </li>
+ <li><em>Working Lists</em>: Some of our groups are considered "working lists", by which we mean that the list is intended to be used in support of the completion of specific tasks. On these groups, we don't welcome off-topic conversations, and will generally ask you to take general discussions to a different list. Since these are lists where people are trying to get work done, we will be pretty aggressive about keeping the noise level low. We ask that you respect our contributors' time and keep general discussions to appropriate lists.
+ </li>
+ <li><em>Spam</em>: We hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
+ </li>
+</ul>
+<p>
+The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one. That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
+</p>
+<h2 id="contacting">Contacting the moderators</h2>
+<p>
+If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
+</p>
+<p>
+But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
+</p>
\ No newline at end of file
diff --git a/src/source/community/index.jd b/src/source/community/index.jd
new file mode 100644
index 0000000..0af20a6
--- /dev/null
+++ b/src/source/community/index.jd
@@ -0,0 +1,171 @@
+page.title=Android Community
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Welcome to the Android community!</p>
+<p>The key to any community is, obviously, communication. Like most projects,
+Android communicates via mailing lists. Because Android is an extremely large
+project with many components, we have many discussion forums, each focusing on
+a different topic.</p>
+<p>Please check out the groups below, and join any that seem interesting to
+you. Note that if you're a user looking for help with your Android device,
+this page probably isn't for you; you should contact your carrier or retailer
+for help with your phone.</p>
+<p>Please note that if you're looking for information about building
+applications for Android, you can find a separate set of groups for those at
+our sister site, developer.android.com: [https://developer.android.com/resources/community-groups.html]</p>
+
+<h2 id="open-source-project-discussions">Open Source Project discussions</h2>
+<ul>
+<li>
+<p><em>android-platform</em>:
+ This list is for general discussion about the Android open-source project or the platform technologies.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-platform">android-platform</a></li>
+<li>Subscribe via email: <a href="mailto:android-platform+subscribe@googlegroups.com">android-platform</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-building</em>:
+ Subscribe to this list for discussion and help on building the Android source code, and on the build system. If you've just checked out the source code and have questions about how to turn it into binaries, start here.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-building">android-building</a></li>
+<li>Subscribe via email: <a href="mailto:android-building+subscribe@googlegroups.com">android-building</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-porting</em>:
+ This list is for developers who want to port Android to a new device. If you're wondering how to combine the Android source code with your hardware, this is the right group for you. Discuss here the specifics of porting Android to individual devices, from obtaining toolchains and merging kernel drivers all the way to configuring or modifying applications for your specific
+configuration.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-porting">android-porting</a></li>
+<li>Subscribe via email: <a href="mailto:android-porting+subscribe@googlegroups.com">android-porting</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-contrib</em>:
+ This list is for developers who want to contribute code to Android. This is a working list, and is not appropriate for general discussion. We ask that general discussion go to android-platform. Note: contributors to the Android kernel should go to the android-kernel list, below.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-contrib">android-contrib</a></li>
+<li>Subscribe via email: <a href="mailto:android-contrib+subscribe@googlegroups.com">android-contrib</a></li>
+</ul>
+</li>
+<li>
+<p><em>android-kernel</em>:
+ This list is for deveopers who want to contribute to the Linux kernel that Android devices use. If you've downloaded the kernel code, if you know how to compile it, if you want to write kernel code to specifically support Android,
+this is your place. This group isn't for user-space topics (see android-platform for that), and people will shake their fingers at you and call you naughty if you ask user-space questions here.</p>
+<ul>
+<li>Subscribe using Google Groups: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-kernel">android-kernel</a></li>
+<li>Subscribe via email: <a href="mailto:android-kernel+subscribe@googlegroups.com">android-kernel</a></li>
+</ul>
+</li>
+</ul>
+
+
+<h3 id="audience">Audience</h3>
+<p>
+These discussion groups are intended for developers working with the Android platform. Everyone is welcome to join in, provided you follow our community's policies described below. Our users help each other, and many experts post to these groups, including members of the Open Handset Alliance.
+</p>
+<p>
+No topic is off-limits, provided it relates to Android in some way. However, since these are very busy lists, search the archives before posting your question; you may find your question has already been answered.
+</p>
+
+
+<h3 id="getting-the-most-from-our-lists">Getting the Most from Our Lists</h3>
+<p>Please consider the following before you post to our lists.</p>
+<ul>
+<li>
+<p><em>Read the <a href="#mailing">Charter for our forums.</a></em> This explains the (few) rules and guidelines for our community.</p>
+</li>
+<li>
+<p><em>Search the group archives to see whether your questions have already been discussed.</em> This avoids time-wasting redundant discussions.</p>
+</li>
+<li>
+<p><em>Use a clear, relevant message subject.</em> This helps everyone, both those trying to answer your question as well as those who may be looking for information in the future.</p>
+</li>
+<li>
+<p><em>Give plenty of details in your post.</em> Code or log snippets, pointers to screenshots, and similar details will get better results and make for better discussions. For a great guide to phrasing your questions, read <a href="http://www.catb.org/%7Eesr/faqs/smart-questions.html">How to Ask Questions the Smart Way</a>.
+<img src="/images/external-link.png"></p>
+</li>
+</ul>
+
+<h3 id="mailing">Mailing list rules</h3>
+<p>We love simplicity and hate restrictions, so we keep our policies minimal. The rules
+below describe what's expected of subscribers to the Android mailing lists.</h2>
+
+<ul>
+ <li><em>Please be friendly</em>: Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive toward anyone; if you think there is, think again before you post. Mobile development is serious business, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source.
+ </li>
+ <li><em>Allowed discussion topics</em>: Most of our groups are for technical discussions of Android or users helping each other. Generally we don't put hard restrictions on the topics discussed in the group: as long as the topic is relevant to Android in some way, it's welcome on our groups. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news, but please do not cross-post. Post only to the most relevant group for your message. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen.
+ </li>
+ <li><em>Working Lists</em>: Some of our groups are considered "working lists", by which we mean that the list is intended to be used in support of the completion of specific tasks. On these groups, we don't welcome off-topic conversations, and will generally ask you to take general discussions to a different list. Since these are lists where people are trying to get work done, we will be pretty aggressive about keeping the noise level low. We ask that you respect our contributors' time and keep general discussions to appropriate lists.
+ </li>
+ <li><em>Spam</em>: We hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
+ </li>
+</ul>
+<p>
+The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one. That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
+</p>
+<h3 id="contacting">Contacting the moderators</h3>
+<p>
+If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
+</p>
+<p>
+But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
+</p>
+
+
+
+<h3 id="using-email-with-google-groups">Using email with Google Groups</h3>
+<p>Instead of using the <a href="https://groups.google.com/">Google groups</a> site, you can use your email client of choice to participate in the mailing lists.</p>
+<p>To subscribe to a group without using the Google Groups site, use the link under "subscribe via email" in the lists above.</p>
+<p>To set up how you receive mailing list postings by email:</p>
+<ol>
+<li>
+<p>Sign into the group via the Google Groups site. For example, for the android-platform group you would use [https://groups.google.com/forum/?fromgroups#!forum/android-platform].</p>
+</li>
+<li>
+<p>Click "My membership" on the right side.</p>
+</li>
+<li>
+<p>Under "How do you want to read this group?" select one of the email options.</p>
+</li>
+</ol>
+<h2 id="android-on-irc">Android on IRC</h2>
+<p>We also have a presence on IRC via <a href="http://freenode.net/">freenode</a>.
+We maintain two official IRC channels on <a href="irc://irc.freenode.net/">irc.freenode.net</a> (access via the web
+at <a href="http://webchat.freenode.net/">freenode webchat</a>)</p>
+<ul>
+<li>
+<p><a href="irc://irc.freenode.net/android">#android</a> - dedicated to general Android discussion and porting concerns</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-dev">#android-dev</a> - dedicated to discussion about writing Android applications</p>
+</li>
+</ul>
+<p>The channels above are official. There are a few other channels the
+community is using, but are not official. These aren't official or officially
+moderated/managed, so you use the channels below at your own risk. The Open
+Handset Alliance doesn't endorse these channels, there's no warranty express
+or implied, and so on. There may be more channels than just these listed.</p>
+<ul>
+<li>
+<p><a href="irc://irc.freenode.net/android-firehose">#android-firehose</a> - displays in real-time the commits to the Android Open Source Project</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-fr">#android-fr</a> - pour discuter d'Android en français</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-offtopic">#android-offtopic</a> - for, well, off-topic discussions</p>
+</li>
+<li>
+<p><a href="irc://irc.freenode.net/android-root">#android-root</a> - for discussion related to off-label uses of hardware</p>
+</li>
+</ul>
diff --git a/src/source/contributing.jd b/src/source/contributing.jd
new file mode 100644
index 0000000..377c449
--- /dev/null
+++ b/src/source/contributing.jd
@@ -0,0 +1,49 @@
+page.title=Contributing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Thanks for your interest in Android! Here are some ways you can get involved
+and help us improve Android. For background on the Android project and our
+goals, check out the <a href="/source/index.html">Overview</a> page.</p>
+<h2 id="report-bugs">Report Bugs</h2>
+
+<p>One of the easiest and most effective ways you can help improve Android is
+to file bugs. For more information, visit the <a href="report-bugs.html">Reporting Bugs</a> page.</p>
+<p>Please note that we can't guarantee that any particular bug will be fixed in
+any particular release. To see what happens to your bug once you report it,
+read <a href="life-of-a-bug.html">Life of a Bug</a>.</p>
+
+<h2 id="develop-apps">Develop Apps</h2>
+<p>We created Android so that all developers can distribute their applications
+to users on an open platform. One of the best ways you can help Android is to
+write cool apps that users love!</p>
+
+<p>To get started, visit <a href="https://developer.android.com">developer.android.com</a>. This site
+provides the information and tools you need to write applications for
+compatible Android devices, using the SDK.</p>
+
+<h2 id="contribute-to-the-code">Contribute to the Code</h2>
+<p>Code is King. We'd love to review any changes you submit, so please check
+out the source, pick a bug or feature, and get coding. Note that the smaller
+and more targetted your patch submissions, the easier it will be for us to
+review them.</p>
+
+<p>You can get started with Android by learning about the <a href="life-of-a-patch.html">Life of a Patch</a>,
+and by learning about <code>git</code>, <code>repo</code>, and other tools using the links to the left.
+You can also view the activity on all contributions on our
+<a href="https://android-review.googlesource.com/">Gerrit server</a>.
+If you need help along the way, you can join our <a href="/source/index.html">discussion groups</a>.</p>
\ No newline at end of file
diff --git a/src/source/developing.jd b/src/source/developing.jd
new file mode 100644
index 0000000..d8bfb05
--- /dev/null
+++ b/src/source/developing.jd
@@ -0,0 +1,159 @@
+page.title=Developing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>To work with the Android code, you will need to use both Git and Repo. In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however.</p>
+<p><strong>Git</strong> is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits. One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.</p>
+<p><strong>Repo</strong> is a repository management tool that we built on top of Git. Repo
+unifies the many Git repositories when necessary, does the uploads to our
+<a href="https://android-review.googlesource.com/">revision control system</a>, and
+automates parts of the Android development workflow. Repo is not meant to
+replace Git, only to make it easier to work with Git in the context of
+Android. The repo command is an executable Python script that you can put
+anywhere in your path. In working with the Android source files, you will
+use Repo for across-network operations. For example, with a single Repo
+command you can download files from multiple repositories into your local
+working directory.</p>
+<p><strong>Gerrit</strong> is a web-based code review system for projects that use git. Gerrit encourages more centralized use of Git by allowing all authorized users to submit changes, which are automatically merged if they pass code review. In addition, Gerrit makes reviewing easier by displaying changes side by side in-browser and enabling inline comments. </p>
+<h2 id="basic-workflow">Basic Workflow</h2>
+<div style="float:right">
+ <img src="{@docRoot}images/submit-patches-0.png" alt="basic workflow diagram">
+</div>
+
+<p>The basic pattern of interacting with the repositories is as follows:</p>
+<ol>
+<li>
+<p>Use <code>repo start</code> to start a new topic branch.</p>
+</li>
+<li>
+<p>Edit the files.</p>
+</li>
+<li>
+<p>Use <code>git add</code> to stage changes.</p>
+</li>
+<li>
+<p>Use <code>git commit</code> to commit changes.</p>
+</li>
+<li>
+<p>Use <code>repo upload</code> to upload changes to the review server.</p>
+</li>
+</ol>
+<h2 id="task-reference">Task reference</h2>
+<p>The task list below shows a summary of how to do common Repo and Git tasks.
+For information about using repo to download source, see <a href="{@docRoot}source/downloading.html">Downloading the Source</a> and
+<a href="{@docRoot}source/using-repo.html">Using Repo</a>.</p>
+<h2 id="synchronizing-your-client">Synchronizing your client</h2>
+<p>To synchronize the files for all available projects: </p>
+<pre><code>$ repo sync
+</code></pre>
+<p>To synchronize the files for selected projects:</p>
+<pre><code>$ repo sync PROJECT0 PROJECT1 PROJECT2 ...
+</code></pre>
+<h2 id="creating-topic-branches">Creating topic branches</h2>
+<p>Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature. A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you can isolate one aspect of your work from the others. For an interesting article about using topic branches, see <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt">Separating topic branches</a>.
+<img src="/images/external-link.png" alt=""></p>
+<p>To start a topic branch using Repo: </p>
+<pre><code>$ repo start BRANCH_NAME
+</code></pre>
+<p>To verify that your new branch was created:</p>
+<pre><code>$ repo status
+</code></pre>
+<h2 id="using-topic-branches">Using topic branches</h2>
+<p>To assign the branch to a particular project:</p>
+<pre><code>$ repo start BRANCH_NAME PROJECT
+</code></pre>
+<p>To switch to another branch that you have created in your local work environment:</p>
+<pre><code>$ git checkout BRANCH_NAME
+</code></pre>
+<p>To see a list of existing branches:</p>
+<pre><code>$ git branch
+</code></pre>
+<p>or </p>
+<pre><code>$ repo branches
+</code></pre>
+<p>The name of the current branch will be preceded by an asterisk.</p>
+<p><em>Note: A bug might be causing <code>repo sync</code> to reset the local topic branch. If <code>git branch</code> shows * (no branch) after you run <code>repo sync</code>, then run <code>git checkout</code> again.</em></p>
+<h2 id="staging-files">Staging files</h2>
+<p>By default, Git notices but does not track the changes you make in a project. In order to tell git to preserve your changes, you must mark them for inclusion in a commit. This is also called "staging". </p>
+<p>You can stage your changes by running</p>
+<pre><code>git add
+</code></pre>
+<p>which accepts as arguments any files or directories within the project directory. Despite the name, <code>git add</code> does not simply add files to the git repository; it can also be used to stage file modifications and deletions.</p>
+<h2 id="viewing-client-status">Viewing client status</h2>
+<p>To list the state of your files:</p>
+<pre><code>$ repo status
+</code></pre>
+<p>To see uncommitted edits:</p>
+<pre><code>$ repo diff
+</code></pre>
+<p>The <code>repo diff</code> command shows every local edit that you have made that would <em>not</em> go into the commit, if you were to commit right now. To see every edit that would go into the commit if you were to commit right now, you need a Git command, <code>git diff</code>. Before running it, be sure you are in the project directory:</p>
+<pre><code>$ cd ~/WORKING_DIRECTORY/PROJECT
+$ git diff --cached
+</code></pre>
+<h2 id="committing-changes">Committing changes</h2>
+<p>A commit is the basic unit of revision control in git, consisting of a snapshot of directory structure and file contents for the entire project. Creating a commit in git is as simple as typing</p>
+<pre><code>git commit
+</code></pre>
+<p>You will be prompted for a commit message in your favorite editor; please provide a helpful message for any changes you submit to the AOSP. If you do not add a log message, the commit will be aborted. </p>
+<h2 id="uploading-changes-to-gerrit">Uploading changes to Gerrit</h2>
+<p>Before uploading, update to the latest revisions:</p>
+<pre><code>repo sync
+</code></pre>
+<p>Next run</p>
+<pre><code>repo upload
+</code></pre>
+<p>This will list the changes you have committed and prompt you to select which branches to upload to the review server. If there is only one branch, you will see a simple <code>y/n</code> prompt.</p>
+<h2 id="recovering-sync-conflicts">Recovering sync conflicts</h2>
+<p>If a <code>repo sync</code> shows sync conflicts:</p>
+<ul>
+<li>View the files that are unmerged (status code = U).</li>
+<li>Edit the conflict regions as necessary.</li>
+<li>
+<p>Change into the relevant project directory, run <code>git add</code> and <code>git commit</code> for the files in question, and then "rebase" the changes. For example:</p>
+<pre><code>$ git add .
+$ git commit
+$ git rebase --continue
+</code></pre>
+</li>
+<li>
+<p>When the rebase is complete start the entire sync again:</p>
+<pre><code>$ repo sync PROJECT0 PROJECT1 ... PROJECTN
+</code></pre>
+</li>
+</ul>
+<h2 id="cleaning-up-your-client-files">Cleaning up your client files</h2>
+<p>To update your local working directory after changes are merged in Gerrit:</p>
+<pre><code>$ repo sync
+</code></pre>
+<p>To safely remove stale topic branches: </p>
+<pre><code>$ repo prune
+</code></pre>
+<h2 id="deleting-a-client">Deleting a client</h2>
+<p>Because all state information is stored in your client, you only need to delete the directory from your filesystem:</p>
+<pre><code>$ rm -rf WORKING_DIRECTORY
+</code></pre>
+<p>Deleting a client will <em>permanently delete</em> any changes you have not yet uploaded for review.</p>
+<h2 id="git-and-repo-cheatsheet">Git and Repo cheatsheet</h2>
+<p><img src="/images/git-repo-1.png" alt="list of basic git and repo commands"></p>
diff --git a/src/source/download.html b/src/source/download.html
deleted file mode 100644
index 0820f26..0000000
--- a/src/source/download.html
+++ /dev/null
@@ -1,8 +0,0 @@
-<!DOCTYPE html>
-<html>
-<head>
-<meta http-equiv="refresh" content="0;url=/source/initializing.html" />
-</head>
-<body>
-</body>
-</html>
diff --git a/src/source/downloading.jd b/src/source/downloading.jd
new file mode 100644
index 0000000..7376d41
--- /dev/null
+++ b/src/source/downloading.jd
@@ -0,0 +1,279 @@
+page.title=Downloading the Source
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>
+ The Android source tree is located in a Git repository hosted by Google. This document
+ describes how to download the source tree for a specific Android code-line.
+</p>
+<h2 id="installing-repo">
+ Installing Repo
+</h2>
+<p>
+ Repo is a tool that makes it easier to work with Git in the context of Android. For more
+ information about Repo, see the <a href="developing.html">Developing</a> section.
+</p>
+<p>
+ To install Repo:
+</p>
+<ol>
+ <li>
+ <p>
+ Make sure you have a bin/ directory in your home directory and that it is included in
+ your path:
+ </p>
+ <pre>
+<code>$ mkdir ~/bin
+$ PATH=~/bin:$PATH
+</code>
+</pre>
+ </li>
+ <li>
+ <p>
+ Download the Repo tool and ensure that it is executable:
+ </p>
+ <pre>
+$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
+$ chmod a+x ~/bin/repo
+</pre>
+ </li>
+</ol>
+<p>
+ For version 1.17, the SHA-1 checksum for repo is ddd79b6d5a7807e911b524cb223bc3544b661c28
+</p>
+<h2 id="initializing-a-repo-client">
+ Initializing a Repo client
+</h2>
+<p>
+ After installing Repo, set up your client to access the Android source repository:
+</p>
+<ol>
+ <li>
+ <p>
+ Create an empty directory to hold your working files. If you're using MacOS, this has to
+ be on a case-sensitive filesystem. Give it any name you like:
+ </p>
+<pre>
+$ mkdir WORKING_DIRECTORY
+$ cd WORKING_DIRECTORY
+</pre>
+ </li>
+ <li>
+ <p>
+ Run <code>repo init</code> to bring down the latest version of Repo with all its most
+ recent bug fixes. You must specify a URL for the manifest, which specifies where the
+ various repositories included in the Android source will be placed within your working
+ directory.
+ </p>
+<pre>
+$ repo init -u https://android.googlesource.com/platform/manifest
+</pre>
+ <p>
+ To check out a branch other than "master", specify it with -b:
+ </p>
+<pre>
+$ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
+</pre>
+ </li>
+ <li>
+ <p>
+ When prompted, configure Repo with your real name and email address. To use the Gerrit
+ code-review tool, you will need an email address that is connected with a <a href=
+ "https://www.google.com/accounts">registered Google account</a>. Make sure this is a live
+ address at which you can receive messages. The name that you provide here will show up in
+ attributions for your code submissions.
+ </p>
+ </li>
+</ol>
+<p>
+ A successful initialization will end with a message stating that Repo is initialized in your
+ working directory. Your client directory should now contain a <code>.repo</code> directory
+ where files such as the manifest will be kept.
+</p>
+<h2 id="getting-the-files">
+ Downloading the Android Source Tree
+</h2>
+<p>
+ To pull down the Android source tree to your working directory from the repositories as
+ specified in the default manifest, run
+</p>
+<pre>$ repo sync</pre>
+<p>
+ The Android source files will be located in your working directory under their project names.
+ The initial sync operation will take an hour or more to complete. For more about <code>repo
+ sync</code> and other Repo commands, see the <a href="developing.html">Developing</a> section.
+</p>
+<h2 id="using-authentication">
+ Using Authentication
+</h2>
+<p>
+ By default, access to the Android source code is anonymous. To protect the servers against
+ excessive usage, each IP address is associated with a quota.
+</p>
+<p>
+ When sharing an IP address with other users (e.g. when accessing the source repositories from
+ beyond a NAT firewall), the quotas can trigger even for regular usage patterns (e.g. if many
+ users sync new clients from the same IP address within a short period).
+</p>
+<p>
+ In that case, it is possible to use authenticated access, which then uses a separate quota
+ for each user, regardless of the IP address.
+</p>
+<p>
+ The first step is to create a password from <a href=
+ "https://android.googlesource.com/new-password">the password generator</a> and to save it in
+ <code>~/.netrc</code> according to the instructions on that page.
+</p>
+<p>
+ The second step is to force authenticated access, by using the following manifest URI:
+ <code>https://android.googlesource.com/a/platform/manifest</code>. Notice how the
+ <code>/a/</code> directory prefix triggers mandatory authentication. You can convert an
+ existing client to use mandatory authentication with the following command:
+</p>
+<pre>
+$ repo init -u https://android.googlesource.com/a/platform/manifest
+</pre>
+<h2 id="troubleshooting-network-issues">
+ Troubleshooting network issues
+</h2>
+<p>
+ When downloading from behind a proxy (which is common in some corporate environments), it
+ might be necessary to explicitly specify the proxy that is then used by repo:
+</p>
+<pre>
+$ export HTTP_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
+$ export HTTPS_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
+</pre>
+<p>
+ More rarely, Linux clients experience connectivity issues, getting stuck in the middle of
+ downloads (typically during "Receiving objects"). It has been reported that tweaking the
+ settings of the TCP/IP stack and using non-parallel commands can improve the situation. You
+ need root access to modify the TCP setting:
+</p>
+<pre>
+$ sudo sysctl -w net.ipv4.tcp_window_scaling=0
+$ repo sync -j1
+</pre>
+<h2 id="using-a-local-mirror">
+ Using a local mirror
+</h2>
+<p>
+ When using several clients, especially in situations where bandwidth is scarce, it is better
+ to create a local mirror of the entire server content, and to sync clients from that mirror
+ (which requires no network access). The download for a full mirror is smaller than the
+ download of two clients, while containing more information.
+</p>
+<p>
+ These instructions assume that the mirror is created in <code>/usr/local/aosp/mirror</code>.
+ The first step is to create and sync the mirror itself, which uses close to 13GB of network
+ bandwidth and a similar amount of disk space. Notice the <code>--mirror</code> flag, which
+ can only be specified when creating a new client:
+</p>
+<pre>
+$ mkdir -p /usr/local/aosp/mirror
+$ cd /usr/local/aosp/mirror
+$ repo init -u https://android.googlesource.com/mirror/manifest --mirror
+$ repo sync
+</pre>
+<p>
+ Once the mirror is synced, new clients can be created from it. Note that it's important to
+ specify an absolute path:
+</p>
+<pre>$ mkdir -p /usr/local/aosp/master
+$ cd /usr/local/aosp/master
+$ repo init -u /usr/local/aosp/mirror/platform/manifest.git
+$ repo sync
+</pre>
+<p>
+ Finally, to sync a client against the server, the mirror needs to be synced against the
+ server, then the client against the mirror:
+</p>
+<pre>
+$ cd /usr/local/aosp/mirror
+$ repo sync
+$ cd /usr/local/aosp/master
+$ repo sync
+</pre>
+<p>
+ It's possible to store the mirror on a LAN server and to access it over NFS, SSH or Git. It's
+ also possible to store it on a removable drive and to pass that drive around between users or
+ between machines.
+</p>
+<h2 id="verifying-git-tags">
+ Verifying Git Tags
+</h2>
+<p>
+ Load the following public key into your GnuPG key database. The key is used to sign annotated
+ tags that represent releases.
+</p>
+<pre>
+$ gpg --import
+</pre>
+<p>
+ Copy and paste the key(s) below, then enter EOF (Ctrl-D) to end the input and process the
+ keys.
+</p>
+<pre>
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.4.2.2 (GNU/Linux)
+
+mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
+lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
+8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
+u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
+wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
+/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
+jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
+MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
+b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
+aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
+cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
+gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
+2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
+QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
+hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
+C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
+LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
+OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
+pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
+KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
+N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
+vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
+G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
+hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
+EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
+=Wi5D
+-----END PGP PUBLIC KEY BLOCK-----
+</pre>
+<p>
+ After importing the keys, you can verify any tag with
+</p>
+<pre>
+$ git tag -v TAG_NAME
+</pre>
+<p>
+ If you haven't <a href="initializing.html#ccache">set up ccache</a> yet, now would be a good
+ time to do it.
+</p>
\ No newline at end of file
diff --git a/src/source/downloading.md b/src/source/downloading.md
deleted file mode 100644
index 72dffee..0000000
--- a/src/source/downloading.md
+++ /dev/null
@@ -1,207 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Downloading the Source Tree #
-
-## Installing Repo ##
-
-Repo is a tool that makes it easier to work with Git in the context of Android. For more information about Repo, see [Version Control](version-control.html).
-
-To install, initialize, and configure Repo, follow these steps:
-
- - Make sure you have a bin/ directory in your home directory, and that it is included in your path:
-
- $ mkdir ~/bin
- $ PATH=~/bin:$PATH
-
- - Download the Repo script and ensure it is executable:
-
- $ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
- $ chmod a+x ~/bin/repo
-
- - For version 1.17, the SHA-1 checksum for repo is
- ddd79b6d5a7807e911b524cb223bc3544b661c28
-
-
-## Initializing a Repo client ##
-
-After installing Repo, set up your client to access the android source repository:
-
- - Create an empty directory to hold your working files.
- If you're using MacOS, this has to be on a case-sensitive filesystem.
- Give it any name you like:
-
-
- $ mkdir WORKING_DIRECTORY
- $ cd WORKING_DIRECTORY
-
- - Run `repo init` to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest, which specifies where the various repositories included in the Android source will be placed within your working directory.
-
- $ repo init -u https://android.googlesource.com/platform/manifest
-
- To check out a branch other than "master", specify it with -b:
-
- $ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
-
- - When prompted, please configure Repo with your real name and email address. To use the Gerrit code-review tool, you will need an email address that is connected with a [registered Google account](https://www.google.com/accounts). Make sure this is a live address at which you can receive messages. The name that you provide here will show up in attributions for your code submissions.
-
-A successful initialization will end with a message stating that Repo is initialized in your working directory. Your client directory should now contain a `.repo` directory where files such as the manifest will be kept.
-
-
-## Getting the files ##
-
-To pull down files to your working directory from the repositories as specified in the default manifest, run
-
- $ repo sync
-
-The Android source files will be located in your working directory
-under their project names. The initial sync operation will take
-an hour or more to complete. For more about `repo sync` and other
-Repo commands, see [Version Control](version-control.html).
-
-
-## Using authentication ##
-
-By default, access to the Android source code is anonymous. To protect the
-servers against excessive usage, each IP address is associated with a quota.
-
-When sharing an IP address with other users (e.g. when accessing the source
-repositories from beyond a NAT firewall), the quotas can trigger even for
-regular usage patterns (e.g. if many users sync new clients from the same IP
-address within a short period).
-
-In that case, it is possible to use authenticated access, which then uses
-a separate quota for each user, regardless of the IP address.
-
-The first step is to create a password from
-[the password generator](https://android.googlesource.com/new-password) and
-to save it in `~/.netrc` according to the instructions on that page.
-
-The second step is to force authenticated access, by using the following
-manifest URI: `https://android.googlesource.com/a/platform/manifest`. Notice
-how the `/a/` directory prefix triggers mandatory authentication. You can
-convert an existing client to use mandatory authentication with the following
-command:
-
- $ repo init -u https://android.googlesource.com/a/platform/manifest
-
-## Troubleshooting network issues ##
-
-When downloading from behind a proxy (which is common in some
-corporate environments), it might be necessary to explicitly
-specify the proxy that is then used by repo:
-
- $ export HTTP_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
- $ export HTTPS_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
-
-More rarely, Linux clients experience connectivity issues, getting
-stuck in the middle of downloads (typically during "Receiving objects").
-It has been reported that tweaking the settings of the TCP/IP stack and
-using non-parallel commands can improve the situation. You need root
-access to modify the TCP setting:
-
- $ sudo sysctl -w net.ipv4.tcp_window_scaling=0
- $ repo sync -j1
-
-
-## Using a local mirror ##
-
-When using several clients, especially in situations where bandwidth is scarce,
-it is better to create a local mirror of the entire server content, and to
-sync clients from that mirror (which requires no network access). The download
-for a full mirror is smaller than the download of two clients, while containing
-more information.
-
-These instructions assume that the mirror is created in `/usr/local/aosp/mirror`.
-The first step is to create and sync the mirror itself, which uses close to
-13GB of network bandwidth and a similar amount of disk space. Notice the
-`--mirror` flag, which can only be specified when creating a new client:
-
- $ mkdir -p /usr/local/aosp/mirror
- $ cd /usr/local/aosp/mirror
- $ repo init -u https://android.googlesource.com/mirror/manifest --mirror
- $ repo sync
-
-Once the mirror is synced, new clients can be created from it. Note that it's
-important to specify an absolute path:
-
- $ mkdir -p /usr/local/aosp/master
- $ cd /usr/local/aosp/master
- $ repo init -u /usr/local/aosp/mirror/platform/manifest.git
- $ repo sync
-
-Finally, to sync a client against the server, the mirror needs to be synced
-against the server, then the client against the mirror:
-
- $ cd /usr/local/aosp/mirror
- $ repo sync
- $ cd /usr/local/aosp/master
- $ repo sync
-
-It's possible to store the mirror on a LAN server and to access it over
-NFS, SSH or Git. It's also possible to store it on a removable drive and
-to pass that drive around between users or between machines.
-
-
-## Verifying Git Tags ##
-
-Load the following public key into your GnuPG key database. The key is used to sign annotated tags that represent releases.
-
- $ gpg --import
-
-Copy and paste the key(s) below, then enter EOF (Ctrl-D) to end the input and process the keys.
-
- -----BEGIN PGP PUBLIC KEY BLOCK-----
- Version: GnuPG v1.4.2.2 (GNU/Linux)
-
- mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
- lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
- 8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
- u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
- wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
- /HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
- jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
- MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
- b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
- aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
- cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
- gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
- 2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
- QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
- hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
- C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
- LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
- OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
- pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
- KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
- N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
- vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
- G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
- hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
- EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
- =Wi5D
- -----END PGP PUBLIC KEY BLOCK-----
-
-After importing the keys, you can verify any tag with
-
- $ git tag -v TAG_NAME
-
-If you haven't [set up ccache](initializing.html#ccache) yet,
-now would be a good time to do it.
-
-# Next: Build the code #
-
-You now have a complete local copy of the Android codebase. Continue on to [building](building.html)....
diff --git a/src/source/faqs.jd b/src/source/faqs.jd
new file mode 100644
index 0000000..84ee855
--- /dev/null
+++ b/src/source/faqs.jd
@@ -0,0 +1,445 @@
+page.title=Frequently Asked Questions
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<h2 id="open-source">Open Source</h2>
+<h3 id="what-is-the-android-open-source-project">What is the Android Open Source Project?</h3>
+<p>We use the phrase "Android Open Source Project" or "AOSP" to refer to the
+people, the processes, and the source code that make up Android.</p>
+<p>The people oversee the project and develop the actual source code. The
+processes refer to the tools and procedures we use to manage the development
+of the software. The net result is the source code that you can use to build
+cell phone and other devices.</p>
+<h3 id="why-did-we-open-the-android-source-code">Why did we open the Android source code?</h3>
+<p>Google started the Android project in response to our own experiences
+launching mobile apps. We wanted to make sure that there would always be an
+open platform available for carriers, OEMs, and developers to use to make
+their innovative ideas a reality. We also wanted to make sure that there was no
+central point of failure, so that no single industry player could restrict or control
+the innovations of any other. The single most important goal of the Android
+Open-Source Project (AOSP) is to make sure that the open-source Android
+software is implemented as widely and compatibly as possible, to everyone's
+benefit.</p>
+<p>You can find more information on this topic at our Project Philosophy page.</p>
+<h3 id="what-kind-of-open-source-project-is-android">What kind of open-source project is Android?</h3>
+<p>Google oversees the development of the core Android open-source platform,
+and works to create robust developer and user communities. For the most part
+the Android source code is licensed under the permissive Apache Software
+License 2.0, rather than a "copyleft" license. The main reason for this is
+because our most important goal is widespread adoption of the software, and
+we believe that the ASL2.0 license best achieves that goal.</p>
+<p>You can find more information on this topic at our Project Philosophy and
+Licensing pages. </p>
+<h3 id="why-is-google-in-charge-of-android">Why is Google in charge of Android?</h3>
+<p>Launching a software platform is complex. Openness is vital to the
+long-term success of a platform, since openness is required to attract
+investment from developers and ensure a level playing field. However, the
+platform itself must also be a compelling product to end users.</p>
+<p>That's why Google has committed the professional engineering resources
+necessary to ensure that Android is a fully competitive software platform.
+Google treats the Android project as a full-scale product development
+operation, and strikes the business deals necessary to make sure that great
+devices running Android actually make it to market.</p>
+<p>By making sure that Android is a success with end users, we help ensure the
+vitality of Android as a platform, and as an open-source project. After all,
+who wants the source code to an unsuccessful product?</p>
+<p>Google's goal is to ensure a successful ecosystem around Android, but no
+one is required to participate, of course. We opened the Android source code
+so anyone can modify and distribute the software to meet their own needs.</p>
+<h3 id="what-is-googles-overall-strategy-for-android-product-development">What is Google's overall strategy for Android product development?</h3>
+<p>We focus on releasing great devices into a competitive marketplace, and
+then incorporate the innovations and enhancements we made into the core
+platform, as the next version.</p>
+<p>In practice, this means that the Android engineering team typically focuses
+on a small number of "flagship" devices, and develops the next version of
+the Android software to support those product launches. These flagship
+devices absorb much of the product risk and blaze a trail for the broad OEM
+community, who follow up with many more devices that take advantage of the
+new features. In this way, we make sure that the Android platform evolves
+according to the actual needs of real-world devices.</p>
+<h3 id="how-is-the-android-software-developed">How is the Android software developed?</h3>
+<p>Each platform version of Android (such as 1.5, 1.6, and so on) has a
+corresponding branch in the open-source tree. At any given moment, the most
+recent such branch will be considered the "current stable" branch version.
+This current stable branch is the one that manufacturers port to their
+devices. This branch is kept suitable for release at all times.</p>
+<p>Simultaneously, there is also a "current experimental" branch, which is
+where speculative contributions, such as large next-generation features, are
+developed. Bug fixes and other contributions can be included in the current
+stable branch from the experimental branch as appropriate.</p>
+<p>Finally, Google works on the next version of the Android platform in tandem
+with developing a flagship device. This branch pulls in changes from the
+experimental and stable branches as appropriate.</p>
+<p>You can find more information on this topic at our <a href="source/code-lines.html">Branches and Releases</a>.</p>
+<h3 id="why-are-parts-of-android-developed-in-private">Why are parts of Android developed in private?</h3>
+<p>It typically takes over a year to bring a device to market, but of course
+device manufacturers want to ship the latest software they can. Developers,
+meanwhile, don't want to have to constantly track new versions of the
+platform when writing apps. Both groups experience a tension between
+shipping products, and not wanting to fall behind.</p>
+<p>To address this, some parts of the next version of Android including the
+core platform APIs are developed in a private branch. These APIs constitute
+the next version of Android. Our aim is to focus attention on the current
+stable version of the Android source code, while we create the next version
+of the platform as driven by flagship Android devices. This allows developers
+and OEMs to focus on a single version without having to track unfinished
+future work just to keep up. Other parts of the Android system that aren't
+related to application compatibility are developed in the open, however.
+It's our intention to move more of these parts to open development over
+time.</p>
+<h3 id="when-are-source-code-releases-made">When are source code releases made?</h3>
+<p>When they are ready. Some parts of Android are developed in the open,
+so that source code is always available. Other parts are developed first in
+a private tree, and that source code is released when the next platform
+version is ready.</p>
+<p>In some releases, core platform APIs will be ready far enough in advance
+that we can push the source code out for an early look in advance of the
+device's release; however in others, this isn't possible. In all cases, we
+release the platform source when we feel the version has stabilized enough,
+and when the development process permits. Releasing the source code is a
+fairly complex process.</p>
+<h3 id="what-is-involved-in-releasing-the-source-code-for-a-new-android-version">What is involved in releasing the source code for a new Android version?</h3>
+<p>Releasing the source code for a new version of the Android platform is a
+significant process. First, the software gets built into a system image for
+a device, and put through various forms of certification, including
+government regulatory certification for the regions the phones will be
+deployed. It also goes through operator testing. This is an important phase
+of the process, since it helps shake out a lot of software bugs.</p></p>
+<p>Once the release is approved by the regulators and operators, the
+manufacturer begins mass producing devices, and we turn to releasing the
+source code.</p>
+<p>Simultaneous to mass production the Google team kicks off several efforts
+to prepare the open source release. These efforts include final API changes
+and documentation (to reflect any changes that were made during
+qualification testing, for example), preparing an SDK for the new version,
+and launching the platform compatibility information.</p>
+<p>Also included is a final legal sign-off to release the code into open
+source. Just as open source contributors are required to sign a Contributors
+License Agreement attesting to their IP ownership of their contribution,
+Google too must verify that it is clear to make contributions.</p>
+<p>Starting at the time mass production begins, the software release process
+usually takes around a month, which often roughly places source code
+releases around the same time that the devices reach users.</p>
+<h3 id="how-does-the-aosp-relate-to-the-android-compatibility-program">How does the AOSP relate to the Android Compatibility Program?</h3>
+<p>The Android Open-Source Project maintains the Android software, and
+develops new versions. Since it's open-source, this software can be used for
+any purpose, including to ship devices that are not compatible with other
+devices based on the same source.</p>
+<p>The function of the Android Compatibility Program is to define a baseline
+implementation of Android that is compatible with third-party apps written
+by developers. Devices that are "Android compatible" may participate in the
+Android ecosystem, including Google Play; devices that don't meet the
+compatibility requirements exist outside that ecosystem.</p>
+<p>In other words, the Android Compatibility Program is how we separate
+"Android compatible devices" from devices that merely run derivatives of the
+source code. We welcome all uses of the Android source code, but only
+Android compatible devices -- as defined and tested by the Android
+Compatibility Program -- may participate in the Android ecosystem.</p>
+<h3 id="how-can-i-contribute-to-android">How can I contribute to Android?</h3>
+<p>There are a number of ways you can contribute to Android. You can report
+bugs, write apps for Android, or contribute source code to the Android
+Open-Source Project.</p>
+<p>There are some limits on the kinds of code contributions we are willing or
+able to accept. For instance, someone might want to contribute an
+alternative application API, such as a full C++-based environment. We would
+decline that contribution, since Android is focused on applications that run
+in the Dalvik VM. Alternatively, we won't accept contributions such as GPL
+or LGPL libraries that are incompatible with our licensing goals.</p>
+<p>We encourage those interested in contributing source code to contact us via
+the AOSP Community page prior to beginning any work. You can find more
+information on this topic at the Getting Involved page.</p>
+<h3 id="how-do-i-become-an-android-committer">How do I become an Android committer?</h3>
+<p>The Android Open Source Project doesn't really have a notion of a
+"committer". All contributions -- including those authored by Google
+employees -- go through a web-based system known as "gerrit" that's part of
+the Android engineering process. This system works in tandem with the git
+source code management system to cleanly manage source code
+contributions.</p>
+<p>Once submitted, changes need to be accepted by a designated Approver.
+Approvers are typically Google employees, but the same approvers are
+responsible for all submissions, regardless of origin.</p>
+<p>You can find more information on this topic at the <a href="source/submit-patches.html">Submitting Patches</a> page.</p>
+<h2 id="compatibility">Compatibility</h2>
+<h3 id="what-does-compatibility-mean">What does "compatibility" mean?</h3>
+<p>We define an "Android compatible" device as one that can run any
+application written by third-party developers using the Android SDK and NDK.
+We use this as a filter to separate devices that can participate in the
+Android app ecosystem, and those that cannot. Devices that are properly
+compatible can seek approval to use the Android trademark. Devices that are
+not compatible are merely derived from the Android source code and may not
+use the Android trademark.</p>
+<p>In other words, compatibility is a prerequisite to participate in the
+Android apps ecosystem. Anyone is welcome to use the Android source code,
+but if the device isn't compatible, it's not considered part of the Android
+ecosystem.</p>
+<h3 id="what-is-the-role-of-google-play-in-compatibility">What is the role of Google Play in compatibility?</h3>
+<p>Devices that are Android compatible may seek to license the Google Play
+client software. This allows them to become part of the Android app
+ecosystem, by allowing users to download developers' apps from a catalog
+shared by all compatible devices. This option isn't available to devices
+that aren't compatible.</p>
+<h3 id="what-kinds-of-devices-can-be-android-compatible">What kinds of devices can be Android compatible?</h3>
+<p>The Android software can be ported to a lot of different kinds of devices,
+including some on which third-party apps won't run properly. The Android
+Compatibility Definition Document (CDD) spells out the specific device
+configurations that will be considered compatible.</p>
+<p>For example, though the Android source code could be ported to run on a
+phone that doesn't have a camera, the CDD requires that in order to be
+compatible, all phones must have a camera. This allows developers to rely
+on a consistent set of capabilities when writing their apps.</p>
+<p>The CDD will evolve over time to reflect market realities. For instance,
+the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit
+telephony hardware, allowing for non-phone devices such as tablet-style
+music players to be compatible. As we make these changes, we will also
+augment Google Play to allow developers to retain control over where
+their apps are available. To continue the telephony example, an app that
+manages SMS text messages would not be useful on a media player, so Google
+Play allows the developer to restrict that app exclusively to phone
+devices.</p>
+<h3 id="if-my-device-is-compatible-does-it-automatically-have-access-to-google-play-and-branding">If my device is compatible, does it automatically have access to Google Play and branding?</h3>
+<p>Google Play is a service operated by Google. Achieving compatibility is
+a prerequisite for obtaining access to the Google Play software and branding.
+Device manufacturers should contact Google to obtain access to Google
+Play.</p>
+<h3 id="if-i-am-not-a-manufacturer-how-can-i-get-google-play">If I am not a manufacturer, how can I get Google Play?</h3>
+<p>Google Play is only licensed to handset manufacturers shipping devices.
+For questions about specific cases, contact android-partnerships@google.com.</p>
+<h3 id="how-can-i-get-access-to-the-google-apps-for-android-such-as-maps">How can I get access to the Google apps for Android, such as Maps?</h3>
+<p>The Google apps for Android, such as YouTube, Google Maps and Navigation,
+Gmail, and so on are Google properties that are not part of Android, and
+are licensed separately. Contact android-partnerships@google.com for
+inquiries related to those apps.</p>
+<h3 id="is-compatibility-mandatory">Is compatibility mandatory?</h3>
+<p>No. The Android Compatibility Program is optional. Since the Android source
+code is open, anyone can use it to build any kind of device. However, if a
+manufacturer wishes to use the Android name with their product, or wants
+access to Google Play, they must first demonstrate that the device is
+compatible.</p>
+<h3 id="how-much-does-compatibility-certification-cost">How much does compatibility certification cost?</h3>
+<p>There is no cost to obtain Android compatibility for a device. The
+Compatibility Test Suite is open-source and available to anyone to use to
+test a device.</p>
+<h3 id="how-long-does-compatibility-take">How long does compatibility take?</h3>
+<p>The process is automated. The Compatibility Test Suite generates a report
+that can be provided to Google to verify compatibility. Eventually we intend
+to provide self-service tools to upload these reports to a public database.</p>
+<h3 id="who-determines-what-will-be-part-of-the-compatibility-definition">Who determines what will be part of the compatibility definition?</h3>
+<p>Since Google is responsible for the overall direction of Android as a
+platform and product, Google maintains the Compatibility Definition Document
+for each release. We draft the CDD for a new Android version in consultation
+with a number of OEMs, who provide input on its contents.</p>
+<h3 id="how-long-will-each-android-version-be-supported-for-new-devices">How long will each Android version be supported for new devices?</h3>
+<p>Since Android's code is open-source, we can't prevent someone from using an
+old version to launch a device. Instead, Google chooses not to license the
+Google Play client software for use on versions that are considered
+obsolete. This allows anyone to continue to ship old versions of Android,
+but those devices won't use the Android name and will exist outside the
+Android apps ecosystem, just as if they were non-compatible.</p>
+<h3 id="can-a-device-have-a-different-user-interface-and-still-be-compatible">Can a device have a different user interface and still be compatible?</h3>
+<p>The Android Compatibility Program focuses on whether a device can run
+third-party applications. The user interface components shipped with a
+device (such as home screen, dialer, color scheme, and so on) does not
+generally have much effect on third-party apps. As such, device builders are
+free to customize the user interface as much as they like. The Compatibility
+Definition Document does restrict the degree to which OEMs may alter the
+system user interface for areas that do impact third-party apps.</p>
+<h3 id="when-are-compatibility-definitions-released-for-new-android-versions">When are compatibility definitions released for new Android versions?</h3>
+<p>Our goal is to release new versions of Android Compatibility Definition
+Documents (CDDs) once the corresponding Android platform version has
+converged enough to permit it. While we can't release a final draft of a CDD
+for an Android software version before the first flagship device ships with
+that software, final CDDs will always be released after the first device.
+However, wherever practical we will make draft versions of CDDs available.</p>
+<h3 id="how-are-device-manufacturers-compatibility-claims-validated">How are device manufacturers' compatibility claims validated?</h3>
+<p>There is no validation process for Android device compatibility. However,
+if the device is to include Google Play, Google will typically validate
+the device for compatibility before agreeing to license the Google Play client
+software.</p>
+<h3 id="what-happens-if-a-device-that-claims-compatibility-is-later-found-to-have-compatibility-problems">What happens if a device that claims compatibility is later found to have compatibility problems?</h3>
+<p>Typically, Google's relationships with Google Play licensees allow us to
+ask them to release updated system images that fix the problems.</p>
+<h2 id="compatibility-test-suite">Compatibility Test Suite</h2>
+<h3 id="what-is-the-purpose-of-the-cts">What is the purpose of the CTS?</h3>
+<p>The Compatibility Test Suite is a tool used by device manufacturers to help
+ensure their devices are compatible, and to report test results for
+validations. The CTS is intended to be run frequently by OEMs throughout the
+engineering process to catch compatibility issues early.</p>
+<h3 id="what-kinds-of-things-does-the-cts-test">What kinds of things does the CTS test?</h3>
+<p>The CTS currently tests that all of the supported Android strong-typed APIs
+are present and behave correctly. It also tests other non-API system
+behaviors such as application lifecycle and performance. We plan to add
+support in future CTS versions to test "soft" APIs such as Intents as
+well.</p>
+<h3 id="will-the-cts-reports-be-made-public">Will the CTS reports be made public?</h3>
+<p>Yes. While not currently implemented, Google intends to provide web-based
+self-service tools for OEMs to publish CTS reports so that they can be
+viewed by anyone. CTS reports can be shared as widely as manufacturers
+prefer.</p>
+<h3 id="how-is-the-cts-licensed">How is the CTS licensed?</h3>
+<p>The CTS is licensed under the same Apache Software License 2.0 that the
+bulk of Android uses.</p>
+<h3 id="does-the-cts-accept-contributions">Does the CTS accept contributions?</h3>
+<p>Yes please! The Android Open-Source Project accepts contributions to
+improve the CTS in the same way as for any other component. In fact,
+improving the coverage and quality of the CTS test cases is one of the best
+ways to help out Android.</p>
+<h3 id="can-anyone-use-the-cts-on-existing-devices">Can anyone use the CTS on existing devices?</h3>
+<p>The Compatibility Definition Document requires that compatible devices
+implement the 'adb' debugging utility. This means that any compatible device
+-- including ones available at retail -- must be able to run the CTS
+tests.</p>
+
+
+<h2>Security</h2>
+<h3 id="secure">Is Android secure?</h3>
+
+<p>The security and privacy of our users' data is of primary importance to the
+Android Open Source Project. We are dedicated to building and maintaining one
+of the most secure mobile platforms available while still fulfilling our goal
+of opening the mobile device space to innovation and competition.</p>
+
+<p> A comprehensive overview of the <a
+href="http://source.android.com/tech/security/index.html">Android
+security model and Android security processes</a> is provided in the Android
+Open Source Project Website.</p>
+
+<p>Application developers play an important part in the security of Android.
+The Android Platform provides developers with a rich <a
+href="http://code.google.com/android/devel/security.html">security model</a>
+that to request the capabilities, or access, needed by their
+application and to define new capabilities that other applications can request.
+The Android user can choose to grant or deny an application's request for
+certain capabilities on the handset.</p>
+
+<p>We have made great efforts to secure the Android platform, but it is
+inevitable that security bugs will be found in any system of this complexity.
+Therefore, the Android team works hard to find new bugs internally and responds
+quickly and professionally to vulnerability reports from external researchers.
+</p>
+
+
+<h3 id="issue">I think I found a security flaw. How do I
+report it?</h3>
+
+<p>You can reach the Android security team at <a
+href="mailto:security@android.com">security@android.com</a>. If you like, you
+can protect your message using our <a
+href="http://code.google.com/android/security_at_android_dot_com.txt">PGP
+key</a>.</p>
+
+<p>We appreciate researchers practicing responsible disclosure by emailing us
+with a detailed summary of the issue and keeping the issue confidential while
+users are at risk. In return, we will make sure to keep the researcher informed
+of our progress in issuing a fix. </p>
+
+
+<h3 id="informed">How can I stay informed about Android security?</h3>
+
+<p>For general discussion of Android platform security, or how to use
+security features in your Android application, please subscribe to <a
+href="http://groups.google.com/group/android-security-discuss">android-security-discuss</a>.
+</p>
+
+
+<h3 id="use">How do I securely use my Android phone?</h3>
+
+<p>Android was designed so that you can safely use your phone without making
+any changes to the device or installing any special software. Android applications
+run in an Application Sandbox that limits access to sensitive information or data
+with the users permission.</p>
+
+<p>To fully benefit from the security protections in Android, it is important that
+users only download and install software from known sources.</p>
+
+<p>As an open platform, Android allows users to visit any website and load
+software from any developer onto a device. As with a home PC, the user must be
+aware of who is providing the software they are downloading and must decide
+whether they want to grant the application the capabilities it requests.
+This decision can be informed by the user's judgment of the software
+developer's trustworthiness, and where the software came from.</p>
+
+
+<h3 id="malware">I think I found malicious software being
+distributed for Android. How can I help?</h3>
+
+<p>Like any other platform, it will be possible for unethical developers
+to create malicious software, known as <a
+href="http://en.wikipedia.org/wiki/Malware">malware</a>, for Android. If you
+think somebody is trying to spread malware, please let us know at <a
+href="mailto:security@android.com">security@android.com</a>. Please include as
+much detail about the application as possible, with the location it is
+being distributed from and why you suspect it of being malicious software.</p>
+
+<p>The term <i>malicious software</i> is subjective, and we cannot make an
+exhaustive definition. Some examples of what the Android Security Team believes
+to be malicious software is any application that:
+<ul>
+ <li>uses a bug or security vulnerability to gain permissions that have not
+ been granted by the user</li>
+ <li>shows the user unsolicited messages (especially messages urging the
+ user to buy something);</li>
+ <li>resists (or attempts to resist) the user's effort to uninstall it;</li>
+ <li>attempts to automatically spread itself to other devices;</li>
+ <li>hides its files and/or processes;</li>
+ <li>discloses the user's private information to a third party, without the
+ user's knowledge and consent;</li>
+ <li>destroys the user's data (or the device itself) without the user's
+ knowledge and consent;</li>
+ <li>impersonates the user (such as by sending email or buying things from a
+ web store) without the user's knowledge and consent; or</li>
+ <li>otherwise degrades the user's experience with the device.</li>
+</ul>
+</p>
+
+<h3 id="fixes">How do Android-powered devices receive security
+fixes?</h3>
+
+<p>The manufacturer of each device is responsible for distributing software
+upgrades for it, including security fixes. Many devices will update themselves
+automatically with software downloaded "over the air", while some devices
+require the user to upgrade them manually.</p>
+
+<p>Google provides software updates for a number of Android devices, including
+the <a href="http://www.google.com/nexus">Nexus</a>
+series of devices, using an "over the air" (OTA) update. These updates may include
+security fixes as well as new features.</p>
+
+<h3 id="directfix">Can I get a fix directly from the
+Android Platform Project?</h3>
+
+<p>Android is a mobile platform that is released as open source and
+available for free use by anybody. This means that there are many
+Android-based products available to consumers, and most of them are created
+without the knowledge or participation of the Android Open Source Project. Like
+the maintainers of other open source projects, we cannot build and release
+patches for the entire ecosystem of products using Android. Instead, we will
+work diligently to find and fix flaws as quickly as possible and to distribute
+those fixes to the manufacturers of the products through the open source project.</p>
+
+<p>If you are making an Android-powered device and would like to know how you can
+properly support your customers by keeping abreast of software updates, please
+contact us at <a
+href="mailto:info@openhandsetalliance.com">info@openhandsetalliance.com</a>.</p>
+
diff --git a/src/source/flashing.jd b/src/source/flashing.jd
new file mode 100644
index 0000000..fa99cf5
--- /dev/null
+++ b/src/source/flashing.jd
@@ -0,0 +1,29 @@
+page.title=Flashing
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>To flash a device, you will need to use <code>fastboot</code>. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with</p>
+<pre><code>$ adb reboot bootloader
+</code></pre>
+<p>Once the device is in fastboot mode, run </p>
+<pre><code>$ fastboot flashall -w
+</code></pre>
+<p>The <code>-w</code> option wipes the <code>/data</code> partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.</p>
+<h1 id="emulating">Emulating</h1>
+<p>To run the emulator, type</p>
+<pre><code>$ emulator
+</code></pre>
\ No newline at end of file
diff --git a/src/source/flashing.md b/src/source/flashing.md
deleted file mode 100644
index 80f4979..0000000
--- a/src/source/flashing.md
+++ /dev/null
@@ -1,35 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Flashing #
-
-To flash a device, you will need to use `fastboot`. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with
-
- $ adb reboot bootloader
-
-Once the device is in fastboot mode, run
-
- $ fastboot flashall -w
-
-The `-w` option wipes the `/data` partition on the device; this is useful for your first time flashing a particular device, but is otherwise unnecessary.
-
-# Emulating #
-
-To run the emulator, type
-
- $ emulator
-
-
diff --git a/src/source/getting-started.jd b/src/source/getting-started.jd
new file mode 100644
index 0000000..bf87be8
--- /dev/null
+++ b/src/source/getting-started.jd
@@ -0,0 +1,22 @@
+page.title=Getting Started
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>Thanks for your interest in Android! To begin working with the platform, whether
+you're creating a custom version of Android for existing devices or if you are
+building a hardware device from scratch, you'll need to set up your machine to download and build the
+source.
\ No newline at end of file
diff --git a/src/source/git-repo.html b/src/source/git-repo.html
index 83b2ee7..e85ebc2 100644
--- a/src/source/git-repo.html
+++ b/src/source/git-repo.html
@@ -1,7 +1,6 @@
-<!DOCTYPE html>
<html>
<head>
-<meta http-equiv="refresh" content="0;url=/source/version-control.html" />
+<meta http-equiv="refresh" content="0;url=/source/developing.html" />
</head>
<body>
</body>
diff --git a/src/source/git-resources.jd b/src/source/git-resources.jd
new file mode 100644
index 0000000..bced045
--- /dev/null
+++ b/src/source/git-resources.jd
@@ -0,0 +1,33 @@
+page.title=Git Resources
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>For further information on Git, check out these excellent off-site resources:</p>
+<ul>
+<li>
+<p>The <a href="http://book.git-scm.com">Git Community Book</a> (maintained by Scott Chacon) </p>
+</li>
+<li>
+<p><a href="http://git.or.cz/gitwiki/FrontPage">Git Wiki</a></p>
+</li>
+<li>
+<p><a href="http://www.kernel.org/pub/software/scm/git/docs">Git Manual Page</a> </p>
+</li>
+<li>
+<p><a href="http://www.gitcasts.com">GitCasts</a> (Git how-to videos)</p>
+</li>
+</ul>
\ No newline at end of file
diff --git a/src/source/git-resources.md b/src/source/git-resources.md
deleted file mode 100644
index fc33249..0000000
--- a/src/source/git-resources.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Git Resources #
-
-For further information on Git, check out these excellent off-site resources:
-
-- The [Git Community Book](http://book.git-scm.com) (maintained by Scott Chacon)
-
-- [Git Wiki](http://git.or.cz/gitwiki/FrontPage)
-
-- [Git Manual Page](http://www.kernel.org/pub/software/scm/git/docs)
-
-- [GitCasts](http://www.gitcasts.com) (Git how-to videos)
-
-
diff --git a/src/source/index.jd b/src/source/index.jd
new file mode 100644
index 0000000..e39c611
--- /dev/null
+++ b/src/source/index.jd
@@ -0,0 +1,65 @@
+page.title=The Android Source Code
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>
+Android is an open-source software stack created for a wide array of devices
+with different form factors. The primary purpose of Android is to create an
+open software platform available for carriers, OEMs, and developers to make
+their innovative ideas a reality and to create a successful,
+real-world product that improves the mobile experience for end users.
+
+We also wanted to make sure that there was
+no central point of failure, where one industry player could restrict or
+control the innovations of any other. The result is a full, production-quality
+consumer product whose source is open for customization and porting.
+</p>
+
+
+
+
+<h2 id="governance-philosophy">Governance Philosophy</h2
+<p>Android was originated by a group of companies known as the Open
+Handset Alliance, led by Google. Today, many companies -- both original members
+of the OHA and others -- have invested heavily in Android, typically in the form
+of allocating significant engineering resources to improve Android and bring Android devices to market.
+</p>
+<p>The companies that have invested in Android have done so on its merits,
+because we believe that an open platform is necessary. Android is
+intentionally and explicitly an open-source -- as opposed to free software --
+effort: a group of organizations with shared needs has pooled
+resources to collaborate on a single implementation of a shared product.
+The Android philosophy is pragmatic, first and foremost. The objective is
+a shared product that each contributor can tailor and customize.</p>
+
+<p>Uncontrolled customization can, of course, lead to incompatible
+implementations. To prevent this, the Android Open Source Project also maintains the <a href="{@docRoot}compatibility/index.html">Android
+Compatibility Program</a>, which spells out what it means to be "Android
+compatible", and what is required of device builders to achieve that status.
+Anyone can (and will!) use the Android source code for any purpose, and we
+welcome all such uses. However, in order to take part in the shared
+ecosystem of applications that we are building around Android, device builders
+must participate in the Android Compatibility Program.</p>
+
+<p>The Android Open Source Project is led by Google, who
+maintains and further develops Android.
+Although Android consists of multiple subprojects, this is strictly a
+project management technique. We view and manage Android as a single,
+holistic software product, not a "distribution", specification, or collection
+of replaceable parts. Our intent is that device builders port
+Android to a device; they don't implement a specification or curate a
+distribution.</p>
\ No newline at end of file
diff --git a/src/source/index.md b/src/source/index.md
deleted file mode 100644
index 5fdcd58..0000000
--- a/src/source/index.md
+++ /dev/null
@@ -1,53 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Get Involved #
-
-Thanks for your interest in Android! Here are some ways you can get involved
-and help us improve Android. For background on the Android project and our
-goals, check out the [Project Philosophy page](/about/philosophy.html).
-
-## Report Bugs ##
-
-One of the easiest and most effective ways you can help improve Android is
-to file bugs. For more information, visit the [Reporting Bugs](report-bugs.html) page.
-
-Please note that we can't guarantee that any particular bug will be fixed in
-any particular release. To see what happens to your bug once you report it,
-read [Life of a Bug](life-of-a-bug.html).
-
-## Develop Apps ##
-
-We created Android so that all developers can distribute their applications
-to users on an open platform. One of the best ways you can help Android is to
-write cool apps that users love!
-
-To get started, visit [developer.android.com](https://developer.android.com). This site
-provides the information and tools you need to write applications for
-compatible Android devices, using the SDK.
-
-## Contribute to the Code ##
-
-Code is King. We'd love to review any changes you submit, so please check
-out the source, pick a bug or feature, and get coding. Note that the smaller
-and more targetted your patch submissions, the easier it will be for us to
-review them.
-
-You can get started with Android by learning about the [Life of a Patch](life-of-a-patch.html),
-and by learning about `git`, `repo`, and other tools using the links to the left.
-You can also view the activity on all contributions on our
-[Gerrit server](https://android-review.googlesource.com/).
-If you need help along the way, you can join our [discussion groups](/community/index.html).
diff --git a/src/source/initializing.jd b/src/source/initializing.jd
new file mode 100644
index 0000000..029f308
--- /dev/null
+++ b/src/source/initializing.jd
@@ -0,0 +1,262 @@
+page.title=Initializing a Build Environment
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Before you begin, ensure that your system meets the <a href="{@docRoot}source/building.html">minimum requirements</a>.
+
+<h2 id="setup-linux">Setting up a Linux Build Environment</h2>
+
+<h3 id="installing-the-jdk">Installing the JDK</h3>
+<p>The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add the appropriate repository and indicate to the system which JDK should be used.</p>
+<p>Java 6: for Gingerbread and newer</p>
+<pre><code>$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
+$ sudo apt-get update
+$ sudo apt-get install sun-java6-jdk
+</code></pre>
+<p>Java 5: for Froyo and older</p>
+<pre><code>$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy main multiverse"
+$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy-updates main multiverse"
+$ sudo apt-get update
+$ sudo apt-get install sun-java5-jdk
+</code></pre>
+<p><em>Note: The <code>lunch</code> command in the build step will ensure that the Sun JDK is
+used instead of any previously installed JDK.</em></p>
+<h3 id="installing-required-packages-ubuntu-1004-1110">Installing required packages (Ubuntu 10.04 -- 11.10)</h3>
+<p>You will need a 64-bit version of Ubuntu. Ubuntu 10.04 is recommended.
+Building using a newer version of Ubuntu is currently only experimentally
+supported and is not guaranteed to work on branches other than master.</p>
+<pre><code>$ sudo apt-get install git-core gnupg flex bison gperf build-essential \
+ zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \
+ x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \
+ libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \
+ libxml2-utils xsltproc
+</code></pre>
+<p>On Ubuntu 10.10:</p>
+<pre><code>$ sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so
+</code></pre>
+<p>On Ubuntu 11.10:</p>
+<pre><code>$ sudo apt-get install libx11-dev:i386
+</code></pre>
+<h3 id="installing-required-packages-ubuntu-1204">Installing required packages (Ubuntu 12.04)</h3>
+<p>Building on Ubuntu 12.04 is currently only experimentally supported and is not
+guaranteed to work on branches other than master.</p>
+<pre><code>$ sudo apt-get install git gnupg flex bison gperf build-essential \
+ zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
+ libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
+ libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos \
+ python-markdown libxml2-utils xsltproc zlib1g-dev:i386
+$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
+</code></pre>
+<h3 id="configuring-usb-access">Configuring USB Access</h3>
+<p>Under GNU/linux systems (and specifically under Ubuntu systems),
+regular users can't directly access USB devices by default. The
+system needs to be configured to allow such access.</p>
+<p>The recommended approach is to create a file
+<code>/etc/udev/rules.d/51-android.rules</code> (as the root user) and to copy
+the following lines in it. <code><username></code> must be replaced by the
+actual username of the user who is authorized to access the phones
+over USB.</p>
+<pre><code># adb protocol on passion (Nexus One)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0600", OWNER="<username>"
+# fastboot protocol on passion (Nexus One)
+SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0600", OWNER="<username>"
+# adb protocol on crespo/crespo4g (Nexus S)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"
+# fastboot protocol on crespo/crespo4g (Nexus S)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"
+# adb protocol on stingray/wingray (Xoom)
+SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="70a9", MODE="0600", OWNER="<username>"
+# fastboot protocol on stingray/wingray (Xoom)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="708c", MODE="0600", OWNER="<username>"
+# adb protocol on maguro/toro (Galaxy Nexus)
+SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0600", OWNER="<username>"
+# fastboot protocol on maguro/toro (Galaxy Nexus)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0600", OWNER="<username>"
+# adb protocol on panda (PandaBoard)
+SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d101", MODE="0600", OWNER="<username>"
+# fastboot protocol on panda (PandaBoard)
+SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d022", MODE="0600", OWNER="<username>"
+# usbboot protocol on panda (PandaBoard)
+SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d00f", MODE="0600", OWNER="<username>"
+# usbboot protocol on panda (PandaBoard ES)
+SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d010", MODE="0600", OWNER="<username>"
+# adb protocol on grouper/tilapia (Nexus 7)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0600", OWNER="<username>"
+# fastboot protocol on grouper/tilapia (Nexus 7)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", MODE="0600", OWNER="<username>"
+# adb protocol on mako/manta (Nexus 4, Nexus 10)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0600", OWNER="<username>"
+# fastboot protocol on mako/manta (Nexus 4, Nexus 10)
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="0600", OWNER="<username>"
+</code></pre>
+<p>Those new rules take effect the next time a device is plugged in.
+It might therefore be necessary to unplug the device and plug it
+back into the computer.</p>
+<p>This is known to work on both Ubuntu Hardy Heron (8.04.x LTS) and
+Lucid Lynx (10.04.x LTS). Other versions of Ubuntu or other
+variants of GNU/linux might require different configurations.</p>
+<p><a name="ccache"></a></p>
+<h3 id="setting-up-ccache">Setting up ccache</h3>
+<p>You can optionally tell the build to use the ccache compilation tool.
+Ccache acts as a compiler cache that can be used to speed-up rebuilds.
+This works very well if you do "make clean" often, or if you frequently
+switch between different build products.</p>
+<p>Put the following in your .bashrc or equivalent.</p>
+<pre><code>export USE_CCACHE=1
+</code></pre>
+<p>By default the cache will be stored in ~/.ccache.
+If your home directory is on NFS or some other non-local filesystem,
+you will want to specify the directory in your .bashrc as well.</p>
+<pre><code>export CCACHE_DIR=<path-to-your-cache-directory>
+</code></pre>
+<p>The suggested cache size is 50-100GB.
+You will need to run the following command once you have downloaded
+the source code:</p>
+<pre><code>prebuilts/misc/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>When building Ice Cream Sandwich (4.0.x) or older, ccache is in
+a different location:</p>
+<pre><code>prebuilt/linux-x86/ccache/ccache -M 50G
+</code></pre>
+<p>This setting is stored in the CCACHE_DIR and is persistent.</p>
+<h3 id="using-a-separate-output-directory">Using a separate output directory</h3>
+<p>By default, the output of each build is stored in the out/
+subdirectory of the matching source tree.</p>
+<p>On some machines with multiple storage devices, builds are
+faster when storing the source files and the output on
+separate volumes. For additional performance, the output
+can be stored on a filesystem optimized for speed instead
+of crash robustness, since all files can be re-generated
+in case of filesystem corruption.</p>
+<p>To set this up, export the <code>OUT_DIR_COMMON_BASE</code> variable
+to point to the location where your output directories
+will be stored.</p>
+<pre><code>export OUT_DIR_COMMON_BASE=<path-to-your-out-directory>
+</code></pre>
+<p>The output directory for each separate source tree will be
+named after the directory holding the source tree.</p>
+<p>For instance, if you have source trees as <code>/source/master1</code>
+and <code>/source/master2</code> and <code>OUT_DIR_COMMON_BASE</code> is set to
+<code>/output</code>, the output directories will be <code>/output/master1</code>
+and <code>/output/master2</code>.</p>
+<p>It's important in that case to not have multiple source
+trees stored in directories that have the same name,
+as those would end up sharing an output directory, with
+unpredictable results.</p>
+<p>This is only supported on Jelly Bean (4.1) and newer,
+including the master branch.</p>
+<h2 id="setting-up-a-mac-os-x-build-environment">Setting up a Mac OS X build environment</h2>
+<p>In a default installation, OS X runs on a case-preserving but case-insensitive
+filesystem. This type of filesystem is not supported by git and will cause some
+git commands (such as "git status") to behave abnormally. Because of this, we
+recommend that you always work with the AOSP source files on a case-sensitive
+filesystem. This can be done fairly easily using a disk image, discussed below.</p>
+<p>Once the proper filesystem is available, building the master branch in a modern
+OS X environment is very straightforward. Earlier branches, including ICS,
+require some additional tools and SDKs.</p>
+<h3 id="creating-a-case-sensitive-disk-image">Creating a case-sensitive disk image</h3>
+<p>You can create a case-sensitive filesystem within your existing OS X environment
+using a disk image. To create the image, launch Disk
+Utility and select "New Image". A size of 25GB is the minimum to
+complete the build, larger numbers are more future-proof. Using sparse images
+saves space while allowing to grow later as the need arises. Be sure to select
+"case sensitive, journaled" as the volume format.</p>
+<p>You can also create it from a shell with the following command:</p>
+<pre><code># hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg
+</code></pre>
+<p>This will create a .dmg (or possibly a .dmg.sparsefile) file which, once mounted, acts as a drive with the required formatting for Android development. For a disk image named "android.dmg" stored in your home directory, you can add the following to your <code>~/.bash_profile</code> to mount the image when you execute "mountAndroid":</p>
+<pre><code># mount the android file image
+function mountAndroid { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
+</code></pre>
+<p>Once mounted, you'll do all your work in the "android" volume. You can eject it (unmount it) just like you would with an external drive.</p>
+<h3 id="master-branch">Master branch</h3>
+<p>To build the latest source in a Mac OS environment, you will need an Intel/x86
+machine running MacOS 10.6 (Snow Leopard) or MacOS 10.7 (Lion), along with Xcode
+4.2 (Apple's Developer Tools). Although Lion does not come with a JDK, it should
+install automatically when you attempt to build the source.</p>
+<p>The remaining sections for Mac OS X only apply to those who wish to build
+earlier branches.</p>
+<h3 id="branch-40x-and-all-earlier-branches">Branch 4.0.x and all earlier branches</h3>
+<p>To build android-4.0.x and earlier branches in a Mac OS environment, you need an
+Intel/x86 machine running MacOS 10.5 (Leopard) or MacOS 10.6 (Snow Leopard). You
+will need the MacOS 10.5 SDK.</p>
+<h3 id="installing-required-packages">Installing required packages</h3>
+<ul>
+<li>
+<p>Install Xcode from <a href="http://developer.apple.com/">the Apple developer site</a>.
+We recommend version 3.1.4 or newer, i.e. gcc 4.2.
+Version 4.x could cause difficulties.
+If you are not already registered as an Apple developer, you will have to
+create an Apple ID in order to download.</p>
+</li>
+<li>
+<p>Install MacPorts from <a href="http://www.macports.org/install.php">macports.org</a>.</p>
+<p><em>Note: Make sure that <code>/opt/local/bin</code> appears in your path BEFORE <code>/usr/bin</code>. If not, add</em> </p>
+<pre><code>export PATH=/opt/local/bin:$PATH
+</code></pre>
+<p><em>to your <code>~/.bash_profile</code>.</em></p>
+</li>
+<li>
+<p>Get make, git, and GPG packages from MacPorts: </p>
+<pre><code>$ POSIXLY_CORRECT=1 sudo port install gmake libsdl git-core gnupg
+</code></pre>
+<p>If using Mac OS 10.4, also install bison:</p>
+<pre><code>$ POSIXLY_CORRECT=1 sudo port install bison
+</code></pre>
+</li>
+</ul>
+<h3 id="reverting-from-make-382">Reverting from make 3.82</h3>
+<p>For versions of Android before ICS, there is a bug in gmake 3.82 that prevents android from building. You can install version 3.81 using MacPorts by taking the following steps:</p>
+<ul>
+<li>
+<p>Edit <code>/opt/local/etc/macports/sources.conf</code> and add a line that says</p>
+<pre><code>file:///Users/Shared/dports
+</code></pre>
+<p>above the rsync line. Then create this directory: </p>
+<pre><code>$ mkdir /Users/Shared/dports
+</code></pre>
+</li>
+<li>
+<p>In the new <code>dports</code> directory, run </p>
+<pre><code>$ svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
+</code></pre>
+</li>
+<li>
+<p>Create a port index for your new local repository: </p>
+<pre><code>$ portindex /Users/Shared/dports
+</code></pre>
+</li>
+<li>
+<p>Finally, install the old version of gmake with </p>
+<pre><code>$ sudo port install gmake @3.81
+</code></pre>
+</li>
+</ul>
+<h3 id="setting-a-file-descriptor-limit">Setting a file descriptor limit</h3>
+<p>On MacOS the default limit on the number of simultaneous file descriptors open is too low and a highly parallel build process may exceed this limit. </p>
+<p>To increase the cap, add the following lines to your <code>~/.bash_profile</code>: </p>
+<pre><code># set the number of open files to be 1024
+ulimit -S -n 1024
+</code></pre>
diff --git a/src/source/initializing.md b/src/source/initializing.md
deleted file mode 100644
index ac50857..0000000
--- a/src/source/initializing.md
+++ /dev/null
@@ -1,340 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Initializing a Build Environment #
-
-The "Getting Started" section describes how to set up your local work environment, how to use Repo to get the Android files, and how to build the files on your machine. To build the Android source files, you will need to use Linux or Mac OS. Building under Windows is not currently supported.
-
-*Note: The source download is approximately 8.5GB in size.
-You will need over 30GB free to complete a single build, and
-up to 100GB (or more) for a full set of builds.*
-
-For an overview of the entire code-review and code-update process, see [Life of a Patch](life-of-a-patch.html).
-
-# Choosing a Branch #
-
-Some of the requirements for your build environment are determined by which
-version of the source code you plan to compile. See
-[Build Numbers](build-numbers.html) for a full listing of branches you may
-choose from. You may also choose to download and build the latest source code
-(called "master"), in which case you will simply omit the branch specification
-when you initialize the repository.
-
-Once you have selected a branch, follow the appropriate instructions below to
-set up your build environment.
-
-# Setting up a Linux build environment #
-
-These instructions apply to all branches, including master.
-
-The Android build is routinely tested in house on recent versions of
-Ubuntu LTS (10.04), but most distributions should have the required
-build tools available. Reports of successes or failures on other
-distributions are welcome.
-
-For Gingerbread (2.3.x) and newer versions, including the master
-branch, a 64-bit environment is required. Older versions can be
-compiled on 32-bit systems.
-
-*Note: It is also possible to build Android in a virtual machine.
-If you are running Linux in a virtual machine, you will need at
-least 16GB of RAM/swap and 30GB or more of disk space in order to
-build the Android tree.*
-
-Detailed instructions for Ubuntu and MacOS follow. In general you will need:
-
- - Python 2.5 -- 2.7, which you can download from [python.org](http://www.python.org/download/).
-
- - GNU Make 3.81 -- 3.82, which you can download from [gnu.org](http://ftp.gnu.org/gnu/make/),
-
- - JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from [java.sun.com](http://java.sun.com/javase/downloads/).
-
- - Git 1.7 or newer. You can find it at [git-scm.com](http://git-scm.com/download).
-
-## Installing the JDK ##
-
-The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add the appropriate repository and indicate to the system which JDK should be used.
-
-Java 6: for Gingerbread and newer
-
- $ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
- $ sudo apt-get update
- $ sudo apt-get install sun-java6-jdk
-
-Java 5: for Froyo and older
-
- $ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy main multiverse"
- $ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy-updates main multiverse"
- $ sudo apt-get update
- $ sudo apt-get install sun-java5-jdk
-
-*Note: The `lunch` command in the build step will ensure that the Sun JDK is
-used instead of any previously installed JDK.*
-
-## Installing required packages (Ubuntu 10.04 -- 11.10) ##
-
-You will need a 64-bit version of Ubuntu. Ubuntu 10.04 is recommended.
-Building using a newer version of Ubuntu is currently only experimentally
-supported and is not guaranteed to work on branches other than master.
-
- $ sudo apt-get install git-core gnupg flex bison gperf build-essential \
- zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \
- x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \
- libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \
- libxml2-utils xsltproc
-
-On Ubuntu 10.10:
-
- $ sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so
-
-On Ubuntu 11.10:
-
- $ sudo apt-get install libx11-dev:i386
-
-## Installing required packages (Ubuntu 12.04) ##
-
-Building on Ubuntu 12.04 is currently only experimentally supported and is not
-guaranteed to work on branches other than master.
-
- $ sudo apt-get install git-core gnupg flex bison gperf build-essential \
- zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
- libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
- libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos \
- python-markdown libxml2-utils xsltproc zlib1g-dev:i386
- $ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
-
-## Configuring USB Access ##
-
-Under GNU/linux systems (and specifically under Ubuntu systems),
-regular users can't directly access USB devices by default. The
-system needs to be configured to allow such access.
-
-The recommended approach is to create a file
-`/etc/udev/rules.d/51-android.rules` (as the root user) and to copy
-the following lines in it. `<username>` must be replaced by the
-actual username of the user who is authorized to access the phones
-over USB.
-
- # adb protocol on passion (Nexus One)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0600", OWNER="<username>"
- # fastboot protocol on passion (Nexus One)
- SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0600", OWNER="<username>"
- # adb protocol on crespo/crespo4g (Nexus S)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"
- # fastboot protocol on crespo/crespo4g (Nexus S)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"
- # adb protocol on stingray/wingray (Xoom)
- SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="70a9", MODE="0600", OWNER="<username>"
- # fastboot protocol on stingray/wingray (Xoom)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="708c", MODE="0600", OWNER="<username>"
- # adb protocol on maguro/toro (Galaxy Nexus)
- SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0600", OWNER="<username>"
- # fastboot protocol on maguro/toro (Galaxy Nexus)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0600", OWNER="<username>"
- # adb protocol on panda (PandaBoard)
- SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d101", MODE="0600", OWNER="<username>"
- # fastboot protocol on panda (PandaBoard)
- SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d022", MODE="0600", OWNER="<username>"
- # usbboot protocol on panda (PandaBoard)
- SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d00f", MODE="0600", OWNER="<username>"
- # usbboot protocol on panda (PandaBoard ES)
- SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d010", MODE="0600", OWNER="<username>"
- # adb protocol on grouper (Nexus 7)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0600", OWNER="<username>"
- # fastboot protocol on grouper (Nexus 7)
- SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", MODE="0600", OWNER="<username>"
-
-Those new rules take effect the next time a device is plugged in.
-It might therefore be necessary to unplug the device and plug it
-back into the computer.
-
-This is known to work on both Ubuntu Hardy Heron (8.04.x LTS) and
-Lucid Lynx (10.04.x LTS). Other versions of Ubuntu or other
-variants of GNU/linux might require different configurations.
-
-<a name="ccache"></a>
-## Setting up ccache ##
-
-You can optionally tell the build to use the ccache compilation tool.
-Ccache acts as a compiler cache that can be used to speed-up rebuilds.
-This works very well if you do "make clean" often, or if you frequently
-switch between different build products.
-
-Put the following in your .bashrc or equivalent.
-
- export USE_CCACHE=1
-
-By default the cache will be stored in ~/.ccache.
-If your home directory is on NFS or some other non-local filesystem,
-you will want to specify the directory in your .bashrc as well.
-
- export CCACHE_DIR=<path-to-your-cache-directory>
-
-The suggested cache size is 50-100GB.
-You will need to run the following command once you have downloaded
-the source code:
-
- prebuilts/misc/linux-x86/ccache/ccache -M 50G
-
-When building Ice Cream Sandwich (4.0.x) or older, ccache is in
-a different location:
-
- prebuilt/linux-x86/ccache/ccache -M 50G
-
-This setting is stored in the CCACHE_DIR and is persistent.
-
-## Using a separate output directory ##
-
-By default, the output of each build is stored in the out/
-subdirectory of the matching source tree.
-
-On some machines with multiple storage devices, builds are
-faster when storing the source files and the output on
-separate volumes. For additional performance, the output
-can be stored on a filesystem optimized for speed instead
-of crash robustness, since all files can be re-generated
-in case of filesystem corruption.
-
-To set this up, export the `OUT_DIR_COMMON_BASE` variable
-to point to the location where your output directories
-will be stored.
-
- export OUT_DIR_COMMON_BASE=<path-to-your-out-directory>
-
-The output directory for each separate source tree will be
-named after the directory holding the source tree.
-
-For instance, if you have source trees as `/source/master1`
-and `/source/master2` and `OUT_DIR_COMMON_BASE` is set to
-`/output`, the output directories will be `/output/master1`
-and `/output/master2`.
-
-It's important in that case to not have multiple source
-trees stored in directories that have the same name,
-as those would end up sharing an output directory, with
-unpredictable results.
-
-This is only supported on Jelly Bean (4.1) and newer,
-including the master branch.
-
-# Setting up a Mac OS X build environment #
-
-In a default installation, OS X runs on a case-preserving but case-insensitive
-filesystem. This type of filesystem is not supported by git and will cause some
-git commands (such as "git status") to behave abnormally. Because of this, we
-recommend that you always work with the AOSP source files on a case-sensitive
-filesystem. This can be done fairly easily using a disk image, discussed below.
-
-Once the proper filesystem is available, building the master branch in a modern
-OS X environment is very straightforward. Earlier branches, including ICS,
-require some additional tools and SDKs.
-
-### Creating a case-sensitive disk image ###
-
-You can create a case-sensitive filesystem within your existing OS X environment
-using a disk image. To create the image, launch Disk
-Utility and select "New Image". A size of 25GB is the minimum to
-complete the build, larger numbers are more future-proof. Using sparse images
-saves space while allowing to grow later as the need arises. Be sure to select
-"case sensitive, journaled" as the volume format.
-
-You can also create it from a shell with the following command:
-
- # hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg
-
-This will create a .dmg (or possibly a .dmg.sparsefile) file which, once mounted, acts as a drive with the required formatting for Android development. For a disk image named "android.dmg" stored in your home directory, you can add the following to your `~/.bash_profile` to mount the image when you execute "mountAndroid":
-
- # mount the android file image
- function mountAndroid { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
-
-Once mounted, you'll do all your work in the "android" volume. You can eject it (unmount it) just like you would with an external drive.
-
-## Master branch ##
-
-To build the latest source in a Mac OS environment, you will need an Intel/x86
-machine running MacOS 10.6 (Snow Leopard) or MacOS 10.7 (Lion), along with Xcode
-4.2 (Apple's Developer Tools). Although Lion does not come with a JDK, it should
-install automatically when you attempt to build the source.
-
-The remaining sections for Mac OS X only apply to those who wish to build
-earlier branches.
-
-## Branch 4.0.x and all earlier branches ##
-
-To build android-4.0.x and earlier branches in a Mac OS environment, you need an
-Intel/x86 machine running MacOS 10.5 (Leopard) or MacOS 10.6 (Snow Leopard). You
-will need the MacOS 10.5 SDK.
-
-### Installing required packages ###
-
-- Install Xcode from [the Apple developer site](http://developer.apple.com/).
-We recommend version 3.1.4 or newer, i.e. gcc 4.2.
-Version 4.x could cause difficulties.
-If you are not already registered as an Apple developer, you will have to
-create an Apple ID in order to download.
-
-- Install MacPorts from [macports.org](http://www.macports.org/install.php).
-
- *Note: Make sure that `/opt/local/bin` appears in your path BEFORE `/usr/bin`. If not, add*
-
- export PATH=/opt/local/bin:$PATH
-
- *to your `~/.bash_profile`.*
-
-- Get make, git, and GPG packages from MacPorts:
-
- $ POSIXLY_CORRECT=1 sudo port install gmake libsdl git-core gnupg
-
- If using Mac OS 10.4, also install bison:
-
- $ POSIXLY_CORRECT=1 sudo port install bison
-
-### Reverting from make 3.82 ###
-
-For versions of Android before ICS, there is a bug in gmake 3.82 that prevents android from building. You can install version 3.81 using MacPorts by taking the following steps:
-
-- Edit `/opt/local/etc/macports/sources.conf` and add a line that says
-
- file:///Users/Shared/dports
-
- above the rsync line. Then create this directory:
-
- $ mkdir /Users/Shared/dports
-
-- In the new `dports` directory, run
-
- $ svn co --revision 50980 http://svn.macports.org/repository/macports/trunk/dports/devel/gmake/ devel/gmake/
-
-- Create a port index for your new local repository:
-
- $ portindex /Users/Shared/dports
-
-- Finally, install the old version of gmake with
-
- $ sudo port install gmake @3.81
-
-### Setting a file descriptor limit ###
-
-On MacOS the default limit on the number of simultaneous file descriptors open is too low and a highly parallel build process may exceed this limit.
-
-To increase the cap, add the following lines to your `~/.bash_profile`:
-
- # set the number of open files to be 1024
- ulimit -S -n 1024
-
-# Next: Download the source #
-
-Your build environment is good to go! Proceed to [downloading the source](downloading.html)....
diff --git a/src/source/known-issues.jd b/src/source/known-issues.jd
new file mode 100644
index 0000000..33ceb16
--- /dev/null
+++ b/src/source/known-issues.jd
@@ -0,0 +1,181 @@
+page.title=Known Issues
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>Even with our best care, small problems sometimes slip in. This page keeps
+track of the known issues around using the Android source code.</p>
+<h2 id="missing-cts-native-xml-generator">Missing CTS Native XML Generator</h2>
+<p><strong>Symptom</strong>: On some builds of IceCreamSandwich and later, the following
+warning is printed early during the build:
+<code>/bin/bash: line 0: cd: cts/tools/cts-native-xml-generator/src/res: No
+such file or directory</code></p>
+<p><strong>Cause</strong>: Some makefile references that path, which doesn't exist.</p>
+<p><strong>Fix</strong>: None. This is a harmless warning.</p>
+<h2 id="black-gingerbread-emulator">Black Gingerbread Emulator</h2>
+<p><strong>Symptom</strong>: The emulator built directly from the gingerbread branch
+doesn't start and stays stuck on a black screen.</p>
+<p><strong>Cause</strong>: The gingerbread branch uses version R7 of the emulator,
+which doesn't have all the features necessary to run recent versions
+of gingerbread.</p>
+<p><strong>Fix</strong>: Use version R12 of the emulator, and a newer kernel that matches
+those tools. No need to do a clean build.</p>
+<pre><code>$ repo forall platform/external/qemu -c git checkout aosp/tools_r12
+$ make
+$ emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7
+</code></pre>
+<h2 id="emulator-built-on-macos-107-lion-doesnt-work">Emulator built on MacOS 10.7 Lion doesn't work.</h2>
+<p><strong>Symptom</strong>: The emulator (any version) built on MacOS 10.7 Lion
+and/or on XCode 4.x doesn't start.</p>
+<p><strong>Cause</strong>: Some change in the development environment causes
+the emulator to be compiled in a way that prevents it from working.</p>
+<p><strong>Fix</strong>: Use an emulator binary from the SDK, which is built on
+MacOS 10.6 with XCode 3 and works on MacOS 10.7.</p>
+<h2 id="difficulties-syncing-the-source-code-proxy-issues">Difficulties syncing the source code (proxy issues).</h2>
+<p><strong>Symptom</strong>: <code>repo init</code> or <code>repo sync</code> fail with http errors,
+typically 403 or 500.</p>
+<p><strong>Cause</strong>: There are quite a few possible causes, most often
+related to http proxies, which have difficulties handling the
+large amounts of data getting transfered.</p>
+<p><strong>Fix</strong>: While there's no general solution, using python 2.7
+and explicitly using <code>repo sync -j1</code> have been reported to
+improve the situation for some users.</p>
+<h2 id="difficulties-syncing-the-source-tree-virtualbox-ethernet-issues">Difficulties syncing the source tree (VirtualBox Ethernet issues).</h2>
+<p><strong>Symptom</strong>: When running <code>repo sync</code> in some VirtualBox installations,
+the process hangs or fails with a variety of possible symptoms.
+One such symptom is
+<code>DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble)</code>.</p>
+<p><strong>Cause</strong>: The default network behavior of VirtualBox is to use
+NAT (Network Addrss Translation) to connect the guest system to
+the network. The heavy network activity of repo sync triggers some
+corner cases in the NAT code.</p>
+<p><strong>Fix</strong>: Configure VirtualBox to use bridged network instead of NAT.</p>
+<h2 id="difficulties-syncing-the-source-tree-dns-issues">Difficulties syncing the source tree (DNS issues).</h2>
+<p><strong>Symptom</strong>: When running <code>repo sync</code>, the process fails with
+various errors related to not recognizing the hostname. One such
+error is <code><urlopen error [Errno -2] Name or service not known></code>.</p>
+<p><strong>Cause</strong>: Some DNS systems have a hard time coping with the
+high number of queries involved in syncing the source tree
+(there can be several hundred requests in a worst-case scenario).</p>
+<p><strong>Fix</strong>: Manually resolve the relevant hostnames, and hard-code
+those results locally.</p>
+<p>You can resolve them with the <code>nslookup</code> command, which will give
+you one numerical IP address for each of those (typically in the
+"Address" part of the output).</p>
+<pre><code>$ nslookup googlesource.com
+$ nslookup android.googlesource.com
+</code></pre>
+<p>You can then hard-code them locally by editing <code>/etc/hosts</code>, and
+adding two lines in that file, of the form:</p>
+<pre><code>aaa.bbb.ccc.ddd googlesource.com
+eee.fff.ggg.hhh android.googlesource.com
+</code></pre>
+<p>Note that this will only work as long as the servers' addresses
+don't change, and if they do and you can't connect you'll have
+to resolve those hostnames again and edit <code>etc/hosts</code> accordingly.</p>
+<h2 id="difficulties-syncing-the-source-tree-tcp-issues">Difficulties syncing the source tree (TCP issues).</h2>
+<p><strong>Symptom</strong>: <code>repo sync</code> hangs while syncing, often when it's
+completed 99% of the sync.</p>
+<p><strong>Cause</strong>: Some settings in the TCP/IP stack cause difficulties
+in some network environments, such that <code>repo sync</code> neither completes
+nor fails.</p>
+<p><strong>Fix</strong>: On linux, <code>sysctl -w net.ipv4.tcp_window_scaling=0</code>. On
+MacOS, disable the rfc1323 extension in the network settings.</p>
+<h2 id="make-snod-and-emulator-builds"><code>make snod</code> and emulator builds.</h2>
+<p><strong>Symptom</strong>: When using <code>make snod</code> (make system no dependencies)
+on emulator builds, the resulting build doesn't work.</p>
+<p><strong>Cause</strong>: All emulator builds now run Dex optimization at build
+time by default, which requires to follow all dependencies to
+re-optimize the applications each time the framework changes.</p>
+<p><strong>Fix</strong>: Locally disable Dex optimizations with
+<code>export WITH_DEXPREOPT=false</code>, delete the existing optimized
+versions with <code>make installclean</code> and run a full build to
+re-generate non-optimized versions. After that, <code>make snod</code>
+will work.</p>
+<h2 id="permission-denied-during-builds">"Permission Denied" during builds.</h2>
+<p><strong>Symptom</strong>: All builds fail with "Permission Denied", possibly
+along with anti-virus warnings.</p>
+<p><strong>Cause</strong>: Some anti-virus programs mistakenly recognize some
+source files in the Android source tree as if they contained
+viruses.</p>
+<p><strong>Fix</strong>: After verifying that there are no actual viruses
+involved, disable anti-virus on the Android tree. This has
+the added benefit of reducing build times.</p>
+<h2 id="camera-and-gps-dont-work-on-galaxy-nexus">Camera and GPS don't work on Galaxy Nexus.</h2>
+<p><strong>Symptom</strong>: Camera and GPS don't work on Galaxy Nexus.
+As an example, the Camera application crashes as soon as it's
+launched.</p>
+<p><strong>Cause</strong>: Those hardware peripherals require proprietary
+libraries that aren't available in the Android Open Source
+Project.</p>
+<p><strong>Fix</strong>: None.</p>
+<h2 id="build-errors-related-to-using-the-wrong-compiler">Build errors related to using the wrong compiler.</h2>
+<p><strong>Symptom</strong>: The build fails with various symptoms. One
+such symptom is <code>cc1: error: unrecognized command line option "-m32"</code></p>
+<p><strong>Cause</strong>: The Android build system uses the default compiler
+in the PATH, assuming it's a suitable compiler to generate
+binaries that run on the host. Other situations (e.g. using
+the Android NDK or building the kernel) cause the default
+compiler to not be a host compiler.</p>
+<p><strong>Fix</strong>: Use a "clean" shell, in which no previous
+actions could have swapped the default compiler.</p>
+<h2 id="build-errors-caused-by-non-default-tool-settings">Build errors caused by non-default tool settings.</h2>
+<p><strong>Symptom</strong>: The build fails with various symptoms, possibly
+complinaing about missing files or files that have the
+wrong format. One such symptom is <code>member [...] in archive is not an object</code>.</p>
+<p><strong>Cause</strong>: The Android build system tends to use many host tools
+and to rely on their default behaviors. Some settings change
+those tools' behaviors and make them behave in ways that
+confuse the build system. Variables known to cause such
+issues are <code>CDPATH</code> and <code>GREP_OPTIONS</code>.</p>
+<p><strong>Fix</strong>: Build Android in an environment that has as few
+customizations as possible.</p>
+<h2 id="build-error-with-40x-and-earlier-on-macos-107">Build error with 4.0.x and earlier on MacOS 10.7.</h2>
+<p><strong>Symptom</strong>: Building IceCreamSandwich 4.0.x (and older
+versions) fails on MacOS 10.7 with errors similar to this:
+<code>Undefined symbols for architecture i386: "_SDL_Init"</code></p>
+<p><strong>Cause</strong>: 4.0.x is not compatible with MacOS 10.7.</p>
+<p><strong>Fix</strong>: Either downgrade to MacOS 10.6, or use the master
+branch, which can be built on MacOS 10.7.</p>
+<pre><code>$ repo init -b master
+$ repo sync
+</code></pre>
+<h2 id="build-error-on-macos-with-xcode-43">Build error on MacOS with XCode 4.3.</h2>
+<p><strong>Symptom</strong>: All builds fail when using XCode 4.3.</p>
+<p><strong>Cause</strong>: XCode 4.3 switched the default compiler from
+gcc to llvm, and llvm rejects code that used to be
+accepted by gcc.</p>
+<p><strong>Fix</strong>: Use XCode 4.2.</p>
+<h2 id="build-error-with-40x-and-earlier-on-ubuntu-1110">Build error with 4.0.x and earlier on Ubuntu 11.10.</h2>
+<p><strong>Symptom</strong>: Building IceCreamSandwich 4.0.x (and older
+versions) on Ubuntu 11.10 and newer fails with errors similar to this:
+<code><command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]</code></p>
+<p><strong>Cause</strong>: Ubuntu 11.10 uses a version of gcc where that symbol
+is defined by default, and Android also defines that symbol,
+which causes a conflict.</p>
+<p><strong>Fix</strong>: Either downgrade to Ubuntu 10.04, or use the master
+branch, which can be compiled on Ubuntu 11.10 and newer.</p>
+<pre><code>$ repo init -b master
+$ repo sync
+</code></pre>
diff --git a/src/source/known-issues.md b/src/source/known-issues.md
deleted file mode 100644
index 74579de..0000000
--- a/src/source/known-issues.md
+++ /dev/null
@@ -1,236 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Known Issues #
-
-Even with our best care, small problems sometimes slip in. This page keeps
-track of the known issues around using the Android source code.
-
-## Missing CTS Native XML Generator ##
-
-**Symptom**: On some builds of IceCreamSandwich and later, the following
-warning is printed early during the build:
-`/bin/bash: line 0: cd: cts/tools/cts-native-xml-generator/src/res: No
-such file or directory`
-
-**Cause**: Some makefile references that path, which doesn't exist.
-
-**Fix**: None. This is a harmless warning.
-
-## Black Gingerbread Emulator ##
-
-**Symptom**: The emulator built directly from the gingerbread branch
-doesn't start and stays stuck on a black screen.
-
-**Cause**: The gingerbread branch uses version R7 of the emulator,
-which doesn't have all the features necessary to run recent versions
-of gingerbread.
-
-**Fix**: Use version R12 of the emulator, and a newer kernel that matches
-those tools. No need to do a clean build.
-
- $ repo forall platform/external/qemu -c git checkout aosp/tools_r12
- $ make
- $ emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7
-
-## Emulator built on MacOS 10.7 Lion doesn't work. ##
-
-**Symptom**: The emulator (any version) built on MacOS 10.7 Lion
-and/or on XCode 4.x doesn't start.
-
-**Cause**: Some change in the development environment causes
-the emulator to be compiled in a way that prevents it from working.
-
-**Fix**: Use an emulator binary from the SDK, which is built on
-MacOS 10.6 with XCode 3 and works on MacOS 10.7.
-
-## Difficulties syncing the source code (proxy issues). ##
-
-**Symptom**: `repo init` or `repo sync` fail with http errors,
-typically 403 or 500.
-
-**Cause**: There are quite a few possible causes, most often
-related to http proxies, which have difficulties handling the
-large amounts of data getting transfered.
-
-**Fix**: While there's no general solution, using python 2.7
-and explicitly using `repo sync -j1` have been reported to
-improve the situation for some users.
-
-## Difficulties syncing the source tree (VirtualBox Ethernet issues). ##
-
-**Symptom**: When running `repo sync` in some VirtualBox installations,
-the process hangs or fails with a variety of possible symptoms.
-One such symptom is
-`DownloadError: HTTP 500 (Internal Server Error: Server got itself in trouble)`.
-
-**Cause**: The default network behavior of VirtualBox is to use
-NAT (Network Addrss Translation) to connect the guest system to
-the network. The heavy network activity of repo sync triggers some
-corner cases in the NAT code.
-
-**Fix**: Configure VirtualBox to use bridged network instead of NAT.
-
-## Difficulties syncing the source tree (DNS issues). ##
-
-**Symptom**: When running `repo sync`, the process fails with
-various errors related to not recognizing the hostname. One such
-error is `<urlopen error [Errno -2] Name or service not known>`.
-
-**Cause**: Some DNS systems have a hard time coping with the
-high number of queries involved in syncing the source tree
-(there can be several hundred requests in a worst-case scenario).
-
-**Fix**: Manually resolve the relevant hostnames, and hard-code
-those results locally.
-
-You can resolve them with the `nslookup` command, which will give
-you one numerical IP address for each of those (typically in the
-"Address" part of the output).
-
- $ nslookup googlesource.com
- $ nslookup android.googlesource.com
-
-You can then hard-code them locally by editing `/etc/hosts`, and
-adding two lines in that file, of the form:
-
- aaa.bbb.ccc.ddd googlesource.com
- eee.fff.ggg.hhh android.googlesource.com
-
-Note that this will only work as long as the servers' addresses
-don't change, and if they do and you can't connect you'll have
-to resolve those hostnames again and edit `etc/hosts` accordingly.
-
-## Difficulties syncing the source tree (TCP issues). ##
-
-**Symptom**: `repo sync` hangs while syncing, often when it's
-completed 99% of the sync.
-
-**Cause**: Some settings in the TCP/IP stack cause difficulties
-in some network environments, such that `repo sync` neither completes
-nor fails.
-
-**Fix**: On linux, `sysctl -w net.ipv4.tcp_window_scaling=0`. On
-MacOS, disable the rfc1323 extension in the network settings.
-
-## `make snod` and emulator builds. ##
-
-**Symptom**: When using `make snod` (make system no dependencies)
-on emulator builds, the resulting build doesn't work.
-
-**Cause**: All emulator builds now run Dex optimization at build
-time by default, which requires to follow all dependencies to
-re-optimize the applications each time the framework changes.
-
-**Fix**: Locally disable Dex optimizations with
-`export WITH_DEXPREOPT=false`, delete the existing optimized
-versions with `make installclean` and run a full build to
-re-generate non-optimized versions. After that, `make snod`
-will work.
-
-## "Permission Denied" during builds. ##
-
-**Symptom**: All builds fail with "Permission Denied", possibly
-along with anti-virus warnings.
-
-**Cause**: Some anti-virus programs mistakenly recognize some
-source files in the Android source tree as if they contained
-viruses.
-
-**Fix**: After verifying that there are no actual viruses
-involved, disable anti-virus on the Android tree. This has
-the added benefit of reducing build times.
-
-## Camera, GPS and NFC don't work on Galaxy Nexus. ##
-
-**Symptom**: Camera, GPS and NFC don't work on Galaxy Nexus.
-As an example, the Camera application crashes as soon as it's
-launched.
-
-**Cause**: Those hardware peripherals require proprietary
-libraries that aren't available in the Android Open Source
-Project.
-
-**Fix**: None.
-
-## Build errors related to using the wrong compiler. ##
-
-**Symptom**: The build fails with various symptoms. One
-such symptom is `cc1: error: unrecognized command line option "-m32"`
-
-**Cause**: The Android build system uses the default compiler
-in the PATH, assuming it's a suitable compiler to generate
-binaries that run on the host. Other situations (e.g. using
-the Android NDK or building the kernel) cause the default
-compiler to not be a host compiler.
-
-**Fix**: Use a "clean" shell, in which no previous
-actions could have swapped the default compiler.
-
-## Build errors caused by non-default tool settings. ##
-
-**Symptom**: The build fails with various symptoms, possibly
-complinaing about missing files or files that have the
-wrong format. One such symptom is `member [...] in archive is not an object`.
-
-**Cause**: The Android build system tends to use many host tools
-and to rely on their default behaviors. Some settings change
-those tools' behaviors and make them behave in ways that
-confuse the build system. Variables known to cause such
-issues are `CDPATH` and `GREP_OPTIONS`.
-
-**Fix**: Build Android in an environment that has as few
-customizations as possible.
-
-## Build error with 4.0.x and earlier on MacOS 10.7. ##
-
-**Symptom**: Building IceCreamSandwich 4.0.x (and older
-versions) fails on MacOS 10.7 with errors similar to this:
-`Undefined symbols for architecture i386: "_SDL_Init"`
-
-**Cause**: 4.0.x is not compatible with MacOS 10.7.
-
-**Fix**: Either downgrade to MacOS 10.6, or use the master
-branch, which can be built on MacOS 10.7.
-
- $ repo init -b master
- $ repo sync
-
-## Build error on MacOS with XCode 4.3. ##
-
-**Symptom**: All builds fail when using XCode 4.3.
-
-**Cause**: XCode 4.3 switched the default compiler from
-gcc to llvm, and llvm rejects code that used to be
-accepted by gcc.
-
-**Fix**: Use XCode 4.2.
-
-## Build error with 4.0.x and earlier on Ubuntu 11.10. ##
-
-**Symptom**: Building IceCreamSandwich 4.0.x (and older
-versions) on Ubuntu 11.10 and newer fails with errors similar to this:
-`<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]`
-
-**Cause**: Ubuntu 11.10 uses a version of gcc where that symbol
-is defined by default, and Android also defines that symbol,
-which causes a conflict.
-
-**Fix**: Either downgrade to Ubuntu 10.04, or use the master
-branch, which can be compiled on Ubuntu 11.10 and newer.
-
- $ repo init -b master
- $ repo sync
diff --git a/src/source/licenses.jd b/src/source/licenses.jd
new file mode 100644
index 0000000..7db245c
--- /dev/null
+++ b/src/source/licenses.jd
@@ -0,0 +1,104 @@
+page.title=Licenses
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>The Android Open Source Project uses a few <a href="http://www.opensource.org/">open source initiative</a>
+approved open source licenses for our software.</p>
+<h2 id="android-open-source-project-license">Android Open Source Project license</h2>
+<p>The preferred license for the Android Open Source Project is the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
+Software License, 2.0</a> ("Apache 2.0"),
+and the majority of the Android software is licensed
+with Apache 2.0. While the project will strive to adhere to the preferred
+license, there may be exceptions which will be handled on a case-by-case
+basis. For example, the Linux kernel patches are under the GPLv2 license with
+system exceptions, which can be found on <a href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a>.</p>
+<h2 id="contributor-license-grants">Contributor License Grants</h2>
+<p>All <em>individual</em> contributors (that is, contributors making contributions
+only on their own behalf) of ideas, code, or documentation to the Android Open
+Source Project will be required to complete, sign, and submit an <a href="cla-individual.html">Individual
+Contributor License Grant</a>. The grant can be executed online through the
+<a href="https://android-review.googlesource.com/#/settings/agreements">code review tool</a>.
+The grant clearly defines the terms under which intellectual
+property has been contributed to the Android Open Source Project. This license
+is for your protection as a contributor as well as the protection of the
+project; it does not change your rights to use your own contributions for any
+other purpose.</p>
+<p>For a <em>corporation</em> (or other entity) that has assigned employees to
+work on the Android Open Source Project, a <a href="cla-corporate.pdf">Corporate
+Contributor License Grant</a> is available.
+This version of the grant allows a
+corporation to authorize contributions submitted by its designated employees
+and to grant copyright and patent licenses. Note that a Corporate Contributor
+License Grant does not remove the need for any developer to sign their own
+Individual Contributor License Grant as an individual, to cover any of their
+contributions which are <em>not</em> owned by the corporation signing the
+Corporate Contributor License Grant.</p>
+<p>Please note that we based our grants on the ones that the
+<a href="http://www.apache.org">Apache Software Foundation</a> uses, which can
+be found on <a href="http://www.apache.org/licenses/">the Apache web site</a>.</p>
+<h2 id="why-apache-software-license">Why Apache Software License?</h2>
+<p>We are sometimes asked why Apache Software License 2.0 is the preferred
+license for Android. For userspace (that is, non-kernel) software, we do in
+fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
+licenses such as LGPL.</p>
+<p>Android is about freedom and choice. The purpose of Android is promote
+openness in the mobile world, but we don't believe it's possible to predict or
+dictate all the uses to which people will want to put our software. So, while
+we encourage everyone to make devices that are open and modifiable, we don't
+believe it is our place to force them to do so. Using LGPL libraries would
+often force them to do so.</p>
+<p>Here are some of our specific concerns:</p>
+<ul>
+<li>
+<p>LGPL (in simplified terms) requires either: shipping of source to the
+application; a written offer for source; or linking the LGPL-ed library
+dynamically and allowing users to manually upgrade or replace the library.
+Since Android software is typically shipped in the form of a static system
+image, complying with these requirements ends up restricting OEMs' designs.
+(For instance, it's difficult for a user to replace a library on read-only
+flash storage.)</p>
+</li>
+<li>
+<p>LGPL requires allowance of customer modification and reverse
+engineering for debugging those modifications. Most device makers do
+not want to have to be bound by these terms, so to minimize the burden on
+these companies we minimize usage of LGPL software in userspace.</li></p>
+</li>
+<li>
+<p>Historically, LGPL libraries have been the source of a large number
+of compliance problems for downstream device makers and application
+developers. Educating engineers on these issues is difficult and slow-going,
+unfortunately. It's critical to Android's success that it be as easy as
+possible for device makers to comply with the licenses. Given the
+difficulties with complying with LGPL in the past, it is most prudent to
+simply not use LGPL libraries if we can avoid it.</p>
+</li>
+</ul>
+<p>The issues discussed above are our reasons for preferring ASL2.0 for
+our own code. They aren't criticisms of LGPL or other licenses. We do
+feel strongly on this topic, even to the point where we've gone out of our
+way to make sure as much code as possible is ASL2.0. However, we love all free
+and open source licenses, and respect others' opinions and preferences. We've
+simply decided that ASL2.0 is the right license for our goals.</p>
\ No newline at end of file
diff --git a/src/source/licenses.md b/src/source/licenses.md
deleted file mode 100644
index 0405e84..0000000
--- a/src/source/licenses.md
+++ /dev/null
@@ -1,103 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Licenses #
-
-The Android Open Source Project uses a few [open source initiative](http://www.opensource.org/)
-approved open source licenses for our software.
-
-## Android Open Source Project license ##
-
-The preferred license for the Android Open Source Project is the [Apache
-Software License, 2.0](http://www.apache.org/licenses/LICENSE-2.0) ("Apache 2.0"),
-and the majority of the Android software is licensed
-with Apache 2.0. While the project will strive to adhere to the preferred
-license, there may be exceptions which will be handled on a case-by-case
-basis. For example, the Linux kernel patches are under the GPLv2 license with
-system exceptions, which can be found on [kernel.org](http://www.kernel.org/pub/linux/kernel/COPYING).
-
-## Contributor License Grants ##
-
-All *individual* contributors (that is, contributors making contributions
-only on their own behalf) of ideas, code, or documentation to the Android Open
-Source Project will be required to complete, sign, and submit an [Individual
-Contributor License Grant](cla-individual.html). The grant can be executed online through the
-[code review tool](https://android-review.googlesource.com/#/settings/agreements).
-The grant clearly defines the terms under which intellectual
-property has been contributed to the Android Open Source Project. This license
-is for your protection as a contributor as well as the protection of the
-project; it does not change your rights to use your own contributions for any
-other purpose.
-
-For a *corporation* (or other entity) that has assigned employees to
-work on the Android Open Source Project, a [Corporate
-Contributor License Grant](cla-corporate.pdf) is available.
-This version of the grant allows a
-corporation to authorize contributions submitted by its designated employees
-and to grant copyright and patent licenses. Note that a Corporate Contributor
-License Grant does not remove the need for any developer to sign their own
-Individual Contributor License Grant as an individual, to cover any of their
-contributions which are *not* owned by the corporation signing the
-Corporate Contributor License Grant.
-
-Please note that we based our grants on the ones that the
-[Apache Software Foundation](http://www.apache.org) uses, which can
-be found on [the Apache web site](http://www.apache.org/licenses/).
-
-## Why Apache Software License? ##
-
-We are sometimes asked why Apache Software License 2.0 is the preferred
-license for Android. For userspace (that is, non-kernel) software, we do in
-fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
-licenses such as LGPL.
-
-Android is about freedom and choice. The purpose of Android is promote
-openness in the mobile world, but we don't believe it's possible to predict or
-dictate all the uses to which people will want to put our software. So, while
-we encourage everyone to make devices that are open and modifiable, we don't
-believe it is our place to force them to do so. Using LGPL libraries would
-often force them to do so.
-
-Here are some of our specific concerns:
-
-- LGPL (in simplified terms) requires either: shipping of source to the
-application; a written offer for source; or linking the LGPL-ed library
-dynamically and allowing users to manually upgrade or replace the library.
-Since Android software is typically shipped in the form of a static system
-image, complying with these requirements ends up restricting OEMs' designs.
-(For instance, it's difficult for a user to replace a library on read-only
-flash storage.)
-
-- LGPL requires allowance of customer modification and reverse
-engineering for debugging those modifications. Most device makers do
-not want to have to be bound by these terms, so to minimize the burden on
-these companies we minimize usage of LGPL software in userspace.</li>
-
-- Historically, LGPL libraries have been the source of a large number
-of compliance problems for downstream device makers and application
-developers. Educating engineers on these issues is difficult and slow-going,
-unfortunately. It's critical to Android's success that it be as easy as
-possible for device makers to comply with the licenses. Given the
-difficulties with complying with LGPL in the past, it is most prudent to
-simply not use LGPL libraries if we can avoid it.
-
-The issues discussed above are our reasons for preferring ASL2.0 for
-our own code. They aren't criticisms of LGPL or other licenses. We do
-feel strongly on this topic, even to the point where we've gone out of our
-way to make sure as much code as possible is ASL2.0. However, we love all free
-and open source licenses, and respect others' opinions and preferences. We've
-simply decided that ASL2.0 is the right license for our goals.
-
diff --git a/src/source/life-of-a-bug.jd b/src/source/life-of-a-bug.jd
new file mode 100644
index 0000000..6f3b2c3
--- /dev/null
+++ b/src/source/life-of-a-bug.jd
@@ -0,0 +1,189 @@
+page.title=Life of a Bug
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>The Android Open Source project maintains a public issue tracker where you
+can report bugs and request features for the Android software stack. (For
+details on this issue tracker, please see the <a href="report-bugs.html">Reporting Bugs</a> page).
+Reporting bugs is great (thank you!), but what happens to a bug report once
+you file it? This page describes the Life of a Bug.</p>
+<p>*Please note: the Android Open Source Project (AOSP) issue tracker is
+intended only for bugs and feature requests related to the Android software
+stack. Because many users find their way here looking for the Google apps for
+Android (such as Gmail and so on), we have components set up for their
+convenience. However, these apps are not part of Android, and any issues
+reported on these components are not guaranteed to to receive attention.
+Most notably, to report issues related to Google Play, you should visit the
+<a href="https://support.google.com/googleplay/">Google Play Support Forum</a>.</p>
+<p>Here's the life of a bug, in a nutshell:</p>
+<ol>
+<li>
+<p>A bug is filed, and has the state "New".</p>
+</li>
+<li>
+<p>An AOSP contributor periodically reviews and triages bugs. Bugs are
+triaged into one of four "buckets": New, Open, No-Action, or Resolved.</p>
+</li>
+<li>
+<p>Each bucket includes a number of states that provide more detail on the
+fate of the issue.</p>
+</li>
+<li>
+<p>Bugs in the "Resolved" bucket will eventually be included in a future
+release of the Android software.</p>
+</li>
+</ol>
+<h1 id="bucket-details">Bucket Details</h1>
+<p>Here is some additional information on each bucket, what it means, and how
+it's handled.</p>
+<h2 id="new-issues">New Issues</h2>
+<p>New issues include bug reports that are not yet being acted upon. The two
+states are:</p>
+<ul>
+<li>
+<p><em>New:</em>
+ The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)</p>
+</li>
+<li>
+<p><em>NeedsInfo:</em>
+ The bug report has insufficient information to act
+upon. The person who reported the bug needs to provide additional detail
+before it can be triaged. If enough time passes and no new information is
+provided, the bug may be closed by default, as one of the No-Action
+states.</p>
+</li>
+</ul>
+<h2 id="open-issues">Open Issues</h2>
+<p>This bucket contains bugs that need action, but which are still
+unresolved, pending a change to the source code.</p>
+<ul>
+<li>
+<p><em>Unassigned:</em>
+ The bug report has been recognized as an adequately
+detailed report of a legitimate issue, but has not yet been assigned to an
+AOSP contributor to be fixed. Typically, bugs in this state are considered low
+priority, at least insofar that if they were high priority, they'd be assigned
+to a contributor.</p>
+</li>
+<li>
+<p><em>Reviewed:</em>
+ Like <em>Unassigned</em>, but the issue
+represented is being tracked in a separate bug database. For example, the bug
+might have been reported via an internal bug-tracking system,
+which is considered the "master" copy. (For instance, Google maintains one
+such private issue tracker, intended primarily for bugs which contain
+sensitive information which can't be revealed publicly.)</p>
+</li>
+<li>
+<p><em>Assigned:</em>
+ Like <em>Unassigned</em>, but the bug has been
+actually assigned to a specific contributor to fix.</p>
+</li>
+</ul>
+<p>Typically, a given bug will start in <em>Unassigned</em>, where it
+will remain until it is associated with a specific upcoming release, at which
+point it will enter <em>Reviewed</em> or <em>Assigned</em>. However,
+note that this isn't a guarantee, and it's not uncommon for bugs to go from
+<em>Unassigned</em> to one of the Resolved states.</p>
+<p>In general, if a bug is in one of these Open states, the AOSP team has
+recognized it as a legitimate issue and will fix it according to the product
+priorities and milestones. However, it's impossible to guarantee a fix in time
+for any particular release.</p>
+<h2 id="no-action-issues">No-Action Issues</h2>
+<p>This bucket contains bugs that have for one reason or another been
+determined to not require any action.</p>
+<ul>
+<li>
+<p><em>Spam:</em>
+ A kind soul sent us some delicious pork products, that we,
+regrettably, do not want.</p>
+</li>
+<li>
+<p><em>Question:</em>
+ Someone mistook the issue tracker for a help forum.
+(This is not as uncommon as you might think: many users whose native language
+isn't English misunderstand the site and make this mistake.)</p>
+</li>
+<li>
+<p><em>Unreproducible:</em>
+ An AOSP contributor attempted to reproduce the
+behavior described, and was unable to do so. This sometimes means that the bug
+is legitimate but simply rare or difficult to reproduce, and sometimes means
+that the bug was fixed in a later release.</p>
+</li>
+<li>
+<p><em>WorkingAsIntended:</em>
+ An AOSP contributor has determined that the
+behavior described isn't a bug, but is the intended behavior. This state is
+also commonly referred to as "WAI".</p>
+</li>
+<li>
+<p><em>Declined:</em>
+ This is like <em>WorkingAsIntended</em>, except
+typically used for feature requests instead of bugs. That is, an AOSP
+contributor has determined that the request is not going to be implemented in
+Android.</p>
+</li>
+</ul>
+<h2 id="resolved-issues">Resolved Issues</h2>
+<p>This bucket contains bugs that have had action taken, and are now
+considered resolved.</p>
+<ul>
+<li>
+<p><em>FutureRelease:</em>
+ This bug has been fixed (or feature implemented) in
+a source tree, but has not yet been included in a formal Android
+platform release. (Note that this may also include fixes that exist in a
+private source tree that has not yet been contributed to a public
+tree.)</p>
+</li>
+<li>
+<p><em>Released:</em>
+ This bug has been fixed, and is included in a formal
+Android platform release. When this state is set, we try to also set a
+property indicating which release it was fixed in.</p>
+</li>
+<li>
+<p><em>Duplicate:</em>
+ This bug is a duplicate of another, existing bug report.</p>
+</li>
+</ul>
+<h1 id="other-stuff">Other Stuff</h1>
+<p>The states and lifecycle above are how we generally try to track software.
+However, Android contains a lot of software and gets a correspondingly large
+number of bugs. As a result, sometimes bugs don't make it through all the
+states in a formal progression. We do try to keep the system up to date, but
+we tend to do so in periodic "bug sweeps" where we review the database and
+make updates.</p>
+<p>Since the AOSP is essentially constantly evolving, we do make tweaks to
+the list of bug states and the lifecycle described above. When we do this,
+however, we'll be sure to update this page as well.</p>
+<p>Finally, you should be aware that for a variety of reasons, there are
+actually multiple issue trackers for Android-related issues. The
+<a href="https://code.google.com/p/android/issues/list">Google Code Project Hosting Issue Tracker</a>
+is the <em>only</em> official public issue tracker; however,
+Google also maintains a private issue tracker, own, as do most OEMs. We try to
+keep the public issue tracker in sync with private issue trackers
+wherever possible, but in cases where confidential information and security
+issues are involved, this isn't always possible.</p>
\ No newline at end of file
diff --git a/src/source/life-of-a-bug.md b/src/source/life-of-a-bug.md
deleted file mode 100644
index 64d2119..0000000
--- a/src/source/life-of-a-bug.md
+++ /dev/null
@@ -1,173 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Life of a Bug #
-
-The Android Open Source project maintains a public issue tracker where you
-can report bugs and request features for the Android software stack. (For
-details on this issue tracker, please see the [Reporting Bugs](report-bugs.html) page).
-Reporting bugs is great (thank you!), but what happens to a bug report once
-you file it? This page describes the Life of a Bug.
-
-*Please note: the Android Open Source Project (AOSP) issue tracker is
-intended only for bugs and feature requests related to the Android software
-stack. Because many users find their way here looking for the Google apps for
-Android (such as Gmail and so on), we have components set up for their
-convenience. However, these apps are not part of Android, and any issues
-reported on these components are not guaranteed to to receive attention.
-Most notably, to report issues related to Google Play, you should visit the
-[Google Play Support Forum](https://support.google.com/googleplay/).
-
-Here's the life of a bug, in a nutshell:
-
-1. A bug is filed, and has the state "New".
-
-1. An AOSP contributor periodically reviews and triages bugs. Bugs are
-triaged into one of four "buckets": New, Open, No-Action, or Resolved.
-
-1. Each bucket includes a number of states that provide more detail on the
-fate of the issue.
-
-1. Bugs in the "Resolved" bucket will eventually be included in a future
-release of the Android software.
-
-# Bucket Details #
-
-Here is some additional information on each bucket, what it means, and how
-it's handled.
-
-## New Issues ##
-
-New issues include bug reports that are not yet being acted upon. The two
-states are:
-
-- *New:*
- The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)
-
-- *NeedsInfo:*
- The bug report has insufficient information to act
-upon. The person who reported the bug needs to provide additional detail
-before it can be triaged. If enough time passes and no new information is
-provided, the bug may be closed by default, as one of the No-Action
-states.
-
-## Open Issues ##
-
-This bucket contains bugs that need action, but which are still
-unresolved, pending a change to the source code.
-
-- *Unassigned:*
- The bug report has been recognized as an adequately
-detailed report of a legitimate issue, but has not yet been assigned to an
-AOSP contributor to be fixed. Typically, bugs in this state are considered low
-priority, at least insofar that if they were high priority, they'd be assigned
-to a contributor.
-
-- *Reviewed:*
- Like *Unassigned*, but the issue
-represented is being tracked in a separate bug database. For example, the bug
-might have been reported via an internal bug-tracking system,
-which is considered the "master" copy. (For instance, Google maintains one
-such private issue tracker, intended primarily for bugs which contain
-sensitive information which can't be revealed publicly.)
-
-- *Assigned:*
- Like *Unassigned*, but the bug has been
-actually assigned to a specific contributor to fix.
-
-Typically, a given bug will start in *Unassigned*, where it
-will remain until it is associated with a specific upcoming release, at which
-point it will enter *Reviewed* or *Assigned*. However,
-note that this isn't a guarantee, and it's not uncommon for bugs to go from
-*Unassigned* to one of the Resolved states.
-
-In general, if a bug is in one of these Open states, the AOSP team has
-recognized it as a legitimate issue and will fix it according to the product
-priorities and milestones. However, it's impossible to guarantee a fix in time
-for any particular release.
-
-## No-Action Issues ##
-
-This bucket contains bugs that have for one reason or another been
-determined to not require any action.
-
-- *Spam:*
- A kind soul sent us some delicious pork products, that we,
-regrettably, do not want.
-
-- *Question:*
- Someone mistook the issue tracker for a help forum.
-(This is not as uncommon as you might think: many users whose native language
-isn't English misunderstand the site and make this mistake.)
-
-- *Unreproducible:*
- An AOSP contributor attempted to reproduce the
-behavior described, and was unable to do so. This sometimes means that the bug
-is legitimate but simply rare or difficult to reproduce, and sometimes means
-that the bug was fixed in a later release.
-
-- *WorkingAsIntended:*
- An AOSP contributor has determined that the
-behavior described isn't a bug, but is the intended behavior. This state is
-also commonly referred to as "WAI".
-
-- *Declined:*
- This is like *WorkingAsIntended*, except
-typically used for feature requests instead of bugs. That is, an AOSP
-contributor has determined that the request is not going to be implemented in
-Android.
-
-## Resolved Issues ##
-
-This bucket contains bugs that have had action taken, and are now
-considered resolved.
-
-- *FutureRelease:*
- This bug has been fixed (or feature implemented) in
-a source tree, but has not yet been included in a formal Android
-platform release. (Note that this may also include fixes that exist in a
-private source tree that has not yet been contributed to a public
-tree.)
-
-- *Released:*
- This bug has been fixed, and is included in a formal
-Android platform release. When this state is set, we try to also set a
-property indicating which release it was fixed in.
-
-- *Duplicate:*
- This bug is a duplicate of another, existing bug report.
-
-# Other Stuff #
-
-The states and lifecycle above are how we generally try to track software.
-However, Android contains a lot of software and gets a correspondingly large
-number of bugs. As a result, sometimes bugs don't make it through all the
-states in a formal progression. We do try to keep the system up to date, but
-we tend to do so in periodic "bug sweeps" where we review the database and
-make updates.
-
-Since the AOSP is essentially constantly evolving, we do make tweaks to
-the list of bug states and the lifecycle described above. When we do this,
-however, we'll be sure to update this page as well.
-
-Finally, you should be aware that for a variety of reasons, there are
-actually multiple issue trackers for Android-related issues. The
-[Google Code Project Hosting Issue Tracker](https://code.google.com/p/android/issues/list)
-is the *only* official public issue tracker; however,
-Google also maintains a private issue tracker, own, as do most OEMs. We try to
-keep the public issue tracker in sync with private issue trackers
-wherever possible, but in cases where confidential information and security
-issues are involved, this isn't always possible.
diff --git a/src/source/life-of-a-patch.jd b/src/source/life-of-a-patch.jd
new file mode 100644
index 0000000..a6fee4b
--- /dev/null
+++ b/src/source/life-of-a-patch.jd
@@ -0,0 +1,26 @@
+page.title=Life of a Patch
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<p>The Android Open Source Project (AOSP) uses a web-based code review tool
+known as <a href="https://android-review.googlesource.com/">Gerrit</a>.
+The image below is a flowchart that details what happens to
+a patch, once it's been written. Though it may appear complex, the majority of
+the steps below are performed in the web application.</p>
+<p>For full instructions on how to get set up to use gerrit and git, please
+see the <a href="submit-patches.html">Submitting Patches</a> page.</p>
+<p><img src="/images/workflow-0.png" alt="workflow diagram"/></p>
\ No newline at end of file
diff --git a/src/source/life-of-a-patch.md b/src/source/life-of-a-patch.md
deleted file mode 100644
index f84ceac..0000000
--- a/src/source/life-of-a-patch.md
+++ /dev/null
@@ -1,28 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Life of a Patch #
-
-The Android Open Source Project (AOSP) uses a web-based code review tool
-known as [Gerrit](https://android-review.googlesource.com/).
-The image below is a flowchart that details what happens to
-a patch, once it's been written. Though it may appear complex, the majority of
-the steps below are performed in the web application.
-
-For full instructions on how to get set up to use gerrit and git, please
-see the [Submitting Patches](submit-patches.html) page.
-
-<img src="/images/workflow-0.png" alt="workflow diagram"/>
diff --git a/src/source/overview.html b/src/source/overview.html
new file mode 100644
index 0000000..b8f56fc
--- /dev/null
+++ b/src/source/overview.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/index.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/source/overview.md b/src/source/overview.md
deleted file mode 100644
index 804c1f0..0000000
--- a/src/source/overview.md
+++ /dev/null
@@ -1,70 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Android Platform Overview #
-
-Our sister site, [developer.android.com](https://developer.android.com/),
-includes feature overviews of the various Android platform versions.
-The links below will take you to developer.android.com where you can view this
-information.
-
-The links below will navigate you away from this site.
-
-## [Android 4.0](https://developer.android.com/sdk/android-4.0-highlights.html) ##
-
-Android 4.0 corresponded to the "IceCreamSandwich" milestone branch, and has an API level of 14.
-
-## [Android 2.3](https://developer.android.com/sdk/android-2.3-highlights.html) ##
-
-Android 2.3 corresponded to the "Gingerbread" milestone branch, and has an API level of 9.
-In versions 2.3.3 and higher, the API level is 10.
-
-## [Android 2.2](https://developer.android.com/sdk/android-2.2-highlights.html) ##
-
-Android 2.2 corresponded to the "FroYo" milestone branch, and has an API level of 8.
-
-## [Android 2.1](https://developer.android.com/sdk/android-2.0-highlights.html) ##
-
-Android 2.1 corresponded to the "Eclair" milestone branch, and has an API level of 7.
-
-The Eclair branch was also used for 2.0 and 2.0.1; however, both of those
-releases were quickly obsoleted by the version 2.1 Eclair release. As Android
-2.1 includes key bug fixes and improvements not present in 2.0/2.0.1, only
-Android 2.1 should be used for new devices. As there is no compatibility
-program for 2.0 or 2.0.1, the officially compatible Eclair-based release is Android
-2.1. (The linked document refers to Android 2.0, because there were
-no new platform features added in 2.1.)
-
-## [Android 1.6](https://developer.android.com/sdk/android-1.6-highlights.html) ##
-
-Android 1.6 corresponded to the "Donut" milestone branch, and has an API level of 4.
-
-## [Android 1.5](https://developer.android.com/sdk/android-1.5-highlights.html) ##
-
-Android 1.5 corresponded to the "Cupcake" milestone branch, and has an API
-level of 3.
-
-## [Android 1.1](https://developer.android.com/sdk/android-1.1.html) ##
-
-Android 1.1 has an API level of 2. Android 1.1 was known as
-"Petit Four" internally, though this name was not used officially.
-
-## Android 1.0 ##
-
-was the first release of Android, and has an API
-level of 1. Since it was the first released version of Android, no platform
-highlights were prepared for this release.
-
diff --git a/src/source/report-bugs.jd b/src/source/report-bugs.jd
new file mode 100644
index 0000000..9b85b08
--- /dev/null
+++ b/src/source/report-bugs.jd
@@ -0,0 +1,152 @@
+page.title=Report Bugs
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>Thanks for your interest in Android! One of the best ways you can help us
+improve Android is to let us know about any problems you find with it.</p>
+<p>First, though: if you think you've found a security vulnerability,
+<em>please don't use the forms below</em>. Using the public forms below may
+allow anyone to see your report, which may put users at risk until the bug is
+fixed. Please visit
+<a href="{@docRoot}source/faqs.html">our
+security faq</a> for more information on reporting security vulnerabilities
+to the Android security team.</p>
+<p>Here's how to report non-security bugs:</p>
+<ul>
+<li>
+<p><a href="https://code.google.com/p/android/issues/advsearch">Search for your bug</a> to see if anyone has already reported it.</p>
+</li>
+<li>
+<p>If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.</p>
+</li>
+<li>
+<p>If no one's reported your bug, file the bug. You can use one of these templates:</p>
+<ul>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=User%20bug%20report">Bug in your Device</a> - use this if you are a user reporting a bug in a device you own</p>
+</li>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report">Bug in the Software</a> - use this if you found a bug in the course of developing an app</p>
+</li>
+<li>
+<p><a href="https://code.google.com/p/android/issues/entry?template=Feature%20request">Feature Request</a> - use this for a feature you'd like to see in a future verison</p>
+</li>
+</ul>
+</li>
+</ul>
+<p>Please note that we can't guarantee that any particular bug can be fixed in
+any particular release. To see what happens to your bug once you report it,
+read <a href="life-of-a-bug.html">Life of a Bug</a>.</p>
+<p>In general, please put as much info in bugs as you can. Just a one liner
+telling us something isn't working is usually useless, and will probably be
+closed without any action. The more detail you provide, the more likely your
+issue is to be resolved. Below, there are some examples of a good bug report
+and a poor bug report.</p>
+
+<h2 id="a-poor-bug-report">A Poor Bug Report</h2>
+<pre>
+Title: Error message
+
+When running Eclipse I get an "Internal Error" that says "See the .log file for more details".
+
+Steps to reproduce:
+Happens when "Object o = null". Doesn't happen when changed to "Object o".
+
+Expected results:
+I wouldn't get the error message--would work with Object o = null.
+
+Observed results:
+See above.
+</pre>
+<p>This is a poor bug report because it doesn't provide any context for the
+issue; is it a problem in the Dalvik virtual machine, the core framework, or
+something else? It also doesn't provide any code or hint on how to reproduce
+it. In other words, this bug report doesn't provide enough information for
+anyone to take action on, so it would be ignored.</p>
+<h2 id="a-good-bug-report">A Good Bug Report</h2>
+<pre>
+Title: Stepping over "Object o = null" causes Eclipse "Internal Error"
+
+Interesting bug, while using Eclipse 3.3.1.1 with m37a of android and the following code:
+
+package com.saville.android;
+
+import android.app.Activity;
+import android.os.Bundle;
+import android.util.Log;
+
+public class TestObjectNull extends Activity {
+ /** Called when the activity is first created. */
+ @Override
+ public void onCreate(Bundle icicle) {
+ super.onCreate(icicle);
+ setContentView(R.layout.main);
+
+ Object o = null;
+
+ o = "hi";
+
+ Log.v(TAG, "o=" + o);
+ }
+
+ static final String TAG = "TestObjectNull";
+}
+
+Eclipse indicates an "Internal Error" with "See the .log file for more
+details" and then asks if I want to exit the workbench. This occurs when I
+place a break point on "setContentView(R.layout.main);" and then single
+step over "Object o = null;"
+
+If I change "Object o = null;" to "Object o" all is well.
+
+The last lines of the .log file are:
+
+!ENTRY org.eclipse.core.jobs 4 2 2008-01-01 13:04:15.825
+!MESSAGE An internal error occurred during: "has children update".
+!STACK 0
+java.lang.InternalError: Invalid signature: "<null>"
+ at
+org.eclipse.jdi.internal.TypeImpl.signatureToTag(TypeImpl.java:307)
+ at
+org.eclipse.jdi.internal.LocalVariableImpl.tag(LocalVariableImpl.java:185)
+ at
+org.eclipse.jdi.internal.StackFrameImpl.getValues(StackFrameImpl.java:128)
+ at
+org.eclipse.jdi.internal.StackFrameImpl.getValue(StackFrameImpl.java:73)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDILocalVariable.retrieveValue(JDILocalVariable.java:57)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:66)
+ at
+org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:88)
+ at
+org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.hasChildren(VariableContentProvider.java:62)
+ at
+org.eclipse.jdt.internal.debug.ui.variables.JavaVariableContentProvider.hasChildren(JavaVariableContentProvider.java:73)
+ at
+org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.updateHasChildren(ElementContentProvider.java:223)
+ at
+org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
+ at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
+</pre>
\ No newline at end of file
diff --git a/src/source/report-bugs.md b/src/source/report-bugs.md
deleted file mode 100644
index f4fd7e5..0000000
--- a/src/source/report-bugs.md
+++ /dev/null
@@ -1,139 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Report Bugs #
-
-Thanks for your interest in Android! One of the best ways you can help us
-improve Android is to let us know about any problems you find with it.
-
-First, though: if you think you've found a security vulnerability,
-*please don't use the forms below*. Using the public forms below may
-allow anyone to see your report, which may put users at risk until the bug is
-fixed. Please visit
-<a href="https://developer.android.com/resources/faq/security.html#issue">our
-security faq</a> for more information on reporting security vulnerabilities
-to the Android security team.
-
-Here's how to report non-security bugs:
-
-- [Search for your bug](https://code.google.com/p/android/issues/advsearch) to see if anyone has already reported it.
-
-- If you find your issue and it's important to you, star it! That's how we know which bugs are most important to fix.
-
-- If no one's reported your bug, file the bug. You can use one of these templates:
-
- - [Bug in your Device](https://code.google.com/p/android/issues/entry?template=User%20bug%20report) - use this if you are a user reporting a bug in a device you own
-
- - [Bug in the Software](https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report) - use this if you found a bug in the course of developing an app
-
- - [Feature Request](https://code.google.com/p/android/issues/entry?template=Feature%20request) - use this for a feature you'd like to see in a future verison
-
-Please note that we can't guarantee that any particular bug can be fixed in
-any particular release. To see what happens to your bug once you report it,
-read [Life of a Bug](life-of-a-bug.html).
-
-In general, please put as much info in bugs as you can. Just a one liner
-telling us something isn't working is usually useless, and will probably be
-closed without any action. The more detail you provide, the more likely your
-issue is to be resolved. Below, there are some examples of a good bug report
-and a poor bug report.
-
-## A Poor Bug Report ##
- Title: Error message
-
- When running Eclipse I get an "Internal Error" that says "See the .log file for more details".
-
- Steps to reproduce:
- Happens when "Object o = null". Doesn't happen when changed to "Object o".
-
- Expected results:
- I wouldn't get the error message--would work with Object o = null.
-
- Observed results:
- See above.
-
-This is a poor bug report because it doesn't provide any context for the
-issue; is it a problem in the Dalvik virtual machine, the core framework, or
-something else? It also doesn't provide any code or hint on how to reproduce
-it. In other words, this bug report doesn't provide enough information for
-anyone to take action on, so it would be ignored.
-
-## A Good Bug Report ##
-
- Title: Stepping over "Object o = null" causes Eclipse "Internal Error"
-
- Interesting bug, while using Eclipse 3.3.1.1 with m37a of android and the following code:
-
- package com.saville.android;
-
- import android.app.Activity;
- import android.os.Bundle;
- import android.util.Log;
-
- public class TestObjectNull extends Activity {
- /** Called when the activity is first created. */
- @Override
- public void onCreate(Bundle icicle) {
- super.onCreate(icicle);
- setContentView(R.layout.main);
-
- Object o = null;
-
- o = "hi";
-
- Log.v(TAG, "o=" + o);
- }
-
- static final String TAG = "TestObjectNull";
- }
-
- Eclipse indicates an "Internal Error" with "See the .log file for more
- details" and then asks if I want to exit the workbench. This occurs when I
- place a break point on "setContentView(R.layout.main);" and then single
- step over "Object o = null;"
-
- If I change "Object o = null;" to "Object o" all is well.
-
- The last lines of the .log file are:
-
- !ENTRY org.eclipse.core.jobs 4 2 2008-01-01 13:04:15.825
- !MESSAGE An internal error occurred during: "has children update".
- !STACK 0
- java.lang.InternalError: Invalid signature: "<null>"
- at
- org.eclipse.jdi.internal.TypeImpl.signatureToTag(TypeImpl.java:307)
- at
- org.eclipse.jdi.internal.LocalVariableImpl.tag(LocalVariableImpl.java:185)
- at
- org.eclipse.jdi.internal.StackFrameImpl.getValues(StackFrameImpl.java:128)
- at
- org.eclipse.jdi.internal.StackFrameImpl.getValue(StackFrameImpl.java:73)
- at
- org.eclipse.jdt.internal.debug.core.model.JDILocalVariable.retrieveValue(JDILocalVariable.java:57)
- at
- org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:66)
- at
- org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:88)
- at
- org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.hasChildren(VariableContentProvider.java:62)
- at
- org.eclipse.jdt.internal.debug.ui.variables.JavaVariableContentProvider.hasChildren(JavaVariableContentProvider.java:73)
- at
- org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.updateHasChildren(ElementContentProvider.java:223)
- at
- org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
-
diff --git a/src/source/roles.jd b/src/source/roles.jd
new file mode 100644
index 0000000..9c93efc
--- /dev/null
+++ b/src/source/roles.jd
@@ -0,0 +1,100 @@
+page.title=Project Roles
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>The Android Open Source Project (AOSP) includes individuals working in a variety
+of roles. Google is responsible for Android product management
+and the engineering process for the core framework and platform; however,
+the project considers contributions from any source, not just Google. This
+page describes the kinds of roles that interested parties can take on.</p>
+<p>Anyone who is interested in exploring and contributing to Android can use the
+Android Open Source Project resources. Anyone can join the mailing lists, ask
+questions, contribute patches, report bugs, look at submitted patches, and use
+the tools. To get started with the Android code, see <a href="/source/contributing.html">Contributing</a>.</p>
+<h2 id="contributor">Contributor</h2>
+<p>A "Contributor" is anyone making contributions to the AOSP source code,
+including both employees of Google or other companies, as well as external
+developers who are contributing to Android on their own behalf. There is no
+distinction between Contributors who are employed by Google, and those who are
+not: all engineers use the same tools (git, repo, and gerrit),
+follow the same code review process, and are subject
+to the same requirements on code style and so on.</p>
+<h2 id="developer">Developer</h2>
+<p>A "Developer" is an engineer writing applications that run on Android
+devices. There is, of course, no difference in skillset between a "Developer"
+and a "Contributor", but AOSP uses "Developer" to distinguish between
+engineers using the platform and those contributing to it. Developers are
+(along with end users) the "customers" of the platform that the Contributors
+create. As such, we talk about Developers a lot, though this isn't technically
+a separate role in the AOSP per se.</p>
+<h2 id="verifier">Verifier</h2>
+<p>"Verifiers" are responsible for testing change requests. After individuals
+have submitted a significant amount of high-quality code to the project, the
+Project Leads might invite them to become Verifiers. <em>Note: at this
+time, generally Verifiers are the same as Approvers.</em></p>
+<h2 id="approver">Approver</h2>
+<p>"Approvers" are experienced members of the project who have demonstrated their
+design skills and have made significant technical contributions to the
+project. In the code-review process, an Approver decides whether to include or
+exclude a change. Project Leads (who are typically employed by Google) choose
+the Approvers, sometimes promoting to this position Verifiers who have
+demonstrated their expertise within a specific project.</p>
+<h2 id="project-leads">Project Leads</h2>
+<p>Android consists of a number of sub-projects; you can see these in the git
+repository, as individual .git files. Tech Leads are senior Contributors who
+oversee the engineering for individual Android projects. Typically these tech
+leads will be Google employees. A Project Lead for an individual project is
+responsible for the following:</p>
+<ul>
+<li>
+<p>Lead all technical aspects of the project; for example, the project roadmap,
+ development, release cycles, versioning, and QA.</p>
+</li>
+<li>
+<p>Ensure that the project is QA-ed in time for scheduled Android platform
+ releases.</p>
+</li>
+<li>
+<p>Designate Verifiers and Approvers for submitted patches.</p>
+</li>
+<li>
+<p>Be fair and unbiased while reviewing changes. Accept or reject patches
+ based on technical merit and alignment with the Android strategy.</p>
+</li>
+<li>
+<p>Review changes in a timely manner and make best efforts to communicate
+ when changes are not accepted.</p>
+</li>
+<li>
+<p>Optionally maintain a web site for the project for information and
+ documents specific to the project.</p>
+</li>
+<li>
+<p>Act as a facilitator in resolving technical conflicts.</p>
+</li>
+<li>
+<p>Be a public face for the project and the go-to person for questions
+ related to the project.</p>
+</li>
+</ul>
diff --git a/src/source/roles.md b/src/source/roles.md
deleted file mode 100644
index 5e7c62a..0000000
--- a/src/source/roles.md
+++ /dev/null
@@ -1,95 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# People and Roles #
-
-The Android Open Source Project (AOSP) includes individuals working in a variety
-of roles. As noted in [Our Philosophy](philosophy.html), Google is responsible for Android product management
-and the engineering process for the core framework and platform; however,
-the project considers contributions from any source, not just Google. This
-page describes the kinds of roles that interested parties can take on.
-
-Anyone who is interested in exploring and contributing to Android can use the
-Android Open Source Project resources. Anyone can join the mailing lists, ask
-questions, contribute patches, report bugs, look at submitted patches, and use
-the tools. To get started with the Android code, see [Get Involved](/source/index.html).
-
-## Contributor ##
-
-A "Contributor" is anyone making contributions to the AOSP source code,
-including both employees of Google or other companies, as well as external
-developers who are contributing to Android on their own behalf. There is no
-distinction between Contributors who are employed by Google, and those who are
-not: all engineers use the same tools (git, repo, and gerrit),
-follow the same code review process, and are subject
-to the same requirements on code style and so on.
-
-## Developer ##
-
-A "Developer" is an engineer writing applications that run on Android
-devices. There is, of course, no difference in skillset between a "Developer"
-and a "Contributor", but AOSP uses "Developer" to distinguish between
-engineers using the platform and those contributing to it. Developers are
-(along with end users) the "customers" of the platform that the Contributors
-create. As such, we talk about Developers a lot, though this isn't technically
-a separate role in the AOSP per se.
-
-## Verifier ##
-
-"Verifiers" are responsible for testing change requests. After individuals
-have submitted a significant amount of high-quality code to the project, the
-Project Leads might invite them to become Verifiers. *Note: at this
-time, generally Verifiers are the same as Approvers.*
-
-## Approver ##
-
-"Approvers" are experienced members of the project who have demonstrated their
-design skills and have made significant technical contributions to the
-project. In the code-review process, an Approver decides whether to include or
-exclude a change. Project Leads (who are typically employed by Google) choose
-the Approvers, sometimes promoting to this position Verifiers who have
-demonstrated their expertise within a specific project.
-
-## Project Leads ##
-
-Android consists of a number of sub-projects; you can see these in the git
-repository, as individual .git files. Tech Leads are senior Contributors who
-oversee the engineering for individual Android projects. Typically these tech
-leads will be Google employees. A Project Lead for an individual project is
-responsible for the following:
-
-- Lead all technical aspects of the project; for example, the project roadmap,
- development, release cycles, versioning, and QA.
-
-- Ensure that the project is QA-ed in time for scheduled Android platform
- releases.
-
-- Designate Verifiers and Approvers for submitted patches.
-
-- Be fair and unbiased while reviewing changes. Accept or reject patches
- based on technical merit and alignment with the Android strategy.
-
-- Review changes in a timely manner and make best efforts to communicate
- when changes are not accepted.
-
-- Optionally maintain a web site for the project for information and
- documents specific to the project.
-
-- Act as a facilitator in resolving technical conflicts.
-
-- Be a public face for the project and the go-to person for questions
- related to the project.
-
diff --git a/src/source/sidebar.md b/src/source/sidebar.md
deleted file mode 100644
index 5818d91..0000000
--- a/src/source/sidebar.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Getting Started #
-
-- [Initializing the Build Environment](initializing.html)
-- [Downloading the Source](downloading.html)
-- [Building and Running](building.html)
-- [Building for Devices](building-devices.html)
-- [Building Kernels](building-kernels.html)
-- [Known Issues](known-issues.html)
-
-# Navigating the Source #
-
-- [Platform Overview](overview.html)
-- [Branches & Releases](code-lines.html)
-- [Build Numbers](build-numbers.html)
-
-# Contributing #
-
-- [Life of a Patch](life-of-a-patch.html)
-- [Submitting Patches](submit-patches.html)
-- [View Patches](https://android-review.googlesource.com/)
-- [Life of a Bug](life-of-a-bug.html)
-- [Reporting Bugs](report-bugs.html)
-
-# Reference #
-
-- [Version Control](version-control.html)
- - [Repo Commands](using-repo.html)
- - [Git Resources](git-resources.html)
-- [Using Eclipse](using-eclipse.html)
-- [Code Style Guidelines](code-style.html)
-- [FAQs](/faqs.html)
-
-
-
diff --git a/src/source/source_toc.cs b/src/source/source_toc.cs
new file mode 100644
index 0000000..969a4fa
--- /dev/null
+++ b/src/source/source_toc.cs
@@ -0,0 +1,85 @@
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--><?cs # Table of contents for Dev pdk.?>
+<ul id="nav">
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/code-lines.html">Codelines, Branches, and Releases</a></li>
+ <li><a href="<?cs var:toroot ?>source/build-numbers.html">Codenames, Tags, and Build Numbers</a></li>
+ <li><a href="<?cs var:toroot ?>source/roles.html">Project Roles</a></li>
+ <li><a href="<?cs var:toroot ?>source/licenses.html">Licenses</a></li>
+ <li><a href="<?cs var:toroot ?>source/faqs.html">FAQ</a></li>
+ </ul>
+ </li>
+
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/building.html">
+ <span class="en">Downloading and Building</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/initializing.html">Initializing the Build Environment</a></li>
+ <li><a href="<?cs var:toroot ?>source/downloading.html">Downloading the Source</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-running.html">Building and Running</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-devices.html">Building for Devices</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-kernels.html">Building Kernels</a></li>
+ <li><a href="<?cs var:toroot ?>source/known-issues.html">Known Issues</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/developing.html">
+ <span class="en">Developing</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/using-repo.html">Using Repo</a></li>
+ <li><a href="<?cs var:toroot ?>source/using-eclipse.html">Using Eclipse</a></li>
+ <li><a href="<?cs var:toroot ?>source/git-resources.html">Git Resources</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>source/contributing.html">
+ <span class="en">Contributing</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-patch.html">Life of a Patch</a>
+ <li><a href="<?cs var:toroot ?>source/submit-patches.html">Submitting Patches</a></li>
+ <li><a href="http://android-review.googlesource.com">View Patches</a></li>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-bug.html">Life of a Bug</a></li>
+ <li><a href="<?cs var:toroot ?>source/report-bugs.html">Reporting Bugs</a></li>
+ <li><a href="<?cs var:toroot ?>source/code-style.html">Code Style Guidelines</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header empty">
+ <a href="<?cs var:toroot ?>source/community/index.html">
+ <span class="en">Community</span>
+ </a>
+ </div>
+ </li>
+
+</ul>
\ No newline at end of file
diff --git a/src/source/submit-patches.jd b/src/source/submit-patches.jd
new file mode 100644
index 0000000..6d555c5
--- /dev/null
+++ b/src/source/submit-patches.jd
@@ -0,0 +1,204 @@
+page.title=Submitting Patches
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>This page describes the full process of submitting a patch to the AOSP, including
+reviewing and tracking changes with <a href="https://android-review.googlesource.com/">Gerrit</a>.</p>
+<h2 id="prerequisites">Prerequisites</h2>
+<ul>
+<li>
+<p>Before you follow the instructions on this page, you need to <a href="">initialize your
+build environment</a> and <a href="{@docRoot}source/downloading.html">download the source</a>.</p>
+</li>
+<li>
+<p>For details about Repo and Git, see the <a href="version-control.html">Developing</a> section.</p>
+</li>
+<li>
+<p>For information about the different roles you can play within the Android
+Open Source community, see <a href="/source/roles.html">Project roles</a>.</p>
+</li>
+<li>
+<p>If you plan to contribute code to the Android platform, be sure to read
+the <a href="/source/licenses.html">AOSP's licensing information</a>.</p>
+</li>
+<li>
+<p>Note that changes to some of the upstream projects used by Android should be
+made directly to that project, as described in <a href="#upstream-projects">Upstream Projects</a>.</p>
+</li>
+</ul>
+<h1 id="for-contributors">For contributors</h1>
+<h2 id="authenticate-with-the-server">Authenticate with the server</h2>
+<p>Before you can upload to Gerrit, you need to establish a password that
+will identify you with the server. You only need to do this once.</p>
+<ul>
+<li>
+<p>Sign in on the <a href="https://android-review.googlesource.com/">AOSP Gerrit Server</a>.</p>
+</li>
+<li>
+<p>Go to Settings -> HTTP Password -> Obtain Password</p>
+</li>
+<li>
+<p>Follow the instructions on the subsquent pages, and copy-paste your
+password in <code>~/.netrc</code>. If there are two password lines, copy both.</p>
+</li>
+</ul>
+<h2 id="start-a-repo-branch">Start a repo branch</h2>
+<p>For each change you intend to make, start a new branch within the relevant git repository:</p>
+<pre><code>$ repo start NAME .
+</code></pre>
+<p>You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and will not be included on gerrit or the final source tree.</p>
+<h2 id="make-your-change">Make your change</h2>
+<p>Once you have modified the source files (and validated them, please) commit the changes to your local repository:</p>
+<pre><code>$ git add -A
+$ git commit -s
+</code></pre>
+<p>Provide a detailed description of the change in your commit message. This description will be pushed to the public AOSP repository, so please follow our guidelines for writing changelist descriptions: </p>
+<ul>
+<li>
+<p>Start with a one-line summary (60 characters max), followed by a blank line. This format is used by git and gerrit for various displays. </p>
+<pre><code>short description on first line
+
+more detailed description of your patch,
+which is likely to take up multiple lines.
+</code></pre>
+</li>
+<li>
+<p>The description should focus on what issue it solves, and how it solves it. The second part is somewhat optional when implementing new features, though desirable.</p>
+</li>
+<li>
+<p>Include a brief note of any assumptions or background information that may be important when another contributor works on this feature next year. </p>
+</li>
+</ul>
+<p>A unique change ID and your name and email as provided during <code>repo init</code> will be automatically added to your commit message. </p>
+<h2 id="upload-to-gerrit">Upload to gerrit</h2>
+<p>Once you have committed your change to your personal history, upload it to gerrit with</p>
+<pre><code>$ repo upload
+</code></pre>
+<p>If you have started multiple branches in the same repository, you will be prompted to select which one(s) to upload.</p>
+<p>After a successful upload, repo will provide you the URL of a new page on
+<a href="https://android-review.googlesource.com/">Gerrit</a>. Visit this link to view
+your patch on the review server, add comments, or request specific reviewers
+for your patch.</p>
+<h2 id="uploading-a-replacement-patch">Uploading a replacement patch</h2>
+<p>Suppose a reviewer has looked at your patch and requested a small modification. You can amend your commit within git, which will result in a new patch on gerrit with the same change ID as the original.</p>
+<p><em>Note that if you have made other commits since uploading this patch, you will need to manually move your git HEAD.</em></p>
+<pre><code>$ git add -A
+$ git commit --amend
+</code></pre>
+<p>When you upload the amended patch, it will replace the original on gerrit and in your local git history.</p>
+<h2 id="resolving-sync-conflicts">Resolving sync conflicts</h2>
+<p>If other patches are submitted to the source tree that conflict with yours, you will need to rebase your patch on top of the new HEAD of the source repository. The easy way to do this is to run</p>
+<pre><code>$ repo sync
+</code></pre>
+<p>This command first fetches the updates from the source server, then attempts to automatically rebase your HEAD onto the new remote HEAD.</p>
+<p>If the automatic rebase is unsuccessful, you will have to perform a manual rebase.</p>
+<pre><code>$ git rebase master
+</code></pre>
+<p>Using <code>git mergetool</code> may help you deal with the rebase conflict. Once you have successfully merged the conflicting files,</p>
+<pre><code>$ git rebase --continue
+</code></pre>
+<p>After either automatic or manual rebase is complete, run <code>repo upload</code> to submit your rebased patch.</p>
+<h2 id="after-a-submission-is-approved">After a submission is approved</h2>
+<p>After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. Other users will be able to run <code>repo sync</code> to pull the update into their local client.</p>
+<h1 id="for-reviewers-and-verifiers">For reviewers and verifiers</h1>
+<h2 id="reviewing-a-change">Reviewing a change</h2>
+<p>If you are assigned to be the Approver for a change, you need to determine the following:</p>
+<ul>
+<li>
+<p>Does this change fit within this project's stated purpose?</p>
+</li>
+<li>
+<p>Is this change valid within the project's existing architecture?</p>
+</li>
+<li>
+<p>Does this change introduce design flaws that will cause problems in the future?</p>
+</li>
+<li>
+<p>Does this change follow the best practices that have been established for this project?</p>
+</li>
+<li>
+<p>Is this change a good way to perform the described function?</p>
+</li>
+<li>
+<p>Does this change introduce any security or instability risks?</p>
+</li>
+</ul>
+<p>If you approve of the change, mark it with LGTM ("Looks Good to Me") within Gerrit.</p>
+<h2 id="verifying-a-change">Verifying a change</h2>
+<p>If you are assigned to be the Verifier for a change, you need to do the following:</p>
+<ul>
+<li>
+<p>Patch the change into your local client using one of the Download commands.</p>
+</li>
+<li>
+<p>Build and test the change.</p>
+</li>
+<li>
+<p>Within Gerrit use Publish Comments to mark the commit as "Verified" or "Fails," and add a message explaining what problems were identified.</p>
+</li>
+</ul>
+<h2 id="downloading-changes-from-gerrit">Downloading changes from Gerrit</h2>
+<p>A submission that has been verified and merged will be downloaded with the next <code>repo sync</code>. If you wish to download a specific change that has not yet been approved, run</p>
+<pre><code>$ repo download TARGET CHANGE
+</code></pre>
+<p>where TARGET is the local directory into which the change should be downloaded and CHANGE is the
+change number as listed in <a href="https://android-review.googlesource.com/">Gerrit</a>. For more information,
+see the <a href="/source/using-repo.html">Repo reference</a>.</p>
+<h2 id="how-do-i-become-a-verifier-or-approver">How do I become a Verifier or Approver?</h2>
+<p>In short, contribute high-quality code to one or more of the Android projects.
+For details about the different roles in the Android Open Source community and
+who plays them, see <a href="/source/roles.html">Project Roles</a>.</p>
+<h2 id="diffs-and-comments">Diffs and comments</h2>
+<p>To open the details of the change within Gerrit, click on the "Id number" or "Subject" of a change. To compare the established code with the updated code, click the file name under "Side-by-side diffs."</p>
+<h2 id="adding-comments">Adding comments</h2>
+<p>Anyone in the community can use Gerrit to add inline comments to code submissions. A good comment will be relevant to the line or section of code to which it is attached in Gerrit. It might be a short and constructive suggestion about how a line of code could be improved, or it might be an explanation from the author about why the code makes sense the way it is.</p>
+<p>To add an inline comment, double-click the relevant line of the code and write your comment in the text box that opens. When you click Save, only you can see your comment.</p>
+<p>To publish your comments so that others using Gerrit will be able to see them, click the Publish Comments button. Your comments will be emailed to all relevant parties for this change, including the change owner, the patch set uploader (if different from the owner), and all current reviewers.</p>
+<p><a name="upstream-projects"></a></p>
+<h1 id="upstream-projects">Upstream Projects</h1>
+<p>Android makes use of a number of other open-source projects, such as the Linux kernel and WebKit, as described in
+<a href="/source/code-lines.html">Codelines, Branches, and Releases</a>. For most projects under <code>external/</code>, changes should be made upstream and then the Android maintainers informed of the new upstream release containing these changes. It may also be useful to upload patches that move us to track a new upstream release, though these can be difficult changes to make if the project is widely used within Android like most of the larger ones mentioned below, where we tend to upgrade with every release.</p>
+<p>One interesting special case is bionic. Much of the code there is from BSD, so unless the change is to code that's new to bionic, we'd much rather see an upstream fix and then pull a whole new file from the appropriate BSD. (Sadly we have quite a mix of different BSDs at the moment, but we hope to address that in future, and get into a position where we track upstream much more closely.)</p>
+<h2 id="icu4c">ICU4C</h2>
+<p>All changes to the ICU4C project at <code>external/icu4c</code> should be made upstream at
+<a href="http://site.icu-project.org/">icu-project.org/</a>.
+See <a href="http://site.icu-project.org/bugs">Submitting ICU Bugs and Feature Requests</a> for more.</p>
+<h2 id="openssl">OpenSSL</h2>
+<p>All changes to the OpenSSL project at <code>external/openssl</code> should be made upstream at
+<a href="http://www.openssl.org">openssl.org</a>.</p>
+<h2 id="v8">V8</h2>
+<p>All changes to the V8 project at <code>external/v8</code> should be submitted upstream at
+<a href="https://code.google.com/p/v8">code.google.com/p/v8</a>. See <a href="https://code.google.com/p/v8/wiki/Contributing">Contributing to V8</a>
+for details.</p>
+<h2 id="webkit">WebKit</h2>
+<p>All changes to the WebKit project at <code>external/webkit</code> should be made
+upstream at <a href="http://www.webkit.org">webkit.org</a>. The process begins by filing a WebKit bug.
+This bug should use <code>Android</code> for the <code>Platform</code> and <code>OS</code>
+fields only if the bug is specific to Android. Bugs are far more likely to receive the reviewers'
+attention once a proposed fix is added and tests are included. See
+<a href="http://webkit.org/coding/contributing.html">Contributing Code to WebKit</a> for details.</p>
+<h2 id="zlib">zlib</h2>
+<p>All changes to the zlib project at <code>external/zlib</code> should be made upstream at
+<a href="http://zlib.net">zlib.net</a>.</p>
diff --git a/src/source/submit-patches.md b/src/source/submit-patches.md
deleted file mode 100644
index 0ea530d..0000000
--- a/src/source/submit-patches.md
+++ /dev/null
@@ -1,225 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Submitting Patches #
-
-This page describes the full process of submitting a patch to the AOSP, including
-reviewing and tracking changes with [Gerrit](https://android-review.googlesource.com/).
-
-## Prerequisites ##
-
-- Before you follow the instructions on this page, you will need to set up your
-local working environment and get the Android source files. For instructions,
-follow the "Getting Started" section [here](downloading.html).
-
-- For details about Repo and Git, see [Version Control](version-control.html).
-
-- For information about the different roles you can play within the Android
-Open Source community, see [Project roles](/source/roles.html).
-
-- If you plan to contribute code to the Android platform, be sure to read
-the [AOSP's licensing information](/source/licenses.html).
-
-- Note that changes to some of the upstream projects used by Android should be
-made directly to that project, as described in [Upstream Projects](#upstream-projects).
-
-# For contributors #
-
-## Authenticate with the server ##
-
-Before you can upload to Gerrit, you need to establish a password that
-will identify you with the server. You only need to do this once.
-
-- Sign in on the [AOSP Gerrit Server](https://android-review.googlesource.com/).
-
-- Go to Settings -> HTTP Password -> Obtain Password
-
-- Follow the instructions on the subsquent pages, and copy-paste your
-password in `~/.netrc`. If there are two password lines, copy both.
-
-## Start a repo branch ##
-
-For each change you intend to make, start a new branch within the relevant git repository:
-
- $ repo start NAME .
-
-You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and will not be included on gerrit or the final source tree.
-
-## Make your change ##
-
-Once you have modified the source files (and validated them, please) commit the changes to your local repository:
-
- $ git add -A
- $ git commit -s
-
-Provide a detailed description of the change in your commit message. This description will be pushed to the public AOSP repository, so please follow our guidelines for writing changelist descriptions:
-
-- Start with a one-line summary (60 characters max), followed by a blank line. This format is used by git and gerrit for various displays.
-
- short description on first line
-
- more detailed description of your patch,
- which is likely to take up multiple lines.
-
-- The description should focus on what issue it solves, and how it solves it. The second part is somewhat optional when implementing new features, though desirable.
-
-- Include a brief note of any assumptions or background information that may be important when another contributor works on this feature next year.
-
-A unique change ID and your name and email as provided during `repo init` will be automatically added to your commit message.
-
-## Upload to gerrit ##
-
-Once you have committed your change to your personal history, upload it to gerrit with
-
- $ repo upload
-
-If you have started multiple branches in the same repository, you will be prompted to select which one(s) to upload.
-
-After a successful upload, repo will provide you the URL of a new page on
-[Gerrit](https://android-review.googlesource.com/). Visit this link to view
-your patch on the review server, add comments, or request specific reviewers
-for your patch.
-
-## Uploading a replacement patch ##
-
-Suppose a reviewer has looked at your patch and requested a small modification. You can amend your commit within git, which will result in a new patch on gerrit with the same change ID as the original.
-
-*Note that if you have made other commits since uploading this patch, you will need to manually move your git HEAD.*
-
- $ git add -A
- $ git commit --amend
-
-When you upload the amended patch, it will replace the original on gerrit and in your local git history.
-
-## Resolving sync conflicts ##
-
-If other patches are submitted to the source tree that conflict with yours, you will need to rebase your patch on top of the new HEAD of the source repository. The easy way to do this is to run
-
- $ repo sync
-
-This command first fetches the updates from the source server, then attempts to automatically rebase your HEAD onto the new remote HEAD.
-
-If the automatic rebase is unsuccessful, you will have to perform a manual rebase.
-
- $ git rebase master
-
-Using `git mergetool` may help you deal with the rebase conflict. Once you have successfully merged the conflicting files,
-
- $ git rebase --continue
-
-After either automatic or manual rebase is complete, run `repo upload` to submit your rebased patch.
-
-## After a submission is approved ##
-
-After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. Other users will be able to run `repo sync` to pull the update into their local client.
-
-# For reviewers and verifiers #
-
-## Reviewing a change ##
-
-If you are assigned to be the Approver for a change, you need to determine the following:
-
-- Does this change fit within this project's stated purpose?
-
-- Is this change valid within the project's existing architecture?
-
-- Does this change introduce design flaws that will cause problems in the future?
-
-- Does this change follow the best practices that have been established for this project?
-
-- Is this change a good way to perform the described function?
-
-- Does this change introduce any security or instability risks?
-
-If you approve of the change, mark it with LGTM ("Looks Good to Me") within Gerrit.
-
-## Verifying a change ##
-
-If you are assigned to be the Verifier for a change, you need to do the following:
-
-- Patch the change into your local client using one of the Download commands.
-
-- Build and test the change.
-
-- Within Gerrit use Publish Comments to mark the commit as "Verified" or "Fails," and add a message explaining what problems were identified.
-
-## Downloading changes from Gerrit ##
-
-A submission that has been verified and merged will be downloaded with the next `repo sync`. If you wish to download a specific change that has not yet been approved, run
-
- $ repo download TARGET CHANGE
-
-where TARGET is the local directory into which the change should be downloaded and CHANGE is the
-change number as listed in [Gerrit](https://android-review.googlesource.com/). For more information,
-see the [Repo reference](/source/using-repo.html).
-
-## How do I become a Verifier or Approver? ##
-
-In short, contribute high-quality code to one or more of the Android projects.
-For details about the different roles in the Android Open Source community and
-who plays them, see [Project Roles](/source/roles.html).
-
-## Diffs and comments ##
-
-To open the details of the change within Gerrit, click on the "Id number" or "Subject" of a change. To compare the established code with the updated code, click the file name under "Side-by-side diffs."
-
-## Adding comments ##
-
-Anyone in the community can use Gerrit to add inline comments to code submissions. A good comment will be relevant to the line or section of code to which it is attached in Gerrit. It might be a short and constructive suggestion about how a line of code could be improved, or it might be an explanation from the author about why the code makes sense the way it is.
-
-To add an inline comment, double-click the relevant line of the code and write your comment in the text box that opens. When you click Save, only you can see your comment.
-
-To publish your comments so that others using Gerrit will be able to see them, click the Publish Comments button. Your comments will be emailed to all relevant parties for this change, including the change owner, the patch set uploader (if different from the owner), and all current reviewers.
-
-<a name="upstream-projects"></a>
-
-# Upstream Projects #
-
-Android makes use of a number of other open-source projects, such as the Linux kernel and WebKit, as described in
-[Branches and Releases](/source/code-lines.html). For most projects under `external/`, changes should be made upstream and then the Android maintainers informed of the new upstream release containing these changes. It may also be useful to upload patches that move us to track a new upstream release, though these can be difficult changes to make if the project is widely used within Android like most of the larger ones mentioned below, where we tend to upgrade with every release.
-
-One interesting special case is bionic. Much of the code there is from BSD, so unless the change is to code that's new to bionic, we'd much rather see an upstream fix and then pull a whole new file from the appropriate BSD. (Sadly we have quite a mix of different BSDs at the moment, but we hope to address that in future, and get into a position where we track upstream much more closely.)
-
-## ICU4C ##
-
-All changes to the ICU4C project at `external/icu4c` should be made upstream at
-[icu-project.org/](http://site.icu-project.org/).
-See [Submitting ICU Bugs and Feature Requests](http://site.icu-project.org/bugs) for more.
-
-## OpenSSL ##
-
-All changes to the OpenSSL project at `external/openssl` should be made upstream at
-[openssl.org](http://www.openssl.org).
-
-## V8 ##
-
-All changes to the V8 project at `external/v8` should be submitted upstream at
-[code.google.com/p/v8](https://code.google.com/p/v8). See [Contributing to V8](https://code.google.com/p/v8/wiki/Contributing)
-for details.
-
-## WebKit ##
-
-All changes to the WebKit project at `external/webkit` should be made
-upstream at [webkit.org](http://www.webkit.org). The process begins by filing a WebKit bug.
-This bug should use `Android` for the `Platform` and `OS`
-fields only if the bug is specific to Android. Bugs are far more likely to receive the reviewers'
-attention once a proposed fix is added and tests are included. See
-[Contributing Code to WebKit](http://webkit.org/coding/contributing.html) for details.
-
-## zlib ##
-
-All changes to the zlib project at `external/zlib` should be made upstream at
-[zlib.net](http://zlib.net).
diff --git a/src/source/using-eclipse.jd b/src/source/using-eclipse.jd
new file mode 100644
index 0000000..d34084a
--- /dev/null
+++ b/src/source/using-eclipse.jd
@@ -0,0 +1,231 @@
+page.title=Using Eclipse
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>This document will help you set up the Eclipse IDE for Android platform development.</p>
+<p><em>Note: if you are looking for information on how to use
+Eclipse to develop applications that run on Android, this is not the right
+page for you. You probably would find <a href="https://developer.android.com/sdk/eclipse-adt.html">the Eclipse page on
+developer.android.com</a> more useful.</em></p>
+<h2 id="basic-setup">Basic setup</h2>
+<p>First, it's important to make sure the regular Android development system is set up.</p>
+<pre><code>cd /path/to/android/root
+make
+</code></pre>
+<p><strong>Important</strong>: You will still be using <code>make</code> to build the files you will actually run (in the emulator or on a device). You will be using Eclipse to edit files and verify that they compile, but when you want to run something you will need to make sure files are saved in Eclipse and run <code>make</code> in a shell. The Eclipse build is just for error checking.</p>
+<p>Eclipse needs a list of directories to search for Java files. This is called the "Java Build Path" and can be set with the <code>.classpath</code> file. We have a sample version to start you off.</p>
+<pre><code>cd /path/to/android/root
+cp development/ide/eclipse/.classpath .
+chmod u+w .classpath
+</code></pre>
+<p>Now edit that copy of <code>.classpath</code>, if necessary.</p>
+<h3 id="increase-eclipses-memory-settings">Increase Eclipse's Memory Settings</h3>
+<p>The Android project is large enough that Eclipse's Java VM sometimes runs out of memory while compiling it. Avoid this problem by editing the <code>eclipse.ini</code> file. On Apple OSX the eclipse.ini file is located at</p>
+<pre><code>/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
+</code></pre>
+<p>Memory-related defaults (as of Eclipse 3.4):</p>
+<pre><code>-Xms40m
+-Xmx256m
+-XX:MaxPermSize=256m
+</code></pre>
+<p>Recommended settings for Android development:</p>
+<pre><code>-Xms128m
+-Xmx512m
+-XX:MaxPermSize=256m
+</code></pre>
+<p>These settings set Eclipse's minimum Java heap size to 128MB, set the maximum Java heap size to 512MB, and keep the maximum permanent generation size at the default of 256MB.</p>
+<p>Now start Eclipse:</p>
+<pre><code>eclipse
+</code></pre>
+<p>Now create a project for Android development:</p>
+<ol>
+<li>
+<p>If Eclipse asks you for a workspace location, choose the default.</p>
+</li>
+<li>
+<p>If you have a "Welcome" screen, close it to reveal the Java perspective.</p>
+</li>
+<li>
+<p>File > New > Java Project</p>
+</li>
+<li>
+<p>Pick a project name, "android" or anything you like.</p>
+</li>
+<li>
+<p>Select "Create project from existing source", enter the path to your Android root directory, and click Finish.</p>
+</li>
+<li>
+<p>Wait while it sets up the project. (You'll see a subtle progress meter in the lower right corner.)</p>
+</li>
+</ol>
+<p>Once the project workspace is created, Eclipse should start building. In theory, it should build with no errors and you should be set to go. If necessary, uncheck and re-check Project Build Automatically to force a rebuild.</p>
+<p><em>Note:</em> Eclipse sometimes likes to add an <code>import android.R</code> statement at the top of your files that use resources, especially when you ask eclipse to sort or otherwise manage imports. This will cause your make to break. Look out for these erroneous import statements and delete them.</p>
+<h3 id="when-you-sync">When You Sync</h3>
+<p>Every time you repo sync, or otherwise change files outside of Eclipse (especially the .classpath), you need to refresh Eclipse's view of things:</p>
+<ol>
+<li>
+<p>Window > Show View > Navigator</p>
+</li>
+<li>
+<p>In the Navigator, right-click on the project name</p>
+</li>
+<li>
+<p>Click Refresh in the context menu</p>
+</li>
+</ol>
+<h3 id="adding-apps-to-the-build-path">Adding Apps to the Build Path</h3>
+<p>The default <code>.classpath</code> includes the source to the core system and a sample set of apps, but might not include the particular app you may want to work on. To add an app, you must add the app's source directory. To do this inside Eclipse:</p>
+<ol>
+<li>
+<p>Project > Properties</p>
+</li>
+<li>
+<p>Select "Java Build Path" from the left-hand menu.</p>
+</li>
+<li>
+<p>Choose the "Source" tab.</p>
+</li>
+<li>
+<p>Click "Add Folder..."</p>
+</li>
+<li>
+<p>Add your app's <code>src</code> directory.</p>
+</li>
+<li>
+<p>Click OK.</p>
+</li>
+</ol>
+<p>When you're done, the "source folder" path in the list should look like </p>
+<pre><code>android/packages/apps/YOURAPP/src
+</code></pre>
+<p>Depending on which app(s) you include, you may also need to include <code>othersrc/main/java</code> directories under <code>android/dalvik/libcore</code>. Do this if you find you cannot build with the default set.</p>
+<h2 id="eclipse-formatting">Eclipse formatting</h2>
+<p>You can import files in <code>development/ide/eclipse</code> to make Eclipse
+follow the Android style rules. </p>
+<ol>
+<li>
+<p>Select Window > Preferences > Java > Code Style.</p>
+</li>
+<li>
+<p>Use Formatter > Import to import <code>android-formatting.xml</code>.</p>
+</li>
+<li>
+<p>Organize Imports > Import to import <code>android.importorder</code>.</p>
+</li>
+</ol>
+<h2 id="debugging-the-emulator-with-eclipse">Debugging the emulator with Eclipse</h2>
+<p>You can also use eclipse to debug the emulator and step through code. First, start the emulator running:</p>
+<pre><code>cd /path/to/android/root
+. build/envsetup.sh
+lunch 1
+make
+emulator
+</code></pre>
+<p>If the emulator is running, you should see a picture of a phone.</p>
+<p>In another shell, start DDMS (the Dalvik debug manager):</p>
+<pre><code>cd /path/to/android/root
+ddms
+</code></pre>
+<p>You should see a splufty debugging console.</p>
+<p>Now, in eclipse, you can attach to the emulator:</p>
+<ol>
+<li>
+<p>Run > Open Debug Dialog...</p>
+</li>
+<li>
+<p>Right-click "Remote Java Application", select "New".</p>
+</li>
+<li>
+<p>Pick a name, i.e. "android-debug" or anything you like.</p>
+</li>
+<li>
+<p>Set the "Project" to your project name.</p>
+</li>
+<li>
+<p>Keep the Host set to "localhost", but change Port to 8700.</p>
+</li>
+<li>
+<p>Click the "Debug" button and you should be all set.</p>
+</li>
+</ol>
+<p>Note that port 8700 is attached to whatever process is currently selected in the DDMS console, so you need to sure that DDMS has selected the process you want to debug.</p>
+<p>You may need to open the Debug perspective (next to the "Java" perspective icon in the upper-right, click the small "Open Perspective" icon and select "Debug"). Once you do, you should see a list of threads; if you select one and break it (by clicking the "pause" icon), it should show the stack trace, source file, and line where execution is at. Breakpoints and whatnot should all work.</p>
+<h2 id="bonus-material">Bonus material</h2>
+<p>Replace Ctrl with the Apple key on Mac.</p>
+<table>
+<thead>
+<tr>
+<th>shortcut</th>
+<th>function</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Ctrl-Shift-o</td>
+<td>Organize imports</td>
+</tr>
+<tr>
+<td>Ctrl-Shift-t</td>
+<td>load class by name</td>
+</tr>
+<tr>
+<td>Ctrl-Shift-r</td>
+<td>load non-class resource by name</td>
+</tr>
+<tr>
+<td>Ctrl-1</td>
+<td>quick fix</td>
+</tr>
+<tr>
+<td>Ctrl-e</td>
+<td>Recently viewed files</td>
+</tr>
+<tr>
+<td>Ctrl-space</td>
+<td>auto complete</td>
+</tr>
+<tr>
+<td>Shift-Alt-r</td>
+<td>refactor:rename</td>
+</tr>
+<tr>
+<td>Shift-Alt-v</td>
+<td>refactor:move</td>
+</tr>
+</tbody>
+</table>
+<h2 id="eclipse-is-not-working-correctly-what-should-i-do">Eclipse is not working correctly, what should I do?</h2>
+<p>Make sure:</p>
+<ul>
+<li>
+<p>You followed the instructions on this page precisely.</p>
+</li>
+<li>
+<p>Your Problems view doesn't show any errors.</p>
+</li>
+<li>
+<p>Your application respects the package/directory structure.</p>
+</li>
+</ul>
+<p>If you're still having problems, please contact one of the Android mailing lists or IRC channels.</p>
diff --git a/src/source/using-eclipse.md b/src/source/using-eclipse.md
deleted file mode 100644
index 803b2cc..0000000
--- a/src/source/using-eclipse.md
+++ /dev/null
@@ -1,191 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Using Eclipse #
-
-This document will help you set up the Eclipse IDE for Android platform development.
-
-*Note: if you are looking for information on how to use
-Eclipse to develop applications that run on Android, this is not the right
-page for you. You probably would find [the Eclipse page on
-developer.android.com](https://developer.android.com/sdk/eclipse-adt.html) more useful.*
-
-## Basic setup ##
-
-First, it's important to make sure the regular Android development system is set up.
-
- cd /path/to/android/root
- make
-
-**Important**: You will still be using `make` to build the files you will actually run (in the emulator or on a device). You will be using Eclipse to edit files and verify that they compile, but when you want to run something you will need to make sure files are saved in Eclipse and run `make` in a shell. The Eclipse build is just for error checking.
-
-Eclipse needs a list of directories to search for Java files. This is called the "Java Build Path" and can be set with the `.classpath` file. We have a sample version to start you off.
-
- cd /path/to/android/root
- cp development/ide/eclipse/.classpath .
- chmod u+w .classpath
-
-Now edit that copy of `.classpath`, if necessary.
-
-### Increase Eclipse's Memory Settings ###
-
-The Android project is large enough that Eclipse's Java VM sometimes runs out of memory while compiling it. Avoid this problem by editing the `eclipse.ini` file. On Apple OSX the eclipse.ini file is located at
-
- /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
-
-Memory-related defaults (as of Eclipse 3.4):
-
- -Xms40m
- -Xmx256m
- -XX:MaxPermSize=256m
-
-Recommended settings for Android development:
-
- -Xms128m
- -Xmx512m
- -XX:MaxPermSize=256m
-
-These settings set Eclipse's minimum Java heap size to 128MB, set the maximum Java heap size to 512MB, and keep the maximum permanent generation size at the default of 256MB.
-
-Now start Eclipse:
-
- eclipse
-
-Now create a project for Android development:
-
-1. If Eclipse asks you for a workspace location, choose the default.
-
-2. If you have a "Welcome" screen, close it to reveal the Java perspective.
-
-3. File > New > Java Project
-
-4. Pick a project name, "android" or anything you like.
-
-5. Select "Create project from existing source", enter the path to your Android root directory, and click Finish.
-
-6. Wait while it sets up the project. (You'll see a subtle progress meter in the lower right corner.)
-
-Once the project workspace is created, Eclipse should start building. In theory, it should build with no errors and you should be set to go. If necessary, uncheck and re-check Project Build Automatically to force a rebuild.
-
-*Note:* Eclipse sometimes likes to add an `import android.R` statement at the top of your files that use resources, especially when you ask eclipse to sort or otherwise manage imports. This will cause your make to break. Look out for these erroneous import statements and delete them.
-
-### When You Sync ###
-
-Every time you repo sync, or otherwise change files outside of Eclipse (especially the .classpath), you need to refresh Eclipse's view of things:
-
-1. Window > Show View > Navigator
-
-1. In the Navigator, right-click on the project name
-
-1. Click Refresh in the context menu
-
-### Adding Apps to the Build Path ###
-
-The default `.classpath` includes the source to the core system and a sample set of apps, but might not include the particular app you may want to work on. To add an app, you must add the app's source directory. To do this inside Eclipse:
-
-1. Project > Properties
-
-1. Select "Java Build Path" from the left-hand menu.
-
-1. Choose the "Source" tab.
-
-1. Click "Add Folder..."
-
-1. Add your app's `src` directory.
-
-1. Click OK.
-
-When you're done, the "source folder" path in the list should look like
-
- android/packages/apps/YOURAPP/src
-
-Depending on which app(s) you include, you may also need to include `othersrc/main/java` directories under `android/dalvik/libcore`. Do this if you find you cannot build with the default set.
-
-## Eclipse formatting ##
-
-You can import files in `development/ide/eclipse` to make Eclipse
-follow the Android style rules.
-
-1. Select Window > Preferences > Java > Code Style.
-
-1. Use Formatter > Import to import `android-formatting.xml`.
-
-1. Organize Imports > Import to import `android.importorder`.
-
-## Debugging the emulator with Eclipse ##
-
-You can also use eclipse to debug the emulator and step through code. First, start the emulator running:
-
- cd /path/to/android/root
- . build/envsetup.sh
- lunch 1
- make
- emulator
-
-If the emulator is running, you should see a picture of a phone.
-
-In another shell, start DDMS (the Dalvik debug manager):
-
- cd /path/to/android/root
- ddms
-
-You should see a splufty debugging console.
-
-Now, in eclipse, you can attach to the emulator:
-
-1. Run > Open Debug Dialog...
-
-1. Right-click "Remote Java Application", select "New".
-
-1. Pick a name, i.e. "android-debug" or anything you like.
-
-1. Set the "Project" to your project name.
-
-1. Keep the Host set to "localhost", but change Port to 8700.
-
-1. Click the "Debug" button and you should be all set.
-
-Note that port 8700 is attached to whatever process is currently selected in the DDMS console, so you need to sure that DDMS has selected the process you want to debug.
-
-You may need to open the Debug perspective (next to the "Java" perspective icon in the upper-right, click the small "Open Perspective" icon and select "Debug"). Once you do, you should see a list of threads; if you select one and break it (by clicking the "pause" icon), it should show the stack trace, source file, and line where execution is at. Breakpoints and whatnot should all work.
-
-## Bonus material ##
-
-Replace Ctrl with the Apple key on Mac.
-
-shortcut | function
--------------|-----------------
-Ctrl-Shift-o | Organize imports
-Ctrl-Shift-t | load class by name
-Ctrl-Shift-r | load non-class resource by name
-Ctrl-1 | quick fix
-Ctrl-e | Recently viewed files
-Ctrl-space | auto complete
-Shift-Alt-r | refactor:rename
-Shift-Alt-v | refactor:move
-
-## Eclipse is not working correctly, what should I do? ##
-
-Make sure:
-
-- You followed the instructions on this page precisely.
-
-- Your Problems view doesn't show any errors.
-
-- Your application respects the package/directory structure.
-
-If you're still having problems, please contact one of the Android mailing lists or IRC channels.
-
diff --git a/src/source/using-repo.jd b/src/source/using-repo.jd
new file mode 100644
index 0000000..7dfd38f
--- /dev/null
+++ b/src/source/using-repo.jd
@@ -0,0 +1,265 @@
+page.title=Repo command reference
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<p>Repo usage takes the following form: </p>
+<pre><code>repo COMMAND OPTIONS
+</code></pre>
+<p>Optional elements are shown in brackets [ ]. Once Repo is installed, you can get information about any command by running </p>
+<pre><code>repo help COMMAND
+</code></pre>
+<p>Many commands take a project list as an argument. You can specify project-list as a list of names or a list of paths to local source directories for the projects:</p>
+<pre><code>repo sync [PROJECT0 PROJECT1 ... PROJECTN]
+repo sync [/PATH/TO/PROJECT0 ... /PATH/TO/PROJECTN]
+</code></pre>
+
+<h2 id="init">init</h2>
+<pre><code>$ repo init -u URL [OPTIONS]
+</code></pre>
+<p>Installs Repo in the current directory. This creates a <code>.repo/</code> directory that contains Git repositories for the Repo source code and the standard Android manifest files. The <code>.repo/</code> directory also contains <code>manifest.xml</code>, which is a symlink to the selected manifest in the <code>.repo/manifests/</code> directory.</p>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-u</code>: specify a URL from which to retrieve a manifest repository. The common manifest can be found at <code>https://android.googlesource.com/platform/manifest</code></p>
+</li>
+<li>
+<p><code>-m</code>: select a manifest file within the repository. If no manifest name is selected, the default is default.xml. </p>
+</li>
+<li>
+<p><code>-b</code>: specify a revision, i.e., a particular manifest-branch.</p>
+</li>
+</ul>
+<p><em>Note: For all remaining Repo commands, the current working directory must either be the parent directory of <code>.repo/</code> or a subdirectory of the parent directory.</em></p>
+<h2 id="sync">sync</h2>
+<pre><code>repo sync [PROJECT_LIST]
+</code></pre>
+<p>Downloads new changes and updates the working files in your local environment. If you run <code>repo sync</code> without any arguments, it will synchronize the files for all the projects.</p>
+<p>When you run <code>repo sync</code>, this is what happens:</p>
+<ul>
+<li>
+<p>If the project has never been synchronized, then <code>repo sync</code> is equivalent to <code>git clone</code>. All branches in the remote repository are copied to the local project directory.</p>
+</li>
+<li>
+<p>If the project has already been synchronized once, then <code>repo sync</code> is equivalent to:</p>
+<pre><code>git remote update
+git rebase origin/BRANCH
+</code></pre>
+<p>where <code>BRANCH</code> is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.</p>
+</li>
+<li>
+<p>If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, <code>git rebase --continue</code>) to resolve the conflicts.</p>
+</li>
+</ul>
+<p>After a successful <code>repo sync</code>, the code in specified projects will be up to date with the code in the remote repository.</p>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-d</code>: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.</p>
+</li>
+<li>
+<p><code>-s</code>: sync to a known good build as specified by the manifest-server element in the current manifest.</p>
+</li>
+<li>
+<p><code>-f</code>: proceed with syncing other projects even if a project fails to sync.</p>
+</li>
+</ul>
+<h2 id="upload">upload</h2>
+<pre><code>repo upload [PROJECT_LIST]
+</code></pre>
+<p>For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.</p>
+<p>After you select one or more branches, all commits on the selected branches
+are transmitted to Gerrit over an HTTPS connection. You will need to
+configure an HTTPS password to enable upload authorization. Visit the
+<a href="https://android-review.googlesource.com/new-password">Password Generator</a>
+to generate a new username/password pair to use over HTTPS.</p>
+<p>When Gerrit receives the object data over its server, it will turn each
+commit into a change so that reviewers can comment on each commit
+individually. To combine several "checkpoint" commits together into a
+single commit, use git rebase -i before you run repo upload.</p>
+<p>If you run repo upload without any arguments, it will search all the projects for changes to upload.</p>
+<p>To make edits to changes after they have been uploaded, you should use a tool like <code>git rebase -i</code> or <code>git commit --amend</code> to update your local commits. After your edits are complete:</p>
+<ul>
+<li>
+<p>Make sure the updated branch is the currently checked out branch.</p>
+</li>
+<li>
+<p>Use <code>repo upload --replace PROJECT</code> to open the change matching editor.</p>
+</li>
+<li>
+<p>For each commit in the series, enter the Gerrit change ID inside the brackets:</p>
+<pre><code># Replacing from branch foo
+[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
+[ 2829 ] ec18b4ba Update proto client to support patch set replacments
+[ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
+# Insert change numbers in the brackets to add a new patch set.
+# To create a new change record, leave the brackets empty.
+</code></pre>
+</li>
+</ul>
+<p>After the upload is complete the changes will have an additional Patch Set.</p>
+<h2 id="diff">diff</h2>
+<pre><code>repo diff [PROJECT_LIST]
+</code></pre>
+<p>Shows outstanding changes between commit and working tree using <code>git diff</code>. </p>
+<h2 id="download">download</h2>
+<pre><code>repo download TARGET CHANGE
+</code></pre>
+<p>Downloads the specified change from the review system and makes it available in your project's local working directory.</p>
+<p>For example, to download <a href="https://android-review.googlesource.com/23823">change 23823</a> into your platform/frameworks/base directory:</p>
+<pre><code>$ repo download platform/build 23823
+</code></pre>
+<p>A <code>repo sync</code> should effectively remove any commits retrieved via <code>repo download</code>. Or, you can check out the remote branch; e.g., <code>git checkout m/master</code>.</p>
+<p>*Note: There is a slight mirroring lag between when a change is visible on
+the web in <a href="https://android-review.googlesource.com/">Gerrit</a> and when
+<code>repo download</code> will be able to find it for all users, because of replication
+delays to all servers worldwide.</p>
+<h2 id="forall">forall</h2>
+<pre><code>repo forall [PROJECT_LIST] -c COMMAND
+</code></pre>
+<p>Executes the given shell command in each project. The following additional environment variables are made available by <code>repo forall</code>:</p>
+<ul>
+<li>
+<p><code>REPO_PROJECT</code> is set to the unique name of the project.</p>
+</li>
+<li>
+<p><code>REPO_PATH</code> is the path relative to the root of the client.</p>
+</li>
+<li>
+<p><code>REPO_REMOTE</code> is the name of the remote sstem from the manifest.</p>
+</li>
+<li>
+<p><code>REPO_LREV</code> is the name of the revision from the manifest, translated to a local tracking branch. Used if you need to pass the manifest revision to a locally executed git command.</p>
+</li>
+<li>
+<p><code>REPO_RREV</code> is the name of the revision from the manifest, exactly as written in the manifest.</p>
+</li>
+</ul>
+<p>Options:</p>
+<ul>
+<li>
+<p><code>-c</code>: command and arguments to execute. The command is evaluated through <code>/bin/sh</code> and any arguments after it are passed through as shell positional parameters.</p>
+</li>
+<li>
+<p><code>-p</code>: show project headers before output of the specified command. This is achieved by binding pipes to the command's stdin, stdout, and sterr streams, and piping all output into a continuous stream that is displayed in a single pager session.</p>
+</li>
+<li>
+<p><code>-v</code>: show messages the command writes to stderr. </p>
+</li>
+</ul>
+<h2 id="prune">prune</h2>
+<pre><code>repo prune [PROJECT_LIST]
+</code></pre>
+<p>Prunes (deletes) topics that are already merged.</p>
+<h2 id="start">start</h2>
+<pre><code>repo start BRANCH_NAME [PROJECT_LIST]
+</code></pre>
+<p>Begins a new branch for development, starting from the revision specified in the manifest.</p>
+<p>The <code>BRANCH_NAME</code> argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.</p>
+<p>The <code>PROJECT_LIST</code> specifies which projects will participate in this topic branch. </p>
+<p><em>Note: "." is a useful shorthand for the project in the current working directory.</em></p>
+<h2 id="status">status</h2>
+<pre><code>repo status [PROJECT_LIST]
+</code></pre>
+<p>Compares the working tree to the staging area (index) and the most recent commit on this branch (HEAD) in each project specified. Displays a summary line for each file where there is a difference between these three states.</p>
+<p>To see the status for only the current branch, run <code>repo status</code>. The status information will be listed by project. For each file in the project, a two-letter code is used:</p>
+<p>In the first column, an uppercase letter indicates how the staging area differs from the last committed state.</p>
+<table>
+<thead>
+<tr>
+<th>letter</th>
+<th>meaning</th>
+<th>description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>-</td>
+<td>no change</td>
+<td>same in HEAD and index</td>
+</tr>
+<tr>
+<td>A</td>
+<td>added</td>
+<td>not in HEAD, in index</td>
+</tr>
+<tr>
+<td>M</td>
+<td>modified</td>
+<td>in HEAD, modified in index</td>
+</tr>
+<tr>
+<td>D</td>
+<td>deleted</td>
+<td>in HEAD, not in index</td>
+</tr>
+<tr>
+<td>R</td>
+<td>renamed</td>
+<td>not in HEAD, path changed in index</td>
+</tr>
+<tr>
+<td>C</td>
+<td>copied</td>
+<td>not in HEAD, copied from another in index</td>
+</tr>
+<tr>
+<td>T</td>
+<td>mode changed</td>
+<td>same content in HEAD and index, mode changed</td>
+</tr>
+<tr>
+<td>U</td>
+<td>unmerged</td>
+<td>conflict between HEAD and index; resolution required</td>
+</tr>
+</tbody>
+</table>
+<p>In the second column, a lowercase letter indicates how the working directory differs from the index.</p>
+<table>
+<thead>
+<tr>
+<th>letter</th>
+<th>meaning</th>
+<th>description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>-</td>
+<td>new/unknown</td>
+<td>not in index, in work tree</td>
+</tr>
+<tr>
+<td>m</td>
+<td>modified</td>
+<td>in index, in work tree, modified</td>
+</tr>
+<tr>
+<td>d</td>
+<td>deleted</td>
+<td>in index, not in work tree</td>
+</tr>
+</tbody>
+</table>
diff --git a/src/source/using-repo.md b/src/source/using-repo.md
deleted file mode 100644
index b62f693..0000000
--- a/src/source/using-repo.md
+++ /dev/null
@@ -1,217 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Repo command reference #
-
-Repo usage takes the following form:
-
- repo COMMAND OPTIONS
-
-Optional elements are shown in brackets [ ]. Once Repo is installed, you can get information about any command by running
-
- repo help COMMAND
-
-Many commands take a project list as an argument. You can specify project-list as a list of names or a list of paths to local source directories for the projects:
-
- repo sync [PROJECT0 PROJECT1 ... PROJECTN]
- repo sync [/PATH/TO/PROJECT0 ... /PATH/TO/PROJECTN]
-
-[TOC]
-
-## init ##
-
- $ repo init -u URL [OPTIONS]
-
-Installs Repo in the current directory. This creates a `.repo/` directory that contains Git repositories for the Repo source code and the standard Android manifest files. The `.repo/` directory also contains `manifest.xml`, which is a symlink to the selected manifest in the `.repo/manifests/` directory.
-
-Options:
-
-* `-u`: specify a URL from which to retrieve a manifest repository. The common manifest can be found at `https://android.googlesource.com/platform/manifest`
-
-* `-m`: select a manifest file within the repository. If no manifest name is selected, the default is default.xml.
-
-* `-b`: specify a revision, i.e., a particular manifest-branch.
-
-*Note: For all remaining Repo commands, the current working directory must either be the parent directory of `.repo/` or a subdirectory of the parent directory.*
-
-
-## sync ##
-
- repo sync [PROJECT_LIST]
-
-Downloads new changes and updates the working files in your local environment. If you run `repo sync` without any arguments, it will synchronize the files for all the projects.
-
-When you run `repo sync`, this is what happens:
-
-- If the project has never been synchronized, then `repo sync` is equivalent to `git clone`. All branches in the remote repository are copied to the local project directory.
-
-- If the project has already been synchronized once, then `repo sync` is equivalent to:
-
- git remote update
- git rebase origin/BRANCH
-
- where `BRANCH` is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.
-
-- If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, `git rebase --continue`) to resolve the conflicts.
-
-After a successful `repo sync`, the code in specified projects will be up to date with the code in the remote repository.
-
-Options:
-
-* `-d`: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.
-
-* `-s`: sync to a known good build as specified by the manifest-server element in the current manifest.
-
-* `-f`: proceed with syncing other projects even if a project fails to sync.
-
-
-## upload ##
-
- repo upload [PROJECT_LIST]
-
-For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.
-
-After you select one or more branches, all commits on the selected branches
-are transmitted to Gerrit over an HTTPS connection. You will need to
-configure an HTTPS password to enable upload authorization. Visit the
-[Password Generator](https://android-review.googlesource.com/new-password)
-to generate a new username/password pair to use over HTTPS.
-
-When Gerrit receives the object data over its server, it will turn each
-commit into a change so that reviewers can comment on each commit
-individually. To combine several "checkpoint" commits together into a
-single commit, use git rebase -i before you run repo upload.
-
-If you run repo upload without any arguments, it will search all the projects for changes to upload.
-
-To make edits to changes after they have been uploaded, you should use a tool like `git rebase -i` or `git commit --amend` to update your local commits. After your edits are complete:
-
-- Make sure the updated branch is the currently checked out branch.
-
-- Use `repo upload --replace PROJECT` to open the change matching editor.
-
-- For each commit in the series, enter the Gerrit change ID inside the brackets:
-
- # Replacing from branch foo
- [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
- [ 2829 ] ec18b4ba Update proto client to support patch set replacments
- [ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
- # Insert change numbers in the brackets to add a new patch set.
- # To create a new change record, leave the brackets empty.
-
-After the upload is complete the changes will have an additional Patch Set.
-
-
-## diff ##
-
- repo diff [PROJECT_LIST]
-
-Shows outstanding changes between commit and working tree using `git diff`.
-
-
-## download ##
-
- repo download TARGET CHANGE
-
-Downloads the specified change from the review system and makes it available in your project's local working directory.
-
-For example, to download [change 23823](https://android-review.googlesource.com/23823) into your platform/frameworks/base directory:
-
- $ repo download platform/build 23823
-
-A `repo sync` should effectively remove any commits retrieved via `repo download`. Or, you can check out the remote branch; e.g., `git checkout m/master`.
-
-*Note: There is a slight mirroring lag between when a change is visible on
-the web in [Gerrit](https://android-review.googlesource.com/) and when
-`repo download` will be able to find it for all users, because of replication
-delays to all servers worldwide.
-
-
-## forall ##
-
- repo forall [PROJECT_LIST] -c COMMAND
-
-Executes the given shell command in each project. The following additional environment variables are made available by `repo forall`:
-
-* `REPO_PROJECT` is set to the unique name of the project.
-
-* `REPO_PATH` is the path relative to the root of the client.
-
-* `REPO_REMOTE` is the name of the remote sstem from the manifest.
-
-* `REPO_LREV` is the name of the revision from the manifest, translated to a local tracking branch. Used if you need to pass the manifest revision to a locally executed git command.
-
-* `REPO_RREV` is the name of the revision from the manifest, exactly as written in the manifest.
-
-Options:
-
-* `-c`: command and arguments to execute. The command is evaluated through `/bin/sh` and any arguments after it are passed through as shell positional parameters.
-
-* `-p`: show project headers before output of the specified command. This is achieved by binding pipes to the command's stdin, stdout, and sterr streams, and piping all output into a continuous stream that is displayed in a single pager session.
-
-* `-v`: show messages the command writes to stderr.
-
-
-## prune ##
-
- repo prune [PROJECT_LIST]
-
-Prunes (deletes) topics that are already merged.
-
-
-## start ##
-
- repo start BRANCH_NAME [PROJECT_LIST]
-
-Begins a new branch for development, starting from the revision specified in the manifest.
-
-The `BRANCH_NAME` argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.
-
-The `PROJECT_LIST` specifies which projects will participate in this topic branch.
-
-*Note: "." is a useful shorthand for the project in the current working directory.*
-
-
-## status ##
-
- repo status [PROJECT_LIST]
-
-Compares the working tree to the staging area (index) and the most recent commit on this branch (HEAD) in each project specified. Displays a summary line for each file where there is a difference between these three states.
-
-To see the status for only the current branch, run `repo status`. The status information will be listed by project. For each file in the project, a two-letter code is used:
-
-In the first column, an uppercase letter indicates how the staging area differs from the last committed state.
-
-letter | meaning | description
--------|----------------|-------------------------
-- | no change | same in HEAD and index
-A | added | not in HEAD, in index
-M | modified | in HEAD, modified in index
-D | deleted | in HEAD, not in index
-R | renamed | not in HEAD, path changed in index
-C | copied | not in HEAD, copied from another in index
-T | mode changed | same content in HEAD and index, mode changed
-U | unmerged | conflict between HEAD and index; resolution required
-
-In the second column, a lowercase letter indicates how the working directory differs from the index.
-
-letter | meaning | description
--------|----------------|----------------------------
-- | new/unknown | not in index, in work tree
-m | modified | in index, in work tree, modified
-d | deleted | in index, not in work tree
-
-
diff --git a/src/source/version-control.html b/src/source/version-control.html
new file mode 100644
index 0000000..e85ebc2
--- /dev/null
+++ b/src/source/version-control.html
@@ -0,0 +1,7 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0;url=/source/developing.html" />
+</head>
+<body>
+</body>
+</html>
diff --git a/src/source/version-control.md b/src/source/version-control.md
deleted file mode 100644
index 302fb68..0000000
--- a/src/source/version-control.md
+++ /dev/null
@@ -1,187 +0,0 @@
-<!--
- Copyright 2010 The Android Open Source Project
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-# Version Control with Repo and Git #
-
-To work with the Android code, you will need to use both Git and Repo. In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however.
-
-**Git** is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits. One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.
-
-**Repo** is a repository management tool that we built on top of Git. Repo
-unifies the many Git repositories when necessary, does the uploads to our
-[revision control system](https://android-review.googlesource.com/), and
-automates parts of the Android development workflow. Repo is not meant to
-replace Git, only to make it easier to work with Git in the context of
-Android. The repo command is an executable Python script that you can put
-anywhere in your path. In working with the Android source files, you will
-use Repo for across-network operations. For example, with a single Repo
-command you can download files from multiple repositories into your local
-working directory.
-
-**Gerrit** is a web-based code review system for projects that use git. Gerrit encourages more centralized use of Git by allowing all authorized users to submit changes, which are automatically merged if they pass code review. In addition, Gerrit makes reviewing easier by displaying changes side by side in-browser and enabling inline comments.
-
-## Basic Workflow ##
-
-<div style="float:right">
- <img src="/images/submit-patches-0.png" alt="basic workflow diagram">
-</div>
-
-The basic pattern of interacting with the repositories is as follows:
-
-1. Use `repo start` to start a new topic branch.
-
-1. Edit the files.
-
-1. Use `git add` to stage changes.
-
-1. Use `git commit` to commit changes.
-
-1. Use `repo upload` to upload changes to the review server.
-
-# Task reference #
-
-The task list below shows a summary of how to do common Repo and Git tasks.
-For complete quick-start information and examples, see [Getting started](downloading.html).
-
-## Synchronizing your client ##
-
-To synchronize the files for all available projects:
-
- $ repo sync
-
-To synchronize the files for selected projects:
-
- $ repo sync PROJECT0 PROJECT1 PROJECT2 ...
-
-## Creating topic branches ##
-
-Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature. A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you can isolate one aspect of your work from the others. For an interesting article about using topic branches, see [Separating topic branches](http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt).
-<img src="/images/external-link.png" alt="">
-
-To start a topic branch using Repo:
-
- $ repo start BRANCH_NAME
-
-To verify that your new branch was created:
-
- $ repo status
-
-## Using topic branches ##
-
-To assign the branch to a particular project:
-
- $ repo start BRANCH_NAME PROJECT
-
-To switch to another branch that you have created in your local work environment:
-
- $ git checkout BRANCH_NAME
-
-To see a list of existing branches:
-
- $ git branch
-
-or
-
- $ repo branches
-
-The name of the current branch will be preceded by an asterisk.
-
-*Note: A bug might be causing `repo sync` to reset the local topic branch. If `git branch` shows \* (no branch) after you run `repo sync`, then run `git checkout` again.*
-
-## Staging files ##
-
-By default, Git notices but does not track the changes you make in a project. In order to tell git to preserve your changes, you must mark them for inclusion in a commit. This is also called "staging".
-
-You can stage your changes by running
-
- git add
-
-which accepts as arguments any files or directories within the project directory. Despite the name, `git add` does not simply add files to the git repository; it can also be used to stage file modifications and deletions.
-
-## Viewing client status ##
-
-To list the state of your files:
-
- $ repo status
-
-To see uncommitted edits:
-
- $ repo diff
-
-The `repo diff` command shows every local edit that you have made that would *not* go into the commit, if you were to commit right now. To see every edit that would go into the commit if you were to commit right now, you need a Git command, `git diff`. Before running it, be sure you are in the project directory:
-
- $ cd ~/WORKING_DIRECTORY/PROJECT
- $ git diff --cached
-
-## Committing changes ##
-
-A commit is the basic unit of revision control in git, consisting of a snapshot of directory structure and file contents for the entire project. Creating a commit in git is as simple as typing
-
- git commit
-
-You will be prompted for a commit message in your favorite editor; please provide a helpful message for any changes you submit to the AOSP. If you do not add a log message, the commit will be aborted.
-
-## Uploading changes to Gerrit ##
-
-Before uploading, update to the latest revisions:
-
- repo sync
-
-Next run
-
- repo upload
-
-This will list the changes you have committed and prompt you to select which branches to upload to the review server. If there is only one branch, you will see a simple `y/n` prompt.
-
-## Recovering sync conflicts ##
-
-If a `repo sync` shows sync conflicts:
-
-- View the files that are unmerged (status code = U).
-- Edit the conflict regions as necessary.
-- Change into the relevant project directory, run `git add` and `git commit` for the files in question, and then "rebase" the changes. For example:
-
- $ git add .
- $ git commit
- $ git rebase --continue
-
-- When the rebase is complete start the entire sync again:
-
- $ repo sync PROJECT0 PROJECT1 ... PROJECTN
-
-## Cleaning up your client files ##
-
-To update your local working directory after changes are merged in Gerrit:
-
- $ repo sync
-
-To safely remove stale topic branches:
-
- $ repo prune
-
-## Deleting a client ##
-
-Because all state information is stored in your client, you only need to delete the directory from your filesystem:
-
- $ rm -rf WORKING_DIRECTORY
-
-Deleting a client will *permanently delete* any changes you have not yet uploaded for review.
-
-# Git and Repo cheatsheet #
-
-<img src="/images/git-repo-1.png" alt="list of basic git and repo commands">
-
-
