Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Unterstützung der Kameraversion

Auf dieser Seite werden Versionsunterschiede bei Kamera-HALs, APIs und zugehörigen CTS- Tests (Compatibility Test Suite) beschrieben . Es werden auch einige Architekturänderungen behandelt, die vorgenommen wurden, um das Kamera-Framework in Android 7.0 zu härten und zu sichern, der Wechsel zu Treble in Android 8.0 und die Aktualisierungsanbieter, die diese Änderungen in ihren Kamera-Implementierungen unterstützen müssen.

Terminologie

Die folgenden Begriffe werden auf dieser Seite verwendet:

Kamera-API1
Das Kamera-Framework auf App-Ebene für Android 4.4 und niedrigere Geräte, das über die Klasse android.hardware.Camera .
Kamera API2
Das Kamera-Framework auf App-Ebene für Geräte mit Android 5.0 und höher, das über das Paket android.hardware.camera2 .
Kamera HAL
Die von SoC-Anbietern implementierte Kameramodulschicht. Die öffentlichen Frameworks auf App-Ebene basieren auf der Kamera-HAL.
Kamera HAL3.1
Version des mit Android 4.4 veröffentlichten Kamerageräts HAL.
Kamera HAL3.2
Version des mit Android 5.0 veröffentlichten Kamerageräts HAL.
Kamera API1 CTS
Eine Reihe von Kamera-CTS-Tests, die auf der Kamera-API1 ausgeführt werden.
Kamera API2 CTS
Zusätzlicher Satz von Kamera-CTS-Tests, die auf der Kamera-API2 ausgeführt werden.
Verdreifachen
Trennt die Herstellerimplementierung (gerätespezifische Software auf niedrigerer Ebene, die von Siliziumherstellern geschrieben wurde) über eine neue Herstellerschnittstelle vom Android-Betriebssystem-Framework.
HIDL
Die mit Treble eingeführte HAL-Schnittstellendefinitionssprache wird verwendet, um die Schnittstelle zwischen einem HAL und seinen Benutzern anzugeben.
VTS
Vendor Test Suite neben Treble eingeführt.

Kamera-APIs

Android enthält die folgenden Kamera-APIs.

Kamera-API1

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

  • 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 Burst- / Streaming-Flows ohne Kopie und Einzelbildsteuerung für Belichtung, Verstärkung, Weißabgleich, Farbkonvertierung, Entrauschen, Schärfen und mehr. Weitere Informationen finden Sie in der Google I / O-Videoübersicht .

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 Funktionen der Kamera-API2. Die Eigenschaft android.info.supportedHardwareLevel , die Apps über die Camera API2-Schnittstellen abfragen können, weist eine der folgenden Unterstützungsstufen auf:

  • LEGACY : Diese Geräte stellen Apps über die Camera API2-Schnittstellen Funktionen zur Verfügung, die ungefähr den Funktionen entsprechen, die Apps über die Camera API1-Schnittstellen zur Verfügung stehen. Der Legacy-Framework-Code übersetzt konzeptionell Kamera-API2-Aufrufe in Kamera-API1-Aufrufe. Legacy-Geräte unterstützen keine Funktionen der Kamera-API2, z. B. Steuerelemente pro Frame.
  • LIMITED : Diese Geräte unterstützen einige (aber nicht alle) Camera API2-Funktionen und müssen Camera 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 die YUV-Wiederaufbereitung und RAW-Bilderfassung sowie zusätzliche Konfigurationen für den Ausgabestream.
  • EXTERNAL : Diese Geräte ähneln mit einigen Ausnahmen LIMITED Geräten. Beispielsweise werden einige Sensor- oder Linseninformationen möglicherweise nicht gemeldet oder weisen weniger stabile Bildraten auf. Diese Stufe wird für externe Kameras wie USB-Webcams verwendet.

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

Die unterstützte Hardwareebene des Geräts sowie die von ihm unterstützten spezifischen Kamera-API2-Funktionen sind als die folgenden Funktionsflags verfügbar, um die Google Play-Filterung 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 Camera HAL3.2-Implementierung enthalten und nicht in der Lage sind, die vollständigen Camera API2-Schnittstellen zu unterstützen, müssen die Camera API2 CTS-Tests weiterhin bestehen. Das Gerät wird jedoch im LEGACY Modus der Kamera-API2 LEGACY (in dem die Aufrufe der Kamera-API2 konzeptionell den Aufrufen der Kamera-API1 zugeordnet sind), sodass alle CTS-Tests der Kamera-API2, die sich auf Funktionen oder Fähigkeiten außerhalb der Kamera-API1 beziehen, automatisch übersprungen werden.

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

