Unterstützung von Kameraversionen

Auf dieser Seite werden Versionsunterschiede bei Kamera-HALs, APIs und zugehörigen Compatibility Test Suite (CTS)-Tests beschrieben. Außerdem werden mehrere architektonische Änderungen behandelt, 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 für Geräte mit Android 4.4 und niedriger, verfügbar in der Klasse android.hardware.Camera.

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.

Camera HAL3.1

Version des Kamerageräts HAL, veröffentlicht mit Android 4.4.

Camera 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 enthält 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 schrittweise erfolgen 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.
• Camera HAL-Versionen Beinhaltet Unterstützung für Kamera HAL1.0.

Camera API2

Das Camera API2-Framework ermöglicht der App die Kamerasteuerung auf niedrigerer Ebene. Dazu gehören effiziente Burst-/Streaming-Abläufe ohne Kopie und Steuerung pro Frame für Belichtung, Verstärkung, Weißabgleichverstärkung, Farbkonvertierung, Geräuschunterdrückung, Schärfe und mehr. 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-Oberflächen abfragen können, meldet eine der folgenden Supportstufen:

• LEGACY: Diese Geräte stellen über die Camera API2-Schnittstellen Funktionen für Apps bereit, die ungefähr denselben Funktionen wie Apps über die Camera API1-Schnittstellen haben. 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. FULL-Geräte benötigen 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 davon. Die BACKWARD_COMPATIBLE-Funktion muss jedoch immer definiert sein.

Die unterstützte Hardwareebene des Geräts sowie die spezifischen Kamera-API2-Funktionen, die es unterstützt, sind als die folgenden Funktions-Flags verfügbar, um das Filtern von Camera API2-Kamera-Apps durch 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 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 und binderisierten HAL-Implementierungen müssen die VTS-Tests der Kamera bestehen.

Härtung des Kamerarahmens

Um die Sicherheit von Medien- und Kamera-Frameworks zu härten, verschiebt Android 7.0 den Kameradienst aus dem Mediaserver. Ab Android 8.0 wird jeder gebinderte Camera HAL in einem separaten Prozess vom Kameradienst ausgeführt. Je nach verwendeter API- und HAL-Version 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

Für die API1-Videoaufzeichnung wird vorausgesetzt, dass Kamera und Video-Encoder im selben Prozess live gehen. 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.

  

  Abbildung 1. Android 7.0-Kamera und -Medien-Stack 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.)

  

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

Architekturänderungen für API2

Bei API2 auf HAL1 oder HAL3 übergibt die BufferQueue Puffer, 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:

  

  Abbildung 3. Android 7.0-Kamera und -Medien-Stack 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ächliche Auswirkung messen, indem sie android.hardware.camera2.cts.PerformanceTest ausführen und die Google Kamera App für eine Hochgeschwindigkeitsvideoaufzeichnung mit 120/240 fps ausführen. Außerdem benötigen Geräte ein wenig 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 vorhandene CTS-Tests schlagen fehl, wenn Sie die oben genannten Updates 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.

Versionsverlauf der Camera HAL

Eine Liste der verfügbaren Tests zur Bewertung des Android Camera HAL finden Sie in der Kamera-HAL-Testprüfliste.

Android 10

Mit Android 10 werden die folgenden Updates eingeführt.

Camera API

• Verbesserungen bei der Mehrfachkamera, durch die physische Kameras einzeln oder über entsprechende logische Kameras verwendet werden können, indem physische Kamera-IDs ausgeblendet werden. Weitere Informationen finden Sie unter Multi-Kamera-Unterstützung.
• Möglichkeit, zu prüfen, ob eine bestimmte Sitzungskonfiguration unterstützt wird, ohne dass durch das Erstellen einer neuen Sitzung ein Leistungsaufwand entsteht. Siehe CameraDevice.
• Möglichkeit zum Abrufen empfohlener Streamkonfigurationen für einen bestimmten Anwendungsfall, um den Client energieeffizienter und leistungsfähiger zu machen. Siehe getRecommendedStreamConfigurationMap.
• Unterstützung für das JPEG-Bildformat mit Tiefeninformationen Weitere Informationen finden Sie in der Spezifikation für dynamische Tiefen.
• Unterstützung für das HEIC-Bildformat. Siehe HEIF-Bildverarbeitung.
• Datenschutzverbesserungen. Der Client benötigt bestimmte Schlüssel, die Berechtigungen vom Typ CAMERA haben, bevor sie aus CameraCharacteristics abgerufen werden können. Siehe getKeysNeedingPermission.

