Minimizing Boot Time of Android Based Devices · Chapter 2 Approaches to Minimize Boot Time There...

Minimizing Boot Time of Android BasedDevices

Dissertation

Submitted in partial fulfillment of the requirements

for the degree of

Master of Technology

by

Nimit D. Kalaria

Roll No: 10305904

under the guidance of

Prof. D. B. Phatak

Department of Computer Science and Engineering

Indian Institute of Technology, Bombay

Mumbai

Contents

1 Introduction 1

2 Approaches to Minimize Boot Time 3

2.1 Hibernation Based Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Boot Sequence Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Android System 4

3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Boot Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Init Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2 Zygote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 System Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Package Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Activity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Experiment/Implementation 17

4.1 Modifying Zygote preloading . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Changing Init.rc Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 Activity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Package Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 All In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Future Work 28

6 Conclusion 29

A Android Programming 31

A.1 Reading AndroidManifest.xml from ‘apk’ File . . . . . . . . . . . . . . . . 31

A.2 Parsing Extracted AndroidManifest.xml . . . . . . . . . . . . . . . . . . . 34

A.3 Starting Delayed Applications . . . . . . . . . . . . . . . . . . . . . . . . . 35

i

Abstract

Smart devices are becoming popular day by day due to its different features. This

affects the boot time of the device, which should be minimal. Smart devices like phones,

tablets, etc., are used by different people of different fields like industries, entertainment,

students, etc where devices should boot quickly. Thus, it is necessary to minimize the

boot time of smart devices. Boot time of the device can be minimized either by using a

better hardware, or by optimizing the device boot sequence. Optimizing boot sequence is

better than using costly hardware. In boot sequence, we need to identify time consuming

areas where time can be saved by avoiding or modifying component. In Android, Zygote

class preloading, Activity Manager and Package Manager are time consuming components

of Android boot sequence. Boot time can be reduced by modifying these components.

Chapter 1

Introduction

Usage of smart devices is rapidly growing because of its different features. As number

of features are increasing, the initialization time of software modules is also increasing.

Different hardware(i.e cameras, Bluetooth, and WiFi, etc.) have their own long initializa-

tion time. This leads to increase in boot time of devices. To fulfill user demand for faster

and reliable services, quick boot of time is necessary. Android, an Open Source project

launched by Google in September 2008 has become a popular platform for mobile phones

and other embedded devices. Android system architecture comprises of modified Linux

kernel, middle-ware library, application framework and applications.

Quick boot up is important for good end-user performance. Android stack is packed

with different functions which initialize after the device is switched on; This results into

long boot time of the device. To minimize the boot up time, modify the list of component

which are initialized during boot time. This has some other disadvantages(like, increase in

memory usage) but are not essential for performance. Various changes in the system can

improve boot time of device. For example, file system of storage will also be responsible

for boot up time, as bunch of data are read from storage. Reading kernel in compression

and decompression mode also affects boot time. If device processor is slow, then device

takes longer time to decompress, if it is in compression mode. It will take less time if it is

in uncompress mode. Android userspace consumes more time in boot sequence. The next

section discusses the time consumed by userspace module. Android userspace module

contains parsing of “init.rc”script, starting up Zygote, package scanning and initializing

core services.

When android OS is started it will start Zygote process and preloads classes to create

a shared memory area for applications. Android developers have generated a default class

preloading list with the aim of reducing overall memory usage of the system and appli-

cation startup time, but they have not considered the effects of class preloading time on

overall boot time[13]. Thus, this way memory usage is decreased on the cost of high boot

1

time. Changes in Zygote class preloading, can also reduce the boot time. But, changes

in the number of prelaoded classes, results into increase in memory usage which is dis-

advantage of minimizing boot time. Experimental section shows the amount of memory

increase while reducing boot time. Changes in “init.rc”file can also reduce the boot time.

Therafter, avoiding package scanning and delaying startup of few process results into less

boot time. In this stage, we will focus on Zygote preloading and “init.rc”script.

Package Manager will scan the packages of installed applications. Scanning is needed

to check required permissions for application to run. It will also check application version

compatibility by checkingAndroidManifest.xml file. But doing this on every boot is time

consuming which can be reduced by modifying the package scanning method. On every

boot, Activity Manager will start different system applications and vendor applications

which should be started after boot is finished. Starting of all these applications which

may not be used by user after boot is time consuming part, delaying starting of all these

processes can help to reduce boot time. Section 3.4 and 3.5 contain more information

about Package Manager and Activity Manager.

In chapter 2, we will see two different approaches to minimize boot time of Android

devices. Chapter 3 will talk about Android system architecture and boot up process of

Android devices, Zygote startup, package scanning by Package Manager and starting of

different application by Activity Manager. Chapter 4 comprises of experiment and im-

plementation. Chapter 5 and chapter 6 contains future work and conclusion respectively.

2

Chapter 2

Approaches to Minimize Boot Time

There are different techniques to minimize android boot up time.

2.1 Hibernation Based Boot

This approach[1], takes snapshot of memory image of a fully booted Android device and

compress snapshot image. Now, when users start their devices, the device loads the kernel

and it will loads compressed snapshot image from memory and uncompress snapshot

image, kernel will also restore system state. If device contains faster hardware then this

is best way to boot from compressed snapshot image. Because of faster hardware reading

of compressed snapshot image is faster and its decompression is also faster. The main

disadvantage of this approach is, to maintain the latest snapshot image. Consider that

user installs some application which needs to be stared at the boot time using the with

old snapshot image, the application will not get start at boot time. Thus, the snapshot

needs to be recreated whenever an application is installed on the tablet.

2.2 Boot Sequence Optimization

In this approach[13], optimize every component responsible for boot sequence. For ex-

ample, boot-loader, kernel, Zygote class preloading, Package Manager, Activity Manager

etc. Understand these all component, their execution flow and modify them. In this

approach there is not any common algorithm or method to modify these component.

All component have different modification compare to others. Apart from this compo-

nent, modifying init.rc script of android device will also optimize boot time. Explanation

