Configurer Le Build Gradle
Chaque projet contient une série de fichiers Gradle utilisés pour définir votre configuration de construction, comprenant:
Fichier settings.gradle de portée du projet qui définit les modules à inclure lors de la construction de votre application. Fichier build.gradle au niveau du projet dans lequel les référentiels et les dépendances de Gradle lui-même sont spécifiés, ainsi que tous les référentiels et dépendances communs à tous vos modules.
Fichier build.gradle de niveau module utilisé pour configurer les paramètres de construction de votre application,y compris les dépendances, les versions minimales et ciblées de la plate-forme, les informations de version de votre application, ainsi que plusieurs types de construction et types de produits. Pour la plupart des applications, il n’est pas nécessaire de modifier les paramètres par défaut et les fichiers Gradle de construction à l’échelle du projet. Le fichier de paramètres par défaut spécifie un seul module (votre application). Le fichier de construction Gradle de niveau supérieur inclut JCenter et Google en tant que référentiels permettant à Gradle de rechercher des dépendances, ainsi que le plug-in Android pour Gradle en tant que dépendance de projet. En revanche, vous devrez probablement apporter des modifications continues au fichier de construction Gradle au niveau du module, ce qui vous permettra de définir une ou plusieurs configurations de construction pour votre application, notamment les dépendances de nouvelles bibliothèques de support, les changements de numéros de version et les versions de plate-forme et de SDK. vous soutenez.
Fichier Settings Gradle
Le fichier settings.gradle se trouve dans le dossier racine de votre projet et permet d'indiquer à Gradle les modules à inclure lors de la création de votre application. Par défaut, votre module d'application unique est inclus:include ': app'Si votre projet se développe pour utiliser plusieurs modules, vous devrez les ajouter ici.
Fichier Gradle Build du Projet
Le fichier build.gradle de niveau supérieur relatif au projet se trouve dans le répertoire du projet racine. Il vous permet de spécifier des dépendances (et les référentiels utilisés par Gradle pour rechercher puis télécharger ces dépendances) qui s'appliquent au projet et à tous ses modules.Le noeud buildscript est utilisé pour indiquer les référentiels et les dépendances utilisés par Gradle lui-même, mais pas pour votre application.Par exemple, le bloc des dépendances par défaut inclut le plug-in Android pour Gradle, car il est nécessaire à Gradle pour créer des modules d'application Android, et le bloc des référentiels préconfigure JCenter et Google en tant que référentiels que Gradle doit utiliser pour le rechercher:
buildscript { repositories { google() jcenter()
} dependencies {
classpath 'com.android.tools.build:gradle:3.1.3'
}
}
Notez que ce n'est pas là que vous indiquez les dépendances de votre application. ils appartiennent au fichier build.gradle du module correspondant à votre module d'application, comme décrit dans la section suivante.Utilisez le bloc allprojects pour spécifier les référentiels et les dépendances utilisés par tous les modules de votre projet. Toutefois, pour les projets comportant un seul module, il est courant d’inclure ses dépendances dans le fichier build.gradle au niveau du module.Pour les nouveaux projets, Android Studio ajoute JCenter et Google comme référentiels par défaut.
allprojects { repositories { google() jcenter()
}
}
Android Studio définit également une nouvelle tâche de projet, à savoir nettoyer, qui supprime le contenu du dossier de construction de votre projet:
task clean(type: Delete) { delete rootProject.buildDir }
Module Gradle Build Files
Le fichier build.gradle au niveau du module, situé dans chacun des répertoires de modules de votre projet, permet de configurer les paramètres de construction du module correspondant, notamment les dépendances requises, les versions minimale et ciblée de la plate-forme, les informations de version de votre application et différents types de construction et produits. les saveurs.La première ligne de la configuration de construction applique le plug-in Android pour Gradle à cette construction, ce qui permet d'utiliser le bloc Android pour spécifier des options de construction spécifiques à Android:
apply plugin: 'com.android.application'
Au niveau supérieur du bloc Android, vous spécifiez les options de configuration de l'application Android, telles que la version du SDK avec laquelle compiler votre application. Veillez à mettre à jour ces valeurs lorsque vous téléchargez une nouvelle version du SDK:
android { compileSdkVersion 27
defaultConfig {...} buildTypes {...} productFlavors {...} splits {...} }
Configuration par Défaut
Le bloc defaultConfig (dans le bloc Android) spécifie les paramètres par défaut qui seront partagés entre toutes les variantes de produits:
defaultConfig { applicationId 'com.professionalandroid.apps.helloworld'
minSdkVersion 16 targetSdkVersion 27
versionCode 1 versionName "1.0" }
Comme indiqué dans le code précédent, vous devez spécifier le: applicationId: pour fournir un «nom de package» unique qui sera utilisé pour identifier l'APK construit pour la publication et la distribution. Par défaut et selon les besoins, cela devrait utiliser le même nom de package que celui défini dans votre manifeste et vos classes d'application. minSdkVersion: pour définir la version la plus basse de la plate-forme Android avec laquelle votre application est compatible. Cela vous permet d’indiquer la version la plus récente de la plate-forme Android sur laquelle votre application peut être installée et exécutée. Le cadre Android empêchera les utilisateurs d’installer votre application si le niveau de l’API du système est inférieur à cette valeur. Si vous ne spécifiez pas de version minimale, la valeur par défaut est 1 et sera disponible sur tous les périphériques, ce qui provoquera un blocage si des API non disponibles sont appelées. targetSdkVersion: pour spécifier la version de la plateforme Android par rapport à laquelle vous avez effectué votre développement et vos tests. La définition d'un kit de développement logiciel cible indique au système qu'il n'est pas nécessaire d'appliquer des modifications de compatibilité ascendante ou descendante pour prendre en charge cette plate-forme particulière. Pour tirer parti des améliorations les plus récentes de l'interface utilisateur de la plate-forme, il est recommandé de mettre à jour le kit SDK cible de votre application vers la dernière version de la plate-forme après l'avoir confirmé, même si vous n'utilisez pas de nouvelles API. versionCode: pour définir la version actuelle de l'application en tant qu'entier qui augmente avec chaque itération de version que vous publiez. versionName - Pour spécifier un identifiant de version publique qui sera affiché aux utilisateurs. testInstrumentationRunner - Pour spécifier un programme d'exécution de test à utiliser. Par défaut, l'instrumentation AndroidJUnitRunner de la bibliothèque de support Android est incluse et vous permet d'exécuter des tests JUnit3 et JUnit4 sur votre application.
Remarque
Certaines de ces valeurs de configuration de construction peuvent également être spécifiées dans le manifeste Android. Lorsque votre application est créée, Gradle fusionne ces valeurs avec celles fournies par votre manifeste, les valeurs de construction de Gradle étant prioritaires. Pour éviter toute confusion, la meilleure pratique consiste à spécifier uniquement ces valeurs dans les fichiers de construction de Gradle.Un cas particulier est le nom du package de votre application. Vous devez toujours inclure un attribut de package à l'élément racine de votre fichier manifeste. Le nom de package défini ici sert également un objectif secondaire, à savoir le nom de package utilisé pour les classes de votre application, y compris la classe de ressources R.Comme vous le verrez plus tard, Gradle permet de créer facilement plusieurs variantes (ou «variantes») de votre application (par exemple, des variantes «gratuites» et «pro» ou «alpha», «bêta» et «libérées»). Chaque version doit avoir un nom de package différent, mais pour utiliser une base de code unique, le nom du package de vos classes doit être cohérent.Par conséquent, le nom de package utilisé dans votre manifeste est utilisé pour votre classe R et pour résoudre toute ambiguïté concernant le nom de classe dans votre application, mais l'ID d'application indiqué dans vos fichiers de construction Gradle est utilisé comme nom de package lors de la création de leurs fichiers associés. APKs.
Build Types
Le bloc buildTypes est utilisé pour définir plusieurs types de construction différents, généralement le débogage et la publication. Lorsque vous créez un nouveau module, Android Studio crée automatiquement un type de génération de version pour vous. Dans la plupart des cas, vous n'avez pas besoin de le modifier.Notez que le type de construction de débogage n'a pas besoin d'être explicitement inclus dans le fichier de construction de Gradle, mais par défaut, Android Studio configurera vos générations de débogage avec la valeur true de debuggable. Par conséquent, ces versions sont signées avec le magasin de clés de débogage et vous pouvez les déboguer sur des appareils Android verrouillés et signés.Le type de construction de la version par défaut (indiqué dans le code suivant) applique les paramètres de Proguard pour réduire et obscurcir le code compilé, et n'utilise pas de clé de signature par défaut:
buildTypes { release { minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
}
Dimensions des arômes et des arômes du produit
Les blocs flavourDimensions et productFlavors sont des nœuds facultatifs, non inclus par défaut, qui vous permettent de remplacer toutes les valeurs que vous avez définies dans le bloc defaultConfig afin de prendre en charge différentes versions (saveurs) de votre application utilisant le même code. Chaque type de produit doit spécifier son propre identifiant d'application unique afin que chacun puisse être distribué et installé indépendamment:
productFlavors { freeversion {
applicationId 'com.professionalandroid.apps.helloworld.free'
versionName "1.0 Free" }
paidversion {
applicationId 'com.professionalandroid.apps.helloworld.paid'
versionName "1.0 Full"
}
}
Les dimensions des arômes vous permettent de créer des groupes d’arômes de produits pouvant être combinés pour créer une variante de construction finale. Cela vous permet de spécifier des modifications de construction selon plusieurs dimensions (par exemple, des modifications basées sur des versions gratuites ou payantes), ainsi que des modifications basées sur le niveau minimal d'API:
flavorDimensions "apilevel", "paylevel"
productFlavors { freeversion {
applicationId 'com.professionalandroid.apps.helloworld.free' versionName "1.0 Free" dimension "paylevel" }
paidversion {
applicationId 'com.professionalandroid.apps.helloworld.paid' versionName "1.0 Full" dimension "paylevel" }
minApi24 { dimension "apilevel" minSdkVersion 24
versionCode 24000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi24" }
minApi23 { dimension "apilevel" minSdkVersion 16
versionCode 16000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi23"
}
}
}
Lors de la création de votre application, Gradle combinera les différentes versions du produit le long de chaque dimension, ainsi qu’une configuration de type de construction, pour créer la variante de construction finale. Gradle ne combine pas les arômes de produits appartenant à la même dimension.Notez que Gradle détermine la priorité des dimensions de la saveur en fonction de l'ordre dans lequel elles sont spécifiées, la première dimension remplaçant les valeurs affectées le long de la deuxième dimension, etc.Depuis Gradle 3.0.0, vous devez définir au moins une dimension de produit afin de définir les variantes. Chaque saveur doit avoir une dimension de produit associée. Toutefois, si vous ne définissez qu'une seule dimension, elle sera utilisée par défaut par chaque saveur.Vous pouvez détecter la version actuelle du produit au moment de l'exécution et modifier votre comportement en conséquence, à l'aide de l'extrait de code suivant:
if (BuildConfig.FLAVOR == "orangesherbert") {
// Do groovy things
} else {
// Enable paid features
}
Vous pouvez également créer un nouvel ensemble de classes et de ressources (un nouvel ensemble source) que votre application pourra utiliser pour chaque type, en créant une structure de répertoires supplémentaire parallèle au chemin source "principal" par défaut.Pour les classes, vous devez créer les dossiers manuellement, tandis que pour les ressources, vous pouvez choisir le jeu source auquel une nouvelle ressource doit appartenir, comme indiqué dans la boîte de dialogue Nouveau fichier de ressources de la figure 4-2.
Remarque
Lors de la création de votre application, Gradle fusionnera la source et les ressources Java de votre ensemble de sources d'arômes avec l'ensemble de sources «principal» en utilisant le même nom de package (tel que défini dans votre manifeste). Par conséquent, vous ne pouvez pas utiliser un nom de classe dans une version qui duplique un nom de classe dans le jeu source principal. Dans Android Studio, vous pouvez sélectionner la construction que vous souhaitez créer et exécuter à l’aide de l’élément de menu Construire ➪ Choisir la variante de construction et en le sélectionnant dans le menu déroulant affiché dans la fenêtre Variante de construction.
Splits
Vous pouvez utiliser le bloc de fractionnement facultatif pour configurer différentes versions de l'APK contenant uniquement le code et les ressources pour chaque densité d'écran ou ABI prise en charge.Il est généralement préférable de créer et de distribuer un fichier APK unique pour prendre en charge tous vos appareils cibles. Toutefois, dans certains cas (notamment les jeux), cela peut entraîner une taille de fichier APK de taille prohibitive.La création et la distribution de fichiers APK divisés n'entrent pas dans le cadre de ce livre, mais vous pouvez trouver plus de détails sur la configuration des fichiers APK à l'adresse developer.android.com/studio/build/configure-apk-splits .html.
Les dépendances
Le bloc de dépendances spécifie les dépendances requises pour construire votre application.Par défaut, un nouveau projet inclut une dépendance binaire locale qui indique à Gradle d'inclure tous les fichiers JAR situés dans le dossier apps / libs, des dépendances binaires distantes sur la bibliothèque de support Android et JUnit, ainsi qu'une dépendance sur la bibliothèque de tests Android Espresso:
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar']) implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support.constraint:constraint-layout:1.1.2'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2' }