f itself, the kernel wouldn’t know whatto do once it’s loaded. It would sit there and do nothing. But what the Linuxkernel expects is an initial ramdisk at a predefined memoryaddress. This ramdisk contains a very rudimentary and usually read-onlyfilesystem which contains the most basic root filesystem possible, and a fileunder /sbin/init which the kernel executes as the last thingit does as part of initialization. This
So now we come back to the difference between aboot and recovery image. While the kernel sometimes is the same as the bootimage, the recovery image ramdisk has a distinct sets of init scriptswhich don’t start the Java VM, but instead start a small C program called (didyou guess it?) recovery. Recovery displays a limited user interfacethat allows the user to start the system, factory reset, clear the cachepartition, etc. Some custom recoveries have their own program that offers evenmore functionality.
Packing an Android Boot Image
The Android boot images have a
The layout of an Android boot image
I should mention something of this second stage.To be completely honest, I do not know its raison d’être, theoriginal intent of it. I have seen it used in more recent times to hold thekernel’s device tree block (DTB, another long and deeply technical topic bestexplained elsewhere) by certain phone manufacturers. The older kernels had theDTB as part of the kernel image, now they’ve split it out into its own separatepiece to make it easier to build a more generic kernel that can be adapted to avariety of hardware configurations within the same architecture.
Moving swiftly along (and back!) to the bootimage header, this primarily tells the bootloader how to load the components ofthe boot image, and it looks something like this:
Android boot image header
As you can see, it has a few “book-keeping”fields about how large the other sub-components of the boot image are, whataddress to load them into, etc.
It also has a field called magic. Themagic field is simply a string of well-known characters to identify this as anAndroid boot image. In this case the string is “ANDROID!”, which fits neatlyinto 8 bytes.
Somebody familiar with the Linux kernel andboot-up process will recognize the kernel tags and command line argument fieldsas ways to pass more custom information into the kernel, such as where theconsole should be, and where to find that initial ramdisk from where to loadits init program.
Working With Android Boot Images
So, since we have custom recovery and boot imagesfor our Android phones (such as TWRP, CWM, etc.), obviously, someone had tocreate their own recovery image or modify an already existing boot image. Mostof the work was done using the already open-sourced Google Android code, butthere only was code there to create a boot image from its components. There wasno tool to unpack a boot image for modification. Now, you can use a tool like
Further Areas to Explore
There are some interesting aspects relating tothe initial ramdisk that apply to both the boot and recovery Android imagesthat this article won’t cover in detail due to its already burgeoning size, butthat are worth mentioning.
● The filesystem that initial ramdisks useis usually a gzipped CPIO archive
● You can pack and unpack the initialramdisks and modify them
● init scripts are written in their owndomain specific language (DSL) and you can read their
● Default SELinux file contexts and policyusually reside in the ramdisk’s root
We can spend many hours talking about and playingwith the above items, but at least for now I will leave them as an exercise tothe keen reader.