Unterstützung der Kameraversion

Auf dieser Seite werden Versionsunterschiede bei Kamera-HALs, APIs und zugehörigen Compatibility Test Suite (CTS) -Tests detailliert beschrieben. Es behandelt außerdem mehrere Architekturänderungen, die vorgenommen wurden, um das Kamera-Framework in Android 7.0 zu härten und zu sichern, den Wechsel zu Treble in Android 8.0 und die Aktualisierungen, die Anbieter vornehmen müssen, um diese Änderungen in ihren Kameraimplementierungen zu unterstützen.

Terminologie

Auf dieser Seite werden folgende Begriffe verwendet:

Kamera-API1
Das Kamera-Framework auf App-Ebene auf Geräten mit Android 4.4 und niedriger, verfügbar gemacht durch die Klasse android.hardware.Camera .
Kamera-API2
Das Kamera-Framework auf App-Ebene auf Geräten mit Android 5.0 und höher, bereitgestellt über das Paket android.hardware.camera2 .
Kamera HAL
Die von SoC-Anbietern implementierte Kameramodulschicht. Die öffentlichen Frameworks auf App-Ebene basieren auf dem Kamera-HAL.
Kamera HAL3.1
Mit Android 4.4 veröffentlichte Version des Kamerageräts HAL.
Kamera HAL3.2
Mit Android 5.0 veröffentlichte Version des Kamerageräts HAL.
Kamera API1 CTS
Satz von Kamera-CTS-Tests, die auf der Kamera-API1 ausgeführt werden.
Kamera API2 CTS
Zusätzlicher Satz Kamera-CTS-Tests, die zusätzlich zur Kamera-API2 ausgeführt werden.
Verdreifachen
Trennt die Anbieterimplementierung (gerätespezifische Software auf niedrigerer Ebene, die von Siliziumherstellern geschrieben wurde) über eine neue Anbieterschnittstelle vom Android-Betriebssystem-Framework.
HIDL
HAL-Schnittstellendefinitionssprache, die mit Treble eingeführt wurde und zur Spezifikation der Schnittstelle zwischen einem HAL und seinen Benutzern verwendet wird.
VTS
Zusammen mit Treble wurde die Testsuite eines Anbieters eingeführt.

Kamera-APIs

Android umfasst die folgenden Kamera-APIs.

Kamera-API1

Android 5.0 hat die Kamera-API1 als veraltet markiert und wird weiterhin auslaufen, da sich die Entwicklung neuer Plattformen auf die Kamera-API2 konzentriert. Allerdings wird die Auslaufphase langwierig sein und Android-Releases werden noch einige Zeit lang Kamera-API1-Apps unterstützen. Konkret wird weiterhin Unterstützung für Folgendes gewährt:

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

Kamera-API2

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

Android 5.0 und höher enthält Camera API2; Allerdings unterstützen Geräte mit Android 5.0 und höher möglicherweise nicht alle Kamera-API2-Funktionen. Die Eigenschaft android.info.supportedHardwareLevel , die Apps über die Kamera-API2-Schnittstellen abfragen können, meldet eine der folgenden Unterstützungsstufen:

  • LEGACY : Diese Geräte stellen Apps über die Kamera-API2-Schnittstellen Funktionen zur Verfügung, die ungefähr den gleichen Funktionen entsprechen wie die, die Apps über die Kamera-API1-Schnittstellen zur Verfügung gestellt werden. Der Code des Legacy-Frameworks übersetzt Kamera-API2-Aufrufe konzeptionell in Kamera-API1-Aufrufe. Ältere Geräte unterstützen keine Kamera-API2-Funktionen wie die Steuerung pro Bild.
  • LIMITED : Diese Geräte unterstützen einige Kamera-API2-Funktionen (aber nicht alle) und müssen Kamera-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 YUV-Neuverarbeitung und RAW-Bilderfassung sowie zusätzliche Ausgabestream-Konfigurationen.
  • EXTERNAL : Diese Geräte ähneln mit einigen Ausnahmen LIMITED Geräten. Beispielsweise werden einige Sensor- oder Objektivinformationen möglicherweise nicht gemeldet oder die Bildraten sind weniger stabil. Diese Ebene wird für externe Kameras wie USB-Webcams verwendet.

