Introduction
Le modèle de développement d'Android est très éloigné de celui d'un projet open source classique car Google développe le projet « behind the doors ». Il n'y a quasiment aucun dialogue avec les développeurs officiels contrairement à d'autres projets majeurs comme le noyau Linux, Yocto ou Buildroot. Il y a donc très peu de chances d'influencer réellement les choix techniques de Google par des contributions.
Google fournit cependant une « distribution » officielle des sources d'Android sous le nom AOSP (Android Open Source Project). AOSP constitue la référence pour les plate-formes Google (téléphones et tablettes NEXUS), la carte Pandaboard et bien entendu l'émulateur utilisé dans l'environnement de développement Android basé sur Eclipse (ADT = Android Development Tools). Les constructeurs de matériel compatible Android ont donc l'habitude de « dériver » les sources d'AOSP afin d'ajouter le support de leur matériel.
Dans ce court article nous allons décrire comment produire rapidement une image directement utilisable dans l'émulateur Android. Nous précisons qu'il n'est pas nécessaire d'installer l'outil ADT pour cela car l'émulateur sera également produit à partir des sources.
Préparation d'un système de développement
Le nombre de développeurs évoluant dans l'environnement AOSP (donc s'intéressant au fonctionnement interne d'Android) est bien entendu largement inférieur au nombre de développeurs d'applications. La documentation est donc beaucoup plus rare et se limite à deux ouvrages cités en bibliographie et les quelques pages d'introduction fournies par Google. Notons d'ailleurs que cette documentation n'est pas toujours strictement à jour...
La première étape consiste à mettre en place un système capable de produire l'image AOSP. Ce travail concerne des spécialistes et il est possible uniquement sous Linux et Mac OS X (mais pas sous Windows !). Le pré-requis Google sont encore plus stricts puisque la seule distribution Linux « supportée » est l'Ubuntu 12.04 LTS. Au niveau matériel, un CPU i5 ou supérieur est nécessaire ainsi qu'un minimum de 4 Go de mémoire vive. L'ensemble sources et fichiers compilés représente au final 40 Go sur le disque. L'utilisation d'une machine virtuelle n'est pas recommandé sauf en cas d'utilisation d'un système (très) haut de gamme !
Le lien http://source.android.com/source/initializing.html décrit la configuration du système et en particulier les paquets à installer sur l'environnement de développement. Dans notre cas nous utilisons une version 12.04.3. Nous pouvons installer un premier ensemble de paquets par la commande :
$ sudo apt-get update
$ sudo apt-get install git gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
L'installation du paquet libgl1-mesa-glx:i386 demandé par Google pose problème sur Ubuntu 12.04.3. Il est donc nécessaire d'installer le paquet libgl1-mesa-dri:i386.
$ sudo apt-get install libgl1-mesa-dri:i386
$ sudo apt-get install libgl1-mesa-glx:i386
La première installation supprime le bureau X.org (oups!). I lfaut donc le réinstaller dans la foulée par la commande :
$ sudo apt-get install ubuntu-desktop xserver-xorg
Outre cela, il faut bien entendu installer une version officielle de Java (version 6 ou supérieure fournie par Oracle).
Obtention des sources d'AOSP
Cette partie est décrite par Google sur http://source.android.com/source/downloading.html. Le contenu du projet représente environ 20 Go (!) et cela pour deux raisons principales :
-
En plus des sources, AOSP contient un grand nombre d'outils binaires dédiés aux cibles Linux et Mac OS X (voir le répertoire prebuilts).
-
Contrairement aux projets collaboratifs, AOSP fournit les sources des projets externes utilisés (voir le répertoire external).
- AOSP contient non-seulement le code source mais également un grand nombre de ressources nécessaires (images, son etc...)
Sachant qu'il est impossible de gérer correctement 20 Go de source dans un dépôt Git, AOSP est donc constitué de plusieurs centaines de dépôts Git que l'on peut manipuler grâce à l'outil repo fourni par Google. Ce dernier sera ajouté à un répertoire local cité dans la variable PATH de l'utilisateur.
$ mkdir ~/bin
$ export PATH=$PATH:~/bin
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
On peut alors créer un répertoire de travail et obtenir le fichier manifest qui contient la liste des dépôts à charger.
$ mkdir work && cd work
$ repo init -u https://android.googlesource.com/platform/manifest
Si l'on désire une branche de développement particulière, on peut utiliser l'option -b.
$ repo init -u https://android.googlesource.com/platform/manifest -b nom_branche
La liste des branches est disponible sur l'URL https://android.googlesource.com/platform/manifest. On peut alors obtenir les sources par la commande suivante, l'option -j permettant de lancer plusieurs téléchargements en parallèle, ce qui est fortement conseillé !
$ repo sync -j N
Sélection d'une cible et compilation
Contrairement à Yocto ou Buildroot, AOSP utilise un système de production assez rudimentaire uniquement basé sur des scripts (shell) et des fichiers Makefile. On charge les fonctions et variables d'environnement nécessaires par la commande :
$ source build/envsetup.sh
On peut alors sélectionner la cible par la fonction lunch.
$ lunch
You're building on Linux
Lunch menu... pick a combo:
1. aosp_arm-eng
2. aosp_x86-eng
3. aosp_mips-eng
4. aosp_x86_64-eng
5. vbox_x86-eng
6. full_panda-userdebug
7. aosp_flo-userdebug
8. aosp_deb-userdebug
9. full_tilapia-userdebug
10. full_grouper-userdebug
11. mini_mips-userdebug
12. mini_x86-userdebug
13. mini_armv7a_neon-userdebug
14. full_arndale-userdebug
15. full_mako-userdebug
16. full_maguro-userdebug
17. full_manta-userdebug
18. full_toro-userdebug
19. full_toroplus-userdebug
Which would you like? [aosp_arm-eng]
Le choix par défaut concerne l'émulateur utilisant une architecture ARM (nommée goldfish) qui est une excellente option pour un premier test ! A l'issue de la sélection on peut lancer la compilation par la commande :
$ make -j N
La valeur de N dépend bien entendu du nombre de cœurs disponibles sur la machine. Le temps de compilation sur un Dell XPS 13 équipé d'un i7 à 2GHz, 8 Go de RAM et disque SSD est de 80 mn en utilisant l'option -j 8.
Test du résultat
La totalité des binaires sont produits dans le répertoire out qui occupe dans notre cas 16 Go. Le répertoire out contient une arborescence dépendant de la cible choisie. Les principales images produites sont ramdisk.img (disque de démarrage), system.img (contenu principal du système Android) et userdata.img (données de l'utilisateur).
$ ls -l out/target/product/generic/
total 779508
-rw-rw-r-- 1 pierre pierre 7 Feb 13 16:00 android-info.txt
drwxrwxr-x 2 pierre pierre 4096 Feb 13 17:08 cache
-rw-r--r-- 1 pierre pierre 69206016 Feb 17 14:35 cache.img
-rw------- 1 pierre pierre 6 Feb 17 14:35 cache.img.lock
-rw-rw-r-- 1 pierre pierre 34074 Feb 13 15:59 clean_steps.mk
drwxrwxr-x 4 pierre pierre 4096 Feb 13 17:17 data
drwxrwxr-x 3 pierre pierre 4096 Feb 13 17:10 dex_bootjars
drwxrwxr-x 2 pierre pierre 4096 Feb 13 17:18 fake_packages
-rw-rw-r-- 1 pierre pierre 1313 Feb 17 14:35 hardware-qemu.ini
-rw------- 1 pierre pierre 6 Feb 17 14:35 hardware-qemu.ini.lock
-rw-rw-r-- 1 pierre pierre 52733 Feb 13 17:21 installed-files.txt
drwxrwxr-x 13 pierre pierre 4096 Feb 13 17:21 obj
-rw-rw-r-- 1 pierre pierre 585 Feb 13 15:59 previous_build_config.mk
-rw-rw-r-- 1 pierre pierre 243516 Feb 13 17:15 ramdisk.img
drwxrwxr-x 8 pierre pierre 4096 Feb 13 17:15 root
drwxrwxr-x 5 pierre pierre 4096 Feb 13 17:16 symbols
drwxrwxr-x 12 pierre pierre 4096 Feb 13 17:17 system
-rw-r--r-- 1 pierre pierre 576716800 Feb 13 17:21 system.img
-rw------- 1 pierre pierre 209715200 Feb 17 17:05 userdata-qemu.img
-rw------- 1 pierre pierre 6 Feb 17 14:35 userdata-qemu.img.lock
-rw-r--r-- 1 pierre pierre 209715200 Feb 13 17:17 userdata.img
On peut tester le résultat en utilisant la commande :
$ emulator &
qui conduit à l'affichage de l'image suivante :
Conclusion
Cet article nous a permis de produire en quelques commandes une image de test Android. Malgré les limites de l'émulateur, nous verrons dans d'autres articles qu'il permet de s'initier aux bases du développement « système » Android en utilisant l'outil ADB (Android Debug Bridge) ou bien le NDK (Native Development Kit) .
Bibliographie