Unterstützung der Kameraversion

Auf dieser Seite werden die Versionsunterschiede bei Camera HALs, APIs und zugehörigen Compatibility Test Suite (CTS)-Tests beschrieben. Außerdem werden mehrere architektonische Änderungen behandelt, die vorgenommen wurden, um das Kamera-Framework in Android 7.0 zu härten und zu schützen, die Umstellung auf Treble in Android 8.0 und die Updates, die Anbieter vornehmen müssen, um diese Änderungen in ihren Kameraimplementierungen zu unterstützen.

Terminologie

Auf dieser Seite werden die folgenden Begriffe verwendet:

Camera API1
Das Kamera-Framework auf App-Ebene auf Geräten mit Android 4.4 und niedriger, das über die Klasse android.hardware.Camera verfügbar ist.
Camera API2
Das Kamera-Framework auf App-Ebene auf Geräten mit Android 5.0 und höher, das über das Paket android.hardware.camera2bereitgestellt wird.
Kamera-HAL
Die vom SoC-Anbieter implementierte Kameramodulschicht. Die öffentlichen Frameworks auf App-Ebene basieren auf der Kamera-HAL.
Camera HAL3.1
Version des Kamera-Geräte-HAL, das mit Android 4.4 veröffentlicht wurde.
Camera HAL3.2
Version des Kamera-Geräte-HAL, das mit Android 5.0 veröffentlicht wurde.
Camera API1 CTS
Eine Reihe von CTS-Tests für die Kamera, die auf der Camera API1 ausgeführt werden.
Camera API2 CTS
Zusätzliche CTS-Kameratests, die zusätzlich zur Camera API2 ausgeführt werden.
Höhen
Trennt die Anbieterimplementierung (gerätespezifische Software auf niedriger Ebene, die von Chipherstellern geschrieben wurde) durch eine neue Anbieterschnittstelle vom Android-Betriebssystem-Framework.
HIDL
HAL-Schnittstellendefinitionssprache: Diese Sprache wurde mit Treble eingeführt und wird verwendet, um die Schnittstelle zwischen einer HAL und ihren Nutzern zu definieren.
VTS
Die Vendor Test Suite wurde zusammen mit Treble eingeführt.

Kamera-APIs

Android umfasst die folgenden Kamera-APIs.

Camera API1

In Android 5.0 wurde die Camera API1 eingestellt. Sie wird weiterhin auslaufen, da sich die Entwicklung neuer Plattformen auf die Camera API2 konzentriert. Die Übergangsphase wird jedoch lang sein und Android-Releases werden Camera API1-Apps noch einige Zeit unterstützen. Konkret wird weiterhin Folgendes unterstützt:

  • Camera API1-Schnittstellen für Apps: Kamera-Apps, die auf Camera API1 basieren, sollten wie auf Geräten mit niedrigeren Android-Versionen funktionieren.
  • Camera HAL-Versionen: Unterstützung für Camera HAL1.0 ist enthalten.

Camera API2

Das Camera API2-Framework bietet der App eine Kamera-Steuerung auf niedrigerer Ebene, einschließlich effizienter Burst-/Streaming-Abläufe ohne Kopieren und Steuerelemente für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung und Schärfen pro Frame. Weitere Informationen finden Sie im Google I/O-Video.

Android 5.0 und höher umfasst die Camera API2. Geräte mit Android 5.0 und höher unterstützen jedoch möglicherweise nicht alle Camera API2-Funktionen. Die Eigenschaft android.info.supportedHardwareLevel, die Apps über die Camera API2-Schnittstellen abfragen können, gibt einen der folgenden Unterstützungsgrade an:

  • LEGACY: Diese Geräte stellen Apps Funktionen über die Camera API2-Schnittstellen zur Verfügung, die ungefähr den Funktionen entsprechen, die Apps über die Camera API1-Schnittstellen zur Verfügung gestellt werden. Bei den Legacy-Frameworks werden Camera API2-Aufrufe konzeptionell in Camera API1-Aufrufe übersetzt. Legacy-Geräte unterstützen keine Camera API2-Funktionen wie die Steuerung pro Frame.
  • LIMITED: Diese Geräte unterstützen einige (aber nicht alle) Camera API2-Funktionen und müssen Camera HAL 3.2 oder höher verwenden.
  • FULL: Diese Geräte unterstützen alle wichtigen Funktionen von Camera API2 und müssen Camera HAL 3.2 oder höher und Android 5.0 oder höher verwenden.
  • LEVEL_3: Diese Geräte unterstützen die YUV-Nachbearbeitung und die Aufnahme von RAW-Bildern sowie zusätzliche Konfigurationen für Ausgabestreams.
  • EXTERNAL: Diese Geräte ähneln LIMITED-Geräten, es gibt jedoch einige Ausnahmen. So werden beispielsweise einige Sensor- oder Objektivinformationen möglicherweise nicht gemeldet oder haben weniger stabile Frameraten. Diese Stufe wird für externe Kameras wie USB-Webcams verwendet.

