Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Versionshinweise für die Android 12 Camera Image Test Suite
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Im Android 12-Release sind einige Änderungen an der ITS-Funktion für Kameras enthalten. Auf dieser Seite werden die Änderungen in vier Kategorien zusammengefasst:

Refactoring auf Python 3
Einführung des Mobly-Test-Frameworks
Änderungen testen
Neue Tests

Zu Python 3 umstellen

Aufgrund der Einstellung von Python 2.7 im Januar 2020 wurde der gesamte Codebestand der Kamera-ITS-Funktion auf Python 3 umgestellt. Die folgenden Python-Versionen und ‑Bibliotheken sind in Android 12 erforderlich:

Der Haupt-Test-Launcher, tools/run_all_tests.py, bleibt unverändert wie in den Versionen Android 11 oder niedriger und wird auf Python 3 umgestellt.

Alle einzelnen Tests werden neu strukturiert 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 jetzt für alle einzelnen Tests die entsprechenden Szenen geladen. Das Laden der Szene für jeden Test erhöht zwar die Gesamttestzeit, ermöglicht aber das Debuggen einzelner Tests.

Weitere Informationen zu einzelnen Teständerungen finden Sie unter Teständerungen.

Die folgenden Python-Module werden umstrukturiert 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

Einführung des Mobly-Test-Frameworks

Mobly ist ein Python-basiertes Testframework, das Testfälle unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwarekonfigurationen erforderlich sind. Camera ITS nutzt die Mobly-Testinfrastruktur, um eine bessere Kontrolle und Protokollierung der Tests zu ermöglichen.

Camera ITS nutzt die Mobly-Testinfrastruktur, um eine bessere Kontrolle und Protokollierung der Tests zu ermöglichen. Mobly ist ein Python-basiertes Test-Framework, das Testfälle unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwarekonfigurationen erforderlich sind. Weitere Informationen zu Mobly finden Sie unter google/mobly.

config.yml-Dateien

Mit dem Mobly-Framework können Sie ein Testgerät und ein Diagrammtablet in der Klasse its_base_test einrichten. Mit einer config.yml-Datei (YAML) wird ein Mobly-Testbed erstellt. In dieser Konfigurationsdatei können mehrere Testbeds konfiguriert werden, z. B. ein Tablet und ein Sensorfusions-Testbed. Im Controller-Abschnitt jedes Testbeds können Sie device_ids angeben, um dem Test-Runner die entsprechenden Android-Geräte zuzuweisen. Zusätzlich zu den Geräte-IDs werden in der Testklasse weitere Parameter wie „Tablet“ brightness, chart_distance, debug_mode, camera_id und scene_id übergeben. Gängige 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)

Tabletbasierte Tests

Bei tabletbasierten Tests muss das Keyword TABLET im Namen des Testbeds enthalten sein. Während der Initialisierung initialisiert der Mobly-Test-Runner TestParams und übergibt ihn an die einzelnen Tests.

Im Folgenden sehen Sie eine Beispiel-config.yml-Datei für tabletbasierte Läufe.

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

Der Testbed kann mit tools/run_all_tests.py aufgerufen werden. Wenn keine Befehlszeilenwerte vorhanden sind, werden die Tests mit den Werten aus der Datei config.yml ausgeführt. Außerdem können Sie die Werte der Konfigurationsdateien camera und scene in der Befehlszeile mit Befehlen überschreiben, die denen in Android 11 oder niedriger ä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 des Testbeds das Keyword SENSOR_FUSION enthalten. Das richtige Testsystem wird anhand der getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino- als auch Canakit-Controller für die Sensorfusion.

Im Folgenden finden Sie eine Beispiel-config.yml-Datei für Sensorfusionsläufe.

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 dem Sensorfusionstestgerät aus:

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

Mehrere Testbeds

In der Konfigurationsdatei können mehrere Testbeds enthalten sein. Die gängigste Kombination ist ein Tablet-Testfeld und ein Sensorfusions-Testfeld.

Im Folgenden finden Sie eine Beispieldatei vom Typ config.yml mit Testbeds für Tablet- und Sensorfusion.

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. Der Test muss jedoch im Testbed-Namen mit dem Keyword MANUAL gekennzeichnet sein. Außerdem darf die Testumgebung keine Tablet-ID enthalten.

Im Folgenden finden Sie eine Beispieldatei config.yml 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

