Unterstützung der Kameraversion

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite werden Versionsunterschiede in Kamera-HALs, APIs und zugehörigen Tests der Compatibility Test Suite (CTS) beschrieben. Es behandelt auch mehrere architektonische Änderungen, die vorgenommen wurden, um das Kamera-Framework in Android 7.0 zu härten und zu sichern, 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 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 android.hardware.Camera -Klasse.
Kamera-API2
Das Kamera-Framework auf App-Ebene auf Geräten mit Android 5.0 und höher, verfügbar gemacht durch das android.hardware.camera2 -Paket.
Kamera HAL
Die von SoC-Anbietern implementierte Kameramodulschicht. Die öffentlichen Frameworks auf App-Ebene bauen auf der Kamera-HAL auf.
Kamera HAL3.1
Version des Kamerageräts HAL veröffentlicht mit Android 4.4.
Kamera HAL3.2
Version des Kamerageräts HAL veröffentlicht mit Android 5.0.
Kamera API1 CTS
Satz von Kamera-CTS-Tests, die auf Kamera-API1 ausgeführt werden.
Kamera API2 CTS
Zusätzlicher Satz von Kamera-CTS-Tests, die auf Kamera-API2 ausgeführt werden.
Verdreifachen
Trennt die Anbieterimplementierung (gerätespezifische, untergeordnete Software, die von Siliziumherstellern geschrieben wurde) vom Android-Betriebssystem-Framework durch eine neue Anbieterschnittstelle.
HIDL
HAL-Schnittstellendefinitionssprache, die mit Treble eingeführt wurde und verwendet wird, um die Schnittstelle zwischen einer HAL und ihren Benutzern zu spezifizieren.
VTS
Hersteller-Testsuite zusammen mit Treble eingeführt.

Kamera-APIs

Android enthält die folgenden Kamera-APIs.

Kamera-API1

Android 5.0 hat die Kamera-API1 verworfen, die weiterhin ausläuft, da sich die Entwicklung neuer Plattformen auf die Kamera-API2 konzentriert. Die Auslaufphase wird jedoch langwierig sein, und Android-Releases werden Kamera-API1-Apps noch einige Zeit unterstützen. Insbesondere wird die Unterstützung fortgesetzt für:

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

Kamera-API2

Das Kamera-API2-Framework stellt der App eine niedrigere Kamerasteuerung zur Verfügung, einschließlich effizienter Zero-Copy-Burst-/Streaming-Flüsse und Einzelbildsteuerungen für Belichtung, Verstärkung, Weißabgleichsverstärkung, Farbkonvertierung, Rauschunterdrückung, Schärfen und mehr. Einzelheiten finden Sie in der Videoübersicht zur Google I/O .

Android 5.0 und höher enthält Camera API2; Geräte mit Android 5.0 und höher unterstützen jedoch 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ützungsebenen:

  • LEGACY : Diese Geräte stellen Apps über die Kamera-API2-Schnittstellen Funktionen zur Verfügung, die ungefähr dieselben Funktionen sind wie die, die Apps über die Kamera-API1-Schnittstellen bereitgestellt werden. Der Legacy-Framework-Code übersetzt Kamera-API2-Aufrufe konzeptionell in Kamera-API1-Aufrufe; Legacy-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-Wiederverarbeitung und RAW-Bilderfassung zusammen mit zusätzlichen Ausgabestromkonfigurationen.
  • EXTERNAL : Diese Geräte ähneln LIMITED Geräten mit einigen Ausnahmen; Beispielsweise werden einige Sensor- oder Objektivinformationen möglicherweise nicht gemeldet oder weisen weniger stabile Bildraten auf. 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 sogar für FULL -Geräte optional. LIMITED Geräte können jede Teilmenge dieser Funktionen ankündigen, einschließlich keiner davon. Die BACKWARD_COMPATIBLE Fähigkeit muss jedoch immer definiert werden.

