CPP基础--语句之范围for语句 范围for语句C++11标准引入了一种更简单的for语句，这种语句可以遍历容器或其他序列的所有元素。范围for语句的语法形式是：for (declaration : expression) statementexpression表示的必须是一个序列，比如用花括号括起来的初始值列表、数组或者vector等类型的对象，这些类型的共同特点是拥有能返回迭代器的begin和end成员。declaration定义一个变量，序列中的每个元素都得能转换成该变量的类型。确保类型相容最简单的办法是使用auto类型说明符。如果需要对序列中的元素执行写操作，循环变量必须声明成引用类型。每次迭代都会重新定义循环控制变量，并将其初始化成序列中的下一个值，之后才会执行statement。所有元素都处理完毕后循环终止。

CPP基础--标准库类型vector 标准库类型vector标准库类型vector表示对象的集合，其中所有对象的类型都相同。集合中每个对象都有一个与之对应的索引，索引用于访问对象。因为vector"容纳着"其他对象，所以也常被乘做容器（container）。vector是模板而非类型，由vector生成的类型必须包含vector中元素的类型，例如vector<int>vector能容纳绝大多数类型的对象作为其元素，但是因为引用不是对象，所以不存在包含引用的vector。1. 定义和初始化vector对象和任何一种类类型一样，vector模板控制着定义和初始化向量的方法。列表初始化vector对象用花括号括起来的0个或多个初始元素值被赋给vector对象：vector<string> articles = {"a", "an", "the"};创建指定数量的元素还可以用vector对象容纳的元素数量和所有元素的统一初始值来初始化vector对象：vector<int> ivec(10, -1); vector<string> svec(10, "hi");值初始化通常情况下，可以只提供给vector对象容纳的元素数量而不用略去初始值。此时库会创建一个值初始化的（value-initialized）元素初值，并把它赋给容器中的所有元素。这个初值由vector对象中元素的类型决定。vector<int> ivec(10); // 10个元素，每个都初始化为0 vector<string> svec(10); // 10个元素，每个都是空string对象对这种初始化的方式有两个特殊限制：其一，有些类要求必须明确地提供初始值，如果vector对象中元素的类型不支持默认初始化，我们就必须提供初始的元素值。对这种类型的对象来说，只提供元素的数量而不设定初始值无法完成初始化工作。列表初始值还是元素数量在某些情况下，初始化的真实含义依赖于传递初始值时用的是花括号还是圆括号。vector<int> v1(10); // 10个元素，每个值都是0 vector<int> v2{10}; // 1个元素，值为10 vector<int> v3(10, 1); // 10个元素，每个值都是1 vector<int> v4{10, 1}; // 2个元素，值分别是10和1如果用的是圆括号，可以说提供的值是用来构造（construct）vector对象的。如果用的是花括号，可以表述成我们想列表初始化该vector对象。另一方面，如果初始化时用了花括号的形式但是提供的值又不能用来列表初始化，就要考虑用这样的值来构造vector对象了。vector<string> v5{"hi"}; vector<string> v6("hi"); // error:不能使用字符串字面值构建vector对象 vector<string> v7{10}; // v7有10个默认初始化的元素 vector<string> v8{10, "hi"}; // v8有10个值为"hi"的元素2. 向vector对象添加元素经常使用vector的情况是并不清楚实际所需的元素个数，元素的值也经常无法确定。还有些时候即使元素的初值已知，但如果这些值总量较大而各不相同，那么在创建vector对象的时候执行初始化操作也会显得过于繁琐。我们可以利用vector成员函数push_back()向其中添加元素vector<int> v1; for (int i = 0; i < 100; i++) { v1.push_back(i); }向vector对象添加元素蕴含的编程假定必须要确保缩写的循环正确无误，特别是在循环有可能改变vector对象容量的时候如果循环体内部包含有向vector对象添加元素的语句，则不能使用范围for循环。范围for语句体内不应改变其所遍历序列的大小。3. 其它vector操作除了push_back之外，vector还提供了几种其他操作，大多数都和string的相关操作类似计算vector内对象的索引使用下标运算符能获取到指定对象的元素。和string一样，vector对象的下标也是从0开始计起，下标的类型是相应的size_type类型。只要vector对象不是一个常量，就能向下标运算符返回的元素赋值。不能使用下标形式添加元素vector对象(以及string对象)的下标运算符可用于访问已存在的元素，而不能用于添加元素。关于下标必须明确的一点是：只能对确知已存在的元素执行下标操作。

CPP基础--变量和基本类型之const限定符 const限定符因为const对象一旦创建后其值不能更改，因此创建时就必须初始化在不改变const对象的操作中还有一种是初始化，如果利用一个对象去初始化另外一个对象，则它们是不是const都无关紧要:int i = 42; const ci = i; // correct int j = ci; // correct尽管ci是整型常量，但无论如何ci中的值还是一个整型数。ci的常量特征仅仅在执行改变ci的操作时才会发挥作用。当用ci去初始化j时，根本无须在意ci是不是一个常量。拷贝一个对象的值并不会改变它，一旦拷贝完成，新的对象就和原来的对象没有关系了。默认状态下，const对象仅在文件内有效当多个文件中出现了同名的const变量时，其实等同于在不同文件中分别定义了独立的变量。某些时候有这样一种const变量，它的初始值不是一个常量表达式，但又确实有必要在文件间共享。这种情况下，我们不希望编译器为每个文件分别生成独立的变量。相反，我们想让这类const对象像其他（非常量）对象一样工作，也就是说，只在一个文件中定义const，而在多个文件中声明并使用它解决办法是，对于const变量不管是声明还是定义都添加extern关键字，这样只需定义一次就可以了;// file_1.cc定义并初始化了一个常量，该常量能被其他文件访问 extern const int bufSize = fcn(); // file_1.h头文件 extern const int bufSize; // 与file_1.cc中定义的bufSize是同一个file_1.h头文件中的声明也由extern做了限定，其作用是指明bufSize并非本文件所独有，它的定义将在别处出现。如果想在多个文件之间共享const对象，必须在变量的定义之前添加extern关键字1. const的引用可以把引用绑定到const对象上，就像绑定到其它对象上一样，我们称之为对常用的引用（reference to const）。与普通引用不同的是，对常量的引用不能被用作修改它所绑定的对象：const int ci = 1024; const int &r1 = ci; // correct,引用及其对应的对象都是常量 r1 = 42; // 错误，r1是对常量的引用 int &r2 = ci; // 错误,试图让一个非常量引用指向一个常量对象。假设该初始化合法，则可以通过r2来改变它引用对象的值，这显然是不正确的。初始化和对const的引用引用的类型必须与其所引用的对象的类型一致，但是有两个例外。第一种例外情况就是在初始化常量引用时允许用任意表达式作为初始值，只要该表达式的结果能转换成引用的类型即可，尤其，允许为一个常量引用绑定非常量的对象、字面值，甚至是个一般表达式：int i = 42; const int &r1 = i; // 允许将const int&绑定到一个普通的int对象上 const int &r2 = 42; // 正确： r1是一个常量引用 const int &r3 = r1 * 2; // 正确; // r3是一个常量引用 int &r4 = r1 * 2; // 错误：r4是一个普通的非常量引用可以这样做的原因如下，double dval = 3.14; const int &ri = dval;编译器把上述代码变成了如下形式const int temp = dval; // 由双精度浮点数生成一个临时的整型常量 const int &ri = temp; // 由ri绑定这个临时量如果ri不是常量，就允许对ri赋值，这样就会改变ri所引用对象的值。注意，此时绑定的对象是一个临时量而非dval。程序员既然让ri引用dval，就肯定想通过ri改变dval的值，否则干什么要给ri赋值呢？如此看来，既然大家都不会想着把引用绑定到临时量上，C++语言也就把这种行为归为非法。对const的引用可能引用一个并非const的对象int i = 42; int &r1 = i; // 引用ri绑定对象i const int &r2 = i; // r2也绑定对象i，但是不允许通过r2修改i的值 r1 = 0; // r1并非常量，i的值修改为0 r2 = 0; // 错误：r2是一个常量引用不允许通过r2修改i的值2. 指针和const指向常量的指针（pointer to const）不能用于改变其所指对象的值。要想存放常量对象的地址，只能使用指向常量的指针：const double pi = 3.14; double *ptr = &pi; // error const double *cptr = &pi; // correct *cptr = 42; // errorconst指针常量指针（const pointer）,将指针本身定为常量。常量指针必须初始化，而且一旦初始化完成，则它的值（也就是存放在指针中的那个地址）就不能再改变了。int errnumb= 0； int *const curErr = &errNumb; // curErr将一直指向errNumb const double pi = 3.14159; const double *const pip = &pi; // pip是一个指向常量对象的常量指针3. 顶层const用名词顶层const（top-level const）表示指针本身是个常量用名词底层const(low-level const)表示指针所指的对象是一个常量4.constexpr和常量表达式常量表达式（const expression）是指值不会改变并且在编译过程就能得到计算结果的表达式。以下均不是常量表达式;int staff_size = 27; const int sz = get_size();constexpr变量在一个复杂系统中，很难（几乎不能）分辨一个初始值到底是不是一个常量表达式。C++11标准规定，允许将变量声明为constexpr类型以便由编译器来验证变量的值是否是一个常量表达式。声明为constexpr的变量一定是一个常量，而且必须用常量表达式初始化。一般来说，如果你认定变量是一个常量表达式，那就把它声明称constexpr类型。字面值类型常量表达式的值需要在编译时就得到计算，因此对声明constexpr时用到的类型必须有所限制。因为这些类型一般比较简单，值也显而易见、容易得到，就把它们称为"字面值类型"（literal type）到目前为止，算术类型、引用和指针都属于字面值类型。自定义类Sales_item、IO库、string类型则不属于字面值类型，也就不能被定义成constexpr。指针和constexpr必须明确一点，在constexpr声明中如果定义了一个指针，限定符constexpr仅对指针有效，与指针所指的对象无关：const int *p = nullptr; // p是一个指向整型常量的指针 constexpr int *q = nullptr; // q是一个指向整数的常量指针

[转载]android 8.1 安全机制 — SEAndroid & SELinux 版权声明：本文为CSDN博主「岁月斑驳7」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/qq_19923217/article/details/81240027

Android系统之VINTF（1）manifests&compatibility matrices 暂无简介

