Atenção:desde agosto de 2021, todas as novas os apps precisam ser publicados como pacotes de apps. Se você publicar seu app no Google Play, criar e fazer upload de um Android App Bundle; Quando ao fazer isso, o Google Play gera e envia automaticamente APKs otimizados para configuração do dispositivo de cada usuário para que eles façam o download apenas do código e dos recursos necessárias para executar o app. A publicação de vários APKs é útil se você publicar em uma loja que não oferece suporte para o formato AAB. Nesse caso, precisa criar, assinar e gerenciar cada APK por conta própria.
Embora seja melhor criar um único APK para oferecer suporte a todos os dispositivos de destino sempre que possível, isso pode resultar em um APK muito grande devido ao tamanho suportando vários densidades de tela ou binário de aplicativo Interfaces do usuário (ABIs). Uma forma de reduzir o tamanho do APK é criar vários APKs que contêm arquivos para densidades de tela ou ABIs específicas.
O Gradle pode criar APKs separados que contenham apenas códigos e recursos específicos para cada densidade ou ABI. Esta página descreve como configurar seu build para gerar vários APKs. Se você precisar criar versões diferentes do app que não sejam baseados na densidade de tela ou na ABI, use as variantes de build.
Configurar o build para vários APKs
Para configurar o build para vários APKs, adicione um
bloco
splits
ao arquivo de nível de módulo
build.gradle
(link em inglês). Dentro do
Bloco splits
, fornecer
Um bloco density
que especifica como você quer que o Gradle gere
APKs por densidade ou um bloco abi
que especifica como você quer que o Gradle
para gerar APKs por ABI. Você pode fornecer blocos de densidade e ABI, e
o sistema de build cria um APK para cada combinação de densidade e ABI.
Configurar vários APKs para densidades de tela
Para criar APKs separados para diferentes densidades de tela, adicione um
bloco density
dentro da sua
splits
. No bloco density
, forneça um
lista de densidades de tela desejadas e tamanhos de tela compatíveis. Use apenas a lista de
tamanhos de tela compatíveis se você precisar de
<compatible-screens>
no manifesto de cada APK.
As seguintes opções de DSL do Gradle são usadas para configurar vários APKs para densidades de tela:
-
enable
para Groovy,isEnable
para o script Kotlin. -
Se você definir este elemento como
true
, o Gradle gerará vários APKs com base nas densidades de tela que você definir. O valor padrão éfalse
: -
exclude
-
Especifica uma lista separada por vírgulas de densidades que você não quer que o Gradle
para gerar APKs separados. Use
exclude
se você quiser gerar APKs para a maioria das densidades, mas precisar excluir alguns densidades incompatíveis com seu app. -
reset()
-
Apaga a lista padrão de densidades de tela. Use somente quando combinado com o
include
para especificar as densidades que você quer adicionar.O snippet a seguir define a lista de densidades como
ldpi
exxhdpi
chamandoreset()
para limpar a lista e, em seguida, usandoinclude
:reset() // Clears the default list from all densities // to no densities. include "ldpi", "xxhdpi" // Specifies the two densities to generate APKs // for.
-
include
-
Especifica uma lista de densidades separada por vírgulas que você quer que o Gradle gere
e APKs para. Use somente em combinação com
reset()
para especificar uma lista exata de densidades. -
compatibleScreens
-
Especifica uma lista separada por vírgulas de tamanhos de tela compatíveis. Isso injeta um correspondente
<compatible-screens>
no manifesto para para cada APK.Essa configuração é uma forma conveniente de gerenciar densidades e tamanhos de tela na mesma seção
build.gradle
. No entanto, usar<compatible-screens>
pode limitar os tipos de dispositivo com as quais seu app funciona. Para conhecer formas alternativas de suporte a tamanhos de tela, consulte visão geral de compatibilidade de tela.
Como cada APK que é baseado na densidade da tela inclui um
Tag <compatible-screens>
com restrições específicas
sobre os tipos de tela com suporte do APK, mesmo que você publique vários
APKs: alguns dispositivos novos não correspondem aos seus diversos filtros de APK. Assim,
O Gradle sempre gera um APK universal adicional que contém recursos.
para todas as densidades de tela e não inclui um
<compatible-screens>
. Publicar
APK universal com seus APKs por densidade para fornecer um substituto para
que não correspondem aos APKs
<compatible-screens>
.
O exemplo a seguir gera um APK separado para cada
tela
densidade exceto ldpi
, xxhdpi
e
xxxhdpi
. Isso é feito usando exclude
para remover
dessas três densidades da lista padrão de todas as densidades.
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") } } }
Para mais detalhes sobre como personalizar diferentes builds variantes do seu app para tipos de tela e dispositivos específicos, consulte Declarar conteúdo restrito suporte de tela.
Configurar vários APKs para ABIs
Para criar APKs separados para diferentes ABIs, adicione um bloco abi
dentro do seu bloco splits
. No bloco abi
, forneça uma lista de
as ABIs desejadas.
As seguintes opções de DSL do Gradle são usadas para configurar vários APKs por ABI:
-
enable
para Groovy ouisEnable
para script Kotlin - Se você definir esse elemento como
true
, o Gradle gerará vários APKs com base nas ABIs definidas por você. O valor padrão éfalse
. -
exclude
-
Especifica uma lista de ABIs separadas por vírgulas que você não quer que o Gradle
e gerar APKs separados. Use
exclude
se quiser gerar APKs para a maioria das ABIs, mas precisam excluir algumas que não são suporte. -
reset()
-
Limpa a lista padrão de ABIs. Use somente quando combinado com o
include
para especificar as ABIs que você quer adicionar.O snippet a seguir define a lista de ABIs como
x86
ex86_64
chamandoreset()
para limpar a lista; e em seguida, usandoinclude
: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
-
Especifica uma lista de ABIs separadas por vírgulas para as quais você quer que o Gradle gere APKs
pelas quais Use somente em combinação com
reset()
para especificar um valor exato lista de ABIs. -
universalApk
para Groovy ouisUniversalApk
para Script do Kotlin -
Se
true
, o Gradle gera um APK universal, além do por ABI. Um APK universal contém código e recursos para todas as ABIs em um um único APK. O valor padrão éfalse
.Observe que essa opção só é disponíveis no bloco
splits.abi
. Ao criar vários APKs com base na densidade da tela, o Gradle sempre gera um APK universal que contém código e recursos para todas as densidades de tela.
O exemplo a seguir gera um APK separado para cada ABI: x86
e x86_64
. Isso é feito usando reset()
para começar com uma lista vazia de ABIs, seguida por include
com um
lista de ABIs para que cada uma recebe um 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 } } }
Para uma lista de ABIs compatíveis, consulte Compatível ABIs
Projetos sem código nativo/C++
Para projetos sem código nativo/C++, o painel Build Variants tem duas opções: colunas: Module e Active Build Variante, conforme mostrado na Figura 1.
e
Figura 1. O painel Build Variants tem duas colunas para projetos sem
código nativo/C++.
O valor da Active Build Variant para o determina a variante de build implantada e visível no editor. Para alternar entre variantes, clique na célula Active Build Variant de um módulo. e escolha a variante desejada no campo de lista.
Projetos com código nativo/C++
Para projetos com código nativo/C++, o painel Build Variants tem três colunas: Módulo, Active Build Variant e Active ABI, conforme mostrado na Figura 2.
Figura 2. O painel Build Variants adiciona a coluna Active ABI para projetos com código nativo/C++.
O valor da Active Build Variant para o módulo. determina a variante de build que é implantada e fica visível no editor. Para módulos nativos, o valor de Active ABI determina a ABI que o editor usa, mas não afeta o que é implantado.
Para mudar o tipo de build ou a ABI:
- Clique na célula da Active Build Variant. ou ABI ativa.
- Escolha a variante ou ABI desejada na lista. . Uma nova sincronização é executada automaticamente.
Mudar a coluna para um módulo de app ou de biblioteca aplica a mudança a todos os de linhas dependentes.
Configurar o controle de versões
Por padrão, quando o Gradle gera vários APKs, cada um deles tem a mesma
informações da versão, conforme especificado no arquivo
Arquivo build.gradle
ou build.gradle.kts
. Como o
A Google Play Store não permite que o mesmo app tenha vários APKs
as mesmas informações de versão, você precisa garantir que cada APK tenha um
versionCode
antes de fazer upload para a Play Store.
Você pode configurar o arquivo build.gradle
do módulo para
substituir o versionCode
para cada APK. Ao criar um mapeamento,
que atribui um valor numérico exclusivo para cada ABI e densidade que você configurar
vários APKs, é possível substituir o código de versão de saída por um valor que
combina o código de versão definido no defaultConfig
ou
bloco productFlavors
com o valor numérico atribuído ao
ou ABI.
No exemplo abaixo, o APK da ABI x86
recebe uma versionCode
de 2004 e a ABI x86_64
recebe um versionCode
de 3004.
Atribuir códigos de versão em grandes incrementos, como 1.000, permite
atribuir posteriormente códigos de versão exclusivos se precisar atualizar o app. Para
exemplo, se defaultConfig.versionCode
for iterado como 5 em uma
atualização subsequente, o Gradle atribui um versionCode
de 2005 ao
ao APK x86
e 3005 ao APK x86_64
.
Dica:caso seu build inclua um APK universal, atribua a ele um
versionCode
um valor mais baixo que o dos outros APKs.
Como a Google Play Store instala a versão do app compatível com o
dispositivo de destino e que tem o maior
versionCode
, atribuir um versionCode
menor ao
APK universal garante que a Play Store tente instalar um dos seus
APKs antes do APK universal. O exemplo de código a seguir
lida com isso sem substituir o URL de um APK
versionCode
padrão.
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)) } } } }
Para ver mais exemplos de esquemas de código de versão alternativos, consulte Como atribuir códigos de versão.
Desenvolver vários APKs
Depois de configurar as APIs build.gradle
ou
build.gradle.kts
para criar vários APKs, clique em
Criação > Criar um APK para gerar todos os APKs para o
módulo selecionado no painel Project. O Gradle cria os APKs
para cada densidade ou ABI na classe build/outputs/apk/
diretório.
O Gradle cria um APK para cada densidade ou ABI para as quais você configura vários APKs. Se você habilitar vários APKs para densidades e ABIs, o Gradle criará um APK para cada combinação desses elementos.
Por exemplo, o seguinte
O snippet build.gradle
permite criar vários APKs para mdpi
e
Densidades de hdpi
e ABIs x86
e 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") } }
O resultado da configuração de exemplo inclui os quatro APKs a seguir:
app-hdpiX86-release.apk
: contém código e recursos de Densidade dehdpi
e ABIx86
.app-hdpiX86_64-release.apk
: contém código e recursos de Densidade dehdpi
e ABIx86_64
.app-mdpiX86-release.apk
: contém código e recursos de Densidade demdpi
e ABIx86
.app-mdpiX86_64-release.apk
: contém código e recursos de Densidade demdpi
e ABIx86_64
.
Ao criar vários APKs com base na densidade de tela, o Gradle sempre gera um APK universal que inclui código e recursos para todas as densidades de tela, além dos APKs por densidade.
Ao criar vários APKs com base em
ABI, o Gradle só gera um APK que inclui código e recursos para todos os
ABIs se você especificar universalApk true
nas
Bloco splits.abi
no arquivo build.gradle
(para o Groovy) ou isUniversalApk = true
no
Bloco splits.abi
no arquivo build.gradle.kts
(para script Kotlin).
Formato de nome de arquivo do APK
Ao criar vários APKs, o Gradle gera nomes de arquivos do APK usando o seguinte: esquema:
modulename-screendensityABI-buildvariant.apk
Os componentes do esquema são:
-
modulename
- Especifica o nome do módulo que está sendo criado.
-
screendensity
-
Se vários APKs para densidade da tela estão ativados, especifica a tela
densidade para o APK, como
mdpi
. -
ABI
-
Se vários APKs para ABI estão ativados, especifica a ABI do APK, como: como
x86
.Se vários APKs para densidade de tela e ABI estão ativados, O Gradle concatena o nome da densidade com o nome da ABI, por exemplo
mdpiX86
: SeuniversalApk
estiver ativado para por ABI APKs, o Gradle usauniversal
como a parte ABI do APK universal. nome do arquivo. -
buildvariant
-
Especifica a variante de build que está sendo criada, como
debug
.
Por exemplo, ao criar o APK de densidade da tela mdpi
para o
versão de depuração do myApp, o nome do arquivo do APK será
myApp-mdpi-debug.apk
. O lançamento
do myApp, que está configurada para criar vários APKs para os dois.
A densidade da tela mdpi
e a ABI x86
têm o nome de arquivo do APK de
myApp-mdpiX86-release.apk