Controla la calidad técnica de tu app con Android vitals

Para obtener más detalles sobre una métrica, selecciona Ver detalles () junto a ella. En la pantalla que aparece a continuación, puedes revisar lo siguiente:

• Umbrales de comportamiento inadecuado
• Comparativas por categoría
• Comparativas detalladas
  • Para editar un grupo personalizado de apps similares, selecciona Editar grupo de apps similares en la tarjeta de comparación correspondiente que aparece cerca de la parte superior de la página. Una vez que crees un grupo personalizado de apps similares, podrás ver cómo se compara tu app con otras que selecciones en Google Play.
• Tendencia de las métricas a lo largo del tiempo

Las métricas de tasa de ANR proporcionan una descripción general de la calidad de tu app. Para calcularlas, se toma la cantidad de tus usuarios que experimentan ANR y se la normaliza en función del uso de la app. Se informan como un porcentaje de usuarios activos por día. Un usuario activo por día se define como una persona que utiliza la app en un determinado día desde un solo dispositivo. Si un usuario usa tu app en más de un dispositivo durante un día específico, se calcula cada dispositivo como parte de la cantidad de usuarios activos de ese día. Si varios usuarios usan el mismo dispositivo en un día determinado, todos ellos cuentan como un usuario activo.

Existen tres métricas de tasa de ANR:

• Tasa de ANR percibidos por el usuario: Es el porcentaje de usuarios activos por día que experimentaron y percibieron al menos un ANR. Un ANR percibido por el usuario es aquel que probablemente el usuario haya notado. Actualmente, solo se contabilizan los ANR por "tiempo de espera de envío de entrada agotado". Esta métrica siempre será inferior a tu tasa de ANR general, ya que se normaliza en función del uso diario, pero no cuenta todos los ANR.
  La tasa de errores ANR percibidos por el usuario es una métrica esencial, lo que significa que afecta la visibilidad de tu app en Google Play. Es importante porque los ANR que cuenta ocurren siempre cuando el usuario interactúa con la app y, por lo tanto, causan la mayor cantidad de interrupciones.
• Tasa de ANR: Es el porcentaje de usuarios diarios que experimentaron al menos un ANR. Esta métrica incluye ANR que no se clasifican como percibidos por el usuario, pero no podemos garantizar que estos no afecten a los usuarios.
• Tasa de ANR múltiples: Es el porcentaje de usuarios diarios que experimentaron al menos dos ANR. Esta métrica ayuda a destacar los problemas que se reiteran.

Cómo corregir un problema

Los ANR que se cuentan dentro de las métricas de tasa de ANR se informan en la página Fallas y ANR, donde puedes filtrar por ANR percibidos por los usuarios.

En el sitio de Android Developers, encontrarás orientación sobre cómo diagnosticar y corregir errores de ANR.

Las métricas de tasa de fallas proporcionan una descripción general de la calidad de tu app. Para calcularlas, se toma la cantidad de usuarios que experimentan fallas y se la normaliza en función del uso de la app. Se informan como un porcentaje de usuarios diarios. Un usuario diario se define como una persona que utiliza la app en un determinado día desde un solo dispositivo. Si un usuario tiene más de un dispositivo, se lo cuenta más de una vez. Por ejemplo, si dos usuarios usan la app durante dos días con un dispositivo diferente cada día, producirán cuatro sesiones diarias.

Existen tres métricas de tasa de fallas:

• Tasa de fallas percibidas por el usuario: Es el porcentaje de usuarios diarios que experimentaron y percibieron al menos una falla. Una falla percibida por el usuario es aquella que probablemente el usuario haya notado, por ejemplo, las fallas que se producen cuando tu app muestra una actividad o se ejecuta como un servicio en primer plano. Esta métrica siempre será inferior a la tasa de fallas general, ya que se normaliza en función del uso diario, pero no cuenta todas las fallas.
  La tasa de fallas percibidas por el usuario es una métrica esencial, lo que significa que afecta la visibilidad de tu app en Google Play. Es importante porque solo cuenta las fallas que ocurren cuando el usuario interactúa con la app y, por lo tanto, causan la mayor cantidad de interrupciones. Por este motivo, debes asegurarte de que tu app no supere el umbral de comportamiento inadecuado de esta métrica.

• Tasa de fallas: Es el porcentaje de usuarios diarios que experimentaron al menos una falla. Esta métrica incluye fallas que no se clasifican como percibidas por el usuario, pero no podemos garantizar que estas no afecten a los usuarios.

• Tasa de fallas múltiples: Es el porcentaje de usuarios diarios que experimentaron al menos dos fallas. Esta métrica ayuda a destacar los problemas que se reiteran.

Cómo corregir un problema

En el sitio de Android Developers, encontrarás orientación sobre cómo diagnosticar y solucionar fallas.

En la página Tiempo de inicio, puedes ver detalles de las instancias en las que tu app se inicia lentamente a partir de estados del sistema en los que la app se inicia en frío, en tibio y en caliente. El tiempo de inicio mide el tiempo que demora la app desde que el usuario la abre hasta que aparecen los primeros fotogramas en la pantalla. Esto también se conoce como "tiempo transcurrido hasta la visualización inicial".

Es posible que la app no esté lista para que el usuario empiece a interactuar con ella después de este momento, por ejemplo, si la app tiene pantallas de carga adicionales.

Detalles de recopilación de datos

• Solo se registran los tiempos de inicio cuando un usuario realiza una actividad.
  • Ejemplo: Para las apps de teclado, el tiempo de inicio es igual que el de la aplicación complementaria.
• Si se inicia varias veces una app el mismo día desde el mismo estado del sistema, se registra el tiempo de inicio máximo del día.
• Los tiempos de inicio se rastrean cuando se carga completamente el primer fotograma de la app, incluso aunque no sea una pantalla con la que los usuarios interactúen.
  • Ejemplo: Si se inicia una app con una pantalla de presentación, el tiempo de inicio equivale al tiempo necesario para cargar esa pantalla.

Detalles de vitals

• Sesiones afectadas: Indica el porcentaje de sesiones durante las que los usuarios experimentaron un tiempo de inicio lento para cada estado del sistema respectivo:
  • Inicio en frío lento: 5 segundos o más
  • Inicio lento de una app que está en la memoria: 2 segundos o más
  • Inicio lento de una app y actividades que están en la memoria: 1 segundo o más
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: Indica entre el 1% y el 10% de sesiones diarias en las que los usuarios experimentaron un tiempo de inicio lento de la app.

Cómo corregir un problema

Si la app tiene una gran cantidad de tiempos de inicio lento, consulta las soluciones recomendadas en el sitio para desarrolladores de Android.

Por qué es importante

Si usas sesiones lentas, podrás comprender el rendimiento de la velocidad de fotogramas de tu juego, que afecta la fluidez y homogeneidad del título para los usuarios.

Cómo leer los datos de la app

En la página Sesiones lentas, verás detalles sobre el porcentaje de sesiones diarias en las que los usuarios experimentaron un rendimiento de más del 25% de los fotogramas en velocidades más lentas que 30 o 20 FPS, según la comparativa que selecciones. También puedes ver la distribución de sesiones por velocidad de fotogramas con relación a tu juego (la velocidad de fotogramas a nivel de sesión se mide en el percentil 75, lo que significa que el 75% de los fotogramas alcanzan al menos esta velocidad).

La mayoría de los juegos en Google Play deben tener una velocidad de 30 FPS o superior. Esto proporciona una experiencia razonable para los usuarios, más allá del tipo de juego que usen (aunque algunos usuarios preferirán un mínimo de 60 FPS, especialmente en dispositivos de alta gama). Supervisa la métrica de tasa de sesiones lentas (30 FPS) para asegurarte de alcanzar esta barra. Ten en cuenta que esta métrica solo incluye sesiones en las que a más del 25% de los fotogramas les faltan 30 FPS, por lo que tiene cierta tolerancia a la variabilidad de la velocidad de fotogramas.

Si bien 30 FPS proporcionan una experiencia razonable, puede haber ocasiones o tipos de juegos en los que sea conveniente establecer la velocidad de fotogramas por debajo de ese número o en los que los usuarios quieran jugar en teléfonos que no admiten esa velocidad. En estas situaciones, al menos el 75% de los fotogramas de una sesión deberían alcanzar una velocidad de 20 FPS o superior. Supervisa la métrica de tasa de sesiones lentas (20 FPS) para asegurarte de cumplir con esta barra.