VTS-Anforderungen

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

Aushärten des Kamerarahmens

Um die Sicherheit von Medien und Kamera-Frameworks zu verbessern, verschiebt Android 7.0 den Kameradienst aus dem Mediaserver. Ab Android 8.0 wird jede binderisierte Kamera-HAL in einem vom Kameradienst getrennten Prozess ausgeführt. Abhängig von der verwendeten API- und HAL-Version müssen Anbieter möglicherweise Änderungen an der Kamera-HAL vornehmen. In den folgenden Abschnitten werden architektonische Änderungen in AP1 und AP2 für HAL1 und HAL3 sowie allgemeine Anforderungen beschrieben.

Architekturänderungen für API1

Bei der API1-Videoaufzeichnung wird möglicherweise davon ausgegangen, dass Kamera und Video-Encoder im selben Prozess live sind. Bei Verwendung von API1 auf:

  • HAL3, bei dem 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 für Android 7.0 in API1 auf HAL3

  • HAL1, das die Übergabe von Metadaten in Videopuffern unterstützt, muss von Anbietern aktualisiert werden, 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 für Android 7.0 in API1 auf HAL1

Architekturänderungen für API2

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

  • HAL1 ist vom Umzug des Kameraservices nicht betroffen, und es ist kein Hersteller-Update erforderlich.
  • HAL3 ist betroffen, es ist jedoch kein Hersteller-Update erforderlich:

    Android 7.0 Kamera- und Medienstapel in API2 auf HAL3

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

Zusätzliche Anforderungen

Die architektonischen Änderungen, die zum Härten der Medien- und Kamera-Framework-Sicherheit vorgenommen wurden, umfassen die folgenden zusätzlichen Geräteanforderungen.

  • Allgemeines. Geräte benötigen aufgrund des IPC zusätzliche Bandbreite, was sich auf zeitkritische Anwendungsfälle von Kameras wie Hochgeschwindigkeits-Videoaufzeichnungen auswirken kann. Anbieter können die tatsächliche Auswirkung messen, indem sie android.hardware.camera2.cts.PerformanceTest und die Google Camera-App für Hochgeschwindigkeits-Videoaufzeichnungen mit 120/240 FPS ausführen. Geräte benötigen außerdem eine kleine Menge zusätzlichen Arbeitsspeichers, um den neuen Prozess zu erstellen.
  • Übergeben Sie Metadaten in Videopuffern ( nur HAL1 ). Wenn HAL1 Metadaten anstelle von echten YUV-Rahmendaten in Videopuffern speichert, muss die HAL kMetadataBufferTypeNativeHandleSource als Metadatenpuffertyp verwenden und VideoNativeHandleMetadata in VideoNativeHandleMetadata . ( kMetadataBufferTypeCameraSource wird unter Android 7.0 nicht mehr unterstützt.) Mit VideoNativeHandleMetadata können Kamera- und Medien-Frameworks die VideoNativeHandleMetadata zwischen Prozessen übertragen, indem sie die nativen Handles ordnungsgemäß serialisieren und deserialisieren.
  • Die Adresse des Pufferhandles speichert nicht immer denselben Puffer ( nur HAL3 ). Für jede Erfassungsanforderung erhält HAL3 Adressen von Pufferhandles. HAL kann die Adressen nicht zum Identifizieren von Puffern verwenden, da die Adressen möglicherweise ein anderes Pufferhandle speichern, nachdem HAL den Puffer zurückgegeben hat. Sie müssen die HAL aktualisieren, um Pufferhandles zum Identifizieren der Puffer zu verwenden. Beispielsweise empfängt HAL eine Pufferhandle-Adresse A, in der das Pufferhandle A gespeichert ist. Nachdem HAL das Pufferhandle A zurückgegeben hat, kann die Pufferhandle-Adresse A das Pufferhandle B speichern, wenn die HAL sie das nächste Mal empfängt.
  • Aktualisieren Sie die SELinux-Richtlinien für den Kameraserver. Wenn gerätespezifische SELinux-Richtlinien 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 erfordern). Cameraserver sollte nur über die Berechtigungen verfügen, die zum Ausführen von Kamerafunktionen erforderlich sind, und unnötige kamerabezogene Berechtigungen im Mediaserver sollten entfernt werden.
  • Trennung zwischen Kamera HAL und Kameraserver. Android 8.0 und höher trennen zusätzlich die binderisierte Kamera HAL in einem anderen Prozess als der Kameraserver. IPC durchläuft HIDL-definierte Schnittstellen.