Einzelne Funktionen werden über das Attribut android.request.availableCapabilities in den Camera API2-Schnittstellen bereitgestellt. FULL-Geräte erfordern unter anderem die Funktionen MANUAL_SENSOR und MANUAL_POST_PROCESSING. Die RAW-Funktion ist auch für FULL-Geräte optional. LIMITED-Geräte können eine beliebige Teilmenge dieser Funktionen bewerben, auch keine. Die BACKWARD_COMPATIBLE-Funktion muss jedoch immer definiert sein.

Der unterstützte Hardware-Level des Geräts sowie die spezifischen Camera API2-Funktionen, die es unterstützt, sind als die folgenden Feature-Flags verfügbar, um das Filtern von Camera API2-Kamera-Apps in Google Play zu ermöglichen.

  • android.hardware.camera.hardware_level.full
  • android.hardware.camera.capability.raw
  • android.hardware.camera.capability.manual_sensor
  • android.hardware.camera.capability.manual_post_processing

CTS-Anforderungen

Geräte mit Android 5.0 und höher müssen die Camera API1 CTS, Camera API2 CTS und CTS Verifier-Kameratests bestehen.

Geräte, die keine Camera HAL3.2-Implementierung haben und die vollständigen Camera API2-Schnittstellen nicht unterstützen können, müssen trotzdem die Camera API2-CTS-Tests bestehen. Das Gerät wird jedoch im Camera API2-Modus LEGACY ausgeführt, in dem die Camera API2-Aufrufe konzeptionell Camera API1-Aufrufen zugeordnet werden. Daher werden alle Camera API2-CTS-Tests, die sich auf Funktionen oder Möglichkeiten beziehen, die über Camera API1 hinausgehen, automatisch übersprungen.

Auf älteren Geräten werden Camera API2 CTS-Tests mit den vorhandenen öffentlichen Camera API1-Schnittstellen und ‑Funktionen ohne neue Anforderungen ausgeführt. Fehler, die aufgedeckt werden (und die einen Camera API2 CTS-Fehler verursachen), sind Fehler, die bereits in der vorhandenen Camera HAL des Geräts vorhanden sind und daher von vorhandenen Camera API1-Apps gefunden würden. Wir gehen nicht davon aus, dass viele Fehler dieser Art auftreten. Alle Fehler dieser Art müssen jedoch behoben werden, damit die Camera API2-CTS-Tests bestanden werden.

VTS-Anforderungen

Geräte mit Android 8.0 und höher mit binderisierten HAL-Implementierungen müssen die VTS-Tests für die Kamera bestehen.

Härtung des Kamerasystems

Um die Sicherheit des Media- und Kamerasystems zu erhöhen, wurde der Kameradienst in Android 7.0 aus dem Mediaserver ausgelagert. Ab Android 8.0 wird jede gebundene Kamera-HAL in einem separaten Prozess vom Kameradienst ausgeführt. Je nach verwendeter API- und HAL-Version müssen Anbieter möglicherweise Änderungen am Kamera-HAL vornehmen. In den folgenden Abschnitten werden die Architekturänderungen in AP1 und AP2 für HAL1 und HAL3 sowie allgemeine Anforderungen beschrieben.

Architekturänderungen für API1

