Kamera HAL

Die Kamera-Hardware-Abstraktionsschicht (HAL) von Android verbindet die übergeordneten Kamera-Framework-APIs in android.hardware.camera2 mit dem zugrunde liegenden Kameratreiber und der zugrunde liegenden Kamera-Hardware. Ab Android 13 wird für die Entwicklung der HAL-Schnittstelle der Kamera AIDL verwendet. Mit Android 8.0 wurde Treble eingeführt. Dabei wurde die Camera HAL API auf eine stabile Schnittstelle umgestellt, die von der HAL-Schnittstellenbeschreibungssprache (HIDL) definiert wird. Wenn Sie bereits ein HAL-Modul und einen Treiber für Android 7.0 und niedriger entwickelt haben, sollten Sie sich über die erheblichen Änderungen an der Kamerapipeline informieren.

AIDL-Kamera HAL

Auf Geräten mit Android 13 oder höher unterstützt das Kamera-Framework AIDL-Kamera-HALs. Das Kamera-Framework unterstützt auch HIDL-Kamera-HALs. Kamerafunktionen, die in Android 13 oder höher hinzugefügt wurden, sind jedoch nur über die AIDL-Kamera-HAL-Schnittstellen verfügbar. Um solche Funktionen auf Geräten zu implementieren, die auf Android 13 oder höher aktualisiert werden, müssen Gerätehersteller ihren HAL-Prozess von HIDL-Kameraschnittstellen zu AIDL-Kameraschnittstellen migrieren.

Weitere Informationen zu den Vorteilen von AIDL finden Sie unter AIDL für HALs.

AIDL-Kamera-HAL implementieren

Eine Referenzimplementierung einer AIDL-Kamera-HAL finden Sie unter hardware/google/camera/common/hal/aidl_service/.

Die HAL-Spezifikationen der AIDL-Kamera finden Sie an folgenden Stellen:

Bei der Migration zu AIDL müssen Gerätehersteller möglicherweise die Android SELinux-Richtlinie (sepolicy) und die RC-Dateien je nach Codestruktur ändern.

AIDL-Camera HAL validieren

Um Ihre AIDL-Kamera-HAL-Implementierung zu testen, muss das Gerät alle CTS- und VTS-Tests bestehen. Mit Android 13 wird der AIDL VTS-Test eingeführt, VtsAidlHalCameraProvider_TargetTest.cpp.

Camera HAL3-Funktionen

Ziel der Neugestaltung der Android Camera API ist es, die Möglichkeit von Apps zur Steuerung des Kamera-Subsystems auf Android-Geräten erheblich zu verbessern und gleichzeitig die API so zu organisieren, dass sie effizienter und wartungsfreundlicher ist. Die zusätzliche Steuerung macht es einfacher, hochwertige Kamera-Apps auf Android-Geräten zu erstellen, die zuverlässig über mehrere Produkte hinweg funktionieren und dabei wann immer möglich gerätespezifische Algorithmen verwenden, um Qualität und Leistung zu maximieren.

Version 3 des Kamera-Subsystems strukturiert die Betriebsmodi in einer einzigen einheitlichen Ansicht, die zum Implementieren aller vorherigen Modi und mehrerer anderer Modi wie dem Serienbildmodus verwendet werden kann. Das führt zu einer besseren Nutzersteuerung für Fokus und Belichtung sowie zu mehr Möglichkeiten bei der Nachbearbeitung, z. B. Geräuschunterdrückung, Kontrast und Schärfen. Außerdem erleichtert diese vereinfachte Ansicht App-Entwicklern die Verwendung der verschiedenen Kamerafunktionen.

Die API modelliert das Kamera-Subsystem als Pipeline, die eingehende Anfragen für Frame-Captures 1:1 in Frames umwandelt. Die Anfragen enthalten alle Konfigurationsinformationen zur Erfassung und Verarbeitung eines Frames. Dazu gehören Auflösung und Pixelformat, manuelle Sensor-, Objektiv- und Blitzsteuerung, 3A-Betriebsmodi, Steuerung der RAW->YUV-Verarbeitung, Statistikgenerierung usw.

Einfach ausgedrückt: Das Anwendungs-Framework fordert einen Frame vom Kamera-Subsystem an und das Kamera-Subsystem gibt Ergebnisse an einen Ausgabestream zurück. Außerdem werden für jeden Ergebnissatz Metadaten mit Informationen wie Farbräumen und Objektivschatten generiert. Sie können sich Kameraversion 3 als Pipeline zum Einwegstream von Kameraversion 1 vorstellen. Dabei wird jede Aufnahmeanfrage in ein vom Sensor aufgenommenes Bild umgewandelt, das zu folgenden Ergebnissen verarbeitet wird:

  • Ein Ergebnisobjekt mit Metadaten zur Aufnahme.
  • Ein bis N Bilddaten-Buffer, jeweils in eine eigene Zielfläche.

Die möglichen Ausgabeoberflächen sind vorkonfiguriert:

  • Jede Oberfläche ist ein Ziel für einen Strom von Bildpuffern mit einer festen Auflösung.
  • Es können nur wenige Oberflächen gleichzeitig als Ausgänge konfiguriert werden (ca. 3).

Eine Anfrage enthält alle gewünschten Aufnahmeeinstellungen und die Liste der Ausgabeoberflächen, in die Bildbuffer für diese Anfrage aus dem gesamten konfigurierten Satz geschoben werden sollen. Eine Anfrage kann einmalig (mit capture()) oder unbegrenzt wiederholt (mit setRepeatingRequest()) werden. Aufnahmen haben Vorrang vor wiederkehrenden Anfragen.

Kameradatenmodell

Abbildung 1: Kamerakernbetriebsmodell

Kamera-HAL1 – Übersicht

Version 1 des Kamera-Subsystems wurde als Blackbox mit allgemeinen Steuerelementen und den folgenden drei Betriebsmodi entwickelt:

  • Vorschau
  • Videoaufnahme
  • Standbildaufnahme

Die Funktionen der einzelnen Modi unterscheiden sich geringfügig und überschneiden sich. Das machte es schwierig, neue Funktionen wie den Serienbildmodus zu implementieren, der zwischen zwei der Betriebsmodi liegt.

Blockdiagramm der Kamera

Abbildung 2. Kamerakomponenten

Android 7.0 unterstützt weiterhin HAL1 für Kameras, da viele Geräte noch darauf angewiesen sind. Außerdem unterstützt der Android-Kamerazugriff die Implementierung beider HALs (1 und 3). Das ist nützlich, wenn Sie eine weniger leistungsfähige Frontkamera mit Kamera-HAL1 und eine fortschrittlichere Rückkamera mit Kamera-HAL3 unterstützen möchten.

Es gibt ein einzelnes HAL-Modul für die Kamera (mit einer eigenen Versionsnummer), in dem mehrere unabhängige Kamerageräte mit jeweils einer eigenen Versionsnummer aufgeführt sind. Kameramodul 2 oder höher ist erforderlich, um Geräte 2 oder höher zu unterstützen. Solche Kameramodule können eine Mischung aus Kamerageräteversionen haben. Das ist gemeint, wenn wir sagen, dass Android die Implementierung beider HALs unterstützt.