Unterstützung der Kameraversion

Auf dieser Seite werden Versionsunterschiede bei Kamera-HALs, APIs und zugehörigen Compatibility Test Suite (CTS)-Tests beschrieben. Außerdem werden mehrere architektonische Änderungen beschrieben, die zur Härtung und Sicherheit des Kamera-Frameworks in Android 7.0 vorgenommen wurden, 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 android.hardware.camera2-Paket bereitgestellt wird.
Kamera-HAL
Die Kameramodulebene, die von SoC-Anbietern implementiert wird. Die öffentlichen Frameworks auf App-Ebene basieren auf der Kamera-HAL.
Kamera HAL3.1
Version der HAL des Kamerageräts, die mit Android 4.4 veröffentlicht wurde.
Kamera HAL3.2
Version der HAL des Kamerageräts, die mit Android 5.0 veröffentlicht wurde.
Camera API1 CTS
Reihe von Kamera-CTS-Tests, die über die Camera API 1 ausgeführt werden.
Camera API2 CTS
Zusätzliche CTS-Tests für Kameras, die über die Camera API2 ausgeführt werden.
Höhen
Die Anbieterimplementierung (gerätespezifische Software auf niedriger Ebene, die von Siliziumherstellern geschrieben wurde) wird über eine neue Anbieterschnittstelle vom Android-Betriebssystem getrennt.
HIDL
HAL-Schnittstellendefinitionsprache, die mit Treble eingeführt wurde und zum Definieren der Schnittstelle zwischen einer HAL und ihren Nutzern verwendet wird.
VTS
Anbietertestsuite, die zusammen mit Treble eingeführt wurde.

Kamera-APIs

Android umfasst die folgenden Kamera-APIs.

Camera API1

Mit Android 5.0 wurde die Camera API1 eingestellt. Sie wird nach und nach eingestellt, da sich die Entwicklung der neuen Plattform auf die Camera API2 konzentriert. Die Einstellung wird jedoch langwierig sein und Android-Releases unterstützen noch einige Zeit lang Apps mit der Camera API 1. Insbesondere wird der Support für Folgendes fortgesetzt:

  • Camera API1-Schnittstellen für Apps Kamera-Apps, die auf der Camera API 1 basieren, sollten auf Geräten mit niedrigeren Android-Release-Versionen wie gewohnt funktionieren.
  • Kamera-HAL-Versionen Unterstützt Camera HAL1.0.

Camera API2

Das Camera API2-Framework stellt der App eine Kamerasteuerung auf niedriger Ebene zur Verfügung, einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Frames-Steuerelemente für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Rauschunterdrückung, Schärfen usw. Weitere Informationen finden Sie im Video zur Google I/O-Übersicht.

Android 5.0 und höher enthält die Camera API2. Geräte mit Android 5.0 und höher unterstützen jedoch möglicherweise nicht alle Funktionen der Camera API2. Das Attribut android.info.supportedHardwareLevel, das Apps über die Camera API2-Schnittstellen abfragen können, gibt eines der folgenden Unterstützungsniveaus an:

  • LEGACY: Diese Geräte stellen Apps über die Kamera API 2-Schnittstellen Funktionen zur Verfügung, die ungefähr den Funktionen entsprechen, die Apps über die Kamera API 1-Schnittstellen zur Verfügung gestellt werden. Der Code der älteren Frameworks übersetzt Camera API2-Aufrufe konzeptionell in Camera API1-Aufrufe. Ältere Geräte unterstützen keine Camera API2-Funktionen wie Frames-spezifische Steuerelemente.
  • LIMITED: Diese Geräte unterstützen einige, aber nicht alle Funktionen der Camera API2 und müssen Camera HAL 3.2 oder höher verwenden.
  • FULL: Diese Geräte unterstützen alle wichtigen Funktionen der 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-Neuverarbeitung und die RAW-Bilderfassung sowie zusätzliche Konfigurationen für Ausgabestreams.
  • EXTERNAL: Diese Geräte ähneln mit einigen Ausnahmen LIMITED-Geräten. Beispielsweise werden einige Sensor- oder Objektivinformationen möglicherweise nicht erfasst oder haben eine weniger stabile Bildrate. Diese Ebene wird für externe Kameras wie USB-Webcams verwendet.

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

