these-ammii/thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

add compilation steps
Some checks failed
/ test_checkout (push) Failing after 1s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-07-11 00:35:45 +02:00
parent bf222d5ce5
commit c83a81c35a
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
1 changed files with 31 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

32
2_background/X_android.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX
#import "../lib.typ": todo, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX, XML
== Android <sec:bg-android>
@ -67,6 +67,36 @@ An additionnal file, `resources.arsc`, in a custom binary format, contains a lis
==== Compilation Process
For the developer, the compilation process is handled by Android Studio and is mostly transparent.
Behind the scene, Android Studio rely on Gradle to orchestrate the different compilation steps:
The sources #XML files like `AndroidManifest.xml` and the one in `res/` are compile to binary #AXML by `aapt`, which also generate the ressource table `resources.arsc` and a `R.java` file that define for each ressources variable named after the variable, set to the id of the ressouce.
The `R.java` file allows the developer to refere to ressources with readable names and avoid using the often automatically generated ressources ids, that can change from a version of the application to another.
The source code is then compile.
The most common programming langages used for Android application are Java and Kotlin.
Both are first compiled to java bytecode in `.class` files using the langage compiler.
To allow access to the Android API, the `.class` are linked during the compilation to an `android.jar` file that contains classes with the same signatures as the one in the Android API for the targeted SDK.
The `.class` files are the converted to #DEX files using `d8`.
During those steeps, both the original langage compiler and `d8` can perform optimizations on the classes.
If the application contains native code, the original C or C++ code is compile using tools Android #NDK to target the different architecture target.
`aapt` is then used once again to package all the generated #AXML, #DEX, `.so` files, as well as the other ressources files, assets, `resources.arsc`, and any additionnal files deemed necessary in ZIP file.
`aapt` ensures that the generated ZIP is compatible with the requirement from Android.
For instance, the `resources.arsc` will be mapped directly in memory at runtime, so it must not be compressed inside the ZIP file.
If necessary, the ZIP file is then aligned using `zipalign`.
Again, this is to ensure compatibility with android optimizations: files like `resources.arsc` need to be 4 bits alligned to be mapped in memory.
The last step is to sign the application using the `apksigner` utility.
Since 2021, Google require that new applications in the Google Play app store to be uploaded in a new format called Android App Bundles.
The main difference is that Google will perform the last packaging steps and generate (and sign) the application itself.
This allow Google to generate different applications for different target, and avoid including unnecessary files in the application like native code targetting the wrong architecture.
=== Android Runtime <sec:bg-art>
#todo[NDK / JDK, java runtime, intent]