Solução de problemas e perguntas frequentes sobre a Developer Device Platform

Visualizar

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção "Termos Gerais de Serviço" dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, você vai encontrar ajuda para a solução de problemas e respostas a perguntas frequentes sobre a execução de testes com a Developer Device Platform. Se você não encontrar o que procura ou precisar de ajuda, entre em contato com nossa equipe.

Solução de problemas

Quais recursos você tem para migrar do Firebase Test Lab para a Developer Device Platform?

Se você estiver migrando do Firebase Test Lab para a Developer Device Platform, consulte nosso guia de migração, tradução de comandos e flags, e habilidade de migração para agentes de IA.

Por que meu teste está demorando tanto para ser executado?

Quando você seleciona um dispositivo com um nível alto de capacidade no catálogo da Developer Device Platform, os testes podem começar mais rapidamente. Quando um dispositivo tem baixa capacidade, os testes podem levar mais tempo para serem executados. Se o número de testes invocados for muito maior do que a capacidade dos dispositivos selecionados, os testes poderão levar mais tempo para serem concluídos.

Os testes executados em qualquer nível de capacidade do dispositivo podem demorar mais por causa dos fatores a seguir:

• Tráfego, que afeta a disponibilidade do dispositivo e a velocidade de teste.
• Falhas no dispositivo ou na infraestrutura, que podem acontecer a qualquer momento. Para verificar se há uma infraestrutura relatada para a Developer Device Platform, consulte o painel do Google Cloud Personalized Service Health.

Para saber mais sobre a capacidade do dispositivo na Developer Device Platform, consulte o Catálogo de dispositivos.

Por que os resultados do teste foram inconclusivos?

Os resultados inconclusivos geralmente acontecem devido a erros de infraestrutura ou testes cancelados. Além de PASSED e FAILED, a Developer Device Platform pode retornar ERROR, TIMED_OUT e CANCELLED.

Os erros de infraestrutura são causados por problemas internos da Developer Device Platform, como erros de rede ou comportamentos inesperados em dispositivos. A Developer Device Platform tenta novamente os testes que produzem erros de infraestrutura várias vezes antes de informar um resultado inconclusivo.

Para determinar a causa do erro, faça o seguinte:

1. Procure por falhas conhecidas no painel Integridade do serviço do Google Cloud.

2. Repita o teste na Developer Device Platform para verificar se é possível reproduzir.

   Observação: a Developer Device Platform não cobra por erros de infraestrutura.

3. Faça o teste em outro tipo de dispositivo, se aplicável. Consulte o Catálogo de dispositivos para mais informações.

Por que a fragmentação deixou meus testes mais demorados?

A fragmentação pode fazer com que os testes sejam executados por mais tempo quando o número de fragmentos especificado exceder o número de dispositivos disponíveis para uso na Developer Device Platform. Para evitar essa situação, limite a contagem de dispositivos à contagem de fragmentos. Para mais informações sobre como escolher um dispositivo diferente, consulte o Catálogo de dispositivos.

Por que está demorando muito para o início do meu teste?

Quando solicitação de teste é enviada, o app é validado, assinado novamente etc. para se preparar para executar testes em um dispositivo. Normalmente, esse processo é concluído em menos de alguns segundos, mas pode ser afetado por fatores como o tamanho do app.

Depois que o app estiver preparado, as execuções de teste serão programadas e vão permanecer em uma fila até que um dispositivo esteja pronto para a execução.

Observação: o tempo que o teste passa aguardando um dispositivo disponível não é contabilizado no tempo de faturamento.

Por que meu teste está demorando muito?

Após a conclusão da execução do teste, os artefatos de teste são transferidos por download do dispositivo, processados e enviados para o Cloud Storage. A duração dessa etapa pode ser afetada pela quantidade e pelo tamanho dos artefatos.

Por que sessions.batchGet retorna um erro HTML 400 Bad Request?

Ao chamar o método REST sessions.batchGet com muitos nomes de sessão, você pode receber uma resposta 400 Bad Request como uma página HTML, em vez de um erro JSON, com a mensagem "Seu cliente emitiu uma solicitação malformada ou ilegal".

