Android Memory Analysis

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search
Translate this page to   

Contents

Introduction

Android migration to non-mobile segments

Challenges for non-phone segment


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

NoteNote: 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.

Android-memory-footprint.png
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

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

Android Run Time Environment

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

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

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

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-layerinteraction-3.png 

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

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

$adb shell dumpsys meminfo 

$adb shell dumpsys meminfo system

$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.


com.cooliris.media: After android boot

Galleyapp-meminfo-boot.png

com.cooliris.media: After opening gallery application

Galleyapp-meminfo-launch.png

Android Framework : Memory FootPrint


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

NoteNote:  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


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


Boot Time-Non Volatile Memory Customization

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)

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.

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

Customizing Android Product Package 

>> 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 \


>> 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.
Kindly apply patch to <android-src>/frameworks/base
$patch -p1 < {patch-file}

## 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}

Configuration1 : 144 MB run-time memory 

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‘

Configuration2 : 128 MB run-time memory 

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‘

Configuration3 : 128 MB run-time memory 

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‘

Configuration4 : 128 MB run-time memory, No SGX 

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‘

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.

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

E2e.jpg For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Android Memory Analysis here.
Hyperlink blue.png Links
ARM Microcontroller MCU ARM Processor Digital Media Processor Digital Signal Processing Microcontroller MCU Multi Core Processor
Ultra Low Power DSP 8 bit Microcontroller MCU 16 bit Microcontroller MCU 32 bit Microcontroller MCU

Retrieved from "http://processors.wiki.ti.com/index.php/Android_Memory_Analysis"
Leave a Comment
Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox