At this point, we have our copy of AOSP so we can start looking inside to see what the project consists of.
Before delving inside, we must warn you that, when generating a new build image from scratch, you won't find any of the Google applications that you can find on most of the Android devices. That is because the Google applications are not licensed under Apache 2.0 license, so they are not provided with the public project. We are talking about applications such as Play Store, Gmail, YouTube, Maps, and all other official Google apps.
These applications are provided only to the compatible devices, that is, the devices that pass the Compatibility Test Suite we met in the first chapter.
Being able to distribute an Android device with all Google's app on-board is no easy trip. After confirming that the device is compatible using CTS, it is also necessary to obtain a particular Google Mobile Services (GMS) license by contacting Google directly.
Obviously, you can find those applications in their binary form on the Internet and add it like that to your build. It's not the official way to achieve the goal and we support a cleaner conduct to distribute our awesome device, but is worth mentioning that there are blurry shortcuts.
Going back to our source code, let's take a look inside our WORKING_DIRECTORY and see where we can find the basic Android components that AOSP is composed of.
The next screenshot shows a clear overview of all the folders contained in the root directory:
One of the most important folders is surely art/. It contains the source code for the new Runtime Environment, designed and devolved by Google.
ART is an acronym of Android RunTime and it has been introduced in the Android 4.4 Kitkat as an alternative to the Dalvik Virtual Machine. It has completely replaced Dalvik in Android 5.0 Lollipop. The old Dalvik VM was based on a Just-In-Time (JIT) compiler technology, that is, it interprets and compiles an application source code into machine code in real time. This implementation has its advantages, but also disadvantages since runtime compilation certainly impacts system performance.
ART is based on an AOT (Ahead-of-time) technology, which compiles all the application code at the time of application installation, that is, before the execution. That obviously requires more time to install the application, but that time is usually imperceptible seeing the hardware performance of the latest Android devices.
Bionic is the C-runtime for Android. Unlike most Linux distributions, Android doesn't use the GNU C library (glibc). The main differences between the GNU C library and bionic is the license— glibc is distributed under the GPL license while bionic has the BSD license. A more permissive license is crucial in a world so commercially oriented.
Other very important features are the lightness and the size. Bionic is much smaller than glibc, which makes it more usable for embedded systems such as cell phones. Also, it has been made having in mind low-performance processors, so it performs better.
A big part of the bionic source code comes from the OpenBSD project, but there are also some parts, such as pthread and the dynamic linker, that have been written from scratch, to be sure to meet the performance, lightness, and flexibility requirements.
This directory contains the whole Android build system. It contains all the makefile core templates.
Besides that, it contains envsetup.sh, a script that allows the developer to work with Android sources without struggling with environment management. We will explain it in more detail later in the book, but in short, launching this script gives you various utilities that enable you to perform various operations on the source code, for example, compile specific modules or perform searches on specific files such as on all .java files, and so on.
All the packages regarding open source projects used by Android can be found in this directory. It contains various libraries as well as very important utilities such as zlib, SQLite, and webkit.
Here you can find all the configurations and definitions for specific devices. The following screenshot gives an overview of the content. As you can see, it's full of folders with names of well-known manufacturers:
There are all the definitions for the official Google devices, that is for all the Nexus devices, but there are also other directories such as:
common: This directory contains certain information about the GPS and a script that allows you to extract the binary parts regarding a specific device so that they can be included in the image build.generic: This directory contains the configuration for the generic device called "goldfish" and is used to build the emulator image.google: This directory contains the code for the Accessory Development Kit (ADK). It also contains a DEMOKIT Android app that allows you to control the ADK board. ADK is a reference implementation for hardware manufacturers and hobbyists that can be used as a starting point for making Android accessories;sample: This directory contains a complete example of how to write your own shared library for Android, without modifying the Android framework. It also shows how to write JNI code to be included in the library, and a client application that uses such a library.
This folder is very important because it contains the source code for the Android framework. It is here that you can find all the main components of Android such as Activity, Services, and so on. Here you can also find the mapping used between the native code in C/C++ and the code in Java.
As intuitive as it can sound, when the build is done, the result of the compilations is in this directory. Here we will find images that are ready to be flashed on our device or emulator, under named subdirectories, such as out/product/generic/ for the emulator image. In one of its subfolders, in the out/host/linux-x86/, you can also find all the tools that are needed from the host side, such as fastboot, zipalign, dexdump, and so on.
As the folder name says, here you can find all the standard Android application packages, for example, Camera, Calculator, Dialer, Launcher, Settings, and so on. Once again, these are not Google apps such as YouTube or Maps, but just the system apps that are common to every Android installation.
The system/ directory contains the source code of the Android system core, that is a minimal Linux system that takes care of the initialization of the device before the ART virtual machine starts any Java-based service.
Inside this folder, you can find the source code for the init process and the relative init.rc default script that initializes and dynamically configures the platform, as well as applications such as Toolbox (the Android alternative to BusyBox) and the source codes for the adb and fastboot utilities that we will explain in more detail in the coming chapters.
Here are the remaining folders that are part of the AOSP:
abi: This is the source file forlibgabi++.bootable: This includes the boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.cts: This directory contains the code for the compatibility test suite.dalvik: This directory contains the code for the Dalvik virtual machine.development: This directory contains development tools—the source code of the SDK and the NDK.docs: This directory contains the documentation relative to the Android Open Source Project. It contains a subfolder calledsource.android.com, which contains all the required files to generate the static HTML. You can see the result of the build at http://source.android.com/.Note: This directory is the online version that often doesn't coincide with the one present in the AOSP.hardware: This folder contains HAL (Hardware Abstraction Layer), libraries that enable interfacing with the device hardware.libcore: This directory contains Apache Harmony.ndk: This directory contains the script to generate the Native Development Kit, that allows the use of the native code written in C/C++ from Android applications.pdk: This is the Platform Development Kit, a set of utilities that Google sends to various OEMs so that they can update their own frameworks before important system updates.prebuilts: This directory contains precompiled files, including various toolchain versions.sdk: This is the Software Development Kit.tools: These are some external IDE tools.