Monitorizar la calidad técnica de una aplicación con Android vitals

Nuevas estadísticas sobre problemas de calidad y recomendaciones de aplicaciones

Desde septiembre del 2024, puedes encontrar nuevas estadísticas y recomendaciones en las páginas Información general de Android vitals y Fallos y errores ANR de Play Console para ayudarte a priorizar los problemas de calidad.

Por ahora, se muestran problemas de compatibilidad con aplicaciones, comportamientos inadecuados y algunas recomendaciones de experiencia de usuario. El año que viene seguiremos detectando y mostrando más problemas de calidad, así como ofreciendo más recomendaciones.

Android vitals te ayuda a entender y a mejorar la estabilidad, el rendimiento y el uso de batería de tu aplicación, entre otros aspectos.

Elegir cómo acceder a los datos de tu aplicación

Hay dos formas de usar Android vitals: a través de Play Console y mediante la API Google Play Developer Reporting.

La API proporciona acceso programático a Android vitals a los desarrolladores que quieran integrar los datos de Android vitals en otros conjuntos de datos o en sus flujos de trabajo. Si quieres más información sobre cómo usar una API para acceder a Android vitals, consulta la página de la API Google Play Developer Reporting.

Para buscar y consultar los datos de Android vitals de tu aplicación en Play Console, sigue estos pasos:

1. Abre Play Console y ve a la página Información general de Android vitals (Calidad > Android vitals > Información general).
2. Elige el intervalo de datos que quieras ver usando el selector de intervalo de fechas, que está arriba a la derecha.

Importante: Si no aparece ningún dato, significa que tu aplicación no tiene dentro de los filtros especificados suficiente información para identificar problemas.

Monitorizar los Android vitals prioritarios de tu aplicación

En la parte superior de la página Información general de Android vitals, puedes consultar los datos de los Android vitals prioritarios de tu aplicación. Estas son las métricas técnicas más importantes, ya que afectan a la descubribilidad de tu aplicación en Google Play. Entre los Android vitals prioritarios, se incluyen los siguientes:

• Tasa de errores ANR percibidos por los usuarios
• Tasa de fallos percibidos por los usuarios

Google Play define umbrales de comportamiento inadecuado para estas métricas. Si tu aplicación supera los umbrales, es probable que sea menos descubrible en Google Play. En algunos casos, se podría mostrar una advertencia en la ficha de Play Store de tu aplicación para informar al usuario.

En la sección "Problemas críticos", puedes identificar rápidamente las áreas de tu aplicación que se pueden mejorar. Hay dos tipos de problemas críticos:

• Mal funcionamiento: métricas que superan los umbrales de mal funcionamiento.
• Anomalías: cambios significativos en los datos (por ejemplo, un aumento brusco de la tasa de errores ANR percibidos por los usuarios).

Para recibir notificaciones por correo electrónico, accede a Configuración > Notificaciones, o haz clic en la opción Administrar notificaciones, que está en la esquina de la sección "Android vitals prioritarios" (Calidad > Android vitals > Información general). Ten en cuenta que, actualmente, solo se pueden recibir notificaciones sobre anomalías.

Consultar todos los datos de Android vitals

Cerca de la parte central de la página Información general de Android vitals, puedes consultar todos los datos de Android vitals según los aspectos de calidad.

En la tabla, puedes consultar las métricas de periodos pasados o del momento actual. También puedes ver comparaciones entre tu aplicación y otras de Google Play.

Consultar métricas detalladas

Para obtener más información sobre una métrica, selecciona la opción Ver detalles () situada junto a ella. En la siguiente pantalla podrás consultar estos datos:

• Umbrales de comportamiento inadecuado
• Comparativas de categorías
• Comparativas detalladas
  • En la parte superior de la página, en la tarjeta de comparación con aplicaciones similares, selecciona Editar grupo de aplicaciones similares para editar un grupo de aplicaciones similares personalizado. Crear un grupo de aplicaciones similares personalizado te permitirá ver una comparación de tu aplicación con otras de Google Play que selecciones.
• Tendencia de la métrica a lo largo del tiempo

Analizar datos con dimensiones

Para ayudarte a organizar, segmentar y analizar los datos, tus métricas se desglosan en dimensiones. Todas las métricas tienen las siguientes dimensiones:

