#import "../lib.typ": todo, APK, JAR, AXML, ART, SDK, JNI, NDK == Android Android is the smartphone operating system develloped by Google. It is based on a Long Term Support Linux Kernel, to which patches are added patches develloped by the Android community. On top of the kernel, Android redeveloped many of the usual components used by linux-based operating systems, and added new ones. Those change make Android a verry unique operating system. === Android Applications Application in the Android ecosystem are distributed in the #APK format. #APK files are #JAR files with additionnal features, which are themself ZIP files with additionnal features. A minimal #APK file is a ZIP archive containing a file `AndroidManifest.xml`, the `META-INF/` folder containing the #JAR manifest and signature files, and an #APK Signing Block at the end of the ZIP file. Other files are then added. Dalvik bytecode is stored in the `classes.dex`, `classes2.dex`, `classes3.dex`, ... and native code is stored in `lib//*.so`. The `res/` folder contains the ressources required for the user interface. When ressources are present in `res/`, the file `resources.arsc` is also present at the root of the archive. The `assets/` folder contains the files that are used directly by the code application. Depending on the application and compilation process, any kind of other files and folders can be added to the application. ==== Signature Android applications are cryptographically signed to prove the autorship. Applicatations signed with same key are considered develloped by the same entity. This allow to securelly update applications, and application can declare security permission to restrict access to some feature to only application with the same author. Android has several signature schemes coexisting: - The v1 signature scheme is the #JAR signing scheme, where the signature data is stored in the `META-INF/` folder. - The v2, v3 and v3.1 signature scheme are store in the '#APK Signing Block' of the #APK. The v2 signature scheme was introduce in Android 7.0, and to keep retrocompatibility with older version, the v1 scheme is still used in addition to the #APK Signing Block. The Signing block is an unindexed binary section added to the ZIP file, between the ZIP entries and the Central Directory. The signature was added in an unindexed section of the ZIP to avoid interferring with the v1 signature scheme that sign the files inside the archive, and not the archive itself. - The v4 signature scheme is complementary to the v2/v3 signature scheme. Signature data are stored in an external, `.apk.idsig` file. ==== Android Manifest The Android Manifest is stored in the `AndroidManifest.xml`, encoded in the binary #AXML format. The manifest declare important informations about the application: - generic informations like the application name, id, icon - The Android compatibility of the applications, in the form of 3 values: the Android `min-sdk`, `target-sdk` and `max-sdk`. Those are the minimum, targeted and maximum version of the Android SDK supported by the application - The application componants (Activity, Service, Receiver and Provider) of the application and the classes they are associated to - Intent filters to list the itents that can start or be sent to the application componants - Security permissions required by the application ==== Code An application usually contains at least a `classes.dex` file containing Dalvik bytecode. This is the format executed by the Android #ART. It is common for an application to have more thant one #DEX file, when application need to reference more methods than the format allows in one file. Support for multiple #DEX files was added in the #SDK 21 version of Android, and applications that have multiple #DEX file are sometimes refered to as 'multi-dex'. In addition to #DEX files, and sometimes instead of #DEX files, applications can contain `.so` ELF (Executable and Linkable Format) files in the `lib/` folder. In the Android echosystem, binary code is called native code. Because native code is compile for a specific architecture, `.so` files are present in different versions, stored in different subfolders, depending on the targetted architecture. For example `lib/arm64-v8a/libexample.so` is the version of the `example` library compiled for an ARM 64 architecture. Because smartphones mostly use ARM processors, it is not rare to see applications that only have the ARM version of their native code. ==== Ressources Application user interface require many kind of specific assets, which are stored in `lib/`. Those ressources include bitmap images, text, layout, etc. Data like layout, color or text are stored in binary #AXML. An additionnal file, `resources.arsc`, in a custom binary format, contains a list of the ressources names, ids, and their properties. ==== Compilation Process === Android Runtime #todo[NDK / JDK, java runtime, intent]