Einzelne Funktionen werden über die Eigenschaft android.request.availableCapabilities in den Kamera-API2-Schnittstellen verfügbar gemacht. FULL Geräte erfordern unter anderem die Funktionen MANUAL_SENSOR und MANUAL_POST_PROCESSING . Die RAW Fähigkeit ist auch für FULL Geräte optional. LIMITED -Geräte können jede Teilmenge dieser Funktionen anbieten, auch keine davon. Die Funktion BACKWARD_COMPATIBLE muss jedoch immer definiert sein.

Die unterstützte Hardwarestufe des Geräts sowie die spezifischen unterstützten Camera API2-Funktionen sind als folgende Funktionsflags verfügbar, um die Google Play-Filterung von Camera API2-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 Camera API1 CTS, Camera API2 CTS und CTS Verifier bestehen.

Geräte, die nicht über eine Camera HAL3.2-Implementierung verfügen und nicht in der Lage sind, die vollständigen Camera API2-Schnittstellen zu unterstützen, müssen dennoch die Camera API2 CTS-Tests bestehen. Das Gerät läuft jedoch im Camera API2 LEGACY Modus (in dem die Camera API2-Aufrufe konzeptionell den Camera API1-Aufrufen zugeordnet sind), sodass alle Camera API2 CTS-Tests, die sich auf Funktionen oder Fähigkeiten beziehen, die über Camera API1 hinausgehen, automatisch übersprungen werden.

Auf älteren Geräten nutzen die ausgeführten Camera API2 CTS-Tests die vorhandenen öffentlichen Camera API1-Schnittstellen und -Funktionen ohne neue Anforderungen. Aufgedeckte Fehler (und die einen CTS-Fehler der Kamera-API2 verursachen) sind Fehler, die bereits im vorhandenen Kamera-HAL des Geräts vorhanden sind und daher von vorhandenen Kamera-API1-Apps gefunden werden. Wir erwarten nicht viele Fehler dieser Art (allerdings müssen solche Fehler behoben werden, um die Camera API2 CTS-Tests zu bestehen).

VTS-Anforderungen

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

Härtung des Kameragerüsts

Um die Sicherheit des Medien- und Kamera-Frameworks zu erhöhen, entfernt Android 7.0 den Kameradienst vom Medienserver. Ab Android 8.0 wird jede binderisierte Kamera-HAL in einem vom Kameradienst getrennten Prozess ausgeführt. Abhängig von den verwendeten API- und HAL-Versionen müssen Anbieter möglicherweise Änderungen am Kamera-HAL vornehmen. In den folgenden Abschnitten werden Architekturänderungen in AP1 und AP2 für HAL1 und HAL3 sowie allgemeine Anforderungen detailliert beschrieben.

Architekturänderungen für API1

Bei der API1-Videoaufzeichnung kann davon ausgegangen werden, dass Kamera und Video-Encoder im selben Prozess aktiv sind. Bei Verwendung von API1 auf:

  • HAL3, wo der Kameradienst BufferQueue verwendet, um Puffer zwischen Prozessen zu übergeben, ist kein Anbieter-Update erforderlich.

    Android 7.0-Kamera und Medienstapel in API1 auf HAL3

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

  • HAL1, das die Weitergabe 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.)

    Android 7.0-Kamera und Medienstapel in API1 auf HAL1

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

Architekturänderungen für API2

Für API2 auf HAL1 oder HAL3 übergibt BufferQueue Puffer, sodass diese Pfade weiterhin funktionieren. Die Android 7.0-Architektur für API2 auf:

  • HAL1 ist von der Kameraservice-Umstellung nicht betroffen und es ist kein Anbieter-Update erforderlich.
  • HAL3 ist betroffen, es ist jedoch kein Hersteller-Update erforderlich:

    Android 7.0-Kamera und Medienstapel in API2 auf HAL3

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

Zusätzliche Anforderungen

