Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Versionshinweise für die Android 12 Camera Image Test Suite

Mit der Android 12-Version wurden einige Änderungen an den Camera ITS eingeführt. Auf dieser Seite werden die Änderungen zusammengefasst, die in vier Kategorien unterteilt sind:

Refactoring zu Python 3
Übernahme des Mobly-Test-Frameworks
Änderungen an Tests
Neue Tests

Refactoring zu Python 3

Aufgrund der Einstellung von Python 2.7 im Januar 2020 wurde die gesamte Camera ITS-Codebasis zu Python 3 refaktoriert. Die folgenden Python-Versionen und ‑Bibliotheken sind in Android 12 erforderlich:

Der Haupt-Test-Launcher tools/run_all_tests.py ist derselbe wie in Android 11 oder niedrigeren Versionen und wurde zu Python 3 refaktoriert.

Alle einzelnen Tests wurden refaktoriert und verwenden die neue Testeinrichtungsklasse, die in tests/its_base_test.py definiert ist. Die meisten Testnamen und ‑funktionen bleiben gleich. In Android 12 werden die Szenen jetzt für alle einzelnen Tests geladen. Das Laden von Szenen für jeden Test verlängert zwar die Gesamttestzeit, ermöglicht aber das Debuggen einzelner Tests.

Weitere Informationen zu Änderungen an einzelnen Tests finden Sie unter Änderungen an Tests.

Die folgenden Python-Module wurden refaktoriert und umbenannt:

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

Übernahme des Mobly-Test-Frameworks

Mobly ist ein Python-basiertes Test Framework, das Testfälle unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwareeinrichtungen erforderlich sind. Camera ITS verwendet die Mobly-Testinfrastruktur, um die Tests besser steuern und protokollieren zu können.

Camera ITS verwendet die Mobly-Testinfrastruktur, um die Tests besser steuern und protokollieren zu können. Mobly ist ein Python-basiertes Test-Framework, das Testfälle unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwareeinrichtungen erforderlich sind. Weitere Informationen zu Mobly finden Sie unter google/mobly.

`config.yml`-Dateien

Mit dem Mobly-Framework können Sie in der Klasse its_base_test ein zu testendes Gerät (Device Under Test, DUT) und ein Tablet für Diagramme einrichten. Eine config.yml-Datei (YAML) wird verwendet, um eine Mobly-Testumgebung zu erstellen. In dieser Konfigurationsdatei können mehrere Testumgebungen konfiguriert werden, z. B. eine Tablet- und eine Sensorfusions-Testumgebung. Im Controller-Bereich jeder Testumgebung können Sie device_ids angeben, um die entsprechenden Android-Geräte für den Test-Runner zu identifizieren. Neben den Geräte-IDs werden auch andere Parameter wie brightness (Helligkeit), chart_distance (Abstand zum Diagramm), debug_mode (Debug-Modus), camera_id (Kamera-ID) und scene_id (Szenen-ID) in der Testklasse übergeben. Häufige Werte für Testparameter sind:

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)

Tablet-basierte Tests

Für Tablet-basierte Tests muss das Keyword TABLET im Namen der Testumgebung vorhanden sein. Während der Initialisierung initialisiert der Mobly-Test-Runner TestParams und übergibt sie an die einzelnen Tests.

Hier sehen Sie ein Beispiel für eine config.yml-Datei für Tablet-basierte Tests.

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

Die Testumgebung kann mit tools/run_all_tests.py aufgerufen werden. Wenn keine Befehlszeilenwerte vorhanden sind, werden die Tests mit den Werten aus der config.yml-Datei ausgeführt. Außerdem können Sie die Werte für camera und scene in der Konfigurationsdatei in der Befehlszeile mit Befehlen überschreiben, die Android 11 oder niedrigeren Versionen ähneln.

Beispiel:

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

Sensorfusionstests

Für Sensorfusionstests, muss der Name der Testumgebung das Keyword enthalten SENSOR_FUSION. Die richtige Testumgebung wird durch die getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino als auch Canakit Controller für die Sensorfusion.

Hier sehen Sie ein Beispiel für eine config.yml-Datei für Sensorfusionstests.

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

