Probatoire

CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS
CENTRE REGIONAL ASSOCIÉ DE PICARDIE
ENG111 : INFORMATION ET COMMUNICATION POUR L'INGENIEUR
présenté par
Pierre-Yves Aillet
Mobilité : plate-forme de développement

Google/Android
Soutenu le 8 Juin 2009
JURY
Président : M. Bernard LEMAIRE
Membres: M. David DURAND (Professeur principal)
M. Claude PÉGARD
M. Christophe LOGÉ
Mobilité: plate-forme de développement Google/Android
Sommaire
Introduction..........................................................................................................................................3
Autour d'Android..................................................................................................................................4
Les autres plates-formes mobiles.................................................................................................................4
Fonctionnalités minimales.........................................................................................................................................6
Accessibles aux développeurs...................................................................................................................................6
Les outils communautaires de Google au service d'Android.......................................................................7
Google IO..................................................................................................................................................................7
Android Developer Challenge...................................................................................................................................7
Google code...............................................................................................................................................................8
Les outils de développement........................................................................................................................9
Le kit de développement...........................................................................................................................................9
Présentations des outils.............................................................................................................................................9
Android Developer Toolkit......................................................................................................................................10
Développement d'applications pour Android.....................................................................................11
Structure d'une application.........................................................................................................................11
Fichier apk...............................................................................................................................................................11
Composant principaux.............................................................................................................................................12
Le fichier AndroidManifest.xml..............................................................................................................................12
Présentation de l'API.................................................................................................................................16
Activités et services.................................................................................................................................................16
Interfaces utilisateur................................................................................................................................................18
Ressources...............................................................................................................................................................20
Intentions et récepteurs............................................................................................................................................21
Fournisseurs de contenu..........................................................................................................................................23
Communication.........................................................................................................................................24
Android Interface Definition Language..................................................................................................................24
Services web REST et représentation des données.................................................................................................25
Applications distribuées..........................................................................................................................................26
Architecture interne d'Android...........................................................................................................27
Vue d'ensemble du système.......................................................................................................................27
Les optimisations de Dalvik......................................................................................................................29
Format DEX............................................................................................................................................................29
Zygote et le Copy-on-Write.....................................................................................................................................30
Perspectives........................................................................................................................................31
Glossaire.............................................................................................................................................32
Conservatoire National des Arts et Métiers - Amiens 2 Session 2008/2009

Mobilité: plate-forme de développement Google/Android Introduction
Introduction
L'entreprise Google est aujourd'hui omniprésente, et ce grâce aux nombreux services qu'elle
propose gratuitement sur Internet. Que l'on souhaite rechercher la moindre information, trouver un
itinéraire, échanger des messages, des documents, partager un agenda, améliorer le référencement
de son site ou encore y incorporer de la publicité, il existe un service Google qui répond à ce besoin.
La domination de la firme de Mountain-View sur le Web ne fait aucun doute, mais ce n'est pas pour
autant qu'elle ne cherche pas à se développer sur d'autres secteurs.
S'il est un marché qui se développe encore plus rapidement que celui d'Internet, c'est celui des
utilisateurs de téléphones mobiles. Avec le développement des réseaux mobiles haut-débit (de type
3G notamment), de plus en plus d'usagers se tournent vers des terminaux mobiles dits
« intelligents » (Smartphones) offrant un accès supplémentaire à des services autres que la
téléphonie.
Jusqu'alors Google était relativement peu présent dans ce domaine, ne proposant que
ponctuellement des applications facilitant l'accès à ses services (GoogleMaps, Gmail, …).
En Août 2005 pourtant, la firme achète une start-up nommée Android officiant dans le domaine de
la téléphonie mobile. En Novembre 2007, Google annonce conjointement avec T-Mobile, HTC, etc,
la création de l'Open Handset Alliance [OHA 2008], cette fondation est créée pour encadrer le
développement de la plateforme Android dont le code est ouvert en Octobre 2008. En Septembre de
la même année Google annonce le premier terminal fonctionnant sous Android, le G1 du
constructeur HTC. Actuellement en France, il n'existe que deux terminaux Android, tous deux de
marque HTC. Cependant, au moins une demi-douzaine d'autres mobiles sont en projets chez
différents constructeurs (Samsung, LG, Motorola, ...).
Afin de bien comprendre les enjeux d'un système destiné aux terminaux mobiles, nous
commenceront par étudier les solutions proposées par les concurrents, et les avantages dont dispose
Google pour s'attaquer à ce marché. Nous nous intéresseront ensuite au développement
d'applications pour la plate-forme Android, en étudiant la structure d'une application, l'API de la
plate-forme et les outils favorisant les communications entre applications. Enfin, nous étudieront le
fonctionnement interne de la plate-forme et les solutions originales proposées par Android aux
problèmatiques de ressources limitées en environnement embarqué.

Mobilité: plate-forme de développement Google/Android Autour d'Android
Autour d'Android
Les autres plates-formes mobiles
Android est loin d'être la première plate-forme de développement apparue dans le monde des
terminaux mobiles. Microsoft ou Palm en proposaient déjà, d 'abord pour les PDA, puis pour les
téléphones mobiles dits « intelligents » (Smartphones) à partir de 2002. Autre acteur important de
ce marché, Apple qui, le 29 Juin 2007, commercialise son iPhone et révolutionne le monde des
mobiles. Ce nouveau terminal, doté d'un écran tactile multi-point et d'accéléromètres, propose une
interface innovante qui se veut intuitive et intégrée à l'environnement Apple. Ainsi, un utilisateur
disposant d'un iPhone et d'un compte MobileMe doit pouvoir synchroniser son carnet d'adresse ou
son agenda entre son ordinateur et son terminal mobile, mais également consulter ses données
depuis n'importe quel ordinateur connecté à Internet. La géolocalisation, autre innovation née de la
convergence entre les terminaux mobiles disposant d'un accès aux réseaux sans- fil haut-débit et les
équipement GPS portables, est également utilisée pour la promotion de l'iPhone. Elle permet à un
utilisateur de connaitre son emplacement et d'obtenir rapidement des informations sur son
environnement immédiat par l'intermédiaire de services complexes hébergés en ligne.
Le terme Cloud-computing est employé pour désigner l'ensemble de ces services nécessitant une
puissance de calcul, une quantité de données importante et accessibles à travers le réseau Internet.
L'emploi du mot nuage vient du fait que sur la plupart des schémas d'architecture réseau on utilise
un nuage pour représenter le réseau Internet.
C'est précisément l'accès à ce type de services depuis les terminaux mobiles que Microsoft, Palm ou
Google ont voulu développer pour concurrencer Apple.
En s'appuyant sur son ensemble de service regroupés sous l'appellation « Live », Microsoft possède
déjà son « nuage ». Comme expliqué précédemment c'est également le cas de Google, qui possède
un nombre considérable de services accessibles en ligne, qui sont pour beaucoup les plus évolués
dans leur domaine. Pour appuyer cette affirmation, on peut citer l'application de cartographie en
ligne de Google (Google Maps), qui intègre une vue immersive en trois dimensions de nombreuses
villes dans le monde (Google Street View).

