Unterstützung von Kameraversionen

Auf dieser Seite werden die Versionsunterschiede in Kamera-HALs, APIs und zugehörigen Tests der Kompatibilitätstest-Suite (CTS) Sie umfasst auch mehrere Änderungen an der Architektur, um das Kamera-Framework in Android zu härten und zu sichern 7.0, der Wechsel zu Treble in Android 8.0 und die Updates, die Anbieter vornehmen müssen, die diese Änderungen bei der Kameraimplementierung unterstützen.

Terminologie

Auf dieser Seite werden die folgenden Begriffe verwendet:

Kamera-API1
Das Kamera-Framework für Geräte mit Android 4.4 und niedriger auf App-Ebene, durch die Klasse android.hardware.Camera.
Kamera-API2
Das Kamera-Framework für Geräte mit Android 5.0 und höher auf App-Ebene über das android.hardware.camera2-Paket.
Kamera HAL
Die von SoC-Anbietern implementierte Ebene des Kameramoduls. Die öffentliche Anzeige auf App-Ebene Framework auf dem Kamera-HAL.
Kamera HAL3.1
Version des Kamerageräts HAL, veröffentlicht mit Android 4.4.
Kamera HAL3.2
Version des Kamerageräts HAL, das mit Android 5.0 veröffentlicht wurde.
Camera API1 CTS
Eine Reihe von CTS-Tests für Kameras, die zusätzlich zur Kamera ausgeführt werden API1.
Camera API2 CTS
Zusätzliche CTS-Tests für Kameras, die zusätzlich zur Camera API2 ausgeführt werden.
Höhen
Trennt die Anbieterimplementierung (gerätespezifische untergeordnete Software). von Siliziumherstellern) aus dem Framework des Android-Betriebssystems durch eine neue die Benutzeroberfläche des Anbieters.
HIDL
HAL-Schnittstellendefinition mit Treble eingeführt und zur Angabe der Schnittstelle zwischen einem HAL und für die Nutzenden.
VTS
Anbieter-Testsuite zusammen mit Höhen.

Kamera-APIs

Android enthält die folgenden Kamera-APIs.

Kamera-API1

Unter Android 5.0 wurde die Camera API1 eingestellt, die nach und nach konzentriert sich bei der Plattformentwicklung auf die Camera API2. Die Phase der Einstellungsphase und Android-Releases werden weiterhin Camera API1-Apps für etwas Zeit widmen. Insbesondere in folgenden Bereichen werden weiterhin Support angeboten:

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

Kamera-API2

Das Camera API2-Framework ermöglicht der App die Kamerasteuerung auf niedrigerer Ebene. einschließlich effizienter Zero-Copy-Burst-/Streaming-Abläufe und Kontrollen pro Frame Belichtung, Verstärkung, Erhöhung des Weißabgleichs, Farbkonvertierung, Rauschunterdrückung, Schärfe, und vieles mehr. Weitere Informationen finden Sie in der <ph type="x-smartling-placeholder"></ph> Video 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 möglicherweise nicht alle Kamera-API2-Funktionen. Die Property android.info.supportedHardwareLevel, die Apps abfragen können über die Camera API2-Oberflächen eine der folgenden Unterstützungsstufen meldet Stufen:

  • LEGACY: Diese Geräte stellen Apps Funktionen über die Camera API2-Schnittstellen mit ungefähr denselben Funktionen wie die die Apps über die Camera API1-Schnittstellen zugänglich sind. Der Code der Legacy-Frameworks Kamera-API2-Aufrufe konzeptionell in Kamera-API1-Aufrufe umwandeln; Legacy-Geräte unterstützen keine Kamera-API2-Funktionen wie Steuerelemente für einzelne Frames.
  • LIMITED: Diese Geräte unterstützen einige Funktionen der Camera API2. (aber nicht alle) und muss Kamera HAL 3.2 oder höher verwenden.
  • FULL: Diese Geräte unterstützen alle wichtigen Funktionen von Camera API2 und muss Camera HAL 3.2 oder höher und Android 5.0 oder höher verwenden.
  • LEVEL_3: Diese Geräte unterstützen die erneute Verarbeitung von YUV und RAW-Bilder. sowie zusätzliche Ausgabestream-Konfigurationen.
  • EXTERNAL: Diese Geräte ähneln LIMITED Geräte mit einigen Ausnahmen; Einige Sensor- oder Objektivinformationen nicht gemeldet werden oder eine weniger stabile Framerate haben. Diese Ebene wird für externe wie z. B. USB-Webcams.