• Artefacto: la versión de la aplicación en la que se ha producido el problema.
• Versión de Android (SDK): versión del SO Android registrada por el dispositivo del usuario.
• Factor de forma: tipo de dispositivo en el que se ha ejecutado la aplicación (por ejemplo, un teléfono, una tablet, una televisión o un wearable).
• Modelo del dispositivo: un término amplio compuesto por una marca y un identificador de dispositivo que son únicos (por ejemplo, "Google oriole"). Un modelo de dispositivo puede aplicarse a variantes con diferencias en lo referente a versiones de Android, RAM, espacio de almacenamiento o sistema en chip (SoC).
• País o territorio: la ubicación que indica el dispositivo del usuario en el momento del problema.

Nota: Para desglosar la información en aspectos específicos del hardware o del software del dispositivo (por ejemplo, el modelo o la versión de Android), puedes hacer clic en el símbolo () situado junto al elemento de la tabla.

Algunas métricas tienen desgloses adicionales:

• Nombre de wake lock: etiquetas que se han configurado mediante programación al usar la API PowerManager en tu aplicación.
• Nombre de wakeup: etiquetas que se han configurado automáticamente al usar la API AlarmManager en tu aplicación.
• Nombre de la actividad del error ANR: nombre cualificado del tipo de actividad en la que se ha producido el error ANR (si está disponible).
• Tipo de error ANR: momento en el que se ha producido el error ANR (por ejemplo, al ejecutar un servicio), si está disponible.

Puedes consultar más detalles cuando estén disponibles (por ejemplo, los clústeres de fallos o de errores ANR asociados a ese desglose). Para ello, selecciona la opción Ver detalles () situada junto al elemento.

Nota: Puedes cambiar entre métricas de una misma categoría con el interruptor situado en la parte superior de la pantalla y filtrar la página.

Tipos y métricas de datos

Los datos de Android vitals de los últimos 90 días están disponibles en Play Console, y los de los tres últimos años, en la API Play Developer Reporting.

Los datos proceden de un subconjunto de dispositivos Android y versiones del SO cuyos usuarios han habilitado la opción para compartir automáticamente datos de uso y diagnóstico. Si quieres consultar más información sobre cómo aceptan compartir datos los usuarios de Android, visita el Centro de Ayuda de Cuentas.

Android vitals se actualiza a diario. A veces, los datos de los dispositivos con Android 10 o versiones posteriores llegan antes que los datos de los dispositivos con versiones inferiores a Android 10. Si ocurre esto, verás los datos de los dispositivos con Android 10 o versiones posteriores de los días en los que estén disponibles.

Nota: Las métricas de Android vitals excluyen problemas técnicos que se producen en modelos de dispositivos no certificados o en versiones de tu aplicación que no se hayan instalado a través de Google Play.

Ocultar todo Mostrar todo

Estabilidad

Métricas de la tasa de errores ANR

Las métricas de la tasa de errores ANR proporcionan información general sobre la calidad de tu aplicación. Estas métricas se calculan normalizando el número de usuarios con errores ANR en función del uso de la aplicación. Se registran como un porcentaje de usuarios activos al día. Se considera que un usuario activo al día es aquel que utiliza la aplicación un día en un dispositivo. Si un usuario utiliza tu aplicación en más de un dispositivo durante un mismo día, cada uno de esos dispositivos se sumará al número de usuarios activos de ese día. Si varios usuarios utilizan el mismo dispositivo durante un mismo día, el dispositivo contará como un solo usuario activo.

La tasa de errores ANR tiene tres métricas:

• Tasa de errores ANR percibidos por los usuarios: el porcentaje de usuarios activos al día que han percibido al menos un error ANR. Los errores ANR percibidos por los usuarios son errores ANR que probablemente hayan detectado los propios usuarios. Actualmente, solo se contabilizan los errores ANR "Input dispatching timed out". Esta métrica siempre será inferior a tu tasa de errores ANR general, ya que se normaliza en función del uso diario, pero no incluye todos los errores ANR.
  La tasa de errores ANR percibidos por los usuarios forma parte de los Android vitals prioritarios, es decir, afecta a la descubribilidad de tu aplicación en Google Play. Es importante porque los errores ANR que incluye siempre se producen cuando el usuario interactúa con la aplicación, que es el tipo de interrupción más grave.