Szenen ohne Tablets testen

Szene 0 und Szene 5 können mit TEST_BED_TABLET_SCENES oder TEST_BED_MANUAL getestet werden. Wenn die Tests jedoch mit TEST_BED_TABLET_SCENES durchgeführt werden, muss das Tablet angeschlossen und die Seriennummer des Tablets gültig sein, auch wenn das Tablet nicht verwendet wird, da die Seriennummer in der Testklasseneinrichtung dem Tablet zugewiesen wird.

Einzelne Tests ausführen

Einzelne Tests können nur zu Debugzwecken ausgeführt werden, da ihre Ergebnisse nicht an den CTS Verifier gesendet werden. Da die config.yml-Dateien für camera und scene nicht in der Befehlszeile überschrieben werden können, müssen diese Parameter in der config.yml-Datei für den jeweiligen Test korrekt sein. Wenn sich in der Konfigurationsdatei mehrere Testbeds befinden, müssen Sie den Testbed 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

Unter Android 12 werden Testartefakte für die Kamera-ITS ähnlich wie unter Android 11 oder niedriger gespeichert, jedoch mit den folgenden Änderungen:

Dem zufälligen String aus acht Zeichen im Testartefaktverzeichnis /tmp wird zur besseren Übersicht CameraITS_ vorangestellt.
Testausgabe und Fehler werden für jeden Test in test_log.DEBUG anstatt in test_name_stdout.txt und test_name_stderr.txt gespeichert.
Die Logcats des DUT und des Tablets aus jedem einzelnen Test werden im Verzeichnis /tmp/CameraITS_######## gespeichert. Das vereinfacht die Fehlerbehebung, da alle Informationen, die zur Behebung von 3A-Problemen erforderlich sind, protokolliert werden.

Änderungen testen

Unter Android 12 sind die Tablet-Szenen PNG-Dateien und keine PDF-Dateien. Durch die Verwendung von PNG-Dateien können die Szenen auf mehr Tablet-Modellen korrekt dargestellt werden.

scene0/test_jitter.py

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

scene1_1/test_black_white.py

Unter Android 12 hat test_black_white sowohl die Funktionen von test_black_white als auch von test_channel_saturation.

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

Test name	Erste API-Ebene	Behauptungen
scene1_1/test_black_white.py	ALLE	Kurze Belichtung, geringe Verstärkung: RGB-Werte etwa [0, 0, 0] Lange Belichtung, hohe Verstärkung: RGB-Werte etwa [255, 255, 255]
scene1_1/test_channel_saturation.py	29	Die Toleranz bei Abweichungen von [255, 255, 255] wurde reduziert, um Farbstiche in weißen Bildern zu entfernen.

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

Test name	Erste API-Ebene	Behauptungen
scene1_1/test_black_white.py	ALLE	Kurze Belichtung, niedrige Verstärkung, RGB-Werte von etwa [0, 0, 0] Lange Belichtung, hohe Verstärkung, RGB-Werte von etwa [255, 255, 255] und reduzierte Toleranz zwischen den Werten, um Farbton in weißen Bildern zu entfernen.

scene1_1/test_burst_sameness_manual.py

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

scene1_2/test_tonemap_sequence.py

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

scene1_2/test_yuv_plus_raw.py

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

scene2_a/test_format_combos.py

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

scene3/test_flip_mirror.py

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

scene4/test_aspect_ratio_and_crop.py

Die Suche nach Gruppen in scene4/test_aspect_ratio_and_crop.py wurde in Android 12 neu strukturiert.

Bei früheren Android-Versionen wurde eine Methode verwendet, bei der eine untergeordnete Kontur (der Kreis) innerhalb der übergeordneten Kontur (das Quadrat) mithilfe von Filtern für Größe und Farbe gefunden wurde. Android 12 verwendet eine Methode, bei der alle Konturen ermittelt und dann nach den Elementen gefiltert werden, die am kreisförmigsten sind. Um unerwünschte Kreise auf dem Display herauszufiltern, ist ein Mindestkonturbereich 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 Methode für Android 12 ist einfacher und behebt das Problem mit dem Zuschneiden des Begrenzungsrahmens auf einigen Display-Tablets. Alle Kreiskandidaten werden zu Debug-Zwecken protokolliert.

