Introduction

Android est une plateforme pour appareil mobile (tlphone, PDA, netbook, tablettes, etc). Elle est compose d'un systme d'exploitation, de librairies "middleware", et d'un ensemble d'applications : un client mail, un navigateur, un calendrier, etc. Android est bas sur un kernel linux. Les librairies "middleware" qui le compose sont crite en C/C++. Le Framework est quant lui crit en java.

OHA
Android est dvelopp par l'OHA (Open Hanset Alliance), une alliance internationale dentreprises. Cette alliance se compose de compagnie ne faisant pas partie du mme secteur. Ainsi elle se compose :

d'oprateur mobile (Vodafone, Telefonica, Telecom Italia, China Mobile, etc.) de fabricants de tlphone mobiles ( Asus, HTC, LG, Motorola, etc.) de fabricants de semi conducteur ( Intel, Nvidia, ARM, etc.) d'diteurs logiciels ( Ebay, Google, PacketVideo, etc.) de distributeurs (Aplix corporation, Borqs, TAT)

Aujourd'hui il y a 2 milliards de tlvisions dans le monde. 1,5 milliard de personnes ont accs internet. Mais prs de 4 milliards de personnes ont un tlphone portable, ce qui fait que le tlphone portable est le produit connaissant le plus grand succs dans le monde. C'est pour cela que l'OHA s'est lance sur le secteur du mobile. Ils esprent fournir une plateforme mobile innovante et performante fournissant aux utilisateurs une nouvelle exprience d'utilisation de leur mobile.

Historique
En juillet 2005, Google a acquit Android, Inc., une petite startup qui dveloppait des applications pour tlphones mobiles .C'est ce moment l que des rumeurs sur l'entre de Google dans le secteur du mobile ont commenc. Mais personne n'tait sur, dans quels marchs ils allaient se positionner. Aprs ce rachat, Google, une quipe dirige par Andy Rubin, un ancien d'Android Inc, a commenc travailler sur un systme d'exploitation pour appareil mobile bas sur linux. Durant 2 ans, avant que l'OHA soit cre officiellement, un certain nombre de rumeurs ont circul au sujet de Google. Il a t dit que Google dveloppait des applications mobiles de son moteur de recherche, qu'ils dveloppaient un nouveau tlphone mobile, etc. En 2007, le 5 novembre, l'OHA a t officiellement annonce, ainsi que son but. Dvelopper des standards open source pour appareil mobile. premier standard annonc a t Android, une plateforme pour appareils mobiles base sur un kernel linux 2.6. septembre 2008, la premire version stable du SDK est sortie, ce jour la dernire version est la 1.2.

Le

En

Caractristiques : Framework : Framework Java pour le dveloppement d'application pour la plateforme Android Machine virtuelle Dalvik : Machine virtuelle spcialement dveloppe pour Android. Cette machine virtuelle permet d'excuter les applications java dveloppes avec le Framework. Navigateur Web : Navigateur web bas sur le moteur de rendu Webkit. WebKit est une bibliothque logicielle permettant aux dveloppeurs d'intgrer facilement un moteur de rendu de pages Web dans leurs logiciels. Graphique : Librairie graphique 2D, librairie graphique 3D bas sur OpenGL ES 1.0. Acclration matriel possible. qui dfinit une API multiplate-forme pour la conception d'applications gnrant des images 3D drive de la spcification OpenGL, sous une forme adapte aux plateformes mobiles. Stockage : Base de donnes SQL : SQLite est utilis pour le stockage des donnes. Media : Android supporte les formats audio/video/image suivants : MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF Connectivit : gsm, edge, 3G, bluetooth, wifi Support Matriel : Android est capable d'utiliser Camera, GPS, acclromtre. Environnement de dveloppement : Android possde un environnement de dveloppement complet contenant : un

mulateur, un dbuggeur, un analyseur de mmoires et de performances et un plugin eclipse.

Architecture du systme Android 1- Vue gnrale :

Android est bas sur un kernel linux 2.6.xx, au dessus du kernel il y a "le hardware abstraction layer" qui permet de sparer la plateforme logique du matriel. Au dessus de cette couche d'abstraction on retrouve les librairies C/C++ utilises par un certain nombre de composants du systme Android. Au dessus des librairies on retrouve l'Android Runtime, cette couche contient les librairies curs du Framework ainsi que la machine virtuelle excutant les applications. Au dessus la couche "Android Runtime" et des librairies curs on retrouve le Framework permettant au dveloppeur de crer des applications. Enfin au dessus du Framework il y a les applications.

2- Linux Kernel : Android est bas sur un kernel linux 2.6 mais ce n'est pas linux. Il ne possde pas de systme de fentrage natif (X window system), la glibc n'est pas support, Android utilise une libc personnalise appel Bionic libc. Enfin Android utilise un kernel avec diffrents patches pour la gestion de l'alimentation, le partage mmoire, etc. permettant une meilleurs gestion de ces caractristiques pour les appareils mobiles. Android n'est pas linux mais il est bas sur un kernel linux.

