Qué es Android realmente

Preguntar qué es Android es como preguntar qué es un país: depende de si hablas del territorio, de las leyes o de la gente. Android es a la vez un proyecto de código abierto que cualquiera puede compilar, un conjunto de servicios propietarios que Google licencia, un documento de compatibilidad que define qué puede llamarse Android, y una pila de software donde cada capa la escribe una empresa distinta. Esa multiplicidad no es trivia: es la causa directa de casi todo lo que te va a resultar incómodo al programar aquí. El kernel que ejecuta tu app lo parcheó un fabricante de chips, la capa de sistema la retocó el fabricante del teléfono, y el runtime que interpreta tu bytecode puede haberse actualizado esta semana desde la tienda sin que el sistema operativo cambiase de versión. Entender esa arquitectura de responsabilidades repartidas es el primer paso para dejar de sorprenderte.

Una pila, no un sistema operativo

Antes de programar nada conviene saber sobre qué se está programando, y en Android esa respuesta tiene más profundidad de la que parece.

Lo que llamamos Android es una torre de capas donde cada una habla con la de abajo a través de una interfaz estable, y cada interfaz marca una frontera de responsabilidad empresarial. Abajo del todo hay un kernel Linux —una rama LTS con parches propios: el driver binder para la comunicación entre procesos, la gestión de wakelocks, el asesino por falta de memoria— sobre el que se apoya una capa de abstracción de hardware que aísla al resto del sistema del silicio concreto. Encima viven las bibliotecas nativas y el runtime, después el framework de servicios del sistema escrito en Java y Kotlin, y arriba las aplicaciones, tanto las del sistema como la tuya.

flowchart TB
APP[Apps del sistema y la tuya]
FW[Framework de servicios en Java y Kotlin]
ART[Runtime ART y bibliotecas nativas]
HAL[Capa de abstraccion de hardware]
KER[Kernel Linux con parches de Android]
HW[Silicio del fabricante]
APP --> FW --> ART --> HAL --> KER --> HW
style APP fill:#a6e3a1,color:#11111b
style ART fill:#f9e2af,color:#11111b
style KER fill:#89b4fa,color:#11111b

La pieza que hace que esa torre funcione como un sistema y no como capas sueltas es binder, el mecanismo de comunicación entre procesos que Android añadió al kernel. Casi todo lo que tu app hace de interesante ocurre en otro proceso: pedir una ubicación, mostrar una ventana, reproducir audio o consultar la agenda son llamadas que cruzan una frontera de proceso y acaban en un servicio del sistema. El framework te presenta esas llamadas como métodos normales de objetos normales, pero debajo hay una transacción con un límite de tamaño, una cola de hilos y una posibilidad real de fallo. Muchas de las rarezas que encontrarás más adelante —por qué no puedes pasar un objeto grande en un Intent, por qué un cursor de base de datos ajena se lee por trozos— son consecuencias directas de esa frontera.

Todo eso es AOSP, el Android Open Source Project: código abierto que cualquiera puede descargar y compilar. Lo que no está ahí son los Google Mobile Services —Play Store, Play Services, Maps, el motor de notificaciones push—, que se licencian aparte y solo a fabricantes que superen la batería de pruebas de compatibilidad. De ahí la distinción práctica que separa a un teléfono europeo de un Amazon Fire o de un modelo doméstico chino: todos ejecutan Android en el sentido de AOSP, pero solo unos cuantos tienen el ecosistema de Google encima.

Esa separación no es un capricho comercial, tiene una función técnica clara. Al dejar fuera de AOSP los servicios de Google, esas piezas pueden actualizarse por la tienda en cualquier momento, con independencia del sistema y del fabricante. Es el mismo principio que más adelante llevará a los módulos de Mainline, y es la razón de que APIs muy usadas —ubicación fusionada, notificaciones push, autenticación— hayan podido evolucionar durante años en dispositivos que el sistema operativo dejó de actualizar hace tiempo.

ART y el viaje que hace tu código

Con la pila situada, toca seguir el camino que hace tu propio código desde que lo escribes hasta que se ejecuta, porque casi todas las decisiones de rendimiento que tomarás más adelante se apoyan en ese recorrido.

