Novas estatísticas sobre problemas e recomendações de qualidade das apps
Por agora, são apresentados problemas de compatibilidade e comportamentos incorretos de apps, e algumas recomendações de experiência do utilizador. Vamos continuar a detetar e apresentar mais problemas de qualidade, e a fazer mais recomendações no próximo ano.
Use o Android vitals para ajudar a compreender e melhorar a estabilidade, o desempenho e a utilização da bateria da sua app, entre outros aspetos.
Escolha como aceder aos dados da app
Existem duas formas de usar o Android vitals: através da Play Console e da API Play Developer Reporting.
A API oferece acesso programático ao Android vitals para programadores que querem integrar dados do Android vitals com outros conjuntos de dados ou incorporá-los nos respetivos fluxos de trabalho. Para saber mais sobre como usar uma API para aceder ao Android vitals, aceda à página da API Google Play Developer Reporting.
Para procurar e rever os dados do Android vitals da app na Play Console:
- Abra a Play Console e aceda à página Vista geral do Android vitals (Qualidade > Android vitals > Vista geral).
- Escolha o intervalo de dados que quer ver através do seletor do intervalo de datas na parte superior direita.
Importante: se não estiverem disponíveis quaisquer dados, a sua app não tem pontos de dados suficientes nos filtros especificados para identificar eventuais problemas.
Monitorize as métricas essenciais do Android vitals da sua app
Na parte superior da página Vista geral do Android vitals, pode ver dados sobre as métricas essenciais do Android vitals da sua app. Estas são as métricas técnicas mais importantes e afetam a visibilidade da sua app no Google Play. As métricas essenciais do Android vitals incluem:
- Taxa de ANRs (A aplicação não está a responder) observados pelo utilizador
- Taxa de falhas observadas pelo utilizador
O Google Play define limites de comportamento incorreto nestas métricas. Se a sua app exceder estes limites, é provável que se torne menos visível no Google Play. Em alguns casos, pode ser apresentado um aviso na Ficha da loja da sua app para definir as expetativas dos utilizadores.
Pode usar a secção "Problemas críticos" para identificar rapidamente as áreas em que a app pode melhorar. Existem dois tipos de problemas críticos:
- Comportamentos incorretos: métricas que excedem os limites de comportamento incorreto.
- Anomalias: alterações significativas nos dados (por exemplo, um aumento acentuado na taxa de ANRs observados pelo utilizador)
Para receber notificações por email, visite Configuração > Notificações ou clique em Gerir notificações no canto da secção "Métricas essenciais do Android vitals" (Qualidade > Android vitals > Vista geral). Tenha em atenção que, atualmente, as notificações estão disponíveis apenas para anomalias.
Explore todas as métricas do Android vitalsJunto ao centro da página Vista geral do Android vitals, pode ver dados sobre todas as métricas do Android vitals por aspeto da qualidade.
Na tabela, pode rever as métricas dos períodos atuais e anteriores. Também pode ver uma comparação entre a sua app e outras apps no Google Play.
Para obter detalhes adicionais acerca de uma métrica, selecione Ver detalhes () junto à mesma. No ecrã seguinte, pode analisar:
- Os limites de comportamento incorreto
- As referências da categoria
- As comparações de referências detalhadas
- Junto à parte superior da página, no cartão de comparação de pares, selecione Editar grupo de pares para editar um grupo de pares personalizado. Depois de criar um grupo de pares personalizado, pode ver uma comparação entre a sua app e outras apps selecionadas no Google Play.
- Tendência de métricas ao longo do tempo
Para ajudar a organizar, segmentar e analisar os seus dados, as métricas são discriminadas por várias dimensões diferentes. Todas as métricas têm as seguintes discriminações:
- Artefacto: a versão da app na qual o problema ocorreu
- Versão do Android (SDK): a versão do SO Android comunicada pelo dispositivo do utilizador
- Formato: o tipo de dispositivo no qual a app foi executada (por exemplo, telemóvel, tablet, TV ou wearable)
- Modelo do dispositivo: uma descrição de nível superior do dispositivo, composta por um identificador de dispositivo e marca único, por exemplo, "Google oriole". Um único modelo de dispositivo pode ter variantes com diferentes versões do Android, RAM, armazenamento ou sistema no chip (SoC).
- País/região: a localização comunicada pelo dispositivo do utilizador no momento do problema
Sugestão: para análises detalhadas por aspetos específicos do hardware ou software do dispositivo (por exemplo, modelo do dispositivo ou versão do Android), pode clicar no símbolo () junto ao item na tabela.
Algumas métricas têm discriminações adicionais:
- Nome do wake lock: as etiquetas que foram programaticamente definidas durante a utilização da API PowerManager na sua app
- Nome de ativação: as etiquetas que foram programaticamente definidas durante a utilização da API AlarmManager na sua 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: quando ocorreu o ANR (por exemplo, durante a execução de um serviço) (se disponível)
Para ver mais detalhes quando estiverem disponíveis (por exemplo, os clusters de falhas de sistema ou ANRs [A aplicação não está a responder] associados a essa discriminação), selecione Ver detalhes () junto ao item.
Sugestão: pode alternar entre métricas numa única categoria usando o botão na parte superior do ecrã e filtrar a página.
Tipos de dados e métricas
Os dados do Android vitals estão disponíveis para os 90 dias anteriores na Play Console e três anos na API Google Play Developer Reporting.
Os dados são recolhidos de utilizadores que optaram por partilhar automaticamente os dados de utilização e diagnósticos a partir de um subconjunto de dispositivos Android e versões do SO. Para mais informações sobre como os utilizadores do Android optam por partilhar dados, aceda ao Centro de Ajuda de Contas.
O Android vitals é atualizado diariamente. Por vezes, os dados de dispositivos com o Android 10 ou superior são enviados mais cedo do que os dados de dispositivos com uma versão inferior ao Android 10. Se isto acontecer, serão apresentados os dados do Android 10 ou superior disponíveis para os dias em que apenas estes estão disponíveis.
Nota: as métricas do Android vitals excluem problemas técnicos que ocorrem em modelos de dispositivos não certificados ou versões da app que não foram instaladas através do Google Play.
Estabilidade
Métricas da taxa de ANRsAs métricas da taxa de ANRs oferecem uma vista geral da qualidade da sua app. Estas métricas são calculadas ao considerar o número de utilizadores com ANRs e normalizá-los com base na utilização da app. São comunicadas como uma percentagem de utilizadores ativos diariamente, em que um utilizador ativo diariamente é definido como um utilizador que usa a app num único dia, num único dispositivo. Se um utilizador usar a sua app em mais do que um dispositivo num único dia, cada dispositivo contribui para o número de utilizadores ativos nesse dia. Se vários utilizadores usarem o mesmo dispositivo num único dia, tal é contabilizado como um utilizador ativo.
Existem três métricas da taxa de ANRs:
- Taxa de ANRs observados pelo utilizador: a percentagem de utilizadores ativos diariamente que foram afetados por, pelo menos, um ANR observado pelo utilizador. Um ANR observado pelo utilizador é um ANR que provavelmente foi detetado por este. Atualmente, apenas são contabilizados os ANRs do tipo "O envio de entrada excedeu o tempo limite". Esta métrica é sempre inferior à sua taxa de ANRs geral, porque é normalizada pela utilização diária, mas não contabiliza todos os ANRs.
A taxa de ANRs observados pelo utilizador é uma métrica essencial do Android vitals, o que significa que afeta a visibilidade da sua app no Google Play. É importante porque os ANRs contabilizados ocorrem sempre quando o utilizador interage com a app e são os que provocam grande parte das interrupções.
- Taxa de ANRs: a percentagem dos seus utilizadores diários que foram afetados por, pelo menos, um ANR. Esta métrica inclui ANRs que não são classificados como observados pelo utilizador, mas não podemos garantir que estes ANRs não estejam a afetar os utilizadores.
- Taxa de vários ANRs: a percentagem dos seus utilizadores diários que foram afetados por, pelo menos, 2 ANRs. Esta métrica ajuda a realçar ciclos de problemas.
Corrija um problema
Os ANRs que contribuem para as suas métricas da taxa de ANRs são comunicados na página Falhas de sistema e ANRs. Pode filtrar por ANRs observados pelo utilizador nesta página.
O site para programadores Android disponibiliza orientações para diagnosticar e corrigir ANRs.
As métricas da taxa de falhas oferecem uma vista geral da qualidade da sua app. Estas métricas são calculadas ao considerar o número de utilizadores com falhas de sistema e normalizá-los com base na utilização da app. São comunicadas como uma percentagem de utilizadores diários, em que um utilizador diário é definido como um utilizador que usa a app num único dia, num único dispositivo. Se um utilizador tiver mais do que um dispositivo, será contabilizado mais do que uma vez. Por exemplo, se dois utilizadores usarem a app durante dois dias num dispositivo cada, tal vai produzir quatro sessões diárias.
Existem três métricas da taxa de falhas:
- Taxa de falhas observadas pelo utilizador: a percentagem de utilizadores diários que foram afetados por, pelo menos, uma falha de sistema observada pelo utilizador. Uma falha observada pelo utilizador é uma falha de sistema que provavelmente foi detetada pelo utilizador. Por exemplo, falhas de sistema que ocorrem quando a sua app está a apresentar uma atividade ou em execução como um serviço em primeiro plano. Esta métrica é sempre inferior à sua taxa de falhas geral, porque é normalizada pela utilização diária, mas não contabiliza todas as falhas de sistema.
A taxa de falhas observadas pelo utilizador é uma métrica essencial do Android vitals, o que significa que afeta a visibilidade da sua app no Google Play. É importante porque as falhas de sistema contabilizadas ocorrem sempre quando o utilizador interage com a app e são as que provocam grande parte das interrupções. Por este motivo, deve garantir que a sua app não excede o limite de comportamento incorreto para esta métrica.
-
Taxa de falhas: a percentagem dos utilizadores diários que foram afetados por, pelo menos, uma falha de sistema. Esta métrica inclui falhas de sistema que não são classificados como observadas pelo utilizador, mas não podemos garantir que estas falhas de sistema não estejam a afetar os utilizadores.
-
Taxa de várias falhas: a percentagem dos utilizadores diários que foram afetados por, pelo menos, 2 falhas de sistema. Esta métrica ajuda a realçar ciclos de problemas.
Corrija um problema
O site para programadores Android disponibiliza orientações para diagnosticar e corrigir falhas de sistema.
Arranque e tempos de carregamento
Tempo de arranque (tempo até à apresentação inicial)Na página Tempo de início da app, pode ver os detalhes sobre quando a app é iniciada lentamente a partir dos estados do sistema frio, quente e frequente. O tempo de início mede o tempo necessário desde que um utilizador inicia a app até os primeiros frames serem apresentados no ecrã. Isto também é conhecido como "tempo até à apresentação inicial".
A sua app pode não estar pronta para o utilizador começar a interagir com a mesma após este tempo, por exemplo, se a sua app tiver ecrãs de carregamento adicionais.
Detalhes da recolha de dados
- Os tempos de arranque são registados apenas quando um utilizador aciona uma atividade.
- Exemplo: para apps de teclado, o tempo de arranque é igual ao tempo de arranque da app associada.
- Se uma app for iniciada várias vezes no mesmo dia a partir do mesmo estado do sistema, é registado o tempo máximo de arranque do dia.
- Os tempos de arranque são monitorizados quando o primeiro frame da app é carregado completamente, mesmo que não seja um ecrã com o qual os utilizadores interagem.
- Exemplo: se uma app for iniciada com um ecrã inicial, o tempo de arranque é igual ao tempo necessário para apresentar o ecrã inicial.
Detalhes essenciais
- Sessões afetadas: a percentagem de sessões durante as quais os utilizadores foram afetados por um tempo de arranque lento para cada estado do sistema respetivo:
- Início a frio lento: 5 segundos ou mais
- Início a quente lento: 2 segundos ou mais
- Início frequente lento: 1 segundo ou mais
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 10%/1% das sessões diárias em que os utilizadores foram afetados por um tempo de arranque lento para a sua app.
Corrija um problema
Se a sua app tiver um número elevado de tempos de início de apps lentos, aceda ao site para programadores Android para ver as soluções recomendadas.
Renderização
Todas as renderizações
Taxa de sessões lentas (30 FPS ou 20 FPS) [apenas para jogos]Por que motivo isto é importante
A utilização de sessões lentas permite-lhe compreender o desempenho da velocidade de frames do seu jogo, o que afeta a suavidade e a fluidez do jogo.
Compreenda os dados da app
Na página Sessões lentas, são apresentados detalhes sobre a percentagem de sessões diárias em que os utilizadores foram afetados por mais de 25% de frames mais lentos do que 30 FPS ou 20 FPS, consoante a referência selecionada. Também pode ver a distribuição de sessões pela velocidade de frames para o seu jogo. (A velocidade de frames ao nível da sessão é medida no percentil 75, o que significa que 75% dos frames alcançam, pelo menos, esta velocidade de frames.)
A maioria dos jogos no Google Play deve procurar atingir 30 FPS ou mais. Isto oferece uma experiência razoável aos utilizadores, independentemente do tipo de jogo que estejam a jogar (apesar de alguns utilizadores preferirem, pelo menos, 60 FPS, especialmente em dispositivos topo de gama). Monitorize a métrica da taxa de sessões lentas (30 FPS) para garantir que está a atingir este objetivo. Tenha em atenção que esta métrica inclui apenas sessões em que mais de 25% dos frames não têm 30 FPS, por isso, tem alguma tolerância à variabilidade da velocidade de frames.
Embora a velocidade de 30 FPS ofereça uma experiência razoável, pode haver alturas ou tipos de jogos em que faça sentido reduzir esta velocidade de frames abaixo deste valor ou os utilizadores queiram jogar o seu jogo em telemóveis que não suportem 30 FPS. Nestas circunstâncias, pelo menos 75% dos frames numa sessão ainda devem alcançar 20 FPS ou mais. Monitorize a métrica da taxa de sessões lentas (20 FPS) para garantir que está a atingir este objetivo.
O Android vitals comunica sessões lentas (30 FPS) e sessões lentas (20 FPS) para cada dispositivo, bem como em todos os dispositivos e sessões. Use a métrica geral para compreender a experiência geral do utilizador, mas também preste atenção ao desempenho por dispositivo. Atempadamente, o Google Play vai começar a afastar os utilizadores dos jogos que não conseguem alcançar 20 FPS nos telemóveis.
O Android vitals só começa a monitorizar a velocidade de frames após o jogo ser executado durante 1 minuto.
Detalhes da recolha de dados
A métrica de sessões lentas é calculada com dados recolhidos pelo SurfaceFlinger. Mais concretamente, a velocidade de frames de uma sessão é estimada com base no tempo entre frames apresentados em superfícies pertencentes à app e inclui frames renderizados pelo OpenGL, Vulkan e toolkit de IU do Android. Atualmente, esta métrica só está disponível para jogos.
Os dados da velocidade de frames para sessões lentas são recolhidos para dispositivos com o Android 9 e posterior.
Visualização no painel de controlo
- Velocidade de frames representativa: o desempenho da velocidade de frames do jogo em dispositivos com o Android 9 ou posterior, calculado no percentil 75. Isto significa que 75% das sessões tiveram uma velocidade de frames igual ou superior a esta 75% das vezes.
- Taxa de sessões lentas ao longo do tempo: um intervalo temporal que mostra a percentagem de sessões determinadas como sendo sessões lentas.
- Distribuição da velocidade de frames: um histograma que mostra a velocidade de frames do percentil 75 nas sessões. Isto significa que 75% dos frames numa sessão foram mais rápidos do que a velocidade de frames usada para agrupar a sessão.
Corrija um problema
Se a sua app tiver um número elevado de sessões lentas, aceda ao site para programadores Android para ver as soluções recomendadas.
Renderização do toolkit de IU do Android
Demasiados frames lentos [apenas para apps]Compreenda os dados da app
Na página Demasiados frames lentos, são apresentados detalhes acerca da percentagem de sessões diárias em que os utilizadores foram afetados por mais de 50% de frames fora do prazo de desenho do dispositivo. As interações dos utilizadores com a sua app devem ter uma taxa de 60 frames por segundo sem frames atrasados ou removidos.
Detalhes da recolha de dados
A Google recolhe o tempo de renderização de cada frame apresentado pela app quando é utilizado o framework do Toolkit de IU. Os frames renderizados através do OpenGL ou Vulkan não são recolhidos.
Visualização no painel de controlo
Quando seleciona uma linha, os dados são divididos em percentis.
- Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetados por mais de 50% de frames com um tempo de renderização superior a 16 ms. Uma sessão diária refere-se a um dia em que a sua app foi usada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 90%/99% do total de frames tiveram um tempo de renderização inferior ao número indicado. Estes números são baseados em todos os frames recolhidos.
Quando clica numa entrada na tabela, é apresentado o gráfico "Distribuição do tempo de renderização da IU". Quando analisar o gráfico, recomendamos que se certifique de que a maioria dos frames da app é igual ou inferior a 16 ms.
Os dados abaixo do gráfico indicam o desempenho de renderização da app e podem ser úteis para encontrar a causa essencial de quaisquer problemas relacionados com o tempo de renderização. Por exemplo, se a percentagem de "Latência de entrada elevada" for elevada, poderá ser útil analisar o código da app que processa a introdução do utilizador. Para mais informações acerca destas métricas, aceda ao artigo 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 pelo número de frames.
- Latência de entrada elevada: para todos os frames renderizados em mais de 16 ms, o número de eventos de entrada que demoraram mais de 24 ms dividido pelo número de frames.
- Thread da IU lenta: para todos os frames renderizados em mais de 16 ms, o número de vezes em que a thread da IU demorou mais de 8 ms a ser concluída dividido pelo número de frames.
- Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, o número de vezes em que o envio de comandos de desenho para a GPU demorou mais de 12 ms dividido pelo número de frames.
- Carregamentos lentos de mapas de bits: para todos os frames renderizados em mais de 16 ms, o número de vezes em que o mapa de bits demorou mais de 3,2 ms a ser carregado para a GPU dividido pelo número de frames.
Corrija um problema
Se a sua app tiver um número elevado de frames com um tempo de renderização superior a 16 ms, aceda ao site para programadores Android para ver as soluções recomendadas.
Compreenda os dados da app
Na página Demasiados frames lentos, são apresentados detalhes acerca da percentagem de sessões diárias em que os utilizadores foram afetados por mais de 50% de frames fora do prazo de desenho do dispositivo. As interações dos utilizadores com a sua app devem ter uma taxa de 60 frames por segundo sem frames atrasados ou removidos.
Detalhes da recolha de dados
A Google recolhe o tempo de renderização de cada frame apresentado pela app quando é utilizado o framework do Toolkit de IU. Os frames renderizados através do OpenGL ou Vulkan não são recolhidos.
Visualização no painel de controlo
Quando seleciona uma linha, os dados são divididos em percentis.
- Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetados por mais de 50% de frames com um tempo de renderização superior a 16 ms. Uma sessão diária refere-se a um dia em que a sua app foi usada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 90%/99% do total de frames tiveram um tempo de renderização inferior ao número indicado. Estes números são baseados em todos os frames recolhidos.
Quando clica numa entrada na tabela, é apresentado o gráfico "Distribuição do tempo de renderização da IU". Quando analisar o gráfico, recomendamos que se certifique de que a maioria dos frames da app é igual ou inferior a 16 ms.
Os dados abaixo do gráfico indicam o desempenho de renderização da app e podem ser úteis para encontrar a causa essencial de quaisquer problemas relacionados com o tempo de renderização. Por exemplo, se a percentagem de "Latência de entrada elevada" for elevada, poderá ser útil analisar o código da app que processa a introdução do utilizador. Para mais informações acerca destas métricas, aceda ao artigo 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 pelo número de frames.
- Latência de entrada elevada: para todos os frames renderizados em mais de 16 ms, o número de eventos de entrada que demoraram mais de 24 ms dividido pelo número de frames.
- Thread da IU lenta: para todos os frames renderizados em mais de 16 ms, o número de vezes em que a thread da IU demorou mais de 8 ms a ser concluída dividido pelo número de frames.
- Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, o número de vezes em que o envio de comandos de desenho para a GPU demorou mais de 12 ms dividido pelo número de frames.
- Carregamentos lentos de mapas de bits: para todos os frames renderizados em mais de 16 ms, o número de vezes em que o mapa de bits demorou mais de 3,2 ms a ser carregado para a GPU dividido pelo número de frames.
Corrija um problema
Se a sua app tiver um número elevado de frames com um tempo de renderização superior a 16 ms, aceda ao site para programadores Android para ver as soluções recomendadas.
Utilização da bateria
Wake locks bloqueados e wake locks parciais bloqueados (em segundo plano)As páginas Wake locks parciais bloqueados e Wake locks parciais bloqueados (em segundo plano) mostram wake locks parciais adquiridos pela sua app através da classe PowerManager. Um wake lock parcial garante que a CPU está em execução, mas que o ecrã e a retroiluminação do teclado podem ser desligados.
Detalhes da recolha de dados
- Por motivos de privacidade, as etiquetas de identificação do wake lock parcial são tornadas anónimas.
- Os dados acerca dos wake locks parciais são recolhidos quando o dispositivo não está a ser carregado e o ecrã está desligado.
- Os dados dos wake locks parciais bloqueados (em segundo plano) apenas são recolhidos quando a app está a ser executada em segundo plano.
- A Google calcula a duração máxima do wake lock parcial por sessão de bateria para mostrar quantas sessões são afetadas por um wake lock prolongado. Por exemplo, se um utilizador acionar dois wake locks de duas horas, a Google usa um valor máximo de wake lock de uma hora.
- Para as apps que definem o
sharedUserIdno ficheiro de manifesto: os dados apenas são apresentados se estiver instalada, no máximo, uma app com o mesmosharedUserId.
Detalhes essenciais
- Sessões afetadas: percentagem de sessões de bateria em que os utilizadores se depararam com, pelo menos, um wake lock de mais de uma hora.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 10%/1% das sessões diárias em que os utilizadores foram afetados por wake locks parciais com durações superiores ao número indicado.
- Limite de comportamento incorreto: se a app apresentar uma taxa de ocorrência igual ou superior ao limiar apresentado, encontra-se nos últimos 25% das 1000 apps mais populares no Google Play (pelo número de instalações).
Corrija um problema
Se a sua app tiver um número elevado de wake locks parciais bloqueados, aceda ao site para programadores Android para ver as soluções recomendadas.
A página Ativações excessivas mostra as ativações do Alarm Manager acionadas pela sua app. São apresentados dados de ativação para as classes ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.
Detalhes da recolha de dados
- Por motivos de privacidade, as etiquetas de identificação de ativação são tornadas anónimas.
- As ativações são recolhidas quando o dispositivo não está a ser carregado.
- Para fornecer uma métrica normalizada, o número de ativações é comparado com o tempo durante o qual o dispositivo está a utilizar a bateria. A Google calcula o número de ativações por utilizador por hora para mostrar quantos utilizadores são afetados por uma taxa de ativação elevada.
- Para as apps que definem o
sharedUserIdno ficheiro de manifesto: os dados apenas são apresentados se estiver instalada, no máximo, uma app com o mesmosharedUserId.
Detalhes essenciais
- Sessões afetadas: percentagem de sessões de bateria em que os utilizadores foram afetados por mais de 10 ativações por hora. Uma sessão de bateria é a agregação de todos os relatórios de bateria recebidos num determinado período de 24 horas. No Android 10, um relatório de bateria refere-se ao intervalo entre dois carregamentos da bateria, seja de um valor inferior a 20% até mais de 80% ou de qualquer valor até 100%. No Android 11 e superior, um relatório de bateria refere-se a um período fixo de 24 horas. A Google só recolhe os dados quando o dispositivo não está ligado ao carregador.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 10%/1% das sessões diárias em que os utilizadores foram afetados por um número de ativações por hora superior ao valor indicado.
- Limite de comportamento incorreto: se a app apresentar uma taxa de ocorrência igual ou superior ao limiar apresentado, encontra-se nos últimos 25% das 1000 apps mais populares no Google Play (pelo número de instalações).
Corrija um problema
Se a sua app tiver ativações frequentes, aceda ao site para programadores Android para ver as soluções recomendadas.
A página Procuras de redes Wi-Fi em excesso (em segundo plano) mostra quando as procuras de redes Wi-Fi estão a resultar numa elevada utilização da bateria.
Detalhes da recolha de dados
Os dados acerca da procura de redes Wi-Fi são recolhidos quando o dispositivo não está a ser carregado e a app está em segundo plano.
Detalhes essenciais
- Sessões afetadas: percentagem de sessões de bateria em que os utilizadores foram afetados por mais de 4 procuras de Wi-Fi por hora.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 10%/1% das sessões diárias em que os utilizadores foram afetados por mais procuras de Wi-Fi em segundo plano por hora do que o número indicado.
Corrija um problema
Se a sua app tiver um número elevado de procuras de Wi-Fi em segundo plano, aceda ao site para programadores Android para obter soluções recomendadas.
A página Utilização da rede excessiva mostra quando uma grande quantidade de dados da rede está associada a um serviço em segundo plano. Quando a utilização da rede móvel ocorre em segundo plano, os utilizadores não têm um acesso fácil aos controlos para impedir a transferência de dados.
Detalhes da recolha de dados
Os dados acerca da utilização da rede móvel são recolhidos quando o dispositivo não está a ser carregado e a app está em segundo plano.
Detalhes essenciais
- Sessões afetadas: percentagem de sessões de bateria em que os utilizadores foram afetados por uma utilização da rede superior a 50 MB em segundo plano por dia.
- Número de sessões: número aproximado de sessões registadas.
- Percentil 90-99: 10%/1% das sessões diárias em que os utilizadores foram afetados por uma utilização da rede diária em segundo plano superior ao número indicado.
Corrija um problema
Se a sua app tiver uma utilização da rede em segundo plano elevada, aceda ao site para programadores Android para obter soluções recomendadas.
Autorizações
Autorizações recusadasNa página Autorizações recusadas, pode ver os detalhes sobre a percentagem de sessões de autorizações diárias durante as quais os utilizadores recusaram autorizações. Uma sessão de autorizações diária refere-se a um dia no qual a sua app pede, pelo menos, uma autorização ao utilizador.
Detalhes da recolha de dados
Os dados sobre autorizações recusadas são recolhidos quando os utilizadores respondem a pedidos de autorizações na sua app.
Detalhes essenciais
- Recusadas: a percentagem de sessões de autorizações diárias durante as quais os utilizadores recusaram autorizações.
- Não pedir novamente: a percentagem de sessões de autorizações diárias durante as quais os utilizadores recusaram autorizações selecionando a opção Não pedir novamente.
- Total de sessões: número aproximado de sessões registadas.
Corrija um problema
Se a sua app tiver um número elevado de autorizações recusadas, aceda ao site para programadores Android para ver as soluções recomendadas.
Limites de comportamento incorreto para as métricas essenciais do Android vitals
O Google Play definiu limites de comportamento incorretos nas métricas essenciais do Android vitals da sua app.
Se a sua app exceder um limite de comportamento incorreto, é provável que se torne menos visível no Google Play. Se a sua app tiver um comportamento incorreto em modelos de dispositivos específicos, o Google Play vai desviar os utilizadores nesses dispositivos destes títulos e direcioná-los para outros que sejam mais adequados para eles. Em alguns casos, pode ser apresentado um aviso na Ficha da loja da sua app para definir as expetativas dos utilizadores e disponibilizar a opção de procurar alternativas com maior qualidade técnica.
Geralmente, o Google Play considera os últimos 28 dias de dados ao avaliar a qualidade da sua app, mas pode agir mais cedo caso ocorra um pico.
Estabilidade
Limites da taxa de ANRs observados pelo utilizadorO Google Play definiu limites de comportamento incorretos na taxa de ANRs observados pelo utilizador:
-
Comportamento incorreto geral: pelo menos 0,47% dos utilizadores ativos diariamente são afetados por um ANR observado pelo utilizador em todos os modelos de dispositivos.
-
Comportamento incorreto por dispositivo: pelo menos 8% dos utilizadores ativos diariamente são afetados por um ANR observado pelo utilizador num único modelo de dispositivo.
Para melhorar a sua taxa de ANRs, corrija os clusters de ANRs subjacentes comunicados na página Falhas de sistema e ANRs. Quanto mais elevado for o número de utilizadores afetados, mais esse cluster contribui para a sua taxa de ANRs.
Se determinados aspetos do hardware ou software do dispositivo puderem estar a contribuir para a sua taxa de ANRs, o Android vitals envia-lhe uma notificação. Também pode explorar associações na página Vista geral do Alcance e dispositivos (Lançamento > Alcance e dispositivos > Vista geral).
O Google Play definiu limites de comportamento incorretos na taxa de falhas observadas pelo utilizador:
-
Comportamento incorreto geral: pelo menos 1,09% dos utilizadores diários são afetados por uma falha observada pelo utilizador em todos os modelos de dispositivos.
-
Comportamento incorreto por dispositivo: pelo menos 8% dos utilizadores diários são afetados por uma falha observada pelo utilizador num único modelo de dispositivo.
Para melhorar a sua taxa de falhas, corrija os clusters de falhas subjacentes que são comunicados na página Falhas de sistema e ANRs. Quanto mais elevado for o número de utilizadores afetados, mais esse cluster contribui para a sua taxa de falhas.
Se determinados aspetos do hardware ou software do dispositivo puderem estar a contribuir para a sua taxa de falhas, o Android vitals envia-lhe uma notificação. Também pode explorar associações na página Vista geral do Alcance e dispositivos (Lançamento > Alcance e dispositivos > Vista geral).
Conteúdo relacionado
Descubra as práticas recomendadas para usar o Android vitals para melhorar o desempenho e a estabilidade da sua app.