The Android philosophy

Android is an open source platform created to be compatible with a huge number of different devices, from a hardware point of view to a purpose point of view. The main goal is to provide a freely available software platform for both large enterprise companies and small independent makers or even single developers. Android aims to provide an easy way to create innovative solutions and bring them to market with no effort.

Everything started in 2005, when Google acquired Android Inc., a small company that was developing an operating system for mobile devices. A couple of years later, the Open Handset Alliance was born. In 2007, 84 companies, including mobile operators, handset manufacturers, and semiconductor and software companies, publicly announced their brand new, upcoming mobile operating system.

For one more whole year the project was kept a secret. Google worked hard to bring the project to version 1.0 and in 2008 Android was shown to the world. In the following seven years, four major versions of the system have been released. The following table tells the chronological history of all the Android versions. Every single version was released as open source software to the world. Every version, but Honeycomb, that was an ugly PR slip for Google, which spent a lot of energy to bring it down and replace it with Ice Cream Sandwich as soon as possible:

The license

Creating an open source platform brings in a few concerns about which license gives the perfect balance between protection and freedom. The goal is to give manufacturers enough freedom to adapt the system to their own hardware without being scared of dark licenses, trying to steal their intellectual property. To reach this goal, Google picked one of the most famous open source licenses available at the time and applied it to most parts of the operative system.

The license that Google uses to protect the Android Open Source Project (AOSP) is the Apache Software License, Version 2.0, also known as Apache 2.0, and it covers almost every line of code published to AOSP. The Apache 2 license doesn't apply to one big system component—the kernel. Linux Kernel is protected by GNU Public License, V2, and it comes with a system exception to be able to be shipped with Android.

Being open source and being easily adaptable to popular hardware, it launched Android to the top of the mobile market at rocket speed, reaching one billion active devices all over the world with over one million apps available on the Google Play Store. One billion active devices is the result of a winning strategy—providing manufacturers with a software solution for their hardware, easy to integrate and customize, coming free of charge and community supported, in a market that was dominated by Apple.

Open source, closed doors

A closer look at the project shows how Android is slightly different from other open source projects: Android is developed by Google behind closed doors. Lots of people in the community don't agree about considering Android as open as Linux is. In fact, the two approaches are completely different. Yes, both of them have an open source license, but Linux is a community-developed project, Android, instead, is completely developed by Google.

Every technical discussion, every decision, every roadmap step is decided by Google. When the development life cycle completes, Google releases a new version of the operative system, updates the public source code repository and everybody is able to download the latest version of the OS.

Of course, there are e-mailing lists for discussion and support and there are a few ways to contribute to the project, but everything is decided by the Android development team.

The Android development model

To assure the stability of the Android current release, Google keeps the source code in code lines. This approach provides a proper mechanism to keep separated the current stable version, available on all latest devices, from the currently under development, unstable version. As you may easily notice, Google is using a different naming convention for Android compared to the usual nomenclature of open source projects—code line is used instead of branch, because a single code line can be based on multiple git branches.

The following diagram shows how the source code history evolves over time, through different branches and releases:

The previous diagram shows the main public branch, Upstream, on the left. This branch is the main public development branch where all the critical bug fixes are released constantly, and where all the main experimentation with new devices and new technology is performed. Every developer or manufacturer can obtain this set of source code and start to create their own Android device.

On the right side of the diagram, we can see Google's private branch. This branch contains the Android next version. Generally, all the development is done by Google itself, with the support of a hardware partner that provides a reference device. Typically, this device is a high-end, top-class device that Google appoints as Google's next reference device, also known as Nexus. Every new Nexus has been chosen keeping in mind Google Android's development roadmap—every technical hardware specification supports or discourages particular software development, to create the perfect symbiosis between the device and the operating system.

When the internal development reaches the desired stable point, the new version is released, every branch is updated accordingly and a new public/private development cycle begins, once again.

Source code tags and builds

To effectively refer to a specific Android version, every public release, since Android 1.5, comes with a fancy pop codename, a version number, and a more developer-oriented API level.

The following table shows how the correspondence between codename/version/API level is not always a one-to-one relationship. Most of the time, the code name has a longer life cycle than the version number:

Nexus

The Nexus family contains all those Android devices that Google designs, produces, and sells, with the help of its hardware manufacture partners.

One of the peculiarities of the Nexus family is the bare Android system it equips the device—there is no customization of any sort, neither from the manufacturer nor from the telephone carrier. The system is based on pure Android source code, providing the user with the purest Android experience. As an advanced note, the device bootloader can be easily and legally unlocked, to allow every sort of modification any expert user could desire. Security-wise, the Nexus devices are the first ones that receive security fixes and system updates—stay updated, stay safe!

The Nexus family is continuously growing in numbers and quality and it now contains smartphones, tablets, and even digital players. The upcoming tables show an overview on all the currently available models.

Phones

Here is a list of all stock Nexus phones:

Tablets

Here is a list of all stock Nexus tablets:

Digital media players

Here is a list of all stock Nexus digital media players:

Every single device in these tables has its own Android build, specifically tailored for its hardware and purpose. The following table is an example of builds code names and versions that Google provides for all the expert Android users who want to manually replace the operative system and want to retrieve the official build by Google:

Every build is identified by a build-code, for instance, LMY470. The first letter is the initial letter of the code name, for instance, Lollipop; the second letter identifies the branch used to produce this build; the following two letters identify the release date, based on quarters notation—A is Q1 2009, F is Q2 2010, and so on. The two numbers following the quarter letter specify the release day. The last letter identifies the build number. This notation is not critically precise. Google often reuses the same build code for more than one build. We need to consider it as a rough estimation of the release date.

Source code tools

Android is a huge project, with an astonishing amount of source code. Google itself manages the source code and stores it on its servers which are publicly accessible to the developers and advanced users.

Considering the complexity of the project, we will need only two tools to retrieve the source code:

• git
• repo

Let's have a quick overview on these powerful tools that will accompany us during our journey.

Git

Git is currently the most popular source code version control system, openly available in the world. It's an impressive tool created by Linus Torvalds (yes, the same Linus Torvalds who created the Linux kernel contained in Android).

In 2005, Torvalds was struggling to find a proper way to manage the amount of code and contributions from the developers who were working on its Linux kernel. No tool available at that time was enough and, in a few days, he created the first working version of his new distributed revision control system that was able to manage a huge project with speed and flexibility.

Git provides effective and easy-to-achieve solutions for modular systems and Google takes full advantage of this opportunity. Every contribution to the Android code base is provided using git features—commits, branches, and patches.

The system is kept as modular as possible to allow developers and OEM to extract and replace components that need to be customized. Knowing this, it's easy to guess how many git repositories Android contains—dozens of interconnected repositories of different sizes and structures.

Repo

To overcome the difficulty of managing a plethora of different repositories, Google created git-repo, a tool written in Python that acts like a coordinator upon git and allows automation of some common parts of the workflow.

Repo comes in handy in a lot of scenarios. Most of all, all those network operations that involve the source code: retrieving, updating, and pushing the code to the remote servers. Repo is a pivot tool and we will learn a lot about it in the next sections.

Gerrit

Worth mentioning, Gerrit is the code review tool used to evaluate and approve every contribution made to AOSP. It provides a graphical user interface to monitor the evolution of the code base and represent the central point where all the contributions end before being accepted and merged into the main code base, or rejected if the review resolves in a no, th anks.