Monitorize o desempenho técnico da sua app com o Android vitals

Para dar aos programadores visibilidade sobre o nível de suavidade e fluidez do jogo aos utilizadores, estamos a adicionar uma nova métrica do Android vitals denominada "Sessões lentas".

Esta página foi atualizada para refletir estas alterações.

Esta funcionalidade ainda não está disponível para todos os programadores.

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 analisar os dados do Android vitals da app na Play Console:

  1. Abra a Play Console.
  2. Selecione uma app.
  3. No menu do lado esquerdo, selecione Qualidade > Android vitals > Vista geral.
  4. 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 com a sua app.

Reveja o painel de controlo Vista geral e as páginas de métricas detalhadas

Métricas essenciais do Android vitals

Na parte superior da página Vista geral, pode ver dados sobre as métricas essenciais do Android vitals da sua app, que são métricas de desempenho que podem afetar a visibilidade e a classificação da app no Google Play. As métricas essenciais do Android vitals incluem:

  • Taxa de ANRs
  • Taxa de falhas
  • Wake locks parciais bloqueados (em segundo plano)
  • Ativações excessivas

Se a sua app tiver problemas críticos de desempenho que necessitem da sua atenção, incluindo métricas que excedem os limites de comportamento incorreto e alterações importantes nos dados de desempenho (conhecidas como anomalias), pode utilizar esta página para identificar rapidamente as áreas onde a app pode melhorar. Para receber notificações por email quando forem detetadas alterações significativas de ANRs, de clusters de falhas ou do Android vitals, 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).

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.

Importante: para obter a melhor experiência do utilizador, todas as apps devem identificar e corrigir problemas para se manterem abaixo dos limites de comportamento incorreto.

Procurar em todas as métricas do Android vitals

Junto ao centro da página Vista geral, pode ver dados sobre todas as métricas do Android vitals por tipo de dados. Para filtrar a tabela, escolha as dimensões e o período de tempo que pretende ver.

Para cada métrica, pode rever a percentagem de sessões da app que foram afetadas pelos períodos de tempo atual e anterior. Para ver o desempenho da sua app em comparação com outras apps no Google Play, também pode ver a diferença entre a mediana da sua app e a dos respetivos pares.

Veja métricas detalhadas

Para obter detalhes adicionais acerca de uma métrica, selecione Ver detalhes. No ecrã seguinte, pode rever:

  • As anomalias encontradas nos dados de desempenho.
  • 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.
  • Métricas por artefacto, dispositivo, versão do Android, referência ou intervalo de tempo.
    • Para ver mais detalhes, pode expandir cada linha nas tabelas ao selecionar a seta para baixo no lado direito.
Filtre por comportamentos incorretos

Na parte superior da página Vista geral, algumas métricas podem estar marcadas com um ícone de erro vermelho . Isto significa que o número mostrado é elevado quando comparado com outras apps, o que é considerado um comportamento incorreto.

Selecione Ver detalhes no cartão com o ícone para ver quais dos APKs da sua app apresentam o comportamento incorreto.

Tipos de dados e métricas

Os seguintes dados são recolhidos de utilizadores que optaram por partilhar automaticamente os dados de utilização e de diagnóstico a partir de um subconjunto de dispositivos Android e de 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.

Reduzir tudo  Expandir tudo

Estabilidade

Taxa de ANRs e taxa de vários ANRs

Compreenda os dados da app

Nas páginas Taxa de ANRs e Taxa de vários ANRs, verá dados semelhantes aos apresentados na página ANRs e falhas de sistema da sua app. Na página Android vitals, os dados de ANR são combinados com dados de utilização para criar uma métrica normalizada.

Detalhes da Taxa de ANRs

  • Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetados por, pelo menos, um ANR. Uma sessão diária refere-se a um dia em que a sua app foi utilizada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
  • Sessões sem ANR: percentagem de sessões diárias em que os utilizadores não foram afetados por nenhum ANR. Uma sessão diária refere-se a um dia em que a sua app foi utilizada.
  • Número de sessões: número aproximado de sessões registadas.
  • 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).

Detalhes da taxa de vários ANRs

  • Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetados por, pelo menos, dois ANRs. Uma sessão diária refere-se a um dia em que a sua app foi utilizada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
  • Sessões não afetadas: percentagem de sessões diárias em que os utilizadores se depararam com um ou nenhum ANR. Uma sessão diária refere-se a um dia em que a sua app foi utilizada.
  • Número de sessões: número aproximado de sessões registadas.

