Android Memory Analysis

Content is no longer maintained and is being kept for reference only!

Introduction

Content is no longer maintained and is being kept for reference only!

Android migration to non-mobile segments

• Following flavors of android has lead this OS migration to non-mobile segments
  • Attractive licensing for investors and corporate
  • Open source
  • Strong eco system
  • Supports for embedded c/c++ components
  • Development and debugging tools

Challenges for non-phone segment

• Balancing cost to performance ratio:
  • Reduction in bills of material is necessary to make an impact on cost.Mainly this cost directly proportional to memory size and power efficiency.
  • Use of DSP and SGX like components will give a gain on performance side
• Boot time: It is very important to reduce boot time for segments like car infotainment,medical personal assistant,car navigation devices etc.
• Native application needs to be run along with android apps.Every non-phone segment has customized application for a segment use case. ex. Car navigation system has native map application should be running through out along with other android apps.

Among all the challenges mentioned above,- Current wiki will focus on cutting down cost on memory through footprint analysis and simple techniques to customize android OS.Wiki will cover

• Boot time memory requirements (eMMC,MMC/SD card, NAND etc.)
• Run time memory requirements (DRAM,DDR3 etc.)
• Android customization for boot time and run time memory

Note: All examples or test mentioned in this document is tested on [prebuilt] binaries of AM37x device.However analysis and customization techniques can be applied to similar architecture

Boot Time Memory

Boot time memory is non volatile-memory which holds good amount of data(like boot loader, kernel images, file system etc)- required to boot android system.There are various boot options for android system. It can boot from on chip NAND or eMMC or SD Card or serial flash or any other memory available on device.

• Following are the components which are part of this memory
  • Boot Loader
  • Kernel
  • File System ( Before Boot + After Boot)
  • Media/Data Files( if available)

Above diagram explains memory footprint of “TI-Android-Gingerbread-2.3.4-DevKit-2.1” release for AM37x device.
“/data” section in the file system will be populated after boot. Android system will

• Create cache history for core framework and applications
• Create database files to be used by applications

With respect to above statistics; one required minimum of ~ 105 MB non-volatile memory to boot the android system.
How one can bring down this figure? - is explained in later section.

Run Time Memory

• This is the memory which is required run time for the execution of application or process or service. Typically RAM plays this role.

• Run time memory requirement solely depends on application use case that is required to execute on android OS. A lot of memory in android is actually shared across multiple processes. So how much memory a process uses is really not clear.

Android Run Time Environment

There are mainly three possible run time environment with respect to android layers
1. Android app -> Runtime Service -> Lib

Android App      : Java Application
Runtime Service 	: Java Service
Lib		: Shared Object

2. Android app -> Runtime Service -> Native Service -> Lib

Android App	: Java Application
Runtime Service 	: Java Service
Native Service 	: C/C++ Executable
Lib		: Shared Object

3. Android app -> Runtime Service -> Native Daemon -> Lib

Android App	: Java Application
Runtime Service 	: Java Service
Native Daemon 	: C/C++ Daemon
Lib		: Shared Object

• For each java application & service, the instance of DVM (Dalvik Virtual Machine) will be loaded into the memory.
• Runtime Service & Native Service will communicate using IPC binder (Android Implementation). Therefore binder library will be loaded into the memory.
• Runtime Service & Native Daemon will communicate using sockets (Kernel Implementation).
• In brief android run time environment mainly categorize into
  • Libraries : Shared Objects
  • Applications : .apk
  • Frameworks : Core libraries & Services
  • Services : Run time android services
  • Daemon : Run time Linux Daemons
  • Utilities : Android Shell, /system/bin, /system/xbin

Memory Anatomy

PSS : Proportional Set Size

Amount of memory shared with other processes, account in a way that the amount is divided evenly between the processes that share it. This is memory that would not be released if the process was terminated, but is indicative of the amount that this process is “contribution” to overall memory load.

USS : Unique Set Size

USS is the set of pages that are unique to a process. This is the amount of memory that would be freed if the application gets terminated.

Heap

Runtime memory available for allocation (Used by applications, services, daemons)

Dalvik Heap

