La fragmentación real

La fragmentación es el tópico más repetido sobre Android y también el peor entendido. Se suele reducir a un problema de versiones del sistema, como si bastara con elegir bien un número para tenerla domada, cuando en la práctica ese es el eje más fácil de los cuatro que existen. Los otros tres —las capas que cada fabricante superpone, la diversidad brutal de hardware y pantallas, y las políticas de energía que cada marca aplica a su manera— no se resuelven con una línea del fichero de compilación, no aparecen en ninguna tabla oficial y son los que provocan los informes de fallos que solo ocurren en un modelo concreto de un país concreto. Esta lección pone cifras donde suele haber anécdotas, y convierte el miedo difuso a la fragmentación en una estrategia de pruebas con prioridades.

Los números y de dónde salen

Empecemos por el eje del que todo el mundo habla, aunque acabe siendo el menos problemático, porque es el único que se puede citar con cifras.

A mediados de 2026 el reparto es más plano de lo que la gente supone. Android 16, publicado un año antes, ronda la cuarta parte del parque medido por tráfico web; Android 15 se queda por debajo, Android 14 y 13 conservan porciones nada despreciables, y Android 17 apenas asoma porque acaba de salir y todavía no ha llegado más que a los dispositivos de referencia. La lectura correcta no es cuál gana, sino que no hay una versión mayoritaria: la mediana del parque va tres o cuatro años por detrás de lo último.

Hay además un detalle metodológico que descarta la mitad de las discusiones de pasillo: no es lo mismo medir dispositivos que medir sesiones. Un parque donde el veinte por ciento de los aparatos son antiguos puede generar solo el cinco por ciento del uso, porque son dispositivos secundarios que se encienden poco. Y al revés: en algunos mercados los aparatos más modestos son los que más se usan, porque son el único ordenador que su dueño tiene. Antes de citar un porcentaje, pregunta siempre qué unidad hay debajo.

Esa última fila es la única que debería mover tu minSdk. Es habitual encontrar diferencias de más de treinta puntos porcentuales entre dos fuentes públicas para la misma versión, y ninguna de las dos miente: miden poblaciones distintas. Una herramienta cuyos usuarios son desarrolladores tendrá un parque modernísimo; una app de mensajería con tracción en el sur de Asia tendrá una cola larga de dispositivos de gama baja y varios años de antigüedad. Decidir con la media mundial cuando tienes tus propios datos es sustituir información por folclore.

Los cuatro ejes, y cuál duele de verdad

Ordenarlos así no es un adorno pedagógico: es una asignación de presupuesto. El primer eje se cubre casi entero con decisiones de compilación y bibliotecas, y su coste tiende a cero con los años porque Jetpack absorbe cada nueva diferencia. El tercero se cubre con diseño, una vez, y a cambio te abre superficies enteras. El segundo y el cuarto no se cubren con nada que se compre ni se declare: exigen cambiar supuestos arquitectónicos y probar en hardware real. Si tu plan contra la fragmentación consiste solo en elegir bien un minSdk, estás atacando el eje más barato y dejando intactos los dos que te van a generar los informes de fallos.

La razón de que el segundo eje sea el caro es estructural, y viene de la lección primera: la capa del fabricante es un fork parcial del framework, no un tema visual. Samsung, Xiaomi, la familia Oppo y OnePlus, Honor o el grupo Transsion mantienen su propia gestión de memoria y de procesos en segundo plano, y varias de ellas son notoriamente más agresivas que AOSP matando lo que no está en pantalla. Tu trabajo diferido puede no ejecutarse nunca, tu servicio en primer plano puede ser eliminado, y tu alarma exacta puede llegar tarde, todo ello sin que ningún registro te diga por qué.

flowchart TD
F[Fragmentacion]
F --> V[Versiones del sistema]
F --> C[Capas de fabricante]
F --> H[Hardware y pantallas]
F --> E[Politicas de energia]
V --> VS[Se resuelve con minSdk y Jetpack]
C --> CS[Se resuelve probando en dispositivos reales]
H --> HS[Se resuelve con diseno adaptativo]
E --> ES[Se resuelve delegando en WorkManager]
style VS fill:#a6e3a1,color:#11111b
style CS fill:#f38ba8,color:#11111b
style HS fill:#f9e2af,color:#11111b
style ES fill:#89b4fa,color:#11111b

Nada de esto es malicia. Un fabricante que vende millones de teléfonos de gama media con poca memoria compite en autonomía y en fluidez, y matar procesos ajenos es la palanca más directa que tiene para ganar en ambas. Su incentivo es legítimo y no va a desaparecer, así que la conclusión práctica no es indignarse sino diseñar contando con ello.

