Android.bp简介 转载自Android.bp 语法浅析-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系统的编译历程： 2.Android.bp文件格式根据设计，Android.bp 文件很简单。它们不包含任何条件语句，也不包含控制流语句；所有复杂问题都由用 Go 编写的构建逻辑处理。Android.bp 文件的语法和语义都尽可能与 Bazel BUILD 文件类似。2.1 模块Android.bp 文件中的模块以模块类型开头，后跟一组 name: "value", 格式的属性：cc_binary { name: "gzip", srcs: ["src/test/minigzip.c"], shared_libs: ["libz"], stl: "none", }每个模块都必须具有 name 属性，并且相应值在所有 name 文件中必须是唯一的，仅有两个例外情况是命名空间和预构建模块中的 Android.bp 属性值，这两个值可能会重复。srcs 属性以字符串列表的形式指定用于构建模块的源文件。您可以使用模块引用语法 ":<module-name>" 来引用生成源文件的其他模块的输出，如 genrule 或 filegroup。如需有效模块类型及其属性的列表，请参阅 Soong 模块参考：https://www.cnblogs.com/linhaostudy/p/12361659.html常用模块类型：cc_binarycc_librarycc_library_staticandroid_appjava_libraryhidl_interfaceaidl_interface2.2 类型变量和属性是强类型，变量根据第一项赋值动态变化，属性由模块类型静态设置。支持的类型为：布尔值Bool（true 或 false）整数Integers (int)字符串Strings ("string")字符串列表List of string (["string1", "string2"])映射Maps ({key1: "value1", key2: ["value2"]})映射可以包含任何类型的值，包括嵌套映射。列表和映射可能在最后一个值后面有终止逗号。2.3 Glob接受文件列表的属性（例如 srcs）也可以采用 glob 模式。glob 模式可以包含普通的 UNIX 通配符 *，例如 *.java。glob 模式还可以包含单个 ** 通配符作为路径元素，与零个或多个路径元素匹配。例如，java/**/*.java 同时匹配 java/Main.java 和 java/com/android/Main.java 模式。2.4 变量Android.bp 文件可能包含顶级变量赋值：gzip_srcs = ["src/test/minigzip.c"] cc_binary { srcs: gzip_srcs, shared_libs: ["libz"], stl: "none", }变量的作用域限定在声明它们的文件的其余部分，以及所有子 Android.bp文件，可以使用 “=” 号赋值， 但是不能使用 “：=” 赋值。变量是不可变的，但有一个例外情况：可以使用 += 赋值将变量附加到别处，但只能在引用它们之前附加。例：gzip_srcs = ["src/test/minigzip.c"] gzip_srcs += [ "src/test/test.cpp", ] cc_binary { srcs: gzip_srcs, shared_libs: ["libz"], stl: "none", }2.5 注释Android.bp 文件可以包含 C 样式的多行 / / 注释以及 C++ 样式的单行 // 注释。2.6 运算符可以使用 + 运算符附加字符串、字符串列表和映射。可以使用 + 运算符对整数求和。附加映射会生成两个映射中键的并集，并附加在两个映射中都存在的所有键的值。2.7 条件语句Soong 不支持 Android.bp 文件中的条件语句。但是，编译规则中需要条件语句的复杂问题将在 Go（在这种语言中，您可以使用高级语言功能，并且可以跟踪条件语句引入的隐式依赖项）中处理。大多数条件语句都会转换为映射属性，其中选择了映射中的某个值并将其附加到顶级属性。例如，要支持特定于架构的文件，请使用以下命令：cc_library { ... srcs: ["generic.cpp"], arch: { arm: { srcs: ["arm.cpp"], }, x86: { srcs: ["x86.cpp"], }, }, }2.8 格式设置语句Soong 包含一个针对 Blueprint 文件的规范格式设置工具，类似于 gofmt。如需以递归方式重新设置当前目录中所有 Android.bp 文件的格式，请运行以下命令：bpfmt -w .规范格式包括缩进四个空格、多元素列表的每个元素后面有换行符，以及列表和映射末尾有英文逗号。2.9 默认模块默认模块可用于在多个模块中重复使用相同的属性。例如：cc_defaults { name: "gzip_defaults", shared_libs: ["libz"], stl: "none", } cc_binary { name: "gzip", defaults: ["gzip_defaults"], srcs: ["src/test/minigzip.c"], }2.10 预编译的模块某些预构建的模块类型允许模块与其基于源代码的对应模块具有相同的名称。例如，如果已有同名的 cc_binary，也可以将 cc_prebuilt_binary 命名为 foo。这让开发者可以灵活地选择要纳入其最终产品中的版本。如果编译配置包含两个版本，则预编译模块定义中的 prefer 标记值会指示哪个版本具有优先级。请注意，某些预编译模块的名称不能以 prebuilt开头，例如 android_app_import。2.11 命名空间模块在 Android 完全从 Make 转换为 Soong 之前，Make 产品配置必须指定 PRODUCT_SOONG_NAMESPACES 值。它的值应该是一个以空格分隔的列表，其中包含 Soong 导出到 Make 以使用 m 命令进行编译的命名空间。在 Android 完成到 Soong 的转换之后，启用命名空间的详细信息可能会发生变化。Soong 可以让不同目录中的模块指定相同的名称，只要每个模块都在单独的命名空间中声明即可。可以按如下方式声明命名空间：soong_namespace { imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"], }请注意，命名空间没有 name 属性；其路径会自动指定为其名称。系统会根据每个 Soong 模块在树中的位置为其分配命名空间。每个 Soong 模块都会被视为处于 Android.bp（位于当前目录或最近的父级目录中的 soong_namespace 文件内）定义的命名空间中。如果未找到此类 soong_namespace 模块，则认为该模块位于隐式根命名空间中。下面是一个示例：Soong尝试解析由模块 M 在名称空间 N（导入命名空间 I1、I2、I3…）中声明的依赖项D。如果 D 是 //namespace:module 格式的完全限定名称，系统将仅在指定的命名空间中搜索指定的模块名称。否则，Soong 将首先查找在命名空间 N 中声明的名为 D 的模块。如果该模块不存在，Soong 会在命名空间 I1、I2、I3…中查找名为 D 的模块。最后，Soong 在根命名空间中查找。2.12 Android.mk文件 自动转Android.bp方法Android源码里边提供了快捷直接Android.mk转换成Android.bp的工具：androidmk。androidmk源码位置： build/soong/androidmk/cmd/androidmk/androidmk.go编译出来后androidmk可执行文件位置：aosp/out/soong/host/linux-x86/bin/androidmk转换方法：aosp/out/soong/host/linux-x86/bin/androidmk [Android.mk PATH] > [Android.bp PATH]该工具可以转换变量、模块、注释和一些条件，但任何自定义生成文件规则、复杂条件或额外的包含都必须手动转换。