Pourquoi sur un kernel linux ?

Le kernel linux a un systme de gestion mmoire et de processus reconnu pour sa stabilit et ses performances. Le model de scurit utilis par linux, bas sur un systme de permission, connu pour tre robuste et performant. Il na pas chang depuis les annes 70 Le kernel linux fournit un systme de driver permettant une abstraction avec le matriel. Il permet galement le partage de librairies entre diffrent processus, le chargement et le dchargement de modules chaud. le kernel linux est entirement open source et il y a une communaut de dveloppeurs qui l'amliorrent et rajoute des drivers.

C'est pour les points cits ci-dessus que l'quipe en charge du noyau a dcid d'utiliser un kernel linux.
Modifications apportes au noyaux Le kernel Android a t patchs avec diffrents patchs :

Alarme
Ce patch fournit un certain nombre de timeurs permettant par exemple de "rveiller l'appareil quand il est en veille"

Ashmem
Android shared memory

Ce patch permet aux applications de partager la mmoire. Cette gestion est faite au niveau kernel du fait que le partage mmoire est trs utilis dans la plateforme Android car la mmoire dans les appareils mobiles est limite par rapport des PC. Le partage mmoire est essentiellement utilis par le Binder (lien).

Binder - Android IPC

La communication interprocessus (IPC) peut entrainer des trous de scurit, c'est pour cela qu'Android son propre IPC, le Binder et que la communication interprocessus n'est pas laiss aux dveloppeurs d'application. De plus, avoir un systme IPC centralis permet une maintenance plus facile et une correction des problmes de scurits gnrales. Dans Android chaque application est lance dans un processus diffrent. Ces diffrents processus ont besoin de communiquer ensemble, de partager des donnes. Cet IPC est possible avec le Binder. Il permet plusieurs processus de partager des donnes, de communiquer entre eux en utilisant le partage mmoire (ashmem driver). Cette technique permet des performances accrue par rapports de la recopie en mmoire des donnes, ou de la srialisation. Les problmes de concurrence, lorsque plusieurs processus essaye d'accder en mme temps une "mme zone mmoire" (au mme objet java) sont grs par le Binder. Tous les appels sont synchroniss entre les processus. Fonctionnement

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/anatomyphysiology-of-an-android) illustrates this:

L'application A rcupre une rfrence vers le Service B l'aide du Context Manager. Le Context Manager peut tre compar un DNS. Il permet de rcuprer l'aide d'un nom, une rfrence 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 pralable les enregistrer dans le Context Manager. Une fois la rfrence vers le service B rcupre, la mthode foo() du service B est appele par l'application A. Le binder intercepte cet appel, et l'aide d'un des threads libres prsent dans sa thread pool (piscine de thread ou rservoir de threads), il va excuter la mthode sur le service B.

Gestion de lalimentation : Problmatique :

Appareils mobiles dpendent de la puissance de la batterie et les batteries ont une capacit limite. Proprits 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 lalimentation plus agressive. o Les Composants font des demandes de rester en veille travers les Wake Locks . o Power Management supporte diffrents types de Wake Locks .

S'il n'ya pas de Wake Locks actifs, le processeur sera dsactive. S'il n'ya pas de Wake Locks partiel, seul lcran et le clavier seront teint.

