Télécharger cours système d’exploitation Android, tutoriel document pdf.
Binder – Android IPC
La communication interprocessus (IPC) peut entrainer des trous de sécurité, c’est pour cela qu’Android à son propre IPC, le Binder et que la communication interprocessus n’est pas laissé aux développeurs d’application. De plus, avoir un système IPC centralisé permet une maintenance plus facile et une correction des problèmes de sécurités générales.
Dans Android chaque application est lancée dans un processus différent. Ces différents processus ont besoin de communiquer ensemble, de partager des données. Cet IPC est possible avec le Binder.
Il permet à plusieurs processus de partager des données, de communiquer entre eux en utilisant le partage mémoire (ashmem driver). Cette technique permet des performances accrue par rapports à de la recopie en mémoire des données, ou de la sérialisation.
Les problèmes de concurrence, lorsque plusieurs processus essaye d’accéder en même temps à une « même zone mémoire » (au même objet java) sont gérés par le Binder. Tous les appels sont synchronisés entre les processus.
IPC
With its emphasis on isolating apps and services in process boundaries, it is clear that Android requries a lightweight IPC. The IPC mechanism in Android is called Binder and is based on shared memory. Recall that when a process starts it registers itself with the Service Manager.
This happens behind the scenes, and on registeration, each process gets what is called a Context object – a reference to the Service manager. Now lets say app A needs to communicate with service B, and the two are running in two separate processes. To do this, app A asks the Context for the Service B by passing the well known name of the service. The Context returns a reference to the service to A, on which A can call a method – say foo. This method call is intercepted by the Binder driver. The driver marshals the object and passes a reference of it to the receiver – B. Note that this is passing by reference, not passing by value, in which the object is serialized. On the side of the service B, the Binder maintains a thread-pool (transparent to the service). One of the threads in this pool receives the incoming call, locates the actual object in the service B and make the call. The return value is then similarly passed back to the caller. The following diagram (fromhttp://sites.google.com/site/io/anatomy–physiology-of-an-android) illustrates this:
L’application A récupère une référence vers le Service B à l’aide du Context Manager. Le Context Manager peut être comparé à un DNS. Il permet de récupérer à l’aide d’un nom, une référence vers un objet java.
Pour ceux qui connaissent RMI (Remote Method Invocation), c’est le registry. Si on veut partager des objets, il faut au préalable les enregistrer dans le Context Manager.
Une fois la référence vers le service B récupérée, la méthode foo() du service B est appelée par l’application A. Le binder intercepte cet appel, et à l’aide d’un des threads libres présent dans sa thread pool (piscine de thread ou réservoir de threads), il va exécuter la méthode sur le service B.
Gestion de l’alimentation :
– Problématique :
Appareils mobiles dépendent de la puissance de la batterie et les batteries ont une capacité limitée.
– Propriétés de Gestion de l’alimentation
o Power Management est construit au-dessus de la Gestion de l’alimentation standard de Linux.
o Power Management supporte une politique de gestion de l’alimentation plus agressive.
o Les Composants font des demandes de rester en veille à travers les «Wake Locks ».
o Power Management supporte différents types de «Wake Locks ».
– S’il n’ya pas de «Wake Locks » actifs, le processeur sera désactivée.
– S’il n’ya pas de «Wake Locks» partiel, seul l’écran et le clavier seront éteint.
Android supporte ses propres Power Management (basé sur la Gestion d’alimentation standard de Linux), conçu sur le principe que le CPU ne devrait pas consommer de l’énergie si aucune des applications ou services nécessitent une alimentation.
Android exige que les applications et les services demandent des ressources CPU avec «Wake Locks » à travers le « Android Application Framework » et les bibliothèques linux natives.
S’il n’ya pas de «Wake Locks » actifs, Android va arrêter le CPU.
L’image ci-dessous illustre l’architecture Android gestion de l’alimentation..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Système d’exploitation Android (1,62 MO) (Cours PDF)