Android vitals informa sobre sesiones lentas (de 30 FPS y 20 FPS) tanto para cada dispositivo como para todos los dispositivos y sesiones. Usa la métrica general para comprender la experiencia integral del usuario, pero presta atención también al rendimiento por dispositivo. A su debido tiempo, Play comenzará a alejar a los usuarios de los juegos que no puedan alcanzar los 20 FPS en sus teléfonos.

Vitals solo comienza a supervisar la velocidad de fotogramas después de que el juego se ejecutó por 1 minuto.

Detalles de recopilación de datos

La métrica de sesiones lentas se calcula con datos recopilados de SurfaceFlinger. Más concretamente, la velocidad de fotogramas de una sesión se estima en función del tiempo entre fotogramas dibujados en las plataformas que tiene la app e incluye los fotogramas renderizados por OpenGL y Vulkan, así como el kit de herramientas de IU de Android. Actualmente, esta métrica solo está disponible para juegos.

Los datos de velocidad de fotogramas para sesiones lentas se recopilan en dispositivos que ejecutan Android 9 y versiones posteriores.

Pantalla del panel

• Velocidad representativa de fotogramas: Es la velocidad de fotogramas de tu juego en dispositivos con Android 9 o versiones posteriores, calculada en el percentil 75. Esto significa que el 75% de las sesiones tuvo esta velocidad de fotogramas o una más rápida el 75% del tiempo.
• Tasa de sesiones lentas a lo largo del tiempo: Es una serie temporal que muestra el porcentaje de sesiones que se consideran sesiones lentas.
• Distribución de la velocidad de fotogramas: Es el histograma que muestra la velocidad de fotogramas del percentil 75 en todas las sesiones. Esto significa que el 75% de los fotogramas de una sesión fueron más rápidos que la velocidad de fotogramas que se usó para agrupar la sesión.

Cómo corregir un problema

Si tu app tiene una gran cantidad de sesiones lentas, consulta las soluciones recomendadas en el sitio de Android Developers.

Cómo leer los datos de la app

En la página Demasiados fotogramas lentos, verás detalles sobre el porcentaje de sesiones diarias en las que los usuarios experimentaron más de un 50% de los fotogramas fuera del plazo de renderización objetivo del dispositivo. Las interacciones de los usuarios con la app deberían ejecutarse a 60 fotogramas por segundo sin pérdida ni retraso de fotogramas.

Detalles de recopilación de datos

Google recopila el tiempo de renderización de cada fotograma que procesa tu app cuando se usa el framework de herramientas de IU. No se recopilan los fotogramas que se renderizan directamente con OpenGL o Vulkan.

Pantalla del panel

Cuando selecciones una fila, verás los datos desglosados en percentiles.

• Sesiones afectadas: Indica el porcentaje de sesiones diarias en las que los usuarios experimentaron un tiempo de renderización superior a 16 ms en más del 50% de los fotogramas. Una sesión diaria hace referencia a un día en el que se usó la app. Por ejemplo, si dos usuarios utilizan la app durante dos días, se contarán cuatro sesiones diarias.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: Indica que entre un 90% y un 99% del total de los fotogramas tuvieron un tiempo de renderización inferior al valor que se indica. Estos números se basan en todos los fotogramas recopilados.

Cuando hagas clic en una entrada en la tabla, verás el gráfico "Distribución del tiempo de renderización de la IU". Cuando consultes el gráfico, asegúrate de que la mayoría de los fotogramas de la app sean iguales o inferiores a 16 ms.

Los datos que aparecen debajo del gráfico muestran el rendimiento de la app y pueden ayudarte a encontrar la causa de los problemas con el tiempo de renderización. Por ejemplo, si tu porcentaje de "latencia de entrada alta" es alto, es posible que debas revisar el código de tu app que procesa las entradas del usuario. Para obtener más información sobre estas métricas, prueba el rendimiento de la IU.

