A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Note di rilascio della suite di test per le immagini della fotocamera Android 12

Nella release di Android 12 sono incluse diverse modifiche all'ITS della fotocamera. Questa pagina riassume le modifiche che rientrano in quattro ampie categorie:

Refactoring a Python 3
Adozione del framework di test Mobly
Testare le modifiche
Nuovi test

Refactoring a Python 3

A causa del ritiro di Python 2.7 a gennaio 2 2020, l'intero codebase ITS della videocamera è stato sottoposto a refactoring in Python 3. In Android 12 sono necessarie le seguenti versioni e librerie Python:

Il programma di lancio dei test principale, tools/run_all_tests.py, rimane invariato rispetto alle versioni Android 11 o precedenti e viene ristrutturato in Python 3.

Tutti i singoli test vengono sottoposti a refactoring e utilizzano la nuova classe di configurazione del test definita in tests/its_base_test.py. La maggior parte dei nomi e delle funzionalità dei test rimane invariata. In Android 12 tutti i singoli test ora caricano le proprie scene. Sebbene il caricamento della scena per ogni test aumenti il tempo di test complessivo, consente il debug dei singoli test.

Per ulteriori informazioni sulle modifiche ai singoli test, consulta Modifiche ai test.

I seguenti moduli Python sono stati sottoposti a refactoring con una modifica del nome:

pymodules/its/caps.py → utils/camera_properties_utils.py
pymodules/its/cv2image.py → utils/opencv_processing_utils.py
pymodules/its/device.py → utils/its_session_utils.py
pymodules/its/error.py → utils/error_util.py
pymodules/its/image.py → utils/image_processing_utils.py
pymodules/its/objects.py → utils/capture_request_utils.py
pymodules/its/target.py → utils/target_exposure_utils.py
tools/hw.py → utils/sensor_fusion_utils.py

Adozione del framework di test Mobly

Mobly è un framework di test basato su Python che supporta gli scenari di test che richiedono più dispositivi con configurazioni hardware personalizzate. La ITS della videocamera utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e registrazione dei test.

La ITS della videocamera utilizza l'infrastruttura di test Mobly per consentire un migliore controllo e logging dei test. Mobly è un framework di test basato su Python che supporta casi di test che richiedono più dispositivi con configurazioni hardware personalizzate. Per ulteriori informazioni su Mobly, visita la pagina google/mobly.

file config.yml

Con il framework Mobly, puoi configurare un dispositivo in test (DUT) e un tablet con grafici nella classe its_base_test. Un file config.yml (YAML) viene utilizzato per creare un testbed Mobly. In questo file di configurazione è possibile configurare più banchi di prova, ad esempio un tablet e un banco di prova di fusione di sensori. Nella sezione del controller di ogni testbed, puoi specificare device_ids per identificare i dispositivi Android appropriati per il programma di test. Oltre agli ID dispositivo, nella classe di test vengono passati altri parametri come il tablet brightness, chart_distance, debug_mode, camera_id e scene_id. I valori comuni dei parametri di test sono:

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

Test basati su tablet

Per i test su tablet, la parola chiave TABLET deve essere presente nel nome del testbed. Durante l'inizializzazione, il test runner di Mobly inizializza TestParams e li passa ai singoli test.

Di seguito è riportato un file config.yml di esempio per le esecuzioni su tablet.

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

La piattaforma di test può essere richiamata utilizzando tools/run_all_tests.py. Se non sono presenti valori della riga di comando, i test vengono eseguiti con i valori del file config.yml. Inoltre, puoi sostituire i valori dei file di configurazione camera e scene nella riga di comando utilizzando comandi simili ad Android 11 o versioni precedenti.

Ad esempio:

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=1 scenes=2,1,0

Test di fusione dei sensori

Per i test di fusione dei sensori, il nome della piattaforma di test deve includere la parola chiaveSENSOR_FUSION. La piattaforma di test corretta è determinata dalle scene testate. Android 12 supporta sia i controller Arduino sia i controller Canakit per la fusione dei sensori.

Di seguito è riportato un file config.yml di esempio per le esecuzioni di fusione dei dati dei sensori.

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         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Per eseguire test di fusione dei sensori con la apparecchiatura di test per la fusione dei sensori, utilizza:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

Più testbed

Nel file di configurazione è possibile includere più banchi di prova. La combinazione più comune è avere sia un testbed per tablet sia un testbed per la fusione dei sensori.

Di seguito è riportato un file config.yml di esempio con i testbed di fusione di tablet e sensori.

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

Test manuale

I test manuali continuano a essere supportati in Android 12. Tuttavia, il testbed deve identificare i test come tali con la parola chiave MANUAL nel nome del testbed. Inoltre, il laboratorio di test non può includere un ID tablet.

Di seguito è riportato un file config.yml di esempio per i test manuali.

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

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

Testare le scene senza tablet