Unter Android 12 wird der Zuschneidetest für FULL- und LEVEL3-Geräte ausgeführt. Bei Android 11 oder niedriger werden die Testaussagen für den Zuschnitt für FULL-Geräte übersprungen.

In der folgenden Tabelle sind die Behauptungen für test_aspect_ratio_and_crop.py aufgeführt, die einer bestimmten Geräteebene und der ersten API-Ebene entsprechen.

Geräteebene	Erste API-Ebene	Behauptungen
EINGESCHRENKTER STATUS	ALLE	Seitenverhältnis Bildwinkel für 4:3-, 16:9- und 2:1-Formate
VOLLSTÄNDIG	Unter 31	Seitenverhältnis Bildwinkel für 4:3-, 16:9- und 2:1-Formate
VOLLSTÄNDIG	≥ 31	Zuschneiden Seitenverhältnis Bildwinkel für 4:3-, 16:9- und 2:1-Formate
LEVEL3	ALLE	Zuschneiden Seitenverhältnis Bildwinkel für 4:3-, 16:9- und 2:1-Formate

scene4/test_multi_camera_alignment.py

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

Python 2-Code für 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

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

In Versionen niedriger als Android 12 wird das gesamte Bild verwendet, um die besten 240 Features zu finden, die dann auf die zentralen 20% maskiert werden, um Rolling-Shutter-Effekte zu vermeiden. Die Mindestanzahl der Features beträgt 30.

Wenn die mit dieser Methode gefundenen Funktionen nicht ausreichen, maskiert Android 12 zuerst die Mitte des Bereichs für die Funktionserkennung zu 20% und begrenzt die maximale Anzahl der Funktionen auf das Doppelte der Mindestanzahl.

Das folgende Bild zeigt den Unterschied zwischen der Funktion „Funktionserkennung“ in Android 11 und Android 12. Wenn Sie den Mindestgrenzwert für die Anforderungen an Funktionen erhöhen, werden Funktionen von geringer Qualität erkannt und die Messungen werden negativ beeinflusst.

Unterschied bei der Feature-Erkennung zwischen Android 11 und Android 12

Sensorfusion

Abbildung 2: Unterschied bei der Funktionserkennung zwischen Android 11 und Android 12

Neue Tests

scene0/test_solid_color_test_pattern.py

Der neue Test test_solid_color_test_pattern ist für Android 12 aktiviert. Dieser Test ist für alle Kameras aktiviert und wird in der folgenden Tabelle beschrieben.

Szene	Test name	Erste API-Ebene	Beschreibung
0	test_solid_color_test_pattern	31	Prüft, ob die Ausgabe eines einfarbigen Bilds und die Programmierbarkeit der Bildfarbe möglich sind.

Testmuster mit durchgehender Farbe müssen aktiviert sein, damit der Vertraulichkeitsmodus der Kamera unterstützt wird. Beim test_solid_color_test_pattern-Test wird die YUV-Bildausgabe mit durch das ausgewählte Muster definierte Farbe bestätigt und die Bildfarbe ändert sich gemäß den Spezifikationen.

Parameter

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

Eine Beschreibung des Testmusters mit durchgehender Farbe finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Method

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

YUV-Aufnahmen sind auf die vollständig gesättigten Testmuster BLACK, WHITE, RED, GREEN und BLUE eingestellt. 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)`
WEIẞ	`(1, 1, 1, 1)`
Richtlinie 2014/53/EU	`(1, 0, 0, 0)`
GRÜN	`(0, 1, 1, 0)`
BLAU	`(0, 0, 0, 1)`

Tabelle mit Behauptungen

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

Kamera Erste API-Ebene	Kameratyp	Angewendete Farben
31	Bayer	SCHWARZ, WEISS, ROT, GRÜN, BLAU
31	MONO	SCHWARZ, WEISS
Unter 31	Bayer/MONO	SCHWARZ

Leistungstests für Klassen

scene2_c/test_camera_launch_perf_class.py

Prüft, ob das Starten der Kamera sowohl für die primäre Front- als auch Rückkamera weniger als 500 ms dauert, wenn sich die Szene „scene2_c“ (Gesicht) auf dem Display befindet.

scene2_c/test_jpeg_capture_perf_class.py

Prüft, ob die Latenz bei der Aufnahme von 1080p-JPEG-Bildern sowohl mit der primären Front- als auch der primären Rückkamera unter 1 Sekunde liegt. Dabei wird die Szene „scene2_c“ verwendet.