U
Usuario eliminado 365408
Durante bastante tiempo, publicar una aplicación en Google Play consistía, a grandes rasgos, en cumplir las políticas, mantener actualizado el nivel de API, completar las declaraciones correspondientes y entregar una versión razonablemente estable. Si la aplicación abría, no fallaba demasiado y no utilizaba permisos conflictivos, buena parte del trabajo estaba resuelta.
Eso está cambiando.
Google comenzó a darle mucho más peso al comportamiento real de las aplicaciones una vez instaladas. Ya no alcanza con que una app funcione correctamente durante una prueba rápida. También importa cuánta memoria utiliza, cuánto código innecesario arrastra, qué hace cuando queda en segundo plano, cuánto tarda en iniciar y si mantiene activo el procesador sin una razón válida.
En otras palabras, Play Store está empezando a mirar la eficiencia como parte de la calidad.
Uno de los cambios más visibles tiene que ver con R8. Muchos desarrolladores lo conocemos principalmente como la herramienta que reduce y ofusca el código antes de generar una versión de producción. Durante años fue común desactivarlo cuando aparecía algún problema con una librería, una clase cargada por reflexión o una configuración difícil de rastrear. La aplicación pesaba un poco más, pero compilaba y funcionaba.
Ahora esa decisión puede tener otras consecuencias.
R8 no solamente cambia nombres de clases para dificultar la lectura del código. También elimina partes que no se utilizan, reduce el tamaño de los archivos DEX, optimiza métodos y disminuye la cantidad de trabajo que la aplicación debe realizar durante su ejecución. Esto puede traducirse en menos memoria ocupada, un inicio más rápido y una menor posibilidad de bloqueos o errores ANR.
Google Play ya puede analizar el nivel de optimización, reducción y ofuscación del código incluido en un App Bundle. Para aplicaciones con más de 10 MB de código DEX se establece un nivel mínimo esperado. No significa que toda aplicación con R8 desactivado vaya a ser rechazada automáticamente, pero sí que una optimización insuficiente puede aparecer en Android vitals y, más adelante, afectar su visibilidad dentro de la tienda.
También comenzó a cobrar importancia el consumo de energía. En las aplicaciones móviles comunes, Google no está midiendo simplemente qué porcentaje de batería gasta cada app. El control se concentra especialmente en los llamados wake locks, que permiten mantener activo el procesador aunque la pantalla esté apagada o la aplicación se encuentre en segundo plano.
Un wake lock puede ser necesario para reproducir audio, completar determinadas tareas o mantener una función que el usuario está utilizando. El problema aparece cuando queda retenido durante demasiado tiempo, cuando un servicio continúa ejecutándose sin necesidad o cuando una tarea en segundo plano despierta constantemente el dispositivo.
Android vitals considera excesivo que estos bloqueos parciales acumulen dos horas o más dentro de un período de 24 horas, siempre que no pertenezcan a alguno de los casos exceptuados. Si este comportamiento afecta a más del cinco por ciento de las sesiones medidas, la aplicación puede perder visibilidad en Google Play.
Esto obliga a revisar con más cuidado servicios en primer plano, sincronizaciones, tareas periódicas, actualizaciones de ubicación, conexiones de red y procesos que antes podían quedar funcionando casi por costumbre. Una aplicación puede verse perfectamente estable y, sin embargo, estar consumiendo recursos innecesarios mientras el usuario ni siquiera la está mirando.
La memoria es otro punto que deja de ser un detalle interno. Google ahora diferencia el consumo según la cantidad de RAM del dispositivo y el estado en el que se encuentra la aplicación. También observa por separado la memoria utilizada por mapas de bits, algo especialmente importante en apps con fotografías, catálogos, galerías, cámaras o interfaces cargadas de imágenes.
En un teléfono moderno con bastante memoria, una mala gestión puede pasar inadvertida. En un equipo más limitado, la misma aplicación puede generar cierres, recargas constantes de pantallas o una experiencia lenta. El hecho de que funcione bien en el dispositivo del desarrollador ya no es una prueba suficiente.
Los errores percibidos por el usuario continúan teniendo un peso central. Play sigue controlando cierres inesperados y ANR, pero ahora esas métricas forman parte de una evaluación más amplia que incluye estabilidad, batería, memoria y optimización. Incluso puede detectar problemas concentrados en un modelo específico de teléfono, aunque el promedio general de la aplicación parezca aceptable.
A esto se suma la actualización obligatoria del nivel de API. Desde el 31 de agosto de 2026, las nuevas aplicaciones y sus actualizaciones deben apuntar a Android 16, API 36, para poder presentarse en Google Play. Las aplicaciones existentes también necesitan mantenerse dentro de los niveles admitidos si pretenden seguir apareciendo para usuarios con dispositivos nuevos.
El cambio importante no está solamente en estas fechas. Lo que se está modificando es el criterio general de la tienda.
Play Store ya no funciona únicamente como un lugar donde se sube un archivo AAB y se espera una aprobación. Cada vez interviene más como un sistema que observa el comportamiento de las aplicaciones instaladas y utiliza esos resultados para decidir cuánto alcance darles.
A partir de febrero de 2027, superar ciertos límites de memoria, uso de mapas de bits o falta de optimización del código podrá tener un efecto directo sobre la visibilidad. Por eso conviene empezar a revisar estos datos ahora y no cuando aparezca una advertencia en la consola.
Para quienes desarrollamos solos o trabajamos con recursos limitados, esto agrega otra capa de complejidad. Activar R8 puede descubrir reglas mal configuradas. Reducir memoria puede obligar a replantear la carga de imágenes. Corregir tareas en segundo plano requiere probar comportamientos que no siempre son fáciles de reproducir. Y actualizar el nivel de API suele traer cambios adicionales en permisos, servicios y compatibilidad.
Sin embargo, también hay una lógica razonable detrás de estas exigencias. El usuario no sabe qué es un archivo DEX, un wake lock o una regla de ProGuard. Solamente nota que una aplicación tarda, consume batería, se cierra o vuelve lento su teléfono.
El nuevo estándar de Google Play intenta medir justamente eso: no solamente si una aplicación funciona, sino cuánto cuesta mantenerla funcionando dentro del dispositivo del usuario.
