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 ähnelnLIMITED
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.
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.)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:
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 SieVideoNativeHandleMetadata
in Videozwischenspeichern ein und übergeben Sie sie. (kMetadataBufferTypeCameraSource
wird auf Android nicht mehr unterstützt) 7.0.) MitVideoNativeHandleMetadata
, 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
- Verbesserungen an mehreren Kameras, durch die physische Kameras einzeln oder durch entsprechende logische Kameras verwendet werden, IDs physischer Kameras. Weitere Informationen finden Sie unter Unterstützung für mehrere Kameras.
- Möglichkeit zu prüfen, ob eine bestimmte Sitzungskonfiguration
ohne den Leistungsaufwand einer
neuen Sitzung zu steigern.
Weitere Informationen finden Sie unter
CameraDevice
- Kann empfohlene Streamkonfigurationen für eine bestimmte Verwendung abrufen
um den Kunden energieeffizienter und leistungsfähiger zu machen. Weitere Informationen finden Sie unter
getRecommendedStreamConfigurationMap
- Unterstützung für die <ph type="x-smartling-placeholder"></ph> JPEG-Bildformat mit Tiefenschärfe. Weitere Informationen finden Sie in der <ph type="x-smartling-placeholder"></ph> Dynamic Depth – Spezifikation
- Unterstützung für die <ph type="x-smartling-placeholder"></ph> HEIC-Bildformat Weitere Informationen finden Sie unter HEIF-Bildverarbeitung:
- Datenschutzverbesserungen. Für den Client sind bestimmte Schlüssel erforderlich
haben
<ph type="x-smartling-placeholder"></ph>
CAMERA
-Berechtigungen, bevor sie abgerufen werden können <ph type="x-smartling-placeholder"></ph>CameraCharacteristics
Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph>getKeysNeedingPermission
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 DienstconfigureStreams_3_5
ausführen soll und dass Der HAL muss alle Puffer bestimmter Streams zurückgeben. -
configureStreams_3_5
: Ähnlich wieICameraDevice3.4.configureStreams
, aber in Außerdem wird der ZählerstreamConfigCounter
an Suche nach einer Race-Bedingung zwischenconfigureStreams_3_5
undsignalStreamFlush
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ürisTorchModeSupported
.
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
- <ph type="x-smartling-placeholder"></ph>
configureStreams_3_4
: Unterstützung fürsessionParameters
und logische Kameras - <ph type="x-smartling-placeholder"></ph>
processCaptureRequest_3_4
: Die Integration physischer Kamera-IDs in die Stream-Struktur wird jetzt unterstützt.
Aktualisierungen für ICameraDeviceCallback
-
<ph type="x-smartling-placeholder"></ph>
processCaptureResult_3_4
: Fügt den Aufnahmeergebnissen physische Kamera-Metadaten hinzu.
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 FormatRAW_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 zucamera3_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 Stattdessenget_vendor_tag_ops
incamera_common.h
.register_stream_buffers
wird eingestellt. Alle Gralloc-Zwischenspeicher vom Framework für HAL inprocess_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
stattprocess_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:
- 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. - 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. - 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
undconflicting_devices
-Felder sollten immer imcamera_info
-Gebäude, das vonget_camera_info
zurückgegeben wird aufrufen. - 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.