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

I declare this manuscript finished
All checks were successful
/ test_checkout (push) Successful in 1m48s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-10-07 17:16:32 +02:00
parent 9f39ded209
commit 5c3a6955bd
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
14 changed files with 162 additions and 131 deletions
Download patch file Download diff file Expand all files Collapse all files

18
4_class_loader/2_classloading.typ
View file

@ -73,6 +73,15 @@ This behaviour implements a priority and avoids redefining by error a core class
This behaviour is useful for overriding specific classes of a class loader while keeping the other classes.
A normal class loader would prioritise the classes of its delegate over its own.
At runtime, Android instantiates for each application three instances of class loaders described previously: `bootClassLoader`, the unique instance of `BootClassLoader`, and two instances of `PathClassLoader`: `systemClassLoader` and `appClassLoader`.
`bootClassLoader` is responsible for loading Android *#platc*.
It is the direct delegate of the two other class loaders instantiated by Android.
`appClassLoader` points to the application `.apk` file, and is used to load the classes inside the application
`systemClassLoader` is a `PathClassLoader` pointing to `'.'`, the working directory of the application, which is `'/'` by default.
The documentation of `ClassLoader.getSystemClassLoader` reports that this class loader is the default context class loader for the main application thread.
In reality, the #platc are loaded by `bootClassLoader` and the classes from the application are loaded from `appClassLoader`.
`systemClassLoader` is never used in production according to our careful reading of the #AOSP sources.
#figure(
```python
def get_mutli_dex_classses_dex_name(index: int):
@ -98,15 +107,6 @@ A normal class loader would prioritise the classes of its delegate over its own.
caption: [Default Class Loading Algorithm for Android Applications],
) <lst:cl-loading-alg>
At runtime, Android instantiates for each application three instances of class loaders described previously: `bootClassLoader`, the unique instance of `BootClassLoader`, and two instances of `PathClassLoader`: `systemClassLoader` and `appClassLoader`.
`bootClassLoader` is responsible for loading Android *#platc*.
It is the direct delegate of the two other class loaders instantiated by Android.
`appClassLoader` points to the application `.apk` file, and is used to load the classes inside the application
`systemClassLoader` is a `PathClassLoader` pointing to `'.'`, the working directory of the application, which is `'/'` by default.
The documentation of `ClassLoader.getSystemClassLoader` reports that this class loader is the default context class loader for the main application thread.
In reality, the #platc are loaded by `bootClassLoader` and the classes from the application are loaded from `appClassLoader`.
`systemClassLoader` is never used in production according to our careful reading of the #AOSP sources.
In addition to the class loaders instantiated by ART when starting an application, the developer of an application can use class loaders explicitly by calling ones from the #Asdk, or by recoding custom class loaders that inherit from the `ClassLoader` class.
At this point, accurately modelling the complete class loading algorithm becomes impossible: the developer can program any algorithm of their choice.
For this reason, this case is excluded from this chapter, and we focus on the default behaviour where the context class loader is the one pointing to the `.apk` file and where its delegate is `BootClassLoader`.