Die unterstützte Hardwarestufe des Geräts sowie die spezifischen Kamera-API2-Funktionen, die es unterstützt, sind als die folgenden Feature-Flags verfügbar, um Google Play das Filtern von Kamera-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 keine Kamera-HAL3.2-Implementierung aufweisen und nicht in der Lage sind, die vollständigen Kamera-API2-Schnittstellen zu unterstützen, müssen dennoch die Kamera-API2-CTS-Tests bestehen. Das Gerät wird jedoch im Kamera-API2- LEGACY Modus ausgeführt (in dem die Kamera-API2-Aufrufe konzeptionell den Kamera-API1-Aufrufen zugeordnet sind), sodass alle Kamera-API2-CTS-Tests, die sich auf Funktionen oder Fähigkeiten jenseits der Kamera-API1 beziehen, automatisch übersprungen werden.

Auf älteren Geräten verwenden Kamera-API2-CTS-Tests, die ausgeführt werden, die vorhandenen öffentlichen Kamera-API1-Schnittstellen und -Funktionen ohne neue Anforderungen. Aufgedeckte Fehler (die einen Kamera-API2-CTS-Fehler verursachen) sind Fehler, die bereits in der vorhandenen Kamera-HAL des Geräts vorhanden sind und daher von vorhandenen Kamera-API1-Apps gefunden würden. Wir erwarten nicht viele Fehler dieser Art (jedoch müssen solche Fehler behoben werden, um die Kamera-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ärten des Kameragerüsts

Um die Sicherheit des Medien- und Kamera-Frameworks zu erhöhen, verschiebt Android 7.0 den Kameradienst aus dem Medienserver. Beginnend mit Android 8.0 wird jede gebundene Kamera-HAL in einem Prozess ausgeführt, der vom Kameradienst getrennt ist. Je nach verwendeter API- und HAL-Version müssen Anbieter möglicherweise Änderungen an der Kamera-HAL vornehmen. Die folgenden Abschnitte beschreiben architektonische Änderungen in AP1 und AP2 für HAL1 und HAL3 sowie allgemeine Anforderungen.

Architekturänderungen für API1

Die API1-Videoaufzeichnung kann Kamera und Video-Encoder live im selben Prozess übernehmen. Bei Verwendung von API1 auf:

  • HAL3, wo der Kameradienst BufferQueue verwendet, um Puffer zwischen Prozessen zu übergeben, ist keine Herstelleraktualisierung erforderlich.

    Android 7.0-Kamera und Medienstapel in API1 auf HAL3

    Abbildung 1. Kamera- und Medienstapel von 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.)

    Android 7.0-Kamera und Medienstapel in API1 auf HAL1

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

Architekturänderungen für API2

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

  • HAL1 ist von der Verschiebung des Kameradienstes nicht betroffen, und es ist keine Aktualisierung des Anbieters erforderlich.
  • HAL3 ist betroffen, aber es ist kein Hersteller-Update erforderlich:

    Android 7.0-Kamera und Medienstapel in API2 auf HAL3

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

Zusätzliche Anforderungen

Die architektonischen Änderungen, die zur Härtung von Medien- und Kamera-Framework-Sicherheit 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 Hochgeschwindigkeitsvideoaufzeichnung auswirken kann. Anbieter können die tatsächlichen Auswirkungen 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 auch eine kleine Menge an zusätzlichem RAM, um den neuen Prozess zu erstellen.
  • Übergeben Sie Metadaten in Videopuffern ( nur HAL1 ). Wenn HAL1 Metadaten anstelle von echten YUV-Framedaten in Videopuffern speichert, muss 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 übergeben, 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 Puffer-Handles. HAL kann die Adressen nicht verwenden, um Puffer zu identifizieren, da die Adressen möglicherweise ein anderes Puffer-Handle speichern, nachdem HAL den Puffer zurückgibt. Sie müssen die HAL aktualisieren, um Puffer-Handles zum Identifizieren der Puffer zu verwenden. Zum Beispiel empfängt HAL eine Puffer-Handle-Adresse A, die Puffer-Handle A speichert. Nachdem HAL Puffer-Handle A zurückgibt, kann Puffer-Handle-Adresse A Puffer-Handle B speichern, wenn HAL sie das nächste Mal empfängt.
  • Aktualisieren Sie die SELinux-Richtlinien für den Kameraserver. Wenn gerätespezifische SELinux-Richtlinien dem Mediaserver Berechtigungen zum Ausführen der Kamera erteilen, müssen Sie die SELinux-Richtlinien aktualisieren, um dem Kameraserver die richtigen 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 benötigen). Cameraserver sollte nur die Berechtigungen haben, die zum Ausführen von Kamerafunktionen erforderlich sind, und alle unnötigen kamerabezogenen Berechtigungen in Mediaserver sollten entfernt werden.
  • Trennung zwischen Kamera HAL und Kameraserver. Android 8.0 und höher trennt zusätzlich die gebundene Kamera-HAL in einem anderen Prozess als der Kameraserver. IPC geht durch HIDL-definierte Schnittstellen.

