APK vs. AAB: Explicando o Novo Formato de Distribuição do Android
O que o APK Realmente É (E Por Que Dominou o Android por 15 Anos)
Por 15 anos, o Android Package Kit — APK — foi a única opção disponível. Ele tem sido o padrão para aplicativos Android desde o lançamento da plataforma em 2008. Um APK é, na verdade, apenas um arquivo ZIP com uma estrutura interna muito específica: ele contém o AndroidManifest.xml compilado, o bytecode DEX (classes.dex), uma tabela resources.arsc e pastas para assets, bibliotecas nativas e outros recursos brutos. Quando você baixa um aplicativo de um site ou o envia para um amigo por Bluetooth, está enviando um único arquivo .apk que tem tudo o que é necessário para rodar em qualquer dispositivo Android. A abordagem universal é, ao mesmo tempo, a maior força e a falha fatal do APK. Um único APK da Google Play Store precisa ser compatível com tudo, desde um Samsung Galaxy S25 Ultra com um chip ARM de 64 bits até um celular Tecno de baixo custo com um chip ARM de 32 bits, além de Chromebooks com processadores x86 e todas as densidades de tela imagináveis. Para fazer isso, os desenvolvedores tinham que empacotar todas as versões de cada biblioteca nativa, string traduzida e imagem para cada densidade de tela em um único pacote massivo. O resultado? Aplicativos como o Google Maps enviavam APKs de 100 MB quando seu dispositivo só precisava de cerca de 40 MB daquilo. O resto era apenas peso morto — baixado e armazenado, mas nunca usado.
Android App Bundle: O que Mudou em 2018 e Por Que o Google o Tornou Obrigatório
O Google finalmente resolveu o problema de inchaço do APK na Google I/O 2018 com o Android App Bundle (AAB), tornando-o obrigatório para novos aplicativos na Play Store em agosto de 2021. Embora tenha a extensão .aab e também seja um arquivo ZIP, ele não é um aplicativo instalável. Pense nele como uma receita e uma caixa de ingredientes, não o bolo pronto. Um AAB contém o código compilado e os recursos em módulos, mas são os servidores da Google Play que fazem a montagem final. Esse processo é chamado de Dynamic Delivery. Quando um usuário clica em 'Instalar' na Play Store, os servidores do Google analisam seu dispositivo específico — a arquitetura da CPU (ABI), a densidade da tela e as configurações de idioma. Em seguida, eles constroem e servem um conjunto personalizado de APKs divididos (split APKs) contendo apenas o que aquele dispositivo exato precisa. Um Pixel 9 rodando Android 15 em português pode receber um download de 38 MB, enquanto o antigo APK monolítico teria pesados 95 MB. A redução de tamanho não é teórica; é significativa e mensurável. Dados do próprio Google de 2021 mostraram uma redução média de tamanho de 15% para aplicativos que mudaram para AAB, com alguns cortando seu tamanho em mais de 50%. Para um jogo com enormes atlas de textura projetados para diferentes formatos de compressão de GPU (como ETC2, ASTC e S3TC), a economia pode ser astronômica, removendo facilmente centenas de megabytes da instalação final no celular do usuário.
A Estrutura Interna de um Arquivo AAB
Se você abrir um AAB com um utilitário de ZIP, verá imediatamente que não é um APK. No nível superior, há um arquivo BundleConfig.pb, que define a configuração do bundle, um diretório BUNDLE-METADATA e pelo menos um diretório de módulo. O módulo principal é sempre chamado de `base/`, e ele se parece um pouco com um APK por dentro, com pastas `dex/`, `manifest/`, `res/`, `root/` e `lib/`. Mas há uma diferença crucial: os recursos são armazenados em um formato proto `resources.pb`, e não no binário plano `resources.arsc` de um APK. Esta é uma razão fundamental pela qual um AAB não pode ser instalado diretamente. Outros módulos de funcionalidade (feature modules) aparecem ao lado do módulo `base/`, com nomes como `onboarding/` ou `ar_features/`. Cada um tem seu próprio manifesto e recursos e pode ser configurado para ser baixado no momento da instalação, logo após a instalação (fast-follow) ou apenas quando necessário. Este modelo sob demanda é como um aplicativo como o Google Earth pode evitar sobrecarregar todos os usuários com dados de cidades em 3D, buscando-os através da biblioteca Play Core apenas quando alguém realmente tenta visualizar uma cidade com essa cobertura. O diretório `lib/` dentro de cada módulo é onde a verdadeira mágica da economia de tamanho acontece. Um jogo multiplataforma pode ter subdiretórios `arm64-v8a`, `armeabi-v7a` e `x86_64`, cada um cheio de bibliotecas .so compiladas. Um APK monolítico empacotaria todas elas. Com um AAB, o Dynamic Delivery garante que apenas o único diretório ABI correspondente seja enviado. Para um jogo com 80 MB de código nativo por ABI, isso representa uma economia instantânea de 160 MB em um celular moderno de 64 bits que não tem utilidade para bibliotecas de 32 bits ou x86.
APK vs. AAB: Uma Comparação Direta do que Importa para Desenvolvedores
Então, o que essas diferenças significam na prática para desenvolvedores, QA e usuários? Vamos detalhar a comparação pelo que realmente importa no seu trabalho diário. **Suporte a canais de distribuição:** A Google Play exige AABs para novos aplicativos. Simples assim. No entanto, AABs são uma tecnologia exclusiva do Google. Lojas de aplicativos Android alternativas como a Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery e F-Droid todas exigem os bons e velhos APKs. Se você está distribuindo seu aplicativo fora da Google Play, você ainda está no negócio dos APKs. Isso não é um detalhe menor, especialmente em mercados onde a Google Play não está disponível e a distribuição apenas por APK é o padrão. **Instalação direta:** Você não pode fazer sideload de um AAB. Tentar instalar um com `adb install app.aab` apenas resultará em um erro. Para testar um AAB localmente, você precisa usar a ferramenta `bundletool` do Google para gerar um conjunto de APKs locais ou usar a flag `--local-testing` na sua compilação. Qualquer um que já tentou fazer um stakeholder não técnico testar uma build sabe que adicionar etapas extras é uma receita para a frustração. Isso definitivamente adiciona atrito aos fluxos de trabalho de QA. **Ferramentas de compilação:** No Android Studio, você cria um AAB com Build > Generate Signed Bundle/APK > Android App Bundle, ou com a tarefa `./gradlew bundleRelease`. Você compila um APK com `./gradlew assembleRelease`. A maioria das equipes usa ambos, compilando APKs para testes internos e AABs para o upload final na Play Store. **Tamanho do arquivo em disco:** Aqui está um ponto comum de confusão: seu arquivo AAB quase sempre será maior que seu APK. Um APK de 60 MB pode gerar um AAB de 80 MB porque o AAB contém os recursos para *todas* as configurações de dispositivo. A economia de tamanho só aparece no dispositivo do usuário depois que a Google Play faz sua mágica. **Modelo de segurança:** Ambos os formatos são assinados, mas o processo difere. Com AABs, você deve usar o Play App Signing. Isso significa que você faz o upload do seu bundle e o Google reassina os APKs divididos finais que ele gera com uma chave que ele gerencia. Embora você registre essa chave, em última análise, o Google a detém, um fato que deixa algumas equipes preocupadas com segurança nervosas. Com APKs, você pode controlar todo o processo de assinatura com suas próprias chaves, sem envolvimento do Google.
Convertendo entre APK e AAB: O que é Possível e o que Não É
É aqui que respostas honestas importam mais do que promessas de marketing. Vamos ser diretos: converter um APK existente de volta para um AAB não é algo que exista de verdade, e você deve ser profundamente cético em relação a qualquer ferramenta que afirme fazer isso automaticamente. O problema é fundamental. Um AAB precisa das informações originais da fonte — os arquivos de recursos organizados por densidade de tela e idioma, a tabela de recursos em formato proto, a estrutura de módulos. Todos esses dados são compilados, achatados e otimizados quando um APK é criado. O arquivo `resources.arsc` em um APK é um blob binário; a estrutura de pastas original `res/drawable-hdpi/` se foi. Tentar reconstruir isso a partir de um APK compilado não é conversão; é um processo doloroso de engenharia reversa, e os resultados são quase sempre incompletos. O CocoConvert foi construído para operações de APK para APK. Você pode usá-lo para reempacotar, renomear e, o mais útil, extrair o conteúdo de arquivos APK para inspeção. Faça o upload de um APK e você pode extrair seu manifesto, ver sua tabela de recursos ou pegar assets específicos. Mas o que o CocoConvert não pode fazer é gerar um AAB válido e pronto para a Play Store a partir de um APK. Francamente, nenhuma ferramenta consegue fazer isso de forma confiável se você não tiver o projeto com o código-fonte original. Se você perdeu seu código-fonte e só tem um APK, sua melhor aposta é uma ferramenta como o `apktool`. Ele pode descompilar o pacote para bytecode smali e lhe dar uma aproximação dos recursos, mas transformar isso de volta em um projeto adequado que possa ser compilado em um AAB requer uma quantidade massiva de trabalho manual. Para o que o CocoConvert *é* genuinamente útil são as tarefas que surgem o tempo todo em QA mobile e pesquisa de segurança. Você pode converter APKs para arquivos ZIP para navegar em seu conteúdo, extrair imagens ou arquivos de áudio específicos e até mesmo processar em lote uma pasta inteira de APKs para auditá-los. Esses são os trabalhos práticos e do mundo real com os quais podemos ajudar.
O Problema do Sideloading e Por Que o APK Não Vai Desaparecer
Apesar do grande esforço do Google pelo AAB, o humilde APK não vai a lugar nenhum. Sua durabilidade vem de todos os casos de uso que existem completamente fora do controle do Google. O sideloading — instalar um APK de fora da Play Store — é um recurso central do Android, habilitado por uma rápida visita às configurações do seu celular (geralmente em Configurações > Apps > Acesso especial a apps > Instalar apps desconhecidos, embora o caminho varie). E o ecossistema de sideloading é massivo. O APKMirror hospeda APKs verificados de aplicativos da Play Store, permitindo que os usuários obtenham atualizações antes que um lançamento gradual os alcance ou instalem versões mais antigas. Ferramentas de Gerenciamento de Dispositivos Móveis (MDM) empresariais da VMware e Microsoft enviam APKs para milhares de dispositivos corporativos sem nunca tocar na Play Store. As comunidades de modding de jogos vivem e respiram APKs modificados. Para desenvolvedores em regiões com acesso limitado à Play Store, compartilhar APKs é o principal método de distribuição. Para qualquer um desses usuários, o AAB é simplesmente irrelevante. É um formato que vive e morre dentro do jardim murado do Google. No segundo em que um aplicativo precisa ser compartilhado, implantado ou instalado fora desse ecossistema, ele precisa ser um APK. Isso está se tornando ainda mais relevante com novas regulamentações. A Lei dos Mercados Digitais (Digital Markets Act) da UE está forçando tanto a Apple quanto o Google a se abrirem para lojas de aplicativos alternativas. À medida que os marketplaces de terceiros para Android ganham força na Europa, eles precisarão de um formato universal para os envios. Como eles não podem usar a infraestrutura proprietária de Dynamic Delivery do Google, esse formato será o APK. Isso poderia, ironicamente, levar a um ressurgimento da importância do APK em alguns dos maiores mercados do mundo, mesmo enquanto o Google aposta ainda mais no AAB para sua própria loja.
Recomendações Práticas Baseadas na Sua Situação
Então, vamos direto ao ponto. O formato certo depende inteiramente do que você está tentando fazer. Aqui está um guia sem rodeios baseado na sua função. **Se você está publicando um novo aplicativo na Google Play:** Você não tem escolha. Você deve enviar um AAB para qualquer novo aplicativo desde agosto de 2021. Configure o Play App Signing no Play Console (Configuração > Integridade do app), configure seu signing config do Gradle e execute `./gradlew bundleRelease`. Certifique-se de testá-lo localmente com `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` seguido por `bundletool install-apks --apks=app.apks`. **Se você está distribuindo para dispositivos corporativos via MDM:** Fique com os APKs. Compile um com `./gradlew assembleRelease`. Sua solução de MDM envia o APK diretamente para os dispositivos. Usar um AAB aqui não agrega valor algum e só cria dores de cabeça. **Se você está distribuindo para lojas de aplicativos alternativas:** Compile APKs. A Amazon Appstore, por exemplo, tem seu próprio portal de desenvolvedor para uploads de APK e sua própria lógica para segmentação de dispositivos. Eles não usam o sistema do Google. **Se você é um engenheiro de QA testando uma build:** Use APKs para seus smoke tests diários e testes de regressão; eles são rápidos e instalam diretamente com `adb install`. Para a validação final pré-lançamento, você deve compilar um AAB e usar o `bundletool` para garantir que está testando o que os usuários realmente receberão da Play Store. **Se você precisa inspecionar um APK que recebeu:** Você pode fazer o upload para o CocoConvert para extrair rapidamente seu conteúdo, ou usar o próprio APK Analyzer do Android Studio (Build > Analyze APK). O analisador oferece uma ótima visualização detalhada dos tamanhos dos arquivos e é perfeito para comparar duas builds diferentes para ver o que mudou. No final das contas, o debate APK vs. AAB não é sobre qual formato é tecnicamente superior de forma isolada. É sobre logística. A escolha certa é determinada pelo seu canal de distribuição e suas ferramentas. Ambos os formatos vieram para ficar, servindo a caminhos diferentes no extenso ecossistema Android.