• Vsync perdidos: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de eventos perdidos de Vsync dividida por la cantidad de fotogramas.
• Latencia de entrada alta: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de eventos de entrada que tardaron más de 24 ms en procesarse, dividida por la cantidad de fotogramas.
• Subproceso de la IU lento: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces que el subproceso de IU tardó más de 8 ms en completarse, dividida por la cantidad de fotogramas.
• Comandos de dibujo lentos: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces en las que el envío de comandos de dibujo a la GPU tardó más de 12 ms, dividida por la cantidad de fotogramas.
• Cargas de mapas de bits lentas: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces en las que el mapa de bits tardó más de 3.2 ms en subirse a la GPU, dividida por la cantidad de fotogramas.

Cómo corregir un problema

Si la app tiene una gran cantidad de fotogramas con un tiempo de renderización mayor a 16 ms, consulta las soluciones recomendadas en el sitio de Android Developers.

Cómo leer los datos de la app

En la página Demasiados fotogramas lentos, verás detalles sobre el porcentaje de sesiones diarias en las que los usuarios experimentaron más de un 50% de los fotogramas fuera del plazo de renderización objetivo del dispositivo. Las interacciones de los usuarios con la app deberían ejecutarse a 60 fotogramas por segundo sin pérdida ni retraso de fotogramas.

Detalles de recopilación de datos

Google recopila el tiempo de renderización de cada fotograma que procesa tu app cuando se usa el framework de herramientas de IU. No se recopilan los fotogramas que se renderizan directamente con OpenGL o Vulkan.

Pantalla del panel

Cuando selecciones una fila, verás los datos desglosados en percentiles.

• Sesiones afectadas: Indica el porcentaje de sesiones diarias en las que los usuarios experimentaron un tiempo de renderización superior a 16 ms en más del 50% de los fotogramas. Una sesión diaria hace referencia a un día en el que se usó la app. Por ejemplo, si dos usuarios utilizan la app durante dos días, se contarán cuatro sesiones diarias.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: Indica que entre un 90% y un 99% del total de los fotogramas tuvieron un tiempo de renderización inferior al valor que se indica. Estos números se basan en todos los fotogramas recopilados.

Cuando hagas clic en una entrada en la tabla, verás el gráfico "Distribución del tiempo de renderización de la IU". Cuando consultes el gráfico, asegúrate de que la mayoría de los fotogramas de la app sean iguales o inferiores a 16 ms.

Los datos que aparecen debajo del gráfico muestran el rendimiento de la app y pueden ayudarte a encontrar la causa de los problemas con el tiempo de renderización. Por ejemplo, si tu porcentaje de "latencia de entrada alta" es alto, es posible que debas revisar el código de tu app que procesa las entradas del usuario. Para obtener más información sobre estas métricas, prueba el rendimiento de la IU.

• Vsync perdidos: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de eventos perdidos de Vsync dividida por la cantidad de fotogramas.
• Latencia de entrada alta: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de eventos de entrada que tardaron más de 24 ms en procesarse, dividida por la cantidad de fotogramas.
• Subproceso de la IU lento: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces que el subproceso de IU tardó más de 8 ms en completarse, dividida por la cantidad de fotogramas.
• Comandos de dibujo lentos: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces en las que el envío de comandos de dibujo a la GPU tardó más de 12 ms, dividida por la cantidad de fotogramas.
• Cargas de mapas de bits lentas: En el caso de los fotogramas que se renderizan a más de 16 ms, indica la cantidad de veces en las que el mapa de bits tardó más de 3.2 ms en subirse a la GPU, dividida por la cantidad de fotogramas.

Cómo corregir un problema

Si la app tiene una gran cantidad de fotogramas con un tiempo de renderización mayor a 16 ms, consulta las soluciones recomendadas en el sitio de Android Developers.

Las páginas Bloqueos de activación sostenidos parciales y Bloqueos de activación sostenidos parciales (en segundo plano) muestran los bloqueos de activación parciales adquiridos por la app mediante la clase PowerManager. Durante un bloqueo de activación parcial, la CPU estará activa, pero la pantalla y la retroiluminación del teclado podrán apagarse.

Detalles de recopilación de datos