about modification is given in the next chapter. The disadvantage of this approach is

the increase in memory usage while avoiding Zygote preloading. Since not availability

of Android source code for AAKASH tablet all experiment are done on emulator. And

modification of boot-loader and kernel is not possible in emulator.

3

Chapter 3

Android System

Android is an Open Source mobile device Operating System developed by Google, based

on the Linux 2.6 kernel.[11] Since, Linux kernel has different driver model, memory and

process management, network support, and other core services, it is easy to develop new

OS for android devices.

3.1 Architecture

Android OS is a stack consisting of different modules, “Linux-kernel”, “Middleware layer(mainly

library)”, “Application frame work”, and “Applications”. All these layers are written in

different languages. Android is using 2.6 Linux kernel witten in ‘C’language. The Linux

kernel was chosen due to its proven driver model, existing drivers, memory and pro-

cess management, networking support along with other core operating system services.

In addition to the Linux kernel, various libraries were added to the platform, in order

to support higher functionality[11]. The kernel enhancement of Android include, alarm

driver, ashmem (Android Shared Memory Driver), binder driver(Inter-Process Communi-

cation Interface), power management, low memory killer, kernel debugger, and logger[11].

Middleware layer is mainly a library layer which contains different libraries witten in

C and C++. Android has created their own C library called Bionic. Application-frame

layer framwork is written using C++ and JAVA. The application framework was created

to provide the system libraries in a concise manner to the end-user applications[11]. Ap-

plication later is a third party software layer, where all applications are witten using JAVA.

The main part of the Android is Java Runtime Engine(JRE), i.e. Dalvik Virtual

Machine(DVM). DVM is used to optimize limited resources available on a mobile platform.

Applications written in JAVA are presented as byte code. This byte code uses more

mermory footprint to execute the application. Android converts byte code to dex file

format i.e. Dalvik executable format. This takes less memory footprint to execute the

4

application. Apart from this, each application execute in its own DVM, so, if any one

application crashes then, it will not affect the other running applications. DVM for every

application is created by Zygote, library will be shared among the applications.

Figure 3.1: Android System Architecture[11]

5

3.2 Boot Process

Booting in an Android device is time consuming process. Since more functions will be

added, it will take more time to boot. Android boot sequence is similar to Linux boot

sequence. The only difference is in the initialization of user-space applications. Figure

3.2 shows Android boot sequence. The Android boot sequence[12][5] is explained below.

Init

Daemon

(1)

usbd, adbddebuggerd

rild

Zygote

(2)

Runtime

(3)

ServiceManager

(4)

Dalvik VM

SystemServer

ActivityManager Package

Manager

PowerManager

WindowManager . . . . .

Figure 3.2: Android Boot up process.

• When the device switches on, boot ROM code is executed, which is placed at a fixed

location. This boot ROM code will load the first stage of the boot loader into the

internal RAM.

• This first stage boot-loader will set up an external RAM and will then load the

second stage boot-loader. Second stage will set up file system, low level memory

protection, and network support.

• Once the second stage execution is completed, it will look for Linux kernel and

thereafter load it in to the RAM. Linux kernel will initialize memory management

and caches. It will look into the root file system for init process and will then launch

it.

• “Init”is the first user space process to execute with PID(Process ID) as 1. Init is

placed at root node in the process tree. Every other process of the system will be

launched by init process.

• Init process parse the init.rc script and launch the system services. This script

describes information about the file system, different system services, and other

parameters that need to be set up during the boot process.

6

• Init will start some daemon processes which are needed to start system. It will also

start “usbd”,“adbd”, “debuggerd”, and“rild daemon”.

• The first process to launch by init, is Zygote, which will execute and initialize the

Dalvik VM.

• Thereafter, init will start runtime service and Service Manger. Service Manager is

the context manager for Binder that handles service registration[11].

• Thereafter, that runtime service will invoke Zygote to start System Server. Zygote

will create copy of its DVM and will load System Server code into that.

• First process or application created by Zygote is System Server application. System

Server process is responsible for starting or creating necessary Android services. It

will also start Package Manager which will scan different packages.

• Activity Manager will then start start applications like, phone application(com.android.phone),

home, and few core applications.

After completing these steps, the device will display home screen. This takes normally

40-43 seconds on ARMv7 based emulator. Table 3.1 shows boot process time distribution.

Output is collected by “adb logcat -d -b events”commands. As referred in Table 3.1, pms

stand for Package Manger Service and ams is Activity Manger Service. The time given in

table is relative time with respect to SystemClock which starts with zero on starting of

system. Third column is time difference between two consecutive progress output. To get

graphical output of boot process bootchart [10] tool is used. Figure 3.3 shows bootchart

output of boot up process.

Boot Progress Output Time(sec) Time Difference(sec)

I/boot progress start 3.489 3.489I/boot progress preload start(Zygote) 4.872 1.383

I/boot progress preload end 21.163 16.291I/boot progress system run(System Server) 21.669 0.536

I/boot progress pms start(Package Manager Service) 22.037 0.338I/boot progress pms system scan start 22.494 0.457I/boot progress pms data scan start 24.776 2.282

I/boot progress pms scan end 24.794 0.018I/boot progress pms ready 24.946 0.152

I/boot progress ams ready(Activity Manager Service) 27.277 2.331I/boot progress enable screen 40.870 13.593

Total Boot Time 40.870

Table 3.1: Logcat output of Android boot progress.

As shown in Figure 3.3, kernel initialization indicated by black line “No. 1”takes ap-

prox 3 seconds time. Zygote initialization indicated by black line “No. 2”takes approx 16

7

Figure 3.3: Bootchart of unoptimized Android Boot up.

seconds out of which 7.7 seconds are for preloading 2297 classes and 8.4 seconds are for

preloading 379 resources. Table 3.2 displays this output. Thereafter, Packager Manager

scans packages, which takes around 2 seconds to scan packages. Activity Manager takes

13 seconds to start different applications. Thereafter, home screen is displayed after some

delay. Thus, optimization is needed at different phases of the boot sequence process.