添加新设备类型-Android编译系统（4） 1.理解构建层构建层次结构包括与设备的物理结构对应的抽象层。下表中介绍了这些层。每一层都与上一层存在一对多的关系。例如，一个架构(ARCH)可以有多个主板(Board/device)，一个主板可以有多个产品(Product)。您可以将指定层中的某个元素定义为同一层中某个元素的特化元素，这样可以免去复制操作并简化维护工作。LayerExampleDescriptionProductmyProduct, myProduct_eu, myProduct_eu_fr, j2, sdkThe product layer defines the feature specification of a shipping product such as the modules to build, locales supported, and configuration for various locales. In other words, this is the name of the overall product. Product-specific variables are defined in product definition makefiles. A product can inherit from other product definitions, which simplifies maintenance. A common method is to create a base product that contains features that apply to all products, then create product variants based on that base product. For example, two products that differ only by their radios (CDMA versus GSM) can inherit from the same base product that doesn't define a radio.Board/devicemarlin, blueline, coralThe board/device layer represents the physical layer of plastic on the device (that is, the industrial design of the device). This layer also represents the bare schematics of a product. These include the peripherals on the board and their configuration. The names used are merely codes for different board/device configurations.Archarm, x86, arm64, x86_64The architecture layer describes the processor configuration and application binary interface (ABI) running on the board.2.使用build variants在针对特定产品进行构建时，如果能在最终发布 build 的基础上有细微的变化，会非常有用。在模块定义中，模块可以通过 LOCAL_MODULE_TAGS 指定标记，这些标记可以是以下一个或多个值：optional（默认值）、debug 和 eng。如果某个模块没有通过 LOCAL_MODULE_TAGS 指定标记，则其标记默认设置为 optional。仅当 PRODUCT_PACKAGES 的产品配置需要可选模块时，系统才会安装可选模块。下面是当前定义的构建变体(build variants)。VariantDescriptionengThis is the default flavor. - Installs modules tagged with eng or debug.- Installs modules according to the product definition files, in addition to tagged modules.- ro.secure=0- ro.debuggable=1- ro.kernel.android.checkjni=1- adb is enabled by default.userThe variant intended to be the final release bits.- Installs modules tagged with user.- Installs modules according to the product definition files, in addition to tagged modules.- ro.secure=1- ro.debuggable=0- adb is disabled by default.userdebugThe same as user, with these exceptions:- Also installs modules tagged with debug.- ro.debuggable=1- adb is enabled by default.aosp为build系统提供三种Product配置，文档里叫做build variants,分别是:eng : 对应到工程版。编译打包所有模块。表示adbd处于ROOT状态，所有调试开关打开userdebug : 对应到用户调试版。打开调试开关，但并没有放开ROOT权限user : 对应到用户版。关闭调试开关，关闭ROOT权限。最终发布到用户手上的版本，通常都是user版。2.1 userdebug的准则在测试中运行 userdebug build 有助于设备开发者了解开发中版本的性能和功耗。为了让 user build 和 userdebug build 保持一致，并在用于调试的 build 中获得可靠的指标，设备开发者应遵循以下准则：userdebug 定义为已启用 root 权限的 user build，但以下情况除外：仅由用户视需要运行且仅用于 userdebug build 的应用仅在空闲维护（连接充电器/充满电）期间执行的操作，例如，使用 dex2oatd 而不是 dex2oat 来进行后台编译不要添加根据构建类型默认启用/停用的功能。建议开发者不要使用任何影响电池续航时间的日志记录形式（例如调试日志记录或堆转储）。在 userdebug build 中默认启用的任何调试功能都应明确定义，并告知处理相关项目的所有开发者。您应该只在限定的时间内启用调试功能，直到您尝试调试的问题得到解决。3. Customizing the build with resource overlays（利用资源叠加层自定义build）Android 构建系统会在构建时使用资源叠加层来自定义产品。资源叠加层用于指定在默认文件之上应用的资源文件。如需使用资源叠加层，请修改项目构建文件，将 PRODUCT_PACKAGE_OVERLAYS 设为相对于顶级目录的路径。当构建系统搜索资源时，该路径会变为影子根目录，系统除了在当前根目录中进行搜索外，还会一并在该路径中进行搜索。最常自定义的设置包含在 frameworks/base/core/res/res/values/config.xml 文件中。如需在此文件上设置资源叠加层，请使用以下某个命令将叠加层目录添加到项目构建文件：PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay例如：或PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay然后，将一个叠加层文件添加到该目录下，例如：vendor/foobar/overlay/frameworks/base/core/res/res/config.xml在叠加层 config.xml 文件中找到的所有字符串或字符串数组都会替换在原始文件中找到的对应字符串或字符串数组。4. 构建产品您可以通过多种不同的方式来组织设备的源文件。下面简要说明了 Pixel 实现的一种组织方式。为 Pixel 实现名为 marlin 的主设备配置。根据此设备配置，为产品创建产品定义 Makefile，用于声明关于设备的产品特定信息，例如名称和型号。您可以查看 device/google/marlin 目录，了解所有相关配置的具体设置方式。4.1 编写产品Makefile以下步骤介绍了如何采用与设置 Pixel 产品线类似的方式设置产品 Makefile：为您的产品创建一个 device/<company-name>/<device-name> 目录。例如，device/google/marlin。此目录将包含您设备的源代码以及构建这些代码所需的 Makefile。创建一个 device.mk Makefile，用来声明设备所需的文件和模块。有关示例，请查看 device/google/marlin/device-marlin.mk。创建一个产品定义 Makefile，以便基于设备创建具体产品。以下示例 Makefile 来自于 device/google/marlin/aosp_marlin.mk。请注意，该产品会通过 Makefile 沿用 device/google/marlin/device-marlin.mk 和 vendor/google/marlin/device-vendor-marlin.mk 文件中的设置，同时还会声明产品特定信息，例如名称、品牌和型号。# Inherit from the common Open Source product configuration $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk) $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk) PRODUCT_NAME := aosp_marlin PRODUCT_DEVICE := marlin PRODUCT_BRAND := Android PRODUCT_MODEL := AOSP on msm8996 PRODUCT_MANUFACTURER := Google PRODUCT_RESTRICT_VENDOR_FILES := true PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin $(call inherit-product, device/google/marlin/device-marlin.mk) $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk) PRODUCT_PACKAGES += \ Launcher3QuickStep \ WallpaperPicker如需了解可添加到 Makefile 的其他产品特定变量，请参阅设置产品定义变量(4.2小节)。创建一个指向产品的 Makefile文件AndroidProducts.mk。在此示例中，仅需要产品定义 Makefile。以下示例来自于 device/google/marlin/AndroidProducts.mk（该文件同时包含 marlin (Pixel) 和 sailfish (Pixel XL)，它们共享大部分配置）：PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug创建一个包含主板特定配置的Makefile文件BoardConfig.mk 。如需查看示例，请查看 device/google/marlin/BoardConfig.mk。创建一个 vendorsetup.sh 文件，以便将您的产品（“午餐套餐”）与构建变体（使用短划线将两者分隔开）一起添加到 build 中。例如：add_lunch_combo <product-name>-userdebug这一步显得多余了，谷歌已经不建议这样了这时，您就可以基于同一设备创建更多产品变体了。4.2 设置产品定义变量产品特定变量在产品的 Makefile 中进行定义。下表显示了在产品定义文件中维护的部分变量。变量说明示例PRODUCT_AAPT_CONFIGaapt configurations to use when creating packages. PRODUCT_BRANDThe brand (for example, carrier) the software is customized for, if any. PRODUCT_CHARACTERISTICSaapt characteristics to allow adding variant-specific resources to a package.tablet, nosdcardPRODUCT_COPY_FILESList of words like source_path:destination_path. The file at the source path should be copied to the destination path when building this product. The rules for the copy steps are defined in config/makefile. PRODUCT_DEVICEName of the industrial design. This is also the board name, and the build system uses it to locate BoardConfig.mk.tunaPRODUCT_LOCALESA space-separated list of two-letter language code, two-letter country code pairs that describe several settings for the user, such as the UI language and time, date, and currency formatting. The first locale listed in PRODUCT_LOCALES is used as the product's default locale.en_GB, de_DE, es_ES, fr_CAPRODUCT_MANUFACTURERName of the manufacturer.acmePRODUCT_MODELEnd-user-visible name for the end product. PRODUCT_NAMEEnd-user-visible name for the overall product. Appears in the Settings > About screen. PRODUCT_OTA_PUBLIC_KEYSList of over-the-air (OTA) public keys for the product. PRODUCT_PACKAGESList of the APKs and modules to install.Calendar contactsPRODUCT_PACKAGE_OVERLAYSIndicates whether to use default resources or add any product specific overlays.vendor/acme/overlayPRODUCT_SYSTEM_PROPERTIESList of the system property assignments in the format "key=value" for the system partition. System properties for other partitions can be set via PRODUCT_<PARTITION>_PROPERTIES as in PRODUCT_VENDOR_PROPERTIES for the vendor partition. Supported partition names: SYSTEM, VENDOR, ODM, SYSTEM_EXT, and PRODUCT. 4.3 设置ADB_VENDOR_KEYS以通过USB进行连接借助 ADB_VENDOR_KEYS 环境变量，设备制造商无需手动授权，即可通过 adb 访问可调试的 build（userdebug build 和 eng build，但不能访问 user build）。通常，adb 会为每台客户端计算机生成一个唯一的 RSA 身份验证密钥，并将其发送到所有已连接的设备。这就是 adb 授权对话框中显示的 RSA 密钥。或者，您也可以将已知密钥构建到系统映像中，并将其分享给相应的 adb 客户端。这对于操作系统开发来说很有用，对测试来说尤其有用，因为此做法无需与 adb 授权对话框手动进行交互。如需创建供应商密钥，应安排一个人（通常为发布管理员）执行以下操作：使用 adb keygen 生成密钥对。对于 Google 设备，Google 会为每个新操作系统版本生成一个新密钥对。将密钥对签入源代码树中的某个位置。例如，Google 会将其存储在 vendor/google/security/adb/ 中。设置构建变体 PRODUCT_ADB_KEYS，使其指向您的密钥目录。为此，Google 会在密钥目录中添加一个 Android.mk 文件，其内容为 PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub，以帮助确保我们记得为每个操作系统版本生成新的密钥对。以下是 Google 在该目录（我们将各版本的已签入密钥对存储在此处）中使用的 Makefile：PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),) $(warning ========================) $(warning The adb key for this release) $(warning ) $(warning $(PRODUCT_ADB_KEYS)) $(warning ) $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk) $(warning has changed and a new adb key needs to be generated.) $(warning ) $(warning Please run the following commands to create a new key:) $(warning ) $(warning make -j8 adb) $(warning LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS))) $(warning ) $(warning and upload/review/submit the changes) $(warning ========================) $(error done) endif如需使用这些供应商密钥，工程师只需将 ADB_VENDOR_KEYS 环境变量设为指向存储相应密钥对的目录。这会告知 adb 先尝试这些规范密钥，然后回退到需要手动授权的已生成主机密钥。当 adb 无法连接到未获授权的设备时，系统会显示错误消息，提示您设置 ADB_VENDOR_KEYS（如果尚未设置）。参考：Android系统之添加ProductAdding a New Device

