Camera ITS – Übersicht

Die Camera Image Test Suite (ITS) ist ein Framework zum Ausführen von Tests für Bilder, die mit einer Android-Kamera aufgenommen wurden. Das allgemeine Ziel jedes Tests in ITS besteht darin, die Kamera auf eine bestimmte Weise zu konfigurieren, ein oder mehrere Fotos aufzunehmen und die Fotos zu prüfen, um festzustellen, ob sie die erwarteten Bilddaten enthalten. Bei vielen Tests muss die Kamera auf ein bestimmtes Testbild gerichtet oder mit einer bestimmten Intensität beleuchtet werden.

ITS befindet sich in der CTS Verifier-Testumgebung unter cts/apps/CameraITS. Geräte müssen die ITS-Tests bestehen, die den von der Kamera-Framework für Drittanbieter-Apps beworbenen unterstützten Funktionen entsprechen. Diese Tests sind eine Teilmenge von CTS.

Einrichtung

Für die Ausführung von ITS-Tests muss Folgendes eingerichtet sein:

  • Ein zu testendes Gerät (device under test, DUT)
  • Ein Hostcomputer (z. B. ein Linux-Desktop oder -Laptop)
  • Eine Szene, die von der Kamera fotografiert wird

Einrichtung des zu testenden Geräts (DUT)

So richten Sie ein DUT ein:

  1. Verbinden Sie das DUT über USB mit einem Hostcomputer.
  2. Konfigurieren Sie die Entwickleroptionen auf dem DUT:
    • Aktivieren Sie Display aktiv lassen und USB-Debugging.
    • Deaktivieren Sie Automatische Systemupdates und Apps über USB überprüfen.
  3. Gewähren Sie dem Host Berechtigungen für den Zugriff auf das DUT über ADB.

  4. Installieren Sie die CTS Verifier App (CtsVerifier.apk) auf dem Gerät. Weitere Informationen finden Sie unter CTS Verifier verwenden.

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

  5. Starten Sie auf dem DUT die Standardkamera-App und schließen Sie alle Fenster, die beim Start angezeigt werden, um Störungen während des Tests zu vermeiden.

Host einrichten

Für ITS muss der Hostcomputer über USB mit dem DUT verbunden sein, ADB für die Gerätesteuerung und -kommunikation verwenden können und die erforderliche Software installiert haben.

Achten Sie darauf, dass die folgende Software auf dem Hostcomputer installiert ist.

Android SDK Platform Tools

Die Android SDK Platform Tools müssen installiert sein und ADB muss sich im ausführbaren Pfad der Shell oder des Terminals befinden, die auf dem Hostcomputer ausgeführt werden. Die öffentlich veröffentlichte Version der Android SDK Platform Tools finden Sie in den Versionshinweisen zu den SDK Platform Tools. siehe Versionshinweise zu den SDK Platform Tools.

Python

Python muss auf dem Hostcomputer installiert sein. Wir empfehlen, eine gebündelte Python-Distribution zu verwenden, um die Unterstützung für kompatible Versionen sicherzustellen. Details zu den Python- und Paketversionen, die für einen bestimmten Release installiert werden müssen, finden Sie in den Versionshinweisen zu Camera ITS für den entsprechenden Release.

Mobly

Installieren Sie für Android 12 und höher das Mobly-Test-Framework. Mit Mobly können Sie ein DUT und ein Testbild-Tablet in der Klasse its_base_test einrichten. Führen Sie Folgendes aus, um das Mobly-Test-Framework zu installieren:

pip install mobly

Umgebung einrichten

Führen Sie Folgendes aus, um die Testumgebung einzurichten:

cd CameraITS
source build/envsetup.sh

