Nuevas estadísticas sobre los problemas y las recomendaciones de calidad de las apps
Por ahora, se muestran problemas de compatibilidad de la app, comportamientos inadecuados y algunas recomendaciones de UX. Seguiremos detectando y mostrando más problemas de calidad, y proporcionaremos más recomendaciones durante el próximo año.
Usa Android vitals para comprender y mejorar la estabilidad, el rendimiento, el uso de batería y otros factores de tu app.
Elige cómo acceder a los datos de tu app
Puedes usar Android vitals de dos maneras: a través de Play Console y con la API de Play Developer Reporting.
La API proporciona acceso programático a Android vitals para los desarrolladores que quieran integrar datos de Android vitals con otros conjuntos de datos o incorporarlos a sus flujos de trabajo. Para obtener más información sobre cómo usar una API para acceder a Android vitals, visita la página de la API de Google Play Developer Reporting.
Para buscar y revisar los datos de Android vitals relacionados con tus apps en Play Console, sigue estos pasos:
- Abre Play Console y ve a la página Información general de Android vitals (Supervisa y mejora > Android vitals > Información general).
- Usa el selector de períodos que se encuentra en la esquina superior derecha para elegir el período de datos que quieres ver.
Importante: Si no hay información disponible, significa que tu app no tiene suficientes datos en los filtros especificados para identificar problemas.
En la parte superior de la página Información general de Android vitals, puedes ver datos sobre las métricas esenciales de tu app, es decir, las métricas técnicas más importantes que afectan la visibilidad de tu app en Google Play. Entre las métricas esenciales, se incluyen las siguientes:
Google Play define los umbrales de comportamiento inadecuado en función de estas métricas. Si tu app los excede, es probable que sea menos visible en Google Play. En algunos casos, es posible que se muestre una advertencia en la ficha de Play Store de tu app para establecer las expectativas de los usuarios.
Puedes usar la sección "Problemas críticos" para identificar rápidamente las áreas en las que tu app puede mejorar. Existen dos tipos de problemas críticos:
- Comportamientos inadecuados: Son métricas que exceden los umbrales de comportamiento inadecuado.
- Anomalías: Son cambios significativos en los datos (por ejemplo, un gran aumento en la tasa de errores de ANR percibidos por el usuario).
Para recibir notificaciones por correo electrónico, ve a Configuración > Notificaciones o haz clic en Administrar notificaciones en la esquina de la sección "Métricas esenciales" (Supervisa y mejora > Android vitals > Información general). Ten en cuenta que, actualmente, las notificaciones solo están disponibles para las anomalías.
Cerca de la mitad de la página Información general de Android vitals, verás datos sobre todas las métricas de vitals por aspecto de calidad.
En la tabla, puedes revisar tus métricas para los períodos actuales y anteriores, así como ver una comparación de tu app con otras de Google Play.
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
Para ayudarte a organizar, segmentar y analizar tus datos, las métricas se desglosan en diferentes dimensiones. Todas las métricas tienen los siguientes desgloses:
- Artefacto: Indica la versión de tu app en la que ocurrió el problema.
- Versión de Android (SDK): Indica la versión del SO Android que se informó desde el dispositivo del usuario.
- Factor de forma: Es el tipo de dispositivo en el que se ejecutó la app (por ejemplo, teléfono, tablet, TV o wearable).
- Modelo del dispositivo: Es una descripción de nivel superior del dispositivo, que consta de una marca y un identificador de dispositivo únicos, como "Google Oriole". Cada modelo puede tener variantes con diferentes versiones de Android, RAM, almacenamiento o sistema en chip (SoC).
- País o región: Es la ubicación que informa el dispositivo del usuario en el momento del problema.
Sugerencia: Para obtener desgloses por aspectos específicos de hardware o software del dispositivo (por ejemplo, modelo de dispositivo o versión de Android), puedes hacer clic en el símbolo (
) que está junto al elemento de la tabla.
Algunas métricas tienen desgloses adicionales:
- Nombre del bloqueo de activación: Se establece de manera programática cuando se usa la API de PowerManager en tu app.
- Nombre de activación: Se establece de manera programática cuando se usa la API de AlarmManager en tu app.
- Nombre de actividad de ANR: Indica el nombre completamente calificado de la clase de actividad en que ocurrió el error de ANR (si está disponible).
- Tipo de ANR: Indica cuándo ocurrió el error de ANR; por ejemplo, al ejecutar un servicio (si está disponible).
Para ver más detalles cuando estén disponibles (por ejemplo, los clústeres de fallas o ANR asociados con ese desglose), selecciona Ver detalles () junto al elemento.
Nota: Puedes alternar entre las métricas de una sola categoría con el botón de activación ubicado en la parte superior de la pantalla y, luego, filtrar la página.
Tipos de datos y métricas
Los datos de Android vitals están disponibles para los últimos 90 días en Play Console y durante tres años en la API de Play Developer Reporting.
Se recopilan los datos de aquellos usuarios que aceptaron compartir automáticamente los datos de uso y diagnóstico de un subconjunto de dispositivos Android y versiones de SO. Para obtener más información sobre cómo los usuarios de Android aceptan compartir datos, visita el Centro de ayuda de cuentas.
Android vitals se actualiza todos los días. En ocasiones, los datos de dispositivos con Android 10 o versiones posteriores pueden llegar antes que los de dispositivos con versiones anteriores. Si esto ocurre, solo verás datos de Android 10 o versiones posteriores para los días en que estén disponibles.
Nota: Las métricas de Android vitals no incluyen los problemas técnicos que ocurren en modelos de dispositivos no certificados o en versiones de tu app que no se instalaron a través de Google Play.
Contraer todo Expandir todo
Estabilidad
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 los usuarios activos por día, cada uno de los cuales 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 múltiples 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 errores de ANR percibidos por el usuario: Es el porcentaje de usuarios activos por día que experimentaron al menos un error de este tipo. Un error de ANR percibido por el usuario es un error de ANR que probablemente haya notado el usuario. Actualmente, solo se contabilizan los errores de ANR de "tiempo de espera para el ingreso de datos 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 errores de este tipo.
La tasa de errores de 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 error de 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 errores de 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, cada uno de los cuales 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 al menos una falla de este tipo. 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.
Tiempos de inicio y carga
En la página Tiempo de inicio, puedes ver detalles de las instancias en las que tu app se inicia lentamente cuando el sistema está en frío, semicaliente 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 para 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: Es el porcentaje de sesiones durante las que los usuarios experimentaron lentitud al iniciar la app en cada estado del sistema:
- Inicio en frío lento: Es cuando la app demora 5 segundos o más en iniciarse.
- Inicio semicaliente lento: Es cuando la app demora 2 segundos o más en iniciarse.
- Inicio lento de una app y actividades que están en la memoria: 1 segundo o más
- Cantidad de sesiones: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican el 10% y el 1% de sesiones diarias en las que los usuarios experimentaron un tiempo de inicio lento de tu 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.
Renderización
Toda la renderización
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 con más del 25% de los fotogramas que se ejecutaron 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 este umbral. 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 este umbral.
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 haya funcionado durante al menos 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 solucionar un problema
Si tu app tiene muchas sesiones lentas, consulta las soluciones recomendadas en el sitio de Android Developers.
Renderización del kit de herramientas de IU de Android
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 un rendimiento con más del 50% de los fotogramas por 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican que el 90% y el 99% del total de los fotogramas tuvieron un tiempo de renderización inferior al número que se indica. Estos números se basan en todos los fotogramas recopilados.
Cuando hagas clic en una entrada de 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 renderización de la app y pueden ayudarte a encontrar la causa raíz de los problemas relacionados 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.
- Vsyncs 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 completarse, dividida por la cantidad de fotogramas.
- Subproceso de 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 un rendimiento con más del 50% de los fotogramas por 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican que el 90% y el 99% del total de los fotogramas tuvieron un tiempo de renderización inferior al número que se indica. Estos números se basan en todos los fotogramas recopilados.
Cuando hagas clic en una entrada de 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 renderización de la app y pueden ayudarte a encontrar la causa raíz de los problemas relacionados 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.
- Vsyncs 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 completarse, dividida por la cantidad de fotogramas.
- Subproceso de 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.
Uso de batería
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 parciales 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 bloqueos de activación de dos horas, Google usará un valor máximo de bloqueo de activación 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: 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican el 10% y el 1% de sesiones diarias en las que los usuarios experimentaron duraciones de bloqueos de activación parciales superiores al número que se indica.
- Umbral de comportamiento inadecuado: Si la app exhibe una tasa de ocurrencia igual o superior al umbral que se muestra, significa que está en el 25% inferior de las 1,000 apps principales 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: Es 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 específico de 24 horas. En Android 10, un informe de batería hace referencia al intervalo entre dos cargas, 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican el 10% y el 1% de sesiones diarias en las que los usuarios experimentaron activaciones por hora superiores al valor que se indica.
- Umbral de comportamiento inadecuado: Si la app exhibe una tasa de ocurrencia igual o superior al umbral que se muestra, significa que está en el 25% inferior de las 1,000 apps principales 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indica el 10% y el 1% de sesiones diarias en las que los usuarios experimentaron más búsquedas de Wi-Fi por hora en segundo plano que el número que se muestra.
Cómo corregir un problema
Si tu app tiene muchas búsquedas de Wi-Fi en segundo plano, accede al sitio de Android Developers para conocer las soluciones recomendadas.
La página Uso excesivo de la red indica cuándo 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 los 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: Es 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: Es la cantidad aproximada de sesiones grabadas.
- Percentil 90/99: Indican el 10% y el 1% de sesiones diarias en las que los usuarios experimentaron un uso de red diario mayor en segundo plano que el número que se indica.
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.
Permisos
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: El porcentaje de sesiones de permisos diarios durante las que los usuarios denegaron permisos.
- No volver a preguntar: Es el porcentaje de sesiones diarias de permisos en las que los usuarios seleccionaron la opción No volver a preguntar para denegar los permisos.
- Total de sesiones: Es 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 las métricas esenciales de tu app.
Si tu app supera un umbral de comportamiento inadecuado, es probable que sea menos visible en Google Play. Asimismo, cuando la app tiene un comportamiento inadecuado en modelos de dispositivos específicos, Google Play conduce a los usuarios de esos dispositivos fuera de los títulos en cuestión y los dirige hacia otros más adecuados para ellos. En algunos casos, es posible que se muestre una advertencia en la ficha de Play Store de tu app para establecer las expectativas de los usuarios y ofrecer la opción de buscar alternativas con mayor calidad técnica.
Por lo general, Google Play tendrá en cuenta los datos de los últimos 28 días cuando evalúe la calidad de tu app, pero es posible que actúe antes en caso de un aumento repentino de comportamientos inadecuados.
Contraer todo Expandir todo
Estabilidad
Google Play definió umbrales de comportamiento inadecuado en la tasa de errores de ANR percibidos por el usuario:
-
Comportamiento inadecuado general: Al menos el 0.47% de los usuarios activos por día experimentan un error de ANR percibido por el usuario en todos los modelos de dispositivos.
-
Comportamiento inadecuado por dispositivo: Al menos el 8% de los usuarios activos por día experimentan un error de ANR percibido por el usuario 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 (Supervisa y mejora > 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 por día experimentan una falla percibida por el usuario en todos los modelos de dispositivos.
-
Comportamiento inadecuado por dispositivo: Al menos el 8% de los usuarios por día experimentan una falla percibida por el usuario 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 (Supervisa y mejora > Alcance y dispositivos > Descripción general).
Contenido relacionado
Descubre las recomendaciones para usar Android vitals a fin de mejorar el rendimiento y la estabilidad de la app.