Bei der API1-Videoaufzeichnung wird möglicherweise davon ausgegangen, dass sich Kamera und Video-Encoder im selben Prozess befinden. Bei Verwendung von API1 auf:

  • Bei HAL3, wo der Kameradienst BufferQueue verwendet, um Puffer zwischen Prozessen zu übergeben, ist kein Anbieterupdate erforderlich.

    Kamera- und Media-Stack unter Android 7.0 in API1 auf HAL3

    Abbildung 1. Kamera- und Media-Stack unter Android 7.0 in API1 auf HAL3

  • HAL1, das die Übergabe von Metadaten in Videopuffern unterstützt, müssen Anbieter die HAL aktualisieren, um kMetadataBufferTypeNativeHandleSource zu verwenden. (kMetadataBufferTypeCameraSource wird in Android 7.0 nicht mehr unterstützt.)

    Kamera- und Media-Stack unter Android 7.0 in API1 auf HAL1

    Abbildung 2. Kamera- und Media-Stack unter Android 7.0 in API1 auf HAL1

Architekturänderungen für API2

Bei API2 auf HAL1 oder HAL3 werden Puffer über BufferQueue übergeben, sodass diese Pfade weiterhin funktionieren. Die Android 7.0-Architektur für API2 auf:

  • HAL1 ist von der Umstellung des Kameraservice nicht betroffen und es ist kein Anbieterupdate erforderlich.
  • HAL3 ist betroffen, aber kein Anbieterupdate ist erforderlich:

    Android 7.0-Kamera- und Media-Stack in API2 auf HAL3

    Abbildung 3. Kamera- und Media-Stack unter Android 7.0 in API2 auf HAL3

Zusätzliche Anforderungen

Die architektonischen Änderungen, die zur Härtung der Sicherheit des Media- und Kamera-Frameworks vorgenommen wurden, umfassen die folgenden zusätzlichen Geräteanforderungen.

  • Allgemein Geräte benötigen aufgrund von IPC zusätzliche Bandbreite, was sich auf zeitkritische Kameraanwendungsfälle wie die Hochgeschwindigkeits-Videoaufzeichnung auswirken kann. Anbieter können die tatsächlichen Auswirkungen messen, indem sie android.hardware.camera2.cts.PerformanceTest und die Google Kamera App für die High-Speed-Videoaufnahme mit 120/240 FPS ausführen. Außerdem benötigen Geräte etwas zusätzlichen RAM, um den neuen Prozess zu erstellen.
  • Metadaten in Videopuffern übergeben (nur HAL1). Wenn HAL1 Metadaten anstelle von echten YUV-Framedaten in Videopuffern speichert, muss das HAL kMetadataBufferTypeNativeHandleSource als Metadatenpuffertyp verwenden und VideoNativeHandleMetadata in Videopuffern übergeben. (kMetadataBufferTypeCameraSource wird unter Android 7.0 nicht mehr unterstützt.) Mit VideoNativeHandleMetadata können Kamera- und Media-Frameworks die Videopuffer zwischen Prozessen übergeben, indem die nativen Handles richtig serialisiert und deserialisiert werden.
  • Die Puffer-Handle-Adresse speichert nicht immer denselben Puffer (nur HAL3). Für jede Erfassungsanfrage ruft HAL3 Adressen von Puffer-Handles ab. HAL kann die Adressen nicht verwenden, um Puffer zu identifizieren, da in den Adressen möglicherweise ein anderes Puffer-Handle gespeichert wird, nachdem HAL den Puffer zurückgegeben hat. Sie müssen das HAL aktualisieren, damit Puffer mithilfe von Puffer-Handles identifiziert werden. HAL empfängt beispielsweise die Puffer-Handle-Adresse A, in der das Puffer-Handle A gespeichert ist. Nachdem HAL das Pufferhandle A zurückgegeben hat, kann unter der Adresse des Pufferhandles A das Pufferhandle B gespeichert werden, wenn HAL es das nächste Mal empfängt.
  • SELinux-Richtlinien für cameraserver aktualisieren: Wenn gerätespezifische SELinux-Richtlinien dem Mediaserver Berechtigungen zum Ausführen der Kamera gewähren, müssen Sie die SELinux-Richtlinien aktualisieren, um dem Kameraserver die richtigen Berechtigungen zu gewähren. Wir raten davon ab, die SELinux-Richtlinien des Mediaservers für den Kameraserver zu replizieren, da Mediaserver und Kameraserver in der Regel unterschiedliche Ressourcen im System benötigen. Der Kameraserver sollte nur die Berechtigungen haben, die zum Ausführen von Kamerafunktionen erforderlich sind. Alle unnötigen kamerabezogenen Berechtigungen im Mediaserver sollten entfernt werden.
  • Trennung zwischen Camera HAL und cameraserver: Unter Android 8.0 und höher wird die gebundene Camera HAL zusätzlich in einem Prozess getrennt, der sich vom Kameraserver unterscheidet. Die IPC erfolgt über HIDL-definierte Schnittstellen.

