Dans la mesure du possible, il est conseillé de ne compiler qu'un seul APK pour prendre en charge tous vos appareils cibles. Cependant, cela peut générer un APK très volumineux, en raison des fichiers nécessaires pour prendre en charge plusieurs interfaces binaires d'application (ABI). Pour réduire la taille de votre APK, une méthode consiste à créer plusieurs APK contenant des fichiers pour des ABI spécifiques.
Gradle peut créer des APK distincts qui ne contiennent que le code et les ressources spécifiques à chaque ABI. Cette page vous explique comment configurer votre build afin de générer plusieurs APK. Si vous devez créer différentes versions de votre application qui ne sont pas basées sur l'ABI, utilisez plutôt des variantes de compilation.
Configurer votre build pour plusieurs APK
Pour configurer votre build pour plusieurs APK, ajoutez un bloc splits à votre fichier build.gradle au niveau du module. Dans le bloc splits, fournissez un bloc abi qui indique comment vous souhaitez que Gradle génère des APK par ABI.
Configurer plusieurs APK pour les ABI
Pour créer des APK distincts pour différentes ABI, ajoutez un bloc abi dans votre bloc splits. Dans votre bloc abi, fournissez la liste des ABI que vous avez choisies.
Les options Gradle DSL ci-dessous permettent de configurer plusieurs APK par ABI :
enablepour Groovy ouisEnablepour le script Kotlin- Si vous définissez cet élément sur
true, Gradle génère plusieurs APK en fonction des ABI définies. La valeur par défaut estfalse. exclude- Spécifie une liste d'ABI séparées par une virgule pour lesquelles vous ne souhaitez pas que Gradle génère des APK distincts. Utilisez
excludesi vous souhaitez générer des APK pour la plupart des ABI, mais que vous devez en exclure quelques-unes qui ne sont pas prises en charge par votre application. reset()Efface la liste par défaut des ABI. N'utilisez cette option qu'avec l'élément
includepour spécifier les ABI que vous souhaitez ajouter.L'extrait de code suivant définit la liste des ABI sur
x86etx86_64en appelantreset()pour effacer la liste, puis en utilisantinclude:reset() // Clears the default list from all ABIs to no ABIs. include "x86", "x86_64" // Specifies the two ABIs we want to generate APKs for.includeSpécifie une liste d'ABI séparées par une virgule pour lesquelles vous souhaitez que Gradle génère des APK. N'utilisez cette option qu'avec l'élément
reset()pour spécifier une liste exacte d'ABI.universalApkpour Groovy ouisUniversalApkpour le script KotlinSi la valeur est
true, Gradle génère un APK universel en plus des APK par ABI. Un APK universel contient le code et les ressources de toutes les ABI dans un seul APK. La valeur par défaut estfalse.
L'exemple suivant génère un APK distinct pour chaque ABI : x86 et x86_64.
Pour ce faire, utilisez l'option reset() pour commencer par une liste vide d'ABI, suivie de include avec une liste d'ABI qui recevront chacune un APK.
Groovy
android { ... splits { // Configures multiple APKs based on ABI. abi { // Enables building multiple APKs per ABI. enable true // By default all ABIs are included, so use reset() and include to specify that you only // want APKs for x86 and x86_64. // Resets the list of ABIs for Gradle to create APKs for to none. reset() // Specifies a list of ABIs for Gradle to create APKs for. include "x86", "x86_64" // Specifies that you don't want to also generate a universal APK that includes all ABIs. universalApk false } } }
Kotlin
android { ... splits { // Configures multiple APKs based on ABI. abi { // Enables building multiple APKs per ABI. isEnable = true // By default all ABIs are included, so use reset() and include to specify that you only // want APKs for x86 and x86_64. // Resets the list of ABIs for Gradle to create APKs for to none. reset() // Specifies a list of ABIs for Gradle to create APKs for. include("x86", "x86_64") // Specifies that you don't want to also generate a universal APK that includes all ABIs. isUniversalApk = false } } }
Pour obtenir la liste des ABI compatibles, consultez ABI compatibles.
Projets sans code natif/C++
Pour les projets sans code natif/C++, le panneau Build Variants (Variantes de compilation) présente deux colonnes : Module et Active Build Variant (Variante de compilation active), comme illustré dans la figure 1.
La valeur Active Build Variant (Variante de compilation active) du module détermine la variante de compilation déployée et visible dans l'éditeur. Pour passer d'une variante à l'autre, cliquez sur la cellule Active Build Variant (Variante de compilation active) d'un module et sélectionnez la variante souhaitée dans le champ de liste.
Projets avec code natif/C++
Pour les projets avec du code natif/C++, le panneau Build Variants (Variantes de compilation) présente trois colonnes : Module, Active Build Variant (Variante de compilation active) et Active ABI (ABI active), comme illustré dans la figure 2.
La valeur Active Build Variant (Variante de compilation active) du module détermine la variante de compilation déployée et visible dans l'éditeur. Pour les modules natifs, la valeur Active ABI (ABI active) détermine l'ABI qui sera utilisée par l'éditeur, mais n'a aucune incidence sur ce qui est déployé.
Pour modifier le type de compilation ou l'ABI :
- Cliquez sur la cellule de la colonne Active Build Variant (Variante de compilation active) ou Active ABI (ABI active).
- Sélectionnez la variante ou l'ABI de votre choix dans le champ de liste. Une nouvelle synchronisation est effectuée automatiquement.
Si vous modifiez l'une des colonnes d'un module d'application ou de bibliothèque, la modification est appliquée à toutes les lignes dépendantes.
Configurer la gestion des versions
Par défaut, lorsque Gradle génère plusieurs APK, chacun d'eux dispose des mêmes informations de version, comme indiqué dans le fichier build.gradle ou build.gradle.kts au niveau du module. Étant donné que le Google Play Store n'autorise pas l'utilisation de plusieurs APK disposant des mêmes informations de version pour la même application, vous devez vous assurer que chaque APK possède son propre versionCode unique avant de les importer sur le Play Store.
Vous pouvez configurer votre fichier build.gradle au niveau du module pour remplacer le versionCode de chaque APK. En créant un mappage qui attribue une valeur numérique unique à chaque ABI pour laquelle vous configurez plusieurs APK, vous pouvez remplacer le code de version de sortie ayant une valeur combinant le code de version défini dans le bloc defaultConfig ou productFlavors par la valeur numérique attribuée à l'ABI.
Dans l'exemple suivant, l'APK de l'ABI x86 reçoit le versionCode 2004 et l'ABI x86_64 reçoit le versionCode 3004.
L'attribution de codes de version avec des incréments importants, tels que 1 000, vous permet d'attribuer, par la suite, des codes de version uniques si votre application doit être mise à jour. Par exemple, si defaultConfig.versionCode effectue une itération sur 5 lors d'une mise à jour ultérieure, Gradle attribue le versionCode 2005 à l'APK x86 et 3005 à l'APK x86_64.
Groovy
android { ... defaultConfig { ... versionCode 4 } splits { ... } } // Map for the version code that gives each ABI a value. ext.abiCodes = ['armeabi-v7a':1, x86:2, x86_64:3] import com.android.build.OutputFile // For each APK output variant, override versionCode with a combination of // ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode // is equal to defaultConfig.versionCode. If you configure product flavors that // define their own versionCode, variant.versionCode uses that value instead. android.applicationVariants.all { variant -> // Assigns a different version code for each output APK // other than the universal APK. variant.outputs.each { output -> // Stores the value of ext.abiCodes that is associated with the ABI for this variant. def baseAbiVersionCode = // Determines the ABI for this variant and returns the mapped value. project.ext.abiCodes.get(output.getFilter(OutputFile.ABI)) // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes, // the following code doesn't override the version code for universal APKs. // However, because you want universal APKs to have the lowest version code, // this outcome is desirable. if (baseAbiVersionCode != null) { // Assigns the new version code to versionCodeOverride, which changes the // version code for only the output APK, not for the variant itself. Skipping // this step causes Gradle to use the value of variant.versionCode for the APK. output.versionCodeOverride = baseAbiVersionCode * 1000 + variant.versionCode } } }
Kotlin
android { ... defaultConfig { ... versionCode = 4 } splits { ... } } // Map for the version code that gives each ABI a value. val abiCodes = mapOf("armeabi-v7a" to 1, "x86" to 2, "x86_64" to 3) import com.android.build.api.variant.FilterConfiguration.FilterType.* // For each APK output variant, override versionCode with a combination of // abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode // is equal to defaultConfig.versionCode. If you configure product flavors that // define their own versionCode, variant.versionCode uses that value instead. androidComponents { onVariants { variant -> // Assigns a different version code for each output APK // other than the universal APK. variant.outputs.forEach { output -> val name = output.filters.find { it.filterType == ABI }?.identifier // Stores the value of abiCodes that is associated with the ABI for this variant. val baseAbiCode = abiCodes[name] // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes, // the following code doesn't override the version code for universal APKs. // However, because you want universal APKs to have the lowest version code, // this outcome is desirable. if (baseAbiCode != null) { // Assigns the new version code to output.versionCode, which changes the version code // for only the output APK, not for the variant itself. output.versionCode.set(baseAbiCode * 1000 + (output.versionCode.get() ?: 0)) } } } }
Vous trouverez, à la section Attribuer des codes de version, des exemples d'autres schémas de code de version.
Compiler plusieurs APK
Une fois que vous avez configuré votre fichier build.gradle ou build.gradle.kts au niveau du module pour compiler plusieurs APK, cliquez sur Build > Build APK (Compiler > Compiler un APK) pour compiler tous les APK du module sélectionné dans le volet Project (Projet). Gradle crée les APK pour chaque ABI dans le répertoire build/outputs/apk/ du projet.
Gradle crée un APK pour chaque ABI pour laquelle vous configurez plusieurs APK.
Par exemple, l'extrait de code build.gradle suivant permet de compiler plusieurs APK pour les ABI x86 et x86_64 :
Groovy
... splits { abi { enable true reset() include "x86", "x86_64" } }
Kotlin
... splits { abi { isEnable = true reset() include("x86", "x86_64") } }
La sortie de l'exemple de configuration comprend les quatre APK suivants :
app-X86-release.apk: contient du code et des ressources pour l'ABIx86.app-X86_64-release.apk: contient du code et des ressources pour l'ABIx86_64.
Lorsque vous compilez plusieurs APK en fonction de l'ABI, Gradle génère uniquement un APK qui inclut le code et les ressources de toutes les ABI si vous spécifiez universalApk true dans le bloc splits.abi de votre fichier build.gradle (pour Groovy) ou isUniversalApk = true dans le bloc splits.abi de votre fichier build.gradle.kts (pour le script Kotlin).
Format du nom de fichier APK
Lorsque vous compilez plusieurs APK, Gradle génère des noms de fichiers APK selon le schéma suivant :
modulename-ABI-buildvariant.apk
Les composants du schéma sont les suivants :
modulename- Spécifie le nom du module en cours de compilation.
ABI- Si plusieurs APK sont activés pour l'ABI, ce composant spécifie l'ABI de l'APK ; par exemple
x86. buildvariant- Spécifie la variante de compilation en cours de compilation ; par exemple
debug.