Nom Firme Sortie Terminaux GPS WiFi / Tactile / Connectivité
Bluetooth Accéléromètres au « nuage »
1
Android Google Septembre 2008 2 Oui Oui / Oui / Google Maps, Talk, ...
Open Handset Alliance Oui Oui
2
WindowsMobile Microsoft Octobre 2001 40+ Oui Oui / Oui / Services Live,
(Pocket PC 2002) Oui Oui3 My Phone
4
Palm/Pre Palm Prévu pour le 1er 0 Oui Oui / Oui / Synergy
semestre 2009 Oui Oui
5
iPhone Apple Juin 2007 2 Oui Oui / Oui / MobileMe
Oui Oui
Tab 1: Comparatif des plates-formes mobiles et terminaux orientés connectivité
1 Intégration d'une boussole/compas utilisable dans l'application Google Streetview par exemple
2 Selon les terminaux
3 Selon les terminaux
4 Un terminal prévu
5 Un troisième terminal est en préparation
Fonctionnalités minimales
À travers le comparatif précédent nous pouvons constater que les mobiles sur lesquels fonctionnent
ces plates-formes ont un certain nombre de point commun, dont l'accès au réseau haut-débit sans-
fil, le GPS et un écran tactile, voire pour certains, un clavier complet. C'est la configuration
minimale requise pour profiter des services et des applications. C'est également pour cette raison
que les opérateurs proposent ces mobiles accompagnés de forfaits ou d'options permettant l'accès
illimité au réseau.
Accessibles aux développeurs

Les capacités de la plate-forme et des terminaux sont loin d'être les seuls facteurs de succès de ces
produits. Il est indispensable de proposer des logiciels tirant partie de ces capacités et offrant de
nouvelles possibilités aux utilisateurs. Une des solutions retenues pour enrichir l'offre logicielle
consiste à attirer des développeurs qui proposeront des produits adaptés à ces terminaux et
contribueront à l'innovation.
Ainsi, il y a bien longtemps que Microsoft propose son kit de développement (SDK) pour Windows
Mobile. Cet ensemble d'outils s'intègre à l'environnement intégré de développement (IDE)
commercial Visual Studio, proposé par Microsoft, et comprend de la documentation, des exemples
de code, des émulateurs, des outils de compilation et de création de paquets.
Palm et Apple proposent également le même genre de kits intégrés à différents IDE. Une des
particularités de Palm est de proposer également son propre kit de développement pour Windows
Mobile.
Pour chacune des plates-formes, les développeurs ont également accès à des outils communautaires
(forums, blogs, mailing-list...) leur permettant d'échanger leurs expériences et de trouver de l'aide
auprès d'autres développeurs.
Une autre innovation venue d'Apple est le concept de « magasin d'application », qui se nomme
l'Apple Store dans leur cas. Celui-ci permet aux utilisateurs d'iPhone d'accéder à un catalogue
centralisé d'applications gratuites ou commerciales. Ce concept permet également aux développeurs
de toucher un public plus large qu'en utilisant uniquement d'autres canaux de diffusion que les
utilisateurs finaux ne connaissent pas forcément.
L'AppleStore a rencontré un tel succès qu'il est aujourd'hui repris par Microsoft qui a créé Windows
Marketplace, et que Sun envisage de développer un système similaire pour l'ensemble des
applications Java.

Les outils communautaires de Google au service d'Android
La plate-forme Android de Google est arrivée tardivement sur le marché. Les autres acteurs et leurs
solutions avaient déjà eu le temps de s'implanter et d'occuper une large part du marché. Malgré ce
désavantage, la firme de Mountain-View dispose de ressources lui conférant un énorme avantage
concernant la diffusion de ses produits et la création de communautés.
En effet, ils ont pu créer un blog dédié à leur plate-forme sur blogspot, héberger leurs mailing-list
sur googlegroups et intégrer le projet Android à leur forge logicielle Google Code.
Google IO
Au mois de Mai 2008, Google a organisé une série de conférences [Google IO 2008] pour faire la
promotion de ses outils auprès des développeurs, présenter les nouveautés et parler du futur de ses
applications. Lors de ce Google IO 2008, la plate-forme Android était le sujet de six conférences
allant de la présentation générale de la plate-forme jusqu'aux détails de la séquence de démarrage
d'un terminal fonctionnant sous Android ou de l'implémentation de l'interpréteur de bytecode de la
machine virtuelle Dalvik.
Ces conférences ont été enregistrées et mises à disposition sur le site de partage de vidéos Youtube
et sur le site du Google IO 2008, sur lequel il est également possible de télécharger les supports de
ces conférences. Elles sont un outil formidable pour la promotion de ce projet et permettent de se
plonger rapidement dans le sujet. Cet évènement est renouvelé les 27 et 28 Mai 2009.
Android Developer Challenge

La mise à disposition de ces outils ne peut permettre à elle seule à Android de rattraper son retard et
de se constituer une collection suffisante de logiciels. C'est pourquoi Google a décidé d'organiser un
concours de développement d'applications pour sa plate-forme [ADC a], en proposant au total dix
millions de dollars pour cent applications.
La première partie de ce concours a déjà eu lieu, et sur les 1788 applications proposées, 50 ont été
récompensées. L'accent a été mis sur les applications utilisant au maximum les capacités du
téléphone, notamment en terme d'accès aux services en ligne. Par exemple, un de ces logiciels
permet de scanner un code barre sur un livre ou un CD, d'obtenir immédiatement des informations
sur le produit en s'appuyant sur les services proposés par Amazon. L'utilisateur peut ensuite le
commander en ligne, ou même connaître l'emplacement des plus proches magasins le proposant à la
vente. La majorité des applications tirent partie de la géolocalisation pour proposer des services
associés, comme du co-voiturage, des services d'alertes en cas de catastrophe à proximité...

Une autre application orientée biométrie permet d'utiliser la caméra du téléphone pour scanner son
iris et sécuriser ses données. Une présentation des applications est disponible sur le site d'Android
[ADC b], mais ne comprend que 46 applications car 4 développeurs ont choisi de travailler dans le
secret.
Google code
La forge logicielle Google code permet également aux développeurs de profiter d'un ensemble
d'outils (wiki, rapports de bogues, gestionnaire de versions...) pour concevoir et diffuser leurs
projets à une communauté de développeurs afin d'attirer d'autres contributeurs.
Le 9 Mai 2009, Google code intègre 616 projets en lien avec la plate-forme Android.

Les outils de développement
Lorsque les concepteurs d'Android ont eu à choisir un langage de programmation pour leur plate-
forme, il se sont tournés vers le Java, car selon eux, c'était le langage offrant le plus d'outils pour le
développement et le déploiement. En outre, il regroupait la communauté de développeurs la plus
importante. C'est pour cette raison que leur kit de développement est basé sur un certain nombre
d'outils issus du monde du Java.
Le kit de développement
Ce kit de développement est disponible pour les plates-formes Windows, Mac OS (Intel) et Linux et
se présente sous la forme d'une simple archive à télécharger. Il comprend la documentation
complète des API proposée par Android.
Il comprend également un ensemble d'outils permettant de simplifier l'élaboration d'une application,
de la création du projet, à la construction de paquet en passant par les phases de compilations et de
débogage.
Ces outils sont disponibles sous la forme de commandes pour les différents environnements.
Présentations des outils

android: Cette commande permet d'automatiser la création d'un nouveau projet ou d'un nouvel
environnement d'émulation. L'exécution de cette commande pour créer un projet permet de générer
automatiquement un ensemble de fichiers nécessaires au bon fonctionnement du projet. Les détail
de ces fichiers sera présenté dans le chapitre traitant de la structure d'une application.
ant: Cet outil n'est pas intégré au kit de développement, mais il est indispensable à la construction
des projets. Il permet d'automatiser les étapes de compilation du programme et se base sur certains
fichiers précédemment créés par la commande android.
adb: Ce programme permet de gérer l'état des émulateurs en cours d'exécution sur le système. Il
est notamment capable de modifier la configuration réseau de l'appareil émulé, d'installer de
nouveaux programmes ou d'exécuter des commandes à distance.
ddms: Il s'agit du débogueur qui sera utilisé par les développeurs pour diagnostiquer et corriger les
problèmes pouvant exister dans leurs applications. Il utilise la commande adb pour obtenir les
informations nécessaires à son fonctionnement, et permet ainsi au développeur de consulter en
temps réel l'état de la mémoire de l'appareil, les threads en cours d'exécution, l'état de la machine
virtuelle Dalvik, etc.