• Tasa de errores ANR: el porcentaje de usuarios diarios que han experimentado al menos un error ANR. Esta métrica incluye errores ANR que no se consideran errores percibidos por los usuarios, pero que no podemos garantizar que no les estén afectando.
• Tasa de errores ANR múltiples: el porcentaje de usuarios diarios que han experimentado al menos dos errores ANR. Esta métrica ayuda a detectar bucles de problemas.

Solucionar un problema

Los errores ANR que incluyen las métricas de la tasa de errores ANR aparecen en la página Fallos y errores ANR. En esta página, puedes filtrar por errores ANR percibidos por los usuarios.

En el sitio Android para desarrolladores se proporcionan directrices para diagnosticar y corregir los errores ANR.

Métricas de la tasa de fallos

Las métricas de la tasa de fallos proporcionan información general sobre la calidad de tu aplicación. Estas métricas se calculan normalizando el número de usuarios con fallos en función del uso de la aplicación. Se registran como un porcentaje de usuarios diarios. Se considera que un usuario diario es aquel que usa la aplicación un día en un dispositivo. Si un usuario tiene más de un dispositivo, se contabilizará más de una vez. Por tanto, si dos usuarios usan la aplicación dos días con un dispositivo cada uno, se registrarán cuatro sesiones diarias.

La tasa de fallos tiene tres métricas:

• Tasa de fallos percibidos por los usuarios: el porcentaje de usuarios diarios que han experimentado al menos un fallo percibido por los usuarios. Los fallos percibidos por los usuarios son fallos que es probable que los usuarios hayan notado. Por ejemplo, los fallos que se producen cuando tu aplicación muestra una actividad o se ejecuta como un servicio en primer plano. Esta métrica siempre será inferior a tu tasa de fallos general, ya que se normaliza en función del uso diario, pero no incluye todos los fallos.
  La tasa de fallos percibidos por los usuarios forma parte de los Android vitals prioritarios, es decir, afecta a la descubribilidad de tu aplicación en Google Play. Es importante porque los fallos que incluye siempre se producen cuando el usuario interactúa con la aplicación, que es el tipo de interrupción más grave. Por eso, debes asegurarte de que tu aplicación no supere el umbral de comportamiento inadecuado de esta métrica.

• Tasa de fallos: el porcentaje de usuarios diarios que han experimentado al menos un fallo. Esta métrica incluye fallos que no se consideran fallos percibidos por los usuarios, pero que no podemos garantizar que no les estén afectando.

• Tasa de fallos múltiples: el porcentaje de usuarios diarios que han experimentado al menos dos fallos. Esta métrica ayuda a detectar bucles de problemas.

Solucionar un problema

En el sitio para desarrolladores de Android, se proporcionan directrices para diagnosticar y corregir los fallos.

Tiempos de inicio y de carga

Tiempo de inicio (tiempo hasta la visualización inicial)

En la página Tiempo de inicio, se muestran datos sobre los momentos en los que tu aplicación arranca lenta en frío, en caliente lento y en caliente. El tiempo de inicio mide el tiempo que transcurre desde que un usuario abre tu aplicación hasta que aparecen los primeros fotogramas en la pantalla. También se denomina "tiempo hasta la visualización inicial".

Es posible que la aplicación no esté lista para que el usuario empiece a interactuar con ella una vez transcurrido ese tiempo (por ejemplo, si la aplicación tiene pantallas de carga adicionales).

Información sobre la recogida de datos

• Los tiempos de arranque solo se registran cuando el usuario inicia una actividad.
  • Ejemplo: El tiempo de arranque de las aplicaciones de teclado es el mismo que el de la aplicación complementaria.
• Si se arranca una aplicación varias veces durante un día desde el mismo estado del sistema, se registrará el mayor tiempo de arranque de ese día.
• Los tiempos de arranque se registran cuando el primer fotograma de la aplicación se carga por completo, aunque no sea una pantalla con la que interactúen los usuarios.
  • Ejemplo: Si una aplicación se inicia con una pantalla inicial de carga, el tiempo de arranque será el tiempo que necesita para mostrar esa pantalla.

Información de Android vitals

