If you’ve been following this Masterclass from the beginning, you should now be able to set up the Android Kitchen app, take a stock ROM for your supported device, load it up, rip out the bloatware, change the splash screen and even add in your own performance-enhancing scripts. In this class, we go deeper into our Android ROM by looking at the boot image – what it does, how to pull it apart, modify it and put it back together – before we build our final ROM package and flash it to our device.
What is the boot image?
We looked at the concept of a boot image briefly in the las in considering initialization (init.d) scripting, but it’s time to look at it in more detail. When your phone or tablet boots up, the Android OS you recognise is in effect the second OS it launches. Before that, your device uses a tiny app called a bootloader to load the boot image, which contains the kernel and the initial root file system (initramfs) or RAM disk. This boot image has one specific job – to lay the component platform on which the main Android OS is launched. It’s a bit like the BIOS of your PC, except that instead of residing in an EEPROM on a motherboard, the boot image is supplied with the Android ROM.
However, the boot image exists in the ROM as a single file – effectively, it’s a ROM within a ROM. It’s the first thing your Android device loads when it boots, but it has one other important function relevant to this Masterclass series – it’s also the source of your root access.
Pulling apart boot.img
Because it is a ROM within a ROM, we need to pull it apart before we can see what it does and modify its features. Thankfully, the Android Kitchen provides us with the tools to do this. We’re assuming you’ve been following the Android ROM series, you’ve already set up the Android Kitchen app on your Linux PC or virtual machine and you have an Android ROM already expanded. The next step is to pull apart the boot.img file and you do that within the Kitchen by selecting ‘0 – Advanced Options’, followed by ‘12 – Tools for boot image’.
This brings up the ‘Boot Image Tools’ menu. Just to make sure your ROM is valid and has a boot image on-board, the first thing you should do is select S to show the boot.img file information. After that, choose W to pull the boot.img file apart – the Kitchen will extract the kernel and the RAM disk into a subfolder called BOOT-EXTRACTED in your /user/kitchen folder location.
Manually add root access
Now you can use Thunar, Nautilus or your favourite Linux file manager to look inside this folder and you’ll see a ‘zImage’ file (the Android kernel) and ‘boot.img-ramdisk’ folder (the boot image). Again, we’re using a stock Android 4.1.2 ROM for a Samsung Galaxy S3 smartphone in this example – your mileage may vary, but it shouldn’t by much. If you look inside the boot.img-ramdisk folder, you’ll see what vaguely resembles the folder structure of a Linux OS, which is roughly what this little RAM disk is.
One of the first files you should see in this folder is default.prop, a properties file that tells the device some basic setup options, including its security setting. Now the first thing we’d suggest here is that you make a copy of this file and store it somewhere outside the Kitchen folder as a backup. After that, you’re safe to work on the real file in your working folder.
Open up the file in a Notepad-like text editor (Mousepad is my favourite) and you’ll see the line ‘ro.secure=1’ or ‘ro.secure=0’. If the ro.secure key is set to ‘1’, it means your Android OS is in secure mode and won’t allow root access. But if it’s set to ‘0’, you’ll now have root access. And essentially, that’s it – that’s what all the root-access fuss is about. This is what Android Kitchen’s ‘Add root permissions’ option (and every other root-access app) has to do to enable root access – open up the boot.img RAM disk and edit default.prop to read (among other things) ‘ro.secure=0’.
That said, Google appears to have changed how security works in Android 4.3 and getting root access on a ‘live’ device running this OS has been problematic. While our process will work with ROMs up to Android 4.2.x, we’ll need to investigate Android 4.3 support further.
In the meantime, here’s the complete default.prop file for our customised root-access-enabled Galaxy S3 test ROM:
MTP or UMS?
The last line has nothing to do with root-access, but sets the default USB configuration setup – whether it uses the Media Transfer Protocol (MTP) or USB Mass Storage (UMS) device driver method when connecting to your PC.
For MTP, you’ll see ‘persist.sys.usb.config=mtp,adb’ and for mass storage, it’ll be ‘persist.sys.usb.config=mass_storage,adb’. In practice, your phone/tablet will appear as a media device in Windows Explorer if you use MTP, but via UMS, you’ll see it as a normal external drive. UMS stops your device doing anything else while files are being transferred, plus there’s a 4GB filesize limit. MTP on the other hand allows your phone to still do other things and there’s no filesize limitation, but it does support Windows DRM. Incidentally, ‘adb’ refers to Android Debug Bridge, a way of programming your Android device through a direct USB-connect to your PC.
Once you’ve made any changes, you have to rebuild the boot.img file before it can be bundled back into the ROM. You do that by going back to Android Kitchen’s Boot Image Tools menu where you’ll now find a ‘B = build boot.img from BOOT-EXTRACTED folder’. Select B and it’ll not only rebuild the boot.img file but copy it back to your working ROM folder and delete the BOOT-EXTRACTED folder, tidying everything up. (It’s not a great idea to have multiple boot image folders floating in your working folder.)
Change the ROM name
The last thing to do before you build your custom ROM from this mad collection of folders and files is to set your ROM name. Every Android ROM has a name that’s displayed in the ‘Settings > About Device’ page and you should give yours a unique name. To do that, go to Android Kitchen’s main menu and select ‘7 – Change name of ROM’. This will show you the existing name and allow you the choice of renaming it. We recommend you keep any existing base name codes and just add your own custom text to it. This way, you’ll easily identify its original source at a future date.
Final custom ROM build
Now you’re ready to build your final customised ROM. At this point, it’s worth making sure, again, that you’ve been using a ROM base that’s designed for your particular device. Flashing a ROM that’s not designed for your device is a guaranteed way to brick it, so it really does pay to be sure before you do it.
To put your files back together again into a flashable ROM, go to Android Kitchen’s main menu and select ’99 – Build ROM from working folder’. The Kitchen gives you four build options – Interactive, Lazy, Express and Extreme. We recommend everyone runs through the step-by-step Interactive option at least once, just so you know what the Kitchen is doing and to understand what’s involved in the process. After that, choose the Lazy option as the fastest way to get you home. But regardless of which option you choose, there’s a fair bit to do here so be prepared for it to take some time – enough to get a cuppa, depending on the size of your ROM. When it’s finished, you’ll find the new ROM as a single zip file in the OUTPUT_ZIP folder in your main Kitchen folder.
Flashing your custom ROM
Once you have your custom ROM, flashing it to your device is just the same as flashing any other ROM, whether it’s a stock ROM, CyanogenMod or whatever. We don’t have space to cover the whole process now, but we did go into detail of how to gain root access and flash a custom ROM using Samsung’s Galaxy S2 and S3 smartphones on our website which you can refer to.
In short, the process here is:
- Backup your device
- Root your device, adding a custom recovery app like ClockworkMod
- Copy the new ROM zip file to the device’s SD card slot
- Boot into Recovery Mode (usually the power, home and volume-up buttons)
- Wipe Dalvic Cache
- Install new ROM
Again, it’s important that you’re using a ROM base that’s designed for your device and to follow the root access and ROM flashing process that works with your device.
While rooting and flashing custom ROMs to Android devices are now every-day occurrences, we can’t guarantee the process will work flawlessly every time. It should – we just can’t guarantee it. That’s why it’s important you understand the troubleshooting options for your device’s recommended process before you starting flashing, just so you know what to do should trouble strike.
As far as your new custom ROM goes, provided you’ve followed the steps for your device correctly, you should end up with a working ROM, but it’ll still be subject to all the usual install issues when installing any Android ROM. The two most common problems we’ve seen are boot lockup, where you see nothing but your splash screen; or a boot loop, which sees your phone cycling through your boot animation and rebooting again and again.
But before you hit the panic button, thinking you have a boot lockup, be patient – the first boot of a new ROM will always take extra time and subsequent boots will quickly sort themselves out. But if your device hasn’t booted up within ten minutes, it’s pretty safe to assume there’s a problem somewhere.
If your device appears stuck in a boot loop, the most common issue is forgetting to wipe the Dalvic cache partition – basically, your device is trying to use cached data from your old ROM with the new one and it’s (not surprisingly) failing. Go back to ‘Recovery Mode’, wipe the cache and it should now work. If necessary, you may need to re-flash the new ROM too.
If the device is locked up on the splash screen, you may have the same problem but it’s also possible that your ROM just isn’t right. You must make sure you’re using the correct ROM base for your device. Try building the ROM again from your working folder, check for any possible errors and flash your device again. If you still can’t get your device to boot, don’t panic – flash it back to original with the stock ROM again, in which case, you may need to start your build process again from scratch.
Other things to consider are any apps you have removed from the ROM. It’s easy to get a bit enthusiastic about removing bloatware apps and go a step too far – always only remove apps you know and know are bloatware only.
Always backup before you flash
But if there’s one over-riding thing to remember, it’s always make a Nandroid Backup of your phone/tablet before you flash any ROM, so that if things go seriously wrong, you can always restore your phone to its current state. We cannot emphasise this enough.
And make sure you copy the backup to your PC or home server for safe keeping. Don’t just store it on your device’s storage card – it’s far too easy to erase it.
Hopefully, this series has given you a taste for how Android ROMs work and that they aren’t really as scary as they may first look. Starting with the next class, we’ll begin taking some of the things we’ve learned throughout this series and applying them ‘live’ to your device’s existing Android OS. We’ll start by how to bypass a Google Play app’s unsupported devices list and get it installed on any Android device. We’ll see you then.
Flashing your Android device with any unofficial ROM will guarantee you void its warranty. While we have successfully tested this process on our own Galaxy S3 phone, we provide no warranty on its use – you use it at your own risk.