Die architektonischen Änderungen zur Härtung der Medien- und Kamera-Framework-Sicherheit umfassen die folgenden zusätzlichen Geräteanforderungen.

  • Allgemein. Geräte benötigen aufgrund von IPC zusätzliche Bandbreite, was sich auf zeitkritische Kamera-Anwendungsfälle wie die Hochgeschwindigkeits-Videoaufzeichnung auswirken kann. Anbieter können die tatsächliche Wirkung messen, indem sie android.hardware.camera2.cts.PerformanceTest und die Google Camera-App für Hochgeschwindigkeitsvideoaufnahmen mit 120/240 FPS ausführen. Geräte benötigen außerdem eine kleine Menge zusätzlichen RAM, um den neuen Prozess zu erstellen.
  • Übergeben Sie Metadaten in Videopuffern ( nur HAL1 ). Wenn HAL1 Metadaten anstelle echter YUV-Framedaten in Videopuffern speichert, muss der 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 Medienframeworks die Videopuffer zwischen Prozessen weitergeben, indem sie die nativen Handles ordnungsgemäß serialisieren und deserialisieren.
  • Die Puffer-Handle-Adresse speichert nicht immer denselben Puffer ( nur HAL3 ). Für jede Erfassungsanforderung erhält HAL3 Adressen von Pufferhandles. HAL kann die Adressen nicht zur Identifizierung von Puffern verwenden, da die Adressen möglicherweise ein weiteres Pufferhandle speichern, nachdem HAL den Puffer zurückgegeben hat. Sie müssen die HAL aktualisieren, um Pufferhandles zur Identifizierung der Puffer zu verwenden. HAL empfängt beispielsweise eine Puffer-Handle-Adresse A, die Puffer-Handle A speichert. Nachdem HAL Puffer-Handle A zurückgegeben hat, speichert Puffer-Handle-Adresse A möglicherweise Puffer-Handle B, wenn der HAL das nächste Mal das Puffer-Handle A empfängt.
  • Aktualisieren Sie die SELinux-Richtlinien für den Kameraserver. Wenn gerätespezifische SELinux-Richtlinien dem Medienserver Berechtigungen zum Ausführen der Kamera erteilen, müssen Sie die SELinux-Richtlinien aktualisieren, um dem Kameraserver die entsprechenden Berechtigungen zu erteilen. Wir raten davon ab, die SELinux-Richtlinien des Medienservers für den Kameraserver zu replizieren (da Medienserver und Kameraserver im Allgemeinen unterschiedliche Ressourcen im System erfordern). Der Kameraserver sollte nur über die Berechtigungen verfügen, die zum Ausführen der Kamerafunktionen erforderlich sind, und alle unnötigen kamerabezogenen Berechtigungen im Medienserver sollten entfernt werden.
  • Trennung zwischen Kamera-HAL und Kameraserver. Android 8.0 und höher trennen außerdem die gebundene Kamera-HAL auf andere Weise als der Kameraserver. IPC durchläuft HIDL-definierte Schnittstellen.

Validierung

Überprüfen Sie bei allen Geräten, die über eine Kamera verfügen und Android 7.0 ausführen, die Implementierung, indem Sie Android 7.0 CTS ausführen. Obwohl Android 7.0 keine neuen CTS-Tests enthält, die Änderungen an Kameradiensten überprüfen, schlagen bestehende CTS-Tests fehl, wenn Sie die oben genannten Aktualisierungen nicht vorgenommen haben.

Überprüfen Sie bei allen Geräten, die über eine Kamera verfügen und Android 8.0 und höher ausführen, die Implementierung des Anbieters, indem Sie VTS ausführen.

Versionsgeschichte der Kamera-HAL

Eine Liste der verfügbaren Tests zur Evaluierung des Android-Kamera-HAL finden Sie in der Checkliste für Kamera-HAL-Tests .

Android 10

Android 10 führt die folgenden Updates ein.

Kamera-API

Kamera HAL

Die folgenden Kamera-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. Siehe Multi-Kamera-Unterstützung .
  • isStreamCombinationSupported : Diese Methode unterstützt eine öffentliche API, die Clients bei der Abfrage unterstützt, ob eine Sitzungskonfiguration unterstützt wird. Siehe API zum Abfragen von Stream-Kombinationen .

ICameraDeviceSession

  • isReconfigurationNeeded : Methode, die dem Kamera-Framework mitteilt, ob eine vollständige Stream-Neukonfiguration für mögliche neue Sitzungsparameterwerte erforderlich ist. Dies trägt dazu bei, unnötige Verzögerungen bei der Neukonfiguration der Kamera zu vermeiden. Siehe Sitzungsrekonfigurationsabfrage .
  • HAL-Pufferverwaltungs-APIs : Diese APIs ermöglichen es der Kamera-HAL, Puffer nur bei Bedarf vom Kamera-Framework anzufordern, anstatt jede Aufnahmeanforderung mit den zugehörigen Puffern in der gesamten Kamera-Pipeline zu koppeln, was zu potenziell erheblichen Speichereinsparungen führt.
    • signalStreamFlush : Signalisiert der HAL, dass der Kameradienst im Begriff ist, configureStreams_3_5 auszuführen, 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 zu prüfen, ob eine Race-Bedingung zwischen den Aufrufen configureStreams_3_5 und signalStreamFlush vorliegt.