• Por motivos de privacidad, las etiquetas de identificación de los bloqueos de activación son anónimas.
• Los datos sobre bloqueos de activación parciales se recopilan cuando el dispositivo no está cargando y la pantalla está apagada.
• Los datos de bloqueos de activación sostenidos parciales (en segundo plano) solo se recopilan cuando la app se ejecuta en segundo plano.
• Google calcula la duración máxima de los bloqueos de activación parcial por sesión de batería para mostrar cuántas sesiones se ven afectadas por un bloqueo de activación prolongado. Por ejemplo, si un usuario tiene dos bloqueos de activación de una hora, Google usará un valor máximo de bloqueo de activación sostenido de una hora.
• En el caso de las apps que establecen el valor de sharedUserId en el archivo de manifiesto, solo se mostrarán datos si se instala como máximo una app con el mismo valor de sharedUserId.

Detalles de vitals

• Sesiones afectadas: indica el porcentaje de sesiones de batería en las que los usuarios experimentaron al menos un bloqueo de activación de más de una hora.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: indica entre el 1% y el 10% de sesiones diarias en las que los usuarios experimentaron duraciones de bloqueos de activación parciales superiores al número que se indica.
• Límite de comportamiento inadecuado: si la app exhibe una tasa de ocurrencia igual o superior al umbral que se muestra, significa que está entre el 25% inferior de las 1,000 apps más destacadas de Google Play (por cantidad de instalaciones).

Cómo corregir un problema

Si la app tiene una gran cantidad de bloqueos de activación sostenidos parciales, consulta las soluciones recomendadas en el sitio para desarrolladores de Android.

La página Demasiadas activaciones muestra las activaciones de Alarm Manager que provoca tu app. Verás los datos de activaciones de las clases ELAPSED_REALTIME_WAKEUP o RTC_WAKEUP.

Detalles de recopilación de datos

• Por motivos de privacidad, las etiquetas de identificación de las activaciones son anónimas.
• Los datos sobre activaciones se recopilan cuando no se está cargando el dispositivo.
• Para proporcionar una métrica normalizada, se compara la cantidad de activaciones con el tiempo en que el dispositivo funciona con la batería. Google calcula la cantidad de activaciones por usuario por hora para mostrar cuántos usuarios se ven afectados por una tasa de activaciones alta.
• En el caso de las apps que establecen el valor de sharedUserId en el archivo de manifiesto, solo se mostrarán datos si se instala como máximo una app con el mismo valor de sharedUserId.

Detalles de vitals

• Sesiones afectadas: Indica el porcentaje de sesiones de batería en las que los usuarios experimentaron más de 10 activaciones por hora. Una sesión de batería es la agregación de todos los informes de batería que se reciben en un período determinado de 24 horas. En Android 10, un informe de batería hace referencia al intervalo entre dos cargas de batería, que puede ser desde menos del 20% hasta más del 80%, o desde cualquier valor hasta el 100%. En Android 11 y versiones posteriores, un informe de batería hace referencia a un período fijo de 24 horas. Google recopila datos únicamente cuando el dispositivo no está conectado al cargador.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: indica entre el 1% y el 10% de sesiones diarias en las que los usuarios experimentaron activaciones por hora superiores al valor que se indica.
• Límite de comportamiento inadecuado: si la app exhibe una tasa de ocurrencia igual o superior al umbral que se muestra, significa que está entre el 25% inferior de las 1,000 apps más destacadas de Google Play (por cantidad de instalaciones).

Cómo corregir un problema

Si la app tiene una gran frecuencia de activaciones, consulta las soluciones recomendadas en el sitio para desarrolladores de Android.

La página Demasiados escaneos de Wi-Fi (en segundo plano) muestra que los escaneos de Wi-Fi resultan en un uso elevado de la batería.

Detalles de recopilación de datos

Los datos sobre las búsquedas de Wi-Fi se recopilan cuando no se está cargando el dispositivo y la app está en segundo plano.

Detalles de vitals

• Sesiones afectadas: indica el porcentaje de sesiones de batería en las que los usuarios experimentaron más de 4 búsquedas de Wi-Fi por hora.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: Indica entre el 1% y el 10% de sesiones diarias en las que los usuarios experimentaron más búsquedas de Wi-Fi por hora en segundo plano que la cantidad que se muestra.

