HAL-Subsystem

Auf dieser Seite wird das HAL-Subsystem beschrieben, einschließlich Anfragen, dem Kamera-Subsystem, der Start- und Betriebssequenz, Hardware-Levels und Interaktionen.

Anfragen

Das App-Framework sendet Anfragen für aufgenommene Ergebnisse an das Kamera-Subsystem. Eine Anfrage entspricht einem Satz von Ergebnissen. Eine Anfrage enthält alle Konfigurationsinformationen zum Erfassen und Verarbeiten dieser Ergebnisse. Dazu gehören unter anderem Auflösung und Pixelformat, manuelle Steuerung von Sensor, Objektiv und Blitz, 3A-Betriebsmodi, Steuerung der RAW-zu-YUV-Verarbeitung und Generierung von Statistiken. So haben Sie viel mehr Kontrolle über die Ausgabe und Verarbeitung der Ergebnisse. Es können mehrere Anfragen gleichzeitig laufen und das Senden von Anfragen ist nicht blockierend. Die Anfragen werden immer in der Reihenfolge ihres Eingangs bearbeitet.

Abbildung 1. Kameramodell

HAL und Kamera-Subsystem

Das Kamerasubsystem umfasst die Implementierungen für Komponenten in der Kamerapipeline, z. B. den 3A-Algorithmus und die Verarbeitungseinstellungen. Die Kamera-HAL bietet Schnittstellen, mit denen Sie Ihre Versionen dieser Komponenten implementieren können. Um die plattformübergreifende Kompatibilität zwischen mehreren Geräteherstellern und Anbietern von Bildsignalprozessoren (ISPs oder Kamerasensoren) aufrechtzuerhalten, ist das Kamerapipeline-Modell virtuell und entspricht nicht direkt einem realen ISP. Sie ähnelt jedoch echten Verarbeitungspipelines, sodass Sie sie effizient auf Ihre Hardware abstimmen können. Außerdem ist sie abstrakt genug, um mehrere verschiedene Algorithmen und Operationsreihenfolgen zu ermöglichen, ohne die Qualität, Effizienz oder geräteübergreifende Kompatibilität zu beeinträchtigen.

Die Kamerapipeline unterstützt auch Trigger, die vom App-Framework initiiert werden können, um Funktionen wie den Autofokus zu aktivieren. Außerdem werden Benachrichtigungen an das App-Framework zurückgesendet, um Apps über Ereignisse wie eine Autofokus-Sperre oder Fehler zu informieren.

Abbildung 2: Kamera-Pipeline.

Einige der oben im Diagramm gezeigten Bildverarbeitungsblöcke sind in der ersten Version noch nicht genau definiert. Die Kamerapipeline geht von folgenden Annahmen aus:

• Die RAW-Bayer-Ausgabe wird im ISP nicht verarbeitet.
• Statistiken werden auf Grundlage der Rohsensordaten generiert.
• Die verschiedenen Verarbeitungsblöcke, die Rohsensordaten in YUV umwandeln, sind in einer beliebigen Reihenfolge angeordnet.
• Es werden zwar mehrere Skalierungs- und Zuschneideeinheiten angezeigt, aber alle Skalierungseinheiten verwenden dieselben Steuerelemente für den Ausgabebereich (digitaler Zoom). Jede Einheit kann jedoch eine andere Ausgaberesolution und ein anderes Pixelformat haben.

Zusammenfassung der API-Nutzung

Hier finden Sie eine kurze Zusammenfassung der Schritte zur Verwendung der Android-Kamera-API. Im Abschnitt „Start und erwartete Abfolge von Vorgängen“ finden Sie eine detaillierte Aufschlüsselung dieser Schritte, einschließlich API-Aufrufen.

1. Kamerageräte erkennen und auflisten.
2. Öffne das Gerät und verbinde die Kopfhörer.
3. Konfigurieren Sie die Ausgaben für den Zielanwendungsfall (z. B. Standbildaufnahme oder Aufzeichnung).
4. Anfragen für den Zielanwendungsfall erstellen
5. Anfragen und Bursts erfassen/wiederholen
6. Metadaten und Bilddaten für Ergebnisse empfangen.
7. Wenn Sie den Anwendungsfall wechseln, kehren Sie zu Schritt 3 zurück.