Aktualisierungen für ICameraDeviceCallback :

  • requestStreamBuffers : Synchroner Rückruf, den die Kamera-HAL aufruft, um den Kameraserver nach Puffern zu fragen. Siehe requestStreamBuffers .
  • returnStreamBuffers : Synchroner Rückruf für die Kamera-HAL, um Ausgabepuffer an den Kameraserver zurückzugeben. Siehe 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
  • Kamera-Metadaten-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
  • Fähigkeiten
    • 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 dynamische Tiefenstromkonfigurationen
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Verfügbare HEIC-Stream-Konfigurationen
    • 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 für Geräte hinzu, um die Kamera-HAL zu benachrichtigen, wenn physische Änderungen, wie z. B. Falten, Kamera und Routing beeinflussen.

2.4

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

Android 9

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

Kamera-API

  • Führt die Multikamera-API ein, um Geräte mit mehreren in die gleiche Richtung gerichteten Kameras besser zu unterstützen und Funktionen wie Bokeh und nahtlosen Zoom zu ermöglichen. Dadurch 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 von einer logischen Kamera umfasst werden. Siehe Multi-Kamera-Unterstützung .
  • Führt Sitzungsparameter ein. Sitzungsparameter sind eine Teilmenge der verfügbaren Erfassungsparameter, deren Änderung zu erheblichen Verarbeitungsverzögerungen führen kann. Diese Kosten können gemindert werden, wenn Clients ihre Anfangswerte während der Initialisierung der Erfassungssitzung übergeben. Siehe Sitzungsparameter .
  • Fügt optische Stabilisierungsdatenschlüssel (OIS) für Stabilisierung und Effekte auf App-Ebene hinzu. Siehe STATISTICS_OIS_SAMPLES .
  • Fügt externe Flash-Unterstützung hinzu. Siehe CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Fügt eine Bewegungsverfolgungsabsicht in CAPTURE_INTENT hinzu. Siehe CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Verwirft LENS_RADIAL_DISTORTION und fügt stattdessen LENS_DISTORTION hinzu.
  • Fügt Verzerrungskorrekturmodi in CaptureRequest hinzu. Siehe DISTORTION_CORRECTION_MODE .
  • Fügt Unterstützung für externe USB-/UVC-Kameras auf unterstützten Geräten hinzu. Siehe 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.

  • Fähigkeiten
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Kamera-Metadaten-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 wird Treble eingeführt. Bei Treble müssen Kamera-HAL-Implementierungen des Anbieters binderisiert werden. Android 8.0 enthält außerdem diese wichtigen Verbesserungen des Kameradienstes:

  • Gemeinsame Oberflächen: Aktivieren Sie mehrere Oberflächen, die dieselbe OutputConfiguration teilen
  • System-API für benutzerdefinierte Kameramodi
  • onCaptureQueueEmpty

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

Gemeinsame Oberflächen

Mit dieser Funktion kann nur ein Puffersatz zwei Ausgaben steuern, z. B. Vorschau und Videokodierung, was den Strom- und Speicherverbrauch senkt. Um diese Funktion zu unterstützen, müssen Gerätehersteller sicherstellen, dass ihre Kamera-HAL- und Gralloc-HAL-Implementierungen Gralloc-Puffer erstellen können, die von mehreren verschiedenen Verbrauchern (z. B. dem Hardware-Composer/GPU und dem Video-Encoder) und nicht nur einem Verbraucher verwendet werden. Der Kameradienst übergibt die Verbrauchernutzungsflags an die Kamera-HAL und die Gralloc-HAL. Sie müssen entweder die richtigen Puffertypen zuweisen oder der Kamera-HAL muss einen Fehler zurückgeben, dass diese Verbraucherkombination nicht unterstützt wird.

Weitere Einzelheiten finden Sie in der Entwicklerdokumentation enableSurfaceSharing .