Die unterstützte Hardwareebene des Geräts sowie die von ihm unterstützten Camera2 API-Funktionen sind als die folgenden Feature-Flags verfügbar, um die Google Play-Filterung von Camera2 API-Kamera-Apps 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 Kameratests für Camera API 1 CTS, Camera API 2 CTS und CTS Verifier bestehen.

Geräte, die keine Kamera-HAL3.2-Implementierung haben und die gesamten Schnittstellen der Camera API2 nicht unterstützen können, müssen trotzdem die CTS-Tests der Camera API2 bestehen. Das Gerät wird jedoch im Camera API2-LEGACY-Modus ausgeführt, in dem die Camera API2-Aufrufe konzeptionell den Camera API1-Aufrufen zugeordnet werden. Alle Camera API2-CTS-Tests, die sich auf Funktionen oder Fähigkeiten beziehen, die über die Camera API1 hinausgehen, werden daher automatisch übersprungen.

Auf älteren Geräten werden bei CTS-Tests für die Camera API2 die vorhandenen öffentlichen Schnittstellen und Funktionen der Camera API1 ohne neue Anforderungen verwendet. Fehler, die aufgedeckt werden (und zu einem CTS-Fehler der Camera API2 führen), sind bereits in der vorhandenen HAL der Kamera des Geräts vorhanden und würden daher von vorhandenen Camera API1-Apps gefunden. Wir gehen nicht davon aus, dass viele Fehler dieser Art auftreten. Alle derartigen Fehler müssen jedoch behoben werden, damit die CTS-Tests der Camera API2 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 Kamera-Frameworks

Um die Sicherheit des Medien- und Kamera-Frameworks zu erhöhen, wird der Kameradienst in Android 7.0 aus dem Mediaserver verschoben. Ab Android 8.0 wird jede gebundene Camera HAL in einem separaten Prozess vom Kameradienst ausgeführt. Je nach verwendeten API- und HAL-Versionen müssen Anbieter möglicherweise Änderungen an der 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 davon ausgegangen, dass Kamera und Videoencoder im selben Prozess live sind. Bei Verwendung von API1 auf:

  • Bei HAL3, bei dem der Kameradienst BufferQueue verwendet, um Puffer zwischen Prozessen zu übergeben, ist kein Update des Anbieters erforderlich.

    Android 7.0-Kamera- und Medienstack in API1 auf HAL3

    Abbildung 1. Android 7.0-Kamera- und Medienstack in API1 auf HAL3

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

    Android 7.0-Kamera- und Medienstack in API1 auf HAL1

    Abbildung 2. Android 7.0-Kamera- und Medienstack in API1 auf HAL1

Architekturänderungen für API2

Bei API2 auf HAL1 oder HAL3 gibt BufferQueue Puffer weiter, damit diese Pfade weiterhin funktionieren. Die Android 7.0-Architektur für API2 auf:

  • HAL1 ist von der Verlagerung des Kameradienstes nicht betroffen und kein Anbieterupdate erforderlich.
  • HAL3 ist betroffen, aber kein Anbieterupdate erforderlich:

    Android 7.0-Kamera- und Medienstack in API2 auf HAL3

    Abbildung 3. Android 7.0-Kamera- und Medienstack in API2 auf HAL3

Zusätzliche Anforderungen