Einzelne Funktionen werden über die Eigenschaft android.request.availableCapabilities in der Camera API2 Schnittstellen. Für FULL-Geräte sind die MANUAL_SENSOR und MANUAL_POST_PROCESSING-Funktionen. Die Die RAW-Funktion ist sogar für FULL-Geräte optional. Auf LIMITED-Geräten kann eine beliebige Untergruppe dieser Funktionen beworben werden, einschließlich keiner von ihnen. Die BACKWARD_COMPATIBLE-Funktion immer definiert werden.

Die unterstützte Hardwareebene des Geräts sowie die spezifische Kamera API2-Funktionen, die es unterstützt, sind als die folgenden Funktions-Flags verfügbar, Google Play-Filterung von Camera API2-Kamera-Apps zulassen

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

CTS-Anforderungen

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

Geräte ohne Kamera-HAL3.2-Implementierung die alle Camera API2-Schnittstellen unterstützen können, müssen dennoch die Kamera API2-CTS-Tests Das Gerät wird jedoch in der Camera API2 ausgeführt. LEGACY-Modus, in dem die Camera API2-Aufrufe konzeptionell zugeordnet werden Kamera-API1-Aufrufen hinzugefügt wurden), also Kamera-API2-CTS-Tests für Funktionen oder über die Camera API1 hinausgehende Funktionen, werden automatisch übersprungen.

Auf älteren Geräten nutzen Camera API2-CTS-Tests die bestehenden öffentlichen Camera API1-Schnittstellen und ‐Funktionen, Anforderungen. Mögliche Fehler, die einen Kamera-API2-CTS-Fehler verursachen in der bestehenden Kamera-HAL des Geräts bereits vorhanden sind. Kamera-API1-Apps gefunden werden. Wir rechnen nicht mit vielen Bugs dieser Art. Solche Fehler müssen jedoch behoben werden, um die CTS-Tests der Camera API2 zu bestehen.

VTS-Anforderungen

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

Härtung des Kamerarahmens

Um die Sicherheit von Medien- und Kamera-Frameworks zu erhöhen, wird Android 7.0 außerhalb des Mediaservers. Ab Android 8.0 ist jede gebundene Kamera HAL wird in einem vom Kameradienst getrennten Prozess ausgeführt. Zulieferunternehmen müssen möglicherweise Änderungen im Kamera-HAL, je nachdem, welche API- und HAL-Versionen verwendet werden. Die In den folgenden Abschnitten werden Architekturänderungen in AP1 und AP2 für HAL1 und HAL3 sowie die allgemeinen Anforderungen.

Architekturänderungen für API1

Für die API1-Videoaufzeichnung wird möglicherweise vorausgesetzt, dass Kamera und Video-Encoder im selben . Wenn API1 auf folgenden Geräten verwendet wird:

  • HAL3, bei der der Kameradienst BufferQueue verwendet, um Puffer zwischen ist kein Update des Anbieters erforderlich.

    Android 7.0 – Kamera und Medien Stapel in API1 auf HAL3

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

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

    Android 7.0 – Kamera und Medien Stapel in API1 auf HAL1

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

Architekturänderungen für API2

Bei API2 auf HAL1 oder HAL3 übergibt die BufferQueue Puffer, damit diese Pfade fortgesetzt werden. zu arbeiten. Die Android 7.0-Architektur für API2 auf:

  • HAL1 ist von der Verschiebung des Kameradienstes nicht betroffen und kein Anbieter Update erforderlich.
  • HAL3 ist betroffen, aber es ist kein Anbieterupdate vorhanden notwendig:

    Android 7.0-Kamera und Mediastack in API2 auf HAL3

    Abbildung 3: Android 7.0-Kamera und -Medien Stapel in API2 auf HAL3

Zusätzliche Anforderungen