dx: Il s'agit du compilateur d'Android qui permet de transformer du bytecode Java (fichiers .class)
en bytecode Dalvik.
Android Developer Toolkit

Tous ces outils sont utilisables en dehors du cadre de tout IDE, cependant si les concepteurs
d'Android ont fait le choix du langage Java c'est aussi parce qu'il possède un environnement de
développement extrêmement évolué et complet: Eclipse.
Le projet Eclipse initié par IBM avait précisément pour objectif d'offrir un environnement de
développement qui puisse être enrichi par des tiers. Ainsi est né ADT, distribué sous la forme d'un
module d'extension pour Eclipse, il permet aux développeurs de bénéficier d'une interface plus
conviviale et de fonctionnalités supplémentaires.
Il simplifie l'invocation des commandes présentées précédemment en les intégrant au processus de
développement classique d'Eclipse. Il donne accès aux développeurs à des éditeurs graphiques
facilitant la création d'interface riches et ergonomiques, ou la modification des propriétés du projet
sans se plonger dans une syntaxe xml complexe.

Mobilité: plate-forme de développement Google/Android Développement d'applications pour Android
Développement d'applications pour Android
Structure d'une application
Fichier apk
Ce format partage certaines caractéristiques avec les fichiers de type jar issus du monde du Java,
montrant encore une fois l'intérêt des concepteurs d'Android pour ce langage et les outils qui
l'entoure. En revanche, ils y ont intégré leurs propres caractéristiques rompant ainsi avec le
standard. Nous expliquerons ces différences dans un second temps, mais d'abord rappelons les
caractéristiques communes aux deux formats.
Il ne s'agit ni plus ni moins que d'archives zip, leur particularité est de contenir un fichier appelé
manifeste qui regroupe un certain nombre d'informations sur le contenu de l'archive, en l'occurrence
sur notre application Android. Si on considère le répertoire / comme étant la racine de l'archive, le
fichier /META-INF/MANIFEST.MF contient des informations sur la version de fichier manifeste, sur
l'application qui a permis de créer l'archive. Il comprend également la liste des fichiers contenus
dans cette même archive, avec pour chacun une somme de contrôle (SHA-1) permettant d'en
vérifier l'intégrité.
Contrairement aux manifestes des fichiers jar, celui d'un fichier apk ne contient ni les informations
sur la classe principale à exécuter, ni sur les éventuelles chemins vers des classes complémentaires
(CLASSPATH) à prendre en compte à l'exécution.
Les informations sur la classe principale de l'application sont présentes dans un fichier
AndroidManifest.xml également présent dans l'archive et qui mérite une présentation individuelle.
Quant aux chemins vers des classes complémentaires, il n'est pas nécessaire car à la construction
d'un fichier apk, l'ensemble des classes est regroupé dans un autre format de fichier conçu pour la
machine virtuelle Dalvik et dont la création sera expliquée dans le chapitre traitant des
optimisations.
L'archive contient également tous les autres fichiers qui peuvent être nécessaires au fonctionnement
de l'application (images, sons...), soit en tant que « ressources » et présents dans le répertoire /res
s'il s'agit de fichier directement référencés dans l'application, soit en tant que « biens » et présents
dans le répertoire /assets s'il s'agit de fichiers auxquels l'application fait ponctuellement appel
selon un mécanisme plus complexe.

Enfin, dernière caractéristique notable des fichiers de type apk, ils peuvent être signés. La signature
est un mécanisme issu de la cryptographie à clé publique et permettant de vérifier la provenance et
l'intégrité d'un fichier. Le développeur effectue une somme de contrôle de son fichier manifeste et
chiffre cette somme de contrôle à l'aide de sa clé privée. L'utilisateur pourra ainsi déchiffrer la
somme de contrôle à l'aide de la clé publique du développeur et comparer le résultat à la somme de
contrôle de son fichier. Un certificat contenant la clé publique du développeur et signé par un tiers
de confiance est également distribué avec l'application. Pour obtenir une paire de clés et signer une
application selon le procédé exposé, les développeurs utilisent keytool et jarsigner, deux outils
développés par Sun, également utilisés pour la signature des fichier jar. Cette procédure crée deux
fichiers supplémentaires dans le répertoire /META-INF. Le certificat du développeur, généralement
un fichier , et la signature électronique.
Composant principaux
Avant de présenter le fichier AndroidManifest.xml il est nécessaire de présenter les concepts et les
éléments composants une application.
• Activités : Elles sont la partie visible de votre application, elles en affichent l'interface à
l'aide de vues et permettent d'interagir avec l'utilisateur.
• Services : Ils permettent d'effectuer des traitements en arrière plan en réponse à des requêtes
issues de votre applications ou d'applications tierces, sans affichage à destination de
l'utilisateur.
• Fournisseurs de contenu : Ils mettent des données en partage, permettant ainsi à différentes
applications d'utiliser et de modifier une source de données commune.
• Intentions : Elles sont des messages transmis entre applications. Votre application émet une
intention, le système la reçoit et la retransmet à son destinataire.
• Récepteurs : Ils permettent d'effectuer une tâche particulière à la réception d'une intention,
sans pour autant lancer un mécanisme complexe comme ceux des activités ou des services.
• Notifications : Elles fournissent un ensemble de mécanismes permettant d'informer
l'utilisateur sans interaction.
Le fichier AndroidManifest.xml
Ce manifeste définit les propriétés de votre applications et se présente sous la forme d'un fichier
xml, dont la structure générale est présentée ci-après.

<?xml version="1.0" encoding="utf-8"?>

<manifest>
<uses-permission />
<permission />
<permission-tree />
<permission-group />
<instrumentation />
<uses-sdk />
<application>
<activity>
<intent-filter>
<action />
<category />
<data />
</intent-filter>
<meta-data />
</activity>
<activity-alias>
<intent-filter> . . . </intent-filter>
<meta-data />
</activity-alias>
<service>
<meta-data/>
</service>
<receiver>
<meta-data />
</receiver>
<provider>
<grant-uri-permission />
<meta-data />
</provider>
<uses-library />
<uses-configuration />
</application>
</manifest>
fig 1: Aperçu de la structure du fichier AndroidManifest.xml
La balise <uses-permission> définit les permissions qui seront demandées à l'utilisateur lors de
l'installation de l'application. Il peut s'agir par exemple de l'autorisation de lire les SMS contenus
dans le téléphone, d'accéder aux informations de localisation, de modifier l'état de la connexion
Wi-Fi, etc. L'ensemble des permissions existantes par défaut est défini dans la classe
android.Manifest.permission. La permission requise par une de ces balises est présente dans
son attribut android:name.
Les applications peuvent déclarer des permissions personnalisées et les regrouper selon différentes
structures à l'aide des balises <permission>, <permission-group>, <permission-tree> .
La balise <instrumentation> est surtout utilisée à des fins de débogage, elle déclare une classe
dont le nom est décrit dans l'attribut android:name de la balise et qui hérite de la classe

Instrumentation. Elle permet d'observer les interaction entre l'application et le système.