Android supporte ses propres Power Management (bas sur la Gestion d'alimentation standard de Linux), conu sur le principe que le CPU ne devrait pas consommer de l'nergie si aucune des applications ou services ncessitent une alimentation. Android exige que les applications et les services demandent des ressources CPU avec Wake Locks travers le Android Application Framework et les bibliothques linux natives. S'il n'ya pas de Wake Locks actifs, Android va arrter le CPU. L'image ci-dessous illustre l'architecture Android gestion de l'alimentation.

Types de Wake Locks

Wake Lock
ACQUIRE_CAUSES_WAKEUP

Description
Dhabitude les wake locks ne font pas rveiller le priphrique, ils vont juste l'amener rester eveill une fois que c'est dj fait. Pensez l'app lecteur vido comme un comportement courant. Les notifications qui surgissent et veulent que le dispositif soit veill sont les exceptions; utiliser cette option pour tre comme eux.

FULL_WAKE_LOCK ON_AFTER_RELEASE PARTIAL_WAKE_LOCK

Wake lock qui garantit que l'cran et le clavier sont sur pleine luminosit. Lorsque ce wake lock est libr , rinitialiser le timer de lactivit de l'utilisateur afin que l'cran reste allum pendant un peu plus de temps. Wake lock qui assure que le CPU est en marche. L'cran pourrait ne pas tre en marche.

3- Les Librairies
Au dessus du kernel, il y a les librairies natives. Ces librairies sont crites en C/C++. Elles fournissent les fonctionnalits de bas niveau d'Android.

Bionic Libc Android ne supporte pas la glibc, pour cela on a dvelopp une librairie C (libc) nomm Bionic libc. Elle est optimise pour les appareils mobiles et a t dvelopp spcialement pour Android. La plateforme Android besoin de sa propre libc car il avait besoin d'une libc lgre (la libc sera charg dans chaque processus) et rapide (les appareils mobiles ne disposent de CPU puissant). La Bionic libc a t crit pour supporter les CPU ARM, bien que le support x86 est prsent. Il n'y pas de support pour les autres architecture CPU tel que PowerPC ou MIPS. Nanmoins, pour le march des appareils mobiles, seulement l'architecture ARM est importante.
Les architectures ARM, dveloppes par ARM Ltd, sont des architectures RISC 32 bits. Dots d'une architecture relativement plus simple que d'autres familles de processeurs, et bnficiant d'une faible consommation, les processeurs ARM sont devenus dominants dans le domaine de l'informatique embarque, en particuliers la tlphonie mobile et les tablettes. Ces processeurs sont fabriqus sous licence par un grand nombre de constructeurs.

Cette libc est sous licence BSD, elle reprend une grande partie du code des glibc issue d'OpenBSD, FreeBSD et NetBSD. Caractristiques :

-Elle environ une taille de 200Ko soit la moiti de la glibc -L'implmentation des pthreads (POSIX thread) a t compltement rcrite pour supporter les threads de la machine virtuelle Dalvik. De ce fait la Bionic libc ne supporte les threads POSIX -Les exceptions C++ et les "wide char" ne sont pas supports

-Il n'y a pas de "Standard Template Library" (STI) La Standard Template Library (STL) est une bibliothque C++, normalise par l'ISO (document ISO/CEI 14882) et mise en oeuvre l'aide des templates. Cette bibliothque fournit :

un ensemble de classes conteneurs, telles que les vecteurs (vector), les tableaux associatifs (map), les listes chanes (list), qui peuvent tre utilises pour contenir n'importe quel type de donnes condition qu'il supporte certaines oprations comme la copie et l'assignation. une abstraction des pointeurs : les itrateurs. Ceux-ci fournissent un moyen simple et lgant de parcourir des squences d'objets et permettent la description d'algorithmes indpendamment de toute structure de donnes. des algorithmes gnriques tels que des algorithmes d'insertion/suppression, recherche et tri. une classe string permettant de grer efficacement et de manire sre les chanes de caractres. WebKit : WebKit est une bibliothque logicielle permettant aux dveloppeurs d'intgrer facilement un moteur de rendu de pages Web dans leurs logiciels. Elle est disponible sous licence BSD et GNU LGPL. Originellement rserve au systme d'exploitation Mac OS X ( partir de la version 10.3 Panther), elle a t porte vers Linux et Windows. Ainsi le portage de WebKit pour les environnements GTK+ et Qt se nomment respectivement WebKitGTK+ et QtWebKit. WebKit est un fork du moteur de rendu KHTML du projet KDE utilis notamment dans le navigateur Konqueror. Elle intgre deux sous-bibliothques : WebCoreet JavaScriptCore correspondant respectivement KHTML et KJS. WebKit est moteur de rendu, qui fournit une bibliotheque sur lequel on peut dvelopper un navigateur web. Il a t driv lorigine par Apple du moteur de rendu KHTML pour tre utilis par le navigateur web Safari et maintenant il est dvelopp par KDE project, Apple, Nokia, Google et d'autres. WebKit est compos de deux librairies : WebCore et JavascriptCore qui sont disponible sous licence GPL.
WebKit supporte le CSS, Javascript, AJAX. La version de WebKit prsent dans Android t lgrement modifie pour s'adapter aux appareils mobiles.

Media framework
La librairie Media Framework est base sur OpenCore de PacketVideo. Elle permet le support des standards audio/vido/images.

Android Media Framework est construit au dessus d'un ensemble de bibliothques de mdias, y compris OpenCore, vorbis et SONiVOX. Donc, un des objectifs de Android Media Framework est de fournir une interface cohrente pour tous les services fournis par les bibliothques sous-jacentes et de les rendre transparents pour les utilisateurs. La figure ci-dessous montre les relations de dpendance entre les bibliothques du mdia framework.

Dans cette figure, les composants verts sont les mdiathques, les librairies android interne sont des composants jaunes, les composants gris sont les bibliothques externes, et la classe de couleur bleue clair est le consommateur java du mdia framework. Sauf pour la classe android.media.MediaPlayer, tous les composants sont mis en uvre en C ou C + +. Le noyau du Media Framework est compos de libmedia, libmediaplayerservice et libmedia_jni. libmedia dfinit la hirarchie d'hritage et les interfaces de base. C'est la bibliothque de base. libmedia_jni est lintermdiaire entre l'application Java et la bibliothque native. D'abord, il implmente la spcification JNI (Le JNI (Java Native Interface) est un framework qui permet au code Java s'excutant l'intrieur de la JVM d'appeler et d'tre appel1 par des applications natives (c'est--dire des programmes spcifiques aumatriel et au systme d'exploitation de la plate-forme concerne), ou avec des bibliothques logicielles bases sur d'autres langages (C, C++, assembleur, etc.).) afin qu'il puisse tre utilis par une application Java. Deuximement, il implmente le modle faade pour la commodit de l'appelant.

libmediaplayerservice met en uvre concrtement certains Lecteurs de Medias et les services de mdias qui vont grer les instances de ces lecteurs. Ce qui est intressant noter dans Android, Cest que l'application qui a l'intention dafficher le contenu des mdias et le lecteur qui affiche rellement ce contenu (audio, vido) fonctionnent dans des processus diffrent. La ligne rouge dans le diagramme de squence ci-dessous montre la limite de deux processus.

La figure montre les trois oprations les plus courantes, la cration d'un nouveau Lecteur, mise en DataSource et la Lecture. Le dernier objet MediaPlayerBase est l'interface que lobjet MediaPlayerService::client utilise pour se rfrer l'instance du lecteur concret. Le lecteur

concret peut tre VorbisPlayer, pvPlayer, ou n'importe quel autre Lecteur, en fonction du type du mdia lu. Quand une application cre un objet android.media.MediaPlayer, il utilise en fait un objet Proxy pour manipuler le Lecteur concret rsidant dans le processus MediaServer. Pendant toute la procdure, deux processus communique avec Binder IPC. Ayant des connaissances ci-dessus, il n'est pas difficile de comprendre pourquoi MediaPlayer ne fournit pas une API utiliser comme source de flux de mmoire. Parce que la mmoire manipule par le flux est en l'espace d'adressage de l'application, et ce n'est pas directement accessible par le processus media server. Le schma ci dessous dcrit toutes les fonctionnalits fournit par cette librairie : Mdiathques base sur PacketVideo de OpenCore; les librairies permettant la lecture et lenregistrement audio et vido, ainsi que la gestion des fichiers image, y compris MPEG4, H.264, MP3, AAC, AMR, JPG et PNG. Le schma ci-dessous dcrit tous les lments de larchitecture de ces mdiathques:

SURFACE FLINGER :
Le Surface Flinger permet de construire le rendu graphique, il manipule toutes les surfaces afficher provenant du frame buffer. Il peut combiner de la 2D et de la 3D provenant de diffrentes applications. Les surfaces afficher sont passes par buffers via le Binder.

Le surface flinger utilise un double buffer permettant de basculer d'une surfaces une autre rapidement. Ce double buffer permet galement de ne jamais afficher des surfaces incompltes, car le deuxime buffer n'est affich que lorsque celui est complet. Les deux buffers sont utiliss tour tour. Il peut utiliser OpenGL ES et l'acclration matrielle pour le rendu 2D en utilisant l'API khronos.

Audio Flinger
L'audio flinger gre tous priphriques audio. Il traite les flux audio et les route vers les priphriques de sortie (haut parleur, Bluetooth, casque).

Le Hardware Abstraction Layer

Cette couche se situe entre les librairies et le kernel linux, elle fournit les interfaces que doivent implmenter les drivers kernel. Cette couche spare la plateforme logique des interfaces matrielles. Le but de cette couche est de faciliter le portage des librairies sur diffrents matriels.

Les concepteurs d'Android ont dcid de faire cette couche car :

Les drivers kernel ne possdent pas tous des interfaces standardises. les drivers kernel sont sous licence GPL ce qui exposerait les interfaces propritaires des fabricants. Les fabricants veulent pouvoir garder ces interfaces en "closed source" Android a des besoins spcifiques pour les drivers kernel.

4- Android Runtime

Cette couche se situe au dessus des libraires C/C++, elle se compose du "cur" du Framework et de la machine virtuel dalvik.

Dalvik
La machine virtuelle Dalvik est base sur une architecture de registre l'instar de beaucoup de machine virtuel et de la machine virtuelle Java qui ont une architecture de pile. Utiliser une architecture de pile ou de registre dpends des stratgies de compilation et d'interprtation choisit. Gnralement, les machines bases sur une architecture de pile, doivent utiliser des instructions pour charger les donnes sur la pile et manipuler ces donnes. Ce qui rajoute des instructions dans le code machine, et donc il y a plus de code que pour une machine bas sur une architecture de registre. Cependant, les instructions pour une machine base sur une architecture de registre doivent tre encodes pour les registres sources et destinations, ce qui prend galement de la place dans le code machine rsultant. La diffrence est essentiellement importante suivant l'interprteur de code machine prsent dans la VM. Les applications Java dveloppes pour Android doivent tre compiles au format dalvik excutable (.dex) avec l'outil dx. Cet outil compile les .java en .class et ensuite il convertit ces .class en .dex. Un .dex peut contenir plusieurs classes. Les strings dupliqus et autre constantes utilises dans de multiples classes sont regroups dans un .dex. Le bytecode utilis dans les .dex est le Dalvik bytecode et non le java Bytecode.

Pour comparaison un .dex dcompress est un peu plus petit en taille qu'un .jar compress driv des mmes fichiers .class. Etant optimis pour utiliser une quantit de mmoire minimale, la VM Dalvik a quelques caractristiques spcifiques par rapport aux autres VM:

la VM a t "dgraisse" pour utiliser moins d'espace mmoire pas de compilation la vol (JIT) Elle utilise sont propre bytecode et pas le Java bytecode La table des constantes a t modifi pour n'utiliser que des indexes de 32 bit afin de simplifier l'interprteur.

Core Libraries
Les libraries Core fournissent le langage Java disponible pour les applications. Le langage Java fournit avec Android reprend en grande partie l'API JSE 1.5. Il y a des choses qui ont t mis de cot car cela n'avait pas de sens pour Android ( comme les imprimantes, swing, etc.) et d'autres par ce que des APIs spcifiques sont requises pour Android. Packages JSE 1.5 supports par Android java.io

Packages JSE 1.5 non supports par Android java.applet

java.lang (sauf java.lang.management)

java.awt

support java.math java.net java.nio java.security java.sql java.text java.util javax.crypto javax.net javax.security javax.security.auth.kerberos, javax.security.auth.spi, javax.security.sasl) javax.sound javax.sql (sauf javax.sql.rowset) javax.xml.parsers org.w3c.dom org.xml.sax (sauf and

java.beans java.lang.management java.rmi javax.accessibility javax.activity javax.imageio javax.management javax.naming javax.print javax.rmi javax.security.auth.kerberos javax.security.auth.spi javax.security.sasl javax.swing javax.transaction javax.xml (sauf javax.xml.parsers) org.ietf.* org.omg.* org.w3c.dom.*

Librairies spcifiques ajoutes dans les Core Libraries d'Android :

org.apache.commons.codec org.apache.commons.httpclient org.bluez org.json

Le Framework Application :

Le framework est situ au dessus de l'Android Runtime et des librairies. Il fournit des API permettant aux dveloppeurs de crer des applications riches.

Core Plateform Services

Android introduit la notion de services. Un service est une application qui n'a aucune interaction avec l'utilisateur et qui tourne en arrire plan pendant un temps indfini.

Les services curs de la plateforme (Core Plateform Services) fournissent des services essentiels au fonctionnement de la plateforme :

Activity Manager : gre le cycle de vie des applications et maintient une "pile de navigation" (navigation backstack) permettant d'aller d'une application une autre et de revenir la prcdente quand la dernire application ouverte est ferme. Package Manager : utilis par l'Activity Manager pour charger les informations provenant des fichiers .apk (android packaga file) Window Manager : juste au dessus du Surface Flinger (lien), il gre les fentres des applications : quelle fentre doit tre affiche devant une autre l'cran ? Resouce Manage : Gre tous ce qui n'est pas du code, toutes les ressources --> images, fichier audio, etc. Content Provider : gre le partage de donnes entre applications, comme par exemple la base de donnes de contact, qui peut tre consulte par d'autres applications que l'application Contact. Les Donnes peuvent partager travers une base de donnes (SQLite), des fichiers, le rseau, etc. View System : fournit tous les composants graphiques : listes, grille, textbox, buttons et mme un navigateur web embarqu.

Hardware Services
Les services matriels (Hardware Services) fournissent un accs vers les API matrielles de bas niveau :

Telephony Service : permet d'accder aux interfaces "tlphonique" (gsm, 3G, etc.) Location Service : permet d'accder au GPS. Bluetooth Service : permet d'accder l'interface bluetooth. WiFi Service : permet d'accder l'interface Wifi. USB Service : permet d'accder aux interfaces USB. Sensor Service : permet d'accder aux dtecteurs (dtecteurs de luminosit, etc.)

Le Processus de Dmarrage :
A- Comme tout systme Linux, au dmarrage le bootLoader charge le kernel et lance le processus init. Le pre de tous les processus. B- Ensuite un certain nombre de daemons sont lancs par le processus init :

USB daemon (usbd) Android Debug Bridge (adbd) Debugger Daemon (debuggerd); Il permet de grer les requtes de debug de processus (dump memory, etc.) Radio Interface Layer Daemon (rild)

Par la suite le processus init lance le processus Zygote. Au dmarrage, une instance spciale de la machine virtuelle Java est lanc, appel zygote. Ce processus charge un tas de classes Java de base et effectue leur traitement initial, ce qui rend possible d'viter cette tape pour chaque lancement dapplication. Une fois le travail initial est fait, le processus attend les requtes en coutant sur un socket. Le processus Zygote :

initialise une instance de la Dalvik VM Pr charge les classes de base et coute sur un socket pour crer des Dalvik VM Fork sur demande pour crer des instances de Dalvik VM pour chaque application. fork () cre un nouveau processus en dupliquant le processus appelant. Le nouveau processus, appel l'enfant, est une copie exacte du processus appelant, appel en tant que parent Les VM cres partagent des zones mmoire communes ce qui permet de minimiser la mmoire utilises Chaque VM crer par zygote est un fork d'une VM "mre", ce qui permet d'acclrer le dmarrage d'une application.

Ensuite le processus init lance le processus Runtime qui va lancer son tour le Service Manager ("DNS" fournissant un moyen de communiquer avec un service donn par son nom, responsable de la gestion de l'IPC permettant d'enregistrer et de rcuprer des rfrences vers des services andoid) et enregistre ce Service Manager comme le Context Manager par dfaut. C- Une fois tout cela est fait, le processus Runtime, envoie une requte au processus zygote lui demandant de lancer le System Server. Zygote va forker une nouvelle instance de Dalvik VM pour le processus System Server et dmarrer le service. C'est le premier processus (aprs Zygote) qui execute une instance de Dalvik VM. D- Le System Server va lancer son tour l'Audio Flinger et le surface Flinger qui vont ensuite s'enregistrer au prs du Service Manager. E- Le System Server lance ensuite les services d'Android (gestionnaire de fentres,gestionnaire de tlphonie, Power Manager, gestionnaire de l'activit, etc). Ces services une fois lancs vont s'enregistrer au prs du Service Manager.
Une fois tous les services chargs, le systme est prt. Des applications utilisateur peuvent tre lances.

A ce stade, nous avons les processus suivants en place: 1. Init - le processus d'initialisation d'origine a commenc par le programme d'amorage 2. Dmons - dmarrs par init 3. Runtime - aussi commenc par init 4. Zygote - le zygote original qui va sans cesse faire des forks pour que de nouvelles applications soient lances 5. System Server - le premier processus gr qui contient tous les services et composants de la plateforme de base. Aprs cela, l'cran d'accueil ou l'cran de veille est lanc - essentiellement le gestionnaire d'activit (qui est l'intrieur du systm server) envoie un message Zygote pour lancer l'activit Home, ce qui conduit Zygote faire un fork dans un nouveau processus dune Dalvik VM et de l'activit Home. Maintenant, en fonction de l'action mene par l'utilisateur, l'application approprie serait

lanc avec le fork Zygote chaque fois pour crer une nouvelle instance VM dans un nouveau processus. Ainsi, par exemple, si l'utilisateur lance l'application Contacts, le processus apt serait install:

Chaque nouvelle application reoit un ID utilisateur unique qui est inconnu par l'application, et le systme dfinit les autorisations pour tous les fichiers dans l'application de sorte que seul l'ID utilisateur attribu l'application peut accder ces fichiers. ceci rend le systme scuris puisque cest la seule application a accs des composants dont il a besoin pour faire son travail et rien d'autre. Toute fois, les applications peuvent avoir besoin de communiquer entre eux et avec les services du systme, qui sont tous excuts dans des processus spars. Ceci est accompli grce au Binder IPC

Applications
Une application Android est une collection de composants. Il ya quatre types de composants: Activit: Une activit est un composant d'interface utilisateur correspondant un cran avec lequel un utilisateur interagit de manire faire quelque chose. Service: un service est un composant de l'application sans interface utilisateur utilise pour effectuer de longues oprations en tche de fond. Broadcast Receiver: est un lment qui rpond l'chelle du systme des missions (par exemple pour l'cran teint, batterie faible, etc) Fournisseur de contenu: Un fournisseur de contenu est un lment qui stocke et rcupre les donnes et les rend disponibles toutes les applications. Il existe diffrents types de fournisseurs de contenu: audio, vido, contacts, etc et vous pouvez crer votre propre fournisseur de contenu aussi.

As mentioned earlier, each application runs in its own process. By default, all components used by that app also run in the same process, and on the main thread. However, it is possible to make a component of your app run in a separate process thru the manifest file. Thus, an application in Android may span multiple processes.

Comme mentionn prcdemment, chaque application s'excute dans son propre processus. Par dfaut, tous les composants utiliss par cette application sont galement excuts dans le mme processus, et sur le thread principal. Cependant, il est possible de faire un composant de votre application s'excutant dans un processus spar travers le fichier manifest de lapplication. Ainsi, une application sous Android peut s'tendre sur plusieurs processus.

Dmarrage dune Application

Android suit un modle assez unique en ce qu'il n'ya pas de point d'entre unique pour une application - il n'ya pas de fonction main (). Par contre, un composant dans une application Android peut dmarrer un autre dans une autre application. Cette communication entre les applications qui se passe travers le mcanisme IPC dcrit prcdemment. Ainsi, alors que l'activit est dtenue par une application, il est possible pour une autre application de la lancer (si l'application propritaire le permet). Un exemple est de cliquer sur un lien hypertexte dans une application qui ouvre le navigateur. Ceci s'applique non seulement pour les activits, mais d'autres types de composants aussi. Pour ce faire, il ya deux tapes ncessaires: 1. Dans le cas o l'application n'est pas dj lanc, le systme Android apporterait l'application la vie dans un nouveau processus par un fork du zygote. 2. Le composant dsir l'intrieur de lapplication aurait besoin d'tre activ. Notez que dans le cas o l'application est dj lance, le nouveau composant sera instanci par dfaut dans le mme processus. Comme mentionn plus haut, l'IPC passe travers un objet Context . Alors, quand un composant A l'intrieur d'une application doit activer un autre composant B dans une application diffrente, ou lui donner quelque chose de nouveau faire, il utilise essentiellement l'objet Context pour envoyer un message l'autre composant. Dans le cas d'une activit, de service ou un BroadcastReceiver, cela prend la forme de ce qu'on appelle une intention Intent .