Kamera HAL

Die folgenden Kamera-HAL-Versionen wurden unter Android 10 aktualisiert.

3,50

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 für mögliche neue Sitzungsparameterwerte eine vollständige Neukonfiguration des Streams erforderlich ist. Dadurch werden unnötige Verzögerungen bei der Neukonfiguration der Kamera vermieden. 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 dem HAL, dass der Kameradienst gleich configureStreams_3_5 ausführen wird und dass der HAL alle Zwischenspeicher bestimmter 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. Siehe requestStreamBuffers.
• returnStreamBuffers: Synchroner Callback für den Kamera-HAL, um Ausgabepuffer 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 das Routing 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

• Führt die API für mehrere Kameras ein, um Geräte mit mehreren Kameras, die in die gleiche Richtung weisen, besser zu unterstützen. Dadurch werden 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. Siehe CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• LENS_RADIAL_DISTORTION wird eingestellt und an seiner Stelle wird LENS_DISTORTION hinzugefügt.
• 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. Weitere Informationen finden Sie unter INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Camera HAL

3.4

Aktualisierungen für ICameraDeviceSession

• configureStreams_3_4: Unterstützt sessionParameters und logische Kameras.
• processCaptureRequest_3_4: Unterstützung für die Aufnahme physischer Kamera-IDs in die Streamstruktur.

Aktualisierungen für ICameraDeviceCallback

• processCaptureResult_3_4: Fügt den Aufnahmeergebnissen Metadaten der physischen Kamera hinzu.

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 die HAL-Implementierungen der Kamera des Anbieters gebunden sein. Android 8.0 enthält außerdem die folgenden wichtigen Verbesserungen am Kameradienst:

• Gemeinsam genutzte Oberflächen: Mehrere Oberflächen mit derselben OutputConfiguration aktivieren
• 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 Public Camera API definiert zwei Betriebsmodi: normale und eingeschränkte Hochgeschwindigkeitsaufzeichnung. Sie haben eine ziemlich unterschiedliche Semantik. Beispielsweise ist der Hochgeschwindigkeitsmodus auf maximal zwei bestimmte Ausgänge gleichzeitig beschränkt. Verschiedene OEMs haben Interesse daran bekundet, andere benutzerdefinierte Modi für hardwarespezifische Funktionen zu definieren. 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 Modi zu vermeiden, die zukünftig der öffentlichen API hinzugefügt werden.

Zur Unterstützung dieser Funktion müssen OEMs nur den neuen Modus zu ihrem HAL hinzufügen, der durch diese Ganzzahl ausgelöst wird, die an den HAL in „configure_streams“ übergeben wird. Anschließend muss ihre benutzerdefinierte Kamera-App die System-API verwenden.

Der Methodenname ist 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

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

• Fügen Sie die statischen ANDROID_SENSOR_OPAQUE_RAW_SIZE-Metadaten als obligatorisch hinzu, wenn das Format RAW_OPAQUE unterstützt wird.
• Fügen Sie die statischen ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE-Metadaten als obligatorisch hinzu, wenn ein RAW-Format unterstützt wird.
• Ändern Sie das Feld camera3_stream_t data_space in eine flexiblere Definition mit Version 0 der Datenraumcodierung.
• Allgemeine Metadatenergänzungen, die für HALv3.2 oder höher verwendet werden können:
  • 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

Nebenversion des HAL mit erweiterter Funktionalität:

• 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

Nebenversion des HAL mit erweiterter Funktionalität:

• 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 teilweise Ergebnisse 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 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

Kleinere Überarbeitung des 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 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 Callbacks 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 bei älteren/eingeschränkten Hardwaregeräten

2

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

• Das ist ausreichend, um die vorhandene android.hardware.Camera API zu implementieren.
• 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 bedeutendsten Hexadezimalziffern stehen für die Hauptversion und die beiden am wenigsten signifikanten 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 eine Kamera geöffnet wird, 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ültige Aufrufe, 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. Hinweise für das Kamera-Schiedsgerichtsverfahren: Es wird unterstützt, die Anzahl der Kamerageräte anzugeben, die gleichzeitig geöffnet und verwendet werden können. 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. Es wird vor allen anderen Modulmethoden aufgerufen.

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 Kamerageräte, die über dieses Modul geöffnet werden können, unterstützen nur Version 1 des Kameragerät-HAL. 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.