• Sesiones afectadas: el porcentaje de sesiones en las que los usuarios han experimentado un tiempo de arranque lento con cada estado del sistema:
  • Arranque en frío lento: 5 segundos o más
  • Arranque lento con la aplicación abierta: 2 segundos o más
  • Arranque lento con la aplicación abierta con actividad: 1 segundo o más
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: el 10 % o el 1 % de las sesiones diarias en las que los usuarios han experimentado un tiempo de arranque lento al usar tu aplicación.

Solucionar un problema

Si tu aplicación presenta un número elevado de tiempos de inicio lentos, accede al sitio para desarrolladores de Android y consulta las soluciones recomendadas.

Renderizado

Todo el renderizado

Porcentaje de sesiones lentas (30 FPS o 20 FPS) [solo videojuegos]

Por qué es importante

Con las sesiones lentas, puedes entender el rendimiento de la velocidad de fotogramas de tu videojuego, que influye en la sensación de fluidez de tu videojuego que perciben los usuarios.

Entender los datos de una aplicación

En la página Sesiones lentas, se mostrará el porcentaje de sesiones diarias en las que los usuarios han observado que más del 25 % de los fotogramas se renderizaban a menos de 30 FPS o de 20 FPS (en función del punto de referencia que hayas seleccionado). Además, podrás consultar la distribución de las sesiones por velocidad de fotogramas de tu juego. La velocidad de fotogramas por sesión se mide a partir del percentil 75, lo que significa que el 75 % de los fotogramas alcanzan al menos esta velocidad de fotogramas.

La mayoría de los juegos que estén en Google Play deberían llegar a 30 FPS o más. Esta velocidad de fotogramas permite ofrecer a los usuarios una experiencia razonablemente fluida, con independencia del tipo de juego (aunque algunos usuarios preferirán al menos 60 FPS, especialmente en los dispositivos de alta gama). Monitoriza la métrica del porcentaje de sesiones lentas (30 FPS) para asegurarte de que estés alcanzando esta velocidad de fotogramas. Ten en cuenta que esta métrica solo incluye las sesiones en las que más del 25 % de los fotogramas se rendericen a una velocidad inferior a 30 FPS, por lo que se aplica un margen de tolerancia con respecto a la variabilidad de la velocidad de fotogramas.

Aunque ofrecer 30 FPS permite disfrutar de una experiencia razonablemente fluida, puede haber momentos o tipos de juegos en los que sea adecuado proporcionar una velocidad de fotogramas inferior. También puede ocurrir que algunos usuarios quieran disfrutar de tu juego en teléfonos que no admitan 30 FPS. En estas situaciones, al menos el 75 % de los fotogramas de una sesión deberían llegar a 20 FPS o más. Monitoriza la métrica del porcentaje de sesiones lentas (20 FPS) para asegurarte de que estés alcanzando esta velocidad de fotogramas.

Android vitals te informa de las sesiones lentas (30 FPS y 20 FPS) de cada dispositivo, así como de todos los dispositivos y todas las sesiones. Usa la métrica global para hacerte una idea de cómo es la experiencia de usuario en general, pero presta atención también al rendimiento por dispositivo. A su debido tiempo, Google Play empezará a alejar a los usuarios de los juegos que no puedan llegar a 20 FPS en sus teléfonos.

Android vitals no empezará a monitorizar la velocidad de fotogramas hasta que el juego se haya estado ejecutando durante 1 minuto.

Información sobre la recogida de datos

La métrica de sesiones lentas se calcula con datos recogidos por SurfaceFlinger. En concreto, la velocidad de fotogramas de una sesión se calcula en función del tiempo entre fotogramas renderizados en las superficies que pertenecen a la aplicación e incluye los fotogramas renderizados por OpenGL y Vulkan, así como con el kit de herramientas de UI de Android. Esta métrica solo está disponible para juegos.

Los datos de velocidad de fotogramas de las sesiones lentas se recogen para los dispositivos que tengan Android 9 o versiones posteriores.

Vista del panel de control

• Velocidad de fotogramas representativa: es el rendimiento de la velocidad de fotogramas de tu videojuego en dispositivos con Android 9 o versiones posteriores, calculado a partir del percentil 75. Esto significa que el 75 % de las sesiones han tenido esta velocidad de fotogramas o más rápida el 75 % del tiempo.
• Porcentaje de sesiones lentas a lo largo del tiempo: una serie temporal en la que se muestra el porcentaje de sesiones que se ha determinado que son sesiones lentas.
• Distribución de la velocidad de fotogramas: histograma que muestra el percentil 75 de la velocidad de fotogramas en todas las sesiones. Esto significa que el 75 % de los fotogramas de una sesión han sido más rápidos que la velocidad de fotogramas usada para registrar la sesión.

Solucionar un problema

Si tu aplicación presenta un número elevado de sesiones lentas, ve al sitio Android para desarrolladores y consulta las soluciones recomendadas.

Renderizado del kit de herramientas de UI de Android

Fotogramas lentos excesivos [solo aplicaciones]

Entender los datos de una aplicación

En la página Fotogramas lentos excesivos, se mostrará el porcentaje de sesiones diarias en las que los usuarios han observado que más del 50 % de los fotogramas no se ajustaban al tiempo de renderizado objetivo del dispositivo. Las interacciones de los usuarios con tu aplicación deben realizarse a 60 fotogramas por segundo sin que estos se retrasen ni descienda su número.

Información sobre la recogida de datos

Google recoge el tiempo de renderizado de cada fotograma renderizado por tu aplicación con el framework del kit de herramientas de UI. No se recogen los fotogramas renderizados directamente con OpenGL o Vulkan.

Vista del panel de control

Si seleccionas una fila, los datos aparecerán desglosados en percentiles.

• Sesiones afectadas: el porcentaje de sesiones diarias en las que los usuarios han experimentado un tiempo de renderizado superior a 16 ms en más de un 50 % de los fotogramas. Una sesión diaria equivale a un día en el que se ha usado la aplicación. Por ejemplo, si dos usuarios utilizan la aplicación durante dos días, se registrarán cuatro sesiones diarias.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: un 90 % o un 99 % del total de fotogramas ha tenido un tiempo de renderizado más lento que el número indicado. Estas cifras se basan en todos los fotogramas recopilados.

Si haces clic en una entrada de la tabla, aparecerá el gráfico "Distribución del tiempo de renderizado de la UI". Cuando lo consultes, asegúrate de que el tiempo de renderizado de la mayoría de los fotogramas de tu aplicación sea 16 ms o menos.

Los datos que se muestran bajo el gráfico representan el rendimiento durante el renderizado de la aplicación y te permiten detectar la causa principal de cualquier problema relacionado con el tiempo de renderizado. Por ejemplo, si el porcentaje de "Latencia de entrada alta" es elevado, te recomendamos que compruebes el código de tu aplicación que gestiona la entrada de usuarios. Para obtener más información sobre estas métricas, consulta el artículo sobre cómo probar el rendimiento de la UI.

• Vsyncs perdidos: en el caso de los fotogramas renderizados en más de 16 ms, el número de eventos Vsync perdidos dividido entre el número de fotogramas.
• Latencia de entrada alta: en el caso de los fotogramas renderizados en más de 16 ms, el número de eventos de entrada que han tardado más de 24 ms dividido entre el número de fotogramas.
• Hilo de UI lento: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el hilo de UI ha tardado más de 8 ms en completarse dividido entre el número de fotogramas.
• Comandos de dibujo lentos: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el envío de comandos de dibujo ha tardado más de 12 ms en subirse a la GPU dividido entre el número de fotogramas.
• Subidas lentas del mapa de bits: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el mapa de bits ha tardado más de 3,2 ms en subirse a la GPU dividido entre el número de fotogramas.

Solucionar un problema

Si tu aplicación presenta un número elevado de fotogramas con un tiempo de renderizado superior a 16 ms, accede al sitio Android para desarrolladores y consulta las soluciones recomendadas.

Fotogramas congelados excesivos [solo aplicaciones]

Entender los datos de una aplicación

En la página Fotogramas lentos excesivos, se mostrará el porcentaje de sesiones diarias en las que los usuarios han observado que más del 50 % de los fotogramas no se ajustaban al tiempo de renderizado objetivo del dispositivo. Las interacciones de los usuarios con tu aplicación deben realizarse a 60 fotogramas por segundo sin que estos se retrasen ni descienda su número.