Optimization is done for init.rc script and Zygote preloading classes, package scanning by

Package Manager and starting of different applications by Activity Manager.

Tag Time(sec)

I/Zygote ( 37): ...preloaded 2297 classes 7.785

I/Zygote ( 37): ...preloaded 379 resources 8.404

Table 3.2: Logcat output of preloading classes and resources

3.2.1 Init Script

Init process parses “init.rc”and “init.<machine name>.rc”and starts other processes listed

in these files. “Init.rc”file contains many processes out of which fews can be avoided dur-

ing boot. For example, starting of bluetooth, wifi services can be avoided. Init will start

boot animation which is CPU consuming process and can be avoided during boot and

other processes can use that amount of CPU for initialization. In experiment section, it

is shown that avoiding only boot up animation will save around 6 seconds of time.

3.2.2 Zygote

Zygote[7] is the first process started by the init process. All applications and services start

only through Zygote. Before starting an application, it shares running DVM code and

8

memory information, for reducing application starting time. When does Zygote starts,

the first task by Zygote, is to register a socket to listen fork request for new application

which will sent by Activity Manager. Zygote will then preload the commonly used classes

by different application during Zygote’s start up. It preinitializes and preloads common

Android classes in its heap, which increases the boot time. The reason behind this, is to

share memory between different processes which is forked by Zygote. Reduced memory

usage caused by this class memory sharing, is a bonus for embedded systems that have

limited memory capacity[13]. Thus, Android will save memory by preinitializing large

number of classes during boot up. One can avoid the preloading of classes which will save

boot up time, but will increase memory usage of the process. Preloading of classes can

be avoided or reduced if the memory usage is not improtant.

Once class preloading is done, Zygote will create new DVM for System Server process.

It will then load System Server process code into newly created DVM. Thereafter, Zygote

will go in loop mode to listen to the socket for creating new application request. Whenever

a request is received, it will fork the process and generate new process. Zygote will

share memory code and library with this newly created process. Thereafter, it will load

requested application code into Dalvik VM dynamically[3]. Once this is done, Zygote will

pass process control to the requested application.

3.3 System Server

Once Zygote is completely started, it will create a new instance of Dalvik-VM for start-

ing System Server process. System Server is the main process of Android, which will

initialize core services for Android. First services initialized by System Server is Surface

Flinger and Audio Flinger. After this, System Server starts different services for Android.

These includes starting of Activity Manager, Package Manager, Window Manager, Ac-

count Manager, Content Manager, Init Watchdog, Bluetooth services, Status Bar service,

Notification Manager, Backup service, Mount service, etc.

As shown in Table 3.1, the time consuming part of the System Server is the package

scanning by Package Manager and Activity Manager. Package Manager takes time to scan

system and data. The time to scan packages is around 2.2 seconds. These are the packages

are installed in the devices. If we install more packages more time will be spent in package

scanning. Optimizing package scanning to save time is seen in the next section. Activity

Manager takes time to start the processes which should have started after completion of

boot. Activity Manager will start few of the system applications and third party (vendor)

applications. Time spent to start this applications is around 13 seconds which is large

boot time. Activity Manager section discusses the process that it starts.

9

3.4 Package Manager

Package Manager is a core service which scans the package during boot time. Package

of any application is installed in /system/framework, /system/app, and /data/app di-

rectory depending on the type of packages. /system/app contains system application

packages, while /system/data contains vendor application packages. Package Manager

scans all these packages present in these directories on every boot. Table 3.3 is shows

the time spent for collecting packages which is around 2.28 seconds. Similar to Table 3.1,

table 3.3 shows relative time with respect to SystemClock. Third column have only one

entry which is time difference between pms data scan start and pms system scan start.

Progress Output Time(sec) Time Difference(sec)

start 3.489preload start(Zygote) 4.872

preload end 21.163system run(System Server) 21.669

pms start(Package Manager Service) 22.037pms system scan start 22.494pms data scan start 24.776 2.282

pms scan end 24.794pms ready 24.946

ams ready(Activity Manager Service) 27.277enable screen 40.870


Package Manager[2] reads a AndroidManifest.xml file from .apk package. Pack-

age Manager will read this file for checking permissions, creating list of services, ac-

tivity, and receiver. It also does signature verification. Now, the problem is that to get

AndroidManifest.xml file Package Manager will read whole .apk file from memory which

will cause more memory access as compared to accessing only AndroidManifest.xml file.

Figure 3.4 is showing the flow of method call while scanning the packages.

scanDirLI function will scan directory for the list of packages. Then, for each pack-

age it will call scanPackageLI function which will call parsePackage function to parse

the package. Then, this function will call openXmlResourceParser function which will

getXmlBlock object from openXmlBlockAsset function, and then parse thatXmlBlock

intoXmlResourceParser object and pass it to parsePackage function. openXmlBlockAsset

function will get XmlBlock object from openXmlAssetNative function. From this point

onwards call goes to C++ library which will access .apk file from memory.

Now, instead of accessing .apk file for reading AndroidManifest.xml file, it is good to

directly read AndroidManifest.xml file and create XmlBlock object and will return it to

openXmlResourceParser function. This modified approach is shown in figure 3.5. When

call goes to openXmlResourceParser it will check whether AndroidManifest.xml file

10

Figure 3.4: Flow of package scanning by Package Manager.

for given package is present or not. If it is present, read that file and create XmlBlock

object, parse it, and return it to parsePackage function. If file does not exits then

continue to call openXmlBlockAsset function. By doing this, reading of whole .apk file

is avoided. Experiment section contains results for saving time by doing this approach.

To get AndroidManifest.xml file from .apk file[6], an application with RECEIVE

BOOT COMPLETED permission was developed. So that, on each boot this application

gets called and will check /system/framework, /system/app and /data/app directories

for packages. It will then read .apk file and get AndroidManifest.xml file and write it

to /data/xml/ < dir > / < packagename > file. Here, < dir > represents anyone of the

three directory and < packagename > represent name of package. So, whenever user will

