APK frente a App Bundle: entrega por dispositivo

Durante una década, publicar una app significaba subir un APK que contenía todo para todos: los iconos de las seis densidades, los textos de los ochenta idiomas, las librerías nativas de las cuatro arquitecturas. Cada usuario descargaba el conjunto completo y usaba una fracción. El AAB rompió ese modelo: subes un formato intermedio que no es instalable, y la tienda genera y firma en el servidor el paquete exacto que necesita cada dispositivo. Es el cambio con más impacto sobre el tamaño de descarga que ha tenido la plataforma, y trajo consigo una forma nueva de pensar la modularidad.

Qué es un AAB y en qué se diferencia de un APK

Un AAB es un archivo de publicación, no de instalación. Contiene el código y los recursos de la app organizados por módulo y ya separados en dimensiones —código, recursos por densidad, recursos por idioma, librerías por arquitectura—, junto con metadatos que describen cómo puede trocearse. Ningún dispositivo puede instalarlo directamente: es materia prima para que la tienda fabrique paquetes.

mi-app.aab
  base/
    manifest/           manifiesto del modulo base
    dex/                codigo en DEX
    res/                recursos con sus calificadores
    lib/                librerias nativas por arquitectura
    assets/
  caracteristica_mapas/ modulo adicional con la misma estructura
  BUNDLE-METADATA/      metadatos de la herramienta de build

Cuando un usuario instala, la tienda mira el dispositivo —densidad de pantalla, idiomas configurados, arquitectura del procesador, versión del sistema— y genera un conjunto de paquetes divididos: uno base con el código común, y varios complementarios con exactamente la densidad, los idiomas y la arquitectura que hacen falta. Los firma con la clave real de la app y los entrega juntos. El sistema los instala como una única aplicación.

flowchart TD
DEV[Subes un AAB] --> PLAY[La tienda lo procesa]
PLAY --> GEN[Genera paquetes divididos]
GEN --> B[Paquete base con el codigo]
GEN --> D[Paquete de densidad concreta]
GEN --> I[Paquete de idiomas del usuario]
GEN --> A[Paquete de arquitectura del procesador]
B --> SIGN[Firma con la clave de la app]
D --> SIGN
I --> SIGN
A --> SIGN
SIGN --> INST[Instalacion en el dispositivo]

De aquí se deduce algo que sorprende la primera vez: la firma gestionada por la tienda no es opcional en este modelo, es su condición de posibilidad. Los paquetes divididos se fabrican en el servidor después de que tú subas nada, así que alguien en el servidor tiene que poder firmarlos, y ese alguien solo puede ser quien custodia la clave de la app.

La segunda consecuencia es que el paquete base y sus complementos no son apps independientes que colaboran: el sistema los trata como una instalación única, comparten proceso, identificador y clase R, y deben estar firmados con la misma clave y declarar la misma versión. Si alguno falta o desencaja, la instalación se rechaza entera. Esta cohesión es lo que permite que el código del módulo base referencie recursos que llegaron en un complemento sin enterarse de nada.

También cambia lo que puedes probar en local. Como el artefacto que subes no se instala, la única forma de ejecutar lo que recibirá un usuario es generar los paquetes divididos tú mismo con la herramienta oficial de bundles y desplegarlos como conjunto. Ese paso extra es la fuente del malentendido más común del formato: no es que el AAB esté roto cuando el dispositivo lo rechaza, es que nunca fue instalable.

Los tres ejes de división y lo que ahorran

La división automática opera sobre tres dimensiones, y cada una ahorra por una razón distinta. La densidad elimina las copias de mapas de bits que ese dispositivo nunca dibujaría: cinco escalones de icono se reducen a uno. El idioma elimina las cadenas de las lenguas que el usuario no tiene configuradas, lo que en apps muy traducidas es una porción sorprendente del total. La arquitectura elimina las librerías nativas de procesadores ajenos, y ese es el ahorro más brutal en apps con componentes en C o motores de juego, donde cada arquitectura puede pesar decenas de megabytes.

