Kamera HAL

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

Kamera AIDL HAL

W przypadku urządzeń z systemem Android 13 lub nowszym platforma kamery obsługuje warstwy HAL kamer 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 zaimplementować takie funkcje na urządzeniach z systemem Android 13 lub nowszym, producenci urządzeń muszą przeprowadzić migrację procesu HAL z interfejsów kamery HIDL do interfejsów kamer AIDL.

Aby dowiedzieć się o zaletach AIDL, zobacz AIDL dla HAL .

Zaimplementuj kamerę AIDL HAL

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

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

W przypadku urządzeń migrujących do AIDL może być konieczne zmodyfikowanie przez producentów urządzeń zasad systemu 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 przeszło wszystkie testy CTS i VTS. W Androidzie 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 w zakresie kontrolowania podsystemu aparatu na urządzeniach z systemem Android przy jednoczesnej reorganizacji interfejsu API, aby był bardziej wydajny i łatwiejszy w utrzymaniu. Dodatkowa kontrola ułatwia tworzenie wysokiej jakości aplikacji aparatu na urządzenia z systemem Android, które mogą niezawodnie działać na wielu produktach, a jednocześnie, jeśli to możliwe, nadal korzystać z algorytmów specyficznych dla urządzenia, aby zmaksymalizować jakość i wydajność.

Wersja 3 podsystemu kamery łączy tryby działania w jeden ujednolicony widok, który można wykorzystać do wdrożenia dowolnego z poprzednich trybów oraz kilku innych, takich jak tryb zdjęć seryjnych. Zapewnia to lepszą kontrolę użytkownika nad ostrością i ekspozycją, a także większą liczbę procesów przetwarzania końcowego, takich 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 klatek na klatki w stosunku 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 najprościej, struktura aplikacji żąda ramki z podsystemu kamery, a podsystem kamery zwraca wyniki do strumienia wyjściowego. Ponadto dla każdego zestawu wyników generowane są metadane zawierające takie informacje, jak przestrzenie kolorów i cieniowanie soczewki. Możesz myśleć o wersji 3 kamery jako o potoku prowadzącym do jednokierunkowego strumienia z kamery w wersji 1. Konwertuje każde żądanie przechwycenia na jeden obraz zarejestrowany przez czujnik, który jest przetwarzany na:

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

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

  • Każda powierzchnia jest miejscem docelowym strumienia buforów obrazu o ustalonej rozdzielczości.
  • Tylko niewielką liczbę powierzchni można skonfigurować jednocześnie jako wyjścia (~3).

Żądanie zawiera wszystkie żądane ustawienia przechwytywania i listę powierzchni wyjściowych, do których należy wypchnąć bufory obrazu dla tego żądania (z całkowitego skonfigurowanego zestawu). Żądanie może być jednorazowe (z capture() ) lub może być powtarzane w nieskończoność (z setRepeatingRequest() ). Przechwytywania mają pierwszeństwo przed powtarzającymi się żądaniami.

Model danych kamery

Rysunek 1. Model działania rdzenia kamery

Przegląd kamery HAL1

Wersja 1 podsystemu kamery została zaprojektowana jako czarna skrzynka z wysokim poziomem kontroli i trzema trybami pracy:

  • Zapowiedź
  • Zapis wideo
  • Nadal przechwytuj

Każdy tryb ma nieco inne i nakładające się możliwości. Utrudniało to wdrożenie nowych funkcji, takich jak tryb zdjęć seryjnych, który mieści się pomiędzy dwoma trybami pracy.

Schemat blokowy kamery

Rysunek 2. Elementy kamery

Android 7.0 nadal obsługuje kamerę HAL1, ponieważ wiele urządzeń nadal 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ć mniej wydajną kamerę przednią z kamerą HAL1 i bardziej zaawansowaną kamerę tylną z kamerą HAL3.

Istnieje moduł HAL z pojedynczą kamerą (z własnym numerem wersji ), który wyświetla listę wielu niezależnych kamer, 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ń kamerowych (to właśnie mamy na myśli, mówiąc, że Android obsługuje implementację obu warstw HAL).