HAL aparatu

Warstwę abstrakcji sprzętu aparatu (HAL) w Androidzie łączy interfejsy API frameworku aparatu wyższego poziomu android.hardware.camera2 z podstawowym sterownikiem aparatu i sprzętem. Od Androida 13 rozwój interfejsu HAL kamery korzysta z AIDL. W Androidzie 8.0 wprowadzono Treble, który zastąpił interfejs Camera HAL API, zapewniając stabilny interfejs zdefiniowany za pomocą języka opisu interfejsu HAL (HIDL). Jeśli wcześniej opracowaliśmy moduł HAL aparatu i sterownik dla systemu Android 7.0 lub niższego, należy pamiętać o znacznych zmianach w przetwarzaniu obrazu.

Interfejs HAL aparatu AIDL

W przypadku urządzeń z Androidem 13 lub nowszym framework aparatu obsługuje interfejsy HAL aparatu AIDL. Platforma aparatu obsługuje również interfejsy HIDL, ale funkcje aparatu dodane w Androidzie 13 lub nowszym są dostępne tylko przez interfejsy AIDL. Aby wdrożyć takie funkcje na urządzeniach aktualizowanych do Androida 13 lub nowszego, producenci urządzeń muszą przenieść proces HAL z interfejsów HIDL na interfejsy AIDL.

Więcej informacji o zaletach AIDL znajdziesz w artykule AIDL dla HAL.

Wdrożenie interfejsu HAL aparatu AIDL

Implementację referencyjną interfejsu HAL aparatu AIDL znajdziesz w  hardware/google/camera/common/hal/aidl_service/.

Specyfikacje interfejsu HAL aparatu AIDL znajdują się w tych miejscach:

W przypadku urządzeń przechodzących na AIDL producenci mogą potrzebować zmodyfikowania zasad SELinux Androida (sepolicy) i plików RC w zależności od struktury kodu.

Weryfikacja interfejsu HAL aparatu AIDL

Aby przetestować implementację interfejsu HAL kamery AIDL, sprawdź, czy urządzenie przechodzi wszystkie testy CTS i VTS. Android 13 wprowadza test AIDL VTS, VtsAidlHalCameraProvider_TargetTest.cpp.

Funkcje Camera HAL3

Celem przeprojektowania interfejsu Camera API na Androida jest znaczne zwiększenie możliwości aplikacji w sterowaniu podsystemem kamery na urządzeniach z Androidem przy jednoczesnej reorganizacji interfejsu API w celu zwiększenia jego wydajności i łatwości konserwacji. Ta dodatkowa kontrola ułatwia tworzenie na urządzeniach z Androidem aplikacji aparatu o wysokiej jakości, które mogą niezawodnie działać w różnych produktach, a jednocześnie korzystać z algorytmów dostosowanych do danego urządzenia, aby w miarę możliwości maksymalizować jakość i wydajność.

Wersja 3.0 podsystemu aparatu porządkuje tryby działania w jednym ujednoliconym widoku, który można wykorzystać do implementacji wszystkich poprzednich trybów oraz kilku innych, takich jak tryb seryjny. Dzięki temu użytkownik ma większą kontrolę nad ostrością i ekspozycją oraz większą liczbę opcji przetwarzania w poście, takich jak redukcja szumów, kontrast i wyostrzanie. Ponadto uproszczone wyświetlanie ułatwia deweloperom aplikacji korzystanie z różnych funkcji aparatu.

Interfejs API modeluje podsystem kamery jako potok, który konwertuje przychodzące żądania dotyczące ujęć w ramki na ujęcia w ramce 1:1. Żądania zawierają wszystkie informacje o konfiguracji dotyczące rejestrowania i przetwarzania klatki. Obejmuje to rozdzielczość i format pikseli, ręczne sterowanie czujnikiem, obiektywem i lampą błyskową, tryby działania 3A, przetwarzanie RAW → YUV, generowanie statystyk itp.

Mówiąc w prosty sposób, platforma aplikacji prosi o ramkę z podsystemu kamery, a podsystem kamery zwraca wyniki do strumienia wyjściowego. Dodatkowo dla każdego zestawu wyników generowane są metadane zawierające informacje takie jak przestrzenie barw i zacienienie obiektywu. Wersję 3 kamery możesz traktować jako kanał do jednokierunkowej transmisji z wersji 1. Każde żądanie przechwytywania jest przekształcane w jeden obraz zarejestrowany przez czujnik, który jest przetwarzany w postaci:

  • Obiekt wyniku z metadanymi dotyczącymi przechwycenia.
  • Bufory danych obrazu typu „jeden do N”, z których każdy jest przeznaczony do osobnej powierzchni docelowej.

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

  • Każda powierzchnia jest miejscem docelowym dla strumienia buforów obrazów o stałej rozdzielczości.
  • Jako wyjścia można skonfigurować tylko niewielką liczbę powierzchni (około 3).

Żądanie zawiera wszystkie żądane ustawienia przechwytywania i listę powierzchni wyjściowych, na których mają być umieszczane bufory obrazów (z całego skonfigurowanego zestawu). Żądanie może być jednorazowe (z capture()) lub może być powtarzane w nieskończoność (z setRepeatingRequest()). Zapisy mają pierwszeństwo przed powtarzającymi się żądaniami.

Model danych aparatu

Rysunek 1. Model podstawowy działania aparatu

Omówienie interfejsu Camera HAL1

Wersja 1 aparatu została zaprojektowana jako czarna skrzynka z ogólnymi elementami sterującymi i 3 trybami działania:

  • Podgląd
  • Nagrywanie wideo
  • Zdjęcie

Każdy tryb ma nieco inne i nakładające się możliwości. Utrudniało to wdrażanie nowych funkcji, takich jak tryb serii, który znajduje się pomiędzy dwoma trybami pracy.

Schemat blokowy kamery

Rysunek 2. Części aparatu

Android 7.0 nadal obsługuje komponent HAL1 aparatu, ponieważ wiele urządzeń nadal z niego korzysta. Usługa aparatu Androida obsługuje implementację obu komponentów HAL (1 i 3), co jest przydatne, gdy chcesz obsługiwać mniej wydajny przedni aparat za pomocą komponentu HAL1 i bardziej zaawansowany tylny aparat za pomocą komponentu HAL3.

Jest 1 moduł HAL kamery (z własnym numerem wersji), który zawiera listę wielu niezależnych urządzeń kamery, z których każde ma własny numer wersji. Obsługa urządzeń 2 lub nowszych wymaga modułu aparatu 2 lub nowszego. Takie moduły aparatu mogą mieć różne wersje urządzeń (oznacza to, że Android obsługuje implementację obu komponentów HAL).