install new application, AndroidManifest.xml file for those packages will also write into

corresponding directory.

11

Figure 3.5: Modified flow of package scanning by Package Manager.

3.5 Activity Manager

Activity Manager is a base/core service which is running inside System Server as a thread.

Task of the Activity Manager is to manage life-cycles of process activity. New process

creation is go through Activity Manager service. Whenever new process creation request

is sent, it will go to Activity Manager and then it will call Process.start function, which

will then call Zygote to create a new instance of Dalvik-VM. [8] has explained step of

service creation and how does Activity Manager will start the services. Table 3.3 shows

list of the processes which are started during the boot time. Table 3.3 contains two rows.

One is for required processes which is critical application for Android system and second

row contain processes whose execution/startup can be delayed. Process distribution is

done based on who is starting process and at what time. We will see how does Activity

Manager starts the process.

System Server will call main function of ActivityManagerService class. This function

will create a thread whose name is given as ActivityManager. This thread will initialize ob-

12

Required System com.android.systemui, com.android.phone,Applications com.android.launcher, android.process.acore,

com.android.inputmethod.latin

System application com.android.setting, com.android.smspush,that can com.android.deskclock, com.android.contacts,be delayed com.android.exchange, com.android.email,

com.android.providers.calendar, com.android.calendar,com.android.email, com.android.voicedialer,

com.android.media, com.android.mms

Table 3.4: Different processes get started by Activity Manager during boot

ject of ActivityManagerService and will go into loop. Then, System Server will create a

thread for Package Manager and after that it will call setSystemProcess function of Activ-

ityManagerService class. This function will add object of ActivityManagerService class

created by ActivityManager thread as activity service, cpu-info service, memory-info ser-

vice, and permission controller service. After this, System Server will start other services.

Once all the services are started System Server will tell Activity Manger to start third

party code. For this, System Server will call systemReady function ofAcivityManagerService

class. From this point onwards system applications will get started by Activity Manager.

The process that is required during boot is selected based on who is starting that process.

Now we will see how do all processes start during boot time.

The first process that is starts by System Server is SystemUI process. It provides

the framework on top of which you build your app. Important aspects include the

Home screen experience, global device navigation, and notifications[4]. System Server

will call startService function of AcivityManagerService class. Since required pro-

cess is not, running Activity Manager will call bringUpServiceLocked function which

will check whether process is running or not. If process is not running it will call

startProcessLocked function. This is the function which will actually start a process.

Now com.android.systemui process is started. This process will use remote procedure

call(RPC) to bindService function of AcivityManagerService class. This will go to

bringUpServiceLocked which will check whether process is running or not. Since process

is executing it will check whether service is running or not. If required service is not

running, then call goes to realStartServiceLocked function which will start the service.

Now com.android.systemui process is completely running with its service.

Next process get started by System Server is inputmethod.latin. It is process which

will provide interface for user input such as on-screen keyboard. This process started by

sending Intent to Activity Manager. An Intent is basically a message to say that process

want something to happen. Remote procedure call(RPC) will go to bindService function

with Intent message for starting com.android.inputmethod.latin process. bindService

function will call bringUpServiceLocked function. Since the process is not running

13

this function will call startProcessLocked function which will start the process. Once

process gets started it will call remote procedure call to attachApplication function of

AcivityManagerService class. This function is to attach a service to the process. If

service is not running, then it will call realStartServiceLocked function to start service.

com.android.phone process starts during execution of systemReady function. This

function will call startProcessLocked function to start the process. After that process

will use RPC same as inputmethod.latin process to start service. After starting of phone

process systemReady function will use RPC to resumeTopActivityThread function of

ActivityStack class. Which will call startSpecificActivityLocked function and this func-

tion call will start com.android.launch process. To start this process again from Aciv-

ityStack remote procedure call happen to startProcessLocked function. After launch

process will do RPC to attachApplication to start service.

Process android.process.acore is started by receiving Intentmessage by Activity Man-

ager. This Intent will be handled by handleMessage function of AcivityManagerService

class. This function will call processNextBroadcast function to process next broadcast

message from message queue. Since the process is not started, call goes to startProcessLocked

function which will create a new process. So these the five required processes which is

get started during boot. Apart from this there are other processes which also get started

during the boot time. Like, com.android.setting process is get started by System Server

which will broadcast Intent message for starting process. This message will get handled

by handleMessage function which will call processNextBroadcast function to process the

next broadcast message. processNextBroadcast function will call startProcessLocked

function to start process. Similarly, phone application will do remote procedure call to

bringUpServiceLocked function to start com.android.smspush process.

Boot Progress Output Time(sec) Time Difference(sec)

start 3.489preload start(Zygote) 4.872

preload end 21.163system run(System Server) 21.669

pms start(Package Manager Service) 22.037pms system scan start 22.494pms data scan start 24.776

pms scan end 24.794pms ready 24.946

ams ready(Activity Manager Service) 27.277enable screen 40.870 13.593


After this, System Server will broadcast Intent with android.intent.action.T IME SET

action. This will start the com.android.calendar, com.android.deskclock and com.android.

14

contacts application. When booting process is finished, Intent with BOOT COMPLETED

action will get broadcast and it will start all applications which have RECEIVE BOOT

COMPLETED permission. This Intent message will start the remaining applications. If

your application does not have this permission then your application will not start after

boot.

Intent

handleMessage()

processNextBroadcast()

startProcessLocked()

Process.start()

finishBooting()

enableScreenAfterBoot()

Figure 3.6: Flow of starting application during boot.

All these processes start after ActivityManagerService is ready. In Table 3.4 we can

see that the time difference between ams ready and enable screen is around 13.5 seconds.

This time is spent for starting services, required system applications and other third party

applications. We can reduce this difference by delaying starting of applications. The

common flow of starting system applications is given in figure 3.4. Intent messages will

get handled by handleMessage function. This function will call processNextBroadcast

function which will call startProcessLocked function to start process if required. When

booting is completed, Activity Manager will call finishBooting function and after that