Android Binder机制（1）简介 [TOC]1. 概述Android系统中，每个应用程序是由Android的Activity，Service，Broadcast，ContentProvider这四剑客的中一个或多个组合而成，这四剑客所涉及的多进程间的通信底层都是依赖于Binder IPC机制。例如当进程A中的Activity要向进程B中的Service通信，这便需要依赖于Binder IPC。不仅于此，整个Android系统架构中，大量采用了Binder机制作为IPC（进程间通信）方案，当然也存在部分其他的IPC方式，比如Zygote通信便是采用socket。Binder作为Android系统提供的一种IPC机制，无论从事系统开发还是应用开发，都应该有所了解，这是Android系统中最重要的组成，也是最难理解的一块知识点，错综复杂。要深入了解Binder机制，最好的方法便是阅读源码，借用Linux鼻祖Linus Torvalds曾说过的一句话：Read The Fucking Source Code。2. Binder2.1 IPC原理从进程角度来看IPC机制每个Android的进程，只能运行在自己进程所拥有的虚拟地址空间。对应一个4GB的虚拟地址空间，其中3GB是用户空间，1GB是内核空间，当然内核空间的大小是可以通过参数配置调整的。对于用户空间，不同进程之间彼此是不能共享的，而内核空间却是可共享的。Client进程向Server进程通信，恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的，Client端与Server端进程往往采用ioctl等方法跟内核空间的驱动进行交互。2.2 Binder原理Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及Binder驱动，其中Service Manager用于管理系统中的各种服务。架构图如下所示：可以看出无论是注册服务和获取服务的过程都需要ServiceManager，需要注意的是此处的Service Manager是指Native层的ServiceManager（C++），并非指framework层的ServiceManager(Java)。ServiceManager是整个Binder通信机制的大管家，是Android进程间通信机制Binder的守护进程，要掌握Binder机制，首先需要了解系统是如何首次启动Service Manager。当Service Manager启动之后，Client端和Server端通信时都需要先获取Service Manager接口，才能开始通信服务。图中Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信，那么同样也是C/S架构，则图中的3大步骤都有相应的Client端与Server端。注册服务(addService)：Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。获取服务(getService)：Client进程使用某个Service前，须先向ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。图中的Client,Server,Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder驱动进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client,Server,Service Manager位于用户空间。Binder驱动和Service Manager可以看做是Android平台的基础架构，而Client和Server是Android的应用层，开发人员只需自定义实现client、Server端，借助Android的基本平台架构便可以直接进行IPC通信。2.3 C/S模式BpBinder(客户端)和BBinder(服务端)都是Android中Binder通信相关的代表，它们都从IBinder类中派生而来，关系图如下：client端：BpBinder.transact()来发送事务请求；server端：BBinder.onTransact()会接收到相应事务。转载：http://gityuan.com/2015/10/31/binder-prepare/