So führen Sie Sensorfusionstests mit der Sensorfusions-Testeinrichtung, aus:

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

Mehrere Testumgebungen

In der Konfigurationsdatei können mehrere Testumgebungen enthalten sein. Die häufigste Kombination ist eine Tablet-Testumgebung und eine Sensorfusions-Testumgebung.

Hier sehen Sie ein Beispiel für eine config.yml-Datei mit Tablet- und Sensorfusions-Testumgebungen.

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

Manuelle Tests

Manuelle Tests werden in Android 12 weiterhin unterstützt. Die Testumgebung muss jedoch mit dem Keyword MANUAL im Namen der Testumgebung als solche gekennzeichnet sein. Außerdem darf die Testumgebung keine Tablet-ID enthalten.

Hier sehen Sie ein Beispiel für eine config.yml-Datei für manuelle Tests.

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

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

Testszenen ohne Tablets

Tests für Szene 0 und Szene 5 können mit TEST_BED_TABLET_SCENES oder mit TEST_BED_MANUAL durchgeführt werden. Wenn die Tests jedoch mit TEST_BED_TABLET_SCENES durchgeführt werden, muss das Tablet verbunden sein und die Serien-ID des Tablets muss gültig sein, obwohl das Tablet nicht verwendet wird, da die Serien-ID für das Tablet in der Testklasseneinrichtung zugewiesen wird.

Einzelne Tests ausführen

Einzelne Tests können nur zu Debugging-Zwecken ausgeführt werden, da ihre Ergebnisse nicht an CTS Verifiergemeldet werden. Da die config.yml-Dateien in der Befehlszeile für camera und scene nicht überschrieben werden können, müssen diese Parameter in der config.yml-Datei für den jeweiligen Test korrekt sein. Wenn außerdem mehrere Testumgebungen in der Konfigurationsdatei vorhanden sind, müssen Sie die Testumgebung mit dem Flag --test_bed angeben. Beispiel:

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

Testartefakte

In Android 12 werden Testartefakte für Camera ITS ähnlich wie in Android 11 oder niedrigeren Versionen gespeichert, aber mit den folgenden Änderungen:

Dem Verzeichnis /tmp für Testartefakte wird zur besseren Übersicht CameraITS_ vor dem zufälligen String mit 8 Zeichen vorangestellt.
Testausgabe und ‑fehler werden für jeden Test in test_log.DEBUG anstelle von test_name_stdout.txt und test_name_stderr.txt gespeichert.
Die Logcats für DUT und Tablet aus jedem einzelnen Test werden im Verzeichnis /tmp/CameraITS_######## gespeichert. Dadurch wird das Debugging vereinfacht, da alle Informationen, die zum Debuggen von 3A-Problemen erforderlich sind, protokolliert werden.

Änderungen an Tests

In Android 12 sind die Tablet-Szenen PNG-Dateien und keine PDF-Dateien mehr. Durch die Verwendung von PNG-Dateien können die Szenen auf mehr Tablet-Modellen richtig angezeigt werden.

scene0/test_jitter.py

Der Test test_jitter wird in Android 12 auf physischen versteckten Kameras ausgeführt.

scene1_1/test_black_white.py

In Android 12 hat test_black_white die Funktionen von test_black_white und test_channel_saturation.

In der folgenden Tabelle werden die beiden einzelnen Tests in Android 11 beschrieben.

Test name	Erstes API-Level	Assertionen
scene1_1/test_black_white.py	ALLE	Kurze Belichtung, niedrige Verstärkung, RGB-Werte ~[0, 0, 0] Lange Belichtung, hohe Verstärkung, RGB-Werte ~[255, 255, 255]
scene1_1/test_channel_saturation.py	29	Reduzierte Toleranz bei Unterschieden von [255, 255, 255], um Farbstiche in weißen Bildern zu vermeiden.

In der folgenden Tabelle wird der zusammengeführte Test „scene1_1/test_black_white.py“ in Android 12 beschrieben.