I test per la scena 0 e la scena 5 possono essere eseguiti con TEST_BED_TABLET_SCENES o con TEST_BED_MANUAL. Tuttavia, se i test vengono eseguiti con TEST_BED_TABLET_SCENES, il tablet deve essere connesso e il suo ID di serie deve essere valido anche se il tablet non viene utilizzato perché la configurazione della classe di test assegna il valore dell'ID di serie al tablet.

Esegui test individuali

I singoli test possono essere eseguiti solo a scopo di debug perché i relativi risultati non vengono segnalati a CTS Verifier. Poiché i file config.yml non possono essere sovrascritti nella riga di comando per camera e scene, questi parametri devono essere corretti nel file config.yml per il singolo test in questione. Inoltre, se nel file di configurazione è presente più di un testbed, devi specificare il testbed con il flag --test_bed. Ad esempio:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Artefatti di test

In Android 12, gli elementi di test per l'ITS della fotocamera vengono memorizzati in modo simile ad Android 11 o versioni precedenti, ma con le seguenti modifiche:

Per chiarezza, alla directory dell'elemento del test /tmp è stato anteposto CameraITS_ alla stringa casuale di 8 caratteri.
L'output e gli errori dei test vengono memorizzati in test_log.DEBUG per ogni test anziché in test_name_stdout.txt e test_name_stderr.txt.
I logcat del DUT e del tablet di ogni singolo test sono memorizzati nella directory /tmp/CameraITS_########, semplificando il debugging poiché vengono registrate tutte le informazioni necessarie per eseguire il debug dei problemi relativi a 3A.

Testa le modifiche

In Android 12 le scene per tablet sono file PNG anziché PDF. L'utilizzo di file PNG consente a più modelli di tablet di visualizzare correttamente le scene.

scene0/test_jitter.py

Il test test_jitter viene eseguito su fotocamere nascoste fisiche in Android 12.

scene1_1/test_black_white.py

Per Android 12, test_black_white ha la funzionalità sia di test_black_white sia di test_channel_saturation.

La tabella seguente descrive i due singoli test in Android 11.

Nome test	Primo livello API	Verifiche
scene1_1/test_black_white.py	TUTTE	Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0] Esposizione lunga, valori RGB ad alto guadagno ~[255, 255, 255]
scene1_1/test_channel_saturation.py	29	Tolleranza ridotta per le differenze [255, 255, 255] per eliminare la tinta del colore nelle immagini bianche.

La tabella seguente descrive il test unito, scene1_1/test_black_white.py, in Android 12.

Nome test	Primo livello API	Verifiche
scene1_1/test_black_white.py	TUTTE	Esposizione breve, valori RGB a basso guadagno ~[0, 0, 0] Esposizione lunga, valori RGB ad alto guadagno ~[255, 255, 255] e tolleranza ridotta tra i valori per eliminare la tinta del colore nelle immagini bianche.

scene1_1/test_burst_sameness_manual.py

Il test test_burst_sameness_manual viene eseguito su fotocamere nascoste fisiche in Android 12.

scene1_2/test_tonemap_sequence.py

Il test test_tonemap_sequence viene eseguito su fotocamere LIMITATE in Android 12.

scene1_2/test_yuv_plus_raw.py

Il test test_yuv_plus_raw viene eseguito su fotocamere nascoste fisiche in Android 12.

scene2_a/test_format_combos.py

Il test test_format_combos viene eseguito su fotocamere LIMITATE in Android 12.

scene3/test_flip_mirror.py

Il test test_flip_mirror viene eseguito su fotocamere LIMITATE in Android 12.

scene4/test_aspect_ratio_and_crop.py

La ricerca di cerchi in scene4/test_aspect_ratio_and_crop.py è stata sottoposta a refactoring in Android 12.

Le versioni precedenti di Android utilizzavano un metodo che prevedeva il rilevamento di un contorno secondario (il cerchio) all'interno del contorno principale (il quadrato) con filtri per dimensioni e colore. Android 12 utilizza un metodo che prevede di trovare tutti i contorni e poi filtrare in base alle funzionalità più circolari. Per escludere i cerchi spuri sul display, è necessaria un'area con un contorni minimo e il contorno del cerchio deve essere nero.

I contorni e i relativi criteri di selezione sono mostrati nella seguente immagine.

Disegno concettuale di contorni e criteri di selezione

Figura 1. Disegno concettuale di contorni e criteri di selezione

Il metodo per Android 12 è più semplice e consente di risolvere il problema di ritaglio della casella delimitante in alcuni tablet da display. Tutti i candidati al cerchio vengono registrati a scopo di debug.

In Android 12, il test di ritaglio viene eseguito per i dispositivi FULL e LEVEL3. Le versioni di Android 11 o precedenti ignorano le affermazioni del test di ritaglio per i dispositivi FULL.

La tabella seguente elenca le asserzioni per test_aspect_ratio_and_crop.py che corrispondono a un determinato livello del dispositivo e al primo livello dell'API.