Validierung

Überprüfen Sie für alle Geräte, die eine Kamera enthalten 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, mit denen Änderungen am Kameradienst überprüft werden, schlagen vorhandene CTS-Tests fehl, wenn Sie die oben angegebenen Aktualisierungen nicht vorgenommen haben.

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

Verlauf der Kamera-HAL-Version

Eine Liste der Tests, die zur Bewertung der Android Camera HAL verfügbar sind, finden Sie in der Checkliste für die Camera HAL-Tests .

Android 10

Android 10 führt die folgenden Updates ein.

Kamera-API

Kamera HAL

Die folgenden Camera HAL-Versionen wurden 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 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 zum Abfragen von Stream-Kombinationen .

ICameraDeviceSession

  • isReconfigurationNeeded : Methode, die dem Kamera-Framework mitteilt, ob für mögliche neue Sitzungsparameterwerte eine vollständige Stream-Rekonfiguration erforderlich ist. Dies hilft, unnötige Verzögerungen bei der Neukonfiguration der Kamera zu vermeiden. Siehe Abfrage zur Sitzungsrekonfiguration .
  • HAL-Pufferverwaltungs-APIs : Mit diesen APIs kann die Kamera-HAL nur bei Bedarf Puffer vom Kamera-Framework anfordern, anstatt jede Erfassungsanforderung mit den zugehörigen Puffern in der gesamten Kamera-Pipeline zu koppeln, was zu potenziell erheblichen Speichereinsparungen führt.
    • signalStreamFlush : signalStreamFlush der HAL, dass der signalStreamFlush configureStreams_3_5 ausführen configureStreams_3_5 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 eine signalStreamFlush zwischen den Aufrufen configureStreams_3_5 und signalStreamFlush zu überprü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 Tasten werden zu 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 Konfigurationen für dynamische Tiefenströme
    • 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, die Kamera und das Routing beeinflussen.

2.4

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

Android 9

Die Android 9-Version enthält die folgenden Updates für die Kamera-API2 und die HAL-Oberfläche.

Kamera-API

  • Einführung der Multi-Kamera-API zur besseren Unterstützung von Geräten mit mehreren Kameras in derselben Richtung, die Funktionen wie Bokeh und nahtlosen Zoom ermöglichen. Auf diese Weise können Apps mehrere Kameras auf einem Gerät als eine logische Einheit (logische Kamera) anzeigen. Erfassungsanforderungen können auch an einzelne Kamerageräte gesendet werden, die von einer logischen Kamera umfasst werden. Siehe Unterstützung für mehrere Kameras .
  • Führt Sitzungsparameter ein. Sitzungsparameter sind eine Teilmenge der verfügbaren Erfassungsparameter, die bei Änderungen zu erheblichen Verarbeitungsverzögerungen führen können. Diese Kosten können gemindert werden, wenn Clients ihre Anfangswerte während der Initialisierung der Erfassungssitzung übergeben. Siehe Sitzungsparameter .
  • Fügt OIS-Datenschlüssel (Optical Stabilization) 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 in CAPTURE_INTENT eine Bewegungsverfolgungsabsicht CAPTURE_INTENT . Siehe CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Deprecates LENS_RADIAL_DISTORTION und fügt LENS_DISTORTION an seinem Platz.
  • 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

Aktualisierungen von ICameraDeviceSession

Aktualisierungen von ICameraDeviceCallback

3.3

Die folgenden Tasten werden zu 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 die CAL- HAL-Implementierungen des Anbieters binderisiert werden . Android 8.0 enthält außerdem die folgenden wichtigen Verbesserungen für den Kameradienst:

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

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

Gemeinsame Flächen