Die architektonischen Veränderungen, die durch die Härtung des Medien- und Kamera-Frameworks vorgenommen wurden die folgenden zusätzlichen Geräteanforderungen umfassen.

  • Allgemeines. Geräte benötigen aufgrund des IPC zusätzliche Bandbreite, was sich auf zeitkritische Kameraanwendungsfälle wie Hochgeschwindigkeitsvideos auswirken kann. Aufzeichnung. Anbieter können die tatsächliche Auswirkung messen, indem sie android.hardware.camera2.cts.PerformanceTest und Google Kamera App für Hochgeschwindigkeits-Videoaufnahmen mit 120/240 fps. Geräte benötigen außerdem eine zusätzlichen RAM, um den neuen Prozess zu erstellen.
  • Metadaten in Videozwischenspeichern übergeben (nur HAL1). Wenn HAL1 Metadaten anstelle von echten YUV-Frame-Daten in Videopuffern speichert, muss der HAL kMetadataBufferTypeNativeHandleSource als Metadatenpuffer verwenden Geben Sie VideoNativeHandleMetadata in Videozwischenspeichern ein und übergeben Sie sie. (kMetadataBufferTypeCameraSource wird auf Android nicht mehr unterstützt) 7.0.) Mit VideoNativeHandleMetadata, Kamera- und Medien-Frameworks können die Videopuffer zwischen Prozessen weiterleiten, indem sie nativen Handles korrekt deserialisiert.
  • Die Adresse des Zwischenspeichers speichert nicht immer denselben Zwischenspeicher. (nur HAL3). Für jede Erfassungsanfrage erhält HAL3 die Zwischenspeicheradressen Aliasse. HAL kann die Adressen nicht zum Identifizieren von Puffern verwenden, da die Adressen kann ein weiteres Puffer-Handle speichern, nachdem HAL den Zwischenspeicher zurückgegeben hat. Aktualisierung erforderlich HAL, um die Puffer mithilfe von Ziehpunkten zu identifizieren. HAL empfängt beispielsweise eine Puffer-Handle-Adresse A, die Puffer-Handle A speichert. Nachdem HAL zurückgegeben wurde Puffer-Handle A kann Puffer-Handle B gespeichert werden, wenn HAL empfängt ihn.
  • SELinux-Richtlinien für Kameraserver aktualisieren Wenn gerätespezifische SELinux-Richtlinien gewähren Medienservern Berechtigungen zum Ausführen der Kamera, müssen Sie die SELinux-Richtlinien aktualisieren, um dem Kameraserver die entsprechenden Berechtigungen zu erteilen. Mi. Sie raten davon ab, die SELinux-Richtlinien des Mediaservers für den Kameraserver zu replizieren. da mediaserver und cameraserver in der Regel unterschiedliche Ressourcen System). Der Kameraserver sollte nur die Berechtigungen haben, die zum Ausführen der Kamera erforderlich sind und unnötige kamerabezogene Berechtigungen auf dem Mediaserver, entfernt werden sollte.
  • Trennung zwischen Kamera-HAL und Kameraserver. Android-Geräte Ab Version 8.0 wird die gebundene Kamera-HAL außerdem in einem weiteren Prozess getrennt. vom Kameraserver. IPC durchläuft HIDL-definierte Schnittstellen.

Zertifizierungsstufe

Überprüfen Sie bei allen Geräten mit Kamera und Android 7.0 die mit Android 7.0 CTS implementieren. Obwohl Android 7.0 keine Neue CTS-Tests zum Prüfen von Änderungen am Kameradienst; bestehende CTS-Tests schlagen fehl wenn Sie die oben genannten Änderungen nicht vorgenommen haben.

Überprüfen Sie bei allen Geräten mit Kamera und Android 8.0 oder höher, Anbieterimplementierung mithilfe von VTS.

Kamera-HAL-Versionsverlauf

Eine Liste der verfügbaren Tests zur Bewertung des HAL von Android Camera finden Sie auf der Kamera-HAL-Test Checkliste.

Android 10

Mit Android 10 werden die folgenden Updates eingeführt.

Camera API

Kamera HAL

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

3,50

