Construire Android

Suivez ces instructions pour commencer à construire Android.

Mise en place de l'environnement

Initialisez l'environnement avec le script envsetup.sh :

source build/envsetup.sh

ou

. build/envsetup.sh

Consultez le script sur platform/build/envsetup.sh pour obtenir des descriptions des commandes associées, y compris lunch pour sélectionner des cibles d'appareils et tapas pour créer des applications dégroupées, telles que l' application TV de référence .

Vous devez relancer cette commande après chaque repo sync pour récupérer les modifications apportées à ce script. Notez que le remplacement source par . (un seul point) enregistre quelques caractères, et la forme abrégée est plus couramment utilisée dans la documentation.

Le script envsetup.sh importe plusieurs commandes qui vous permettent de travailler avec le code source Android, y compris les commandes utilisées dans cet exercice.

Pour voir la liste complète des commandes disponibles, exécutez :

hmm

Choisir une cible

déjeuner

Choisissez la cible à construire avec lunch . lunch product_name - build_variant sélectionne product_name comme produit à construire et build_variant comme variante à construire, et stocke ces sélections dans l'environnement pour qu'elles soient lues par les appels ultérieurs de m et d'autres commandes similaires.

La configuration exacte peut être passée en argument. Par exemple, la commande suivante fait référence à une version complète de l'émulateur, avec tout le débogage activé :

lunch aosp_arm-eng

S'il est exécuté sans arguments, lunch vous invite à choisir une cible dans le menu, mais notez que le menu n'inclut pas toutes les possibilités. Voir Sélection d'une build d'appareil pour les configurations de build de tous les appareils pris en charge dans AOSP, ou discutez avec les membres de votre équipe du déjeuner correct pour l'appareil sur lequel vous travaillez.

Toutes les cibles de construction prennent la forme BUILD-BUILDTYPE , où BUILD est un nom de code faisant référence à la combinaison de fonctionnalités particulière. BUILDTYPE est l'un des suivants.

Type de construction	Utiliser
utilisateur	Accès limité; adapté à la fabrication
débogage utilisateur	Comme utilisateur mais avec un accès root et une capacité de débogage ; préféré pour le débogage
fra	Configuration de développement avec des outils de débogage supplémentaires

La version userdebug doit se comporter de la même manière que la version user , avec la possibilité d'activer un débogage supplémentaire qui viole normalement le modèle de sécurité de la plate-forme. Cela rend la construction userdebug bonne pour les tests utilisateur avec de plus grandes capacités de diagnostic. Lors du développement avec la version userdebug , suivez les directives userdebug .

La version eng donne la priorité à la productivité de l'ingénierie pour les ingénieurs qui travaillent sur la plate-forme. La version eng désactive diverses optimisations utilisées pour offrir une bonne expérience utilisateur. Sinon, la version eng a un comportement similaire aux versions user et userdebug afin que les développeurs de périphériques puissent voir comment le code se comporte dans ces environnements.

Pour voir les paramètres actuels du déjeuner, exécutez la commande :

echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"

Pour plus d'informations sur la création et l'exécution sur du matériel réel, consultez Flashing Devices .

tapas

La commande tapas configure la construction d'applications dégroupées. Il sélectionne les applications individuelles à créer par le système de génération Android. Contrairement lunch , tapas ne demandent pas la construction d'images pour un appareil.

Exécutez tapas help pour plus d'informations sur la commande.

Construire le code

Cette section est un résumé rapide pour s'assurer que la configuration est terminée.

Construisez tout avec m . m peut gérer des tâches parallèles avec un argument -jN . Si vous ne fournissez pas d'argument -j , le système de construction sélectionne automatiquement un nombre de tâches parallèles qu'il pense être optimal pour votre système.

m

Comme expliqué ci-dessus, vous pouvez créer des modules spécifiques au lieu de l'image complète du périphérique en répertoriant leurs noms dans votre ligne de commande m . De plus, m fournit des pseudo-cibles à des fins spéciales. Certains exemples sont:

• droid - m droid est la construction normale. Cette cible est ici car la cible par défaut nécessite un nom.
• all - m all construit tout ce que fait m droid , plus tout ce qui n'a pas la balise droid . Le serveur de génération l'exécute pour s'assurer que tout ce qui se trouve dans l'arborescence et contient un fichier Android.mk est généré.
• m - Exécute les builds à partir du haut de l'arborescence. Ceci est utile car vous pouvez exécuter make à partir de sous-répertoires. Si vous avez défini la variable d'environnement TOP , elle l'utilise. Si vous ne le faites pas, il recherche l'arborescence à partir du répertoire courant, en essayant de trouver le sommet de l'arborescence. Vous pouvez soit créer l'arborescence complète du code source en exécutant m sans arguments, soit créer des cibles spécifiques en spécifiant leurs noms.
• mma - Construit tous les modules du répertoire courant et leurs dépendances.
• mmma - Construit tous les modules dans les répertoires fournis et leurs dépendances.
• croot - cd au sommet de l'arbre.
• clean -m m clean supprime tous les fichiers de sortie et intermédiaires pour cette configuration. C'est la même chose que rm -rf out/ .

Exécutez m help pour voir ce que d'autres pseudotargets m fournissent.

Exécution de la construction

Vous pouvez soit exécuter votre build sur un émulateur, soit le flasher sur un appareil. Étant donné que vous avez déjà sélectionné votre cible de construction avec lunch , il est peu probable qu'elle s'exécute sur une cible différente de celle pour laquelle elle a été conçue.

Remarque : N'oubliez pas d'obtenir des fichiers binaires propriétaires, sinon votre build ne démarrera pas correctement sur votre matériel cible. Parfois, la source peut avoir différents fichiers binaires pour différentes versions et branches. Si vous obtenez des blobs binaires à ce stade, vous devez les décompresser, m installclean et reconstruire. Pour plus d'informations sur ce processus, consultez Obtention de fichiers binaires propriétaires .

Clignotant avec fastboot

Pour flasher un périphérique, utilisez fastboot , qui doit être inclus dans votre chemin après une construction réussie. Voir Flasher un appareil pour les instructions.

Émuler un appareil Android

L'émulateur est automatiquement ajouté à votre chemin par le processus de construction. Pour exécuter l'émulateur, tapez :

emulator

Comprendre les empreintes digitales de build

Pour suivre et signaler les problèmes liés à une version Android particulière, il est important de comprendre l'empreinte de la version. L'empreinte digitale de build est une chaîne unique, lisible par l'homme, contenant des informations sur le fabricant émises pour chaque build. Voir la description FINGERPRINT dans la section Build Parameters du document Android Compatibility Definition Document (CDD) pour la syntaxe précise.

L'empreinte de construction représente une implémentation et une révision Android particulières. Cette clé unique permet aux développeurs d'applications et à d'autres de signaler des problèmes avec des versions de micrologiciel spécifiques. Voir Signaler des bogues pour le processus de signalement des problèmes Android.

Une empreinte digitale de build encapsule tous les détails d'implémentation d'Android :

• API : Android et natives, ainsi que les comportements des API logicielles
• API de base et certains comportements de l'interface utilisateur du système
• Exigences de compatibilité et de sécurité définies dans le CDD
• Spécifications du produit et paramètres de fonctionnalité d'utilisation utilisés par les applications pour cibler les appareils répondant aux exigences attendues
• Implémentations de composants matériels et logiciels

Consultez le CDD pour plus de détails et Ajouter un nouvel appareil pour obtenir des instructions sur la création d'un tout nouvel appareil Android.

Dépannage des erreurs de compilation courantes

Mauvaise version de Java

Si vous essayez de créer une version d'Android qui n'est pas compatible avec votre version de Java, make des abandons avec un message tel que :

************************************************************
You are attempting to build with the incorrect version
of java.

Your version is: WRONG_VERSION.
The correct version is: RIGHT_VERSION.

Please follow the machine setup instructions at
    https://source.android.com/source/initializing.html
************************************************************

Voici les causes probables et les solutions :

• Échec de l'installation du JDK correct tel que spécifié dans les exigences du JDK . Assurez-vous d'avoir suivi les étapes décrites dans Configuration de l'environnement et Choix d'une cible .
• Un autre JDK précédemment installé apparaissant dans votre chemin. Ajoutez le JDK correct au début de votre chemin ou supprimez le JDK problématique.

Aucune autorisation USB

Par défaut sur la plupart des systèmes Linux, les utilisateurs non privilégiés ne peuvent pas accéder aux ports USB. Si vous voyez une erreur d'autorisation refusée, suivez les instructions de la section Configuration de l'accès USB .

Si ADB était déjà en cours d'exécution et ne peut pas se connecter à l'appareil après avoir configuré ces règles, vous pouvez le tuer avec adb kill-server . Cette commande provoque le redémarrage d'ADB avec la nouvelle configuration.