Cest une structure passive de donnes qui dfinit l'opration effectuer pour une activit et un service, et pour un BroadcastReceiver, cest une dfinition de la dclaration en cours de diffusion. Les fournisseurs de contenu ne sont cependant pas activs par Intentions. Au lieu de cela, l'activation se produit sur une demande d'un ContentResolver, qui agit comme un mdiateur entre le composant demandeur et le fournisseur de contenu.

Le Back-Stack
Considrons le scnario suivant: 1. Vous tes sur l'cran d'accueil. Ceci est lactivit 1 2. Vous cliquez sur l'icne de lapplication Mail, qui active lactivit principale dans l'application Mail qui apparait au premier plan. C'est l'activit 2 3. Vous cliquez maintenant sur Composez et qui active l'activit de composition dans l'application Mail. C'est l'activit 3 4. Vous dcidez d'annuler de composer un nouveau message et appuyez sur le bouton de retour. Vous revenez l'activit 2

Voici ce qui arrive dans le fond: Quand une activit dmarre une autre, elle s'arrte et son tat est sauvegard. Alors, quand l'activit 1 commence Activit 2, activit 1 est arrte, son tat sauvegard et ainsi de suite Le systme maintient une pile (appele un Back-Stack) avec la dernire activit sur le dessus et la plus ancienne activit la base. Lorsque l'utilisateur appui sur le bouton retour de lappareil, l'activit 3 est sorti de la pile et l'Activit 2 est dmarr partir de son tat sauvegard