ICameraDevice

  • getPhysicalCameraCharacteristics: Die statischen Kamerainformationen für eine physische Kamera-ID, die eine logische Kameragerät. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> Unterstützung für mehrere Kameras
  • isStreamCombinationSupported: Diese Methode unterstützt eine öffentliche API, mit der Clients abfragen können, ob eine Sitzungskonfiguration unterstützt wird. Siehe API um Streamkombinationen abzufragen.

ICameraDeviceSession

  • isReconfigurationNeeded: Methode, die dem Kamerasystem mitteilt, ob der Stream vollständig ist ist eine Neukonfiguration für mögliche neue Sitzungsparameterwerte erforderlich. Dieses vermeidet unnötige Verzögerungen bei der Neukonfiguration der Kamera. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> Abfrage zur Neukonfiguration der Sitzung.
  • HAL APIs zur Zwischenspeicherverwaltung: Mit diesen APIs kann der Kamera-HAL puffert nur bei Bedarf die Kamera vom Kamerarahmen, statt sie zu koppeln mit den zugehörigen Puffern in der gesamten Kamera-Pipeline erfassen was potenziell zu erheblichen Einsparungen beim Arbeitsspeicher führt.
    • signalStreamFlush: signalisiert dem HAL, dass die Kamera Dienst configureStreams_3_5 ausführen soll und dass Der HAL muss alle Puffer bestimmter Streams zurückgeben.
    • configureStreams_3_5: Ähnlich wie ICameraDevice3.4.configureStreams, aber in Außerdem wird der Zähler streamConfigCounter an Suche nach einer Race-Bedingung zwischen configureStreams_3_5 und signalStreamFlush Anrufe.

Aktualisierungen für ICameraDeviceCallback:

  • requestStreamBuffers: Synchroner Callback, den der Kamera-HAL aufruft, um den Kameraserver anzufordern Puffer. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> requestStreamBuffers
  • returnStreamBuffers: Synchroner Callback für den Kamera-HAL, um Ausgabepuffer an den Kameraserver. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> returnStreamBuffers

3.4

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

  • Bildformate <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Kamera-Metadaten-Tags <ph type="x-smartling-placeholder">
      </ph>
    • 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
  • Leistungsspektrum <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Werte für ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT Taste <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Verfügbare Konfigurationen für dynamischen Tiefenstream <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Verfügbare HEIC-Streamkonfigurationen <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Kameramodul

Die folgenden Kameramodulversionen werden unter Android aktualisiert 10.

2,50

  • Fügt die Methode notifyDeviceStateChange für Geräte hinzu, die benachrichtigt werden sollen Kamera-HAL, wenn physische Änderungen, wie das Zusammenklappen, die Kamera und Routenplanung.

2.4

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

Android 9

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

Camera API

  • Einführung der API für mehrere Kameras zur besseren Unterstützung von Geräten mit mehreren Kamera, die in dieselbe Richtung zeigen, sodass Funktionen wie Bokeh- und nahtlosen Zoom. Dadurch können Apps mehrere Kameras auf einem Gerät als eine Kamera sehen Logische Einheit (logische Kamera) Erfassungsanfragen können auch an einzelne Personen Kamerageräte zusammen mit einer logischen Kamera. Weitere Informationen finden Sie unter Unterstützung für mehrere Kameras.
  • Stellt Sitzungsparameter vor. Sitzungsparameter sind eine Teilmenge der verfügbaren Erfassungsparametern, die zu erheblichen Verarbeitungsverzögerungen führen können, geändert. Diese Kosten können gemindert werden, wenn Clients ihre Anfangswerte übergeben. während der Initialisierung der Capture-Sitzung. Weitere Informationen finden Sie unter Sitzungsparameter:
  • Datenschlüssel zur optischen Stabilisierung (OIS) zur Stabilisierung auf App-Ebene Effekte. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> STATISTICS_OIS_SAMPLES
  • Zusätzliche Unterstützung für externen Flash. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> CONTROL_AE_MODE_ON_EXTERNAL_FLASH
  • Fügt einen Bewegungserkennungs-Intent in CAPTURE_INTENT hinzu. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> CONTROL_CAPTURE_INTENT_MOTION_TRACKING
  • LENS_RADIAL_DISTORTION wird eingestellt und hinzugefügt <ph type="x-smartling-placeholder"></ph> LENS_DISTORTION ersetzt.
  • Fügt Verzeichnungskorrekturmodi in CaptureRequest hinzu. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> DISTORTION_CORRECTION_MODE
  • Externe USB-/UVC-Kameras auf unterstützten Geräten werden unterstützt. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL

Kamera HAL

3.4

Aktualisierungen für ICameraDeviceSession

Aktualisierungen für ICameraDeviceCallback

3.3

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

  • Leistungsspektrum <ph type="x-smartling-placeholder">
      </ph>
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Kamera-Metadaten-Tags <ph type="x-smartling-placeholder">
      </ph>
    • 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-Version 8.0 wurde Treble eingeführt. Mit Höhen, Verkäufer Kamera HAL Implementierungen binderisiert. Auch für Android 8.0 enthält die folgenden wichtigen Verbesserungen am Kameradienst:

  • Gemeinsam genutzte Oberflächen: Mehrere Plattformen aktivieren, die sich auf die gleiche Weise teilen OutputConfiguration
  • System API für benutzerdefinierte Kameramodi
  • onCaptureQueueEmpty

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

Gemeinsam genutzte Plattformen

Diese Funktion ermöglicht nur einen Satz von Puffern, um zwei Ausgaben zu erzeugen, z. B. Vorschau und Videocodierung, wodurch der Strom- und Speicherverbrauch reduziert wird. Bis diese Funktion unterstützen, müssen Gerätehersteller sicherstellen, gralloc-HAL-Implementierungen können gralloc-Zwischenspeicher erstellen, die von mehreren verschiedenen Nutzern (z. B. Hardware-Komponisten/-GPU und Video) Encoder) statt nur einem Nutzer. Der Kameradienst übergibt Nutzungs-Flags an Kamera-HAL und gralloc-HAL; müssen sie entweder die richtigen Arten von Puffern zuteilen, oder der Kamera-HAL muss einen Fehler zurückgeben dass diese Nutzerkombination nicht unterstützt wird.

Siehe enableSurfaceSharing in der Entwicklerdokumentation.

System API für benutzerdefinierte Kameramodi

Die Public Camera API definiert zwei Betriebsmodi: „normal“ und „eingeschränkt“ Hochgeschwindigkeitsaufnahmen. Sie haben eine ziemlich unterschiedliche Semantik, zum Beispiel ist der Hochgeschwindigkeitsmodus auf maximal zwei bestimmte Ausgaben gleichzeitig beschränkt. Verschiedene OEMs haben Interesse an der Entwicklung weiterer benutzerdefinierter Modi für hardwarespezifischen Funktionen. Intern ist der Modus nur eine Ganzzahl an configure_streams übergeben. Weitere Informationen: <ph type="x-smartling-placeholder"></ph> hardware/camera/device/3.2/ICameraDeviceSession#configurestreams

Diese Funktion beinhaltet einen System-API-Aufruf, mit dem OEM-Kamera-Apps eine benutzerdefinierten Modus. Diese Modi müssen mit dem Ganzzahlwert 0x8000 beginnen, um Konflikte zu vermeiden. mit zukünftigen Modi zur öffentlichen API.

Um diese Funktion zu unterstützen, müssen OEMs lediglich den neuen Modus zu ihrem HAL hinzufügen, ausgelöst durch diese Ganzzahl, die an den HAL inconfigure_streams übergeben wird, und für ihre benutzerdefinierte Kamera-App die System-API verwenden.

Der Methodenname lautet android.hardware.camera2.CameraDevice#createCustomCaptureSession. Weitere Informationen: <ph type="x-smartling-placeholder"></ph> frameworks/base/core/java/android/hardware/camera2/CameraDevice

onCaptureQueueEmpty

Der Zweck dieser API ist es, die Latenz von Steuerungsänderungen wie Zoomen um sodass die Anfragewarteschlange so leer wie möglich bleibt. onCaptureQueueEmpty erfordert keine HAL-Arbeit; eine reine Ergänzung des Frameworks. Apps, die einen Listener für diesen Callback hinzufügen und auf die angemessen. Im Allgemeinen geschieht dies, indem Sie eine weitere Aufnahmeanfrage an die Kamera .

