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

typo ch 4
All checks were successful
/ test_checkout (push) Successful in 48s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-12-21 14:21:12 +01:00
parent 3b5df50248
commit ca4e7703e1
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
6 changed files with 2781 additions and 623 deletions
Download patch file Download diff file Expand all files Collapse all files

2
4_class_loader/2_classloading.typ
View file

@ -207,7 +207,7 @@ With the increasing complexity of Android applications, the need arose to load m
To solve this problem, Android started storing classes in multiple files named `classesX.dex` as illustrated by the @lst:cl-dexname that generates the filenames read by class loaders.
Android starts loading the file `GetMultiDexClassesDexName(0)` (`classes.dex`), then `GetMultiDexClassesDexName(1)` (`classes2.dex`), and continues until finding a value `n` for which `GetMultiDexClassesDexName(n)` does not exist.
Even if Android emits a warning message when it finds more than 100 #dexfiles, it will still load any number of #dexfiles that way.
This change had the unintended consequence of permitting two classes with the same name but different implementations to be stored in the same `.apk` file using two #dexfiles (#eg the class `Foo` can be defined both in `classes.dex` and `classes2.dex`).
This change has the unintended consequence of permitting two classes with the same name but different implementations to be stored in the same `.apk` file using two #dexfiles (#eg the class `Foo` can be defined both in `classes.dex` and `classes2.dex`).
Android explicitly performs checks that prevent several classes from using the same name inside a #dexfile.
However, this check does not apply to multiple #dexfiles in the same `.apk` file, and a `.dex` can contain a class with a name already used by another class in another #dexfile of the application.