Work-in-progress snapshot of the source.android.com (formerly PDK) site
refresh.
diff --git a/pdk/Pdk.mk b/pdk/Pdk.mk
index 5268384..d19b342 100644
--- a/pdk/Pdk.mk
+++ b/pdk/Pdk.mk
@@ -54,7 +54,7 @@
pdk_camera_dir := frameworks/base/include/ui
# Destination directory for docs (templates + doxygenated headers)
-pdk_docs_dest_dir := $(pdk_docs_intermediates)/docs/guide
+pdk_docs_dest_dir := $(pdk_docs_intermediates)/docs/porting
pdk_app_eng_root := $(pdk_docs_intermediates)/docs
# Working directory for source to be doxygenated
@@ -188,12 +188,12 @@
LOCAL_MODULE := online-pdk
LOCAL_DROIDDOC_OPTIONS:= \
- -toroot /online-pdk/ \
+ -toroot / \
-hdf android.whichdoc online \
-hdf android.whichmodule $(LOCAL_MODULE)
LOCAL_DROIDDOC_CUSTOM_TEMPLATE_DIR := build/tools/droiddoc/templates-pdk
-LOCAL_DROIDDOC_CUSTOM_ASSET_DIR := assets-pdk
+LOCAL_DROIDDOC_CUSTOM_ASSET_DIR := assets
include $(BUILD_DROIDDOC)
@@ -205,10 +205,6 @@
@echo "PDK: $@"
$(copy-file-to-target-with-cp)
-$(OUT_DOCS)/pdk.py: $(pdk_hosting_dir)/pdk.py
- @echo "PDK: $@"
- $(copy-file-to-target-with-cp)
-
# Name the tar files
name := android_pdk_docs-$(REQUESTED_PRODUCT)
ifeq ($(TARGET_BUILD_TYPE),debug)
@@ -232,11 +228,11 @@
$(hide) gzip -cf $< > $@
# tar up all the files to make the pdk docs.
-$(pdk_docs_tarfile): $(DOCS_OUT_DIR)-timestamp $(OUT_DOCS)/app.yaml $(OUT_DOCS)/pdk.py
+$(pdk_docs_tarfile): $(DOCS_OUT_DIR)-timestamp $(OUT_DOCS)/app.yaml
@echo "PDK docs: $@"
@mkdir -p $(dir $@)
@rm -f $@
- $(hide) tar rf $@ -C $(OUT_DOCS) $(LOCAL_MODULE) pdk.py app.yaml
+ $(hide) tar rf $@ -C $(OUT_DOCS) $(LOCAL_MODULE) app.yaml
# Debugging reporting can go here, add it as a target to get output.
pdk_debug:
diff --git a/pdk/docs/about/about_toc.cs b/pdk/docs/about/about_toc.cs
new file mode 100644
index 0000000..4676ace
--- /dev/null
+++ b/pdk/docs/about/about_toc.cs
@@ -0,0 +1,18 @@
+<script type="text/javascript" language="JavaScript">
+<!--
+function nothing() {}
+-->
+</script>
+
+<ul>
+ <li><a href="<?cs var:toroot ?>about/philosophy.html">Project Philosophy</a></li>
+ <li><a href="<?cs var:toroot ?>source/index.html">Getting Involved</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/index.html">Compatibility</a></li>
+ <li><a href="<?cs var:toroot ?>source/licenses.html">Licensing Information</a></li>
+</ul>
+
+<script type="text/javascript">
+<!--
+ buildToggleLists();
+//-->
+</script>
diff --git a/pdk/docs/about/index.jd b/pdk/docs/about/index.jd
new file mode 100644
index 0000000..2f98b65
--- /dev/null
+++ b/pdk/docs/about/index.jd
@@ -0,0 +1,20 @@
+page.title=About the Android Open Source Project
+doc.type=about
+doc.hidenav=true
+@jd:body
+<p>Android is an open-source software stack created for mobile phones and
+other devices. The Android Open Source Project (AOSP) is tasked with the
+maintenance and further development of Android. Many device manufacturers have
+brought to market devices running Android, and they are readibly available
+around the world.</p>
+<p>Our primary purpose is to build an excellent software platform for everyday
+users. A number of companies have committed many engineers to achieve this
+goal, and the result is a full production quality consumer product whose
+source is open for customization and porting.</p>
+<p>You can find more information about Android from these pages:</p>
+<ul>
+ <li><a href="{@docRoot}about/philosophy.html">Our Project Philosophy and Goals</a></li>
+ <li><a href="{@docRoot}source/index.html">Interacting with the Project</a></li>
+ <li><a href="{@docRoot}compatibility/index.html">Android Compatibility</a></li>
+ <li><a href="{@docRoot}source/licenses.html">Licensing Information</a></li>
+</ul>
diff --git a/pdk/docs/about/philosophy.jd b/pdk/docs/about/philosophy.jd
new file mode 100644
index 0000000..a1a75cc
--- /dev/null
+++ b/pdk/docs/about/philosophy.jd
@@ -0,0 +1,80 @@
+page.title=Philosophy and Goals
+doc.type=about
+@jd:body
+<div id="mainBodyFixed">
+<p>Android is an open-source software stack for mobile phones and similar
+devices. The Android Open Source Project is tasked with maintaining current
+and developing new versions of the Android software. We believe that users
+deserve to have the source code to the software they run on their devices,
+that developers deserve an open, level playing field for their apps, and that
+OEMs and carriers deserve the freedom to differentiate and innovate. That's
+why we created Android, and made the source code open.</p>
+<h2>Origin and Goal</h2>
+<p>Android was originated by a group of companies known as the Open Handset
+Alliance, led by Google. Today, many companies -- both original members of the
+OHA and others -- have invested heavily in Android, typically in the form of
+allocating significant engineering resources to improve Android and bring
+Android devices to Market.</p>
+<p>We created Android in response to our own experiences launching mobile
+apps. We wanted to make sure that there would always be an open platform
+available for carriers, OEMs, and developers to use to make their innovative
+ideas a reality. We wanted to make sure that there was no central point of
+failure, where one industry player could restrict or control the innovations
+of any other. The solution we chose was an open and open-source platform.</p>
+<p>But the ultimate goal, of course, is to improve the mobile experience for
+real users by facilitating innovation. Accordingly, the primary goal of the
+AOSP is to make sure Android is a success as an end user product.</p>
+<h2>Governance Philosophy</h2>
+<p>The companies that have invested in Android have done so on its merits,
+because we collectively believe that an open platform is necessary. In some
+ways, Android is the purest form of an open-source (as opposed to free
+software) effort: a group of organizations with shared needs has pooled
+resources to collaborate on a single implementation of a shared product. That
+is, the Android philosophy is pragmatic, first and foremost. The objective is
+a shared product that each contributor can tailor and customize.</p>
+<p>Uncontrolled customization can, of course, lead to incompatibile
+implementations. To prevent this, the AOSP also maintains the Android
+Compatibility Program, which spells out what it means to be "Android
+compatible", and what is required of device builders to achieve that status.
+Anyone can (and will!) use the Android source code for any purpose, and we
+welcome all such uses. However, in order to take part in the shared
+ecosystem that we are building around Android, device builders can take
+advantage of the Compatibility Program.</p>
+<p>Though Android consists of multiple sub-projects, this is strictly a
+project-management technique. We view and manage Android as a single,
+holistic software product, not a "distribution", specification, or collection
+of replaceable parts. Conceptually, our notion is that device builders port
+Android to a device; they don't implement a specification or curate a
+distribution.</p>
+<h2>How We Work</h2>
+<p>We know that quality does not come without hard work. The
+members of the Android Open Source Project have contributed full-time
+engineers, product managers, UI designers, Quality Assurance, and all the
+other roles required to launch modern devices in the modern marketplace.
+We integrate the open source administration and maintenance into the larger
+product development cycle.</p>
+<p>In a nutshell:</p>
+<ul>
+<li>At any given moment, there is a current latest release of the Android
+platform. This typically takes the form of a branch in the tree.</li>
+<li>AOSP members, device builders, and contributors work with the current
+latest release, fixing bugs, launching new devices, experimenting with new
+features, and so on.</li>
+<li>In parallel, the AOSP members work internally on the next version of the
+Android platform and framework, working according to the product's needs and
+goals. Some of the work from the current latest tree will promoted into these
+releases.</li>
+<li>When the "n+1"th version is determined to be nearing completion, it will
+be published to the public source tree, and become the new latest
+release.</li>
+<li>Since Android is open source, nothing prevents device implementers from
+shipping devices on older (obsolete) Android builds. However, active work will
+be focused on the current platform release.</li>
+</ul>
+<p>To meet our goals, Android needs to achieve widespread, compatible
+adoption. We believe that the best way to accomplish that is to make sure that
+we ship high-quality, flagship devices with an intense product and end-user
+focus. The "next release" of Android is driven by the product needs for the next
+generation of mobile devices; the resulting excellent product is then released
+to open source and becomes the new current version of the platform.</p>
+</div>
diff --git a/pdk/docs/community/community_toc.cs b/pdk/docs/community/community_toc.cs
new file mode 100644
index 0000000..1f4094e
--- /dev/null
+++ b/pdk/docs/community/community_toc.cs
@@ -0,0 +1,24 @@
+<script type="text/javascript" language="JavaScript">
+<!--
+function nothing() {}
+-->
+</script>
+<ul>
+ <li><h2>Discussion Groups</h2><ul>
+ <li><a href="http://groups.google.com/group/android-platform">android-platform</a></li>
+ <li><a href="http://groups.google.com/group/android-porting">android-porting</a></li>
+ <li><a href="http://groups.google.com/group/android-kernel">android-kernel</a></li>
+ <li><a href="http://groups.google.com/group/repo-discuss">repo-discuss</a></li>
+ <li><a href="http://groups.google.com/group/android-framework">android-framework</a></li>
+ </ul></li>
+ <li><h2>Other Links</h2><ul>
+ <li><a href="<?cs var:toroot ?>community/groups-charter.html">Groups Charter</a></li>
+ <li><a href="http://developer.android.com/community/index.html">App Developer Groups</a></li>
+ </ul></li>
+</ul>
+<script type="text/javascript">
+<!--
+ buildToggleLists();
+//-->
+</script>
+
diff --git a/pdk/docs/community/groups-charter.jd b/pdk/docs/community/groups-charter.jd
new file mode 100644
index 0000000..69381d9
--- /dev/null
+++ b/pdk/docs/community/groups-charter.jd
@@ -0,0 +1,50 @@
+page.title=Android Discussion Groups Charter
+doc.type=community
+@jd:body
+<h3><b>Android mailing lists charter</b>
+</h3>
+<div><div><div><div><div><p><b>Contents</b>
+</p>
+<ol><li><a href="#TOC-Audience"><b>1</b>
+Audience</a>
+</li>
+<li><a href="#TOC-Mailing-list-rules"><b>2</b>
+Mailing list rules</a>
+</li>
+<li><a href="#TOC-Contacting-the-moderators"><b>3</b>
+Contacting the moderators</a>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<h2>
+Audience
+</h2>
+<p>These discussion groups are intended for developers working with the Android platform. Everyone is welcome to join in, provided you follow our community's policies described below. Our users help each other, and many experts post to these groups, including members of the Open Handset Alliance.
+</p>
+<p>No topic is off-limits, provided it relates to Android in some way. However, since these are very busy lists, search the archives before posting your question; you may find your question has already been answered.
+</p>
+<h2>
+Mailing list rules
+</h2>
+<p>We love simplicity and hate restrictions, so we keep our policies minimal. The rules below describe what's expected of subscribers to the Android mailing lists.
+</p>
+<ul><li><b>Please be friendly</b>
+<br>Showing courtesy and respect to others is a vital part of the Android culture, and we expect everyone participating in the Android community to join us in accepting nothing less. Being courteous does not mean we can't constructively disagree with each other, but it does mean that we must be polite when we do so. There's never a reason to be antagonistic or dismissive toward anyone; if you think there is, think again before you post.<br><br>Mobile development is serious business, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source.<br><br></li>
+<li><b>Allowed discussion topics</b>
+<br>Most topics are technical discussions of Android or users helping each other, but this group is intended for discussions of<i>everything</i>
+in the world of Android. We welcome announcements and discussion of products, libraries, publications, and other interesting Android-related news. We even welcome (polite!) discussion of articles and ideas critical of Android--after all, we can't improve if we don't listen. There are no restrictions on the subject matter, and we don't exclude discussions of commercial products if users are interested in talking about them.<br><br>However, we hate spam almost as passionately as we love courtesy and respect, so we reserve the right to limit discussions that amount to spam. Outright spam will result in the spammer being immediately and permanently banned from the list.
+</li>
+</ul>
+<p>The most important rule is friendliness. Remember: disrespect and rudeness are not welcome in our community under any circumstances. We don't have a formal policy on dealing with troublemakers, and we hope we never need one.That said, we do pledge to do our best to be fair, and we will always try to warn someone before banning him or her.
+</p>
+<h2>
+Contacting the moderators
+</h2>
+<p>If you see anyone being rude, call them out on it. This is your group too, and you don't have to accept someone else being disrespectful just because it wasn't directed at you. Just remember to be polite and courteous yourself! Don't add fuel to the fire.
+</p>
+<p>But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!
+</p>
+</div>
diff --git a/pdk/docs/community/index.jd b/pdk/docs/community/index.jd
index bc04eee..d00838f 100644
--- a/pdk/docs/community/index.jd
+++ b/pdk/docs/community/index.jd
@@ -1,6 +1,122 @@
-home=true
+page.title=Community
+doc.type=community
@jd:body
+<h1>Android Community</h1>
+<p>Welcome to the Android community!</p>
+<p>The key to any community is, obviously, communication. Like most projects,
+Android communicates via mailing lists. Because Android is an extremely large
+project with many components, we have many discussion forums, each focusing on
+a different topic.</p>
+<p>Please check out the groups below, and join any that seem interesting to
+you. Note that if you're a user looking for help with your Android device,
+this page probably isn't for you; you should contact your carrier or retailer
+for help with your phone.</p>
+<p>Please note that if you're looking for information about building
+applications for Android, you can find a separate set of groups for those at
+our sister site, developer.android.com: <a
+href="http://developer.android.com/community/index.html">http://developer.android.com/community/index.html</a></p>
-<p>
- Some community information here
-</p>
+<h2>Getting the Most from Our Lists</h2>
+<p>Please consider the following before you post to our lists.</p>
+<ol>
+ <li><b>Read the <a
+ href="{@docRoot}community/groups-charter.html">Charter
+ for our forums.</a></b> This explains the (few) rules and guidelines for our
+ community.<br></li>
+ <li><b>Search the group archives to see whether your questions have already
+ been discussed.</b></li> This avoids time-wasting redundant discussions.
+ <li><b>Use a clear, relevant message subject.</b> This helps everyone,
+ both those trying to answer your question as well as those who may be
+ looking for information in the future.</li>
+ <li><b>Give plenty of details in your post.</b> Code or log snippets,
+ pointers to screenshots, and similar details will get better results and
+ make for better discussions. For a great guide to phrasing your questions,
+ read <a href="http://www.catb.org/%7Eesr/faqs/smart-questions.html">How To
+ Ask Questions The Smart Way</a>.</li>
+</ol>
+<h2>Open Source Project discussions</h2>
+<ul>
+<li><b>android-platform</b><br/>
+This list is for developers who want to contribute code to the Android
+user-space projects, such as the core system libraries, the Android
+services, the public APIs, or the built-in applications. Before posting,
+please be sure you've downloaded the source code, compiled it, read through
+it, and are at the point where you're going to be making changes of your own
+to contribute into the Android source code. You can use this list to
+coordinate your efforts with those of other contributors, and
+discuss architecture, design and implementation. Please use android-kernel for
+discussions about contributing to the kernel, android-porting if you're
+porting Android to your own hardware or making changes that you're not going
+to contribute back, android-developers if you're writing applications with the
+SDK, or android-discuss for everything else.<br/><br/>
+Subscribe using Google Groups: <a
+href="http://groups.google.com/group/android-platform">android-platform</a><br/>
+Subscribe via email: <a href="mailto:android-platform+subscribe@googlegroups.com">android-platform+subscribe@googlegroups.com</a>
+</li>
+
+<li><b>android-porting</b><br/>
+This list is for developers who want to port Android to a new device. If
+you're wondering how to combine the Android source code with your hardware,
+this is the right group for you. Discuss here the specifics of porting Android
+to individual devices, from obtaining toolchains and merging kernel drivers
+all the way to configuring or modifying applications for your specific
+configuration.<br/><br/>
+Subscribe using Google Groups: <a
+href="http://groups.google.com/group/android-porting">android-porting</a><br/>
+Subscribe via email: <a href="mailto:android-porting+subscribe@googlegroups.com">android-porting+subscribe@googlegroups.com</a>
+</li>
+
+<li><b>android-kernel</b><br/>
+This list is for deveopers who want to contribute to the Linux kernel that
+Android devices use. If you've downloaded the kernel code, if you know how to
+compile it, if you want to write kernel code to specifically support Android,
+this is your place. This group isn't for user-space topics (see
+android-platform for that), and people will shake their fingers at you and
+call you naughty if you ask user-space questions here.<br/><br/>
+Subscribe using Google Groups: <a
+href="http://groups.google.com/group/android-kernel">android-kernel</a><br/>
+Subscribe via email: <a href="mailto:android-kernel+subscribe@googlegroups.com">android-kernel+subscribe@googlegroups.com</a>
+</li>
+
+<li><b>Repo and Gerrit discussion</b><br/>
+This list is for discussions on everything related to the process used to
+manage the Android source code with repo and gerrit: downloading the source
+code, submitting changes for review, commenting on code being reviewed,
+submitting changes for the world to enjoy.<br/><br/>
+Subscribe using Google Groups: <a
+href="http://groups.google.com/group/repo-discuss">repo-discuss</a><br/>
+Subscribe via email: <a href="mailto:repo-discuss+subscribe@googlegroups.com">repo-discuss+subscribe@googlegroups.com</a>
+</li>
+</ul>
+
+<h2>Using email with Google Groups</h2>
+<p>Instead of using the <a href="http://groups.google.com/">Google Groups</a>
+site, you can use your email client of choice to participate in the mailing lists.</p>
+<p>To subscribe to a group without using the Google Groups site, use the link
+under "subscribe via email" in the lists above.</p>
+<p>To set up how you receive mailing list postings by email:</p>
+<ol>
+<li>Sign into the group via the Google Groups site. For example, for the android-framework group you would
+visit <a
+href="http://groups.google.com/group/android-framework">http://groups.google.com/group/android-framework</a>.</li>
+<li>Click "Edit my membership" on the right side.</li>
+<li>Under "How do you want to read this group?" select one of the email options.</li>
+</ol>
+
+<h2>Android on IRC</h2>
+<p>We also have a presence on IRC via Freenode. We maintain two official IRC
+channels on irc.freenode.net:</p>
+<ul>
+<li><b>#android</b> - dedicated to general Android discussion and porting concerns</li>
+<li><b>#android-dev</b> - dedicated to discussion about writing Android applications</li>
+</ul>
+<p>The channels above are official. There are a few other channels the
+community is using, but are not official. These aren't official or officially
+moderated/managed, so you use the channels below at your own risk. The Open
+Handset Alliance doesn't endorse these channels, there's no warranty express
+or implied, and so on. There may be more.</p>
+<ul>
+<li><b>#android-offtopic</b> - for, well, off-topic discussions</li>
+<li><b>#android-root</b> - for discussion related to off-label uses of hardware</li>
+<li><b>#androidfra</b> - pour discuter d'Android en français</li>
+</ul>
diff --git a/pdk/docs/compatibility/compatibility_toc.cs b/pdk/docs/compatibility/compatibility_toc.cs
index 3952495..8e16bc8 100644
--- a/pdk/docs/compatibility/compatibility_toc.cs
+++ b/pdk/docs/compatibility/compatibility_toc.cs
@@ -5,23 +5,17 @@
</script>
<ul>
- <li> <h2>Program Details </h2>
- <ul>
- <li><a href="">Program Overview</a></li>
- <li><a href="">Getting Started</a></li>
- <li><a href="">Contact Us</a></li>
- </ul>
- </li>
+ <li><h2>Getting Started</h2><ul>
+ <li><a href="<?cs var:toroot ?>compatibility/overview.html">Compatibility Overview</a></li>
+ <li><a href="">Current CDD</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/cts-intro.html">CTS Introduction</a></li>
+ </ul></li>
- <li> <h2>Compatibility Tools </h2>
- <ul>
- <li><a href="">Compatibility Definition</a></li>
- <li><a href="">Compatibility Test Suite</a></li>
- <li><a href="">Compatibility FAQ</a></li>
- <li><a href="">Downloads</a></li>
- </ul>
- </li>
-
+ <li><h2>More Information</h2><ul>
+ <li><a href="<?cs var:toroot ?>downloads/index.html">Downloads</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/faq.html">FAQ</a></li>
+ <li><a href="<?cs var:toroot ?>compatibility/contact-us.html">Contact Us</a></li>
+ </ul></li>
</ul>
<script type="text/javascript">
diff --git a/pdk/docs/compatibility/contact-us.jd b/pdk/docs/compatibility/contact-us.jd
new file mode 100644
index 0000000..92062ba
--- /dev/null
+++ b/pdk/docs/compatibility/contact-us.jd
@@ -0,0 +1,28 @@
+page.title=Android Compatibility - Contact Us
+doc.type=compatibility
+@jd:body
+<h3><b>Mailing list</b>
+</h3>
+<div><div>Welcome to the Android compatibility mailing list!<br>
+To get the most out of the mailing list discussions, please do the following before you post:
+<ol><li><b>Read the<a href="http://sites.google.com/a/android.com/opensource/discuss/android-discussion-groups-charter">mailing list charter</a>
+</b>
+that covers the community guidelines.<br><br></li>
+<li><b>Search the mailing list archives</b>
+to see whether your questions have already been discussed.<br><br></li>
+<li><b>Be very clear</b>
+about your question in the subject -- it helps everyone, both those trying to answer your question as well as those who may be looking for information in the future.<br><br></li>
+<li><b>Give plenty of details</b>
+in your post to help others understand your problem. Code or log snippets, as well as pointers to screenshots, may also be helpful. For a great guide to phrasing your questions, read<a href="http://www.google.com/url?q=http%3A%2F%2Fwww.catb.org%2F%257Eesr%2Ffaqs%2Fsmart-questions.html&sa=D&sntz=1&usg=AFrqEzd169OWM-dgsNW_9rDKrOgOJqgpEA">How To Ask Questions The Smart Way</a>
+.
+</li>
+</ol>
+<br>There are two ways to join the Android compatibility mailing list:<br></div>
+<ul><li>Visit the<a href="http://groups.google.com/group/android-compatibility">android-compatibility sign-up page</a>
+on Google Groups, or
+</li>
+<li>Send email to<a href="mailto:android-compatibility-subscribe@googlegroups.com">android-compatibility-subscribe@googlegroups.com</a>
+.
+</li>
+</ul>
+</div>
diff --git a/pdk/docs/compatibility/cts-intro.jd b/pdk/docs/compatibility/cts-intro.jd
new file mode 100644
index 0000000..b575b11
--- /dev/null
+++ b/pdk/docs/compatibility/cts-intro.jd
@@ -0,0 +1,98 @@
+page.title=Android Compatibility - Compatibility Test Suite
+doc.type=compatibility
+@jd:body
+<h3><b>Compatibility test suite (CTS)</b>
+</h3>
+<b>Contents</b>
+<ol>
+<li><a href="#TOC-How-does-the-CTS-work-">How does the CTS work?</a></li>
+<li><a href="#TOC-Workflow">Workflow</a></li>
+<li><a href="#TOC-Types-of-test-cases">Types of test cases</a></li>
+<li><a href="#TOC-Areas-Covered">Areas Covered</a></li>
+</ol>
+
+<h3>How does the CTS work?</h3>
+<div><img src="{@docRoot}images/cts-0.png"></div>
+<div>The CTS is an automated testing harness that includes two major software components:</div>
+<ul>
+<li>The CTS test harness runs on your desktop machine and manages test execution.</li>
+<li>Individual test cases are executed on attached mobile devices or on an emulator. The test cases are written in Java as JUnit tests and packaged as Android .apk files to run on the actual device target.</li>
+</ul>
+
+<h3>Workflow</h3>
+<ol>
+<li>Use the bundled CTS release or download the CTS from the Android Open Source Project onto your desktop machine.</li>
+<li>Install and configure the CTS.</li>
+<li>Attach at least one device (or emulator) to your machine.</li>
+<li>Launch the CTS. The CTS test harness loads the test plan onto the attached devices. For each test in the test harness:
+ <ul>
+ <li>The test harness pushes a .apk file to each device, executes the test through instrumentation, and records test results.</li>
+ <li>The test harness removes the .apk file from each device.</li>
+ </ul>
+</li>
+<li>Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.</li>
+<li>If you see test failures, follow the instructions on the<a href="http://sites.google.com/a/android.com/compatibility/compatibility-faq">Compatibility FAQ</a>
+page.</li>
+</ol>
+<div>When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.</div>
+
+<h3>Types of test cases</h3>
+The CTS includes the following types of test cases:
+<ul>
+<li><i>Unit tests</i> test atomic units of code within the Android platform; e.g. a single class, such as java.util.HashMap.</li>
+<li><i>Functional tests</i> test a combination of APIs together in a higher-level use-case.</li>
+<li><i>Reference application tests</i> instrument a complete sample application to exercise a full set of APIs and Android runtime services</li>
+</ul>
+<div>Future versions of the CTS will include the following types of test cases:</div>
+<ul>
+<li><i>Robustness tests</i> test the durability of the system under stress.</li>
+<li><i>Performance tests</i> test the performance of the system against defined benchmarks, for example rendering frames per second.</li>
+</ul>
+
+<h3>Areas Covered</h3>
+The unit test cases cover the following areas to ensure compatibility<br>
+<table><tbody>
+<tr><td>Area</td><td>Description<br></td></tr>
+<tr><td>Signature tests</td>
+<td>For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
+</td>
+</tr>
+<tr><td>Platform API Tests</td>
+<td>Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK<a href="http://code.google.com/android/reference/classes.html">Class Index</a>
+to ensure API correctness:
+<ul>
+<li>correct class, attribute and method signatures</li>
+<li>correct method behavior</li>
+<li>negative tests to ensure expected behavior for incorrect parameter handling</li>
+</ul>
+</td></tr>
+<tr><td>Dalvik VM Tests</td><td>The tests focus on testing the Dalvik VM</td></tr>
+<tr><td>Platform Data Model</td>
+<td>The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK<a href="http://code.google.com/android/reference/android/provider/package-summary.html">android.provider</a>
+package:
+<ul>
+<li>contacts</li>
+<li>browser</li>
+<li>settings</li>
+<li>more...</li>
+</ul>
+</td></tr>
+<tr><td>Platform Intents</td>
+<td>The CTS tests the core platform intents, as documented in the SDK<a href="http://code.google.com/android/reference/available-intents.html">Available Intents</a>.</td>
+</tr>
+<tr><td>Platform Permissions</td>
+<td>The CTS tests the core platform permissions, as documented in the SDK<a href="http://code.google.com/android/reference/android/Manifest.permission.html">Available Permissions</a>.</td>
+</tr>
+<tr><td>Platform Resources<br></td>
+<td>The CTS tests for correct handling of the core platform resource types, as documented in the SDK<a href="http://code.google.com/android/reference/available-resources.html">Available Resource Types</a>
+. This includes tests for:
+<ul>
+<li>simple values</li>
+<li>drawables</li>
+<li>nine-patch</li>
+<li>animations</li>
+<li>layouts</li>
+<li>styles and themes</li>
+<li>loading alternate resources</li>
+</ul></td></tr>
+</tbody></table>
diff --git a/pdk/docs/compatibility/faq.jd b/pdk/docs/compatibility/faq.jd
new file mode 100644
index 0000000..71a193d
--- /dev/null
+++ b/pdk/docs/compatibility/faq.jd
@@ -0,0 +1,124 @@
+page.title=Android Compatibility - Frequently Asked Questions
+doc.type=compatibility
+@jd:body
+
+<h3><b>Compatibility FAQ</b></h3>
+<div><div><div><div><div><div><p><b>Contents</b>
+</p>
+<ol><li><a href="#TOC-The-CTS-report-shows-test-failures-"><b>1</b>
+The CTS report shows test failures -- what should I do now?</a>
+</li>
+<li><a href="#TOC-Android-1.5-CTS-r1-known-issues"><b>2</b>
+Android 1.5 CTS r1 known issues</a>
+</li>
+<li><a href="#TOC-Can-I-remove-the-final-modifier-fro"><b>3</b>
+Can I remove the 'final' modifier from classes in the Android public APIs and still be an Android-compatible device?</a>
+</li>
+<li><a href="#TOC-I-see-a-failure-in-my-report-with-t"><b>4</b>
+I see a failure in my report with the comment "A test that was a known failure actually passed. Please check." -- what does this mean?</a>
+</li>
+<li><a href="#TOC-Why-are-compass-and-accelerometer-r"><b>5</b>
+Why are compass and accelerometer required for Android compatibility?</a>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<h3>
+The CTS report shows test failures -- what should I do now?
+</h3>
+<div><div><b>Step 1: Get the latest CTS version.</b>
+Make sure you are running the latest version of CTS -- check if your version is the same as the one posted on the<a href="http://sites.google.com/a/android.com/compatibility/download-cts">Downloads</a>
+page. If not, make sure you update to the latest version and re-run CTS. As we find issues in CTS, we push out new versions with fixes to the tests and/or frame-work. Using the latest version minimizes the chances of you facing any CTS specific issues.
+</div>
+<div><br></div>
+<div><b>Step 2: Investigate the CTS source code.</b>
+Make sure you have grabbed the CTS sources provided on the<a href="http://sites.google.com/a/android.com/compatibility/download-cts">Download</a>
+page. Then unzip the CTS report zip$CTS_ROOT/repository/results/start time.zipand opentestResult.xmlin your favorite browser. Find the exception next to the failing test and check the corresponding source file for possible failure causes.</div>
+<div><br></div>
+<div><b>Step 3: Fix the error in your source and re-run CTS.</b>
+Once you have located the cause of failure in your source code, fix it and re-run CTS.
+</div>
+<div><br></div>
+<div><b>Step 4: The test is broken.</b>
+If you think the CTS test is incorrect or is not testing things the right way, shoot a detailed email to cts@android.com with the following information at the minimum - the failing test, why you think the CTS test is broken, your CTS test report and the log generated by your CTS run (text file in the$CTS_ROOT/repository/results/directory corresponding to timestamp of run).</div>
+<div><br></div>
+<h3>
+Android 1.5 CTS r1 known issues
+</h3>
+<div>android.app.cts.ActivityManagerTest#testGetRunningServices - known issue test, waived automatically</div>
+<div>android.graphics.cts.BitmapTest#testCopyPixelsToBuffer - can be an issue if device uses a pixel format like ARGB (4 bytes per pixel)</div>
+<div>tests.api.java.io.OutputStreamWriterTest.test_write$C(OutputStreamWriterTest.java:470) - test breaks in 1.5 r3</div>
+<div><br></div>
+<div><b>The following tests have known issues with non en_US locales:</b>
+</div>
+<div>tests.api.java.io.PrintStreamTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object<br>tests.api.java.io.PrintStreamTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object<br>tests.api.java.io.PrintWriterTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object<br>tests.api.java.io.PrintWriterTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object<br>tests.api.java.util.CalendarTest#test_hashCode<br>tests.api.java.util.CalendarTest#test_getFirstDayOfWeek<br>tests.api.java.util.CalendarTest#test_getInstanceLjava_util_Locale<br>tests.api.java.util.CalendarTest#test_getInstanceLjava_util_TimeZoneLjava_util_Locale<br>tests.api.java.util.CalendarTest#test_getMinimalDaysInFirstWeek<br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_ByteShortIntegerLongConversionD<br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_DateTimeConversion<br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$LBigInteger<br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_BigIntegerPaddingConversion<br>tests.api.java.util.FormatterTest#test_formatLjava_util_LocaleLjava_lang_StringLjava_lang_Object<br>tests.api.java.util.GregorianCalendarTest#test_ConstructorLjava_util_Locale<br>tests.api.java.util.LocaleTest#test_getDisplayCountryLjava_util_Locale<br>tests.api.java.util.LocaleTest#test_getDisplayLanguageLjava_util_Locale<br>tests.api.java.util.LocaleTest#test_getDisplayNameLjava_util_Locale<br>tests.api.java.util.ScannerTest#test_nextDouble<br>tests.api.java.util.ScannerTest#test_nextFloat<br>tests.api.java.util.ScannerTest#test_nextInt<br>tests.api.java.util.ScannerTest#test_nextIntI<br>tests.api.java.util.ScannerTest#test_nextLong<br>tests.api.java.util.ScannerTest#test_nextShortI<br>tests.api.java.util.ScannerTest#test_nextShort<br>tests.api.java.util.ScannerTest#test_nextLongI<br>tests.api.java.util.ScannerTest#test_hasNextIntI<br>tests.api.java.util.ScannerTest#test_hasNextInt<br>tests.api.java.util.ScannerTest#test_hasNextFloat<br>tests.api.java.util.ScannerTest#test_hasNextShortI<br>tests.api.java.util.ScannerTest#test_hasNextShort<br>tests.api.java.util.ScannerTest#test_hasNextLongI<br>tests.api.java.util.ScannerTest#test_hasNextLong<br>tests.api.java.util.ScannerTest#test_hasNextDouble<br>tests.api.java.util.ScannerTest#test_hasNextBigDecimal<br>tests.api.java.util.ScannerTest#test_nextBigDecimal<br>tests.api.java.util.TimeZoneTest#test_getDisplayNameLjava_util_Locale<br>tests.api.java.util.TimeZoneTest#test_getDisplayNameZILjava_util_Locale<br>org.apache.harmony.text.tests.java.text.DateFormatTest#test_getAvailableLocales<br>org.apache.harmony.text.tests.java.text.DecimalFormatSymbolsTest#test_getCurrency<br>org.apache.harmony.text.tests.java.text.DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_Object<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getInstanceLjava_util_Locale<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_parseObjectLjava_lang_StringLjava_text_ParsePosition<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getIntegerInstanceLjava_util_Locale<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLdouble<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLlong<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getCurrencyInstanceLjava_util_Locale<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getNumberInstanceLjava_util_Locale<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getPercentInstanceLjava_util_Locale<br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_setGroupingUsed<br><br></div>
+<div><br></div>
+<h3>
+Can I remove the 'final' modifier from classes in the Android public APIs and still be an Android-compatible device?
+</h3>
+<div>Let's take the following example, where you want to extend the base Contacts class to create your own version of the class. Android 1.5 supports SDK add-ons that OEMs can create to expose new functionality and platform APIs specific to the phone. However, the SDK add-on architecture does not allow the add-on provider to include their own android.jar Thus, when you expose your new Contacts class (which expects to extend the base Contacts class) developers using your add-on plugin will be unable to compile and run their applications against the standard android.jar containing the *final* Contacts class.</div>
+<div><div><br></div>
+<div>The recommended approach is to create a new class with the specific fields that you want to add and access these fields from the new class. This will not only ensure compatibility but will also ensure a safer and easier update path when the Android schema/implementation changes with future releases. This is illustrated in the following example:</div>
+<div><div><br></div>
+<div><p>public /* final */ class BaseClass {</p>
+<p>/* private */ protected BaseClass() { }</p>
+<br>
+<p>public static final String SOME_FIELD = "base";</p>
+<p>// If this is declared final, WrongApproach.java won't compile.</p>
+<p>// In Contacts.People, it is not declared final (it didn't need to since the class was final)</p>
+<p>public static /* final */ String frungulate() { return "foo"; }</p>
+<p>}</p>
+<br>
+<p>public final class CorrectApproach {</p>
+<p>public static final String SOME_FIELD = "some";</p>
+
+<p>public static final String frungulate() { return "bar"; }</p>
+<p>}</p>
+<br>
+<p>public class WrongApproach extends BaseClass {</p>
+<p>public static final String SOME_FIELD = "some";</p>
+
+<p>public static final String frungulate() { return "bar"; }</p>
+
+<p>public static void main(String[] args) {</p>
+<p>WrongApproach m = new WrongApproach();</p>
+<p>System.out.println(m.SOME_FIELD);</p>
+<p>System.out.println(m.frungulate());</p>
+
+<p>// What should be done...</p>
+<p>System.out.println(CorrectApproach.SOME_FIELD);</p>
+<p>System.out.println(CorrectApproach.frungulate());</p>
+<p>}</p>
+<p>}</p>
+</div>
+<div></div>
+</div>
+</div>
+<div><br></div>
+<h3>
+I see a failure in my report with the comment "A test that was a known failure actually passed. Please check." -- what does this mean?
+</h3>
+<div>A "known failure" test is one that fails when run against our own implementation on G1 or Magic, hence it gets tagged as such and does not count towards your failure. However, if the test suddenly starts passing on your implementation this is not the expected result causing it to show up as a failure then.
+</div>
+<div><br>You should dig into the test source to see whats happening underneath.<br><br></div>
+<h3>
+Why are compass and accelerometer required for Android compatibility?
+</h3>
+<div>Whenever possible, we try to open up hardware options by making the Android software smarter.For example, in Android 1.5 we added an Input Method Framework and soft keyboard so that devices didn't need physical text input devices.The Android<i>Donut</i>
+release will the ability to scale application windows to different densities and resolutions so that devices aren't restricted to 160-180dpi HVGA displays.<br><br>Unfortunately, software can only do so much, and a compass and accelerometer are things Android cannot replace with software.These two input devices are now commonly used by applications.For example, many of the most popular applications in Android Market:<br><br>-<a href="http://www.android.com/market/featured.html#app=skymap"><i>Google Sky Map</i>
+</a>
+uses compass and accelerometer<br>-<a href="http://www.android.com/market/free.html#app=labyrinth"><i>Labyrinth</i>
+</a>
+uses accelerometer<br>-<a href="http://www.android.com/market/free.html#app=bonsaiblast"><i>Bonzai Blast</i>
+</a>
+uses accelerometer<br>-<a href="http://www.android.com/market/featured.html#app=wikitude"><i>Wikitude</i>
+</a>
+uses compass and accelerometer<br>-<a href="http://www.android.com/market/featured.html#app=zagatnru"><i>Zagat</i>
+</a>
+uses compass<br><br>As Market has no way of knowing whether an application uses these controls, we would not be able to filter these out of Android Market for devices which don't have the required hardware.This would create a bad user experience and could hurt the Android ecosystem if developers can no longer rely on these features in handsets, or receive bad reviews from consumers who have devices which can't support the features.<br></div>
+<div><br></div>
+</div>
+</div>
diff --git a/pdk/docs/compatibility/index.jd b/pdk/docs/compatibility/index.jd
index 964fdf7..9f62872 100644
--- a/pdk/docs/compatibility/index.jd
+++ b/pdk/docs/compatibility/index.jd
@@ -1,11 +1,60 @@
-home=true
+page.title=Android Compatibility
doc.type=compatibility
@jd:body
+<p>Android is an open source product, and anyone can use the source code to build
+devices. Incautious implementations, however, can easily introduce bugs that
+cause third-party applications to break. The purpose of the Android
+Compatibility Program is to help Android device implementations remain
+compatible with all apps.</p>
+<h2>Why build compatible Android devices?</h2>
+<h3>Users want a customizable device.</h3>
+<p>A mobile phone is a highly personal, always-on, always-present gateway to
+the Internet. We haven't met a user yet who didn't want to customize it by
+extending its functionality. That's why Android was designed as a robust
+platform for running after-market applications.</p>
-<div id="mainBodyFixed">
+<h3>Developers outnumber us all.</h3>
+<p>No device manufacturer can hope to write all the software that anyone could
+conceivably need. We need third-party developers to write the apps users want,
+so the Android Open Source Project aims to make it as easy and open as
+possible for developers to build apps.</p>
-<p>
-Compatibility start page goes here
-</p>
+<h3>Everyone needs a common ecosystem.</h3>
+<p>Every line of code developers write to work around a particular phone's bug
+is a line of code that didn't add a new feature. The more compatible phones
+there are, the more apps there will be. By building a fully compatible Android
+device, you benefit from the huge pool of apps written for Android, while
+increasing the incentive for developers to build more of those apps.</p>
-</div>
+
+<h2>Android compatibility is free, and it's easy.</h2>
+<p>If you are building a mobile device, you can follow these steps to make
+sure your device is compatible with Android. For more details about the
+Android compatibility program in general, see <a
+href="{@docRoot}compatibility/overview.html">the program overview</a>.</p>
+<p>Building a compatible device is a four-step process:</p>
+<ol>
+ <li><b>Obtain the Android software stack source code</b><p>This is the
+ <a href="{@docRoot}source/index.html">source code for the Android
+ platform</a>, that you port to your hardware.</p></li>
+ <li><b>Comply with Android Compatibility Definition Document</b><p>
+ This document enumerates the software and the hardware features of
+ a compatible Android device.</p></li>
+ <li><b>Pass the Compatibility Test Suite (CTS)</b><p>You can use the CTS
+ as an ongoing aid to compatibility during the development process.</p></li>
+ <li><b>Submit CTS report</b><p>[Optional] You can also submit your CTS report,
+ so that it can be validated and recorded.</p><p><i>Note:
+ the submission system is currently under construciton, and is not currently
+ available.</i></p></li>
+</ol>
+
+<h2>Benefits of compatibility</h2>
+<p>By submitting a validated CTS report, you receive public recognition of
+your device's compatibility. This also opens up additional options you can
+pursue such as use of the Android branding, access to Android Market, and
+more.</p>
+<p>As a consequence of some legal quirks, we aren't able to offer automatic
+licensing of either the Android Market or branding. To actually obtain access
+to these programs, you will need to <a
+href="{@docRoot}compatibility/contact-us.html">contact us</a> to obtain a
+license.</p>
diff --git a/pdk/docs/compatibility/overview.jd b/pdk/docs/compatibility/overview.jd
new file mode 100644
index 0000000..039e2c2
--- /dev/null
+++ b/pdk/docs/compatibility/overview.jd
@@ -0,0 +1,88 @@
+page.title=Compatibility Program Overview
+doc.type=compatibility
+@jd:body
+<p>The Android compatibility program makes it easy for mobile device
+manufacturers to develop compatible Android devices.</p>
+<h3>Program goals</h3>
+<p>The Android compatibility program works for the benefit of the entire
+Android community, including users, developers, and device manufacturers.</p>
+<p>Each group depends on the others. Users want a wide selection of devices
+and great apps; great apps come from developers motivated by a large market
+for their apps with many devices in users' hands; device manufacturers rely
+on a wide variety of great apps to increase their products' value for
+consumers.</p>
+<p>Our goals were designed to benefit each of these groups:</p>
+<ul>
+<li><b>Provide a consistent application and hardware environment to application
+developers.</b><p>Without a strong compatibility standard, devices can vary so
+greatly that developers must design different versions of their applications
+for different devices. The compatibility program provides a precise definition
+of what developers can expect from a compatible device in terms of APIs and
+capabilities. Developers can use this information to make good design
+decisions, and be confident that their apps will run well on any compatible
+device.</p></li>
+<li><b>Enable a consistent application experience for consumers.</b><p>If an
+application runs well on one compatible Android device, it should run well on
+any other device that is compatible with the same Android platform version.
+Android devices will differ in hardware and software capabilities, so the
+compatibility program also provides the tools needed for distribution systems
+such as Android Market to implement appropriate filtering. This means that
+users can only see applications which they can actually run.</p></li>
+<li><b>Enable device manufacturers to differentiate while being
+compatible.</b><p>The Android compatibility program focuses on the aspects of
+Android relevant to running third-party applications, which allows device
+manufacturers the flexibility to create unique devices that are nonetheless
+compatible.</p></li>
+<li><b>Minimize costs and overhead associated with
+compatibility.</b><p>Ensuring compatibility should be easy and inexpensive to
+device manufacturers. The testing tool (CTS) is free and will soon be available
+in open source. CTS is designed to be used for continuous self-testing during
+the device development process to eliminate the cost of changing your workflow
+or sending your device to a third party for testing. Meanwhile, there are no
+required certifications, and thus no corresponding costs and fees.</p></li>
+</ul>
+<p>The Android compatibility program consists of three key components:</p>
+<ul>
+<li>The source code to the Android software stack</li>
+<li>The Compatilbility Definition Document, representing the "policy"
+aspect of compatibility</li>
+<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li>
+</ul>
+<p>Just as each version of the Android platform exists in a separate branch in
+the source code tree, there is a separate CTS and CDD for each version as
+well. The CDD, CTS, and source code are -- along with your hardware and your
+software customizations -- everything you need to create a compatible device.</p>
+
+<h3>Compatibility Definition Document (CDD)</h3>
+<p>For each release of the Android platform, a detailed Compatibility
+Definition Document (CDD) will be provided. The CDD represents the "policy"
+aspect of Android compatibility.</p>
+<p>No test suite, including CTS, can truly be comprehensive. For instance, the
+CTS includes a test that checks for the presence and correct behavior of
+OpenGL graphics APIs, but no software test can verify that the graphics
+actually appear correctly on the screen. More generally, it's impossible to
+test the presence of hardware features such as keyboards, display density,
+WiFi, and Bluetooth.</p>
+<p>The CDD's role is to codify and clarify specific requirements, and
+eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
+Android is a single corpus of open-source code, the code itself is the
+comprehensive "specification" of the platform and its APIs. The CDD acts as a
+"hub", referencing other content (such as SDK API documentation) that provides
+a framework in which the Android source code may be used so that the end
+result is a compatible system.</p>
+<p>If you want to build a device compatible with a given Android version,
+start by checking out the source code for that version, and then read the
+corresponding CDD and stay within its guidelines. For additional details,
+simply examine <a href="">the latest CDD</a>.</p>
+
+<h3>Compatibility Test Suite (CTS)</h3>
+<p>The CTS is a free, commercial-grade test suite, available along with the
+Android source code. The CTS represents the "mechanism" of compatibility.</p>
+<p>The CTS runs on a desktop machine and executes test cases directly on
+attached devices or an emulator. The CTS is a set of unit tests designed to be
+integrated into the daily workflow (such as via a continuous build system) of
+the engineers building a device. Its intent is to reveal incompatibilities
+early on, and ensure that the software remains compatible throughout the
+development process.</p>
+<p>For details on the CTS, consult the <a
+href="{@docRoot}compatibility/cts-intro.html">CTS introduction</a>.</p>
diff --git a/pdk/docs/downloads/downloads_toc.cs b/pdk/docs/downloads/downloads_toc.cs
new file mode 100644
index 0000000..28f43af
--- /dev/null
+++ b/pdk/docs/downloads/downloads_toc.cs
@@ -0,0 +1,21 @@
+<script type="text/javascript" language="JavaScript">
+<!--
+function nothing() {}
+-->
+</script>
+
+<ul>
+ <li><h2>PDK</h2><ul>
+ <li><a href="">PDK 1.6</a></li>
+ </ul></li>
+
+ <li><h2>Compatibility</h2><ul>
+ <li><a href="">Android 1.6</a></li>
+ </ul></li>
+</ul>
+
+<script type="text/javascript">
+<!--
+ buildToggleLists();
+//-->
+</script>
diff --git a/pdk/docs/downloads/index.jd b/pdk/docs/downloads/index.jd
new file mode 100644
index 0000000..f196808
--- /dev/null
+++ b/pdk/docs/downloads/index.jd
@@ -0,0 +1,46 @@
+page.title=Downloads
+doc.type=downloads
+doc.hidenav=true
+@jd:body
+<div id="mainBodyFixed">
+<p>This page provides access to various downloads. Note that if you're looking
+for the Android SDK (for application developers), you should visit <a
+href="http://developer.android.com/sdk/index.html">developer.android.com</a>.</p>
+
+<h2>Compatibility</h2>
+<p>The Compatibility Definition Document can be downloaded below. The
+Compatibility Test Suite is available in the open-source tree.</p>
+<table class="download">
+ <tr>
+ <th>Item</th>
+ <th>File</th>
+ <th>Size</th>
+ </tr>
+ <tr>
+ <td>Android CDD 2.1</td>
+ <td><a href="">android-cdd-2.1.pdf</a></td>
+ <td>23070805 bytes</td>
+ </tr>
+ <tr class="alt-color">
+ <td>Android CTS 2.1 Manual</td>
+ <td><a href="">android-cts-manual-2.1.0.pdf</a></td>
+ <td>23070805 bytes</td>
+ </tr>
+ <tr>
+ <td>Android CDD 1.6</td>
+ <td><a href="">android-cdd-1.6.pdf</a></td>
+ <td>23070805 bytes</td>
+ </tr>
+ <tr class="alt-color">
+ <td>Android CTS 1.6 Manual</td>
+ <td><a href="">android-cts-manual-1.6.4.pdf</a></td>
+ <td>23070805 bytes</td>
+ </tr>
+</table>
+<p>For more information on how to build an Android-compatible device, see the
+<a href="{@docRoot}compatibility/index.html">Compatibility</a> page. Note that
+there is no compatibility program for Android 1.5 and earlier. Note also that
+there is no compatibility program for Android 2.0, since it was superceded by
+Android 2.1 after only a few weeks.
+</p>
+</div>
diff --git a/pdk/docs/images/bluetooth-0.jpg b/pdk/docs/images/bluetooth-0.jpg
new file mode 100644
index 0000000..f06eebf
--- /dev/null
+++ b/pdk/docs/images/bluetooth-0.jpg
Binary files differ
diff --git a/pdk/docs/images/cts-0.png b/pdk/docs/images/cts-0.png
new file mode 100644
index 0000000..cca38c5
--- /dev/null
+++ b/pdk/docs/images/cts-0.png
Binary files differ
diff --git a/pdk/docs/images/cts-process-0.gif b/pdk/docs/images/cts-process-0.gif
new file mode 100644
index 0000000..565da23
--- /dev/null
+++ b/pdk/docs/images/cts-process-0.gif
Binary files differ
diff --git a/pdk/docs/images/cts-process-1.png b/pdk/docs/images/cts-process-1.png
new file mode 100644
index 0000000..2656433
--- /dev/null
+++ b/pdk/docs/images/cts-process-1.png
Binary files differ
diff --git a/pdk/docs/images/discuss-0.png b/pdk/docs/images/discuss-0.png
new file mode 100644
index 0000000..e2cea10
--- /dev/null
+++ b/pdk/docs/images/discuss-0.png
Binary files differ
diff --git a/pdk/docs/images/documentation-0.png b/pdk/docs/images/documentation-0.png
new file mode 100644
index 0000000..e2cea10
--- /dev/null
+++ b/pdk/docs/images/documentation-0.png
Binary files differ
diff --git a/pdk/docs/images/download-0.png b/pdk/docs/images/download-0.png
new file mode 100644
index 0000000..e2cea10
--- /dev/null
+++ b/pdk/docs/images/download-0.png
Binary files differ
diff --git a/pdk/docs/images/git-repo-0.png b/pdk/docs/images/git-repo-0.png
new file mode 100644
index 0000000..e2cea10
--- /dev/null
+++ b/pdk/docs/images/git-repo-0.png
Binary files differ
diff --git a/pdk/docs/images/git-repo-1.png b/pdk/docs/images/git-repo-1.png
new file mode 100644
index 0000000..6bc8dcb
--- /dev/null
+++ b/pdk/docs/images/git-repo-1.png
Binary files differ
diff --git a/pdk/docs/images/home-bugdroid.png b/pdk/docs/images/home-bugdroid.png
new file mode 100644
index 0000000..c30fac9
--- /dev/null
+++ b/pdk/docs/images/home-bugdroid.png
Binary files differ
diff --git a/pdk/docs/images/how-it-works-0.png b/pdk/docs/images/how-it-works-0.png
new file mode 100644
index 0000000..3c1c9dc
--- /dev/null
+++ b/pdk/docs/images/how-it-works-0.png
Binary files differ
diff --git a/pdk/docs/images/how-it-works-1.png b/pdk/docs/images/how-it-works-1.png
new file mode 100644
index 0000000..856674a
--- /dev/null
+++ b/pdk/docs/images/how-it-works-1.png
Binary files differ
diff --git a/pdk/docs/images/lil-wrench.png b/pdk/docs/images/lil-wrench.png
new file mode 100644
index 0000000..74b4972
--- /dev/null
+++ b/pdk/docs/images/lil-wrench.png
Binary files differ
diff --git a/pdk/docs/images/submit-patches-0.png b/pdk/docs/images/submit-patches-0.png
new file mode 100644
index 0000000..ca7eaad
--- /dev/null
+++ b/pdk/docs/images/submit-patches-0.png
Binary files differ
diff --git a/pdk/docs/images/submit-patches-1.png b/pdk/docs/images/submit-patches-1.png
new file mode 100644
index 0000000..777a3c3
--- /dev/null
+++ b/pdk/docs/images/submit-patches-1.png
Binary files differ
diff --git a/pdk/docs/images/workflow-0.png b/pdk/docs/images/workflow-0.png
new file mode 100644
index 0000000..d8456b5
--- /dev/null
+++ b/pdk/docs/images/workflow-0.png
Binary files differ
diff --git a/pdk/docs/index.jd b/pdk/docs/index.jd
index d7077d5..1f7b552 100644
--- a/pdk/docs/index.jd
+++ b/pdk/docs/index.jd
@@ -1,114 +1,55 @@
+page.title=Welcome to Android
home=true
@jd:body
+<div style="float: left; width: 45%; font-size: 1.3em;">
+ <p>Here you can find the source code and information you need to build an
+ Android-compatible device.</p>
+ <p>Android is an open-source software stack for mobile devices, maintained by
+ the Android Open Source Project (AOSP). We believe that users deserve to have
+ the source code to the devices they use on a daily basis, that developers
+ deserve an open and level playing field, and that OEMs and carriers deserve
+ the freedom to create innovative devices. That's why we created Android, and
+ made its source code open.</p>
+ <p><a href="{@docRoot}about/index.html">Learn more »</a></p>
+</div>
+<div style="float: right; width: 35%;">
+<h3 style="padding-top: 0px;">News crap here</h3>
+<p>This is a test of the emergency broadcast system. This is only a test. Had
+this been an actual emergency, we would have fled in terror, and you would not
+have been informed.</p>
+</div>
+<img style="float: right; padding-right: 1.5em;" src="{@docRoot}images/home-bugdroid.png" alt="Android Mascot"/>
+<div style="clear: both;"/>
- <div id="mainBodyFixed" align="top">
- <div id="mainBodyLeft">
- <h2>Android Open Source Project</h2>
- <!-- total max width is 520px -->
- <p> Android is the first free, open source, and fully customizable mobile platform.
- Android offers a full stack: an operating system, middleware and key mobile applications.
- It also contains a rich set of APIs that allows third-party developers to develop great
- applications. </p>
- </div><!-- end mainBodyLeft -->
+<table border="0" style="border: 0px; margin: 0px; padding: 0px;"><tr><td align="center" style="border: 0px; margin: 0px; padding: 0px;">
+<div class="rebox lil" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Get Involved</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em;"
+ />Learn how you, for one, can help welcome our new Android overlords.</p>
+ <p><a href="{@docRoot}source/index.html">More »</a></p>
+ </div>
+</div>
- <div id="mainBodyRight">
- <table id="rightColumn">
- <tr>
- <td class="imageCell"><a href="{@docRoot}sdk/index.html"><img src="{@docRoot}assets/images/icon_download.jpg" style="padding:0" /></a></td>
- <td>
- <h2 class="green">Download</h2>
- <p>The Android SDK has the tools, sample code, and docs you need to create great apps. </p>
- <p><a href="http://developer.android.com">Learn more »</a></p>
- </td>
- </tr>
- <tr>
- <td colspan="2"><div class="seperator"> </div></td>
- </tr>
- <tr>
- <td class="imageCell"><a href="http://www.android.com/market.html"><img src="{@docRoot}assets/images/icon_market.jpg" style="padding:0" /></a></td>
- <td>
- <h2 class="green">Publish</h2>
- <p>Android Market is an open service that lets you distribute your apps to handsets.</p>
- <p><a href="http://www.android.com/market.html">Learn more »</a></p>
- </td>
- </tr>
- <tr>
- <td colspan="2"><div class="seperator"> </div></td>
- </tr>
+<div class="rebox lil" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Build a Device</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em;"/>So,
+ you think you have what it takes to build an Android device? We'll see;
+ we'll see.</p>
+ <p><a href="{@docRoot}porting/index.html">More »</a></p>
+ </div>
+</div>
- </table>
- </div>
- </div>
+<div class="rebox lil" style="float: left; width: 30%; margin: 1em;">
+ <h2 style="color: white; background-color: #95C0D0; border: 0px;">Compatibility</h2>
+ <div class="p">
+ <p><img src="images/lil-wrench.png" alt="" style="margin: 1em;"/>There's more to this than
+ just booting the Linux kernel. Don't be evil, be compatible.</p>
+ <p><a href="{@docRoot}compatibility/index.html">More »</a></p>
+ </div>
+</div>
+</td></tr></table>
-<!--[if lte IE 6]>
- <style>
- #arrow-left {
- margin:0 0 0 5px;
- }
- #arrow-right {
- margin-left:0;
- }
- .app-list-container {
- margin: 37px 0 0 23px;
- }
- div#list-clip {
- width:468px;
- }
- </style>
-<![endif]-->
-
-<script type="text/javascript">
-
-// * -- carousel dictionary -- * //
- /* layout: imgLeft, imgRight, imgTop
- icon: image for carousel entry. cropped (height:70px, width:90px)
- name: string for carousel entry
- img: image for bulletin post. cropped (height: 170, width:230px)
- title: header for bulletin (optional, insert "" value to skip
- desc: the bulletin post. must include html tags.
- */
-
- var droidList = {
- 'sdk': {
- 'layout':"imgLeft",
- 'icon':"sdk-small.png",
- 'name':"SDK 1.5 r3",
- 'img':"sdk-large.png",
- 'title':"Android 1.5 SDK",
- 'desc': "<p>Android 1.5 SDK is now available. It includes new APIs for Android 1.5, updated developer tools, multiple platform versions, and a Google APIs add-on.</p><p><a href='{@docRoot}sdk/1.5_r3/index.html'>Download Android 1.5 SDK »</a></p>"
- },
-
- 'io': {
- 'layout':"imgLeft",
- 'icon':"io-small.png",
- 'name':"Google I/O",
- 'img':"io-large.png",
- 'title':"Google I/O Developer Conference",
- 'desc': "<p>The Google I/O developer conference took place May 27-28 in San Francisco. If you missed the conference, you can experience the Android sessions by viewing YouTube videos.</p><p><a href='{@docRoot}videos/index.html'>See the sessions from Google I/O »</a></p>"
- },
-
- 'mapskey': {
- 'layout':"imgLeft",
- 'icon':"maps-small.png",
- 'name':"Maps API Key",
- 'img':"maps-large.png",
- 'title':"Maps API Key",
- 'desc':"<p>If you're writing an Android application that uses Google Maps (with MapView), you must register your application to obtain a Maps API Key. Without the key, your maps application will not work on Android devices. Obtaining a key requires just a couple of steps.</p><p><a href='http://code.google.com/android/add-ons/google-apis/maps-overview.html'>Learn more »</a></p>"
- },
-
- 'devphone': {
- 'layout':"imgLeft",
- 'icon':"devphone-small.png",
- 'name':"Dev Phone 1",
- 'img':"devphone-large.png",
- 'title':"Android Dev Phone 1",
- 'desc': "<p>Run and debug your Android applications directly on this device. Modify and rebuild the Android operating system, and flash it onto the phone. The Android Dev Phone 1 is carrier independent, and available for purchase by any developer registered with <a href='http://market.android.com/publish'>Android Market</a>.</p><p><a href='/guide/developing/device.html#dev-phone-1'>Learn more about the Android Dev Phone 1 »</a></p>"
- }
-
- }
-</script>
-<script type="text/javascript" src="{@docRoot}assets/carousel.js"></script>
-<script type="text/javascript">
- initCarousel("sdk");
-</script>
+<div style="clear: both;"/>
diff --git a/pdk/docs/porting/audio.jd b/pdk/docs/porting/audio.jd
new file mode 100755
index 0000000..e82788f
--- /dev/null
+++ b/pdk/docs/porting/audio.jd
@@ -0,0 +1,61 @@
+page.title=Audio
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidAudioBuildingDriver">Building an Audio Library</a></li>
+<li><a href="#androidAudioInterface">Interface</a></li>
+</ul>
+</div>
+</div>
+
+
+<p>AudioHardwareInterface serves as the glue between proprietary audio drivers and the Android AudioFlinger service, the core audio service that handles all audio-related requests from applications.</p>
+<p><img src="images/android_audio_architecture.gif"></p>
+
+Solid elements represent Android blocks and dashed elements represent partner-specific blocks.
+
+
+
+<a name="androidAudioBuildingDriver"></a><h3>Building an Audio Library</h3>
+
+<p>To implement an audio driver, create a shared library that implements the interface defined in <code>AudioHardwareInterface.h</code>. You must name your shared library <code>libaudio.so</code> so that it will get loaded from <code>/system/lib</code> at runtime. Place libaudio sources and <code>Android.mk</code> in <code>vendor/acme/chipset_or_board/libaudio/</code>.</p>
+<p>The following stub <code>Android.mk</code> file ensures that <code>libaudio</code> compiles and links to the appropriate libraries:</p>
+
+<pre class="prettify">
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libaudio
+
+LOCAL_SHARED_LIBRARIES := \
+ libcutils \
+ libutils \
+ libmedia \
+ libhardware
+
+LOCAL_SRC_FILES += MyAudioHardware.cpp
+
+LOCAL_CFLAGS +=
+
+LOCAL_C_INCLUDES +=
+
+LOCAL_STATIC_LIBRARIES += libaudiointerface
+
+include $(BUILD_SHARED_LIBRARY)
+</pre>
+
+
+<a name="androidAudioInterface"></a><h3>Interface</h3>
+
+
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="audio_sub_system.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="AudioHardwareInterface_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0" frameborder="0" style="width:100%;"></iframe>
diff --git a/pdk/docs/porting/bluetooth.jd b/pdk/docs/porting/bluetooth.jd
new file mode 100755
index 0000000..e974982
--- /dev/null
+++ b/pdk/docs/porting/bluetooth.jd
@@ -0,0 +1,193 @@
+page.title=Bluetooth
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidBluetoothPorting">Porting</a></li>
+<li><a href="#androidBluetoothCompiling">Compiling</a></li>
+<li><a href="#androidBluetoothTroubleshooting">Troubleshooting</a></li>
+<li><a href="#androidBluetoothTools">Tools</a></li>
+<li><a href="#androidBluetoothFeatures">Feature Support</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android's Bluetooth stack uses BlueZ version 3.36 for GAP, SDP, and RFCOMM profiles, and is a SIG-qualified Bluetooth 2.0 + EDR host stack.</p>
+
+<p>Bluez is GPL licensed, so the Android framework interacts with userspace bluez code through D-BUS IPC to avoid proprietary code.</p>
+
+<p>Headset and Handsfree (v1.5) profiles are implemented in the Android framework and are both tightly coupled with the Phone App. These profiles are also SIG qualified.</p>
+
+<p>The diagram below offers a library-oriented view of the Bluetooth stack. Click <a href="bluetooth/bluetooth_process.html">Bluetooth Process Diagram</a> for a process-oriented view.</p>
+
+<p><img src="images/androidBluetooth.gif"></p>
+
+Solid elements represent Android blocks and dashed elements represent partner-specific blocks.
+
+
+
+<a name="androidBluetoothPorting"></a><h3>Porting</h3>
+
+<p>BlueZ is Bluetooth 2.0 compatible and should work with any 2.0 chipset. There are two integration points:</p>
+<p><ul>
+<li>UART driver</li>
+<li>Bluetooth Power On / Off</li>
+</ul>
+</p>
+
+
+<a name="androidBluetoothPortingDriver"></a><h4>UART Driver</h4>
+
+<p>The BlueZ kernel sub-system attaches to your hardware-specific UART driver using the <code>hciattach</code> daemon.</p>
+<p>For example, for MSM7201A, this is <code>drivers/serial/msm_serial.c</code>. You may also need to edit command line options to <code>hciattach</code> via <code>init.rc</code>.</p>
+
+
+<a name="androidBluetoothPortingPowerOnOff"></a><h4>Bluetooth Power On / Off</h4>
+
+<p>The method for powering on and off your bluetooth chip varies from Android V 1.0 to post 1.0.</p>
+
+<p><ul>
+<li><b>1.0</b>: Android framework writes a 0 or 1 to <code>/sys/modules/board_[PLATFORM]/parameters/bluetooth_power_on</code>.</li>
+
+<li><b>Post 1.0</b>: Android framework uses the linux <code>rfkill</code> API. See <code>arch/arm/mach-msm/board-trout-rfkill.c</code> for an example.</li>
+</ul>
+</p>
+
+<a name="androidBluetoothCompiling"></a><h4>Compiling</h4>
+
+<p>To compile Android with Bluetooth support enabled, add the following line to <code>BoardConfig.mk</code>.
+<pre>
+BOARD_HAVE_BLUETOOTH := true
+</pre>
+
+<a name="androidBluetoothTroubleshooting"></a><h3>Troubleshooting</h3>
+<p><strong>Debugging</strong></p>
+<p>To debug your bluetooth implementation, start by reading the logs (<code>adb logcat</code>) and look for ERRROR and WARNING messages regarding Bluetooth.
+ Andoird uses Bluez, which comes with some useful debugging tools. The snippet below provides examples in a suggested order:</p>
+<pre>
+hciconfig -a # print BT chipset address and features. Useful to check if you can communicate with your BT chipset.
+hcidump -XVt # print live HCI UART traffic.
+hcitool scan # scan for local devices. Useful to check if RX/TX works.
+l2ping ADDRESS # ping another BT device. Useful to check if RX/TX works.
+sdptool records ADDRESS # request the SDP records of another BT device.
+</pre>
+
+<p><strong>Deamon Logs</strong></p>
+<p>Deamon logs for <code>hcid</code> (<code>STDOUT</code>) and <code>hciattach</code> (<code>STDERR</code>) are sent to <code>/dev/null</code> by default. Edit <code>init.rc</code></span> and <code>init.PLATFORM.rc</code></span> to run these daemons under <code>logwrapper</code>, which redirects output to <code>logcat</code>.</p>
+<p><strong>hciconfig -a and hcitool</strong></p>
+<p>If you compile your own system.img for Android, and <code>hciconfig -a</code> works but <code>hcitool</code> scan doesn't, try installing the firmware for the Bluetooth chipset. This firmware isn't yet available in the open source codebase, but you can <code>adb pull</code> and then <code>adb push</code>it from a stock T-Mobile G1 (located in <code>/etc/firmware/brf6300.bin</code>).<br />
+ <a name="androidBluetoothTools"></a></p>
+<h3>Tools</h3>
+
+<p>BlueZ provides a rich set of command line tools for debugging and interacting with the Bluetooth sub-system, including:</p>
+<p><ul>
+<li><code>hciconfig</code></li>
+<li><code>hcitool</code></li>
+<li><code>hcidump</code></li>
+<li><code>sdptool</code></li>
+<li><code>dbus-send</code></li>
+<li><code>dbus-monitor</code></li>
+</ul>
+</p>
+
+<a name="androidBluetoothFeatures"></a>
+<h3>Feature Support</h3>
+<p>This section provides a change history of Bluetooth features added in each Android release and provides some rough guidance as to future features. </p>
+<h4>Android 1.0 release</h4>
+<h5>Platform features</h5>
+<ul>
+ <li>Based on Bluez 3.36 and Linux Kernel 2.6.25</li>
+ <li>Bluetooth 2.0+EDR host stack</li>
+ <li>Headset Profile 1.0 in Audio Gateway role</li>
+ <li>Handsfree Profile 1.5 in Audio Gateway role</li>
+ <ul>
+ <li>Three-way calling</li>
+ <li>Phonebook over AT commands
+ </li>
+ </ul>
+</ul>
+<h5>Qualifications</h5>
+<ul>
+ <li>QDID B014524: Host stack (SDP, L2CAP, GAP, RFCOMM, SPP)</li>
+ <li>QDID B014624: EPL for HTC Dream (HSP, HFP)</li>
+</ul>
+<h5>Example products</h5>
+<ul>
+ <li>HTC Dream / T-Mobile G1</li>
+</ul>
+<h4> </h4>
+<h4>Android 1.1 release</h4>
+<p>No Bluetooth changes since 1.0</p>
+<h4> </h4>
+<h4>Android 1.5 release (cupcake)</h4>
+<h4>Platform features</h4>
+<ul>
+ <li>Based on Bluez 3.36 with Linux Kernel 2.6.27</li>
+ <li>Bluetooth 2.0+EDR host stack</li>
+ <ul>
+ <li>Support for auto-pairing with '0000' devices</li>
+ </ul>
+ <li>Headset Profile 1.1 in Audio Gateway role</li>
+ <li>Handsfree Profile 1.5 in Audio Gateway role</li>
+ <ul>
+ <li>Three-way calling </li>
+ <li>Phonebook over AT commands </li>
+ <li>Volume synchronization</li>
+ <li>eSCO</li>
+ <li>Extensive bug fixes and compatibility improvements</li>
+ </ul>
+ <li>Stereo Bluetooth (A2DP 1.2) in Source role</li>
+ <ul>
+ <li>AVDTP 1.2 in Acceptor and Initiator roles</li>
+ <li>GAVDTP 1.0 in Acceptor and Initiator roles</li>
+ <li>44.1 khz, stereo, software SBC codec</li>
+ </ul>
+ <li>Remote Control (AVRCP 1.0) in Target role</li>
+ <ul>
+ <li>AVCTP 1.3 in Target role</li>
+ <li>play/pause/stop/prev/next</li>
+ </ul>
+</ul>
+<h4>Qualifications</h4>
+<ul>
+ <li>QDID B015261: Host stack (SDP, L2CAP, GAP, RFCOMM, SPP, AVCTP, AVRCP, GAVDP, AVDTP, A2DP)</li>
+ <li>QDID B015262: EPL for HTC Sapphire (HSP, HFP)</li>
+</ul>
+<h5> </h5>
+<h4>Future releases</h4>
+<p>This section offers a rough guide of which features the team is developing for the next release. This feature list may change without notice. It isn't possible to post scheduling advice to the mailing lists.</p>
+<ul>
+ <li>Java Bluetooth API</li>
+ <li>Bluez 4.x with Linux Kernel 2.6.29</li>
+ <li>More profiles...</li>
+ <li>Bluetooth 2.1+EDR</li>
+</ul>
+
+<p><strong>Development Notes</strong></p>
+<ul>
+ <li><strong>HID Support<br />
+ </strong>Cupcake features some early work—Bluez has an HID plugin, <code>external/bluez/utils/input/Android.mk</code>, which gets compiled. <br />
+ <br />
+You can interact directly with this plugin using <code>dbus-send</code></span> and <code>dbus-monitor</code>. While not officially supported, you should be able to connect and use a HID keyboard and mouse using the Bluez HID plugin API. Next steps include plumbing the plugin API in the Android Java framework and offering better support for HID input methods (new keymaps and mouse support).<br />
+ <br />
+ </li>
+ <li> <strong>Tethering - DUN and PAN Support</strong><br />
+ Cupcake features some early work—Bluez has has DUN and PAN daemons which get compiled and <code>external/bluez/utils/dun/Android.mk
+ external/bluez/utils/pan/Android.mk
+BNEP</code> support is compiled into the kernel with cupcake. <br />
+<br />
+While not officially supported, you should be able to run <code>dund</code> or <code>pand</code> daemons and, using <code>pppd</code> or <code>iptables</code>, test tethering support. Next steps include plubming the DBUS APIs to these daemons up into the Android Java framework and adding code to setup the network paths via <code>pppd</code> and / or <code>iptables</code>.<br />
+ <br />
+ </li>
+ <li><strong>Emulator Support</strong><br />
+ The Android emulator does not support Bluetooth at this time and there currently aren't any plans for its support.<br />
+ <br />
+ </li>
+ <li><strong>Bluetooth 2.1 and Simple Pairing Support</strong><br />
+ In order to support these features, Android needs to move to a Bluez 4.x version. This change is not scheduled at this time.</li>
+</ul>
diff --git a/pdk/docs/porting/bluetooth/bluetooth_process.jd b/pdk/docs/porting/bluetooth/bluetooth_process.jd
new file mode 100755
index 0000000..ea46f23
--- /dev/null
+++ b/pdk/docs/porting/bluetooth/bluetooth_process.jd
@@ -0,0 +1,7 @@
+page.title=Bluetooth Process Diagram
+pdk.version=1.0
+doc.type=guide
+@jd:body
+
+<p>The diagram below offers a process-oriented architectural overview of Android's Bluetooth stack. Click <a href="../bluetooth.html">Bluetooth</a> to return to the Bluetooth overview page.</p>
+<img src="images/androidBluetoothProcessDiagram.jpg">
diff --git a/pdk/docs/porting/bluetooth/images/androidBluetoothProcessDiagram.jpg b/pdk/docs/porting/bluetooth/images/androidBluetoothProcessDiagram.jpg
new file mode 100755
index 0000000..6872180
--- /dev/null
+++ b/pdk/docs/porting/bluetooth/images/androidBluetoothProcessDiagram.jpg
Binary files differ
diff --git a/pdk/docs/porting/bring_up.jd b/pdk/docs/porting/bring_up.jd
new file mode 100755
index 0000000..022c185
--- /dev/null
+++ b/pdk/docs/porting/bring_up.jd
@@ -0,0 +1,359 @@
+page.title=Bring Up
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<p>Once your code is built and you have verified that all necessary directories exist, power on and test your device with basic bring up, as described below. Bring up tests are typically designed to stress certain aspects of your system and allow you to characterize the device's behavior. </p>
+<p> </p>
+<h3>1. Confirm a Clean Installation of a Basic Linux Kernel </h3>
+<p>Before considering Android-specific modifications to the Linux kernel, verify that you can build, deploy, and boot a core Linux kernel on your target hardware. </p>
+<p> </p>
+<h3>2. Modify Your Kernel Configuration to Accommodate Android Drivers</h3>
+<p>Your kernel configuration file should include the following:</p>
+<pre class="prettyprint">
+#
+# Android
+#
+# CONFIG_ANDROID_GADGET is not set
+# CONFIG_ANDROID_RAM_CONSOLE is not set
+CONFIG_ANDROID_POWER=y
+CONFIG_ANDROID_POWER_STAT=y
+CONFIG_ANDROID_LOGGER=y
+# CONFIG_ANDROID_TIMED_GPIO is not set
+CONFIG_ANDROID_BINDER_IPC=y
+</pre>
+<h3>3. Write Drivers</h3>
+<p>Android ships with default drivers for all basic functionality but you'll likely want to write your own drivers (or at least customize the default drivers) for your own device depending on your hardware configuration. See the following topics for examples of how to write your own drivers. </p>
+<ul>
+ <li><a href="audio_subsystem.html">Audio</a></li>
+ <li><a href="keymaps_keyboard_input.html">Keymaps and Keyboard</a></li>
+ <li><a href="display_drivers.html">Display</a></li>
+</ul>
+<p> </p>
+<h3>4. Burn Images to Flash</h3>
+<p>An image represents the state of a system or part of a system stored in non-volatile memory. The build process should produce the following system images:</p>
+<ul>
+ <li><strong>bootloader</strong>: The bootloader is a small program responsible for initiating loading of the operating system. </li>
+ <li><strong>boot</strong>: </li>
+ <li><strong>recovery</strong>: </li>
+ <li><strong>system</strong>: The system image stores a snapshot of the Android operating system.</li>
+ <li><strong>data</strong>: The data image stores user data. Anything not saved to the <code>device/data</code> directory will be lost on reboot.</li>
+</ul>
+<ul>
+ <li><strong>kernel</strong>: The kernel represents the most basic element of an operating system. Android's Linux kernel is responsible for managing the system's resources and acts as an abstraction layer between hardware and a system's applications. </li>
+ <li><strong>ramdisk</strong>: RAMdisk defines a portion of Random Access Memory (RAM) that gets used as if it were a hard drive. </li>
+</ul>
+<p> </p>
+<p>Configure the bootloader to load the kernel and RAMdisk into RAM and pass the RAMdisk address to the kernel on startup. </p>
+<p> </p>
+<h3>5. Boot the kernel and mount the RAMdisk.</h3>
+<p> </p>
+<h3>6. Debug Android-specific init programs on RAMdisk</h3>
+<p>Android-specific init programs are found in <code>device/system/init</code>. Add LOG messages to help you debug potential problems with the LOG macro defined in <code>device/system/init/init.c</code>.</p>
+<p> The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a <code>/etc/fstab</code> file in Android). After <code>device/system</code> files are mounted, init reads <code>/etc/init.rc</code> and invokes the programs listed there (one of the first of which is the console shell).</p>
+<p> </p>
+<h3>7. Verify that applications have started </h3>
+<p>Once the shell becomes available, execute <code>% ps</code> to confirm that the following applications are running:</p>
+<ul>
+ <li><code>/system/bin/logd</code></li>
+ <li><code>/sbin/adbd</code></li>
+ <li><code>/system/bin/usbd</code></li>
+ <li><code>/system/bin/debuggerd</code></li>
+ <li><code>/system/bin/rild</code></li>
+ <li><code>/system/bin/app_process</code></li>
+ <li><code>/system/bin/runtime</code></li>
+ <li><code>/system/bin/dbus-daemon</code></li>
+ <li><code>system_server</code></li>
+</ul>
+<p>Each of these applications is embedded Linux C/C++ and you can use any standard Linux debugging tool to troubleshoot applications that aren't running. Execute <code>% make showcommands</code> to determine precise build commands. <code>gdbserver</code> (the GNU debugger) is available in the <code>bin</code> directory of the system partition (please see <a href="http://sourceware.org/gdb/">http://sourceware.org/gdb/</a> for more information). </p>
+<p> </p>
+<h3>8. Pulling it all together </h3>
+<p>If bring up was successful, you should see the following Java applications (with icons) visible on the LCD panel:</p>
+<ul>
+ <li>com.google.android.phone: The Android contact application. </li>
+ <li>com.google.android.home</li>
+ <li>android.process.google.content</li>
+</ul>
+<p>If they are not visible or unresponsive to keypad control, run the <code>framebuffer/keypad</code> tests.</p>
+
+
+<a name="androidInitLanguage"></a><h1>Android Init Language</h1>
+
+
+<p>The Android Init Language consists of four broad classes of statements:</p>
+<ul>
+ <li>Actionn</li>
+ <li>Commands</li>
+ <li>Services</li>
+ <li>Options</li>
+</ul>
+<p>The language syntax includes the following conventions: </p>
+<ul>
+ <li>All classes are line-oriented and consist of tokens separated by whitespace. c-style backslash escapes may be used to insert whitespace into a token. Double quotes may also be used to prevent whitespace from breaking text into multiple tokens. A backslash <br />
+ appearing as the last character on a line is used for line-folding.</li>
+ <li> Lines that start with a # (leading whitespace allowed) are comments.</li>
+ <li>Actions and Services implicitly declare new sections. All commands
+ or options belong to the section most recently declared. Commands
+ or options before the first section are ignored. </li>
+ <li>Actions and Services have unique names. If a second Action or Service is declared with the same name as an existing one, it is ignored as an error.</li>
+</ul>
+<p> Actions</p>
+<p> Actions are named sequences of commands. Actions have a trigger used to determine when the action should occur. When an event
+ occurs which matches an action's trigger, that action is added to
+ the tail of a to-be-executed queue (unless it is already on the
+ queue).<br />
+ <br />
+ Each action in the queue is dequeued in sequence. Each command in
+ an action is executed in sequence. Init handles other activities
+ (such as, device creation/destruction, property setting, process restarting) "between" the execution of the commands in activities.
+<p>Actions take the form of:</p>
+<pre class="prettify">
+on <trigger>
+ <command>
+ <command>
+ <command>
+</pre>
+<p>Services</p>
+<p>Services are programs that init launches and (optionally) restarts
+when they exit. </p>
+<p>Services take the form of:</p>
+<pre class="prettify">
+ service <name> <pathname> [ <argument> ]*
+ <option>
+ <option>
+ ...
+</pre>
+<p>Options</p>
+ <p> Options are modifiers to services that affect how and when init
+runs a service. Options are described in the table below:</p>
+<table>
+ <tr>
+ <th scope="col">Option</th><th scope="col">Description</th></tr>
+ <tr>
+ <td><code>disabled</code></td>
+ <td>This service will not automatically start with its class. It must be explicitly started by name.</td>
+ </tr>
+ <tr>
+ <td><code>socket <type> <name> <perm> [ <user> [ <group> ] ]</code></td>
+ <td> Create a unix domain socket named <code>/dev/socket/<name></code> and pass its fd to the launched process. Valid <code><type></code> values include <code>dgram</code> and <code>stream</code>. <code>user</code> and <code>group</code> default to 0.</td>
+ </tr>
+ <tr>
+ <td><code>user <username></code></td>
+ <td>Change to username before exec'ing this service. Currently defaults to root.</td>
+ </tr>
+ <tr>
+ <td><code>group <groupname> [ <groupname> ]*</code></td>
+ <td> Change to groupname before exec'ing this service. Additional groupnames beyond the first, which is required, are used to set additional groups of the process (with <code>setgroups()</code>). Currently defaults to root.</td>
+ </tr>
+ <tr>
+ <td><code>capability [ <capability> ]+</code></td>
+ <td>Set linux capability before exec'ing this service</td>
+ </tr>
+ <tr>
+ <td><code>oneshot</code></td>
+ <td>Do not restart the service when it exits.</td>
+ </tr>
+ <tr>
+ <td><code>class <name></code></td>
+ <td>Specify a class name for the service. All services in a named class must start and stop together. A service is considered of class "default" if one is not specified via the class option.</td>
+ </tr>
+</table>
+ <p> Triggers</p>
+ <p>Triggers are strings used to match certain kinds of events that cause an action to occur. </p>
+ <table>
+ <tr>
+ <th scope="col">Trigger</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td><code>boot</code></td>
+ <td>This is the first trigger that occurs when init starts (after <code>/init.conf</code> is loaded).</td>
+ </tr>
+ <tr>
+ <td><code><name>=<value></code></td>
+ <td>Triggers of this form occur when the property <code><name></code> is set to the specific value <code><value></code>.</td>
+ </tr>
+ <tr>
+ <td><code>device-added-<path><br />
+ device-removed-<path></code></td>
+ <td>Triggers of these forms occur when a device node is added or removed.</td>
+ </tr>
+ <tr>
+ <td><code> service-exited-<name></code></td>
+ <td>Triggers of this form occur when the specified service exits.</td>
+ </tr>
+ </table>
+ <p><br />
+ Commands</p>
+ <table>
+ <tr>
+ <th scope="col">Command</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td><code>exec <path> [ <argument> ]*</code></td>
+ <td>Fork and execute a program (<code><path></code>). This will block until the program completes execution. Try to avoid exec. Unlike the <code>builtin</code> commands, it runs the risk of getting init "stuck".</td>
+ </tr>
+ <tr>
+ <td><code>export <name> <value></code></td>
+ <td>Set the environment variable <code><name></code> equal to <code><value></code> in the global environment (which will be inherited by all processes started after this command is executed).</td>
+ </tr>
+ <tr>
+ <td><code>ifup <interface></code></td>
+ <td>Bring the network interface <code><interface></code> online.</td>
+ </tr>
+ <tr>
+ <td><code>import <filename></code></td>
+ <td> Parse an init config file, extending the current configuration.</td>
+ </tr>
+ <tr>
+ <td><code>hostname <name></code></td>
+ <td>Set the host name.</td>
+ </tr>
+ <tr>
+ <td><code>class_start <serviceclass></code></td>
+ <td>Start all services of the specified class if they are not already running.</td>
+ </tr>
+ <tr>
+ <td><code>class_stop <serviceclass></code></td>
+ <td>Stop all services of the specified class if they are currently running.</td>
+ </tr>
+ <tr>
+ <td><code>domainname <name></code></td>
+ <td>Set the domain name.</td>
+ </tr>
+ <tr>
+ <td><code>insmod <path></code></td>
+ <td>Install the module at <code><path></code>.</td>
+ </tr>
+ <tr>
+ <td><code>mkdir <path></code></td>
+ <td>Make a directory at <code><path></code>.</td>
+ </tr>
+ <tr>
+ <td><code>mount <type> <device> <dir> [ <mountoption> ]*</code></td>
+ <td>Attempt to mount the named device at the directory <code><dir></code> <code><device></code>. This may be of the form mtd@name to specify a mtd block device by name.</td>
+ </tr>
+ <tr>
+ <td><code>setkey</code></td>
+ <td>- currenlty undefined - </td>
+ </tr>
+ <tr>
+ <td><code>setprop <name> <value></code></td>
+ <td>Set system property <code><name></code> to <code><value></code>.</td>
+ </tr>
+ <tr>
+ <td><code> setrlimit <resource> <cur> <max></code></td>
+ <td>Set the rlimit for a resource.</td>
+ </tr>
+ <tr>
+ <td><code>start <service></code></td>
+ <td>Start a service running if it is not already running.</td>
+ </tr>
+ <tr>
+ <td><code> stop <service></code></td>
+ <td>Stop a service from running if it is currently running.</td>
+ </tr>
+ <tr>
+ <td><code>symlink <target> <path></code></td>
+ <td>Create a symbolic link at <code><path></code> with the value <code><target></code>.</td>
+ </tr>
+ <tr>
+ <td><code>write <path> <string> [ <string> ]*</code></td>
+ <td>Open the file at <code><path></code> and write one or more strings to it with write(2).</td>
+ </tr>
+ </table>
+ <p> Properties</p>
+ Init updates some system properties to provide some insight into<br />
+ what it's doing:</p>
+ <table>
+ <tr>
+ <th scope="col">Property</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td><code>init.action</code></td>
+ <td>Equal to the name of the action currently being executed or "" if none.</td>
+ </tr>
+ <tr>
+ <td><code>init.command</code></td>
+ <td>Equal to the command being executed or "" if none.</td>
+ </tr>
+ <tr>
+ <td><code>init.svc.<name></code></td>
+ <td>State of a named service ("stopped", "running", or "restarting").</td>
+ </tr>
+ </table>
+ <p>Example init.conf</p>
+ <p>The following snippet is an incomplete example of the <code>init.conf</code> file, simply meant to give you an idea of what a proper configuration resembles.</p>
+ <pre class="prettify">
+on boot
+ export PATH /sbin:/system/sbin:/system/bin
+ export LD_LIBRARY_PATH /system/lib
+
+ mkdir /dev
+ mkdir /proc
+ mkdir /sys
+
+
+ mount tmpfs tmpfs /dev
+ mkdir /dev/pts
+ mkdir /dev/socket
+ mount devpts devpts /dev/pts
+ mount proc proc /proc
+ mount sysfs sysfs /sys
+
+
+ write /proc/cpu/alignment 4
+
+
+ ifup lo
+
+
+ hostname localhost
+ domainname localhost
+
+
+ mount yaffs2 mtd@system /system
+ mount yaffs2 mtd@userdata /data
+
+
+ import /system/etc/init.conf
+
+
+ class_start default
+
+
+service adbd /sbin/adbd
+ user adb
+ group adb
+
+
+service usbd /system/bin/usbd -r
+ user usbd
+ group usbd
+ socket usbd 666
+
+
+service zygote /system/bin/app_process -Xzygote /system/bin --zygote
+ socket zygote 666
+
+
+service runtime /system/bin/runtime
+ user system
+ group system
+
+
+on device-added-/dev/compass
+ start akmd
+
+
+on device-removed-/dev/compass
+ stop akmd
+
+
+service akmd /sbin/akmd
+ disabled
+ user akmd
+ group akmd
+</pre>
diff --git a/pdk/docs/porting/build_cookbook.jd b/pdk/docs/porting/build_cookbook.jd
new file mode 100755
index 0000000..d619086
--- /dev/null
+++ b/pdk/docs/porting/build_cookbook.jd
@@ -0,0 +1,556 @@
+page.title=Build Cookbook
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#simpleAPK">Simple APK</a></li>
+<li><a href="#APKJar">APK Dependent on static .jar file</a></li>
+ <li><a href="#APKPlatform">APK signed with the platform key</a></li>
+ <li><a href="#APKVendor">APK that signed with vendor key</a></li>
+ <li><a href="#prebuiltAPK">Prebuilt APK</a></li>
+ <li><a href="#staticJava">Adding a Static Java Library</a></li>
+ <li><a href="#mkVars">Android.mk variables</a></li>
+</ul>
+</div>
+</div>
+
+
+<p>The Android Build Cookbook offers code snippets to help you quickly implement some common build tasks. For additional instruction, please see the other build documents in this section.</p>
+<h3><a name="simpleAPK"></a>Building a simple APK</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # Build all java files in the java subdirectory
+ LOCAL_SRC_FILES := $(call all-subdir-java-files)
+
+ # Name of the APK to build
+ LOCAL_PACKAGE_NAME := LocalPackage
+
+ # Tell it to build an APK
+ include $(BUILD_PACKAGE)
+</pre>
+<h3><a name="APKJar"></a>Building a APK that depends on a static .jar file</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # List of static libraries to include in the package
+ LOCAL_STATIC_JAVA_LIBRARIES := static-library
+
+ # Build all java files in the java subdirectory
+ LOCAL_SRC_FILES := $(call all-subdir-java-files)
+
+ # Name of the APK to build
+ LOCAL_PACKAGE_NAME := LocalPackage
+
+ # Tell it to build an APK
+ include $(BUILD_PACKAGE)
+</pre>
+<h3><a name="APKPlatform"></a>Building a APK that should be signed with the platform key</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # Build all java files in the java subdirectory
+ LOCAL_SRC_FILES := $(call all-subdir-java-files)
+
+ # Name of the APK to build
+ LOCAL_PACKAGE_NAME := LocalPackage
+
+ LOCAL_CERTIFICATE := platform
+
+ # Tell it to build an APK
+ include $(BUILD_PACKAGE)
+</pre>
+<h3><a name="APKVendor"></a>Building a APK that should be signed with a specific vendor key</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # Build all java files in the java subdirectory
+ LOCAL_SRC_FILES := $(call all-subdir-java-files)
+
+ # Name of the APK to build
+ LOCAL_PACKAGE_NAME := LocalPackage
+
+ LOCAL_CERTIFICATE := vendor/example/certs/app
+
+ # Tell it to build an APK
+ include $(BUILD_PACKAGE)
+</pre>
+<h3><a name="prebuiltAPK"></a>Adding a prebuilt APK</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # Module name should match apk name to be installed.
+ LOCAL_MODULE := LocalModuleName
+ LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
+ LOCAL_MODULE_CLASS := APPS
+ LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
+
+ include $(BUILD_PREBUILT)
+</pre>
+<h3><a name="staticJava"></a>Adding a Static Java Library</h3>
+<pre>
+ LOCAL_PATH := $(call my-dir)
+ include $(CLEAR_VARS)
+
+ # Build all java files in the java subdirectory
+ LOCAL_SRC_FILES := $(call all-subdir-java-files)
+
+ # Any libraries that this library depends on
+ LOCAL_JAVA_LIBRARIES := android.test.runner
+
+ # The name of the jar file to create
+ LOCAL_MODULE := sample
+
+ # Build a static jar file.
+ include $(BUILD_STATIC_JAVA_LIBRARY)
+</pre>
+<h3><a name="mkVars"></a>Android.mk Variables</h3>
+
+<p>These are the variables that you'll commonly see in Android.mk files, listed
+alphabetically. First, a note on the variable naming: </p>
+
+<ul>
+ <li><b>LOCAL_</b> - These variables are set per-module. They are cleared
+ by the <code>include $(CLEAR_VARS)</code> line, so you can rely on them
+ being empty after including that file. Most of the variables you'll use
+ in most modules are LOCAL_ variables.</li>
+ <li><b>PRIVATE_</b> - These variables are make-target-specific variables. That
+ means they're only usable within the commands for that module. It also
+ means that they're unlikely to change behind your back from modules that
+ are included after yours. This
+ <a href="http://www.gnu.org/software/make/manual/make.html#Target_002dspecific">link to the make documentation</a>
+ describes more about target-specific variables.
+ </li>
+ <li><b>HOST_</b> and <b>TARGET_</b> - These contain the directories
+ and definitions that are specific to either the host or the target builds.
+ Do not set variables that start with HOST_ or TARGET_ in your makefiles.
+ </li>
+ <li><b>BUILD_</b> and <b>CLEAR_VARS</b> - These contain the names of
+ well-defined template makefiles to include. Some examples are CLEAR_VARS
+ and BUILD_HOST_PACKAGE.</li>
+ <li>Any other name is fair-game for you to use in your Android.mk. However,
+ remember that this is a non-recursive build system, so it is possible that
+ your variable will be changed by another Android.mk included later, and be
+ different when the commands for your rule / module are executed.</li>
+</ul>
+
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Parameter</th>
+ <th scope="col">Description</th>
+ </tr>
+<tr>
+<td valign="top">LOCAL_AAPT_FLAGS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ACP_UNAVAILABLE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ADDITIONAL_JAVA_DIR</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_AIDL_INCLUDES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ALLOW_UNDEFINED_SYMBOLS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ARM_MODE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ASFLAGS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ASSET_DIR</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_ASSET_FILES</td>
+<td valign="top">In Android.mk files that <code>include $(BUILD_PACKAGE)</code> set this
+to the set of files you want built into your app. Usually:</p>
+<p><code>LOCAL_ASSET_FILES += $(call find-subdir-assets)</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_BUILT_MODULE_STEM</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_C_INCLUDES</td>
+<td valign="top"><p>Additional directories to instruct the C/C++ compilers to look for header
+files in. These paths are rooted at the top of the tree. Use
+<code>LOCAL_PATH</code> if you have subdirectories of your own that you
+want in the include paths. For example:</p>
+<p><code>
+LOCAL_C_INCLUDES += extlibs/zlib-1.2.3<br/>
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/src
+</code></p>
+<p>You should not add subdirectories of include to
+<code>LOCAL_C_INCLUDES</code>, instead you should reference those files
+in the <code>#include</code> statement with their subdirectories. For
+example:</p>
+<p><code>#include <utils/KeyedVector.h></code><br/>
+not <code><s>#include <KeyedVector.h></s></code></p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CC</td>
+<td valign="top">If you want to use a different C compiler for this module, set LOCAL_CC
+to the path to the compiler. If LOCAL_CC is blank, the appropriate default
+compiler is used.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CERTIFICATE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CFLAGS</td>
+<td valign="top">If you have additional flags to pass into the C or C++ compiler, add
+them here. For example:</p>
+<p><code>LOCAL_CFLAGS += -DLIBUTILS_NATIVE=1</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CLASSPATH</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_COMPRESS_MODULE_SYMBOLS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_COPY_HEADERS</td>
+<td valign="top"><p>The set of files to copy to the install include tree. You must also
+supply <code>LOCAL_COPY_HEADERS_TO</code>.</p>
+<p>This is going away because copying headers messes up the error messages, and
+may lead to people editing those headers instead of the correct ones. It also
+makes it easier to do bad layering in the system, which we want to avoid. We
+also aren't doing a C/C++ SDK, so there is no ultimate requirement to copy any
+headers.</p></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_COPY_HEADERS_TO</td>
+<td valign="top"><p>The directory within "include" to copy the headers listed in
+<code>LOCAL_COPY_HEADERS</code> to.</p>
+<p>This is going away because copying headers messes up the error messages, and
+may lead to people editing those headers instead of the correct ones. It also
+makes it easier to do bad layering in the system, which we want to avoid. We
+also aren't doing a C/C++ SDK, so there is no ultimate requirement to copy any
+headers.</p></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CPP_EXTENSION</td>
+<td valign="top">If your C++ files end in something other than "<code>.cpp</code>",
+you can specify the custom extension here. For example:
+<p><code>LOCAL_CPP_EXTENSION := .cc</code></p>
+Note that all C++ files for a given module must have the same
+extension; it is not currently possible to mix different extensions.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CPPFLAGS</td>
+<td valign="top">If you have additional flags to pass into <i>only</i> the C++ compiler, add
+them here. For example:</p>
+<p><code>LOCAL_CPPFLAGS += -ffriend-injection</code></p>
+<code>LOCAL_CPPFLAGS</code> is guaranteed to be after <code>LOCAL_CFLAGS</code>
+on the compile line, so you can use it to override flags listed in
+<code>LOCAL_CFLAGS</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_CXX</td>
+<td valign="top">If you want to use a different C++ compiler for this module, set LOCAL_CXX
+to the path to the compiler. If LOCAL_CXX is blank, the appropriate default
+compiler is used.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_DX_FLAGS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_EXPORT_PACKAGE_RESOURCES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_FORCE_STATIC_EXECUTABLE</td>
+<td valign="top"><p>If your executable should be linked statically, set
+<code>LOCAL_FORCE_STATIC_EXECUTABLE:=true</code>. There is a very short
+list of libraries that we have in static form (currently only libc). This is
+really only used for executables in /sbin on the root filesystem.</p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_GENERATED_SOURCES</td>
+<td valign="top"><p>Files that you add to <code>LOCAL_GENERATED_SOURCES</code> will be
+automatically generated and then linked in when your module is built.
+See the <a href="#custom-tools">Custom Tools</a> template makefile for an
+example.</p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_INSTRUMENTATION_FOR</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_INSTRUMENTATION_FOR_PACKAGE_NAME</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_INTERMEDIATE_SOURCES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_INTERMEDIATE_TARGETS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_IS_HOST_MODULE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JAR_MANIFEST</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JARJAR_RULES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JAVA_LIBRARIES</td>
+<td valign="top"><p>When linking Java apps and libraries, <code>LOCAL_JAVA_LIBRARIES</code>
+specifies which sets of java classes to include. Currently there are
+two of these: <code>core</code> and <code>framework</code>.
+In most cases, it will look like this:</p>
+<p><code>LOCAL_JAVA_LIBRARIES := core framework</code></p>
+<p>Note that setting <code>LOCAL_JAVA_LIBRARIES</code> is not necessary
+(and is not allowed) when building an APK with
+"<code>include $(BUILD_PACKAGE)</code>". The appropriate libraries
+will be included automatically.</p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JAVA_RESOURCE_DIRS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JAVA_RESOURCE_FILES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_JNI_SHARED_LIBRARIES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_LDFLAGS</td>
+<td valign="top"><p>You can pass additional flags to the linker by setting
+<code>LOCAL_LDFLAGS</code>. Keep in mind that the order of parameters is
+very important to ld, so test whatever you do on all platforms.</p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_LDLIBS</td>
+<td valign="top"><p><code>LOCAL_LDLIBS</code> allows you to specify additional libraries
+that are not part of the build for your executable or library. Specify
+the libraries you want in -lxxx format; they're passed directly to the
+link line. However, keep in mind that there will be no dependency generated
+for these libraries. It's most useful in simulator builds where you want
+to use a library preinstalled on the host. The linker (ld) is a particularly
+fussy beast, so it's sometimes necessary to pass other flags here if you're
+doing something sneaky. Some examples:</p>
+<p><code>LOCAL_LDLIBS += -lcurses -lpthread<br/>
+LOCAL_LDLIBS += -Wl,-z,origin
+</code></p> </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_MODULE</td>
+<td valign="top"><code>LOCAL_MODULE</code> is the name of what's supposed to be generated
+from your Android.mk. For exmample, for libkjs, the <code>LOCAL_MODULE</code>
+is "libkjs" (the build system adds the appropriate suffix -- .so .dylib .dll).
+For app modules, use <code>LOCAL_PACKAGE_NAME</code> instead of
+<code>LOCAL_MODULE</code>. </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_MODULE_PATH</td>
+<td valign="top">Instructs the build system to put the module somewhere other than what's
+normal for its type. If you override this, make sure you also set
+<code>LOCAL_UNSTRIPPED_PATH</code> if it's an executable or a shared library
+so the unstripped binary has somewhere to go. An error will occur if you forget
+to.</p>
+<p>See <a href="#moving-modules">Putting modules elsewhere</a> for more.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_MODULE_STEM</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_MODULE_TAGS</td>
+<td valign="top"><p>Set <code>LOCAL_MODULE_TAGS</code> to any number of whitespace-separated
+tags. <p>This variable controls what build flavors the package gets included in. For example:</p>
+<ul type="disc">
+ <li><code>user</code>: include this in user/userdebug builds</li>
+ <li><code>eng</code>: include this in eng builds</li>
+ <li><code>tests</code>: the target is a testing target and makes it available for tests</li>
+ <li><code>optional</code>: don't include this</li>
+</ul></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_NO_DEFAULT_COMPILER_FLAGS</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_NO_EMMA_COMPILE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_NO_EMMA_INSTRUMENT</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_NO_STANDARD_LIBRARIES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_OVERRIDES_PACKAGES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PACKAGE_NAME</td>
+<td valign="top"><code>LOCAL_PACKAGE_NAME</code> is the name of an app. For example,
+Dialer, Contacts, etc. </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_POST_PROCESS_COMMAND</td>
+<td valign="top"><p>For host executables, you can specify a command to run on the module
+after it's been linked. You might have to go through some contortions
+to get variables right because of early or late variable evaluation:</p>
+<p><code>module := $(HOST_OUT_EXECUTABLES)/$(LOCAL_MODULE)<br/>
+LOCAL_POST_PROCESS_COMMAND := /Developer/Tools/Rez -d __DARWIN__ -t APPL\<br/>
+ -d __WXMAC__ -o $(module) Carbon.r
+</code></p>
+ </td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PREBUILT_EXECUTABLES</td>
+<td valign="top">When including $(BUILD_PREBUILT) or $(BUILD_HOST_PREBUILT), set these to
+executables that you want copied. They're located automatically into the
+right bin directory.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PREBUILT_JAVA_LIBRARIES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PREBUILT_LIBS</td>
+<td valign="top">When including $(BUILD_PREBUILT) or $(BUILD_HOST_PREBUILT), set these to
+libraries that you want copied. They're located automatically into the
+right lib directory.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PREBUILT_OBJ_FILES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_PRELINK_MODULE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_REQUIRED_MODULES</td>
+<td valign="top"><p>Set <code>LOCAL_REQUIRED_MODULES</code> to any number of whitespace-separated
+module names, like "libblah" or "Email". If this module is installed, all
+of the modules that it requires will be installed as well. This can be
+used to, e.g., ensure that necessary shared libraries or providers are
+installed when a given app is installed.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_RESOURCE_DIR</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_SDK_VERSION</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_SHARED_LIBRARIES</td>
+<td valign="top">These are the libraries you directly link against. You don't need to
+pass transitively included libraries. Specify the name without the suffix:</p>
+<p><code>LOCAL_SHARED_LIBRARIES := \<br/>
+ libutils \<br/>
+ libui \<br/>
+ libaudio \<br/>
+ libexpat \<br/>
+ libsgl
+</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_SRC_FILES</td>
+<td valign="top">The build system looks at <code>LOCAL_SRC_FILES</code> to know what source
+files to compile -- .cpp .c .y .l .java. For lex and yacc files, it knows
+how to correctly do the intermediate .h and .c/.cpp files automatically. If
+the files are in a subdirectory of the one containing the Android.mk, prefix
+them with the directory name:</p>
+<p><code>LOCAL_SRC_FILES := \<br/>
+ file1.cpp \<br/>
+ dir/file2.cpp
+</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_STATIC_JAVA_LIBRARIES</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_STATIC_LIBRARIES</td>
+<td valign="top">These are the static libraries that you want to include in your module.
+Mostly, we use shared libraries, but there are a couple of places, like
+executables in sbin and host executables where we use static libraries instead.
+<p><code>LOCAL_STATIC_LIBRARIES := \<br/>
+ libutils \<br/>
+ libtinyxml
+</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_UNINSTALLABLE_MODULE</td>
+<td valign="top"></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_UNSTRIPPED_PATH</td>
+<td valign="top">Instructs the build system to put the unstripped version of the module
+somewhere other than what's normal for its type. Usually, you override this
+because you overrode <code>LOCAL_MODULE_PATH</code> for an executable or a
+shared library. If you overrode <code>LOCAL_MODULE_PATH</code>, but not
+<code>LOCAL_UNSTRIPPED_PATH</code>, an error will occur.</p>
+<p>See <a href="#moving-modules">Putting modules elsewhere</a> for more.</td>
+</tr>
+<tr>
+<td valign="top">LOCAL_WHOLE_STATIC_LIBRARIES</td>
+<td valign="top">These are the static libraries that you want to include in your module without allowing
+the linker to remove dead code from them. This is mostly useful if you want to add a static library
+to a shared library and have the static library's content exposed from the shared library.
+<p><code>LOCAL_WHOLE_STATIC_LIBRARIES := \<br/>
+ libsqlite3_android<br/>
+</code></td>
+</tr>
+<tr>
+<td valign="top">LOCAL_YACCFLAGS</td>
+<td valign="top">Any flags to pass to invocations of yacc for your module. A known limitation
+here is that the flags will be the same for all invocations of YACC for your
+module. This can be fixed. If you ever need it to be, just ask.</p>
+<p><code>LOCAL_YACCFLAGS := -p kjsyy</code></td>
+</tr>
+<tr>
+<td valign="top">OVERRIDE_BUILT_MODULE_PATH</td>
+<td valign="top"></td>
+</tr>
+
+</table>
diff --git a/pdk/docs/porting/build_new_device.jd b/pdk/docs/porting/build_new_device.jd
new file mode 100755
index 0000000..55b0355
--- /dev/null
+++ b/pdk/docs/porting/build_new_device.jd
@@ -0,0 +1,242 @@
+page.title=Configuring a New Product
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidOHDPortingDeviceBuildingProcess">Detailed Instructions</a></li>
+<li><a href="#androidBuildNewFileTree">New Product File Tree</a></li>
+<li><a href="#androidBuildSystemProductDefFiles">Product Definition Files</a></li>
+</ul>
+</div>
+</div>
+
+
+<a name="androidOHDPortingDeviceBuildingProcess"></a><h3>Detailed Instructions</h3>
+
+<p>The steps below describe how to configure makefiles for new mobile devices and products running Android.</p>
+<ol>
+ <li>Create a company directory in <code>//vendor/</code>.<br/>
+ <pre class="prettyprint">
+ mkdir vendor/<company_name></pre></li>
+ <li>Create a <code>products</code> directory beneath the company directory you created in step 1.<BR>
+ <pre class="prettyprint">
+ mkdir vendor/<company_name>/products/</pre></li>
+ <li>Create a product-specific makefile, called <code>vendor/<company_name>/products/<first_product_name>.mk</code>, that includes at least the following code:<BR>
+ <pre class="prettyprint">
+ $(call inherit-product, $(SRC_TARGET_DIR)/product/generic.mk)
+ #
+ # Overrides
+ PRODUCT_NAME := <first_product_name>
+ PRODUCT_DEVICE := <board_name></pre>
+ <li>
+ Additional product-specific variables can be added to this <a href="#androidBuildSystemProductDefFiles">Product Definition</a>
+file.
+ </li>
+ <li>In the <code>products</code> directory, create an <code>AndroidProducts.mk</code> file that point to (and is responsible for finding) the individual product make files.<BR>
+ <pre class="prettyprint">
+ #
+ # This file should set PRODUCT_MAKEFILES to a list of product makefiles
+ # to expose to the build system. LOCAL_DIR will already be set to
+ # the directory containing this file.
+ #
+ # This file may not rely on the value of any variable other than
+ # LOCAL_DIR; do not use any conditionals, and do not look up the
+ # value of any variable that isn't set in this file or in a file that
+ # it includes.
+ #
+
+ PRODUCT_MAKEFILES := \
+ $(LOCAL_DIR)/first_product_name.mk \</pre></li>
+ <li>Create a board-specific directory beneath your company directory that matches the <code>PRODUCT_DEVICE</code> variable <code><board_name></code> referenced in the product-specific make file above. This will include a make file that gets accessed by any product using this board.<BR>
+ <pre class="prettyprint">
+ mkdir vendor/<company_name>/<board_name></pre></li>
+ <li>Create a <code>BoardConfig.mk</code> file in the directory created in the previous step (<code>vendor/<company_name>/<board_name></code>). <BR>
+ <pre class="prettyprint">
+ # These definitions override the defaults in config/config.make for <board_name>
+ #
+ # TARGET_NO_BOOTLOADER := false
+ # TARGET_HARDWARE_3D := false
+ #
+ TARGET_USE_GENERIC_AUDIO := true</pre></li>
+ <li>If you wish to modify system properties, create a <code>system.prop</code> file in your <code><board_name></code> directory(<code>vendor/<company_name>/<board_name></code>).<BR>
+ <pre class="prettyprint">
+ # system.prop for <board_name>
+ # This overrides settings in the products/generic/system.prop file
+ #
+ # rild.libpath=/system/lib/libreference-ril.so
+ # rild.libargs=-d /dev/ttyS0</pre></li>
+ <li>Add a pointer to <code><second_product_name>.mk</code> within <code>products/AndroidProducts.mk</code>.<BR>
+ <pre class="prettypring">
+ PRODUCT_MAKEFILES := \
+ $(LOCAL_DIR)/first_product_name.mk \
+ $(LOCAL_DIR)/second_product_name.mk</pre></li>
+ <li>An <code>Android.mk</code> file must be included in <code>vendor/<company_name>/<board_name></code> with at least the following code:<BR>
+ <pre class="prettyprint">
+ # make file for new hardware <board_name> from <company_name>
+ #
+ LOCAL_PATH := $(call my-dir)
+ #
+ # this is here to use the pre-built kernel
+ ifeq ($(TARGET_PREBUILT_KERNEL),)
+ TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel
+ endif
+ #
+ file := $(INSTALLED_KERNEL_TARGET)
+ ALL_PREBUILT += $(file)
+ $(file): $(TARGET_PREBUILT_KERNEL) | $(ACP)
+ $(transform-prebuilt-to-target)
+ #
+ # no boot loader, so we don't need any of that stuff..
+ #
+ LOCAL_PATH := vendor/<company_name>/<board_name>
+ #
+ include $(CLEAR_VARS)
+ #
+ # include more board specific stuff here? Such as Audio parameters.
+ #</pre>
+
+ </li>
+<li>To create a second product for the same board, create a second product-specific make file called <code>vendor/company_name/products/<second_product_name>.mk</code> that includes:<BR>
+<pre class="prettyprint">
+ $(call inherit-product, $(SRC_TARGET_DIR)/product/generic.mk)
+ #
+ # Overrides
+ PRODUCT_NAME := <second_product_name>
+ PRODUCT_DEVICE := <board_name></pre></li>
+</ol>
+<p>By now, you should have two new products, called <code><first_product_name></code> and <code><second_product_name></code> associated with <code><company_name></code>. To verify that a product is properly configured (<code><first_product_name></code>, for example), execute the following:<BR>
+<pre class="prettyprint">
+ . build/envsetup.sh
+ make PRODUCT-<first_product_name>-user
+</pre>
+<p>You should find new build binaries located in <code>/out/target/product/<board_name></code>.
+
+
+<a name="androidBuildNewFileTree"></a><h3>New Product File Tree</h3>
+
+<p>The file tree below illustrates what your own system should look like after completing the steps above.</p>
+<p>
+<ul>
+ <li><code><company_name></code></li>
+ <ul>
+ <li><code><board_name></code></li>
+ <ul>
+ <li><code>Android.mk</code></li>
+ <li><code>product_config.mk</code></li>
+ <li><code>system.prop</code></li>
+ </ul>
+ <li><code>products</code></li>
+ <ul>
+ <li><code>AndroidProducts.mk</code></li>
+ <li><code><first_product_name>.mk</code></li>
+ <li><code><second_product_name>.mk</code></li>
+ </ul>
+ </ul>
+</ul>
+</p>
+
+<a name="androidBuildSystemProductDefFiles"></a><h3>Product Definition Files</h3>
+
+<p>Product-specific variables are defined in product definition files. A product definition file can inherit from other product definition files, thus reducing the need to copy and simplifying maintenance.</p>
+<p>Variables maintained in a product definition files include:</p>
+<p>
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Parameter</th>
+ <th scope="col">Description</th>
+ <th scope="col">Example</th>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_NAME</td>
+ <td valign="top">End-user-visible name for the overall product. Appears in the "About the phone" info.</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_MODEL</td>
+ <td valign="top">End-user-visible name for the end product</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_LOCALES</td>
+ <td valign="top">A space-separated list of two-letter language code, two-letter country code pairs that describe several settings for the user, such as the UI language and time, date and currency formatting. The first locale listed in PRODUCT_LOCALES is is used if the locale has never been set before.</td>
+ <td valign="top"><code>en_GB de_DE es_ES fr_CA</code></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_PACKAGES</td>
+ <td valign="top">Lists the APKs to install.</td>
+ <td valign="top"><code>Calendar Contacts</code></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_DEVICE</td>
+ <td valign="top">Name of the industrial design</td>
+ <td valign="top"><code>dream</code></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_MANUFACTURER</td>
+ <td valign="top">Name of the manufacturer</td>
+ <td valign="top"><code>acme</code></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_BRAND</td>
+ <td valign="top">The brand (e.g., carrier) the software is customized for, if any</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_PROPERTY_OVERRIDES</td>
+ <td valign="top">List of property assignments in the format "key=value"</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_COPY_FILES</td>
+ <td valign="top">List of words like <code>source_path:destination_path</code>. The file at the source path should be copied to the destination path when building this product. The rules for the copy steps are defined in config/Makefile</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_OTA_PUBLIC_KEYS</td>
+ <td valign="top">List of OTA public keys for the product</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_POLICY</td>
+ <td valign="top">Indicate which policy this product should use</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_PACKAGE_OVERLAYS</td>
+ <td valign="top">Indicate whether to use default resources or add any product specific overlays</td>
+ <td valign="top"><code>vendor/acme/overlay</code></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_CONTRIBUTORS_FILE</td>
+ <td valign="top">HTML file containing the contributors to the project.</td>
+ <td valign="top"></td>
+ </tr>
+ <tr>
+ <td valign="top">PRODUCT_TAGS</td>
+ <td valign="top">list of space-separated words for a given product</td>
+ <td valign="top"></td>
+ </tr>
+</table>
+
+</P>
+<p>The snippet below illustrates a typical product definition file.</p>
+<pre class="prettyprint">
+$(call inherit-product, build/target/product/generic.mk)
+
+#Overrides
+PRODUCT_NAME := MyDevice
+PRODUCT_MANUFACTURER := acme
+PRODUCT_BRAND := acme_us
+PRODUCT_LOCALES := en_GB es_ES fr_FR
+PRODUCT_PACKAGE_OVERLAYS := vendor/acme/overlay
+
+</pre>
+
+
diff --git a/pdk/docs/porting/build_system.jd b/pdk/docs/porting/build_system.jd
new file mode 100755
index 0000000..e5811bd
--- /dev/null
+++ b/pdk/docs/porting/build_system.jd
@@ -0,0 +1,270 @@
+page.title=Android Build System
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidBuildSystemOverview">Understanding the makefile</a></li>
+<li><a href="#androidBuildSystemLayers">Layers</a></li>
+<li><a href="#androidSourceSetupBuildingCodeBase">Building the Android Platform</a></li>
+<li><a href="#androidSourceSetupBuildingKernel">Building the Android Kernel</a></li>
+<li><a href="#androidBuildVariants">Build Variants</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android uses a custom build system to generate tools, binaries, and documentation. This document provides an overview of Android's build system and instructions for doing a simple build. </p>
+<p>Android's build system is make based and requires a recent version of GNU Make (note that Android uses advanced features of GNU Make that may not yet appear on the GNU Make web site). Before continuing, check your version of make by running <code>% make -v</code>. If you don't have version 3.80 or greater, you need to <a href="http://www.gnu.org/software/make/">upgrade your version of make</a>. </p>
+
+
+
+
+<a name="androidBuildSystemOverview"></a><h4>Understanding the makefile</h4>
+
+<p>A makefile defines how to build a particular application. Makefiles typically include all of the following elements:</p>
+<ol>
+ <li>Name: Give your build a name (<code>LOCAL_MODULE := <build_name></code>).</li>
+ <li>Local Variables: Clear local variables with CLEAR_VARS (<code>include $(CLEAR_VARS)</code>).</li>
+ <li>Files: Determine which files your application depends upon (<code>LOCAL_SRC_FILES := main.c</code>).</li>
+ <li>Tags: Define tags, as necessary (<code>LOCAL_MODULE_TAGS := eng development</code>).</li>
+ <li>Libraries: Define whether your application links with other libraries (<code>LOCAL_SHARED_LIBRARIES := cutils</code>).</li>
+ <li>Template file: Include a template file to define underlining make tools for a particular target (<code>include $(BUILD_EXECUTABLE)</code>).</li>
+</ol>
+
+<p>The following snippet illustrates a typical makefile.</p>
+<pre class="prettyprint">
+LOCAL_PATH := $(my-dir)
+include $(CLEAR_VARS)
+LOCAL_MODULE := <buil_name>
+LOCAL_SRC_FILES := main.c
+LOCAL_MODULE_TAGS := eng development
+LOCAL_SHARED_LIBRARIES := cutils
+include $(BUILD_EXECUTABLE)
+(HOST_)EXECUTABLE, (HOST_)JAVA_LIBRARY, (HOST_)PREBUILT, (HOST_)SHARED_LIBRARY,
+ (HOST_)STATIC_LIBRARY, PACKAGE, JAVADOC, RAW_EXECUTABLE, RAW_STATIC_LIBRARY,
+ COPY_HEADERS, KEY_CHAR_MAP
+</pre>
+<p>The snippet above includes artificial line breaks to maintain a print-friendly document.</p>
+
+
+<a name="androidBuildSystemLayers"></a><h4>Layers</h4>
+
+<p>The build hierarchy includes the abstraction layers described in the table below.</p>
+
+<p>Each layer relates to the one above it in a one-to-many relationship. For example, an arch can have more than one board and each board can have more than one device. You may define an element in a given layer as a specialization of an element in the same layer, thus eliminating copying and simplifying maintenance.</p>
+
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Layer</th>
+ <th scope="col">Example</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td valign="top">Product</td>
+ <td valign="top">myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk</td>
+ <td valign="top">The product layer defines a complete specification of a shipping product, defining which modules to build and how to configure them. You might offer a device in several different versions based on locale, for example, or on features such as a camera. </td>
+ </tr>
+ <tr>
+ <td valign="top">Device</td>
+ <td valign="top">myDevice, myDevice_eu, myDevice_eu_lite</td>
+ <td valign="top">The device layer represents the physical layer of plastic on the device. For example, North American devices probably include QWERTY keyboards whereas devices sold in France probably include AZERTY keyboards. Peripherals typically connect to the device layer. </td>
+ </tr>
+ <tr>
+ <td valign="top">Board</td>
+ <td valign="top">sardine, trout, goldfish </td>
+ <td valign="top">The board layer represents the bare schematics of a product. You may still connect peripherals to the board layer. </td>
+ </tr>
+ <tr>
+ <td valign="top">Arch</td>
+ <td valign="top">arm (arm5te) (arm6), x86, 68k </td>
+ <td valign="top">The arch layer describes the processor running on your board. </td>
+ </tr>
+</table>
+
+<a name="androidSourceSetupBuildingCodeBase"></a><h3>Building the Android Platform</h3>
+
+<p>This section describes how to build the default version of Android. Once you are comfortable with a generic build, then you can begin to modify Android for your own target device.</p>
+
+
+<a name="androidSourceSetupBuildingDeviceCodeBase"></a><h4>Device Code</h4>
+
+<p>To do a generic build of android, source <code>build/envsetup.sh</code>, which contains necessary variable and function definitions, as described below.</p>
+<pre class="prettyprint">
+% cd $TOP
+
+% . build/envsetup.sh
+
+# pick a configuration using choosecombo
+% choosecombo
+
+% make -j4 PRODUCT-generic-user
+</pre>
+<p>You can also replace user with eng for a debug engineering build:</p>
+
+<pre class="prettyprint">
+% make -j4 PRODUCT-generic-eng
+</pre>
+
+<p>These <a href="#androidBuildVariants">Build Variants</a> differ in terms of debug options and packages installed.
+
+
+<a name="androidBuildingCleaning"></a><h4>Cleaning Up</h4>
+
+<p>Execute <code>% m clean</code> to clean up the binaries you just created. You can also execute <code>% m clobber</code> to get rid of the binaries of all combos. <code>% m clobber</code> is equivalent to removing the <code>//out/</code> directory where all generated files are stored.</p>
+
+
+<a name="androidBuildingSpeeding"></a><h4>Speeding Up Rebuilds</h4>
+
+<p> The binaries of each combo are stored as distinct sub-directories of <code>//out/</code>, making it possible to quickly switch between combos without having to recompile all sources each time. </p>
+<p> However, performing a clean rebuild is necessary if the build system doesn't catch changes to environment variables or makefiles. If this happens often, you should define the <code>USE_CCACHE</code> environment variable as shown below: </p>
+<pre class="prettyprint">
+% export USE_CCACHE=1
+</pre>
+<p>Doing so will force the build system to use the ccache compiler cache tool, which reduces recompiling all sources.</p>
+
+<p><code>ccache</code> binaries are provided in <code>//prebuilt/...</code> and don't need to get installed on your system.</p>
+
+
+<a name="androidBuildingTroubleshooting"></a><h4>Troubleshooting</h4>
+
+<p>The following error is likely caused by running an outdated version of Java.</p>
+<pre class="prettyprint">
+device Dex: core UNEXPECTED TOP-LEVEL ERROR:
+java.lang.NoSuchMethodError: method java.util.Arrays.hashCode with
+signature ([Ljava.lang.Object;)I was not found.
+ at com.google.util.FixedSizeList.hashCode(FixedSizeList.java:66)
+ at com.google.rop.code.Rop.hashCode(Rop.java:245)
+ at java.util.HashMap.hash(libgcj.so.7)
+[...]
+</pre>
+<p><code>dx</code> is a Java program that uses facilities first made available in Java version 1.5. Check your version of Java by executing <code>% java -version</code> in the shell you use to build. You should see something like:</p>
+<pre class="prettyprint">
+java version "1.5.0_07"
+Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
+Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
+</pre>
+<p>If you do have Java 1.5 or later and your receive this error, verify that you have properly updated your <code>PATH</code> variable.</p>
+
+
+<a name="androidSourceSetupBuildingKernel"></a><h3>Building the Android Kernel</h3>
+
+<p>This section describes how to build Android's default kernel. Once you are comfortable with a generic build, then you can begin to modify Android drivers for your own target device.</p>
+
+
+<p>To build the kernel base, switch to the device directory (<code>/home/joe/android/device</code>) in order to establish variables and run:
+<pre class="prettyprint">
+% . build/envsetup.sh
+% partner_setup generic
+</pre>
+<p>Then switch to the kernel directory <code>/home/joe/android/kernel</code>.
+
+
+<a name="androidSourceSetupBuildingKernelCheckingBranch"></a><h4>Checking Out a Branch</h4>
+
+<p>The default branch is always <code>android</code>. To check out a different branch, execute the following:</p>
+
+<pre class="prettyprint">
+% git checkout --track -b android-mydevice origin/android-mydevice
+ //Branch android-mydevice set up to track remote branch
+% refs/remotes/origin/android-mydevice.
+ //Switched to a new branch "android-mydevice"
+</pre>
+
+<p>To simplify code management, give your local branch the same name as the remote branch it is tracking (as illustrated in the snippet above). Switch between branches by executing <code>% git checkout <branchname></code>.</p>
+
+
+<a name="androidSourceSetupBuildingKernelBranchLocation"></a><h4>Verifying Location</h4>
+
+<p>Find out which branches exist (both locally and remotely) and which one is active (marked with an asterisk) by executing the following:</p>
+<pre class="prettyprint">
+% git branch -a
+ android
+* android-mydevice
+ origin/HEAD
+ origin/android
+ origin/android-mydevice
+ origin/android-mychipset
+</pre>
+<p>To only see local branches, omit the <code>-a</code> flag.</p>
+
+
+<a name="androidSourceSetupBuildingKernelBuild"></a><h4>Building the Kernel</h4>
+
+<p>To build the kernel, execute:</p>
+<pre class="prettyprint">
+% make -j4
+</pre>
+
+<a name="androidBuildVariants"></a><h3>Build Variants</h3>
+
+<p>
+When building for a particular product, it's often useful to have minor
+variations on what is ultimately the final release build. These are the
+currently-defined build variants:
+</p>
+
+<table border=1>
+<tr>
+ <td>
+ <code>eng<code>
+ </td>
+ <td>
+ This is the default flavor. A plain <code>make</code> is the
+ same as <code>make eng</code>.
+ <ul>
+ <li>Installs modules tagged with: <code>eng</code>, <code>debug</code>,
+ <code>user</code>, and/or <code>development</code>.
+ <li>Installs non-APK modules that have no tags specified.
+ <li>Installs APKs according to the product definition files, in
+ addition to tagged APKs.
+ <li><code>ro.secure=0</code>
+ <li><code>ro.debuggable=1</code>
+ <li><code>ro.kernel.android.checkjni=1</code>
+ <li><code>adb</code> is enabled by default.
+ </td>
+</tr>
+<tr>
+ <td>
+ <code>user<code>
+ </td>
+ <td>
+ <code>make user</code>
+ <p>
+ This is the flavor intended to be the final release bits.
+ <ul>
+ <li>Installs modules tagged with <code>user</code>.</li>
+ <li>Installs non-APK modules that have no tags specified.</li>
+ <li>Installs APKs according to the product definition files; tags
+ are ignored for APK modules.</li>
+ <li><code>ro.secure=1</code> </li>
+ <li><code>ro.debuggable=0</code> </li>
+ <li><code>adb</code> is disabled by default.</li>
+ </td>
+</tr>
+<tr>
+ <td>
+ <code>userdebug<code>
+ </td>
+ <td>
+ <code>make userdebug</code>
+ <p>
+ The same as <code>user</code>, except:
+ <ul>
+ <li>Also installs modules tagged with <code>debug</code>.
+ <li><code>ro.debuggable=1</code>
+ <li><code>adb</code> is enabled by default.
+ </td>
+</tr>
+</table>
+
+<p>
+If you build one flavor and then want to build another, you should run
+<code>make installclean</code> between the two makes to guarantee that
+you don't pick up files installed by the previous flavor. <code>make
+clean</code> will also suffice, but it takes a lot longer.
+</p>
diff --git a/pdk/docs/porting/camera.jd b/pdk/docs/porting/camera.jd
new file mode 100755
index 0000000..0571fb5
--- /dev/null
+++ b/pdk/docs/porting/camera.jd
@@ -0,0 +1,76 @@
+page.title=Camera
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidCameraBuildingDriver">Building a Camera Library</a></li>
+<li><a href="#androidCameraSequenceDiagrams">Sequence Diagrams</a></li>
+<li><a href="#androidCameraInterfaceIntro">Interface</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android's camera subsystem connects the camera application to the application framework and user space libraries, which in turn communicate with the camera hardware layer that operates the physical camera.</p>
+<p>The diagram below illustrates the structure of the camera subsystem.</p>
+<p><img src="images/camera_video2.gif"></p>
+
+
+<a name="androidCameraBuildingDriver"></a><h3>Building a Camera Library</h3>
+
+<p>To implement a camera driver, create a shared library that implements the interface defined in <code>CameraHardwareInterface.h</code>. You must name your shared library <code>libcamera.so</code> so that it will get loaded from <code>/system/lib</code> at runtime. Place libcamera sources and <code>Android.mk</code> in <code>vendor/acme/chipset_or_board/libcamera/</code>.</p>
+<p>The following stub <code>Android.mk</code> file ensures that <code>libcamera</code> compiles and links to the appropriate libraries:</p>
+<pre class="prettify">
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libcamera
+
+LOCAL_SHARED_LIBRARIES := \
+ libutils \
+ librpc \
+ liblog
+
+LOCAL_SRC_FILES += MyCameraHardware.cpp
+
+LOCAL_CFLAGS +=
+
+LOCAL_C_INCLUDES +=
+
+LOCAL_STATIC_LIBRARIES += \
+ libcamera-common \
+ libclock-rpc \
+ libcommondefs-rpc
+
+include $(BUILD_SHARED_LIBRARY)
+</pre>
+
+
+<a name="androidCameraSequenceDiagrams"></a><h3>Sequence Diagrams</h3>
+
+
+
+<a name="androidCameraSequenceDiagramsPreview"></a><h4>Preview</h4>
+
+<p>The following diagram illustrates the sequence of function calls and actions necessary for your camera to preview.</p>
+<img src="images/cameraPreview.jpg">
+
+
+<a name="androidCameraSequenceDiagramsTakePic"></a><h4>Taking a Picture</h4>
+
+<p>The following diagram illustrates the sequence of function calls and actions necessary for your camera to take a picture.</p>
+<img src="images/cameraTakePicture.jpg">
+
+
+<a name="androidCameraInterfaceIntro"></a><h3>Interface</h3>
+
+
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="camera.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="CameraHardwareInterface_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0" frameborder="0" style="width:100%;"></iframe>
diff --git a/pdk/docs/porting/customization.jd b/pdk/docs/porting/customization.jd
new file mode 100755
index 0000000..7c11a8e
--- /dev/null
+++ b/pdk/docs/porting/customization.jd
@@ -0,0 +1,321 @@
+page.title=Customization
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidBootScreenCustomization">Boot Screen Customization</a></li>
+<li><a href="#androidNetCustPlat">Network Customization Platform</a></li>
+<li><a href="#androidCustomizingPre-LoadedApps">Customizing pre-loaded applications</a></li>
+<li><a href="#androidBrowserBookmarks">Customizing browser bookmarks</a></li>
+<li><a href="#androidEmailProviderCustomization">Email Provider Customization</a></li>
+<li><a href="#androidThemes">Platform Themes</a></li>
+</ul>
+</div>
+</div>
+
+
+
+<a name="androidBootScreenCustomization"></a><h3>Boot Screen Customization</h3>
+
+<p>At startup, Android displays a splashscreen image while booting the device. Do the following if you wish to modify the default splash screen:</p>
+<p>
+<ol><li>Create a 320x480 image, <code>splashscreen.jpg</code> in this example.</li>
+<li>Using ImageMagick, convert your .jpg file to .r format:
+<pre class="prettify">
+convert screen.jpg screen.r
+</pre>
+</li>
+<li>Use the rgb2565 application to convert the image to 565 format:
+<pre class="prettify">
+rgb2565 < screen.rgb > screen.565
+</pre>
+</li>
+<li>Use fastboot to flash the image to the device:
+<pre class="prettify">
+fastboot flash splash1 screen.565
+</pre>
+</li>
+</ol>
+
+
+<a name="androidNetCustPlat"></a><h3>Network Customization Platform</h3>
+
+
+
+<a name="androidNetCustPlatNetworkConfig"></a><h4>Network Configuration</h4>
+
+<p>Android stores network configurations as a resource that gets compiled into binary at form at build time. The XML representation of this resource is located at <code>//android/frameworks/base/core/res/res/xml/apns.xml</code>. This file does not include any configured APNs. You should not modify this file, but instead configure APNs by product at build time (see Build-time APN Configuration below).</p>
+<p>Each network configuration is stored in an XML element following this syntax:</p>
+<pre class="prettify">
+<apn carrier="T-Mobile US"
+ mcc="310"
+ mnc="260"
+ apn=" wap.voicestream.com"
+ user="none"
+ server="*"
+ password="none"
+ proxy=" 216.155.165.50"
+ port="8080"
+ mmsc="http://216.155.174.84/servlets/mms"
+/>
+</pre>
+
+
+<a name="androidNetCustPlatAPNConfig"></a><h4>Build-time APN configuration</h4>
+
+<p>To set the APN configuration for a particular product target, add an <code>apns-conf.xml</code> file to the product configuration (do not modify the default platform APNs). This allows multiple products, all with different APNs, to be built off the same code base. </p>
+
+<p>To configure APNs at the product level, add a line to the product configuration file like the example below (<code>vendor/<vendor_name>/products/myphone-us.mk</code>): </p>
+
+<pre class="prettify">
+PRODUCT_COPY_FILES := vendor/acme/etc/apns-conf-us.xml:system/etc/apns-conf.xml
+</pre>
+
+
+
+<a name="androidNetCustPlatAPNRunTime"></a><h4>APN configuration at run time</h4>
+
+<p>At runtime, the Android reads APNs from the following file:</p>
+<pre class="prettify">
+system/etc/apns-conf.xml
+</pre>
+
+<p>Android supports the following run-time network configuration methods to choose the appropriate APN from the list of configured APNs:</p>
+<p><ul>
+<li><b>Automatic Configuration</b>: At boot time, Android determines the correct network configuration based on the MCC and MNC from the SIM card and automatically configure all network settings.</li>
+<li><b>Manual Configuration</b>: The platform will also support runtime (user) manual selection of network settings by name, for example, "Company Name US," and will support manual network configuration entry.</li>
+<li><b>WAP / SMS Push Configuration</b>: The network configurations are standard Android resources. You can upgrade a resource at runtime by installing a new system resource APK package. It will be possible to develop a network configuration service which listens to a specific binary SMS port for binary SMS messages containing the network configurations. NOTE: The implementation will likely be network operator dependent due to inconsistent SMS ports, binary SMS formats, etc.</li>
+</ul>
+
+
+
+
+<a name="androidCustomizingPre-LoadedApps"></a><h3>Customizing pre-loaded applications</h3>
+
+<p>To customize the list of Android packages for a particular product (applications, input methods, providers, services, etc.), set <code>PRODUCT_PACKAGES</code> property in the product configuration, as illustrated below:</p>
+
+<pre class="prettify">
+PRODUCT_PACKAGES := \
+ <company_name>Mail \
+ <company_name>IM \
+ <company_name>HomeScreen \
+ <company_name>Maps \
+ <company_name>SystemUpdater
+</pre>
+
+<p>Package names should correspond to the <code>LOCAL_PACKAGE_NAME</code> specified for each package's build target. For example, the <code>Android.mk</code> build target for <company_name>Mail, referenced above, could look like this:
+
+<pre class="prettify">
+# Build the <company_name>Mail application
+LOCAL_PATH:= $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := user development
+
+LOCAL_SRC_FILES := $(call all-java-files-under,src,tests)
+
+LOCAL_STATIC_JAVA_LIBRARIES := <company_name>login-client
+
+# Specify the package name
+LOCAL_PACKAGE_NAME := <company_name>Mail
+
+# Specify the certificate used to sign the application
+LOCAL_CERTIFICATE := vendor/<company_name>/certs/app
+
+include $(BUILD_PACKAGE)
+
+# Build the login client static library
+include $(LOCAL_PATH)/client/Android.mk
+</pre>
+
+<p>Note that the home screen is just an Android application that can be replaced entirely or customized by changing source code and application resources (Java source, layouts, etc.).</p>
+
+
+
+<a name="androidBrowserBookmarks"></a><h3>Customizing browser bookmarks</h3>
+
+<p>Browser bookmarks are stored as string resources in the Browser application: <code>//android/packages/apps/Browser/res/values/strings.xml</code>. Bookmarks are defined as simple value string arrays called "bookmarks". Each bookmark entry is stored as a pair of array values; the first represents the bookmark name and the second the bookmark URL. For example:</p>
+<pre class="prettify">
+<!-- Bookmarks -->
+<string-array name="bookmarks">
+ <item>Google</item>
+ <item>http://www.google.com/</item>
+ <item>Yahoo!</item>
+ <item>http://www.yahoo.com/</item>
+ <item>MSN</item>
+ <item>http://www.msn.com/</item>
+ <item>MySpace</item>
+ <item>http://www.myspace.com/</item>
+ <item>Facebook</item>
+ <item>http://www.facebook.com/</item>
+ <item>Wikipedia</item>
+ <item>http://www.wikipedia.org/</item>
+ <item>eBay</item>
+ <item>http://www.ebay.com/</item>
+ <item>CNN</item>
+ <item>http://www.cnn.com/</item>
+ <item>New York Times</item>
+ <item>http://www.nytimes.com/</item>
+ <item>ESPN</item>
+ <item>http://espn.go.com/</item>
+ <item>Amazon</item>
+ <item>http://www.amazon.com/</item>
+ <item>Weather Channel</item>
+ <item>http://www.weather.com/</item>
+ <item>BBC</item>
+ <item>http://www.bbc.co.uk/</item>
+</string-array>
+</pre>
+<p>Like and Android application resource, the platform will load alternate resources based on the platform configuration values. See <a href="http://developer.android.com/guide/topics/resources/resources-i18n.html">Resources and Internationalization</a> in the Android SDK for details. To configure bookmarks for a specific mobile network operator, place your customized bookmarks in a separate <code>strings.xml</code> file and place it under a Mobile Network Code (MNO) specific resource folder. For example, <code>Browser/res/values-mccXXX-mncYYY/strings.xml</code> where XXX and YYY represent the three-digit MCC and two to three digit MNC values.</p>
+<p>Android loads any configuration-specific resources as override values for the default values, so it is only necessary to include the bookmarks string-array values in this file.</p>
+
+
+
+<a name="androidEmailProviderCustomization"></a>
+<h3>Email Provider Customization</h3>
+
+<p>The default email provider settings are stored as string resources in the Email application (<code>//android/packages/apps/Email/res/xml/providers.xml</code>) as illustrated below.</p>
+<p><providers></p>
+<pre class="prettify">
+<!-- Gmail variants -->
+ <provider id="gmail" label="Gmail" domain="gmail.com">
+ <incoming uri="imap+ssl+://imap.gmail.com" username="$email"/>
+ <outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email"/>
+ </provider>
+ <provider id="googlemail" label="Google Mail" domain="googlemail.com">
+ <incoming uri="imap+ssl+://imap.googlemail.com" username="$email"/>
+ <outgoing uri="smtp+ssl+://smtp.googlemail.com" username="$email"/>
+ </provider>
+ <provider id="google" label="Google" domain="google.com">
+ <incoming uri="imap+ssl+://imap.gmail.com" username="$email"/>
+ <outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email"/>
+ </provider>
+ <provider id="android" label="Android" domain="android.com">
+ <incoming uri="imap+ssl+://imap.gmail.com" username="$email"/>
+ <outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email"/>
+ </provider></p>
+
+ <!-- Common US providers -->
+
+ <provider id="aim" label="AIM" domain="aim.com">
+ <incoming uri="imap://imap.aim.com" label="IMAP" username="$email"/>
+ <outgoing uri="smtp://smtp.aim.com:587" username="$email"/>
+ </provider>
+ <provider id="aol" label="AOL" domain="aol.com">
+ <incoming uri="imap://imap.aol.com" label="IMAP" username="$email"/>
+ <outgoing uri="smtp://smtp.aol.com:587" username="$email"/>
+ </provider>
+ <provider id="comcast" label="Comcast" domain="comcast.net">
+ <incoming uri="pop3+ssl+://mail.comcast.net" username="$user"/>
+ <outgoing uri="smtp+ssl+://smtp.comcast.net" username="$user"/>
+ </provider>
+ <provider id="compuserve" label="CompuServe" domain="cs.com">
+ <incoming uri="imap://imap.cs.com" username="$user"/>
+ <outgoing uri="smtp://smtp.cs.com" username="$user"/>
+ </provider>
+ <provider id="dotmac" label=".Mac" domain="mac.com">
+ <incoming uri="imap+tls://mail.mac.com" username="$email"/>
+ <outgoing uri="smtp+tls://smtp.mac.com" username="$email"/>
+ </provider>
+ <provider id="earthlink" label="Earthlink" domain="earthlink.net">
+ <incoming uri="pop3://pop.earthlink.net" username="$email"/>
+ <outgoing uri="smtp://smtpauth.earthlink.net:587" username="$email"/>
+ </provider>
+ <provider id="juno" label="Juno" domain="juno.com">
+ <incoming uri="pop3://pop.juno.com" username="$user"/>
+ <outgoing uri="smtp://smtp.juno.com" username="$user"/>
+ </provider>
+ <provider id="live" label="Windows Live Hotmail Plus" domain="live.com" note="@string/provider_note_live">
+ <incoming uri="pop3+ssl+://pop3.live.com" username="$email"/>
+ <outgoing uri="smtp+tls+://smtp.live.com" username="$email"/>
+ </provider>
+ <provider id="hotmail" label="Windows Live Hotmail Plus" domain="hotmail.com" note="@string/provider_note_live">
+ <incoming uri="pop3+ssl+://pop3.live.com" username="$email"/>
+ <outgoing uri="smtp+tls+://smtp.live.com" username="$email"/>
+ </provider>
+ <provider id="msn" label="Windows Live Hotmail Plus" domain="msn.com" note="@string/provider_note_live">
+ <incoming uri="pop3+ssl+://pop3.live.com" username="$email"/>
+ <outgoing uri="smtp+tls+://smtp.live.com" username="$email"/>
+ </provider>
+ <provider id="mobileme" label="MobileMe" domain="me.com">
+ <incoming uri="imap+tls://mail.me.com" username="$email"/>
+ <outgoing uri="smtp+tls://smtp.me.com" username="$email"/>
+ </provider>
+ <provider id="netzero" label="NetZero" domain="netzero.com">
+ <incoming uri="pop3://pop.netzero.com" username="$user"/>
+ <outgoing uri="smtp://smtp.netzero.com" username="$user"/>
+ </provider>
+ <provider id="sbcglobal" label="SBC Global" domain="sbcglobal.net">
+ <incoming uri="pop3://pop.sbcglobal.yahoo.com" username="$email"/>
+ <outgoing uri="smtp://smtp.sbcglobal.yahoo.com" username="$email"/>
+ </provider>
+ <provider id="verizon" label="Verizon" domain="verizon.net">
+ <incoming uri="pop3://incoming.verizon.net" username="$user"/>
+ <outgoing uri="smtp://outgoing.verizon.net" username="$user"/>
+ </provider>
+ <provider id="yahoo" label="Yahoo Plus" domain="yahoo.com" note="@string/provider_note_yahoo">
+ <incoming uri="pop3+ssl+://plus.pop.mail.yahoo.com" username="$user"/>
+ <outgoing uri="smtp+ssl+://plus.smtp.mail.yahoo.com" username="$user"/>
+ </provider>
+
+ <!-- Common UK providers -->
+
+ <provider id="aol-uk" label="AOL" domain="aol.co.uk">
+ <incoming uri="imap+ssl+://imap.uk.aol.com" label="IMAP" username="$user"/>
+ <outgoing uri="smtp+ssl+://smtp.uk.aol.com" username="$user"/>
+ </provider>
+ <provider id="bt" label="BT Internet" domain="btinternet.com">
+ <incoming uri="pop3://mail.btinternet.com" username="$email"/>
+ <outgoing uri="smtp://mail.btinternet.com" username=""/>
+ </provider>
+ <provider id="tiscali" label="Tiscali" domain="tiscali.co.uk">
+ <incoming uri="pop3://pop.tiscali.co.uk" username="$email"/>
+ <outgoing uri="smtp://smtp.tiscali.co.uk" username="$email:wq"/>
+ </provider>
+ <provider id="yahoo-uk" label="Yahoo" domain="yahoo.co.uk" note="@string/provider_note_yahoo_uk">
+ <incoming uri="pop3+ssl+://pop.mail.yahoo.co.uk" username="$user"/>
+ <outgoing uri="smtp+ssl+://smtp.mail.yahoo.co.uk" username="$user"/>
+ </provider>
+
+ <!-- Common Germany providers -->
+
+ <provider id="freenet" label="Freenet" domain="freenet.de">
+ <incoming uri="pop3://mx.freenet.de" username="$user"/>
+ <outgoing uri="smtp+ssl://mx.freenet.de" username="$email"/>
+ </provider>
+ <provider id="gmx" label="GMX" domain="gmx.de">
+ <incoming uri="pop3+tls://pop.gmx.net" username="$email"/>
+ <outgoing uri="smtp+tls://mail.gmx.net" username="$email"/>
+ </provider>
+ <provider id="T-Online" label="T-Online" domain="t-online.de" note="@string/provider_note_t_online">
+ <incoming uri="pop3://popmail.t-online.de" username="$email"/>
+ <outgoing uri="smtp://smtpmail.t-online.de" username="$email"/>
+ </provider>
+ <provider id="web.de" label="Web.de" domain="web.de">
+ <incoming uri="pop3+tls://pop3.web.de" username="$user"/>
+ <outgoing uri="smtp+tls://smtp.web.de" username="$user"/>
+ </provider>
+</providers>
+</pre>
+<p>As with all Android application resources, the platform will load alternate resources based on the platform configuration values. See <a href="http://developer.android.com/guide/topics/resources/resources-i18n.html">Resources and Internationalization</a> in the Android SDK for details. To configure email providers for a specific mobile network operator, place the customized providers in a separate <code>providers.xml</code> file and place it under a Mobile Network Code (MNO) specific resource folder. For example, <code>Email/res/xml-mccXXX-mncYYY/providers.xml</code> where XXX and YYY represent the three-digit MCC and two to three digit MNC values.</p>
+
+
+
+<a name="androidThemes"></a><h3>Platform Themes</h3>
+
+
+
+<a name="androidThemesStyles"></a><h4>Themes and Styles</h4>
+
+<p>System level styles are defined in <code>//android/framework/base/core/res/res/values/styles.xml</code>.</p>
+
+
+<a name="androidThemesAnimations"></a><h4>Animations</h4>
+
+<p>Android supports configurable animations for window and view transitions. System-level animations are defined in XML in global resource files located in <code>//android/framework/base/core/res/res/anim/</code>.</p>
+
diff --git a/pdk/docs/porting/dalvik.jd b/pdk/docs/porting/dalvik.jd
new file mode 100755
index 0000000..50b7499
--- /dev/null
+++ b/pdk/docs/porting/dalvik.jd
@@ -0,0 +1,355 @@
+page.title=Dalvik
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#dalvikCoreLibraries">Core Libraries</a></li>
+<li><a href="#dalvikJNICallBridge">JNI Call Bridge</a></li>
+<li><a href="#dalvikInterpreter">Interpreter</a></li>
+</ul>
+</div>
+</div>
+
+<p>
+The Dalvik virtual machine is intended to run on a variety of platforms.
+The baseline system is expected to be a variant of UNIX (Linux, BSD, Mac
+OS X) running the GNU C compiler. Little-endian CPUs have been exercised
+the most heavily, but big-endian systems are explicitly supported.
+</p><p>
+There are two general categories of work: porting to a Linux system
+with a previously unseen CPU architecture, and porting to a different
+operating system. This document covers the former.
+</p>
+
+
+<a name="dalvikCoreLibraries"></a><h3>Core Libraries</h3>
+
+<p>
+The native code in the core libraries (chiefly <code>dalvik/libcore</code>,
+but also <code>dalvik/vm/native</code>) is written in C/C++ and is expected
+to work without modification in a Linux environment. Much of the code
+comes directly from the Apache Harmony project.
+</p><p>
+The core libraries pull in code from many other projects, including
+OpenSSL, zlib, and ICU. These will also need to be ported before the VM
+can be used.
+</p>
+
+
+<a name="dalvikJNICallBridge"></a><h3>JNI Call Bridge</h3>
+
+<p>
+Most of the Dalvik VM runtime is written in portable C. The one
+non-portable component of the runtime is the JNI call bridge. Simply put,
+this converts an array of integers into function arguments of various
+types, and calls a function. This must be done according to the C calling
+conventions for the platform. The task could be as simple as pushing all
+of the arguments onto the stack, or involve complex rules for register
+assignment and stack alignment.
+</p><p>
+To ease porting to new platforms, the <a href="http://sourceware.org/libffi/">
+open-source FFI library</a> (Foreign Function Interface) is used when a
+custom bridge is unavailable. FFI is not as fast as a native implementation,
+and the optional performance improvements it does offer are not used, so
+writing a replacement is a good first step.
+</p><p>
+The code lives in <code>dalvik/vm/arch/*</code>, with the FFI-based version
+in the "generic" directory. There are two source files for each architecture.
+One defines the call bridge itself:
+</p><p><blockquote>
+<code>void dvmPlatformInvoke(void* pEnv, ClassObject* clazz, int argInfo,
+int argc, const u4* argv, const char* signature, void* func,
+JValue* pReturn)</code>
+</blockquote></p><p>
+This will invoke a C/C++ function declared:
+</p><p><blockquote>
+ <code>return_type func(JNIEnv* pEnv, Object* this [, <i>args</i>])<br></code>
+</blockquote>or (for a "static" method):<blockquote>
+ <code>return_type func(JNIEnv* pEnv, ClassObject* clazz [, <i>args</i>])</code>
+</blockquote></p><p>
+The role of <code>dvmPlatformInvoke</code> is to convert the values in
+<code>argv</code> into C-style calling conventions, call the method, and
+then place the return type into <code>pReturn</code> (a union that holds
+all of the basic JNI types). The code may use the method signature
+(a DEX "shorty" signature, with one character for the return type and one
+per argument) to determine how to handle the values.
+</p><p>
+The other source file involved here defines a 32-bit "hint". The hint
+is computed when the method's class is loaded, and passed in as the
+"argInfo" argument. The hint can be used to avoid scanning the ASCII
+method signature for things like the return value, total argument size,
+or inter-argument 64-bit alignment restrictions.
+</p>
+
+<a name="dalvikInterpreter"></a><h3>Interpreter</h3>
+
+<p>
+The Dalvik runtime includes two interpreters, labeled "portable" and "fast".
+The portable interpreter is largely contained within a single C function,
+and should compile on any system that supports gcc. (If you don't have gcc,
+you may need to disable the "threaded" execution model, which relies on
+gcc's "goto table" implementation; look for the THREADED_INTERP define.)
+</p><p>
+The fast interpreter uses hand-coded assembly fragments. If none are
+available for the current architecture, the build system will create an
+interpreter out of C "stubs". The resulting "all stubs" interpreter is
+quite a bit slower than the portable interpreter, making "fast" something
+of a misnomer.
+</p><p>
+The fast interpreter is enabled by default. On platforms without native
+support, you may want to switch to the portable interpreter. This can
+be controlled with the <code>dalvik.vm.execution-mode</code> system
+property. For example, if you:
+</p><p><blockquote>
+<code>adb shell "echo dalvik.vm.execution-mode = int:portable >> /data/local.prop"</code>
+</blockquote></p><p>
+and reboot, the Android app framework will start the VM with the portable
+interpreter enabled.
+</p>
+
+
+<h3>Mterp Interpreter Structure</h3>
+
+<p>
+There may be significant performance advantages to rewriting the
+interpreter core in assembly language, using architecture-specific
+optimizations. In Dalvik this can be done one instruction at a time.
+</p><p>
+The simplest way to implement an interpreter is to have a large "switch"
+statement. After each instruction is handled, the interpreter returns to
+the top of the loop, fetches the next instruction, and jumps to the
+appropriate label.
+</p><p>
+An improvement on this is called "threaded" execution. The instruction
+fetch and dispatch are included at the end of every instruction handler.
+This makes the interpreter a little larger overall, but you get to avoid
+the (potentially expensive) branch back to the top of the switch statement.
+</p><p>
+Dalvik mterp goes one step further, using a computed goto instead of a goto
+table. Instead of looking up the address in a table, which requires an
+extra memory fetch on every instruction, mterp multiplies the opcode number
+by a fixed value. By default, each handler is allowed 64 bytes of space.
+</p><p>
+Not all handlers fit in 64 bytes. Those that don't can have subroutines
+or simply continue on to additional code outside the basic space. Some of
+this is handled automatically by Dalvik, but there's no portable way to detect
+overflow of a 64-byte handler until the VM starts executing.
+</p><p>
+The choice of 64 bytes is somewhat arbitrary, but has worked out well for
+ARM and x86.
+</p><p>
+In the course of development it's useful to have C and assembly
+implementations of each handler, and be able to flip back and forth
+between them when hunting problems down. In mterp this is relatively
+straightforward. You can always see the files being fed to the compiler
+and assembler for your platform by looking in the
+<code>dalvik/vm/mterp/out</code> directory.
+</p><p>
+The interpreter sources live in <code>dalvik/vm/mterp</code>. If you
+haven't yet, you should read <code>dalvik/vm/mterp/README.txt</code> now.
+</p>
+
+
+<h3>Getting Started With Mterp</h3>
+
+</p><p>
+Getting started:
+<ol>
+<li>Decide on the name of your architecture. For the sake of discussion,
+let's call it <code>myarch</code>.
+<li>Make a copy of <code>dalvik/vm/mterp/config-allstubs</code> to
+<code>dalvik/vm/mterp/config-myarch</code>.
+<li>Create a <code>dalvik/vm/mterp/myarch</code> directory to hold your
+source files.
+<li>Add <code>myarch</code> to the list in
+<code>dalvik/vm/mterp/rebuild.sh</code>.
+<li>Make sure <code>dalvik/vm/Android.mk</code> will find the files for
+your architecture. If <code>$(TARGET_ARCH)</code> is configured this
+will happen automatically.
+</ol>
+</p><p>
+You now have the basic framework in place. Whenever you make a change, you
+need to perform two steps: regenerate the mterp output, and build the
+core VM library. (It's two steps because we didn't want the build system
+to require Python 2.5. Which, incidentally, you need to have.)
+<ol>
+<li>In the <code>dalvik/vm/mterp</code> directory, regenerate the contents
+of the files in <code>dalvik/vm/mterp/out</code> by executing
+<code>./rebuild.sh</code>. Note there are two files, one in C and one
+in assembly.
+<li>In the <code>dalvik</code> directory, regenerate the
+<code>libdvm.so</code> library with <code>mm</code>. You can also use
+<code>make libdvm</code> from the top of the tree.
+</ol>
+</p><p>
+This will leave you with an updated libdvm.so, which can be pushed out to
+a device with <code>adb sync</code> or <code>adb push</code>. If you're
+using the emulator, you need to add <code>make snod</code> (System image,
+NO Dependency check) to rebuild the system image file. You should not
+need to do a top-level "make" and rebuild the dependent binaries.
+</p><p>
+At this point you have an "all stubs" interpreter. You can see how it
+works by examining <code>dalvik/vm/mterp/cstubs/entry.c</code>. The
+code runs in a loop, pulling out the next opcode, and invoking the
+handler through a function pointer. Each handler takes a "glue" argument
+that contains all of the useful state.
+</p><p>
+Your goal is to replace the entry method, exit method, and each individual
+instruction with custom implementations. The first thing you need to do
+is create an entry function that calls the handler for the first instruction.
+After that, the instructions chain together, so you don't need a loop.
+(Look at the ARM or x86 implementation to see how they work.)
+</p><p>
+Once you have that, you need something to jump to. You can't branch
+directly to the C stub because it's expecting to be called with a "glue"
+argument and then return. We need a C stub "wrapper" that does the
+setup and jumps directly to the next handler. We write this in assembly
+and then add it to the config file definition.
+</p><p>
+To see how this works, create a file called
+<code>dalvik/vm/mterp/myarch/stub.S</code> that contains one line:
+<pre>
+/* stub for ${opcode} */
+</pre>
+Then, in <code>dalvik/vm/mterp/config-myarch</code>, add this below the
+<code>handler-size</code> directive:
+<pre>
+# source for the instruction table stub
+asm-stub myarch/stub.S
+</pre>
+</p><p>
+Regenerate the sources with <code>./rebuild.sh</code>, and take a look
+inside <code>dalvik/vm/mterp/out/InterpAsm-myarch.S</code>. You should
+see 256 copies of the stub function in a single large block after the
+<code>dvmAsmInstructionStart</code> label. The <code>stub.S</code>
+code will be used anywhere you don't provide an assembly implementation.
+</p><p>
+Note that each block begins with a <code>.balign 64</code> directive.
+This is what pads each handler out to 64 bytes. Note also that the
+<code>${opcode}</code> text changed into an opcode name, which should
+be used to call the C implementation (<code>dvmMterp_${opcode}</code>).
+</p><p>
+The actual contents of <code>stub.S</code> are up to you to define.
+See <code>entry.S</code> and <code>stub.S</code> in the <code>armv5te</code>
+or <code>x86</code> directories for working examples.
+</p><p>
+If you're working on a variation of an existing architecture, you may be
+able to use most of the existing code and just provide replacements for
+a few instructions. Look at the <code>armv4t</code> implementation as
+an example.
+</p>
+
+
+<h3>Replacing Stubs</h3>
+
+<p>
+There are roughly 230 Dalvik opcodes, including some that are inserted by
+<a href="dexopt.html">dexopt</a> and aren't described in the
+<a href="dalvik-bytecode.html">Dalvik bytecode</a> documentation. Each
+one must perform the appropriate actions, fetch the next opcode, and
+branch to the next handler. The actions performed by the assembly version
+must exactly match those performed by the C version (in
+<code>dalvik/vm/mterp/c/OP_*</code>).
+</p><p>
+It is possible to customize the set of "optimized" instructions for your
+platform. This is possible because optimized DEX files are not expected
+to work on multiple devices. Adding, removing, or redefining instructions
+is beyond the scope of this document, and for simplicity it's best to stick
+with the basic set defined by the portable interpreter.
+</p><p>
+Once you have written a handler that looks like it should work, add
+it to the config file. For example, suppose we have a working version
+of <code>OP_NOP</code>. For demonstration purposes, fake it for now by
+putting this into <code>dalvik/vm/mterp/myarch/OP_NOP.S</code>:
+<pre>
+/* This is my NOP handler */
+</pre>
+</p><p>
+Then, in the <code>op-start</code> section of <code>config-myarch</code>, add:
+<pre>
+ op OP_NOP myarch
+</pre>
+</p><p>
+This tells the generation script to use the assembly version from the
+<code>myarch</code> directory instead of the C version from the <code>c</code>
+directory.
+</p><p>
+Execute <code>./rebuild.sh</code>. Look at <code>InterpAsm-myarch.S</code>
+and <code>InterpC-myarch.c</code> in the <code>out</code> directory. You
+will see that the <code>OP_NOP</code> stub wrapper has been replaced with our
+new code in the assembly file, and the C stub implementation is no longer
+included.
+</p><p>
+As you implement instructions, the C version and corresponding stub wrapper
+will disappear from the output files. Eventually you will have a 100%
+assembly interpreter.
+</p>
+
+
+<h3>Interpreter Switching</h3>
+
+<p>
+The Dalvik VM actually includes a third interpreter implementation: the debug
+interpreter. This is a variation of the portable interpreter that includes
+support for debugging and profiling.
+</p><p>
+When a debugger attaches, or a profiling feature is enabled, the VM
+will switch interpreters at a convenient point. This is done at the
+same time as the GC safe point check: on a backward branch, a method
+return, or an exception throw. Similarly, when the debugger detaches
+or profiling is discontinued, execution transfers back to the "fast" or
+"portable" interpreter.
+</p><p>
+Your entry function needs to test the "entryPoint" value in the "glue"
+pointer to determine where execution should begin. Your exit function
+will need to return a boolean that indicates whether the interpreter is
+exiting (because we reached the "bottom" of a thread stack) or wants to
+switch to the other implementation.
+</p><p>
+See the <code>entry.S</code> file in <code>x86</code> or <code>armv5te</code>
+for examples.
+</p>
+
+
+<h3>Testing</h3>
+
+<p>
+A number of VM tests can be found in <code>dalvik/tests</code>. The most
+useful during interpreter development is <code>003-omnibus-opcodes</code>,
+which tests many different instructions.
+</p><p>
+The basic invocation is:
+<pre>
+$ cd dalvik/tests
+$ ./run-test 003
+</pre>
+</p><p>
+This will run test 003 on an attached device or emulator. You can run
+the test against your desktop VM by specifying <code>--reference</code>
+if you suspect the test may be faulty. You can also use
+<code>--portable</code> and <code>--fast</code> to explictly specify
+one Dalvik interpreter or the other.
+</p><p>
+Some instructions are replaced by <code>dexopt</code>, notably when
+"quickening" field accesses and method invocations. To ensure
+that you are testing the basic form of the instruction, add the
+<code>--no-optimize</code> option.
+</p><p>
+There is no in-built instruction tracing mechanism. If you want
+to know for sure that your implementation of an opcode handler
+is being used, the easiest approach is to insert a "printf"
+call. For an example, look at <code>common_squeak</code> in
+<code>dalvik/vm/mterp/armv5te/footer.S</code>.
+</p><p>
+At some point you need to ensure that debuggers and profiling work with
+your interpreter. The easiest way to do this is to simply connect a
+debugger or toggle profiling. (A future test suite may include some
+tests for this.)
+</p>
+
+
diff --git a/pdk/docs/porting/debugging_gdb.jd b/pdk/docs/porting/debugging_gdb.jd
new file mode 100755
index 0000000..17ff471
--- /dev/null
+++ b/pdk/docs/porting/debugging_gdb.jd
@@ -0,0 +1,146 @@
+page.title=Debugging with GDB
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#gdb">Debugging</a></li>
+ <li><a href="#justInTime">Just-In-Time Debug Feature</a></li>
+</ul>
+</div>
+</div>
+
+<p>The current version of <code>envsetup.sh</code> has a <code>gdbclient</code> command that handles much of the setup. For example, to attach the
+ already-running <code>globaltime</code> application, execute the following, making sure that: 1) you do this from the same window used to build the software on the device you are debugging and 2) verify that the symbols in the object files in the build tree match up with what is installed on the device or emulator.</p>
+<pre class="prettify">
+gdbclient app_process :5039 globaltime
+</pre>
+<a name="gdb"></a><h3>Debugging</h3>
+<a name="gdbShort"></a>
+<h4>Short Instructions</h4>
+<p>Android runs <code>gdbserver</code> on the device and an ARM aware <code>gdb</code>, named <code>arm-eabi-gdb</code>, on the desktop machine.</p>
+<ol>
+ <li>First you need to
+ run <code>gdbserver</code> on the device:<BR>
+ <pre class="prettify">
+ gdbserver :5039 /system/bin/<i>executable</i>
+ </pre>
+ <BR>
+ The <code>:5039</code> tells gdbserver to listen on port 5039 on the localhost, which adb bridges from the host to the device. <code>executable</code> represents the command to debug, a common one being runtime -s which starts the entire system all running in a single process. <br>
+ <br>
+ </li>
+ <li>Launch <code>gdb</code> on the desktop.
+ This can be
+ done easily with the following command in the shell from which you built:
+ <pre class="prettify">
+gdbclient <i>executable</i>
+</pre>
+ </li>
+</ol>
+<p>At this point <code>gdb</code> will connect with your device
+ and you should be
+ able to enter <code>c</code> to have the device start executing inside of the
+ desktop <code>gdb</code> session.</p>
+<a name="gdbDetailed"></a>
+<h4>Detailed Instructions</h4>
+<p>If the short instructions don't work, these detailed instructions should:
+<ol>
+ <li>On the device, launch a new command:
+ <pre class="prettify">gdbserver :5039 /system/bin/<i>executable</i></pre>
+ or attach to an existing process:
+ <pre class="prettify">gdbserver :5039 --attach <i>pid</i></pre>
+ </li>
+ <li>On your workstation, forward port 5039 to the device with adb:
+ <pre class="prettify">adb forward tcp:5039 tcp:5039</pre>
+ </li>
+ <li>Start a special version of <code>gdb</code> that lives in the "prebuilt" area of the source tree: <br>
+ <code>prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-eabi-gdb</code> (for Linux) <br>
+ <code>prebuilt/darwin-x86/toolchain-eabi-4.2.1/bin/arm-eabi-gdb</code> (for Darwin) </li>
+ <li>If you can't find either special version of <code>gdb</code>, run <code>find prebuilt -name arm-eabi-gdb</code> in your source tree to find and run the latest version:
+ <pre class="prettify">
+prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-eabi-gdb out/target/product/<i>product-name</i>/symbols/system/bin/<i>executable</i>
+</pre>
+ <BR>
+ Where <i>product-name</i> is the name of the device product that you're building (for example, <code>sooner</code>),
+ and <i>executable</i> is the program to debug (usually <code>app_process</code> for an application).<br>
+ <br>
+ Make sure to use the copy of the executable in the symbols directory, not the
+ primary android directory, because the one in the primary directory has
+ been stripped of its debugging information.</li>
+ <li>In <code>gdb</code>, Tell <code>gdb</code> where to find the shared libraries that will get loaded:
+ <pre class="prettify">
+set solib-absolute-prefix /<i>absolute-source-path</i>/out/target/product/<i>product-name</i>/symbols
+set solib-search-path /<i>absolute-source-path</i>/out/target/product/<i>product-name</i>/symbols/system/lib
+</pre>
+ <BR>
+ <i>absolute-source-path</i> is the path to your source tree; for example, <code>/work/device</code> or <code>/Users/hoser/android/device</code>.<BR>
+ <i>product-name</i> is the same as above; for example, <code>sooner</code>. <BR>
+ <BR>
+ Make sure you specify the correct directories—<code>gdb</code> may not tell you if you make a mistake.</li>
+ <li>Connect to the device by issuing the <code>gdb</code> command:<BR>
+ <pre class="prettify">
+target remote :5039
+</pre>
+ <BR>
+ <BR>
+ The <code>:5039</code> tells <code>gdb</code> to connect to the localhost port 5039, which is bridged to the device by <code>adb</code>.<BR>
+ <BR>
+ You may need to inspire gdb to load some symbols by typing:
+ <pre class="prettify">shared</pre>
+ </li>
+</ol>
+<p>You should be connected and able to debug as you normally would. You can ignore the error about not
+ finding the location for the thread creation breakpoint. It will be found when
+ the linker loads <code>libc</code> into your process before hitting <code>main()</code>. Also note that
+ the <code>gdb</code> remote protocol doesn't have a way for the device to
+ tell the host about
+ newly created threads so you will not always see notifications about newly
+ created threads. Info about other threads will be queried from the
+ device when a
+ breakpoint is hit or you ask for it by running info thread. <a name="justInTime"></a>
+<h3>Just-In-Time Debug Feature</h3>
+If you see the red LED flashing it means a process is in that new
+state (crashed and waiting for GDB connection). If this happens to the
+system process, most likely your device will be frozen at this point. <strong>Do not press the home key</strong>. Bring the device to someone who can
+debug native crashes and ask for advice.
+If you're in the field and just want your device to continue as it
+would have without this feature (like cylonning), press home (a
+tombstone will be recorded as usual).
+
+To enable a process to be debugged this way, you need to set a property:
+<pre class="prettify">
+adb shell setprop debug.db.uid 10000
+</pre>
+and all processes with a <code>uid <= 10000</code> will be trapped in this
+manner. When one of them crashes, the tombstone is processed as usual, an explicit message is printed into the log, and the red LED starts
+flashing waiting for the Home key to be depressed (in which case it
+continues execution as usual).
+<pre class="prettify">
+I/DEBUG ( 27): ********************************************************
+I/DEBUG ( 27): * process 82 crashed. debuggerd waiting for gdbserver
+I/DEBUG ( 27): *
+I/DEBUG ( 27): * adb shell gdbserver :port --attach 82 &
+I/DEBUG ( 27): *
+I/DEBUG ( 27): * and press the HOME key.
+I/DEBUG ( 27): ********************************************************
+</pre>
+<p>When you see the entry above, make sure <code>adb</code> is forwarding port 5039 (you only need to do this once,
+ unless the ADB server dies) and execute:</p>
+<pre class="prettify">% adb forward tcp:5039 tcp:5039</pre>
+Execute the line shown in the debug output, substituting 5039 for the proper <code>port</code>:
+<pre class="prettify">
+% adb shell gdbserver :5039 --attach 82 &
+</pre>
+<p>If the crashing process is based off zygote (that is, system_server and all
+ applications), the default values for the <code>gdbclient</code> command, <code>app_process</code> binary and port <code>5039</code>, are correct, so you can execute:</p>
+<pre class="prettify">
+% cd <top of device source tree>
+% gdbclient
+</pre>
+<p>Otherwise you need to determine the path of the crashing binary and follow the
+ steps as mentioned above (for example, <code>gdbclient hoser :5039</code> if
+ the <code>hoser</code> command has failed).</p>
diff --git a/pdk/docs/porting/debugging_native.jd b/pdk/docs/porting/debugging_native.jd
new file mode 100755
index 0000000..7bb655f
--- /dev/null
+++ b/pdk/docs/porting/debugging_native.jd
@@ -0,0 +1,305 @@
+page.title=Debugging Native Code
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#Capturing_logs">Capturing logs</a></li>
+<li><a href="#Debug_Scenarios">Debug Scenarios</a></li>
+</ul>
+</div>
+</div>
+
+<a name="Capturing_logs"></a><h3>Capturing logs</h3>
+
+<p>To capture log output:</p>
+<ol>
+<li> Produce a process list with <code>ps</code> (<code>ps -t</code> if you want verbose thread feedback).</li>
+<li> Dump kernel messages with <code>dmesg</code>.</li>
+<li> Get verbose log messages with <code>logcat '*:v' &</code> (running in bg with & is important).</li>
+
+</ol>
+
+<a name="Debug_Scenarios"></a><h3>Debug Scenarios</h3>
+<pre class="prettify">
+ # command to device shell (via adb)
+ % command to host pc shell
+</pre>
+<p>
+</p>
+
+<a name="Crash_but_no_exit_stuck"></a><h4>Crash but no exit...stuck</h4>
+
+<p>In this scenario, the GTalk app crashed but did not actually exit or seems stuck. Check the debug logs to see if there is anything unusual: </p>
+
+<pre class="prettify">
+# logcat &
+
+...
+E/WindowManager( 182): Window client android.util.BinderProxy@4089f948 has died!! Removing window.
+W/WindowManager( 182): **** WINDOW CLIENT android.view.WindowProxy@40882248 DIED!
+W/ActivityManager( 182): **** APPLICATION com.google.android.gtalk DIED!
+I/ServiceManager( 257): Executing: /android/bin/app_process (link=/tmp/android-servicemanager/com.google.android.gtalk, wrapper=/tmp/android-servi
+cemanager/com.google.android.gtalk)
+I/appproc ( 257): App process is starting with pid=257, class=android/activity/ActivityThread.
+I/ ( 257): java.io.FileDescriptor: class initialization
+I/SurfaceFlinger.HW( 182): About to give-up screen
+I/SurfaceFlinger.HW( 182): screen given-up
+I/SurfaceFlinger.HW( 182): Screen about to return
+I/SurfaceFlinger.HW( 182): screen returned
+I/SurfaceFlinger.HW( 182): About to give-up screen
+I/SurfaceFlinger.HW( 182): screen given-up
+I/SurfaceFlinger.HW( 182): Screen about to return
+...
+</pre>
+
+<p>
+The logs indicate that the system launched a replacement GTalk process but that it got stuck somehow:
+</p>
+
+<pre class="prettify">
+# ps
+PID PPID VSIZE RSS WCHAN PC NAME
+257 181 45780 5292 ffffffff 53030cb4 S com.google.andr
+</pre>
+
+<p>
+GTalk's PC is at 53030cb4. Look at the memory map to find out what lib is 0x53......
+</p>
+
+<pre class="prettify">
+# cat /proc/257/maps
+...
+51000000-5107c000 rwxp 00000000 1f:03 619 /android/lib/libutils.so
+52000000-52013000 rwxp 00000000 1f:03 639 /android/lib/libz.so
+53000000-53039000 rwxp 00000000 1f:03 668 /android/lib/libc.so
+53039000-53042000 rw-p 53039000 00:00 0
+54000000-54002000 rwxp 00000000 1f:03 658 /android/lib/libstdc++.so
+...
+</pre>
+
+<p>
+Disassemble <code>libc</code> to figure out what is going on:
+</p>
+
+<pre class="prettify">
+% prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-elf-objdump -d out/target/product/sooner/symbols/android/lib/libc.so
+
+00030ca4 <__futex_wait>:
+ 30ca4: e1a03002 mov r3, r2
+ 30ca8: e1a02001 mov r2, r1
+ 30cac: e3a01000 mov r1, #0 ; 0x0
+ 30cb0: ef9000f0 swi 0x009000f0
+ 30cb4: e12fff1e bx lr
+</pre>
+
+<a name="Blocked_in_a_syscall"></a><h4>Blocked in a syscall</h4>
+
+<p>
+In this scenario, the system is blocked in a syscall. To debug using <code>gdb</code>, first tell <code>adb</code> to forward the <code>gdb</code> port:
+</p>
+
+<pre class="prettify">
+
+% adb forward tcp:5039 tcp:5039
+</pre>
+
+<p>
+Start the <code>gdb</code> server and attach to process 257 (as demonstrated in the previous example):
+</p>
+
+<pre class="prettify">
+# gdbserver :5039 --attach 257 &
+Attached; pid = 257
+Listening on port 5039
+
+% prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-elf-gdb out/target/product/sooner/system/bin/app_process
+(gdb) set solib-absolute-prefix /work/android/device/out/target/product/sooner/symbols
+(gdb) set solib-search-path /work/android/device/out/target/product/sooner/symbols/android/lib
+(gdb) target remote :5039
+Remote debugging using :5039
+0x53030cb4 in ?? ()
+Current language: auto; currently asm
+</pre>
+
+<p>
+Don't let other threads get scheduled while we're debugging.
+You should "set scheduler-locking off" before issuing a "continue", or else your thread may get stuck on a futex or other
+spinlock because no other thread can release it.
+</p>
+
+<pre class="prettify">
+(gdb) set scheduler-locking on
+</pre>
+
+<p>
+Ignore SIGUSR1 if you're using JamVM. Shouldn't hurt if you're not.
+</p>
+
+<pre class="prettify">
+(gdb) handle SIGUSR1 noprint
+
+(gdb) where
+#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+#1 0x53010eb8 in pthread_cond_timedwait (cond=0x12081c, mutex=0x120818, abstime=0xffffffff)
+ at system/klibc/android/pthread.c:490
+#2 0x6b01c848 in monitorWait (mon=0x120818, self=0x6b039ba4, ms=0, ns=0) at extlibs/jamvm-1.4.1/src/lock.c:194
+#3 0x6b01d1d8 in objectWait (obj=0x408091c0, ms=0, ns=0) at extlibs/jamvm-1.4.1/src/lock.c:420
+#4 0x6b01d4c8 in jamWait (clazz=0xfffffffc, mb=0x0, ostack=0x2e188) at extlibs/jamvm-1.4.1/src/natives.c:91
+#5 0x6b013b2c in resolveNativeWrapper (clazz=0x408001d0, mb=0x41798, ostack=0x2e188) at extlibs/jamvm-1.4.1/src/dll.c:236
+#6 0x6b015c04 in executeJava () at extlibs/jamvm-1.4.1/src/interp.c:2614
+#7 0x6b01471c in executeMethodVaList (ob=0x0, clazz=0x40808f20, mb=0x12563c, jargs=0xbe9229f4)
+ at extlibs/jamvm-1.4.1/src/execute.c:91
+#8 0x6b01bcd0 in Jam_CallStaticVoidMethod (env=0xfffffffc, klass=0x0, methodID=0x12563c)
+ at extlibs/jamvm-1.4.1/src/jni.c:1063
+#9 0x58025b2c in android::AndroidRuntime::callStatic (this=0xfffffffc,
+ className=0xbe922f0a "android/activity/ActivityThread", methodName=0x57000b7c "main")
+ at libs/android_runtime/AndroidRuntime.cpp:215
+#10 0x57000504 in android::app_init (className=0xbe922f0a "android/activity/ActivityThread")
+ at servers/app/library/app_init.cpp:20
+#11 0x000089b0 in android::sp<android::ProcessState>::~sp ()
+#12 0x000089b0 in android::sp<android::ProcessState>::~sp ()
+Previous frame identical to this frame (corrupt stack?)
+
+(gdb) info threads
+ 7 thread 263 __ioctl () at system/klibc/syscalls/__ioctl.S:12
+ 6 thread 262 accept () at system/klibc/syscalls/accept.S:12
+ 5 thread 261 __futex_wait () at system/klibc/android/atomics_arm.S:88
+ 4 thread 260 __futex_wait () at system/klibc/android/atomics_arm.S:88
+ 3 thread 259 __futex_wait () at system/klibc/android/atomics_arm.S:88
+ 2 thread 258 __sigsuspend () at system/klibc/syscalls/__sigsuspend.S:12
+ 1 thread 257 __futex_wait () at system/klibc/android/atomics_arm.S:88
+
+
+(gdb) thread 7
+[Switching to thread 7 (thread 263)]#0 __ioctl () at system/klibc/syscalls/__ioctl.S:12
+12 movs r0, r0
+(gdb) bt
+#0 __ioctl () at system/klibc/syscalls/__ioctl.S:12
+#1 0x53010704 in ioctl (fd=-512, request=-1072143871) at system/klibc/android/ioctl.c:22
+#2 0x51040ac0 in android::IPCThreadState::talkWithDriver (this=0x1207b8, doReceive=true) at RefBase.h:83
+#3 0x510418a0 in android::IPCThreadState::joinThreadPool (this=0x1207b8, isMain=false)
+ at libs/utils/IPCThreadState.cpp:343
+#4 0x51046004 in android::PoolThread::threadLoop (this=0xfffffe00) at libs/utils/ProcessState.cpp:52
+#5 0x51036428 in android::Thread::_threadLoop (user=0xfffffe00) at libs/utils/Threads.cpp:1100
+#6 0x58025c68 in android::AndroidRuntime::javaThreadShell (args=0x105ffe28) at libs/android_runtime/AndroidRuntime.cpp:540
+
+(gdb) thread 6
+[Switching to thread 6 (thread 262)]#0 accept () at system/klibc/syscalls/accept.S:12
+12 movs r0, r0
+(gdb) bt
+#0 accept () at system/klibc/syscalls/accept.S:12
+#1 0x6b0334e4 in jdwpAcceptConnection (state=0xfffffe00) at extlibs/jamvm-1.4.1/jdwp/JdwpNet.c:213
+#2 0x6b032660 in jdwpThreadEntry (self=0x4d020) at extlibs/jamvm-1.4.1/jdwp/JdwpMain.c:37
+#3 0x6b022c2c in shell (args=0x4d960) at extlibs/jamvm-1.4.1/src/thread.c:629
+
+(gdb) thread 5
+[Switching to thread 5 (thread 261)]#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+88 bx lr
+(gdb) bt
+#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+#1 0x53010f48 in pthread_cond_timeout (cond=0x6b039b64, mutex=0x6b039b60, msecs=0) at system/klibc/android/pthread.c:513
+#2 0x6b01c8d0 in monitorWait (mon=0x6b039b60, self=0x4d400, ms=1000, ns=272629312) at extlibs/jamvm-1.4.1/src/lock.c:183
+#3 0x6b022084 in threadSleep (thread=0x4d400, ms=1000, ns=272629312) at extlibs/jamvm-1.4.1/src/thread.c:215
+#4 0x6b00d4fc in asyncGCThreadLoop (self=0x4d400) at extlibs/jamvm-1.4.1/src/alloc.c:1179
+#5 0x6b022c2c in shell (args=0x4d480) at extlibs/jamvm-1.4.1/src/thread.c:629
+
+(gdb) thread 4
+[Switching to thread 4 (thread 260)]#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+88 bx lr
+(gdb) bt
+#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+#1 0x53010eb8 in pthread_cond_timedwait (cond=0x6b039934, mutex=0x6b039930, abstime=0x0)
+ at system/klibc/android/pthread.c:490
+#2 0x6b00b3ec in referenceHandlerThreadLoop (self=0x4d360) at extlibs/jamvm-1.4.1/src/alloc.c:1247
+#3 0x6b022c2c in shell (args=0x4d960) at extlibs/jamvm-1.4.1/src/thread.c:629
+
+(gdb) thread 3
+[Switching to thread 3 (thread 259)]#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+88 bx lr
+(gdb) bt
+#0 __futex_wait () at system/klibc/android/atomics_arm.S:88
+#1 0x53010eb8 in pthread_cond_timedwait (cond=0x6b03992c, mutex=0x6b039928, abstime=0x0)
+ at system/klibc/android/pthread.c:490
+#2 0x6b00b1dc in finalizerThreadLoop (self=0x4d8e0) at extlibs/jamvm-1.4.1/src/alloc.c:1238
+#3 0x6b022c2c in shell (args=0x4d960) at extlibs/jamvm-1.4.1/src/thread.c:629
+
+(gdb) thread 2
+[Switching to thread 2 (thread 258)]#0 __sigsuspend () at system/klibc/syscalls/__sigsuspend.S:12
+12 movs r0, r0
+(gdb) bt
+#0 __sigsuspend () at system/klibc/syscalls/__sigsuspend.S:12
+#1 0x6b023814 in dumpThreadsLoop (self=0x51b98) at extlibs/jamvm-1.4.1/src/thread.c:1107
+#2 0x6b022c2c in shell (args=0x51b58) at extlibs/jamvm-1.4.1/src/thread.c:629
+</pre>
+
+<a name="Crash_in_C_C_code"></a><h4>Crash in C / C++ code</h4>
+<p>If it crashes, connect with <code>aproto</code> and run <code>logcat</code> on the device. You should see output like this:</p>
+
+<pre class="prettify">
+I/ActivityManager( 188): Starting activity: Intent { component=com.android.calendar.MonthScreen }
+I/ActivityManager( 188): Starting application com.android.calendar to host activity com.android.calendar.MonthScree
+n
+I/ServiceManager( 417): Executing: /android/bin/app_process (link=/android/bin/app_process, wrapper=/android/bin/app_process)
+I/DEBUG: -- observer of pid 417 starting --
+I/appproc ( 417): App process is starting with pid=417, class=android/activity/ActivityThread.
+I/DEBUG: -- observer of pid 417 exiting --
+I/DEBUG: -- observer of pid 420 starting --
+I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
+I/DEBUG: pid: 373, tid: 401 >>> android.content.providers.pim <<<
+I/DEBUG: signal 11 (SIGSEGV), fault addr 00000000
+I/DEBUG: r0 ffffffff r1 00000000 r2 00000454 r3 002136d4
+I/DEBUG: r4 002136c0 r5 40804810 r6 0022dc70 r7 00000010
+I/DEBUG: r8 0020a258 r9 00000014 10 6b039074 fp 109ffcf8
+I/DEBUG: ip 6b039e90 sp 109ffc0c lr 580239f0 pc 6b0156a0
+I/DEBUG: #01 pc 6b0156a0 /android/lib/libjamvm.so
+I/DEBUG: #01 lr 580239f0 /android/lib/libandroid_runtime.so
+I/DEBUG: #02 pc 6b01481c /android/lib/libjamvm.so
+I/DEBUG: #03 pc 6b0148a4 /android/lib/libjamvm.so
+I/DEBUG: #04 pc 6b00ebc0 /android/lib/libjamvm.so
+I/DEBUG: #05 pc 6b02166c /android/lib/libjamvm.so
+I/DEBUG: #06 pc 6b01657c /android/lib/libjamvm.so
+I/DEBUG: #07 pc 6b01481c /android/lib/libjamvm.so
+I/DEBUG: #08 pc 6b0148a4 /android/lib/libjamvm.so
+I/DEBUG: #09 pc 6b0235c0 /android/lib/libjamvm.so
+I/DEBUG: #10 pc 5300fac4 /android/lib/libc.so
+I/DEBUG: #11 pc 5300fc5c /android/lib/libc.so
+I/DEBUG: -- observer of pid 373 exiting --
+I/DEBUG: -- observer of pid 423 starting --
+</pre>
+
+<p>If debugging output indicates an error in C or C++ code, the addresses aren't particularly useful, but the debugging symbols aren't present on the device. Use the "stack" tool to convert these addresses to files and line numbers, for example:</p>
+
+<pre class="prettify">
+pid: 373, tid: 401 >>> android.content.providers.pim <<<
+
+ signal 11 (SIGSEGV), fault addr 00000000
+ r0 ffffffff r1 00000000 r2 00000454 r3 002136d4
+ r4 002136c0 r5 40804810 r6 0022dc70 r7 00000010
+ r8 0020a258 r9 00000014 10 6b039074 fp 109ffcf8
+ r8 0020a258 r9 00000014 10 6b039074 fp 109ffcf8
+
+ ADDR FUNCTION FILE:LINE
+ 6b0156a0 executeJava extlibs/jamvm-1.4.1/src/interp.c:2674
+ 580239f0 android_util_Parcel_freeBuffer libs/android_runtime/android_util_Binder.cpp:765
+ 6b01481c executeMethodVaList extlibs/jamvm- 1.4.1/src/execute.c:91
+ 6b0148a4 executeMethodArgs extlibs/jamvm-1.4.1/src/execute.c:67
+ 6b00ebc0 initClass extlibs/jamvm-1.4.1/src/class.c:1124
+ 6b02166c resolveMethod extlibs/jamvm- 1.4.1/src/resolve.c:197
+ 6b01657c executeJava extlibs/jamvm-1.4.1/src/interp.c:2237
+ 6b01481c executeMethodVaList extlibs/jamvm-1.4.1/src/execute.c:91
+ 6b0148a4 executeMethodArgs extlibs/jamvm- 1.4.1/src/execute.c:67
+ 6b0235c0 threadStart extlibs/jamvm-1.4.1/src/thread.c:355
+ 5300fac4 __thread_entry system/klibc/android/pthread.c:59
+ 5300fc5c pthread_create system/klibc/android/pthread.c:182
+</pre>
+
+<p>Or you can run <code>logcat</code> without any parameters and it will read from <code>stdin</code>. You can then paste output into the terminal or pipe it. Run <code>logcat</code> from the top of the tree in the environment in which you do builds so that the application can determine relative paths to the toolchain to use to decode the object files.
+</p>
+</body>
+</html>
diff --git a/pdk/docs/porting/display_drivers.jd b/pdk/docs/porting/display_drivers.jd
new file mode 100755
index 0000000..570f6f6
--- /dev/null
+++ b/pdk/docs/porting/display_drivers.jd
@@ -0,0 +1,345 @@
+page.title=Display Drivers
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidDisplayDriverFunctionality">Functionality</a></li>
+<li><a href="#androidDisplayDriversSourceTemplate">Implementing Your Own Driver (Driver Template)</a></li>
+<li><a href="#androidDisplayDriversTroubleshooting">Troubleshooting</a></li>
+</ul>
+</div>
+</div>
+
+<p>This section describes how the display driver functions and offers a functional template designed to help you build your own device-specific driver.</p>
+<p>Android relies on the standard frame buffer device (<code>/dev/fb0</code> or <code>/dev/graphics/fb0</code>) and driver as described in the <code>linux/fb.h</code> kernel header file. For more information regarding the standard Linux frame buffer, please see <a href="http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/fb/framebuffer.txt">The Frame Buffer Device</a> at <a href="http://kernel.org">http://kernel.org</a>.
+
+
+<a name="androidDisplayDriverFunctionality"></a><h3>Functionality</h3>
+
+<p>In Android, every window gets implemented with an underlying Surface object, an object that gets placed on the framebuffer by SurfaceFlinger, the system-wide screen composer. Each Surface is double-buffered. The back buffer is where drawing takes place and the front buffer is used for composition. </p>
+<p> When <code>unlockCanvas()</code> is called, the back buffer is posted, which
+ means that it gets displayed and becomes available again. Android flips the front and back buffers, ensuring a minimal amount of buffer copying and that there is always a buffer for SurfaceFlinger to use for composition (which ensures that the screen never flickers or shows artifacts).</p>
+<p>Android makes two requirements of the driver: a linear address space of mappable memory that it can write to directly and support for the rgb_565 pixel format. A typical frame display includes:</p>
+<ul>
+ <li>accessing the driver by calling open on <code>/dev/fb0</code></li>
+ <li>using the <code>FBIOGET_FSCREENINFO</code> and <code>FBIOGET_VSCREENINFO</code> Input / Output Control (ioctl) calls to retrieve information about the screen</li>
+ <li>using <code>FBIOPUT_VSCREENINFO</code> ioctl to attempt to create a virtual display twice the size of the physical screen and to set the pixel format to rgb_565. If this succeeds, double buffering is accomplished with video memory. </li>
+</ul>
+<p>When a page flip is required, Android makes another <code>FBIOPUT_VSCREENINFO</code> ioctl call with a new y-offset pointing to the other buffer in video memory. This ioctl, in turn, invokes the driver's <code>.fb_pan_display</code> function in order to do the actual flip. If there isn't sufficient video memory, regular memory is used and is just copied into the video memory when it is time do the flip. After allocating the video memory and setting the pixel format, Android uses <code>mmap()</code> to map the memory into the process's address space. All writes to the frame buffer are done through this mmaped memory.</p>
+<p>To maintain adequate performance, framebuffer memory should be cacheable. If you use write-back, flush the cache before the frame buffer is written from DMA to the LCD. If that isn't possible, you may use write-through. As a last resort, you can also use uncached memory with the write-bugger enabled, but performance will suffer.</p>
+
+
+<a name="androidDisplayDriversSourceTemplate"></a><h3>Implementing Your Own Driver (Driver Template)</h3>
+
+<p>The following sample driver offers a functional example to help you build your own display driver. Modify <code>PGUIDE_FB...</code> macros as desired to match the requirements of your own device hardware.</p>
+<pre class="prettyprint">
+/*
+ * pguidefb.c
+ *
+ * Copyright 2007, Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+/*
+ * ANDROID PORTING GUIDE: FRAME BUFFER DRIVER TEMPLATE
+ *
+ * This template is designed to provide the minimum frame buffer
+ * functionality necessary for Android to display properly on a new
+ * device. The PGUIDE_FB macros are meant as pointers indicating
+ * where to implement the hardware specific code necessary for the new
+ * device. The existence of the macros is not meant to trivialize the
+ * work required, just as an indication of where the work needs to be
+ * done.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/mm.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+
+
+/* Android currently only uses rgb565 in the hardware framebuffer */
+#define ANDROID_BYTES_PER_PIXEL 2
+
+/* Android will use double buffer in video if there is enough */
+#define ANDROID_NUMBER_OF_BUFFERS 2
+
+/* Modify these macros to suit the hardware */
+
+#define PGUIDE_FB_ROTATE
+ /* Do what is necessary to cause the rotation */
+
+#define PGUIDE_FB_PAN
+ /* Do what is necessary to cause the panning */
+
+#define PGUIDE_FB_PROBE_FIRST
+ /* Do any early hardware initialization */
+
+#define PGUIDE_FB_PROBE_SECOND
+ /* Do any later hardware initialization */
+
+#define PGUIDE_FB_WIDTH 320
+ /* Return the width of the screen */
+
+#define PGUIDE_FB_HEIGHT 240
+ /* Return the heighth of the screen */
+
+#define PGUIDE_FB_SCREEN_BASE 0
+ /* Return the virtual address of the start of fb memory */
+
+#define PGUIDE_FB_SMEM_START PGUIDE_FB_SCREEN_BASE
+ /* Return the physical address of the start of fb memory */
+
+#define PGUIDE_FB_REMOVE
+ /* Do any hardware shutdown */
+
+
+
+
+
+struct pguide_fb {
+ int rotation;
+ struct fb_info fb;
+ u32 cmap[16];
+};
+
+static inline u32 convert_bitfield(int val, struct fb_bitfield *bf)
+{
+ unsigned int mask = (1 << bf->length) - 1;
+
+ return (val >> (16 - bf->length) & mask) << bf->offset;
+}
+
+
+/* set the software color map. Probably doesn't need modifying. */
+static int
+pguide_fb_setcolreg(unsigned int regno, unsigned int red, unsigned int green,
+ unsigned int blue, unsigned int transp, struct fb_info *info)
+{
+ struct pguide_fb *fb = container_of(info, struct pguide_fb, fb);
+
+ if (regno < 16) {
+ fb->cmap[regno] = convert_bitfield(transp, &fb->fb.var.transp) |
+ convert_bitfield(blue, &fb->fb.var.blue) |
+ convert_bitfield(green, &fb->fb.var.green) |
+ convert_bitfield(red, &fb->fb.var.red);
+ return 0;
+ }
+ else {
+ return 1;
+ }
+}
+
+/* check var to see if supported by this device. Probably doesn't
+ * need modifying.
+ */
+static int pguide_fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ if((var->rotate & 1) != (info->var.rotate & 1)) {
+ if((var->xres != info->var.yres) ||
+ (var->yres != info->var.xres) ||
+ (var->xres_virtual != info->var.yres) ||
+ (var->yres_virtual >
+ info->var.xres * ANDROID_NUMBER_OF_BUFFERS) ||
+ (var->yres_virtual < info->var.xres )) {
+ return -EINVAL;
+ }
+ }
+ else {
+ if((var->xres != info->var.xres) ||
+ (var->yres != info->var.yres) ||
+ (var->xres_virtual != info->var.xres) ||
+ (var->yres_virtual >
+ info->var.yres * ANDROID_NUMBER_OF_BUFFERS) ||
+ (var->yres_virtual < info->var.yres )) {
+ return -EINVAL;
+ }
+ }
+ if((var->xoffset != info->var.xoffset) ||
+ (var->bits_per_pixel != info->var.bits_per_pixel) ||
+ (var->grayscale != info->var.grayscale)) {
+ return -EINVAL;
+ }
+ return 0;
+}
+
+
+/* Handles screen rotation if device supports it. */
+static int pguide_fb_set_par(struct fb_info *info)
+{
+ struct pguide_fb *fb = container_of(info, struct pguide_fb, fb);
+ if(fb->rotation != fb->fb.var.rotate) {
+ info->fix.line_length =
+ info->var.xres * ANDROID_BYTES_PER_PIXEL;
+ fb->rotation = fb->fb.var.rotate;
+ PGUIDE_FB_ROTATE;
+ }
+ return 0;
+}
+
+
+/* Pan the display if device supports it. */
+static int pguide_fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ struct pguide_fb *fb __attribute__ ((unused))
+ = container_of(info, struct pguide_fb, fb);
+
+ /* Set the frame buffer base to something like:
+ fb->fb.fix.smem_start + fb->fb.var.xres *
+ ANDROID_BYTES_PER_PIXEL * var->yoffset
+ */
+ PGUIDE_FB_PAN;
+
+ return 0;
+}
+
+
+static struct fb_ops pguide_fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = pguide_fb_check_var,
+ .fb_set_par = pguide_fb_set_par,
+ .fb_setcolreg = pguide_fb_setcolreg,
+ .fb_pan_display = pguide_fb_pan_display,
+
+ /* These are generic software based fb functions */
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+
+static int pguide_fb_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct pguide_fb *fb;
+ size_t framesize;
+ uint32_t width, height;
+
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if(fb == NULL) {
+ ret = -ENOMEM;
+ goto err_fb_alloc_failed;
+ }
+ platform_set_drvdata(pdev, fb);
+
+ PGUIDE_FB_PROBE_FIRST;
+ width = PGUIDE_FB_WIDTH;
+ height = PGUIDE_FB_HEIGHT;
+
+
+ fb->fb.fbops = &pguide_fb_ops;
+
+ /* These modes are the ones currently required by Android */
+
+ fb->fb.flags = FBINFO_FLAG_DEFAULT;
+ fb->fb.pseudo_palette = fb->cmap;
+ fb->fb.fix.type = FB_TYPE_PACKED_PIXELS;
+ fb->fb.fix.visual = FB_VISUAL_TRUECOLOR;
+ fb->fb.fix.line_length = width * ANDROID_BYTES_PER_PIXEL;
+ fb->fb.fix.accel = FB_ACCEL_NONE;
+ fb->fb.fix.ypanstep = 1;
+
+ fb->fb.var.xres = width;
+ fb->fb.var.yres = height;
+ fb->fb.var.xres_virtual = width;
+ fb->fb.var.yres_virtual = height * ANDROID_NUMBER_OF_BUFFERS;
+ fb->fb.var.bits_per_pixel = 16;
+ fb->fb.var.activate = FB_ACTIVATE_NOW;
+ fb->fb.var.height = height;
+ fb->fb.var.width = width;
+
+ fb->fb.var.red.offset = 11;
+ fb->fb.var.red.length = 5;
+ fb->fb.var.green.offset = 5;
+ fb->fb.var.green.length = 6;
+ fb->fb.var.blue.offset = 0;
+ fb->fb.var.blue.length = 5;
+
+ framesize = width * height *
+ ANDROID_BYTES_PER_PIXEL * ANDROID_NUMBER_OF_BUFFERS;
+ fb->fb.screen_base = PGUIDE_FB_SCREEN_BASE;
+ fb->fb.fix.smem_start = PGUIDE_FB_SMEM_START;
+ fb->fb.fix.smem_len = framesize;
+
+ ret = fb_set_var(&fb->fb, &fb->fb.var);
+ if(ret)
+ goto err_fb_set_var_failed;
+
+ PGUIDE_FB_PROBE_SECOND;
+
+ ret = register_framebuffer(&fb->fb);
+ if(ret)
+ goto err_register_framebuffer_failed;
+
+ return 0;
+
+
+err_register_framebuffer_failed:
+err_fb_set_var_failed:
+ kfree(fb);
+err_fb_alloc_failed:
+ return ret;
+}
+
+static int pguide_fb_remove(struct platform_device *pdev)
+{
+ struct pguide_fb *fb = platform_get_drvdata(pdev);
+
+ PGUIDE_FB_REMOVE;
+
+ kfree(fb);
+ return 0;
+}
+
+
+static struct platform_driver pguide_fb_driver = {
+ .probe = pguide_fb_probe,
+ .remove = pguide_fb_remove,
+ .driver = {
+ .name = "pguide_fb"
+ }
+};
+
+static int __init pguide_fb_init(void)
+{
+ return platform_driver_register(&pguide_fb_driver);
+}
+
+static void __exit pguide_fb_exit(void)
+{
+ platform_driver_unregister(&pguide_fb_driver);
+}
+
+module_init(pguide_fb_init);
+module_exit(pguide_fb_exit);
+
+MODULE_LICENSE("GPL");
+</pre>
+
+
+<a name="androidDisplayDriversTroubleshooting"></a><h3>Troubleshooting</h3>
+
+<p>Both of the following problems have a similar cause:</p>
+<ul>
+ <li><strong>Number keys</strong>: In the dialer application, when a number key is pressed to dial a phone number, the number doesn't display on the screen until after the next number has been pressed. </li>
+ <li><strong>Arrow keys</strong>: When an arrow key is pressed, the desired icon doesn't get highlighted. For example, if you browse through icons in the Applications menu, you might notice that icons aren't highlighted as expected when you use the arrow key to navigate between options.</li>
+</ul>
+<p>Both problems are caused by an incorrect implementation of the frame buffer's page flipping. Key events are captured, but the graphical interface appears to drop every other frame. </p>
+<p>Android relies on a double buffer to smoothly render page flips (please see <a href="#androidDisplayDriverFunctionality">Functionality</a> for details).</p>
diff --git a/pdk/docs/porting/getting_source_code.jd b/pdk/docs/porting/getting_source_code.jd
new file mode 100755
index 0000000..30a2f9f
--- /dev/null
+++ b/pdk/docs/porting/getting_source_code.jd
@@ -0,0 +1,128 @@
+page.title=Getting Source Code
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<a name="toc"/>
+<div style="padding:10px">
+<a href="#androidSourceSetupBuildGitSetup">Introduction</a><br/>
+<a href="#androidSourceSetupBuildGitSetupInstall">Installing and Configuring Git</a><br/>
+<a href="#androidSourceSetupBuildGitSetupServer">Establishing Server Access</a><br/><div style="padding-left:40px">
+
+<a href="#androidSourceSetupBuildGitSetupServerRSAKeys">Generating RSA Keys</a><br/>
+<a href="#androidSourceSetupBuildGitSetupServerVerifyConnection">Verifying a Connection to the Git Server</a><br/></div>
+<a href="#androidSourceSetupGetCode">Downloading Code</a><br/>
+<a href="#androidSourceSetupExtractingPatch">Extracting an Android Patch</a><br/></div>
+
+<a name="androidSourceSetupBuildGitSetup"></a><h2>Introduction</h2>
+
+<p>Android relies on Git, a version control system, to install the Android platform. You will need to install Git 1.5.2 or greater in order to access the source tree. Please visit <a href="http://git.or.cz/">http://git.or.cz/</a> for more information regarding Git.</p>
+<p>Git permits you to control access to working directories, and we recommend that you use it to limit Android repository access to only a few people within your organization (please refer to your Google NDA for potential contractual restraints on sharing Android source access). </p>
+<p>You may clone Google's repository to a local copy for sharing internally (see Git documentation for details).</p>
+
+
+<a name="androidSourceSetupBuildGitSetupInstall"></a><h2>Installing and Configuring Git</h2>
+
+<p>To install the Git package, execute:</p>
+<pre class="prettyprint">
+% sudo apt-get install git-core
+</pre>
+
+
+<a name="androidSourceSetupBuildGitSetupServer"></a><h2>Establishing Server Access</h2>
+
+<p>Once Git is cleanly installed, you need to establish a connection with Google's Git server, a connection that requires an RSA key in order to authenticate requests.</p>
+
+
+<a name="androidSourceSetupBuildGitSetupServerRSAKeys"></a><h3>Generating RSA Keys</h3>
+
+<p>Each developer must have a unique RSA key in order to access Android source code. To generate an RSA key: </p>
+<p>
+<ol>
+<li>Type:<br/>
+<pre class="prettyprint">% ssh-keygen -t rsa -C email@domain.com</pre><br/>
+You must use a valid email address to create your key.</li>
+<li>When prompted, indicate the file to which you wish to write your key (<code>id_rsa</code> in this example).</li>
+<li>When prompted, associate a passphrase with your key.</li>
+<li>Upon success, you should have two files saved to the designated directory: </li>
+<ul>
+ <li><code>id_rsa</code>: This file contains the private half of your RSA key. You shouldn't share this file with anyone. </li>
+ <li><code>id_rsa.pub</code>: This is the public half or your RSA key and you should send it to your Google technical account manager.</li>
+ </ul>
+</ol>
+</p>
+<p>Send your Google Account Manager your public key file in order to establish Git server access. </p>
+
+
+<a name="androidSourceSetupBuildGitSetupServerVerifyConnection"></a><h3>Verifying a Connection to the Git Server</h3>
+
+<p>Once you have generated an RSA key and shared the public file with Google, you can test your connection with the Git server with the following command:</p>
+<pre class="prettyprint">
+% ssh android-git.ext.google.com
+</pre>
+
+<p>You should receive one of the following results:</p>
+
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Result</th>
+ <th scope="col">Cause</th>
+ <th scope="col">Action</th>
+ </tr>
+ <tr>
+ <td>
+<code>fatal: What do you think I am? A shell?<BR>
+Connection to android-git closed.</code>
+</pre> </td>
+ <td>Success</td>
+ <td>None. You successfully connected to the Git server. (You should not have shell access and it's expected to receive this error.)</td>
+ </tr>
+ <tr>
+ <td>ssh hangs and eventually times out. </td>
+ <td>Your setup is failing to locate and establish a basic connection. </td>
+ <td>Google needs to debug network settings. </td>
+ </tr>
+ <tr>
+ <td>Error: Permission denied <public key> </td>
+ <td>Either you are not using the matching username or the RSA private key does not match the public key. </td>
+ <td>Try executing:<BR>
+ <code>
+% ssh $USER@android-
+ git.ext.google.com
+</code></td>
+ </tr>
+</table>
+
+
+<a name="androidSourceSetupGetCode"></a><h2>Downloading Code</h2>
+
+<p>Android source code is maintained in two repositories: <code>device</code> and <code>kernel</code>. The <code>device</code> repository includes the Android framework (things like the Activity Manager, Window Manager, Telephony Manager, View System, etc.). The <code>kernel</code> repository includes the core code necessary to run the operating system (things like the Display Driver, Camera Driver, Keypad Driver, Power Management, etc.). (Please see <a href="http://code.google.com/android/what-is-android.html">What is Android?</a> for details.)</p>
+
+<p>Save device and kernel code at the same directory level, for example:</p>
+<p>
+<ul><li><code>/home/joe/android/device</code></li>
+<li><code>/home/joe/android/kernel</code></li>
+</ul></p>
+<p><b>Device Code</b></p>
+<p>To download device code, you need your username and a unique <code><path></code> string supplied by Google to execute the following:</p>
+<pre class="prettyprint">
+% git-clone $USER@android-git.ext.google.com:<path>/device.git
+</pre>
+
+<p><b>Kernel Code</b></p>
+<p>To download kernel code, you need your username and a unique <code><path></code> string supplied by Google to execute the following:</p>
+<pre class="prettyprint">
+% git-clone $USER@android-git.ext.google.com:<path>/kernel.git
+</pre>
+
+
+
+<a name="androidSourceSetupExtractingPatch"></a><h2>Extracting an Android Patch</h2>
+
+<p>You likely already have Linux running on your platform and only need to integrate Android-specific changes. The following directions describe how to extract an Android patch.</p>
+<ol>
+ <li>Download a generic version of the Linux kernel that matches the Linux version downloaded with the Android Kernel code.</li>
+ <li>Run <code>diff</code> on the two kernel packages to get Android-specific changes.</li>
+ <li>Apply the patch to your target kernel and build.</li>
+</ol>
+
diff --git a/pdk/docs/porting/gps.jd b/pdk/docs/porting/gps.jd
new file mode 100755
index 0000000..1449460
--- /dev/null
+++ b/pdk/docs/porting/gps.jd
@@ -0,0 +1,60 @@
+page.title=GPS
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidGPSBuildingDriver">Building a GPS Library</a></li>
+<li><a href="#androidGPSInterface">Interface</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android defines a user space C abstraction interface for GPS hardware. The interface header is defined in <code>include/hardware/gps.h</code>. In order to integate GPS with Android, you need to build a shared library that implements this interface. </p>
+
+
+<a name="androidGPSBuildingDriver"></a><h3>Building a GPS Library</h3>
+
+<p>To implement a GPS driver, create a shared library that implements the interface defined in <code>gps.h</code>. You must name your shared library <code>libgps.so</code> so that it will get loaded from <code>/system/lib</code> at runtime. Place GPS sources and Android.mk in <code>vendor/acme/chipset_or_board/gps/</code> (where "acme" is your organization name and "chipset_or_board" is your hardware target).</p>
+
+<p>The following stub <code>Android.mk</code> file ensures that <code>libgps</code> compiles and links to the appropriate libraries:</p>
+
+<pre class="prettify">
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libgps
+
+LOCAL_STATIC_LIBRARIES:= \
+# include any static library dependencies
+
+LOCAL_SHARED_LIBRARIES := \
+# include any shared library dependencies
+
+LOCAL_SRC_FILES += \
+# include your source files. eg. MyGpsLibrary.cpp
+
+LOCAL_CFLAGS += \
+# include any needed compile flags
+
+LOCAL_C_INCLUDES:= \
+# include any needed local header files
+
+include $(BUILD_SHARED_LIBRARY)
+</pre>
+
+
+<a name="androidGPSInterface"></a><h3>Interface</h3>
+
+
+
+<p><span class="lh3"><a name="androidDoxygenNote"></a></span>
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="gps.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="gps_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0" frameborder="0" style="width:100%;"></iframe>
diff --git a/pdk/docs/porting/group__memory.jd b/pdk/docs/porting/group__memory.jd
new file mode 100755
index 0000000..224e0cb
--- /dev/null
+++ b/pdk/docs/porting/group__memory.jd
@@ -0,0 +1,24 @@
+page.title=Providing Heap Memory
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div class="navigation" id="top">
+ <div class="tabs">
+ <ul>
+ <li><a href="index.html"><span>Main Page</span></a></li>
+ <li><a href="modules.html"><span>Modules</span></a></li>
+ <li><a href="namespaces.html"><span>Namespaces</span></a></li>
+ <li><a href="annotated.html"><span>Data Structures</span></a></li>
+ <li><a href="files.html"><span>Files</span></a></li>
+ </ul>
+ </div>
+</div>
+
+<small>
+[<a class="el" href="group__networking.html">Neworking Support</a>]</small>
+</h1><table border="0" cellpadding="0" cellspacing="0">
+<tr><td></td></tr>
+</table>
+This is the text in the "Providing Heap Memory" subgroup </div>
+
diff --git a/pdk/docs/porting/group__networking.jd b/pdk/docs/porting/group__networking.jd
new file mode 100755
index 0000000..67da8a6
--- /dev/null
+++ b/pdk/docs/porting/group__networking.jd
@@ -0,0 +1,26 @@
+page.title=Networking Support
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div class="navigation" id="top">
+ <div class="tabs">
+ <ul>
+ <li><a href="index.html"><span>Main Page</span></a></li>
+ <li><a href="modules.html"><span>Modules</span></a></li>
+ <li><a href="namespaces.html"><span>Namespaces</span></a></li>
+ <li><a href="annotated.html"><span>Data Structures</span></a></li>
+ <li><a href="files.html"><span>Files</span></a></li>
+ </ul>
+ </div>
+</div>
+
+<table border="0" cellpadding="0" cellspacing="0">
+<tr><td></td></tr>
+<tr><td colspan="2"><br><h2>Modules</h2></td></tr>
+<tr><td class="memItemLeft" nowrap align="right" valign="top"> </td><td class="memItemRight" valign="bottom"><a class="el" href="group__memory.html">Porividng Heap Memory</a></td></tr>
+
+</table>
+<hr><a name="_details"></a><h2>Detailed Description</h2>
+This is a text for the Networking Support Group </div>
+
diff --git a/pdk/docs/porting/images/androidBluetooth.gif b/pdk/docs/porting/images/androidBluetooth.gif
new file mode 100755
index 0000000..e62f5a8
--- /dev/null
+++ b/pdk/docs/porting/images/androidBluetooth.gif
Binary files differ
diff --git a/pdk/docs/porting/images/androidPMArchitecture.gif b/pdk/docs/porting/images/androidPMArchitecture.gif
new file mode 100755
index 0000000..1aa48db
--- /dev/null
+++ b/pdk/docs/porting/images/androidPMArchitecture.gif
Binary files differ
diff --git a/pdk/docs/porting/images/android_audio_architecture.gif b/pdk/docs/porting/images/android_audio_architecture.gif
new file mode 100755
index 0000000..79854a3
--- /dev/null
+++ b/pdk/docs/porting/images/android_audio_architecture.gif
Binary files differ
diff --git a/pdk/docs/porting/images/cameraPreview.jpg b/pdk/docs/porting/images/cameraPreview.jpg
new file mode 100755
index 0000000..3dea011
--- /dev/null
+++ b/pdk/docs/porting/images/cameraPreview.jpg
Binary files differ
diff --git a/pdk/docs/porting/images/cameraTakePicture.jpg b/pdk/docs/porting/images/cameraTakePicture.jpg
new file mode 100755
index 0000000..4ac6d95
--- /dev/null
+++ b/pdk/docs/porting/images/cameraTakePicture.jpg
Binary files differ
diff --git a/pdk/docs/porting/images/camera_video2.gif b/pdk/docs/porting/images/camera_video2.gif
new file mode 100755
index 0000000..8c46a83
--- /dev/null
+++ b/pdk/docs/porting/images/camera_video2.gif
Binary files differ
diff --git a/pdk/docs/porting/images/customLogo.gif.png b/pdk/docs/porting/images/customLogo.gif.png
new file mode 100755
index 0000000..3322fed
--- /dev/null
+++ b/pdk/docs/porting/images/customLogo.gif.png
Binary files differ
diff --git a/pdk/docs/porting/images/stk.gif b/pdk/docs/porting/images/stk.gif
new file mode 100755
index 0000000..9d6db69
--- /dev/null
+++ b/pdk/docs/porting/images/stk.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_display_text.gif b/pdk/docs/porting/images/stk_display_text.gif
new file mode 100755
index 0000000..b737c51
--- /dev/null
+++ b/pdk/docs/porting/images/stk_display_text.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_display_text2.gif b/pdk/docs/porting/images/stk_display_text2.gif
new file mode 100755
index 0000000..cac707b
--- /dev/null
+++ b/pdk/docs/porting/images/stk_display_text2.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_refresh_init.gif b/pdk/docs/porting/images/stk_refresh_init.gif
new file mode 100755
index 0000000..a79ccaa
--- /dev/null
+++ b/pdk/docs/porting/images/stk_refresh_init.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_refresh_reset.gif b/pdk/docs/porting/images/stk_refresh_reset.gif
new file mode 100755
index 0000000..dff8d4e
--- /dev/null
+++ b/pdk/docs/porting/images/stk_refresh_reset.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_refresh_update.gif b/pdk/docs/porting/images/stk_refresh_update.gif
new file mode 100755
index 0000000..15614ed
--- /dev/null
+++ b/pdk/docs/porting/images/stk_refresh_update.gif
Binary files differ
diff --git a/pdk/docs/porting/images/stk_send_SMS.gif b/pdk/docs/porting/images/stk_send_SMS.gif
new file mode 100755
index 0000000..67fc1a0
--- /dev/null
+++ b/pdk/docs/porting/images/stk_send_SMS.gif
Binary files differ
diff --git a/pdk/docs/porting/images/telephony.gif b/pdk/docs/porting/images/telephony.gif
new file mode 100755
index 0000000..8515730
--- /dev/null
+++ b/pdk/docs/porting/images/telephony.gif
Binary files differ
diff --git a/pdk/docs/porting/images/telephony_solicted_example.gif b/pdk/docs/porting/images/telephony_solicted_example.gif
new file mode 100755
index 0000000..352ca98
--- /dev/null
+++ b/pdk/docs/porting/images/telephony_solicted_example.gif
Binary files differ
diff --git a/pdk/docs/porting/images/telephony_unsolicted_example.gif b/pdk/docs/porting/images/telephony_unsolicted_example.gif
new file mode 100755
index 0000000..e51c4d6
--- /dev/null
+++ b/pdk/docs/porting/images/telephony_unsolicted_example.gif
Binary files differ
diff --git a/pdk/docs/porting/index.jd b/pdk/docs/porting/index.jd
new file mode 100644
index 0000000..9d23fbe
--- /dev/null
+++ b/pdk/docs/porting/index.jd
@@ -0,0 +1,28 @@
+page.title=Android Platform Developer's Guide
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+<p>Welcome to the <i>Android Platform Dev Guide</i>! This guide provides an under-the-hood introduction to the Android platform, and is designed for platform developers and manufacturers building Android-powered devices.</p>
+
+<p>If you're a software developer interested in developing applications for Android, please visit the <a href="http://developer.android.com">Android Developers site</a>.</p>
+
+<a name="androidWelcomeAboutThisGuide"></a><h2>About this Guide</h2>
+
+<p>This guide is divided into sections by logical platform component (see the table of contents on the left). Android is a complex project under constant development, and the level of detail, as well as the rate of change, may vary from section to section. This guide will be updated regularly as more content becomes available.</p>
+
+<a name="androidWelcomeIntendedAudience"></a><h2>Intended Audience</h2>
+
+<p>This guide is intended for engineers who are proficient with building and running Linux on embedded devices. It aims to provide explanation of the Android platform rather than Linux or embedded development in general.</p>
+
+<a name="androidWelcomeGettingStarted"></a><h2>Getting Started with Android</h2>
+
+<p>If you are new to Android, start with the platform documentation on the following sites:
+<ul>
+<li><a href="http://developer.android.com">Android Developers site</a>: This site offers high-level platform documentation and architecture concepts.</li>
+<li><a href="http://source.android.com">Android Open Source Project site</a>: This site provides instructions on how to get the source code, establish a development environment, and perform a simple build.</li>
+</ul>
+
+<p>When you are ready to start customizing the platform or porting to your target hardware, start in this guide with the <a href="build_system.html">Build System overview</a>.</p>
+
diff --git a/pdk/docs/porting/instrumentation_framework.jd b/pdk/docs/porting/instrumentation_framework.jd
new file mode 100755
index 0000000..fcb006b
--- /dev/null
+++ b/pdk/docs/porting/instrumentation_framework.jd
@@ -0,0 +1,143 @@
+page.title=Instrumentation Framework
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<a name="toc"/>
+<div style="padding:10px">
+<a href="#androidInstrumentationFrameworkIntro">Introduction</a><br/>
+<a href="#androidInstrumentationFrameworkamCommand">Understanding the am Command</a><br/>
+<a href="#androidInstrumentationFrameworkWritingRunning">Writing and Running Test Cases</a><br/>
+<a href="#androidInstrumentationFrameworkTestCase">Exploring a Test Case</a><br/>
+<a href="#androidInstrumentationFrameworkTroubleshooting">Troubleshooting</a><br/></div>
+
+<a name="androidInstrumentationFrameworkIntro"></a><h2>Introduction</h2>
+
+<p>This document describes how to use the Instrumentation Framework to write test cases. You should have a working knowledge of the following:</p>
+<ul>
+ <li> Android Application Framework </li>
+ <li> Using <code>adb</code>, <code>am</code> and various logging functionality </li>
+ <li> A brief understanding of the application of interest, that is, he names of the classes which handle the intents etc. </li>
+ <li> Junit testing. </li>
+</ul>
+<p> Each Android application runs in its own process. Instrumentation kills the application process and restarts the process with Instrumentation. Instrumentation gives a handle to the application context used to poke around the application to validate test assertions, allowing you to write test cases to test applications at a much lower level than UI screen shot tests. Note that Instrumentation cannot catch UI bugs. </p>
+
+
+<a name="androidInstrumentationFrameworkamCommand"></a><h2>Understanding the am Command</h2>
+
+<p><code>am</code> is used to start and instrument activities using the adb shell command, as shown in the snippet below:</p>
+<pre class="prettify">
+> adb shell am
+usage: am [start|instrument]
+ am start [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
+ [-c <CATEGORY> [-c <CATEGORY>] ...]
+ [-e <EXTRA_KEY> <EXTRA_VALUE> [-e <EXTRA_KEY> <EXTRA_VALUE> ...]
+ [-n <COMPONENT>] [-D] [<URI>]
+ am instrument [-e <ARG_NAME> <ARG_VALUE>] [-p <PROF_FILE>]
+ [-w] <COMPONENT>
+For example, to start the Contacts application you can use
+> adb shell am start -n com.google.android.contacts/.ContactsActivity
+</pre>
+
+
+<a name="androidInstrumentationFrameworkWritingRunning"></a><h2>Writing and Running Test Cases</h2>
+
+<p>Each instrumentation test case is similar to an Android application with the distinction that it starts another application. For example, have a look in the <code>tests/Contacts</code> directory. </p>
+<ul>
+ <li> There should be a Makefile and an Android Manifest file. </li>
+ <li> Tests are located in <code>tests/Contacts/src/com/google/android/contactstests</code>. </li>
+ <li> The Instrumentation Test Runner is located at <code>tests/Contacts/src/com/google/android/contactstests/functional/ContactsInstrumentationTestRunner.java</code>.</li>
+</ul>
+<p>Suppose you have a makefile with <code>Contactstests</code> as the target. </p>
+<ul>
+ <li> <code>make Contactstests</code>: Compiles the test cases. </li>
+ <li> <code>adb install Contactstests.apk</code>: Installs the apk on the device. </li>
+ <li> Use the adb shell <code>am</code> command to run them. </li>
+</ul>
+<p> For options and other details, please see <a href="instrumentation_testing.html" target="_top">Instrumentation Testing</a>.</p>
+
+
+<a name="androidInstrumentationFrameworkTestCase"></a><h2>Exploring a Test Case</h2>
+
+<p> The test case described in this section adds and tests a new Contact. Note that you can send intents, register intent receivers, etc. </p>
+<p><code>Instrumentation.java</code> has helper functions that send key events and string, for example: </p>
+<ul>
+ <li><code>getInstrumentation()</code>: Returns the handle to the instrumentation </li>
+ <li><code>sendCharacterSync</code>: Sends a character. </li>
+ <li><code>sendStringSync</code>: Sends a string to an input box. </li>
+ <li><code>sendKeyDownUpSync</code>: Sends a specific keyevent. </li>
+ <li><code>sendTrackballEventSync</code>: Send a trackball event.</li>
+</ul>
+<p> You can find the test case below at <code>device/tests/Contacts.</code></p>
+<pre class="prettify">
+private void addNewContact(String name, int star, int phoneType, String number, String label,
+ String email, int emailType){
+ ContentValues values = new ContentValues();
+ Uri phoneUri = null;
+ Uri emailUri = null;
+
+ values.put(Contacts.People.NAME, name);
+ values.put(Contacts.People.STARRED, star);
+
+ //Add Phone Numbers
+ Uri uri = mActivity.getContentResolver().insert(Contacts.People.CONTENT_URI, values);
+ phoneUri = Uri.withAppendedPath(uri, Contacts.People.Phones.CONTENT_DIRECTORY);
+
+ values.clear();
+ values.put(Contacts.Phones.TYPE, phoneType);
+ values.put(Contacts.Phones.NUMBER, number);
+ values.put(Contacts.Phones.LABEL, label);
+ mActivity.getContentResolver().insert(phoneUri, values);
+
+ //Add Email
+ emailUri = Uri.withAppendedPath(uri, ContactMethods.CONTENT_DIRECTORY);
+
+ values.clear();
+ values.put(ContactMethods.KIND, Contacts.KIND_EMAIL);
+ values.put(ContactMethods.DATA, email);
+ values.put(ContactMethods.LABEL, "");
+ values.put(ContactMethods.TYPE, emailType);
+ mActivity.getContentResolver().insert(emailUri, values);
+}
+
+
+ public void testAddSaveSingleContact(){
+ int previousCount = mActivity.getListView().getCount();
+ String message;
+
+ addNewContact(INPUT_NAME_1 + "1", "5435754532", "1" + INPUT_EMAIL_1, CONFIRM_OPTION);
+
+ message = "Added 1 to initial length=" + previousCount + ", but resulted with a count=" +
+ mActivity.getListView().getCount();
+ assertEquals(message, ++previousCount, mActivity.getListView().getCount());
+
+ // Check Content; Name; Num; Starred
+ assertEquals(INPUT_NAME_1 + "1", getTextFromView(0, android.R.id.text1));
+ assertEquals("5435754532", getTextFromView(0, android.R.id.text2));
+
+ //Check email is saved
+ //cursor = returnEmailCursorAtId("1");
+ Uri uri = Uri.parse("content://contacts/people/1");
+ uri = Uri.withAppendedPath(uri, ContactMethods.CONTENT_DIRECTORY);
+ Cursor cursor = mActivity.getContentResolver().query(uri, CONTACTS_COLUMNS, null, null, null);
+ assertTrue("returnEmailCursorAtId: Moving cursor to first row has failed", cursor.first());
+
+ int dataIndex = cursor.getColumnIndexOrThrow("data");
+ assertEquals("1" + INPUT_EMAIL_1, cursor.getString(dataIndex));
+ cursor.deactivate();
+}
+ </pre>
+
+
+<a name="androidInstrumentationFrameworkTroubleshooting"></a><h2>Troubleshooting</h2>
+
+<p>If you run your test cases and nothing appears to happen, have a look at <code>adb logcat</code>. The following is a common problem:</p>
+<pre class="prettify">
+I/dalvikvm( 688): threadid=11: attached from native, name=Binder Thread #1
+I/dalvikvm( 688): threadid=13: attached from native, name=Binder Thread #2
+W/ActivityManager( 469): Unable to find instrumentation info for: ComponentInfo{com.google.android.browser_instrumentation/com.google.android.browser_instrumentation.BrowserWebkitLayoutInstrumentation}
+D/AndroidRuntime( 688): Shutting down VM
+E/AndroidRuntime( 688): ERROR: thread attach failed
+</pre>
+<p>It's possible that the instrumentation apk isn't installed on your device or that the package name is incorrect in the Manifest file. </p>
+
diff --git a/pdk/docs/porting/instrumentation_testing.jd b/pdk/docs/porting/instrumentation_testing.jd
new file mode 100755
index 0000000..c3765f4
--- /dev/null
+++ b/pdk/docs/porting/instrumentation_testing.jd
@@ -0,0 +1,494 @@
+page.title=Instrumentation Testing
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidInstrumentationTestingFramework">Instrumentation Framework</a></li>
+<li><a href="#androidInstrumentationFrameworkPlatform">Platform Test Suites</a></li>
+<li><a href="#androidInstrumentationFrameworkWritingRunning">Running Tests</a></li>
+<li><a href="#androidInstrumentationTestingCreating">Writing Tests</a></li>
+<li><a href="#troubleshooting">Troubleshooting</a></li>
+</ul>
+</div>
+</div>
+
+<p>This document describes how to use the Instrumentation Framework to write test cases. Instrumentation testing allows you to verify a particular feature or behavior with an automated JUnit TestCase. You can launch activities and providers within an application, send key events, and make assertions about various UI elements. </p>
+<p>You should have a working knowledge of the following:</p>
+<ul>
+ <li> Android Application Framework</li>
+ <li> Using <code>adb</code>, <code>am</code> and various logging functionality </li>
+ <li> A brief understanding of the application of interest, that is, the names of the classes which handle the intents etc. </li>
+ <li> JUnit testing.</li>
+</ul>
+<p> Each Android application runs in its own process. Instrumentation kills the application process and restarts the process with Instrumentation. Instrumentation gives a handle to the application context used to poke around the application to validate test assertions, allowing you to write test cases to test applications at a much lower level than UI screen shot tests. Note that Instrumentation cannot catch UI bugs. </p>
+
+
+<a name="androidInstrumentationTestingFramework"></a><h3>Instrumentation Framework</h3>
+
+
+
+<a name="androidInstrumentationTestingClasses"></a><h4>Classes</h4>
+
+<p> The following classes help glue together <code>Instrumentation</code> with JUnit testing. </p>
+<table>
+ <tr>
+ <th scope="col">Class</th>
+ <th scope="col">Description</th></tr>
+ <tr>
+ <td valign="top"><code>InstrumentationTestCase</code></td>
+ <td valign="top">
+ <p>This extends the standard JUnit <code>TestCase</code> and offers access to an <code>Instrumentation</code> class. Write tests inside your instrumentation class any way you see fit. For example, your test might launch activities and send key events. For this to work properly, the instrumentation needs to be injected into the test case.</p> </td>
+ </tr>
+ <tr>
+ <td valign="top"><code>InstrumentationTestRunner</code></td>
+ <td valign="top">The instrumentation test runner is an instrumentation that runs instrumentation test cases and injects itself into each test case. Instrumentation test cases need to be grouped together with an instrumentation test runner with the appropriate target package.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>InstrumentationTestSuite</code></td>
+ <td valign="top">The instrumentation test suite is a simple extension of the standard JUnit <code>TestSuite</code> that keeps a member <code>Instrumentation</code> variable on hand to inject into each <code>TestCase</code> before running them. It is used by <code>InstrumentationTestRunner</code>.</td>
+ </tr>
+</table>
+<p> Three additional base classes extend <code>InstrumentationTestCase</code> to allow you to test <code>Activity</code> and <code>Provider</code> classes:</p>
+<table>
+ <tr>
+ <th scope="col">Class</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td valign="top"><code>ActivityTestCase</code></td>
+ <td valign="top"><p>This class can be used to write tests for a specific activity. An activity is launched in its <code>setUp()</code> method and finished with <code>tearDown</code>. If you write a test case that extends <code>ActivityTestCase</code>, you can write tests that access the activity using <code>getActivity()</code> and assume it has been set up properly.</p></td>
+ </tr>
+ <tr>
+ <td valign="top"><code>ServiceTestCase</code></td>
+ <td valign="top">This test case provides a framework in which you can test Service classes in a controlled environment. It provides basic support for the lifecycle of a Service, and hooks by which you can inject various dependencies and control the environment in which your Service is tested.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>SingleLaunchActivityTestCase</code></td>
+ <td valign="top">This class is similar to <code>ActivityTestCase</code> except that the activity is launched once per class instead of every time the test case calls setup. </td>
+ </tr>
+ <tr>
+ <td valign="top"><code>ProviderTestCase</code></td>
+ <td valign="top">This class is similar to <code>ActivityTestCase</code> except that it will setup, tear down, and provide access to the <code>Provider</code> of your choice.</td>
+ </tr>
+</table>
+
+
+<a name="androidInstrumentationFrameworkamCommand"></a><h4>Understanding the am Command</h4>
+
+<p>The am command is a command-line interface to the ActivityManager (see <a href="http://code.google.com/android/reference/android/app/ActivityManager.html">http://code.google.com/android/reference/android/app/ActivityManager.html</a> for details). <code>am</code> is used to start and instrument activities using the adb shell command, as shown in the snippet below:</p>
+<pre class="prettify">
+> adb shell am
+usage: am [start|instrument]
+ am start [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
+ [-c <CATEGORY> [-c <CATEGORY>] ...]
+ [-e <EXTRA_KEY> <EXTRA_VALUE> [-e <EXTRA_KEY> <EXTRA_VALUE> ...]
+ [-n <COMPONENT>] [-D] [<URI>]
+ am instrument [-e <ARG_NAME> <ARG_VALUE>] [-p <PROF_FILE>]
+ [-w] <COMPONENT>
+For example, to start the Contacts application you can use
+> adb shell am start -n com.google.android.contacts/.ContactsActivity
+</pre>
+
+
+<a name="androidInstrumentationFrameworkPlatform"></a><h3>Platform Test Suites</h3>
+
+<p>This section provides an overview for various unit and functional test cases that can be executed through the instrumentation framework.</p>
+
+
+<a name="androidTestingPlatformFramework"></a><h4>Framework Tests</h4>
+
+<p>Framework test cases test the Android application framework or specific Android application functionality that requires an Android runtime context. These tests can be found in <code>//device/tests</code> and <code>//device/apps/AndroidTests</code>.</p>
+
+
+<a name="androidTestingPlatformCoreLibrary"></a><h4>Core Library</h4>
+
+<p>Core library test cases test the Android library functionality that does not require an Android runtime context. These tests are split into Android library (android.* package space) tests at <code>//device/java/tests</code> and Java library (java.*, javax.*, etc. packages) tests at <code>//device/dalvik/libcore/.../tests</code>.</p>
+
+
+<a name="androidInstrumentationFrameworkWritingRunning"></a><h3>Running Tests</h3>
+
+<p>Each instrumentation test case is similar to an Android application with the distinction that it starts another application. For example, have a look in the <code>tests/Contacts</code> directory. </p>
+<ul>
+ <li> There should be a Makefile and an Android Manifest file. </li>
+ <li> Tests are located in <code>tests/Contacts/src/com/google/android/contactstests</code>. </li>
+ <li> The Instrumentation Test Runner is located at <code>tests/Contacts/src/com/google/android/contactstests/functional/ContactsInstrumentationTestRunner.java</code>.</li>
+</ul>
+<p>Suppose you have a makefile with <code>Contactstests</code> as the target. </p>
+<ul>
+ <li> <code>make Contactstests</code>: Compiles the test cases. </li>
+ <li> <code>adb install Contactstests.apk</code>: Installs the apk on the device. </li>
+ <li> Use the adb shell <code>am</code> command to run them. </li>
+</ul>
+<p> To run your tests, use the <code>am instrument</code> command with your <code>InstrumentationTestRunner</code> as its argument. Results are printed as a result of the instrumentation. For example, the following snippet displays the output after running the framework tests with one test failing (note the unusual syntax caused by how instrumentations are run via <code>am</code>):</p>
+<pre class="prettify">
+$ adb shell am instrument -w com.google.android.frameworktest/.tests.FrameworkInstrumentationTestRunner
+INSTRUMENTATION_RESULT: test results:=.......F.......
+Time: 6.837
+There was 1 failure:
+1) testSetUpConditions(com.google.android.frameworktest.tests.focus.RequestFocusTest)junit.framework.AssertionFailedError: requestFocus() should work from onCreate.
+ at com.google.android.frameworktest.tests.focus.RequestFocusTest.testSetUpConditions(RequestFocusTest.java:66)
+ at java.lang.reflect.Method.invokeNative(Native Method)
+ at android.test.InstrumentationTestSuite.runTest(InstrumentationTestSuite.java:73)
+ at android.test.InstrumentationTestSuite.runTest(InstrumentationTestSuite.java:73)
+ at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:151)
+ at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1088)
+
+FAILURES!!!
+Tests run: 14, Failures: 1, Errors: 0
+
+<RETURN> to continue
+
+INSTRUMENTATION_CODE: -1
+$
+</pre>
+
+
+<a name="androidInstrumentationTestingRunningAll"></a><h4>All Tests with Default TestRunner behavior</h4>
+
+<p>If no class or package is passed in to run, InstrumentationTestRunner will automatically find and run all tests under the package of the test application (as defined by the <code>android:targetPackage</code> attribute of the instrumentation defined in its manifest file).
+</p>
+<pre>
+$ adb shell am instrument -w \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+
+INSTRUMENTATION_RESULT: Test results for InstrumentationTestRunner=..........
+Time: 2.317
+
+OK (10 tests)
+
+
+INSTRUMENTATION_CODE: -1
+</pre>
+
+
+<a name="androidTestingTestSinglePakcage"></a><h4>Running all Tests Under Single Package</h4>
+
+<p>If you have many tests under one package, use the <code>-e package <packagename></code> option to run all tests under that package without having to manually create a test suite.</p>
+<pre>
+$ adb shell am instrument -w \
+ -e package com.android.samples.view \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+INSTRUMENTATION_RESULT: Test results for InstrumentationTestRunner=........
+Time: 1.587
+
+OK (8 tests)
+</pre>
+
+
+<a name="androidTestingSingleTestSuite"></a><h4>Running a Single Test Suite</h4>
+
+<p>If you prefer to explicitly state which tests comprise all of your tests, you can define a test suite and run that directly. By convention, all test packages in your system should have at least one suite called <code>AllTests</code> (see <code>AllTests.java</code>). To run all of the tests using the <code>AllTests</code> suite for the api demos test app:</p>
+
+<pre>
+$ adb shell am instrument -w \
+ -e class com.android.samples.AllTests \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+
+INSTRUMENTATION_RESULT: Test results for AllTests=..........
+Time: 2.286
+
+OK (10 tests)
+
+
+INSTRUMENTATION_CODE: -1
+</pre>
+
+
+<a name="androidInstrumentationTestingRunningSingleTestCase"></a><h4>A Single Test Case</h4>
+
+<pre>
+$ adb shell am instrument -w \
+ -e class com.android.samples.view.Focus2ActivityTest \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+
+INSTRUMENTATION_RESULT: Test results for Focus2ActivityTest=....
+Time: 1.359
+
+OK (4 tests)
+
+
+INSTRUMENTATION_CODE: -1
+</pre>
+
+
+<a name="androidInstrumentationTestingRunningSingleTest"></a><h4>A Single Test</h4>
+
+<pre>
+$ adb shell am instrument -w \
+ -e class com.android.samples.view.Focus2ActivityTest#testGoingLeftFromRightButtonGoesToCenter \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+
+INSTRUMENTATION_RESULT: Test results for Focus2ActivityTest=.
+Time: 0.51
+
+OK (1 test)
+
+
+INSTRUMENTATION_CODE: -1
+</pre>
+
+
+<a name="androidTestingDebugging"></a><h4>Attaching a debugger to your test</h4>
+
+<p>In order to debug your test code, instruct the controller to stop and wait for the debugger by adding <code>-e debug true</code> to your
+command line. This causes the test runner to stop and wait for the debugger just before calling your <code>setUp()</code> method. For example,</p>
+
+<pre>
+$ adb shell am instrument -w \
+ -e debug true \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+</pre>
+
+
+<a name="androidInstrumentationTestingCreating"></a><h3>Writing Tests</h3>
+
+<p>When writing tests, refer to the ApiDemos tests as models (located at <code>//device/samples/ApiDemos</code>). This section provides an overview of the test structure with ApiDemos.</p>
+
+
+<a name="androidTestingLocationFiles"></a><h4>Location of Files</h4>
+
+<p>Test packages should use the following structure and include <code>Android.mk</code>, <code>AndroidManifest.xml</code>, <code>AllTests.java</code>, and a src directory that mirrors the src directory of the tested application.</p>
+<p>Files are located within a <code>tests</code> directory found in the root directory:</p>
+<pre>
+$ find samples/ApiDemos/tests
+samples/ApiDemos/tests
+samples/ApiDemos/tests/Android.mk
+samples/ApiDemos/tests/AndroidManifest.xml
+samples/ApiDemos/tests/src
+samples/ApiDemos/tests/src/com
+samples/ApiDemos/tests/src/com/google
+samples/ApiDemos/tests/src/com/google/android
+samples/ApiDemos/tests/src/com/google/android/samples
+samples/ApiDemos/tests/src/com/google/android/samples/AllTests.java
+samples/ApiDemos/tests/src/com/google/android/samples/ApiDemosTest.java
+samples/ApiDemos/tests/src/com/google/android/samples/os
+samples/ApiDemos/tests/src/com/google/android/samples/os/MorseCodeConverterTest.java
+samples/ApiDemos/tests/src/com/google/android/samples/view
+samples/ApiDemos/tests/src/com/google/android/samples/view/Focus2ActivityTest.java
+samples/ApiDemos/tests/src/com/google/android/samples/view/Focus2AndroidTest.java
+</pre>
+
+
+<a name="androidTestingContentMakefile"></a><h4>Contents of makefile</h4>
+
+<p>The contents of the makefile are similar to a normal application with the addition of a <code>LOCAL_INSTRUMENTATION_FOR</code> declaration.<p />
+<pre>
+# Add appropriate copyright banner here
+LOCAL_PATH:= $(call my-dir)
+include $(CLEAR_VARS)
+
+# We only want this apk build for tests.
+LOCAL_MODULE_TAGS := tests
+
+# Include all test java files.
+LOCAL_SRC_FILES := $(call all-java-files-under, src)
+
+# Notice that we don't have to include the src files of ApiDemos because, by
+# running the tests using an instrumentation targeting ApiDemos, we
+# automatically get all of its classes loaded into our environment.
+
+LOCAL_PACKAGE_NAME := ApiDemosTests
+
+LOCAL_INSTRUMENTATION_FOR := ApiDemos
+
+include $(BUILD_PACKAGE)
+</pre>
+
+
+<a name="androidTestingContentManifest"></a><h4>Content of Manifest</h4>
+
+<p>Use the following example to create an <code>AndroidManifest.xml</code> file that declares the instrumentation. Specify that the framework supplied Instrumentation TestRunner targest the package of your application, allowing the tests that are run with the instrumentation to get access to all of the classes of your application without having to build the source into the test app. The name of the test application is typically the same as your target application with <code>.tests</code> appended. </p>
+<pre>
+# Add appropriate copyright banner here
+<manifest xmlns:android="http://schemas.android.com/apk/res/android"
+ package="com.android.samples.tests">
+
+ <uses-permission android:name="android.permission.RUN_INSTRUMENTATION" />
+
+ <!--
+ This declares that this app uses the instrumentation test runner targeting
+ the package of com.android.samples. To run the tests use the command:
+ "adb shell am instrument -w com.android.samples.tests/android.test.InstrumentationTestRunner"
+ -->
+ <instrumentation android:name="android.test.InstrumentationTestRunner"
+ android:targetPackage="com.android.samples"
+ android:label="Tests for Api Demos."/>
+
+</manifest>
+</pre>
+<p> </p>
+<p>The following snippet will prefix the <code>/android.test.InstrumentationTestRunner</code> when running tests from the command line:</p>
+<pre>
+$ adb shell am instrument -w \
+ com.android.samples.tests/android.test.InstrumentationTestRunner
+</pre>
+
+
+<a name="androidInstrumentationTestingCreatingTestRunner"></a><h4>New Instrumentation TestRunner</h4>
+
+<p>Create a class that derives from this class. You must override two abstract methods; one that returns the class loader of the target package, and another that defines all of the tests within the package. For example, the snippet below displays the test runner for the framework tests.</p>
+<pre class="prettify">
+public class FrameworkInstrumentationTestRunner extends InstrumentationTestRunner {
+
+ @Override
+ public TestSuite getAllTests() {
+ InstrumentationTestSuite suite = new InstrumentationTestSuite(this);
+
+ suite.addTestSuite(FocusAfterRemovalTest.class);
+ suite.addTestSuite(RequestFocusTest.class);
+ suite.addTestSuite(RequestRectangleVisibleTest.class);
+ return suite;
+ }
+
+ @Override
+ public ClassLoader getLoader() {
+ return FrameworkInstrumentationTestRunner.class.getClassLoader();
+ }
+}
+</pre>
+<p> Next, in an appropriate <code>AndroidManifest.xml</code>, define the instrumentation for the derived class with the appropriate <code>android:targetPackage</code> set. For example, the snippet below defines the instrumentation runner for the framework tests.</p>
+<pre class="prettify">
+<uses-permission android:name="android.permission.RUN_INSTRUMENTATION" />
+
+<instrumentation android:name="android.tests.FrameworkInstrumentationTestRunner"
+ android:targetPackage="com.google.android.frameworktest"
+ android:label="framework instrumentation test runner" />
+</pre>
+
+
+<a name="androidInstrumentationTestingCreatingTestCase"></a><h4>New InstrumentationTestCase</h4>
+
+<p> To create a new test case, write a class that extends <code>InstrumentationTestCase</code> in the same application as your test runner. The following snippet illustrates an example <code>ActivityTestCase</code> that tests an activity named <code>MyActivity</code>.</p>
+<pre class="prettify">
+public class ButtonPressTest extends ActivityTestCase<MyActivity> {
+
+ Button mLeftButton;
+
+ public ButtonPressTest() {
+ super("com.example", MyActivity.class);
+ }
+
+ @Override
+ public void setUp() throws Exception {
+ super.setUp();
+ mLeftButton = (Button) getActivity().findViewById(R.id.leftButton);
+ }
+
+ public void testFocusMovesToRight() throws Exception {
+ assertTrue(mLeftButton.hasFocus());
+ getInstrumentation().sendCharacterSync(KeyEvent.KEYCODE_DPAD_RIGHT);
+
+ Button rightButton = (Button) getActivity().findViewById(R.id.rightButton);
+ assertTrue(rightButton.hasFocus());
+ }
+
+ // could have several more tests...
+}
+</pre>
+
+
+<a name="androidInstrumentationFrameworkTestCase"></a><h4>Exploring a Test Case</h4>
+
+<p> The test case described in this section adds and tests a new Contact. Note that you can send intents, register intent receivers, etc. </p>
+<p><code>Instrumentation.java</code> has helper functions that send key events and strings, for example: </p>
+<ul>
+ <li><code>getInstrumentation()</code>: Returns the handle to the instrumentation </li>
+ <li><code>sendCharacterSync</code>: Sends a character. </li>
+ <li><code>sendStringSync</code>: Sends a string to an input box. </li>
+ <li><code>sendKeyDownUpSync</code>: Sends a specific keyevent. </li>
+ <li><code>sendTrackballEventSync</code>: Sends a trackball event.</li>
+</ul>
+<p> You can find the test case below at <code>device/tests/Contacts.</code></p>
+<pre class="prettify">
+private void addNewContact(String name, int star, int phoneType, String number, String label,
+ String email, int emailType){
+ ContentValues values = new ContentValues();
+ Uri phoneUri = null;
+ Uri emailUri = null;
+
+ values.put(Contacts.People.NAME, name);
+ values.put(Contacts.People.STARRED, star);
+
+ //Add Phone Numbers
+ Uri uri = mActivity.getContentResolver().insert(Contacts.People.CONTENT_URI, values);
+ phoneUri = Uri.withAppendedPath(uri, Contacts.People.Phones.CONTENT_DIRECTORY);
+
+ values.clear();
+ values.put(Contacts.Phones.TYPE, phoneType);
+ values.put(Contacts.Phones.NUMBER, number);
+ values.put(Contacts.Phones.LABEL, label);
+ mActivity.getContentResolver().insert(phoneUri, values);
+
+ //Add Email
+ emailUri = Uri.withAppendedPath(uri, ContactMethods.CONTENT_DIRECTORY);
+
+ values.clear();
+ values.put(ContactMethods.KIND, Contacts.KIND_EMAIL);
+ values.put(ContactMethods.DATA, email);
+ values.put(ContactMethods.LABEL, "");
+ values.put(ContactMethods.TYPE, emailType);
+ mActivity.getContentResolver().insert(emailUri, values);
+}
+
+
+ public void testAddSaveSingleContact(){
+ int previousCount = mActivity.getListView().getCount();
+ String message;
+
+ addNewContact(INPUT_NAME_1 + "1", "5435754532", "1" + INPUT_EMAIL_1, CONFIRM_OPTION);
+
+ message = "Added 1 to initial length=" + previousCount + ", but resulted with a count=" +
+ mActivity.getListView().getCount();
+ assertEquals(message, ++previousCount, mActivity.getListView().getCount());
+
+ // Check Content; Name; Num; Starred
+ assertEquals(INPUT_NAME_1 + "1", getTextFromView(0, android.R.id.text1));
+ assertEquals("5435754532", getTextFromView(0, android.R.id.text2));
+
+ //Check email is saved
+ //cursor = returnEmailCursorAtId("1");
+ Uri uri = Uri.parse("content://contacts/people/1");
+ uri = Uri.withAppendedPath(uri, ContactMethods.CONTENT_DIRECTORY);
+ Cursor cursor = mActivity.getContentResolver().query(uri, CONTACTS_COLUMNS, null, null, null);
+ assertTrue("returnEmailCursorAtId: Moving cursor to first row has failed", cursor.first());
+
+ int dataIndex = cursor.getColumnIndexOrThrow("data");
+ assertEquals("1" + INPUT_EMAIL_1, cursor.getString(dataIndex));
+ cursor.deactivate();
+}
+ </pre>
+
+
+<a name="androidTestingKindsofTests"></a><h4>Deciding Kinds of Tests to Write</h4>
+
+<p>Once you are bootstrapped with your test application, you can start writing tests. There are three of types of tests you may wish to write:</p>
+<p><ul>
+<li> <strong>TestCase</strong>: The standard junit test case.
+</li>
+<li> <strong>AndroidTestCase</strong>: A test case with access to a Context object that is injected for you by the instrumentation test runner.
+</li>
+<li> <strong>InstrumentationTestCase</strong>: A test case with access to an Instrumentation, which can be used to launch activities, content providers, send key events, etc.
+</li>
+</ul>
+</p>
+<p>The API Demos test suite includes examples of all three styles and can be used as a guideline for writing each type of test.</p>
+<p>There are two utility classes available for the most common uses of InstrumentationTestCase: ActivityTestCase and ProviderTestCase. See their javadoc for more information.
+</p>
+
+
+<a name="troubleshooting"></a><h3>Troubleshooting</h3>
+
+<p>If you run your test cases and nothing appears to happen, have a look at <code>adb logcat</code>. The following is a common problem:</p>
+<pre class="prettify">
+I/dalvikvm( 688): threadid=11: attached from native, name=Binder Thread #1
+I/dalvikvm( 688): threadid=13: attached from native, name=Binder Thread #2
+W/ActivityManager( 469): Unable to find instrumentation info for: ComponentInfo{com.google.android.browser_instrumentation/com.google.android.browser_instrumentation.BrowserWebkitLayoutInstrumentation}
+D/AndroidRuntime( 688): Shutting down VM
+E/AndroidRuntime( 688): ERROR: thread attach failed
+</pre>
+<p>It's possible that the instrumentation apk isn't installed on your device or that the package name is incorrect in the Manifest file. </p>
diff --git a/pdk/docs/porting/intro_source_code.jd b/pdk/docs/porting/intro_source_code.jd
new file mode 100755
index 0000000..2ba413c
--- /dev/null
+++ b/pdk/docs/porting/intro_source_code.jd
@@ -0,0 +1,171 @@
+page.title=Source Code Overview
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<a name="toc"/>
+<div style="padding:10px">
+<a href="#androidSourceCodeDirectories">Introduction</a><br/>
+<a href="#Android_Source">Android Source</a><br/><div style="padding-left:40px">
+
+<a href="#androidSourceCodeDirectoriesKernel">Linux Kernel</a><br/>
+<a href="#androidSourceCodeDirectoriesDevice">Android Platform and Applications</a><br/></div>
+<a href="#androidSourceGuidelines">Adding Source Code</a><br/></div>
+
+<a name="androidSourceCodeDirectories"></a><h2>Introduction</h2>
+
+<p>Android source code is maintained in two code bases: the Android Linux kernel (<code>kernel</code> directory) and Android platform and applications (<code>device</code> directory). This document provides a high-level introduction to the source code organization and an overview of the major components of each primary directory.</p>
+
+<a name="Android_Source"></a><h2>Android Source</h2>
+
+
+<a name="androidSourceCodeDirectoriesKernel"></a><h3>Linux Kernel</h3>
+
+<p>The Android Linux kernel includes enhancements to the Linux 2.6 kernel that provide additional drivers to support the Android platform, including:</p>
+<ul>
+ <li>Binder: an OpenBinder-based driver to facilitate inter-process communication (IPC) in the Android platform.</li>
+ <li>Android Power Management: a light weight power management driver built on top of standard Linux power management but optimized for embedded systems.</li>
+ <li>Low Memory Killer: Based on hints from the userspace, the low memory killer can kill off processes to free up memory as necessary. It is designed to provide more flexibility than the Out Of Memory (OOM) killer in the standard kernel.</li>
+ <li>Logger: A light weight logging device used to capture system, radio, logdata, etc.</li>
+ <li>USB Gadget: Uses the USB function framework.</li>
+ <li>Android/PMEM: The PMEM (physical memory) driver is used to provide contiguous physical memory regions to userspace libraries that interact with the digital signal processor (DSP) and other hardware that cannot cope with scatter-gather.</li>
+ <li>Android Alarm: A driver which provides timers that can wake the device up from sleep and a monotonic timebase that runs while the device is asleep.</li>
+</ul>
+<p>Look for Android-specific enhancements in the following directories:</p>
+<p><ul>
+<li><code>/drivers/android</code></li>
+<li><code>/drivers/misc</code></li>
+<li><code>/include/linux</code></li>
+</ul>
+</p>
+
+
+<a name="androidSourceCodeDirectoriesDevice"></a><h3>Android Platform and Applications</h3>
+
+<p>The following list outlines the directory structure found within the <code>device</code> branch of Android source code:</p>
+
+
+<p><span class="lh2"><a name="gmapiMobileTagsListStart"></a></span>
+
+<ul>
+
+
+<li>apps
+Core Android applications such as Phone, Camera, and Calendar.
+</li>
+
+
+<li>boot
+Reference Android bootloader and other boot-related source code.
+</li>
+
+
+<li>commands
+Common Android commands, the most important of which is the runtime command, which does much of the initialization of the system.
+</li>
+
+
+<li>config
+System-wide makefiles and linker scripts.
+</li>
+
+
+<li>content
+Standard Android ContentProvider modules.
+</li>
+
+
+<li>dalvik
+Android runtime Virtual Machine (VM).
+</li>
+
+
+<li>data
+Fonts, keymaps, sounds, timezone information, etc.
+</li>
+
+
+<li>docs
+Full set of Android documentation.
+</li>
+
+
+<li>extlibs
+Non-Android libraries. This directory is intended to host unmodified external code. None of the libraries included within this directory rely on Android headers or libraries.
+</li>
+
+
+<li>ide
+Tools for support of the IDE's used to write Android applications.
+</li>
+
+
+<li>include
+Android system headers for inclusion.
+</li>
+
+
+<li>java
+Android core APIs, as well as some external libraries.
+</li>
+
+
+<li>libs
+Android-specific C++ based libraries.
+</li>
+
+
+<li>partner
+Project-specific source code for various proprietary components.
+</li>
+
+
+<li>prebuilt
+Prebuilt tools, like the toolchains and emulator binary.
+</li>
+
+
+<li>product
+Device-specific configuration files. This directory will include a subdirectory for each new device.
+</li>
+
+
+<li>samples
+Sample applications.
+</li>
+
+
+<li>servers
+C++ based system servers.
+</li>
+
+
+<li>system
+Core of the embedded Linux platform at the heart of Android. These essential bits are required for basic booting, operation, and debugging.
+</li>
+
+
+<li>tests
+Platform and application test cases.
+</li>
+
+
+<li>tools
+Tools for building and debugging Android (of particular interest for porting are "adb" and "emulator").
+</li>
+
+
+
+<p><span class="lh2"><a name="gmapiMobileTagsListEnd"></a></span>
+
+</ul>
+
+
+<a name="androidSourceGuidelines"></a><h2>Adding Source Code</h2>
+
+<p>You can develop Android applications with the same standard tools you use to develop any Java application. The Android core libraries provide the functionality needed to build rich mobile applications and the Android development tools are designed to simplify running, debugging, and testing your applications.</p>
+
+<p>Add project-specific source code to the Android source tree under the <code>partner</code> directory in a directory specific to the application or service you are building. For example, all Google-specific applications would be placed under <code>vendor/google/</code>. A Google search application would be placed under <code>vendor/google/apps/Search</code>.
+<p>See <a href="build_new_device.html">Building Android for a new Mobile Device</a> for detailed instructions.</p>
+
+
diff --git a/pdk/docs/porting/keymaps_keyboard_input.jd b/pdk/docs/porting/keymaps_keyboard_input.jd
new file mode 100755
index 0000000..f712015
--- /dev/null
+++ b/pdk/docs/porting/keymaps_keyboard_input.jd
@@ -0,0 +1,504 @@
+page.title=Keymaps and Keyboard Input
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidKeymapFunctionality">Functionality</a></li>
+<li><a href="#androidKeymapKeyLayoutMapTitle">Key Layout Map</a></li>
+<li><a href="#androidKeymapKeyCharMap">Key Character Map</a></li>
+<li><a href="#androidKeymapDriverTemplate">Implementing Your Own Driver (Driver Template)</a></li>
+<li><a href="#androidKeymapKeyCharMapSampleImplementation">Sample Implementation</a></li>
+</ul>
+</div>
+</div>
+
+<p>This document describes how keyboard input gets translated into Android actions and how you can customize key layout and key character maps to match the needs of your own device. </p>
+<p>Android uses the standard Linux input event device (<code>/dev/event0</code>) and driver as described in the <code>linux/input.h</code> kernel header file. For more information regarding standard Linux input drivers, please see <a href="http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/input/input.txt">Linux Input drivers</a> at <a href="http://kernel.org">http://kernel.org</a>.</p>
+
+
+
+
+<a name="androidKeymapFunctionality"></a><h3>Functionality</h3>
+
+<p>Android's input event device is structured around an interrupt or polling routine that captures the device-specific scancode and converts it to a standard form acceptable to Linux (as defined in <code>input.h</code>) before passing it to the kernel with <code>input_event()</code>.</p>
+<p>The keymap driver's other primary function is to establish a probe function that sets up the interrupt or polling function, handles hardware initialization, and attaches the driver to the input subsystem with <code>input_register_device()</code>.</p>
+<p>The table below describes the steps required to translate from keyboard input to application action: </p>
+<table border=1>
+ <tbody><tr>
+ <th scope="col">Step</th>
+ <th scope="col">Action</th>
+ <th scope="col">Explanation</th>
+ </tr>
+ <tr>
+ <td>1.</td>
+ <td>Window manager reads key event from Linux keyboard driver. </td>
+ <td>Events are typically positional. For example, the top-left position on a keypad returns 16 regardless of whether that key is printed with a Q (as on a QWERTY keypad) or an A (as on an AZERTY keypads). This first conversion by the Linux Keyboard Driver yields a scancode (for example, 16).</td>
+ </tr>
+ <tr>
+ <td>2. </td>
+ <td>Window manager maps scancode to keycode.</td>
+ <td>When the window manager reads a key event out of the driver, it maps the scancode to a keycode using a key layout map file. Typically, the keycode is the primary symbol screen-printed on a key. For example, <code>KEYCODE_DPAD_CENTER</code> is the center button on the five-way navigation control. Even though ALT + G generates a "?" character, <code>KEYCODE_G</code> is the keycode.</td>
+ </tr>
+ <tr>
+ <td>3. </td>
+ <td>Window manager sends both the scancode and the keycode to the application.</td>
+ <td>Both the scancode and keycode are handled by the view with focus.
+ How the application interprets both depend on the application.</td>
+ </tr>
+</tbody>
+</table>
+
+
+<a name="androidKeymapKeyLayoutMapTitle"></a><h3>Key Layout Map</h3>
+
+
+
+<a name="androidKeymapKeyLayoutMapSelection"></a><h4>Selection of a Key Layout Map</h4>
+
+<p>Key layout maps are installed in <code>/system/usr/keylayout</code> and <code>/data/usr/keylayout</code>.</p>
+<p>For each keyboard device xxx, set the <code>android.keylayout.xxx</code> system property (see <a href="build_new_device.html">Building New Device</a> for help setting system properties). If you don't specify a keylayout file, Android will default to <code>/system/usr/keylayout/qwerty.kl</code>.</p>
+
+
+<a name="androidKeymapKeyLayoutMapFileFormat"></a><h4>File Format</h4>
+
+<p>Key layout maps are stored on the device as UTF-8 text files and have the following characteristics:</p>
+<p><ul>
+<li>Comments: The pound symbol (#) denotes a comment and everything after the pound symbol on a line is ignored.</li>
+<li>Whitespace: All empty lines are ignored.</li>
+<li>Key definitions: Key definitions follow the syntax <code>key SCANCODE KEYCODE [FLAGS...]</code>, where <code>SCANCODE</code> is a number, <code>KEYCODE</code> is defined in your specific keylayout file (<code>android.keylayout.xxx</code>), and potential <code>FLAGS</code> are defined as follows:
+<ul><li>SHIFT: While pressed, the shift key modifier is set</li>
+<li>ALT: While pressed, the alt key modifier is set</li>
+<li>CAPS: While pressed, the caps lock key modifier is set</li>
+<li>WAKE: When this key is pressed while the device is asleep, the device will wake up and the key event gets sent to the app.</li>
+<li>WAKE_DROPPED: When this key is pressed while the device is asleep, the device will wake up and the key event does not get sent to the app.</li>
+</ul>
+</li>
+</ul>
+</p>
+
+
+<a name="androidKeymapKeyLayoutMapExample"></a><h4>Example of a Key Layout Map File</h4>
+
+<p>The following code comes from <code>android/src/device/product/generic/tuttle2.kl</code> and is an example of a complete key layout file:</p>
+<pre class="prettify">
+# Copyright 2007 Google Inc.
+
+key 2 1
+key 3 2
+key 4 3
+key 5 4
+key 6 5
+key 7 6
+key 8 7
+key 9 8
+key 10 9
+key 11 0
+key 158 BACK WAKE_DROPPED
+key 230 SOFT_RIGHT WAKE
+key 60 SOFT_RIGHT WAKE
+key 107 ENDCALL WAKE_DROPPED
+key 62 ENDCALL WAKE_DROPPED
+key 229 MENU WAKE_DROPPED
+key 59 MENU WAKE_DROPPED
+key 228 POUND
+key 227 STAR
+key 231 CALL WAKE_DROPPED
+key 61 CALL WAKE_DROPPED
+key 232 DPAD_CENTER WAKE_DROPPED
+key 108 DPAD_DOWN WAKE_DROPPED
+key 103 DPAD_UP WAKE_DROPPED
+key 102 HOME WAKE
+key 105 DPAD_LEFT WAKE_DROPPED
+key 106 DPAD_RIGHT WAKE_DROPPED
+key 115 VOLUME_UP
+key 114 VOLUME_DOWN
+key 116 POWER WAKE
+key 212 SLASH
+
+key 16 Q
+key 17 W
+key 18 E
+key 19 R
+key 20 T
+key 21 Y
+key 22 U
+key 23 I
+key 24 O
+key 25 P
+
+key 30 A
+key 31 S
+key 32 D
+key 33 F
+key 34 G
+key 35 H
+key 36 J
+key 37 K
+key 38 L
+key 14 DEL
+
+key 44 Z
+key 45 X
+key 46 C
+key 47 V
+key 48 B
+key 49 N
+key 50 M
+key 51 COMMA
+key 52 PERIOD
+key 28 NEWLINE
+
+key 56 ALT_LEFT
+key 42 SHIFT_LEFT
+key 215 AT
+key 57 SPACE
+key 53 SLASH
+key 127 SYM
+key 100 ALT_LEFT
+
+key 399 GRAVE
+</pre>
+
+
+<a name="androidKeymapKeyCharMap"></a><h3>Key Character Map</h3>
+
+
+
+<a name="androidKeymapKeyCharMapSelection"></a><h4>Selection of a Key Character Map</h4>
+
+<p>Key character maps are installed in <code>/system/usr/keychars</code> and <code>/data/usr/keychars</code>.</p>
+<p>For each keyboard device xxx, set the <code>android.keychar.xxx</code> system property to the full path of the desired keychar file. If you don't specify a keychar file, Android will default to <code>/system/usr/keychar/qwerty.kl</code>.
+
+
+<a name="androidKeymapKeyCharMapFileFormat"></a><h4>File Format</h4>
+
+<p>Key character maps are stored on the device as binary resources in order to reduce loading time. Key character maps have the following characteristics:</p>
+<p><ul>
+
+<li>Comments: The pound symbol (#) denotes a comment and everything after the pound symbol on a line is ignored.</li>
+<li>Whitespace: All empty lines are ignored.</li>
+<li>Column definitions: Column definitions follow the syntax <code>columns MODIFIERS [...]</code>, where <code>MODIFIERS</code> are defined as follows:
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Character in MODIFIERS</th>
+ <th scope="col">Corresponding bit in the modifiers</th>
+ </tr>
+ <tr>
+ <td>O</td>
+ <td>no modifiers</td>
+ </tr>
+ <tr>
+ <td>S</td>
+ <td>MODIFIER_SHIFT</td>
+ </tr>
+ <tr>
+ <td>C</td>
+ <td>MODIFIER_CONTROL</td>
+ </tr>
+ <tr>
+ <td>L</td>
+ <td>MODIFIER_CAPS_LOCK</td>
+ </tr>
+ <tr>
+ <td>A</td>
+ <td>MODIFIER_ALT</td>
+ </tr>
+</table>
+</li>
+<li>Key definitions: Key definitions have the syntax <code>key SCANCODE CHARACTER [...]</code> where <code>SCANCODE</code> is a number and <code>CHARACTER</code> values are either UTF-8 characters in quotation marks (for example, "a") or a numeric value that <code>strtol</code> can parse.</li>
+</ul></p>
+
+
+<a name="androidKeymapKeyCharMapExample"></a><h4>Example of a Key Character Map File</h4>
+
+<p>The following code comes from <code>android/src/device/product/generic/tuttle2.kcm</code> and represents a complete key character file:</p>
+<p>The type line indicates what kind of keyboard your device implements. Possible types include:</p>
+<p><ul>
+<li><b>NUMERIC</b>: A numeric (12-key) keyboard.</li>
+<li><b>Q14</b>: A keyboard that includes all letters but multiple letters per key.</li>
+<li><b>QWERTY</b>: A keyboard with all letters and possibly numbers. This option applies to all full keyboard configurations, such as AZERTY.</li>
+</ul>
+</p>
+<pre class="prettify">
+# Copyright 2007 Google Inc.
+
+[type=QWERTY]
+
+# keycode base caps fn caps_fn number display_label
+
+A 'a' 'A' '%' 0x00 '%' 'A'
+B 'b' 'B' '=' 0x00 '=' 'B'
+C 'c' 'C' '8' 0x00E7 '8' 'C'
+D 'd' 'D' '5' 0x00 '5' 'D'
+E 'e' 'E' '2' 0x0301 '2' 'E'
+F 'f' 'F' '6' 0x00A5 '6' 'F'
+G 'g' 'G' '-' '_' '-' 'G'
+H 'h' 'H' '[' '{' '[' 'H'
+I 'i' 'I' '$' 0x0302 '$' 'I'
+J 'j' 'J' ']' '}' ']' 'J'
+K 'k' 'K' '"' '~' '"' 'K'
+L 'l' 'L' ''' '`' ''' 'L'
+M 'm' 'M' '>' 0x00 '>' 'M'
+N 'n' 'N' '<' 0x0303 '<' 'N'
+O 'o' 'O' '(' 0x00 '(' 'O'
+P 'p' 'P' ')' 0x00 ')' 'P'
+Q 'q' 'Q' '*' 0x0300 '*' 'Q'
+R 'r' 'R' '3' 0x20AC '3' 'R'
+S 's' 'S' '4' 0x00DF '4' 'S'
+T 't' 'T' '+' 0x00A3 '+' 'T'
+U 'u' 'U' '&' 0x0308 '&' 'U'
+V 'v' 'V' '9' '^' '9' 'V'
+W 'w' 'W' '1' 0x00 '1' 'W'
+X 'x' 'X' '7' 0xEF00 '7' 'X'
+Y 'y' 'Y' '!' 0x00A1 '!' 'Y'
+Z 'z' 'Z' '#' 0x00 '#' 'Z'
+
+COMMA ',' ';' ';' '|' ',' ','
+PERIOD '.' ':' ':' 0x2026 '.' '.'
+AT '@' '0' '0' 0x2022 '0' '@'
+SLASH '/' '?' '?' '\' '/' '/'
+
+SPACE 0x20 0x20 0x9 0x9 0x20 0x20
+NEWLINE 0xa 0xa 0xa 0xa 0xa 0xa
+
+# on pc keyboards
+TAB 0x9 0x9 0x9 0x9 0x9 0x9
+0 '0' ')' ')' ')' '0' '0'
+1 '1' '!' '!' '!' '1' '1'
+2 '2' '@' '@' '@' '2' '2'
+3 '3' '#' '#' '#' '3' '3'
+4 '4' '$' '$' '$' '4' '4'
+5 '5' '%' '%' '%' '5' '5'
+6 '6' '^' '^' '^' '6' '6'
+7 '7' '&' '&' '&' '7' '7'
+8 '8' '*' '*' '*' '8' '8'
+9 '9' '(' '(' '(' '9' '9'
+
+GRAVE '`' '~' '`' '~' '`' '`'
+MINUS '-' '_' '-' '_' '-' '-'
+EQUALS '=' '+' '=' '+' '=' '='
+LEFT_BRACKET '[' '{' '[' '{' '[' '['
+RIGHT_BRACKET ']' '}' ']' '}' ']' ']'
+BACKSLASH '\' '|' '\' '|' '\' '\'
+SEMICOLON ';' ':' ';' ':' ';' ';'
+APOSTROPHE ''' '"' ''' '"' ''' '''
+STAR '*' '*' '*' '*' '*' '*'
+POUND '#' '#' '#' '#' '#' '#'
+PLUS '+' '+' '+' '+' '+' '+'
+</pre>
+
+
+<a name="androidKeymapKeyCharMapResourceBinaryFileFormat"></a><h4>Resource Binary File Format</h4>
+
+<p>The file snippet above gets converted to the following by the <code>makekcharmap</code> tool as part of the build process. You can <code>mmap</code> this file in and share the approximately 4k of memory that it uses between processes to minimize load time.</p>
+<table>
+ <tbody><tr>
+ <th scope="col">Offset</th>
+
+ <th scope="col">Size (bytes)</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>0x00-0x0b</td>
+ <td></td>
+ <td>The ascii value "keycharmap1" including the null character</td>
+
+ </tr>
+ <tr>
+ <td>0x0c-0x0f</td>
+ <td></td>
+ <td>padding</td>
+ </tr>
+ <tr>
+ <td>0x10-0x13</td>
+
+ <td></td>
+ <td>The number of entries in the modifiers table (COLS)</td>
+ </tr>
+ <tr>
+ <td>0x14-0x17</td>
+ <td></td>
+ <td>The number of entries in the characters table (ROWS)</td>
+
+ </tr>
+ <tr>
+ <td>0x18-0x1f</td>
+ <td></td>
+ <td>padding</td>
+ </tr>
+ <tr>
+ <td></td>
+
+ <td>4*COLS</td>
+ <td>Modifiers table. The modifier mask values that each of the
+ columns in the characters table correspond to.</td>
+ </tr>
+ <tr>
+ <td></td>
+ <td></td>
+ <td>padding to the next 16 byte boundary</td>
+
+ </tr>
+ <tr>
+ <td></td>
+ <td>4*COLS*ROWS</td>
+ <td>Characters table. The modifier mask values that each of the
+ columns correspond to.</td>
+ </tr>
+</tbody></table>
+
+
+<a name="androidKeymapDriverTemplate"></a><h3>Implementing Your Own Driver (Driver Template)</h3>
+
+<p>The following file, <code>pguide_events.c</code>, illustrates how to implement an Android keymap driver.</p>
+<pre class="prettyprint">
+/*
+ * pguide_events.c
+ *
+ * ANDROID PORTING GUIDE: INPUT EVENTS DRIVER TEMPLATE
+ *
+ * This template is designed to an example of the functionality
+ * necessary for Android to recieve input events. The PGUIDE_EVENT
+ * macros are meant as pointers indicating where to implement the
+ * hardware specific code necessary for the new device. The existence
+ * of the macros is not meant to trivialize the work required, just as
+ * an indication of where the work needs to be done.
+ *
+ * Copyright 2007, Google Inc.
+ * Based on goldfish-events.c
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/types.h>
+#include <linux/input.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+
+
+#include <asm/irq.h>
+#include <asm/io.h>
+
+
+
+#define PGUIDE_EVENTS_INTERRUPT do{} while(0)
+#define PGUIDE_EVENTS_PROBE do{} while(0)
+
+struct event_dev {
+ struct input_dev *input;
+ int irq;
+};
+
+static irqreturn_t pguide_events_interrupt(int irq, void *dev_id)
+{
+ struct event_dev *edev = dev_id;
+ unsigned type=0, code=0, value=0;
+
+ /* Set up type, code, and value per input.h
+ */
+ PGUIDE_EVENTS_INTERRUPT;
+
+ input_event(edev->input, type, code, value);
+ return IRQ_HANDLED;
+}
+
+static int pguide_events_probe(struct platform_device *pdev)
+{
+ struct input_dev *input_dev;
+ struct event_dev *edev;
+
+ printk("*** pguide events probe ***\n");
+
+ edev = kzalloc(sizeof(struct event_dev), GFP_KERNEL);
+ input_dev = input_allocate_device();
+
+ /* Setup edev->irq and do any hardware init */
+ PGUIDE_EVENTS_PROBE;
+
+ if(request_irq(edev->irq, pguide_events_interrupt, 0,
+ "pguide_events", edev) < 0) {
+ goto fail;
+ }
+
+ /* indicate that we generate key events */
+ set_bit(EV_KEY, input_dev->evbit);
+ set_bit(EV_REL, input_dev->evbit);
+ set_bit(EV_ABS, input_dev->evbit);
+
+ /* indicate that we generate *any* key event */
+
+ bitmap_fill(input_dev->keybit, KEY_MAX);
+ bitmap_fill(input_dev->relbit, REL_MAX);
+ bitmap_fill(input_dev->absbit, ABS_MAX);
+
+ platform_set_drvdata(pdev, edev);
+
+ input_dev->name = "pguide_events";
+ input_dev->private = edev;
+ input_dev->cdev.dev = &pdev->dev;
+
+ input_register_device(input_dev);
+ return 0;
+
+fail:
+ kfree(edev);
+ input_free_device(input_dev);
+
+ return -EINVAL;
+}
+
+static struct platform_driver pguide_events_driver = {
+ .probe = pguide_events_probe,
+ .driver = {
+ .name = "pguide_events",
+ },
+};
+
+static int __devinit pguide_events_init(void)
+{
+ return platform_driver_register(&pguide_events_driver);
+}
+
+
+static void __exit pguide_events_exit(void)
+{
+}
+
+module_init(pguide_events_init);
+module_exit(pguide_events_exit);
+
+MODULE_DESCRIPTION("Pguide Event Device");
+MODULE_LICENSE("GPL");
+</pre>
+
+
+<a name="androidKeymapKeyCharMapSampleImplementation"></a><h3>Sample Implementation</h3>
+
+<p>Assume the following for the setup of a new keypad device:</p>
+<pre class="prettify">
+android.keylayout.partnerxx_keypad = /system/usr/keylayout/partnerxx_keypad.kl
+android.keychar.partnerxx_keypad = /system/usr/keychars/partnerxx.kcm
+</pre>
+<p>The following example log file indicates that you have correctly registered the new keypad:</p>
+<pre class="prettify">
+I/EventHub( 1548): New device: path=/dev/input/event0 name=partnerxx_keypad id=0x10000 (of 0x1) index=1 fd=30
+I/EventHub( 1548): new keyboard input device added, name = partnerxx_keypad
+D/WindowManager( 1548): Starting input thread.
+D/WindowManager( 1548): Startup complete!
+I/EventHub( 1548): New keyboard: name=partnerxx_keypad
+ keymap=partnerxx_keypad.kl
+ keymapPath=/system/usr/keychars/partnerxx_keypad.kcm.bin
+I/ServiceManager( 1535): ServiceManager: addService(window, 0x13610)
+I/EventHub( 1548): Reporting device opened: id=0x10000, name=/dev/input/event0
+I/KeyInputQueue( 1548): Device added: id=0x10000, name=partnerxx_keypad, classes=1
+I/KeyInputQueue( 1548): Keymap: partnerxx_keypad.kl
+</pre>
+<p>The snippet above contains artificial line breaks to maintain a print-friendly document.</p>
diff --git a/pdk/docs/porting/lights.jd b/pdk/docs/porting/lights.jd
new file mode 100755
index 0000000..6bbfb89
--- /dev/null
+++ b/pdk/docs/porting/lights.jd
@@ -0,0 +1,48 @@
+page.title=Lights
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidLightsBuildingDriver">Building a Lights Library</a></li>
+<li><a href="#androidLightsInterface">Interface</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android defines a user space C abstraction interface for LED hardware. The interface header is defined in
+<code>hardware/libhardware/include/hardware/lights.h</code>.
+In order to integrate LEDs with Android you need to build a shared library that implements this interface.
+
+The types of logical lights currently supported by Android include:
+<ul>
+<li>Backlight</li>
+<li>Keyboard</li>
+<li>Buttons</li>
+<li>Battery</li>
+<li>Notifications</li>
+<li>Attention</li>
+</ul>
+</p>
+
+<a name="androidLightsBuildingDriver"></a><h3>Building a Lights Library</h3>
+<p> To implement a Lights driver, create a shared library that implements the interface defined in <code>lights.h</code>. You must name your shared library
+<code>liblights.so</code> so that it will get loaded from <code>/system/lib</code> at runtime.
+</p
+
+
+<a name="androidLightsInterface"></a><h3>Interface</h3>
+
+
+
+<p><span class="lh3"><a name="androidDoxygenNote"></a></span>
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="lights.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="lights_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0"
+frameborder="0" style="width:100%;"></iframe>
diff --git a/pdk/docs/porting/modules.html b/pdk/docs/porting/modules.html
new file mode 100755
index 0000000..ea2a07a
--- /dev/null
+++ b/pdk/docs/porting/modules.html
@@ -0,0 +1,37 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<title>Doxygen-Generated Content</title>
+<link href="doxygen.css" rel="stylesheet" type="text/css" />
+<style type="text/css">
+<!--
+.navigation {
+ display: none;
+}
+-->
+</style>
+</head>
+<body>
+<!-- Generated by Doxygen 1.5.6 -->
+<div class="navigation" id="top">
+ <div class="tabs">
+ <ul>
+ <li><a href="index.html"><span>Main Page</span></a></li>
+ <li class="current"><a href="modules.html"><span>Modules</span></a></li>
+ <li><a href="namespaces.html"><span>Namespaces</span></a></li>
+ <li><a href="annotated.html"><span>Data Structures</span></a></li>
+ <li><a href="files.html"><span>Files</span></a></li>
+ </ul>
+ </div>
+</div>
+<div class="contents">
+<h1>Modules</h1>Here is a list of all modules:<ul>
+<li><a class="el" href="group__networking.html">Neworking Support</a>
+<ul>
+<li><a class="el" href="group__memory.html">Porividng Heap Memory</a>
+</ul>
+</ul>
+</div>
+</body>
+</html>
diff --git a/pdk/docs/porting/porting_toc.cs b/pdk/docs/porting/porting_toc.cs
new file mode 100644
index 0000000..02b18e3
--- /dev/null
+++ b/pdk/docs/porting/porting_toc.cs
@@ -0,0 +1,92 @@
+<script type="text/javascript" language="JavaScript">
+<!--
+function nothing() {}
+-->
+</script>
+
+<ul>
+
+<li> <h2>Setup and Building</h2>
+ <ul>
+ <li class="toggle-list">
+ <div><a href="<?cs var:toroot ?>porting/build_system.html">Build System</a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/build_new_device.html">Configuring a New Product</a></li>
+ <li><a href="<?cs var:toroot ?>porting/build_cookbook.html">Build Cookbook</a></li>
+ </ul>
+ </li>
+ <li><a href="<?cs var:toroot ?>porting/release_keys.html">Release Keys and Signing Builds</a></li>
+ </ul>
+</li>
+
+<li> <h2>Customization</h2>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/customization.html">Customization</a></li>
+ </ul>
+</li>
+
+<li> <h2>System</h2>
+
+<ul>
+ <li><a href="<?cs var:toroot ?>porting/bring_up.html">Bring up</a></li>
+ <li class="toggle-list">
+ <div><a href="javascript:nothing()">Connectivity</a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/bluetooth.html">Bluetooth</a></li>
+ <li><a href="<?cs var:toroot ?>porting/gps.html">GPS</a></li>
+ <li><a href="<?cs var:toroot ?>porting/wifi.html">Wi-Fi</a></li>
+ </ul>
+ </li>
+
+ <li><a href="<?cs var:toroot ?>porting/display_drivers.html">Display Drivers</a></li>
+ <li class="toggle-list">
+ <div><a href="javascript:nothing()">Input Devices</a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/keymaps_keyboard_input.html">Keymaps and Keyboard</a></li>
+ </ul>
+ </li>
+ <li><a href="<?cs var:toroot ?>porting/lights.html">Lights</a></li>
+ <li class="toggle-list">
+ <div><a href="javascript:nothing()">Multimedia</a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/audio.html">Audio</a></li>
+ <li><a href="<?cs var:toroot ?>porting/camera.html">Camera/Video</a></li>
+ </ul>
+ </li>
+
+ <li><a href="<?cs var:toroot ?>porting/power_management.html">Power Management</a></li>
+ <li><a href="<?cs var:toroot ?>porting/sensors.html">Sensors</a></li>
+ <li class="toggle-list">
+ <div><a href="javascript:nothing()">Telephony</a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/telephony.html">Radio Interface Layer</a></li>
+ <li><a href="<?cs var:toroot ?>porting/stk.html">SIM Toolkit Application (STK)</a></li>
+ </ul>
+ </li>
+
+</ul>
+</li>
+
+<li> <h2>Dalvik Virtual Machine</h2>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/dalvik.html">Porting Dalvik</a></li>
+ </ul>
+</li>
+<li> <h2>Testing and Debugging</h2>
+ <ul>
+ <li><a href="<?cs var:toroot ?>porting/instrumentation_testing.html">Instrumentation Testing</a></li>
+ <li><a href="<?cs var:toroot ?>porting/debugging_gdb.html">Debugging with GDB</a></li>
+ <li><a href="<?cs var:toroot ?>porting/debugging_native.html">Debugging Native Code</a></li>
+ <li><a href="<?cs var:toroot ?>porting/tcpdump.html">Debugging with tcpdump</a></li>
+ </ul>
+</li>
+
+
+
+</ul>
+
+<script type="text/javascript">
+<!--
+ buildToggleLists();
+//-->
+</script>
diff --git a/pdk/docs/porting/power_management.jd b/pdk/docs/porting/power_management.jd
new file mode 100755
index 0000000..542459d
--- /dev/null
+++ b/pdk/docs/porting/power_management.jd
@@ -0,0 +1,203 @@
+page.title=Power Management
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<a name="toc"/>
+<div style="padding:10px">
+<a href="#androidPowerIntro">Introduction</a><br/>
+<a href="#androidPowerWakeLocks">Wake Locks</a><br/><div style="padding-left:40px">
+
+<a href="#androidPowerWakeLocksDefinitions">Types of Wake Locks</a><br/>
+<a href="#androidPowerWakeLockExample">Exploring a Wake Lock Example</a><br/></div>
+<a href="#androidPowerPowerManagerClass">PowerManager class</a><br/>
+<a href="#androidPowerKernelRegistration">Registering Drivers with the PM Driver</a><br/>
+<a href="#androidPowerEarlySuspend">Early Suspend</a><br/>
+</div>
+
+<a name="androidPowerIntro"></a><h2>Introduction</h2>
+
+<p>Android supports its own Power Management (on top of the standard Linux Power Management) designed with the premise that the CPU shouldn't consume power if no applications or services require power. For more information regarding standard Linux power management, please see <a href="http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/pm.txt">Linux Power Management Support</a> at <a href="http://kernel.org">http://kernel.org</a>.</p>
+<p>Android requires that applications and services request CPU resources with "wake locks" through the Android application framework and native Linux libraries. If there are no active wake locks, Android will shut down the CPU. </p>
+<p>The image below illustrates the Android power management architecture. </p>
+<p><img src='images/androidPMArchitecture.gif'></p>
+
+Solid elements represent Android blocks and dashed elements represent partner-specific blocks.
+
+
+
+<a name="androidPowerWakeLocks"></a><h2>Wake Locks</h2>
+
+<p>Wake locks are used by applications and services to request CPU resources.</p>
+
+<p>A locked wakelock, depending on its type, prevents the system from entering suspend or other low-power states. This document describes how to employ wakelocks. </p>
+<p>There are two settings for a wakelock:</p>
+<ul>
+ <li><code>WAKE_LOCK_SUSPEND</code>: prevents a full system suspend. </li>
+ <li><code></code><code>WAKE_LOCK_IDLE</code>: low-power states, which often cause large interrupt latencies or that disable a set of interrupts, will not be entered from idle until the wakelocks are released. </li>
+</ul>
+<p>Unless the type is specified, this document refers to wakelocks of type <code>WAKE_LOCK_SUSPEND</code>. </p>
+<p>If the suspend operation has already started when locking a wakelock, the system will abort the suspend operation as long it has not already reached the <code>suspend_late</code> stage. This means that locking a wakelock from an interrupt handler or a freezeable thread always works, but if you lock a wakelock from a <code>suspend_late</code> handler, you must also return an error from that handler to abort suspend. You can use wakelocks to allow the user-space to decide which keys should wake the full system and turn on the screen. Use <code>set_irq_wake</code> or a platform-specific API to ensure that the keypad interrupt wakes up the CPU. Once the keypad driver has resumed, the sequence of events can look like this:</p>
+<ol>
+ <li> The Keypad driver receives an interrupt, locks the keypad-scan wakelock,
+ and starts scanning the keypad matrix. </li>
+ <li>The keypad-scan code detects a key change and reports it to the input-event
+ driver. </li>
+ <li>The input-event driver sees the key change, enqueues an event, and locks
+ the input-event-queue wakelock. </li>
+ <li>The keypad-scan code detects that no keys are held and unlocks the
+ keypad-scan wakelock. </li>
+ <li>The user-space input-event thread returns from select/poll, locks the
+ process-input-events wakelock, and calls read in the input-event device. </li>
+ <li>The input-event driver dequeues the key-event and, since the queue is now
+ empty, unlocks the input-event-queue wakelock. </li>
+ <li>The user-space input-event thread returns from read. It determines that the
+ key should not wake up the full system, releases the process-input-events
+ wakelock, and calls select or poll. </li>
+</ol>
+<p>The simple sequence diagram below illustrates these steps:</p>
+ <pre>
+ Key pressed Key released
+ | |
+ keypad-scan ++++++++++++++++++++++
+ input-event-queue +++ +++
+ process-input-events +++ +++
+ </pre>
+
+<a name="driverAPI"></a><h3>Driver API</h3>
+<p>A driver can use the wakelock API by adding a wakelock variable to its state and calling <code>wake_lock_init</code>, as illustrated in the snippet below:</p>
+<pre>
+ struct state {
+ struct wakelock wakelock;
+ }
+ init() {
+ wake_lock_init(&state->wakelock, WAKE_LOCK_SUSPEND, "wakelockname");
+ }
+ Before freeing the memory, wake_lock_destroy must be called:
+ uninit() {
+ wake_lock_destroy(&state->wakelock);
+ }
+ </pre>
+<p> When the driver determines that it needs to run (usually in an interrupt handler), it calls <code>wake_lock</code>:</p>
+<pre>
+ wake_lock(&state->wakelock);
+ </pre>
+<p>When it no longer needs to run, it calls <code>wake_unlock</code>:</p>
+<pre>
+ wake_unlock(&state->wakelock);
+ </pre>
+<p> It can also call <code>wake_lock_timeout</code> to release the wakelock after a delay:</p>
+<pre>
+ wake_lock_timeout(&state->wakelock, HZ);
+</pre>
+<p> This works whether or not the wakelock is already held. It is useful if the driver woke up other parts of the system that do not use wakelocks but still need to run. Avoid this when possible, since it will waste power if the timeout is long or may fail to finish needed work if the timeout is short.</p>
+<a name="userspaceAPI"></a><h3>User-space API</h3>
+<p>Write <code>lockname</code> or <code>lockname timeout</code> to <code>/sys/power/wake_lock</code> lock and, if needed, create a wakelock. The timeout here is specified in nanoseconds. Write <code>lockname</code> to <code>/sys/power/wake_unlock</code> to unlock a user wakelock.</p>
+<p> Do not use randomly generated wakelock names as there is no API to free a user-space wakelock.</p>
+
+<a name="androidPowerWakeLocksDefinitions"></a><h3>Types of Wake Locks</h3>
+
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Wake Lock </th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>ACQUIRE_CAUSES_WAKEUP<br/></td>
+ <td>Normally wake locks don't actually wake the device, they just cause it to remain on once it's already on. Think of the video player app as the normal behavior. Notifications that pop up and want the device to be on are the exception; use this flag to be like them.</td>
+ </tr>
+ <tr>
+ <td>FULL_WAKE_LOCK</td>
+ <td>Wake lock that ensures that the screen and keyboard are on at full brightness. </td>
+ </tr>
+ <tr>
+ <td>ON_AFTER_RELEASE</td>
+ <td>When this wake lock is released, poke the user activity timer so the screen stays on for a little longer.</td>
+ </tr>
+ <tr>
+ <td>PARTIAL_WAKE_LOCK</td>
+ <td>Wake lock that ensures that the CPU is running. The screen might not be on.</td>
+ </tr>
+ <tr>
+ <td>SCREEN_BRIGHT_WAKE_LOCK</td>
+ <td>Wake lock that ensures that the screen is on at full brightness; the keyboard backlight will be allowed to go off.</td>
+ </tr>
+ <tr>
+ <td>SCREEN_DIM_WAKE_LOCK</td>
+ <td>Wake lock that ensures that the screen is on, but the keyboard backlight will be allowed to go off, and the screen backlight will be allowed to go dim.</td>
+ </tr>
+</table>
+
+
+<a name="androidPowerWakeLockExample"></a><h3>Exploring a Wake Lock Example</h3>
+
+<p>All power management calls follow the same basic format:</p>
+<p><ol><li>Acquire handle to the <code>PowerManager</code> service.</li>
+<li>Create a wake lock and specify the power management flags for screen, timeout, etc.</li>
+<li>Acquire wake lock.</li>
+<li>Perform operation (play MP3, open HTML page, etc.).</li>
+<li>Release wake lock.</li>
+</ol>
+</p>
+<p>The snippet below illustrates this process.</p>
+<pre class="prettify">
+PowerManager pm = (PowerManager)mContext.getSystemService(
+ Context.POWER_SERVICE);
+PowerManager.WakeLock wl = pm.newWakeLock(
+ PowerManager.SCREEN_DIM_WAKE_LOCK
+ | PowerManager.ON_AFTER_RELEASE,
+ TAG);
+wl.acquire();
+ // ...
+wl.release();
+</pre>
+
+
+<a name="androidPowerPowerManagerClass"></a><h2>PowerManager class</h2>
+
+<p>The Android Framework exposes power management to services and applications through the <code>PowerManager</code> class.</p>
+<p>User space native libraries (any hardware function in <code>//device/lib/hardware/</code> meant to serve as supporting libraries for Android runtime) should never call into Android Power Management directly (see the image above). Bypassing the power management policy in the Android runtime will destabilize the system.</p>
+<p>All calls into Power Management should go through the Android runtime PowerManager APIs.</p>
+<p> Please visit
+<a href="http://code.google.com/android/reference/android/os/PowerManager.html">http://code.google.com/android/reference/android/os/PowerManager.html</a> for a description of the API and examples.</p>
+
+
+<a name="androidPowerKernelRegistration"></a><h2>Registering Drivers with the PM Driver</h2>
+
+<p>You can register Kernel-level drivers with the Android Power Manager driver so that they're notified immediately before power down or after power up. For example, you might set a display driver to completely power down when a request comes in to power down from the user space (see the Android MSM MDDI display driver for a sample implementation).</p>
+<p>To register drivers with the Android PM driver, implement call-back handlers and register them with the Android PM, as illustrated in the snippet below:</p>
+<pre class="prettify">
+android_register_early_suspend(android_early_suspend_t *handler)
+android_register_early_resume(android_early_resume_t *handler)
+</pre>
+<p>It is critical in a drive to return immediately and not wait for anything to happen in the call back.</p>
+
+
+<a name="androidPowerEarlySuspend"></a><h2>Early Suspend</h2>
+
+<p>The early-suspend API allows drivers to get notified when user-space writes to <code>/sys/power/request_state</code> to indicate that the user visible sleep state should change. Suspend handlers are called in order of low to high (4 - 1 below) and resume handlers are called in order of high to low (1 - 4 below).</p>
+<ol>
+ <li><code>EARLY_SUSPEND_LEVEL_BLANK_SCREEN</code>: </li>
+ <ul>
+ <li>on suspend: the screen should be turned off but the framebuffer must still be accessible. </li>
+ <li>on resume: the screen can be turned back on.</li>
+ </ul>
+ <li><code>EARLY_SUSPEND_LEVEL_STOP_DRAWING</code>:
+ <ul>
+ <li>on suspend: this level notifies user-space that it should stop accessing the framebuffer and it waits for it to complete.</li>
+ <li>on resume: it notifies user-space that it should resume screen access. Two methods are provided, console switch or a sysfs interface.</li>
+ </ul>
+ </li>
+ <li><code>EARLY_SUSPEND_LEVEL_DISABLE_FB</code>: Turn off the framebuffer
+ <ul>
+ <li>on suspend: turn off the framebuffer</li>
+ <li>on resume: turn the framebuffer back on. </li>
+ </ul>
+ </li>
+ <li><code>EARLY_SUSPEND_LEVEL_STOP_INPUT</code>:
+ <ul>
+ <li>on suspend: turn off input devices that are not capable of wakeup or where wakeup is disabled. </li>
+ <li>on resume: turn the same devices back on.</li>
+ </ul>
+ </li>
+</ol>
diff --git a/pdk/docs/porting/release_keys.jd b/pdk/docs/porting/release_keys.jd
new file mode 100755
index 0000000..116cdbb
--- /dev/null
+++ b/pdk/docs/porting/release_keys.jd
@@ -0,0 +1,82 @@
+page.title=Creating Release Keys and Signing Builds
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+ <div id ="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+ <ul>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#generatingKeys">Generating keys</a></li>
+ <li><a href="#signing">Signing a build for release</a></li>
+ </ul>
+ </div>
+</div>
+<a name="intro"></a>
+<h3>Introduction</h3>
+<p>Android requires that each application be signed with the developer's digital keys to enforce signature permissions and application request to use shared user ID or target process. For more information on the general Android security principles and signing requirements, see the Android Security and Permissions section in the Android Developer Guide). The core Android platform uses four keys to maintain security of core platform components:</p>
+<ul>
+ <li><strong>platform</strong>: a key for packages that are part of the core platform.</li>
+ <li><strong>shared</strong>: a key for things that are shared in the <code>home/contacts</code> process.</li>
+ <li><strong>media</strong>: a key for packages that are part of the <code>media/download</code> system.</li>
+ <li><strong>releasekey</strong>: the default key to sign with if not otherwise specified</li>
+</ul>
+<p>These keys are used to sign applications separately for release images and are not used by the Android build system. The build system signs packages with the testkeys provided in <code>build/target/product/security/</code>. Because the testkeys are part of the standard Android open source distribution, they should never be used for production devices. Instead, device manufacturers should generate their own private keys for shipping release builds.</p>
+<a name="generatingKeys"></a>
+<h3>Generating keys</h3>
+<p>A device manufacturer's keys for each product should be stored under <code>vendor/<vendor_name>/security/<product_name></code>, where <code><vendor_name></code> and <code><product_name></code> represent the manufacturer and product names. To simplify key creation, copy the script below to this directory in a file called <code>mkkey.sh</code>. To customize your keys, change the line that starts with AUTH to reflect the correct information for your company:</p>
+<pre>
+#!/bin/sh
+AUTH='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'
+if [ "$1" == "" ]; then
+ echo "Create a test certificate key."
+ echo "Usage: $0 NAME"
+ echo "Will generate NAME.pk8 and NAME.x509.pem"
+ echo " $AUTH"
+ exit
+fi
+
+openssl genrsa -3 -out $1.pem 2048
+
+openssl req -new -x509 -key $1.pem -out $1.x509.pem -days 10000 \
+ -subj "$AUTH"
+
+echo "Please enter the password for this key:"
+openssl pkcs8 -in $1.pem -topk8 -outform DER -out $1.pk8 -passout stdin
+</pre>
+<p><code>mkkey.sh</code> is a helper script to generate the platform's keys. NOTE: the password you type will be visible in your terminal window. Note the passwords you use as you will need them to sign release builds.</p>
+<p>To generate the required 4 platform keys, run <code>mkkey.sh</code> four times specifying the key name and password for each:</p>
+<pre>
+sh mkkey.sh platform # enter password
+sh mkkey.sh media # enter password
+sh mkkey.sh shared # enter password
+sh mkkey.sh release # enter password
+</pre>
+<p>You should now have new keys for your product.</p>
+<a name="signing"></a>
+<h3>Signing a build for release</h3>
+<p>Signing a build for a release is a two-step process. </p>
+<ol>
+ <li>Sign all the individual parts of the build.</li>
+ <li>Put the parts back together into image files.</li>
+</ol>
+<h4>Signing applications</h4>
+<p>Use <code>build/tools/releasetools/sign_target_files_apks</code> to sign a <code>target_files</code> package. The <code>target_files</code> package isn't built by default, you need to make sure to specify the "dist" target when you call make. For example:</p>
+<pre>
+make -j4 PRODUCT-<product_name>-user dist
+</pre>
+<p>The command above creates a a file under <code>out/dist </code>called <code><product_name>-target_files.zip</code>. This is the file you need to pass to the <code>sign_target_files_apks</code> script.</p>
+<p>You would typically run the script like this:</p>
+<pre>
+./build/tools/releasetools/sign_target_files_apks -d vendor/<vendor_name>/security/<product_name> <product_name>-target_files.zip signed-target-files.zip
+</pre>
+<p>If you have prebuilt and pre-signed apk's in your build that you don't want re-signed, you must explicitly ignore them by adding <code>-e Foo.apk=</code> to the command line for each apk you wish to ignore.</p>
+<p><code>sign_target_files_apks</code> also has many other options that could be useful for signing release builds. Run it with <code>-h</code> as the only option to see the full help.</p>
+<h4>Creating image files</h4>
+<p>Once you have <code>signed-target-files.zip</code>, create the images so you can put it onto a device with the command below:</p>
+<pre>
+build/tools/releasetools/img_from_target_files signed-target-files.zip signed-img.zip
+</pre>
+<p><code>signed-img.zip</code> contains all the <code>.img</code> files. You can use <code>fastboot update signed-img.zip</code> to use fastboot to get them on the device.</p>
diff --git a/pdk/docs/porting/sensors.jd b/pdk/docs/porting/sensors.jd
new file mode 100755
index 0000000..1b24026
--- /dev/null
+++ b/pdk/docs/porting/sensors.jd
@@ -0,0 +1,67 @@
+page.title=Sensors
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidSensorsInterface">Interface</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android defines a user space C abstraction interface for sensor hardware. The interface header is defined in
+<code>hardware/libhardware/include/hardware/sensors.h</code>.
+In order to integrate sensors with Android you need to build a shared library that implements this interface.
+
+The types of sensors currently supported by Android include:
+<ul>
+<li>Accelerometer</li>
+<li>Magnetic Field</li>
+<li>Orientation</li>
+<li>Gyroscope</li>
+<li>Light</li>
+<li>Pressure</li>
+<li>Temperature</li>
+<li>Proximity</li>
+</ul>
+</p>
+
+<a name="androidSensorBuildingDriver"></a><h3>Building a Sensor Library</h3>
+<p> To implement a Sensors driver, create a shared library that implements the interface defined in <code>sensors.h</code>. You must name your shared library
+<code>libsensors.so</code> so that it will get loaded from <code>/system/lib</code> at runtime.
+</p>
+
+<p> The following stub file, <code>Android.mk</code>, ensures that <code>libsensors</code> compiles and links to the appropriate libraries:</p>
+
+<pre>
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := sensors
+
+LOCAL_PRELINK_MODULE := false
+
+LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw
+
+LOCAL_SHARED_LIBRARIES := liblog
+# include any shared library dependencies
+
+LOCAL_SRC_FILES := sensors.c
+
+include $(BUILD_SHARED_LIBRARY)
+</pre>
+
+<a name="androidSensorsInterface"></a><h3>Interface</h3>
+
+
+<p><span class="lh3"><a name="androidDoxygenNote"></a></span>
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="sensors.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="sensors_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0"
+frameborder="0" style="width:100%;"></iframe>
diff --git a/pdk/docs/porting/source_setup_guide.jd b/pdk/docs/porting/source_setup_guide.jd
new file mode 100755
index 0000000..77e1d60
--- /dev/null
+++ b/pdk/docs/porting/source_setup_guide.jd
@@ -0,0 +1,118 @@
+page.title=Host System Setup
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<a name="toc"/>
+<div style="padding:10px">
+<a href="#androidSourceSetupIntro">Introduction</a><br/>
+<a href="#androidSourceSetupBuildSystemSetupPackages">Installing Packages</a><br/><div style="padding-left:40px">
+
+<a href="#androidSourceSetupBuildSystemSetupRequiredPackages">Required Packages</a><br/>
+<a href="#androidSourceSetupUbuntu606Intro">Ubuntu 6.06 (Dapper)</a><br/>
+<a href="#androidSourceSetupUbuntu710Intro">Ubuntu 7.10</a><br/>
+<a href="#androidSourceSetupUbuntu804Intro">Ubuntu 8.04</a><br/></div>
+<a href="#androidSourceSetupBuildSystemSetupJavaIntro">Installing Java</a><br/></div>
+
+<a name="androidSourceSetupIntro"></a><h2>Introduction</h2>
+
+<p>This section provides instructions on how to configure your host system to build Android for mobile devices. While Android is designed as host-environment agnostic, it has been tested and is known to work on the following Linux operating system; Ubuntu 6.06 (Dapper), 7.10 (Gutsy), and 8.04. Cygwin is not recommended. </p>
+
+
+<a name="androidSourceSetupBuildSystemSetupPackages"></a><h2>Installing Packages</h2>
+
+
+
+<a name="androidSourceSetupBuildSystemSetupRequiredPackages"></a><h3>Required Packages</h3>
+
+<p>Android requires the following system packages:</p>
+<p><ul>
+<li>flex: This lexical analyzer generator is used to read a given input file for a description of a scanner to generate.</li>
+<li>bison: This is a general-purpose parser generator.</li>
+<li>gperf: This is a perfect hash function generator.</li>
+<li>libesd0-dev: This enlightened sound daemon (dev files) is used to mix digitized audio streams for playback by a single device.</li>
+<li>libwxgtk2.6-dev: This package provides GUI components and other facilities for many different platforms.</li>
+<li>build-essential: This package contains a list of packages considered fundamental to building Debian packages.</li>
+</ul></p>
+
+
+<a name="androidSourceSetupUbuntu606Intro"></a><h3>Ubuntu 6.06 (Dapper)</h3>
+
+<p>On a clean Dapper system, type the following:</p>
+<pre class="prettyprint">
+% sudo apt-get install flex bison gperf libesd0-dev libwxgtk2.6-dev zlib1g-dev
+ build-essential
+</pre>
+<p>This snippet includes an artificial line break to maintain a print-friendly document.</p>
+
+
+<a name="androidSourceSetupUbuntu710Intro"></a><h3>Ubuntu 7.10</h3>
+
+<ol><li>The libwxgtk2.6-dev package will only work if the following code is included in your /etc/apt/source file.
+<p><pre class="prettyprint">
+## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
+## team, and may not be under a free license. Please satisfy yourself as to
+## your rights to use the software. Also, please note that software in
+## universe WILL NOT receive any review or updates from the Ubuntu security
+## team.
+# Line commented out by installer because it failed to verify:
+deb http://us.archive.ubuntu.com/ubuntu/ gutsy universe
+# Line commented out by installer because it failed to verify:
+deb-src http://us.archive.ubuntu.com/ubuntu/ gutsy universe
+# Line commented out by installer because it failed to verify:
+deb http://us.archive.ubuntu.com/ubuntu/ gutsy-updates universe
+# Line commented out by installer because it failed to verify:
+deb-src http://us.archive.ubuntu.com/ubuntu/ gutsy-updates universe
+</pre></p></li>
+<li>Install required packages with the following command:
+<p><pre class="prettyprint">
+% sudo apt-get install flex bison gperf libesd0-dev libwxgtk2.6-dev zlib1g-dev
+ build-essential
+</pre></p>
+This snippet includes an artificial line break to maintain a print-friendly document.
+</li>
+<li>
+<p>Install the X11 development environment with the following commands:</p>
+<p><pre class="prettyprint">
+% sudo apt-get install x-dev
+% sudo apt-get install libx11-dev
+% sudo apt-get install libncurses5-dev
+</pre></p>
+</li>
+</ol>
+
+
+<a name="androidSourceSetupUbuntu804Intro"></a><h3>Ubuntu 8.04</h3>
+
+<p>On a clean system, type the following:</p>
+<pre class="prettify">
+% sudo apt-get install flex bison gperf libesd0-dev libwxgtk2.6-dev
+zlib1g-dev build-essential
+% sudo apt-get install x-dev
+% sudo apt-get install libx11-dev
+% sudo apt-get install libncurses5-dev
+% sudo apt-get install sun-java5-jdk
+</pre>
+
+
+<a name="androidSourceSetupBuildSystemSetupJavaIntro"></a><h2>Installing Java</h2>
+
+<p>Android source code includes a hard dependency on the Java Developer Kit (JDK) 5.0 Update 12 or greater. The specific file name of the Update 12 package is <code>jdk-1_5_0_12-linux-i586.bin</code>. To download this version of the Java JDK:</p>
+<p><ol>
+<li>Navigate to: <a href="http://java.sun.com/products/archive/">http://java.sun.com/products/archive/</a>.</li>
+<li>Select '5.0 Update 12' from the 'Java 2 Platform Standard Edition (J2SE)' -> 'JDK/JRE - 5.0' field and click 'Go.'</li>
+<li>Click 'Download JDK.'</li>
+<li>In the 'Linux Platform' section, click 'Linux self-extracting file' associated with the jdk-1_5_0_12-linux-i586.bin package.</li>
+<li>Follow the installation instructions.</li>
+</ol>
+</p>
+
+<p>Once you have cleanly installed the JDK, modify your PATH environment variable to include <code><jdk-install-dir>/jdk1.5.0_12/bin</code> at its beginning so that Dapper will use the correct installation. </p>
+<p><b>Ubuntu 7.10</b></p>
+<p>An alternative method to quickly install Java is to enable multiverse repo in <code>/etc/apt/sources.list</code> and then execute:</p>
+<pre class="prettyprint">
+% sudo apt-get install sun-java5-jdk
+</pre>
+
+
+
diff --git a/pdk/docs/porting/stk.jd b/pdk/docs/porting/stk.jd
new file mode 100755
index 0000000..a73ed93
--- /dev/null
+++ b/pdk/docs/porting/stk.jd
@@ -0,0 +1,508 @@
+page.title=Sim Toolkit Application (STK)
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidSTKRILRilUp">Communication from the RIL up</a></li>
+<li><a href="#androidSTKRILApplciationDown">Communication from the application down</a></li>
+<li><a href="#androidSTKTelephony">Telephony</a></li>
+<li><a href="#androidSTKFeatureList">Feature List</a></li>
+</ul>
+</div>
+</div>
+
+
+<p>This document offers a high-level overview of the SIM Toolkit Application for Android 1.0 and is primarily of interest for implementors of the Radio Interface Layer (RIL). The STK is R96 compatible (3GPP TS 11.14 v5.9.0) and complies partially with R99 (3GPP TS 101.267 v8.17.0). See the <a href="#androidSTKFeatureList">STK Feature List</a> for the complete feature list. </p>.
+<p>The Android STK implementation includes three layers:</p>
+<ul>
+ <li> STK RIL: Low-level layer provided by the vendor plus <code>libril</code>.</li>
+ <li>STK Telephony: Protocol translation layer that converts raw messages provided by the STK RIL to application level messages.</li>
+ <li>STK Application: Provides the user interface interactions needed by the STK.</li>
+</ul>
+<p align="left"><br />
+ <img src="images/stk.gif" alt="STK schema" width="566" height="516" /><br />
+</p>
+<p> The Sim Toolkit communication flow is bi-directional and commands can originate from the <code>STK RIL</code> packaged in <code>RIL_UNSOL_STK_PROACTIVE_COMMAND</code>, <code>RIL_UNSOL_STK_EVENT_NOTIFY</code>, <code>RIL_UNSOL_REFRESH</code> and <code>RIL_UNSOL_STK_SESSION_END</code> messages.</p>
+<p align="left">Commands originating from the STK App or STK Telephony layers are packaged in <code>RIL_REQUEST_STK_SEND_TERMINAL_REPSONSE</code>, <code>RIL_REQUEST_SEND_ENVELOPE_COMMAND</code> or <code>RIL_REQUEST_HANDLE_CALL_SETUP_REQUESTED_FROM_SIM</code>.</p>
+<p align="left">For commands sent or recieved by the STK RIL, it's not necessary to remove unused sub-commands because the upper layers will gracefully ignore unused information contained in the message. The content of each message is encoded in the BER-TLV format except for two:</p>
+<ul>
+ <li><code>RIL_UNSOL_STK_SESSION_END</code>: has no data </li>
+ <li><code>RIL_REQUEST_HANDLE_CALL_SETUP_REQUESTED_FROM_SIM</code>: has a single byte of data that indicates accept/reject.</li>
+</ul>
+<p>See the <a href="http://pdk-docs.prom.corp.google.com/docs/telephony.html">Android Platform Development Kit</a> for details.</p>
+
+
+<a name="androidSTKRILRilUp"></a><h4>Communication from the RIL up</h4>
+
+<p>Communication to the upper layers is done using the <code>RIL_UNSOL_xxx</code> family of commands defined in <code>/hardware/ril/include/ril.h</code>. The payload for each command is encoded using BER-TLV. As stated above, it is not necessary to remove extraneous fields. This allows the SIM to pass a complete command to the upper layers and simplifies STK RIL code. Below is the mapping from RIL_UNSOL_xxx commands to the SIM commands.</p>
+
+
+<a name="androidSTKRILRilUpUnsol"></a><h4>RIL_UNSOL_STK_PROACTIVE_COMMAND</h4>
+
+<p> The Sim Toolkit communication flow is bi-directional and commands can originate from the <code>STK RIL</code> packaged in <code>RIL_UNSOL_STK_PROACTIVE_COMMAND</code>, <code>RIL_UNSOL_STK_EVENT_NOTIFY</code>, <code>RIL_UNSOL_REFRESH</code> and <code>RIL_UNSOL_STK_SESSION_END</code> messages.</p>
+
+
+<a name="androidSTKRILRilUpDisplay"></a><h5>DISPLAY TEXT (6.4.1)</h5>
+
+<p>This command is handled by <code>StkDialogActivity</code>. If the immediate response flag is set, the terminal response is sent with an "OK" <code>(0x00)</code> result code when the message is first received. Otherwise the terminal response is sent when the dialog is dismissed either from user action or it times out.</p>
+<p>The user sees a dialog box with a message and / or icon, an OK button, and a Cancel button.</p>
+<p>Terminal responses include:</p>
+<ul>
+ <li> "OK" (0x00)</li>
+ <li> "Session terminated by user" (0x10)</li>
+ <li> "Backward move by user" (0x11)</li>
+ <li> "No response from user" (0x12)</li>
+</ul>
+
+<img src="images/stk_display_text.gif" border="1">
+
+
+<a name="androidSTKRILRilUpGetInKey"></a><h5>GET IN KEY (6.4.2)</h5>
+
+<P>This command is processed by <code>StkInputActivity</code>. It displays a dialog box with a prompt and or an icon and yes and no buttons.</p>
+<p>Terminal responses include:</p>
+<p>
+<ul>
+ <li> “OK” (0x00) with “Yes” or “No” as the response text</li>
+ <li> “Session terminated by user” (0x10) << Currently not supported</li>
+ <li> “Backward move by user” (0x11)</li>
+ <li> “No response from user” (0x12)</li>
+</ul>
+</p>
+
+
+<a name="androidSTKRILRilUpGetInput"></a><h5>GET INPUT (6.4.3)</h5>
+
+<p>This command is handled by <code>StkInputActivity</code>.
+<p>The user sees a dialog box with a prompt and / or an icon, a text box with optional default text, and an OK button. 'digits only,' 'min,' 'max,' and 'hidden' modes are all supported.
+<p>Terminal responses include:</p>
+ <ul>
+ <li>OK” (0x00) if the input criteria is met </li>
+ <li>“Session terminated by user” (0x10) << Currently not supported </li>
+ <li>“Backward move by user” (0x11) </li>
+ <li>“No response from user” (0x12) </li>
+</ul>
+
+
+<a name="androidSTKRILRilUpPlayTone"></a><h5>PLAY TONE (6.4.5)</h5>
+
+<p>This command is processed by <code>ToneDialog</code>.</p>
+<p>The user sees a dialog box with a prompt for the duration of the tone or until the user presses the back key.</p>
+<p>Terminal responses include:</p>
+ <ul>
+ <li>"OK" (0x00) if the tone is played to completion </li>
+ <li>“Session terminated by user” (0x10) if back button is pressed </li>
+</ul>
+
+
+<a name="androidSTKRILRilUpSetMenu"></a><h5>SET UP MENU (6.4.8)</h5>
+
+<p>This command is processed by <code>StkAppService</code>. It installs the STK ICON on the home page and prepares the Main menu for use when the ICON is selected. Typically this is the first RIL unsolicited command and should not be sent until after the <code>RIL_RadioFunctions.getVersion</code> routine is called.</p>
+<p>Terminal reponses:</p>
+<ul>
+ <li>“OK” (0x00) </li>
+</ul>
+<p>At a later time, the STK ICON will be selected and <code>StkMenuActivity</code> will launch and display the Main menu to the user. If an item is selected, it will be returned to the RIL in <code>RIL_REQUEST_STK_SEND_ENVELOPE_COMMAND</code> with the item id. If no item is selected, the <code>StkMenuActivity</code> will receive a timeout message and return to the Main menu and no message will be sent to the RIL.</p>
+<p>Depending upon what item is selected, the SIM may perform another action, such as sending another set of menu items via a SELECT ITEM command or performing an action like send an SMS or text display. </p>
+
+
+<a name="androidSTKRILRilUpSelectItem"></a><h5>SELECT ITEM (6.4.9)</h5>
+
+<p>This command is processed by <code>StkMenuActivity</code>. Instead of displaying the Main menu, the list of menu items provided in this command are displayed.</p>
+<p>Terminal responses:
+<ul>
+ <li> “OK” (0x00) </li>
+</ul>
+<p>The command then proceeds as in the SETUP MENU. </p>
+
+
+<a name="androidSTKRILRilUpSetIdle"></a><h5>SET UP IDLE MODE TEXT (6.4.22)</h5>
+
+<p><code>StkAppService</code> displays the message and or icon as an Android notification.</p>
+<p>Terminal responses include:</p>
+ <ul>
+ <li>OK” (0x00)</li>
+</ul>
+
+
+<a name="androidSTKRILRilUpLaunchBrowser"></a><h5>LAUNCH BROWSER (6.4.26)</h5>
+
+<p>This command is initially handled by <code>StkDialogActivity</code> and presents the user with a confirmation dialog, a URL, and OK, and cancel buttons. If the user presses OK, the browser is launched using the URL.</p>
+<p>Terminal responses include:</p>
+ <ul>
+ <li>“OK” (0x00) the browser has been launched </li>
+ <li>“Session terminated by user” (0x10) </li>
+ <li>“Backward move by user” (0x11)</li>
+ <li>“No response from user” (0x12)</li>
+</ul>
+
+
+<a name="androidSTKRILRilUpEvent"></a><h4>RIL_UNSOL_STK_EVENT_NOTIFY</h4>
+
+<p align="left">The commands in this section are proactive in nature. They are handled by the STK RIL and the upper layers and delivered using <code>RIL_UNSOL_STK_EVENT_NOTIFY</code> message. This distinction is an implementation detail of Android and is not defined in the 3GPP sepcifications.</p>
+<p align="left">The upper layers handle the UI and the STK RIL handles all other aspects of each command, which means that the STK RIL sends the terminal response (it is never sent by the STK App). Each command must be a properlery-formed proactive command. It is not necessary to remove unused fields. The behavior of any other command <em>within this context </em>sent by <code>RIL_UNSOL_STK_EVENT_NOTIFY</code> is undefined. See Event Notify Command Details. </p>
+<ul>
+ <li>SEND SMS (6.4.10) – no response</li>
+ <li>SEND SS (6.4.11) – no response</li>
+ <li>SEND USSD (6.4.12) – no response</li>
+ <li>SET UP CALL (6.4.13) – responds with <code>RIL_REQUEST_STK_HANDLE_CALL_SETUP_REQUESTED_FROM_SIM</code></li>
+ <li>SEND DTMF (6.4.24) – no response</li>
+</ul>
+
+<img src="images/stk_send_SMS.gif">
+
+
+<a name="androidSTKRILRilUpUnsolSim"></a><h4>RIL_UNSOL_SIM_REFRESH</h4>
+
+<p> Used to send the <code>REFRESH</code> command. No response.</p>
+
+
+<a name="androidSTKRILRilUpRefresh"></a><h4>REFRESH (6.4.7)</h4>
+
+<p><code>RIL_UNSOL_STK_SESSION_END</code></p>
+<p>Sent by the SIM to signal the end of a session. No content and no response.</p>
+<P><img src="images/stk_refresh_init.gif"></p>
+<p><img src="images/stk_refresh_update.gif"> </p>
+<p><img src="images/stk_refresh_reset.gif"> </p>
+
+
+
+<a name="androidSTKRILRilUpRilUnsol"></a><h4>RIL_UNSOL_STK_SESSION_END</h4>
+
+<p>Sent by SIM to signal end of session. No content and no response.</p>
+
+
+<a name="androidSTKRILApplciationDown"></a><h4>Communication from the application down</h4>
+
+<p>Communication from the upper layers to the RIL uses the commands below (defined in <code>ril.h</code>):</p>
+
+
+<a name="androidSTKRILApplciationDownTerminal"></a><h4>RIL_REQUEST_STK_SEND_TERMINAL_REPSONSE</h4>
+
+<p> Used to send a terminal response for commands sent via <code>RIL_UNSOL_STK_PROACTIVE_COMMAND</code>. </P>
+<P>Contents include TERMINAL RESPONSE (6.8).</p>
+
+
+<a name="androidSTKRILApplciationDownEnvelope"></a><h4>RIL_REQUEST_STK_SEND_ENVELOPE_COMMAND</h4>
+
+<p>Used to send information from to SIM encoded as BER-TLV tags (see R96 section 13). Two tags are supported:</p>
+<ul>
+ <li> BER_MENU_SELECTION_TAG (0xd3); Contents: MENU SELECTION (8)</li>
+ <li>BER_EVENT_DOWNLOAD_TAG (0xd6); Contents: EVENT DOWNLOAD Language selection (11.8)</li>
+</ul>
+<P>Content for these tags include:
+<ul>
+ <li>MENU SELECTION (8)</li>
+ <li>EVENT DOWNLOAD Language selection (11.8)</li>
+</ul>
+
+
+
+<a name="androidSTKRILApplciationDownFromSim"></a><h4>RIL_REQUEST_HANDLE_CALL_SETUP_REQUESTED_FROM_SIM</h4>
+
+<p>Returns a single-byte parameter:</p>
+<ul>
+ <li>1: accepted</li>
+ <li>0: not accepted</li>
+</ul>
+<p> This should cause the terminal response to be sent to the SIM.</p>
+
+
+<a name="androidSTKTelephony"></a><h3>Telephony</h3>
+
+<p>STK Telephony is a protocol translation layer used to convert messages from BERL-TLV format to Application messages and back. </p>
+<p>On the STK RIL side, STK Telphony receives raw buffer messages from RIL I/F and decodes them into a command parameters container before passing them on to the application. On the Application side, this layer receives application responses for commands and encodes them into raw buffer messages, which then get sent over the RIL I/F back to the SIM card.</p>
+
+
+<a name="androidSTKFeatureList"></a><h3>Feature List</h3>
+
+<table border="1" cellspacing="2" cellpadding="2">
+ <tr>
+ <td><p align="center"><strong>Feature</strong></p></td>
+ <td><p align="center"><strong>Support</strong></p></td>
+ <td><p align="center"><strong>Implemented by</strong></p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROFILE DOWNLOAD - before radio turn-on</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SET UP MENU</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="SELECT ITEM "><p>SELECT ITEM </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>GET INPUT</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>GET INKEY</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>DISPLAY TEXT</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="SET UP IDLE MODE TEXT "><p>SET UP IDLE MODE TEXT </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="SEND SHORT MESSAGE "><p>SEND SHORT MESSAGE </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="SEND SS "><p>SEND SS </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SEND USSD</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SEND DTMF</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>LAUNCH BROWSER</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SET UP CALL</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PLAY TONE</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>POLL INTERVAL</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>POLLING OFF</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="TIMER MANAGEMENT "><p>TIMER MANAGEMENT </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>MORE TIME</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (MCC, MNC, LAC, Cell ID & IMEI)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (NMR)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (Timing Advance)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION(battery state)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (IMEISV)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (NMR(UTRAN))</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PROVIDE LOCAL INFORMATION (Search Mode change)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>REFRESH</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="SET UP EVENT LIST "><p>SET UP EVENT LIST </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband – ME</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: MT call</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Call connected (all modes)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Call disconnected (all modes)</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Idle screen available</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Browser termination</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="Event: Location status "><p>Event: Location status </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Data available</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Channel status</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Access Technology changed</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Local Connection</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Event: Network Search Mode Change</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>GET READER STATUS</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>POWER ON CARD</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>POWER OFF CARD</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>PERFORM CARD ADPU</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>RUN AT COMMAND</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>OPEN CHANNEL</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="CLOSE CHANNEL "><p>CLOSE CHANNEL </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>RECEIVE DATA</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SEND DATA</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>GET CHANNEL STATUS</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>CALL CONTROL BY SIM</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SMS-PP data download</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>SMS-CB data download</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">Baseband</p></td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="BIP over GPRS "><p>BIP over GPRS </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>BIP over USB</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom" u1:str="Text Attributes "><p>Text Attributes </p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">NO</p></td>
+ <td nowrap="nowrap" valign="bottom"> </td>
+ </tr>
+ <tr>
+ <td nowrap="nowrap" valign="bottom"><p>Color icons</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">YES</p></td>
+ <td nowrap="nowrap" valign="bottom"><p align="center">ME</p></td>
+ </tr>
+</table>
diff --git a/pdk/docs/porting/system_requirements.jd b/pdk/docs/porting/system_requirements.jd
new file mode 100755
index 0000000..0a0b331
--- /dev/null
+++ b/pdk/docs/porting/system_requirements.jd
@@ -0,0 +1,60 @@
+page.title=Device Requirements
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<p>While Android is designed to support a wide variety of hardware platforms and configurations, this section provides recommended minimum device requirements.</p>
+<table border=1 cellpadding=2 cellspacing=0>
+ <tbody><tr>
+ <th scope="col">Feature</th>
+ <th scope="col">Minimum Requirement</th>
+ <th scope="col">Notes</th>
+ </tr>
+ <tr>
+ <td>Chipset</td>
+ <td>ARM-based</td>
+ <td>For the first release, Android is primarily targeted towards mobile handsets and portions of the platform, such as Dalvik VM graphics processing, currently assume an ARM architecture.</td>
+ </tr>
+ <tr>
+ <td>Memory</td>
+ <td>128 MB RAM; 256 MB Flash External</td>
+ <td>Android can boot and run in configurations with less memory, but it isn't recommended.</td>
+ </tr>
+ <tr>
+ <td>Storage</td>
+ <td>Mini or Micro SD </td>
+ <td>Not necessary for basic bring up, but recommended.</td>
+ </tr>
+ <tr>
+ <td>Primary Display </td>
+ <td>HVGA required</td>
+ <td>The current Android interface targets a touch-based HVGA resolution display with a touch-interface no smaller than 2.8 inches in size. However, smaller displays will suffice for initial porting.</td>
+ </tr>
+ <tr>
+ <td>Navigation Keys </td>
+ <td>5-way navigation with 5 application keys, power, camera and volume controls</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>Camera</td>
+ <td>2MP CMOS</td>
+ <td>Not required for basic bring up. </td>
+ </tr>
+ <tr>
+ <td>USB</td>
+ <td>Standard mini-B USB interface</td>
+ <td>Android uses the USB interface for flashing the device system images and debugging a running device.</td>
+ </tr>
+ <tr>
+ <td>Bluetooth</td>
+ <td>1.2 or 2.0 </td>
+ <td>Not required for initial bring up.</td>
+ </tr>
+</tbody>
+</table>
+<p>If available, your Android device can also benefit from the following optional device characteristics:</p>
+<ul>
+ <li>QWERTY keyboard</li>
+ <li>WiFi</li>
+ <li>GPS</li>
+</ul>
diff --git a/pdk/docs/porting/tcpdump.jd b/pdk/docs/porting/tcpdump.jd
new file mode 100755
index 0000000..1627bc7
--- /dev/null
+++ b/pdk/docs/porting/tcpdump.jd
@@ -0,0 +1,90 @@
+page.title=Debugging with tcpdump and other tools
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+
+<a name="toc"/>
+<div style="padding:10px">
+ <a href="#installing">Installing tcpdump</a><BR>
+ <a href="#running">Running tcpdump</a><br/>
+ <a href="#other">Other network debugging commands</a><br/>
+</div>
+
+<a name="installing"></a>
+<h3>Installing tcpdump</h3>
+<h4>Pushing the binary to an existing device</h4>
+<p>Download tcpdump from <a href="http://www.tcpdump.org/">http://www.tcpdump.org/</a>, then execute:</p>
+<pre>
+adb root
+adb remount
+adb push /wherever/you/put/tcpdump /system/xbin/tcpdump
+adb shell chmod 6755 /data/local/tmp/tcpdump
+</pre>
+<h4>Including tcpdump in the build image</h4>
+<p>If you are running your own build, execute:</p>
+<pre>
+mmm external/tcpdump # install the binary in out/.../system/xbin
+make snod # build a new system.img that includes it
+</pre>
+<p>Flash the device as usual, for example, <code>fastboot flashball</code>.</p>
+<p>If you want to build tcpdump by default, add <code>CUSTOM_TARGETS += tcpdump</code> to your <code>buildspec.mk</code>.</p>
+<h3><a name="running"></a>Running tcpdump</h3>
+<p>You need to have root access on your device. </p>
+<h4>Batch mode capture</h4>
+<p>The typical procedure is to capture packets to a file and then examine the file on the desktop, as illustrated below:</p>
+<pre>
+adb shell tcpdump -i any -p -s 0 -w /sdcard/capture.pcap
+# "-i any": listen on any network interface
+# "-p": disable promiscuous mode (doesn't work anyway)
+# "-s 0": capture the entire packet
+# "-w": write packets to a file (rather than printing to stdout)
+
+ ... do whatever you want to capture, then ^C to stop it ...
+
+adb pull /sdcard/capture.pcap .
+sudo apt-get install wireshark # or ethereal, if you're still on dapper
+wireshark capture.pcap # or ethereal
+
+ ... look at your packets and be wise ...
+</pre>
+<p>You can run <code>tcpdump</code> in the background from an interactive shell or from Terminal. By default, <code>tcpdump</code> captures all traffic without filtering. If you prefer, add an expression like port 80 to the <code>tcpdump</code> command line.</p>
+<h4>Real time packet monitoring</h4>
+<p>Execute the following if you would like to watch packets go by rather than capturing them to a file (<code>-n</code> skips DNS lookups. <code>-s 0</code> captures the entire packet rather than just the header):</p>
+<pre>
+adb shell tcpdump -n -s 0
+</pre>
+<p>Typical <code>tcpdump</code> options apply. For example, if you want to see HTTP traffic:</p>
+<pre>
+adb shell tcpdump -X -n -s 0 port 80
+</pre>
+<p>You can also monitor packets with <code>wireshark</code> or <code>ethereal</code>, as shown below:</p>
+<pre>
+# In one shell, start tcpdump.
+adb shell "tcpdump -n -s 0 -w - | nc -l -p 11233"
+
+# In a separate shell, forward data and run ethereal.
+adb forward tcp:11233 tcp:11233 && nc 127.0.0.1 11233 | ethereal -k -S -i -
+</pre>
+<p>Note that you can't restart capture via <code>ethereal</code>. If anything goes wrong, you will need to rerun both commands.</p>
+<p>For more immediate output, add <code>-l</code> to the <code>tcpdump</code> command line, but this can cause <code>adb</code> to choke (it helps to use a nonzero argument for <code>-s</code> to limit the amount of data captured per packet; <code>-s 100</code> is sufficient if you just want to see headers).</p>
+<h4>Disabling encryption</h4>
+<p>If your service runs over <code>https</code>, <code>tcpdump</code> is of limited use. In this case, you can rewrite some service URLs to use <code>http</code>, for example:</p>
+<pre>
+vendor/google/tools/override-gservices url:calendar_sync_https_proxy \
+ https://www.google.com/calendar rewrite http://android.clients.google.com/proxy/calendar
+</pre>
+<h3><a name="other"></a>Other network debugging commands</h3>
+<h4>On the device:</h4>
+<ul>
+ <li><code>ifconfig interface</code>: note that unlike Linux, you need to give <code>ifconfig</code> an argument</li>
+ <li><code>netcfg</code>: lists interfaces and IP addresses</li>
+ <li><code>iftop</code>: like top for network</li>
+ <li><code>route</code>: examine the routing table</li>
+ <li><code>netstat</code>: see active network connections</li>
+ <li><code>nc</code>: <code>netcat</code> connection utility</li>
+</ul>
+<h4>On the desktop:</h4>
+<ul>
+ <li> <code>curl</code>: fetch URLs directly to emulate device requests</li>
+</ul>
diff --git a/pdk/docs/porting/telephony.jd b/pdk/docs/porting/telephony.jd
new file mode 100755
index 0000000..dcf5773
--- /dev/null
+++ b/pdk/docs/porting/telephony.jd
@@ -0,0 +1,230 @@
+page.title=Radio Layer Interface
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidTelephonyRILInitialization">RIL Initialization</a></li>
+<li><a href="#androidTelephonyRILIntro">RIL Interaction</a></li>
+<li><a href="#androidTelephonyRILImplementing">Implementing the RIL</a></li>
+<li><a href="#androidTelephonyRILFunctions">RIL Functions</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony services (<a href="http://code.google.com/android/reference/android/telephony/package-descr.html">android.telephony</a>) and radio hardware. The RIL is radio agnostic, and includes support for Global System for Mobile communication (GSM)-based radios. </P>
+
+
+<p>The diagram below illustrates the RIL in the context of Android's Telephony system architecture.</p>
+<p><img src="images/telephony.gif"></p>
+
+Solid elements represent Android blocks and dashed elements represent partner-specific blocks.
+
+<p>The RIL consists of two primary components:</p>
+<p><ul>
+<li><b>RIL Daemon</b>: The RIL daemon initializes the Vendor RIL, processes all communication from Android telephony services, and dispatches calls to the Vendor RIL as solicited commands.</li>
+<li><b>Vendor RIL</b>: The radio-specific Vendor RIL of <code>ril.h</code> that processes all communication with radio hardware and dispatches calls to the RIL Daemon (<code>rild</code>) through unsolicited commands.</li>
+</ul>
+</p>
+
+
+<a name="androidTelephonyRILInitialization"></a><h3>RIL Initialization</h3>
+
+<p>Android initializes the telephony stack and the Vendor RIL at startup as described in the sequence below:</p>
+<p><ol>
+<li>RIL daemon reads <code>rild.lib</code> path and <code>rild.libargs</code> system properties to determine the Vendor RIL library to use and any initialization arguments to provide to the Vendor RIL</li>
+<li>RIL daemon loads the Vendor RIL library and calls <code>RIL_Init</code> to initialize the RIL and obtain a reference to RIL functions</li>
+<li>RIL daemon calls <code>RIL_register</code> on the Android telephony stack, providing a reference to the Vendor RIL functions</li></ol>
+</p>
+<p>See the RIL Daemon source code at <code>//device/commands/rild/rild.c</code> for details.</p>
+<p><b>System Properties</b></p>
+<p>The following RIL-related system properties are set by the RIL library:</p>
+<p><ul>
+<li><code>ro.ril.ecclist</code>: list of valid Emergency Call Codes, for example, 911. Values are read from <code>EF_ECC</code> on the SIM and possibly supplmented by tables based on operator, network, or manufacturing code.</li></ul></p>
+
+<p>The following RIL_related system properties are available to the RIL library:</p>
+<p><ul>
+<li><code>ro.ril.hsxpa</code>: inidcates <code>hsxpa</code> support of target network.</li>
+<li><code>ro.ril.gprsclass</code>: inidcates GPRS class of target network.</li>
+<li><code>ro.ril.enable.3g.prefix=1</code>: adds the 3G prefix to the operator name.</li>
+</ul></p>
+
+<a name="androidTelephonyRILIntro"></a><h3>RIL Interaction</h3>
+
+<p>There are two forms of communication that the RIL handles:</p>
+<ul>
+ <li>Solicited commands: Solicited commands originated by RIL lib, such as <code>DIAL</code> and <code>HANGUP</code>.</li>
+ <li>Unsolicited responses: Unsolicited responses that originate from the baseband, such as <code>CALL_STATE_CHANGED</code> and <code>NEW_SMS</code>.</li>
+</ul>
+
+
+<a name="androidTelephonyRILSolicited"></a><h4>Solicited</h4>
+
+<p>The following snippet illustrates the interface for solicited commands:</p>
+<pre class="prettify">
+void OnRequest (int request_id, void *data, size_t datalen, RIL_Token t);
+void OnRequestComplete (RIL_Token t, RIL_Error e, void *response, size_t responselen);
+</pre>
+<p>There are over sixty solicited commands grouped by the following families:</p>
+<p>
+<ul>
+ <li>SIM PIN, IO, and IMSI/IMEI (11)</li>
+ <li>Call status and handling (dial, answer, mute…) (16)</li>
+ <li>Network status query (4)</li>
+ <li>Network setting (barring, forwarding, selection…) (12)</li>
+ <li>SMS (3)</li>
+ <li>PDP connection (4)</li>
+ <li>Power and reset (2)</li>
+ <li>Supplementary Services (5)</li>
+ <li>Vendor defined and support (4)<br/>
+ </li>
+</ul>
+</p>
+<p>The following diagram illustrates a solicited call in Android.</p>
+<p><img src="images/telephony_solicted_example.gif"></p>
+
+
+<a name="androidTelephonyRILUnsolicited"></a><h4>Unsolicited</h4>
+
+<p>The following snippet illustrates the interface for unsolicited commands:</p>
+<pre class="prettify">
+void OnUnsolicitedResponse (int unsolResponse, void *data, size_t datalen);
+</pre>
+<p>There are over ten unsolicited commands grouped by the following families:</p>
+<p>
+<ul>
+<li>Network status changed (4)</li>
+<li>New SMS notify (3)</li>
+<li>New USSD notify (2)</li>
+<li>Signal strength or time changed (2)</li>
+</ul>
+</p>
+<p>The following diagram illustrates an unsolicited call in Android.</p>
+<p><img src="images/telephony_unsolicted_example.gif"></p>
+
+
+<a name="androidTelephonyRILImplementing"></a><h3>Implementing the RIL</h3>
+
+<p>To implement a radio-specific RIL, create a shared library that implements a set of functions required by Android to process radio requests. The required functions are defined in the RIL header (<code>/include/telephony/ril.h</code>).</p>
+<p>The Android radio interface is radio-agnostic and the Vendor RIL can use any protocol to communicate with the radio. Android provides a reference Vendor RIL, using the Hayes AT command set, that you can use as a quick start for telephony testing and a guide for commercial vendor RILs. The source code for the reference RIL is found at <code>/commands/reference-ril/</code>.</p>
+<p>Compile your Vendor RIL as a shared library using the convention <code>libril-<companyname>-<RIL version>.so</code>, for example, libril-acme-124.so, where:</p>
+<p><ul>
+<li><b>libril</b>: all vendor RIL implementations start with 'libril'</li>
+<li><b><companyname></b>: a company-specific abbreviation</li>
+<li><b><RIL version></b>: RIL version number</li>
+<li><b>so</b>: file extension</li>
+</ul>
+</p>
+
+
+<a name="androidTelephonyRILInit"></a><h4>RIL_Init</h4>
+
+<p>Your Vendor RIL must define a RIL_Init function that provides a handle to the functions which will process all radio requests. RIL_Init will be called by the Android RIL Daemon at boot time to initialize the RIL.</p>
+
+<pre class="prettify">
+RIL_RadioFunctions *RIL_Init (RIL_Env* env, int argc, char **argv);
+</pre>
+
+<p>RIL_Init should return a RIL_RadioFunctions structure containing the handles to the radio functions:</p>
+<pre class="prettify">
+type structure {
+ int RIL_version;
+ RIL_RequestFunc onRequest;
+ RIL_RadioStateRequest onStateRequest;
+ RIL_Supports supports;
+ RIL_Cancel onCancel;
+ RIL_GetVersion getVersion;
+}
+RIL_RadioFunctions;
+</pre>
+
+
+<a name="androidTelephonyRILFunctions"></a><h3>RIL Functions</h3>
+
+<p><code>ril.h</code> defines RIL states and variables, such as <code>RIL_UNSOL_STK_CALL_SETUP</code>, <code>RIL_SIM_READY</code>, <code>RIL_SIM_NOT_READY</code>, as well as the functions described in the tables below. Skim the header file (<code>/device/include/telephony/ril.h</code>) for details.</p>
+
+
+<a name="androidRilFunctionsSolicited"></a><h4>RIL Solicited Command Requests</h4>
+
+<p>The vendor RIL must provide the functions described in the table below to handle solicited commands. The RIL solicited command request types are defined in <code>ril.h</code> with the <code>RIL_REQUEST_</code> prefix. Check the header file for details.</p>
+<p><table>
+ <tr><th scope="col">Name</th><th scope="col">Description</th></tr>
+ <tr>
+ <td valign="top"><code> void (*RIL_RequestFunc) (int request, void *data, size_t datalen, RIL_Token t);</code></td>
+ <td valign="top">
+ <p>This is the RIL entry point for solicited commands and must be able to handle the various RIL solicited request types defined in <code>ril.h</code> with the <code>RIL_REQUEST_</code> prefix.</p>
+ <ul>
+ <li><code>request</code> is one of <code>RIL_REQUEST_*</code></li>
+ <li><code>data</code> is pointer to data defined for that <code>RIL_REQUEST_*</code></l>
+ <li><code>t</code> should be used in subsequent call to <code>RIL_onResponse</code></li>
+ <li><code>datalen</code> is owned by caller, and should not be modified or freed by callee</li>
+ </ul>
+ <p>Must be completed with a call to <code>RIL_onRequestComplete()</code>. <code>RIL_onRequestComplete()</code> may be called from any thread before or after this function returns. This will always be called from the same thread, so returning here implies that the radio is ready to process another command (whether or not the previous command has completed).</p></td>
+ </tr>
+ <tr>
+ <td valign="top"><code> RIL_RadioState (*RIL_RadioStateRequest)();</code></td>
+ <td valign="top">This function should return the current radio state synchronously.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code> int (*RIL_Supports)(int requestCode);</code></td>
+ <td valign="top">This function returns "1" if the specified <code>RIL_REQUEST</code> code is supported and 0 if it is not.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code> void (*RIL_Cancel)(RIL_Token t);</code></td>
+ <td valign="top"><p>This function is used to indicate that a pending request should be canceled. This function is called from a separate thread--not the thread that calls <code>RIL_RequestFunc</code>.</p>
+ <p>On cancel, the callee should do its best to abandon the request and call <code>RIL_onRequestComplete</code> with <code>RIL_Errno CANCELLED</code> at some later point.</p>
+ <p>Subsequent calls to <code>RIL_onRequestComplete</code> for this request with other results will be tolerated but ignored (that is, it is valid to ignore the cancellation request).</p>
+ <p><code>RIL_Cancel</code> calls should return immediately and not wait for cancellation.</p></td>
+ </tr>
+ <tr>
+ <td valign="top"><code> const char * (*RIL_GetVersion) (void);</code></td>
+ <td valign="top">Return a version string for your Vendor RIL</td>
+ </tr>
+</table>
+
+
+<p>The vendor RIL uses the following callback methods to communicate back to the Android RIL daemon.</p>
+<p>
+<table>
+ <tr>
+ <th scope="col">Name</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td><code>void RIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen);</code></td>
+ <td><ul>
+ <li><code>t</code> is parameter passed in on previous call to <code>RIL_Notification</code> routine.</li>
+ <li>If <code>e</code> != SUCCESS, then response can be null and is ignored</li>
+ <li><code>response</code> is owned by caller, and should not be modified or freed by callee</li>
+ <li><code>RIL_onRequestComplete</code> will return as soon as possible</li>
+ </ul></td>
+ </tr>
+ <tr>
+ <td><code>void RIL_requestTimedCallback (RIL_TimedCallback callback, void *param, const struct timeval *relativeTime);</code></td>
+ <td>Call user-specified callback function on the same thread that <code>RIL_RequestFunc</code> is called. If <code>relativeTime</code> is specified, then it specifies a relative time value at which the callback is invoked. If <code>relativeTime</code> is NULL or points to a 0-filled structure, the callback will be invoked as soon as possible.</td>
+ </tr>
+</table></p>
+
+
+<a name="androidRilFunctionsUnsolicited"></a><h4>RIL Unsolicited Commands</h4>
+
+<p>The functions listed in the table below are call-back functions used by the Vendor RIL to invoke unsolicited commands on the Android platform. See <code>ril.h</code> for details. </p>
+<p>
+<table>
+ <tr>
+ <th scope="col">Name</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td><code>void RIL_onUnsolicitedResponse(int unsolResponse, const void *data, size_t datalen);</code></td>
+ <td><ul>
+ <li><code>unsolResponse</code> is one of <code>RIL_UNSOL_RESPONSE_*</code></li>
+ <li><code>data</code> is pointer to data defined for that <code>RIL_UNSOL_RESPONSE_*</code></li>
+ <li><code>data</code> is owned by caller, and should not be modified or freed by callee</li>
+ </ul></td>
+ </tr>
+</table></p>
diff --git a/pdk/docs/porting/wifi.jd b/pdk/docs/porting/wifi.jd
new file mode 100755
index 0000000..eea431b
--- /dev/null
+++ b/pdk/docs/porting/wifi.jd
@@ -0,0 +1,51 @@
+page.title=Wi-Fi
+pdk.version=1.0
+doc.type=porting
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+<h2>In this document</h2>
+<a name="toc"/>
+<ul>
+<li><a href="#androidWifiBuildingDriver">Building a Wi-Fi Library</a></li>
+<li><a href="#androidWifiInterface">Interface</a></li>
+</ul>
+</div>
+</div>
+
+<p>Android uses wpa_supplicant as the platform interface to the Wi-Fi device. Your Wi-Fi driver must be compatible with the standard wpa_supplicant in addition to extensions added to the supplicant (specifically, the "DRIVER" commands described in <code>wifi.h/wifi_command()</code>).</p>
+
+
+<a name="androidWifiBuildingDriver"></a><h3>Building a Wi-Fi Library</h3>
+
+<p>To create a Wi-Fi driver for Android:</p>
+<p><ul>
+<li>create a shared library that implements the interface defined in <code>include/hardware/wifi.h</code>, which also defines the Wi-Fi supplicant.</li>
+<li>Follow the instructions posted at <a href="http://hostap.epitest.fi/wpa_supplicant/">http://hostap.epitest.fi/wpa_supplicant/</a>.</li>
+<li>Place your driver in <code>libs/hardware/wifi/</code></li>
+<li>Test your driver using the command line <code>wpa_cli</code> utilities.</li>
+</ul>
+
+<p>You can find the default implementation in <code>libs/hardware/wifi/wifi.c</code>. If you need to make changes, create a new source file similar to <code>wifi.c</code>, for example, <code>wifi_mywifi.c</code>. </p>
+
+<p>Update the default <code>Android.mk</code> file (<code>libs/hardware/wifi/Android.mk</code>) as shown below.</p>
+<pre class="prettify">
+LOCAL_SHARED_LIBRARIES += libnetutils
+
+ifeq ($(TARGET_PRODUCT),acme)
+LOCAL_SRC_FILES += wifi/wifi_mywifi.c
+else
+LOCAL_SRC_FILES += wifi/wifi.c
+endif
+</pre>
+
+
+<a name="androidWifiInterface"></a><h3>Interface</h3>
+
+
+
+<p class="note"><strong>Note</strong>: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, <a href="wifi.html">click here</a>.</p>
+
+
+<iframe onLoad="resizeDoxFrameHeight();" src="wifi_8h.html" scrolling="no" scroll="no" id="doxygen" marginwidth="0" marginheight="0" frameborder="0" style="width:100%;"></iframe>
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>
diff --git a/pdk/hosting/app.yaml b/pdk/hosting/app.yaml
index b36efe8..6758539 100644
--- a/pdk/hosting/app.yaml
+++ b/pdk/hosting/app.yaml
@@ -4,8 +4,10 @@
api_version: 1
handlers:
-- url: /online-pdk
- static_dir: online-pdk
-
- url: /
- script: pdk.py
+ static_files: online-pdk/index.html
+ upload: online-pdk/index.html
+
+- url: /(.*)
+ static_files: online-pdk/\1
+ upload: online-pdk/.*
