Work-in-progress snapshot of the source.android.com (formerly PDK) site
refresh.
diff --git a/pdk/docs/source/building-dream.jd b/pdk/docs/source/building-dream.jd
new file mode 100644
index 0000000..71b4f58
--- /dev/null
+++ b/pdk/docs/source/building-dream.jd
@@ -0,0 +1,33 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Building For Dream</b>
+</h3>
+<div>The basic manifest for cupcake (and above) 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.<br><br>To build donut or master for dream (your device needs to be an ADP1 running an official 1.6 system):<br><ol><li>Follow the<a href="http://source.android.com/download">normal steps</a>
+to setup repo and check out the sources.
+</li>
+<li>At the root of your source tree, run ". build/envsetup.sh" like you normally would for an emulator build.
+</li>
+<li>Run "make adb" if you don't already have adb in your path.
+</li>
+<li>run "adb root".<br></li>
+<li>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.<br></li>
+<li>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).<br></li>
+<li>run make from the top of the source tree.
+</li>
+<li>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".<br></li>
+</ol>
+To build cupcake for dream (your device needs to be an ADP1 running an official 1.5 system):<br><ol><li>Follow the<a href="http://source.android.com/download">normal steps</a>
+to setup repo and check out the sources.
+</li>
+<li>At the root of your source tree, run ". build/envsetup.sh" like you normally would for an emulator build.
+</li>
+<li>Run "make adb" if you don't already have adb in your path.<br></li>
+<li>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.<br></li>
+<li>run "lunch htc_dream-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).<br></li>
+<li>run make from the top of the source tree.
+</li>
+<li>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".<br></li>
+</ol>
+* The Dream device software contains some proprietary binaries.For contractual reasons, these cannot be redistributed to be used directly with the Android Open-Source Project, but the provided script may be used to extract these binaries from your development device so that they can be correctly included in your build.These libraries include the openGL|ES library, the Qualcomm camera library, the HTC Radio Interface Library, etc.
+</div>
diff --git a/pdk/docs/source/cla-corporate.jd b/pdk/docs/source/cla-corporate.jd
new file mode 100644
index 0000000..5ddfe6f
--- /dev/null
+++ b/pdk/docs/source/cla-corporate.jd
@@ -0,0 +1,53 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Corporate Contributor License Grant - Android Open Source Project</b>
+</h3>
+<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.<br></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>
+</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><br>Please sign: __________________________________ Date: _______________<br><br><br><br>Title: _______________________________________________________________<br><br><br><br>Corporation: __________________________________________________________<br><br></pre>
+<h3>
+Schedule A</h3>
+[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]
+<h3>
+Schedule B</h3>
+[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]
+</div>
diff --git a/pdk/docs/source/cla-individual.jd b/pdk/docs/source/cla-individual.jd
new file mode 100644
index 0000000..1433318
--- /dev/null
+++ b/pdk/docs/source/cla-individual.jd
@@ -0,0 +1,46 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Individual Contributor License Grant - Android Open Source Project</b>
+</h3>
+<div><p><i>Please visit the<a href="https://review.source.android.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.</i>
+<br></p>
+<p><br></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.<br></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://review.source.android.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><br><br>Mailing Address: ______________________ Telephone: ___________________<br><br><br><br>_______________________________________ Facsimile: ___________________<br><br><br><br>_______________________________________ Country: ___________________<br><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>
+<p><br></p>
+<ol><li><p>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."
+</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>
+</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>
+</div>
diff --git a/pdk/docs/source/code-style.jd b/pdk/docs/source/code-style.jd
new file mode 100644
index 0000000..540ac99
--- /dev/null
+++ b/pdk/docs/source/code-style.jd
@@ -0,0 +1,438 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Code Style Guide</b>
+</h3>
+<div>
+<h1>Android Code Style Rules</h1>
+<p>The rules below are not guidelines or recommendations, but strict rules.<b>You may not disregard the rules we list below</b>
+except as approved on a need-to-use basis.
+</p>
+<p>Not all existing code follows these rules, but all new code is expected to.
+</p>
+<h1><a>Java Language Rules</a>
+</h1>
+<p>We follow standard Java coding conventions. We add a few rules:
+</p>
+<ol><li><a href="#exceptionsIgnore">Exceptions</a>
+: Never catch and ignore them without explanation.
+</li>
+<li><a href="#exceptionsAll">Exceptions</a>
+: do not catch generic Exception, except in library code at the root of the stack.
+</li>
+<li><a href="#finalizers">Finalizers</a>
+: generally don't use them.
+</li>
+<li><a href="#imports">Imports</a>
+: Fully qualify imports
+</li>
+</ol>
+<h1><a>Java Library Rules</a>
+</h1>
+<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>
+<h1><a>Java Style Rules</a>
+</h1>
+<p>Programs are much easier to maintain when all files have a consistent style. We follow the standard Java coding style, as defined by Sun in their<a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Code Conventions for the Java Programming Language</a>
+, with a few exceptions and additions. This style guide is comprehensive and detailed and is in common usage in the Java community.
+</p>
+<p>In addition, we enforce the following style rules:
+</p>
+<ol><li><a href="#javadoc">Comments/Javadoc</a>
+: write it; use standard style
+</li>
+<li><a href="#shortmethods">Short methods</a>
+: don't write giant methods
+</li>
+<li>Fields: should either be at the top of the file, or immediately before the methods that use them
+</li>
+<li><a href="#localvariables">Local variables</a>
+: limit the scope
+</li>
+<li><a href="#import_style">Imports</a>
+: android; third party alphabetical; java(x)
+</li>
+<li><a href="#indentation">Indentation</a>
+: 4 spaces, no tabs.
+</li>
+<li><a href="#linelen">Line length</a>
+: 100 columns
+</li>
+<li><a href="#field_names">Field names</a>
+: Non-public, non-static fields start with m. Static fields start s.
+</li>
+<li><a href="#braces">Braces</a>
+: Opening braces don't go on their own line.
+</li>
+<li><a href="#annotations">Annotations</a>
+: Use the standard annotations.
+</li>
+<li><a href="#acronyms">Acronyms are words</a>
+: Treat acronyms as words in names, yielding XmlHttpRequest, getUrl(), etc.
+</li>
+<li><a href="#todo">TODO style</a>
+: "TODO: write this description"
+</li>
+<li><a href="#consistency">Consistency</a>
+: Look at what's around you!
+</li>
+<li><a href="#logging">Logging</a>
+: Be careful with logging. It's expensive.
+</li>
+</ol>
+<h1><a>Javatests Style Rules</a>
+</h1>
+<ol><li><a href="#testmethodnames">Naming test methods</a>
+: testMethod_specificCase is ok
+</li>
+</ol>
+<hr><h2>
+Java Language Rules
+</h2>
+<h2><a>Exceptions: do not ignore</a>
+</h2>
+Sometimes it is tempting to write code that completely ignores an exception like this:
+<pre>void setServerPort(String value) {<br>try {<br>serverPort = Integer.parseInt(value);<br>} catch (NumberFormatException e) {<br>}<br>}<br><br></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>
+<blockquote>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.<br><div>-<a href="http://www.artima.com/intv/solid4.html">James Gosling</a>
+</div>
+</blockquote>
+<p>Acceptable alternatives (in order of preference) are:
+</p>
+<ul><li>Throw the exception up to the caller of your method.
+<pre>void setServerPort(String value) throws NumberFormatException {<br>serverPort = Integer.parseInt(value);<br>}<br><br></pre>
+</li>
+<li>Throw a new exception that's appropriate to your level of abstraction.
+<pre>void setServerPort(String value) throws ConfigurationException {<br>try {<br>serverPort = Integer.parseInt(value);<br>} catch (NumberFormatException e) {<br>throw new ConfigurationException("Port " + value + " is not valid.");<br>}<br><br></pre>
+</li>
+<li>Handle the error gracefully and substitute an appropriate value in the catch {} block.
+<pre>/** Set port. If value is not a valid number, 80 is substituted. */<br>void setServerPort(String value) {<br>try {<br>serverPort = Integer.parseInt(value);<br>} catch (NumberFormatException e) {<br>serverPort = 80; // default port for server<br>}<br></pre>
+</li>
+<li>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.
+<pre>/** Set port. If value is not a valid number, die. */<br>void setServerPort(String value) {<br>try {<br>serverPort = Integer.parseInt(value);<br>} catch (NumberFormatException e) {<br>throw new RuntimeException("port " + value " is invalid, ", e);<br>}<br></pre>
+Note that the original exception is passed to the constructor for RuntimeException. This wrapped exception paradigm is very useful but only works in Java 1.4. If your code must compile under Java 1.3, you will need to omit the exception that is the cause.<br><br></li>
+<li>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:
+<pre>/** If value is not a valid number, original port number is used. */<br>void setServerPort(String value) {<br>try {<br>serverPort = Integer.parseInt(value);<br>} catch (NumberFormatException e) {<br>// Method is documented to just ignore invalid user input.<br>// serverPort will just be unchanged.<br>}<br>}<br></pre>
+</li>
+</ul>
+<h2><a>Exceptions: do not catch generic Exception</a>
+</h2>
+Sometimes it is tempting to be lazy when catching exceptions and do something like this:
+<pre>try {<br>someComplicatedIOFunction(); // may throw IOException<br>someComplicatedParsingFunction(); // may throw ParsingException<br>someComplicatedSecurityFunction(); // may throw SecurityException<br>// phew, made it all the way<br>} catch (Exception e) { // I'll just catch all exceptions<br>handleError(); // with one generic handler!<br>}<br><br></pre>
+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>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>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>
+<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.
+</li>
+<li>Rethrow the exception. Many times you don't need to catch the exception at this level anyway, just let the method throw it.
+</li>
+</ul>
+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.
+<h2><a>Finalizers</a>
+</h2>
+<p><b>What it is</b>
+: Finalizers are a way to have a chunk of code executed when an object is garbage collected.
+</p>
+<p><b>Pros</b>
+: can be handy for doing cleanup, particularly of external resources.
+</p>
+<p><b>Cons</b>
+: there are no guarantees as to when a finalizer will be called, or even that it will be called at all.
+</p>
+<p><b>Decision</b>
+: 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>
+<p>The one exception is it is OK to write a finalizer if all it does is make calls to X.assertTrue().
+</p>
+<h2><a>Imports</a>
+</h2>
+<h3>
+Wildcards in imports
+</h3>
+<p><b>What it is</b>
+: When you want to use class Bar from package foo,there are two possible ways to import it:
+</p>
+<ol><li>import foo.*;
+</li>
+<li>import foo.Bar;
+</li>
+</ol>
+<p><b>Pros of #1</b>
+: Potentially reduces the number of import statements.
+</p>
+<p><b>Pros of #2</b>
+: Makes it obvious what classes are actually used. Makes code more readable for maintainers.
+</p>
+<p><b>Decision</b>
+:Use style #2 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.*).
+</p>
+<h2><a>Comments/Javadoc</a>
+</h2>
+<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>/*<br>* Copyright (C) 2007 The Android Open Source Project<br>*<br>* Licensed under the Apache License, Version 2.0 (the "License");<br>* you may not use this file except in compliance with the License.<br>* You may obtain a copy of the License at<br>*<br>* http://www.apache.org/licenses/LICENSE-2.0<br>*<br>* Unless required by applicable law or agreed to in writing, software<br>* distributed under the License is distributed on an "AS IS" BASIS,<br>* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.<br>* See the License for the specific language governing permissions and<br>* limitations under the License.<br>*/<br><br>package com.android.internal.foo;<br><br>import android.os.Blah;<br>import android.view.Yada;<br><br>import java.sql.ResultSet;<br>import java.sql.SQLException;<br><br>/**<br>* Does X and Y and provides an abstraction for Z.<br>*/<br>public class Foo {<br>...<br>}<br></pre>
+<p>Every class and nontrivial public method you write<b>must</b>
+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:
+</p>
+<pre>/** Returns the correctly rounded positive square root of a double value. */<br>static double sqrt(double a) {<br>}<br><br>/**<br>* Constructs a new String by converting the specified array of<br>* bytes using the platform's default character encoding.<br>*/<br>public String(byte[] bytes) {<br>}<br></pre>
+<p>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.
+</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>
+Android does not currently enforce a specific style for writing Javadoc comments, but you<b>should</b>
+follow the<a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">Sun Javadoc conventions</a>
+.
+<h2><a>Short methods</a>
+</h2>
+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.
+<h2><a>Local variables</a>
+</h2>
+The scope of local variables should be kept to a minimum (<i>Effective Java</i>
+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>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>// Instantiate class cl, which represents some sort of Set<br>Set s = null;<br>try {<br>s = (Set) cl.newInstance();<br>} catch(IllegalAccessException e) {<br>throw new IllegalArgumentException(cl + " not accessible");<br>} catch(InstantiationException e) {<br>throw new IllegalArgumentException(cl + " not instantiable");<br>}<br><br>// Exercise the set<br>s.addAll(Arrays.asList(args));<br></pre>
+<p>But even this case can be avoided by encapsulating the try-catch block in a method:
+</p>
+<pre>Set createSet(Class cl) {<br>// Instantiate class cl, which represents some sort of Set<br>try {<br>return (Set) cl.newInstance();<br>} catch(IllegalAccessException e) {<br>throw new IllegalArgumentException(cl + " not accessible");<br>} catch(InstantiationException e) {<br>throw new IllegalArgumentException(cl + " not instantiable");<br>}<br>}<br>...<br>// Exercise the set<br>Set s = createSet(cl);<br>s.addAll(Arrays.asList(args));<br></pre>
+Loop variables should be declared in the for statement itself unless there is a compelling reason to do otherwise:
+<pre>for (int i = 0; i n; i++) {<br>doSomething(i);<br>}<br><br>for (Iterator i = c.iterator(); i.hasNext(); ) {<br>doSomethingElse(i.next());<br>}<br><br><br></pre>
+<h2><a>Imports</a>
+</h2>
+The ordering of import statements is:Android importsImports from third parties (com, junit, net, org)<br>java and javax
+<p>To exactly match the IDE settings, the imports should be:
+</p>
+Alphabetical within each grouping.<br>Capital letters are considered to come before lower case letter (e.g. Z before a).There should be a blank line between each major grouping (android, com, junit, net, org, java, javax).
+<h4>
+Why?
+</h4>
+<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 javaguide and made the IDE's 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>The style chosen such that:
+</p>
+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 styleThe IDE's can follow the style
+<h3>
+What about static imports?
+</h3>
+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>Since most people consider this a low priority issue, just use your judgement and please be consistent.
+</p>
+
+<h2><a>Indentation</a>
+</h2>
+<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>Instrument i<br>= someLongExpression(that, wouldNotFit, on, one, line);</pre>
+and this is not correct:
+<pre>Instrument i<br>= someLongExpression(that, wouldNotFit, on, one, line);</pre>
+<h2><a>Field Names</a>
+</h2>
+<ul><li>Non-public, non-static field names start with m.
+</li>
+<li>Static field names start with s.
+</li>
+<li>Other fields start with a lower case letter.
+</li>
+<li>Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
+</li>
+</ul>
+<p>For example:
+</p>
+<pre>public class MyClass {<br>public static final int SOME_CONSTANT = 42;<br>public int publicField;<br>private static MyClass sSingleton;<br>int mPackagePrivate;<br>private int mPrivate;<br>protected int mProtected;<br>}</pre>
+<h2><a>Braces</a>
+</h2>
+<p>Braces do not go on their own line; they go on the same line as the code before them. So:
+</p>
+<pre>class MyClass {<br>int func() {<br>if (something) {<br>// ...<br>} else if (somethingElse) {<br>// ...<br>} else {<br>// ...<br>}<br>}<br>}<br></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>if (condition) {<br>body; // ok<br>}<br>if (condition) body; // ok</pre>
+<p>but this is still illegal:
+</p>
+<pre>if (condition)<br>body; // bad<br></pre>
+<h2><a>Line length</a>
+</h2>
+<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>
+<h2>
+Java 1.5 Annotations
+</h2>
+<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 1.5's are:
+</p>
+@DeprecatedThe @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<b>still</b>
+supposed to work.
+<p>If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.
+</p>
+@OverrideThe @Override annotation must be used whenever a method overrides the declaration or implementation from a super-class.
+<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>
+@SuppressWarningsThe @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<b>must</b>
+be used, so as to ensure that all warnings reflect actual problems in the code.
+<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>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics<br>@SuppressWarnings({"generic-cast"})<br>ListStringblix = Utility.rotate(blax);<br></pre>
+When a @SuppressWarnings annotation is required, the code should be refactored to isolate the software elements where the annotation applies.
+<h2><a>Acronyms in names</a>
+</h2>
+<p>Treat acronyms and abbreviations as words. The names are much more readable:
+</p>
+
+<table><tbody><tr><td>Good
+</td>
+<td>Bad
+</td>
+</tr>
+<tr><td>XmlHttpRequest</td>
+<td>XMLHTTPRequest
+</td>
+</tr>
+<tr><td>getCustomerId</td>
+<td>getCustomerID
+</td>
+</tr>
+</tbody>
+</table>
+
+<p>This style rule also applies when an acronym or abbreviation is the entire name:
+</p>
+
+<table><tbody><tr><td>Good
+</td>
+<td>Bad
+</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<i>Effective Java</i>
+Item 38 and<i>Java Puzzlers</i>
+Number 68.
+</p>
+<h2><a>TODO style</a>
+</h2>
+<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>// TODO: Remove this code after the UrlTable2 has been checked in.<br><br>// TODO: Change this to use a flag instead of a constant.</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>
+<h2>
+Consistency
+</h2>
+<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>
+<h2><a>Logging</a>
+</h2>
+<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><b>ERROR:</b>
+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.
+</li>
+<li><b>WARNING:</b>
+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.
+</li>
+<li><b>INFORMATIVE:</b>
+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.
+</li>
+<li><b>DEBUG:</b>
+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.
+</li>
+<li><b>VERBOSE:</b>
+This level of logging should be used for everything else. This level will only be logged on debug builds and should be surrounded by 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.
+</li>
+</ul>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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.
+</p>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+Logging that reports successes should never be used at levels higher than VERBOSE.
+</p>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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>
+<p><i>Note:</i>
+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.
+</p>
+<p><i>Note:</i>
+<b>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.</b>
+</p>
+<h2>
+Javatests Style Rules
+</h2>
+
+<h2><a>Naming test methods</a>
+</h2>
+<a>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.</a>
+<p><a>Example:</a>
+</p>
+<pre><a>testMethod_specificCase1 <br>testMethod_specificCase2</a>
+</pre>
+
+<pre><a>void testIsDistinguishable_protanopia() {<br>ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)<br>assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))<br>assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))<br>}</a>
+</pre>
+</div>
+</div>
+</div>
diff --git a/pdk/docs/source/documentation.jd b/pdk/docs/source/documentation.jd
new file mode 100644
index 0000000..8be5701
--- /dev/null
+++ b/pdk/docs/source/documentation.jd
@@ -0,0 +1,56 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Documentation</b>
+</h3>
+<div><p>
+ As this page grows, it will include resources for wireless operators and handset manufacturers as well as for platform developers.<br></p>
+<h3>
+Resources for platform developers
+ </h3>
+
+ Google I/O videos:<br><ul><li><a href="http://sites.google.com/site/io/an-introduction-to-android">Introduction to Android</a>
+<img src="{@docRoot}images/documentation-0.png">
+<br></li>
+<li><a href="http://sites.google.com/site/io/anatomy--physiology-of-an-android">Anatomy Physiology of an Android</a>
+<img src="{@docRoot}images/documentation-0.png">
+</li>
+<li><a href="http://sites.google.com/site/io/inside-the-android-application-framework">Inside the Android Application Framework</a>
+<img src="{@docRoot}images/documentation-0.png">
+</li>
+<li><a href="http://sites.google.com/site/io/dalvik-vm-internals">Dalvik VM Internals</a>
+<img src="{@docRoot}images/documentation-0.png">
+</li>
+</ul>
+
+ Getting started with the Android source code:<br><ul><li><a href="http://source.android.com/download">Get source</a>
+</li>
+<li><a href="http://source.android.com/submit-patches/code-style-guide">Code Style Guide</a>
+<br></li>
+</ul>
+
+ Repo and Git resources:<br><ul><li><a href="http://source.android.com/download/using-repo#TOC-Git-and-Repo-cheatsheet">Git and Repo cheat sheet</a>
+</li>
+<li><a href="http://source.android.com/download/using-repo">Using Repo and Git<br></a>
+</li>
+<li>
+ The<a href="http://book.git-scm.com/">Git Community Book</a>
+<img src="{@docRoot}images/documentation-0.png">
+maintained by Scott Chacon<br></li>
+<li><a href="http://git.or.cz/gitwiki/FrontPage">GitWiki</a>
+<img src="{@docRoot}images/documentation-0.png">
+</li>
+<li><a href="http://www.kernel.org/pub/software/scm/git/docs/">Git Manual Page</a>
+<img src="{@docRoot}images/documentation-0.png">
+</li>
+<li><a href="http://www.gitcasts.com/">GitCasts</a>
+<img src="{@docRoot}images/documentation-0.png">
+(Git how-to videos)
+ </li>
+</ul>
+
+ Documentation on specific tasks:<br><ul><li><a href="http://source.android.com/documentation/building-for-dream">Building for Dream</a>
+(Android Developer Phone 1)
+ </li>
+</ul>
+</div>
diff --git a/pdk/docs/source/download.jd b/pdk/docs/source/download.jd
new file mode 100644
index 0000000..9f67512
--- /dev/null
+++ b/pdk/docs/source/download.jd
@@ -0,0 +1,367 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><span><b>Get source</b>
+</span>
+</h3>
+<div><div><div><div><div><div><div><div><p><b>Contents</b>
+</p>
+<ol><li><a href="#TOC-What-s-in-the-source-"><b>1</b>
+What's in the source?</a>
+</li>
+<li><a href="#TOC-Setting-up-your-machine"><b>2</b>
+Setting up your machine</a>
+<ol><li><a href="#TOC-Linux"><b>2.1</b>
+Linux</a>
+<ol><li><a href="#TOC-Ubuntu-Linux-32-bit-x86-"><b>2.1.1</b>
+Ubuntu Linux (32-bit x86)</a>
+</li>
+<li><a href="#TOC-Ubuntu-Linux-64-bit-x86-"><b>2.1.2</b>
+Ubuntu Linux (64-bit x86)</a>
+</li>
+<li><a href="#TOC-Running-Linux-in-a-virtual-machine"><b>2.1.3</b>
+Running Linux in a virtual machine</a>
+</li>
+<li><a href="#TOC-Other-Linux"><b>2.1.4</b>
+Other Linux</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Mac-OS"><b>2.2</b>
+Mac OS</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Installing-Repo"><b>3</b>
+Installing Repo</a>
+</li>
+<li><a href="#TOC-Initializing-a-Repo-client"><b>4</b>
+Initializing a Repo client</a>
+</li>
+<li><a href="#TOC-Getting-the-files"><b>5</b>
+Getting the files</a>
+</li>
+<li><a href="#TOC-Verifying-Git-Tags"><b>6</b>
+Verifying Git Tags</a>
+</li>
+<li><a href="#TOC-Building-the-code"><b>7</b>
+Building the code</a>
+</li>
+<li><a href="#TOC-Using-an-IDE"><b>8</b>
+Using an IDE</a>
+</li>
+<li><a href="#TOC-Troubleshooting"><b>9</b>
+Troubleshooting</a>
+</li>
+<li><a href="#TOC-What-s-next-"><b>10</b>
+What's next?</a>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div><table><tbody><tr><td>For information about current problems and fixes, see <a href="http://source.android.com/known-issues">Known issues</a>
+.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div><br>This document 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.<br><br>Related reading:<br></div>
+<ul><li>For an overview of the entire code-review and code-update process, see <a href="http://source.android.com/submit-patches/workflow">Workflow</a>
+.</li>
+<li>For reference details about Repo, see <a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+.<br></li>
+</ul>
+<h2>
+What's in the source?</h2>
+<div>For a description of all the projects that make up the Android source code, see <a href="http://source.android.com/projects">Project layout</a>
+. To see snapshots and histories of the files available in the public Android repositories, visit the <a href="http://android.git.kernel.org/">GitWeb</a>
+web interface.</div>
+<div></div>
+<div>The source is approximentely 2.1GB in size.You will need 6GB free to complete the build.<br><br></div>
+<h2>
+Setting up your machine</h2>
+<div>To build the Android source files, you will need to use Linux or Mac OS. Building under Windows is not currently supported.</div>
+<div><br></div>
+<h3>
+Linux</h3>
+The Android build is routinely tested on recent versions of Ubuntu (6.06 and later), but reports of successes or failures on other distributions are welcome.<br><h4>
+Ubuntu Linux (32-bit x86)</h4>
+<div>To set up your Linux development environment, make sure you have the following:</div>
+<div><div><div><ul><li>Required Packages:</li>
+<ul><li>Git 1.5.4 or newer <span>and the GNU Privacy Guard.<br></span>
+</li>
+</ul>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div><div><div><div><ul><ul><li>JDK 5.0, update 12 or higher.Java 6 is not supported, because of incompatibilities with @Override.<br></li>
+</ul>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div><div><div><div><ul><ul><li><span>flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.6-dev (optional), build-essential, zip, curl.</span>
+</li>
+</ul>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<blockquote><span>$ sudo apt-get install</span>
+<span>git-core gnupg</span>
+<span>sun-java5-jdk</span>
+<span>flex bison gperf <span>libsdl-dev libesd0-dev</span>
+libwxgtk2.6-dev build-essential zip <span>curl libncurses5-dev zlib1g-dev <br></span>
+</span>
+</blockquote>
+<div><div><div><div><ul><li><span><span>You might also want Valgrind, a tool that will help you find memory leaks, stack corruption, array bounds overflows, etc.</span>
+</span>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<blockquote><div><span>$ sudo apt-get install valgrind <br></span>
+</div>
+</blockquote>
+<ul><li><span><span>Intrepid (</span>
+</span>
+8.10) users may need a newer version of libreadline:</li>
+</ul>
+<div>$ sudo apt-get install lib32readline5-dev <br></div>
+</div>
+<div><div><div><div><div><div><h4>
+Ubuntu Linux (64-bit x86)</h4>
+This has not been as well tested. Please send success or failure reports to <a href="mailto:android-porting@googlegroups.com">android-porting@googlegroups.com</a>
+.</div>
+<div><br></div>
+<div>The Android build requires a 32-bit build environment as well as some other tools:<br></div>
+<div><ul><li>Required Packages:</li>
+<ul><li>Git, JDK, flex, and the other packages as listed above in the i386 instructions:<span><br></span>
+</li>
+<li>JDK 5.0, update 12 or higher.Java 6 is not supported, because of incompatibilities with @Override.</li>
+<li>Pieces from the 32-bit cross-building environment</li>
+<li>X11 development <br></li>
+</ul>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<blockquote><span><span>$</span>
+sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl</span>
+sun-java5-jdk <span><span>zlib1g-dev</span>
+</span>
+gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev ia32-libs x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev</blockquote>
+<ul><li>Set the system to use the right version of java by default:<br><br>$sudo update-java-alternatives -sjava-1.5.0-sun <br></li>
+</ul>
+<ul><li>X11: Ubuntu doesn't have packages for the X11 libraries, but that can be worked around with the following command:<br><br>$ sudo ln -s /usr/lib32/libX11.so.6 /usr/lib32/libX11.so <br><br></li>
+</ul>
+<div><div><div><div><div><h4>
+Running Linux in a virtual machine</h4>
+If you are running Linux in a virtual machine, you will need at least 1.5GB of RAM and 10GB or more of disk space in order to build the Android tree.<br><h4>
+Other Linux</h4>
+<p>There's no reason why Android cannot be built on non-Ubuntu systems. Please send any success or failure reports to <a href="mailto:android-porting@googlegroups.com">android-porting@googlegroups.com</a>
+<span>. In general you will need:</span>
+</p>
+<ul><li>Python 2.4, which you can <a href="http://www.python.org/download/">download from python.org</a>.</li>
+<li>JDK 5.0, update 12 or higher, which you can <a href="http://java.sun.com/javase/downloads/">download from java.sun.com</a>. Java 6 is not supported, because of incompatibilities with @Override.</li>
+<li>Git 1.5.4 or newer. You can find it at <a href="http://git.or.cz/">http://git.or.cz/</a>.</li>
+</ul>
+<p>Anything missing from this list? Please let us know!</p>
+<h4>
+<span><br></span>
+</h4>
+</div>
+<div><h3>
+Mac OS <br></h3>
+</div>
+<div><p><span>Requirements:</span>
+</p>
+<ul><li><span>To build the Android files in a Mac OS environment, you need an Intel/x86 machine running MacOS 10.4 ("Tiger") or 10.5 ("Leopard"). At the moment MacOS 10.6 ("Snow Leopard") is not supported. The Android build system and tools do not support the obsolete PowerPC architecture.</span>
+</li>
+<li><span>Android must be built on a case-sensitive file system.<br></span>
+</li>
+<ul><li>We recommend that you build Android on a partition that has been formatted with the "Case-sensitive Journaled HFS+" file system:</li>
+<ul><li>A case-sensitive file system is required because the sources contain files that differ only in case.</li>
+<li>Journaled systems are more robust. (This is optional, but recommended.)</li>
+<li>HFS+ is required to successfully build Mac OS applications such as the Android Emulator for OS X.</li>
+</ul>
+<li>If you want to avoid partitioning/formatting your hard drive, you can use a case-sensitive disk image instead.</li>
+<ul><li>To create the image:<br><ul><li>launch /Applications/Utilities/Disk Utility</li>
+<li>select "New Image"</li>
+<li>size: 8 GB (this will work, but you can choose more if you want to)</li>
+<li>volume format: case sensitive, journaled</li>
+</ul>
+</li>
+<li>This will create a .dmg 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":<br><br><div># command to mount the android file image <br>function mountAndroid{ hdiutil attach ~/android.dmg-mountpoint /Volumes/android; }<br></div>
+<br>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.</li>
+</ul>
+</ul>
+</ul>
+<ul></ul>
+To set up your Mac OS development environment, follow these steps:<br><ol><li>Install the XCode version 2.4 or later from <a href="http://developer.apple.com/">http://developer.apple.com</a>. We recommend version 3.0 or newer.<br></li>
+<li>Install MacPorts. To do this:</li>
+<ol><li>Download the tar file from <a href="http://www.macports.org/">http://www.macports.org/</a> and untar the files.</li>
+<li>Run the following:<span><br>$ ./configure <br></span>
+<span>$</span>
+<span>make <br></span>
+<span>$</span>
+<span>sudo make install</span>
+</li>
+<li>Make sure that /opt/local/bin is in your path before /usr/bin. by running <br>$ echo $PATH <br>If you don't see /opt/local/bin, edit $HOME/.bash_profile and add the line <br>export PATH=/opt/local/bin:$PATH <br>(or the equivalent for other shells) after any other PATH-related lines.<span>To verify that your path is now correct, o</span>
+pen a new terminal and <span>run</span>
+echo $PATH <span>again</span>
+.</li>
+<li>Ask MacPorts to update itself:<br><span></span>
+<span>$</span>
+<span>sudo port selfupdate</span>
+<br></li>
+</ol>
+<li>Get the following packages from port:<br>$<span>POSIXLY_CORRECT=1</span>
+sudo port install gmake libsdl git-core gnupg <br><span>If using Mac OS 10.4, also install:<br>$<span>POSIXLY_CORRECT=1</span>
+sudo port install bison <br></span>
+</li>
+<li>Upgrade GNU make to 3.81 or later by running.Mac OS doesn't come with a recent enough version.<br>$ sudo ln -s gmake /opt/local/bin/make <br></li>
+<li>Set an appropriate per-process file descriptor limit. To do this, add the following lines to your <i><span>.bash_profile</span>
+</i>
+file:<br># set the number of open files to be 1024<br>ulimit -S -n 1024</li>
+</ol>
+</div>
+</div>
+</div>
+<div><br></div>
+<h2>
+Installing Repo <br></h2>
+<div><p>Repo is a tool that makes it easier to work with Git in the context of Android. For more information about Repo, see <a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+.<br></p>
+To install, initialize, and configure Repo, follow these steps:<br><br></div>
+<ol><li><span>Make sure you have a~/bindirectory in your home directory, and check to be sure that this bin directory is in your path:</span>
+<br>$ cd~<br><span><span>$ mkdir bin <br>$ echo $PATH <br></span>
+</span>
+</li>
+<li><span>Download thereposcript and make sure it is executable:</span>
+<br>$ curl http://android.git.kernel.org/repo~/bin/repo <div>$ chmod a+x ~/bin/repo</div>
+</li>
+</ol>
+</div>
+<div><p><br></p>
+<h2>
+Initializing a Repo client <br></h2>
+</div>
+<div><ol><li><span>Create an empty directory to hold your working files:</span>
+<span><br></span>
+<span>$ mkdir mydroid</span>
+<br><span>$ cd mydroid</span>
+<br></li>
+<li><span>Runrepo initto bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest:</span>
+<br><span>$ repo init</span>
+-u git://android.git.kernel.org/platform/manifest.git</li>
+<ul><li><span>If you would like to check out a branch other than "master", specify it with -b, like:</span>
+<br><span>$ repo init</span>
+-u git://android.git.kernel.org/platform/manifest.git -b cupcake <br></li>
+</ul>
+<li><span>When prompted, configure Repo with your real name and email address. If you plan to submit code, use an email address that is associated with a <a href="https://www.google.com/accounts">Google account</a>
+.</span>
+<br></li>
+</ol>
+<span><span>A successful initialization will end with a message such as</span>
+<br><span>repo</span>
+initialized in /mydroid</span>
+<br><span><span><br>Your client directory should now contain a.repodirectory where files such as the manifest will be kept.</span>
+<br><br></span>
+<span><span><b>What will my name and email be used for?</b>
+<br></span>
+<span><br>To use the Gerrit code-review tool,</span>
+<span>you will need an email address that is connected with a <a href="http://www.google.com/accounts">registered Google account</a>
+(which does not have to be a Gmail address). Make sure this is</span>
+<span>a live address</span>
+<span>at which you can receive messages</span>
+<span>.</span>
+<span>The real name that you provide here will show up in attributions for your code submissions.</span>
+</span>
+<br></div>
+<span><p><b>What is a manifest file?</b>
+</p>
+<p><span>The Android source files are divided among a number of different repositories.</span>
+<span>A manifest</span>
+<span>file contains a mapping of where the files from these repositories will be placed within your working directory w</span>
+<span>hen you synchronize your files.<br></span>
+</p>
+<p><span><br></span>
+</p>
+</span>
+<h2>
+Getting the files</h2>
+<div><span><span>To pull down files to your working directory from the repositories as specified in the default manifest, run</span>
+<br><br>$ repo sync <i><br></i>
+<br><span>For more aboutrepo syncand other Repo commands, see</span>
+<a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+<span>.</span>
+<br><br><span>The Android source files will be located in your working directory under their <a href="http://source.android.com/projects">project</a>
+names.</span>
+</span>
+<br></div>
+<span><h2>
+<br></h2>
+<h2>
+Verifying Git Tags</h2>
+<span>Load the following public key into your GnuPG key database.The key is used to sign annotated tags that represent releases.</span>
+<br><br></span>
+<span>$ gpg --import <br><br></span>
+<span><span>then paste the key(s) below, and press Control-D to end the input and process the keys.</span>
+After importing the keys, you can verify any tag with <br><br></span>
+<span>$ git tag -v <i>tagname</i>
+</span>
+<span><br><br><b><u>key 9AB10E78: "The Android Open Source Projectinitial-contribution@android.com"</u>
+</b>
+<br></span>
+<pre>-----BEGIN PGP PUBLIC KEY BLOCK-----<br>Version: GnuPG v1.4.2.2 (GNU/Linux)<br><br>mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV <br>lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7<br>8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD <br>u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z <br>wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq <br>/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5<br>jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4<br>MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9<br>b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv <br>aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k <br>cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX <br>gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI <br>2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl <br>QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up <br>hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk <br>C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX <br>LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+<br>OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M <br>pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s <br>KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb <br>N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA <br>vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo <br>G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ <br>hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l <br>EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=<br>=Wi5D <br>-----END PGP PUBLIC KEY BLOCK-----<br></pre>
+<span><br><h2>
+Building the code</h2>
+<span>To build the files, runmakefrom within your working directory:</span>
+<br><span>$ cd ~/mydroid</span>
+<span><br>$ make</span>
+<br></span>
+<p>If your build fails, complaining about a missing "run-java-tool", try setting the ANDROID_JAVA_HOME env var to $JAVA_HOME before making.E.g.,</p>
+<p>$ export ANDROID_JAVA_HOME=$JAVA_HOME</p>
+<h2>
+Using an IDE</h2>
+<ul><li><a href="http://source.android.com/using-eclipse">Using Eclipse</a>
+for Android platform development <br></li>
+</ul>
+<h2>
+Troubleshooting</h2>
+<p><span><b>ImportError: No module na</b>
+<span><b>med</b>
+</span>
+<span><b>readline</b>
+</span>
+<b><br></b>
+</span>
+</p>
+<p><span>Mac users getting this should install Python 2.5.2.</span>
+</p>
+<p><span>Linux users that installed Python from source, make sure the dependencies for libreadline are installed, and rebuild Python.</span>
+</p>
+<span><h2>
+What's next?</h2>
+</span>
+<span>To learn about reporting an issue and searching previously reported issues,</span>
+<span>see</span>
+<a href="http://source.android.com/report-bugs">Report bugs</a>
+<span>.</span>
+<span>For information about editing the files and uploading changes to the code-review server, see <a href="http://source.android.com/submit-patches">Contribute</a>
+.</span>
+</div>
+</div>
+</div>
+</div>
diff --git a/pdk/docs/source/git-repo.jd b/pdk/docs/source/git-repo.jd
new file mode 100644
index 0000000..cc99626
--- /dev/null
+++ b/pdk/docs/source/git-repo.jd
@@ -0,0 +1,374 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Using Repo and Git</b>
+</h3>
+<div><div><div><div><div><div><p><b>Contents</b>
+</p>
+<ol><li><a href="#TOC-About-Git"><b>1</b>
+About Git</a>
+<ol><li><a href="#TOC-Why-Git-"><b>1.1</b>
+Why Git?</a>
+</li>
+<li><a href="#TOC-Already-a-Git-user-"><b>1.2</b>
+Already a Git user?</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Task-reference"><b>2</b>
+Task reference</a>
+<ol><li><a href="#TOC-Installing-Repo"><b>2.1</b>
+Installing Repo</a>
+</li>
+<li><a href="#TOC-Synchronizing-your-client"><b>2.2</b>
+Synchronizing your client</a>
+</li>
+<li><a href="#TOC-Why-use-topic-branches-"><b>2.3</b>
+Why use topic branches?</a>
+</li>
+<li><a href="#TOC-Creating-topic-branches"><b>2.4</b>
+Creating topic branches</a>
+</li>
+<li><a href="#TOC-Using-topic-branches"><b>2.5</b>
+Using topic branches</a>
+</li>
+<li><a href="#TOC-Viewing-client-status"><b>2.6</b>
+Viewing client status</a>
+</li>
+<li><a href="#TOC-Recovering-sync-conflicts"><b>2.7</b>
+Recovering sync conflicts</a>
+</li>
+<li><a href="#TOC-Cleaning-up-your-client-files"><b>2.8</b>
+Cleaning up your client files</a>
+</li>
+<li><a href="#TOC-Deleting-a-client"><b>2.9</b>
+Deleting a client</a>
+</li>
+<li><a href="#TOC-Scripting-common-tasks"><b>2.10</b>
+Scripting common tasks</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Repo-command-reference"><b>3</b>
+Repo command reference</a>
+<ol><li><a href="#TOC-init"><b>3.1</b>
+init</a>
+</li>
+<li><a href="#TOC-sync"><b>3.2</b>
+sync</a>
+</li>
+<li><a href="#TOC-upload"><b>3.3</b>
+upload</a>
+</li>
+<li><a href="#TOC-diff"><b>3.4</b>
+diff</a>
+</li>
+<li><a href="#TOC-download"><b>3.5</b>
+download</a>
+</li>
+<li><a href="#TOC-forall"><b>3.6</b>
+forall</a>
+</li>
+<li><a href="#TOC-help"><b>3.7</b>
+help</a>
+</li>
+<li><a href="#TOC-prune"><b>3.8</b>
+prune</a>
+</li>
+<li><a href="#TOC-start"><b>3.9</b>
+start</a>
+</li>
+<li><a href="#TOC-status"><b>3.10</b>
+status</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Git-and-Repo-cheatsheet"><b>4</b>
+Git and Repo cheatsheet</a>
+</li>
+<li><a href="#TOC-Terminology"><b>5</b>
+Terminology</a>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<p>To work with the Android code, you will need to use both Git and Repo.<br></p>
+<ul><li><i>Git</i>
+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.<br><br></li>
+<li><i>Repo</i>
+is a tool that we built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our<a href="http://review.source.android.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 repocommand is an executable Python script that you can put anywhere in your path.<i><br><br></i>
+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.
+</li>
+</ul>
+<h2>
+About Git
+</h2>
+<h3>
+Why Git?
+</h3>
+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.<br><h3>
+Already a Git user?
+</h3>
+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. For more information about Git, see the list of resources on our<a href="http://sites.google.com/a/android.com/opensource/documentation">Documentation</a>
+page.<br></div>
+<div><div><h2>
+Task reference<br></h2>
+The task list below shows a summary of how to do common Repo and Git tasks. For complete quick-start information and examples, see<a href="http://sites.google.com/a/android.com/opensource/download">Get source</a>
+.
+<h3>
+Installing Repo<br></h3>
+$ curl http://android.git.kernel.org/repo ~/bin/repo<div>$ chmod a+x ~/bin/repo</div>
+$ mkdir<i>working-directory-name</i>
+<br>$ cd<i>working-directory-name<br></i>
+$ repo init-u git://android.git.kernel.org/platform/manifest.git<br><br><h3>
+Synchronizing your client
+</h3>
+To synchronize the files for all available<a href="http://sites.google.com/a/android.com/opensource/projects">projects</a>
+:<br>$ repo sync<br><br>To synchronize the files for selected projects:<br>$ repo sync<i>project1 project2 ...</i>
+<i><br></i>
+<br><h3>
+Why use topic branches?
+</h3>
+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.<br><br>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 canisolateone 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>
+.
+<div><img src="{@docRoot}images/git-repo-0.png">
+</div>
+<br><br><h3>
+Creating topic branches
+</h3>
+To start a topic branch using Repo:<br>$ repo start<i>branchname</i>
+<br><br>To verify that your new branch was created:<br>$ repo status<br><br><h3>
+Using topic branches
+</h3>
+To assign the branch to a particular project:<br>$ repo start<i>branch</i>
+<i>name project</i>
+<br><br>To switch back and forth among branches that you have created in your local work environment:<br>$ git checkout<i>branchname</i>
+<br><br>To see a list of existing branches:<br>$ git branch<br>or...<br>$ repo branches<br><br>The name of the current branch will be preceded by an asterisk.<br><br></div>
+<div><i><b>Note:</b>
+<br></i>
+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 checkoutagain.<br></div>
+<div><br><h3>
+Viewing client status
+</h3>
+To list the state of your files:<br>$ repo status<br><br>To see uncommitted edits:<br>$ repo diff<br><br>Therepo diffcommand shows every local edit that you have made that would<i>not</i>
+go into the commit, if you were to commit right now.<br><br>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 down in the project directory:<br>$ cd ~/<i>workingdirectory</i>
+/<i>project</i>
+<br>$ git diff --cached<br><br><h3>
+Recovering sync conflicts
+</h3>
+If a repo sync shows sync conflicts:<br><ol><li>View the files that are unmerged (status code = U).
+</li>
+<li>Edit the conflict regions as necessary.
+</li>
+<li>Change into the relevant project directory, run git add and git commit for the files in question, and then "rebase" the changes. For example:<br>$ cd bionic<br>$ git add bionic/*<br>$ git commit<br>$ git rebase --continue<br><br></li>
+<li>When the rebase is complete start the entire sync again:<br>$ repo syncbionic<i>proj2</i>
+<i>proj3</i>
+<i>...</i>
+
+<i>projN</i>
+<br></li>
+</ol>
+<h3>
+Cleaning up your client files<br></h3>
+To update your local working directory after changes are merged in Gerrit:<br>$repo sync<br><br>To safely remove stale topic branches:<br>$ repo prune<br><br><h3>
+Deleting a client
+</h3>
+Deleting a client will<b>permanently delete</b>
+any changes you have not yet uploaded for review.Becauseall state information is stored in your client, you only need to delete the directory from your filesystem:<br><br>$ cd<i>~</i>
+<br>$ rm -rf<i>working-directory-name</i>
+<br><br><h3>
+Scripting common tasks
+</h3>
+You can use Repo to run the same program across all projects:<br><br>$ repo forall[<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]-c '<i>echo $REPO_PROJECT $@</i>
+'[<i>arg1</i>
+<i>arg2</i>
+<i>...</i>
+
+<i>argN</i>
+]<br><br>The -c argument is evaluated through /bin/sh and any arguments after it are passed through as shell positional parameters.<br><br><h2>
+Repo command reference
+</h2>
+Repo usage takes the following form:<br>repo<i>command options</i>
+<br><br>Optional elements are shown in brackets[ ]. Once Repo is installed, you can get information about any command by running<br>repo help<i>command</i>
+<br><br><h3>
+init
+</h3>
+repo init -u<i>url</i>
+[<i>options</i>
+]<br><br><div>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 containsmanifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.<br><br>The -u argument specifies a URL from which to retrieve a manifest repository. For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git<br><br>To select a manifest file within the repository, use the -m option. (If no manifest name is selected, the default is default.xml.)For example:<br>$ repo init -ugit://android.git.kernel.org/platform/manifest.git-m dalkvik-plus.xml<br><br>To specify a revision, that is, a particular manifest-branch, use the -b option. For example:<br>$ repo init -ugit://android.git.kernel.org/platform/manifest.git-b release-1.0<br><br>To see other repo init options, run<br>$ repo help init<br><br><b>Note:</b>
+For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.<br><br></div>
+<h3>
+sync
+</h3>
+repo sync [<i>project-list</i>
+]<br><br><div>Downloads new changes and updates the working files in your local environment. After a successful repo sync, the code in specified projects will be up to date with the code in the remote repository.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo sync [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br><br>If you run repo sync without any arguments, it will synchronize the files for all the projects.<br><br></div>
+<p><b>How Repo synchronization works</b>
+<br></p>
+<div>When you run repo sync, this is what happens:<br></div>
+<ol><li>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.
+</li>
+<li>If the project has already been synchronized once, then repo sync is equivalent to:<br>git remote update<br>git rebase origin/<i>branch</i>
+<br>where<i>branch</i>
+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.<br><br>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.<br></li>
+</ol>
+<div>The repo sync command also updates the private repositories in the .repo/ directory.<br></div>
+<br><h3>
+upload
+</h3>
+repo upload [<i>project-list</i>
+]<br><br><div>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.<br><br>After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization.Visit<a href="http://review.source.android.com/Gerrit#settings,ssh-keys">SSH Keys</a>
+within the user settings panel to register your public keys with Gerrit.To enable password-less uploads, consider using ssh-agent on your client system.<br><br>When Gerrit receives the object data over its SSH server, it will turn each commit into a change so that reviewers can comment on each commit individually.<br><br>To combine several "checkpoint" commits together into a single commit, use git rebase -i before you run repo upload.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo upload [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br><br>If you run repo upload without any arguments, it will search all the projects for changes to upload.<br><br>To make edits to changes after they have been uploaded, you should use a tool likegit rebase -ior git commit --amend to update your local commits.<br><br>After your edits are complete:<br></div>
+<div><ol><li>Make sure the updated branch is the currently checked out branch.
+</li>
+<li>Use repo upload --replace<i>proj1</i>
+to open the change matching editor.
+</li>
+<li>For each commit in the series, enter the Gerrit change Id inside the brackets:<br></li>
+</ol>
+</div>
+<div># Replacing from branch foo<br>[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...<br>[ 2829 ] ec18b4ba Update proto client to support patch set replacments<br>[ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...<br># Insert change numbers in the brackets to add a new patch set.<br># To create a new change record, leave the brackets empty.<br><br>After the upload is complete the changes will have an additional Patch Set (e.g. Patch Set 2, Patch Set 3, ...).<br></div>
+<br><h3>
+diff
+</h3>
+repo diff [<i>project-list</i>
+]<br><br><div>Shows changes between commit and working tree.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo diff [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br><br>Options:<br>-h, --helpmeans show this help message and exit.<br></div>
+<br><h3>
+download<br></h3>
+repo download<i>target</i>
+<i>change</i>
+<br><br><div>Downloads the specified change into the specified local directory. (Added to Repo as of version 1.0.4.)<br><br>For example, to download<a href="http://review.source.android.com/1241">change 1241</a>
+into your platform/frameworks/base directory:<br>$ repo download platform/frameworks/base 1241<br><br>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".<br><br><b>Note:</b>
+As of Jan. 26, 2009, there is a mirroring lag of approximately 5 minutes between when a change is visible on the web in<a href="http://review.source.android.com/">Gerrit</a>
+and when repo download will be able to find it, because changes are actually downloaded off the git://android.git.kernel.org/ mirror farm. There will always be a slight mirroring lag as Gerrit pushes newly uploaded changes out to the mirror farm.
+</div>
+<br><h3>
+forall
+</h3>
+repo forall [<i>project-list</i>
+] -c<i>command</i>
+[<i>arg.</i>
+..]<br><br><div>Runs a shell command in each project.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects<br></div>
+<br><h3>
+help
+</h3>
+repo help [<i>command</i>
+]<br><br><div>Displays detailed help about a command.<br></div>
+<br><h3>
+prune<br></h3>
+repo prune [<i>project-list</i>
+]<br><br><div>Prunes (deletes) topics that are already merged.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo prune [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br></div>
+<br><h3>
+start
+</h3>
+repo start<i>newbranchname</i>
+[<i>project-list</i>
+]<br><br><div>Starts a new branch for development.<br><br>The<i>newbranchname</i>
+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.<br><br>The<i>project-list</i>
+specifies which projects will participate in this topic branch. You can specify project-list as a list of names or a list of paths to local working directories for the projects:<br>repo start default [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br><br>"." is a useful shorthand for the project in the current working directory.<br></div>
+<br><h3>
+status
+</h3>
+repo status [<i>project-list</i>
+]<br><br><div>Shows the status of the current working directory. You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo status [<i>proj1</i>
+<i>proj2</i>
+<i>...</i>
+
+<i>projN</i>
+]<br><br>To see the status for only the current branch, run<br>repo status .<br><br>The status information will be listed by project. For each file in the project, a two-letter code is used:<br></div>
+<div><ul><li>In the left-most column, an uppercase letter indicates what is happening in the index (the staged files) when compared to the last committed state.<br><br></li>
+<li>In the next column, a lowercase letter indicates what is happening in the working directory when compared to the index (what is staged).
+</li>
+</ul>
+<table><tbody><tr><td><b>Character</b>
+</td>
+<td><b>Meaning</b>
+</td>
+</tr>
+<tr><td>A
+</td>
+<td>The file is added (brand new). Can only appear in the first column.<br></td>
+</tr>
+<tr><td>M or m<br></td>
+<td>The file already exists but has been modified in some way.
+</td>
+</tr>
+<tr><td>D or d<br></td>
+<td>The file has been deleted.<br></td>
+</tr>
+<tr><td>R
+</td>
+<td>The file has been renamed. Can only appear in the first column. The new name is also shown on the line.</td>
+</tr>
+<tr><td>C
+</td>
+<td>The file has been copied from another file. Can only appear in the first column. The source is also shown.
+</td>
+</tr>
+<tr><td>T
+</td>
+<td>Only the file's mode (executable or not) has been changed. Can only appear in the first column.
+</td>
+</tr>
+<tr><td>U
+</td>
+<td>The file has merge conflicts and is still unmerged. Can only appear in the first column.
+</td>
+</tr>
+<tr><td>-
+</td>
+<td>The file state is unmodified. A hyphen in<i>both</i>
+columns means this is a new file, unknown to Git. After you run git add on this file, repo status will show A-, indicating the file has been added.<br></td>
+</tr>
+</tbody>
+</table>
+<br>For example, if you edit the file main.py within the appeng project without staging the changes, then repo status might show<br><br>project appeng/<br>-mmain.py<br><br>If you go on to stage the changes to main.py by running git add, then repo status might show<br><br>project appeng/<br>M- main.py<br><br>If you then make further edits to the already-staged main.py and make edits to another file within the project, app.yaml, then repo status might show<br><br>project appeng/<br>-mapp.yaml<br>Mm main.py<br><br></div>
+<h2>
+Git and Repo cheatsheet
+</h2>
+Click on the cheatsheet to open it in a new window for easier printing.
+
+<div><img src="{@docRoot}images/git-repo-1.png">
+</div>
+<h2>
+<b>Terminology</b>
+</h2>
+<i>Staged</i>
+<i>changes</i>
+<br>Changes marked by git add for inclusion in the next commit's snapshot.<br><br><i>Commit<br></i>
+At intervals, you use git commit to save a snapshot of the staged files and a log message that describes the change.<br><br><i>Manifest</i>
+<br>A manifest file that contains a list of repositories and a mapping of where the files from these repositories will be located within your working directory. When you synchronize your files, the files contained in the repositories that are listed in the manifest will be pulled into your working directory.</div>
+</div>
+</div>
diff --git a/pdk/docs/source/index.jd b/pdk/docs/source/index.jd
new file mode 100644
index 0000000..6c27bdb
--- /dev/null
+++ b/pdk/docs/source/index.jd
@@ -0,0 +1,33 @@
+page.title=Get Involved
+doc.type=source
+@jd:body
+<div>
+<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 <a href="{@docRoot}about/philosophy.html">Our
+Philosophy</a>.</p>
+
+<h2>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="{@docRoot}source/report-bugs.html">Reporting Bugs</a> page.</p>
+<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="{@docRoot}source/life-of-a-bug.html">Life of a Bug</a>.</p>
+
+<h2>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 our sister site, <a
+href="http://developer.android.com/">developer.android.com</a>.</p>
+
+<h2>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.</p>
+<p>You can get started with by learning about the <a
+href="{@docRoot}source/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. If you need help along the way, you can join our <a
+href="{@docRoot}community/index.html">discussion groups.</a></p>
+</div>
diff --git a/pdk/docs/source/licenses.jd b/pdk/docs/source/licenses.jd
new file mode 100644
index 0000000..f1f646b
--- /dev/null
+++ b/pdk/docs/source/licenses.jd
@@ -0,0 +1,87 @@
+page.title=Licenses
+doc.type=source
+@jd:body
+<div>
+<p>The Android Open Source Project uses a few <a
+href="http://www.opensource.org/">open source initiative</a> approved open
+source licenses to enable availability of source code and to accept
+contributions from individuals and corporations.</p>
+<h2>Android Open Source Project license</h2>
+<p>The preferred license for the Android Open Source Project is <a
+href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a>. Apache 2.0
+is a commercial and open source friendly open source license. The majority of
+the Android platform is licensed under the<a
+href="http://www.apache.org/licenses/">Apache 2.0 license</a>. 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>Contributor License Grants</h2>
+<p>All <b>individual</b> 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="{@docRoot}source/cla-individual.html">Individual
+Contributor License Grant</a>. The grant can be executed online through the <a
+href="http://review.source.android.com/Gerrit#settings,agreements">code review
+tool</a>. The agreement clearly defines the terms under which intellectual
+property has been contributed to the Android Open Source Project.This license
+is for your protection as a contributor as well as the protection of the
+project; it does not change your rights to use your own contributions for any
+other purpose.</p>
+<p>For a <b>corporation</b> (or other entity) that has assigned employees to
+work on the Android Open Source Project, a <a
+href="{@docRoot}source/cla-corporate.html">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 <b><i>not</i></b> 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>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>
+<ol>
+<li>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.)</li>
+<li>LGPL requires allowance of customer modification and reverse
+engineering for debugging those modifications. Most app producers do
+want to have to be bound by these terms, and the more userspace libs
+that are LGPL, the more they would have to be to use Android
+userspace.</li>
+<li>Historically, LGPL libraries have been the source of a large number
+of compliance problems for downstream device makers and application
+developers (due to ignorance and disbelief, usually). Education is
+slow going, sadly. Part of android being successful as a platform is
+that we want to make it easy for our device makers to comply with the
+licenses in Android. Given the difficulties with complying with LGPL
+in the past, it is easiest to simply not use LGPL libraries if we can
+avoid it.</li>
+</ol>
+<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>
+</div>
diff --git a/pdk/docs/source/life-of-a-bug.jd b/pdk/docs/source/life-of-a-bug.jd
new file mode 100644
index 0000000..1eb1bc4
--- /dev/null
+++ b/pdk/docs/source/life-of-a-bug.jd
@@ -0,0 +1,126 @@
+page.title=Life of a Bug
+doc.type=source
+@jd:body
+<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 <a
+href="{@docRoot}source/report-bugs.html">the Reporting Bugs page</a>.)
+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><i>Please note: the the Android Open Source Project (AOSP) issue tracker is
+intended only for bugs & 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 Android Market, you should visit the
+<a href="http://www.google.com/support/forum/p/Android+Market?hl=en">Android
+Market Support Forum</a>.</i></p>
+<p>Here's the Life of a Bug, in a nutshell:</p>
+<ol>
+<li>A bug is filed, and has the state "New".</li>
+<li>An AOSP contributor periodically reviews and triages bugs. Bugs are
+triaged into one of four "buckets": New, Open, No-Action, or Resolved.</li>
+<li>Each bucket includes a number of states that provide more detail on the
+fate of the issue.</li>
+<li>Bugs in the "Resolved" bucket will eventually be included in a future
+release of the Android software.</li>
+</ol>
+<h2>Bucket Details</h2>
+<p>Here is some additional information on each bucket, what it means, and how
+it's handled.</p>
+<h3>New Issues</h3>
+<p>New issues include bug reports that are not yet being acted upon. The two
+states are:</p>
+<ul>
+<li><b>New</b><p>The bug report has not yet been triaged (that is, reviewed by
+an AOSP contributor.)</p></li>
+<li><b>NeedsInfo</b><p>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>
+
+<h3>Open Issues</h3>
+<p>This bucket contains bugs that need action, but which are still
+unresolved, pending a change to the source code.</p>
+<ul>
+<li><b>Unassigned</b><p>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><b>Reviewed</b><p>Like <code>Unassigned</code>, but the issue
+represented is being tracked in a separate bug database. For example, the bug
+might have been reported via an AOSP member's internal bug-tracking system,
+which is considered the "master" copy.</p></li>
+<li><b>Assigned</b><li>Like <code>Unassigned</code>, but the bug has been
+actually assigned to a specific contributor to fix.</p></li>
+</ul>
+<p>Typically, a given bug will start in <code>Unassigned</code>, where it
+will remain until it is associated with a specific upcoming release, at which
+point it will enter <code>Reviewed</code> or <code>Assigned</code>. However,
+note that this isn't a guarantee, and it's not uncommon for bugs to go from
+<code>Unassigned</code> 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>
+
+<h3>No-Action Issues</h3>
+<p>This bucket contains bugs that have for one reason or another been
+determined to not require any action.</p>
+<ul>
+<li><b>Spam</b><p>A kind soul sent us some delicious pork products, that we,
+regrettably, do not want.</p></li>
+<li><b>Question</b><p>Someone mistook the issue tracker for a help forum.
+(This is not as uncommon as one might assume: many users whose native language
+isn't English can make this mistake.)</p></li>
+<li><b>Unreproducible</b><p>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><b>WorkingAsIntended</b><p>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".</b></li>
+<li><b>Declined</b><p>This is like <code>WorkingAsIntended</code>, 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.</b></li>
+</ul>
+
+<h3>Resolved Issues</h3>
+<p>This bucket contains bugs that have had action taken, and are now
+considered resolved.</p>
+<ul>
+<li><b>FutureRelease</b><p>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><b>Released</b><p>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><b>Duplicate</b><p>This bug is a duplicate of another, existing bug
+report.</p></li>
+</ul>
+
+<h2>Other Stuff</h2>
+<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="http://code.google.com/p/android/issues/list">Google Code Project
+Hosting Issue Tracker</a> is the <b>only</b> official public issue tracker; however,
+many of the AOSP Member organizations maintain their 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>
diff --git a/pdk/docs/source/life-of-a-patch.jd b/pdk/docs/source/life-of-a-patch.jd
new file mode 100644
index 0000000..e7ae936
--- /dev/null
+++ b/pdk/docs/source/life-of-a-patch.jd
@@ -0,0 +1,5 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h2>Workflow</h2>
+<img src="{@docRoot}images/workflow-0.png"/>
diff --git a/pdk/docs/source/overview-1.0.jd b/pdk/docs/source/overview-1.0.jd
new file mode 100644
index 0000000..cc923c6
--- /dev/null
+++ b/pdk/docs/source/overview-1.0.jd
@@ -0,0 +1,158 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Release features - Android 1.0</b>
+</h3>
+<div><div><div><div>This page provides a high-level overview of Android 1.0 features. For a list of all the projects that make up the Android 1.0 source code, see<a href="http://source.android.com/projects">Project layout</a>
+. To see the code itself, you can either use the<a href="http://git.source.android.com/">GitWeb</a>
+interface to view snapshots of the files, or you can<a href="http://source.android.com/download">download</a>
+the source code onto your local machine.<br><br><b>Applications</b>
+<br><br>The Android platform comes with a variety of applications written using the Java programming language:<br><ul><li><i>Home</i>
+displays applications, widgets, and shortcuts. It also supports customizable wall paper.
+</li>
+<li><i>Phone</i>
+supports regular telephony functions as well as call controls, conference calls, supplementary services, and easy integration with<i>Contacts</i>
+.<br></li>
+<li><i>Web Browser</i>
+is a fully featured WebKit-based browser that supports HTML and XHTML.
+</li>
+<li><i>Email</i>
+provides access to email servers commonly found on the Internet and supports POP3, IMAP4, and SMTP.
+</li>
+<li><i>Media Player</i>
+enables managing, importing, and playing back content that has been encoded in various forms.<br></li>
+<li><i>Alarm Clock, Calculator, Calendar, Camera, Contacts, IM, MMS, Settings,</i>
+<i>Voice Dialer</i>
+, and many other applications are also included in this release.<br></li>
+</ul>
+<b>Application framework</b>
+<br><br></div>
+<div>The Android Application Framework has been designed to provide a rich set of APIs for third-party application developers. For more information, visit the<a href="http://developer.android.com/guide/index.html">Android SDK developer guide</a>
+.<b><br></b>
+</div>
+<div></div>
+<div><b>Android runtime</b>
+<b><br><br></b>
+Android applications run on Dalvik, a custom virtual machine (VM) designed for embedded use. The Dalvik VM runs dex executable files, which are typically compiled from source code written in Java.<br><br></div>
+<div>The dex executable format is designed to have these characteristics:<br><ul><li>Efficient on-device storage.
+</li>
+<li>Efficient runtime memory usage.
+</li>
+<li>Ease of interpretation.<br></li>
+</ul>
+Dalvik has the following runtime characteristics:
+<ul><li>Efficient support for multiple concurrent VM processes, including amortized initialization and heavily shared memory.
+</li>
+<li>Optimized interpreter.
+</li>
+<li>Efficient linkage to low-level native code.
+</li>
+<li>A familiar and rich set of core library functionality. For a complete list of supported libraries, see<a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</a>
+.
+</li>
+<li>Enhanced JDWP support, enabling easier debugging of multiple processes simultaneously.
+</li>
+<li>JNI support.
+</li>
+</ul>
+<b>Native libraries<br></b>
+<br>The Android platform makes use of many native libraries, including:<br><ul><li><i>Bionic</i>
+, a custom libc implementation optimized for embedded systems.
+</li>
+<li>Graphics libraries for 2D and 3D (OpenGL ES 1.0) graphics support.<br></li>
+<li>openCore to provide the bulk of Android's multimedia capability. It includes support for network streaming (HTTP and RTSP), as well as most of the codecs and media file parsers used by the system.<br></li>
+<li>sqlite to support having a lightweight transactional data store.
+</li>
+<li>WebKit library to power Android's WebKit based full web browser.<br></li>
+</ul>
+<br><b>System software</b>
+<b><br></b>
+<br></div>
+<div>About Android's operating system:
+<ul><li>Based on Linux 2.6.25 for ARM.<br></li>
+<li>Platform currently expects ARM V5T or better architecture. Support for earlier architectures could be added, but CPUs without an MMU would be difficult to support.
+</li>
+<li>A set of kernel enhancements are provided to support Android. The patches include alarm, ashmem, binder, power management, low memory killer, kernel degugger, and logger<b>.<br></b>
+</li>
+<li>While the platform is designed to be chipset agnostic, and will run on virtually any ARM-based Linux kernel environment, version 1.0 of the platform has been tested and verified on the MSM 7K chipsets<b>.</b>
+Over time we expect to see support for other major chipsets.
+Kernel patches for MSM based chipsets are also available.
+</li>
+<li>FAT32 file system is supported.
+</li>
+<li>Support for TCP/IP (TCP, UDP, etc).
+</li>
+</ul>
+</div>
+<div>A minimal reference bootloader for the supported chipset is provided. It is capable of booting Linux from RAM, debugger, and NAND Flash.<br></div>
+<div><br>About Android's support for debugging:<br><ul><li>Debugging native code is supported via GDB (GNU Project Debugger) over USB.
+</li>
+<li>Debugging managed code is supported via any JDWP-compatible debugger over USB.
+</li>
+<li>Logging and crash logs supported for debugging.
+</li>
+</ul>
+<b>Supported hardware<br></b>
+<ul><li>The platform will run on almost on any ARM based Linux kernel environment.
+</li>
+<li>The platform requires a minimum of 128 MB of RAM and 256 MB ofFlash memory. AnOEM may want to support more Flash memory to make it possible to download more third-party applications to user devices.<br></li>
+<li>The platform will interface with a baseband radio stack provided externally via a Radio Interface Layer (RIL).
+</li>
+<li>802.11 b/g Wi-Fi
+</li>
+<li>Standard USB interface, including USB 2.0
+</li>
+<li>Bluetooth 2.0 EDR (Enhanced Data Rate)
+</li>
+<li>Camera for still and video capture
+</li>
+<li>Removable storage
+</li>
+</ul>
+<b>Supported display</b>
+<br><ul><li>HVGA resolution<br></li>
+<li>16 bit color depth<br></li>
+<li>Landscape and portrait orientation, including dynamic runtime switching
+</li>
+<li>Finger-based touchscreen navigation
+</li>
+</ul>
+<b>Supported keypads and buttons</b>
+<br><ul><li>QWERTY
+</li>
+<li>5-way navigation
+</li>
+<li>Hardware buttons: Send, End, Home, Back, Menu</li>
+<li>Power button
+</li>
+<li>Volume keys (up and down)
+</li>
+<li>Camera trigger button, including detection for both partial press (to focus) and full press (to actually take a picture)
+</li>
+</ul>
+<b>Supported audio outputs</b>
+<br><ul><li>Audio output via the headphone jack (mono and stereo)
+</li>
+<li>64 kbps Bluetooth audio supported</li>
+</ul>
+<b>Supported notifications</b>
+<br><ul><li>LEDs
+</li>
+<li>Vibration
+</li>
+</ul>
+<b>Supported radio and telephony features<br></b>
+<ul><li>GPRS, EDGE, UMTS, HSDPA
+</li>
+<li>International roaming, SMS, MMS<br></li>
+<li>Emergency call support<br></li>
+<li>Supplementary Services for Telephony, for example call waiting and conference calling<br></li>
+<li>Unstructured Supplementary Service Data (USSD)
+</li>
+<li>Reference Radio Interface Layer (RIL)
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
diff --git a/pdk/docs/source/overview-1.5.jd b/pdk/docs/source/overview-1.5.jd
new file mode 100644
index 0000000..3212f3b
--- /dev/null
+++ b/pdk/docs/source/overview-1.5.jd
@@ -0,0 +1,196 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Release features - Android 1.5</b>
+</h3>
+<div><div><div><div><b>Previous release highlights</b>
+:<a href="http://source.android.com/release-features---android-1-0">Android 1.0</a>
+<br><br>This page provides a high-level overview of the new features added to Android 1.5. To see the code itself, you can either use the<a href="http://git.source.android.com/">GitWeb</a>
+interface to view snapshots of the files, or you can<a href="http://source.android.com/download">download</a>
+the source code onto your local machine. You can use<i>repo init -u</i>
+git://android.git.kernel.org/platform/manifest.git<i>-b android-1.5</i>
+to download the source code for Android 1.5.<br><br><b>User interface refinements:</b>
+<br><ul><li>System-wide:
+<ul><li>Refinement of all core UI elements
+</li>
+<li>Animated window transitions (off by default)
+</li>
+<li>Accelerometer-based application rotations
+</li>
+</ul>
+</li>
+<li>UI polish for:
+<ul><li>In-call experience
+</li>
+<li>Contacts, Call log, and Favorites
+</li>
+<li>SMS MMS
+</li>
+<li>Browser
+</li>
+<li>Calendar
+</li>
+<li>Email
+</li>
+<li>Camera Gallery
+</li>
+<li>Application management
+</li>
+</ul>
+</li>
+</ul>
+<div><b><br>Performance improvements:</b>
+<br></div>
+<ul><li>Faster Camera start-up and image capture
+</li>
+<li>Much faster acquisition of GPS location (powered by SUPL AGPS)
+</li>
+<li>Smoother page scrolling in Browser
+</li>
+</ul>
+<br><b>Applications</b>
+<br><ul><li>Camera Gallery
+</li>
+<ul><li>Video recording
+</li>
+<li>Video playback (MPEG-4 3GP formats)
+</li>
+</ul>
+<li>Browser
+</li>
+<ul><li>Updated with latest Webkit browser Squirrelfish Javascript engines
+</li>
+<li>Copy 'n paste in browser
+</li>
+<li>Search within a page
+</li>
+<li>User-selectable text-encoding
+</li>
+<li>UI changes include:
+</li>
+<ul><li>Unified Go and Search box
+</li>
+<li>Tabbed bookmarks/history/most-visited screen
+</li>
+</ul>
+</ul>
+<li>Contacts
+</li>
+<ul><li>Shows user picture for Favorites
+</li>
+<li>Specific date/time stamp for events in call log
+</li>
+<li>One-touch access to a contact card from call log event
+</li>
+</ul>
+</ul>
+<b><br>Application framework</b>
+<br><br></div>
+<div><ul><li>On-screen soft keyboard
+</li>
+<ul><li>Works in both portrait and landscape orientation
+</li>
+<li>Support for user installation of 3rd party keyboards
+</li>
+<li>User dictionary for custom words
+</li>
+</ul>
+<li>Home screen
+</li>
+<ul><li>Widgets
+</li>
+<ul><li>Bundled home screen widgets include: analog clock, calendar, music player, picture frame, and search
+</li>
+</ul>
+<li>Live folders
+</li>
+</ul>
+<li>UI framework
+</li>
+<ul><li>Framework for easier background/UI thread interaction
+</li>
+<li>New SlidingDrawer widget
+</li>
+<li>Horizontal ScrollView widget
+</li>
+</ul>
+<li>Home Screen framework
+</li>
+<ul><li>APIs for creating secure home screen widgets
+</li>
+<li>APIs for populating live folders with custom content
+</li>
+</ul>
+<li>Media framework
+</li>
+<ul><li>Raw audio recording and playback APIs
+</li>
+<li>Interactive MIDI playback engine
+</li>
+<li>Video recording APIs for developers (3GP format)
+</li>
+<li>Video and photo sharing Intents
+</li>
+<li>Media search Intent
+</li>
+</ul>
+<li>Input Method framework
+</li>
+<ul><li>Text prediction engine
+</li>
+<li>Ability to provide downloadable IMEs to users
+</li>
+</ul>
+<li>Speech recognition framework
+</li>
+<ul><li>Support for using speech recognition libraries via Intent
+</li>
+</ul>
+<li>Misc API additions
+</li>
+<ul><li>LocationManager - Applications can get location change updates via Intent
+</li>
+<li>WebView - Touch start/end/move/cancel DOM event support
+</li>
+<li>SensorManager - redesigned sensor APIs
+</li>
+<li>GLSurfaceView - convenience framework for creating OpenGL applications
+</li>
+<li>Broadcast Intent for app update install succeeded - for smoother app upgrade experience
+</li>
+</ul>
+</ul>
+</div>
+<div></div>
+<div><br><b>System software</b>
+<br><br></div>
+<ul><li>New Linux kernel (version 2.6.27)
+</li>
+<li>SD card filesystem auto-checking and repair
+</li>
+<li>SIM Application Toolkit 1.0
+</li>
+</ul>
+<div><b><br>Supported hardware<br></b>
+<ul><li>Bluetooth</li>
+<ul><li>Stereo Bluetooth support (A2DP and AVCRP profiles)
+</li>
+<li>Auto-pairing
+</li>
+<li>Improved handsfree experience
+</li>
+</ul>
+</ul>
+<br><b>Developer tools</b>
+<br></div>
+<div><ul><li>Support for multiple versions of Android in a single SDK installation
+</li>
+<li>Improved JUnit support in ADT
+</li>
+<li>Easier application performance profiling
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
diff --git a/pdk/docs/source/overview.jd b/pdk/docs/source/overview.jd
new file mode 100644
index 0000000..0948ef2
--- /dev/null
+++ b/pdk/docs/source/overview.jd
@@ -0,0 +1,88 @@
+page.title=Android 1.6 Platform Overview
+doc.type=source
+@jd:body
+<p>This page provides a high-level overview of the new features added to
+Android 1.6. To see the code itself, you can either use the <a
+href="http://git.source.android.com/">GitWeb</a>
+interface to view snapshots of the files, or you can <a
+href="http://source.android.com/download/idex.html">download</a>
+the source code onto your local machine. You can use <code>repo init -u
+git://android.git.kernel.org/platform/manifest.git -b android-1.6</code>
+to download the source code for Android 1.6.</p>
+<p>Information about older Android releases is also available:<ul>
+<li><a href="{@docRoot}source/overview-1.5.html">Android 1.5 Platform Overview</a></li>
+<li><a href="{@docRoot}source/overview-1.0.html">Android 1.0 Platform Overview</a></li>
+</ul></p>
+<h2>User interface refinements</h2>
+<h3>Quick Search Box for Android </h3>
+<p>Android 1.6 includes a redesigned search framework that provides a quick, effective, and consistent way for users to search across multiple sources—such as browser bookmarks history, contacts, and the web—directly from the home screen.
+</p>
+<p><br></p>
+<p>The system constantly learns which search results are more relevant based on what is clicked. So popular contacts or apps that have previously been picked will bubble up to the top when a user types the first few letters of a relevant query.
+</p>
+<p><br></p>
+<p>The search framework also provides developers a way to easily expose relevant content from their applications in Quick Search Box.
+</p>
+<h3>Camera, Camcorder, and Gallery </h3>
+<p>An updated user interface provides an integrated camera, camcorder, and gallery experience. Users can quickly toggle between still and video capture modes. Additionally, the gallery enables users to select multiple photos for deletion.<br></p>
+<p><br></p>
+<p>Android 1.6 also provides a much faster camera experience. Compared to the previous release, launching the camera is now 39% faster, and there is a 28% improvement in the time from completing one shot to the next.
+</p>
+<h3>VPN, 802.1x </h3>
+<p>A new Virtual Private Network (VPN) control panel in Settings allows users to configure and connect to the following types of VPNs:
+</p>
+<ul><li>L2TP/IPSEC pre-shared key based VPN
+ </li>
+<li>L2TP/IPsec certificate based VPN
+ </li>
+<li>L2TP only VPN
+ </li>
+<li>PPTP only VPN
+ </li>
+</ul>
+<h3>Battery usage indicator </h3>
+<p>A new battery usage screen lets users see which apps and services are consuming battery power. If the user determines that a particular service or application is using too much power, they can take action to save the battery by adjusting settings, stopping the application, or uninstalling the application.
+</p>
+<h3>Accessibility </h3>
+<p>Users will be able to download new accessibility services built on the new accessibility framework and enable them in Settings.
+</p>
+<h2>New Platform Technologies </h2>
+<h3>Expanded Search Framework </h3>
+<p>The Android search framework has been redesigned and expanded to provide third-party applications the opportunity to surface content from their applications in Quick Search Box, the global search tool. To do this, developers will need to make their app "searchable" and provide suggestions in response to user queries. To enable application search suggestions, users simply select each application from which they'd like to receive suggestions, under Searchable items in the Search settings.
+</p>
+<h3>Text-to-speech engine</h3>
+<p>Android 1.6 features a multi-lingual speech synthesis engine called Pico. It allows any Android application to "speak" a string of text with an accent that matches the language. The engine supports the following languages: English (American and British accents), French, Italian, German and Spanish. If you're using a T-Mobile G1 or Dream device, you'll need to download the SpeechSynthesis Data Installer from Android Market, which includes the "voices" needed by the text-to-speech engine.
+</p>
+<h3>Gestures </h3>
+<p>A new gestures framework provides application developers with a framework for creating, storing, loading, and recognizing gestures and associating them with specific actions.
+</p>
+<p>Developers can use the new GestureBuilder tool included in the Android 1.6 SDK to generate libraries of gestures to include with their application.
+</p>
+<h3>Accessibility </h3>
+<p>Android 1.6 provides a new accessibility framework. With this framework, developers can create accessibility plugins that respond to user input, such as making a sound when a new window is shown, vibrating when navigating to the top of a list, and providing spoken feedback.
+</p>
+<h3>Expanded support for screen densities and resolutions </h3>
+<p>Android 1.6 adds screen support that enables applications to be rendered properly on different display resolutions and densities. Developers can also specify the types of screens supported by their application.
+</p>
+<h3>Telephony support for CDMA </h3>
+<p>Android 1.6 includes support for CDMA in the telephony stack.
+</p>
+<h3>New version of OpenCore </h3>
+<p>Android 1.6 includes the updated OpenCore 2 media engine, which has:
+</p>
+<ul><li>Support for OpenMAX encoders
+ </li>
+<li>Support for additional audio codecs in AuthorEngine
+ </li>
+<li>Improved buffering model supports shared buffers allocated in the decoder
+ </li>
+</ul>
+<h3>2.6.29 Linux kernel </h3>
+<p>Android 1.6 upgrades the Linux kernel from 2.6.27 to 2.6.29.
+</p>
+<h2>New Framework APIs</h2>
+<p>For a detailed overview of new APIs, see the <a
+href="http://developer.android.com/sdk/android-1.6.html#api-changes">Version
+Notes</a>. For a complete report of all API changes, see the <a
+href="http://developer.android.com/sdk/api_diff/4/changes.html">API
+Differences Report</a>.</p>
diff --git a/pdk/docs/source/report-bugs.jd b/pdk/docs/source/report-bugs.jd
new file mode 100644
index 0000000..e89fbbe
--- /dev/null
+++ b/pdk/docs/source/report-bugs.jd
@@ -0,0 +1,125 @@
+page.title=Report Bugs
+doc.type=source
+@jd:body
+<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,
+<b>please don't use the forms below</b>. (Using the public forms below may
+allow anyone to see your report, which may put users at risk until the bug is
+fixed.) Instead, please report security bugs to our security team by emailing
+<a href="mailto:security@android.com">security@android.com</a>. We believe in
+responsible disclosure of security vulnerabilities, and will give you proper
+attribution for any issues you report.</p>
+<p>Here's how to report non-security bugs:</p>
+<ol>
+ <li><a href="http://code.google.com/p/android/issues/advsearch">Search for
+ your bug</a> to see if anyone has already reported it.</li>
+ <li>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.</li>
+ <li>If no one's reported your bug, file the bug. You can use one of these
+ templates:<ul>
+ <li><a
+ href="http://code.google.com/p/android/issues/entry?template=User%20bug%20report">Bugs
+ in your Device (for users)</a></li>
+ <li><a
+ href="http://code.google.com/p/android/issues/entry?template=Developer%20bug%20report">Bugs
+ in the Software (for developers)</a></li>
+ <li><a
+ href="http://code.google.com/p/android/issues/entry?template=Feature%20request">Request
+ a New Feature</a></li>
+ </ul></li>
+</ol>
+<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="{@docRoot}source/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>
+<h3>A Poor Bug Report</h3>
+<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>
+<h3>A Good Bug Report</h3>
+<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>
+</div>
diff --git a/pdk/docs/source/roles.jd b/pdk/docs/source/roles.jd
new file mode 100644
index 0000000..9c64c71
--- /dev/null
+++ b/pdk/docs/source/roles.jd
@@ -0,0 +1,83 @@
+page.title=People and Roles
+doc.type=source
+@jd:body
+<div>
+<p>The Android Open Source Project (AOSP) includes individuals working in a variety
+of roles. As noted in <a href="{@docRoot}about/philosophy.html">Our
+Philosophy</a>, the core AOSP members operate the Android product management
+and engineering process. This page describes these roles in a bit more
+detail.</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="{@docRoot}source/index.html">Get Involved</a>.</p>
+
+<h2>AOSP Member</h2>
+<p>"AOSP Member" is a somewhat loose term, but generally refers to
+those organizations who are key contributors to Android, and who are managing
+the product requirements process and core engineering. You can think of this
+group as the Android "core team" responsible for Android's overall success in
+the marketplace. One of the most prominent AOSP members is Google.</p>
+<p/>
+
+<h2>Contributor</h2>
+<p>A "Contributor" is anyone making contributions to the AOSP source code,
+including both employees or other affiliates of an AOSP Member, as well as
+external developers who are contributing to Android on their own behalf.
+There is no distinction between Contributors who are affiliated with an AOSP
+Member, and those who are not: all engineers use the same git/gerrit tools,
+follow the same code review process, and are subject to the same requirements
+on code style and so on.</p>
+<p/>
+
+<h2>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"; we simply use "Developer" to help identify our audience.
+Since the key purpose of Android is to cultivate an open development platform,
+"Developers" are one of the key customers of the Android project. As such, we
+talk about them a lot, though this isn't technically a separate role in the
+AOSP <i>per se.</i></p>
+<p/>
+
+<h2>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.</p><p><i>Note: at this
+time, generally Verifiers are the same as Approvers.</i></p>
+<p/>
+
+<h2>Approver</h2>
+"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 (typically employed by an AOSP Member) choose
+the Approvers, sometimes promoting to this position Verifiers who have
+demonstrated their expertise within a specific project.</p>
+<p/>
+
+<h2>Project Leads</h2>
+<p>Android consists of a number of sub-projects; you can see these in the git
+repository, as individual .git files. The AOSP Members generally assign tech
+leads or product leads who oversee the engineering for individual Android
+projects. Typically these tech leads will be employees of an AOSP Member
+company. A Project Lead for an individual project is responsible for the
+following:</p>
+<ul>
+ <li>Lead all technical aspects of the project; for example, the project
+ roadmap, development, release cycles, versioning, and QA.</li>
+ <li>Ensure that the project is QA-ed in time for scheduled Android platform
+ releases.</li>
+ <li>Designate Verifiers and Approvers for submitted patches.</li>
+ <li>Be fair and unbiased while reviewing changes. Accept or reject patches
+ based on technical merit and alignment with the Android platform.</li>
+ <li>Review changes in a timely manner and make best efforts to communicate
+ when changes are not accepted.</li>
+ <li>Optionally maintain a web site for the project for information and
+ documents specific to the project.</li>
+ <li>Act as a facilitator in resolving technical conflicts.</li>
+ <li>Be the public face for the project and the go-to person for questions
+ related to the project.</li>
+</ul>
+</div>
diff --git a/pdk/docs/source/source_toc.cs b/pdk/docs/source/source_toc.cs
new file mode 100644
index 0000000..007ea64
--- /dev/null
+++ b/pdk/docs/source/source_toc.cs
@@ -0,0 +1,36 @@
+<script type="text/javascript" language="JavaScript">
+<!--
+function nothing() {}
+-->
+</script>
+
+<ul>
+ <li><h2>The Project</h2><ul>
+ <li><a href="<?cs var:toroot ?>source/roles.html">People and Roles</a></li>
+ <li><a href="<?cs var:toroot ?>source/licenses.html">Licensing Information</a></li>
+ <li><a href="http://android.git.kernel.org/">Browse Source</a></li>
+ <li><a href="<?cs var:toroot ?>source/overview.html">Platform Overview</a></li>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-bug.html">Life of a Bug</a></li>
+ </ul>
+
+ <li><h2>Getting Started</h2><ul>
+ <li><a href="<?cs var:toroot ?>source/download.html">Getting the Source</a></li>
+ <li><a href="<?cs var:toroot ?>source/git-repo.html">Using git and repo</a></li>
+ <li><a href="<?cs var:toroot ?>source/using-eclipse.html">Using Eclipse</a></li>
+ <li><a href="<?cs var:toroot ?>source/code-style.html">Code Style</a></li>
+ <li><a href="<?cs var:toroot ?>source/building-dream.html">Building for ADP1</a></li>
+ </ul>
+
+ <li><h2>Contributing</h2><ul>
+ <li><a href="<?cs var:toroot ?>source/life-of-a-patch.html">Life of a Patch</a></li>
+ <li><a href="<?cs var:toroot ?>source/submit-patches.html">Submitting Patches</a></li>
+ <li><a href="<?cs var:toroot ?>source/report-bugs.html">Reporting Bugs</a></li>
+ </ul>
+</ul>
+
+<script type="text/javascript">
+<!--
+ buildToggleLists();
+//-->
+</script>
+
diff --git a/pdk/docs/source/submit-patches.jd b/pdk/docs/source/submit-patches.jd
new file mode 100644
index 0000000..afa6bf2
--- /dev/null
+++ b/pdk/docs/source/submit-patches.jd
@@ -0,0 +1,231 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><span><b>Contribute</b>
+</span>
+</h3>
+<div><a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+<div><div><div><div><div><div><p><b>Contents</b>
+</p>
+<ol><li><a href="#TOC-Prerequisites"><b>1</b>
+Prerequisites</a>
+</li>
+<li><a href="#TOC-Working-with-the-code"><b>2</b>
+Working with the code</a>
+<ol><li><a href="#TOC-Starting-a-topic-branch"><b>2.1</b>
+Starting a topic branch</a>
+</li>
+<li><a href="#TOC-Editing-the-files"><b>2.2</b>
+Editing the files</a>
+</li>
+<li><a href="#TOC-Staging-changes"><b>2.3</b>
+Staging changes</a>
+</li>
+<li><a href="#TOC-Using-repo-status"><b>2.4</b>
+Using repo status</a>
+</li>
+<li><a href="#TOC-Using-git-diff"><b>2.5</b>
+Using git diff</a>
+</li>
+<li><a href="#TOC-Committing-changes"><b>2.6</b>
+Committing changes</a>
+</li>
+<li><a href="#TOC-Committing-changes-during-code-revi"><b>2.7</b>
+Committing changes during code review</a>
+</li>
+<li><a href="#TOC-Editing-uploaded-changes"><b>2.8</b>
+Editing uploaded changes</a>
+</li>
+<li><a href="#TOC-Uploading-changes-to-Gerrit"><b>2.9</b>
+Uploading changes to Gerrit</a>
+</li>
+<li><a href="#TOC-Summary-example"><b>2.10</b>
+Summary example</a>
+</li>
+<li><a href="#TOC-Downloading-changes-from-Gerrit"><b>2.11</b>
+Downloading changes from Gerrit</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Using-the-Gerrit-code-review-tool"><b>3</b>
+Using the Gerrit code-review tool</a>
+<ol><li><a href="#TOC-Viewing-the-status-of-uploaded-chan"><b>3.1</b>
+Viewing the status of uploaded changes</a>
+</li>
+<li><a href="#TOC-Reviewing-a-change"><b>3.2</b>
+Reviewing a change</a>
+</li>
+<li><a href="#TOC-Verifying-a-change"><b>3.3</b>
+Verifying a change</a>
+</li>
+<li><a href="#TOC-Viewing-diffs-and-comments"><b>3.4</b>
+Viewing diffs and comments</a>
+</li>
+<li><a href="#TOC-Adding-comments"><b>3.5</b>
+Adding comments</a>
+</li>
+<li><a href="#TOC-After-a-submission-is-approved"><b>3.6</b>
+After a submission is approved</a>
+</li>
+<li><a href="#TOC-How-do-I-become-a-Verifier-or-Appro"><b>3.7</b>
+How do I become a Verifier or Approver?</a>
+</li>
+</ol>
+</li>
+<li><a href="#TOC-Using-GitWeb-to-track-patch-histori"><b>4</b>
+Using GitWeb to track patch histories</a>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<table><tbody><tr><td>For information about current problems and fixes, see<a href="http://source.android.com/known-issues">Known issues</a>
+.</td>
+</tr>
+</tbody>
+</table>
+<br>This page describes how to record changes to the Android files on your local client, upload those changes to the code-review server, and use Gerrit to track changes.<br><h2>
+Prerequisites</h2>
+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, see<a href="http://source.android.com/download">Get source</a>
+.<br><br>Other recommended reading:<br><ul><li>For an overview of the code contribution and review process, see<a href="http://source.android.com/submit-patches/workflow">Workflow</a>
+.</li>
+<li>For details about Repo, see<a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+.<br></li>
+<li>For information about the different roles you can play within the Android Open Source community, see<a href="http://source.android.com/project">Project roles</a>
+.</li>
+<li>If you plan to contribute code to the Android platform, be sure to read about<a href="http://source.android.com/license">contributor licenses</a>
+.</li>
+</ul>
+<h2>
+Working with the code</h2>
+First, download the source into your working directory, as described in<a href="http://source.android.com/download">Get source</a>
+.<br><br>To work on a particular change to the code, follow these steps:<br>
+<div><img src="{@docRoot}images/submit-patches-0.png">
+</div>
+<ol><li>Use repo start<i>branchname</i>
+to start a new topic branch.</li>
+<li>Edit the files.<br></li>
+<li><span>Use git add to stage changes.</span>
+<span>(Sometimes optional.)</span>
+<br></li>
+<li>Use repo status and git diff to view the status of your files.<i><br></i>
+</li>
+<li>Use git commit to commit changes.<br></li>
+<li><span>Use repo upload to upload changes to the review server</span>
+.<br></li>
+</ol>
+You can track your uploaded changes using the Gerrit code-review tool. When it's time to work on the code again, run repo sync, then go back to step 1 above and start another topic branch.<br><br>The steps will not always come in the order shown--for example, you might run git diff at several points in the process.<br><br><h3>
+Starting a topic branch</h3>
+Start a topic branch called default in your local work environment:<br><br>$ repo start default<br><br>For more about topic branches, see<a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+.<br><h3>
+Editing the files</h3>
+You do not need to check files out before working on them. Edit the files using vim, emacs, or any other editor.<br><br><h3>
+Staging changes</h3>
+To indicate that every new and modified file in your working directory should be "staged" for inclusion in the next commit, run git add without any arguments. You can also specify files or filetypes. For example, the following command would stage all the new and modified files under the bionic directory and its subdirectories:<br><br>$ git add bionic/*<br><br>Run git help add to see more ways to use git add.<br><br><b>When is git add optional?<br></b>
+<br>If you add new files, you must stage them using git add before you run git commit. However, if you are only modifying or deleting files, you can skip git add if you use the -a option with git commit. For more details, see the "Committing changes" section further down.<br><br><h3>
+Using repo status<br></h3>
+To see the status of the current branch, run<br><br>$ repo status .<br><br>For information about how to interpret the results of repo status, see<a href="http://source.android.com/download/using-repo#TOC-status">Using Repo and Git</a>
+.<br><br><h3>
+Using git diff</h3>
+To see uncommitted changes, cd into the project directory and run<br><br>$ git
+diff<br><br>Without any arguments, git diff will show you the differences
+between the files in your working directory and the committed
+files.<br><div><br><div><img src="{@docRoot}images/submit-patches-1.png">
+</div>
+<br></div>
+<div>If you add the --cached option, git diff will show you the differences between the files in your working directory and the staged files.<br><br></div>
+<div><a href="http://source.android.com/submit-patches/git-diff.gif?attredirects=0"><br></a>
+</div>
+To see every edit that would go into the commit if you were to commit right now, make sure you are in the project directory and then run<br><br>$ git diff --cached<br><br><h3>
+Committing changes</h3>
+At intervals while you are working, commit your edits by using git commit from within the project directory:<br><span>$ cd ~/mydroid/<i>project-name</i>
+</span>
+<span><br>$ git commit</span>
+<br><br>Every file that you staged using git add will be included in this commit.<br><br>If you have not added any new files that you want to commit, you can skip git add and simply run<br><br>$ git commit -a<br><br>The -a option will stage all the files you have modified or deleted and include them in this commit. (If you have added new files and want them included in the commit, you will need to use git add before you run git commit.)<br><br>If commit<span></span>
+does not find changes to be committed, it will report "nothing to commit (working directory clean)". If commit finds changes to be committed, a file will open in which you can create a log message:<br><br><div><i>Your comments about this commit go here....</i>
+<br># Please enter the commit message for your changes. Lines starting<br># with '#' will be ignored, and an empty message aborts the commit.<br># On branch master<br># Changes to be committed:<br>#(use "git reset HEADfile..." to unstage)<br>#<br>#new file:.repo/projects/gerrit-manifests.git/FETCH_HEAD<br>#new file:.repo/projects/gerrit-manifests.git/HEAD<br>#new file:.repo/projects/gerrit-manifests.git/config<br>.<br>.<br>.<br></div>
+<br>If you do not add a log message, the commit will be aborted. Add a message and save the file.<br><br><h3>
+Committing changes during code review</h3>
+If you previously uploaded a change to Gerrit and the Approver has asked for changes, follow these steps:<br><ol><li>Edit the files to make the changes the Approver has requested.</li>
+<li>Recommit your edits using the --amend flag, for example:<br><span>$ git commit -a --amend</span>
+<br></li>
+<li>See below to upload the changes to Gerrit again for another review cycle.</li>
+</ol>
+<h3>
+Editing uploaded changes</h3>
+To update an existing change with a new patch set:<br><ol><li>Make sure the updated branch is the currently checked out branch.</li>
+<li>Use repo upload --replace<i>proj1</i>
+to open the change matching editor.</li>
+<li>For each commit in the series, enter the Gerrit change Id inside the brackets.</li>
+</ol>
+For more details, see<a href="http://source.android.com/download/using-repo#TOC-upload">Using Repo and Git</a>
+.<br><h3>
+Uploading changes to Gerrit</h3>
+To upload your committed changes to the review server:<br><ol><li>Complete the appropriate<a href="https://review.source.android.com/#settings,new-agreement">Contributor Agreement</a>
+in Gerrit, granting the Android Open Source Project permission to distribute your changes to others.</li>
+<li>Select an<a href="https://review.source.android.com/#settings,ssh-keys">SSH Username</a>
+and upload your<a href="https://review.source.android.com/#settings,ssh-keys">public SSH key</a>
+, so that Gerrit can identify you when you upload changes.Please note that due to a bug in repo, repo upload requires your SSH Username be the local part of your email address (the text on the left of the @ sign).<br><br>These first two steps are only necessary prior to your first change.Gerrit will remember your agreement and SSH key for subsequent changes.<br><br></li>
+<li>Update to the latest revisions:<span><br></span>
+<span>$</span>
+<span>repo sync</span>
+<br><br>For information about how to handle sync conflicts and how Repo synchronization works, see<a href="http://source.android.com/download/using-repo#TOC-sync">Using Repo and Git</a>
+.<br><br></li>
+<li>Run repo upload to examine the list of all available changes and select which topic branches will be uploaded to the review server:<br><span>$</span>
+<span>repo upload</span>
+<br><br>This will open an editor window that will let you choose which topic branch to upload.If there is only one branch available, a simple y/n prompt is instead of an editor.<br></li>
+</ol>
+After a change is uploaded successfully:<br><ul><li>Repo will give you a URL where you can view your submission.</li>
+<li>The code-review system will automatically notify the project owner about your submission.</li>
+</ul>
+For information about specifying particular projects with repo sync and repo upload, see<a href="http://source.android.com/download/using-repo">Using Repo and Git</a>
+.<br><br><h3>
+Summary example<br></h3>
+Here is a simple example that shows how you might work with the bionic/Android.mk file:<br><br>$ cd ~/mydroid/bionic<br>$ repo start default<br>$ vi Android.mk<br><i>...edit and save the file...</i>
+<br>$ git commit -a<br>$ repo sync<br>$ repo upload<br><i>...close the editable window that opens...</i>
+<br><i>...visit the provided URL to open Gerrit and track your change...</i>
+<br><br><h3>
+Downloading changes from Gerrit</h3>
+To download a specific change from Gerrit, run<br><br>$ repo download<i>target change</i>
+<br><br>where target is the local directory into which the change should be downloaded andchange is the change number as listed in<a href="https://review.source.android.com/">Gerrit</a>
+. For more information, see<a href="http://source.android.com/download/using-repo#TOC-download">Using Repo and Git</a>
+.<br><br><h2>
+Using the Gerrit code-review tool<br></h2>
+You can open Gerrit by visiting whatever URL is returned to you from the repo upload command, or by visiting<a href="https://review.source.android.com/">https://review.source.android.com</a>
+/.<br><br><h3>
+Viewing the status of uploaded changes<br></h3>
+To check the status of a change that you uploaded, open<a href="https://review.source.android.com/mine">Gerrit</a>
+, sign in, and click MyChanges.<br><b><br></b>
+<h3>
+Reviewing a change<br></h3>
+If you are assigned to be the Approver for a change, you need to determine the following:<br><ul><li>Does this change fit within this project's stated purpose? (See<a href="http://source.android.com/projects">Project layout</a>
+.)<br></li>
+<li>Is this change valid within the project's existing architecture?</li>
+<li>Does this change introduce design flaws that will cause problems in the future?</li>
+<li>Does this change following the best practices that have been established for this project?</li>
+<li>Is this change a good way to perform the described function?</li>
+<li>Does this change introduce any security or instability risks?</li>
+</ul>
+If you approve of the change, you will then mark it with LGTM ("Looks Good to Me") within Gerrit.<br><br><h3>
+Verifying a change<br></h3>
+If you are assigned to be the Verifier for a change, you need to do the following:<br><ul><li>Patch the change into your local client using one of the Download commands.</li>
+<li>Build and test the change.</li>
+<li>Within Gerrit use Publish Comments to mark the commit as "Verified", or "Fails" (and add a message explaining what problems were identified).<br></li>
+</ul>
+<h3>
+Viewing diffs and comments</h3>
+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."<br></div>
+<div><h3>
+Adding comments</h3>
+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.<br><br>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.<br><br>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.<br><br><h3>
+After a submission is approved</h3>
+After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. The change will now be visible in gitweb, and others users will be able to run repo sync to pull the update into their local client.<br><br><h3>
+How do I become a Verifier or Approver?</h3>
+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="http://source.android.com/project">Project roles</a>
+.<br><br><h2>
+Using GitWeb to track patch histories</h2>
+To view snapshots of the files that are in the public Android repositories and view file histories, use the<a href="http://android.git.kernel.org/">Android instance of GitWeb</a>
+.<br></div>
+</div>
+</div>
diff --git a/pdk/docs/source/using-eclipse.jd b/pdk/docs/source/using-eclipse.jd
new file mode 100644
index 0000000..961da74
--- /dev/null
+++ b/pdk/docs/source/using-eclipse.jd
@@ -0,0 +1,211 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=source
+@jd:body
+<h3><b>Using Eclipse</b>
+</h3>
+<div><h2><a>About this Document</a>
+</h2>
+<p>This document will help you set up the Eclipse IDE for Android platform development.
+</p>
+
+
+<h2><a>Enter eclipse</a>
+</h2>
+<h4>
+Basic setup
+</h4>
+<p>First, it's important to make sure the regular Android development system is set up.
+</p>
+<pre>cd /path/to/android/root<br>make # and wait a while, if you haven't done this<br></pre>
+<p><b>Important</b>
+: 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.
+</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 .classpath file. We have a sample version to start you off.
+</p>
+<pre>cd /path/to/android/root<br>cp development/ide/eclipse/.classpath .<br>chmod u+w .classpath # Make the copy writable<br></pre>
+<p>Now edit that copy of .classpath, if necessary.
+</p>
+<h5>
+Increase Eclipse's Memory Settings
+</h5>
+<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 the eclipse.ini file. On Apple OSX the eclipse.ini file is located at /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
+</p>
+<p>Memory-related defaults (as of Eclipse 3.4)
+</p>
+
+<pre>-Xms40m<br>-Xmx256m<br>-XX:MaxPermSize=256m<br></pre>
+<p>Recommended settings for Android development
+</p>
+<pre>-Xms128m<br>-Xmx512m<br>-XX:MaxPermSize=256m<br></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>eclipse # or you can click some clicky thing instead, if you prefer<br></pre>
+<p>Now create a project for Android development:
+</p>
+<ol><li>If Eclipse asks you for a workspace location, choose the default.
+</li>
+<li>If you have a "Welcome" screen, close it to reveal the Java perspective.
+</li>
+<li>File New Java Project
+</li>
+<li>Pick a project name, "android" or anything you like.
+</li>
+<li>Select "Create project from existing source", enter the path to your Android root directory, and click Finish.
+</li>
+<li>Wait while it sets up the project. (You'll see a subtle progress meter in the lower right corner.)
+</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><i><b>Note:</b>
+</i>
+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.
+</p>
+<h4>
+When you sync
+</h4>
+<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>Window Show View Navigator
+</li>
+<li>In the "Navigator", right-click on the project ("android-java" or whatever you named it)
+</li>
+<li>Click Refresh in the context menu
+</li>
+</ol>
+<h4>
+Adding apps to the build path
+</h4>
+<p>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:
+</p>
+<ol><li>Project Properties
+</li>
+<li>Select "Java Build Path" from the left-hand menu.
+</li>
+<li>Choose the "Source" tab.
+</li>
+<li>Click "Add Folder...".
+</li>
+<li>Add your app's "src" directory.
+</li>
+<li>Click OK.
+</li>
+</ol>
+<p>When you're done, the "source folder" path in the list should look like android/packages/apps/<i>YourAppName</i>
+/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.
+</p>
+<h4>
+Eclipse setup to work on developer tools
+</h4>
+<p>To work on Java developer tools, the principle is the same, except you specify /path/to/tool when using the option "Create project from existing source."
+</p>
+<p>Once the project is created, you need to set up the Java Build Path:
+</p>
+<ol><li>Select the project you just created.
+</li>
+<li>Project Properties
+</li>
+<li>Select "Java Build Path" from the left-hand menu.
+</li>
+<li>Choose the "Source" tab.
+</li>
+<li>Expand the single<i>toolname</i>
+/src entry.
+</li>
+<li>Double click the "Excluded: (none)" item.
+</li>
+<li>Add to the excluded (bottom) list: "MakeFile" and "resources/".
+</li>
+<li>Close the dialog.
+</li>
+<li>Back in the "Source" tab, click "Add Folder...", and add<i>toolname</i>
+/src/resources.
+</li>
+<li>Click OK.
+</li>
+</ol>
+<h4>
+Eclipse setup to work on DDMS<br></h4>
+<p>For DDMS, you will need to make a project for
+</p>
+<ol><li>development/tools/ddms/libs/ddmlib
+</li>
+<li>development/tools/ddms/libs/ddmuilib
+</li>
+<li>development/tools/ddms/app
+</li>
+</ol>
+<p>Each project will need to reference the ones before it ("ddmuilib" references "ddmlib", and "app" references both of those). To do this:
+</p>
+<ol><li>Make sure you have all 3 projects defined.
+</li>
+<li>Right click on a project, "Build Path" "Configure Build Path..."
+</li>
+<li>Choose the "Project" tab.
+</li>
+<li>Click "Add..." and check the required projects.
+</li>
+</ol>
+<h2><a>Eclipse formatting</a>
+</h2>
+<p>You can use a preference file in Eclipse to automatically set the formatter to the Android style guide.Import the files android-formatting.xml and android.importorder, which live underdevelopment/ide/eclipse.
+</p>
+<h2><a>Debugging the emulator with Eclipse</a>
+</h2>
+<p>You can also use eclipse to debug the emulator and step through code. First, start the emulator running:
+</p>
+<pre>cd /path/to/android/root<br>. build/envsetup.sh<br>lunch 1 # to build the emulator<br>make # if you didn't already do this<br>emulator # you should see a GUI picture of a phone<br></pre>
+<p>In another shell, start DDMS (the Dalvik debug manager):
+</p>
+<pre>cd /path/to/android/root<br>ddms # you should get a splufty debugging console<br></pre>
+<p>Now, in eclipse, you can attach to the emulator:
+</p>
+<ol><li>Run Open Debug Dialog...
+</li>
+<li>Right-click "Remote Java Application", select "New".
+</li>
+<li>Pick a name, "android-debug" or anything you like.
+</li>
+<li>Set the "Project" to your project ("android-java" or whatever).
+</li>
+<li>Keep the "Host" set to "localhost", but change "Port" to 8700.
+</li>
+<li>Click the "Debug" button and you should be all set.
+</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><a>Bonus material</a>
+</h2>
+<p>Replace Ctrl with the Apple key on Mac.
+</p>
+
+<pre>Ctrl-Shift-o = Organize imports<br>Ctrl-Shift-t = load class by name<br>Ctrl-Shift-r = load non-class resource by name<br>Ctrl-1 = quick fix<br>Ctrl-e = Recently viewed files<br>Ctrl-space = auto complete<br>Shift-Alt-r = refactor:rename<br>Shift-Alt-v = refactor:move<br></pre>
+
+<h2><a>Useful Plugins</a>
+</h2>
+<p>Eclipse has a plugin architecture that enables third parties to extend the IDE. Here are some plugins that make Eclipse easier to use for writing Android software:
+</p>
+
+<ul><li><a href="http://andrei.gmxhome.de/anyedit/">AnyEdit</a>
+- automatically fix whitespace issues when saving files. Can convert tabs to spaces, strip blanks at end-of-line, and ensure the last line of the file has an end-of-line character.
+</li>
+</ul>
+<h2><a>"Eclipse is not working correctly, what should I do?"</a>
+</h2>
+<p>Make sure:
+</p>
+<ul><li>You followed the instructions on this page precisely.
+</li>
+<li>Your Problems view doesn't show any errors.
+</li>
+<li>Your application respects the package/directory structure.
+</li>
+</ul>
+<p>If you're still having problems, please contact one of the Android mailing lists or IRC channels.
+</p>
+</div>