Mit dieser Funktion kann nur ein Satz von Puffern zwei Ausgänge ansteuern, z. B. Vorschau und Videokodierung, wodurch die Leistung 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 (wie dem Hardware-Composer / der GPU und dem Video-Encoder) anstelle von nur einem Verbraucher verwendet werden. Der Kameradienst leitet die Verbrauchernutzungsflags an die Kamera-HAL und die Gralloc-HAL weiter. 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 enableSurfaceSharing Entwicklerdokumentation von 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 spezifische Ausgänge gleichzeitig beschränkt. Verschiedene OEMs haben Interesse bekundet, andere benutzerdefinierte Modi für hardwarespezifische Funktionen zu definieren. Unter der Haube ist der Modus nur eine Ganzzahl, die an configure_streams . Siehe: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Diese Funktion enthält einen System-API-Aufruf, mit dem OEM-Kamera-Apps einen benutzerdefinierten Modus aktivieren können. Diese Modi müssen mit dem ganzzahligen Wert 0x8000 beginnen, um Konflikte mit zukünftigen Modi zu vermeiden, die der öffentlichen API hinzugefügt wurden.

Um diese Funktion zu unterstützen, müssen OEMs lediglich den neuen Modus zu ihrer HAL hinzufügen, der durch diese Ganzzahl ausgelöst wird, die in configure_streams an die 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 Steuerungsänderungen wie Zoom zu verringern, indem die Anforderungswarteschlange so leer wie möglich gehalten wird. onCaptureQueueEmpty erfordert keine HAL-Arbeit. Es war eine rein rahmenseitige Ergänzung. Anwendungen, die dies nutzen möchten, müssen diesem Rückruf einen Listener hinzufügen und entsprechend reagieren. Im Allgemeinen wird dazu eine weitere Erfassungsanforderung an das Kameragerät gesendet.

Kamera-HIDL-Schnittstelle

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 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 zur Unterstützung von data_space:

  • Fügen ANDROID_SENSOR_OPAQUE_RAW_SIZE statische Metadaten ANDROID_SENSOR_OPAQUE_RAW_SIZE als obligatorisch hinzu, wenn RAW_OPAQUE Format RAW_OPAQUE unterstützt wird.
  • Fügen ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statische Metadaten ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE als obligatorisch hinzu, wenn ein RAW-Format unterstützt wird.
  • camera3_stream_t data_space Feld camera3_stream_t data_space zu einer flexibleren Definition, indem Sie die Version 0-Definition der Datenbereichskodierung verwenden.
  • Allgemeine Metadaten-Ergänzungen, die für HALv3.2 oder höher verfügbar sind:
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • OPAQUE- und YUV-Wiederaufbereitungs-API-Updates.
  • Grundlegende Unterstützung für Tiefenausgabepuffer.
  • Hinzufügen eines data_space Felds zu camera3_stream_t .
  • Hinzufügen eines Rotationsfeldes zu camera3_stream_t .
  • Hinzufügen des Betriebsmodus für die Kamera3-Stream-Konfiguration zu camera3_stream_configuration_t .

3.2

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • Veraltet get_metadata_vendor_tag_ops . Verwenden camera_common.h stattdessen get_vendor_tag_ops in camera_common.h .
  • Veraltet register_stream_buffers . Alle Gralloc-Puffer, die das Framework HAL in process_capture_request 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.
  • Fügen Sie der camera3_request_template manuelle Vorlage camera3_request_template . Anwendungen können diese Vorlage verwenden, um die Aufnahmeeinstellungen direkt zu steuern.
  • Überarbeiten Sie die bidirektionalen und Eingabestream-Spezifikationen.
  • Ändern Sie den Eingabepuffer-Rückweg. Der Puffer wird in process_capture_result anstelle von process_capture_request .

3.1

Kleinere Überarbeitung der HAL mit erweiterten Funktionen:

  • configure_streams übergibt Consumer-Nutzungsflags an die HAL.
  • Flush Call, um alle Anfragen / Puffer während des Fluges so schnell wie möglich zu löschen.

3.0