Pour indiquer qu'une application nécessite un niveau d'API minimum le développeur peut utiliser la
balise <uses-sdk> et définir son attribut android:minSdkVersion dont la valeur par défaut est 1,
qui correspond à l'API d'Android 1.0. La version 2 est apparue avec Android 1.1, et actuellement
nous en sommes à la version avec Android 1.5.
Les deux autres balises définissant les contraintes sont <uses-library> et
<uses-configuration> qui permettent d'indiquer respectivement le besoin d'une librairie ou d'une
fonctionnalités (logicielle ou matérielle) particulière.
La balise <application> est la plus importante, elle définit les possibilités du logiciel et la façon
dont celui-ci agira avec le système et les autres applications. Un fichier manifeste contient cette
balise une et une seule fois.
Afin de rendre les activités visibles pour le système, à chaque activité d'une application doit
correspondre une balise <activity> dans le manifeste. L'activité principale de votre application
contiendra également une balise <intent-filter> construite selon le modèle ci-dessous et
permettant au système de l'identifier comme point d'entrée.
<intent-filter>
<action android:name=”android.intent.action.MAIN” />
<category android:name=”android.intent.category.LAUNCHER” />
</intent-filter>
Les élements action et category seront détaillés dans la partie consacrée aux objets de type Intent,
pour le moment nous retiendrons seulement que ce sont les éléments qui permette d'identifier un
Intent.
Les balises <service> et <receiver> suivent le même modèle et déclarent des <intent-filter>
pour chaque intention dont elles sont destinataires.
Une activité peut également être associée à d'autres intentions sous un autre nom en utilisant la
balise <activity-alias>.
Enfin pour déclarer un fournisseur de contenu accessible aux autres applications et à l'application
elle même, on utilisera la balise <content-provider>. Ce nouveau fournisseur de contenu sera
accessible via la ou les URI définie dans l'attribut android:authorities.
Les balises <meta-data> permettent d'intégrer des données supplémentaires dans certaines balises,
ces données sont accessibles depuis le gestionnaire de paquets d'Android.
Nous ne présenterons pas l'intégralité des attributs utilisés dans le fichier manifeste d'Android car ils
sont nombreux et tous n'ont pas un intérêt essentiel. On peut néanmoins retenir que les balises
activity, service, receiver et provider ont toutes en commun un atrribut android:name dont la valeur

est identique au nom complet (package compris) d'une classe héritant respectivement des classes
android.app.Activity, android.app.Service, android.content.BroadcastReceiver et
android.content.ContentProvider.
À noter aussi que si la valeur des attributs est généralement de type simple (chaine de caractères,
entier, booléen...), elle peut aussi constituer un pointeur vers une ressource plus complexe (chaine
de caractère plus longue et utilisée plusieurs fois, image...).
La syntaxe de ce fichier étant relativement complexe, il est intéressant de noter que l'outil ADT pour
Eclipse comprend un éditeur beaucoup plus intuitif et graphique qui en simplifie l'écriture.

Présentation de l'API
Après avoir présenté brièvement les concepts et classes principaux composant une application pour
la plate-forme Android nous allons maintenant nous intéresser à leur utilisation et à leur
fonctionnement interne.
Activités et services
Une activité doit hériter de la classe android.app.Activity, elle est instanciée lorsque le système
reçoit un Intent dont elle est destinataire, puis son cycle de vie suit le schéma ci-dessous.
fig 2: Cycle de vie d'une activité

Le diagramme précédent met en avant les différentes méthodes que le développeur devra redéfinir
afin de personnaliser le comportement de son application. Dans ces différentes méthodes il pourra
connaitre l'objet Intent qui a déclenché l'activité avec la méthode getIntent() ou définir la vue à
afficher setContentView().
Les services eux, doivent hériter de la classe android.app.Service, ils sont également instanciés
lorsque le système reçoit un objet Intent dont ils sont destinataires, mais ont un cycle un peu
différent.
fig 3: Cycle de vie d'un service

Comme nous pouvons le voir sur le diagramme précédent les services ont deux cycles de vie
possibles. Si nous sommes dans l'application qui contient le service appelé notre classe aura accès à
la déclaration du service et pourra l'utiliser, dans l'autre cas le service n'existe pas dans la même
instance de machine virtuelle que l'application cliente, cette dernière n'a donc pas accès à la
déclaration de la classe service, elle obtiendra ces informations par l'intermédiaire d'un objet
IBinder retourné lors de la connexion au service. Ce mécanisme sera décrit plus en détail dans le
chapitre dédié aux communications.
Interfaces utilisateur
Les concepts les plus importants à connaître pour construire des interfaces utilisateur sous Android
sont les vues, les groupes de vues, les dispositions, les widgets et les adaptateurs de vue.
Tout élément présenté à l'utilisateur sera une vue, en terme de programmation cela se traduit par le
fait que l'ensemble des classes dont nous allons parler héritent de la classe android.view.View., ainsi
un groupe de vues qui aura pour tâche d'afficher une vue à l'écran sera également une vue. Ce
mécanisme est également utilisé dans d'autres toolkits graphiques java (AWT, Swing...). Les
dispositions (layout) sont un peu particulier car ils ne feront généralement pas l'objet d'une
implémentation sous forme de classe. En effet, même s'il est possible de décrire les interfaces
utilisateur de façon programmatique, il est également possible de les décrire dans un fichier xml,
qui regroupera alors l'ensemble de vue et les indications permettant au système de les afficher
conformément au souhait du programmeur.
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/eng111"/>
<ImageView android:id="@+id/ImageView01"
android:layout_width="wrap_content"
android:src="@drawable/android" />
<ImageView android:id="@+id/ImageView02"
android:layout_width="wrap_content"
android:src="@drawable/logocnam" />
</LinearLayout>
fig 4: Exemple de fichier de layout pour Android

Les widgets sont également des vues, mais contrairement aux vues qui n'ont pour seul objectif que
d'afficher des informations, les widgets permettent de gérer les interactions avec celui-ci. La
programmation événementielle se fait de manière tout à fait classique, à l'aide d'écouteurs Java.
Il existe six types d'écouteurs : OnClickListener, OnLongClick(), OnFocusChange(), OnKey(),
OnTouch() et OnCreateContextMenu(), permettant d'intercepter respectivement : le simple clic, un
clic long (1 seconde), le changement de focus, l'enfoncement ou relâchement d'une touche, le
toucher (le fait d'appuyer, de relâcher ou d'effectuer un quelconque mouvement sur l'écran tactile) et
la création d'un menu contextuel. Cette dernière est un peu particulière, elle implique que
l'utilisateur clic ou maintienne appuyé pendant 2 secondes sur notre widget, et permet la création
d'un menu simple (liste d'action), adapté à l'interface actuellement affichée à l'utilisateur.
Dans le cas où le développeur souhaite créer une vue comportant une répétitions d'éléments, comme
une liste, une galerie, etc, il peut utiliser un adaptateur de vue. Cet adaptateur permet de lier une vue
à une source de données et d'automatiser la création de sous-éléments en les peuplant à l'aide des
données de notre source, puis d'indiquer à notre vue quel adaptateur utiliser. Pour prendre en
compte les actions de l'utilisateur sur les sous-éléments, l'adaptateur de vue définit un écouteur
supplémentaire: OnItemClickListener.
Il existe également des mécanismes simples permettant de notifier des informations à l'utilisateur,
soit en affichant brièvement le message à l'écran à l'aide d'un objet Toast, soit en affichant le
message dans la barre d'état du terminal. Dans ce dernier cas, il est nécessaire d'utiliser le service de
notification afin de lui transmettre notre message, sous la forme d'un objet Notification qui contient
un objet Intent. Ce mécanisme est plus complexe, mais il permet d'associer d'autres actions à la
notification, l'activation du vibreur, la lecture d'un son ou la variation du rétro-éclairage par
exemple.
Dernière possibilité d'interface utilisateur, il est possible de créer des boites de dialogues si l'on
souhaite obtenir une information rapidement de l'utilisateur (choisir un item dans une liste, répondre
oui ou non à une question...), cette méthode est également adaptée pour afficher une information qui
doit occuper le premier plan pendant un certain temps. Une barre de progression faisant part à
l'utilisateur de l'avancement d'une tâche relativement longue utilisera ce mécanisme.