Tu Kotlin no llega al dispositivo como Kotlin. El compilador produce bytecode de la JVM, R8 lo reduce, lo ofusca y lo traduce al formato DEX, y ese DEX viaja dentro del paquete. Al otro lado espera ART, el Android Runtime, que no elige entre interpretar y compilar sino que hace las dos cosas según lo que observe. Arranca interpretando, un compilador JIT traduce a código nativo lo que se ejecuta mucho, y el runtime va anotando en un perfil qué métodos resultaron calientes. En momentos de reposo, con el dispositivo cargando, dex2oat compila ese perfil de forma anticipada para que la próxima ejecución arranque ya en código nativo.

# Estado de compilacion de una app instalada
adb shell dumpsys package dexopt | grep -A 3 com.ejemplo.app

# Forzar la compilacion guiada por perfil, como haria el sistema en reposo
adb shell cmd package compile -m speed-profile -f com.ejemplo.app

# Volver al estado de recien instalada, util para medir el arranque en frio
adb shell cmd package compile --reset com.ejemplo.app

Conviene detenerse en el formato intermedio, porque explica decisiones que verás en el sistema de compilación. DEX no es bytecode de la JVM renombrado: usa registros en lugar de una pila, agrupa todas las clases en un mismo fichero con tablas compartidas de cadenas y de tipos, y está diseñado para ocupar poco y cargarse mediante proyección en memoria. De ahí sale el famoso límite histórico de sesenta y cinco mil métodos por fichero, que hoy se resuelve partiendo en varios DEX, y de ahí sale también que reducir el número de métodos que arrastras no sea una manía de purista sino algo que se nota en el tamaño y en el arranque.

Ese bucle explica dos cosas que verás más adelante. La primera, los Baseline Profiles: un perfil que tú generas en desarrollo y empaquetas con la app, para que el primer arranque en el dispositivo del usuario no empiece desde cero. La segunda, los perfiles agregados en la nube, que Play construye con los datos de tus propios usuarios y distribuye al resto. La consecuencia práctica es que medir el arranque de tu app recién instalada en tu móvil de desarrollo no mide lo que vive un usuario real: mide el peor caso.

Falta una pieza para cerrar el recorrido, y es de dónde sale el proceso que ejecuta todo eso. Tu app no arranca una máquina virtual desde cero: el sistema mantiene vivo un proceso plantilla, encendido durante el arranque del dispositivo, que ya tiene cargadas y compartidas las clases del framework y los recursos comunes. Cuando el usuario toca tu icono, el sistema bifurca ese proceso y le da la identidad de tu app. Por eso una app arranca en cientos de milisegundos y no en varios segundos, y por eso la memoria del framework se contabiliza una sola vez aunque haya veinte apps abiertas. También por eso tu proceso hereda un estado que tú no inicializaste, un detalle que reaparecerá cuando estudies el ciclo de vida.

Queda un matiz que cierra el cuadro y que separa a ART de una máquina virtual de servidor: aquí la compilación no persigue el máximo rendimiento en régimen permanente, sino un equilibrio entre arranque, memoria, tamaño en disco y batería. Compilar todo de forma anticipada haría que las apps ocuparan mucho más y que la instalación tardara una eternidad; no compilar nada dejaría el arranque en manos del intérprete. El sistema de perfiles es la respuesta a ese compromiso: compilar solo lo que se demuestra caliente, y hacerlo cuando el dispositivo está enchufado y ocioso.

Treble, GKI y Mainline: el sistema que se actualiza a trozos

Este es el apartado que explica por qué durante años Android tuvo fama de no actualizarse, y por qué esa fama está quedando desfasada. Durante años, actualizar Android era imposible porque todo estaba entrelazado: cambiar la versión del framework obligaba a recompilar el código del fabricante del chip. Project Treble partió esa unión con una interfaz de proveedor estable, de modo que el framework puede subir de versión sin tocar la implementación de hardware. El Generic Kernel Image dio el siguiente paso: un kernel común mantenido por Google, con lo específico de cada fabricante empujado a módulos cargables.

