Zusammenfassung: In diesem Abschnitt wird hauptsächlich die Einführung in das Android10.0-Kompilierungssystem erläutert.
1. Übersicht
Vor Android 7.0 verwendete das Android-Kompilierungssystem GNU Make-Beschreibungen und Shells, um Kompilierungsregeln zu erstellen. Moduldefinitionen wurden mit Android.mk definiert. Die Essenz von Android.mk ist Makefile. Je größer Android-Projekte jedoch immer größer werden, desto größer werden auch die Module immer komplexer. Die Kompilierungszeit der von Makefile organisierten Projekte wird immer länger. Die Google-Ingenieure glauben, dass es nicht funktionieren wird, wenn das so weitergeht, und es muss optimiert werden.
Daher verwendete Google ab Android 7.0 Ninja, um das zuvor verwendete Make zu ersetzen. Da die vorherigen Android.mk-Daten so groß waren, fügte Google ein Kati-Tool hinzu, um Android.mk in eine Ninja-Build-Regeldatei zu konvertieren. buildxxx.ninja und Dann verwende Ninja zum Bauen.
Ninjas Website-Adresse: https://ninja-build.org
Die Kompilierungsgeschwindigkeit ist etwas schneller, aber wenn Sie es tun möchten, dann tun Sie es im großen Stil. Das ultimative Ziel ist es, make zu ersetzen. Um Makefile weiter zu eliminieren, hat Google ab Android 8.0 Android eingeführt. bp-Datei, um die vorherige zu ersetzen. Android.mk.
Android.bp ist nur eine reine Konfigurationsdatei, ausgenommen Steuerprozesse wie Verzweigungen und Schleifenanweisungen. Es handelt sich im Wesentlichen um eine JSON-Konfigurationsdatei. Android.bp wird über Blueprint + soong in Ninjas Build-Regeldatei build.ninja konvertiert und dann wird Ninja zum Erstellen der Arbeit verwendet.
Unter Android 10.0 kann die Liste der kompilierten MK- und BP-Dateien in Android.bp.list und Android.mk.list in \out\.module_paths eingesehen werden. In Android 10.0 gibt es immer noch mehr als 400 MK-Dateien, die noch nicht kompiliert wurden ersetzt. Google hat noch einen langen Weg vor sich.
Entwicklungsprozess der Android-Kompilierung:
-
Verwenden Sie GNU Make vor Android7.0
-
Android7.0 führt Ninja, Kati, Android.bp und bald Build-Systeme ein
-
Android8.0 öffnet standardmäßig Android.bp
-
Android9.0 erzwingt die Verwendung von Android.bp
Google führte das Soong-Build-System nach Android 7.0 ein, um Make zu ersetzen. Es verwendet das Kati GNU Make-Klon-Tool und Ninja-Build-Systemkomponenten, um Android-Builds zu beschleunigen.
Das Make-Build-System wird weitgehend unterstützt und verwendet, ist jedoch langsam, fehleranfällig, nicht skalierbar und auf Android-Ebene schwer zu testen. Das Soong-Build-System bietet genau die Flexibilität, die Sie für Android-Builds benötigen.
Kompilierungsprozess des Android-Systems:
2 Kompilierungsprozess
2.1 Kompilierungsstruktur
Das Kompilierungsverzeichnis von Android befindet sich in /build. Schauen Sie sich das Build-Verzeichnis im Android 10- Quellcode an. Es sieht jetzt so aus:
In diesem Verzeichnis können Sie sehen, dass der Kernordner mit make/core und envsetup.sh mit make/envsetup.sh verknüpft ist. Dies dient hauptsächlich dazu, Benutzer vor den Unterschieden beim Wechsel des Kompilierungssystems zu schützen.
Hier konzentrieren wir uns auf vier Ordner: Blueprint, Kati, Make, Soong
Blaupause: Wird zum Verarbeiten von Android.bp, zum Kompilieren und Generieren von *.ninja-Dateien und zur Ninja-Verarbeitung verwendet
Kati: Wird zum Verarbeiten von Android.mk, zum Kompilieren und Generieren von *.ninja-Dateien und zur Ninja-Verarbeitung verwendet
make: Der Ordner ist immer noch der ursprüngliche Make-Prozess, z. B. envsetup.sh
soong: System erstellen, der Kern wird in soong_ui.bash kompiliert
Die Familienmitglieder des Soong-Kompilierungssystems und ihre Beziehungen sind in der folgenden Abbildung dargestellt:
Während des Kompilierungsprozesses wird Android.bp in out/soong/build.ninja.d gesammelt und Blueprint generiert darauf basierend out/soong/build.ninja.
Android.mk wird von kati/ckati als out/build-aosp_arm.ninja generiert
Die beiden Ninja-Dateien werden in out/combined-aosp_arm.ninja integriert
Der Inhalt von out/combined-aosp_arm.ninja ist wie folgt:
builddir = out
pool local_pool
depth = 42
build _kati_always_build_: phony
subninja out/build-aosp_arm.ninja
subninja out/build-aosp_arm-package.ninja
subninja out/soong/build.ninja
2.2 Kompilierungsschritte
Quelle build/envsetup.sh
Lunch aosp_arm-eng // oder m PRODUCT-aosp_x86_64-eng, Android10.0 erfordert nicht unbedingt den Lunch-Befehl
make -j8 // Sie können m libart auch direkt zum Kompilieren des Moduls verwenden
Die Kompilierungsschritte für Android10.0 sind in der folgenden Abbildung dargestellt:
3 Initialisierung der Kompilierungsumgebung
3.1 Envsetup-Beschreibung
Der erste Schritt der Kompilierung erfordert die Initialisierung der Umgebungsvariablen, die mit dem folgenden Befehl abgeschlossen wird:
source build/envsetup.sh
Die Datei envsetup.sh ist hier mit build/make/envsetup.sh verknüpft
envsetup.sh erledigt hauptsächlich die folgenden Dinge:
Geben Sie nach der Quelle build/envsetup.sh hmm ein, um einige von envsetup unterstützte Schnittstellen anzuzeigen:
| Leben machen |
veranschaulichen |
| Mittagessen |
Mittagessen <Produktname>-<Build_Variante> Wählen Sie <product_name> als zu erstellendes Produkt und <build_variant> als zu erstellende Variante aus und speichern Sie diese Auswahl in der Umgebung, damit spätere Aufrufe von „m“ usw. gelesen werden können. |
| Tapas |
Interaktionsmethode: tapas [<App1> <App2> ...] [arm|x86|mips|arm64|x86_64|mips64] [eng|userdebug|user] |
| croot |
Wechseln Sie in die Verzeichnisse oben im Baum oder in dessen Unterverzeichnisse. |
| M |
Kompilieren Sie den gesamten Quellcode, ohne in das Stammverzeichnis zu wechseln |
| mm |
Kompilieren Sie den Quellcode im aktuellen Verzeichnis, ohne die abhängigen Module |
| mmm |
Kompilieren Sie alle Module im angegebenen Verzeichnis, mit Ausnahme ihrer abhängigen Module. Beispiel: mmm dir/:target1,target2. |
| mma |
Kompilieren Sie den Quellcode im aktuellen Verzeichnis, einschließlich der abhängigen Module |
| mmma |
Kompilieren Sie alle Module im angegebenen Verzeichnis, einschließlich ihrer abhängigen Module |
| Bestimmung |
Flash-Gerät mit allen erforderlichen Partitionen. Optionen werden an Fastboot übergeben. |
| cgrip |
Führen Sie den grep-Befehl für alle lokalen C/C++-Dateien im System aus |
| ggrep |
Führen Sie den grep-Befehl für alle lokalen Gradle-Dateien im System aus |
| greifen |
Führen Sie den grep-Befehl für alle lokalen Java-Dateien im System aus |
| Griff |
Führen Sie den grep-Befehl für die XML-Dateien in allen res-Verzeichnissen lokal auf dem System aus |
| mangrep |
Führen Sie den grep-Befehl für alle lokalen AndroidManifest.xml-Dateien im System aus |
| mgr |
Führen Sie den grep-Befehl für alle lokalen Makefiles-Dateien im System aus |
| sepgrep |
Führen Sie den Befehl grep für alle lokalen Sepolicy-Dateien im System aus |
| Griff |
Führen Sie den grep-Befehl für alle lokalen Quelldateien im System aus |
| wird angehoben |
Durchsuchen Sie das gesamte Verzeichnis gemäß dem Parameterdateinamen nach Godir und wechseln Sie das Verzeichnis |
| allmod |
Listen Sie alle Module auf |
| gomod |
Gehen Sie in das Verzeichnis, das das Modul enthält |
| Pfadmod |
Rufen Sie das Verzeichnis ab, das das Modul enthält |
| Aktualisierungsmod |
Aktualisieren Sie die Modulliste von allmod/gomod |
3.2 Beschreibung des Mittagessens
Nachdem die Umgebungsvariablen initialisiert wurden, müssen wir ein Kompilierungsziel auswählen. Die Hauptfunktion von Lunch besteht darin, Umgebungsvariablen für bestimmte Produkte basierend auf dem vom Benutzer eingegebenen oder ausgewählten Produktnamen festzulegen.
Wenn Sie nicht wissen, welches Ziel Sie kompilieren möchten, führen Sie einfach einen Lunch-Befehl aus und alle Ziele werden aufgelistet. Drücken Sie einfach die Eingabetaste und das Ziel aosp_arm-eng wird standardmäßig verwendet.
Führen Sie den Befehl aus: Mittagessen 1. Sie können einige konfigurierte Umgebungsvariablen sehen
Die Bedeutung dieser Umgebungsvariablen ist wie folgt:
| Ergebnisse des Mittagessens |
veranschaulichen |
| PLATFORM_VERSION_CODENAME=REL |
Gibt den Namen der Plattformversion an |
| PLATFORM_VERSION=10 |
Versionsnummer der Android-Plattform |
| TARGET_PRODUCT=aosp_arm |
Kompilierter Produktname |
| TARGET_BUILD_VARIANT=userdebug |
Art des zusammengestellten Produkts |
| TARGET_BUILD_TYPE=Veröffentlichung |
Kompilierungstyp, Debug und Release |
| TARGET_ARCH=arm |
Stellt die CPU- Architektur des Kompilierungsziels dar |
| TARGET_ARCH_VARIANT=armv7-a-neon |
Gibt die CPU-Architekturversion des Kompilierungsziels an |
| TARGET_CPU_VARIANT=generisch |
Stellt den CPU-Codenamen des Kompilierungsziels dar |
| HOST_ARCH=x86_64 |
Stellt die Architektur der Kompilierungsplattform dar |
| HOST_2ND_ARCH=x86 |
Stellt die zweite CPU-Architektur der Kompilierungsplattform dar |
| HOST_OS=linux |
Stellt das Betriebssystem der Kompilierungsplattform dar |
| HOST_OS_EXTRA=Linux-4.15.0-112-generic-x86_64-Ubuntu-16.04.6-LTS |
Zusätzliche Informationen außerhalb des Build-Systems |
| HOST_CROSS_OS=Windows |
|
| HOST_CROSS_ARCH=x86 |
|
| HOST_CROSS_2ND_ARCH=x86_64 |
|
| HOST_BUILD_TYPE=Veröffentlichung |
Kompilierungstyp |
| BUILD_ID=QQ1D.200205.002 |
BUILD_ID erscheint in den Versionsinformationen und kann verwendet werden |
| OUT_DIR=out |
Pfad zur Kompilierungsergebnisausgabe |
4. Machen Sie Anweisungen
Nachdem Sie den Lunch-Befehl ausgeführt haben, können Sie den Befehl make verwenden, um den Kompilierungs-Build auszuführen.
Android 10.0 kompiliert und erstellt bis bald. Wenn der Befehl make hier ausgeführt wird, wird make() in envsetup.sh zur Kompilierung ausgeführt, nachdem die Datei main.mk einige Umgebungsvariablen und Ziele konfiguriert hat.
Wenn „build/soong/soong_ui.bash“ gefunden wird, verwenden Sie soong_ui.bash zum Kompilieren, andernfalls verwenden Sie zum Kompilieren den ursprünglichen Befehl make.
function make()
{
_wrap_build $(get_make_command "$@") "$@"
}
function get_make_command()
{
# If we're in the top of an Android tree, use soong_ui.bash instead of make
if [ -f build/soong/soong_ui.bash ]; then
# Always use the real make if -C is passed in
for arg in "$@"; do
if [[ $arg == -C* ]]; then
echo command make
return
fi
done
echo build/soong/soong_ui.bash --make-mode
else
echo command make
fi
}
Konfigurieren Sie einige Ressourcenumgebungen und rufen Sie einige Funktionsbefehle ab, z. B. soong_build_go. Kehren Sie schließlich zum Stammverzeichnis zurück und führen Sie out/soong_ui --make-mode aus, um den eigentlichen Build durchzuführen.
soong_build_go soong_ui android/soong/cmd/soong_ui wird kompiliert von
android/soong/cmd/soong_ui/main.go zum Kompilieren und Generieren von Soong_ui.
[build/soong/soong_ui.bash]
# Save the current PWD for use in soong_ui
export ORIGINAL_PWD=${
PWD}
export TOP=$(gettop)
source ${TOP}/build/soong/scripts/microfactory.bash
soong_build_go soong_ui android/soong/cmd/soong_ui
cd ${TOP}
exec "$(getoutdir)/soong_ui" "$@"
“echo build/soong/soong_ui.bash --make-mode ”
Abschließend wird exec out/soong_ui --make-mode zur Kompilierung ausgeführt.
Der Kompilierungsprozess von Soong ist in der folgenden Abbildung dargestellt:
Beim Ausführen von runKatiBuild ist ein wichtiger Schritt das Laden von build/make/core/main.mk. Die Datei main.mk ist die Hauptsteuerdatei des Android Build-Systems. Ausgehend von main.mk werden alle erforderlichen .mk-Dateien über den Befehl include eingebunden und schließlich eine Sammlung aller kompilierten Skripte im Speicher erstellt, was einem riesigen Makefile entspricht. Die Makefile-Datei sieht sehr groß aus, besteht aber tatsächlich hauptsächlich aus drei Arten von Inhalten: Variablendefinitionen, Funktionsdefinitionen und Zielabhängigkeitsregeln. Darüber hinaus ist auch die Einbindung zwischen MK-Dateien sehr wichtig.
Die Einschlussbeziehung von main.mk ist in der folgenden Abbildung dargestellt:
Einige wichtige MK-Dateibeschreibungen:
| dokumentieren |
veranschaulichen |
| build/make/core/main.mk |
Die Hauptsteuerdatei von Build wird hauptsächlich verwendet, um andere mk einzubinden, mehrere wichtige Kompilierungsziele zu definieren und die Versionen von Kompilierungstools wie GCC, Clang, Java usw. zu überprüfen. |
| build/make/core/config.mk |
Die Konfigurationsdatei von Build unterscheidet hauptsächlich die Konfiguration jedes Produkts, führt diese Compiler-Parameter in die Produktkonfiguration BoardConfig.mk ein und konfiguriert auch einige Compiler-Pfade usw. |
| build/make/core/clang/config.mk |
clang kompilierte Konfigurationsdatei |
| build/make/core/definitions.mk |
Eine der wichtigsten Make-Dateien, in der eine Vielzahl von Funktionen definiert sind. Diese Funktionen werden von anderen Dateien im Build-System verwendet. Zum Beispiel: my-dir, all-subdir-makefiles, find-subdir-files, sign-package usw. Beschreibungen dieser Funktionen finden Sie in den Codekommentaren der einzelnen Funktionen. |
| build/make/core/dex_preopt.mk |
Definiert Pfade und Parameter im Zusammenhang mit der Dex-Optimierung |
| build/make/core/pdk_config.mk |
Kompilieren Sie die PDK-Konfigurationsdatei |
| build/make/core/Makefile |
Die verschiedenen Ziele und Regeln, die für die endgültige Zusammenstellung des Systems erforderlich sind |
| build/make/core/envsetup.mk |
Fügen Sie die Datei „product_config.mk“ ein und legen Sie die erforderlichen Umgebungsvariablen fest, um das Produkt entsprechend seinem Inhalt zu kompilieren, die Rechtmäßigkeit zu überprüfen, den Ausgabepfad anzugeben usw. |
| build/make/core/combo/select.mk |
Wählen Sie die plattformbezogene Make-Datei basierend auf der aktuellen Compiler-Plattform aus |
| build/make/core/ninja_config.mk |
Analysieren Sie die Liste der Makefiles, übergeben Sie sie an Kati, konfigurieren Sie die an Ninja und Kati übergebenen Ziele |
| build/make/core/soong_config.mk |
Konfigurieren Sie die Umgebungsvariablen von Soong und stellen Sie eine JSON-Zuordnungsbeziehung zwischen Go-Variablen und MK-Variablen her, damit Go-Variablen die in MK definierten Variablenwerte erhalten können. |
5. Anweisungen zur Kompilierungstoolkette
Das Kompilierungssystem von Android 10.0 umfasst die folgenden Toolketten. Diese Toolketten ergänzen sich, um schließlich die von uns benötigte Bildversion zu kompilieren.
Android10.0-Kompilierungstoolkette:
soong\kati\blueprint\ninja
5.1.Schnelle Anweisungen
Das Soong-Build-System wurde in Android 7.0 (Nougat) eingeführt und sollte Make ersetzen. Es nutzt das Klon-Tool Kati GNU Make und Ninja-Build-Systemkomponenten, um Android-Builds zu beschleunigen.
Soong ist ein in der Go-Sprache geschriebenes Projekt. Ab Android 7.0 wurde die für die Go-Sprache erforderliche Laufumgebung im Verzeichnis prebuilts/go/ hinzugefügt. Soong wird während der Kompilierung verwendet, um Android.bp zu analysieren und in eine Ninja-Datei zu konvertieren. , vollständige Android-Auswahl und -Kompilierung, Parsing- und Konfigurationsarbeiten usw. Daher entspricht Soong dem Kern des Makefile-Kompilierungssystems, dh dem Inhalt unter build/make/core.
另外Soong还会编译产生一个androidmk命令，可以用来手动将Android.mk转换成Android.bp文件。不过这只对无选择、循环等复杂流程控制的Android.mk生效。
soong脚本和代码目录：/build/soong
5.2.kati说明
kati是一个基于Makefile来生成ninja.build的小项目。主要用于把Makefiel转成成ninja file，自身没有编译能力，转换后使用Ninja编译。
在编译过程中，kati负责把既有的Makefile、Android.mk文件，转换成Ninja文件。在Android 8.0以后，它与Soong一起，成为Ninja文件的两大来源。Kati更像是Google过渡使用的一个工具，等所有Android.mk都被替换成Android.bp之后，Kati有可能退出Android编译过程.
在单独使用时，它对普通的小项目还能勉强生效。面对复杂的、多嵌套的Makefile时，它往往无法支持，会出现各种各样的问题。当然，也可以理解为，它只为Android而设计。
kati脚本和代码目录：/build/kati
5.3.blueprint说明
Blueprint由Go语言编写，是生成、解析Android.bp的工具，是Soong的一部分。Soong则是专为Android编译而设计的工具，Blueprint只是解析文件的形式，而Soong则解释内容的含义。
在Android编译最开始的准备阶段，会执行build/soong/soong_ui.bash进行环境准备。
对blueprint项目编译完成之后会在out/soong/host/linux-x86/bin目录下生成soong编译需要的5个执行文件(bpfix,bpfmt,bpmodify,microfatory,bpmodify)。
Soong是与Android强关联的一个项目，而Blueprint则相对比较独立，可以单独编译、使用。
blueprint代码目录：/build/blueprint
5.4.ninja说明
最开始，Ninja 是用于Chromium 浏览器中，Android 在SDK 7.0 中也引入了Ninja。
Ninja是一个致力于速度的小型编译系统（类似于Make），如果把其他编译系统比做高级语言的话，Ninja就是汇编语言。通常使用Kati或soong把makefile转换成Ninja files，然后用Ninja编译。
主要两个特点：
1)可以通过其他高级的编译系统生成其输入文件；
2)它的设计就是为了更快的编译；
ninja核心是由C/C++编写的，同时有一部分辅助功能由python和shell实现。由于其开源性，所以可以利用ninja的开源代码进行各种个性化的编译定制。
从Android 7开始，编译时默认使用Ninja。但是，Android项目里是没有.ninja文件的。遵循Ninja的设计哲学，编译时，会先把Makefile通过kati转换成.ninja文件，然后使用ninja命令进行编译。这些.ninja文件，都产生在out/目录下，共有三类：
第一类是build-*.ninja文件，通常非常大，几十到几百MB。对make全编译，命名是build-<product_name>.ninja。如果Makefile发生修改，需要重新产生Ninja文件。
mm、mma的Ninja文件，命名是build-<product_name>-<path_to_Android.mk>.ninja。而mmm、mmma的Ninja文件，命名是build-<product_name>-_<path_to_Android.mk>.ninja。
第二类是combined-*.ninja文件。在使用了Soong后，除了build-*.ninja之外，还会产生对应的combined-*.ninja，二者的*内容相同。
这类是组合文件，是把build-*.ninja和out/soong/build.ninja组合起来。所以，使用Soong后，combined-*.ninja是编译执行的真正入口。
第三类是out/soong/build.ninja文件，它是从所有的Android.bp转换过来的。
build-*.ninja是从所有的Makefile，用Kati转换过来的，包括build/core/*.mk和所有的Android.mk。所以，在不使用Soong时，它是唯一入口。在使用了Soong以后，会新增源于Android.bp的out/soong/build.ninja，所以需要combined-*.ninja来组合一下。
6.工具链的关系
Android.mk文件、Android.bp、kati、Soong、Blueprint、Ninja之间的关系如下：
Android.bp --> Blueprint --> Soong --> Ninja
Makefile or Android.mk --> kati --> Ninja
(Android.mk --> Soong --> Blueprint --> Android.bp)
Blueprint是生成、解析Android.bp的工具，是Soong的一部分。Soong则是专为Android编译而设计的工具，Blueprint只是解析文件的形式，而Soong则解释内容的含义。
Android.mk可以通过Soong提供的androidmk转换成Android.bp，但仅限简单配置。目前Oreo的编译流程中，仍然是使用kati来做的转换。
现存的Android.mk文件、既有的Android.bp，都会分别被转换成Ninja。从Android.mk与其它Makefile，会生成out/build-<product_name>.ninja文件。而从Android.bp，则会生成out/soong/build.ninja。此外，还会生成一个较小的out/combined-<product_name>.ninja文件，负责把二者组合起来，作为执行入口。
最终，Ninja文件才是真正直接控制源码编译的工具。
7.总结
Android10.0中，mk文件通过kati\ckati编译生成 build-aosp_arm.ninja， bp文件通过blueprint-soong解析编译生成为build.ninja ,这些ninja文件会合并成combined-aosp_arm.ninja，最终通过ninja工具进行最终的编译。
随着Google的不停演进，make的编译会最终退出历史舞台，kati\ckati也会退出，最终全部切到 blueprint-soong的编译。
原文链接：https://blog.csdn.net/yiranfeng/article/details/109082489
摘要：本节主要来进行Android10.0 编译系统入门讲解
1 概述
在 Android 7.0 之前，Android 编译系统使用 GNU Make 描述和shell来构建编译规则，模块定义都使用Android.mk进行定义，Android.mk的本质就是Makefile，但是随着Android的工程越来越大，模块越来越多，Makefile组织的项目编译时间越来越长。这样下去Google工程师觉得不行，得要优化。
因此，在Android7.0开始，Google采用ninja来代取代之前使用的make，由于之前的Android.mk数据实在巨大，因此Google加入了一个kati工具，用于将Android.mk转换成ninja的构建规则文件buildxxx.ninja,再使用ninja来进行构建工作。
ninja的网址：https://ninja-build.org
编译速度快了一些，但是既然要干， 那就干个大的，最终目标要把make都取代，于是从Android8.0开始，Google为了进一步淘汰Makefile，因此引入了Android.bp文件来替换之前的Android.mk。
Android.bp只是一个纯粹的配置文件，不包括分支、循环语句等控制流程，本质上就是一个json配置文件。Android.bp 通过Blueprint+soong转换成ninja的构建规则文件build.ninja，再使用ninja来进行构建工作。
Android10.0上，mk和bp编译的列表可以从 \out\.module_paths中的Android.bp.list、Android.mk.list中看到，Android10.0还有400多个mk文件没有被替换完，Google任重道远。
Android编译演进过程：
-
Android7.0之前 使用GNU Make
-
Android7.0 引入ninja、kati、Android.bp和soong构建系统
-
Android8.0 默认打开Android.bp
-
Android9.0 强制使用Android.bp
Google在 Android 7.0之后，引入了Soong构建系统，旨在取代make，它利用 Kati GNU Make 克隆工具和 Ninja 构建系统组件来加速 Android 的构建。
Make 构建系统得到了广泛的支持和使用，但在 Android 层面变得缓慢、容易出错、无法扩展且难以测试。Soong 构建系统正好提供了 Android build 所需的灵活性。
Android系统的编译历程：
2 编译流程
2.1 编译构成
Android的编译目录在/build 中，看一下Android 10源码中的build目录，现在是这个样子：
这个目录中可以看到core文件夹被link到了make/core，envsetup.sh被link到make/envsetup.sh，这主要是为了对使用者屏蔽切换编译系统的差异。
这里重点看四个文件夹：blueprint、kati、make、soong
blueprint：用于处理Android.bp，编译生成*.ninja文件，用于做ninja的处理
kati：用于处理Android.mk，编译生成*.ninja文件，用于做ninja的处理
make：文件夹还是原始的make那一套流程，比如envsetup.sh
soong：构建系统，核心编译为soong_ui.bash
Soong编译系统家族成员及各自关系如下图所示：
在编译过程中，Android.bp会被收集到out/soong/build.ninja.d,blueprint以此为基础，生成out/soong/build.ninja
Android.mk会由kati/ckati生成为out/build-aosp_arm.ninja
两个ninja文件会被整合进入out/combined-aosp_arm.ninja
out/combined-aosp_arm.ninja内容如下所示：