compile command

• mmm: Compile the module in the specified directory and do not compile other modules it depends on.
• mma: Compile modules and their dependencies in the current directory.
• mm: Compile modules in the current directory and do not compile dependent modules.
• mmma: Compile all modules under the specified path and include dependencies.

Note that generally when you use mmto compilefor the first time , some file resources may not be found. You can usemmato compile related dependencies first, and then you can directly usethe mmcommand to compile.

Compilation steps

1. Initialization is explained
   here using the Launcher
   module as an example . Execute in the AOSP root directory:

source build/envsetup.sh
lunch 47

2. Enter the Settings directory:

cd  /AOSP/packages/apps/Launcher3

3. mm compiles modules in the current directory and does not compile dependent modules

mm

If the compilation is successful, it will be shown in the figure below.

Compilation result.png

Install

After modifying the relevant code, what should we do if we want to check the effect of the modification? There are two ways:

• After the compilation is completed, you can use the adb install -r apk path to directly install the generated apk file on the device. If it is not an APK, directly push the corresponding file.
• After the compilation is completed, use make snod to regenerate system.img and burn it into the device.

Here, because the Launcher module will generate an APK installation package after compilation, we can install it directly:

1. Enter the APK directory

cd AOSP/out/target/product/sailfish/system/priv-app/Launcher3

2. adb installation

adb install -r Launcher3.apk

System optimization and dex/odex/vdex/oat/art

During the above compilation process, the output files include not only apk, but also odex and vdex files. So what are these files used for? This issue will be discussed next. As we all know, Android creates a virtual machine for each application to run, so that each application runs independently without interfering with each other. If one of them crashes, it will not affect the operation of the application, so we will start with Android virtual machine starts the discussion.

Android virtual machine

The difference between Dalvik and ART

Dalvik:

JIT (Just-in-time) real-time compilation, which translates bytecode into machine code during operation. The target file (dex) being run has nothing to do with the hardware platform, and the App running efficiency is low.

ART:

AOT (Ahead-Of-Time) is pre-compiled and the bytecode is translated into machine code before running. The target file (oat) being run is related to the hardware platform. App runs efficiently, but it takes up space, and the time required for Apk installation increases.

vdex

Android 8.0’s new format package is an executable binary code file directly converted from dex code. After Android 8.0, odex extracts a new executable binary code file generated by some modules from the vdex file. odex is extracted from vdex. Afterwards, the size of vdex is reduced;

1. It will be generated under /system/app/<packagename>/oat/ when booting for the first time.
2. While the system is running, the virtual machine copies it from “/system/app” to “/data/davilk-cache/”
3. odex + vdex = the entire source code of apk (vdex is not a file independent of odex. odex + vdex represents an apk)

odex

Dalvik era: When the APK is running, the classes.dex in the APK will be decompressed and the .odex file will be optimized through dexopt and cached in the /data/dalvick-cache directory to improve subsequent execution efficiency (changed to ART virtual after Android 5.0) phones, but mobile phone manufacturers believe that ART technology is not mature yet, so some still use Dalvik).

ART era: When the APK is installed, the classes.dex in the APK will be decompressed, converted into an .odex file through the dex2oat tool (ELF mode, completely different from that generated by Dalvik), and stored in the oat directory of the directory where the apk is located;

Why is the odex file generated when compiling in the source code environment?

We know that ROM is composed of apk, jar, bin, so, etc., so when is the time for the virtual machine to perform conversion and translation? Obviously, the apk is installed, the jar package is loaded, and the ROM is loaded and installed when the phone is turned on. In view of the above characteristics, the advantages and disadvantages of this are summarized:

advantage:

1. Reduce the startup time after system update. Rom without
   odex will perform the odex operation during the first boot . If this process is placed at the compilation time, the boot time will be reduced.
2. Reduce space waste on the device.
   If the dex in the apk file is not deleted, there will be two dex files for the same application: in the apk and in the data/dalvik-cache directory.
3. Prevent third-party users from decompiling system software (odex files follow changes in the system environment, and will not run if the environment is changed; and the apk file does not contain the dex file and cannot run independently)

shortcoming:

1. Increase compilation time during development
2. You cannot directly perform the install operation of the APK. You need to synchronize both the APK and odex to the device.

The opinion about whether dex exists in the APK is temporarily reserved. The author compiled the Launcher module in Android 9.0 and found that dex exists in the apk.

art

The executable binary code file generated by odex optimization is mainly a record of the addresses related to common functions started by apk, which facilitates addressing; usually the related address records of commonly used jar packages are saved in data/dalvik-cache/

1. When the odex file is running, the virtual machine calculates the function call frequency and modifies the function address;
2. Finally, it is generated by the virtual machine in /data/davilk-cache/;
3. After the art file is generated, the function address under /system/app odex and vdex will be invalid, even if you delete them, the apk will run normally

oat

The ART virtual machine uses oat files. The oat file is an Android private ELF file format. It not only contains the local machine instructions translated from the DEX file, but also contains the original DEX file content. During the APK installation process, an OAT file will be generated through the dex2oat tool. For apk, the oat file is actually the packaging of the odex file, that is, oat=odex. For some jar packages in some frameworks, the corresponding oat suffix file will be generated, such as system@framework@boot-telephony- common.oat

refer to

[1]: https://www.jianshu.com/p/f48eac038384
[2]: http://wuxiaolong.me/2018/07/25/AOSP2/