it will call enableScreenAfterBoot function.

Now, our approach is to delay the starting of the applications which are not required

during the boot and start all these applications after enable screen. For that, we have

modified startProcessLocked function so that whenever request come to start an appli-

cation we check it whether it is in list of required applications. If yes, then start the

application, else add process information in pending list and application will not get

started return from startProcessLocked function. enableScreenAfterBoot function will

inform Window Manager about boot completion. After this, we can start applications

which are in pending list. By doing this we are able to save around 4 seconds of boot

15

Intent

handleMessage()

processNextBroadcast()

startProcessLocked()

Process.start()

finishBooting()

enableScreenAfterBoot()

applicationIs

requiredYes

Return

No

Add AppInformation

intopending list

Return

Call startProcessLocked()to start remaining

process

Figure 3.7: Modified flow of starting application during boot.

time. More results are given in experiment section.

16

Chapter 4

Experiment/Implementation

The experiment uses an emulator which is based on Android 4.0.4 which is emulated on

512MB RAM and AMR cortex-a8 processor. While conducting experiment bootchart

was not executing, as it affects the boot time[10]. For doing this experiment, help is

taken from [14][16][15]. Experiment was conducted by changing the number of preloaded

classes in Zygote process. By default, Zygote will preload 2297 classes in Android 4.0.4.

Experiment is conducted for 0, 263, 515, 969 and 2297(default) classes. The choice of

classes for preloading purpose was explained earlier. Other experiment is conducted by

modifying Package Manager and Activity Manager. Results of last section of experiment

is taken by putting all changes together.

Memory utilization is monitored while reducing the number of preloaded classes.

Since, less number of classes are preloaded, sharing will be less between different pro-

cesses. Thus, individual memory utilization will increase. For monitoring memory usage

“procrank”command is used. This gives total memory usage and also memory usage of

individual processes.

Procrank command gives information about Pss(Proportional set size) and Uss(Unique

set size) for all running processes. Uss is a set of pages that are unique to a process. It

is the amount of memory that would be freed if the application was terminated[9]. Pss is

the amount of memory shared equally among all processes, accounted in a way, that the

amount is divided evenly between the processes that it shares. This is the memory that

would not be released, if the process was terminated, but is indicative of the amount, that

this process is “contributing”[9].

4.1 Modifying Zygote preloading

This experiment is taken by changing the number of classes preloaded by Zygote process

which is loaded at boot time. While this taking results preloading of 379 resources is

17

fully avoided which is saving around 8.4 seconds. By default, preloading time is around

7.7 seconds which has reduced to 0.3 seconds by reducing the number of classes that

are preloaded. Table 4.1,4.2,4.3 and 4.4 show preloading time for different classes. It is

observed that, by reducing the number of classes to be preloaded, the preloading time

reduces. Each talbe have five column. First column(C1) represent the boot progress tag.

Second column(C2) represent relative time of unoptimized android. Third column(C3)

represent time difference of consecutive row value of column C2. Fourth column(C4)

represent relative time of optimized android which have some modification accroding to

table. Fifth column(C5) represent time difference of consecutive row value of column C4.

Boot Progress Output Time(sec) Time Difference Time(sec) Time Differencefor C2(sec) for C4(sec)

C1 C2 C3 C4 C5

boot progress start 3.489 3.489 3.258 3.258preload start 4.872 1.383 4.646 1.388preload end 21.163 16.291 4.774 0.128system run 21.669 0.536 5.219 0.445pms start 22.037 0.338 5.764 0.545

pms system scan start 22.494 0.457 6.215 0.451pms data scan start 24.776 2.282 8.362 2.147

pms scan end 24.794 0.018 8.363 0.001pms ready 24.946 0.152 8.523 0.160ams ready 27.277 2.331 11.399 2.876

enable screen 40.870 13.593 24.702 13.303

Total Boot Time 40.870 24.702

Total Boot Time Saved 16.168

Table 4.1: Boot progress for prelading 0 classes.

As shown in table 4.2 preloading time of 263 classes is 0.376 seconds, which is 3 times

of preloading time of 0 class. Still boot time of 268 classes is less than the boot time of

0 class. The reason is that, while preloading 263 classes most of the classes are already

in memory. Thus, starting process does not need to fetch all classes. Thus, achieving less

boot time. Also note that, while preloading 0 classes, process needs to fetch most of the

classes from storage to memory, which in turn increases overall boot time. Thus, boot

time of preloading 0 classes is slightly more than boot time of preloading 263 classes.

Tables 4.1, 4.2, 4.3 and 4.4 shows the amount of boot time saved by changing Zygote

preloading. The boot time saved is different between default boot time(given in second

column) and achieved boot time(given in fourth column). In this, preloading 263 classes

will save more than others. It is saving around 16.492 seconds boot time by preloading

263 classes and 0 resources. Now, the increase in memory usage should be monitored for

18


C1 C2 C3 C4 C5




enable screen 40.870 13.593 24.378 13.081



Table 4.2: Boot progress for preloading 263 classes.

saving this boot time. For this, we have collected total memory usage, total PSS and

USS usage. Table 4.5 displays the total memory usage, total PSS, and USS usage, while

preloading different classes.

The memory usage data is collected after the device displays home screen and contains

only default process that are started during boot up process. We can observe that memory

usage is increasing while preloading less number of classes, but when preloading 969 and

515 number of classes, memory usage is less than the default memory usage. The reason

is, that preloading of other classes are avoided which are not used by process, started

during boot up time. Thus, it decreases memory usage while preloading 969 and 515

classes. When we are preloading 263 classes, memory usage is increased, as this class list

does not contain most of the classes which are used by process started during boot up

time. From Table 4.5 we can see that, memory usage for preloading 0 classes is increased

by around 11 MB and where as memory usage for preloading 263 classes is increased by

around 7.93 MB. Thus, if we combine Table 4.1, 4.2 and 4.5 then it can be observed, that

it is good to preload 263 classes which is better in terms of boot up time and memory

