With our understanding of Android Boot process and profiling of Android Boot Time Analysis, we will now start the actual process of Android boot time optimization.

There is no single solution to improve the boot time applicable to all platforms. The boot process is dependent on each peripheral involved right from DRAM speed, storage device performance, processor speed and also on the customer requirements and kind of application area being used etc. Termed as “Tooth paste effect” by Tim Bird, shortening a process somewhere here will end up lengthening something else over there.

Another important point to remember is that the configuration used for improving must be same as the finally deployment. For example, working on SD Card file system (For ease of programming) to improve the boot time and then finally deploying the result in a NAND file system, will lead nowhere as the data rates of NAND and SD Card will differ.

The following sections describe various techniques module by module for Android boot time optimization.

Bootloader

The boot loader performs a critical initialization that will affect the whole process – DRAM initialization. As the DRAM is going to host the text region and data section, an improper initialization will result in significant performance degradation.

Further the Boot loader copies uboot or Linux kernel image from a non-volatile storage medium such as NAND or SD Card. So the same has to be configured to run in the maximum possible frequency. DMA operations can be used to improve the data transfer through put.

Obviously the processor needs to be run in the highest possible frequency and with I-cache and D-cache enabled.

Unnecessary initializations like initializing display can be removed from the code. But in some applications, it will be required to display images immediately on boot up. For example, it may be required to show a company logo or to show battery status. In this case, it will not be possible to remove the display configuration.

Also the number of boot loader levels should be reduced if possible. This is possible depending on the processor implementation.

Kernel

Using an uncompressed kernel “bImage” rather than a compressed “zImage” will avoid the delay to uncompress it run time. But this will increase the size of kernel image to be copied, there by significantly dependent of on the target system processor and data transfer speeds.

All the unnecessary driver modules should to be removed. A minimal set of device drivers can be built initially and other necessary drivers can be configured as modules and loaded later. A details study has to be made on the device initialization time, time required to copy the increased kernel image (in case of statically linked driver) or load time of a module over the file system.

File systems

Generally a non-removable media is used as the root file system. Sometimes a ramdisk image can be used as a root file system with certain functionalities there by reducing time to start the init scripts. This can be achieved by using uImage. Once again this will increase  the time required to copy it at the boot loader stage.

Also an optimized file system format can be used for the root file system for faster access. It is preferred to have ubifs for NAND and ext4 for SD Cards.

Android

The below sections describes the techniques to improve the functionality inside the Android subsystem.

Init.rc

For a faster processing, avoid starting unnecessary services and daemons. Also since JellyBean, there are lot of changes in file permissions. So the logcat output can be used to analyse any discrepancies in permissions and corrected.

Android preload classes and resources

In ZygoteInit, Andorid loads all the classes and resources that it will need for further execution. The boot time can be reduced significantly by reducing the number of classes and resources to be preload or even avoiding them all.

This is the easiest process and most visible step in the optimization process. The preloading can be disable by just making the variable “PRELOAD_RESOURCES” false (only to disable preloading resources) or commenting the function “preload()” on “frameworks/base/core/java/com/android/internal/os/ZygoteInit.java” (to disable both resources and classes).

But disabling preloading will directly increase in launch time of individual application after boot up. As a compromise, the number of classes to be preloaded can be manually configured in the frameworks/base/preloaded-classes file.

Android System service

By default, the SystemServer starts all android system services. But some of them may not be applicable for the current system. For example, a device may not have a Bluetooth module, thereby has no need for the BlueTooth manager service. Thus a necessity analysis of services and disabling unnecessary ones, will reduce the start time.

Scanning Application Packages

The package manager, up on start up, scans all the available packages in the app directories. Hence the service can be expedited be removing unnecessary applications from the system. It is also possible to delay scanning of packages by custom changes in the package manager implementation and using a customized home application.

Precreate directories

In some systems, certain directives are created in the on-init process. If it is possible, these activities can be done offline once during file system creating there by significantly reducing the time to boot.

Bootanimation

For a faster boot it is better to avoid or use a shorter boot animation. The bootanimation.zip can be tactically placed on the best file system for optimum performance.

Other Techniques

Some other techniques that can be used to speed up boot are:

Storage Device Speed/Processor Execution Speed Tune up

Based on bootchart, the resource requirements of major services can be analyzed and be spread across time to avoid overloading of processor as well as the disk usage.

Disabling All Debug Options

All the debug information like kernel level debugs, debug services like logcat, strace, bootchart etc can be removed on final release. The loglevel in android init.rc can also be reduced.

Proper shutdown

If the system is shutdown improperly (in a non-battery backed up device), the file systems will not be un-mounted properly. So when the system is booted next time, it takes some time to recover the file system errors. So it is necessary to make sure that the system is shutdown properly.

Conclusion

With the above mentioned techniques, it is possible to reduce the boot time of the android system. Once again it is iterated that the effectiveness of each technique is highly dependent on the system. But with some time and a lot of patience, it is possible to achieve significant difference and make the Android boot faster.

Various technological advances are being made in this area. For any queries or requirements on Android Porting and/or Android Boot Time Optimization, feel free to contact us.