System-API für benutzerdefinierte Kameramodi

Die öffentliche Kamera-API definiert zwei Betriebsmodi: normale und eingeschränkte Hochgeschwindigkeitsaufzeichnung. Sie haben eine ziemlich unterschiedliche Semantik; Beispielsweise ist der Hochgeschwindigkeitsmodus auf höchstens zwei bestimmte Ausgänge gleichzeitig beschränkt. Verschiedene OEMs haben Interesse an der Definition anderer benutzerdefinierter Modi für hardwarespezifische Funktionen bekundet. Unter der Haube 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, den OEM-Kamera-Apps verwenden können, um einen benutzerdefinierten Modus zu aktivieren. 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, ausgelöst durch diese Ganzzahl, die auf configure_streams an den HAL übergeben wird, und dann ihre benutzerdefinierte Kamera-App die System-API verwenden lassen.

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 Steueränderungen wie Zoom zu reduzieren, indem die Anforderungswarteschlange so leer wie möglich gehalten wird. onCaptureQueueEmpty erfordert keine HAL-Arbeit; Es handelte sich lediglich um eine Framework-seitige Ergänzung. Anwendungen, die davon profitieren möchten, müssen diesem Rückruf einen Listener hinzufügen und entsprechend reagieren. Im Allgemeinen erfolgt dies durch Senden einer weiteren Aufnahmeanforderung an das Kameragerät.

Kamera-HIDL-Schnittstelle

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

3.4

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

  • Fügen Sie die statischen Metadaten ANDROID_SENSOR_OPAQUE_RAW_SIZE als obligatorisch hinzu, wenn RAW_OPAQUE Format unterstützt wird.
  • Fügen Sie die statischen Metadaten ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE als obligatorisch hinzu, wenn ein RAW-Format unterstützt wird.
  • Stellen Sie das Feld camera3_stream_t data_space auf eine flexiblere Definition um und verwenden Sie die Version 0-Definition der Datenraumkodierung.
  • Allgemeine Metadaten-Ergänzungen, die für HALv3.2 oder neuer 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 des HAL mit erweiterten Funktionen:

  • OPAQUE- und YUV-Wiederverarbeitungs-API-Updates.
  • Grundlegende Unterstützung für Tiefenausgabepuffer.
  • Hinzufügung des Feldes data_space zu camera3_stream_t .
  • Hinzufügung eines Rotationsfelds zu camera3_stream_t .
  • Hinzufügung des Betriebsmodus „Kamera3-Stream-Konfiguration“ zu camera3_stream_configuration_t .

3.2

Kleinere Überarbeitung des HAL mit erweiterten Funktionen:

  • get_metadata_vendor_tag_ops ist veraltet. Verwenden Sie stattdessen get_vendor_tag_ops in camera_common.h .
  • register_stream_buffers ist veraltet. Alle vom Framework für HAL in process_capture_request bereitgestellten Gralloc-Puffer können jederzeit neu sein.
  • Teilergebnisunterstützung hinzufügen. process_capture_result kann mehrmals mit einer Teilmenge der verfügbaren Ergebnisse aufgerufen werden, bevor das vollständige Ergebnis verfügbar ist.
  • Manuelle Vorlage zu camera3_request_template hinzufügen. Anwendungen können diese Vorlage verwenden, um die Aufnahmeeinstellungen direkt zu steuern.
  • Überarbeiten Sie die bidirektionalen und Eingabestream-Spezifikationen.
  • Ä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 übergibt Verbrauchernutzungsflags an die HAL.
  • Flush-Aufruf, um alle In-Flight-Anfragen/Puffer so schnell wie möglich zu löschen.

3,0

Erste Überarbeitung des HAL mit erweiterten Funktionen:

  • Große Versionsänderung, da das ABI völlig anders ist. Keine Änderung der erforderlichen Hardwarefunktionen oder des Betriebsmodells gegenüber 2.0.
  • Überarbeitete Eingabeanforderungs- und Stream-Warteschlangenschnittstellen: Framework-Aufrufe in HAL mit bereits aus der Warteschlange entfernten nächsten Anforderungs- und Stream-Puffer. Die Unterstützung des Sync-Frameworks ist enthalten, was für effiziente Implementierungen erforderlich ist.
  • Auslöser wurden in Anfragen verschoben, die meisten Benachrichtigungen in Ergebnisse.
  • Alle Rückrufe im Framework in einer Struktur und alle Setup-Methoden in einem einzigen initialize() Aufruf zusammengefasst.
  • Die Stream-Konfiguration wurde in einem einzigen Aufruf zusammengefasst, um die Stream-Verwaltung zu vereinfachen. Bidirektionale Streams ersetzen das STREAM_FROM_STREAM -Konstrukt.
  • Semantik des eingeschränkten Modus für ältere/eingeschränkte Hardwaregeräte.

