Compreendendo a arquitetura de CPU do Android (ABI): por que arm64-v8a, armeabi-v7a e x86 são importantes
Se você já mesclou um conjunto de arquivos APK divididos e viu seu telefone devolver "Aplicativo não instalado" ou, pior, assistiu-o instalar corretamente apenas para travar no instante em que você tocou no ícone, há uma boa chance de o problema real não ter nada a ver com um download corrompido. É quase certo que se tratava de arquitetura: uma incompatibilidade entre a CPU em que seu telefone é executado e a CPU para a qual o código nativo do aplicativo foi compilado. A maioria dos usuários do Android nunca precisa pensar sobre isso, até o momento em que algo quebra silenciosamente e então se torna relevante rapidamente. Veja o que a arquitetura da CPU significa para um APK, por que um único aplicativo na Play Store é enviado secretamente como várias versões diferentes de si mesmo e como verificar a compatibilidade antes de instalar qualquer coisa.
O que é uma ABI
ABI significa Interface Binária de Aplicativo. Em termos práticos, é o conjunto de instruções que um chip entende – o formato bruto do código de máquina que um processador pode executar diretamente. A maior parte de um aplicativo Android, as partes escritas em Java ou Kotlin, são compiladas em bytecode que é executado dentro do Android Runtime (ART), e o ART não se importa particularmente em qual chip ele está instalado. Essa camada é independente de arquitetura por design, o que é uma grande parte do motivo pelo qual os aplicativos Android geralmente “simplesmente funcionam” em uma variedade tão ampla de hardware.
O código nativo é uma história diferente. Muitos aplicativos, especialmente jogos, aplicativos de câmera, ferramentas de aprendizado de máquina e qualquer coisa que faça processamento pesado de áudio ou vídeo, enviam bibliotecas nativas escritas em C ou C++ por meio do Android NDK. Essas bibliotecas são compiladas antecipadamente em código de máquina para um conjunto de instruções específico, e um chip construído para um conjunto de instruções geralmente não pode executar código de máquina escrito para um conjunto diferente. Essa é a razão pela qual as ABIs existem como algo que vale a pena entender: no momento em que um aplicativo inclui pelo menos uma biblioteca .so nativa, sua compatibilidade fica vinculada às arquiteturas para as quais a biblioteca foi construída.
As arquiteturas que você encontrará
Costumava haver mais variedade neste espaço (lembra do armeabi simples, ou MIPS?), mas em 2026 o campo se reduziu a quatro ABIs que vale a pena conhecer:
| ABI | Largura de bits | Dispositivos típicos | Notas |
|---|---|---|---|
| arm64-v8a | ARM de 64 bits | Praticamente todos os telefones vendidos desde aproximadamente 2019 | O destino padrão para novos aplicativos; O Google exige suporte de 64 bits para novos envios da Play Store há vários anos. |
| armeabi-v7a | ARM de 32 bits | Dispositivos mais antigos ou baratos, alguns telefones de baixo custo ainda vendidos em mercados emergentes | Ainda fornecido por muitos aplicativos para compatibilidade com versões anteriores, embora a maioria dos dispositivos ativos não precise mais dele. |
| x86 | Intel de 32 bits | Tablets antigos baseados em Intel, emuladores legados | Principalmente obsoleto; you'll rarely encounter a real 32-bit x86 phone today. |
| x86_64 | Intel de 64 bits | Alguns Chromebooks, emuladores Android para desktop, alguns tablets x86 | Importante se você testar aplicativos em um emulador como um Android Studio AVD baseado em x86 ou certas compilações do BlueStacks. |
Se você tem um telefone comprado nos últimos cinco ou seis anos, é quase certo que é o arm64-v8a. As exceções que vale a pena lembrar são emuladores e Chromebooks, que frequentemente rodam em x86_64, uma vez que corresponde à CPU subjacente do laptop ou desktop.
Por que os aplicativos se incomodam em enviar várias compilações
Uma questão óbvia é por que os desenvolvedores não simplesmente amontoam as bibliotecas nativas de cada arquitetura em um único APK e terminam com isso. Alguns aplicativos fazem exatamente isso e são chamados de APK universal ou “gordo”. A desvantagem é o tamanho. Um jogo com bibliotecas nativas para arm64-v8a, armeabi-v7a, x86 e x86_64, todas agrupadas, pode facilmente dobrar ou triplicar de tamanho em comparação com uma compilação contendo apenas a arquitetura que seu dispositivo precisa. Multiplique isso por milhões de instalações e você verá uma quantidade genuinamente significativa de largura de banda e armazenamento desperdiçados, para códigos que nunca serão executados naquele dispositivo.
Para evitar esse desperdício, o Google Play e o formato Android App Bundle dividem um aplicativo em um pequeno APK base mais uma série de APKs de configuração, um dos quais é dedicado à arquitetura. Quando seu telefone solicita o aplicativo, a Play Store fornece o APK base junto com apenas a divisão de arquitetura que corresponde ao seu chip, junto com a densidade de tela e as divisões de idioma correspondentes. Você acaba com uma instalação que se comporta como um único aplicativo, mas é montada a partir de várias peças criadas especificamente nos bastidores.
Como APKs divididos e pacotes de aplicativos usam isso
Se você já abriu um pacote .apks ou .xapk e notou nomes de arquivos como split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk e split_config.en.apk ao lado de um base.apk, é exatamente esse sistema em ação, apenas exportado como um conjunto de arquivos em vez de ser entregue silenciosamente pela Play Store. As divisões de densidade e idioma geralmente são seguras para instalação indiscriminada, pois um telefone simplesmente ignora recursos de que não precisa. A divisão da arquitetura é diferente: instale a errada ou deixe de instalar a correspondente e você terá problemas reais.
Quando você usa um conversor para mesclar um pacote dividido de volta em um único APK instalável, o processo de mesclagem precisa escolher quais divisões de arquitetura serão incluídas. Um bom conversor mantém todas as divisões de arquitetura que são genuinamente úteis ou permite que você escolha, em vez de manter silenciosamente apenas uma e esperar que corresponda ao seu dispositivo.
O que acontece quando a arquitetura não combina
Existem dois modos de falha distintos que vale a pena conhecer, porque eles têm aparência e comportamento diferentes para um usuário comum.
O primeiro é uma falha total na instalação. Se um aplicativo for construído quase inteiramente em torno de código nativo, sem nenhum substituto significativo, o gerenciador de pacotes do Android se recusará a instalá-lo, geralmente revelando um erro como INSTALL_FAILED_NO_MATCHING_ABIS. Você nem conseguirá abrir o aplicativo; o instalador para você na porta.
O segundo resultado, mais frustrante, é um sucesso parcial silencioso. Se um aplicativo tiver um ponto de entrada Java ou Kotlin que carregue bem por conta própria, mas tente chamar uma biblioteca nativa que simplesmente não está presente em sua arquitetura, a instalação será concluída normalmente. Tudo parece bem até você tocar no ícone, momento em que o aplicativo trava quase imediatamente, geralmente com um UnsatisfiedLinkError enterrado nos logs. Esta é a história clássica de “converti, instalei e fecha instantaneamente”, e quase sempre é um problema de arquitetura, e não um arquivo corrompido.
Como verificar a arquitetura do seu próprio telefone
Para a grande maioria das pessoas isso é simples: se o seu telefone for de 2019 ou posterior, assuma arm64-v8a e siga em frente. Se você quiser ter certeza ou estiver lidando com um dispositivo antigo ou incomum, algumas opções práticas:
- Procure o modelo exato do chipset do seu telefone (visível na caixa, no manual ou em um site como o GSMArena) e pesquise se esse chipset é ARM de 32 ou 64 bits.
- Instale um aplicativo leve de informações do sistema que relate diretamente a arquitetura da CPU; existem vários aplicativos gratuitos especificamente para essa finalidade.
- Verifique se o telefone foi fornecido com Android 9 ou posterior como versão original do sistema operacional; Os requisitos de 64 bits do Google daquela época tornam o arm64-v8a essencialmente garantido em qualquer coisa que se qualifique.
Como verificar quais arquiteturas um APK suporta
Antes de instalar um arquivo de fora da Play Store, vale a pena confirmar o que há dentro dele, em vez de adivinhar. As bibliotecas nativas de um APK residem em pastas com os nomes de sua arquitetura dentro do diretório lib/, como lib/arm64-v8a/ ou lib/armeabi-v7a/. Qualquer ferramenta que possa inspecionar a estrutura interna de um APK pode dizer exatamente quais dessas pastas estão presentes, o que informa exatamente em quais dispositivos o arquivo será executado.
Verifique antes de instalar
Nosso Ferramenta de informações do APK lê a pasta lib/ interna de um APK e lista todas as arquiteturas para as quais ele foi criado, para que você possa confirmar a compatibilidade antes de fazer o sideload de qualquer coisa. Quando você converte um pacote dividido com nosso Conversor de XAPK para APK, também exibimos isso automaticamente após cada conversão, listando as arquiteturas encontradas no arquivo mesclado e sinalizando-o quando uma compilação parece estar faltando uma fatia que os dispositivos comuns precisariam.
APK universal vs APK de ABI único: qual você deve usar?
| Métrica | APK universal / gordo | APK de ABI único |
|---|---|---|
| Tamanho do arquivo | Maior, às vezes 2-4x | Pequeno, contém apenas o que seu dispositivo precisa |
| Compatibilidade | Funciona em praticamente qualquer dispositivo | Funciona apenas em uma arquitetura correspondente |
| Melhor para | Compartilhando um arquivo que deveria funcionar em qualquer lugar, destinatários inseguros | Seu próprio dispositivo, quando você já conhece sua arquitetura |
| Risco | Risco muito baixo de incompatibilidade de ABI | Irá falhar ou travar se você escolher o errado |
Erros comuns que as pessoas cometem com pacotes divididos
- Supondo que cada divisão seja opcional. As divisões de densidade e linguagem geralmente são, mas a divisão de arquitetura não; nunca pule durante uma mesclagem.
- Capturando apenas uma arquitetura dividida de um site espelho. Se um download de terceiros oferecer apenas, digamos, a fatia armeabi-v7a, ele pode simplesmente falhar em um dispositivo que precisa do arm64-v8a, mesmo que o aplicativo em si seja legítimo.
- Esquecer que tablets e Chromebooks nem sempre são ARM. Muitos Chromebooks que executam aplicativos Android e alguns tablets mais antigos são x86 ou x86_64 em vez de ARM.
- Testando um APK somente ARM dentro de um emulador x86. Algumas compilações de emuladores mais antigas são executadas em x86, e um APK que fornece apenas bibliotecas nativas ARM simplesmente não será iniciado dentro deles, independentemente de como o APK foi empacotado.
- Confundir “universal” com “ABI único”. Um APK universal é intencionalmente maior porque inclui tudo; um APK ABI único é pequeno e intencionalmente limitado a uma família de chips.
Principais conclusões
- Uma ABI é o conjunto de instruções que um chip entende; isso importa apenas para aplicativos que incluem código nativo (C/C++).
- arm64-v8a cobre quase todos os telefones modernos; armeabi-v7a é para dispositivos mais antigos; x86/x86_64 aparecem principalmente em emuladores e Chromebooks.
- Os aplicativos geralmente são divididos por arquitetura para evitar o envio de código nativo desnecessário para todos os dispositivos.
- Uma arquitetura incompatível bloqueia a instalação completamente ou causa uma falha imediata após uma instalação aparentemente bem-sucedida.
- Você pode verificar a arquitetura do seu dispositivo e as arquiteturas suportadas por um APK antes de instalar qualquer coisa, evitando totalmente suposições.
Perguntas Frequentes (FAQ)
Preciso conhecer a arquitetura do meu telefone para instalar um aplicativo normal da Play Store?
Não. A Play Store detecta automaticamente seu dispositivo e fornece apenas a divisão de arquitetura correspondente. Portanto, isso só se torna relevante quando você faz o sideload de APKs de fora da Play Store.
Um APK pode oferecer suporte a várias arquiteturas ao mesmo tempo?
Sim. Um APK universal ou gordo agrupa bibliotecas nativas para cada arquitetura suportada em um arquivo. É maior, mas pode ser instalado em qualquer dispositivo compatível, independentemente do chip.
Por que meu APK convertido foi instalado, mas travou imediatamente?
Isso geralmente acontece quando o aplicativo tem uma pequena quantidade de código Java que pode ser instalado corretamente, mas depois tenta carregar uma biblioteca nativa que não foi incluída na arquitetura do seu dispositivo, gerando um UnsatisfiedLinkError em tempo de execução.
O arm64-v8a é compatível com versões anteriores dos aplicativos armeabi-v7a?
Geralmente sim. A maioria dos chips arm64-v8a também pode executar instruções ARM de 32 bits, portanto, um APK somente armeabi-v7a geralmente ainda será executado em um telefone arm64 moderno, mas não o contrário.
Os dispositivos Android x86 ainda existirão em 2026?
Eles são raros em telefones hoje, mas você ainda encontrará x86 ou x86_64 em alguns tablets mais antigos baseados em Intel, em alguns Chromebooks executando aplicativos Android e na maioria dos emuladores Android para desktop.
Você não precisa memorizar nada disso. A versão resumida: os telefones modernos são quase sempre arm64-v8a, os aplicativos são divididos por arquitetura para economizar espaço e, se algo se recusa a instalar ou trava logo após a abertura, a incompatibilidade de arquitetura é uma das primeiras coisas que vale a pena descartar antes de assumir que o arquivo em si está quebrado.