Google va a extender a todo Android 17 el límite de memoria por aplicación que ya venía probando en los Pixel: si una app se pasa del presupuesto que el sistema le asignó, primero la empuja a memoria comprimida (zRAM) y, si aun así sigue excedida, le termina el proceso. Según la nota de Hipertextual, la intención es que funcione en cualquier equipo compatible con Android 17, desde 4 GB de RAM hasta más de 16 GB, y que llegue a móviles de otros fabricantes a partir de 2027.
Por qué importa
La señal no es técnica, es económica. Durante quince años el modelo mental de quien desarrolla para móvil fue que la RAM crece sola: si tu app consume de más, el año que viene el hardware te lo perdona. Ese contrato implícito se rompe. Los precios de la memoria subieron y los fabricantes están recortando GB para no mover el precio de venta, así que la plataforma hace lo único que puede hacer: dejar de absorber el desperdicio del software y devolvérselo a quien lo genera.
El segundo detalle es más interesante que el titular. Que la función apunte a todo el rango de dispositivos, y no solo a la gama baja, significa que no es un modo de emergencia para equipos flojos: es una política de presupuesto por proceso. La RAM deja de ser un recurso elástico que negociás con el sistema y pasa a ser una cuota que ya está fijada antes de que tu código arranque. El material publicado no informa cuáles son los valores concretos de ese presupuesto, ni qué marcas ni qué modelos lo van a recibir primero, así que cualquier número que leas por ahí hoy es especulación.
Qué cambia en la práctica
Lo primero: el proceso en segundo plano deja de ser un lugar donde guardar estado. Ya era frágil, pero pasaba por caso raro. Con un mecanismo que mata procesos por presupuesto excedido, la muerte del proceso pasa a ser un camino normal de ejecución. Si tu app tiene un borrador sin guardar, un carrito en memoria, una posición de scroll, un token en una variable de instancia o un formulario a medio llenar, eso ahora se pierde de forma rutinaria.
Lo segundo, y es lo que más va a confundir en producción: la primera etapa no rompe nada, lo hace lento. Comprimir páginas a zRAM cambia presión de memoria por ciclos de CPU. El síntoma no va a llegar como un crash con stack trace, sino como jank, animaciones que se cortan y batería que se va. Vas a estar debuggeando la capa de render mientras el problema real está en cuánta memoria retenés.
Tercero: el presupuesto es del proceso, no de tu código. Ahí adentro entran el WebView, el runtime de JavaScript si usás Capacitor o React Native, el caché de imágenes, el SDK de analytics, el de ads, el de crash reporting y las tres librerías que alguien agregó para una pantalla. En apps híbridas esto pega doble, porque cargás el heap nativo y el heap de la VM de JS al mismo tiempo.
Del lado del backend, la consecuencia práctica es que tu API tiene que tolerar clientes que desaparecen sin avisar: subidas por chunks reanudables, escrituras idempotentes con clave de operación, sincronización por cursor en lugar de por sesión larga, y nada de asumir que un socket abierto va a seguir vivo cuando el usuario cambia de app.
En Android nativo hay una herramienta que ya existe y que casi nadie implementa en serio:
override fun onTrimMemory(level: Int) {
if (level >= TRIM_MEMORY_RUNNING_LOW) {
imageCache.evictAll()
draftRepository.persistNow() // el proceso puede no volver
}
}La regla que yo aplicaría: todo estado que el usuario generó con esfuerzo se persiste apenas la app pierde el foco, no cuando el usuario aprieta guardar.
Cuándo NO usarlo
Esto no es una feature que adoptás, es una restricción que te va a llegar. Y hay varias razones honestas para no salir corriendo a rearquitecturar esta semana.
- No hay umbrales publicados. Sin los valores concretos del presupuesto por app, optimizar es tuning a ciegas. Podés pasar dos sprints bajando 30 MB que nunca importaron, o quedarte corto contra un límite que resulta ser más estricto de lo que asumiste.
- El calendario juega en contra de la urgencia. El despliegue a fabricantes de terceros arranca en 2027, y tu base instalada se mueve todavía más lento. Alcanza con mirar cómo funciona el ciclo de vida real de los equipos: Xiaomi acaba de sumar seis modelos a su lista EOL, que dejan de recibir versiones de Android y parches. Una porción grande de tus usuarios no va a ver Android 17 nunca.
- No cambies memoria por red sin medir. La reacción refleja es vaciar cachés y recargar todo de la API. En un usuario con datos móviles limitados eso empeora la experiencia real y te sube la factura de infraestructura para resolver un problema que quizás tu app no tiene.
- Si tu app es de sesión corta en primer plano (un checkout, un lector, un tracker que corre y cierra), el riesgo concreto es bajo y el trabajo de rediseño no se paga.
- No inventes trucos anti-kill. Servicios foreground falsos, notificaciones persistentes de mentira o procesos hijos para escaparle al presupuesto son deuda que Google cierra en la versión siguiente, y mientras tanto te cuesta reviews en la store.
Qué haría hoy
Tres cosas, ninguna cara. Primero, medir consumo real en un equipo de gama media de verdad, no en un emulador con 16 GB, y anotar el número base para tener contra qué comparar cuando aparezcan los límites oficiales. Segundo, agregar al checklist de QA una prueba que hoy casi nadie corre: matar el proceso a mano con la app en segundo plano y verificar que el usuario vuelve exactamente donde estaba. Si esa prueba pasa, el límite de RAM te importa mucho menos.
Tercero, esperar los números. La arquitectura se toca cuando hay documentación con valores concretos, no cuando hay un anuncio. Lo que sí conviene internalizar ya es el cambio de mentalidad: la memoria dejó de ser gratis, y ese es un cambio permanente, no una función de una versión.