2,0

Erstveröffentlichung von 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 Kameradienstebene.
  • Nicht auf neue Funktionen wie manuelle Erfassungssteuerung, Bayer RAW-Erfassung, Neuverarbeitung von RAW-Daten usw. getestet.

1,0

Anfänglicher Android-Kamera-HAL (Android 4.0) [camera.h]:

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

Versionsgeschichte des Kameramoduls

Dieser Abschnitt enthält Informationen zur Modulversionierung für das Kamera-Hardwaremodul, basierend auf camera_module_t.common.module_api_version . Die beiden höchstwertigen Hexadezimalziffern repräsentieren die Hauptversion und die beiden niedrigstwertigen stellen die Nebenversion dar.

2.4

Diese Kameramodulversion fügt die folgenden API-Änderungen hinzu:

  1. Unterstützung des Taschenlampenmodus. Das Framework kann den Taschenlampenmodus für jedes Kameragerät mit Blitzgerät aktivieren, ohne ein Kameragerät öffnen zu müssen. Das Kameragerät hat beim Zugriff auf das Blitzgerät eine höhere Priorität als das Kameramodul. Durch Öffnen eines Kamerageräts wird die Taschenlampe ausgeschaltet, wenn dies über die Modulschnittstelle aktiviert wurde. Wenn Ressourcenkonflikte auftreten, beispielsweise wenn open() aufgerufen wird, um ein Kameragerät zu öffnen, muss das Kamera-HAL-Modul das Framework über den Statusrückruf für den Taschenlampenmodus darüber informieren, dass der Taschenlampenmodus ausgeschaltet wurde.
  2. Unterstützung für externe Kameras (z. B. USB-Hot-Plug-Kamera). 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 lautet. Das Framework verlässt sich ausschließlich auf Rückrufe zur Änderung des Gerätestatus, um die verfügbare externe Kameraliste zu verwalten.
  3. Hinweise zur Kamera-Schiedsgerichtsbarkeit. Integriert die Unterstützung für die explizite Angabe der Anzahl der Kamerageräte, 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 Struktur „ camera_info festgelegt werden, die vom Aufruf get_camera_info zurückgegeben wird.
  4. Modulinitialisierungsmethode. Wird vom Kameradienst aufgerufen, nachdem das HAL-Modul geladen wurde, um eine einmalige Initialisierung des HAL zu ermöglichen. Es wird aufgerufen, bevor andere Modulmethoden aufgerufen werden.

2.3

Diese Kameramodulversion bietet Unterstützung für offene Legacy-Kamera-HAL-Geräte. Das Framework kann damit das Kameragerät als HAL-Gerät mit niedrigerer Geräteversion öffnen, wenn dasselbe Gerät mehrere Geräte-API-Versionen unterstützen kann. Der Standardaufruf zum Öffnen des Hardwaremoduls ( common.methods->open ) öffnet das Kameragerät weiterhin mit der neuesten unterstützten Version, bei der es sich auch um die in camera_info_t.device_version aufgeführte Version handelt.

2.2

Diese Kameramodulversion fügt Hersteller-Tag-Unterstützung vom Modul hinzu und veraltet die alten vendor_tag_query_ops , auf die zuvor nur bei geöffnetem Gerät zugegriffen werden konnte.

2.1

Diese Kameramodulversion fügt dem Framework Unterstützung für asynchrone Rückrufe vom Kamera-HAL-Modul hinzu, die verwendet werden, um das Framework über Änderungen am Kameramodulstatus zu benachrichtigen. 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 entweder Version 1.0 oder Version 2.0 der HAL-Schnittstelle des Kamerageräts. 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 anfängliche HAL-Schnittstelle des Kameramoduls. Alle Kamerageräte, die über dieses Modul geöffnet werden können, unterstützen nur Version 1 des Kamerageräts 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.