The dalvik heap is preloaded with classes and data by zygote. When zygote forks to start an application, the new application gets a copy-on-write mapping of this heap. As Dan Borstein says below, this helps with memory reduction as well as application startup time. Dalvik, like virtual machines for many other languages, does garbage collection on the heap. There appears to be separate thread (called ‘ HeapWorker’) in each VM process that performs the garbage collection actions.
Dan Borstein note on heap sharing:
(http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html)
“It's used in Android to amortize the RAM footprint of the large amount of effectively-read-only data (technically writable but rarely actually written) associated with common library classes across all active VM processes. 1000+ classes get preloaded by the system at boot time, and each class consumes at least a little heap for itself, including often pointing off to a constellation of other objects. The heap created by the preloading process gets shared copy-on-write with each spawned VM process (but again doesn't in practice get written much). This saves hundreds of kB of dirty unpageable RAM per process and also helps speed up process startup.”

Commands for run time memory usage

• To spit out a bunch of information about the memory use of each JAVA process

$adb shell dumpsys meminfo 

• To see memory for particular process: ( e.g. System)

$adb shell dumpsys meminfo system

• Summary of the overall memory

$adb shell cat /proc/meminfo 

Run Time Memory: Gallery Use Case

Rum time memory usage will depends on kind of use case running on android system. Following are the context where – run time memory will be allocated by android system.

• All java process will run with the instance of DVM. DVM will again have its own run time heap requirement based on java application code complexity.
• Binder IPC will allocate run time memory for marshalling objects
• Service or daemon will allocated run time memory for internal usage
• Following example will show run time heap change with respect to gallery application use case.
  • Size : Total size of particular heap
  • Allocated : Portion of heap is allocated to process
  • Native Usage : Usage by application or service code
  • Dalvik Usage : Usage by Dalvik virtual machine (libdvm)

com.cooliris.media: After android boot



com.cooliris.media: After opening gallery application

• Note that, there is no big change in Dalvik heap but native code heap usage increased by ~2 MB. Further complexity of use case & application code will increase Dalvik heap as well.

Android Framework : Memory FootPrint

• Below table brief about minimum memory requirments for the different core components of android os. Average 65-80 MB of minimum memory required for android to boot with sgx support. After boot android will launch many services and applications, which will add more memory to listed figure. ( Application & Services will start creating instances of dalvik VM & many other objects)

Table 1 : android memory - framework

module#	Description#	Approx size in MB	Remark#
Core Java Libraries	A set of Java libraries used by various components of the Android system	13	Libraries will allocate more space run time to create instances per application bases
Core System Libraries	A set of C/C++ libraries used by various components of the Android system. Includes system c libraries, webcore ( for browser), sgx, bluetooth,SQLlite,freetype and other misc.	27
Surface Flinger	Manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications	5	Surface flinger will allocate buffers for  - Display surface - Launcher - Status bar – normal & expanded This can vary depending on resolution of display system. Figure shown over here is for 640x480 resolution
Dalvik	Vritual machine to run android java applications.	1.5 - 16	Every Android application runs in its own process, with its own instance of the Dalvik virtual machine.16MB is max heap size that dalvik VM will used. This can be configurable.
SGX	This module speed up graphics experience by using h/w accelarated graphics	8 - 40	min 8 MB + use case requirement; This number can go upto 40 MB. Ex. Gallery icon grid view : 4 x 4, each icon is of 100x100 pixel then sgx will allocate : 100x100x2( bytes per pixel) x 4 x4 = 312 KB + background ( 640x480x2)
Cached Memory	Buffer cache.	14-20

Android At Runtime

• Below table briefs about run-time memory utilization by different android processes & applications

Note:  Represent data are taken from RSS (Resident Set Size) field of "ps -a" command. However data collected from various memory tools like DDMS,smem, /proc/meminfo,dumsys are giving similar data what is presented over here. Reason to choose RSS is -one can measure physical pages occupied by process at a moment, which give RAM utilization by running processes. For more details on RSS refer

• • http://linux.about.com/od/commands/l/blcmdl5_proc.htm
  • http://miknight.blogspot.com/2005/11/resident-set-size-in-mac-os-x.html

Table 2: Android at run-time

