Los requisitos de calidad técnica de Google Play ayudan a ofrecer experiencias de alta calidad a los usuarios de tus aplicaciones en Google Play, como parte de los cuatro pilares de la calidad de las aplicaciones Android.
Los requisitos de calidad técnica de Google Play se dividen en dos categorías:
- Requisitos actuales: requisitos que se aplican actualmente. Cumplir estos estándares es fundamental para mantener la estabilidad, el rendimiento y la descubribilidad de tu aplicación en Google Play.
- Próximos requisitos: nuevos estándares anunciados con antelación. Aunque aún no son obligatorios, debes aprovechar el periodo de transición para evaluar tu aplicación, integrar las herramientas y las APIs recomendadas, y cumplir los requisitos antes de que empiecen a aplicarse.
Próximos requisitos
Tal como se anunció el 26 de agosto del 2026, próximamente se aplicarán requisitos de calidad técnica a las aplicaciones y los juegos que se publiquen en Google Play. En este artículo del Centro de Ayuda se ofrecen más detalles sobre los umbrales técnicos y se explica cómo prepararse para los nuevos requisitos antes de que entren en vigor.
Menor uso de memoria
A partir de febrero del 2027, las aplicaciones y los juegos de Google Play deberán cumplir nuevos umbrales de mal funcionamiento. Consulta los detalles específicos más abajo.
Optimización del código
A partir de febrero del 2027, las aplicaciones y los juegos de Google Play deberán cumplir umbrales de optimización. Consulta los detalles específicos más abajo.
Restauración del inicio de sesión sin toques
A partir de abril del 2027, las aplicaciones de Google Play deberán admitir la restauración de credenciales sin toques. Consulta los detalles específicos más abajo.
Menor uso de memoria
Google Play ha definido umbrales de mal funcionamiento para los Android vitals prioritarios de las aplicaciones. El uso de memoria se va a introducir como dos nuevas métricas de Android vitals prioritarios:
- Uso de memoria (RSS anónimo y espacio de intercambio)
- Uso de memoria de mapa de bits
Al igual que las métricas de Android vitals con umbrales de mal funcionamiento, Play usa los datos de los últimos 28 días para evaluar la calidad de tu aplicación.
Estas métricas están disponibles en el encabezado Memoria de la sección Información general de Android vitals, así como en la API Google Play Developer Reporting.
Estas métricas miden la cantidad de memoria que usa tu aplicación durante su ciclo de vida una vez que se carga desde el almacenamiento y se ejecuta, tanto en primer plano como en segundo plano.
Los valores de estas métricas se obtienen de los dispositivos de los usuarios que han dado su consentimiento, se anonimizan y se agregan. En Play Console, puedes ver varios percentiles de cada métrica, incluido el percentil 90, que se usa para evaluar el rendimiento de tu aplicación en comparación con los umbrales de mal funcionamiento. El valor del percentil 90 significa que el 10 % de las muestras recogidas durante un periodo de 1 día han tenido un número superior. Por ejemplo, un P90 de 1,7 GB indica que el 90 % de las muestras recogidas tenían un valor inferior a 1,7 GB y que el 10 % de las muestras recogidas tenían un valor superior a 1,7 GB.
Este requisito solo se aplica a los formatos de móvil y tablet.
Uso de memoria
El tamaño de conjunto residente anónimo (RSS anónimo) representa la memoria asignada directamente por tu aplicación (como el montículo de Java/Kotlin, las asignaciones de memoria nativa y las asignaciones de memoria anónima) que no se puede paginar en el disco sin espacio de intercambio. El espacio de intercambio representa la memoria comprimida o paginada en zRAM.
Los umbrales se adaptan a la categoría de tu aplicación (aplicaciones o juegos) y al nivel de RAM del dispositivo para reflejar las distintas restricciones de hardware. A partir de febrero del 2027, las aplicaciones y los juegos de Play deberán cumplir los siguientes umbrales:
Aplicaciones
| Estado de la aplicación | Primer plano | Servicios percibidos por los usuarios | Segundo plano | En caché |
| RAM física | Percentil 90 | Percentil 90 | Percentil 90 | Percentil 90 |
|
De 0 a 4 GB (De 0 a 3200 MB de memoria total) |
- | - | - | - |
|
4 GB (De 3200 a 4800 MB de memoria total) |
2 GB | 1 GB | 1 GB | - |
|
6 GB (De 4800 a 6800 MB de memoria total) |
2,25 GB | 1,25 GB | 1,25 GB | - |
|
8 GB (De 6800 a 9216 MB de memoria total) |
2,25 GB | 1,5 GB | 1,5 GB | - |
|
12 GB (De 9216 a 14.336 MB de memoria total) |
3,25 GB | 1,75 GB | 1,75 GB | - |
|
16 GB (De 14336 a 18.432 MB de memoria total) |
4,25 GB | 2 GB | 2 GB | - |
|
16 GB o más (Más de 18.432 MB de memoria total) |
- | - | - | - |
Nota: Cada intervalo de nivel de RAM incluye su valor más bajo. La memoria total puede ser inferior a la RAM física anunciada de un dispositivo.
Juegos
| Estado de la aplicación | Primer plano | Servicios percibidos por los usuarios | Segundo plano | En caché |
| RAM física | Percentil 90 | Percentil 90 | Percentil 90 | Percentil 90 |
|
De 0 a 4 GB (De 0 a 3200 MB de memoria total) |
- | - | - | - |
|
4 GB (De 3200 a 4800 MB de memoria total) |
2,25 GB | 2,0 GB | 2,0 GB | - |
|
6 GB (De 4800 a 6800 MB de memoria total) |
2,75 GB | 2,5 GB | 2,5 GB | - |
|
8 GB (De 6800 a 9216 MB de memoria total) |
3,5 GB | 2,75 GB | 2,75 GB | - |
|
12 GB (De 9216 a 14.336 MB de memoria total) |
4 GB | 3,2 GB | 3,2 GB | - |
|
16 GB (De 14336 a 18.432 MB de memoria total) |
5 GB | 3,5 GB | 3,5 GB | - |
|
16 GB o más (Más de 18.432 MB de memoria total) |
- | - | - | - |
Nota: Cada intervalo de nivel de RAM incluye su valor más bajo. La memoria total puede ser inferior a la RAM física anunciada de un dispositivo.
Uso de memoria de mapa de bits
Si se conservan mapas de bits durante largos periodos en estados de la aplicación que no sean el de primer plano, se puede consumir una cantidad excesiva de memoria. No es posible renderizar mapas de bits a menos que la UI esté visible. Normalmente, no deberías conservar mapas de bits durante largos periodos en estos estados, pero es posible que se muestree tu aplicación poco después de un cambio de estado en el que estés respondiendo activamente a onTrimMemory y liberando memoria de mapas de bits, por lo que estos umbrales son superiores a cero para tenerlo en cuenta.
| Estado de la aplicación | Percentil 90 |
| Primer plano | |
| Servicios percibidos por los usuarios | >200 MB |
| Segundo plano | >200 MB |
| En caché | >400 MB |
Optimización de código DEX
A partir de febrero del 2027, las aplicaciones y los juegos de Google Play deberán cumplir unos requisitos mínimos de optimización. Deberás conseguir un mínimo del 25 % de optimización, ofuscación y reducción en todas las aplicaciones que subas a Play Console. Somos conscientes de que no todas las aplicaciones o juegos hacen un uso intensivo del código DEX, por lo que este requisito solo se aplicará cuando los tamaños de DEX no sean insignificantes. Puedes ver el tamaño de DEX, así como los porcentajes de optimización de cada app bundle que subas en el explorador de app bundles de Play Console.
Este requisito se aplica a todos los formatos.
| Juegos | Aplicaciones | |||
| Optimización del código | Juegos con código DEX de más de 50 MB | Aplicaciones con código DEX de más de 10 MB | ||
| Ofuscación | 25 % | 25 % | ||
| Optimización | 25 % | 25 % | ||
| Reducción | 25 % | 25 % | ||
Puedes usar cualquier herramienta, como R8 u otro reductor de aplicaciones, para alcanzar los umbrales mínimos del 25 %.
Puedes usar el analizador de configuración de R8 para obtener más información y optimizar aún más el rendimiento. Ten en cuenta que, si publicas a través de flujos de procesamiento de CI/CD o en un entorno empresarial, es posible que tus compilaciones locales no coincidan perfectamente con la compilación que se sube a Play Console para distribuirla a los usuarios, por lo que es normal que haya algunas diferencias menores.
Restauración del inicio de sesión sin toques
A partir de abril del 2027, las aplicaciones que admitan el inicio de sesión de usuarios (opcional u obligatorio) deberán admitir la restauración del inicio de sesión sin toques cuando un usuario cambie de su dispositivo Android anterior a uno nuevo y seleccione restaurar sus datos mediante una transferencia de dispositivo a dispositivo o una copia de seguridad en la nube. Los inicios de sesión manuales durante la configuración de los dispositivos no solo dificultan la incorporación y reducen la retención de usuarios, sino que también exponen las aplicaciones a vulnerabilidades de seguridad críticas, como el phishing y el robo de credenciales, durante la configuración. La API Restore Credentials para Android es el método principal para solucionar estos problemas y cumplir este requisito, y está disponible en Android 9 y versiones posteriores.
- Las aplicaciones que se integren con Block Store antes del 30 de septiembre del 2026 o ese mismo día para restaurar el estado de inicio de sesión de un usuario se considerarán cumplidoras de este requisito.
- Las aplicaciones privadas de forma permanente y las aplicaciones de gestión de dispositivos empresariales están fuera del ámbito de este requisito.
- Las aplicaciones sujetas a normativas o requisitos de cumplimiento estrictos que afecten al funcionamiento de la función de inicio de sesión (por ejemplo, las de servicios financieros o atención sanitaria) pueden optar a una exención. Los desarrolladores deben enviar una solicitud de exención de este requisito a través de Play Console antes de la fecha de entrada en vigor.
- Actualmente, los juegos no están incluidos en este requisito. En el 2027, los desarrolladores recibirán orientación específica y soluciones personalizadas para casos prácticos complejos de autenticación en juegos. En el caso de los juegos que admiten una sola cuenta de usuario, te recomendamos que uses la API Restore Credentials para que los usuarios puedan iniciar sesión sin tener que tocar la pantalla.
En los próximos meses, se publicarán más detalles sobre este requisito y sus excepciones.
Integración y pruebas
Prueba la integración para asegurarte de que los usuarios disfruten de una experiencia fluida y de que cumples este requisito. La habilidad de IA para restaurar credenciales, publicada recientemente, puede ayudarte a integrarla más fácilmente.
Formatos y versiones de Android incluidos
Este requisito solo se aplica a los formatos de móvil y tablet. La API Restore Credentials no está disponible para otros formatos. Restore Credentials está disponible en Android 9 y versiones posteriores.
Preguntas frecuentes sobre los próximos requisitos
Requisitos de memoria
¿Por qué va a implementar Google requisitos de métricas de memoria?
Es inminente una crisis de memoria a nivel de todo el ecosistema debido al aumento de los costes de RAM. El uso ineficiente de la memoria, como una sola aplicación con una pérdida de memoria descontrolada que consume la mayor parte de la memoria del dispositivo, hace que el dispositivo se entrecorte y cierre otras aplicaciones que funcionan correctamente en segundo plano. Android ha anunciado límites de memoria estrictos y Google Play quiere asegurarse de que tu aplicación se ajuste a ellos y de que se minimicen las probabilidades de que el dispositivo tenga que cerrarla.
¿Cómo puedo reducir el uso de memoria?
Sigue las prácticas recomendadas para aplicaciones y juegos. Entre las estrategias clave se incluyen liberar recursos en onTrimMemory() (incluido el uso del motor de juego para hacerlo), evitar pérdidas de memoria estáticas usando componentes que tengan en cuenta el ciclo de vida, crear perfiles de asignaciones y volcados de montículo con Perfetto, y minimizar las tareas en segundo plano de larga duración.
¿Cómo puedo reducir mis asignaciones de mapa de bits?
Reduce la resolución y decodifica las imágenes para que coincidan con las dimensiones exactas de la vista de pantalla, usa bibliotecas de carga de imágenes modernas (como Coil o Glide) configuradas con cachés que tengan en cuenta la memoria, libera los mapas de bits en memoria que no se usen cuando se oculte la UI (mediante TRIM_MEMORY_UI_HIDDEN en onTrimMemory) y evita mantener referencias estáticas a mapas de bits o vistas.
¿Debo usar R8 para optimizar el código?
Aunque te recomendamos que uses R8 por sus optimizaciones y estadísticas avanzadas, hay otras herramientas de optimización disponibles que puedes usar para cumplir este requisito.
¿Por qué los requisitos son diferentes en las aplicaciones y los juegos?
Los juegos tienen diferentes patrones de uso de memoria para ofrecer una experiencia de juego fluida, principalmente en primer plano. A menudo se basan en motores de juego nativos que tienen limitaciones técnicas diferentes a las de las aplicaciones. Los requisitos de los juegos se adaptan al caso práctico.
¿Cómo distingue Google Play entre una aplicación y un juego?
Se basa en la categoría que puedes configurar en los ajustes de la tienda en Play Console, que influye en la parte de Play Store en la que aparece tu aplicación. Ten en cuenta que cambiar la categoría de tu aplicación a una que no refleje con precisión su función principal para intentar cumplir diferentes umbrales técnicos infringe la política de metadatos de fichas de Play Store.
¿Cómo se relacionan estos requisitos con el programa Experiencias de Aplicaciones y los programas Level Up?
Una vez que se apliquen estos umbrales de memoria, las aplicaciones y los juegos deberán cumplirlos todos para poder participar en el PEA y en Level Up, o para mantener su participación.
Los límites de memoria de Android se aplican a Android 17 y versiones posteriores. ¿Los requisitos de Play solo se aplican a Android 17 y versiones posteriores?
No, Google Play evalúa todas las versiones de tu aplicación en las que haya datos disponibles. Esto se aplica a Android 13 y versiones posteriores en el caso del uso de memoria (RSS anónimo y espacio de intercambio) y del uso de memoria de mapa de bits.
¿Por qué hay diferentes umbrales para RSS anónimo y espacio de intercambio y para cada nivel de RAM?
La división por nivel de RAM reconoce que los diferentes dispositivos tienen distintos niveles de tolerancia para el uso excesivo de memoria. Lo que funciona bien en un dispositivo de 16 GB puede que no funcione igual de bien en un dispositivo de 4 GB. Debes asegurarte de que tu aplicación no use una cantidad excesiva de memoria en todos los niveles de RAM
¿Qué formatos se incluyen en los requisitos de memoria?
Las métricas Uso de memoria (RSS anónimo y espacio de intercambio) y Uso de memoria de mapa de bits se aplican a los formatos de móviles y tablets.
¿Qué herramientas puedo usar para entender mejor mi uso de memoria?
-
Para empezar a mejorar la memoria de las aplicaciones o los juegos, consulta nuestra guía sobre la memoria.
-
Google Play Console (Android vitals): monitoriza las métricas P90 acumuladas de los últimos 28 días de uso de memoria (RSS anónimo y espacio de intercambio) y uso de memoria de mapa de bits. Puedes filtrar por estado de la aplicación (primer plano, servicio percibido por el usuario, segundo plano y en caché), nivel de RAM del dispositivo (por ejemplo, de 4 a 6 GB), versión de Android y versión de la aplicación.
-
API Google Play Developer Reporting: consulta métricas de forma programática para automatizar la creación de informes, identificar regresiones de rendimiento e integrar datos de Android vitals en tus paneles de control internos.
-
Profiler de memoria y volcados de montículo de Android Studio: inspecciona las asignaciones en tiempo real en el montículo de Java/Kotlin, la memoria nativa y los gráficos. Captura y analiza volcados de montículo (.
hprof) para detectar pérdidas de memoria, actividades no publicadas, mapas de bits duplicados y rutas de retención. -
Perfetto y Trazado del sistema: usa Perfetto (
heapprofd) para obtener muestras de baja sobrecarga de asignaciones nativas y de Java para identificar las pilas de llamadas que provocan picos de memoria. Los trazados del sistema ayudan a monitorizar el uso de memoria en las transiciones del ciclo de vida y a correlacionarlo con los eventos de finalización por falta de memoria (lmkd). También se pueden usar las habilidades de análisis de IA (como las habilidades de IA de Perfetto) para automatizar el análisis de los trazados y los volcados de montículo. -
Herramientas de diagnóstico en el dispositivo: usa
adb shell dumpsys meminfo <nombre_del_paquete>para obtener un desglose en tiempo real de PSS, Private Dirty (RSS anónimo), Swap Dirty (zRAM) y mapas de bits, o instrumentaComponentCallbacks2.onTrimMemory()para obtener telemetría de cliente personalizada.
¿Por qué hay un tamaño mínimo de DEX para la optimización del código?
Aunque siempre recomendamos optimizar el código, para disfrutar de las numerosas ventajas que ofrece en cuanto al rendimiento, sopesamos el esfuerzo necesario para volver a compilar y optimizar una aplicación o un juego, así como las ventajas que ofrece a los usuarios. Los tamaños de DEX pequeños (menos de 10 MB para aplicaciones y menos de 50 MB para juegos) tienen un impacto limitado en el uso de memoria de los dispositivos, por lo que no exigimos la optimización del código en este caso.
Restauración del inicio de sesión sin toques
¿La clave de restauración se mantiene si se desinstala una aplicación y se vuelve a instalar en el mismo dispositivo?
No. La clave de restauración se elimina automáticamente cuando se desinstala una aplicación.
¿Este requisito se aplica a todos los formatos?
No, el requisito de restauración de credenciales sin toques solo se aplica a los formatos de móvil y tablet.
¿Se aplica este requisito si un usuario no ha iniciado sesión o a aplicaciones sin cuentas de usuario?
No. El requisito se ha diseñado para mantener un estado de inicio de sesión activo en las transiciones de dispositivos.
-
Aplicaciones sin inicio de sesión de usuario: las aplicaciones que no ofrecen cuentas de usuario ni funciones de inicio de sesión no se ven afectadas.
-
Usuarios que tienen la sesión cerrada o invitados: si un usuario tiene la sesión cerrada, está usando el modo Invitado o ha cerrado sesión antes de cambiar de dispositivo, tu aplicación debería iniciarse en el mismo estado sin autenticar en el nuevo dispositivo.
¿Restore Credentials funciona con cualquier método de autenticación?
Sí, la API Restore Credentials está diseñada para funcionar con cualquier método de autenticación, ya que permite que las aplicaciones almacenen una clave de restauración.
¿Restore Credentials gestiona los ámbitos de autorización o la verificación adicional (por ejemplo, MFA)?
-
No. La API Restore Credentials está diseñada exclusivamente para la autenticación (restaurar la identidad y la sesión del usuario). No gestiona solicitudes de autorización secundarias, como las concesiones de permisos de OAuth o las pruebas multifactor.
-
Te recomendamos que sigas una estrategia de dos pasos:
-
Restaurar la identidad: usa Restore Credentials para restablecer de forma silenciosa el estado de inicio de sesión principal del usuario al iniciar la aplicación por primera vez en el nuevo dispositivo.
-
Autorizar en contexto: solicita permisos de recursos específicos (por ejemplo, acceso a Google Drive) justo cuando el usuario acceda a funciones que los requieren. Si es necesario, también puedes solicitar una autenticación reforzada (por ejemplo, la MFA).
-
¿Cómo puedo saber si mi integración cumple el requisito?
La restauración del inicio de sesión de un usuario se determina mediante la recuperación correcta de la clave de restauración. Se enviará una notificación a las aplicaciones que identifiquemos que no cumplen este requisito.
¿Cómo puedo saber si mi aplicación forma parte de una excepción?
Más adelante, se proporcionarán más directrices sobre las excepciones.
¿Cómo gestiono los casos prácticos de autenticación multifactor (MFA)?
La API Restore Credentials no gestiona las pruebas de MFA ni está diseñada para eludir las políticas de seguridad de tu aplicación. Cuando recuperes una clave de restauración en un dispositivo nuevo, tu aplicación debe decidir si requiere una verificación adicional. Para cumplir este requisito, basta con restaurar el contexto de identidad del usuario (por ejemplo, mostrar el mensaje "Hola de nuevo, Alejandro"). Sin embargo, ten en cuenta que la restauración al pasar de un dispositivo a otro proporciona una prueba de posesión sólida y, por lo tanto, no debería requerir un paso de MFA adicional.
¿Por qué los juegos están exentos de este requisito?
Los juegos están exentos inicialmente mientras trabajamos en soluciones personalizadas para los casos prácticos de autenticación complejos, que son habituales en los juegos. Recomendamos encarecidamente a los juegos que admitan el inicio de sesión con una sola cuenta que adopten la API Restore Credentials para ofrecer la opción de iniciar sesión sin toques.
¿Puedo usar Block Store para cumplir los nuevos requisitos de incorporación de dispositivos?
Sí, se puede considerar que una integración con Block Store cumple los requisitos, pero solo si se ha completado y está en producción el 30 de septiembre del 2026 o antes, y restaura correctamente el estado de inicio de sesión de un usuario. No se considerará que cumplen los requisitos otros tipos de integración o las integraciones que se completen después de la fecha límite.
¿Por qué se ha fijado el 30 de septiembre del 2026 como fecha límite para las integraciones de Block Store?
La fecha del 30 de septiembre del 2026 ofrece un hito claro para los equipos que están integrando Block Store. De esta forma, las implementaciones de inicio de sesión sin toques seguirán siendo válidas y las futuras integraciones se dirigirán al estándar recomendado de Gestor de credenciales.
¿Qué ocurre cuando el usuario cierra sesión o elimina su cuenta en el dispositivo antiguo?
La aplicación tendrá que eliminar activamente la clave de restauración. Si se desinstala la aplicación, la clave de restauración se eliminará automáticamente.
¿Qué puedo hacer con los usuarios en el modo Invitado?
El requisito solo se aplica a la parte autenticada de tu aplicación. Si un usuario era invitado en el dispositivo antiguo, la aplicación debería iniciarse en modo Invitado en el dispositivo nuevo.
¿Qué debo hacer con los usuarios que usan varias cuentas en el mismo dispositivo?
Para cumplir este requisito, tu aplicación debe almacenar la clave de restauración de la cuenta de usuario activa (o de la última cuenta activa) en el dispositivo de origen. Puedes consultar más información en la documentación sobre Restore Credentials.
¿Puedo enviar notificaciones a los usuarios restaurados sin que tengan que volver a conceder permisos de notificaciones?
Sí. Los servicios de copia de seguridad y restauración se encargan de restaurar los permisos de las aplicaciones, incluidos los permisos de notificaciones, del dispositivo anterior. Esto te permite enviar notificaciones genéricas. Además, si se combina con Restore Credentials, puedes volver a captar la atención de los usuarios con notificaciones personalizadas en el nuevo dispositivo sin que tengan que abrir la aplicación primero.
Otros
¿Son opcionales estos requisitos?
Todos los requisitos publicados en esta página son obligatorios. No cumplir un requisito puede afectar a la visibilidad y a las funciones de publicación de una aplicación en Google Play.
Recursos útiles
Optimización del código
- Habilitar la optimización de aplicaciones con R8 | Calidad de la aplicación | Android para desarrolladores
- Usar R8 en modo completo | Calidad de la aplicación | Android para desarrolladores
- Usar el analizador de configuración de R8 | Calidad de la aplicación | Android para desarrolladores
Uso de memoria (RSS anónimo y espacio de intercambio)
Uso de memoria de mapa de bits
Restore Credentials
- Información sobre Restore Credentials
- Guías oficiales: Implementar Restore Credentials
- Materiales de pruebas: Probar Restore Credentials en Android Studio
- Caso de éxito de impacto real: Cómo ha reducido Uber los inicios de sesión manuales en 4 millones al año
Habilidades
Las habilidades son instrucciones y recursos modulares optimizados para la IA que ayudan a los LLMs a comprender y ejecutar mejor patrones específicos que siguen las prácticas recomendadas y las directrices de desarrollo de Android de developer.android.com. Puedes usarlas a través de la CLI de Android u otras herramientas basadas en LLMs.
- Habilidad de análisis de R8: analiza la configuración de R8 de una aplicación y conserva las reglas.
- Habilidades de IA de Perfetto: úsalas para interpretar volcados de montículo y obtener sugerencias prácticas para mejorar el rendimiento de la memoria.
- Habilidad de Profiler de Android: úsala para interpretar volcados de montículo y trazados, y para obtener sugerencias prácticas que te ayuden a mejorar el rendimiento de la memoria.
- Skill Restore Credentials: úsala para obtener ayuda con la integración y la prueba de la configuración de restauración de credenciales.
Requisitos actuales
Los requisitos técnicos de Google Play incluyen umbrales de mal funcionamiento en un conjunto de Android vitals prioritarios, así como requisitos relacionados con el app bundle que subas a Play Console.
Android vitals prioritarios y estabilidad
Google Play monitoriza las métricas de rendimiento prioritarias para asegurarse de que las aplicaciones cumplan los estándares de estabilidad. Si se superan estos umbrales, la visibilidad de tu aplicación en Google Play Store puede verse afectada.
- Tasa de fallos percibidos por los usuarios: umbral del 1,09 % general (media de todos los dispositivos), del 8 % por modelo de teléfono y del 4 % por modelo de reloj. Más información
- Tasa de errores ANR percibidos por los usuarios: umbral del 0,47 % en general (media de todos los dispositivos), del 8 % por modelo de teléfono y del 5 % por modelo de reloj. Más información
- Wake locks parciales excesivos: umbral del 5 % en general (media de todos los dispositivos). Si el dispositivo permanece activo innecesariamente, se agota la batería. Asegúrate de usar los wake locks correctamente y considera la posibilidad de usar WorkManager para las tareas en segundo plano. Más información
- Uso excesivo de batería: umbral del 1 % por modelo de reloj. Más información
Requisitos técnicos
Google Play admite una gran variedad de dispositivos con diferentes configuraciones de hardware y arquitecturas. Algunas arquitecturas son fundamentales para el futuro de Android, por lo que los nuevos app bundles que se suban a Play Console deben ser compatibles con ellas para que podamos ofrecer las experiencias de tu aplicación.
- Compatibilidad con 64 bits: las aplicaciones que contengan código nativo deben ser compatibles con arquitecturas de solo 64 bits. Más información
- Compatibilidad con tamaños de página de memoria de 16 kB: las aplicaciones que contengan código nativo deben admitir dispositivos con tamaños de página de memoria de 16 kB. Las aplicaciones que solo usan Java o Kotlin son compatibles de forma predeterminada. Más información
- Compatibilidad con Wear OS de 64 bits y tamaño de página de memoria de 16 kB: obligatorio a partir del 15 de septiembre del 2026. Más información
- Compatibilidad con TV de 64 bits y tamaño de página de memoria de 16 kB: obligatorio a partir del 1 de agosto del 2026. Más información