Android 17 se pone serio con las apps que consumen demasiada RAM

Te pasa a menudo: cambias de WhatsApp a Instagram, luego abres el banco, cierras todo y al volver a Instagram te carga de cero. O peor, la app simplemente desapareció. No es que tu teléfono vaya mal. Es que Android ha tenido que matar el proceso para liberar memoria y, cuando lo hace, pierdes el estado, la posición del scroll y el progreso del juego.

Ese mecanismo ya existía. Lo que cambia con Android 17 es que Google va a poner un límite claro y medible basado en la RAM total del dispositivo, y si una app lo supera, el sistema la mata directamente. Sin stack trace. Sin aviso previo.

La entrada oficial se publicó el 2 de junio de 2026 en el blog de Android Developers, y detrás hay un problema que afecta a todo el ecosistema: una sola app con fugas de memoria o consumo descontrolado puede arruinar la experiencia de todo el teléfono.

Qué cambia con Android 17

Android siempre ha gestionado la memoria de forma agresiva. Cuando el sistema se queda sin RAM disponible, recurre al Low Memory Killer (LMK) para terminar procesos en segundo plano y liberar espacio. El problema es que este mecanismo puede generar cierres en cascada.

Imagina una app que tiene una fuga de memoria y además está ejecutando un servicio en primer plano. Al estar en primer plano, está protegida del LMK. Pero mientras crece sin control, el sistema se ve obligado a compensar matando decenas de apps pequeñas y trabajos en segundo plano que están bien comportados. Una sola app "mala" destruye la multitarea de todo el dispositivo.

Con Android 17, Google introduce límites de memoria por app basados en la RAM total del dispositivo. Si una app supera ese límite, el sistema la termina directamente. No hay stack trace asociado: el motivo de salida se reporta como REASON_OTHER con la descripción "MemoryLimiter:AnonSwap" dentro de ApplicationExitInfo.

Esto no es una sugerencia. Es una regla del sistema. Y tiene consecuencias directas para el usuario medio.

Por qué esto importa si no eres desarrollador

Cuando una app se acerca a sus límites de memoria heap, se activan recogidas de basura frecuentes que se notan como tirones en la interfaz. Cuando el dispositivo se queda sin memoria disponible, el sistema se pone a reclaim pages de forma agresiva, lo que genera más carga de CPU, latencia en la interfaz y, lo que duele más, más consumo de batería.

Si la escasez de memoria es demasiado severa, se producen eventos LMK que terminan procesos en segundo plano de forma abrupta. El resultado: arranques en frío lentos, pérdida de estado del usuario, posiciones de scroll borradas y progreso de juegos perdido.

En resumen: una app que consume demasiada memoria no solo se queda ella corta. Degrada la estabilidad de todo el teléfono, incluida la autonomía.

Qué tendrán que hacer las apps

Google no se limita a anunciar la regla. También está dando herramientas concretas a los desarrolladores para que las apps se adapten. Las recomendaciones oficiales se centran en cinco áreas:

Optimización de bytecode con R8. Activar el optimizador R8 reduce significativamente la huella de memoria al eliminar código y recursos no utilizados. El caso de Monzo es ilustrativo: con R8 activado al máximo, la app bancaria redujo un 35% su tasa de ANR (aplicaciones no responden), mejoró un 30% la tasa de arranque en frío y redujo un 9% el tamaño total de la app.

Carga de imágenes optimizada. Los bitmaps son habitualmente los objetos más grandes en memoria. Una imagen comprimida de 100 KB puede convertirse en varios megabytes de RAM al decodificarse. Google recomienda usar librerías como Coil para proyectos Kotlin o Glide para Java, con downsampling automático, configuración de formato de píxel adecuada (RGB_565 cuando no se necesita transparencia) y reutilización de bitmaps cuando ya no se necesitan.

Detección de fugas de memoria. Android Studio Panda 3 incluye un profiler dedicado de LeakCanary que permite analizar fugas de memoria en tiempo real directamente desde el IDE. Una fuga es cuando el código mantiene referencias a objetos que ya no se usan, impidiendo que el Garbage Collector recupere esa memoria.

Limpieza de memoria al salir de primer plano. Cuando una app deja de estar visible, debería liberar recursos que no necesita inmediatamente. Es una práctica que ya se recomienda desde hace años, pero que Android 17 hace obligatoria de facto.

Observabilidad con ProfilingManager. Los desarrolladores pueden usar trigger-based profiling con TRIGGER_TYPE_ANOMALY para capturar automáticamente heap dumps cuando se alcanza el límite de memoria. Esto permite diagnosticar exactamente qué está pasando en condiciones reales de uso, no solo en entornos de prueba.

Además, Google ha expandido su documentación sobre límites de memoria e incluye comandos de depuración local para simular restricciones de memoria en el entorno de desarrollo y validar el comportamiento de la aplicación bajo cualquier límite.

Mi lectura: buena noticia, con una pega

Lo de Android 17 es, en el fondo, sentido común. Un solo proceso con fugas no debería poder secuestrar la memoria de todo el dispositivo y obligar al sistema a matar apps que están bien. Poner un límite basado en la RAM total del hardware es una regla predecible que beneficia a todo el mundo: usuario, sistema y desarrolladores responsables.

La pega es que esto no arregla de golpe todas las apps mal optimizadas. El límite no va a hacer magia: si una app está mal escrita, va a chocar contra la pared con más claridad, pero el usuario final seguirá viendo esa app cerrarse de repente.

Aunque, honestamente, eso ya pasaba. Lo que cambia es que ahora pasará de forma más predecible y el sistema será menos propenso a esos cierres en cascada que dejan el teléfono inutilizable durante unos minutos.

Ojo con esto: las apps que hayan invertido en optimización (R8, carga de imágenes, detección de fugas) van a notar una mejora real en estabilidad y batería. Las que no, se van a topar con un techo que antes no existía.