Zertifizierungsstufe

Prüfen Sie die Implementierung für alle Geräte mit Kamera, auf denen Android 7.0 ausgeführt wird, indem Sie das Android 7.0-CTS ausführen. Android 7.0 enthält zwar keine neuen CTS-Tests, mit denen Änderungen am Kameradienst überprüft werden, aber vorhandene CTS-Tests schlagen fehl, wenn Sie die oben genannten Updates nicht vorgenommen haben.

Prüfen Sie für alle Geräte mit Kamera, auf denen Android 8.0 oder höher ausgeführt wird, die Anbieterimplementierung mit VTS.

Versionsverlauf der Kamera HAL

Eine Liste der Tests, die zur Bewertung der Android-Kamera-HAL verfügbar sind, finden Sie in der Checkliste für das Testen der Kamera-HAL.

Android 10

In Android 10 werden die folgenden Updates eingeführt.

Camera API

Kamera-HAL

Die folgenden Camera HAL-Versionen werden in Android 10 aktualisiert.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: Die statischen Kamerainformationen für eine physische Kamera-ID, die ein logisches Kameragerät unterstützt. Weitere Informationen finden Sie unter Multi-Kamera-Unterstützung.
  • isStreamCombinationSupported: Diese Methode unterstützt eine öffentliche API, mit der Clients abfragen können, ob eine Sitzungskonfiguration unterstützt wird. Weitere Informationen finden Sie unter API zum Abfragen von Streamkombinationen.

ICameraDeviceSession

  • isReconfigurationNeeded: Methode, die dem Kamera-Framework mitteilt, ob eine vollständige Stream-Neukonfiguration für mögliche neue Sitzungsparameterwerte erforderlich ist. So werden unnötige Verzögerungen bei der Neukonfiguration der Kamera vermieden. Weitere Informationen finden Sie unter Anfrage zur Neukonfiguration der Sitzung.
  • HAL-APIs für die Pufferverwaltung: Mit diesen APIs kann die Kamera-HAL Puffer nur bei Bedarf vom Kamera-Framework anfordern. So muss nicht jede Aufnahmeanfrage mit den zugehörigen Puffern in der gesamten Kamerapipeline verknüpft werden, was zu potenziell erheblichen Speicherersparnissen führt.
    • signalStreamFlush: Signale an die HAL, dass der Kameradienst demnächst configureStreams_3_5 ausführen wird und dass die HAL alle Puffer der angegebenen Streams zurückgeben muss.
    • configureStreams_3_5: Ähnlich wie ICameraDevice3.4.configureStreams, aber zusätzlich wird der streamConfigCounter-Zähler bereitgestellt, um eine Race Condition zwischen den configureStreams_3_5- und signalStreamFlush-Aufrufen zu prüfen.

Änderungen an ICameraDeviceCallback:

  • requestStreamBuffers: Synchroner Callback, den die Kamera-HAL aufruft, um den Kameraserver nach Puffern zu fragen. Weitere Informationen finden Sie unter requestStreamBuffers.
  • returnStreamBuffers: Synchroner Callback für die Kamera-HAL, um Ausgabepuffer an den Kameraservice zurückzugeben. Weitere Informationen finden Sie unter returnStreamBuffers.

3.4

