Visão geral do Camera ITS

O pacote de testes de imagens da câmera (ITS, na sigla em inglês) é um framework para executar testes em imagens produzidas por uma câmera Android. O objetivo geral de cada teste no ITS é configurar a câmera de uma maneira específica, capturar uma ou mais fotos e examinar as fotos para verificar se elas contêm os dados de imagem esperados. Muitos dos testes exigem que a câmera seja apontada para um gráfico de destino específico ou iluminada em uma intensidade específica.

O ITS está localizado no harness de teste do Verificador do CTS em cts/apps/CameraITS. Os dispositivos precisam passar nos testes do ITS correspondentes aos recursos com suporte anunciados pelo framework da câmera para apps de terceiros como um subconjunto do CTS.

Configuração

Para executar testes do ITS, é necessário configurar o seguinte:

  • Um dispositivo em teste (DUT, na sigla em inglês)
  • Uma máquina host (por exemplo, um computador ou notebook Linux)
  • Uma cena que a câmera fotografa

Configuração do dispositivo em teste (DUT)

Para configurar um DUT, siga estas etapas:

  1. Conecte o DUT a uma máquina host por USB.
  2. Conceda permissões para que o host acesse o DUT pelo ADB.

  3. Instale o app Verificador do CTS (CtsVerifier.apk) no dispositivo. Para mais informações, consulte Como usar o Verificador do CTS.

    extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
cd android-cts-verifier
adb install -r -g CtsVerifier.apk

  4. No DUT, inicie o app de câmera padrão e feche todas as janelas que aparecem na inicialização para evitar interferências durante o teste.

Configuração do host

O ITS exige que a máquina host esteja conectada ao DUT por USB, possa usar o ADB para controle e comunicação do dispositivo e tenha o software necessário instalado.

Para configurar a máquina host, verifique se o software a seguir está instalado.

Android SDK Platform Tools

As ferramentas da plataforma do SDK do Android precisam ser instaladas, e o ADB precisa estar no caminho executável do shell ou terminal em execução na máquina host. Para a versão pública das ferramentas da plataforma do SDK do Android, consulte as notas da versão das ferramentas da plataforma do SDK.

Python

O Python precisa estar instalado na máquina host. Recomendamos o uso de uma distribuição Python agrupada para garantir o suporte a versões compatíveis. Para detalhes sobre quais versões do Python e do pacote instalar para uma versão específica, consulte as notas da versão do ITS da câmera para a versão correspondente.

Mobly

No Android 12 e versões mais recentes, instale o framework de teste Mobly. O Mobly permite configurar um DUT e um tablet de gráfico na classe its_base_test. Para instalar o framework de teste Mobly, execute:

pip install mobly

configuração do ambiente

Para configurar o ambiente de teste, execute:

cd CameraITS
source build/envsetup.sh