Test name	Erstes API-Level	Assertionen
scene1_1/test_black_white.py	ALLE	Kurze Belichtung, niedrige Verstärkung, RGB-Werte ~[0, 0, 0] Lange Belichtung, hohe Verstärkung, RGB-Werte ~[255, 255, 255] und reduzierte Toleranz zwischen den Werten, um Farbstiche in weißen Bildern zu vermeiden.

scene1_1/test_burst_sameness_manual.py

Der Test test_burst_sameness_manual wird in Android 12 auf physischen versteckten Kameras ausgeführt.

scene1_2/test_tonemap_sequence.py

Der Test test_tonemap_sequence wird in Android 12 auf LIMITED-Kameras ausgeführt.

scene1_2/test_yuv_plus_raw.py

Der Test test_yuv_plus_raw wird in Android 12 auf physischen versteckten Kameras ausgeführt.

scene2_a/test_format_combos.py

Der Test test_format_combos wird in Android 12 auf LIMITED-Kameras ausgeführt.

scene3/test_flip_mirror.py

Der Test test_flip_mirror wird in Android 12 auf LIMITED-Kameras ausgeführt.

scene4/test_aspect_ratio_and_crop.py

Das Finden von Kreisen in scene4/test_aspect_ratio_and_crop.py wurde in Android 12 refaktoriert.

In früheren Android-Versionen wurde eine Methode verwendet, bei der eine untergeordnete Kontur (der Kreis) innerhalb der übergeordneten Kontur (das Quadrat) mit Filtern für Größe und Farbe gefunden wurde. In Android 12 wird eine Methode verwendet, bei der alle Konturen gefunden und dann nach Merkmalen gefiltert werden, die am kreisähnlichsten sind. Um falsche Kreise auf dem Display herauszufiltern, ist eine Mindestfläche für die Kontur erforderlich und die Kontur des Kreises muss schwarz sein.

Die Konturen und ihre Auswahlkriterien sind in der folgenden Abbildung dargestellt.

Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Abbildung 1 : Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Die Android 12-Methode ist einfacher und behebt das Problem mit dem Clipping von Begrenzungsrahmen auf einigen Tablets. Alle potenziellen Kreise werden zu Debugging-Zwecken protokolliert.

In Android 12 wird der Test zum Zuschneiden für FULL- und LEVEL3-Geräte ausgeführt. In Android 11 oder niedrigeren Versionen werden die Assertionen für den Test zum Zuschneiden für FULL-Geräte übersprungen.

In der folgenden Tabelle sind die Assertionen für test_aspect_ratio_and_crop.py aufgeführt, die einem bestimmten Gerätelevel und ersten API-Level entsprechen.

Gerätelevel	Erstes API-Level	Assertionen
LIMITED	ALLE	Seitenverhältnis Sichtfeld für die Formate 4:3, 16:9 und 2:1
FULL	< 31	Seitenverhältnis Sichtfeld für die Formate 4:3, 16:9 und 2:1
FULL	≥ 31	Zuschneiden Seitenverhältnis Sichtfeld für die Formate 4:3, 16:9 und 2:1
LEVEL3	ALLE	Zuschneiden Seitenverhältnis Sichtfeld für die Formate 4:3, 16:9 und 2:1

scene4/test_multi_camera_alignment.py

Die Methode undo_zoom() für YUV-Aufnahmen in scene4/test_multi_camera_alignment.py wurde refaktoriert, um das Zuschneiden auf Sensoren, die nicht dem Seitenverhältnis der Aufnahme entsprechen, genauer zu berücksichtigen.

Android 11 Python 2-Code

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

Android 12 Python 3-Code

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 wurde für den Sensorfusionstest eine Methode zum Erkennen von Merkmalen in Bildern hinzugefügt.

In Versionen vor Android 12 wird das gesamte Bild verwendet, um die besten 240 Merkmale zu finden, die dann auf die mittleren 20% maskiert werden, um Rolling-Shutter-Effekte zu vermeiden. Die Mindestanforderung beträgt 30 Merkmale.

Wenn die mit dieser Methode gefundenen Merkmale nicht ausreichen, maskiert Android 12 zuerst den Bereich für die Merkmalserkennung auf die mittleren 20% und begrenzt die maximale Anzahl der Merkmale auf das Doppelte der Mindestanforderung.