#	process#	size in MB#RSS	remark#
Android core processes (required for normal boot)	zygote	16
	system_server	34	running 41 diff services, ref # frameworks/base/services/java/com/android/server/SystemServer.java
	com.android.systemui	19	Handles all notification on status bar. This can be removed from android file system if there is no need of any notification handling for the product use case.
	mediaserver	1.5
Other Processes ( which can be killed in low memory scenario)	com.android.launcher	21
	com.android.phone	15
	com.android.bluetooth	16
Gallery/Music	android.process.media	18
	com.cooliris.media	17
	com.android.inputmethod.latin	5

• With respect to memory figures mentioned in table, minimun android boot configuration : android core process (16 +34+19+1.5) + com.android.launcher (21)   - will require around  91.5 MB of memory. Presented figures are with respect to default gingerbread devkit release for AM37xevm.   

Boot Time-Non Volatile Memory Customization

• This question is very specific to kind of use case for android OS. As android OS is migrating to non-mobile segment; the need arise to remove unwanted applications and libraries which makes no sense to usage environment.
  

• Example:

Android for simple hand held HMI device. For normal use case of hand held device – HMI; there is no need of other android applications like phone, contact, sound record etc. Removing these components can save footprint on boot time memory and also run time memory (as number of preloaded class will be decreased)

• To remove contact and phone use case; following associated classes and libraries can be removed.
  Boot Time memory gain: ~8.10 MB.
  
  
• Refer xls sheet available at following location.
  http://processors.wiki.ti.com/index.php/File:Android_Memory_Calculation_v1.0.zip
  This file will help out to calculate memory gain by removing unwanted libraries from android file system (Based on use case requirement). All the components marked with “Y” cannot be removed from the android file system. These are the required core component for android OS or components which are tightly coupled with many modules.

Run Time-Volatile Memory Customization

This section presents various android customized configurations, which can be run on non-phone devices with memory less than 256MB.

Note:  Only sanity test cycle has been validated against following described configurations.  

Customizing Android Product Package

• Step 1: Customize android product package from file#<android-source>/build/target/product/generic.mk. 
  • Actual file reference#http://gitorious.org/rowboat/build/blobs/rowboat-gingerbread/target/product/generic.mk

>> open file: <android-source>/build/target/product/generic.mk
>> Remove all packages which are not required for product use case
>> Following configuration has been choosen for experiment

Note : Choosing Galley(2D)over Gallery3D will save extra space required for thumbnail caching & 3D accelration by SGX

PRODUCT_PACKAGES := \
    Bluetooth \
    CertInstaller \
    DrmProvider \
    Gallery \
    Launcher2 \
    Music \
    Provision \
    Settings \
    SystemUI \
    LatinIME \

• Step 2:  Remove phone support 
  • Actual file reference#http://gitorious.org/rowboat/build/blobs/master/target/product/core.mk

>> open file: <android-source>/build/target/product/core.mk

>> remove following packages ( listed with '-' sign)

 PRODUCT_PACKAGES := \
     libz \
     sqlite-jdbc \
     Browser \
-    Contacts \
     Home \
     HTMLViewer \
-    Phone \
     ApplicationsProvider \
-    ContactsProvider \
     DownloadProvider \
     DownloadProviderUi \
     MediaProvider \
     PicoTts \
     SettingsProvider \
-    TelephonyProvider \
     TtsService \
     VpnServices \
-    UserDictionaryProvider \
     PackageInstaller \
     DefaultContainerService \
     Bugreport

Note : One can also remove Browser if it is not a part of product use case.

• Step 2.1: Remove Services(Optional): Location Manager,Vibrator,Telephony Registry
  
  • Removing above mentioned services will remove support for telephony, location and vibrator.Run-time memory gain will be ~3MB + Performance.
  • Patch Reference#http://processors.wiki.ti.com/index.php/File:0001-removed-telephony-vibratior-location-manager-service.patch

Kindly apply patch to <android-src>/frameworks/base
$patch -p1 < {patch-file}

• Step 2.2: Remove Wallpaper Service( Optional)
  
  • Removing wallpaper service will create black background. No wallpaper can be set as background.Run-time memory gain will be ~2MB+ performance(specifically switching between views).
  • Patch Reference#http://processors.wiki.ti.com/index.php/File:0001-wallpaper-service-dependency-removed.patch

