Here we are. Every piece of the puzzle is in place—you can finally move forward to installing your brand new custom Android version onto your device.
After the build process is complete, you will find all the system images you need in the out/target/product/shamu folder:
system.img: This is, well, the system image. It contains the whole operating system—Android Framework, system native libraries, and the system utility app, such as Calc or Clock.recovery.img: This image contains what we are going to place in the Recovery partition. It contains a kernel and the recovery software itself.boot.img: This image contains the Linux Kernel and a small RamDisk. This image will be placed in the boot partition and will contain all the files needed to initialize the system:init.rc, for instance, and every other component needed to start the system.
Every partition can be flashed using a specific partition image and an appropriate command. Switch your Nexus into bootloader mode, plug the USB cable, and let's flash a few partitions. Launch your Terminal, navigate to out/target/product/shamu, and execute these commands:
:$ fastboot flash system system.img :$ fastboot flash boot boot.img :$ fastboot flash recovery recovery.img :$ fastboot reboot
The last command will reboot your device and your brand new custom Android version will come to life! This first version of the system will definitely look bare without Google Play Store. With no possibility of installing applications, there is very little we can do with a device, indeed. No sad faces, please! In the next chapters, we will learn how to acquire and install the Google apps we need and how to customize our system.
As a final note, in this first run, we used the Linux Kernel provided by Google—we didn't compile it from sources. In the next chapters, we will learn how to do it and take full control.
As usual, UDOO is slightly different. We have a few possible paths to achieve our goal, but first things first—partitions. The first step is to prepare the SD card with the proper partitions set. Unlike the Nexus and its pre-partitioned Nand memory, ready to be flashed, with UDOO we have full control of the system, even of the memory partitioning.
Freedom and power come with responsibility—we need to create the proper partitions before being able to install the system. Being developer friendly, the UDOO development team provides a handy script to speed up the job. The root folder of your UDOO working directory contains a make_sd.sh file. Insert the UDOO SD card in your computer and detect the disk number:
- On Linux, using
df –f, you should look for something like/dev/mmcblkX - On OS X, using
diskutil listyou should look for something like/dev/rdisksX
A super easy trick is to insert the SD card and note down all the disk numbers. Extract the SD card and figure out the one that is now missing! Once you have detected the disk number, you can run the script like this by specifying the proper disk name:
$ ./make_sd.sh /dev/mmcblkX
The script will automatically erase the SD card, create the partition structure, and copy all the files the build system generated and deployed in out/. This could take a while, depending on the speed of your SD card.
As we saw, developing for a Google device is pretty straightforward: we download the source code and start configuring the system to achieve our built images. We end up with a stock version of the system we can later decide to customize as we like. Developing or porting Android to a new hardware is a totally different matter: it is quite different and requires a bit of effort and commitment.
When you decide to set out for a journey like this, the first crucial step is choosing the proper hardware platform. The market offers a large collection of vendors and every vendor offers his own particular solutions—different SoC, different on-board sensors, cheap low-end boards, or hyper-fast expensive boards. There is no place in this book for discussion about choosing an expensive board or not. We focus on the developer and their world and, as a professional, 99% of the time they will find themselves working with a so-called reference board.
A reference board is a particular kind of development board that every vendor offers to its potential clients. Usually, a reference board ships with everything possible on-board—tons of sensors, tons of external devices, tons of connectors, and possible purposes. The final goal is to provide developers with a board that can truly show off the full potential of the SoC and the whole hardware solution. Everything is tailored to make developers' life easy: the Linux Kernel source code is provided, the hardware components specifications are provided, and the documentation is provided.
The UDOO board we played with in the chapter can be considered close to a reference board. It does not have every possible sensor, but it's easily expandable with external sensors and we know how to communicate with those sensors because the platform is open and easy to debug. An easy way to debug our software and hardware is crucial to make our developing time effective.
UDOO comes with a handy micro-USB connection that is also a Serial-to-USB converter. Using this connection, we can interact with the board at one of the lowest level monitors and manipulate the boot sequence. To properly connect to the board console, we need to install a specific software on our computer: a modem control and terminal emulator named minicom.
You can install it on Ubuntu using apt-get:
$ sudo apt-get install minicom
You can install it on OS X using brew:
$ brew install minicom
When we have minicom, we can connect the turned-off UDOO to the USB port and run the following command on our Terminal:
$ minicom –b 115200 –D /dev/ttyUSB0
ttyUSB0 is the system device that the operating system associated to the UDOO connection. It could be different on your system, that is ttyUSB1, ttyUSB2, according to the hardware configuration, other connected USB devices, and so on. A bit of trial and error could be necessary.
We can now plug the power cable in and turn on the board. If the connection is properly configured, you will see the boot sequence as shown in the following screenshot:
We can monitor the boot sequence and interact with the system in a few interesting ways. The one we are interested in now is stopping the boot sequence and switching to bootloader mode.
During the boot sequence, you will see a message suggesting how to stop the boot sequence itself and access uboot. Once you are in, run fastboot as shown in the following screenshot:
We can now flash the system images we have:
$ fastboot flash system system.img $ fastboot flash boot boot.img $ fastboot flash recovery recovery.img $ fastboot reboot
Having the serial connection still on, when the system reboots, we can enjoy all the system messages that the boot sequence provides: system initialization and Linux kernel loading, until we reach Android loading and finish to Android system console prompt. This is the beauty and the power of having deep access to and knowledge about your system and your hardware. The following screenshot shows a part of the boot sequence in the precise moment of kernel deployment:
