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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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).