Chapter 6. "Cooking" Your First ROM

In Chapter 5, Customizing Kernel and Boot Sequence, we took an amazing journey into the Linux kernel—now you know how to obtain the right version for your device and how to build it. We got great satisfaction customizing and building your own kernel version, specific for your device—we added new drivers for your hardware and removed those that were unnecessary. You finally learned about the boot sequence.

In this chapter, we will enter the modding world and we will move forward with your first customized ROM. You will learn how to set up the system and how to create a custom ROM. We will see an overview of the most popular ROMs, and all the tools you need and how to use them.

The following topics will be covered in the chapter:

• History of Android modding (Cyanogenmod)

• Custom recovery

• Root access

• Kitchen and other tools

History of custom ROMs

First things first—What does "Custom ROM" mean?

Most Android devices come with so-called NAND memories. A NAND memory is a particular type of flash memory. A flash memory is based on transistors, instead of rotating disks, like in old hard drives. This type of memory is completely electrically managed—it can be written and erased and can store data indefinitely (not volatile). Knowing this, we may think that everything is writable on Android. Well, not exactly!

The acronym ROM stands for Read-Only Memory. This type of memory is often used in embedded systems to safely store all those files that are part of the core system. In an effort to guarantee the highest system integrity possible, developers must be sure that the core system stays intact over device reboots and possible failures. That's why the core system is stored in a type of memory that can only be written once—Read-Only Memory, to be precise. With time, the Android hacking community took the acronym and transformed...

An overview of Android recovery

One of the most important parts of the whole Android architecture is the Recovery partition. A recovery partition is very common in embedded systems, and we saw an overview of it in previous chapters. As we know, the so-called Recovery is a minimal runtime system, completely decoupled from the main Android system and totally self-sufficient. Its main goal is to guarantee system integrity and provide the necessary tools to fix common minor issues and restore a properly working system.

With an Android vanilla Recovery, we can:

• Update the Android system

• Wipe the data partition and the cache partition

Wiping the data and cache partition is a common practice if we want to restore our device to the factory defaults, for instance, in order to have a clean system to start experimenting on something specific, or if we just want to sell it.

Diving into Android recovery

The Android Recovery system is completely standalone. This means that whatever might happen to the main...

Device permissions

As we have seen in previous chapters, Android is based on Linux, so it also inherits the part that concerns user permissions. As with a standard Linux system, Android also manages everything through groups and users. In the default configuration, it's not possible to obtain administrator (root) access, in order to prevent tampering with the system. Also, with access to the whole operating system, it's easy to corrupt the system itself, accidentally or deliberately (for example, to steal user data using a virus).

Every Android app, when installed on the system, generates a new user and group, and inter-app communications are performed according to Android SDK constraints and protocols. Sometimes, though, it's useful to have complete control over the device, like, for example, when installing apps that manage CPU frequency and the CPU governor.

Now let's see how to obtain root access and what the implications of rooting the device are.

Root access

Root access enables the users...

Chef toolkit

One of the main goals of this book is to help you realize your own version of a ROM customization. In the dictionary of modders, the act of modifying a version of Android in order to produce one's own ROM customization is often referred to with the verb to cook and the word kitchen.

"Cooking one's own ROM" means to modify the stock version of Android installed on one's device, with the aim of creating a new one.

For this reason, all the tools that might help to make the development of a ROM customization easier are called Chef toolkit.

As discussed in the previous chapters, it is indeed possible to create one's own ROM version starting from the source code, but this is not always possible, as some device manufacturers do not release their source code. In all those cases, we need to act on the system partitions, often directly on the binaries that build the internal core, both on the application framework and on the filesystem utilities.

In the next paragraphs, we will learn how...

Cooking our first ROM

So far, we have seen an overview of the suite of tools we need to create a custom ROM from a binary system image. The most important of all is the kitchen, and it needs system.img and boot.img partition files to properly do its job.

If you are targeting Google devices, this is an easy game. Google provides system source code for its devices, so we can always build our .img files from the source, as we learned in previous chapters. We can also grab the .img files from the official system installation packages that Google also provides for its devices at every new release of the Android system.

If you are targeting a device that's not a Nexus, things become more adventurous. Most of the time you don't have the system source code; often you don't even have the downloadable system images. As you will see in the next sections, there is always a way to obtain every last piece of the puzzle to create our custom ROM.

Gathering the ingredients

The list is quite short. All you need...

Flashing our custom ROM

You have your .zip file and your customized system partition, and you are thrilled to have flashed them to your device.

To flash the system partition, we can use fastboot. First, you must unmount the partition itself using the following command:

~$ umount system_mount_point

Before we start experimenting with the system partition, it's always wise to do a system backup:

"Be prepared. You never know."

Now, you can put the device in Fastboot mode, according to the specific sequence of your device. For our reference device, Google Nexus 6, the sequence is:

1. Power off

2. Press Volume Up, Volume Down, and Power at the same time

3. Release when the Fastboot menu appears

The device is now ready to receive the new system partition. Flash it with the following command:

~ $ fastboot flash system system.img

Your brand new system partition is in place! If your modifications were very extreme and adventurous, you could end up in a bootloop—the system keeps on rebooting and never ends the boot...

Summary

This chapter taught us what a custom ROM is. We started from a description of the currently existing, most relevant projects, and we have proceeded deep into the details. We have also had a look at some very important components, such as Android Recovery, both the stock ones and those that have been modified. Finally, as we did in the previous chapters, we have adopted a practical approach, learning how to prepare a suitable environment for Android customization. We have also studied the different tools that are generally used to perform this task, and, in the end, we have applied the concepts we just learned through a simple example of creating a custom ROM. In the next chapter, we will be diving deeper into every single aspect of a ROM, using practical examples to show how to customize and increase the performance of your ROM.