Ressources
Les ressources d'un projet destiné à la plate-forme Android se trouvent dans le répertoire /res de
l'archive apk. Elles sont ensuite réparties dans différents répertoires en fonction de leur type.
Les fichiers layout vues précédemment (voir fig 4) font partie des ressources et se trouvent dans le
répertoire /res/layout, les fichiers xml définissant un menu se trouvent dans le répertoire
/res/menu.
Les images utilisés dans une application, son icône apparaissant dans le menu par exemple, se
trouvent dans le répertoire /res/drawable. Pour faire références à ces ressources depuis un fichier
xml de layout, le manifeste, un menu, etc, il suffit de préciser le chemin vers la ressource qui
s'exprime sous la forme suivante: @[package:]drawable/mon_image. Le package n'est à préciser
que si l'application en contient plusieurs et que l'image fait partie d'un autre que le principal défini
dans l'attribut package de la balise <manifest> du fichier AndroidManifest.xml. La majorité des
ressources est adressable selon le même mécanisme.
Concernant les images, afin de parer aux différences de résolutions et de taille des écrans sur les
terminaux mobiles, Android propose un mécanisme (NinePatch) permettant de définir des zones de
l'image dont les dimensions peuvent être modifiées. Pour simplifier, l'image est découpée en neuf,
les quatre coins de l'image restent inchangés, les bords sont redimensionnés selon un axe, et la
partie centrale selon les deux axes. Les zones permettant de découper l'image sont définies en
ajoutant un pixel sur chaque côté de l'image et en traçant une ligne noire le long des zones à
redimensionner. Pour utiliser ce mécanisme, le kit de développement d'Android contient un
programme, draw9patch, qui permet de modifier une image existante, de définir les différentes
zones, d'en vérifier le rendu à l'aide d'un aperçu et de sauver l'image sous un nom qui permet à
Android d'identifier l'image comme étant un NinePatch.
Pour intégrer des animations dans ses applications, le développeur peut utiliser un format spécifique
à la plate-forme Android qui permet de décrire l'ensemble des transformations composant une
animation dans un fichier xml. Les transformations possibles sont: la rotation, le fondu, la
translation et le redimensionnement; il n'est nécessaire que de décrire les étapes clés de la
transformations, car la plate-forme peut interpoler les images intermédiaire. Si l'animation comporte
plusieurs étapes clés le développeur peut définir les propriétés d'interpolation entre chacune d'elle.
Il est également possible de définir des styles sous forme de fichier xml qui pourront être associés à
des vues ou à l'ensemble de l'application en tant que thème. Ces styles sont stockés dans le
répertoire /res/values/style.xml. Le répertoire /res/values contient également le fichier

strings.xml qui contient l'ensemble des chaînes caractères utilisées dans l'application. Les styles
sont accessibles avec l'URI suivante @[package:]style/mon_style et les chaînes de caractères
@[package:]string/ma_chaine.
Les ressources sont accessibles depuis les classes java en utilisant une classe particulière nommée
R, créée et mise à jour automatiquement par ADT. Elle définit des identifiants pour chaque
ressources et fournit un ensemble de méthodes permettant de retrouver l'objet ressource par son
identifiant.
Si le développeur souhaite que son application puisse accéder à d'autres types de fichiers que ceux
définis par défaut pour la plate-forme Android, il peut joindre ses fichiers à son projet dans le
répertoire /assets. La plate-forme fournit un AssetManager qui permet d'accéder aux données
brutes de ces fichiers.
Intentions et récepteurs
Les objets de type Intent sont utilisés pour transmettre des messages entre applications ou au sein
d'une même application, ils comprennent un ensemble d'informations à destination du récepteur.
L'Intent peut être à destination d'un composant précis, dans ce cas il faut que sa propriété
ComponentName soit renseignée. Pour définir, plus précisément un Intent il possède également une
propriété Action qui donne une indication au destinataire sur l'action à entreprendre. Les types
d'actions sont définies en tant que constante de la classe Intent, c'est également le cas des Category
qui permettent de qualifier le message.
Le système se base sur les propriétés des Intent pour savoir à quel composant le transmettre, on peut
distinguer le cas des Intent dont le destinataire est explicitement spécifié et ceux qui ne précisent
pas le composant, mais uniquement une action et/ou une catégorie. Dans le deuxième cas, pour
connaitre le composant à activer le système se base sur les <intent-filter> déclarés dans le
manifeste de l'application et pour lequel une action et une catégorie sont précisées.
Nous avons déjà vu comment la réception des Intent s'intégrait dans les cycles de vie des activités et
des services. Pour ce qui est des récepteurs (balise <receiver> dans le manifeste), qui héritent de
la classe android.content.BroadcastReceiver, la réception d'un Intent déclenche uniquement
l'appel de la méthode onReceive().
Lorsque l'émetteur a besoin de transmettre des informations supplémentaires avec l'Intent il peut
définir la propriété Data qui permet de définir l'adresse d'un fournisseur de contenu utilisable par le
destinataire. Si le développeur a besoin dans son application de données qui sont gérées par une
autre activité, il pourra lui envoyer sa requête à l'aide d'un objet Intent en utilisant la méthode

startActivityForResult(). Lorsque l'exécution de la sous-activité sera terminée, la méthode

onActivityResult() de l'activité appelante sera invoquée, elle aura accès par ses paramètres à un
éventuel fournisseur de contenu retournée par la sous-activité.
Pour permettre aux développeurs d'application d'avoir accès à certains éléments du système, et ainsi
être mieux intégrés au téléphone, les applications peuvent utiliser les actions et catégories déjà
définies afin d'interagir avec les composant natifs. Une application de recherche de magasins peut,
par exemple, émettre un objet Intent avec l'action ACTION_DIAL indiquant au système qu'il doit
composer le numéro de téléphone du magasin recherché. Si un composant opère un traitement
particulièrement lourd et non essentiel, il pourra le stopper à la réception d'un objet Intent lui
signifiant que la batterie de l'appareil est faible.
Les applications Google distribuées avec les terminaux peuvent être invoqués par la réception de
certains Intents [Android b], cette technique permet aux développeurs d'améliorer l'intégration de
leurs applications à l'environnement du terminal.
Une initiative de la communauté [OpenIntents] a un objectif similaire, elle répertorie un ensemble
d'Intents et d'applications supplémentaires, ainsi que les Intents qu'elles sont susceptibles d'émettre
ou de recevoir.

Fournisseurs de contenu
Avant de s'intéresser aux fournisseurs de contenu, une brève introduction sur le stockage des
données est nécessaire. La plate-forme Android propose quatre mécanismes de stockage et d'accès
aux données.
• Préférences : C'est un mécanisme léger pour stocker des couples (clé,valeur) de types
primitifs. Il est typiquement utiliser pour sauvegarder des options ou paramètres qui seront
lues au démarrage de l'application.
• Fichiers : Les informations sont stockées dans des fichiers accessibles uniquement à
l'application. L'accès à ces fichiers se fait par l'intermédiaire de la classe Context et des
mécanismes Java standards de lecture/écriture de fichier.
• Bases de données : La plate-forme Android fournit une API pour la création et l'utilisation
de bases de données du type SQLite. De même que les fichiers, ces bases de données ne sont
visibles que de l'application qui les crée.
• Réseau : L'utilisation des sockets réseaux ou d'autres mécanismes de plus haut niveau
permet d'obtenir ou d'envoyer des données à un serveur distant.
Les fournisseurs de contenus utilisent ces mécanismes pour accéder aux données, et les rendre
disponibles aux autres composants. Ils héritent de la classe android.content.ContentProvider
et doivent implémenter les méthodes suivantes: query(), insert(), update() delete(),getType(), afin de
de permettre l'accès aux données.
Le modèle de données présenté par les fournisseurs de contenu est conforme à celui d'une simple
table de base de données où les colonnes correspondent à des attributs et les lignes à des éléments.
Une requête renvoie un objet de type Cursor qui permet de naviguer d'un enregistrement à l'autre.
Pour chaque collection de données mise à disposition par le fournisseur de contenu, celui-ci doit
fournir une URI de la forme suivante: content://com.example.newsprovider/news. En utilisant
cette adresse et la classe ContentResolver, une application effectue ses requêtes sur la source de
données.

