A complete Android project may contain multiple modules, and at a macro level the contents of each module can be divided into two parts: Resources resource files, Java or Kotlin source code. Therefore, the compilation and packaging process of the whole project is also aimed at these two parts.

Compilation phase

Resources Resource file

Resource files include various XML files, animations, drawable images, audio and video files in the RES directory of your project. The AAPT tool is responsible for compiling these resource files in the project. All resource files are compiled and processed, and XML files (except drawable images) are compiled into binary files, so you cannot open XML files directly after decompressing APK. However, resources in assets and raw directories are not compiled and are packaged into apK compressed packages intact.

The result of compiling the resource file consists of two parts: the resources.arsc file and an R.java. The former holds a resource index table, while the latter defines the resource ID constants. The combination of the two will find the corresponding resource reference in the code.

The source code section

The source code in the project is first compiled by javac into.class bytecode files, which are then optimized into.dex files by the dx tool along with.class files in the dependent tripartite libraries. If there is subcontracting, multiple.dex files may also be generated.

In fact, the source code files also include.java files generated after the AIDL interface files are compiled. If an Android project contains.aidl interface files, these.aidl files will be compiled into.java files.

Packaging phase

Finally, use the tool APK Builder to package the compiled resource and.dex files into APK, as well as some other resources. Examples include the Androidmanifest.xml manifest file and the dynamic library.so file used in the tripartite library.

Once apK is created, it cannot be used directly. You need to use the tool Jarsigner to sign it, because the Android system does not install programs that are not signed. After the signature, the META_INF folder is generated, which holds the files related to the signature.

  • Cert. SF: Generates the key relative to each file
  • Manifest. MF: indicates the digital signature information
  • Xxx.sf: This is the signature file for the JAR file
  • Xxx. DSA: the signature and public key of the output file.
  • The PMS checks the validity of the signing certificate in the APK during installation, which is described later.

Generally speaking, the apK should be installed and used normally after signing, but the actual packaging process will be an additional APK optimization operation. Uncompressed resources (images, videos, etc.) in APK are aligned with 4-byte boundaries using zipalign. This idea is very similar to the alignment space in the memory layout of Java objects, primarily to speed up access to resources. If the starting position of each resource is 4n bytes after the previous resource, then the next resource is not traversed, but directly jumped to the 4N byte to determine whether it is a new resource.

At this point a complete APK installation package has been created.