Visão geral da execução do dispositivo na 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.

Este é o Device Run da Developer Device Platform, que permite executar testes e executáveis em dispositivos Android físicos e virtuais e em dispositivos iOS físicos na nuvem. Esta página resume os recursos e descreve as semelhanças entre a execução de testes de instrumentação do Android, executáveis do Android e testes XCTest do iOS.

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

Para usar essa Google Cloud CLI, você precisa fornecer o ID do projeto do Google Cloud . Para um resumo dos comandos, consulte: gcloud beta device-run

Dica: anexe --help a qualquer comando gcloud para ver informações detalhadas de uso.

Principais recursos

O Device Run da Developer Device Platform é um serviço do Google Cloud que permite executar pacotes de testes automatizados em dispositivos móveis físicos e virtuais. Criado para fluxos de trabalho modernos de integração contínua e entrega contínua (CI/CD), o Device Run oferece controle de linha de comando pela Google Cloud CLI (gcloud beta device-run), permitindo que as equipes executem, gerenciem e escalonem pacotes de testes em hardware dedicado e ambientes virtuais.

1. Testes automatizados multiplataforma

• Suporte para Android e iOS: o Device Run é compatível com frameworks de teste integrados, incluindo testes de instrumentação do Android (.apk), executáveis do Android (binários compilados) e XCTests do iOS (.ipa ou .zip).
• Segmentação flexível de dispositivos: segmente dispositivos físicos ou virtuais específicos listados no Catálogo de dispositivos usando identificadores de SO e modelo (por exemplo, modelos Pixel ou iPhone) com a flag --device.
• Execução paralela multidispositivo: execute pacotes de testes idênticos simultaneamente em vários dispositivos especificando IDs de dispositivo separados por vírgulas ou fornecendo várias flags --device.

2. Modos e controles de execução flexíveis

• Envios síncronos e assíncronos: as execuções de teste operam de forma síncrona por padrão, exibindo um resumo após a conclusão. Adicionar a flag --async retorna um ID de sessão imediatamente para execução sem bloqueio, que pode ser monitorada posteriormente usando gcloud beta device-run sessions wait.
• Tempos limite de execução personalizados*: configure limites de duração de execução com --instrumentation-timeout ou --xctest-timeout.
• Novas tentativas de teste instável: defina o número máximo de tentativas de execução do teste instável usando a flag --flaky-test-attempts.

3. Gerenciamento de versões e dependências de software

• Ambientes de teste configuráveis*: descubra, inspecione e selecione versões específicas de ambientes de software, como o AndroidX Test Orchestrator e o Apple Xcode, antes de iniciar as execuções de teste.
• Descoberta de versão: use os comandos gcloud beta device-run software-versions list e describe para conferir os pacotes de software ativos, as versões de SO compatíveis e as especificações de ambiente de execução padrão.

4. Gerenciamento de armazenamento e artefatos

• Integração com o Cloud Storage: as entradas de teste (APKs, IPAs, apps de suporte) e os artefatos de saída (registros, relatórios de teste) são armazenados no Cloud Storage.
• Flexibilidade de bucket: usa automaticamente como padrão um bucket de projeto chamado PROJECT_ID-devicerun ou roteia para um bucket personalizado especificado pela flag --bucket-name. Você tem controle total sobre esse bucket e precisará remover manualmente o conteúdo dele quando não for mais necessário ou configurar o gerenciamento automatizado do ciclo de vida no bucket. Consulte Sobre a exclusão de objetos para ver instruções.
• Caminhos diretos da nuvem: referencie caminhos do gs:// diretamente para arquivos grandes para eliminar a sobrecarga de upload.

5. Recursos avançados de teste do Android

• Android Test Orchestrator: Isole a execução do teste executando cada teste na própria instância de Instrumentation para evitar o estado compartilhado do app e isolar falhas do aplicativo.
• Fragmentação de teste:
  • Fragmentação uniforme: divide os casos de teste de maneira uniforme em um número especificado de fragmentos (--sharding-option=uniform).
  • Fragmentação inteligente: usa dados históricos de execução de testes para equilibrar os casos de teste dinamicamente entre os fragmentos, visando uma duração total de execução do teste específica (--sharding-option=smart).

6. Gerenciamento e diagnóstico de sessões

• Controle total da sessão: liste, descreva, filtre ou cancele execuções de teste ativas ou históricas usando sessions list, sessions describe e sessions cancel.
• Validação de entrada antecipada: realiza a validação automática em binários de teste e artefatos de configuração enviados, mostrando detalhes de erros explícitos e causas raiz (como incompatibilidades de pacotes de destino) quando ocorrem erros.

