Atenção:desde agosto de 2021, todos os novos apps precisam ser publicados como App Bundles. Se você publicar seu app no Google Play, crie e faça upload de um Android App Bundle. Quando você faz isso, o Google Play gera e veicula automaticamente APKs otimizados para a configuração do dispositivo de cada usuário, para que eles façam o download apenas do código e dos recursos necessários para executar seu app. Publicar vários APKs é útil se você estiver publicando em uma loja que não oferece suporte ao formato AAB. Nesse caso, você precisa criar, assinar e gerenciar cada APK por conta própria.
Embora seja recomendável criar um único APK para oferecer compatibilidade com todos os dispositivos de destino sempre que possível, isso pode resultar em um APK muito grande devido aos arquivos que oferecem suporte a várias interfaces binárias de aplicativos (ABIs). Uma maneira de reduzir o tamanho do APK é criar vários APKs que contenham arquivos para ABIs específicas.
O Gradle pode criar APKs separados que contenham apenas códigos e recursos específicos para cada 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 baseadas na ABI, use 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). No bloco
splits, forneça um
bloco abi que especifique como você quer que o Gradle
gere APKs por ABI.
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
ABIs desejadas.
As seguintes opções de DSL do Gradle são usadas para configurar vários APKs por ABI:
-
enablepara Groovy ouisEnablepara script Kotlin - Se você definir esse elemento como
true, o Gradle vai gerar vários APKs com base nas ABIs definidas. O valor padrão éfalse. -
exclude -
Especifica uma lista de ABIs separadas por vírgulas para as quais você não quer que o Gradle
gere APKs separados. Use
excludese quiser gerar APKs para a maioria das ABIs, mas precisar excluir algumas que não são compatíveis com seu app. -
reset() -
Limpa a lista padrão de ABIs. Use somente quando combinado com o elemento
includepara especificar a ABI que você quer adicionar.O snippet a seguir define a lista de ABIs como
x86ex86_64chamandoreset()para limpar a lista e 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. Use somente em combinação com
reset()para especificar uma lista exata de ABIs. -
universalApkpara Groovy ouisUniversalApkpara script Kotlin -
Se for
true, o Gradle vai gerar um APK universal, além dos APKs por ABI. Um APK universal contém código e recursos para todas as ABIs em um único APK. O valor padrão éfalse.
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 uma
lista de ABIs que recebem 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 } } }
Consulte ABIs compatíveis para ver uma lista daquelas que são compatíveis.
Projetos sem código nativo/C++
Para projetos sem código nativo/C++, o painel Build Variants tem duas colunas: Module e Active Build Variant, conforme mostrado na Figura 1.

Figura 1. O painel Build Variants tem duas colunas para projetos sem código nativo/C++.
O valor de Active Build Variant para o módulo determina a variante de build que é implantada e fica 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: Module, Active Build Variant e Active ABI, como mostrado na Figura 2.
Figura 2. O painel Build Variants adiciona a coluna Active ABI para
projetos com código nativo/C++.
O valor de 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 coluna Active Build Variant ou Active ABI.
- Escolha a variante ou ABI desejada no campo da lista. Uma nova sincronização é executada automaticamente.
Mudar uma coluna para um módulo de app ou de biblioteca aplica a mudança a todas as linhas dependentes.
Configurar o controle de versões
Por padrão, quando o Gradle gera vários APKs, cada um deles tem as mesmas
informações de versão, conforme especificado no arquivo
build.gradle ou build.gradle.kts do módulo. Como a
Google Play Store não permite que o mesmo app tenha vários APKs com
as mesmas informações de versão, é necessário garantir que cada APK tenha um
versionCode exclusivo antes de fazer upload para a Play Store.
Você pode configurar o arquivo build.gradle no nível do módulo para
substituir o versionCode de cada APK. Ao criar um mapeamento
que atribui um valor numérico exclusivo a cada ABI para o qual você configura
vários APKs, é possível substituir o código da versão de saída por um valor que
combina o código da versão definido no bloco defaultConfig ou
productFlavors com o valor numérico atribuído à
ABI.
No exemplo a seguir, o APK da ABI x86
recebe um versionCode de 2004 e o APK da ABI x86_64
recebe um versionCode de 3004.
Atribuir códigos de versão em incrementos maiores, como 1000, permite
atribuir códigos de versão exclusivos depois, se você precisar atualizar seu app. Por
exemplo, se defaultConfig.versionCode itera para 5 em uma
atualização subsequente, o Gradle atribui um versionCode de 2005 ao
APK x86 e 3005 ao APK x86_64.
Dica:se seu build inclui um APK universal, atribua um valor de versionCode menor 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
processa isso sem substituir o versionCode
padrão de um APK universal.
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)) } } } }
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 o arquivo build.gradle ou
build.gradle.kts do módulo para criar vários APKs, clique em
Build > Build APK para criar todos os APKs para o
módulo selecionado no painel Project. O Gradle cria os APKs para cada ABI no diretório build/outputs/apk/ do projeto.
O Gradle cria um APK para cada ABI para as quais você configura vários APKs.
Por exemplo, o snippet build.gradle
a seguir permite criar vários APKs para
ABIs x86 e x86_64:
Groovy
... splits { abi { enable true reset() include "x86", "x86_64" } }
Kotlin
... splits { abi { isEnable = true reset() include("x86", "x86_64") } }
O resultado da configuração de exemplo inclui os quatro APKs a seguir:
app-X86-release.apk: contém código e recursos para ABIx86.app-X86_64-release.apk: contém código e recursos para ABIx86_64.
Ao criar vários APKs com base na ABI, o Gradle só gera um APK que inclui código e recursos para todas as ABIs se você especificar universalApk true no bloco splits.abi do arquivo build.gradle (para Groovy) ou isUniversalApk = true no bloco splits.abi do 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 de APK usando o seguinte esquema:
modulename-ABI-buildvariant.apk
Os componentes do esquema são:
-
modulename - Especifica o nome do módulo que está sendo criado.
-
ABI -
Se vários APKs para ABI estão ativados, especifica a ABI do APK, como
x86. -
buildvariant -
Especifica a variante de build que está sendo criada, como
debug.