Novos insights sobre problemas de qualidade de apps e recomendações
Por enquanto, essas informações incluem problemas de compatibilidade do app, maus comportamentos e algumas recomendações de UX. No próximo ano, vamos continuar detectando e mostrando mais problemas de qualidade, além de oferecer outras recomendações.
Use o Android vitals para entender e melhorar a estabilidade, o desempenho, o uso da bateria e outros aspectos do app.
Escolher como acessar os dados do seu app
Há duas maneiras de usar o Android vitals: pelo Play Console ou pela API Play Developer Reporting.
A API oferece acesso programático ao Android vitals para desenvolvedores que querem integrar os dados do recurso a outros conjuntos de dados ou aos fluxos de trabalho. Para saber mais sobre como usar uma API para acessar o Android vitals, consulte a página da API Google Play Developer Reporting.
Para encontrar e analisar dados do app no Android vitals usando o Play Console, siga estas etapas:
- Abra o Play Console e acesse a página Visão geral do Android vitals (Monitorar e melhorar > Android vitals > Visão geral).
- Use o seletor de período no canto superior direito para escolher o intervalo de dados que você quer ver.
Importante: se não houver dados disponíveis, o app não terá pontos de dados suficientes nos filtros especificados para identificar problemas.
Na parte superior da página Visão geral do Android vitals, você pode ver dados sobre as principais métricas do app. Elas são as métricas técnicas mais importantes e afetam a detecção do seu app no Google Play. Veja algumas das principais métricas:
O Google Play define limites de mau comportamento nessas métricas. Se o app ultrapassar esses limites, ele vai ter menos chances de ser descoberto no Google Play. Em alguns casos, um aviso é exibido na página "Detalhes do app" para definir as expectativas dos usuários.
Use a seção "Problemas críticos" para identificar rapidamente as áreas do app que podem melhorar. Há dois tipos de problemas críticos:
- Maus comportamentos: métricas que ultrapassam os limites de mau comportamento.
- Anomalias: mudanças significativas nos dados, como um aumento significativo na taxa de ANR percebido pelo usuário.
Para receber notificações por e-mail, acesse Configuração > Notificações ou clique em Gerenciar notificações no canto da seção "Principais métricas" (Monitorar e melhorar > Android vitals > Visão geral). No momento, as notificações estão disponíveis apenas para anomalias.
No meio da página Visão geral do Android vitals você encontra as informações de todas as métricas por aspecto de qualidade.
Na tabela, é possível analisar suas métricas referentes aos períodos atual e anterior. Também é possível comparar o desempenho do seu app com o de outros no Google Play.
Para mais detalhes sobre uma métrica, selecione Ver detalhes (
) ao lado dela. Na tela seguinte, você encontra estes dados:
- Limites de mau comportamento
- Comparativos de mercado por categoria
- Comparativos de mercado detalhados
- Próximo à parte superior da página, no card de comparação, selecione Editar grupo de apps semelhantes para alterar um grupo personalizado. Depois de criar um grupo, você pode comparar o desempenho dos apps semelhantes do Google Play selecionados ao do seu.
- Tendência de métricas ao longo do tempo
Para ajudar você a organizar, segmentar e analisar os dados, as métricas são divididas em várias dimensões. Todas as métricas têm os seguintes detalhamentos:
- Artefato: é a versão do app em que o problema ocorreu.
- Versão do Android (SDK): é a versão do SO Android informada pelo dispositivo do usuário.
- Formato: é o tipo de dispositivo em que o app foi executado (por exemplo, "Smartphone", "Tablet", "TV" ou "Wearable").
- Modelo do dispositivo: é uma descrição de alto nível do dispositivo, que consiste em uma marca única e um identificador do dispositivo, por exemplo, "Google Oriole". Um único modelo de dispositivo pode ter variantes com diferentes versões do Android, RAM, armazenamento ou system on chip (SoC).
- País/região: é o local informado pelo dispositivo do usuário no momento do problema.
Dica: para ver detalhamentos de aspectos específicos do hardware ou software do dispositivo (por exemplo, modelo do dispositivo ou versão do Android), clique no símbolo (
) ao lado do item na tabela.
Algumas métricas têm outros detalhamentos:
- Nome do wake lock: são as tags que foram definidas programaticamente ao usar a API PowerManager no app.
- Nome da ativação: são as tags que foram definidas programaticamente ao usar a API AlarmManager no app.
- Nome da atividade de ANR: é o nome totalmente qualificado da classe de atividade em que ocorreu o ANR (se disponível).
- Tipo de ANR: é o momento em que o ANR ocorreu, por exemplo, ao executar um serviço (se disponível).
Se estiverem disponíveis, selecione Ver detalhes () ao lado do item para, por exemplo, analisar os clusters de falhas ou ANR associados a ele.
Dica: é possível alternar entre as métricas em uma única categoria usando o botão na parte superior da tela e filtrar a página.
Tipos de dados e métricas
Os dados do Android vitals estão disponíveis para os últimos 90 dias no Play Console e por três anos na API Play Developer Reporting.
Os dados são coletados de usuários que ativaram o compartilhamento automático de dados de uso e diagnóstico de um subconjunto de dispositivos Android e versões de SO. Para mais informações sobre como os usuários do Android ativam o compartilhamento de dados, acesse a Central de Ajuda de Contas.
O Android vitals é atualizado diariamente. Às vezes, os dispositivos com Android 10 ou versões mais recentes recebem os dados antes do que os com versões mais antigas. Se isso acontecer, você vai ver os dados do Android 10 ou versões mais recentes de dias em que apenas este grupo de dispositivos vai ter dados disponíveis.
Observação: as métricas do Android vitals excluem problemas técnicos que ocorrem em modelos de dispositivo não certificados ou em versões do app que não foram instaladas pelo Google Play.
Fechar tudo Abrir tudo
Estabilidade
As métricas de taxa de ANR mostram uma visão geral da qualidade do app. Elas são calculadas com a normalização do número de usuários com falhas com base no uso do app. Eles são contabilizados como uma porcentagem de usuários ativos por dia, que são definidos como usuários que usam o app em um único dia em um dispositivo. Se um usuário usar o app em mais de um dispositivo em um único dia, cada dispositivo vai contribuir para o número de usuários ativos nesse dia. Se vários usuários usarem o mesmo dispositivo em um único dia, isso vai ser contabilizado como um usuário ativo.
Há três métricas de taxa de ANR:
- Taxa de ANR percebido pelo usuário: é a porcentagem de usuários ativos por dia que perceberam pelo menos um ANR. Um ANR percebido pelo usuário é um ANR que provavelmente foi observado pelo usuário. Atualmente, somente os ANRs do tipo "tempo de entrega de entradas esgotado" são contabilizados. Essa métrica é sempre menor que a taxa de ANR geral, porque é normalizada pelo uso diário, mas não conta todos os ANRs.
A taxa de ANR percebido pelo usuário é uma das principais métricas, ou seja, ela afeta a possibilidade de descoberta do app no Google Play. Ela é importante porque os ANRs que ela conta sempre ocorrem quando o usuário está usando o app, o que causa mais interrupções.
- Taxa de ANR: é a porcentagem de usuários diários que tiveram pelo menos um ANR. Essa métrica inclui ANRs que não são classificados como percebidos pelo usuário, mas não podemos garantir que eles não estejam afetando os usuários.
- Taxa de ANRs múltiplos: é a porcentagem de usuários diários que tiveram pelo menos dois ANRs. Essa métrica ajuda a destacar loops de problemas.
Corrigir um problema
Os ANRs que contribuem para as métricas de taxa de ANR são exibidos na página Falhas e ANRs. É possível filtrar por ANRs percebidos pelo usuário nesta página.
O site Desenvolvedores Android tem orientações sobre como diagnosticar e corrigir ANRs.
As métricas de taxa de falhas mostram uma visão geral da qualidade do app. Elas são calculadas com a normalização do número de usuários com falhas com base no uso do app. Eles são contabilizados como uma porcentagem de usuários por dia, que são definidos como usuários que usam o app em um único dia em um dispositivo. Se um usuário tem mais de um dispositivo, ele é contado mais de uma vez. Por exemplo, se dois usuários utilizarem o app por dois dias, cada um em um dispositivo, isso vai produzir quatro sessões diárias.
Há três métricas de taxa de falhas:
- Taxa de falhas percebidas pelo usuário: é a porcentagem de usuários diários que tiveram pelo menos uma falha percebida pelo usuário. Uma falha percebida pelo usuário é uma falha que provavelmente foi observada pelo usuário. Por exemplo, falhas que ocorrem quando o app está exibindo uma atividade ou sendo executado como um serviço em primeiro plano. Essa métrica é sempre menor que a taxa de falhas geral, porque é normalizada pelo uso diário, mas não conta todas as falhas.
A taxa de falhas percebidas pelo usuário é uma das principais métricas, ou seja, ela afeta a possibilidade de descoberta do app no Google Play. Isso é importante porque as falhas contadas sempre ocorrem quando o usuário está engajado com o app, causando mais interrupções. Por isso seu app não pode ultrapassar o
limite de mau comportamento dessa métrica.
-
Taxa de falhas: é a porcentagem dos usuários diários que tiveram pelo menos uma falha. Essa métrica inclui falhas que não são classificadas como percebidas pelo usuário, mas não podemos garantir que elas não estejam afetando os usuários.
-
Taxa de falhas múltiplas: é a porcentagem de usuários diários que tiveram pelo menos duas falhas. Essa métrica ajuda a destacar loops de problemas.
Corrigir um problema
O site para desenvolvedores Android oferece orientações sobre como diagnosticar e corrigir falhas.
Tempos de inicialização e carregamento
Na página Tempo de inicialização, você vê detalhes sobre a inicialização lenta nos estados do sistema: a frio, com estado salvo e a quente. O tempo de inicialização é o período entre a inicialização do app e a exibição dos primeiros frames na tela. Também conhecido como "tempo para exibição inicial".
Talvez o app não esteja pronto para receber interações dos usuários após esse período, por exemplo, se ele tiver telas de carregamento adicionais.
Detalhes da coleta de dados
- Os tempos de inicialização são registrados somente quando um usuário aciona uma atividade.
- Exemplo: para apps de teclado, o tempo de inicialização é igual ao tempo de inicialização do app complementar.
- Se um app é iniciado várias vezes no mesmo dia com o mesmo estado do sistema, o tempo máximo de inicialização do dia é registrado.
- Os tempos de inicialização são rastreados quando o primeiro quadro do app é carregado completamente, mesmo que não seja uma tela de interação com o usuário.
- Exemplo: se um app iniciar com uma tela de apresentação, o tempo de inicialização será igual ao tempo necessário para exibir a tela de apresentação.
Detalhes importantes
- Sessões afetadas: é a porcentagem de sessões em que o tempo de inicialização foi lento para cada estado do sistema relacionado:
- Inicialização a frio lenta: cinco segundos ou mais.
- Inicialização com estado salvo lenta: dois segundos ou mais
- Inicialização a quente lenta: um segundo ou mais
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o tempo de inicialização do app foi lento.
Corrigir um problema
Se o app tiver um número elevado de tempos de inicialização lentos, veja as soluções recomendadas no site para desenvolvedores Android.
Renderização
Toda a renderização
Por que isso é importante
Com as sessões lentas, é possível entender o desempenho do frame rate do jogo, o que afeta a fluidez dele para os usuários.
Interpretar os dados do app
A página "Sessões lentas" mostra detalhes sobre a porcentagem de sessões diárias em que mais de 25% dos frames tiveram uma exibição mais lenta do que 30 ou 20 QPS, dependendo do comparativo que você selecionar. Você também pode acessar a distribuição de sessões por frame rate para o jogo. O frame rate no nível da sessão é medido no 75º percentil, ou seja, 75% dos frames têm esse valor pelo menos.
A maioria dos jogos no Google Play precisa ter 30 QPS ou mais. Isso oferece uma experiência razoável para os usuários em todos os tipos de jogos, embora alguns usuários prefiram pelo menos 60 QPS, especialmente em dispositivos mais avançados. Monitore a métrica de taxa de sessão lenta (30 QPS) para garantir que você esteja cumprindo os requisitos. Essa métrica inclui apenas sessões em que mais de 25% dos frames não chegam a 30 QPS. Por isso, ela tem tolerância à variabilidade de frame rate.
Embora 30 QPS ofereçam uma experiência razoável, pode haver momentos ou tipos de jogos em que faz sentido reduzir o frame rate. Além disso, talvez alguns usuários joguem em smartphones incompatíveis com 30 QPS. Nesses cenários, pelo menos 75% dos frames em uma sessão ainda precisam alcançar 20 QPS ou mais. Monitore a métrica de taxa de sessão lenta (20 QPS) para garantir que você esteja cumprindo os requisitos.
O Android vitals inclui métricas de sessões lentas a 30 e a 20 QPS para cada dispositivo, assim como em todos os dispositivos e sessões. Use a métrica geral para entender a experiência geral do usuário, mas preste atenção também no desempenho por dispositivo. No futuro, o Google Play vai direcionar os usuários a outras opções quando os jogos não alcançam 20 QPS no smartphone.
O Android vitals só começa a monitorar o frame rate depois de o jogo rodar por 1 minuto.
Detalhes da coleta de dados
A métrica de sessões lentas é calculada com os dados coletados pelo SurfaceFlinger. De maneira mais concreta, o frame rate de uma sessão é estimado com base no tempo entre os frames renderizados em plataformas do app e inclui frames renderizados pelo OpenGL, pelo Vulkan e pelo kit de ferramentas de interface do Android. No momento, essa métrica está disponível somente para jogos.
Os dados de frame rate para sessões lentas são coletados de dispositivos com Android 9 ou versões mais recentes.
Painel de exibição
- Frame rate representativo: é o desempenho de frame rate do jogo em dispositivos com o Android 9 ou versões mais recentes, calculado no 75º percentil. Isso significa que 75% das sessões tiveram frame rate igual ou superior a esse 75% das vezes.
- Taxa de sessão lenta ao longo do tempo: é uma série temporal que mostra a porcentagem de sessões consideradas lentas.
- Distribuição de frame rate: é o histograma que mostra o 75º percentil do frame rate em todas as sessões. Isso significa que 75% dos frames em uma sessão foram mais rápidos do que o frame rate usado para agrupar a sessão.
Corrigir um problema
Se o app tiver um número elevado de sessões lentas, veja as soluções recomendadas no site para desenvolvedores Android.
Renderização do kit de ferramentas de interface do Android
Interpretar os dados do app
Na página "Excesso de frames lentos", você encontra detalhes sobre a porcentagem de sessões diárias em que mais de 50% de frames não atingiram o tempo de renderização do dispositivo. As interações do usuário com o app precisam ser executadas a 60 quadros por segundo sem frames perdidos ou atrasados.
Detalhes da coleta de dados
O Google registra o tempo de renderização de cada frame renderizado pelo app ao usar o framework do kit de ferramentas de IU. Os frames renderizados usando o OpenGL ou o Vulkan diretamente não são registrados.
Painel de exibição
Quando você selecionar uma linha, verá os dados divididos em percentuais.
- Sessões afetadas: é a porcentagem de sessões diárias em que mais de 50% dos frames tiveram um tempo de renderização maior que 16 ms. Uma sessão diária é um dia em que o app foi usado. Por exemplo, se dois usuários utilizarem o app por dois dias, serão quatro sessões diárias.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: 90%/99% do total de frames teve um tempo de renderização menor do que o número mostrado. Esses números são baseados em todos os frames coletados.
Ao clicar em uma entrada na tabela, você vê o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, confira se a maioria dos frames do app tem um tempo de renderização de até 16 ms.
Os dados abaixo do gráfico transmitem o desempenho de renderização do app e podem ajudar você a encontrar a causa raiz de algum problema com o tempo de renderização. Por exemplo, se a porcentagem de "Latência de entrada alta" for alta, confira o código do app que processa a entrada do usuário. Para mais informações sobre essas métricas, acesse testar o desempenho da IU.
- Vsyncs perdidos: para todos os frames renderizados em mais de 16 ms, é o número de eventos Vsync perdidos dividido pela quantidade de frames.
- Latência de entrada alta: para todos os frames renderizados em mais de 16 ms, é o número de eventos de entrada que levaram mais de 24 ms dividido pela quantidade de frames.
- Linha de execução de interface lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de interface levou mais de 8 ms para ser concluída dividido pela quantidade de frames.
- Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o envio de comandos de desenho à GPU levou mais de 12 ms dividido pela quantidade de frames.
- Uploads de bitmap lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o bitmap levou mais de 3,2 ms para fazer upload para a GPU dividido pela quantidade de frames.
Corrigir um problema
Se o app tiver um número elevado de frames com tempo de renderização acima de 16 ms, confira as soluções recomendadas no site para Desenvolvedores Android.
Interpretar os dados do app
Na página "Excesso de frames lentos", você encontra detalhes sobre a porcentagem de sessões diárias em que mais de 50% de frames não atingiram o tempo de renderização do dispositivo. As interações do usuário com o app precisam ser executadas a 60 quadros por segundo sem frames perdidos ou atrasados.
Detalhes da coleta de dados
O Google registra o tempo de renderização de cada frame renderizado pelo app ao usar o framework do kit de ferramentas de IU. Os frames renderizados usando o OpenGL ou o Vulkan diretamente não são registrados.
Painel de exibição
Quando você selecionar uma linha, verá os dados divididos em percentuais.
- Sessões afetadas: é a porcentagem de sessões diárias em que mais de 50% dos frames tiveram um tempo de renderização maior que 16 ms. Uma sessão diária é um dia em que o app foi usado. Por exemplo, se dois usuários utilizarem o app por dois dias, serão quatro sessões diárias.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: 90%/99% do total de frames teve um tempo de renderização menor do que o número mostrado. Esses números são baseados em todos os frames coletados.
Ao clicar em uma entrada na tabela, você vê o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, confira se a maioria dos frames do app tem um tempo de renderização de até 16 ms.
Os dados abaixo do gráfico transmitem o desempenho de renderização do app e podem ajudar você a encontrar a causa raiz de algum problema com o tempo de renderização. Por exemplo, se a porcentagem de "Latência de entrada alta" for alta, confira o código do app que processa a entrada do usuário. Para mais informações sobre essas métricas, acesse testar o desempenho da IU.
- Vsyncs perdidos: para todos os frames renderizados em mais de 16 ms, é o número de eventos Vsync perdidos dividido pela quantidade de frames.
- Latência de entrada alta: para todos os frames renderizados em mais de 16 ms, é o número de eventos de entrada que levaram mais de 24 ms dividido pela quantidade de frames.
- Linha de execução de interface lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de interface levou mais de 8 ms para ser concluída dividido pela quantidade de frames.
- Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o envio de comandos de desenho à GPU levou mais de 12 ms dividido pela quantidade de frames.
- Uploads de bitmap lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o bitmap levou mais de 3,2 ms para fazer upload para a GPU dividido pela quantidade de frames.
Corrigir um problema
Se o app tiver um número elevado de frames com tempo de renderização acima de 16 ms, confira as soluções recomendadas no site para Desenvolvedores Android.
Uso da bateria
As páginas Wake locks parciais travados e Wake locks parciais travados (segundo plano) mostram wake locks parciais obtidos pelo app com a classe "PowerManager". Um wake lock parcial garante que a CPU esteja funcionando, mas que a luz de fundo do teclado e da tela possa ser desativada.
Detalhes da coleta de dados
- Para fins de privacidade, as tags de identificação dos wake locks parciais são mantidas anônimas.
- Os dados sobre wake locks parciais são coletados quando o dispositivo não está sendo carregado e a tela está desligada.
- Os dados sobre wake locks parciais travados (segundo plano) só são coletados quando o app está em funcionando em segundo plano.
- O Google calcula o tempo máximo do wake lock parcial por sessão de duração da bateria para mostrar quantas sessões são afetadas por um wake lock longo. Por exemplo, se um usuário acionar wake locks de duas horas, o Google vai usar um valor máximo de uma hora de wake lock.
- No caso de apps que definem o
sharedUserId no arquivo de manifesto, os dados só vão estar disponíveis se no máximo um app com o mesmo sharedUserId estiver instalado.
Detalhes importantes
- Sessões afetadas: porcentagem de sessões diárias em que houve pelo menos um wake lock de mais de uma hora.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que os usuários foram afetados por wake locks parciais com duração maior do que o número exibido.
- Limite de mau comportamento: se o app tem uma taxa de ocorrência igual ou superior ao limite mostrado, ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações).
Corrigir um problema
Se o app tiver um número alto de wake locks parciais travados, acesse o site para desenvolvedores Android e veja as soluções recomendadas.
A página Ativações excessivas mostra as ativações do Alarm Manager acionadas pelo app. Você vai ver os dados de ativação das classes ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.
Detalhes da coleta de dados
- Para fins de privacidade, as tags de identificação das ativações são mantidas anônimas.
- As ativações são coletadas quando o dispositivo não está carregando.
- Para mostrar uma métrica normalizada, o número de ativações é comparado ao tempo de uso da bateria. O Google calcula o número de ativações por usuário a cada hora para mostrar quantas pessoas são afetadas por uma alta taxa de ativações.
- No caso de apps que definem o
sharedUserId no arquivo de manifesto, os dados só vão estar disponíveis se no máximo um app com o mesmo sharedUserId estiver instalado.
Detalhes importantes
- Sessões afetadas: é a porcentagem de durações da bateria em que houve mais de 10 ativações por hora. A duração da bateria é a agregação de todos os relatórios de bateria recebidos em um determinado período de 24 horas. No Android 10, um relatório de bateria cobre o intervalo entre duas cargas de menos de 20% a mais de 80% ou de qualquer valor a 100%. No Android 11 e versões mais recentes, um relatório de bateria se refere a um período fixo de 24 horas. O Google coleta os dados somente quando o dispositivo não está sendo carregado.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o número de ativações por hora foi maior que o valor exibido.
- Limite de mau comportamento: se o app tem uma taxa de ocorrência igual ou superior ao limite mostrado, ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações).
Corrigir um problema
Se o app tiver ativações frequentes, veja as soluções recomendadas no site para desenvolvedores Android.
A página Excesso de verificações de Wi-Fi (segundo plano) mostra quando as verificações de Wi-Fi exigem um uso elevado da bateria.
Detalhes da coleta de dados
Os dados sobre a verificação de Wi-Fi são coletados quando o dispositivo não está carregando e o app está em segundo plano.
Detalhes importantes
- Sessões afetadas: é a porcentagem de durações da bateria em que houve mais de quatro buscas por Wi-Fi por hora.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o número de buscas por Wi-Fi em segundo plano por hora foi maior que o valor exibido.
Corrigir um problema
Caso seu app apresente um número alto de verificações de Wi-Fi em segundo plano, confira as soluções recomendadas no site para desenvolvedores Android.
A página Uso excessivo da rede mostra quando uma grande quantidade de dados de rede está associada a um serviço em segundo plano. Por causa do uso da rede móvel em segundo plano, os usuários não têm fácil acesso aos controles para interromper a transferência de dados.
Detalhes da coleta de dados
Os dados sobre o uso da rede móvel são coletados quando o dispositivo não está carregando e o app está em segundo plano.
Detalhes importantes
- Sessões afetadas: é a porcentagem de durações da bateria em que o uso diário de rede em segundo plano foi maior que 50 MB.
- Número de sessões: número aproximado de sessões gravadas.
- 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o uso diário de rede em segundo plano foi maior do que o número exibido.
Corrigir um problema
Caso o app tenha um uso elevado de rede em segundo plano, veja as soluções recomendadas no site para desenvolvedores Android.
Permissões
Na página Permissões negadas, você pode conferir detalhes sobre a porcentagem de sessões de permissão diárias em que os usuários negaram permissões. Uma sessão de permissão diária é um dia em que o app solicitou pelo menos uma permissão do usuário.
Detalhes da coleta de dados
Os dados sobre permissões negadas são coletados quando os usuários respondem a solicitações de permissões no seu app.
Detalhes importantes
- Negações: porcentagem de sessões diárias de permissão em que os usuários negaram permissões.
- Não perguntar novamente: é a porcentagem de sessões de permissão diárias em que as permissões foram negadas pelos usuários ao selecionarem a opção "Não perguntar novamente".
- Total de sessões: é o número aproximado de sessões registradas.
Corrigir um problema
Se o app tiver um número elevado de permissões negadas, veja as soluções recomendadas no site para desenvolvedores Android.
O Google Play definiu limites de mau comportamento nas Principais métricas do app.
Caso seu app ultrapasse um limite de mau comportamento, ele provavelmente vai ser menos encontrado no Google Play. Se o app tiver um mau comportamento em modelos de dispositivos específicos, o Google Play não vai direcionar os usuários desses dispositivos para esses títulos, e sim para outros mais adequados. Em alguns casos, um aviso é exibido na página "Detalhes do app" para definir as expectativas dos usuários e oferecer uma opção para procurar alternativas com maior qualidade técnica.
Em geral, o Google Play considera os últimos 28 dias de dados ao avaliar a qualidade do app, mas pode agir mais rapidamente em caso de pico.
Fechar tudo Abrir tudo
Estabilidade
O Google Play definiu limites de mau comportamento na taxa de ANR percebido pelo usuário:
-
Mau comportamento geral: pelo menos 0,47% dos usuários ativos por dia percebem um ANR em todos os modelos de dispositivos.
-
Mau comportamento por dispositivo: pelo menos 8% dos usuários ativos por dia percebem um ANR em um único modelo de dispositivo.
Para melhorar a taxa de ANR, corrija os clusters de ANR indicados na página Falhas e ANRs. Quanto maior o número de usuários afetados, maior é a contribuição do cluster à taxa de ANR.
Se aspectos específicos do hardware ou software do dispositivo contribuírem para a taxa de ANR, o Android vitals vai avisar você. Você também pode ver associações por conta própria na página de visão geral da ferramenta Alcance e dispositivos (Monitorar e melhorar > Alcance e dispositivos >Visão geral).
O Google Play definiu limites de mau comportamento na taxa de falhas percebidas pelo usuário:
-
Mau comportamento geral: pelo menos 1,09% dos usuários ativos por dia percebem uma falha em todos os modelos de dispositivos.
-
Mau comportamento por dispositivo: pelo menos 8% dos usuários ativos por dia percebem uma falha em um único modelo de dispositivo.
Para melhorar a taxa de falhas, corrija os clusters de falhas subjacentes indicadas na página Falhas e ANRs. Quanto maior o número de usuários afetados, maior é a contribuição do cluster à taxa de falhas.
Se aspectos específicos do hardware ou software do dispositivo contribuírem para a taxa de falhas, o Android vitals vai avisar você. Você também pode ver associações por conta própria na página de visão geral da ferramenta Alcance e dispositivos (Monitorar e melhorar > Alcance e dispositivos > Visão geral).
Conteúdo relacionado
Veja as práticas recomendadas e use o Android vitals para melhorar o desempenho e a estabilidade do seu app.