Die folgenden Schlüssel werden in Android 10 den Kamerametadaten hinzugefügt.

  • Bildformate
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tags für Kamerametadaten
    • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
    • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
    • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
    • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
    • ANDROID_HEIC_INFO_SUPPORTED
    • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
  • Funktionen
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Werte für den Schlüssel ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Verfügbare Konfigurationen für dynamische Tiefenstreams
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Verfügbare HEIC-Streamkonfigurationen
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Kameramodul

Die folgenden Kameramodulversionen werden in Android 10 aktualisiert.

2.5

  • Fügt die notifyDeviceStateChange-Methode hinzu, damit Geräte die Kamera-HAL benachrichtigen können, wenn sich durch physische Änderungen wie das Zusammenfalten die Kamera und das Routing ändern.

2.4

  • Geräte, die mit API-Level 29 oder höher auf den Markt kommen, MÜSSEN true für isTorchModeSupported melden.

Android 9

Mit der Veröffentlichung von Android 9 werden die folgenden Änderungen an der Camera API2 und der HAL-Schnittstelle eingeführt.

Camera API

  • Die Multi-Kamera-API wurde eingeführt, um Geräte mit mehreren Kameras, die in dieselbe Richtung zeigen, besser zu unterstützen und Funktionen wie Bokeh und nahtloses Zoomen zu ermöglichen. So können Apps mehrere Kameras auf einem Gerät als eine logische Einheit (logische Kamera) ansehen. Aufnahmeanfragen können auch an einzelne Kamerageräte gesendet werden, die zu einer logischen Kamera gehören. Weitere Informationen finden Sie unter Multi-Kamera-Unterstützung.
  • Einführung von Sitzungsparametern Sitzungsparameter sind eine Teilmenge der verfügbaren Erfassungsparameter, die bei Änderung zu erheblichen Verarbeitungsverzögerungen führen können. Diese Kosten können reduziert werden, wenn Clients ihre Anfangswerte bei der Initialisierung der Erfassungssitzung übergeben. Weitere Informationen finden Sie unter Sitzungsparameter.
  • Fügt Daten-Keys für die optische Bildstabilisierung (OIS) für die Stabilisierung und Effekte auf App-Ebene hinzu. Weitere Informationen finden Sie unter STATISTICS_OIS_SAMPLES.
  • Unterstützung für externe Blitze hinzugefügt. Weitere Informationen finden Sie unter CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Fügt in CAPTURE_INTENT einen Intent für die Bewegungserkennung hinzu. Weitere Informationen finden Sie unter CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • LENS_RADIAL_DISTORTION wird eingestellt und stattdessen wird LENS_DISTORTION eingeführt.
  • Fügt Verzeichnungskorrekturmodi in CaptureRequest hinzu. Weitere Informationen finden Sie unter DISTORTION_CORRECTION_MODE.
  • Unterstützung für externe USB-/UVC-Kameras auf unterstützten Geräten hinzugefügt. Weitere Informationen finden Sie unter INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Kamera-HAL

3.4

Änderungen bei ICameraDeviceSession

Änderungen bei ICameraDeviceCallback

3.3

Die folgenden Schlüssel werden in Android 9 den Kamerametadaten hinzugefügt.

  • Funktionen
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tags für Kamerametadaten
    • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
    • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
    • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
    • ANDROID_LENS_POSE_REFERENCE
    • ANDROID_LENS_DISTORTION
    • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
    • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
    • ANDROID_STATISTICS_OIS_DATA_MODE
    • ANDROID_STATISTICS_OIS_TIMESTAMPS
    • ANDROID_STATISTICS_OIS_X_SHIFTS
    • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

Mit Android 8.0 wurde Treble eingeführt. Mit Treble müssen die Camera HAL-Implementierungen des Anbieters binderisiert werden. Android 8.0 enthält außerdem die folgenden wichtigen Verbesserungen des Kameradienstes:

  • Gemeinsam genutzte Oberflächen: Mehrere Oberflächen können dieselbe OutputConfiguration verwenden.
  • System-API für benutzerdefinierte Kameramodi
  • onCaptureQueueEmpty

Weitere Informationen zu diesen Funktionen finden Sie in den Abschnitten unten.

Gemeinsam genutzte Oberflächen

