Added Release Checklist to PDK. Original content written by Dianne.
diff --git a/pdk/docs/guide/pdk_toc.cs b/pdk/docs/guide/pdk_toc.cs
index d1493e6..f829d43 100644
--- a/pdk/docs/guide/pdk_toc.cs
+++ b/pdk/docs/guide/pdk_toc.cs
@@ -16,6 +16,7 @@
</ul>
</li>
<li><a href="<?cs var:toroot ?>guide/release_keys.html">Release Keys and Signing Builds</a></li>
+ <li><a href="<?cs var:toroot ?>guide/release_checklist.html">Release Checklist</a></li>
</ul>
</li>
diff --git a/pdk/docs/guide/release_checklist.jd b/pdk/docs/guide/release_checklist.jd
new file mode 100755
index 0000000..37fb53d
--- /dev/null
+++ b/pdk/docs/guide/release_checklist.jd
@@ -0,0 +1,119 @@
+page.title=Release Checklist
+pdk.version=1.0
+doc.type=guide
+@jd:body
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <a name="toc"/>
+ <ul>
+ <li><a href="#prodCertificates">Production Certificates</a></li>
+ <li><a href="#roSecure">ro.secure Property</a></li>
+ <li><a href="#systemImage">System Image and dex files</a></li>
+ <li><a href="#zygote">Zygote</a></li>
+ <li><a href="#memory">Memory</a></li>
+ <li><a href="#resourceLeaks">Resource Links</a></li>
+ </ul>
+ </div>
+</div>
+<p>This page lists some key points you should verify before releasing your Android device. This document assumes that you have made only minor changes, if any, to the basic software platform.</p>
+<h3><a name="prodCertificates" id="prodCertificates"></a>Production Certificates</h3>
+<p>The Android build system generates a system image with <code>.apks</code> signed by its test keys. This is insecure because the keys are made public in Android source code. You should resign all <code>.apks</code>, especially the framework itself, with your own private keys.</p>
+<h3><a name="roSecure" id="roSecure"></a>ro.secure Property</h3>
+<p>Configure production builds with <code>ro.secure</code> set to <code>1</code>. Without securing the device in this manner, someone could access a locked device. </p>
+<h3><a name="systemImage" id="systemImage"></a>System Image and dex files</h3>
+<p>Development builds place basic <code>.apks</code> in <code>/system/app</code>, which means that at first boot, the system must run <code>dexopt</code> on each <code>.apks</code> and generate the corresponding <code>.odex</code> files in <code>/data/dalvik-cache</code>. To avoid long bootups and to save the user's space, create a production image in which the build system does the <code>dexopt</code> at build time and places <code>.odex</code> files next to their corresponding <code>.apks</code> and strips the original <code>.dex</code> from them.</p>
+<h3><a name="zygote" id="systemImage2"></a>Zygote</h3>
+<p>Tune the zygote process if you add your own classes or resources to the core framework libraries and you use those classes and resources in multiple applications. It can be challenging to determine what should and what should not get preloaded, and it's best to choose conservatively. A good candidate for preload might be framework code you add for use when a UI is displayed.</p>
+<p>The zygote process is important for reducing the amount of memory consumed across the entire system. The base Android system is already reasonably configured, and you only need to consider this if you have made significant changes.</p>
+<h3><a name="memory" id="systemImage3"></a>Memory</h3>
+<p>Memory is a key factor for determining optimal performance. A good basic metric to consider is the size and number of processes after first boot. The example below illustrates:</p>
+<ul><li>the contents of <code>/proc/meminfo</code>, which shows the basic memory of the device</li>
+<li>typical output of <code>procrank</code> after first boot on Android 1.5.</li>
+</ul>
+<pre>
+# cat /proc/meminfo
+MemTotal: 98592 kB
+MemFree: 1564 kB
+Buffers: 5688 kB
+Cached: 24468 kB
+SwapCached: 0 kB
+Active: 39768 kB
+Inactive: 43372 kB
+
+# procrank
+ PID Vss Rss Pss Uss cmdline
+ 71 33704K 24488K 12033K 10364K system_server
+<strong> 118 28708K 20516K 8085K 6588K android.process.acore
+ 167 19352K 19352K 7184K 5880K com.google.process.gapps
+ 112 17816K 17816K 6222K 5280K com.android.phone
+ 198 16416K 16416K 5002K 3828K com.google.android.apps.maps:FriendService
+ 174 16060K 16060K 4635K 3776K android.process.media
+ 228 16308K 16308K 4288K 3244K com.android.calendar
+</strong> 48 16212K 16212K 3396K 1788K zygote
+<strong> 212 14964K 14964K 3146K 2004K android.process.im
+ 147 14116K 14116K 2907K 1964K com.android.mms
+ 286 13856K 13856K 2506K 1552K com.google.android.gm
+ 141 13516K 13516K 2425K 1524K com.tmobile.myfaves
+ 261 13664K 13664K 2295K 1400K com.android.alarmclock
+ 273 12976K 12976K 2069K 1168K com.android.music
+ 246 12488K 12488K 1845K 1072K com.google.android.partnersetup
+ 219 12360K 12360K 1808K 1008K com.android.voicedialer
+</strong> 49 1464K 1464K 1021K 996K /system/bin/mediaserver
+ 47 624K 624K 394K 380K /system/bin/rild
+ 301 536K 536K 384K 336K procrank
+ 53 432K 432K 252K 244K /system/bin/akmd
+ 300 316K 316K 187K 140K /system/bin/sh
+ 1 180K 180K 162K 160K /init
+ 54 148K 148K 148K 148K /sbin/adbd
+ 45 244K 244K 110K 104K /system/bin/vold
+ 50 252K 252K 97K 88K /system/bin/dbus-daemon
+ 44 156K 156K 82K 80K /system/bin/servicemanager
+ 51 180K 180K 76K 72K /system/bin/installd
+ 46 144K 144K 63K 60K /system/bin/debuggerd
+</pre>
+<p>This example is for a device with nearly 100MB available to the kernel. There are 14 application processes, highlighted in bold, able to run with 24MB of RAM remaining in cache. </p>
+<p>The per-process overhead of a Java process is 1-1.8MB (the <code>Uss</code> and <code>Pss</code> sections of the smallest process). This is an important number to track because it has a large impact on the number of concurrent processes that can run, and thus on the overall behavior of the system. You should consider the numbers here as a low bar for what a running Android device should look like.</p>
+<p>These numbers may vary depending on your device and are intended to provide ballpark figures. </p>
+<h3><a name="resourceLeaks" id="systemImage4"></a>Resource Leaks</h3>
+<p>Android is designed to run for months without rebooting, and you should check for resource leaks that might damage or harm system performance over that amount of time.</p>
+<p>The two main kinds of leaks you might encounter are memory and file descriptors. </p>
+<p><strong>Memory Leaks</strong></p>
+<p>Focus particular attention on persistent processes like: </p>
+ <ul>
+ <li><code>system_server</code>: holds all of the core system services such as the window manager and activity manager</li>
+ <li><code>android.process.acore</code>: holds the core UI such as home, contacts, and the LatinIME</li>
+ <li><code>com.android.phone</code>: holds the user space telephone code and UI. </li></ul>
+<p>Also pay attention to the lower-level system processes, such as the mediaserver, rild, and the kernel as well as any custom drivers or other modifications you may have made.</p>
+<p>Leaks in these processes are especially serious because these processes can't be restarted without rebooting the phone. In most other processes, leaks are less problematic because the system will naturally kill and restart such processes during normal interaction with the phone, incidentally cleaning out potential leaks.</p>
+<p>The basic approach to looking for leaks is running the device with regular use of all features for a long period of time. You can also use a device in accelerated use, such as under the monkey command, for a shorter period of time. After use, look at the current state of the system to see if there is any unexpected growth in the use of any resource in these processes.</p>
+<p>For memory, the <code>procrank</code> command provides an initial verification. If a process hasn't grown excessively since first boot, it should be fine. Some growth is to be expected due to memory fragmentation. Here is the typical output of <code>procrank</code> after running for a while: </p>
+<pre>
+# procrank
+ PID Vss Rss Pss Uss cmdline
+ 83 44768K 27360K 18071K 16608K system_server
+ 5780 32672K 24480K 14822K 13224K android.process.acore
+ 128 25936K 17744K 8420K 7208K com.android.phone
+ 5787 17004K 17004K 7731K 6284K com.google.process.gapps
+ 205 21356K 13164K 4438K 3376K com.android.inputmethod.latin
+10094 22184K 13992K 4051K 2676K com.android.settings
+10285 13156K 13156K 3714K 2408K android.process.media
+10224 13140K 13140K 3332K 1852K com.google.android.gm
+10310 12444K 12444K 3017K 1516K com.tmobile.myfaves
+ 54 9152K 9152K 1811K 880K zygote
+ 55 1568K 1568K 1268K 1228K /system/bin/mediaserver
+ 53 636K 636K 435K 420K /system/bin/rild
+10329 492K 492K 338K 288K procrank
+ 60 352K 352K 226K 220K /system/bin/akmd
+10328 320K 320K 188K 140K /system/bin/sh
+ 61 200K 200K 188K 188K /sbin/adbd
+ 1 196K 196K 177K 176K /init
+ 51 268K 268K 132K 124K /system/bin/vold
+ 56 216K 216K 105K 100K /system/bin/dbus-daemon
+ 50 164K 164K 83K 80K /system/bin/servicemanager
+ 57 204K 204K 78K 72K /system/bin/installd
+ 59 164K 164K 76K 72K /system/bin/keystore
+ 52 152K 152K 64K 60K /system/bin/debuggerd
+</pre>
+<p><strong>Descriptor Files</strong></p>
+<p>For file descriptors, look at the currently opened file descriptors with <code>adb shell ls -l /proc/<pid>/fd</code>. Your shell must be running as root to execute this—use <code>adb root</code> to restart your system as root. Comparing before and after output will reveal leaks that happened during the test time.</p>
