APK vs. AAB: El nuevo formato de distribución de Android, explicado
¿Qué es realmente un APK? (Y por qué dominó Android durante 15 años)
Durante 15 años, el Android Package Kit (APK) fue la única opción disponible. Ha sido el estándar para las apps de Android desde el lanzamiento de la plataforma en 2008. Un APK no es más que un archivo ZIP con una estructura interna muy específica: contiene el archivo AndroidManifest.xml compilado, el bytecode DEX (classes.dex), una tabla resources.arsc y carpetas para los assets, las bibliotecas nativas y otros recursos en crudo. Cuando descargas una app de un sitio web o se la pasas a un amigo por Bluetooth, estás enviando un único archivo .apk que tiene todo lo necesario para funcionar en cualquier dispositivo Android. Ese enfoque de 'talla única' es a la vez la mayor fortaleza del APK y su defecto fatal. Un único APK de la Google Play Store debe ser compatible con todo, desde un Samsung Galaxy S25 Ultra con un chip ARM de 64 bits hasta un teléfono Tecno de gama baja con un chip ARM de 32 bits, además de los Chromebooks con procesadores x86 y todas las densidades de pantalla imaginables. Para lograrlo, los desarrolladores tenían que empaquetar cada versión de cada biblioteca nativa, cada cadena de texto traducida y cada imagen para cada densidad de pantalla en un único paquete gigantesco. ¿El resultado? Apps como Google Maps llegaban a pesar 100 MB en formato APK, cuando tu dispositivo en realidad solo necesitaba unos 40 MB de todo eso. El resto era simplemente peso muerto: se descargaba y almacenaba, pero nunca se usaba.
Android App Bundle: Qué cambió en 2018 y por qué Google lo hizo obligatorio
Google finalmente abordó el problema del 'bloat' (o inflado) de los APK en el Google I/O 2018 con el Android App Bundle (AAB), y lo hizo obligatorio para las nuevas apps de la Play Store en agosto de 2021. Aunque tiene la extensión .aab y también es un archivo ZIP, no es una app instalable. Piénsalo como una receta y una caja de ingredientes, no como el pastel ya terminado. Un AAB contiene el código compilado y los recursos en módulos, pero son los servidores de Google Play los que realizan el ensamblaje final. Este proceso se llama Dynamic Delivery. Cuando un usuario pulsa 'Instalar' en la Play Store, los servidores de Google analizan su dispositivo específico: la arquitectura de su CPU (ABI), la densidad de pantalla y la configuración de idioma. Luego, construyen y sirven un conjunto personalizado de APKs divididos (split APKs) que contienen únicamente lo que ese dispositivo concreto necesita. Un Pixel 9 con Android 15 en inglés podría recibir una descarga de 38 MB, mientras que el antiguo APK monolítico habría pesado unos considerables 95 MB. La reducción de tamaño no es teórica; es significativa y medible. Los propios datos de Google de 2021 mostraron una reducción de tamaño promedio del 15% para las apps que se pasaron a AAB, y algunas llegaron a reducir su tamaño en más de un 50%. Para un juego con enormes atlas de texturas diseñados para diferentes formatos de compresión de GPU (como ETC2, ASTC y S3TC), el ahorro puede ser astronómico, eliminando fácilmente cientos de megabytes de la instalación final en el teléfono del usuario.
La estructura interna de un archivo AAB
Si abres un AAB con una utilidad ZIP, verás inmediatamente que no es un APK. En el nivel superior tiene un archivo BundleConfig.pb, que define la configuración del bundle, un directorio BUNDLE-METADATA y al menos un directorio de módulo. El módulo principal siempre se llama `base/`, y por dentro se parece un poco a un APK, con carpetas `dex/`, `manifest/`, `res/`, `root/` y `lib/`. Pero hay una diferencia fundamental: los recursos se almacenan en un formato proto `resources.pb`, no en el binario plano `resources.arsc` de un APK. Esta es una razón clave por la que un AAB no se puede instalar directamente. Otros módulos de funcionalidades (feature modules) aparecen junto al módulo `base/`, con nombres como `onboarding/` o `ar_features/`. Cada uno tiene su propio manifiesto y recursos, y se puede configurar para que se descargue en el momento de la instalación, justo después de instalar (fast-follow) o solo cuando se necesite. Este modelo bajo demanda (on-demand) es lo que permite que una app como Google Earth evite cargar a todos los usuarios con datos de ciudades en 3D, obteniéndolos a través de la biblioteca Play Core solo cuando alguien intenta ver una ciudad con esa cobertura. El directorio `lib/` dentro de cada módulo es donde ocurre la verdadera magia del ahorro de espacio. Un juego multiplataforma podría tener subdirectorios `arm64-v8a`, `armeabi-v7a` y `x86_64`, cada uno lleno de bibliotecas .so compiladas. Un APK monolítico los empaquetaría todos. Con un AAB, Dynamic Delivery se asegura de que solo se envíe el único directorio ABI que coincide. Para un juego con 80 MB de código nativo por ABI, eso es un ahorro instantáneo de 160 MB en un teléfono moderno de 64 bits que no tiene ningún uso para las bibliotecas de 32 bits o x86.
APK vs. AAB: Una comparación directa de lo que importa a los desarrolladores
Entonces, ¿qué significan estas diferencias en la práctica para los desarrolladores, el equipo de QA y los usuarios? Desglosemos la comparación según lo que realmente importa en tu trabajo diario. **Soporte de canales de distribución:** Google Play requiere AABs para las apps nuevas. Así de simple. Sin embargo, los AAB son una tecnología exclusiva de Google. Las tiendas de apps alternativas de Android como Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery y F-Droid requieren los viejos y conocidos APKs. Si distribuyes tu app fuera de Google Play, sigues en el negocio de los APK. No es un detalle menor, especialmente en mercados donde Google Play no está disponible y la distribución exclusiva por APK es el estándar. **Instalación directa:** No puedes instalar un AAB mediante 'sideloading'. Si intentas instalar uno con `adb install app.aab`, simplemente te dará un error. Para probar un AAB localmente, tienes que usar el `bundletool` de Google para generar un conjunto de APKs locales o usar la bandera `--local-testing` en tu compilación. Cualquiera que haya intentado que una persona no técnica pruebe una compilación sabe que añadir pasos adicionales es la receta para la frustración. Esto definitivamente añade fricción a los flujos de trabajo de QA. **Herramientas de compilación:** En Android Studio, creas un AAB con Build > Generate Signed Bundle/APK > Android App Bundle, o con la tarea `./gradlew bundleRelease`. Creas un APK con `./gradlew assembleRelease`. La mayoría de los equipos usan ambos, compilando APKs para pruebas internas y AABs para la subida final a la Play Store. **Tamaño del archivo en disco:** Aquí hay un punto de confusión común: tu archivo AAB casi siempre será más grande que tu APK. Un APK de 60 MB podría generar un AAB de 80 MB porque el AAB contiene los recursos para *todas* las configuraciones de dispositivo. El ahorro de tamaño solo aparece en el dispositivo del usuario después de que Google Play haya hecho su magia. **Modelo de seguridad:** Ambos formatos se firman, pero el proceso es diferente. Con los AAB, debes usar Play App Signing. Esto significa que subes tu bundle y Google vuelve a firmar los APKs divididos finales que genera con una clave que ellos gestionan. Aunque tú registras esta clave, al final es Google quien la custodia, un hecho que pone nerviosos a algunos equipos preocupados por la seguridad. Con los APKs, puedes controlar todo el proceso de firma con tus propias claves, sin necesidad de que Google intervenga.
Convertir entre APK y AAB: Qué es posible y qué no
Aquí es donde las respuestas honestas importan más que las promesas de marketing. Seamos directos: convertir un APK existente de vuelta a un AAB no es algo real, y deberías ser muy escéptico con cualquier herramienta que afirme poder hacerlo automáticamente. El problema es fundamental. Un AAB necesita la información fuente original: los archivos de recursos organizados por densidad de pantalla e idioma, la tabla de recursos en formato proto, la estructura de módulos. Todos esos datos se compilan, aplanan y optimizan hasta desaparecer cuando se crea un APK. El archivo `resources.arsc` en un APK es un 'blob' binario; la estructura original de carpetas `res/drawable-hdpi/` ha desaparecido. Intentar reconstruir eso a partir de un APK compilado no es una conversión; es un doloroso proceso de ingeniería inversa, y los resultados son casi siempre incompletos. CocoConvert está diseñado para operaciones de APK a APK. Puedes usarlo para reempaquetar, renombrar y, lo que es más útil, extraer el contenido de archivos APK para inspeccionarlos. Sube un APK y podrás extraer su manifiesto, ver su tabla de recursos o tomar assets específicos. Pero lo que CocoConvert no puede hacer es generar un AAB válido y listo para la Play Store a partir de un APK. Francamente, ninguna herramienta puede hacer esto de manera fiable si no tienes el proyecto con el código fuente original. Si has perdido el código fuente y solo tienes un APK, tu mejor opción es una herramienta como `apktool`. Puede descompilar el paquete a bytecode smali y darte una aproximación de los recursos, pero convertir eso de nuevo en un proyecto funcional que pueda compilarse como un AAB requiere una cantidad masiva de trabajo manual. Para lo que CocoConvert *sí* es realmente útil es para tareas que surgen constantemente en QA móvil e investigación de seguridad. Puedes convertir APKs a archivos ZIP para explorar su contenido, extraer imágenes o archivos de audio específicos, e incluso procesar por lotes una carpeta entera de APKs para auditarlos. Esos son los trabajos prácticos y del mundo real con los que podemos ayudarte.
El problema del 'sideloading' y por qué el APK no va a desaparecer
A pesar del gran impulso de Google por el AAB, el humilde APK no va a ninguna parte. Su durabilidad proviene de todos los casos de uso que existen completamente fuera del control de Google. El 'sideloading' (instalar un APK desde fuera de la Play Store) es una característica fundamental de Android, que se activa con una visita rápida a los ajustes de tu teléfono (normalmente en Ajustes > Aplicaciones > Acceso especial de apps > Instalar aplicaciones desconocidas, aunque la ruta varía). Y el ecosistema del 'sideloading' es masivo. APKMirror aloja APKs verificados de apps de la Play Store, permitiendo a los usuarios obtener actualizaciones antes de que un despliegue por fases les llegue o instalar versiones antiguas. Las herramientas de gestión de dispositivos móviles empresariales (MDM) de VMware y Microsoft distribuyen APKs a miles de dispositivos corporativos sin tocar nunca la Play Store. Las comunidades de 'modding' de juegos viven y respiran de los APKs modificados. Para los desarrolladores en regiones con acceso limitado a la Play Store, compartir APKs es el principal método de distribución. Para cualquiera de estos usuarios, el AAB es simplemente irrelevante. Es un formato que vive y muere dentro del jardín amurallado de Google. En el momento en que una app necesita ser compartida, desplegada o instalada fuera de ese ecosistema, tiene que ser un APK. Esto se está volviendo aún más relevante con las nuevas regulaciones. La Ley de Mercados Digitales de la UE está obligando tanto a Apple como a Google a abrirse a tiendas de aplicaciones alternativas. A medida que las tiendas de terceros para Android ganen terreno en Europa, necesitarán un formato universal para las subidas. Como no pueden aprovechar la infraestructura propietaria de Dynamic Delivery de Google, ese formato será el APK. Irónicamente, esto podría llevar a un resurgimiento de la importancia del APK en algunos de los mercados más grandes del mundo, incluso mientras Google redobla su apuesta por el AAB para su propia tienda.
Recomendaciones prácticas según tu situación
Vayamos al grano. El formato correcto depende enteramente de lo que estés intentando hacer. Aquí tienes una guía sin rodeos basada en tu rol. **Si vas a publicar una app nueva en Google Play:** No tienes opción. Debes enviar un AAB para cualquier app nueva desde agosto de 2021. Configura Play App Signing en la Play Console (Configuración > Integridad de la app), ajusta tu configuración de firma de Gradle y ejecuta `./gradlew bundleRelease`. Asegúrate de probarlo localmente con `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` seguido de `bundletool install-apks --apks=app.apks`. **Si distribuyes a dispositivos empresariales vía MDM:** Quédate con los APKs. Compila uno con `./gradlew assembleRelease`. Tu solución MDM envía el APK directamente a los dispositivos. Usar un AAB aquí no aporta ningún valor y solo crea dolores de cabeza. **Si distribuyes a tiendas de apps alternativas:** Compila APKs. La Amazon Appstore, por ejemplo, tiene su propio portal de desarrollador para subir APKs y su propia lógica para la segmentación de dispositivos. No usan el sistema de Google. **Si eres un ingeniero de QA probando una compilación:** Usa APKs para tus 'smoke tests' diarios y pruebas de regresión; son rápidos y se instalan directamente con `adb install`. Para la validación final antes del lanzamiento, deberías compilar un AAB y usar `bundletool` para asegurarte de que estás probando lo que los usuarios realmente recibirán de la Play Store. **Si necesitas inspeccionar un APK que has recibido:** Puedes subirlo a CocoConvert para extraer rápidamente su contenido, o usar el propio APK Analyzer de Android Studio (Build > Analyze APK). El analizador ofrece un desglose visual excelente de los tamaños de archivo y es perfecto para comparar dos compilaciones diferentes y ver qué ha cambiado. En última instancia, el debate de APK vs. AAB no trata sobre qué formato es técnicamente superior en el vacío. Se trata de logística. La elección correcta viene determinada por tu canal de distribución y tus herramientas. Ambos formatos han llegado para quedarse, sirviendo a diferentes caminos en el extenso ecosistema de Android.