Este mecanismo también resolvió una limitación antigua: el techo de tamaño. Un APK subido a la tienda tenía un límite estricto que obligaba a los juegos grandes a distribuir archivos de expansión por separado, con toda la fragilidad que eso implicaba. Con AAB el límite se aplica a lo que descarga cada dispositivo, no al artefacto completo, y los archivos de expansión quedaron obsoletos.

Módulos: a demanda, condicional e instalado

Sobre la división automática se apoya la modularidad explícita. Un módulo de característica es un trozo de la app con su propio código y recursos que puede no formar parte de la instalación inicial. Su manifiesto declara el tipo de entrega, y ahí está toda la decisión.

<dist:module
    dist:instant="false"
    dist:title="@string/modulo_mapas">
    <dist:delivery>
        <dist:on-demand />
    </dist:delivery>
    <dist:fusing dist:include="true" />
</dist:module>

Pedir un módulo a demanda desde el código es una operación asíncrona con estados propios, y ese es exactamente el coste que introduce la modularidad dinámica.

val gestor = SplitInstallManagerFactory.create(context)
val peticion = SplitInstallRequest.newBuilder()
    .addModule("caracteristica_mapas")
    .build()

gestor.registerListener { estado ->
    when (estado.status()) {
        SplitInstallSessionStatus.DOWNLOADING -> mostrarProgreso(estado)
        SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION -> pedirConfirmacion(estado)
        SplitInstallSessionStatus.INSTALLED -> abrirPantallaDeMapas()
        SplitInstallSessionStatus.FAILED -> avisarDelError()
    }
}

gestor.startInstall(peticion)

Hay tres modos que conviene no confundir. La entrega a demanda deja el módulo fuera de la instalación y lo descarga cuando el código lo solicita explícitamente, lo que exige gestionar estados de descarga, errores y confirmación del usuario en descargas grandes. La entrega condicional lo incluye en la instalación solo si el dispositivo cumple criterios que declaras —una versión mínima del sistema, un país, una característica de hardware—. Y la entrega en tiempo de instalación lo incluye siempre, con lo que el módulo sirve únicamente para organizar el proyecto y acelerar compilaciones.

El tamaño real de descarga

Hay tres cifras distintas y confundirlas lleva a decisiones equivocadas. El tamaño del AAB que subes no le importa a nadie salvo a tu red. El tamaño de descarga es lo que el usuario baja: la suma de los paquetes divididos que le corresponden, ya comprimidos, y es la cifra que determina si alguien con datos limitados instala tu app o se arrepiente. El tamaño en disco tras instalar es mayor que ambos, porque incluye el código precompilado por el sistema y los datos de la app.

Para medirlo no hay que adivinar: existe una herramienta oficial que reproduce en local exactamente lo que la tienda haría, genera el conjunto de paquetes para una configuración de dispositivo concreta y calcula la descarga estimada. La consola de la tienda muestra además esa cifra por configuración una vez subes el artefacto.

Artefacto subido            AAB de 84 MB      irrelevante para el usuario
APK universal equivalente   78 MB             lo que se descargaba antes
Descarga real estimada      31 MB             base mas densidad, idioma y arquitectura
Ocupacion tras instalar      92 MB            incluye codigo precompilado por el sistema

Las tres primeras cifras explican por qué comparar el AAB con el APK antiguo no dice nada útil: son artefactos de naturaleza distinta y solo la tercera describe la experiencia de alguien instalando la app. La cuarta recuerda que la descarga no es el final del proceso, porque el sistema compila código nativo a partir del DEX y eso ocupa espacio adicional en el dispositivo.

Medir en local antes de publicar es la práctica que convierte el tamaño en algo gobernable, y hacerlo en la integración continua lo convierte en algo defendible: un umbral que falla la compilación cuando la descarga crece más de lo aceptable detiene la degradación silenciosa que sufren todas las apps con el paso de los años.