wip
All checks were successful
/ test_checkout (push) Successful in 1m53s

This commit is contained in:
Jean-Marie Mineau 2025-09-30 20:50:14 +02:00
parent 072c4f48c4
commit 346151125e
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
6 changed files with 21 additions and 16 deletions

View file

@ -24,7 +24,7 @@ Depending on the application and compilation process, any kind of other files an
#paragraph[*Signature*][
Android applications are cryptographically signed to prove the authorship.
Applications signed with the same key are considered developed by the same entity.
This allows updating the applications securely, and applications can declare security permissions to restrict access to some feature to only applications with the same author.
This allows updating the applications securely, and applications can declare security permissions to restrict access to some features to only applications 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.
@ -69,7 +69,7 @@ An additional file, `resources.arsc`, in a custom binary format, contains a list
#paragraph[*Compilation Process*][
For the developer, the compilation process is handled by Android Studio and is mostly transparent.
Behind the scenes, Android Studio rely on Gradle to orchestrate the different compilation steps:
Behind the scenes, Android Studio relies on Gradle to orchestrate the different compilation steps:
The sources #XML files like `AndroidManifest.xml` and the one in `res/` are compiled to binary #AXML by `aapt`, which also generates the resource table `resources.arsc` and a `R.java` file that defines for each resource variables named after the resource, set to the ID of the resource.
The `R.java` file allows the developer to refer to resources with readable names and avoid using the often automatically generated resource IDs, which can change from one version of the application to another.
@ -136,7 +136,7 @@ This component can then respond with another intent.
Applications must declare intent filters to indicate which intent can be sent to the application, and which classes receive the intents.
Intents are central to Android applications and are not just used to access Android capabilities.
For instance, activities and services are started by receiving intents, and it is not uncommon for an application to self-send intents to switch between activities.
Intent can also be sent directly from Android to the application: when a user starts an application by tapping the app icon, Android will send an intent to the class of the application that defined the intent filter for the `android.intent.action.MAIN` intent.
Intents can also be sent directly from Android to the application: when a user starts an application by tapping the app icon, 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 intents do not need to explicitly name the targeted application and class: intents can be implicit and request an action without knowing the exact application that will perform it.
An example of this behaviour is when an application wants 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.
]