Attention:Depuis août 2021, toutes les nouvelles les applications doivent être publiées en tant qu'app bundles. Si vous publiez votre application sur Google Play, créer et importer un Android App Bundle ; Quand ? Google Play génère et diffuse automatiquement des APK optimisés pour la configuration de l'appareil de chaque utilisateur, afin qu'il ne télécharge que le code et les ressources dont ils ont besoin pour exécuter votre application. Il est utile de publier plusieurs APK la publication dans un magasin qui n'est pas compatible avec le format AAB. Dans ce cas, vous devez créer, signer et gérer vous-même chaque APK.
Bien qu'il soit préférable de créer un seul APK pour prendre en charge tous vos appareils cibles dans la mesure du possible, vous risquez d'obtenir un APK très volumineux en raison des fichiers compatible avec plusieurs densités d'écran ou binaire d'application Interfaces (ABI). Pour réduire la taille de votre APK, vous pouvez créer plusieurs APK qui contiennent des fichiers pour des densités d'écran ou des ABI spécifiques.
Gradle peut créer des APK distincts qui ne contiennent que le code et les ressources spécifiques à chaque densité ou 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és sur la densité de l'écran ni 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
, fournir
Un bloc density
qui spécifie la manière dont vous souhaitez que Gradle génère
des APK par densité ou un bloc abi
spécifiant la manière dont Gradle
pour générer des APK par ABI. Vous pouvez fournir des blocs de densité et d'ABI, et
le système de compilation crée un APK pour chaque combinaison de densité et d'ABI.
Configurer plusieurs APK pour les densités d'écran
Pour créer des APK distincts pour différentes densités d'écran, ajoutez un
Bloc density
dans votre
Bloc splits
. Dans votre bloc density
, indiquez une
la liste des densités d'écran souhaitées et des tailles d'écran compatibles. N'utilisez que la liste
des tailles d'écran compatibles si vous avez besoin
<ph type="x-smartling-placeholder"></ph>
<compatible-screens>
dans le fichier manifeste de chaque APK.
Les options Gradle DSL ci-dessous permettent de configurer plusieurs APK pour les densités d'écran :
-
enable
pour Groovy,isEnable
pour le script Kotlin -
Si vous définissez cet élément sur
true
, Gradle génère plusieurs APK en fonction des densités d'écran que vous définissez. La valeur par défaut estfalse
-
exclude
-
Spécifie une liste de densités séparées par une virgule auxquelles vous ne souhaitez pas que Gradle
pour lesquels générer des APK distincts. Utilisez
exclude
si vous souhaitent générer des APK pour la plupart des densités, mais doivent en exclure quelques-unes. que votre application ne prend pas en charge. -
reset()
-
Efface la liste par défaut des densités d'écran. À utiliser uniquement lorsqu'il est associé au
include
pour spécifier les densités souhaitées ajouter.L'extrait de code suivant définit la liste des densités sur
ldpi
etxxhdpi
en appelantreset()
pour effacer la liste, puis en utilisantinclude
:reset() // Clears the default list from all densities // to no densities. include "ldpi", "xxhdpi" // Specifies the two densities to generate APKs // for.
-
include
-
Spécifie une liste de densités séparées par une virgule que vous souhaitez que Gradle génère
APK pour N'utilisez cette propriété qu'en combinaison avec
reset()
pour spécifier un liste exacte des densités. -
compatibleScreens
-
Spécifie une liste de tailles d'écran compatibles séparées par une virgule. Cela injecte un correspondant
<compatible-screens>
dans le fichier manifeste pour chaque APK.Ce paramètre permet de gérer facilement les deux écrans et les tailles d'écran dans la même section
build.gradle
. Toutefois, si vous utilisez<compatible-screens>
peut limiter les types d'appareils compatibles avec votre application. Pour proposer d'autres façons de soutenir différents des tailles d'écran, consultez les présentation de la compatibilité des écrans.
Comme chaque APK basé sur la densité de l'écran comprend un
Balise <compatible-screens>
avec des restrictions spécifiques
les types d'écran compatibles avec l'APK, même si vous en publiez plusieurs
APK : certains nouveaux appareils ne correspondent pas aux différents filtres APK. À ce titre,
Gradle génère toujours un APK universel supplémentaire contenant des éléments.
pour toutes les densités d'écran et n'inclut pas
Balise <compatible-screens>
. Publier
un APK universel avec vos APK par densité afin de fournir une solution de remplacement pour
des appareils qui ne correspondent pas aux APK
Balise <compatible-screens>
.
L'exemple suivant génère un APK distinct pour chaque
écran
des valeurs de sortie, sauf ldpi
, xxhdpi
et
xxxhdpi
Pour ce faire, utilisez exclude
pour supprimer
à partir de la liste par défaut de toutes les densités.
Groovy
android { ... splits { // Configures multiple APKs based on screen density. density { // Configures multiple APKs based on screen density. enable true // Specifies a list of screen densities you don't want Gradle to create multiple APKs for. exclude "ldpi", "xxhdpi", "xxxhdpi" // Specifies a list of compatible screen size settings for the manifest. compatibleScreens 'small', 'normal', 'large', 'xlarge' } } }
Kotlin
android { ... splits { // Configures multiple APKs based on screen density. density { // Configures multiple APKs based on screen density. isEnable = true // Specifies a list of screen densities you don't want Gradle to create multiple APKs for. exclude("ldpi", "xxhdpi", "xxxhdpi") // Specifies a list of compatible screen size settings for the manifest. compatibleScreens("small", "normal", "large", "xlarge") } } }
Pour en savoir plus sur la personnalisation des différentes versions de votre application en fonction de types d'écrans et d'appareils spécifiques, consultez Déclarer une restriction écran.
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 une liste
les ABI souhaitées.
Les options Gradle DSL suivantes permettent de configurer plusieurs APK par ABI:
-
enable
pour Groovy ouisEnable
pour le script Kotlin - Si vous définissez cet élément sur
true
, Gradle génère plusieurs APK basés sur les ABI que vous définissez. La valeur par défaut estfalse
. -
exclude
-
Spécifie une liste d'ABI séparées par une virgule que vous ne souhaitez pas que Gradle utilise
générer des APK distincts. Utilisez
exclude
si vous souhaitez générer APK pour la plupart des ABI, mais devant en exclure quelques-unes qui ne sont pas disponibles par votre application de l'assistance. -
reset()
-
Efface la liste par défaut des ABI. À utiliser uniquement lorsqu'il est associé au
include
pour spécifier les ABI que vous souhaitez ajouter.L'extrait de code suivant définit la liste des ABI sur
x86
uniquement, puisx86_64
en appelantreset()
pour effacer la liste ; et 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.
-
include
-
Spécifie une liste d'ABI séparées par une virgule que vous souhaitez que Gradle génère des APK
. N'utilisez cette propriété qu'en combinaison avec
reset()
pour spécifier un liste des ABI. -
universalApk
pour Groovy ouisUniversalApk
pour Script Kotlin -
Si la valeur est
true
, Gradle génère un APK universel en plus de APK par ABI. Un APK universel contient du code et des ressources pour toutes les ABI d'un un seul fichier APK. La valeur par défaut estfalse
.Notez que cette option n'est disponible disponible dans le bloc
splits.abi
. Lors de la compilation de plusieurs APK basé sur la densité de l'écran, Gradle génère toujours un APK universel qui contient du code et des ressources pour toutes les densités d'écran.
L'exemple suivant génère un APK distinct pour chaque ABI : x86
et x86_64
. Pour ce faire, utilisez reset()
.
pour commencer avec une liste vide d'ABI, suivi de include
avec
liste des ABI qui reçoivent 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 Compatible ABI
Projets sans code natif/C++
Pour les projets sans code natif/C++, le panneau Build Variants (Variantes de compilation) comporte deux Colonnes: Module et Active Build Variante, comme illustré dans la figure 1.
Figure 1 : Le panneau Build Variants (Variantes de compilation) comporte deux colonnes pour les projets sans
en code natif/C++.
La valeur Active Build Variant (Variante de compilation active) de la classe détermine la variante de compilation déployée et visible dans l'éditeur. Pour passer d'une variante à une autre, cliquez sur la cellule Active Build Variant (Variante de compilation active) d'un module. puis sélectionnez la variante souhaitée dans le champ de la liste.
Projets avec code natif/C++
Pour les projets comportant du code natif/C++, le panneau Build Variants (Variantes de compilation) comporte trois Colonnes: Module, Active Build Variant et Active ABI (ABI active), comme illustré dans la figure 2.
Figure 2 : Le panneau Build Variants (Variantes de compilation) ajoute la colonne Active ABI (ABI active) pour
avec du code natif/C++.
Valeur Active Build Variant (Variante de compilation active) pour le 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 que 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 correspondant à Active Build Variant (Variante de compilation active). ou Active ABI (ABI active).
- Sélectionnez la variante ou l'ABI souhaitée dans la 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 à tous les modules 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
les informations de version, comme indiqué au niveau du module
Fichier build.gradle
ou build.gradle.kts
. En effet,
Le Google Play Store n'autorise pas, pour une même application, la présence de plusieurs fichiers APK dont tous
les mêmes informations de version, vous devez vous assurer que chaque APK possède une version
<ph type="x-smartling-placeholder"></ph>
versionCode
avant de l'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 et densité que vous configurez
plusieurs fichiers APK, vous pouvez remplacer le code de la version de sortie par une valeur
combine le code de version défini dans les defaultConfig
ou
bloc productFlavors
avec la valeur numérique attribuée au
ou ABI.
Dans l'exemple suivant, l'APK de l'ABI x86
obtient un versionCode
de 2004 et l'ABI x86_64
obtient une versionCode
de 3004.
L'attribution de codes de version par incréments importants (1 000, par exemple) permet
d'attribuer ultérieurement des codes de version uniques si vous devez mettre à jour votre application. Pour
exemple, si defaultConfig.versionCode
est itéré jusqu'à 5 dans une
mise à jour ultérieure, Gradle attribue un versionCode
de 2005 au
les APK x86
et 3005 à l'APK x86_64
.
Conseil:Si votre build inclut un APK universel, attribuez-lui un
versionCode
est inférieur à celui de tous vos autres APK.
Comme le Google Play Store installe la version de votre application qui est à la fois compatible avec l'appareil cible et qui possède le versionCode
le plus élevé, l'attribution d'un versionCode
plus petit à l'APK universel garantit que le Google Play Store tentera d'installer l'un de vos APK avant de revenir à l'APK universel. L'exemple de code suivant
gère cela en ne remplaçant
pas un fichier APK universel
versionCode
par défaut.
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] // For per-density APKs, create a similar map: // ext.densityCodes = ['mdpi': 1, 'hdpi': 2, 'xhdpi': 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) // For per-density APKs, create a similar map: // val densityCodes = mapOf("mdpi" to 1, "hdpi" to 2, "xhdpi" 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 build.gradle
ou
build.gradle.kts
pour créer plusieurs APK, cliquez sur
Créer > Compilez l'APK pour compiler tous les APK pour le
le module sélectionné dans le volet Project (Projet). Gradle crée les APK
pour chaque densité ou ABI dans la classe build/outputs/apk/
du projet
.
Gradle crée un APK pour chaque densité ou ABI pour laquelle vous configurez plusieurs APK. Si vous activez plusieurs APK pour les densités et les ABI, Gradle crée un APK pour chaque combinaison de densité et d'ABI.
Par exemple :
L'extrait de code build.gradle
permet de compiler plusieurs APK pour mdpi
et
Densités hdpi
, ainsi que les ABI x86
et x86_64
:
Groovy
... splits { density { enable true reset() include "mdpi", "hdpi" } abi { enable true reset() include "x86", "x86_64" } }
Kotlin
... splits { density { isEnable = true reset() include("mdpi", "hdpi") } abi { isEnable = true reset() include("x86", "x86_64") } }
La sortie de l'exemple de configuration comprend les quatre APK suivants :
app-hdpiX86-release.apk
: contient du code et des ressources pour Densitéhdpi
et ABIx86
.app-hdpiX86_64-release.apk
: contient du code et des ressources pour Densitéhdpi
et ABIx86_64
.app-mdpiX86-release.apk
: contient du code et des ressources pour Densitémdpi
et ABIx86
.app-mdpiX86_64-release.apk
: contient du code et des ressources pour Densitémdpi
et ABIx86_64
.
Lorsque vous compilez plusieurs APK en fonction de la densité d'écran, Gradle génère toujours un APK universel contenant du code et des ressources pour l'ensemble des densités, en plus des APK par densité.
Lors de la compilation de plusieurs APK basés sur
ABI, Gradle ne génère qu'un APK incluant le code et les ressources pour tous
ABI si vous spécifiez universalApk true
dans
Bloc splits.abi
dans votre fichier build.gradle
(pour Groovy) ou isUniversalApk = true
dans
Bloc splits.abi
dans votre fichier build.gradle.kts
(pour le script Kotlin).
Format du nom de fichier APK
Lorsque vous compilez plusieurs APK, Gradle génère les noms des fichiers APK à l'aide des éléments suivants : schéma:
modulename-screendensityABI-buildvariant.apk
Les composants du schéma sont les suivants :
-
modulename
- Spécifie le nom du module en cours de compilation.
-
screendensity
-
Si plusieurs APK sont activés pour la densité d'écran, spécifie l'écran
pour l'APK, par exemple
mdpi
. -
ABI
-
Si plusieurs APK sont activés pour l'ABI, ce paramètre spécifie l'ABI de l'APK, tel que en tant que
x86
.Si plusieurs APK sont activés pour la densité de l'écran et l'ABI, Gradle concatène le nom de la densité avec le nom de l'ABI, par exemple
mdpiX86
SiuniversalApk
est activé pour par-ABI APK, Gradle utiliseuniversal
comme partie ABI de l'APK universel nom de fichier. -
buildvariant
-
Spécifie la variante de compilation en cours de compilation, par exemple
debug
.
Par exemple, lorsque vous compilez mdpi
APK de densité d'écran pour le
version de débogage de "myApp", le nom de fichier de l'APK est
myApp-mdpi-debug.apk
La sortie
version de "myApp" configurée pour compiler plusieurs APK pour les deux
La densité d'écran de mdpi
et l'ABI x86
ont le nom de fichier APK de
myApp-mdpiX86-release.apk