Erste Überarbeitung von HAL mit erweiterten Funktionen:

  • Wesentliche Versionsänderung seit dem ABI ist völlig anders. Keine Änderung der erforderlichen Hardwarefunktionen oder des Betriebsmodells ab 2.0.
  • Überarbeitete Schnittstellen für Eingabeanforderungen und Stream-Warteschlangen: Framework ruft HAL auf, wobei die nächste Anforderung und die Stream-Puffer bereits aus der Warteschlange entfernt sind. Die Unterstützung für das Synchronisierungsframework ist enthalten, die für effiziente Implementierungen erforderlich ist.
  • Verschobene Trigger in Anfragen, die meisten Benachrichtigungen in Ergebnisse.
  • Konsolidierte alle Rückrufe in Framework in einer Struktur und alle Setup-Methoden in einem einzigen initialize() -Aufruf.
  • Die Stream-Konfiguration wurde zu einem einzigen Aufruf, um die Stream-Verwaltung zu vereinfachen. Bidirektionale Streams ersetzen das Konstrukt STREAM_FROM_STREAM .
  • Semantik im 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 Kameradienstschicht.
  • Nicht auf neue Funktionen wie manuelle Erfassungssteuerung, Bayer RAW-Erfassung, Wiederaufbereitung von RAW-Daten usw. getestet.

1.0

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

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

Versionsverlauf des Kameramoduls

Dieser Abschnitt enthält Informationen zur Modulversionierung für das Kamera-Hardwaremodul, basierend auf camera_module_t.common.module_api_version . Die zwei höchstwertigen Hex-Ziffern stehen für die Hauptversion und die beiden niedrigstwertigen für die Nebenversion.

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 zu öffnen. Das Kameragerät hat eine höhere Priorität beim Zugriff auf das Blitzgerät als das Kameramodul. Durch Öffnen eines Kamerageräts wird die Taschenlampe ausgeschaltet, wenn sie über die Modulschnittstelle aktiviert wurde. Wenn Ressourcenkonflikte auftreten, z. B. open() , um ein Kameragerät zu öffnen, muss das Kamera-HAL-Modul das Framework über den Statusrückruf des Brennermodus benachrichtigen, dass der Brennermodus deaktiviert wurde.
  2. Unterstützung für externe Kameras (z. B. USB-Hot-Plug-Kamera). Die API-Updates geben an, dass die statischen Informationen der Kamera nur verfügbar sind, wenn die Kamera angeschlossen und für externe Hot-Plug-Kameras einsatzbereit ist. Anrufe zum Abrufen statischer Informationen sind ungültige Anrufe, wenn der Kamerastatus nicht CAMERA_DEVICE_STATUS_PRESENT . Das Framework zählt ausschließlich Rückrufe zur Änderung des Gerätestatus, um die verfügbare externe Kameraliste zu verwalten.
  3. Hinweise zur Kamera-Arbitrierung. Fügt Unterstützung für die explizite Angabe der Anzahl der Kamerageräte hinzu, die gleichzeitig geöffnet und verwendet werden können. Um gültige Kombinationen von Geräten, die angeben resource_cost und conflicting_devices Felder sollten immer Satz in der seine camera_info Struktur durch den zurück get_camera_info Anruf.
  4. Modulinitialisierungsmethode. Wird vom Kameradienst aufgerufen, nachdem das HAL-Modul geladen wurde, um eine einmalige Initialisierung der HAL zu ermöglichen. Es wird aufgerufen, bevor andere Modulmethoden aufgerufen werden.

2.3

Diese Kameramodulversion bietet Unterstützung für HAL-Geräte mit offener Legacy-Kamera. Das Framework kann es verwenden, um das Kameragerät als unteres Gerät zu öffnen. HAL-Version HAL-Gerät, 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, die auch in camera_info_t.device_version .

2.2

Diese Kameramodulversion fügt dem Modul Unterstützung für Vendor-Tags hinzu und veraltet die alten vendor_tag_query_ops , auf die zuvor nur bei geöffnetem Gerät vendor_tag_query_ops konnte.

2.1

Diese Kameramodulversion bietet Unterstützung für asynchrone Rückrufe des Frameworks vom Kamera-HAL-Modul, mit dem das Framework über Änderungen des Kameramodulstatus benachrichtigt wird. Module, die eine gültige set_callbacks() -Methode set_callbacks() , müssen mindestens diese Versionsnummer melden.

2.0

Kameramodule, die diese Versionsnummer melden, implementieren die zweite Version der HAL-Schnittstelle des Kameramoduls. Über dieses Modul zu öffnende Kamerageräte 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. static_camera_characteristics 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 über dieses Modul zu öffnenden Kamerageräte 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.