Kamera-HIDL-Schnittstelle

Die Camera HIDL-Oberfläche ist eine überarbeitete Version der Kamera-HAL-Oberfläche. die stabile HIDL-definierte APIs verwendet. Alle Funktionen und Kamerafunktionen Version 3.4 und 2.4 (für die Kamera Modul) auch Teil der HIDL-Definitionen.

3.4

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

  • Statische Metadaten vom Typ ANDROID_SENSOR_OPAQUE_RAW_SIZE als obligatorisch hinzufügen wenn das Format RAW_OPAQUE unterstützt wird.
  • Statisches ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE-Objekt hinzufügen Metadaten als obligatorisch, wenn ein RAW-Format unterstützt wird.
  • Feld „camera3_stream_t data_space“ auf ein flexibleres Feld umstellen unter Verwendung der Definition von Version 0 der Datenraumcodierung.
  • Allgemeine Metadaten-Ergänzungen, die für HALv3.2 oder höher verfügbar sind: <ph type="x-smartling-placeholder">
      </ph>
    • 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:

  • OPAQUE- und YUV-API-Aktualisierungen zur erneuten Verarbeitung
  • Grundlegende Unterstützung für Tiefenausgabepuffer.
  • Das Feld data_space wurde hinzugefügt zu camera3_stream_t.
  • camera3_stream_t wurde ein Rotationsfeld hinzugefügt.
  • Betriebsmodus für die Kamera 3-Streamkonfiguration hinzugefügt zu camera3_stream_configuration_t

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 Gralloc-Zwischenspeicher vom Framework für HAL in process_capture_request bereitgestellt, möglicherweise neu jederzeit ändern.
  • Unterstützung für Teilergebnisse hinzufügen. process_capture_result ist möglicherweise mit einer Teilmenge der verfügbaren Ergebnisse mehrmals aufgerufen werden, Ergebnis verfügbar ist.
  • Manuelle Vorlage zu camera3_request_template hinzufügen. Apps können diese Vorlage verwenden, um die Erfassungseinstellungen direkt zu steuern.
  • Spezifikationen für bidirektionales und Eingabestreams überarbeiten
  • Ändern Sie den Rückgabepfad des Eingabepuffers. Der Zwischenspeicher wird in process_capture_result statt process_capture_request.

3.1

Nebenversion des HAL mit erweiterter Funktionalität:

  • configure_streams übergibt Nutzernutzungs-Flags an den HAL.
  • einen Leer-Aufruf, um alle In-Flight-Anfragen/Puffer so schnell wie möglich zu löschen.

3

Erste Überarbeitung des HAL mit erweiterten Funktionen:

  • Große Versionsänderung, da das ABI komplett anders ist. Keine Änderung bei erforderliche Hardwarefunktionen oder das Betriebsmodell von Version 2.0.
  • Überarbeitete Schnittstellen für Eingabeanfragen und Streamwarteschlangen: Framework-Aufrufe an HAL mit der nächsten Anfrage und den Stream-Zwischenspeichern bereits in die Warteschlange gestellt. Framework-Unterstützung für die Synchronisierung enthalten, was für eine effiziente Implementierung erforderlich ist.
  • Trigger wurden in Anfragen verschoben, die meisten Benachrichtigungen in Ergebnisse.
  • Alle Callbacks wurden in einer Struktur und der gesamte Einrichtung zusammengefasst. in einem einzigen initialize()-Aufruf kombiniert.
  • Die Streamkonfiguration wurde in einem einzigen Aufruf zusammengefasst, um die Streamverwaltung zu vereinfachen. Bidirektionale Streams ersetzen STREAM_FROM_STREAM Konstruktion.
  • Semantik des eingeschränkten Modus für ältere/eingeschränkte Hardwaregeräte

2

Erste Version des HAL mit erweiterter Funktionalität (Android 4.2) [camera2.h]:

  • Ausreichend für die Implementierung vorhandener android.hardware.Camera der API erstellen.
  • Ermöglicht die ZSL-Warteschlange in der Kameradienstebene.
  • Nicht auf neue Funktionen wie manuelle Aufnahmesteuerung, Bayer RAW getestet Erfassung, erneute Verarbeitung von RAW-Daten usw.

