Minimizing Boot Time of Android Based Devices · Chapter 2 Approaches to Minimize Boot Time There...
Transcript of 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
Table 3.3: Logcat output of Android boot progress.
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
Table 3.5: Logcat output of Android boot progress.
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
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.100 3.100preload start 4.872 1.383 4.486 1.386preload end 21.163 16.291 4.862 0.376system run 21.669 0.536 5.263 0.401pms start 22.037 0.338 5.690 0.427
pms system scan start 22.494 0.457 6.094 0.404pms data scan start 24.776 2.282 8.218 2.124
pms scan end 24.794 0.018 8.219 0.001pms ready 24.946 0.152 8.453 0.234ams ready 27.277 2.331 11.297 2.844
enable screen 40.870 13.593 24.378 13.081
Total Boot Time 40.870 24.378
Total Boot Time Saved 16.492
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
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.113 3.113preload start 4.872 1.383 4.497 1.384preload end 21.163 16.291 5.348 0.851system run 21.669 0.536 5.758 0.410pms start 22.037 0.338 6.032 0.274
pms system scan start 22.494 0.457 6.493 0.461pms data scan start 24.776 2.282 8.669 2.176
pms scan end 24.794 0.018 8.671 0.002pms ready 24.946 0.152 8.838 0.167ams ready 27.277 2.331 11.562 2.694
enable screen 40.870 13.593 24.684 13.122
Total Boot Time 40.870 24.684
Total Boot Time Saved 16.186
Table 4.3: Boot progress for preloading 515 classes.
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
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.089 3.089preload start 4.872 1.383 4.472 1.383preload end 21.163 16.291 6.379 1.907system run 21.669 0.536 6.728 0.349pms start 22.037 0.338 7.002 0.274
pms system scan start 22.494 0.457 7.463 0.461pms data scan start 24.776 2.282 9.652 2.189
pms scan end 24.794 0.018 9.654 0.002pms ready 24.946 0.152 9.806 0.152ams ready 27.277 2.331 12.110 2.304
enable screen 40.870 13.593 25.108 12.998
Total Boot Time 40.870 25.108
Total Boot Time Saved 15.862
Table 4.4: Boot progress for preloading 969 classes.
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.
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.505 3.505preload start 4.872 1.383 4.422 0.917preload end 21.163 16.291 16.642 12.22system run 21.669 0.536 17.026 0.384pms start 22.037 0.338 17.304 0.278
pms system scan start 22.494 0.457 17.667 0.363pms data scan start 24.776 2.282 19.367 1.700
pms scan end 24.794 0.018 19.379 0.012pms ready 24.946 0.152 19.490 0.111ams ready 27.277 2.331 21.255 1.765
enable screen 40.870 13.593 34.105 12.85
Total Boot Time 40.870 34.105
Total Boot Time Saved 6.765
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
Boot Progress Output Time(sec) Time Difference Time(sec) Time Differencefor C2(sec) for C4(sec)
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
pms system scan start 22.494 0.457 21.950 0.519pms data scan start 24.776 2.282 24.210 2.260
pms scan end 24.794 0.018 24.211 0.001pms ready 24.946 0.152 24.359 0.148ams ready 27.277 2.331 26.682 2.323
enable screen 40.870 13.593 37.062 10.38
Total Boot Time 40.870 37.062
Total Boot Time Saved 3.808
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.
Table 4.12 is result of preloading only 515 classes with avoiding boot animation and
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
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.430 3.430preload start 4.872 1.383 4.834 1.404preload end 21.163 16.291 21.277 16.443system run 21.669 0.536 21.785 0.508pms start 22.037 0.338 22.218 0.433
pms system scan start 22.494 0.457 22.650 0.432pms data scan start 24.776 2.282 24.392 1.742
pms scan end 24.794 0.018 24.411 0.019pms ready 24.946 0.152 24.572 0.161ams ready 27.277 2.331 26.931 2.359
enable screen 40.870 13.593 39775 12.844
Total Boot Time 40.870 39.775
Total Boot Time Saved 1.095
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.
Table 4.13 is result of preloading only 263 classes with avoiding boot animation and
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
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.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
pms system scan start 22.494 0.457 17.454 0.345pms data scan start 24.776 2.282 19.174 1.72
pms scan end 24.794 0.018 19.175 0.001pms ready 24.946 0.152 19.281 0.106ams ready 27.277 2.331 21.036 1.755
enable screen 40.870 13.593 31.055 10.019
Total Boot Time 40.870 31.055
Total Boot Time Saved 9.815
Table 4.10: Boot progress of Android with modified Package Manger, Activity Manager,preloading 2297 classes and avoiding boot animation.
Boot Progress Output Time(sec) Time Difference Time(sec) Time Differencefor C2(sec) for C4(sec)
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
pms system scan start 22.494 0.457 6.241 0.360pms data scan start 24.776 2.282 7.877 1.636
pms scan end 24.794 0.018 7.878 0.001pms ready 24.946 0.152 7.992 0.114ams ready 27.277 2.331 9.735 1.743
enable screen 40.870 13.593 18.900 9.165
Total Boot Time 40.870 18.900
Total Boot Time Saved 21.97
Table 4.11: Boot progress of Android with modified Package Manger, Activity Manager,preloading 969 classes and avoiding boot animation.
25
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.070 3.070preload start 4.872 1.383 3.984 0.914preload end 21.163 16.291 4.620 0.636system run 21.669 0.536 4.931 0.311pms start 22.037 0.338 5.133 0.202
pms system scan start 22.494 0.457 5.489 0.356pms data scan start 24.776 2.282 7.115 1.626
pms scan end 24.794 0.018 7.116 0.001pms ready 24.946 0.152 7.234 0.118ams ready 27.277 2.331 9.278 2.044
enable screen 40.870 13.593 18.012 8.734
Total Boot Time 40.870 18.012
Total Boot Time Saved 22.858
Table 4.12: Boot progress of Android with modified Package Manger, Activity Manager,preloading 515 classes and avoiding boot animation.
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.259 3.259preload start 4.872 1.383 4.177 0.918preload end 21.163 16.291 4.464 0.287system run 21.669 0.536 4.768 0.304pms start 22.037 0.338 5.155 0.387
pms system scan start 22.494 0.457 5.502 0.347pms data scan start 24.776 2.282 7.095 1.593
pms scan end 24.794 0.018 7.096 0.001pms ready 24.946 0.152 7.207 0.111ams ready 27.277 2.331 9.348 2.141
enable screen 40.870 13.593 17.611 8.463
Total Boot Time 40.870 17.611
Total Boot Time Saved 23.259
Table 4.13: Boot progress of Android with modified Package Manger, Activity Manager,preloading 263 classes and avoiding boot animation.
26
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.411 3.411preload start 4.872 1.383 4.323 0.912preload end 21.163 16.291 4.381 0.058system run 21.669 0.536 4.721 0.340pms start 22.037 0.338 5.156 0.435
pms system scan start 22.494 0.457 5.493 0.337pms data scan start 24.776 2.282 7.107 1.614
pms scan end 24.794 0.018 7.108 0.001pms ready 24.946 0.152 7.224 0.116ams ready 27.277 2.331 9.427 2.203
enable screen 40.870 13.593 17.901 8.474
Total Boot Time 40.870 17.901
Total Boot Time Saved 22.969
Table 4.14: Boot progress of Android with modified Package Manger, Activity Manager,preloading 0 classes and avoiding boot animation.
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
44 // Check whether given file is .apk or not
45 if(fileName.endsWith(".apk") || fileName.endsWith(".APK")){
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 =
jf.getInputStream(jf.getEntry("AndroidManifest.xml"));
50 byte[] xml = new byte[is.available()];
51
52 // Read file interms of bye and write it.
53 is.read(xml);
54 FileOutputStream fos = new
FileOutputStream("/data/xml/system/app/"+fileName);
55 fos.write(xml);
56 fos.close();
32
57
58 //Give read permission to file so Package Manager Service can read
the file.
59 Runtime.getRuntime().exec("chmod 744 /data/xml/system/app/"+fileName);
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
73 // Check whether given file is .apk or not
74 if(fileName.endsWith(".apk") || fileName.endsWith(".APK")){
75 //Open .apk file
76 JarFile jf = new JarFile("/data/app/"+fileName);
77 InputStream is =
jf.getInputStream(jf.getEntry("AndroidManifest.xml"));
78 byte[] xml = new byte[is.available()];
79
80 // Read file interms of bye and write it.
81 is.read(xml);
82 FileOutputStream fos = new
FileOutputStream("/data/xml/data/app/"+fileName);
83 fos.write(xml);
84 fos.close();
85
86 //Give read permission to file so Package Manager Service can read
the file.
87 Runtime.getRuntime().exec("chmod 744 /data/xml/system/app/"+fileName);
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