Communication
Dans la partie précédente nous avons vu comment les développeur d'Android ont organisé leur API
pour simplifier les communications entre applications tout en respectant certains points de contrôle
de sécurité. Ils ont aussi intégrer un ensemble de classes et de concepts permettant de simplifier la
communication avec d'autres services intégrés ou non au terminal mobile.
Android Interface Definition Language

Afin de permettre aux applications autrement que par les Intents et ContentProvider, et pour leur
permettre d'accéder aux services du système. Les concepteurs d'Android ont défini un mécanisme
d'appel de procédure distance. Il se base sur un langage de description d'interface (aidl) qui permet
d'automatiser la génération des classes nécessaires à ce mécanisme à l'aide de l'outil du même nom.
fig 5: Mécanisme d'appel de procédure distante

Comme indiqué sur le diagramme, le développeur devra décrire son interface dans un fichier aidl
qui permettra de générer le talon et la classe utilisable par le client. Il pourra ensuite écrire sa classe
implémentant l'interface et un service qui retournera un objet de cette classe à la connexion d'un
client.

Le client lui essaie de se connecter au service en utilisant la méthode bindService(), il devra alors
passer en paramètre un objet ServiceConnection implémentant les méthode onServiceConnected()
et onServiceDisconnected() appelée lors de la connexion, respectivement la déconnexion du
service. Une fois la connexion établie, il récupère un objet IBinder à partir duquel il pourra obtenir
l'interface du service.
Services web REST et représentation des données

Les services web de style REST ont pour caractéristiques principales de pouvoir fonctionner sur le
protocole HTTP et d'utiliser une URI pour identifier la ressource à atteindre [Fielding 2000]. On
peut noter que la construction des requêtes vers les services web de style REST est assez semblable
à celle des requêtes destinées aux fournisseurs de contenu.
La plate-forme Android propose justement un client http simplifiant la construction des requêtes à
destinations des services web de style REST. La réponse à une requête pourra être formatée en xml
ou en json, or la plate-forme Android fournit un ensemble de classe permettant d'exploiter ces
formats.
Le xml peut être analysé soit selon le DOM qui construit une structure statique représentant le
document, soit en utilisant SAX qui lit séquenciellement le xml et appelle une fonction de rappel à
chaque balise. L'approche du DOM est plus simple pour le développeur mais nécessite une grande
quantité de mémoire car l'ensemble de la structure est créée en mémoire. L'utilisation de SAX est
plus adapté si les ressources sont limités, mais elle est plus complexe. Enfin, la dernière API
disponible pour analyser le xml est XMLPull, qui permet de traiter le xml comme une séquence de
balises et ainsi simplifier la programmation, sans pour autant créer une structure complexe en
mémoire.
Le json lui est analysable via la classe JSONObject qui permet de créer en mémoire la structure
correspondant à la réponse json. L'utilisation de ce format est préférée à celle du xml, car la
représentation d'une structure en json est bien plus réduite que son équivalent en xml. Or dans le
contexte des terminaux mobiles où la bande passante est une ressource critique, il est préférable de
la préserver.
L'utilisation de REST permettra d'utiliser les services web de nombreux acteurs du web (Yahoo!,
Flickr, del.icio.us, technorati, eBay, Amazon...), même si on peut regretter l'absence
d'implémentation de SOAP, il existe une solution pour l'intégrer à une application.

Applications distribuées
Google contribue énormément au projet Android et ce, sous différentes formes. Ainsi il ne faut pas
confondre les applications que Google distribue pour Android, qui sont présentes sur la plupart des
téléphones et l'existence pour les développeurs d'une API permettant d'accéder aux mêmes services
que ces applications.
Dans la dernière version de Google Android, il est maintenant possible d'envoyer des vidéos sur
Youtube ou des photos sur Picasa, cela ne veut pas dire que les développeurs peuvent intégrer ce
genre de fonctionnalités directement dans leur application. L'intégration de GoogleTalk notamment
pose certains problèmes car l'API n'est pas disponible pour les développeurs, mais les applications
natives l'utilisent.
Les développeurs peuvent tout de même profiter d'une API distribuée sous la forme d'une librairie et
qui leur permet d'interagir avec GoogleMaps simplement [Google API], en intégrant une vue dans
leur application et en la modifiant selon leur besoin. Les applications proposées pour l'Android
Developer Challenge utilisent souvent cette vue pour intégrer des services de géolocalisation.
La communauté des développeurs est également à l'origine d'initiatives intéressantes, comme
l'écriture d'une librairie offrant l'accès aux webservices SOAP [Android SOAP], ou le portage les
librairies GoogleData pour Android []. Elle permet déjà aux développeurs d'accéder aux contacts du
compte Google et à l'application Blogger. Grâce à cette librairie on peut espérer, à terme, avoir
accès aux autres API (Calendar, Book search, Finance Portfolio, Spreadsheet..).
Un dernier exemple intéressant d'application distribuée sur la plate-forme Android est le logiciel de
discussion géolocalisé [jChat] développé par Telecom Italia et utilisant leur implémentation d'un
système multi-agent en Java (JADE) [Gotta et al 2008] pour Android. Elle permet, en utilisant une
carte, de visualiser les contacts à proximité et de communiquer facilement avec eux, via un outil de
discussion, SMS ou conversation téléphonique.

Mobilité: plate-forme de développement Google/Android Architecture interne d'Android
Architecture interne d'Android
Vue d'ensemble du système
La plate-forme Android proposée par Google se présente sous la forme d'une pile logicielle pour les
appareils mobiles. Elle inclut le système d'exploitation Linux, des librairies de bas-niveau adaptées
au contexte des systèmes embarqués et la machine virtuelle Dalvik qui permet aux développeurs de
profiter d'une API complète et de plus haut niveau.
fig 6: Architecture de la plate-forme Android

Grâce à l'intégration du noyau Linux et de librairies Open-Source, les développeurs de la plate-
forme Android profitent d'une base de code conséquente et mise à jour régulièrement. Cela peut
poser des problèmes si l'API de ces librairies change, comme ce fut le cas pour Bluez, la librairie

bluetooth d'Android. En dehors de ces problèmes marginaux, ils peuvent concentrer leurs efforts sur
l'essentiel: La machine virtuelle Dalvik et l'API proposée aux développeurs tiers.
Sur le diagramme ci-dessus, on peut voir que les modifications du noyau Linux concernent surtout
l'intégration de pilotes de périphériques, exception faite du module permettant de réaliser le
mécanisme de communication (IPC) présenté précédemment.
Surface Manager, OpenGL | ES et SGL sont les librairies graphiques utilisées par Android pour
l'affichage et le rendu des interfaces utilisateurs. Il existe même une implémentation de la JSR239
définissant un sous ensemble de la librairie OpenGL utilisable par des applications Java à
destination des terminaux mobiles. Les appels de cette implémentations utilisent donc directement
la libraire OpenGL | ES par le biais de l'interface Java native (JNI).
La librairie Freetype est également utilisée pour le rendu des interface utilisateurs, et plus
particulièrement pour le rendu des polices de caractères.
La librairie SSL permet l'utilisation du protocole du même nom dans les applications réseaux.
WebKit comprend les moteurs de rendu HTML et d'interprétation Javascript mis à dispositions aux
développeurs.
La librairie C intégrée à Android est une nouvelle implémentation, nommée bionic, dont les
objectifs sont de fournir une librairie C standard légère tout en conservant un espace utilisateur libre
de copyleft. La gestion des exceptions C++, n'est pas implémentée dans bionic, car elle utilise trop
de ressources.
SQLite permet aux développeurs de profiter d'un système de gestion de base de données au sein de
leurs applications pour la plate-forme Android.
La lecture des vidéos, sons et autres fichiers multimédias est réalisé grâce au système OpenCORE
développé par la société PacketVideo, qui fait partie des membres fondateurs de l'OpenHandset
Alliance.
L'ensemble de ces librairies sont disponibles sous des licences à code ouvert n'intégrant pas la
notion de copyleft. En effet, l'OpenHandset Alliance et Google ont souhaité laisser la possibilité de
modifier l'espace utilisateur de la plate-forme Android sans redistribuer les modifications.
L'ensemble des manager présentés dans l'Application Framework du diagramme sont accessibles en
Java via des services et font eux-même appel aux librairies natives en utilisant JNI. Ce mécanisme
permet de profiter des performances du code natif, tout en limitant l'exposition des composants clés
du système.