Esse comando verifica a instalação do Python, configura a variável de ambiente PYTHONPATH e executa testes de unidade nos módulos utils/*.py. Se nenhum erro for impresso no terminal, o ambiente estará pronto para executar os testes do ITS.

Configuração da cena

Para configurar as cenas, recomendamos usar a configuração do ITS-in-a-box da câmera para facilitar a automação, a confiabilidade e a eficiência nos testes. Os equipamentos de teste ITS-in-a-box oferecem suporte a todos os requisitos de iluminação, centralização e mudança de gráfico para ITS. Além disso, o ITS-in-a-box é necessário para testes de extensões de câmera.

Para testes manuais, verifique o seguinte:

  • O DUT está em um tripé
  • O DUT está apontado para a cena correta de cada teste. O script de teste do ITS fornece comandos para mudar a configuração da cena antes de iniciar os testes em uma nova cena.
  • O DUT está conectado à máquina host por USB.
  • O DUT não se move durante a execução do teste.
  • A cena é iluminada com uma fonte de luz constante e não flutuante. Não use uma luz fluorescente, porque ela introduz oscilação.

O script de teste do ITS mostra um comando pedindo ao usuário para mudar a configuração da cena antes de iniciar os testes em uma nova cena.

A orientação do smartphone precisa ser definida para que a câmera tire fotos sem rotação. A maneira mais fácil de verificar isso é com as cenas de rosto em scene2. A maioria dos smartphones tem o smartphone na orientação paisagem com o smartphone girado no sentido anti-horário para a câmera traseira e no sentido horário para a câmera frontal.

Arquivos de configuração

Usando o framework Mobly, é necessário criar um arquivo de configuração config.yml para definir o testbed Mobly. Confira abaixo exemplos para diferentes casos de uso.

Arquivo config.yml de cenas baseadas em tablet

Confira abaixo um exemplo de arquivo config.yml para cenas baseadas em tablet. Para testes baseados em tablet, a palavra-chave TABLET precisa estar no nome do testbed. Durante a inicialização, o executor de testes Mobly inicializa os parâmetros no arquivo e os transmite aos testes individuais.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # "True" or "False"; quotes needed
      lighting_cntl: <controller-type>  # "arduino" or "None"; quotes needed
      lighting_ch: <controller-channel>
      camera: 0
      foldable_device: "False". # set "True" if testing foldable
      scene: <scene-name>  # if <scene-name> runs all scenes

Para invocar o testbed, execute tools/run_all_tests.py. Se não houver valores de linha de comando especificando câmeras ou cenas, o teste será executado com os valores do arquivo config.yml. Se houver valores de linha de comando para câmeras ou cenas, eles vão substituir os valores na seção TestParams do arquivo config.yml. Exemplo:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

Parâmetro chart_scaling

No Android 17 e versões mais recentes, o parâmetro chart_scaling está incluído em config.yml para TEST_BED_TABLET_SCENES. Esse parâmetro resolve problemas de escalonamento de gráficos para dispositivos de câmera tele com um campo de visão (FoV, na sigla em inglês) mais amplo, evitando o corte de cenas e aplicando o foco correto do dispositivo durante o teste.

Os valores aceitos para chart_scaling são 1, 0.33, 0.5 ou 0.67, com None como padrão. Essa abordagem permite que os dispositivos usem um fator de escalonamento ideal adaptado aos requisitos específicos, mantendo os testes funcionais em todos os dispositivos.

Se chart_scaling estiver definido como None, os testes vão determinar automaticamente o fator de escalonamento usando chart_scaling_logic. Caso contrário, o valor especificado em config.yml será usado ou um erro será sinalizado se o escalonamento não estiver disponível.

Confira abaixo um exemplo de config.yml com o parâmetro chart_scaling

TestBeds:
  -   Name: TEST_BED_TABLET_SCENES  # Need 'tablet' in name for tablet scenes
    # Use TEST_BED_MANUAL for manual testing and remove below lines:
    #     - serial <tablet_id>
    #       label: tablet
    # Test configuration for scenes[0:4, 6]
    Controllers:
        AndroidDevice:
          -   serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
          -   serial: <tablet-id>  # quotes needed if serial id entirely numeric
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # quotes needed
      lighting_cntl: <controller-type>  # can be arduino or "None"
      lighting_ch: <controller-channel>
      camera: <camera-id>
      scene: <scene-name>  # if <scene-name> runs all scenes
      foldable_device: "False"  # "True" if testing foldable device
      chart_scaling: "None"  # use the values available for scene to be tested
      resultstore_upload: "False"  # "True" if results should be uploaded to ResultStore

Ajustes do lado do teste são necessários para ativar os recursos de escalonamento de gráficos do ITS da câmera. Se um teste que você está usando não oferece suporte a isso, registre um bug.

Confira abaixo um exemplo de mudança do lado do teste com o parâmetro chart_scaling.

# load chart for scene
      its_session_utils.load_scene(
          cam, props, self.scene, self.tablet, self.chart_distance,
          chart_scaling=self.chart_scaling)

Arquivo config.yml de cena sensor_fusion

Confira abaixo um exemplo de arquivo config_yml para testes sensor_fusion. Para testes sensor_fusion, a palavra-chave SENSOR_FUSION precisa estar no nome do testbed. O Android 13 e versões mais recentes oferecem suporte apenas ao controlador Arduino para fusão de sensores devido a testes de estabilização de visualização e vídeo. O Android 12 oferece suporte aos controladores Arduino e Canakit.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino
      rotator_ch: 1
      camera: 0

Para executar testes sensor_fusion com a caixa de fusão do sensor, execute:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

Arquivo config.yml de vários testbeds

Confira abaixo um exemplo de arquivo config.yml com vários testbeds, um testbed de tablet e um testbed sensor_fusion. O testbed correto é determinado pelas cenas testadas.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>           # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Arquivo config.yml de teste manual

Confira abaixo um exemplo de arquivo config.yml para testes manuais. O Android 14 e versões mais recentes oferecem suporte a testes manuais para todos os testes, exceto os scene_extensions testes. Para testes manuais, a palavra-chave MANUAL precisa estar no nome do testbed. Além disso, a seção AndroidDevice não pode incluir uma seção de número de série ou rótulo para um tablet.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: 1

Arquivo config.yml de teste de equipamento Gen2

Confira abaixo um exemplo de arquivo config.yml de um testbed TEST_BED_GEN2. Esse testbed é usado para testes scene_ip, que usam um equipamento Gen2](/docs/compatibility/cts/camera-its-box-gen2). O exemplo a seguir mostra os parâmetros do testbed quando o equipamento Gen2 está disponível e os scene_ip testes não são ignorados.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: gen2_rotator   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: 0
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: gen2_lights  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: 1
      scene: scene_ip

O exemplo a seguir mostra os parâmetros do testbed quando o equipamento Gen2 não está disponível e os testes scene_ip são ignorados.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: "None"   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: <controller-channel>
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: "None"  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: <controller-channel>
      scene: scene_ip

Para executar o teste scene_ip, use um dos seguintes comandos:

python tests/scene_ip/test_default_jca_ip.py -c config.yml
python tools/run_all_tests.py camera=<camera-id> scenes=scene_ip

Como executar testes do ITS

Esta seção descreve como executar testes do ITS.

Como invocar testes

Depois que o dispositivo, a máquina host (incluindo o ambiente) e a cena física forem configurados, execute os testes do ITS usando o processo a seguir.

  1. Abra o app Verificador do CTS. No menu de testes, selecione Teste ITS da câmera. No Android 17 e versões mais recentes, os testes sensor_fusion e feature_combination estão em outra atividade chamada Teste de equipamento de fusão de sensores ITS da câmera.

  2. Na máquina host, execute os testes do ITS no diretório CameraITS/. Por exemplo, para um dispositivo com câmeras frontal e traseira, execute o seguinte comando:

    python tools/run_all_tests.py

    O script itera pelas câmeras e cenas de teste com base no arquivo config.yml. Para configurações de depuração, recomendamos executar uma das cenas scene2 com um único teste para uma resposta mais rápida.

    Para testes manuais, antes de começar a executar o conjunto de testes do ITS em cada cena, o script tira uma foto da cena atual, salva como JPEG, imprime o caminho para o JPEG no console e pede ao usuário para confirmar se a imagem está correta. Esse fluxo de captura e confirmação é repetido até que o usuário confirme que a imagem está correta. Confira abaixo as mensagens nesse fluxo.

    Preparing to run ITS on camera 0
Start running ITS on camera:  0
Press Enter after placing camera 0 to frame the test scene:
scene1_1
The scene setup should be: A grey card covering at least the   middle 30% of the scene
Running vendor 3A on device
Capture an image to check the test scene
Capturing 1 frame with 1 format [yuv]
Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg
Is the image okay for ITS scene1_1? (Y/N)

    Cada execução do script imprime um registro mostrando PASS, FAIL, FAIL* ou SKIP para cada teste do ITS. FAIL* indica que o teste falhou, mas como ele ainda não é obrigatório, o teste será informado como PASS para o CtsVerifier. SKIP indica que o teste foi aprovado porque o dispositivo não anunciou o recurso subjacente que está sendo testado. Por exemplo, se um dispositivo não anunciar pelas interfaces da câmera que oferece suporte a DNG, os testes relacionados à captura de arquivos DNG serão ignorados e contados como PASS.

  3. Para confirmar que os testes atenderam aos requisitos de teste, toque no botão de marca de seleção verde. A entrada Teste ITS da câmera no menu de testes do Verificador do CTS fica verde e indica que o smartphone passou no ITS da câmera.

Teste paralelo de DUT

Dispositivos com o Android 14 ou versões mais recentes oferecem suporte a testes paralelos de DUT. Isso permite testar DUTs em paralelo com vários equipamentos para acelerar o teste geral. Por exemplo, o teste paralelo permite testar a câmera 0 em um equipamento e a câmera 1 em outro equipamento ao mesmo tempo. No Android 17 e versões mais recentes, como os testes do ITS da câmera são divididos em duas atividades, é possível executar testes sensor_fusion e feature_combination em um DUT e outros testes em outro DUT em paralelo. Todos os testes para sessões de teste paralelas são agregados na sessão do Verificador do CTS no DUT de referência. É necessário executar testes paralelos com o controle de iluminação Arduino, já que o controle de iluminação manual não é compatível com testes paralelos. Verifique se um canal diferente no mesmo controlador Arduino controla a iluminação de cada equipamento.

Confira abaixo um exemplo de arquivo config.yml que define três testbeds para execução em paralelo.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES_INDEX_0
    Controllers:
        AndroidDevice:
          - serial: <device-id-0>
            label: dut
          - serial: <tablet-id-0>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-0>
      camera: 0
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  - Name: TEST_BED_TABLET_SCENES_INDEX_1
    Controllers:
        AndroidDevice:
          - serial: <device-id-1>
            label: dut
          - serial: <tablet-id-1>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-1>
      camera: 1
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  # TEST_BED_SENSOR_FUSION represents testbed index 2
  # Parallel sensor_fusion is currently unsupported due to Arduino requirements
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion
    Controllers:
        AndroidDevice:
          - serial: <device-id>
            label: dut
    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: "arduino"
      rotator_ch: <controller-channel-2>
      camera: <camera-id>
      foldable_device: "False"
      tablet_device: "False"
      lighting_cntl: "None"
      lighting_ch: <controller-channel>
      scene: "sensor_fusion"

Para executar os testbeds em paralelo, use o seguinte comando:

for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; wait

Enviar resultados de testes agregados

No Android 17 e versões mais recentes, é possível enviar resultados de testes agregados do ITS da câmera para aprovação do build. O Verificador do CTS permite testar várias cenas simultaneamente em vários dispositivos e agregar resultados de testes de vários relatórios do Verificador do CTS (de diferentes execuções de teste ou dispositivos) em um único envio unificado.

Processo de envio

Para enviar resultados agregados do ITS da câmera para aprovação do build, siga estas etapas:

  1. Prepare os dispositivos:reúna dois ou três dispositivos em teste (DUTs) que tenham a mesma impressão digital do build.
  2. Instale o Verificador do CTS:instale o APK mais recente do Verificador do CTS, que pode ser obtido no build explorer fornecido.

  3. Execute testes em paralelo :

    1. Monte os DUTs em equipamentos separados.
    2. Execute diferentes cenas do ITS da câmera em cada dispositivo simultaneamente.
    3. Coleta de relatórios:extraia o relatório do Verificador do CTS após cada execução. Isso inclui relatórios em que as cenas falharam. Execute novamente apenas as cenas com falha em execuções subsequentes.

  4. Enviar relatórios:faça upload de vários relatórios do Verificador do CTS coletados de todos os dispositivos.

  5. Analisar resultados:depois que os relatórios forem enviados, analise os resultados agregados:

    • A seção Análise de testes mostra uma lista completa de todas as cenas executadas.

    • As cenas não executadas ou com falha são listadas na seção Falha.

      result-aggregation-image-1

      Figura 1. Documentação de cenas que não foram executadas ou falharam.

    • As cenas aprovadas são listadas na seção Aprovação agregada.

      result-aggregation-image-2

      Figura 2. Cenas categorizadas como aprovação agregada

Status de aprovação do build

A aprovação do build é concedida quando todas as cenas necessárias são concluídas com sucesso nos relatórios agregados.

Modelo de ruído DNG

Os dispositivos que anunciam a capacidade de capturar RAW ou DNG precisam fornecer um modelo de ruído nos metadados de resultado da captura de cada foto bruta. Esse modelo de ruído precisa ser incorporado ao HAL da câmera para cada câmera (por exemplo, câmeras frontal e traseira) no dispositivo que declara suporte.

Implementação do modelo de ruído

Para implementar um modelo de ruído, siga estas etapas para gerar um modelo de ruído e incorporar o modelo ao HAL da câmera.

  1. Para gerar um modelo de ruído para cada câmera, execute o dng_noise_model.py script no tools diretório. Isso gera um snippet de código C. Para mais informações sobre como configurar a câmera e o ambiente de captura, consulte o documento DngNoiseModel.pdf no diretório tools.

  2. Para implementar o modelo de ruído para o dispositivo, recorte e cole o snippet de código C no HAL da câmera.

Validação do modelo de ruído

O teste ITS automatizado tests/scene1_1/test_dng_noise_model.py valida o modelo de ruído verificando se os valores de ruído para a exposição e o ganho da foto fornecidos nos dados da câmera estão corretos.

Testes aprovados marginalmente (status de teste PASS*)

No Android 17 e versões mais recentes, uma aprovação marginal (PASS*) indica que um teste foi aprovado, mas as métricas de performance estão muito próximas do limite de aprovação predefinido. Embora o teste atenda tecnicamente aos critérios de aprovação, a proximidade do limite de falha sugere a necessidade de um exame mais detalhado.

Benefícios da aprovação marginal

O status PASS* oferece vários benefícios:

  • Sistema de alerta antecipado: identifica testes que estão prestes a falhar, permitindo que as equipes resolvam problemas antes que eles levem a falhas completas.

  • Otimização proativa: incentiva as equipes a otimizar testes e códigos que estão sendo executados na extremidade inferior do intervalo aceitável, melhorando a estabilidade geral.

  • Qualidade aprimorada: ajuda a manter um padrão de qualidade mais alto, sinalizando áreas que podem ser suscetíveis a regressões futuras com pequenas mudanças de código.

  • Tempo de depuração reduzido: ao detectar testes PASS* com antecedência, o tempo e o esforço necessários para depurar falhas completas no futuro podem ser significativamente reduzidos.

Detalhes do PASS*

O status PASS* inclui o seguinte:

  • Definição de limites: limites de aprovação marginal específicos são definidos para cada teste relevante no ITS da câmera.

  • Detecção automatizada: o sistema de automação de testes detecta e categoriza testes como PASS* com base nos limites definidos.

  • Mecanismo de alerta: as equipes recebem alertas automatizados para todos os testes sinalizados como PASS*, direcionando-as para investigar o teste específico e as métricas dele.

  • Relatórios: os status de aprovação marginal são claramente indicados em relatórios de teste e painéis para melhor visibilidade como PASS* no relatório ItsTestSummary, semelhante a Fail* para testes not_yet_mandated. O teste mantém um status verde, pois continua sendo aprovado dentro dos limites estabelecidos, para evitar mais confusão. O status PASS* se aplica apenas a uma classe de teste, não a toda a cena. Por exemplo, Scene_0 pode ser considerado PASS mesmo que test_jitter e test_metadata sejam PASS*.

  • Monitoramento: os dados de performance são coletados em testes que são aprovados marginalmente em um dispositivo. Isso permite o monitoramento de futuras melhorias da câmera feitas por OEMs se esses testes fizerem a transição para um status PASS.

Confira abaixo um exemplo de resultados de testes com PASS*:

INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}

Incentivamos os parceiros a:

  • Monitorar alertas PASS*
  • Investigar a causa raiz dos testes PASS*
  • Otimizar proativamente os testes e o código identificados como PASS*

O status PASS* tem como objetivo melhorar a robustez e a confiabilidade dos testes do ITS da câmera, levando a um produto estável e de alta qualidade.