Esse erro significa que o URL da solicitação é muito longo. Em uma solicitação GET, cada nome de sessão é enviado como um parâmetro de consulta names, e os limites da API Google Cloud limitam os URLs de solicitação a cerca de 16 kB, o que equivale a aproximadamente 150 nomes de sessão. A solicitação é rejeitada antes de chegar ao Device Run.

Para recuperar até 500 sessões em uma chamada, envie uma solicitação POST para o mesmo URL com o cabeçalho X-HTTP-Method-Override: GET e transmita os nomes das sessões no corpo da solicitação:

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: PROJECT_ID" \
  -H "X-HTTP-Method-Override: GET" \
  -H "Content-Type: application/json" \
  -d '{"names": ["projects/PROJECT_ID/locations/LOCATION/sessions/SESSION_ID_1",
                 "projects/PROJECT_ID/locations/LOCATION/sessions/SESSION_ID_2"]}' \
  "https://devicerun.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/sessions:batchGet"

A solicitação é processada exatamente como a solicitação GET equivalente, com as mesmas permissões, validação e resposta. Também é possível transmitir os parâmetros como um corpo codificado por formulário (application/x-www-form-urlencoded) ou dividir os nomes de sessão em lotes menores. As bibliotecas de cliente e os clientes gRPC enviam solicitações no corpo da mensagem, então esse limite não os afeta. Para mais informações, consulte URLs de solicitação longos.

Solução de problemas específicos do Android

O app não retorna dados e não consegue localizar as capturas de tela

Os artefatos de execução do teste (como capturas de tela e arquivos de registro) são armazenados no Cloud Storage e renderizados diretamente no console do Google Cloud . Verifique se você atribuiu papéis para envolvidos no projeto.

Além disso, a plataforma de dispositivos para desenvolvedores tem um agente de serviço dedicado que usa as próprias credenciais, em vez das suas, para:

• Ler e gravar em buckets e objetos do Cloud Storage
• Baixar arquivos de entrada do Cloud Storage para o sistema interno
• Fazer upload de arquivos do sistema interno para o bucket de saída do Cloud Storage

É possível que você tenha acesso a um bucket do Cloud Storage e a um arquivo, mas que o bucket seja de propriedade de um projeto Google Cloud diferente daquele usado no DDP. Portanto, a conta de serviço da Developer Device Platform não tem acesso a ele.

Você também pode ter outros controles de acesso em buckets individuais. Consulte Device Run para saber como incluir arquivos nos testes e Shared Storage para saber como conceder acesso da Developer Device Platform a buckets externos.

Por que estou recebendo resultados parciais ou ausentes do caso de teste de instrumentação?

Ao executar testes de instrumentação, você pode notar que o total de casos de teste é menor do que o esperado. Isso geralmente acontece porque a Developer Device Platform não consegue analisar o Logcat para encontrar os marcadores de início ou término do caso de teste que geralmente são gerados por AndroidJUnitRunner.

Algumas causas comuns desse problema são as seguintes:

Descrição do problema	Possível solução
O caso de teste não foi executado devido a um tempo limite. Se a duração total dos testes for maior que o tempo limite especificado ou que o tempo limite máximo, o Developer Device Platform cancela o restante dos casos de teste.	Aumente o tempo limite de instrumentação do teste usando `--instrumentation-timeout` para garantir que todos os testes possam ser concluídos. Fragmente os testes se isso ainda não foi feito para que cada fragmento execute um subconjunto dos testes e seja concluído em um período mais curto. Se já tiver feito isso, aumente o número de fragmentos.
O caso de teste não foi concluído porque foi interrompido prematuramente ou teve problemas. O caso de teste pode ser encerrado prematuramente devido a uma exceção não identificada ou a um erro de declaração. Os casos de teste podem ficar travados em um loop infinito ou não continuar, por exemplo, se o app não mostrar a visualização correta e o caso de teste não puder realizar a ação na interface.	Verifique o vídeo e o logcat para investigar onde o teste foi interrompido.
Um executor de testes personalizados, incluindo a extensão de AndroidJUnitRunner, falhou de forma inesperada ou escreveu em logcat marcadores inesperados de início ou fim dos casos de teste.	Verifique o código do executor de testes.
Registros em excesso gravados em logcat, que sobrecarregaram o buffer ou travaram o processo logcat.	Reduza as gravações para logcat.
O app em teste sofreu uma falha.	Depurar o app.