Zusammenfassung des HAL-Vorgangs

• Asynchrone Anfragen für Aufnahmen stammen aus dem Framework.
• HAL-Geräte müssen Anfragen in der Reihenfolge ihrer Eingabe verarbeiten. Für jede Anfrage werden Metadaten für das Ausgaberesultat und ein oder mehrere Ausgabebildpuffer erstellt.
• First-in-first-out-Prinzip für Anfragen und Ergebnisse sowie für Streams, auf die in nachfolgenden Anfragen verwiesen wird.
• Zeitstempel müssen für alle Ausgaben einer bestimmten Anfrage identisch sein, damit das Framework sie bei Bedarf zuordnen kann.
• Die gesamte Erfassungs-Konfiguration und der gesamte Erfassungsstatus (mit Ausnahme der 3A-Routinen) sind in den Anfragen und Ergebnissen enthalten.

Abbildung 3: Übersicht über die Kamera HAL.

Start und erwartete Betriebsfolge

In diesem Abschnitt werden die Schritte beschrieben, die bei der Verwendung der Kamera-API erwartet werden. HIDL-Schnittstellendefinitionen finden Sie unter platform/hardware/interfaces/camera/.

Kamerageräte auflisten, öffnen und eine aktive Sitzung erstellen

1. Nach der Initialisierung beginnt das Framework, auf alle vorhandenen Kameraanbieter zu warten, die die ICameraProvider-Schnittstelle implementieren. Wenn ein solcher Anbieter oder solche Anbieter vorhanden sind, versucht das Framework, eine Verbindung herzustellen.
2. Das Framework listet die Kamerageräte über ICameraProvider::getCameraIdList auf.
3. Das Framework instanziiert ein neues ICameraDevice, indem es das entsprechende ICameraProvider::getCameraDeviceInterface_VX_X aufruft.
4. Das Framework ruft ICameraDevice::open auf, um eine neue aktive Aufnahmesitzung ICameraDeviceSession zu erstellen.

Aktive Kamerasitzung verwenden

1. Das Framework ruft ICameraDeviceSession::configureStreams mit einer Liste von Ein-/Ausgabestreams für das HAL-Gerät auf.
2. Das Framework fordert mit Aufrufen von ICameraDeviceSession::constructDefaultRequestSettings Standardeinstellungen für einige Anwendungsfälle an. Das kann jederzeit nach der Erstellung des ICameraDeviceSession durch ICameraDevice::open passieren.
3. Das Framework erstellt und sendet die erste Erfassungsanfrage an die HAL mit Einstellungen, die auf einem der Standardsätze von Einstellungen basieren, und mit mindestens einem Ausgabestream, der zuvor vom Framework registriert wurde. Sie wird mit ICameraDeviceSession::processCaptureRequest an die HAL gesendet. Die HAL muss die Rückgabe dieses Aufrufs blockieren, bis sie bereit ist, die nächste Anfrage zu senden.
4. Das Framework sendet weiterhin Anfragen und ruft ICameraDeviceSession::constructDefaultRequestSettings auf, um bei Bedarf Puffer für Standardeinstellungen für andere Anwendungsfälle abzurufen.
5. Wenn die Aufnahme einer Anfrage beginnt (der Sensor beginnt mit der Belichtung für die Aufnahme), ruft die HAL ICameraDeviceCallback::notify mit der SHUTTER-Nachricht auf, einschließlich der Framenummer und des Zeitstempels für den Beginn der Belichtung. Dieser Benachrichtigungs-Callback muss nicht vor dem ersten processCaptureResult-Aufruf für eine Anfrage erfolgen. Ergebnisse werden jedoch erst an eine App für eine Aufnahme gesendet, nachdem notify für diese Aufnahme aufgerufen wurde.
6. Nach einer gewissen Verzögerung beginnt das HAL, abgeschlossene Aufnahmen mit ICameraDeviceCallback::processCaptureResult an das Framework zurückzugeben. Sie werden in derselben Reihenfolge zurückgegeben, in der die Anfragen gesendet wurden. Je nach Pipeline-Tiefe des Kamera-HAL-Geräts können mehrere Anfragen gleichzeitig ausgeführt werden.