Corrija um problema

Se a sua app tiver um número elevado de ANRs, aceda ao site para programadores Android para consultar as soluções recomendadas.

Taxa de falhas e taxa de várias falhas

Compreenda os dados da app

Nas páginas Taxa de falhas e Taxa de várias falhas, verá dados semelhantes aos apresentados na página ANRs e falhas de sistema da sua app. Na página Android vitals, os dados de falhas de sistema são combinados com dados de utilização para criar uma métrica normalizada.

Detalhes da taxa de falhas

  • Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetadas por, pelo menos, uma falha de sistema. Uma sessão diária refere-se a um dia em que a sua app foi utilizada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
  • Sessões sem falhas de sistema: percentagem de sessões diárias em que os utilizadores não foram afetados por nenhuma falha de sistema. Uma sessão diária refere-se a um dia em que a sua app foi utilizada.
  • Número de sessões: número aproximado de sessões registadas.
  • 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).

Detalhes da taxa de várias falhas

  • Sessões afetadas: percentagem de sessões diárias em que os utilizadores foram afetadas por, pelo menos, duas falhas de sistema. Uma sessão diária refere-se a um dia em que a sua app foi utilizada. Por exemplo, se dois utilizadores utilizarem a app durante dois dias, são produzidas quatro sessões diárias.
  • Sessões não afetadas: percentagem de sessões diárias em que os utilizadores se depararam com uma ou nenhuma falha de sistema. Uma sessão diária refere-se a um dia em que a sua app foi utilizada.
  • Número de sessões: número aproximado de sessões registadas.

Corrija um problema

Se a sua app tiver um número elevado de falhas de sistema, aceda ao site para programadores Android para consultar as soluções recomendadas.

Tempos de arranque e 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

Taxa de sessões lentas

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. Também pode ver as estatísticas gerais da velocidade de frames para o seu jogo.

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.

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 12 e posterior.

Visualização no painel de controlo

  • Utilizadores no Android 12 e superior: mostra a fração da sua base de instalações no Android 12 ou superior para que compreenda que proporção dos seus utilizadores é abrangida pelas novas estatísticas da velocidade de frames. Nota: os dispositivos com o Android 12 ou superior são mais recentes e, normalmente, têm um melhor desempenho.
  • Velocidade de frames representativa: o desempenho da velocidade de frames do jogo em dispositivos com o Android 12 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.

Demasiados frames lentos

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 quaisquer 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 utilizada. 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.

Demasiados frames bloqueados

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 quaisquer 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 utilizada. 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 utiliza um valor máximo de wake lock de uma hora.
  • Para as apps que definem o sharedUserId no ficheiro de manifesto: os dados apenas são apresentados se estiver instalada, no máximo, uma app com o mesmo sharedUserId.

Detalhes essenciais

  • Sessões afetadas: percentagem de sessões de bateria em que os utilizadores foram afetados por, 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.

Ativações excessivas

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 sharedUserId no ficheiro de manifesto: os dados apenas são apresentados se estiver instalada, no máximo, uma app com o mesmo sharedUserId.

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 recolhe os dados apenas 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.

Procuras de redes Wi-Fi em excesso (em segundo plano)

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. 

Utilização da rede excessiva (em segundo plano)

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 recusadas

Na 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 solicitou, 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 ao selecionarem 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.

Analise os dados com dimensões

Para ajudar a organizar, segmentar e analisar os seus dados, todos os dados da app são divididos com base nas dimensões seguintes.

  • 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
  • Tipo de dispositivo: o tipo de dispositivo no qual a app foi executada (por exemplo, telemóvel, tablet, TV, dispositivo de vestir)
  • 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 SoC
  • País/região: a localização comunicada pelo dispositivo do utilizador no momento do problema
  • 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

Conteúdo relacionado

Descubra as práticas recomendadas para usar o Android vitals para melhorar o desempenho e a estabilidade da sua app.

 

A informação foi útil?
Como podemos melhorá-la?

Precisa de mais ajuda?

Inicie sessão para obter opções de apoio técnico adicionais e resolver rapidamente o seu problema.

Pesquisa
Limpar pesquisa
Fechar pesquisa
Google Apps
Menu principal
Pesquisar no Centro de ajuda
true
92637
false
false