Les optimisations de Dalvik
Lors de la conception de la machine virtuelle Dalvik, les préoccupations majeures des développeurs
ont été la prise en compte des limitations dues au contexte de système embarqué (mémoire,
puissance de calcul, batterie...), et la maximisation des performances. Leurs objectifs étaient de
diminuer l'empreinte mémoire des applications, de partager les ressources alloués entre les
applications et d'optimiser le mécanisme d'interprétation du code intermédiaire (bytecode). Ces
contraintes les ont amenés à définir leur propre format pour la distribution des applications, les
fichiers Dalvik Executable reconnaissables à leur extension DEX.
Format DEX
fig 7: Schéma des références internes d'un fichier DEX

Ce format utilise un système complexe de références internes pour limiter au maximum la

duplication des données qui existe dans le format JAR pour J2ME. Dans ce dernier, les fichiers
classes compilés contiennent chacun les chaînes de caractères définissant leurs types de données,
méthodes, prototypes de méthodes ou autres. Du fait des mécanismes d'héritage du langage Java,
ces informations sont reproduites de nombreuses fois entre les différentes classes et même à
l'intérieur d'un unique fichier de classe.
Dans un fichier DEX, les informations redondantes (chaînes de caractères, prototypes de
méthodes...) sont uniquement pointées dans le contenus, mais regroupées et indexées en fin de
fichier (voir fig 7). Cette technique permet sur des jeux de tests de constater qu'un fichier DEX
occupe légèrement moins de place qu'un fichier JAR. Chose encore plus intéressante, le fichier
DEX n'étant pas compressé, il occupera la même place sur le disque qu'en mémoire, alors qu'un
fichier JAR devra être décompressé avant d'être chargé en mémoire. Le gain final est de l'ordre de
50%.
Zygote et le Copy-on-Write
Lors du démarrage du système, le noyau linux charge le processus init. Ce dernier lancera les
différents démons permettant l'accès aux services de bas niveaux (USB Daemon, Radio Interface
Layer Daemon, …), puis il lancera ensuite un processus particulier appelé zygote. Dans son
acception biologique, ce terme représente la première étape de la vie, concernant la plate-forme
Android, il est le processus originel à partir duquel toutes les applications seront créées.
À sa création, ce processus initialise une instance de la machine virtuelle Dalvik, puis attend de
recevoir des requêtes demandant la création d'autres machines virtuelles.
Les nouvelles instances de machines virtuelles seront créées à partir d'un fork de ce processus.
Comme lors de toute utilisation de fork sous linux, le processus fils partage le même espace
mémoire que son père, jusqu'à ce qu'un des deux tente de le modifier. Le système intercepte cette
modification et réalise la copie de l'espace mémoire afin de le différencier.
Ce mécanisme, appelé Copy-On-Write, permet d'éviter une copie inutile pour certains processus,
économisant ainsi la mémoire et le processeur.

Mobilité: plate-forme de développement Google/Android Perspectives
Perspectives
Le monde du Web évolue très rapidement alors que celui de la téléphonie mobile peut donner
l'impression d'une certaine lenteur. Toutefois avec des solutions comme celles proposées par Apple
ou Google, nous sommes amenés à constater des changements très rapides. Entre le moment où la
rédaction de ce rapport a commencé et maintenant, Google a déjà sorti trois nouvelles versions
mineures de son SDK (1.5pre, 1.5-r1 et 1.5-r2). Une rumeur évoquait la possibilité de voir
commercialiser des ordinateurs ultra-portables sous Android, une compagnie chinoise en propose
déjà. Dell, HP et Asus ont tous annoncé ou laissé entendre qu'ils proposeraient ce genre de produits.
Ces ulta-portables équipés de connexions Wi-Fi et/ou 3G sont une preuve supplémentaire que les
constructeurs souhaitent offrir aux utilisateurs la possibilité de rester connectés en permanence au
« nuage ».
L'objectif est donc de proposer aux développeurs un environnement qui leur permettent d'intégrer
facilement des données ou des fonctionnalités provenant de services en lignes ou d'autres
applications amenant ainsi à la création de « mashups ». Les innovations ainsi proposées sur les
terminaux mobiles ne sont plus un simple accès à une information auparavant inaccessible. Les
développeurs peuvent réellement recombiner et réutiliser toutes sortes de données afin d'offrir à
l'utilisateur une expérience nouvelle.
Malgré quelques problèmes d'intégration de certaines API présentes dans les premières versions du
SDK et absentes par la suite (GoogleTalk, Bluetooth), la plate-forme Android propose réellement un
environnement favorisant: l'interconnexion de ses différents composants et applications, la
connexion vers des services en lignes. Ce fait est confirmé par les initiatives de la communauté des
développeurs évoqués dans ce rapport.
La manipulation et le recoupement d'une telle quantité de données pose toutefois quelques
problèmes. L'utilisateur garde-t-il réellement la maîtrise de ses données personnels lorsqu'elles
transitent par tant d'outils et tant d'acteurs (Google, Twitter, Amazon, …) ? Comment être sûr que
dans la chaîne de ces fournisseurs de services certains n'exposent pas certaines informations à
caractère privées ?

Mobilité: plate-forme de développement Google/Android Glossaire
Glossaire
API: Application Programming Interface. Ensemble des fonctions d'un programme accessible à un
autre programme.
APK: Android Package. Format de fichier utilisé pour distribuer les applications à destination de la
plate-forme Android.
Bytecode: Code intermédiaire exécutable par l'interpréteur d'une machine virtuelle.
Copyleft: Possibilité, laissée par l'auteur d'un travail soumis au droit d'auteur, de modifier et
redistribuer ce travail sous réserve de respecter les mêmes conditions d'application du droit d'auteur.
DEX: Dalvik Executable. Format de fichier exécutable dans la machine virtuelle Dalvik, il est
compilé en Dalvik Bytecode.
DOM: Document Object Model. Recommendation du w3c décrivant une interface de consultation,
mise à jour, de la structure ou du contenu d'un document.
GPS: Global Positionning System. Système de positionnement par satellites, il permet, à un
utilisateur équipé d'un récepteur, de connaître sa position.
IPC: Inter Processus Communication. Ensemble de mécanismes permettant à des processus d'un
système informatique de communiquer.
J2ME: Java 2 Micro Edition. Spécification d'un sous ensemble de Java destiné à être implémenté
sur les appareils à faibles ressources (Mémoire et processeur).
JADE: Java Agent DEvelopment Framework. Framework Java pour les systèmes multiagent.
JAR: Java Archive. Format de fichier utilisé pour l'échange d'applications ou de librairies Java .
JIT: Just in time. Se dit d'un compilateur embarqué dans certaines machines virtuelles. Il permet de
compiler depuis du bytecode vers le langage natif de la machine, uniquement lors de son utilisation.
JNI: Java Native Interface. Mécanisme permettant à un programme Java de faire appelle à des
librairies compilées en code natif.
JSON: JavaScript Object Notation. Format de données textuel, dérivé de la notation des objets du
langage ECMAScript.
JSR: Java Specification Request. Ensemble de spécifications établies et revues par la communauté
dans le but de faire évoluer la plate-forme Java.
HTTP: HyperText Transfer Protocol. Protocole de communication client-serveur développé pour le
World Wide Web.
IDL: Interface Description Langage. Langage de description d'interface permettant la
communication entre des composants répartis.