Nach einiger Zeit passiert Folgendes:

• Das Framework sendet keine neuen Anfragen mehr, wartet, bis die vorhandenen Aufnahmen abgeschlossen sind (alle Puffer gefüllt, alle Ergebnisse zurückgegeben), und ruft dann ICameraDeviceSession::configureStreams noch einmal auf. Dadurch werden die Kamerahardware und die Pipeline für einen neuen Satz von Ein-/Ausgabestreams zurückgesetzt. Einige Streams können aus der vorherigen Konfiguration wiederverwendet werden. Das Framework setzt dann die Verarbeitung mit der ersten Erfassungsanfrage an das HAL fort, sofern mindestens ein registrierter Ausgabestream vorhanden ist. Andernfalls ist zuerst ICameraDeviceSession::configureStreams erforderlich.
• Das Framework kann ICameraDeviceSession::close aufrufen, um die Kamerasitzung zu beenden. Diese Funktion kann jederzeit aufgerufen werden, wenn keine anderen Aufrufe des Frameworks aktiv sind. Der Aufruf kann jedoch blockiert werden, bis alle laufenden Erfassungen abgeschlossen sind (alle Ergebnisse zurückgegeben, alle Puffer gefüllt). Nachdem der close-Aufruf zurückgegeben wurde, sind keine weiteren Aufrufe von ICameraDeviceCallback aus der HAL zulässig. Sobald der close-Aufruf läuft, kann das Framework keine anderen HAL-Gerätefunktionen aufrufen.
• Im Falle eines Fehlers oder eines anderen asynchronen Ereignisses muss die HAL ICameraDeviceCallback::notify mit der entsprechenden Fehler-/Ereignismeldung aufrufen. Nachdem die Benachrichtigung über einen schwerwiegenden geräteweiten Fehler zurückgegeben wurde, sollte sich die HAL so verhalten, als ob close darauf aufgerufen worden wäre. Das HAL muss jedoch alle ausstehenden Aufnahmen entweder abbrechen oder abschließen, bevor notify aufgerufen wird. So wird sichergestellt, dass das Framework nach dem Aufruf von notify mit einem schwerwiegenden Fehler keine weiteren Callbacks vom Gerät empfängt. Andere Methoden als close sollten -ENODEV oder NULL zurückgeben, nachdem die notify-Methode eine schwerwiegende Fehlermeldung zurückgegeben hat.

Abbildung 4: Ablauf der Kamera.

Hardwareebenen

Kamerageräte können je nach ihren Funktionen mehrere Hardwareebenen implementieren. Weitere Informationen finden Sie unter Unterstützte Hardwareebene.

Interaktion zwischen der App-Aufnahmeanfrage, der 3A-Steuerung und der Verarbeitungspipeline

Je nach den Einstellungen im 3A-Steuerblock ignoriert die Kamerapipeline einige der Parameter in der Aufnahmeanfrage der App und verwendet stattdessen die von den 3A-Steuerroutinen bereitgestellten Werte. Wenn beispielsweise die automatische Belichtung aktiv ist, werden die Parameter für Belichtungszeit, Bilddauer und Empfindlichkeit des Sensors vom 3A-Algorithmus der Plattform gesteuert und alle von der App angegebenen Werte werden ignoriert. Die von den 3A-Routinen für den Frame ausgewählten Werte müssen in den Ausgabemetadaten angegeben werden. In der folgenden Tabelle werden die verschiedenen Modi des 3A-Steuerblocks und die Eigenschaften beschrieben, die von diesen Modi gesteuert werden. Definitionen dieser Eigenschaften finden Sie in der Datei platform/system/media/camera/docs/docs.html.

Parameter	Status	Kontrollierte Properties
android.control.aeMode	OFF	Keine.
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (falls unterstützt) und android.lens.filterDensity (falls unterstützt).
	ON_AUTO_FLASH	Alle Vorteile von ON und zusätzlich android.flash.firingPower, android.flash.firingTime und android.flash.mode.
	ON_ALWAYS_FLASH	Gleich wie bei ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Gleich wie bei ON_AUTO_FLASH