Validierung

Überprüfen Sie für alle Geräte, die eine Kamera enthalten und auf denen Android 7.0 ausgeführt wird, die Implementierung, indem Sie Android 7.0 CTS ausführen. Obwohl Android 7.0 keine neuen CTS-Tests enthält, die Änderungen am Kameradienst überprüfen, schlagen vorhandene CTS-Tests fehl, wenn Sie die oben angegebenen Updates nicht vorgenommen haben.

Überprüfen Sie für alle Geräte, die eine Kamera enthalten und auf denen Android 8.0 oder höher ausgeführt wird, die Herstellerimplementierung, indem Sie VTS ausführen.

Kamera-HAL-Versionsverlauf

Eine Liste der verfügbaren Tests zur Bewertung der Android-Kamera-HAL finden Sie in der Kamera-HAL-Test-Checkliste .

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, mit der Clients abfragen können, 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-Rekonfiguration 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 Abfrage zur Sitzungsneukonfiguration .
  • HAL-Pufferverwaltungs-APIs : Diese APIs ermöglichen es der Kamera-HAL, nur bei Bedarf Puffer vom Kamera-Framework anzufordern, anstatt jede Erfassungsanforderung 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 bereitgestellt, um zwischen den Aufrufen von configureStreams_3_5 und signalStreamFlush auf eine Wettlaufbedingung zu prüfen.

Aktualisierungen von 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 Kamera-Metadaten 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 Methode „ notifyDeviceStateChange “ für Geräte hinzu, um die Kamera-HAL zu benachrichtigen, wenn sich physische Änderungen wie das Zusammenklappen auf die Kamera und das Routing auswirken.

2.4

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

Android 9

Die Android 9-Version führt die folgenden Updates für die Kamera-API2 und die HAL-Schnittstelle ein.