Mashups: Applications ou sites composites tirant leurs données et/ou fonctionnalités de plusieurs
autres applications ou sites.
PDA: Personnal Digital Assistant. Ordinateur de poche.
REST: REpresentational State Transfer. Style d'architecture utilisé notamment pour la création de
services web.
SAX: Simple API for XML. Interface de programmation permettant de lire et traiter du XML.
SDK: Software Development Kit. Un kit de développement est un ensemble d'outils permettant au
développeur de créer des applications pour une plate-forme donnée.
SOAP: Simple Object Access Protocol. Protocole d'appel de procédure distante bâti sur xml.
URI: Uniform Resource Identifier. L'identifiant uniforme de ressource est une chaîne de caractère
permettant d'identifier une ressource.
W3C: World Wide Web Consortium. Consortium chargé de promouvoir la compatibilité des
technologies du World Wide Web.
WiFi: Wireless Fidelity. Technologie de réseau informatique sans-fil.
XML: eXtensible Markup Language. Langage informatique de balisage générique, servant
essentiellement à l'échange de données de type texte structurées en champs arborescents.

Bibliographie
OHA 2008: Industry Leaders Announce Open Platform for Mobile Devices,
http://www.google.com/intl/en/press/pressrel/20071105_mobile_open.html, consulté le 23/05/2009
Google IO 2008: Google I/O Session Videos and Slides, http://sites.google.com/site/io/, consulté le
23/05/2009
ADC a: Annonce de l'Android Developer Challenge, http://www.google.fr/press/20071112_android-

developer-challenge.html, consulté le 09/05/2009
ADC b: Gagnants de l'Android Developer Challenge,

http://code.google.com/android/images/adc1r1_deck.pdf, consulté le 10/05/2009
Android b: Intents List: Invoking Google Applications on Android Devices,

http://developer.android.com/guide/appendix/g-app-intents.html, consulté le 08/05/2009
OpenIntents: OpenIntents website, http://www.openintents.org/, consulté le 17/05/2009
Fielding 2000: Roy Thomas Fielding, Architectural Styles andthe Design of Network-based
Software Architectures, 2000
Google API: Google Projects for Android: Google APIs, http://code.google.com/intl/fr/android/add-

ons/google-apis/index.html, consulté le 18/05/2009
Android SOAP: My Solution: Calling SOAP 1.1. Web Services from Android (ksoap2 + apache
http) , http://groups.google.com/group/android-
developers/browse_thread/thread/9b246db7d612a6b5/4e86059309d7b10f?#4e86059309d7b10f,
consulté le 18/05/2009
jChat: jChat pour Android, http://code.google.com/p/jchat4android/, consulté le 08/05/2009
Gotta et al 2008: Jade Android Add-on guide,

http://jade.tilab.com/doc/tutorials/JADE_ANDROID_Guide.pdf, consulté le 26/04/2009
Reto Meyer 2009, Professional Android Application Development, Wiley-Blackwell, ISBN-13:
978-0470344712
Jerome DiMarzio 2008, Android Programming Guide, McGraw-Hill Osborne Media, ISBN-13:
978-0071599887

Résumé
Cette étude présente la plate-forme Google/Android en général et du point

du vue du développeur. Les solutions concurrentes sont brièvement
présentées afin d'expliquer les choix de conception d'Android. Google a
assuré la promotion de sa plate-forme en proposant un large choix d'outils,
dont certains déjà existants. Ce document comprend une introduction à ces
outils ainsi qu'une étude des spécificités du développement Java pour la
machine Virtuelle Dalvik. Enfin, la cible de la plate-forme Android étant des
terminaux mobiles aux ressources extrêmement limitées il est intéressant de
découvrir les mécanismes d'optimisation surtout lorsque ceux-ci mènent à
une rupture de compatibilité avec l'existant.
Abstract
This study presents the Google/Android platform especially from the

developper angle. The competitors' solutions are briefly introduced in order
to emphasize the differences and choices made regarding the Android
platform. Google pushed its platform with a significant set of already
existing and new tools giving them a competitive advantage. This study also
comprises a presentation of these tools and the specificities of the java
developement process for the Dalvik Virtual Machine. Finally, the target of
Android being mobile devices with extremely scarce resources, we focus on
the optimisations mecanisms especially when they lead to compatibility
breakage.
Mot-clés: Android, Google, Mobilité, développement, Java

Probatoire

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Probatoire

Uploaded by

Copyright:

Available Formats

CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS

CENTRE REGIONAL ASSOCIÉ DE PICARDIE

ENG111 : INFORMATION ET COMMUNICATION POUR L'INGENIEUR

Mobilité : plate-forme de développement

Soutenu le 8 Juin 2009

Conservatoire National des Arts et Métiers - Amiens 2 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 3 Session 2008/2009

Les autres plates-formes mobiles

Conservatoire National des Arts et Métiers - Amiens 4 Session 2008/2009

Accessibles aux développeurs

Conservatoire National des Arts et Métiers - Amiens 6 Session 2008/2009

Les outils communautaires de Google au service d'Android

Android Developer Challenge

Conservatoire National des Arts et Métiers - Amiens 7 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 8 Session 2008/2009

Les outils de développement

Présentations des outils

Conservatoire National des Arts et Métiers - Amiens 9 Session 2008/2009

Android Developer Toolkit

Conservatoire National des Arts et Métiers - Amiens 10 Session 2008/2009

Développement d'applications pour Android

Structure d'une application

Conservatoire National des Arts et Métiers - Amiens 11 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 12 Session 2008/2009

<?xml version="1.0" encoding="utf-8"?>

fig 1: Aperçu de la structure du fichier AndroidManifest.xml

Conservatoire National des Arts et Métiers - Amiens 13 Session 2008/2009

Instrumentation. Elle permet d'observer les interaction entre l'application et le système.

Conservatoire National des Arts et Métiers - Amiens 14 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 15 Session 2008/2009

fig 2: Cycle de vie d'une activité

Conservatoire National des Arts et Métiers - Amiens 16 Session 2008/2009

fig 3: Cycle de vie d'un service

Conservatoire National des Arts et Métiers - Amiens 17 Session 2008/2009

fig 4: Exemple de fichier de layout pour Android

Conservatoire National des Arts et Métiers - Amiens 18 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 19 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 20 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 21 Session 2008/2009

startActivityForResult(). Lorsque l'exécution de la sous-activité sera terminée, la méthode

Conservatoire National des Arts et Métiers - Amiens 22 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 23 Session 2008/2009

Android Interface Definition Language

fig 5: Mécanisme d'appel de procédure distante

Conservatoire National des Arts et Métiers - Amiens 24 Session 2008/2009

Services web REST et représentation des données

Conservatoire National des Arts et Métiers - Amiens 25 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 26 Session 2008/2009

Architecture interne d'Android

Vue d'ensemble du système

fig 6: Architecture de la plate-forme Android

Conservatoire National des Arts et Métiers - Amiens 27 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 28 Session 2008/2009

Les optimisations de Dalvik

fig 7: Schéma des références internes d'un fichier DEX

Conservatoire National des Arts et Métiers - Amiens 29 Session 2008/2009

Ce format utilise un système complexe de références internes pour limiter au maximum la

Conservatoire National des Arts et Métiers - Amiens 30 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 31 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 32 Session 2008/2009

Conservatoire National des Arts et Métiers - Amiens 33 Session 2008/2009

ADC a: Annonce de l'Android Developer Challenge, http://www.google.fr/press/20071112_android-

ADC b: Gagnants de l'Android Developer Challenge,

Android b: Intents List: Invoking Google Applications on Android Devices,