El orden histórico de esos tres movimientos no es casual y dibuja una estrategia clara. Treble separó al framework del proveedor de hardware, que era la unión más rígida. El kernel genérico separó el núcleo común de los añadidos de cada fabricante de chips, que era la siguiente. Y Mainline fue directamente a por el resto, sacando componentes concretos de la actualización del sistema para meterlos en la tienda. Cada paso mueve una pieza más desde el lado que actualiza despacio hacia el lado que actualiza rápido.

La comparación con el mundo del que vienes ayuda a medir el logro: un ecosistema con un único fabricante puede actualizar todos sus dispositivos a la vez porque controla la pila entera. Android tuvo que inventar fronteras estables donde otros tienen integración vertical, y estos tres proyectos son precisamente esas fronteras.

Mainline completó la jugada convirtiendo docenas de componentes del sistema —el propio ART, el códec de medios, la resolución de DNS, el stack de conectividad— en módulos actualizables que llegan por la tienda, no por una actualización del sistema. Ese reparto también reordena la responsabilidad de la seguridad. Un fallo en el descodificador de vídeo o en la resolución de nombres ya no exige que el fabricante prepare, valide y distribuya una actualización completa del sistema, proceso que históricamente tardaba meses o no llegaba nunca a los dispositivos de gama media. Hoy llega como una actualización de módulo, por el mismo canal que una app, y alcanza a dispositivos cuyo fabricante hace años que dejó de mantenerlos.

La consecuencia es contraintuitiva y conviene interiorizarla: el nivel de API que declara un dispositivo ya no describe con exactitud el código que ejecuta. Un teléfono anclado en una versión antigua puede llevar un runtime y unos códecs de hace un mes.

Las capas de los fabricantes y quién define Android

Falta la capa de arriba del todo, la que el usuario ve y la que más te va a sorprender cuando llegue un informe de fallo.

Sobre AOSP, cada fabricante superpone su propia capa: no es un tema, es un fork parcial del framework con servicios añadidos, políticas de energía propias y a veces comportamientos que se apartan del estándar. Samsung, Xiaomi, la familia Oppo y OnePlus, Honor o el grupo Transsion —dominante en África y en el sur de Asia— mantienen cada uno la suya. Ninguna de esas capas está documentada para ti: sus diferencias no aparecen en la referencia oficial porque, formalmente, no existen.

La razón de que puedan hacerlo sin romperte es que el contrato define comportamientos observables, no implementaciones. Un fabricante puede reescribir por completo cómo decide qué proceso mata mientras siga respetando los ciclos de vida documentados; puede rehacer la persiana de notificaciones mientras los canales y sus importancias sigan funcionando. La libertad está donde no hay especificación, y ese espacio es exactamente el mapa de tus futuros informes de fallos irreproducibles.

Averiguar sobre qué capa estás corriendo es lo primero que harás cuando recibas un informe de fallo que no reproduces, y se hace con dos órdenes.

# Quien fabrico el dispositivo y que compilacion exacta lleva
adb shell getprop ro.product.manufacturer
adb shell getprop ro.build.fingerprint

# Politicas de energia en vigor ahora mismo, la fuente de la mitad de los misterios
adb shell dumpsys deviceidle | head -30

Lo único que impide que esa diversidad haga inviable programar es el contrato: el documento de definición de compatibilidad, verificado por suites de pruebas automatizadas que un fabricante debe superar para licenciar los servicios de Google. Ese contrato es la razón de que tu app funcione en un teléfono que nunca has visto.

Y también marca el límite de lo que puedes esperar. El contrato garantiza que las APIs públicas existan y se comporten como está documentado, pero no dice nada sobre lo que no está especificado: cuánto vive tu proceso cuando el usuario cambia de app, en qué orden se entregan dos notificaciones simultáneas o si una alarma llega con diez segundos de retraso. Ahí cada fabricante decide, y ahí es donde aparecen los informes de fallos imposibles de reproducir. La conclusión práctica para lo que viene después del nivel es doble: apóyate solo en lo documentado, y trata cualquier comportamiento observado en un dispositivo concreto como una hipótesis, no como una regla.