usage while comparing with preloading 0 classes.

Now, lets observe that the utilization of memory is changed to normal process, while

changing the number of preloading classes. For this, we have collected memory usage of

Browser and Calculator. Table 4.6 displays results of the memory used for Browser and

Calculator. Memory usage is collected in terms of PSS and USS of individual process. It is

observed that PSS usage of both the processes decreases as the number of preloaded classes

19


C1 C2 C3 C4 C5




enable screen 40.870 13.593 24.684 13.122




decrease. On the other hand, USS usage of both process is increasing, as the number of

preloaded classes is decrease. The reason for this is that as we are reducing the number of

preloaded classes, the sharing of classes reduces, This decrease PSS(Proportional set size)

and the unshared classes are loaded by individual process which will increase USS(Unique

set size) of processes.

While preloading 263 classes, USS memory usage for Browser is increased by 3.63 MB,

and for Calculator is increased by 0.3 MB. While preloading 0 classes, USS memory usage

for Browser is increased by 4.17 MB, and for Calculator is increased by 0.73 MB. Thus, it

is observed that,when we are changing the number of preloaded classes, memory usage of

individual process is not increased by a great extent. Good result is given by preloading

263 classes as compared to preloading 0 classes. Thus, changes made in Zygote class

preloading is saving approximately 40% of boot time with cost of 4% increase in memory

usage.

4.2 Changing Init.rc Script

Apart from avoiding Zygote class preloading, we can also reduce time by making changes

in init.rc file, which is executed by init file during boot up. Initial changes are made in this

script to avoiding boot up animation. Boot up animation in android takes approximately

around 6 seconds of time. Animation process is consuming CPU for displaying animation.

This CPU usage can be used for other process to initialize. Avoiding boot up animation

will not affect any memory usage thus we can avoid it and reduce the boot time. Table

20


C1 C2 C3 C4 C5




enable screen 40.870 13.593 25.108 12.998




Number of classes Memory Usage Total PSS Memory Total USS Memorypreloaded (MB) Usage (MB) Usage (MB)

0 231.75 154.16 127.61

263 228.86 160.55 124.10

515 216.37 162.44 118.59

969 211.54 167.10 113.28

2297(Default) 220.96 169.16 111.80

Table 4.5: Memory Usage of preloading different number of classes.

4.7 displays result recorded for avoiding boot animation. Value representation of table

4.7 is same as table 4.1. In table 4.7, Boot time saved is different between default boot

time(given in column C2) and achieved boot time without boot animation(given in column

C4).

4.3 Activity Manager

According to approach for Activity Manager explained in the previous chapter, modifica-

tion is done in

startProcessLocked and enableScreenAfterBoot function to delay starting of few appli-

cations during the boot. Results are shown in table 4.8. We can see, that time difference

between ams ready and enable screen is reduced to 10.38 seconds from 13.59 seconds.

Around 3.8 seconds of boot time is saved is given in table. Value representation int table

21

Number of classes Browser Calculator

PSS (MB) USS (MB) PSS (MB) USS (MB)

0 31.69 32.93 6.05 4.30

263 32.97 32.39 6.82 3.87

515 34.17 31.58 7.06 3.47

969 34.88 30.24 7.30 3.21

2297(Default) 34.96 28.76 7.72 3.57

Table 4.6: Memory Usage of Browser and Calculator.


C1 C2 C3 C4 C5




enable screen 40.870 13.593 34.105 12.85



Table 4.7: Boot progress while avoiding boot animation.

4.8 is same as table 4.1

4.4 Package Manager

Package Manager is scanning packages for that it is reading AndroidManifest.xml file

from .apk file of package. Modification is done for reading AndroidManifest.xml file

such that Package Manager can read it directly. This modification is explained in previous

chapter. Table 4.9 is showing results with modified Package Manager. Table shows that

scanning time reduced to 1.7 seconds from 2.2 seconds. Value representation in table 4.9

is same as table 4.1.

22


C1 C2 C3 C4 C5

start 3.489 3.489 2.994 2.994preload start 4.872 1.383 4.385 1.391preload end 21.163 16.291 20.666 16.281system run 21.669 0.536 21.171 0.505pms start 22.037 0.338 21.431 0.26



enable screen 40.870 13.593 37.062 10.38



Table 4.8: Boot progress of Android with modified Activity Manager

4.5 All In

Now, put all together. Table 4.10 shows results for preloading 2297 classes with modi-

fied Activity Manager, Package Manager and avoiding boot animation. The difference

columns(C3 and C5) have relative difference between current progress output and previ-

ous progress output. As we can see from the table unoptimized Zygote class preloading

is taking around 16 seconds of time. While avoiding boot animation will reduce this

time to around 12 seconds. Relative difference between ams ready and enablescreen is

reduce to approximately 10 seconds. While the time for enabling the screen is reduced to

approximately 31 seconds. So, by unmodified Zygote class preloading with avoiding boot

animation and modified Activity Manager and Package Manager, able to save around 10

seconds(25%) of boot time.

Table 4.11 is result of preloading only 969 classes with avoiding boot animation and

modified Activity Manager. In this table column C3,C5 shows relative time difference

between consecutive boot progress result. We can see that for preloading all classes will

take around 16.2 seconds while preloading 969 classes is taking 1.426 seconds. Enable

screen time is reduced from 40.8 seconds to 18.9 seconds. That is saving of 21.97 sec-

onds(53.84%) of boot time.


m-odified Activity Manager and Package Manager. In this table difference column(C3 and

C5) have relative difference of consecutive progress output. Required time for preloading

515 classes is only 0.6 seconds. Which very less compare to preloading all classes. Enable

screen time is reduced from 40.8 seconds to 18.012 seconds. That is saving of 22.858

23


C1 C2 C3 C4 C5




enable screen 40.870 13.593 39775 12.844



Table 4.9: Boot progress of Android with modified Package Manager

seconds(55.92%) of boot time. This result is slightly more then compare to preloading of

969 classes.