Kamera-API

  • Führt die Multi-Kamera-API ein, um Geräte mit mehreren Kameras, die in die gleiche Richtung zeigen, 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. Aufnahmeanforderungen können auch an einzelne Kamerageräte gesendet werden, die von einer logischen Kamera umfasst sind. Siehe Multi-Kamera-Unterstützung .
  • Führt Sitzungsparameter ein. Sitzungsparameter sind eine Teilmenge der verfügbaren Erfassungsparameter, die bei Änderung zu erheblichen Verarbeitungsverzögerungen führen können. Diese Kosten können verringert werden, wenn Clients ihre Anfangswerte während der Initialisierung der Erfassungssitzung übergeben. Siehe Sitzungsparameter .
  • Fügt Datenschlüssel für optische Stabilisierung (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 . Siehe CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • LENS_RADIAL_DISTORTION und fügt LENS_DISTORTION an seiner Stelle hinzu.
  • Fügt Verzerrungskorrekturmodi in CaptureRequest . 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

Updates für ICameraDeviceSession

Updates für ICameraDeviceCallback

3.3

Die folgenden Schlüssel werden den Kamera-Metadaten 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

Die Android 8.0-Version führt Treble ein. Bei Treble müssen Kamera-HAL-Implementierungen von Anbietern 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

Diese Funktion ermöglicht es, dass nur ein Puffersatz zwei Ausgaben ansteuert, wie z. B. Vorschau und Videocodierung, wodurch der Stromverbrauch und der Speicherverbrauch gesenkt werden. 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 Videoencoder) und nicht nur von einem Verbraucher verwendet werden. Der Kameradienst übergibt die Consumer-Usage-Flags an die Kamera-HAL und die Gralloc-HAL; Sie 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 Einzelheiten finden Sie in der enableSurfaceSharing Entwicklerdokumentation.

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 bekundet, andere benutzerdefinierte Modi für hardwarespezifische Fähigkeiten zu definieren. 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 beim ganzzahligen Wert 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, ausgelöst durch diese Ganzzahl, die an die HAL auf configure_streams ü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 Steuerungsänderungen wie Zoom zu reduzieren, indem die Anforderungswarteschlange so leer wie möglich gehalten wird. onCaptureQueueEmpty erfordert keine HAL-Arbeit; es war eine reine Framework-seitige Ergänzung. Anwendungen, die davon profitieren möchten, müssen diesem Callback einen Listener hinzufügen und entsprechend reagieren. Im Allgemeinen geschieht dies durch Senden einer weiteren Aufnahmeanforderung an das Kameragerät.

Kamera-HIDL-Schnittstelle

Die Kamera-HIDL-Schnittstelle ist eine vollständige Überarbeitung der Kamera-HAL-Schnittstelle, die stabile HIDL-definierte APIs verwendet. Alle Features und Kamerafähigkeiten, die in den neuesten Legacy-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 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 ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statische Metadaten als obligatorisch hinzu, wenn RAW-Formate unterstützt werden.
  • Stellen Sie das Feld camera3_stream_t data_space auf eine flexiblere Definition um, indem Sie die Definition der Version 0 der Datenraumcodierung verwenden.
  • 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 der HAL mit erweiterten Fähigkeiten:

  • OPAQUE- und YUV-Wiederverarbeitungs-API-Updates.
  • Grundlegende Unterstützung für Tiefenausgabepuffer.
  • Hinzufügen des data_space zu camera3_stream_t .
  • Hinzufügen eines Rotationsfelds zu camera3_stream_t .
  • Hinzufügen des Kamera3-Stream-Konfigurationsbetriebsmodus zu camera3_stream_configuration_t .

3.2

Kleinere Überarbeitung der HAL mit erweiterten Fähigkeiten:

  • Veraltet get_metadata_vendor_tag_ops . Verwenden Sie stattdessen get_vendor_tag_ops in camera_common.h .
  • Verwirft register_stream_buffers . Alle Gralloc-Puffer, die vom Framework für HAL in process_capture_request bereitgestellt werden, können jederzeit neu sein.
  • Unterstützung für Teilergebnisse hinzufügen. process_capture_result kann mehrere Male mit einer Teilmenge der verfügbaren Ergebnisse aufgerufen werden, bevor das vollständige Ergebnis verfügbar ist.
  • Manuelle Vorlage zu camera3_request_template . Anwendungen können diese Vorlage verwenden, um die Erfassungseinstellungen direkt zu steuern.
  • Überarbeiten Sie die bidirektionalen und Input-Stream-Spezifikationen.
  • Ändern Sie den Rückgabepfad des Eingangspuffers. Der Puffer wird in process_capture_result statt in process_capture_request .

3.1

Kleinere Überarbeitung der HAL mit erweiterten Fähigkeiten:

  • configure_streams übergibt Consumer-Usage-Flags an die HAL.
  • Flush-Aufruf, um alle In-Flight-Anforderungen/Puffer so schnell wie möglich zu löschen.

3.0