Die Architekturänderungen zur Verbesserung der Sicherheit des Medien- und Kamera-Frameworks umfassen die folgenden zusätzlichen Geräteanforderungen.

  • Allgemein. Geräte benötigen aufgrund der IPC zusätzliche Bandbreite. Dies kann sich auf zeitkritische Kameraanwendungen wie die Hochgeschwindigkeitsvideoaufzeichnung auswirken. Anbieter können die tatsächlichen Auswirkungen messen, indem sie android.hardware.camera2.cts.PerformanceTest und die Google Kamera App für die Hochgeschwindigkeitsvideoaufnahme mit 120/240 fps verwenden. 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-Frame-Daten in Video-Buffers speichert, muss die HAL kMetadataBufferTypeNativeHandleSource als Metadaten-Buffertyp verwenden und VideoNativeHandleMetadata in Video-Buffers übergeben. (kMetadataBufferTypeCameraSource wird unter Android 7.0 nicht mehr unterstützt.) Mit VideoNativeHandleMetadata können Kamera- und Medien-Frameworks die Video-Puffer zwischen Prozessen übergeben, indem die nativen Handles ordnungsgemäß serialisiert und deserialisiert werden.
  • Die Adresse des Buffer-Handles verweist nicht immer auf denselben Buffer (nur HAL3). Für jede Erfassungsanfrage erhält HAL3 Adressen von Puffer-Handles. HAL kann die Adressen nicht zum Identifizieren von Puffern verwenden, da die Adressen möglicherweise einen anderen Puffer-Handle speichern, nachdem HAL den Puffer zurückgegeben hat. Sie müssen die HAL so aktualisieren, dass die Puffer mit Puffer-Handles identifiziert werden. Beispiel: HAL empfängt die Adresse eines Pufferhandles A, in dem der Pufferhandle A gespeichert ist. Nachdem der HAL den Pufferhandle A zurückgegeben hat, kann die Pufferhandle-Adresse A beim nächsten Empfang durch den HAL den Pufferhandle B speichern.
  • SELinux-Richtlinien für den Kameraserver 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 entsprechenden Berechtigungen zu erteilen. 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 für die Ausführung der Kamerafunktionen erforderlich sind. Alle nicht erforderlichen kamerabezogenen Berechtigungen im Mediaserver sollten entfernt werden.
  • Trennung zwischen Camera HAL und Kameraserver. Unter Android 8.0 und höher wird die binderisierte Camera HAL zusätzlich in einem anderen Prozess als der Kameraserver getrennt. Die IPC erfolgt über HIDL-definierte Schnittstellen.

Zertifizierungsstufe

Prüfen Sie bei allen Geräten mit Kamera und Android 7.0 die Implementierung, indem Sie den 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 die vorhandenen CTS-Tests schlagen fehl, wenn Sie die oben genannten Änderungen nicht vorgenommen haben.

Prüfen Sie bei allen Geräten mit Kamera und Android 8.0 oder höher die Implementierung des Anbieters, indem Sie VTS ausführen.

Kamera HAL-Versionsverlauf

Eine Liste der Tests zur Bewertung der Android Camera HAL finden Sie in der Checkliste für HAL-Tests für Kameras.

Android 10

Mit 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 einem logischen Kameragerät zugeordnet ist. 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 findest du unter API zum Abfragen von Streamkombinationen.

ICameraDeviceSession

  • isReconfigurationNeeded: Methode, die dem Kamera-Framework mitteilt, ob eine vollständige Neukonfiguration des Streams für mögliche neue Sitzungsparameterwerte erforderlich ist. So lassen sich unnötige Verzögerungen bei der Neukonfiguration der Kamera vermeiden. Siehe Anfrage zur Sitzungsneukonfiguration.
  • HAL-APIs zur Pufferverwaltung: Mit diesen APIs kann die HAL der Kamera nur bei Bedarf Puffer vom Kamera-Framework anfordern, anstatt jede Aufnahmeanfrage mit den zugehörigen Puffern in der gesamten Kamerapipeline zu verknüpfen. Dies führt zu einer potenziell erheblichen Speichereinsparung.
    • signalStreamFlush: Signalisiert der HAL, dass der Kameradienst configureStreams_3_5 ausführen wird und dass der HAL alle Buffers der angegebenen Streams zurückgeben muss.
    • configureStreams_3_5: Ähnlich wie ICameraDevice3.4.configureStreams, aber zusätzlich wird der streamConfigCounter-Zähler bereitgestellt, um auf eine Race-Bedingung zwischen den configureStreams_3_5- und signalStreamFlush-Aufrufen zu prüfen.

Änderungen an ICameraDeviceCallback:

  • requestStreamBuffers: Synchroner Rückruf, den die HAL der Kamera aufruft, um den Kameraserver um Buffers zu bitten. Weitere Informationen finden Sie unter requestStreamBuffers.
  • returnStreamBuffers: Synchroner Rückruf für die Kamera-HAL, um Ausgabe-Buffer an den Kameraserver zurückzugeben. Weitere Informationen finden Sie unter returnStreamBuffers.