Les Tches
Dans le scnario dcrit ci-dessus, on suppose que lorsque l'utilisateur a t dans lapplication Nouveau Mail (Activit 3), il a dcid d'appeler quelqu'un et a appuy sur le bouton Accueil. Ce ne va pas dpiler le back-stack, mais commencer une nouvelle pile. Pour ce faire, la collection d'activits dans la premire pile a besoin de passer en arrire plan. Ceci est ralis grce la notion de tche Une tche est une unit cohrente d'Activits. Quand une tche passe vers l'arrire-plan, toutes les activits dans cette tche sont arrts, mais le back-stack de la tche demeure intact, de sorte que lorsque l'utilisateur retourne la tche, elle peut reprendre o elle s'tait arrte. Cependant, pour conomiser de la mmoire, le back-stack dune tche de fond n'est pas retenu pour une trs longue priode et si l'utilisateur ne revient pas la tche, le back-stack est effac, lexception de l'activit root.

Cycle de vie dune activit

Le cycle de vie d'une activit est affect par son association avec d'autres activits, sa mission et son back-stack. Il ya trois tats dans lesquels une activit peut exister: Reprise / En execution: L'activit est au premier plan et a le focus utilisateur. Une telle activit n'est jamais tue par le systme. En Pause: L'activit est visible, mais une autre activit est au premier plan et a le focus utilisateur. Cela pourrait arriver si l'autre activit est au sommet, mais elle est translucide, ou parce qu'elle ne couvre pas tout l'cran. Dans l'tat de pause, l'activit est conserve en mmoire, maintient toutes les infos d'tat et reste attach au gestionnaire de fentres. Cependant, il peut tre tu dans des conditions de mmoire extrmement faible. Arrt: l'activit n'est pas visible lutilisateur. Tandis que l'activit est conserve en mmoire, maintient toutes les infos d'tat, il ne reste pas attach au gestionnaire de fentres. L'activit peut tre tue par le systme pour rcuprer de la mmoire si ncessaire.

