Whether you’re a tech enthusiast or merely curious, diving into Google’s Android Building System makes for intriguing reading.
As Android has grown in complexity and size, the methods for building Android from source have evolved with it. Google has been continuously, improving its Android building systems with all sorts of changes over the years. Even though the original system is still in use, the fact that there are now three Android building systems shows Google's dedication to constant improvement in its development processes.
Building Android yourself, including setting up a robust build environment for Android, is an incredibly complicated process, requiring powerful machines and highly specialized knowledge. However, for those of you curious about the latest breakthroughs in Google’s Android building system, here’s a breakdown of where those systems stand today, and where they’re headed.
What is Android build system?
The Android building system coordinates the process of transforming different source files into an Android ROM. It manages tasks like organizing code, processing resources, and packaging, while calling tools to compile source code into an executable form.
Android Building System #1: Compile source code with GNU Make
Before Android 7.0 (Android Nougat), Google used the GNU Make tool to build an AOSP ROM from source.
GNU Make is a widely used open-source tool for automating the process of compiling source code into executables, along with any necessary non-executable files. To use GNU Make, developers create a configuration file called a Makefile which specifies build rules. The Makefile contains the full list of dependencies and rules to direct the compilation and linking processes.
Android uses Android.mk files, which are Makefiles designed to work within the larger Android building system.
Unfortunately, using GNU Make became slow as Android grew in complexity and increased in features. GNU Make was also error-prone and couldn’t be tested easily.
To solve this, Google moved over to a faster Android building system.
Android Building System #2: Building an Android ROM with Soong, Kati, and Ninja
To replace GNU Make, Google introduced the Ninja build system, which is significantly faster than Make.
The Ninja build system works off Ninja (*.ninja) build files. The Ninja system reads these files’ instructions and then executes each instruction to generate the necessary code files that comprise a complete Android ROM.
Image: Example of Ninja build file syntax.
The primary goal of introducing the Ninja build system was to be fast—or at least faster than the Android building system before. Its design philosophy closely matches Make’s but without the additional unnecessary complexities.
To work with the Ninja system, Google introduced a new type of build configuration file called Android.bp (”bp” stands for blueprint). It also created an internal tool called Soong that converts these blueprint files to Ninja files.
Android.bp files can’t contain any logic, unlike Makefiles, which can. However, the Soong build system allows you to add build logic using the Go programming language.
Unfortunately, it was impossible to completely do away with GNU Make and Makefiles. So, building an Android ROM still required both Android.bp and Android.mk files.
The reason you still need Android.mk files for building ROM from Android source is because Soong doesn’t yet support all the declarations possible in a Makefile, and the Ninja build system doesn’t understand Makefiles.
As a result, Google decided to use an additional tool called Kati, which converts Makefiles into .ninja files.
Image: Kati converts Android.mk files into .ninja files.
Image: .mk and .bp files get converted into .ninja files.
In the end, both .bp files and .mk files get converted into a Ninja build file, and the Ninja build file takes over and builds the ROM you need.
What is the difference between Android BP and MK?
Android.bp (”blueprint”) files contain declarative descriptions in a JSON-like format that Soong converts into Ninja (*.ninja) build files. Android.mk files contain GNU Makefile instructions, which Kati converts into Ninja build files.
Android Building System #3: Building Android from source with Bazel
Google already had an excellent proprietary internal build system called Blaze that it used for other Google products. Blaze offered several advantages for building Android as well, which we’ll talk about in a moment.
Google ported this in-house tool into an open-source build system called Bazel. The company now has a multi-year plan to replace all existing Android building systems (Make, Soong, Kati) with Bazel.
Soong was actually based on Blaze and is therefore already compatible with Bazel.
Bazel is an incredibly versatile and feature-rich build system that provides several advantages over other build systems. One of its most impressive features is that it provides multi-platform support at its core—an essential trait for building Android. Using Bazel, it’s possible to specify many different compilation targets in a much simpler way compared to other tools.
It also has a plethora of other features that make it an excellent choice as the future of Android building systems.
Bazel works excellently for both building client and server software including client applications for Android and iOS. But it still needs further improvements to replace Soong as the standard Android building system.
One of the major challenges of adapting Bazel to be used with the Android Open Source Project (AOSP) is that AOSP code trees can be so varied because of multiple devices and manufacturers. Bazel was initially developed to work within the relatively homogenous ecosystem of Google’s internal monorepo—a single code repository with many projects—instead of “out in the wild.”
Bazels’ stable open-source version has been available since October 2019. However, being able to build custom Android ROMs using Bazel isn’t yet possible. Building AOSP doesn’t include building the kernel or bootloaders necessary for Android to run on your chosen hardware. It only builds the Android-specific code.
You can currently build the Android Common Kernel with Bazel as of Android 13, but that’s not the same as building AOSP.
Empowering your Android project
The procedure for building Android is complex in itself, but even more complex are the steps that come before that.
Navigating the challenges in Android development
Imagine you need to modify something in AOSP, where there are over 1,200 projects, and over 14,000 Makefile, Blueprint, and Bazel files. You’d need to know how to find the right project, what syntax to use, and how to resolve dependencies. You also need to know how to maintain it when the next release is presented, and everything must be changed again.
Additionally, you must also ensure you have a functioning Android board support package (Android BSP) for the device you’re using.
The process of modifying and building is then repeated for all new devices and prototypes you create.
After flashing Android onto the device you’ll be using, you also need to ensure that device receives Over-the-Air software updates, which likewise require the Android building system to build yet another version of Android. Many embedded Android devices depend on OTA updates for security because updating them manually is usually unfeasible. Therefore, a whole update infrastructure is needed.
Collaborating with Android experts
Emteria supports companies in customizing and building Android OSes that fit their product requirements. This includes running Android on specifically chosen hardware configurations. Additionally, emteria has the necessary infrastructure in place to provide seamless OTA updates for firmware, apps, and Android itself.
Android has become a major force in the embedded and IoT (Internet of Things) sectors. The operating system is user-friendly, familiar, and reliable, thereby lending itself to a wide variety of use cases.
Android’s popularity means that a large number of support services, such as emteria’s automated and scalable solutions for all Android customization needs, now exist. This makes it unnecessary for companies to lose time and money directly editing Android code, instead focusing on product development and rapid prototyping to stay competitive.
To learn more about how emteria can modify Android according to your specific use cases, book a live demo. ⬇️
Build unique Android products, keep them up-to-date
See why emteria is the chosen Android™ customization & management platform for product builders — build Android products based on your requirements.
Table of contents