A livello di dispositivo	Primo livello API	Verifiche
LIMITATA	TUTTE	Proporzioni Campo visivo per i formati 4:3, 16:9, 2:1
COMPLETO	< 31	Proporzioni Campo visivo per i formati 4:3, 16:9, 2:1
COMPLETO	≥ 31	Ritaglio Proporzioni FoV per i formati 4:3, 16:9, 2:1
LEVEL3	TUTTE	Ritaglio Proporzioni FoV per i formati 4:3, 16:9, 2:1

scene4/test_multi_camera_alignment.py

Il metodo undo_zoom() per le acquisizioni YUV in scene4/test_multi_camera_alignment.py è stato sottoposto a refactoring per tenere conto in modo più accurato del ritaglio su sensori che non corrispondono alle proporzioni dell'acquisizione.

Codice Python 2 per Android 11

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Codice Python 3 per Android 12

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

sensor_fusion/test_sensor_fusion.py

In Android 12, per il test di fusione dei sensori è stato aggiunto un metodo per rilevare elementi nelle immagini.

Nelle versioni precedenti ad Android 12, viene utilizzata l'intera immagine per trovare le 240 migliori caratteristiche, che vengono poi mascherate per il 20% del centro per evitare effetti di scorrimento della fotocamera. Il requisito minimo di elementi è 30.

Se le funzionalità trovate con questo metodo non sono sufficienti, Android 12 maschera innanzitutto il 20% della zona di rilevamento delle funzionalità al centro e limita le funzionalità massime al doppio del requisito minimo.

L'immagine seguente mostra la differenza tra il rilevamento delle funzionalità di Android 11 e di Android 12. L'aumento della soglia minima dei requisiti delle funzionalità comporta il rilevamento di funzionalità di scarsa qualità e influisce negativamente sulle misurazioni.

differenza nel rilevamento delle funzionalità tra Android 11
e Android 12
rilevamento della funzionalità sensor_fusion

Figura 2. Differenza nel rilevamento delle funzionalità tra Android 11 e Android 12

Nuovi test

scene0/test_solid_color_test_pattern.py

Per Android 12 è stato attivato un nuovo test, test_solid_color_test_pattern. Questo test è abilitato per tutte le videocamere ed è descritto nella tabella seguente.

Scena	Nome test	Primo livello API	Descrizione
0	test_solid_color_test_pattern	31	Conferma l'output di immagini a tinta unita e la programmabilità del colore delle immagini.

Per supportare la modalità di privacy della fotocamera, è necessario attivare i pattern di test a tinta unita. Il test test_solid_color_test_pattern conferma l'output di immagini YUV a tinta unita con il colore definito dallo schema selezionato e il colore dell'immagine cambia in base alle specifiche.

Parametri

cameraPrivacyModeSupport: determina se la videocamera supporta la modalità Privacy.
android.sensor.testPatternMode: imposta la modalità del pattern di prova. Questo test utilizza SOLID_COLOR.
android.sensor.testPatternData: imposta i valori del pattern di test R, Gr, Gb, G per la modalità del pattern di test.

Per una descrizione del motivo di prova a tinta unita, consulta SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Metodo

I frame YUV vengono acquisiti per i parametri impostati e i contenuti dell'immagine vengono convalidati. Il pattern di prova viene visualizzato direttamente dal sensore di immagine, quindi non è richiesta una scena particolare. Se PER_FRAME_CONTROL è supportato, viene acquisito un singolo frame YUV per ogni impostazione testata. Se PER_FRAME_CONTROL non è supportato, vengono acquisiti quattro frame, con solo l'ultimo frame analizzato per massimizzare la copertura del test nelle videocamere LIMITED.

Le acquisizioni YUV sono impostate su pattern di test BLACK, WHITE, RED, GREEN e BLUE completamente saturi. Poiché la definizione del pattern di prova è in base al pattern Bayer del sensore, i canali di colore devono essere impostati per ogni colore come mostrato nella tabella seguente.

Colore	testPatternData (RGGB)
NERO	`(0, 0, 0, 0)`
BIANCO	`(1, 1, 1, 1)`
RED	`(1, 0, 0, 0)`
VERDE	`(0, 1, 1, 0)`
BLU	`(0, 0, 0, 1)`

Tabella di asserzione

La seguente tabella descrive le asserzioni di test per test_solid_color_test_pattern.py.

Fotocamera Primo livello API	Tipo di fotocamera	Colori rivendicati
31	Bayer	NERO, BIANCO, ROSSO, VERDE, BLU
31	MONO	NERO, BIANCO
< 31	Bayer/MONO	NERO

Test delle classi di rendimento

scene2_c/test_camera_launch_perf_class.py

Verifica che l'avvio della fotocamera sia inferiore a 500 ms sia per la fotocamera anteriore sia per quella posteriore con la scena di volti scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Verifica che la latenza di acquisizione JPEG a 1080p sia inferiore a 1 secondo sia per la fotocamera principale anteriore sia per quella posteriore con la scena di volti scene2_c.