Enregistrement de ltat de l'activit

Afin de rcuprer de la mmoire notez qu'il est tout fait possible que le systme, peut dtruire une activit, ou mme le processus dans lequel l'activit tait en marche. Toutefois, lorsque l'utilisateur revient l'activit (par le back-stack), on reprend au point o l'utilisateur a quitt. Pour ce faire, une activit doit enregistrer son tat. Cela se passe via la mthode onSaveInstanceState ().

Cycle de vie de processus

Le systme Android peut avoir besoin de tuer un processus, afin de rcuprer de la mmoire. Afin de s'assurer que cela cre un impact minimal sur l'exprience utilisateur, Android range les processus dans un ordre de priorit: Processus de premier plan: Un processus qui est requis pour ce que l'utilisateur est en train de faire. Un tel processus est tu seulement comme un dernier recours Processus visibles: Ce processus n'est pas au premier plan, mais peut affecter ce que l'utilisateur voit sur l'cran. Par exemple, il peut accueillir une activit en pause. Un tel processus n'est pas tu moins que cela est ncessaire pour maintenir tous les processus du premier plan, en execution Procressus Service: Un processus qui excute un service et n'est pas l'un des deux types cidessus. Par exemple, le service peut jouer de la musique ou faire du tlchargement de quelque chose. Le systme peut tenir un tel processus en excution tant qu'il y ait assez de mmoire pour garder les processus de premier plan et visibles en marche. Processus dArrire plan: Un processus qui gre une activit qui n'est pas actuellement visible l'utilisateur (l'activit est arrte). Un tel processus n'a pas d'impact sur l'exprience utilisateur (si le cycle de vie de l'activit est correctement mis en uvre et l'tat d'activit est correctement sauvegard et restaur). Le systme peut tuer un tel processus tout moment. Gnralement, il existe plusieurs processus d'arrire-plan et le systme maintient une liste LRU qui est utilis pour tuer ces processus. Processus vides: un processus vide ne dtient aucun composant actif. La seule raison pour quun tel processus soit maintenu en vie, en premier lieu est pour la mise en cache et l'amlioration du temps de dmarrage. Le systme tue souvent ces processus afin de maintenir l'quilibre entre les caches processus et les caches du noyau sous-jacent.

Bien sr, il peut donc arriver qu'un processus de forte priorit soit dpendant d'un processus de faible priorit. Dans un tel cas, le classement des processus servant augmente au mme niveau que celui du processus dpendant. Une situation o ce classement a un impact direct est la suivante: Votre application doit tlcharger quelque chose de grand qui peut prendre du temps et l'utilisateur est susceptible de se dplacer hors de l'activit de l'application autre chose. Si vous crer un thread pour cette tche et l'utilisateur se dplace, le processus devient un processus de fond. Cependant, si vous crer un service la place, le processus serait un processus de service et sera moins susceptibles d'tre tus

Main / UI Thread
Quand une application est lance et un nouveau processus est cr pour l'accueillir, l'application reoit un seul thread appel thread principal ou le thread d'interface puisque ce thread est responsable du service de l'interface utilisateur. La faon dont cela fonctionne est la plupart du temps la mme chose pour presque n'importe quelle implmentation dinterface utilisateur UI - que ce soit les systmes d'exploitation de bureau ou mobile OS. Fondamentalement, le thread d'interface utilisateur excute une boucle infinie qui vrifie une file d'attente pour voir s'il ya des vnements de l'interface utilisateur en cours. Dans le cas d'Android, ce concept est formalis sous la forme d'un looper. Le looper traite une MessageQueue (file de messages) qui contient les messages tre expdis. La tche relle de la gestion de la file d'attente se fait par un gestionnaire qui est responsable de la manipulation (ajout, suppression, dispatching) des messages dans la file de messages.

Pour le thread principal, un Looper est configur par le systme. Cependant, vous pouvez galement associer un Looper avec votre propre thread. Notez que le Looper peut tre associ avec un seul tread et que l'association ne peut pas tre change. La faon dont Android assure ceci (l'association ne peut pas tre change) est en mettant le looper sur le thread local storage du thread et ne pas exposer un constructeur pour le Looper. Alors bien videmment, on ne doit pas excuter une opration de blocage sur le thread d'interface utilisateur. Si vous le faites, les messages de la file d'attente de cessent de se traiter et votre application ne rpondait plus.

Les Services
Comme mentionn prcdemment, un service est un type de composant qui est utilis pour raliser une opration d'arrire-plan, et ne fournit pas une interface utilisateur. Un composant dune application peut dmarrer un service, et mme si l'utilisateur passe de l'application, le service continue fonctionner. Un cas d'utilisation typiques est de jouer de la musique et tlcharger un fichier. Android assure pour un processus d'excution d'un service quil ne soit pas tu autant que possible (voir cycle de vie du processus ci-dessus). Notez que par dfaut, un service s'excute sur le thread UI principal dans le mme processus. Cela signifie que si on effectue une opration de blocage, votre interface ne rpondait plus, parce que le thread ne serait pas disponible pour excuter l'activit. Pour contourner cela, vous devez lancer un thread de travail l'intrieur du service.