Die folgende Abbildung zeigt den Unterschied zwischen der Merkmalserkennung in Android 11 und Android 12. Wenn der Schwellenwert für die Mindestanforderung für Merkmale erhöht wird, werden Merkmale von schlechter Qualität erkannt und die Messungen werden negativ beeinflusst.

Unterschiede bei der Feature-Erkennung zwischen Android 11 und Android 12
sensor_fusion-Feature-Erkennung

Abbildung 2 : Unterschiede bei der Merkmalserkennung zwischen Android 11 und Android 12

Neue Tests

scene0/test_solid_color_test_pattern.py

Für Android 12 wurde ein neuer Test aktiviert: test_solid_color_test_pattern. Dieser Test ist für alle Kameras aktiviert und wird in der folgenden Tabelle beschrieben.

Szene	Test name	Erstes API-Level	Beschreibung
0	test_solid_color_test_pattern	31	Bestätigt die Ausgabe von Bildern mit einfarbigen Testmustern und die Programmierbarkeit der Bildfarbe.

Einfarbige Testmuster müssen aktiviert sein, um den Datenschutzmodus der Kamera zu unterstützen. Der Test test_solid_color_test_pattern bestätigt die Ausgabe von einfarbigen YUV-Bildern mit der durch das ausgewählte Muster definierten Farbe und die Änderung der Bildfarbe gemäß Spezifikation.

Parameter

cameraPrivacyModeSupport: Bestimmt, ob die Kamera den Datenschutzmodus unterstützt.
android.sensor.testPatternMode: Legt den Testmuster-Modus fest. In diesem Test wird SOLID_COLOR verwendet.
android.sensor.testPatternData: Legt die Testmusterwerte für R, Gr, Gb und G für den Testmuster-Modus fest.

Eine Beschreibung des einfarbigen Testmusters finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Methode

Für die festgelegten Parameter werden YUV-Frames aufgenommen und der Bildinhalt wird validiert. Das Testmuster wird direkt vom Bildsensor ausgegeben, daher ist keine bestimmte Szene erforderlich. Wenn PER_FRAME_CONTROL unterstützt wird, wird für jede getestete Einstellung ein einzelner YUV-Frame aufgenommen. Wenn PER_FRAME_CONTROL nicht unterstützt wird, werden vier Frames aufgenommen, wobei nur der letzte Frame analysiert wird, um die Testabdeckung auf LIMITED-Kameras zu maximieren.

Für YUV-Aufnahmen werden vollständig gesättigte Testmuster in BLACK, WHITE, RED, GREEN und BLUE verwendet. Da die Testmusterdefinition dem Bayer-Muster des Sensors entspricht, müssen die Farbkanäle für jede Farbe wie in der folgenden Tabelle gezeigt festgelegt werden.

Farbe	testPatternData (RGGB)
SCHWARZ	`(0, 0, 0, 0)`
WEISS	`(1, 1, 1, 1)`
Richtlinie 2014/53/EU	`(1, 0, 0, 0)`
GRÜN	`(0, 1, 1, 0)`
BLAU	`(0, 0, 0, 1)`

Assertionstabelle

In der folgenden Tabelle werden die Testassertionen für test_solid_color_test_pattern.py beschrieben.

Kamera Erstes API-Level	Kameratyp	Assertionen für Farben
31	Bayer	SCHWARZ, WEISS, ROT, GRÜN, BLAU
31	MONO	SCHWARZ, WEISS
< 31	Bayer/MONO	SCHWARZ

Tests für Leistungsklassen

scene2_c/test_camera_launch_perf_class.py

Prüft, ob der Kamerastart für die primären Front- und Rückkameras mit der Gesichtsszene „scene2_c“ weniger als 500 ms dauert.

scene2_c/test_jpeg_capture_perf_class.py

Prüft, ob die Latenz bei der JPEG-Aufnahme mit 1080p für die primären Front- und Rückkameras mit der Gesichtsszene „scene2_c“ weniger als 1 Sekunde beträgt.