Cómo corregir un problema

Si tu app tiene una cantidad elevada de escaneos de Wi-Fi en segundo plano, accede al sitio de Android Developers para obtener las soluciones recomendadas.

La página Uso excesivo de la red móvil en segundo plano muestra que una gran cantidad de datos de red se asocian con un servicio en segundo plano. Cuando el uso de redes móviles ocurre en segundo plano, los usuarios no tienen fácil acceso a controles para detener la transferencia de datos.

Detalles de recopilación de datos

Los datos sobre el uso de la red móvil se recopilan cuando el dispositivo no se está cargando y la app está en segundo plano.

Detalles de vitals

• Sesiones afectadas: indica el porcentaje de sesiones de batería en que los usuarios experimentaron más de 50 MB de uso de red en segundo plano por día.
• Cantidad de sesiones: indica la cantidad aproximada de sesiones registradas.
• Percentil 90/99: Indica entre el 1% y el 10% de sesiones diarias en que los usuarios experimentaron un uso de red diario mayor en segundo plano que la cantidad que se muestra.

Cómo corregir un problema

Si la app tiene un uso elevado de red en segundo plano, consulta las soluciones recomendadas en el sitio para desarrolladores de Android.

En la página Denegaciones de permisos, puedes ver detalles acerca del porcentaje de sesiones diarias de permisos durante las que los usuarios denegaron permisos. Una sesión diaria de permisos hace referencia a un día durante el cual tu app solicitó al menos un permiso al usuario.

Detalles de recopilación de datos

Los datos sobre las denegaciones de permisos se recopilan cuando el usuario responde a solicitudes de permisos dentro de tu app.

Detalles de vitals

• Denegaciones: indica el porcentaje de sesiones de permisos diarios durante las que los usuarios rechazaron permisos.
• No volver a preguntar: indica el porcentaje de sesiones de permisos diarios durante las que los usuarios rechazaron permisos y seleccionaron la opción "No volver a preguntar".
• Total de sesiones: Indica la cantidad aproximada de sesiones registradas.

Cómo corregir un problema

Si la app tiene una gran cantidad de denegaciones de permisos, consulta las soluciones recomendadas en el sitio para desarrolladores de Android.

Google Play definió umbrales de comportamiento inadecuado en la tasa de ANR percibidos por el usuario:

• Comportamiento inadecuado general: Al menos el 0.47% de los usuarios activos por día experimentan y perciben un ANR en todos los modelos de dispositivos.

• Comportamiento inadecuado por dispositivo: Al menos el 8% de los usuarios activos por día experimentan y perciben un ANR en un solo modelo de dispositivo.

Para mejorar tu tasa de ANR, corrige los clústeres de ANR subyacentes que se informan en la página Fallas y ANR. Cuanto mayor sea la cantidad de usuarios afectados, más contribuirá el clúster a tu tasa de ANR.

Si hay aspectos específicos del hardware o software del dispositivo que podrían estar afectando tu tasa de ANR, Android vitals te enviará una notificación. También puedes explorar las asociaciones por tu cuenta en la página de descripción general de Alcance y dispositivos (Versión > Alcance y dispositivos > Descripción general).

Google Play definió umbrales de comportamiento inadecuado en la tasa de fallas percibidas por el usuario:

• Comportamiento inadecuado general: Al menos el 1.09% de los usuarios diarios experimentan y perciben una falla en todos los modelos de dispositivos.

• Comportamiento inadecuado por dispositivo: Al menos el 8% de los usuarios diarios experimentan y perciben una falla en un solo modelo de dispositivo.

Para mejorar tu tasa de fallas, corrige los clústeres de fallas subyacentes que se informan en la página Fallas y ANR. Cuanto mayor sea la cantidad de usuarios afectados, más contribuirá el clúster a tu tasa de fallas.

Si hay aspectos específicos del hardware o software del dispositivo que podrían estar afectando tu tasa de fallas, Android vitals te enviará una notificación. También puedes explorar las asociaciones por tu cuenta en la página de descripción general de Alcance y dispositivos (Versión > Alcance y dispositivos > Descripción general).