Construire Android

Suivez ces instructions pour commencer à créer 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 le déjeuner pour sélectionner les cibles des appareils et les tapas pour créer des applications dégroupées, telles que l' application TV de référence .

Vous devez réémettre cette commande après chaque repo sync pour récupérer toute modification apportée à ce script. Notez que remplacer source par . (un seul point) enregistre quelques caractères et la forme courte 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, notamment 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 quelle 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 être lues par les invocations ultérieures 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 tous les débogages activés :

lunch aosp_arm-eng

S'il est exécuté sans argument, lunch vous invite à choisir une cible dans le menu, mais notez que le menu n'inclut pas toutes les possibilités. Consultez Sélection d’une version 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 approprié pour l’appareil sur lequel vous travaillez.

Toutes les cibles de build 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 éléments suivants.

Type de construction	Utiliser
utilisateur	Accès limité; adapté à la production
utilisateurdebug	Comme utilisateur mais avec un accès root et une capacité de débogage ; très proche des performances de production
fra	Configuration de développement avec un temps de construction plus rapide ; le plus adapté au développement quotidien

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 version userdebug idéale pour comprendre les performances et la puissance utilisées par la version. 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 maximiser les performances d'exécution. Sinon, la version eng est très 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 construction Android. Contrairement lunch , tapas ne nécessitent 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 garantir 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 build sélectionne automatiquement un nombre de tâches parallèles qu'il juge 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 version normale. Cette cible est ici car la cible par défaut nécessite un nom.
• all - m all construit tout ce que m droid fait, plus tout ce qui n'a pas la balise droid . Le serveur de build l'exécute pour s'assurer que tout ce qui se trouve dans l'arborescence et contient un fichier Android.mk est construit.
• m - Exécute les builds depuis le haut de l'arborescence. Ceci est utile car vous pouvez exécuter make à partir de sous-répertoires. Si la variable d'environnement TOP est définie, 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'intégralité de l'arborescence 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 clean supprime tous les fichiers de sortie et intermédiaires de cette configuration. C'est la même chose que rm -rf out/ .

Exécutez m help pour voir quelles autres pseudo-cibles m fournit.

Exécuter la build

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 build 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 binaires propriétaires, sinon votre build ne démarrera pas correctement sur votre matériel cible. Parfois, la source peut avoir différents 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 binaires propriétaires .

Flasher avec fastboot

Pour flasher un périphérique, utilisez fastboot , qui doit être inclus dans votre chemin après une build réussie. Voir Flasher un appareil pour obtenir des 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 digitale de la version. L'empreinte digitale de build est une chaîne unique et lisible par l'homme contenant des informations sur le fabricant émises pour chaque build. Voir la description FINGERPRINT dans la section Paramètres de construction du document de définition de compatibilité Android (CDD) pour la syntaxe précise.

L’empreinte digitale de build représente une implémentation et une révision Android particulières. Cette clé unique permet aux développeurs d'applications et autres de signaler des problèmes avec des versions spécifiques du micrologiciel. Voir Signalement de 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 d'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 d'utilisation des fonctionnalités 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 Ajout d'un nouvel appareil pour obtenir des instructions sur la création d'un tout nouvel appareil Android.

Dépannage des erreurs de build courantes

Mauvaise version de Java

Si vous essayez de créer une version d'Android qui n'est pas cohérente avec votre version de Java, make -la 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 comme 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 dans 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 supprimer avec adb kill-server . Cette commande provoque le redémarrage d'ADB avec la nouvelle configuration.