Ce tutoriel vous permet de tester le développement du système d'exploitation Android pour la première fois.
Configurer pour le développement Android
Avant de télécharger et de compiler la branche manifeste android-latest-release
de la source Android, assurez-vous que votre matériel répond aux exigences nécessaires et que les logiciels requis sont correctement installés. Vous devez également connaître les termes suivants :
- Git
- Git est un système de contrôle des versions distribué, sans frais et Open Source. Android utilise Git pour les opérations locales telles que les branchements, les commits, les diffs et les modifications. Pour obtenir de l'aide sur Git, consultez la documentation Git.
- Repo
- Repo est un wrapper Python autour de Git qui simplifie l'exécution d'opérations complexes sur plusieurs dépôts Git. Repo ne remplace pas Git pour toutes les opérations de contrôle des versions. Il facilite uniquement les opérations Git complexes. Repo utilise des fichiers manifestes pour agréger les projets Git dans le superprojet Android.
- fichier manifeste
- Un fichier manifeste est un fichier XML qui spécifie l'emplacement des différents projets Git dans la source Android au sein d'une arborescence source AOSP.
Configuration matérielle requise pour Meet
Votre poste de travail de développement doit répondre aux exigences matérielles suivantes ou les dépasser :
Un système x86 64 bits.
Au moins 400 Go d'espace disque libre pour extraire et compiler le code (250 Go pour l'extraction et 150 Go pour la compilation).
Au moins 64 Go de RAM. Google utilise des machines à 72 cœurs avec 64 Go de RAM pour compiler Android. Avec cette configuration matérielle, la compilation complète d'Android prend environ 40 minutes, tandis que la compilation incrémentielle d'Android ne prend que quelques minutes. En revanche, il faut environ six heures pour une compilation complète avec une machine à six cœurs et 64 Go de RAM.
Respecter la configuration système requise
Votre poste de travail de développement doit exécuter n'importe quelle distribution Linux 64 bits avec GNU C Library (glibc) 2.17 ou version ultérieure.
Installer les packages requis
Pour installer les packages requis pour Ubuntu 18.04 ou version ultérieure, exécutez la commande suivante :
sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig
Installer les logiciels requis
Avant de pouvoir utiliser AOSP, vous devez installer OpenJDK, Make, Python 3 et Repo. La dernière branche de version d'Android est fournie avec des versions précompilées d'OpenJDK, Make et Python 3. Aucune étape d'installation supplémentaire n'est donc requise. La section suivante explique comment installer Repo.
Installer un dépôt
Pour installer Repo, procédez comme suit :
Téléchargez les informations actuelles sur le package :
sudo apt-get update
Exécutez la commande suivante pour installer le lanceur Repo :
sudo apt-get install repo
Le lanceur Repo fournit un script Python qui initialise un checkout et télécharge l'outil Repo complet.
Si l'opération réussit, passez à l'étape 4.
(Facultatif) Installez manuellement Repo à l'aide de la série de commandes suivante :
export REPO=$(mktemp /tmp/repo.XXXXXXXXX) curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65 curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo
Les trois premières commandes configurent un fichier temporaire, téléchargent Repo dans le fichier et vérifient que la clé fournie correspond à la clé requise. Si ces commandes aboutissent, la dernière installe le lanceur Repo.
Vérifiez la version du lanceur Repo :
repo version
Le résultat doit indiquer une version 2.4 ou ultérieure. Exemple :
repo launcher version 2.45
Télécharger la source Android
La source Android se trouve dans une collection de dépôts Git hébergés par Google. Chaque dépôt Git inclut l'intégralité de l'historique de la source Android, y compris les modifications apportées à la source et la date à laquelle elles ont été effectuées. Pour télécharger la source Android :
Accédez à votre répertoire d'accueil :
cd ~
Créez-y un sous-répertoire de travail local :
mkdir aosp
Accédez au répertoire :
cd aosp
Initialisez la branche de dernière version du code source du dépôt AOSP (
android-latest-release
) :repo init --partial-clone -b android-latest-release -u https://android.googlesource.com/platform/manifest
Saisissez ou acceptez vos identifiants Git (nom, adresse e-mail).
Synchronisez le code source :
repo sync -c -j8
Si vous rencontrez des problèmes lors du téléchargement, consultez Résoudre les problèmes de synchronisation.
Compiler le code
Pour compiler le code :
Dans votre répertoire de travail, exécutez le script
envsetup.sh
pour configurer votre environnement de compilation :source build/envsetup.sh
Spécifiez un type d'appareil cible à compiler avec la commande
lunch
. Une cible est une permutation d'appareils, telle qu'un modèle ou un facteur de forme spécifique. Spécifiez cette cible :lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug
Un résumé de votre environnement cible et de compilation devrait s'afficher :
============================================ PLATFORM_VERSION_CODENAME=Baklava PLATFORM_VERSION=Baklava TARGET_PRODUCT=aosp_cf_x86_64_only_phone TARGET_BUILD_VARIANT=userdebug TARGET_ARCH=x86_64 TARGET_ARCH_VARIANT=silvermont HOST_OS=linux HOST_OS_EXTRA=Linux-6.10.11-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete HOST_CROSS_OS=windows BUILD_ID=BP1A.250305.020 OUT_DIR=out ============================================
Créez la cible :
m
La première compilation peut prendre plusieurs heures. Les compilations suivantes prennent beaucoup moins de temps. Le résultat de votre compilation s'affiche dans $OUT_DIR
.
Lancer Cuttlefish
Cuttlefish est l'émulateur Android utilisé pour tester vos compilations.
Exécutez les commandes suivantes pour télécharger, compiler et installer les packages Debian de l'hôte :
sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
git clone https://github.com/google/android-cuttlefish
cd android-cuttlefish
for dir in base frontend; do pushd $dir # Install build dependencies sudo mk-build-deps -i dpkg-buildpackage -uc -us popd done
sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot
Le redémarrage déclenche l'installation de modules de noyau supplémentaires et applique les règles
udev
.Lancez Cuttlefish :
launch_cvd --daemon
Connectez-vous à l'appareil Cuttlefish en accédant à
https://localhost:8443
dans votre navigateur Web. Votre appareil virtuel Android s'affiche.
Effectuer une modification
Mettez à jour le code source en suivant cet exemple de liste des modifications.
À partir de la racine de votre extraction (répertoire
aosp/
), accédez au projet Gitframeworks/native
:cd frameworks/native
Démarrez un projet temporaire à l'aide de la commande suivante :
repo start <some-name> .
Utilisez votre éditeur pour modifier
SurfaceFlinger.cpp
à l'emplacement suivant :aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Localisez la ligne suivante :
void SurfaceFlinger::updateColorMatrixLocked() {
Ajoutez cette ligne au début de
updateColorMatrixLocked()
:mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f}, vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
Créez le code :
m
Mettez à jour la version sur l'appareil :
adb root
adb remount -R
adb root
adb sync
adb reboot
Vérifiez que la couleur de l'appareil sélectionné change, comme illustré à la figure 1.
Figure 1 : Apparence de l'écran après un changement de couleur réussi
Résoudre un problème lié à un test
Cette partie de l'atelier de programmation utilise un exemple de test qui se trouve dans l'arborescence source et qui échoue.
Pour exécuter, déboguer et corriger le test, suivez ces instructions :
Exécutez :
atest DevCodelabTest
Le test échoue.
Examinez la trace de la pile du test défaillant :
STACKTRACE: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:87) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertTrue(Assert.java:53) at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)
La dernière ligne de la trace de pile indique le test qui échoue (
testHelloWorld
). Ce test se trouve dans un fichier appeléDevCodelabTest.java
.Pour déterminer l'emplacement du test à corriger, ajoutez
WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/
à la dernière ligne de la trace de pile, jusqu'au nom du fichier de test inclus. Ainsi,android.test.example.devcodelab.DevCodelabTest
devientWORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
.Modifiez
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
et remplacezAssert.assertTrue(false)
parAssert.assertTrue(true)
.Exécutez à nouveau le test pour vérifier que vous avez résolu le problème :
atest DevCodelabTest
Importer votre code pour examen
Repo simplifie l'utilisation de Git en regroupant des commandes telles que git clone
pour qu'elles fonctionnent simultanément sur plusieurs dépôts Git (ou projets).
Pour examiner le code de vos projets dans Git, utilisez le système d'examen du code Gerrit sur le Web.
En supposant que vous avez apporté vos modifications dans le projet
frameworks/native
, exécutez ces commandes pour les importer :cd frameworks/native
repo start codelab .
git add .
git commit
Pour votre message de commit, saisissez ce qui suit :
Android codelab change Test: manual atest
Importez votre modification :
repo upload
Si l'opération réussit, un message semblable à celui-ci s'affiche :
Upload project frameworks/native/ to remote branch android16-release: branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700): ff46b36d android codelab change to https://android-review.googlesource.com/ (y/N)? y remote: Processing changes: refs: 1, new: 1, done remote: remote: SUCCESS remote: remote: https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW] remote: To https://android-review.googlesource.com/platform/frameworks/native * [new branch] codelab -> refs/for/android16-release
Afficher votre modification dans Gerrit
Pour afficher votre modification dans Gerrit, accédez au lien affiché dans le terminal. Le lien ressemble à ce qui suit :
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Annuler votre modification
Normalement, après les tests, et une fois que votre modification a été examinée et approuvée, vous l'envoyez dans Gerrit et la fusionnez dans le dépôt. Pour les besoins de cet atelier de programmation, revenez plutôt en arrière :
Dans Gerrit, cliquez sur Abandonner.
Abandonnez la branche temporaire associée dans le répertoire du projet
frameworks/native
(ou ses sous-répertoires) :repo abandon codelab .
Annulez les modifications que vous avez apportées au fichier de test. Comme vous n'avez pas exécuté
repo start
,git commit
nirepo upload
sur la modification du test, vous pouvez réinitialiser le fichier lui-même. En supposant que vous vous trouviez dansaosp/platform_testing directory
, utilisez la commande suivante pour réinitialiser le fichier :git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
L'atelier de programmation sur le développement de la plate-forme Android est terminé.
Obtenir de l'aide
Si vous rencontrez des erreurs au cours de cet atelier de programmation, signalez-les à l'aide du lien Issue Tracker en bas de n'importe quelle page. Envoyez vos questions au groupe android-building.
Saisissez ps -A | grep crosvm
pour vérifier si crosvm
est déjà en cours d'exécution. Si crossvm
est en cours d'exécution, saisissez stop_cvd || true
ou kill crosvm
avec le PID du processus.