[转载]make编译过程-Android10.0编译系统（三） 版权声明：本文为CSDN博主「IngresGe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/yiranfeng/article/details/1090840821. 概述上一节，我们理清了编译环境初始化的过程，环境变量已经加载，并配置了编译目标，接下来执行一个make命令我们就能够进行编译。make之后是怎么完成编译的，这个很有意思，我们一起往下探讨。2. Android系统的编译历程Android7.0 Google引入了soong构建系统，用来逐步替代GNU make的编译，因此在Android10.0 上，make执行后，我们走的是soong构建环境。Android系统的编译历程：3.Soong编译系统家族成员从下图可知，mk文件被编译成了 out/build-aosp\_arm.ninja和out/build-aosp\_arm-package.ninja，bp文件被编译成了out/soong/build.ninja，这三个ninja文件又被合并成out/combined-aosp\_arm.ninja，最终通过ninja工具来编译out/combined-aosp\_arm.ninja完成最终的编译。4. make的流程图soong构建的流程图如下图所示：5. make()执行完make命令后，会调用envsetup.sh的make()函数进行处理。function make() { _wrap_build $(get_make_command "$@") "$@" }从get_make_command()可以看出，make后，真正然后执行编译的入口是：build/soong/soong_ui.bashfunction 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 }6. soong_ui.bash6.1 soong_ui.bash调用栈soong_ui.bash执行过程：source  microfactory.bash，得到一些函数命令， 例如：soong_build_go编译/build/soong/cmd/soong_ui/main.go，生成 out/soong_ui这个可执行程序执行命令：out/soong_ui --make-mode ，执行了make命令，会把"build/make/core/main.mk" 加到构建环境中，同时启动kati、blueprint-soong、ninja的编译。接下来根据调用栈的流程，来详细分析编译的过程。6.2 [build/soong/soong_ui.bash]soong_ui.bash 用来配置一些资源环境，得到一些函数命令，例如：soong_build_go,最终回退到根目录，执行out/soong_ui --make-mode进行真正的构建。# 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" "$@"6.2.1 [/soong/../microfactory.bash]得到build_go的函数命令,并提供 soong_build_go的函数执行方法[/build/soong/scripts/microfactory.bash] function soong_build_go { BUILDDIR=$(getoutdir) \ SRCDIR=${TOP} \ BLUEPRINTDIR=${TOP}/build/blueprint \ EXTRA_ARGS="-pkg-path android/soong=${TOP}/build/soong -pkg-path github.com/golang/protobuf=${TOP}/external/golang-protobuf" \ build_go $@ } source ${TOP}/build/blueprint/microfactory/microfactory.bash6.2.2 [/blueprint/../microfactory.bash]build_go主要目的就是用来构建生成 out/soong_ui这个可执行程序，用于参与最终的编译[/build/blueprint/microfactory/microfactory.bash ] function build_go { # Increment when microfactory changes enough that it cannot rebuild itself. # For example, if we use a new command line argument that doesn't work on older versions. local mf_version=3 local mf_src="${BLUEPRINTDIR}/microfactory" local mf_bin="${BUILDDIR}/microfactory_$(uname)" local mf_version_file="${BUILDDIR}/.microfactory_$(uname)_version" local built_bin="${BUILDDIR}/$1" local from_src=1 if [ -f "${mf_bin}" ] && [ -f "${mf_version_file}" ]; then if [ "${mf_version}" -eq "$(cat "${mf_version_file}")" ]; then from_src=0 fi fi local mf_cmd if [ $from_src -eq 1 ]; then # `go run` requires a single main package, so create one local gen_src_dir="${BUILDDIR}/.microfactory_$(uname)_intermediates/src" mkdir -p "${gen_src_dir}" sed "s/^package microfactory/package main/" "${mf_src}/microfactory.go" >"${gen_src_dir}/microfactory.go" mf_cmd="${GOROOT}/bin/go run ${gen_src_dir}/microfactory.go" else mf_cmd="${mf_bin}" fi # GOROOT must be absolute because `go run` changes the local directory GOROOT=$(cd $GOROOT; pwd) ${mf_cmd} -b "${mf_bin}" \ -pkg-path "github.com/google/blueprint=${BLUEPRINTDIR}" \ -trimpath "${SRCDIR}" \ ${EXTRA_ARGS} \ -o "${built_bin}" $2 if [ $? -eq 0 ] && [ $from_src -eq 1 ]; then echo "${mf_version}" >"${mf_version_file}" fi }soong_ui最终的编译命令展开为：$(cd /prebuilts/go/linux-x86/; pwd) /out/microfactory_Linux -b "/out/microfactory_Linux" \ -pkg-path "github.com/google/blueprint=/build/blueprint" \ -trimpath "./" \ -pkg-path android/soong=/build/soong -pkg-path github.com/golang/protobuf=/external/golang-protobuf} \ -o "out/soong_ui" android/soong/cmd/soong_ui从上面的流程可知，生成soong_ui经历几件事情：通过/build/blueprint/microfactory/microfactory.go 编译出/out/microfactory_Linux使用/out/microfactory_Linux来编译soong_uimicrofactory是一个增量编译go程序的工具。它类似于“go install”，但不需要GOPATH。包->路径映射可以指定为命令行选项：-pkg-path android/soong=build/soong -pkg-path github.com/google/blueprint=build/blueprint其实microfactory就是一个高级一点的go命令，它自己由go编出来，又代替了一部分go的部分功能，鸡生蛋，蛋生鸡的故事，这里得到了完美解释 ^\_^。microfactory编译示例：准备go的代码在/home/ingresge/AP/AOSP_Q中创建一个目录hello：创建hello.go---vim hello/hello.go在其中打印一个“Hello，Go！”package main import ( "log" "os" ) func main() { testlog := log.New(os.Stderr, "", log.Ltime) testlog.Println("Hello,Go!") }使用microfactory 编译hello.go/home/ingresge/AP/AOSP_Q/out/microfactory_Linux -pkg-path android/hello=/home/ingresge/AP/AOSP_Q/hello -trimpath /home/ingresge/AP/AOSP_Q/hello -o /home/ingresge/AP/AOSP_Q/out/hellogo android/hello/运行执行命令：./out/hellogo输出结果：17:18:44 Hello,Go!6.3 soong_uisoong_ui 是通过编译 build/soong/cmd/soong_ui/main.go得来，我们接下来分析一下main.go的一些流程6.3.1 main.go调用栈6.3.2 soong_ui启动编译的入口func main() { var stdio terminal.StdioInterface stdio = terminal.StdioImpl{} // dumpvar uses stdout, everything else should be in stderr if os.Args[1] == "--dumpvar-mode" || os.Args[1] == "--dumpvars-mode" { stdio = terminal.NewCustomStdio(os.Stdin, os.Stderr, os.Stderr) } writer := terminal.NewWriter(stdio) defer writer.Finish() log := logger.New(writer) defer log.Cleanup() if len(os.Args) < 2 || !(inList("--make-mode", os.Args) || os.Args[1] == "--dumpvars-mode" || os.Args[1] == "--dumpvar-mode") { log.Fatalln("The `soong` native UI is not yet available.") } ctx, cancel := context.WithCancel(context.Background()) defer cancel() trace := tracer.New(log) defer trace.Close() met := metrics.New() stat := &status.Status{} defer stat.Finish() stat.AddOutput(terminal.NewStatusOutput(writer, os.Getenv("NINJA_STATUS"), build.OsEnvironment().IsEnvTrue("ANDROID_QUIET_BUILD"))) stat.AddOutput(trace.StatusTracer()) build.SetupSignals(log, cancel, func() { trace.Close() log.Cleanup() stat.Finish() }) buildCtx := build.Context{ContextImpl: &build.ContextImpl{ Context: ctx, Logger: log, Metrics: met, Tracer: trace, Writer: writer, Status: stat, }} var config build.Config if os.Args[1] == "--dumpvars-mode" || os.Args[1] == "--dumpvar-mode" { config = build.NewConfig(buildCtx) } else { config = build.NewConfig(buildCtx, os.Args[1:]...) } build.SetupOutDir(buildCtx, config) logsDir := config.OutDir() if config.Dist() { logsDir = filepath.Join(config.DistDir(), "logs") } os.MkdirAll(logsDir, 0777) log.SetOutput(filepath.Join(logsDir, "soong.log")) trace.SetOutput(filepath.Join(logsDir, "build.trace")) stat.AddOutput(status.NewVerboseLog(log, filepath.Join(logsDir, "verbose.log"))) stat.AddOutput(status.NewErrorLog(log, filepath.Join(logsDir, "error.log"))) defer met.Dump(filepath.Join(logsDir, "build_metrics")) if start, ok := os.LookupEnv("TRACE_BEGIN_SOONG"); ok { if !strings.HasSuffix(start, "N") { if start_time, err := strconv.ParseUint(start, 10, 64); err == nil { log.Verbosef("Took %dms to start up.", time.Since(time.Unix(0, int64(start_time))).Nanoseconds()/time.Millisecond.Nanoseconds()) buildCtx.CompleteTrace(metrics.RunSetupTool, "startup", start_time, uint64(time.Now().UnixNano())) } } if executable, err := os.Executable(); err == nil { trace.ImportMicrofactoryLog(filepath.Join(filepath.Dir(executable), "."+filepath.Base(executable)+".trace")) } } // Fix up the source tree due to a repo bug where it doesn't remove // linkfiles that have been removed fixBadDanglingLink(buildCtx, "hardware/qcom/sdm710/Android.bp") fixBadDanglingLink(buildCtx, "hardware/qcom/sdm710/Android.mk") f := build.NewSourceFinder(buildCtx, config) defer f.Shutdown() build.FindSources(buildCtx, config, f) if os.Args[1] == "--dumpvar-mode" { dumpVar(buildCtx, config, os.Args[2:]) } else if os.Args[1] == "--dumpvars-mode" { dumpVars(buildCtx, config, os.Args[2:]) } else { if config.IsVerbose() { writer.Print("! The argument `showcommands` is no longer supported.") writer.Print("! Instead, the verbose log is always written to a compressed file in the output dir:") writer.Print("!") writer.Print(fmt.Sprintf("! gzip -cd %s/verbose.log.gz | less -R", logsDir)) writer.Print("!") writer.Print("! Older versions are saved in verbose.log.#.gz files") writer.Print("") time.Sleep(5 * time.Second) } toBuild := build.BuildAll if config.Checkbuild() { toBuild |= build.RunBuildTests } build.Build(buildCtx, config, toBuild) } }主要执行soong/ui/build/build.go，从build.go就可以看到执行soong的大体流程。main.go中配置的toBuild为 BuildProductConfig | BuildSoong | BuildKati | BuildNinja，支持productconfig\soong\kati\ninja的构建。6.3.3 Build调用栈编译步骤如下:1) runMakeProductConfig 主要配置编译参数2) runSoong 对工具进行编译，编译出blueprint等编译工具, 把*.bp 编译成 out/soong/build.ninja/.minibootstrap/build.ninja - Run minibp to generate .bootstrap/build.ninja (Primary stage) - Run minibp to generate .minibootstrap/build.ninja.in /.bootstrap/build.ninja - Build any bootstrap_go_binary rules and dependencies -- usually the primary builder and any build or runtime dependencies. - Run the primary builder to generate build.ninja3) runKatiBuild, 加载 build/make/core/main.mk， 搜集所有的Android.mk文件生成ninja文件:out/build-aosp\_arm.ninja4) runKatiPackage, 加载build/make/packaging/main.mk, 编译生成out/build-aosp\_arm-package.ninja5) createCombinedBuildNinjaFile,将out/soong/build.ninja 、out/build-aosp_arm.ninja和out/build-aosp\_arm-package.ninja， 合成为out/combined-aosp\_arm.ninja6) runNinja，运行Ninja命令， 解析combined-aosp\_arm.ninja，执行编译过程out/combined-aosp_arm.ninja 内容展示如下：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.ninja6.3.4 BuildBuild入口[/build/soong/ui/build/build.go] func Build(ctx Context, config Config, what int) { ctx.Verboseln("Starting build with args:", config.Arguments()) ctx.Verboseln("Environment:", config.Environment().Environ()) if config.SkipMake() { ctx.Verboseln("Skipping Make/Kati as requested") what = what & (BuildSoong | BuildNinja) } if inList("help", config.Arguments()) { help(ctx, config, what) return } else if inList("clean", config.Arguments()) || inList("clobber", config.Arguments()) { clean(ctx, config, what) return } // Make sure that no other Soong process is running with the same output directory buildLock := BecomeSingletonOrFail(ctx, config) defer buildLock.Unlock() checkProblematicFiles(ctx) SetupOutDir(ctx, config) checkCaseSensitivity(ctx, config) ensureEmptyDirectoriesExist(ctx, config.TempDir()) SetupPath(ctx, config) if config.StartGoma() { // Ensure start Goma compiler_proxy startGoma(ctx, config) } if what&BuildProductConfig != 0 { // Run make for product config runMakeProductConfig(ctx, config) } if inList("installclean", config.Arguments()) { installClean(ctx, config, what) ctx.Println("Deleted images and staging directories.") return } else if inList("dataclean", config.Arguments()) { dataClean(ctx, config, what) ctx.Println("Deleted data files.") return } if what&BuildSoong != 0 { // Run Soong runSoong(ctx, config) } if what&BuildKati != 0 { // Run ckati genKatiSuffix(ctx, config) runKatiCleanSpec(ctx, config) runKatiBuild(ctx, config) runKatiPackage(ctx, config) ioutil.WriteFile(config.LastKatiSuffixFile(), []byte(config.KatiSuffix()), 0777) } else { // Load last Kati Suffix if it exists if katiSuffix, err := ioutil.ReadFile(config.LastKatiSuffixFile()); err == nil { ctx.Verboseln("Loaded previous kati config:", string(katiSuffix)) config.SetKatiSuffix(string(katiSuffix)) } } // Write combined ninja file createCombinedBuildNinjaFile(ctx, config) if what&RunBuildTests != 0 { testForDanglingRules(ctx, config) } if what&BuildNinja != 0 { if !config.SkipMake() { installCleanIfNecessary(ctx, config) } // Run ninja runNinja(ctx, config) } }6.4 main.mk文件分析执行runKatiBuild时，有个重要的步骤，就是加载build/make/core/main.mk，main.mk文件是Android Build系统的主控文件。从main.mk开始，将通过include命令将其所有需要的.mk文件包含进来，最终在内存中形成一个包括所有编译脚本的集合，这个相当于一个巨大Makefile文件。Makefile文件看上去很庞大，其实主要由三种内容构成: 变量定义、函数定义和目标依赖规则，此外mk文件之间的包含也很重要。main.mk主要做了以下几件事情： 1. 定义编译目标product 2. 加载config.mk来初始化相关变量，检测编译环境和目标环境 3. 清除规则，清除out目录中的dex文件 4. 加载build/croe/definitions.mk,定义了很多通用函数，供编译过程调用 5. 加载平台开发工具包  build/make/core/pdk_config.mk 6. 加载系统中所有的Android.mk,最终会被存放到out/.module_paths/Android.mk.list 7. Link 类型检查，校验Link 8. 要为此产品生成的模块的基本列表由相应的产品定义文件指定，这些定义在"product_config.mk"中 9. 运行时APEX库，并进行检查校验 10. 将所有要安装的模块都保存在变量ALL_DEFAULT_INSTALLED_MODULES中，并且将build/core/Makefie文件加载进来。build/core/Makefie文件会根据要安装的模块生成system.img、super.img、boot.img和recovery.img等镜像文件的生成规则 11. 定义编译的image目标 12. 构建文件，然后将其打包成rom格式6.4.1 定义编译目标product流程1：没有KATI命令时，走run_soong_ui执行，通过soong_ui.bash --make-mode 进行编译流程2：通过kati命令编译时在Android10.0中，使用的是soong构建，因此直接走流程2确定了最终的编译目标为droidifndef KATI host_prebuilts := linux-x86 ifeq ($(shell uname),Darwin) host_prebuilts := darwin-x86 endif #流程1：没有KATI命令时，走run_soong_ui执行，通过soong_ui.bash --make-mode 进行编译 .PHONY: run_soong_ui run_soong_ui: +@prebuilts/build-tools/$(host_prebuilts)/bin/makeparallel --ninja build/soong/soong_ui.bash --make-mode $(MAKECMDGOALS) .PHONY: $(MAKECMDGOALS) $(sort $(MAKECMDGOALS)) : run_soong_ui @#empty else # KATI #流程2：通过kati命令编译时，走该流程，Android10.0中走该流程 $(info [1/1] initializing build system ...) .... #1.定义编译目标product #这是默认目标。它必须是第一个声明的目标。 .PHONY: droid DEFAULT_GOAL := droid $(DEFAULT_GOAL): droid_targets .PHONY: droid_targets droid_targets: ... #endif #KATI6.4.2 加载config.mk加载config.mk来初始化相关变量，检测编译环境和目标环境,加载clang/config.mk，配置一些编译的环境。include build/make/core/config.mk ... #加载out/soong/make_vars-aosp_arm.mk include $(SOONG_MAKEVARS_MK) #加载clang编译的一些配置 include $(BUILD_SYSTEM)/clang/config.mk ...6.4.3 清楚规则清除规则，清除out目录中的dex文件。... .PHONY: clean-dex-files clean-dex-files: $(hide) find $(OUT_DIR) -name "*.dex" | xargs rm -f $(hide) for i in `find $(OUT_DIR) -name "*.jar" -o -name "*.apk"` ; do ((unzip -l $$i 2> /dev/null | \ grep -q "\.dex$$" && rm -f $$i) || continue ) ; done @echo "All dex files and archives containing dex files have been removed." ...6.4.5 加载pdk_config.mk加载 平台开发工具包... include build/make/core/pdk_config.mk #为userdebug、eng和non-REL生成启用动态链接器警告 ifneq ($(TARGET_BUILD_VARIANT),user) ADDITIONAL_BUILD_PROPERTIES += ro.bionic.ld.warning=1 else #只要user版本不是最终版本，就启用它。 ifneq ($(PLATFORM_VERSION_CODENAME),REL) ADDITIONAL_BUILD_PROPERTIES += ro.bionic.ld.warning=1 endif endif ...6.4.6 加载系统所有的Android.mk加载系统中所有的Android.mk,最终会被存放到out/.module_paths/Android.mk.list。如果环境变量ONE_SHOT_MAKEFILE的值不等于空，也就是我们执行的是mm或者mmm命令，那么就表示要编译的是特定的模块。这些指定要编译的模块的Android.mk文件路径就保存在环境变量ONE_SHOT_MAKEFILE中，因此直接将这些Android.mk文件加载进来就获得相应的编译规则。如果环境变量ONE_SHOT_MAKEFILE的值等于空,且dont_bother不为true，会通过out/soong/Android-aosp_arm.mk 来获得Android源代码工程下的所有Android.mk文件的路径列表，并存入到out/.module_paths/Android.mk.list 中。 ... ifneq ($(ONE_SHOT_MAKEFILE),) #我们可能已经被带有子目录makefile的“mm” shell函数调用了。 include $(SOONG_ANDROID_MK) $(wildcard $(ONE_SHOT_MAKEFILE)) # Change CUSTOM_MODULES to include only modules that were # defined by this makefile; this will install all of those # modules as a side-effect. Do this after including ONE_SHOT_MAKEFILE # so that the modules will be installed in the same place they # would have been with a normal make. CUSTOM_MODULES := $(sort $(call get-tagged-modules,$(ALL_MODULE_TAGS))) #帮助目标打印出安装路径 define register_module_install_path .PHONY: GET-MODULE-INSTALL-PATH-$(1) GET-MODULE-INSTALL-PATH-$(1): echo 'INSTALL-PATH: $(1) $(ALL_MODULES.$(1).INSTALLED)' endef SORTED_ALL_MODULES := $(sort $(ALL_MODULES)) UNIQUE_ALL_MODULES := $(foreach m,$(SORTED_ALL_MODULES),\ $(if $(call streq,$(m),$(lastword $(UNIQUE_ALL_MODULES))),,\ $(eval UNIQUE_ALL_MODULES += $(m)))) SORTED_ALL_MODULES := $(foreach mod,$(UNIQUE_ALL_MODULES),$(if $(ALL_MODULES.$(mod).INSTALLED),\ $(eval $(call register_module_install_path,$(mod)))\ $(foreach path,$(ALL_MODULES.$(mod).PATH),\ $(eval my_path_prefix := GET-INSTALL-PATH-IN)\ $(foreach component,$(subst /,$(space),$(path)),\ $(eval my_path_prefix := $$(my_path_prefix)-$$(component))\ $(eval .PHONY: $$(my_path_prefix))\ $(eval $$(my_path_prefix): GET-MODULE-INSTALL-PATH-$(mod)))))) UNIQUE_ALL_MODULES := else # ONE_SHOT_MAKEFILE ifneq ($(dont_bother),true) FULL_BUILD := true #包括系统中的所有makefile ：out/.module_paths/Android.mk.list subdir_makefiles := $(SOONG_ANDROID_MK) $(file <$(OUT_DIR)/.module_paths/Android.mk.list) subdir_makefiles_total := $(words int $(subdir_makefiles) post finish) .KATI_READONLY := subdir_makefiles_total $(foreach mk,$(subdir_makefiles),$(info [$(call inc_and_print,subdir_makefiles_inc)/$(subdir_makefiles_total)] including $(mk) ...)$(eval include $(mk))) ifneq (,$(PDK_FUSION_PLATFORM_ZIP)$(PDK_FUSION_PLATFORM_DIR)) # 加载pdk_fusion_modules.mk include $(BUILD_SYSTEM)/pdk_fusion_modules.mk endif # PDK_FUSION_PLATFORM_ZIP || PDK_FUSION_PLATFORM_DIR droid_targets : blueprint_tools endif # dont_bother endif # ONE_SHOT_MAKEFILE ...6.4.7 Link检查编译时的Link 类型检查，校验Link... #Link 类型检查 #“ALL_LINK_TYPES”包含所有链接类型前缀的列表（通常每个模块一个，但是apk可以“链接”到java和本机代码）。 #链接类型前缀由intermediates dir所需的所有信息组成： # # LINK_TYPE:TARGET:_:2ND:STATIC_LIBRARIES:libfoo # #所有未在“允许”或“警告”中列出的依赖关系链接类型都将成为错误 link_type_error := define link-type-prefix-base $(word 2,$(subst :,$(space),$(1))) endef define link-type-prefix $(if $(filter AUX-%,$(link-type-prefix-base)),$(patsubst AUX-%,AUX,$(link-type-prefix-base)),$(link-type-prefix-base)) endef define link-type-aux-variant $(if $(filter AUX-%,$(link-type-prefix-base)),$(patsubst AUX-%,%,$(link-type-prefix-base))) endef define link-type-common $(patsubst _,,$(word 3,$(subst :,$(space),$(1)))) endef define link-type-2ndarchprefix $(patsubst _,,$(word 4,$(subst :,$(space),$(1)))) endef define link-type-class $(word 5,$(subst :,$(space),$(1))) endef define link-type-name $(word 6,$(subst :,$(space),$(1))) endef define link-type-os $(strip $(eval _p := $(link-type-prefix))\ $(if $(filter HOST HOST_CROSS,$(_p)),\ $($(_p)_OS),\ $(if $(filter AUX,$(_p)),AUX,android))) endef define link-type-arch $($(link-type-prefix)_$(link-type-2ndarchprefix)ARCH) endef define link-type-name-variant $(link-type-name) ($(link-type-class) $(link-type-os)-$(link-type-arch)) endef ... # 验证$（1）是否可以链接到$（2） # $（1）和$（2）都是上面定义的链接类型前缀 define verify-link-type $(foreach t,$($(2).TYPE),\ $(if $(filter-out $($(1).ALLOWED),$(t)),\ $(if $(filter $(t),$($(1).WARN)),\ $(call link-type-warning,$(1),$(2),$(t)),\ $(call link-type-error,$(1),$(2),$(t))))) endef #验证所有分支/配置都有合理的警告/错误，并删除此重写 verify-link-type = $(eval $$(1).MISSING := true) ...6.4.8 加载product_config.mk要为此产品生成的模块的基本列表由相应的产品定义文件指定，这些定义在"product_config.mk"中... #列出特定产品安装的大多数文件，包括： # - PRODUCT_PACKAGES, and their LOCAL_REQUIRED_MODULES # - PRODUCT_COPY_FILES # 要为此产品生成的模块的基本列表由相应的产品定义文件指定，这些定义在"product_config.mk"中 define product-installed-files $(eval _mk := $(strip $(1))) \ $(eval _pif_modules := \ $(PRODUCTS.$(_mk).PRODUCT_PACKAGES) \ $(if $(filter eng,$(tags_to_install)),$(PRODUCTS.$(_mk).PRODUCT_PACKAGES_ENG)) \ $(if $(filter debug,$(tags_to_install)),$(PRODUCTS.$(_mk).PRODUCT_PACKAGES_DEBUG)) \ $(if $(filter tests,$(tags_to_install)),$(PRODUCTS.$(_mk).PRODUCT_PACKAGES_TESTS)) \ $(if $(filter asan,$(tags_to_install)),$(PRODUCTS.$(_mk).PRODUCT_PACKAGES_DEBUG_ASAN)) \ $(call auto-included-modules) \ ) \ $(eval ### Filter out the overridden packages and executables before doing expansion) \ $(eval _pif_overrides := $(call module-overrides,$(_pif_modules))) \ $(eval _pif_modules := $(filter-out $(_pif_overrides), $(_pif_modules))) \ $(eval ### Resolve the :32 :64 module name) \ $(eval _pif_modules_32 := $(patsubst %:32,%,$(filter %:32, $(_pif_modules)))) \ $(eval _pif_modules_64 := $(patsubst %:64,%,$(filter %:64, $(_pif_modules)))) \ $(eval _pif_modules_rest := $(filter-out %:32 %:64,$(_pif_modules))) \ $(eval ### Note for 32-bit product, 32 and 64 will be added as their original module names.) \ $(eval _pif_modules := $(call get-32-bit-modules-if-we-can, $(_pif_modules_32))) \ $(eval _pif_modules += $(_pif_modules_64)) \ $(eval ### For the rest we add both) \ $(eval _pif_modules += $(call get-32-bit-modules, $(_pif_modules_rest))) \ $(eval _pif_modules += $(_pif_modules_rest)) \ $(call expand-required-modules,_pif_modules,$(_pif_modules),$(_pif_overrides)) \ $(filter-out $(HOST_OUT_ROOT)/%,$(call module-installed-files, $(_pif_modules))) \ $(call resolve-product-relative-paths,\ $(foreach cf,$(PRODUCTS.$(_mk).PRODUCT_COPY_FILES),$(call word-colon,2,$(cf)))) endef ...6.4.9 运行APEX库运行时APEX库，并进行检查校验 ... APEX_MODULE_LIBS := \ libadbconnection.so \ libadbconnectiond.so \ libandroidicu.so \ libandroidio.so \ libart-compiler.so \ libart-dexlayout.so \ libart-disassembler.so \ libart.so \ libartbase.so \ libartbased.so \ libartd-compiler.so \ libartd-dexlayout.so \ libartd.so \ libartpalette.so \ libc.so \ libdexfile.so \ libdexfile_external.so \ libdexfiled.so \ libdexfiled_external.so \ libdl.so \ libdt_fd_forward.so \ libdt_socket.so \ libicui18n.so \ libicuuc.so \ libjavacore.so \ libjdwp.so \ libm.so \ libnativebridge.so \ libnativehelper.so \ libnativeloader.so \ libnpt.so \ libopenjdk.so \ libopenjdkjvm.so \ libopenjdkjvmd.so \ libopenjdkjvmti.so \ libopenjdkjvmtid.so \ libpac.so \ libprofile.so \ libprofiled.so \ libsigchain.so \ # Conscrypt APEX libraries APEX_MODULE_LIBS += \ libjavacrypto.so \ ... #如果下面的检查失败，那么某些库已经在system/lib或system/lib64中结束，而这些库只打算放入一些APEX包中。 #可能的原因是/system中的库或二进制文件已经增长了一个直接或间接拉入禁止的库的依赖关系。 #要解决此问题，请查找库所属的APEX包-在“APEX”构建模块中的“native_shared_lib”属性中搜索它（参见art/build/APEX/安卓.bp例如）。 #然后检查APEX包中是否有应该使用的导出库，即在其“native_shared_lib”属性中列出的库，对应的“cc_library”模块具有“stubs”子句（如art/libdexfile中的libdexfile_external）/安卓.bp). #如果您找不到适合您需要的APEX导出库，或者您认为/system中应该允许您依赖的库，那么请与包含该库的APEX包的所有者联系。 #如果在APEX中导出的库出现此错误，则APEX可能配置错误，或者生成系统中出现错误。 #请联系APEX包主和/或soong-team@，或android-building@googlegroups.com外部的。 define check-apex-libs-absence $(call maybe-print-list-and-error, \ $(filter $(foreach lib,$(APEX_MODULE_LIBS),%/$(lib)), \ $(filter-out $(foreach dir,$(APEX_LIBS_ABSENCE_CHECK_EXCLUDE), \ $(TARGET_OUT)/$(if $(findstring %,$(dir)),$(dir),$(dir)/%)), \ $(filter $(TARGET_OUT)/lib/% $(TARGET_OUT)/lib64/%,$(1)))), \ APEX libraries found in system image (see comment for check-apex-libs-absence in \ build/make/core/main.mk for details)) endef # TODO(b/129006418): The check above catches libraries through product # dependencies visible to make, but as long as they have install rules in # /system they may still be created there through other make targets. To catch # that we also do a check on disk just before the system image is built. define check-apex-libs-absence-on-disk $(hide) ( \ cd $(TARGET_OUT) && \ findres=$$(find lib* \ $(foreach dir,$(APEX_LIBS_ABSENCE_CHECK_EXCLUDE),-path "$(subst %,*,$(dir))" -prune -o) \ -type f \( -false $(foreach lib,$(APEX_MODULE_LIBS),-o -name $(lib)) \) \ -print) && \ if [ -n "$$findres" ]; then \ echo "APEX libraries found in system image (see comment for check-apex-libs-absence" 1>&2; \ echo "in build/make/core/main.mk for details):" 1>&2; \ echo "$$findres" | sort 1>&2; \ false; \ fi; \ ) endef endif ...6.4.10 保存所有模块将所有要安装的模块都保存在变量ALL_DEFAULT_INSTALLED_MODULES中，并且将build/core/Makefie文件加载进来。... #build/core/Makefie文件会根据要安装的模块生成system.img、super.img、boot.img和recovery.img等镜像文件的生成规则 # TODO: Remove the 3 places in the tree that use ALL_DEFAULT_INSTALLED_MODULES # and get rid of it from this list. modules_to_install := $(sort \ $(ALL_DEFAULT_INSTALLED_MODULES) \ $(product_target_FILES) \ $(product_host_FILES) \ $(call get-tagged-modules,$(tags_to_install)) \ $(CUSTOM_MODULES) \ ) ... #build/make/core/Makefile包含了我们不想污染这个顶级Makefile的额外内容。 #它希望“ALL_DEFAULT_INSTALLED_MODULES”包含当前make期间构建的所有模块，但它还进一步扩展了“ALL_DEFAULT_INSTALLED_MODULES”。 ALL_DEFAULT_INSTALLED_MODULES := $(modules_to_install) include $(BUILD_SYSTEM)/Makefile modules_to_install := $(sort $(ALL_DEFAULT_INSTALLED_MODULES)) ALL_DEFAULT_INSTALLED_MODULES := ... #这是用来获得正确的秩序，你也可以使用这些，但他们被认为是没有文件，所以不要抱怨，如果他们的行为改变。 #依赖于所有复制头的内部目标（请参见复制_标题.make). 需要首先复制头的其他目标可以依赖于此目标。 .PHONY: all_copied_headers all_copied_headers: ; $(ALL_C_CPP_ETC_OBJECTS): | all_copied_headers # All the droid stuff, in directories .PHONY: files files: $(modules_to_install) \ $(INSTALLED_ANDROID_INFO_TXT_TARGET) ...6.4.11 定义编译的image目标定义了我们编译过程中的所有image目标... .PHONY: ramdisk ramdisk: $(INSTALLED_RAMDISK_TARGET) .PHONY: ramdisk_debug ramdisk_debug: $(INSTALLED_DEBUG_RAMDISK_TARGET) .PHONY: systemtarball systemtarball: $(INSTALLED_SYSTEMTARBALL_TARGET) .PHONY: boottarball boottarball: $(INSTALLED_BOOTTARBALL_TARGET) .PHONY: userdataimage userdataimage: $(INSTALLED_USERDATAIMAGE_TARGET) ifneq (,$(filter userdataimage, $(MAKECMDGOALS))) $(call dist-for-goals, userdataimage, $(BUILT_USERDATAIMAGE_TARGET)) endif .PHONY: userdatatarball userdatatarball: $(INSTALLED_USERDATATARBALL_TARGET) .PHONY: cacheimage cacheimage: $(INSTALLED_CACHEIMAGE_TARGET) .PHONY: bptimage bptimage: $(INSTALLED_BPTIMAGE_TARGET) .PHONY: vendorimage vendorimage: $(INSTALLED_VENDORIMAGE_TARGET) .PHONY: productimage productimage: $(INSTALLED_PRODUCTIMAGE_TARGET) .PHONY: productservicesimage productservicesimage: $(INSTALLED_PRODUCT_SERVICESIMAGE_TARGET) .PHONY: odmimage odmimage: $(INSTALLED_ODMIMAGE_TARGET) .PHONY: systemotherimage systemotherimage: $(INSTALLED_SYSTEMOTHERIMAGE_TARGET) .PHONY: superimage_empty superimage_empty: $(INSTALLED_SUPERIMAGE_EMPTY_TARGET) .PHONY: bootimage bootimage: $(INSTALLED_BOOTIMAGE_TARGET) .PHONY: bootimage_debug bootimage_debug: $(INSTALLED_DEBUG_BOOTIMAGE_TARGET) .PHONY: vbmetaimage vbmetaimage: $(INSTALLED_VBMETAIMAGE_TARGET) .PHONY: auxiliary auxiliary: $(INSTALLED_AUX_TARGETS) ...6.4.12 构建系统，打包rom构建文件，然后将其打包成rom格式... .PHONY: droidcore droidcore: $(filter $(HOST_OUT_ROOT)/%,$(modules_to_install)) \ $(INSTALLED_SYSTEMIMAGE_TARGET) \ $(INSTALLED_RAMDISK_TARGET) \ $(INSTALLED_BOOTIMAGE_TARGET) \ $(INSTALLED_DEBUG_RAMDISK_TARGET) \ $(INSTALLED_DEBUG_BOOTIMAGE_TARGET) \ $(INSTALLED_RECOVERYIMAGE_TARGET) \ $(INSTALLED_VBMETAIMAGE_TARGET) \ $(INSTALLED_USERDATAIMAGE_TARGET) \ $(INSTALLED_CACHEIMAGE_TARGET) \ $(INSTALLED_BPTIMAGE_TARGET) \ $(INSTALLED_VENDORIMAGE_TARGET) \ $(INSTALLED_ODMIMAGE_TARGET) \ $(INSTALLED_SUPERIMAGE_EMPTY_TARGET) \ $(INSTALLED_PRODUCTIMAGE_TARGET) \ $(INSTALLED_SYSTEMOTHERIMAGE_TARGET) \ $(INSTALLED_FILES_FILE) \ $(INSTALLED_FILES_JSON) \ $(INSTALLED_FILES_FILE_VENDOR) \ $(INSTALLED_FILES_JSON_VENDOR) \ $(INSTALLED_FILES_FILE_ODM) \ $(INSTALLED_FILES_JSON_ODM) \ $(INSTALLED_FILES_FILE_PRODUCT) \ $(INSTALLED_FILES_JSON_PRODUCT) \ $(INSTALLED_FILES_FILE_PRODUCT_SERVICES) \ $(INSTALLED_FILES_JSON_PRODUCT_SERVICES) \ $(INSTALLED_FILES_FILE_SYSTEMOTHER) \ $(INSTALLED_FILES_JSON_SYSTEMOTHER) \ $(INSTALLED_FILES_FILE_RAMDISK) \ $(INSTALLED_FILES_JSON_RAMDISK) \ $(INSTALLED_FILES_FILE_DEBUG_RAMDISK) \ $(INSTALLED_FILES_JSON_DEBUG_RAMDISK) \ $(INSTALLED_FILES_FILE_ROOT) \ $(INSTALLED_FILES_JSON_ROOT) \ $(INSTALLED_FILES_FILE_RECOVERY) \ $(INSTALLED_FILES_JSON_RECOVERY) \ $(INSTALLED_ANDROID_INFO_TXT_TARGET) \ auxiliary \ soong_docs ... #构建一个完整的系统——默认情况下是构建droidcore droid_targets: droidcore dist_files ...7. 总结至此,make的流程我们基本理清了，后面还有ninja是如何把build.ninja编译出来的，image如何打包的，我们后面继续分析。