Configurações principais

Flags obrigatórias

Estas flags são obrigatórias:

• Dispositivo: especifique um dispositivo usando --device: --device shiba-35 ou --device iphonese3-18-4
• Teste ou executável: especifique o pacote de teste usando --test (--test /path/to/test.apk ou --test /path/to/MyTests.zip) para execuções de teste ou especifique o binário ou script executável usando --executable (--executable /path/to/my_executable) para execuções de executáveis do Android.

As opções de configuração a seguir são comuns em sessões do Device Run.

Caminhos de entrada e saída do Cloud Storage

• Bucket personalizado do Cloud Storage: é possível especificar um bucket personalizado do Cloud Storage para entradas e saídas: --bucket-name=my-custom-bucket Se você não especificar um bucket do Cloud Storage usando a flag --bucket-name=, a Google Cloud CLI vai usar um bucket padrão chamado PROJECT_ID-devicerun.
• Arquivos de entrada: quando você especifica um caminho local com as sinalizações --test, --executable, --apps, --additional-apps, --other-files-to-push ou --xctestrun-file, a Google Cloud CLI o copia automaticamente para o bucket do Cloud Storage em gs://BUCKET_NAME/automation/inputs/DATE_TIME_FOUR_CHARS_SUFFIX/ sempre que você executa o comando, em que BUCKET_NAME é padronizado como PROJECT_ID-devicerun.
• Caminhos do Cloud: como o upload de arquivos grandes pode ser demorado, é possível fazer referência direta a eles usando os caminhos gs:// do Cloud Storage para economizar tempo de upload.
• Arquivos de resultado: os artefatos de saída são enviados para o bucket do Cloud Storage em gs://BUCKET_NAME/automation/sessions/session-[SESSION_ID]/.

Validação de entrada

A Developer Device Platform tenta validar suas entradas, incluindo artefatos, e retorna um ERROR em vez de PASSED ou FAILED ao encontrar uma entrada com erro:

Session [session-94b57778] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   ERROR

Agora, adicione --full ao comando sessions describe para ver mais detalhes sobre a sessão:

gcloud beta device-run sessions describe --full session-94b57778

O que resulta em uma saída semelhante a:

name: projects/user-test1/locations/global/sessions/session-94b57778
sessionConfig:
  displayName: instrumentation-session
  jobConfigs:
  -   action:
      androidInstrumentationTest:
        testInstallable:
          files:
          -   gcsInputFile:
              path: gs://user-test1-devicerun/automation/inputs/2026-09-16_18:55.17372947_EECF/my-test.apk
    allocationConfig:
      deviceConfigs:
      -   actions:
        -   androidLogcat: {}
        requirement:
          deviceId: mediumphone-arm-34
    displayName: job-000
  outputDirectoryConfig:
    gcsOutputDirectory:
      path: gs://user-test1-devicerun/automation/sessions
sessionReport:
  endTime: '2026-09-16T18:55:49.721Z'
  id: ed681f23-669b-4464-8a93-b28456e58136
  jobReports:
  -   displayName: job-000
    endTime: '2026-09-16T18:55:45.839Z'
    executionReports:
    -   displayName: execution-000
      endTime: '2026-09-16T18:55:46.694Z'
      id: ce370173-af94-4dd7-acc6-0863e4d2e9ec
      result:
        cause:
          summary:
            message: The instrumentation target package does not match any of the
              installable packages.
            reason: INSTRUMENTATION_TARGET_MISMATCH
            type: CUSTOMER
        resultType: ERROR
      startTime: '1970-01-01T00:00:00Z'
      status:
        statusType: PENDING
    id: 953b5106-3c20-40f0-aceb-18af89cd1b83
    result:
      cause:
        summary:
          message: The instrumentation target package does not match any of the installable
            packages.
          reason: INSTRUMENTATION_TARGET_MISMATCH
          type: CUSTOMER
      resultType: ERROR
    startTime: '2026-09-16T18:55:31.651Z'
    status:
      statusType: DONE
  result:
    resultType: ERROR
  startTime: '2026-09-16T18:55:24.442Z'
  status:
    statusType: DONE

A seguir

Execute um teste de instrumentação do Android, um executável do Android ou um XCTest do iOS com a Plataforma de Dispositivos para Desenvolvedores.