Mit diesem Befehl wird die Python-Installation geprüft, die Umgebungsvariable PYTHONPATH eingerichtet und Einheitentests für die Module utils/*.py ausgeführt. Wenn keine Fehler im Terminal ausgegeben werden, ist die Umgebung bereit für die Ausführung der ITS-Tests.

Szene einrichten

Für die Einrichtung der Szenen empfehlen wir die Verwendung des Camera ITS-in-a-box-Setups, um die Automatisierung, Zuverlässigkeit und Effizienz beim Testen zu verbessern. Die ITS-in-a-box-Testaufbauten erfüllen alle Anforderungen an Beleuchtung, Zentrierung und Testbildwechsel für ITS. Außerdem ist ITS-in-a-box für das Testen von Kameraerweiterungen erforderlich.

Achten Sie bei manuellen Tests auf Folgendes:

  • Das DUT befindet sich auf einem Stativ.
  • Das DUT ist für jeden Test auf die richtige Szene gerichtet. Die ITS-Testanleitung enthält Aufforderungen, die Szene vor dem Starten von Tests in einer neuen Szene zu ändern.
  • Das DUT ist über USB mit dem Hostcomputer verbunden.
  • Das DUT bewegt sich während des Testlaufs nicht.
  • Die Szene wird mit einer gleichmäßigen, nicht flackernden Lichtquelle beleuchtet. Verwenden Sie keine Leuchtstofflampe, da diese zu Flimmern führt.

Das ITS-Testskript zeigt eine Aufforderung an, die Szene zu ändern, bevor Tests in einer neuen Szene gestartet werden.

Die Ausrichtung des Smartphones muss so eingestellt sein, dass die Kamera Bilder ohne Drehung aufnimmt. Am einfachsten lässt sich dies mit den Gesichtsszenen in Szene 2 überprüfen. Bei den meisten Smartphones ist das Smartphone im Querformat ausgerichtet und für die Rückkamera gegen den Uhrzeigersinn und für die Frontkamera im Uhrzeigersinn gedreht.

Führen Sie tools/check_alignment.py aus, um die Ausrichtung des DUT und des Testbilds zu prüfen. Dadurch werden die X- und Y-Koordinaten für die Mitte des Testbilds im Vergleich zur Mitte des Bilds ausgegeben und ein aufgenommenes Bild mit den beiden Mittelpunkten für eine optimale Ausrichtung versehen.

Konfigurationsdateien

Mit dem Mobly-Framework müssen Sie eine config.yml-Konfigurationsdatei erstellen, um die Mobly-Testumgebung zu definieren. Im Folgenden finden Sie Beispiele für verschiedene Anwendungsfälle.

`config.yml`-Datei für tabletbasierte Szenen

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei für tabletbasierte Szenen. Für tabletbasierte Tests muss das Keyword TABLET im Namen der Testumgebung enthalten sein. Während der Initialisierung initialisiert der Mobly-Testrunner die Parameter in der Datei und übergibt sie an die einzelnen 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"  # "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

Führen Sie tools/run_all_tests.py aus, um die Testumgebung aufzurufen. Wenn keine Befehlszeilenwerte für Kameras oder Szenen angegeben sind, wird der Test mit den Werten aus der Datei config.yml ausgeführt. Wenn Befehlszeilenwerte für Kameras oder Szenen vorhanden sind, überschreiben diese die Werte im Abschnitt TestParams der Datei config.yml. 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=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

Parameter `chart_scaling`

In Android 17 und höher ist der Parameter chart_scaling in config.yml für TEST_BED_TABLET_SCENES enthalten. Dieser Parameter behebt Probleme mit der Testbildskalierung für Geräte mit Telekamera und einem größeren Sichtfeld. So wird verhindert, dass Szenen abgeschnitten werden, und der Fokus des Geräts wird während des Tests richtig eingestellt.

Unterstützte Werte für chart_scaling sind 1, 0.33, 0.5 oder 0.67, wobei None die Standardeinstellung ist. Mit diesem Ansatz können Geräte einen optimalen Skalierungsfaktor verwenden, der auf ihre spezifischen Anforderungen zugeschnitten ist. So werden Funktionstests auf allen Geräten durchgeführt.

Wenn chart_scaling auf None gesetzt ist, wird der Skalierungsfaktor automatisch mit chart_scaling_logic ermittelt. Andernfalls wird der in config.yml angegebene Wert verwendet oder ein Fehler gemeldet, wenn die Skalierung nicht verfügbar ist.

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei mit dem Parameter 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

Auf Testseite sind Anpassungen erforderlich, um die Funktionen zur Testbildskalierung von Camera ITS zu aktivieren. Wenn ein von Ihnen verwendeter Test dies nicht unterstützt, melden Sie einen Fehler.

Im Folgenden finden Sie ein Beispiel für eine Änderung auf Testseite mit dem Parameter 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)

`config.yml`-Datei für die Szene `sensor_fusion`

Im Folgenden finden Sie ein Beispiel für eine config_yml-Datei für sensor_fusion-Tests. Für sensor_fusion-Tests muss das Keyword SENSOR_FUSION im Namen der Testumgebung enthalten sein. Android 13 und höher unterstützen aufgrund von Tests zur Vorschau und Videostabilisierung nur den Arduino-Controller für die Sensorfusion. Android 12 unterstützt Arduino- und Canakit-Controller.

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

Führen Sie Folgendes aus, um sensor_fusion Tests mit der Sensorfusionsbox auszuführen:

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

`config.yml`-Datei für mehrere Testumgebungen

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei mit mehreren Testumgebungen, einer Tablet-Testumgebung und einer sensor_fusion-Testumgebung. Die richtige Testumgebung wird durch die getesteten Szenen bestimmt.

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

`config.yml`-Datei für manuelle Tests

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei für manuelle Tests. Android 14 und höher unterstützt manuelle Tests für alle Tests mit Ausnahme der scene_extensions Tests. Für manuelle Tests muss das Keyword MANUAL im Namen der Testumgebung enthalten sein. Außerdem darf der Abschnitt AndroidDevice keinen Abschnitt für die Seriennummer oder das Label eines Tablets enthalten.

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

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

`config.yml`-Datei für Tests mit Gen2-Testaufbau

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei einer TEST_BED_GEN2-Testumgebung. Verwenden Sie diese Testumgebung für scene_ip Tests, bei denen ein Gen2-Testaufbau verwendet wird. Im folgenden Beispiel werden die Parameter der Testumgebung angezeigt, wenn der Gen2-Testaufbau verfügbar ist und die scene_ip Tests nicht übersprungen werden.

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

Im folgenden Beispiel werden die Parameter der Testumgebung angezeigt, wenn der Gen2-Testaufbau nicht verfügbar ist und die scene_ip-Tests übersprungen werden.

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

Verwenden Sie einen der folgenden Befehle, um den `scene_ip`-Test auszuführen:

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

ITS-Tests ausführen

In diesem Abschnitt wird beschrieben, wie Sie ITS-Tests ausführen.

Tests aufrufen

Nachdem das Gerät, der Hostcomputer (einschließlich Umgebung) und die physische Szene eingerichtet wurden, führen Sie die ITS-Tests mit dem folgenden Verfahren aus.

  1. Öffnen Sie die CTS Verifier App. Wählen Sie im Menü „Tests“ die Option Camera ITS Test aus. In Android 17 und höher befinden sich die Tests sensor_fusion und feature_combination in einer zusätzlichen Aktivität namens Camera ITS Sensor Fusion Rig Test.

  2. Führen Sie die ITS-Tests auf dem Hostcomputer aus dem Verzeichnis CameraITS/ aus. Führen Sie beispielsweise für ein Gerät mit Front- und Rückkamera den folgenden Befehl aus:

    python tools/run_all_tests.py

    Das Skript durchläuft Kameras und Testszenen basierend auf der Datei config.yml. Für Debugging-Setups empfehlen wir, eine der scene2-Szenen mit einem einzelnen Test auszuführen, um die schnellste Bearbeitungszeit zu erzielen.

    Bei manuellen Tests nimmt das Skript vor dem Starten der ITS-Tests für jede Szene ein Bild der aktuellen Szene auf, speichert es als JPEG, gibt den Pfad zum JPEG in der Konsole aus und fordert den Nutzer auf, zu bestätigen, ob das Bild in Ordnung ist. Dieser Ablauf Aufnehmen und bestätigen wird wiederholt, bis der Nutzer bestätigt, dass das Bild in Ordnung ist. Im Folgenden finden Sie die Meldungen in diesem Ablauf.

    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)

    Bei jeder Ausführung des Skripts wird ein Log ausgegeben, in dem für jeden ITS-Test entweder PASS, FAIL, FAIL* oder SKIP angezeigt wird. FAIL* bedeutet, dass der Test fehlgeschlagen ist. Da der Test jedoch noch nicht vorgeschrieben ist, wird er in CtsVerifier als PASS gemeldet. SKIP bedeutet, dass der Test bestanden wurde, weil das Gerät die getestete zugrunde liegende Funktion nicht beworben hat. Wenn ein Gerät beispielsweise über die Kameraschnittstellen nicht bewirbt, dass es DNG unterstützt, werden Tests im Zusammenhang mit der Aufnahme von DNG-Dateien übersprungen und als PASS gezählt.

  3. Tippen Sie auf die grüne Häkchenschaltfläche, um zu bestätigen, dass die Tests die Testanforderungen erfüllt haben. Der Eintrag Camera ITS Test im Menü „Tests“ von CTS Verifier wird dann grün und zeigt an, dass das Smartphone den Camera ITS-Test bestanden hat.

Testzeit verkürzen

Camera ITS unterstützt mehrere Funktionen, um die Gesamtausführungszeit von Tests auf verschiedenen Geräten und in verschiedenen Szenen zu optimieren und zu verkürzen.

Tests mit Unterkameras

Bei Geräten mit Mehrkamerasystemen, die die Mehrkamera-API verwenden, wird für physische Unterkameras eine gezielte Teilmenge der gesamten Testsuite ausgeführt, wie in der folgenden Tabelle dargestellt:

Szene Tests mit Unterkameras
scene0 test_jitter, test_solid_color_test_pattern
scene1_1 test_burst_sameness_manual, test_dng_noise_model, test_exposure, test_linearity
scene1_2 test_raw_exposure, test_raw_sensitivity, test_yuv_plus_raw
scene2_a test_faces, test_num_faces
scene3 test_flip_mirror
scene4 test_aspect_ratio_and_crop
sensor_fusion test_sensor_fusion

Parallele Tests mit DUTs

Geräte mit Android 14 oder höher unterstützen parallele Tests mit DUTs. So können Sie DUTs parallel mit mehreren Testaufbauten testen, um die Gesamttestzeit zu verkürzen. Bei parallelen Tests können Sie beispielsweise Kamera 0 in einem Testaufbau und Kamera 1 in einem anderen Testaufbau gleichzeitig testen. In Android 17 und höher sind Camera ITS-Tests in zwei Aktivitäten unterteilt. So können Sie sensor_fusion- und feature_combination-Tests auf einem DUT und andere Tests parallel auf einem anderen DUT ausführen. Alle Tests für parallele Testsitzungen werden in der CTS Verifier-Sitzung auf dem Referenz-DUT zusammengefasst. Sie müssen parallele Tests mit der Arduino-Lichtsteuerung ausführen, da die manuelle Lichtsteuerung bei parallelen Tests nicht unterstützt wird. Achten Sie darauf, dass die Beleuchtung für jeden Testaufbau über einen anderen Kanal auf demselben Arduino-Controller gesteuert wird.

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei, in der drei Testumgebungen definiert sind, die parallel ausgeführt werden sollen.

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"

Verwenden Sie den folgenden Befehl, um die Testumgebungen parallel auszuführen:

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

Aggregierte Testergebnisse einreichen

In Android 17 und höher können Sie aggregierte Camera ITS-Testergebnisse zur Build-Genehmigung einreichen. Mit CTS Verifier können Sie mehrere Szenen gleichzeitig auf mehreren Geräten testen und Testergebnisse aus mehreren CTS Verifier-Berichten (aus verschiedenen Testläufen oder Geräten) in einer einzigen, einheitlichen Einreichung zusammenfassen.

Einreichungsverfahren

So reichen Sie aggregierte Camera ITS-Ergebnisse zur Build-Genehmigung ein:

  1. Geräte vorbereiten:Sammeln Sie zwei bis drei zu testende Geräte (DUTs), die alle genau denselben Build-Fingerabdruck haben.
  2. CTS Verifier installieren:Installieren Sie die neueste CTS Verifier APK, die Sie im bereitgestellten Build-Explorer erhalten.

  3. Tests parallel ausführen :

    1. Bringen Sie die DUTs in separaten Testaufbauten an.
    2. Führen Sie verschiedene Camera ITS-Szenen gleichzeitig auf jedem Gerät aus.
    3. Sammlung „Berichte“:Rufen Sie nach jeder Ausführung den CTS Verifier-Bericht ab. Dazu gehören auch Berichte, bei denen Szenen fehlgeschlagen sind. Führen Sie die fehlgeschlagenen Szenen nur bei nachfolgenden Ausführungen noch einmal aus.

  4. Berichte einreichen:Laden Sie mehrere CTS Verifier-Berichte hoch, die von allen Geräten erfasst wurden.

  5. Ergebnisse überprüfen:Nachdem die Berichte hochgeladen wurden, überprüfen Sie die aggregierten Ergebnisse:

    • Im Abschnitt Testanalyse finden Sie eine vollständige Liste aller ausgeführten Szenen.

    • Nicht ausgeführte oder fehlgeschlagene Szenen werden im Abschnitt Fehlgeschlagen aufgeführt.

      result-aggregation-image-1

      Abbildung 1 : Dokumentation von Szenen, die nicht ausgeführt wurden oder fehlgeschlagen sind.

    • Bestandene Szenen werden im Abschnitt Aggregiert bestanden aufgeführt.

      result-aggregation-image-2

      Abbildung 2 : Szenen, die als „Aggregiert bestanden“ kategorisiert wurden

Freigabestatus des Builds

Die Build-Genehmigung wird erteilt, sobald alle erforderlichen Szenen in den aggregierten Berichten erfolgreich abgeschlossen wurden.

DNG-Rauschmodell

Geräte, die die Möglichkeit zur Aufnahme von RAW- oder DNG-Dateien bewerben, müssen in den Metadaten der Aufnahmeergebnisse jeder RAW-Aufnahme ein Rauschmodell bereitstellen. Dieses Rauschmodell muss für jede Kamera (z. B. Front- und Rückkamera) auf dem Gerät, das Unterstützung beansprucht, in die Kamera-HAL eingebettet sein.

Implementierung des Rauschmodells

Führen Sie die folgenden Schritte aus, um ein Rauschmodell zu implementieren, ein Rauschmodell zu generieren und das Modell in die Kamera-HAL einzubetten.

  1. Führen Sie das dng_noise_model.py Skript im tools Verzeichnis aus, um ein Rauschmodell für jede Kamera zu generieren. Dadurch wird ein C-Code-Snippet ausgegeben. Weitere Informationen zum Einrichten der Kamera und der Aufnahmeumgebung finden Sie im Dokument DngNoiseModel.pdf im Verzeichnis tools.

  2. Um das Rauschmodell für das Gerät zu implementieren, schneiden Sie das C-Code-Snippet aus und fügen Sie es in die Kamera-HAL ein.

Validierung des Rauschmodells

Der tests/scene1_1/test_dng_noise_model.py automatisierte ITS-Test validiert das Rauschmodell, indem er prüft, ob die Rauschwerte für die Aufnahmebelichtung und -verstärkung, die in den Kameradaten angegeben sind, korrekt sind.

Tests, die knapp bestanden wurden (Teststatus „PASS*“)

In Android 17 und höher bedeutet ein knapp bestanden (PASS*), dass ein Test bestanden wurde, die Leistungsmesswerte jedoch sehr nahe am vordefinierten Schwellenwert für das Bestehen liegen. Obwohl der Test die Kriterien für das Bestehen technisch erfüllt, deutet die Nähe zur Grenze für das Nichtbestehen darauf hin, dass eine genauere Prüfung erforderlich ist.

Vorteile von „knapp bestanden“

Der Status PASS* bietet mehrere Vorteile:

  • Frühwarnsystem: Identifiziert Tests, die kurz vor dem Scheitern stehen, sodass Teams Probleme beheben können, bevor sie zu vollständigen Fehlern führen.

  • Proaktive Optimierung: Fordert Teams auf, Tests und Code zu optimieren, die am unteren Ende des akzeptablen Bereichs liegen, um die Gesamtstabilität zu verbessern.

  • Verbesserte Qualität: Trägt dazu bei, einen höheren Qualitätsstandard aufrechtzuerhalten, indem Bereiche gekennzeichnet werden, die bei geringfügigen Codeänderungen anfällig für zukünftige Regressionen sein könnten.

  • Verkürzte Debugging-Zeit: Wenn PASS*-Tests frühzeitig erkannt werden, können der Zeit- und Arbeitsaufwand für das Debugging vollständiger Fehler in der Zukunft erheblich reduziert werden.

Details zu „PASS*“

Der Status PASS* umfasst Folgendes:

  • Schwellenwerte definieren: Für jeden relevanten Test in Camera ITS werden spezifische Schwellenwerte für „knapp bestanden“ definiert.

  • Automatisierte Erkennung: Das Testautomatisierungssystem erkennt und kategorisiert Tests basierend auf den definierten Schwellenwerten als PASS*.

  • Benachrichtigungsmechanismus: Teams erhalten automatische Benachrichtigungen für alle Tests, die als PASS* gekennzeichnet sind, und werden aufgefordert, den jeweiligen Test und seine Messwerte zu untersuchen.

  • Berichterstellung: Status für „knapp bestanden“ werden in Testberichten und Dashboards deutlich als PASS* im Bericht ItsTestSummary angegeben, ähnlich wie Fail* für not_yet_mandated-Tests. Der Test behält den grünen Status bei, da er weiterhin innerhalb der festgelegten Schwellenwerte bestanden wird, um weitere Verwirrung zu vermeiden. Der Status PASS* gilt nur für eine Testklasse, nicht für die gesamte Szene. Beispielsweise kann Scene_0 als PASS betrachtet werden, auch wenn test_jitter und test_metadata PASS* sind.

  • Monitoring: Für Tests, die auf einem Gerät knapp bestanden wurden, werden Leistungsdaten erfasst. So können zukünftige Kameraverbesserungen von OEMs beobachtet werden, wenn diese Tests den Status PASS erhalten.

Im Folgenden finden Sie ein Beispiel für Testergebnisse mit 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'}}

Partner werden aufgefordert, Folgendes zu tun:

  • PASS*-Benachrichtigungen beobachten
  • Die Ursache von PASS*-Tests untersuchen
  • Tests und Code, die als PASS* identifiziert wurden, proaktiv optimieren

Der Status PASS* soll die Robustheit und Zuverlässigkeit von Camera ITS-Tests verbessern und zu einem stabilen und hochwertigen Produkt führen.