[转载]编译环境初始化-Android10.0编译系统（二） 版权声明：本文为CSDN博主「IngresGe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/yiranfeng/article/details/1090837541. 概述上一节针对Android编译系统做了一个笼统的说明，这一节针对编译环境初始化做一下详细的展示。2. 编译环境初始化初始化命令：source build/envsetup.shenvsetup.sh 主要做了下面几个事情：envsetup.sh 构建代码：  ...   validate_current_shell   source_vendorsetup   addcompletions2.1 hmm查看支持接口输入hmm可以看到envsetup支持的一些接口命令说明lunchlunch <product_name>-<build_variant>选择<product_name>作为要构建的产品，<build_variant>作为要构建的变体，并将这些选择存储在环境中，以便后续调用“m”等读取。tapas交互方式：tapas [<App1> <App2> ...] [arm\x86\mips\arm64\x86_64\mips64] [eng\userdebug\user]croot将目录更改到树的顶部或其子目录。m编译整个源码，可以不用切换到根目录mm编译当前目录下的源码，包含他们的依赖模块(11包含)mmm编译指定目录下的所有模块，包含他们的依赖模块（11包含）   例如：mmm dir/:target1,target2.mma编译当前目录下的源码，包含他们的依赖模块mmma编译指定目录下的所模块，包含他们的依赖模块provision具有所有必需分区的闪存设备。选项将传递给fastboot。cgrep对系统本地所有的C/C++ 文件执行grep命令ggrep对系统本地所有的Gradle文件执行grep命令jgrep对系统本地所有的Java文件执行grep命令resgrep对系统本地所有的res目录下的xml文件执行grep命令mangrep对系统本地所有的AndroidManifest.xml文件执行grep命令mgrep对系统本地所有的Makefiles文件执行grep命令sepgrep对系统本地所有的sepolicy文件执行grep命令sgrep对系统本地所有的source文件执行grep命令godir根据godir后的参数文件名在整个目录下查找，并且切换目录allmod列出所有模块gomod转到包含模块的目录pathmod获取包含模块的目录refreshmod刷新allmod/gomod的模块列表2.2 validate_current_shell确定当前的shell环境，建立shell命令function validate_current_shell() { local current_sh="$(ps -o command -p $$)" case "$current_sh" in *bash*) function check_type() { type -t "$1"; } ;; *zsh*) function check_type() { type "$1"; } enable_zsh_completion ;; *) echo -e "WARNING: Only bash and zsh are supported.\nUse of other shell would lead to erroneous results." ;; esac }2.3 source_vendorsetup从device\vendor\product等目录遍历搜索vendorsetup.sh,并source进来function source_vendorsetup() { allowed= for f in $(find -L device vendor product -maxdepth 4 -name 'allowed-vendorsetup_sh-files' 2>/dev/null | sort); do if [ -n "$allowed" ]; then echo "More than one 'allowed_vendorsetup_sh-files' file found, not including any vendorsetup.sh files:" echo " $allowed" echo " $f" return fi allowed="$f" done allowed_files= [ -n "$allowed" ] && allowed_files=$(cat "$allowed") for dir in device vendor product; do for f in $(test -d $dir && \ find -L $dir -maxdepth 4 -name 'vendorsetup.sh' 2>/dev/null | sort); do if [[ -z "$allowed" || "$allowed_files" =~ $f ]]; then echo "including $f"; . "$f" else echo "ignoring $f, not in $allowed" fi done done }例：1.建立一个目录：/vendor/ingres/build2.创建一个vendorsetup.sh写一个log: echo "vendor build test."3.执行source build/envsetup.shsource后打印：including vendor/ingres/build/vendorsetup.sh vendor build test.2.4 addcompletionsfunction addcompletions() { local T dir f # Keep us from trying to run in something that's neither bash nor zsh. # 检测shell版本字符串BASH_VERSION 或ZSH_VERSION长度为0时，返回 if [ -z "$BASH_VERSION" -a -z "$ZSH_VERSION" ]; then return fi # Keep us from trying to run in bash that's too old. # 检测bash主版本低于3时返回 if [ -n "$BASH_VERSION" -a ${BASH_VERSINFO[0]} -lt 3 ]; then return fi # 指定bash文件目录并检查是否存在 local completion_files=( system/core/adb/adb.bash system/core/fastboot/fastboot.bash tools/asuite/asuite.sh ) # Completion can be disabled selectively to allow users to use non-standard completion. # e.g. # ENVSETUP_NO_COMPLETION=adb # -> disable adb completion # ENVSETUP_NO_COMPLETION=adb:bit # -> disable adb and bit completion #*.bash文件列表，并将这些*.bash文件包含进来 for f in ${completion_files[*]}; do if [ -f "$f" ] && should_add_completion "$f"; then # 对*.bash文件执行'.'操作 . $f fi done if should_add_completion bit ; then complete -C "bit --tab" bit fi if [ -z "$ZSH_VERSION" ]; then # Doesn't work in zsh. complete -o nospace -F _croot croot fi complete -F _lunch lunch # _lunch命令提供lunch命令的补全操作 complete -F _complete_android_module_names gomod complete -F _complete_android_module_names m }3. lunch aosp_arm_eng3.1 lunch说明环境变量初始化完成后，我们需要选择一个编译目标。lunch 主要作用是根据用户输入或者选择的产品名来设置与具体产品相关的环境变量。执行命令：lunch 1， 可以看到配置的一些环境变量lunch结果说明PLATFORM_VERSION_CODENAME=REL表示平台版本的名称PLATFORM_VERSION=10Android平台的版本号TARGET_PRODUCT=aosp_arm所编译的产品名称TARGET_BUILD_VARIANT=userdebug所编译产品的类型TARGET_BUILD_TYPE=release编译的类型，debug和releaseTARGET_ARCH=arm表示编译目标的CPU架构TARGET_ARCH_VARIANT=armv7-a-neon表示编译目标的CPU架构版本TARGET_CPU_VARIANT=generic表示编译目标的CPU代号HOST_ARCH=x86_64表示编译平台的架构HOST_2ND_ARCH=x86表示编译平台的第二CPU架构HOST_OS=linux表示编译平台的操作系统HOST_OS_EXTRA=Linux-4.15.0-112-generic-x86_64-Ubuntu-16.04.6-LTS编译系统之外的额外信息HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release编译类型BUILD_ID=QQ1D.200205.002BUILD_ID会出现在版本信息中，可以利用OUT_DIR=out编译结果输出的路径lunch aosp_arm-eng 结束后，后创建一个out文件夹,生成一些中间文件如下图所示：3.2 lunch()lunch命令用来设置 TARGET_PRODUCT、TARGET_BUILD_VARIANT、TARGET_PLATFORM_VERSION、TARGET_BUILD_TYPE、TARGET_BUILD_APPS等环境变量lunch操作流程如下：1.获取lunch操作的参数，如果参数不为空，参数则为指定要编译的设备型号和编译类型；如果参数为空，会调用print_lunch_menu来显示Lunch菜单项，读取用户的输入，存入answer2.如果answer为空，即之前在lunch菜单用，用户只敲了一个回车。会将默认选项改为aosp_arm-eng，结果存入selection3.如果lunch操作得到的输入是数字，则将数字转换为LUNCH_MENU_CHOICES中的字符串，结果存入selection4.解析selection的值，得到product = aosp_arm 和variant = eng, 把他们分别保存到TARGET_PRODUCT 和 TARGET_BUILD_VARIANT 中5.根据前面的设置，调用build_build_var_cache 来更新编译环境相关变量6.export 编译选项TARGET_PRODUCT, TARGET_BUILD_VARIANT和TARGET_BUILD_TYPE三元组7.调用set_stuff_for_environment 来设置其他环境变量，如PROMPT_COMMAND，编译toolchain和tools相关的路径等8.调用printconfig 来输出当前的设置选项function lunch() { local answer # 获取lunch操作的参数 if [ "$1" ] ; then answer=$1 else # lunch操作不带参数，则先显示lunch menu，然后读取用户输入 print_lunch_menu echo -n "Which would you like? [aosp_arm-eng] " read answer fi local selection= # lunch操作得到的结果为空（例如用户直接在lunch要求输入时回车的情况） # 则将选项默认为"aosp_arm-eng" if [ -z "$answer" ] then selection=aosp_arm-eng # lunch操作得到的输入是数字，则将数字转换为LUNCH_MENU_CHOICES中的字符串 elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$") then local choices=($(TARGET_BUILD_APPS= get_build_var COMMON_LUNCH_CHOICES)) if [ $answer -le ${#choices[@]} ] then # array in zsh starts from 1 instead of 0. if [ -n "$ZSH_VERSION" ] then selection=${choices[$(($answer))]} else selection=${choices[$(($answer-1))]} fi fi else selection=$answer fi export TARGET_BUILD_APPS= local product variant_and_version variant version product=${selection%%-*} # Trim everything after first dash variant_and_version=${selection#*-} # Trim everything up to first dash if [ "$variant_and_version" != "$selection" ]; then variant=${variant_and_version%%-*} if [ "$variant" != "$variant_and_version" ]; then version=${variant_and_version#*-} fi fi if [ -z "$product" ] then echo echo "Invalid lunch combo: $selection" return 1 fi # 设置TARGET_PRODUCT和TARGET_BUILD_VARIANT TARGET_PRODUCT=$product \ TARGET_BUILD_VARIANT=$variant \ TARGET_PLATFORM_VERSION=$version \ # 根据前面的设置，更新编译环境相关变量 build_build_var_cache #参考[3.1.1] if [ $? -ne 0 ] then return 1 fi # export 编译选项TARGET_PRODUCT, TARGET_BUILD_VARIANT和TARGET_BUILD_TYPE三元组 export TARGET_PRODUCT=$(get_build_var TARGET_PRODUCT) export TARGET_BUILD_VARIANT=$(get_build_var TARGET_BUILD_VARIANT) if [ -n "$version" ]; then export TARGET_PLATFORM_VERSION=$(get_build_var TARGET_PLATFORM_VERSION) else unset TARGET_PLATFORM_VERSION fi export TARGET_BUILD_TYPE=release echo set_stuff_for_environment # 设置其他环境变量，如PROMPT_COMMAND，编译toolchain和tools相关的路径等 printconfig # 输出当前的设置选项 destroy_build_var_cache }3.1.1 build_build_var_cache()根据前面的设置，更新编译环境相关变量主要通过执行 "build/soong/soong_ui.bash --dumpvars-mode" 完成最终执行的是 "./out/soog_ui --dumpvars-mode"function build_build_var_cache() { local T=$(gettop) # Grep out the variable names from the script. cached_vars=(`cat $T/build/envsetup.sh | tr '()' ' ' | awk '{for(i=1;i<=NF;i++) if($i~/get_build_var/) print $(i+1)}' | sort -u | tr '\n' ' '`) cached_abs_vars=(`cat $T/build/envsetup.sh | tr '()' ' ' | awk '{for(i=1;i<=NF;i++) if($i~/get_abs_build_var/) print $(i+1)}' | sort -u | tr '\n' ' '`) # Call the build system to dump the "<val>=<value>" pairs as a shell script. build_dicts_script=`\builtin cd $T; build/soong/soong_ui.bash --dumpvars-mode \ --vars="${cached_vars[*]}" \ --abs-vars="${cached_abs_vars[*]}" \ --var-prefix=var_cache_ \ --abs-var-prefix=abs_var_cache_` local ret=$? if [ $ret -ne 0 ] then unset build_dicts_script return $ret fi # Execute the script to store the "<val>=<value>" pairs as shell variables. eval "$build_dicts_script" ret=$? unset build_dicts_script if [ $ret -ne 0 ] then return $ret fi BUILD_VAR_CACHE_READY="true" }soong_ui 由build/soong/cmd/soong_ui/main.go编译生成[build/soong/cmd/soong_ui/main.go] func main() { ... if os.Args[1] == "--dumpvar-mode" { dumpVar(buildCtx, config, os.Args[2:]) } else if os.Args[1] == "--dumpvars-mode" { dumpVars(buildCtx, config, os.Args[2:]) } else { ... } ... } [build/soong/cmd/soong_ui/main.go] func dumpVars(ctx build.Context, config build.Config, args []string) { varData, err := build.DumpMakeVars(ctx, config, nil, allVars) }最后调用到了ckati执行-f build/make/core/config.mk[/build/soong/ui/build/dumpvars.go] func dumpMakeVars(ctx Context, config Config, goals, vars []string, write_soong_vars bool) (map[string]string, error) { ctx.BeginTrace(metrics.RunKati, "dumpvars") defer ctx.EndTrace() cmd := Command(ctx, config, "dumpvars", config.PrebuiltBuildTool("ckati"), "-f", "build/make/core/config.mk", "--color_warnings", "--kati_stats", "dump-many-vars", "MAKECMDGOALS="+strings.Join(goals, " ")) cmd.Environment.Set("CALLED_FROM_SETUP", "true") if write_soong_vars { cmd.Environment.Set("WRITE_SOONG_VARIABLES", "true") } cmd.Environment.Set("DUMP_MANY_VARS", strings.Join(vars, " ")) cmd.Sandbox = dumpvarsSandbox output := bytes.Buffer{} cmd.Stdout = &output pipe, err := cmd.StderrPipe() if err != nil { ctx.Fatalln("Error getting output pipe for ckati:", err) } cmd.StartOrFatal() // TODO: error out when Stderr contains any content status.KatiReader(ctx.Status.StartTool(), pipe) cmd.WaitOrFatal() ret := make(map[string]string, len(vars)) ... return ret, nil }下面我们单独研究一下config.mk。4. config.mk 说明：config.mk首先加载了build/make/common 中的core.mk、math.mk、strings.mk、json.mk 用来配置一些shell环境、math函数、string和json的一些支持函数。最主要的操作还是加载build/make/core中的envsetup.mk和dumpvar.mk ... #配置两个目录的变量，供之后的mk使用 BUILD_SYSTEM :=$= build/make/core BUILD_SYSTEM_COMMON :=$= build/make/common #加载core.mk， 只使用ANDROID_BUILD_SHELL来包装bash。 include $(BUILD_SYSTEM_COMMON)/core.mk #设置make中使用的有效数学函数。 include $(BUILD_SYSTEM_COMMON)/math.mk include $(BUILD_SYSTEM_COMMON)/strings.mk include $(BUILD_SYSTEM_COMMON)/json.mk # 避免硬件解码路径被覆盖的调用pathmap.mk建立硬解映射 include $(BUILD_SYSTEM)/pathmap.mk # 允许项目定义自己的全局可用变量 include $(BUILD_SYSTEM)/project_definitions.mk # ############################################################### # Build system internal files # ############################################################### # 构建系统内部文件（写Android.mk时会调用include头文件，也就是这些makefile文件） BUILD_COMBOS:= $(BUILD_SYSTEM)/combo CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk ... BUILD_NOTICE_FILE := $(BUILD_SYSTEM)/notice_files.mk BUILD_HOST_DALVIK_JAVA_LIBRARY := $(BUILD_SYSTEM)/host_dalvik_java_library.mk BUILD_HOST_DALVIK_STATIC_JAVA_LIBRARY := $(BUILD_SYSTEM)/host_dalvik_static_java_library.mk BUILD_HOST_TEST_CONFIG := $(BUILD_SYSTEM)/host_test_config.mk BUILD_TARGET_TEST_CONFIG := $(BUILD_SYSTEM)/target_test_config.mk #定义大多数全局变量。这些是特定于用户的构建配置的。 include $(BUILD_SYSTEM)/envsetup.mk #构建系统为在哪里找到内核公开了几个变量 #(1)TARGET_DEVICE_KERNEL_HEADERS是为当前正在构建的设备自动创建的。 #它被设置为$（TARGET_DEVICE_DIR）/kernel headers， #例如DEVICE/samsung/tuna/kernel headers。此目录不是由任何人显式设置的，生成系统总是添加此子目录。 TARGET_DEVICE_KERNEL_HEADERS := $(strip $(wildcard $(TARGET_DEVICE_DIR)/kernel-headers)) #(2)TARGET_BOARD_KERNEL_HEADERS由BoardConfig.mk允许包含其他目录的文件。 #如果有一些常见的地方为一组设备保留了一些报头，那么这很有用。 #例如，device/<vendor>/common/kernel头可以包含一些<vendor>设备的头。 TARGET_BOARD_KERNEL_HEADERS := $(strip $(wildcard $(TARGET_BOARD_KERNEL_HEADERS))) TARGET_BOARD_KERNEL_HEADERS := $(patsubst %/,%,$(TARGET_BOARD_KERNEL_HEADERS)) $(call validate-kernel-headers,$(TARGET_BOARD_KERNEL_HEADERS)) #(3)TARGET_PRODUCT_KERNEL_头由产品继承图生成。 #这允许体系结构产品为使用该体系结构的设备提供报头。 TARGET_PRODUCT_KERNEL_HEADERS := $(strip $(wildcard $(PRODUCT_VENDOR_KERNEL_HEADERS))) TARGET_PRODUCT_KERNEL_HEADERS := $(patsubst %/,%,$(TARGET_PRODUCT_KERNEL_HEADERS)) $(call validate-kernel-headers,$(TARGET_PRODUCT_KERNEL_HEADERS)) # 选择一个Java编译器 include $(BUILD_SYSTEM)/combo/javac.mk # A list of SEPolicy versions, besides PLATFORM_SEPOLICY_VERSION, that the framework supports. #框架支持的SEPolicy版本列表，除了PLATFORM_SEPOLICY_VERSION PLATFORM_SEPOLICY_COMPAT_VERSIONS := \ 26.0 \ 27.0 \ 28.0 \ ifeq ($(CALLED_FROM_SETUP),true) include $(BUILD_SYSTEM)/ninja_config.mk include $(BUILD_SYSTEM)/soong_config.mk endif #加载dumpvar.mk,用来生成make目标 include $(BUILD_SYSTEM)/dumpvar.mk4.1 build/make/core/envsetup.mkenvsetup.mk 主要加载了product_config.mk和board_config.mk，用来得到TARGET_DEVICE和其他变量。... #设置host和target编译链相关的变量 include $(BUILD_SYSTEM)/combo/select.mk #(1)阅读产品规格，这样我们就可以得到TARGET_DEVICE和其他变量，我们需要找到输出文件 include $(BUILD_SYSTEM)/product_config.mk include $(BUILD_SYSTEM)/board_config.mk ...4.2 build/make/core/product_config.mk阅读产品规格，这样我们就可以得到TARGET_DEVICE和其他变量，我们需要找到输出文件。... # --------------------------------------------------------------- # Include the product definitions. # We need to do this to translate TARGET_PRODUCT into its # underlying TARGET_DEVICE before we start defining any rules. # include $(BUILD_SYSTEM)/node_fns.mk include $(BUILD_SYSTEM)/product.mk include $(BUILD_SYSTEM)/device.mk ... ############################################################################# # Sanity check and assign default values TARGET_DEVICE := $(PRODUCT_DEVICE) ...4.3 build/make/core/board_config.mk板级可以在$（SRC_TARGET_DIR）/board/$（TARGET_DEVICE）下定义，也可以在vendor/\*/$（TARGET_DEVICE）下定义。在这两个地方搜索，但要确保只存在一个。真正的板级应始终与OEM vendor相关联。... # Boards may be defined under $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE) # or under vendor/*/$(TARGET_DEVICE). Search in both places, but # make sure only one exists. # Real boards should always be associated with an OEM vendor. ifdef TARGET_DEVICE_DIR ifneq ($(origin TARGET_DEVICE_DIR),command line) $(error TARGET_DEVICE_DIR may not be set manually) endif board_config_mk := $(TARGET_DEVICE_DIR)/BoardConfig.mk else board_config_mk := \ $(strip $(sort $(wildcard \ $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \ $(shell test -d device && find -L device -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \ $(shell test -d vendor && find -L vendor -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \ ))) ifeq ($(board_config_mk),) $(error No config file found for TARGET_DEVICE $(TARGET_DEVICE)) endif ifneq ($(words $(board_config_mk)),1) $(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk)) endif TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk))) .KATI_READONLY := TARGET_DEVICE_DIR endif include $(board_config_mk) ...5. 总结至此，envsetup.sh 和lunch()的初始化流程基本上理清了，主要就是加载了环境变量，并选择了编译目标，后面只要执行一下make就能够进行启动编译，下一节让我们一起看看敲下make后到底发生了什么。

[转载]编译系统入门篇-Android10.0编译系统（一） 转载自编译系统入门篇-Android10.0编译系统（一）版权声明：本文为CSDN博主「IngresGe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/yiranfeng/article/details/1090824891. 概述在 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 MakeAndroid7.0 引入ninja、kati、Android.bp和soong构建系统Android8.0 默认打开Android.bpAndroid9.0 强制使用Android.bpGoogle在 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、soongblueprint：用于处理Android.bp，编译生成*.ninja文件，用于做ninja的处理kati：用于处理Android.mk，编译生成*.ninja文件，用于做ninja的处理make：文件夹还是原始的make那一套流程，比如envsetup.shsoong：构建系统，核心编译为soong_ui.bash Soong编译系统家族成员及各自关系如下图所示：在编译过程中，Android.bp会被收集到out/soong/build.ninja.d,blueprint以此为基础，生成out/soong/build.ninjaAndroid.mk会由kati/ckati生成为out/build-aosp_arm.ninja两个ninja文件会被整合进入out/combined-aosp_arm.ninjaout/combined-aosp_arm.ninja内容如下所示：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.ninja2.2 编译步骤source build/envsetup.shlunch aosp_arm-eng // 或者 m PRODUCT-aosp_x86_64-eng ，Android10.0不一定需要lunch命令make -j8      //编译模块也可以直接用 m libartAndroid10.0编译步骤如下图所示：3. 编译环境初始化3.1 envsetup说明 source build/envsetup.sh这里的envsetup.sh被link到了 build/make/envsetup.shenvsetup.sh 主要做了下面几个事情：在source build/envsetup.sh后，输入hmm可以看到envsetup支持的一些接口：命令说明lunchlunch <product_name>-<build_variant>选择<product_name>作为要构建的产品，<build_variant>作为要构建的变体，并将这些选择存储在环境中，以便后续调用“m”等读取。tapas交互方式：tapas [<App1> <App2> ...] [arm\x86\mips\arm64\x86_64\mips64] [eng\userdebug\user]croot将目录更改到树的顶部或其子目录。m编译整个源码，可以不用切换到根目录mm编译当前目录下的源码，不包含他们的依赖模块mmm编译指定目录下的所有模块，不包含他们的依赖模块   例如：mmm dir/:target1,target2.mma编译当前目录下的源码，包含他们的依赖模块mmma编译指定目录下的所模块，包含他们的依赖模块provision具有所有必需分区的闪存设备。选项将传递给fastboot。cgrep对系统本地所有的C/C++ 文件执行grep命令ggrep对系统本地所有的Gradle文件执行grep命令jgrep对系统本地所有的Java文件执行grep命令resgrep对系统本地所有的res目录下的xml文件执行grep命令mangrep对系统本地所有的AndroidManifest.xml文件执行grep命令mgrep对系统本地所有的Makefiles文件执行grep命令sepgrep对系统本地所有的sepolicy文件执行grep命令sgrep对系统本地所有的source文件执行grep命令godir根据godir后的参数文件名在整个目录下查找，并且切换目录allmod列出所有模块gomod转到包含模块的目录pathmod获取包含模块的目录refreshmod刷新allmod/gomod的模块列表3.2 Lunch说明环境变量初始化完成后，我们需要选择一个编译目标。lunch 主要作用是根据用户输入或者选择的产品名来设置与具体产品相关的环境变量。如果你不知道想要编译的目标是什么，直接执行一个lunch命令，会列出所有的目标，直接回车，会默认使用aosp\_arm-eng这个目标。执行命令：lunch 1， 可以看到配置的一些环境变量这些环境变量的含义如下：lunch结果说明PLATFORM_VERSION_CODENAME=REL表示平台版本的名称PLATFORM_VERSION=10Android平台的版本号TARGET_PRODUCT=aosp_arm所编译的产品名称TARGET_BUILD_VARIANT=userdebug所编译产品的类型TARGET_BUILD_TYPE=release编译的类型，debug和releaseTARGET_ARCH=arm表示编译目标的CPU架构TARGET_ARCH_VARIANT=armv7-a-neon表示编译目标的CPU架构版本TARGET_CPU_VARIANT=generic表示编译目标的CPU代号HOST_ARCH=x86_64表示编译平台的架构HOST_2ND_ARCH=x86表示编译平台的第二CPU架构HOST_OS=linux表示编译平台的操作系统HOST_OS_EXTRA=Linux-4.15.0-112-generic-x86_64-Ubuntu-16.04.6-LTS编译系统之外的额外信息HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release编译类型BUILD_ID=QQ1D.200205.002BUILD_ID会出现在版本信息中，可以利用OUT_DIR=out编译结果输出的路径4. Make说明执行完lunch命令后，就可以使用make命令来执行编译Build。Android10.0上是通过soong执行编译构建，这里执行make命令时，main.mk文件把一些环境变量和目标都配置好后，会执行envsetup.sh中的make()进行编译。如果找到“build/soong/soong_ui.bash”，就使用soong_ui.bash 来进行编译，否则使用原始的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 }配置一些资源环境，得到一些函数命令，例如：soong_build_go,最终回退到根目录，执行out/soong_ui --make-mode进行真正的构建soong_build_go soong_ui android/soong/cmd/soong_ui  是通过编译android/soong/cmd/soong_ui/main.go来编译生成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 ”最终会执行 exec out/soong_ui --make-mode 进行编译soong的编译过程如下图所示：执行runKatiBuild时，有个重要的步骤，就是加载build/make/core/main.mk，main.mk文件是Android Build系统的主控文件。从main.mk开始，将通过include命令将其所有需要的.mk文件包含进来，最终在内存中形成一个包括所有编译脚本的集合，这个相当于一个巨大Makefile文件。Makefile文件看上去很庞大，其实主要由三种内容构成: 变量定义、函数定义和目标依赖规则，此外mk文件之间的包含也很重要。main.mk的包含关系如下图所示：一些关键的mk文件说明：文件说明build/make/core/main.mkBuild的主控文件，主要作用是包含其他mk，以及定义几个最重要的编译目标，同时检查编译工具的版本，例如如gcc、clang、java等build/make/core/config.mkBuild的配置文件，主要是区分各个产品的配置，并将这些编译器参数引入产品配置 BoardConfig.mk,同时也配置了一些编译器的路径等build/make/core/clang/config.mkclang编译的配置文件build/make/core/definitions.mk最重要的 Make 文件之一，在其中定义了大量的函数。这些函数都是 Build 系统的其他文件将用到的。例如：my-dir，all-subdir-makefiles，find-subdir-files，sign-package 等，关于这些函数的说明请参见每个函数的代码注释。build/make/core/dex_preopt.mk定义了dex优化相关的路径和参数build/make/core/pdk_config.mk编译pdk的配置文件build/make/core/Makefile系统最终编译完成所需要的各种目标和规则build/make/core/envsetup.mk包含进product_config.mk文件并且根据其内容设置编译产品所需要的环境变量，并检查合法性，指定输出路径等build/make/core/combo/select.mk根据当前编译器的平台选择平台相关的 Make 文件build/make/core/ninja_config.mk解析makefile的的列表，传给kati，配置传给ninja和kati的目标build/make/core/soong_config.mk配置soong的环境变量，建立go变量和mk变量的json映射关系，让go变量可以获取到mk中定义的变量值5. 编译工具链说明Android10.0的编译系统中，涉及以下一些工具链，由这些工具链相辅相成，才最终编译出了我们所需要的镜像版本。Android10.0编译工具链:soong\kati\blueprint\ninja 5.1 Soong说明Soong 构建系统是在 Android 7.0 (Nougat) 中引入的，旨在取代 Make。它利用 Kati GNU Make 克隆工具和 Ninja 构建系统组件来加速 Android 的构建。Soong是由Go语言写的一个项目，从Android 7.0开始，在prebuilts/go/目录下新增了Go语言所需的运行环境，Soong在编译时使用，解析Android.bp，将之转化为Ninja文件，完成Android的选择编译，解析配置工作等。故Soong相当于Makefile编译系统的核心，即build/make/core下面的内容。另外Soong还会编译产生一个androidmk命令，可以用来手动将Android.mk转换成Android.bp文件。不过这只对无选择、循环等复杂流程控制的Android.mk生效。soong脚本和代码目录：/build/soong5.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/kati5.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/blueprint5.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的编译。

[转载]浅谈UML中常用的几种图 转载自https://blog.csdn.net/qq_35495763/article/details/807649141. UML简介统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。‘UML感兴趣的可以阅读UML 1规 范，包含了UML 的所有知识内容。注：OMG, Object Management Group 对象管理组织2. UML常见图分类UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。分类：面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。静态结构图Static Structure Diagram类图Class Diagram对象图Object Diagram用况图Use Case Diagram交互图Interaction Diagram顺序图Sequence Diagram协作图Collaboration Diagram状态图State chart Diagrams活动图Activity Diagrams实现图Implementation Diagrams构件图Component Diagram部署图Deployment Diagram3. （用况图）用例用例图，展现了一组用例、参与者（actor）以及它们之间的关系。用例图从用户角度描述系统的静态使用情况，用于建立需求模型。(用于需求分析)参与者（Actor）在系统外部与系统直接交互的人或事物。需要注意以下两点：1）参与者是角色而不是具体的人（可以是外部系统），它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。2）参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。在UML中，参与者使用如图所示的一个小人表示：在UML中，参与者使用如图所示的一个小人表示：用例（Use Case）系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能：子系统(Subsystem)用来展示系统的一部分功能，这部分功能联系紧密。关系（Relationship）常见关系类型有关联、泛化、包含和扩展。以上各关系在UML图中的表示方式，如下表所示：关联（Association）表示参与者与用例之间的通信，任何一方都可发送或接受消息。【箭头指向】：指向消息接收方泛化（Inheritance）就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。【箭头指向】：指向父用例包含（Include）包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。【箭头指向】：指向分解出来的功能用例扩展（Extend）扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。【箭头指向】：指向基础用例包含(include)、扩展(extend)、泛化(Inheritance) 的区别：条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。对extend（扩展）而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。对Inheritance（泛化）而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；4. 类图在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)泛化（Generalization）【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。【箭头指向】：带三角箭头的实线，箭头指向父类 实现类的继承关系实现（Realization）【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.【箭头指向】：带三角箭头的虚线，箭头指向接口注意可以理解类的继承的关系的另外一种表现形式。关联（Association)【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。【代码体现】：成员变量【箭头及指向】：带普通箭头的实心线，指向被拥有者上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。下图为自身关联：聚合（Aggregation）【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。【代码体现】：成员变量【箭头及指向】：带空心菱形的实心线，菱形指向整体组合（Composition）【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。【代码体现】：成员变量【箭头及指向】：带实心菱形的实线，菱形指向整体依赖（Dependency）【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.【代码表现】：局部变量、方法的参数或者对静态方法的调用【箭头及指向】：带箭头的虚线，指向被使用者各种关系的强弱顺序：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖下面这张UML图，比较形象地展示了各种类图关系：图片转自：http://blog.csdn.net/tianhai110/article/details/6339565注意这里的雁群和大雁的关系画反了。简单类图使用 举例根据下面的陈述画出类图1)学生包括本科生、研究生两种。2)研究生的一部分利用课余时间担任助教。3)教师包括讲师和教授两种。4)一名助教可以为一位讲师或一位教授助课,一位讲师只能有一名助教,一位教授可以有5名助教。按如下描述画出一个自治机器人的类图。这张图的焦点是聚集在那些让机器人在路上行走的机制所对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类: SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法:move()、stop()、resetCounter()、statues()、distance()。这两个类又是另一个类Driver的一部分。类PathAgent 和Driver有一个1对1的关系,和CollisionSensor有1对n的关系。【问题:】综上所述请你用UML来绘制分析类图。参考答案:5. 其他辅助用途时序图时序图别称为顺序图、序列图，在我的大致印象中时序图是以时间为主线，有生命线的动态视图，主要描述的对象是对象。是交互图的一种。主要的作用是表达设计者心中对于未来程序在运作时的对象协作建模，验证软件领域模型的正确性，为程序员提供编码的蓝图。（一）概念定义：时序图是以时间为序的表示方法，主要用来描述对象之间的时间顺序。将交互关系表示为二维图的。纵轴为时间，横轴为在协作中各个独立的对象。对象存在时用一条虚线表示，当对象的过程处于激活状态是，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。如下图：四个元素（对象，生命线，消息，激活）（1）对象对象的概念就不多说了，就是类的实例化，在系统中随便都可以找到一个对象，因为我们使用的是基于OO编程的VB。（2）生命线表示对象的存在存在多久的时间（3）消息对象之间的单路通信，人有人的语言，机器有机器的语言，人和机器都是靠消息传递信息和指令的。消息的类型大致有：同步与异步，返回、阻止和超时。（4）激活表示这个时间，对象实现操作。时序图是将交互关系表示为二维图的。纵轴为时间，横轴为在协作中各个独立的对象。对象存在时用一条虚线表示，当对象的过程处于激活状态，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。（二）建模主要是按时间顺序对控制流建模（三）实例首先要分析用例的正常流，学生刷卡上机，系统记录学生上机时间，同时显示学生的基本信息，此时的学生信息时系统更新，系统根据学生上机时长和类别计算上机费用，系统保存学上上机信息。，学生下机，系统记录时间，跟新数据库，数据库更新，反馈学生信息，系统根据学生上机和下机时间、类别计算上机费用，系统保存学生上机费用然后开始画图：）创建时序图）添加对象并设置对象属性，持续性）添加消息（消息的编号，显示或取消激活显示）如图：（图片有错，不提供参考）版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/tsj11514oo/article/details/38179121协作图（Collaboration Diagram/communication Diagram）/通信图协作图(Collaboration Diagram /Communication Diagram，也叫合作图)是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。下面这张图介绍协作图的基本内容：下面一张图是一个协作图的实例，创建课程的协作图：由于协作图和时序图在语意上是相通的，所以可以互相转换，下面是利用ROSE把上面的协作图转换成的时序图的实例，可以直接使用功能进行转换：由于协作图和时序图在作用上可以替代的，在使用中，一般有了时序图就没有必要使用协作图。状态图1.概述：状态图（Statechart Diagram）主要用于描述一个特定的对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转换。2.构成要素：状态图由状态、转移和事件组成。联合使用状态和转移可以更好地建模它们，有时需要包含决策点和同步条来显示更高层次的细节信息。2.1状态（States）：在对象的生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件或状况。所有的对象都有状态，状态是对象执行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。状态图中可以包含多个开始状态，也可以包含多个结束状态。模型不必同时具有开始和结束状态，因为模型可以总是运行，从不停止。2.2转移（Transitions）：两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作并在某个特定事件发生或某个特定条件满足时进入第二个状态。2.3事件：使状态发生变化的某时刻发生的动作或活动，用来指示是什么触发了转移从而导致状态发生了改变。事件通常在从一个状态到另一个状态的转移路径上直接指定。2.4判断：判断点通过对事件判断分组转移到各自方向，提高了状态图的可视性。2.4同步：使用同步和活动图一样是为了说明并发工作流的分叉与联合。3.机房实例（注册部分）：总结：状态图重点在与描述对象的状态及其状态之间的转移，与活动图区别在于状态图注重的是行为的结果，活动图更注重是行为的动作。活动图(Activity Diagram)“活动图”可通过一系列操作将业务流程或软件进程以工作流的形式显示出来。这些操作可以由人、软件组件或计算机来执行。使用活动图可以描述多种类型的流程，如下：1、用户和您的系统之间的业务流程或工作流。2、某一用例中执行的步骤。3、软件协议，即允许在组件间进行的交互序列。4、软件算法。下面用一张图来介绍活动图的基本内容下面是用rose 和 onenote结合画的一张活动图的实例，基本囊括了活动图的重要元素。组件图(ComponentDiagram)、配置图(Deployment Diagram)组件（构件图）和配置图（部署图）是面向对象系统的物理建模时使用的两种图。组件图：描述软件组件以及组件之间的关系。组件图元素：组件、接口、依赖关系组件：是定义良好接口的物理实现单元，遵从同一组接口，提供实现物理的可替换的部分。接口：一个类提供另一个类的一组操作。依赖关系：一种使用关系（这里不做详解）构件与结构之间关系：构件与构件之间关系：依赖构件与其对应接口之间关系：实现导出接口：组件实现的接口，由提供操作的组件提供导入接口：访问服务的组件使用导入接口机房收费系统构件图：机房收费系统引用控件与报表生成器，导出EXcel，打印报表，通过代码与数据库连接实时更新数据。配置图：描述系统硬件的物理结构以及如何将软件部署在硬件上。用于对系统的实现视图建模，主要是为了描述系统各个物理组成部分的分布、提交、安装过程。组成元素：节点、关系机房收费系统部署图：补充：UML是不断修订的 在UML 中，主要是使用了9 张图，到了UML 2 中有新增了几张图；概览