On the previous post “Android Boot Process”, various steps involved in booting up the Android is explained. Before we start optimizing the Android boot process, each step has to profiled and analyzed to identify the critical delays. There are various tools and techniques available to understand the resource usage (both time and processing), which will be discussed in the below sections.
As the “Observer effect” notes that the measurements of certain systems cannot be made without affecting the system, using some of these tools will affect the actual performance. For example, using “bootchart” tool increases the system load marginally as it has to write to file system for storing the sampled data. But since we are not dealing with quantum mechanics, we can safely use them for improving the process and then disabling them in the release. Now about the tools.
The basic and primary technique is to enable the debug capabilities in the kernel. This option, up on enabled, will output debug prints along with the time stamp information. It can be enabled in the kernel by “make menuconfig” configuration using the following options
During run time, the prints are output in the console.
Android provides a service started by the “init” process to log various debug information. The service can be enabled in init.rc file as follows
service logcat /system/bin/logcat -r 1000 -n 10 -v time -f /data/local/logcat.log
It provides options to print the debug options on process and even thread level along with the time stamp. The logcat can also be started from console command line without needing it to be run as a service and the output directly printed on the console.
The verbosity of the log can be increased by configuring a higher number with 8 as the upper limit. So changing the default log level 3 to log level 8 in init.rc file will help us understand some of the internal processes and execution time of the same.
A detailed description of this tool is available in Android Developer page.
Another valuable tool in documenting performance of each process is the “strace” tool. It helps us to trace the system calls executed by the associated process. To enable strace, in the /init.rc file, rather than starting a process directly, “strace” has to be started with the process as the arguments.
For example to document the zygote process, instead of the usual command,
service zygote /system/bin/app_process -Xzygote /system/bin –zygote –start-system-server
following can be used:
service zygote /system/xbin/strace -tt -o/data/boot.strace /system/bin/app_process -Xzygote /system/bin –zygote –start system-server
strace generally outputs a lot of information and can be used in advanced debugging.
Bootchart is tool to generate a graphical representation of android boot sequence. The greatest advantage of this tool is that the processor usage and disk usage are logged together and hence give a fairly good understanding of the cause of execution delays. This is internally supported in the Android and is enabled during compilation, by exporting a environment variable as follows,
Followed by usual Android compilation process.
To instantiate boot chart process, create a file in /data directory with the number of seconds to log the boot information, typically by
‘echo 60 > /data/bootchart-start’
The up on booting the Android, the bootchart logs all the necessary information in the /data/data/bootchart/ directory.
The contents can be transferred to the host PC and by using a “python” based tool called “bootcharting”, the graphical representation can be created. To generate bootchart image by ‘system/core/init/grab-bootchart.sh’
The following is a typical output of a boot chart.
As we can see, start time of each process along with their disk usage and execution pattern can be inferred.
There are other tools available for profiling the android processes. Some of them are
Since Android boot time optimization needs a lot of iterations, it is better to create an ecosystem to easily capture and process these profiling information using scripts and other techniques.
Now armed with detailed profiling information, we will look in to various Optimization techniques in our next post.
Please fill in this form to subscribe our blog.
In this blog, we will discuss in detail about the camera interface and data flow in Jetson Tegra platforms and typical configuration and setup of a MIPI CSI driver. For specifics, we will consider Jetson Nano and Onsemi OV5693 camera.
In this blog, we will explore the scope for No-Code and Low-Code development for embedded systems and how Flint tool can help realize the same for this field.
Now a days in 2022 due to technology growth, a product is having multiple features/use cases and it has been upgraded for bug fixes and new features in the interest of customer/end.
In any vehicle, the instrument cluster forms a critical part as it is the face of the vehicle that reflects the current state.