---

Perguntas frequentes

Onde posso encontrar informações sobre os preços da Developer Device Platform?

Consulte Perguntas sobre preços e faturamento para mais detalhes.

Onde posso encontrar detalhes do dispositivo, como resolução etc.?

As informações detalhadas do dispositivo estão disponíveis na API e podem ser acessadas na CLI da Developer Device Platform com o comando device-run devices describe <device-id>:

gcloud beta device-run devices describe DEVICE_ID

Como faço para descobrir se o tráfego que chega ao back-end é proveniente do Developer Device Platform?

No seu back-end, é possível determinar se o tráfego vem de dispositivos de teste hospedados na plataforma de dispositivos do desenvolvedor ao verificar o endereço IP de origem em nossos intervalos de IP.

A Developer Device Platform funciona com o VPC Service Controls?

A Developer Device Platform não funciona com o VPC SC, que bloqueia a cópia de apps e outros artefatos de teste entre o armazenamento interno da Developer Device Platform e os buckets de resultados dos usuários.

Como reduzir testes instáveis na Developer Device Platform?

Para detectar comportamentos instáveis nos testes, recomendamos o uso da opção --flaky-test-attempts. As novas execuções de flakes são faturadas ou contadas em relação à cota diária da mesma forma que as execuções de teste normais.

Lembre-se:

• Por padrão, o DDP executa a nova tentativa em sequência para economizar. Os usuários precisam definir --flaky-test-parallel-retry para execução paralela.
• A flag --flaky-test-retry-level define se a nova tentativa será feita no nível shard ou test individual e o padrão é shard. Defina como test para reduzir o tamanho e a duração do teste de nova tentativa.

Observação: os erros de infraestrutura são independentes do recurso de descontinuação e não acionam novas execuções.

Perguntas frequentes específicas do iOS

O Developer Device Platform tem suporte para Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber?

Embora alguns desses itens estejam em nossos planos, não podemos garantir compromisso de suporte com essas plataformas de testes e desenvolvimento de apps.

Por que meu teste para iOS não tem vídeos nos resultados?

A compatibilidade com vídeos nos resultados está planejada para o iOS 18 ou versões mais recentes.

Perguntas frequentes específicas do Android

A Developer Device Platform é compatível com dispositivos wearable?

Sim. Developer Device Platform é compatível com o Google Pixel Watch. Agora você pode executar testes no app para Wear OS independente nos dispositivos Google Pixel Watch. Para saber mais sobre dispositivos da Developer Device Platform, consulte o Catálogo de dispositivos.

A Developer Device Platform é compatível com os dispositivos Google mais recentes?

Sim. A Developer Device Platform é compatível com o Google Pixel Tablet e o Google Pixel Fold. É possível executar testes em dispositivos físicos independentes. Para saber mais sobre os dispositivos disponíveis na Developer Device Platform, consulte o Catálogo de dispositivos.

A Developer Device Platform é compatível com Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber?

Embora alguns desses itens estejam em nossos planos, não podemos garantir compromisso de suporte com essas plataformas de testes e desenvolvimento de apps. No entanto, se você criou seu app com um framework que tem suporte ao Espresso, como o Flutter, é possível programar um teste de instrumentação usando o Espresso e depois executar o teste na Developer Device Platform.

O Developer Device Platform oferece suporte a testes de apps ofuscados, por exemplo, com o ProGuard ou o R8?

O Developer Device Platform não oferece suporte explícito à ofuscação ou desofuscação. Embora o app provavelmente seja executado, todos os dados ofuscados, como stack traces, vão aparecer como ofuscados nos registros.

