keep refactoring

2_background/2_1_android.typ

@@ -1,4 +1,5 @@
-#import "../lib.typ": todo, num, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX, XML, API, ZIP, jfl-note
+#import "../lib.typ": eg, num, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX, XML, API, ZIP, paragraph
+#import "../lib.typ": todo, jfl-note
 
 === Android <sec:bg-android>
 
@@ -7,7 +8,7 @@ It is based on a Long Term Support Linux Kernel, to which are added patches deve
 On top of the kernel, Android redeveloped many of the usual components used by linux-based operating systems, like the init system or the standart C library, and added new ones, like the #ART that execute the applications.
 Those change make Android a verry unique operating system.
 
-==== Android Applications <sec:bg-android>
+==== Android Applications <sec:bg-android-apk>
 
 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.
@@ -20,8 +21,7 @@ When ressources are present in `res/`, the file `resources.arsc` is also present
 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
-
+#paragraph[*Signature*][
 Android applications are cryptographically signed to prove the autorship.
 Applicatations signed with the same key are considered developed by the same entity.
 This allow to securely update applications, and applications can declare security permission to restrict access to some feature to only application with the same author.
@@ -34,9 +34,9 @@ Android has several signature schemes coexisting:
   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
-
+#paragraph[*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.
@@ -44,9 +44,9 @@ The manifest declare important informations about the application:
 - The application componants (Activity, Service, Receiver and Provider) of the application and their associated classes.
 - Intent filters to list the intents that can start or be sent to the application componants.
 - Security permissions required by the application.
+]
 
-===== Code <sec:bg-android-code-format>
-
+#paragraph[*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
@@ -58,16 +58,16 @@ In the Android ecosystem, binary code is called native code.
 Because native code is compiled 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
-
+#paragraph[*Ressources*][
 Developing graphical interfaces for applications 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
-
+#paragraph[*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:
 
@@ -95,6 +95,7 @@ The last step is to sign the application using the `apksigner` utility.
 Since 2021, Google requires 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>
 
@@ -103,15 +104,14 @@ An heavy emphasis is put on isolating the applications from one another as well
 The code execution itself can be confusing at first.
 Instead of the usual linear model with a single entry point, applications have many entrypoints that are called by the Android framework in accordance to external events.
 
-===== Application Architecture
-
+#paragraph[*Application Architecture*][
 Android application expose their componants to the Android Runtime (#ART) via classes inheriting specific classes from the Android #SDK.
 Four classes represent application components that can be used as entry points:
 
-/ Activities: An activity represent a single screen with a user interface. This is the component used to interact with a user.
-/ Services: A service serves as en entrypoint to run the application in the background.
-/ Broadcast receivers: A broadcast receiver is an entry point used when a matching event is broadcasted by the system. 
-/ Content providers: A content provider is a component that manage data accessible by other app through the content provider.
+- _Activities_: An activity represent a single screen with a user interface. This is the component used to interact with a user.
+- _Services_: A service serves as en entrypoint to run the application in the background.
+- _Broadcast receivers_: A broadcast receiver is an entry point used when a matching event is broadcasted by the system. 
+- _Content providers_: A content provider is a component that manage data accessible by other app through the content provider.
 
 Components must be listed in the `AndroidManifest.xml` of the application so that the system knows of them.
 In the live cicle of a component, the system will call specific methods defined by the classes associated to each componant type.
@@ -120,10 +120,10 @@ For instance, an activity might compute some values in `onCreate()`, called when
 
 In addition to the componants declared in the manifest that act as entry points, the Android #API heavily relies on callbacks.
 The most obvious cases are for the user interface, for example a button will call a callback method defined by the application when clicked.
-Other part of the #API also rely on non-linear execution, for example when an application sends an intent (see @sec:bg-sandbox), the intent sent in responce is transmitted back to the application by calling another method.
-
-===== Application Isolation and Interprocess Communication <sec:bg-sandbox>
+Other part of the #API also rely on non-linear execution, for example when an application sends an intent (see next paragraph), the intent sent in responce is transmitted back to the application by calling another method.
+]
 
+#paragraph[*Application Isolation and Interprocess Communication*][
 On Android, each application has its own storage folders and the application processes are isolated from each other and from the hardware interfaces.
 This sandboxing is done using Linux security features like group and user permissions, SELinux, and seccomp.
 The sandboxing is adjusted according to the permissions requested in the `AndroidManifest.xml` file of the applications.
@@ -139,9 +139,9 @@ For instance, the activities and services are started by receiving and intent, a
 Intent can also be sent directly from Android to the application: when a user starts an application by tapping the app icons, Android will send an intent to the class of the application that defined the intent filter for the `android.intent.action.MAIN` intent.
 One interesting feature of the Binder is that intent do not need to explicitly name the targetted application and class: intent can be implicit and request an action without knowing the exact application that will performed it.
 An example of this behaviour is when an application want to open a file: an `android.intent.action.VIEW` intent is sent with the file location and type, and Binder will find and start an application capable of viewing this file.
+]
 
-===== Platform Classes <sec:bg-platform>
-
+#paragraph[*Platform Classes*][
 In addition to the classes they include, Android applications have access to classes provided by Android, stored on the phone.
 Those classes are called _platform classes_.
 They are devided between #SDK classes, and hidden #API.
@@ -152,9 +152,9 @@ The list of #SDK classes is available at compile time in the form of a `android.
 
 On the opposite, hidden #API are undocumented methods used internally by the #ART.
 Still, they are loaded by the application and can be used by it.
+]
 
-===== Class Loading and Reflection
-
+#paragraph[*Class Loading and Reflection*][
 Class loading is the mechanism used by Android to find and select the classes implementation when encontering a reference to a class.
 Android developers mainly use it to load bytecode dynamically from a source other than the application itself (#eg a file downloaded at runtime), using `ClassLoader` objects.
 `Class` objects are the retrieved from those class loaders using their name in the form of strings to identify them.
@@ -163,7 +163,7 @@ The process of manipulating `Class` and `Methods` object instead of using byteco
 Reflection is not limited to bytecode that has been dynamically loaded: it can be used for any class or method available to the application.
 
 Because the `ClassLoader` object are only used when loading bytecode dynamically or when using reflection, it is often forgotten that the #ART uses class loaders constantly behind the scene, allowing classes from the application and platform classes to cohabit seamlessly.
-
+]
 
 #v(2em)