Erste Überarbeitung von HAL mit erweiterten Fähigkeiten:

  • Große Versionsänderung, da die ABI völlig anders ist. Keine Änderung der erforderlichen Hardwarefunktionen oder des Betriebsmodells von 2.0.
  • Überarbeitete Schnittstellen für Eingabeanfragen und Stream-Warteschlangen: Framework-Aufrufe in HAL, wobei die nächste Anfrage und Stream-Puffer bereits aus der Warteschlange entfernt wurden. Sync-Framework-Unterstützung ist enthalten, notwendig für effiziente Implementierungen.
  • Trigger in Anfragen verschoben, die meisten Benachrichtigungen in Ergebnisse.
  • Konsolidierte alle Callbacks in das Framework in einer Struktur und alle Setup-Methoden in einem einzigen initialize() Aufruf.
  • Die Stream-Konfiguration wurde zu einem einzigen Aufruf gemacht, um das Stream-Management zu vereinfachen. Bidirektionale Streams ersetzen das Konstrukt STREAM_FROM_STREAM .
  • 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 vorhandener android.hardware.Camera API.
  • Ermöglicht die ZSL-Warteschlange in der Kameradienstebene.
  • Nicht auf neue Funktionen wie manuelle Erfassungssteuerung, Bayer-RAW-Erfassung, Wiederverarbeitung von RAW-Daten usw. getestet.

1.0

Anfängliche 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 Modulversionsinformationen für das Kamera-Hardwaremodul, basierend auf camera_module_t.common.module_api_version . Die beiden höchstwertigen Hexadezimalziffern stellen die Hauptversion dar, und die beiden niederwertigsten 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 aktivieren, das über eine Blitzeinheit verfügt, ohne ein Kameragerät zu öffnen. Das Kameragerät hat eine höhere Priorität beim Zugriff auf das Blitzgerät als das Kameramodul; Das Öffnen eines Kamerageräts schaltet die Taschenlampe aus, wenn sie über die Modulschnittstelle aktiviert wurde. Wenn Ressourcenkonflikte auftreten, z. B. wenn open() aufgerufen wird, um ein Kameragerät zu öffnen, muss das HAL-Modul der Kamera das Framework durch den Torch-Modus-Statusrückruf benachrichtigen, dass der Torch-Modus 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 . Das Framework zählt ausschließlich auf Gerätestatusänderungsrückrufe, um die Liste der verfügbaren externen Kameras zu verwalten.
  3. Hinweise zur Kamera-Arbitrierung. Fügt Unterstützung für die explizite Angabe der Anzahl von Kamerageräten hinzu, die gleichzeitig geöffnet und verwendet werden können. Um gültige Kombinationen von Geräten anzugeben, sollten die Felder resource_cost und conflicting_devices immer in der vom get_camera_info Aufruf zurückgegebenen camera_info -Struktur festgelegt werden.
  4. Modul-Initialisierungsmethode. 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 fügt Unterstützung für HAL-Geräte für offene Legacy-Kameras hinzu. Das Framework kann es verwenden, um das Kameragerät als HAL-Gerät mit niedrigerer Geräteversion zu öffnen, wenn dasselbe Gerät mehrere Geräte-API-Versionen unterstützen kann. Der Aufruf zum Öffnen des Standardhardwaremoduls ( common.methods->open ) öffnet weiterhin das Kameragerät mit der neuesten unterstützten Version, die auch die in camera_info_t.device_version aufgeführte Version ist.

2.2

Diese Version des Kameramoduls fügt Vendor-Tag-Unterstützung aus dem 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, das verwendet wird, um das Framework über Änderungen am Kameramodulzustand zu benachrichtigen. Module, die eine gültige Methode set_callbacks() , müssen mindestens diese Versionsnummer melden.

2.0

Kameramodule, die diese Versionsnummer melden, implementieren die zweite Version der Kameramodul-HAL-Schnittstelle. Kamerageräte, die durch dieses Modul geöffnet werden können, können entweder Version 1.0 oder Version 2.0 der HAL-Schnittstelle des Kamerageräts unterstützen. 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 Kameramodul-HAL-Schnittstelle. 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 nicht gültig. Nur die android.hardware.Camera API kann von diesem Modul und seinen Geräten unterstützt werden.