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.
The Android build system generates a system image with .apks signed by its test keys. This is insecure because the keys are made public in Android source code. You should resign all .apks, especially the framework itself, with your own private keys.
Configure production builds with ro.secure set to 1. Without securing the device in this manner, someone could access a locked device.
Development builds place basic .apks in /system/app, which means that at first boot, the system must run dexopt on each .apks and generate the corresponding .odex files in /data/dalvik-cache. To avoid long bootups and to save the user's space, create a production image in which the build system does the dexopt at build time and places .odex files next to their corresponding .apks and strips the original .dex from them.
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.
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.
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:
/proc/meminfo, which shows the basic memory of the deviceprocrank after first boot on Android 1.5.
# 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
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
48 16212K 16212K 3396K 1788K zygote
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
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
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.
The per-process overhead of a Java process is 1-1.8MB (the Uss and Pss 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.
These numbers may vary depending on your device and are intended to provide ballpark figures.
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.
The two main kinds of leaks you might encounter are memory and file descriptors.
Memory Leaks
Focus particular attention on persistent processes like:
system_server: holds all of the core system services such as the window manager and activity managerandroid.process.acore: holds the core UI such as home, contacts, and the LatinIMEcom.android.phone: holds the user space telephone code and UI. 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.
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.
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.
For memory, the procrank 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 procrank after running for a while:
# 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
Descriptor Files
For file descriptors, look at the currently opened file descriptors with adb shell ls -l /proc/<pid>/fd. Your shell must be running as root to execute this—use adb root to restart your system as root. Comparing before and after output will reveal leaks that happened during the test time.