android.control.awbMode	OFF	Keine.
	WHITE_BALANCE_*	android.colorCorrection.transform. Plattformspezifische Anpassungen, wenn android.colorCorrection.mode FAST oder HIGH_QUALITY ist.
android.control.afMode	OFF	Keine
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Keine.
	ON	Kann android.scaler.cropRegion anpassen, um die Videostabilisierung zu implementieren.
android.control.mode	OFF	AE, AWB und AF sind deaktiviert.
	AUTO	Es werden individuelle Einstellungen für AE, AWB und AF verwendet.
	SCENE_MODE_*	Kann alle oben aufgeführten Parameter überschreiben. Die einzelnen 3A-Steuerelemente sind deaktiviert.

Die Steuerelemente im Bildverarbeitungsblock in Abbildung 2 funktionieren alle nach einem ähnlichen Prinzip und jeder Block hat drei Modi:

• OFF: Dieser Verarbeitungsblock ist deaktiviert. Die Blöcke für Demosaicing, Farbkorrektur und Anpassung der Tonwertkurve können nicht deaktiviert werden.
• FAST: In diesem Modus verlangsamt der Verarbeitungsblock die Ausgabeframerate möglicherweise nicht im Vergleich zum Modus OFF, sollte aber ansonsten die bestmögliche Ausgabequalität erzielen. Dies wird in der Regel für Vorschau- oder Videoaufnahmemodi oder für Serienaufnahmen von Fotos verwendet. Auf einigen Geräten entspricht dies möglicherweise dem Modus OFF (ohne Verlangsamung der Framerate ist keine Verarbeitung möglich), auf anderen Geräten dem Modus HIGH_QUALITY (beste Qualität führt nicht zu einer Verlangsamung der Framerate).
• HIGH_QUALITY: In diesem Modus sollte der Verarbeitungsblock das bestmögliche Ergebnis liefern und die Ausgabebildrate bei Bedarf verlangsamen. Normalerweise wird diese Einstellung für hochwertige Standbilder verwendet. Einige Blöcke enthalten eine manuelle Steuerung, die optional anstelle von FAST oder HIGH_QUALITY ausgewählt werden kann. Der Farbkorrekturblock unterstützt beispielsweise eine Farbtransformationsmatrix, während die Anpassung der Tonwertkurve eine beliebige globale Tone Mapping-Kurve unterstützt.

Die maximale Bildrate, die von einem Kamerasubsystem unterstützt werden kann, hängt von vielen Faktoren ab:

• Angefragte Auflösungen von Ausgabebildstreams
• Verfügbarkeit von Binning-/Überspringungsmodi auf dem Bildsensor
• Bandbreite der Imager-Schnittstelle
• Die Bandbreite der verschiedenen ISP-Verarbeitungsblöcke

Diese Faktoren können je nach ISP und Sensor stark variieren. Daher versucht die Kamera-HAL-Schnittstelle, die Bandbreitenbeschränkungen in einem möglichst einfachen Modell zu abstrahieren. Das vorgestellte Modell hat die folgenden Merkmale:

• Der Bildsensor ist immer so konfiguriert, dass er die kleinstmögliche Auflösung ausgibt, die durch die angeforderten Ausgabestreamgrößen der App vorgegeben ist. Die kleinste Auflösung muss mindestens so groß sein wie die größte angeforderte Ausgabestreamgröße.
• Für jede Anfrage können alle derzeit konfigurierten Ausgabestreams verwendet werden. Daher müssen Sensor und ISP so konfiguriert sein, dass sie die gleichzeitige Skalierung einer einzelnen Aufnahme auf alle Streams unterstützen.
• JPEG-Streams verhalten sich wie verarbeitete YUV-Streams für Anfragen, in denen sie nicht enthalten sind. In Anfragen, in denen sie direkt referenziert werden, verhalten sie sich wie JPEG-Streams.
• Der JPEG-Prozessor kann parallel zum Rest der Kamerapipeline ausgeführt werden, kann aber jeweils nur eine Aufnahme verarbeiten.