Kamera HAL

Warstwa abstrakcji sprzętu aparatu (HAL) systemu Android łączy interfejsy API struktury aparatu wyższego poziomu w android.hardware.camera2 z podstawowym sterownikiem aparatu i sprzętem. Począwszy od Androida 13, tworzenie interfejsu HAL kamery wykorzystuje AIDL . Android 8.0 wprowadził Treble , przełączając interfejs Camera HAL API na stabilny interfejs zdefiniowany przez język opisu interfejsu HAL (HIDL). Jeśli wcześniej opracowałeś moduł i sterownik HAL kamery dla systemu Android 7.0 i starszych, pamiętaj o znaczących zmianach w potoku kamery.

Kamera AIDL HAL

W przypadku urządzeń z systemem Android 13 lub nowszym struktura aparatu obejmuje obsługę warstw HAL aparatu AIDL. Struktura kamery obsługuje również warstwy HAL kamery HIDL, jednak funkcje kamery dodane w systemie Android 13 lub nowszym są dostępne tylko za pośrednictwem interfejsów HAL kamery AIDL. Aby wdrożyć takie funkcje na urządzeniach uaktualniających do systemu Android 13 lub nowszego, producenci urządzeń muszą przenieść swój proces HAL z używania interfejsów kamer HIDL na interfejsy kamer AIDL.

Aby dowiedzieć się więcej o zaletach AIDL, zobacz AIDL for HALs .

Zaimplementuj kamerę AIDL HAL

Aby zapoznać się z referencyjną implementacją warstwy HAL kamery AIDL, zobacz hardware/google/camera/common/hal/aidl_service/ .

Specyfikacje HAL kamery AIDL znajdują się w następujących lokalizacjach:

W przypadku urządzeń migrujących do AIDL producenci urządzeń mogą wymagać zmodyfikowania zasad Android SELinux (sepolicy) i plików RC w zależności od struktury kodu.

Sprawdź poprawność HAL kamery AIDL

Aby przetestować implementację HAL kamery AIDL, upewnij się, że urządzenie pomyślnie przeszło wszystkie testy CTS i VTS. W systemie Android 13 wprowadzono test AIDL VTS, VtsAidlHalCameraProvider_TargetTest.cpp .

Funkcje kamery HAL3

Celem przeprojektowania interfejsu API aparatu Android jest znaczne zwiększenie możliwości aplikacji do kontrolowania podsystemu aparatu na urządzeniach z systemem Android przy jednoczesnej reorganizacji interfejsu API, aby uczynić go bardziej wydajnym i łatwiejszym w utrzymaniu. Dodatkowa kontrola ułatwia tworzenie wysokiej jakości aplikacji aparatu na urządzeniach z systemem Android, które mogą działać niezawodnie w wielu produktach, a jednocześnie w miarę możliwości korzystać z algorytmów specyficznych dla urządzenia, aby zmaksymalizować jakość i wydajność.

Wersja 3 podsystemu kamer łączy tryby pracy w jeden ujednolicony widok, który można wykorzystać do wdrożenia dowolnego z poprzednich trybów i kilku innych, takich jak tryb zdjęć seryjnych. Powoduje to lepszą kontrolę użytkownika nad ostrością i ekspozycją oraz więcej przetwarzania końcowego, takiego jak redukcja szumów, kontrast i wyostrzanie. Co więcej, ten uproszczony widok ułatwia twórcom aplikacji korzystanie z różnych funkcji aparatu.

Interfejs API modeluje podsystem kamery jako potok, który konwertuje przychodzące żądania przechwycenia ramek na ramki w skali 1:1. Żądania zawierają wszystkie informacje konfiguracyjne dotyczące przechwytywania i przetwarzania ramki. Obejmuje to rozdzielczość i format pikseli; ręczny czujnik, sterowanie obiektywem i lampą błyskową; tryby pracy 3A; Kontrola przetwarzania RAW->YUV; generowanie statystyk; i tak dalej.

Mówiąc prościej, struktura aplikacji żąda ramki od podsystemu kamery, a podsystem kamery zwraca wyniki do strumienia wyjściowego. Ponadto dla każdego zestawu wyników generowane są metadane zawierające informacje, takie jak przestrzenie kolorów i cieniowanie soczewek. Możesz myśleć o wersji kamery 3 jako potoku do jednokierunkowego strumienia kamery w wersji 1. Konwertuje każde żądanie przechwycenia w jeden obraz przechwycony przez czujnik, który jest przetwarzany na:

  • Obiekt wynikowy z metadanymi dotyczącymi przechwytywania.
  • Jeden do N buforów danych obrazu, każdy na swojej własnej powierzchni docelowej.

Zestaw możliwych powierzchni wyjściowych jest wstępnie skonfigurowany:

  • Każda powierzchnia jest miejscem docelowym dla strumienia buforów obrazu o stałej rozdzielczości.
  • Tylko niewielka liczba powierzchni może być jednocześnie skonfigurowana jako wyjścia (~3).

Żądanie zawiera wszystkie żądane ustawienia przechwytywania i listę powierzchni wyjściowych do wypychania buforów obrazu dla tego żądania (z całego skonfigurowanego zestawu). Żądanie może być jednorazowe (za pomocą capture() ) lub może być powtarzane w nieskończoność (za pomocą setRepeatingRequest() ). Przechwyty mają pierwszeństwo przed powtarzającymi się żądaniami.

Model danych kamery

Rysunek 1. Podstawowy model działania kamery

Przegląd kamery HAL1

Wersja 1 podsystemu kamery została zaprojektowana jako czarna skrzynka ze sterowaniem wysokiego poziomu i następującymi trzema trybami pracy:

  • Zapowiedź
  • Nagrywanie wideo
  • Wciąż przechwytywanie

Każdy tryb ma nieco inne i nakładające się możliwości. Utrudniło to zaimplementowanie nowych funkcji, takich jak tryb burst, który mieści się między dwoma trybami pracy.

Schemat blokowy kamery

Rysunek 2. Elementy kamery

Android 7.0 nadal obsługuje kamerę HAL1, ponieważ wiele urządzeń wciąż na niej polega. Ponadto usługa aparatu w systemie Android obsługuje implementację obu warstw HAL (1 i 3), co jest przydatne, gdy chcesz obsługiwać kamerę przednią o mniejszych możliwościach z kamerą HAL1 oraz bardziej zaawansowaną kamerę skierowaną do tyłu z kamerą HAL3.

Istnieje jeden moduł HAL kamery (z własnym numerem wersji ), który zawiera listę wielu niezależnych urządzeń z kamerami, z których każde ma swój własny numer wersji. Do obsługi urządzeń 2 lub nowszych wymagany jest moduł kamery 2 lub nowszy, a takie moduły kamery mogą mieć różne wersje urządzeń z kamerą (o to mamy na myśli, gdy mówimy, że Android obsługuje implementację obu warstw HAL).