modified Activity Manager and Package Manager. In this table difference column(C3 and

C5) have relative difference of consecutive progress output. Required time for preloading

263 classes is only 0.28 seconds. Enable screen time is reduced from 40.8 seconds to 17.611

seconds. That is saving of 23.259 seconds(57.00%) of boot time. This result is slightly

more then compare to preloading of 515 classes.

Table 4.14 is result of without preloading any classes with avoiding boot animation

and modified Activity Manager. In this table difference column(C3 and C5) have relative

difference of consecutive progress output. Time for not preloading any classes is 0.06

seconds. Which is very less compare to any other class preloading time. But if we check

enable screen time that is 17.9 seconds. Which is greater then preloading 263 classes.

The reason for this is explained in Zygote experiment section. So, total time saved is 22.9

seconds(56%) which is slightly less then previous result.

24


C1 C2 C3 C4 C5

boot progress start 3.489 3.489 3.320 3320preload start 4.872 1.383 4.235 0.915preload end 21.163 16.291 16.425 12.19system run 21.669 0.536 16.810 0.385pms start 22.037 0.338 17.109 0.299



enable screen 40.870 13.593 31.055 10.019



Table 4.10: Boot progress of Android with modified Package Manger, Activity Manager,preloading 2297 classes and avoiding boot animation.


C1 C2 C3 C4 C5

start 3.489 3.489 3.068 3.068preload start 4.872 1.383 3.983 0.915preload end 21.163 16.291 5.409 1.426system run 21.669 0.536 5.679 0.270pms start 22.037 0.338 5.881 0.202



enable screen 40.870 13.593 18.900 9.165




25


C1 C2 C3 C4 C5




enable screen 40.870 13.593 18.012 8.734





C1 C2 C3 C4 C5




enable screen 40.870 13.593 17.611 8.463




26


C1 C2 C3 C4 C5




enable screen 40.870 13.593 17.901 8.474




27

Chapter 5

Future Work

Boot time can also be reduced by optimizing kernel where if device hardware is slow then

reading uncompressed kernel will be faster then reading compressed kernel and decompress

it. This may be able to save around 1.5-2 second of boot up time.

Avoiding of increase in memory usage due to Zygote preloading. This required mod-

ification at Dalvik-VM since classes are preloaded during the creation of Dalvik-VM. Or

other approach is do not preload any classes and make heap(memory allocation) of Zygote

dynamic so high priority process can load all those classes into memory area of Zygote.

28

Chapter 6

Conclusion

Modifying Zygote preloading, Activity Manager, Package Manager and avoiding boot up

animation time, have saved 23.259 seconds(or 57%) of original boot time. And, to save

this much boot time, 4% of memory usage is increased. Now, our boot up time is reduced

from 40 seconds to 17.611 seconds. While decreasing boot up time we have one side effects

of memory usage which is increased as we have decreased Zygote preloading. But this

will not be an issue for devices which have enough memory. We can reduce more boot up

time by making changes at kernel level.

29

Acknowledgements

I would like to thank Prof. D. B. Phatak for helping and suggesting appropriate reading

material, and for giving me his valuable time for clearing my doubts. I would also like to

thank Nagesh Karmali for his continuous inputs in my work. I would also like to thank

Ms. Firuza Aibara for reading my report and giving valuable feedback. I would also like

to thank every one else who supported me in this work.

30

Appendix A

Android Programming

A.1 Reading AndroidManifest.xml from ‘apk’ File

Following code extracts AndroidManifest.xml file from apk file of packages. It reads apk

files from /system/app, /system/framework and /data/app and extracts AndroidMani-

fest.xml file in /data/xml/system/app, /data/xml/system/framework and /data/xml/data/app

respectively. After writing xml file, it gives read permission to all users, so that Package

Manager can read it.

1 @Override

2 public void onCreate(Bundle savedInstanceState) {

3 super.onCreate(savedInstanceState);

4 setContentView(R.layout.activity_main);

5

6 try {

7 // Check for .apk file in /system/framework folder

8 String path = "/system/framework";

9 File frameworkFolder = new File(path);

10 File[] list_OfFiles = frameworkFolder.listFiles();

11

12 for ( int i=0; i < list_OfFiles.length ; i++ ){

13 if(list_OfFiles[i].isFile()){

14 String fileName = list_OfFiles[i].getName();

15

16 // Check whether given file is .apk or not

17 if(fileName.endsWith(".apk") || fileName.endsWith(".APK")){

18 // Open .apk file.

19 JarFile jf = new JarFile("/data/app/"+fileName);

20 InputStream is =

jf.getInputStream(jf.getEntry("AndroidManifest.xml"));

31

21 byte[] xml = new byte[is.available()];

22

23 // Read file interms of bye and write it.

24 is.read(xml);

25 FileOutputStream fos = new

FileOutputStream("/data/xml/data/app/"+fileName);

26 fos.write(xml);

27 fos.close();

28

29 //Give read permission to file so Package Manager Service can read

the file.

30 Runtime.getRuntime().exec("chmod 744 /data/xml/system/app/"+fileName);

31 }

32 }

33 }

34

35 // Check for .apk file in /system/app folder

36 path="/system/app";

37 File folder = new File(path);

38 File[] listOfFiles = folder.listFiles();

39

40 for ( int i=0; i < listOfFiles.length ; i++ ) {

41 if(listOfFiles[i].isFile()) {

42 String fileName = listOfFiles[i].getName();

43



46 // Open .apk file

47 JarFile jf = new JarFile("/system/app/"+fileName);

48 Log.i("Nimit.checktaskandapp","kalaria /system/app fileName : " +

fileName);

49 InputStream is =



51


53 is.read(xml);


FileOutputStream("/data/xml/system/app/"+fileName);

55 fos.write(xml);

56 fos.close();

32

57


the file.


60 }

61 }

62 }

63

64 // Check for .apk file in /system/app folder

65 path = "/data/app";

66 File dataFolder = new File(path);

67 File[] list_Of_Files = dataFolder.listFiles();

68

69 for ( int i=0; i < list_Of_Files.length ; i++ ) {

70 if(list_Of_Files[i].isFile()) {

71 String fileName = list_Of_Files[i].getName();

72



75 //Open .apk file

76 JarFile jf = new JarFile("/data/app/"+fileName);

77 InputStream is =



79


81 is.read(xml);


FileOutputStream("/data/xml/data/app/"+fileName);

83 fos.write(xml);

84 fos.close();

85


the file.


88 }

89 }

90 }