3.4

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

  • Bildformate
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Kamerametadaten-Tags
    • 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

  • Die Methode notifyDeviceStateChange wurde hinzugefügt, damit Geräte die HAL der Kamera benachrichtigen können, wenn sich physische Änderungen wie das Zusammenklappen auf die Kamera und die Weiterleitung auswirken.

2.4

  • Für Geräte, die mit API-Level 29 oder höher gestartet werden, MUSS true für isTorchModeSupported angegeben werden.

Android 9

Mit der Android 9-Version werden die folgenden Updates für die Kamera API2 und die HAL-Schnittstelle eingeführt.

Camera API

  • Einführung der Multi-Kamera-API zur besseren Unterstützung von Geräten mit mehreren Kameras, die in dieselbe Richtung zeigen. So sind Funktionen wie Bokeh und nahtloses Zoomen möglich. So können Apps mehrere Kameras auf einem Gerät als eine logische Einheit (logische Kamera) anzeigen. 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.
  • Sitzungsparameter werden eingeführt. 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 während der Initialisierung der Aufnahmesitzung übergeben. Weitere Informationen finden Sie unter Sitzungsparameter.
  • Es werden Datenschlüssel für die optische Stabilisierung (OIS) für Stabilisierung und Effekte auf App-Ebene hinzugefügt. Weitere Informationen finden Sie unter STATISTICS_OIS_SAMPLES.
  • Unterstützung für externes Blitzgerät hinzugefügt. Weitere Informationen finden Sie unter CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Fügen Sie 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 an seiner Stelle wird LENS_DISTORTION hinzugefügt.
  • Es wurden Modi zur Verzeichnungskorrektur in CaptureRequest hinzugefügt. Weitere Informationen finden Sie unter DISTORTION_CORRECTION_MODE.
  • Unterstützung für externe USB-/UVC-Kameras auf unterstützten Geräten. Weitere Informationen finden Sie unter INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Kamera-HAL

3.4

Aktualisierungen für ICameraDeviceSession

Aktualisierungen für ICameraDeviceCallback

3.3

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

  • Funktionen
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Kamerametadaten-Tags
    • 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 der Android 8.0-Version wurde Treble eingeführt. Bei Treble müssen Kamera-HAL-Implementierungen von Anbietern gebunden werden. Android 8.0 enthält außerdem die folgenden wichtigen Verbesserungen am Kameradienst:

  • Gemeinsam genutzte Oberflächen: Mehrere Oberflächen mit derselben OutputConfiguration
  • System API für benutzerdefinierte Kameramodi
  • onCaptureQueueEmpty

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

Gemeinsam genutzte Oberflächen

Mit dieser Funktion können zwei Ausgänge, z. B. Vorschau und Videocodierung, mit nur einem Satz von Puffern betrieben werden, was den Stromverbrauch und die Speichernutzung reduziert. Um diese Funktion zu unterstützen, müssen Gerätehersteller dafür sorgen, dass ihre Kamera-HAL- und gralloc-HAL-Implementierungen Gralloc-Buffer erstellen können, die von mehreren verschiedenen Abnehmern (z. B. dem Hardware-Composer/der GPU und dem Videoencoder) und nicht nur von einem Abnehmer verwendet werden. Der Kameradienst übergibt die Flags zur Nutzung durch den Verbraucher 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 Verbrauchern 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 Hochgeschwindigkeitsaufnahmen. Sie haben eine ziemlich unterschiedliche Semantik. Beispielsweise ist der Hochgeschwindigkeitsmodus auf maximal zwei bestimmte Ausgänge gleichzeitig beschränkt. Verschiedene OEMs haben Interesse an der Definition anderer benutzerdefinierter Modi für hardwarespezifische Funktionen geäußert. Der Modus ist im Grunde 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 ihrer HAL hinzufügen, der durch diese Ganzzahl ausgelöst wird, die bei „configure_streams“ an die 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