La defensa contra el eje de energía no es pelear con cada fabricante, sino no depender de que tu proceso siga vivo: delegar el trabajo que debe ocurrir sí o sí en los mecanismos que el sistema persiste por ti, y dar por muerto todo lo demás. La defensa contra el eje del hardware ya no es opcional desde que Android 16 empezó a ignorar las restricciones de orientación y redimensionado en pantallas de sw 600dp o más, y Android 17 retiró la escapatoria que quedaba: una interfaz que solo funcione en vertical y a un tamaño fijo hoy es, literalmente, una interfaz rota.

La pantalla dejó de ser un rectángulo fijo

De los cuatro ejes, el del hardware ha cambiado de naturaleza en los últimos dos años y merece un apartado propio. Durante una década bastó con dar por hecho un rectángulo vertical de unas cinco o seis pulgadas y tratar las tabletas como un caso raro. Eso se acabó por dos vías simultáneas. La primera es el mercado: plegables que pasan de un panel exterior estrecho a uno interior casi cuadrado sin cerrar la app, tabletas que han recuperado tracción, modos de escritorio con ventanas redimensionables y las primeras gafas con Android dentro. La segunda es normativa: la plataforma ha dejado de permitir que una app se declare rígida.

La consecuencia técnica es que el tamaño de tu ventana es una variable que cambia mientras la app corre, no una constante que se lee al arrancar. Fijar la orientación, cachear el ancho en el arranque o ramificar la interfaz por el modelo del dispositivo son ahora tres formas distintas de escribir un fallo. La respuesta correcta —clases de tamaño de ventana, paneles que se reorganizan, estado que sobrevive al cambio de configuración— es el contenido de un nivel entero más adelante; lo que toca ahora es aceptar la premisa y dejar de probar en un único tamaño.

Qué probar, dónde y en qué orden

Antes de la pirámide, una advertencia sobre la fuente de verdad que más se ignora: los informes de fallos de producción. Ninguna matriz de pruebas que diseñes tendrá la cobertura que ya te está dando, gratis y cada día, la telemetría de tus usuarios reales. Agrupar los fallos por modelo, por fabricante y por nivel de API convierte esa telemetría en la lista priorizada de dispositivos que deberías estar probando, y esa lista suele parecerse bastante poco a la que habrías escrito de memoria.

Para que ese agrupamiento sea posible hay que adjuntar el contexto en cada informe, y son cuatro campos que caben en una línea.

fun contextoDelDispositivo(): Map<String, String> = mapOf(
    "fabricante" to Build.MANUFACTURER,
    "modelo" to Build.MODEL,
    "api" to Build.VERSION.SDK_INT.toString(),
    "compilacion" to Build.FINGERPRINT,
)

La tentación es comprar un armario de teléfonos. La respuesta correcta es una pirámide donde cada nivel cuesta más y cubre menos, y donde el objetivo es empujar cada comprobación al nivel más barato que pueda detectarla.

El segundo nivel es el que más rendimiento da por hora invertida, porque convierte la matriz de versiones en algo reproducible y automático. Se declara en el propio fichero de compilación y la integración continua descarga, arranca y destruye cada emulador sin intervención humana.

testOptions {
    managedDevices.localDevices {
        create("apiMinima") { device = "Pixel 6"; apiLevel = 26 }
        create("apiActual") { device = "Pixel 8"; apiLevel = 36 }
        create("tableta")   { device = "Pixel Tablet"; apiLevel = 36 }
    }
}

Con eso, una sola tarea ejecuta la suite en el suelo, en el objetivo y en una pantalla grande. No cubre las capas de fabricante —ningún emulador lo hace— pero elimina de un plumazo la clase entera de fallos que dependen del nivel de API, que es la más frecuente y la más barata de encontrar.

La regla de selección para los dos últimos niveles es la que casi nadie aplica: no elijas los dispositivos que te gustan, elige los que tienen tus usuarios. Ordena tu analítica por modelo, coge los tres primeros y el percentil más bajo de memoria disponible, y prueba ahí. Añade un plegable y una tableta si tu producto tiene alguna vida fuera del móvil, que en 2026 es casi siempre. Y no descartes el dispositivo lento por ser poco representativo de tu equipo: es donde aparecen antes los problemas de rendimiento que en un aparato potente quedan enmascarados, así que sirve de amplificador además de servir de cobertura. Y prueba al menos una vez con una capa notoriamente agresiva en segundo plano, porque es donde aparecerán los fallos que ningún emulador va a reproducirte jamás.