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

bg android runtime

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-07-11 19:04:50 +02:00
parent c83a81c35a
commit 9e074cf483
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
1 changed files with 43 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

46
2_background/X_android.typ
View file

@ -95,8 +95,48 @@ Since 2021, Google require that new applications in the Google Play app store to
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>
#todo[NDK / JDK, java runtime, intent]
Android runtime environement has many specificities that sets it appart from other platforms.
An heavy heavy empasis is put on isolating the applications from one another as well from the systems critical capabilities.
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
#todo[Subsection name?]
Android application expose their componants to the Android Runtime (#ART) via classes inheriting specific classes from the Android SDK.
They are four type of application commponents, that serves as entry points for application.
Each has a class associated to it, and serves a different role.
/ Activities: An activity represent a single screen with a user interface. This is the componant 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. They allow to application responce to event event when not started.
/ Content providers: A content provider is a componant that manage data accessible by other app through the content provider.
Componant must be listed in the `AndroidManifest.xml` of the application so that the system nows of them.
In the course of a componant live cicle, the system will call specifics methods defined by the classes associated to each componant type.
Those methods are to be overrident by the classes defined in the application if they are specific action to be perfomed.
For instance, an activitymight compute some values in `onCreate()`, called when the activity is created, save the value of those variable to the file system in `onStop()`, called when the acitivity stop being visible to the user, and recover the saved values in `onRestart()`, called when the user navigate back to the activity.
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 send an itent (see @sec:bg-sandbox), the intent sent in responce is transmitted to back to the application by calling another method.
==== Application Isolation and Interprocess Communication <sec:bg-sandbox>
On Android, each application has its own storage folders and the application process are isolated from other applications and 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.
In addition, most feature of the Android system can only be accessed through Binder, Android main interprocess communication channel.
Binder is a componant of tha Android framework, external to the application, that all applications can communicate with.
Applicatians can send messages to Binder, called *intent*, that will check if the application is allowed to send it then foward it to the appropriate componant that can then responce with another intent.
Applications can also receive intent must declare intent filters to indicate which intent can be send to the application, and which classes receive the intents.
Intent are central to Android applications and are not used just to access Android capabilities.
For instance, the activities and services are started by receiving intent, and it is not uncommon for application to send intents to itself to switch activities.
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 behavior is when an application whant open a file: an `android.intent.action.VIEW` intent is sent with the file location, and Binder will find an application capable of viewing the file.