1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
# Android's build system is messier than your distro's
The first step in the development of an Android distribution is coming to terms
with the Android Open Source Project (AOSP) peculiar build system. Despite
modular, AOSP's build system is quite complex and unlike those used in most
other distributions. For instance, it lacks the concept of packages and expects
sub-projects to be explicitly made compatible with it.
## AOSP build system internals
Until version 7 AOSP used a Makefile based system which, in contrast to other
Make based build systems, didn't rely on recursive Makefiles that find and
invoke other Makefiles contained in subdirectories. Rather, it used a custom
script that explores all subdirectories in the source directory in search of
Android.mk files, which describe how a local module is built and handled. The
configuration of this system also differed from others such as GNU autotools or
kernel-style menuconfig, relying instead on variables that are set either as
part of the shell environment or statically and ahead of time on product and
device Makefiles.
As AOSP got larger this system became slow, error prone and hard to scale and
test. To fix this, the Makefile-based system is getting replaced by Soong. Soong
replaces Makefiles with Blueprint files, simpler declarative JSON-like
descriptions of modules, that get translated into a Ninja manifest describing
the commands that need to be run. This approach takes advantage of Ninja's
outstanding performance while sparing developers from it's complex build
language. During the transition period the remaining Makefiles are translated
to Ninja by Kati instead of being executed directly.
The transition to Soong solved the performance issue of AOSP's builds but got
short of taking it closer to the modularity and flexibility found in most
GNU/Linux distributions.
## Building AOSP vs building GNU/Linux distros
Virtually all GNU/Linux distributions use package managers when building their
software. They wrap around the build system being used by the software
(Makefiles, autools, cmake, etc) and bundle the output in a reusable package.
While such packages can usually be installed by the user, and are typically
delivered and updated via software repositories, it is not always the case.
For instance, it is possible to create OpenWRT images lacking a package manager.
In the AOSP build system, no package manager is used to build the
system components. Instead, most software components are built from git
repositories and bundled into a single image that includes the majority of the
distribution. The output of the build ends up in a directory, which is then
compressed into a distribution image and later installed on a device.
Besides the core components of AOSP, community distributions tend to use several
external projects like Mesa. These must usually be integrated into the build
tree as they depend on AOSP's libc. In such cases, Google expects the project
maintainers to make and keep their project compatible with AOSP's build system,
i.e. nowadays they expect the project to have its own Blueprint files.
This contrasts with GNU/Linux distributions, which provide ways to build each
project in its own native build system and then incorporate it into the distro
image as an independent package.
## Replicant's stake
Replicant, a fully free-software AOSP distribution, is now undergoing intense
work to make it as sustainable as possible by sharing code with GNU/Linux
distributions. For instance, Replicant's next release (Replicant 9) is being
developed on top of mainline Linux and Mesa.
This comes with the disadvantage of having to deal with the unsuitability of AOSP
build system to handle external projects. Long hours of development time are
lost due to the incapability of AOSP to detect changes in projects that haven't
been converted to Blueprint, such as Linux, Mesa or SwiftShader.
Adding and maintaining Blueprint support in all external software components,
for multiple Android versions, can be incredibly time consuming and could even
be unsustainable.
More importantly, the future of all Android distributions are very seriously
threatened by the lack of package manager in the build system. Packages
definitions typically have a license field. Instead, as Android doesn't use
packages during the build process, and as all its git repositories are checked
out under a single directory, there is no easy way to keep track of the list of
licenses that are used.
Replicant is thus seeking to discuss and ultimately decide on a sustainable way
to deal with external software components.
To really fix these issues, it would be crucial to make Android support some
form of packages during the build.
|