Mit dieser Funktion kann nur ein Satz von Puffern zwei Ausgaben steuern, z. B. Vorschau und Videocodierung. Dadurch wird der Strom- und Speicherverbrauch gesenkt. Damit diese Funktion unterstützt wird, müssen Gerätehersteller dafür sorgen, dass ihre Camera HAL- und gralloc HAL-Implementierungen gralloc-Puffer erstellen können, die von mehreren verschiedenen Consumern (z. B. dem Hardware-Composer/der GPU und dem Video-Encoder) anstelle von nur einem Consumer verwendet werden. Der Kameradienst übergibt die Consumer-Nutzungsflags an die Kamera-HAL und die gralloc-HAL. Diese müssen entweder die richtigen Arten von Puffern zuweisen oder die Kamera-HAL muss einen Fehler zurückgeben, dass diese Kombination von Consumern nicht unterstützt wird.

Weitere Informationen finden Sie in der enableSurfaceSharingEntwicklerdokumentation.

System-API für benutzerdefinierte Kameramodi

Die öffentliche Kamera-API definiert zwei Betriebsmodi: normale und eingeschränkte High-Speed-Aufnahme. Sie haben eine recht unterschiedliche Semantik. Der High-Speed-Modus ist beispielsweise auf maximal zwei bestimmte Ausgaben gleichzeitig beschränkt. Verschiedene OEMs haben Interesse daran geäußert, andere benutzerdefinierte Modi für hardwarespezifische Funktionen zu definieren. Im Hintergrund ist der Modus nur eine Ganzzahl, die an configure_streams übergeben wird. Siehe: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Diese Funktion umfasst einen System-API-Aufruf, mit dem OEM-Kamera-Apps einen benutzerdefinierten Modus aktivieren können. Diese Modi müssen mit dem Ganzzahlwert 0x8000 beginnen, um Konflikte mit zukünftigen Modi zu vermeiden, die der öffentlichen API hinzugefügt werden.

Um diese Funktion zu unterstützen, müssen OEMs lediglich den neuen Modus zu ihrem HAL hinzufügen, der durch die Ganzzahl ausgelöst wird, die bei „configure_streams“ an das HAL übergeben wird. Anschließend muss ihre benutzerdefinierte Kamera-App die System-API verwenden.

Der Methodenname lautet android.hardware.camera2.CameraDevice#createCustomCaptureSession. Siehe: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

Der Zweck dieser API besteht darin, die Latenz von Steuerelementänderungen wie dem Zoomen zu verringern, indem die Anfragewarteschlange so leer wie möglich gehalten wird. onCaptureQueueEmpty erfordert keine HAL-Arbeit, da es sich um eine reine Framework-Ergänzung handelt. Apps, die diese Funktion nutzen möchten, müssen einen Listener für diesen Callback hinzufügen und entsprechend reagieren. In der Regel wird dazu eine weitere Aufnahmeanfrage an das Kameragerät gesendet.

Camera HIDL-Schnittstelle

Die Camera HIDL-Schnittstelle ist eine vollständige Überarbeitung der Camera HAL-Schnittstelle, bei der stabile, HIDL-definierte APIs verwendet werden. Alle Funktionen und Kamerafunktionen, die in den letzten Legacy-Versionen 3.4 und 2.4 (für das Kameramodul) eingeführt wurden, sind ebenfalls Teil der HIDL-Definitionen.

3.4

Geringfügige Ergänzungen der unterstützten Metadaten und Änderungen an der Unterstützung von „data_space“:

  • Füge ANDROID_SENSOR_OPAQUE_RAW_SIZE als obligatorische statische Metadaten hinzu, wenn das RAW_OPAQUE-Format unterstützt wird.
  • Fügen Sie ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE als statische Metadaten hinzu, wenn ein RAW-Format unterstützt wird.
  • Das Feld camera3_stream_t data_space wird auf eine flexiblere Definition umgestellt, die die Version 0 der Dataspace-Codierung verwendet.
  • Allgemeine Metadaten-Ergänzungen, die für HAL v3.2 oder höher verfügbar sind:
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Geringfügige Überarbeitung des HAL mit erweiterten Funktionen:

  • Aktualisierungen der OPAQUE- und YUV-Aufbereitungs-APIs.
  • Grundlegende Unterstützung für Tiefenausgabepuffer.
  • Das Feld data_space wurde zu camera3_stream_t hinzugefügt.
  • Das Rotationsfeld wurde camera3_stream_t hinzugefügt.
  • Der camera3_stream_configuration_t wurde der Betriebsmodus für die Camera3-Streamkonfiguration hinzugefügt.