Mit dieser API soll die Latenz von Steuerelementänderungen wie dem Zoomen reduziert werden, indem die Anfragewarteschlange so leer wie möglich gehalten wird. onCaptureQueueEmpty erfordert keine HAL-Arbeit; es war eine rein frameworkseitige Ergänzung. Apps, die diese Funktion nutzen möchten, müssen diesem Callback einen Listener hinzufügen und entsprechend reagieren. In der Regel wird dazu eine weitere Aufnahmeanfrage an das Kameragerät gesendet.

HIDL-Schnittstelle der Kamera

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

3.4

Kleinere Ergänzungen zu unterstützten Metadaten und Änderungen an der Unterstützung von data_space:

  • Fügen Sie ANDROID_SENSOR_OPAQUE_RAW_SIZE-Metadaten als obligatorisch hinzu, wenn das RAW_OPAQUE-Format unterstützt wird.
  • Fügen Sie ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE-Statische Metadaten als obligatorisch hinzu, wenn ein RAW-Format unterstützt wird.
  • Verwenden Sie für das Feld camera3_stream_t data_space eine flexiblere Definition, indem Sie die Definition der Version 0 der Datenraumcodierung verwenden.
  • Allgemeine Metadatenergänzungen, die für HALv3.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

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • API-Aktualisierungen für die Neuverarbeitung von OPAQUE- und YUV-Dateien
  • Grundlegende Unterstützung für Tiefenausgabe-Buffer.
  • Dem Feld camera3_stream_t wurde das Feld data_space hinzugefügt.
  • Dem camera3_stream_t-Feld wurde das Rotationsfeld hinzugefügt.
  • Der Betriebsmodus der Kamera 3-Streamkonfiguration wurde zu camera3_stream_configuration_t hinzugefügt.

3.2

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • get_metadata_vendor_tag_ops wird eingestellt. Verwenden Sie stattdessen get_vendor_tag_ops in camera_common.h.
  • register_stream_buffers wird eingestellt. Alle vom Framework an HAL in process_capture_request bereitgestellten Gralloc-Buffer können jederzeit neu sein.
  • Unterstützung für Teilergebnisse hinzufügen. process_capture_result wird möglicherweise mehrmals mit einer Teilmenge der verfügbaren Ergebnisse aufgerufen, bevor das vollständige Ergebnis verfügbar ist.
  • Manuelle Vorlage zu camera3_request_template hinzufügen Apps können diese Vorlage verwenden, um die Aufnahmeeinstellungen direkt zu steuern.
  • Überarbeiten Sie die Spezifikationen für den bidirektionalen und den Eingabestream.
  • Ändern Sie den Rückgabepfad des Eingabepuffers. Der Puffer wird in process_capture_result anstelle von process_capture_request zurückgegeben.

3.1

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • configure_streams gibt Flags zur Nutzernutzung an die HAL weiter.
  • flush-Aufruf, um alle laufenden Anfragen/Puffer so schnell wie möglich zu löschen.

3

Erste Überarbeitung der HAL mit erweiterten Funktionen:

  • Hauptversionsänderung, da das ABI völlig anders ist. Es gibt keine Änderungen an den erforderlichen Hardwarefunktionen oder dem Betriebsmodell im Vergleich zu Version 2.0.
  • Überarbeitete Schnittstellen für Eingabeanfragen und Stream-Warteschlangen: Das Framework ruft die HAL mit der nächsten Anfrage auf und die Stream-Buffer wurden bereits aus der Warteschlange entfernt. Die Unterstützung des Sync Framework ist enthalten, was für effiziente Implementierungen erforderlich ist.
  • Auslöser wurden in Anfragen und die meisten Benachrichtigungen in Ergebnisse verschoben.
  • Alle Rückrufe wurden im Framework in einer Struktur und alle Einrichtungsmethoden in einem einzigen initialize()-Aufruf zusammengefasst.
  • Die Streamkonfiguration wurde zu einem einzigen Aufruf zusammengefasst, um die Streamverwaltung zu vereinfachen. Bidirektionale Streams ersetzen das STREAM_FROM_STREAM-Konstrukt.
  • Semantik für den eingeschränkten Modus auf älteren/eingeschränkten Hardwaregeräten.