1.0

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

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

Versionsverlauf des Kameramoduls

Dieser Abschnitt enthält Informationen zur Modulversionsverwaltung für die Kamerahardware. Modul, basierend auf camera_module_t.common.module_api_version. Die beiden Die wichtigsten Hexadezimalziffern stehen für die Hauptversion und die zwei am wenigsten bedeuten die Nebenversion.

2.4

Mit dieser Version des Kameramoduls werden die folgenden API-Änderungen hinzugefügt:

  1. Unterstützung für den Taschenlampenmodus Das Framework kann den Taschenmodus für jeden beliebigen Kameragerät mit Blitzgerät verwenden, ohne die Kamera öffnen zu müssen. Die Der Zugriff auf das Blitzgerät hat eine höhere Priorität als die der Kamera. Modul; Wenn du eine Kamera öffnest, wird die Taschenlampe ausgeschaltet, falls sie aktiviert war über die Moduloberfläche. Bei Ressourcenkonflikten, z. B. open() wird aufgerufen, um ein Kameragerät zu öffnen, das Kamera-HAL-Modul muss das Framework über den Callback für den Status des Taschenlampenmodus darüber informieren, dass die Modus deaktiviert wurde.
  2. Unterstützung externer Kamera (z. B. USB-Hot-Plug-in) Die API-Updates geben an, dass die statischen Informationen zur Kamera nur verfügbar sind, wenn die Kamera angeschlossen und einsatzbereit für externe Hot-Plug-Kameras. Aufrufe für statische Anrufe Informationen sind ungültige Anrufe, wenn der Kamerastatus nicht CAMERA_DEVICE_STATUS_PRESENT Das Framework zählt ausschließlich Callbacks für die Änderung des Gerätestatus, um die Liste der verfügbaren externen Kameras zu verwalten.
  3. Hinweise für das Kamera-Schiedsgerichtsverfahren: Zusätzliche Unterstützung für die explizite Angabe Anzahl der Kamerageräte, die gleichzeitig geöffnet und verwendet werden können Bis gültige Kombinationen von Geräten, resource_cost und conflicting_devices-Felder sollten immer im camera_info-Gebäude, das von get_camera_info zurückgegeben wird aufrufen.
  4. Methode zur Initialisierung des Moduls. 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 Version des Kameramoduls unterstützt offene HAL-Geräte für ältere Kameras. Das Framework kann es verwenden, um das Kameragerät als niedrigere HAL-Version des Geräts zu öffnen. HAL-Gerät, wenn dasselbe Gerät mehrere Geräte-API-Versionen unterstützen kann. Der offene Aufruf für das Standard-Hardwaremodul (common.methods->open) fährt fort um die Kamera mit der neuesten unterstützten Version zu öffnen, auch die in camera_info_t.device_version aufgeführte Version.

2,2

Mit dieser Version des Kameramoduls werden Anbieter-Tags über das Modul unterstützt. die alte vendor_tag_query_ops, die vorher nur bei geöffnetem Gerät barrierefrei zugänglich sein.

2.1

Mit dieser Version des Kameramoduls werden asynchrone Rückrufe zur vom Kamera-HAL-Modul, mit dem das Framework benachrichtigt wird, Statusänderungen des Kameramoduls. Module, die eine gültige Die Methode set_callbacks() muss mindestens diese Versionsnummer melden.

2

Kameramodule, die diese Versionsnummer melden, implementieren die zweite Version der HAL-Schnittstelle des Kameramoduls. Kamerageräte, die über das Das Modul unterstützt möglicherweise Version 1.0 oder Version 2.0 des Kamerageräts. HAL-Schnittstelle. 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 gleich 2.0 oder höher.

1.0

Kameramodule, die diese Versionsnummern melden, implementieren die ursprüngliche HAL-Schnittstelle des Kameramoduls. Alle Kamerageräte können über diesen unterstützen nur Version 1 des Kameragerät-HAL. Die device_version und static_camera_characteristics Felder von camera_info sind ungültig. Nur die Die android.hardware.Camera API wird von diesem Modul und seinen Geräte.