Información sobre la recogida de datos

Google recoge el tiempo de renderizado de cada fotograma renderizado por tu aplicación con el framework del kit de herramientas de UI. No se recogen los fotogramas renderizados directamente con OpenGL o Vulkan.

Vista del panel de control

Si seleccionas una fila, los datos aparecerán desglosados en percentiles.

• Sesiones afectadas: el porcentaje de sesiones diarias en las que los usuarios han experimentado un tiempo de renderizado superior a 16 ms en más de un 50 % de los fotogramas. Una sesión diaria equivale a un día en el que se ha usado la aplicación. Por ejemplo, si dos usuarios utilizan la aplicación durante dos días, se registrarán cuatro sesiones diarias.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: un 90 % o un 99 % del total de fotogramas ha tenido un tiempo de renderizado más lento que el número indicado. Estas cifras se basan en todos los fotogramas recopilados.

Si haces clic en una entrada de la tabla, aparecerá el gráfico "Distribución del tiempo de renderizado de la UI". Cuando lo consultes, asegúrate de que el tiempo de renderizado de la mayoría de los fotogramas de tu aplicación sea 16 ms o menos.

Los datos que se muestran bajo el gráfico representan el rendimiento durante el renderizado de la aplicación y te permiten detectar la causa principal de cualquier problema relacionado con el tiempo de renderizado. Por ejemplo, si el porcentaje de "Latencia de entrada alta" es elevado, te recomendamos que compruebes el código de tu aplicación que gestiona la entrada de usuarios. Para obtener más información sobre estas métricas, consulta el artículo sobre cómo probar el rendimiento de la UI.

• Vsyncs perdidos: en el caso de los fotogramas renderizados en más de 16 ms, el número de eventos Vsync perdidos dividido entre el número de fotogramas.
• Latencia de entrada alta: en el caso de los fotogramas renderizados en más de 16 ms, el número de eventos de entrada que han tardado más de 24 ms dividido entre el número de fotogramas.
• Hilo de UI lento: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el hilo de UI ha tardado más de 8 ms en completarse dividido entre el número de fotogramas.
• Comandos de dibujo lentos: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el envío de comandos de dibujo ha tardado más de 12 ms en subirse a la GPU dividido entre el número de fotogramas.
• Subidas lentas del mapa de bits: en el caso de los fotogramas renderizados en más de 16 ms, el número de veces que el mapa de bits ha tardado más de 3,2 ms en subirse a la GPU dividido entre el número de fotogramas.

Solucionar un problema

Si tu aplicación presenta un número elevado de fotogramas con un tiempo de renderizado superior a 16 ms, accede al sitio para desarrolladores de Android y consulta las soluciones recomendadas.

Uso de batería

Wake locks estancados y wake locks parciales estancados en segundo plano

Las páginas Wake locks parciales estancados y Wake locks parciales estancados en segundo plano muestran los wake locks parciales que ha adquirido tu aplicación a través de la clase PowerManager. Los wake locks parciales permiten desactivar la retroiluminación del teclado y apagar la pantalla mientras la CPU está funcionando.

Información sobre la recogida de datos

• Para proteger la privacidad, las etiquetas de identificación de wake locks parciales son anónimas.
• Los datos sobre wake locks parciales se recogen cuando el dispositivo no se está cargando y la pantalla está apagada.
• Los datos de wake locks parciales estancados en segundo plano solo se recogen cuando la aplicación se está ejecutando en segundo plano.
• Google calcula la duración máxima de un wake lock parcial por sesión de batería para mostrar cuántas sesiones se ven afectadas por un wake lock largo. Por ejemplo, si un usuario activa dos wake locks que duran una hora, Google utilizará un valor máximo de una hora para el wake lock.
• En las aplicaciones que hayan establecido el atributo sharedUserId en el archivo de manifiesto, solo podrás ver los datos si hay instalada como máximo una aplicación con el mismo atributo sharedUserId.

Información de Android vitals

• Sesiones afectadas: porcentaje de sesiones de batería en las que los usuarios han observado al menos un wake lock de más de una hora.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: en el 10 % o el 1 % de las sesiones diarias los usuarios han observado wake locks parciales con una duración superior al número indicado.
• Umbral de mal funcionamiento: si tu aplicación presenta una tasa de incidencia igual o superior al umbral indicado, se situará en el 25 % inferior de las 1000 aplicaciones más populares de Google Play (según el número de descargas).

Solucionar un problema

Si tu aplicación presenta un número elevado de wake locks parciales estancados, accede al sitio web para desarrolladores de Android y consulta las soluciones recomendadas.

Wakeups excesivos

La página Wakeups excesivos muestra los wakeups de AlarmManager activados por tu aplicación. Verás datos de wakeups de las clases ELAPSED_REALTIME_WAKEUP o RTC_WAKEUP.

Información sobre la recogida de datos

• Para proteger la privacidad, las etiquetas de identificación de wakeup son anónimas.
• Los datos de wakeups se recogen cuando el dispositivo no se está cargando.
• Para proporcionar una métrica normalizada, el número de wakeups se compara con el momento en que el dispositivo está usando la batería. Google calcula el número de wakeups por usuario cada hora para mostrar cuántos usuarios se ven afectados por un porcentaje de wakeups elevado.
• En las aplicaciones que hayan establecido el atributo sharedUserId en el archivo de manifiesto, solo podrás ver los datos si hay instalada como máximo una aplicación con el mismo atributo sharedUserId.

Información de Android vitals

• Sesiones afectadas: el porcentaje de sesiones de batería en las que los usuarios han experimentado más de 10 wakeups por hora. Una sesión de batería se compone de todos los informes de batería que se reciben en un periodo de 24 horas. En Android 10, los informes de batería hacen referencia al intervalo entre dos cargas de batería, cuando se pase de una carga inferior al 20 % a más del 80 %, o de cualquier valor al 100 %. En Android 11 y versiones posteriores, los informes de batería hacen referencia a un periodo fijo de 24 horas. Google recoge los datos únicamente cuando el dispositivo no está conectado al cargador.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: en el 10 % o el 1 % de las sesiones diarias los usuarios han observado wakeups por hora superiores al valor que se indica.
• Umbral de mal funcionamiento: si tu aplicación presenta una tasa de incidencia igual o superior al umbral indicado, se situará en el 25 % inferior de las 1000 aplicaciones más populares de Google Play (según el número de descargas).

Solucionar un problema

Si tu aplicación presenta wakeups habituales, accede al sitio web para desarrolladores de Android y consulta las soluciones recomendadas.

Búsquedas de redes Wi‑Fi en segundo plano excesivas

La página Búsquedas de redes Wi‑Fi en segundo plano excesivas muestra si las búsquedas de redes Wi‑Fi están consumiendo mucha batería.

Información sobre la recogida de datos

Los datos sobre las búsquedas de redes Wi‑Fi se recopilan cuando el dispositivo no se está cargando y la aplicación se está ejecutando en segundo plano.

Información de Android vitals

• Sesiones afectadas: el porcentaje de sesiones de batería en las que los usuarios han experimentado más de 4 búsquedas de redes Wi-Fi por hora.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: en el 10 % o el 1 % de las sesiones diarias los usuarios han experimentado un número de búsquedas de redes Wi-Fi en segundo plano por hora superior al número indicado.

Solucionar un problema

Si tu aplicación presenta un número elevado de búsquedas de redes Wi‑Fi en segundo plano, accede al sitio web para desarrolladores de Android y consulta las soluciones recomendadas.

Uso excesivo de red en segundo plano

La página Uso excesivo de red en segundo plano muestra cuándo se asocia una gran cantidad de datos de red a un servicio en segundo plano. Cuando se usan redes móviles en segundo plano, los usuarios no pueden acceder fácilmente a los controles para detener la transferencia de datos.

Información sobre la recogida de datos

Los datos sobre el uso de redes móviles se recopilan cuando el dispositivo no se está cargando y la aplicación se está ejecutando en segundo plano.

Información de Android vitals

• Sesiones afectadas: el porcentaje de sesiones de batería en las que los usuarios han experimentado que el uso de la red en segundo plano al día ha sido superior a 50 MB.
• Número de sesiones: el número aproximado de sesiones registradas.
• Percentil 90/99: en el 10 % o el 1 % de las sesiones diarias los usuarios han experimentado un uso de la red en segundo plano diario superior al número indicado.

Solucionar un problema