2

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

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

1.0

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

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

Versionsverlauf des Kameramoduls

Dieser Abschnitt enthält Informationen zur Modulversionierung für das Kamera-Hardwaremodul auf der Grundlage von camera_module_t.common.module_api_version. Die beiden höchstwertigen Hexadezimalstellen stehen für die Hauptversion und die beiden niedrigsten für die Nebenversion.

2.4

Diese Kameramodulversion führt die folgenden API-Änderungen ein:

  1. Unterstützung für den Taschenlampenmodus Das Framework kann den Taschenlampenmodus für jede Kamera mit Blitz aktivieren, ohne dass die Kamera geöffnet werden muss. Das Kameragerät hat beim Zugriff auf den Blitz eine höhere Priorität als das Kameramodul. Wenn Sie eine Kamera öffnen, wird die Taschenlampe ausgeschaltet, wenn sie über die Moduloberfläche aktiviert wurde. Bei Ressourcenkonflikten, z. B. wenn open() zum Öffnen eines Kamerageräts aufgerufen wird, muss das HAL-Modul der Kamera das Framework über den Status-Callback des Taschenlampenmodus darüber informieren, dass der Taschenlampenmodus deaktiviert wurde.
  2. Unterstützung externer Kameras (z. B. USB-Hot-Plug-Kameras) Die API-Updates geben an, dass die statischen Kamerainformationen nur verfügbar sind, wenn die Kamera angeschlossen und für externe Hot-Plug-Kameras einsatzbereit ist. Aufrufe zum Abrufen statischer Informationen sind ungültig, wenn der Kamerastatus nicht CAMERA_DEVICE_STATUS_PRESENT ist. Das Framework nutzt ausschließlich Rückrufe für Gerätestatusänderungen, um die Liste der verfügbaren externen Kameras zu verwalten.
  3. Tipps zur Kameraarbitrage Es wird unterstützt, die Anzahl der Kamerageräte, die gleichzeitig geöffnet und verwendet werden können, explizit anzugeben. Um gültige Gerätekombinationen anzugeben, sollten die Felder resource_cost und conflicting_devices immer in der camera_info-Struktur festgelegt sein, die vom get_camera_info-Aufruf zurückgegeben wird.
  4. Methode zur Modulinitialisierung. 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

Diese Kameramodulversion bietet Unterstützung für offene Legacy-HAL-Geräte für Kameras. Das Framework kann damit das Kameragerät als HAL-Gerät mit niedrigerer Geräte-HAL-Version öffnen, wenn dasselbe Gerät mehrere Geräte-API-Versionen unterstützen kann. Der Standardaufruf für das Hardwaremodul (common.methods->open) öffnet das Kameragerät weiterhin mit der neuesten unterstützten Version, die auch in camera_info_t.device_version aufgeführt ist.

2,2

Diese Kameramodulversion unterstützt Anbieter-Tags vom Modul und ersetzt die alte vendor_tag_query_ops, auf die zuvor nur bei geöffnetem Gerät zugegriffen werden konnte.

2.1

Diese Kameramodulversion unterstützt asynchrone Rückrufe an das Framework vom HAL-Modul der Kamera, mit denen das Framework über Änderungen am Status des Kameramoduls informiert wird. Module, die eine gültige set_callbacks()-Methode bereitstellen, müssen mindestens diese Versionsnummer angeben.

2

Kameramodule, die diese Versionsnummer melden, implementieren die zweite Version der HAL-Schnittstelle des Kameramoduls. Kameras, die über dieses Modul geöffnet werden können, unterstützen entweder Version 1.0 oder Version 2.0 der HAL-Schnittstelle der Kamera. 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 mindestens 2.0 ist.

1.0

Kameramodule, die diese Versionsnummern melden, implementieren die ursprüngliche HAL-Schnittstelle des Kameramoduls. Alle Kameras, die über dieses Modul geöffnet werden können, unterstützen nur Version 1 der HAL des Kamerageräts. Die Felder device_version und static_camera_characteristics von camera_info sind ungültig. Dieses Modul und die zugehörigen Geräte unterstützen nur die android.hardware.Camera API.