Android Kernel Analysis Reading Notes Chapter 1 Android compilation system

2. the core of the android compilation system is the make introduced at the end of Chapter 1st. Based on this, a compilation framework suitable for Android is established. MK files, shell scripts, and Python scripts are combined. The system modules of the framework can be compiled or packaged separately, or integrated and packaged according to certain rules;
   the core design theories of the framework are as follows:
   1. build on make, define various targets, and introduce Python and shell scripts as appropriate.
   2. Based on the COC idea, every sub-project is forced to use android. MK file description. To reduce the difficulty of writing this file, the system has defined related variables and various common function libraries by default.
   3. use a Python script to automatically scan all subdirectories including the Android. mk file and convert the settings in the file to the make command.
4. the source code of the entire compilation system is. in the/build/directory, most of them are. MK file. Understanding the nature of the compilation system is actually to analyze the relationship between these script files.
   the entire compilation system consists of three parts: Compilation hub, sub-project, and output path. For details, see:
   
   1. compilation hub: including various. MK files. These files traverse all the sub-projects of the system and generate corresponding targets, so that you can know what specific compilation or packaging commands should be executed when executing make;
   2. sub-project: it is a function module of the entire android source code system. The directory of each function module must contain an android. MK file, which is based on COC and cannot be customized. This file describes the source files and types of output targets of the project, such as jar packages, APK packages, and so packages, the compilation center has defined many common variables and assigned values to these variables.
   3. output path: various temporary files and final target files generated during compilation. The system is defined as the out directory by default, there are two subdirectories: Host/target;
      1. out/host/: corresponds to the various tools and intermediate outputs required during compilation on the PC, use these outputs to compile the final target Program ;
      2. out/target/: corresponds to the final output files that can be deployed on mobile phones, such as various imgfiles.
6. Relationship between compiled scripts
   1. Execute the make command during compilation to find the MAKEFILE file in the top-level directory of the android source code. This file is directly redirected to./build/CORE/Main. mk;
   2. Main. mk is the start of the entire compilation hub. The default target name is droid using. Phony, so that no parameters are required when the make command is executed;
   3. Config. MK: the core is to define various common variables and compile command macros, which will depend on pathmap. mk/executable. mk/buildspec. mk/envsetup. mk/product_config.mk;
   4. Definitions. mk: defines various script functions required during compilation. For example, all-Java-files-under is used to return all java files in the specified directory;
   5. ./Build/tools/findleaves. py: used to scan all android. mk files in the specified directory. You can use parameters to exclude unnecessary directories;
      The scan result is actually the list of sub-projects mentioned above;
7. Relationship between product/variant/Tag
   2. Product: product name, which can be simply understood as our compilation target code, embodied in the source code compilation target value-the first parameter after segmentation, such as full in lunch full-Eng;
      Its value can be arbitrary, but it must be defined in the compilation and packaging script. In essence, it is a set of information combinations. Different products can include different sub-projects, for example, we can create a product by ourselves, which only includes several sub-projects we need. However, we can also automatically determine the product by using the variant sub-type instead of forcibly specifying it;
      Which sub-projects in a product can view the values of product_packages/product_copy_files In the MK file;
      For related scripts, see. MK files in the/build/target/product/directory, such as common full. the product_packages variable value is not specified in MK, while the SDK. MK specifies the variable value and specifies which sub-projects are included;
   4. Variant: Product subtype, used together with product, is a set of default values defined by the system, including eng/user/userdebug/tests, reflected in the source code compilation target value-the second parameter after segmentation, for example, Eng in lunch full-Eng stands for engineer;
      What is the function of setting the Variant Parameter? It has a close mapping relationship with the tag to be introduced next;
   6. Tag: the TAG set for each sub-project. You can set the tag for Android under the sub-project. local_module_tags variable settings in the MK file, including debug/eng/tests/optional/samples/shell_ash/shell_mksh, which cannot be set to other values. The system verifies the setting in base_rules.mk during compilation, if the verification fails, a warning is displayed and the subitem is not added to any product;
      From the above, we can see that the variant and tag are the same in many optional values. Indeed, there is a mapping relationship between them. That is to say, after the variant is specified in the compilation command, during the execution, the script compares the value of variant with the tag value set in each sub-project. If the match is found, compile the sub-project and add it to the output path of the product, otherwise, no compilation is performed;
      Note: The tag and variant are not exactly one-to-one, for example:
      1. Optional indicates that it is optional, that is, it is not required to run the Android system, but as long as the product_packages variable in the product includes this sub-project, the sub-project will be compiled and added to the product;
      2. Samples indicates an instance-based project, which is mostly an independent sub-project and generally does not need to be added to the product;
         ./Development/samples/all sub-projects under the directory are of this type;
      3. Shell_ash is only used in system/CORE/SH/sub-projects;
      4. Shell_mksh is only used in external/mksh/sub-projects;
9. For the entire process of compiling the APK package for Android standard applications, see. Understanding these principles is very important for writing bulk packaging scripts:
   
10. Framework/Android. Jar compilation (the description in this section in the book is not clear, and some of the descriptions are not accurate)
    2. first, let's look at the core of the android. jar package in the SDK, which includes the following top-level packages:
       1. JAVA/javax: it is mainly a base class library of the Java language, such as lang/IO/SQL/util/XML/net.
       2. Dalvik: there are not many internal classes, including the dexclassloader and related bytecode classes specific to the Dalvik Virtual Machine.
       3. Android: everyone is familiar with it. View/activity/handler/... are all here.
       4. asset/Res: various resource files used in some system functions.
       5. ORG/COM: Mainly third-party packages with strong versatility, such as httpclient and JSON.
    4. the preceding content can be divided into three types, which are derived from different jar packages, including:
       1. core. jar: the basic class package required for running Dalvik virtual machines. Its function is to convert and load Dex files to standard class files, on which standard Java applications can run normally; corresponds to Android. in jar, Java/javax/Dalvik/these three top-level packages;
          the source code is located in. /libcore/; the compilation target is. /libcore/android. mk. The output after compilation is located in. /out/target/common/obj/java_libraries/core_intermediates
       2. framework. jar: A framework package used to develop real Android mobile applications based on the Dalvik virtual machine, such as view rendering and management, and page Jump and management. It corresponds to Android. android/assets/RES/these three top-level packages in jar;
          the source code is located in. /frameworks/base; the compilation target is. /frameworks/base/android. mk. The output after compilation is located in. /out/target/common/obj/java_libraries/framework_intermediates
       3. Ext. jar: an extension class library that integrates toolkit that is highly universal and widely accepted and used by the industry. It corresponds to Android. in jar, org/COM/these two top-level packages;
          the source code is located in. /external/; the compilation target is in. /frameworks/base/android. mk. The output after compilation is located in. /out/target/common/obj/java_libraries/ext_intermediates
    6. But does core. Jar/framework. Jar/EXT. Jar contain all the content in Android. jar? The answer is no. The reason is that, in order to ensure the stability and backward compatibility of the application development API, Google divides the source files into two categories: public and private, obviously, some private source files may be changed in the future due to poor stability, so these unstable source files will not be put into Android. in jar, the @ hide label is often seen by colleagues who often look at the source code, which is also a private performance;
       The output after Android. Jar compilation is located in./out/target/common/obj/java_libraries/sdk_v $ {version} _ intermediates.
       $ {Version} indicates the SDK version;