Posso usar meu dispositivo dobrável em diferentes estados e posições dobráveis ao testar na Developer Device Platform?

Sim. É possível testar seu dispositivo dobrável em estados e posturas dobráveis.

Os dispositivos dobráveis podem estar em vários estados dobráveis, como FLAT (totalmente aberto) ou HALF_OPENED (entre totalmente abertos e completamente fechados).

Por outro lado, as posições consistem em orientação específica do dispositivo e estado dobrável. Por exemplo, a posição de mesa, que é um estado HALF_OPENED na orientação horizontal, ou a posição de livro, que é um estado HALF_OPENED na orientação vertical.

Se você estiver executando testes de instrumentação, use a biblioteca Jetpack WindowManager e siga a documentação Como testar seu app em dispositivos dobráveis para testar diferentes estados e posturas.

Como alternativa, os estados disponíveis são específicos do dispositivo e podem ser usados para interagir com o adb shell command cmd device_state.

• Para listar o estado atual, execute adb shell cmd device_state state.
• Para definir ou substituir o estado atual, execute adb shell cmd device_state state <IDENTIFIER>.
• Para redefinir o estado, execute adb shell cmd device_state state reset.
• Para verificar os estados disponíveis, execute o comando adb shell cmd device_state print-states no dispositivo dobrável.

Google Pixel Fold (código do modelo: felix)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSED', app_accessible=true},
      DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
      DeviceState{identifier=2, name='OPENED', app_accessible=true},
      DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]

Samsung Galaxy Z Fold4 (ID do modelo q4q)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSE', app_accessible=true},
      DeviceState{identifier=1, name='TENT', app_accessible=true},
      DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
      DeviceState{identifier=3, name='OPEN', app_accessible=true},
]

Posso testar a Developer Device Platform se eu não tiver um app?

Ao contrário de outros produtos da plataforma de dispositivos para desenvolvedores, não é necessário adicionar um SDK da plataforma de dispositivos para desenvolvedores para usar a plataforma. Se você ainda não tiver um app, faça o download de um APK ou crie um aplicativo e um APK de teste usando uma das amostras no repositório do AndroidX no GitHub. Um teste de instrumentação requer um app e um APK de teste criados usando o código-fonte. Para mais informações, leia sobre Testes de instrumentação.

Para saber mais sobre os recursos da Developer Device Platform, consulte a visão geral do produto DDP.

Quais são os melhores dispositivos para testes de diferença entre capturas de tela?

Os testes de diferença entre capturas de tela têm base nas comparações de imagens de tela coletadas ao executar um teste com golden images que representam o comportamento esperado. Esses testes podem ser mais frágeis em alguns tipos de dispositivos do que em outros. Recomendamos segmentar dispositivos com um emulador de ARM (*.arm) para esses tipos de teste. Os dispositivos com um emulador de ARM usam imagens muito semelhantes ou idênticas aos emuladores genéricos do Android Studio.

Também recomendamos que você investigue as bibliotecas de teste que podem ajudar a tornar os testes de captura de tela mais robustos para lidar com mudanças esperadas.

A Developer Device Platform atualiza dispositivos virtuais?

Sim. Os dispositivos virtuais são atualizados quando as seguintes mudanças são feitas:

1. Atualizações para imagens atuais
2. Descontinuação de níveis anteriores de API
3. Novos níveis da API do Android foram adicionados

Como faço para ativar os relatórios de cobertura?

Para ativar os relatórios de cobertura, adicione coverage=true ao campo additional-test-options. Se você estiver usando o Android Test Orchestrator, forneça um caminho de diretório para armazenar os resultados de cobertura:

--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/

Se você não usa o Orchestrator, então pode especificar um caminho de arquivo:

--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec

Como faço login em um app para Wear sem um smartphone?

Se o app normalmente exigir um smartphone para fazer login, você poderá criar uma variante de build que pule o login e use um token incorporado no build de teste ou ler arquivos no disco normalmente enviados usando a flag --other-files-to-push.

---