91 } catch (Exception ex) {

92 Log.i("","Error : " + ex.toString());

93 }

33

94 }

A.2 Parsing Extracted AndroidManifest.xml

Following code reads extracted AndroidManifest.xml file, if file exist. If file does not exist,

it will continue normal execution.

1 /**

2 * Retrieve a parser for a compiled XML file.

3 *

4 * @param cookie Identifier of the package to be opened.

5 * @param fileName The name of the file to retrieve.

6 * @param pkgName Package name. i.e. : /system/app/<apkfile>

7 * {@hide}

8 */

9 public final XmlResourceParser openXmlResourceParser(int cookie,

10 String fileName, String pkgName) throws IOException {

11 // Check whether file is present of not.

12 String file = "/data/xml"+pkgName;

13 File f_ = new File(file, "r");

14

15 // Check whether file is present of not.

16 if(f_.exists()){

17 // File is present.

18 // Read the file into array of bytes

19 RandomAccessFile f = new RandomAccessFile(file, "r");

20 byte[] b = new byte[(int)f.length()];

21 f.read(b);

22

23 // Create XmlBlock from array of bytes.

24 XmlBlock block = new XmlBlock(b);

25 incRefsLocked(block.hashCode());

26

27 // Parse the block.

28 XmlResourceParser rp = block.newParser();

29 block.close();

30 f.close();

31

32 // Return parsed object to parsePackage function().

33 return rp;

34 } else {

34

35 // File is not present

36 // Go with the default execution.

37 XmlBlock block = openXmlBlockAsset(cookie, fileName);

38 XmlResourceParser rp = block.newParser();

39 block.close();

40 return rp;

41 }

42 }

A.3 Starting Delayed Applications

Modified Activity Manager delay loading of applications to save boot time. Following

code starts all such delayed applications.

1 void enableScreenAfterBoot() {

2 EventLog.writeEvent(EventLogTags.BOOT_PROGRESS_ENABLE_SCREEN,

SystemClock.uptimeMillis());

3 mWindowManager.enableScreenAfterBoot();

4

5 // Now it it time to start processes which is in our hold list.

6 final int processNumber = processHoldList.size();

7

8 if (processNumber > 0) {

9 ArrayList<ProcessRecord> processInfo = new

ArrayList<ProcessRecord>(processHoldList);

10

11 for (int i=0; i<processNumber; i++) {

12 // Call startProcessLocked function for each and every record.

13 // 2nd argument must be "on-hold".

14 // 3rd argument should be "null".

15 startProcessLocked(processInfo.get(i), "on-hold", null);

16 }

17 }

18 }

35

References

[1] K. Baik, C. Jinhee, K. Saena, and W. Suchang. Boosting up Embedded Linux device:

experience on Linux-based Smartphone. In Ottawa linux Symposium. ols, 2010.

[2] Tim Bird. Package Scanning. http://elinux.org/images/2/2d/

Android-bootup-time-celf-jamboree34.ppt, 2010. [Online; accessed on

15-April-2013].

[3] Chune. Zygote. http://rednine.tistory.com/452, 2011. [Online; accessed on

25-Sep-2012].

[4] Android Devlopers. System UI Overview. http://developer.android.com/

design/get-started/ui-overview.html, 2010. [Online; accessed on 08-May-

2013].

[5] DISLab. Initialization process. http://dislab.hufs.ac.kr/lab/Android/

Android\_Initialization\_Process, 2011. [Online; accessed on 8-Sep-2012].

[6] Stack Over Flow. Parse XML file. http://stackoverflow.com/questions/

2097813/how-to-parse-the-androidmanifest-xml-file-inside-an-apk-package/,

2010. [Online; accessed on 27-May-2013].

[7] Roy Lee. Zygote initialization. http://roylee17.blogspot.in/2011/02/

zygote-initialization-flow.html, 2011. [Online; accessed on 25-Sep-2012].

[8] Simon Lewis. Service Creation. https://justanapplication.wordpress.com/

tag/com-android-server-am-activitymanagerservice/, 2010. [Online; ac-

cessed on 20-May-2013].

[9] Linux and Open Source community. Android Memory Usage. http://elinux.org/

Android\_Memory\_Usage, 2010. [Online; accessed on 15-Sep-2012].

[10] Linux and Open Source community. Bootchart. http://elinux.org/Using\

_Bootchart\_on\_Android, 2010. [Online; accessed on 5-Sep-2012].

[11] F. Maker and C. Yu-Hsuan. A Survey on Android vs. Linux.

36

[12] Mattias. Boot Process. http://www.androidenea.com/2009/06/

android-boot-process-from-power-on.html, 2009. [Online; accessed on

8-Sep-2012].

[13] G. Singh, K. Bipin, and R. Dhawan. Optimizing the boot time of android on em-

bedded system. In Consumer Electronics (ISCE), 2011 IEEE 15th International

Symposium on, pages 503 –508, june 2011.

[14] Android Devlopers Team. Android kernel. http://groups.google.com/group/

android-kernel, 2011. [Online; accessed on 5-Sep-2012].

[15] Android Devlopers Team. Android platform. http://groups.google.com/group/

android-platform, 2011. [Online; accessed on 5-Sep-2012].

[16] Android Devlopers Team. Android source code. http://source.android.com/

source/building-kernels.html, 2011. [Online; accessed on 5-Sep-2012].

37

Minimizing Boot Time of Android Based Devices · Chapter 2 Approaches to Minimize Boot Time There...

Documents

Transcript of Minimizing Boot Time of Android Based Devices · Chapter 2 Approaches to Minimize Boot Time There...