Kamera HAL

Die Kamera-Hardware-Abstraktionsschicht (HAL) von Android verbindet die APIs des Kamera-Frameworks der höheren Ebene in android.hardware.camera2 mit dem zugrunde liegenden Kameratreiber und der zugrunde liegenden 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-HALs für Kameras. 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 umgestellt werden, müssen Gerätehersteller ihren HAL-Prozess von der Verwendung 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 AIDL-Kamera-HAL-Spezifikationen finden Sie an den 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-Kamera-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.

Kamera-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. Mit der zusätzlichen Kontrolle können Sie auf Android-Geräten hochwertige Kamera-Apps entwickeln, die zuverlässig auf mehreren Produkten funktionieren. Dabei werden nach Möglichkeit weiterhin gerätespezifische Algorithmen verwendet, 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 Nutzung der verschiedenen Funktionen der Kamera.

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, RAW-zu-YUV-Verarbeitungssteuerung, Statistikerstellung 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 das Ziel für einen Stream 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
  • Videoaufzeichnung
  • Standbildaufnahme

Die einzelnen Modi haben leicht unterschiedliche und sich überschneidende Funktionen. Das machte es schwierig, neue Funktionen wie den Burst-Modus 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.