Si tu aplicación presenta un uso de red en segundo plano elevado, accede al sitio para desarrolladores de Android y consulta las soluciones recomendadas.

Permisos

Denegaciones de permisos

En la página Denegaciones de permisos, puedes consultar información sobre el porcentaje de sesiones de un día con permiso durante las cuales los usuarios han denegado permisos. Una sesión de un día con permiso es un día en el que tu aplicación ha pedido al menos un permiso al usuario.

Información sobre la recogida de datos

Los datos de las denegaciones de permisos se recogen cuando los usuarios responden a las solicitudes de permisos en tu aplicación.

Información de Android vitals

• Denegaciones: indica el porcentaje de sesiones de un día con permiso durante las que los usuarios han denegado permisos.
• No volver a preguntar: indica el porcentaje de sesiones de un día con permiso durante las que los usuarios han seleccionado "No volver a preguntar" para denegar permisos.
• Total de sesiones: el número aproximado de sesiones registradas.

Solucionar un problema

Si tu aplicación tiene un elevado número de denegaciones de permisos, ve al sitio para desarrolladores de Android y consulta las soluciones recomendadas.

Umbrales de comportamiento inadecuado de los Android vitals prioritarios

Google Play ha definido umbrales de comportamiento inadecuado para los Android vitals prioritarios de las aplicaciones.

Si tu aplicación supera un umbral de mal funcionamiento, es probable que sea menos descubrible en Google Play. Además, si la aplicación tiene un mal funcionamiento en determinados modelos de dispositivos, Google Play redirigirá a los usuarios de esos dispositivos a otras aplicaciones que sean más adecuadas para ellos. En algunos casos, podría aparecer una advertencia en la ficha de Play Store de tu aplicación para informar al usuario y ofrecerle la opción de buscar alternativas de mayor calidad técnica.

Por lo general, Google Play tendrá en cuenta los datos de los últimos 28 días a la hora de evaluar la calidad de tu aplicación, pero puede que reduzca ese periodo si se produce un pico.

Ocultar todo Mostrar todo

Estabilidad

Umbrales de la tasa de errores ANR percibidos por los usuarios

Google Play ha definido umbrales de comportamiento inadecuado para la tasa de errores ANR percibidos por los usuarios:

• Mal funcionamiento general: al menos el 0,47 % de los usuarios activos al día experimentan un error ANR percibido por los usuarios (en todos los modelos de dispositivo).

• Mal funcionamiento por dispositivo: al menos el 8 % de los usuarios activos al día experimentan un error ANR percibido por los usuarios (en un solo modelo de dispositivo).

Para reducir la tasa de errores ANR, corrige los clústeres de errores ANR subyacentes que aparecen en la página Fallos y errores ANR. Cuanto mayor sea el número de usuarios afectados, más sumará ese clúster a la tasa de errores ANR.

Si hay aspectos específicos del hardware o del software del dispositivo que estén aumentando la tasa de errores ANR, Android vitals te lo notificará. Además, puedes consultar asociaciones en la página de información general sobre la cobertura y los dispositivos (Versión > Cobertura y dispositivos > Información general).

Umbrales de la tasa de fallos percibidos por los usuarios

Google Play ha definido umbrales de comportamiento inadecuado para la tasa de fallos percibidos por los usuarios:

• Mal funcionamiento general: al menos el 1,09 % de los usuarios diarios experimentan un fallo percibido por los usuarios (en todos los modelos de dispositivos).

• Mal funcionamiento por dispositivo: al menos el 8 % de los usuarios diarios experimentan un fallo percibido por los usuarios (en un solo modelo de dispositivo).

Para reducir la tasa de fallos, corrige los clústeres de fallos subyacentes que aparecen en la página Fallos y errores ANR. Cuanto mayor sea el número de usuarios afectados, más sumará ese clúster a la tasa de fallos.

Si hay aspectos específicos del hardware o del software del dispositivo que estén aumentado la tasa de fallos, Android vitals te lo notificará. Además, puedes consultar asociaciones en la página Vista general de cobertura y dispositivos (Versión > Cobertura y dispositivos > Información general).

Contenido relacionado

Consulta las prácticas recomendadas sobre cómo utilizar Android vitals para mejorar el rendimiento y la estabilidad de tu aplicación.