## Remove following lines from file :<android-src>/frameworks/base/services/java/com/android/server/SystemServer.java
-            try {
-                Slog.i(TAG, "Wallpaper Service");
-                wallpaper = new WallpaperManagerService(context);
-                ServiceManager.addService(Context.WALLPAPER_SERVICE, wallpaper);
-            } catch (Throwable e) {
-                Slog.e(TAG, "Failure starting Wallpaper Service", e);
-            }

## Remove wallpaper dependency from launcher application
Kindly apply mentioned patch to <android-src>/packages/apps/Launcher2
$patch -p1 < {patch-file}

• Step 3: Build customized product configuration.Follow the step given at #http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3-DevKit-1.0_UserGuide#Building_Android_Sources
• Step 4: Flash newly build file system and boot the target

Configuration1 : 144 MB run-time memory

• Customized package created with steps mentioned at section:"Customizing Android Product Package excluding step 2.1 & 2.2"
• Display Configuration is : 640x480-16 bpp(bits per pixel) 
• Boot arguments

setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=144M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=dhcp omap_vout.vid1_static_vrfb_alloc=y vram="2M" omapfb.vram=0:2M‘

• Observations:
  • Normal boot
  • Gallery, Music, Bluetooth, Wifi, Browser, Settings - operations are normal as expected

Configuration2 : 128 MB run-time memory

• Customized package created with steps mentioned at section:"Customizing Android Product Package excluding step 2.1 & 2.2"
• Display Configuration is : 640x480-16 bpp(bits per pixel) 
• Boot arguments

setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=128M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=dhcp omap_vout.vid1_static_vrfb_alloc=y vram="2M" omapfb.vram=0:2M‘

• Observations:
  • Normal boot
  • Gallery, Music, Wifi, Browser, Settings - operations are normal as expected
  • Bluetooth connectivity is fine
  • However sometime file transfer over bluetooth suffers from "low memory" and service gets killed.

Configuration3 : 128 MB run-time memory

• Customized package created by removing SystemUI( no statusbar) & LatinIME (no virtual keyboard support)
• Display Configuration is : 640x480-16 bpp(bits per pixel) 
• Boot arguments

setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=128M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=dhcp omap_vout.vid1_static_vrfb_alloc=y vram="2M" omapfb.vram=0:2M‘

• Observations:
  • Normal boot
  • Gallery, Music, Wifi, Browser, Settings - operations are normal as expected
  • No virtual keyboard, one has to have external keyboard to enter text.
  • Sending a file over bluetooth works fine.
  • Receiving a file over bluetooth can not be tested as notification comes over status bar; which is not a part of this package

Configuration4 : 128 MB run-time memory, No SGX

• Customized package created with steps mentioned at section:"Customizing Android Product Package"
• To build android source without sgx; Kindly refer link# http://processors.wiki.ti.com/index.php/Building_TI_Android_DevKit_Filesystem_without_SGX
• Display Configuration is : 640x480-16 bpp(bits per pixel) 
• Boot arguments

setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=128M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=dhcp omap_vout.vid1_static_vrfb_alloc=y‘

• Observations:
  • Normal boot
  • Gallery, Music, Wifi, Browser,Bluetooth, Settings - operations are normal as expected
  • Graphics experience is poor compared to SGX powered graphics.
  • If step 2.1 & 2.2 gets included in customized build, then system can run with 114MB memory without sgx

Summary Note

After considering memory analysis for android system; minimal memory requirement to run basic android features (standard android source form Google Inc.) are mentioned below.

• Boot time memory : 128 MB
• Run time memory : 256 MB

Reducing run time memory further lead android system to kill unwanted/background activities and processes very frequently, which impact user experience for which android is known for.

Disclaimer:
Memory numbers mentioned above are with respect to standard android distribution from Google Inc. with all basic features working smoothly. However one can always remove unwanted libs, applications, services etc. and make custom android, which can run on lower memory than specified in this document.

References

http://www.elinux.org/Android_Memory_Usage
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_tii/TI_Android_DevKit/TI_Android_GingerBread_2_3_DevKit_1_0/index_FDS.html
http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android/2299813#2299813
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
http://www.intellectsoft.co.uk/