3.2

Geringfügige Überarbeitung des HAL mit erweiterten Funktionen:

  • Stellt get_metadata_vendor_tag_ops ein. Verwenden Sie stattdessen get_vendor_tag_ops in camera_common.h.
  • Stellt register_stream_buffers ein. Alle gralloc-Puffer, die vom Framework an die HAL in process_capture_request übergeben werden, können jederzeit neu sein.
  • Unterstützung für Teilergebnisse hinzufügen. process_capture_result kann mehrmals mit einer Teilmenge der verfügbaren Ergebnisse aufgerufen werden, bevor das vollständige Ergebnis verfügbar ist.
  • Fügen Sie camera3_request_template eine manuelle Vorlage hinzu. Apps können diese Vorlage verwenden, um die Aufnahmeeinstellungen direkt zu steuern.
  • Überarbeiten Sie die Spezifikationen für bidirektionale und Eingabestreams.
  • Ändern Sie den Rückgabepfad des Eingabepuffers. Der Puffer wird in process_capture_result anstelle von process_capture_request zurückgegeben.

3.1

Geringfügige Überarbeitung des HAL mit erweiterten Funktionen:

  • configure_streams übergibt Flags zur Nutzung durch Verbraucher an die HAL.
  • „flush“-Aufruf, um alle laufenden Anfragen/Puffer so schnell wie möglich zu verwerfen.

3

Erste Überarbeitung des HAL mit erweiterten Funktionen:

  • Änderung der Hauptversion, da sich das ABI vollständig geändert hat. Die erforderlichen Hardwarefunktionen oder das Betriebsmodell haben sich seit Version 2.0 nicht geändert.
  • Überarbeitete Schnittstellen für Eingabeanfragen und Stream-Warteschlangen: Das Framework ruft HAL mit der nächsten Anfrage und den Stream-Puffern auf, die bereits aus der Warteschlange entfernt wurden. Unterstützung für das Synchronisierungs-Framework ist enthalten, was für effiziente Implementierungen erforderlich ist.
  • Trigger wurden in Anfragen und die meisten Benachrichtigungen in Ergebnisse verschoben.
  • Alle Callbacks im Framework wurden in einer Struktur und alle Einrichtungsmethoden in einem einzigen initialize()-Aufruf zusammengefasst.
  • Die Streamkonfiguration wurde in einem einzigen Aufruf zusammengefasst, um die Streamverwaltung zu vereinfachen. Bidirektionale Streams ersetzen das STREAM_FROM_STREAM-Konstrukt.
  • Semantik des eingeschränkten Modus für ältere/eingeschränkte Hardwaregeräte.

2.0

Erste Version des HAL mit erweiterten Funktionen (Android 4.2) [camera2.h]:

  • Ausreichend für die Implementierung der vorhandenen android.hardware.Camera-API.
  • Ermöglicht die ZSL-Warteschlange in der Kameraserviceschicht.
  • Nicht für neue Funktionen wie die manuelle Aufnahme, die Aufnahme von Bayer-RAW-Daten oder die Neuverarbeitung von RAW-Daten getestet.

1.0

Erste Android-Kamera-HAL (Android 4.0) [camera.h]:

  • Konvertiert aus der C++-Abstraktionsschicht „CameraHardwareInterface“.
  • Unterstützt die android.hardware.Camera API.

Versionsverlauf des Kameramoduls

Dieser Abschnitt enthält Informationen zur Modulversionierung für das Kamerahardwaremodul basierend auf camera_module_t.common.module_api_version. Die beiden höchstwertigen Hexadezimalziffern stehen für die Hauptversion und die beiden niedrigstwertigen für die Nebenversion.

2.4

In dieser Version des Kameramoduls wurden die folgenden API-Änderungen vorgenommen:

  1. Unterstützung für den Taschenlampenmodus Das Framework kann den Taschenlampenmodus für jedes Kameragerät mit Blitz aktivieren, ohne dass das Kameragerät geöffnet werden muss. Das Kameragerät hat einen höheren Prioritätszugriff auf die Blitzeinheit als das Kameramodul. Wenn ein Kameragerät geöffnet wird, wird die Taschenlampe deaktiviert, falls sie über die Modulschnittstelle aktiviert wurde. Bei Ressourcenkonflikten, z. B. wenn open() aufgerufen wird, um ein Kameragerät zu öffnen, muss das Kamera-HAL-Modul das Framework über den Callback für den Status des Taschenlampenmodus darüber informieren, dass der Taschenlampenmodus deaktiviert wurde.
  2. Unterstützung für externe Kameras (z. B. USB-Hot-Plug-Kameras) In den API-Updates wird angegeben, dass die statischen Kamerainformationen nur verfügbar sind, wenn die Kamera angeschlossen und einsatzbereit ist (gilt für externe Hot-Plug-Kameras). Aufrufe zum Abrufen statischer Informationen sind ungültig, wenn der Kamerastatus nicht CAMERA_DEVICE_STATUS_PRESENT ist. Das Framework stützt sich ausschließlich auf Rückrufe für Änderungen des Gerätestatus, um die Liste der verfügbaren externen Kameras zu verwalten.
  3. Hinweise zum Schiedsgerichtsverfahren für Kameras Unterstützung für die explizite Angabe der Anzahl der Kamerageräte, die gleichzeitig geöffnet und verwendet werden können, wurde hinzugefügt. Um gültige Kombinationen von Geräten anzugeben, sollten die Felder resource_cost und conflicting_devices immer in der camera_info-Struktur festgelegt werden, die vom get_camera_info-Aufruf zurückgegeben wird.
  4. Methode zur Initialisierung des Moduls. Wird vom Kameradienst aufgerufen, nachdem das HAL-Modul geladen wurde, um eine einmalige Initialisierung des HAL zu ermöglichen. Sie wird aufgerufen, bevor andere Modulmethoden aufgerufen werden.

2.3

In dieser Version des Kameramoduls wird die Unterstützung für offene Legacy-Kamera-HAL-Geräte hinzugefügt. Das Framework kann damit das Kameragerät als HAL-Gerät mit einer niedrigeren Geräte-HAL-Version öffnen, wenn dasselbe Gerät mehrere Geräte-API-Versionen unterstützt. Der Standard-Hardwaremodulaufruf (common.methods->open) öffnet weiterhin das Kameragerät mit der neuesten unterstützten Version, die auch in camera_info_t.device_version aufgeführt ist.

2.2

In dieser Version des Kameramoduls wird die Unterstützung von Anbieter-Tags aus dem Modul hinzugefügt und die alten vendor_tag_query_ops werden eingestellt, die zuvor nur bei geöffnetem Gerät zugänglich waren.

2.1

Diese Version des Kameramoduls bietet Unterstützung für asynchrone Callbacks an das Framework vom Kamera-HAL-Modul. Damit wird das Framework über Änderungen am Status des Kameramoduls informiert. Module, die eine gültige set_callbacks()-Methode bereitstellen, müssen mindestens diese Versionsnummer melden.

2.0

Kameramodule, die diese Versionsnummer melden, implementieren die zweite Version der HAL-Schnittstelle des Kameramoduls. Kamerageräte, die über dieses Modul geöffnet werden können, unterstützen möglicherweise Version 1.0 oder Version 2.0 der HAL-Schnittstelle für Kamerageräte. Das Feld device_version von „camera_info“ ist immer gültig. Das Feld static_camera_characteristics von camera_info ist gültig, wenn das Feld device_version 2.0 oder höher ist.

1.0

Kameramodule, die diese Versionsnummern melden, implementieren die erste HAL-Schnittstelle für Kameramodule. Alle Kamerageräte, die über dieses Modul geöffnet werden können, unterstützen nur Version 1 der Kamerageräte-HAL. Die Felder device_version und static_camera_characteristics von camera_info sind ungültig. Nur die android.hardware.Camera API kann von diesem Modul und seinen Geräten unterstützt werden.