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, co oznacza przejście z interfejsu Camera HAL API na stabilny interfejs zdefiniowany za pomocą języka opisu interfejsu HAL (HIDL). Jeśli wcześniej opracowaliśmy moduł HAL aparatu i sterownik do systemu Android 7.0 lub niższego, należy pamiętać o istotnych 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 pliku 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 urządzeń 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 HAL3 aparatu

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. Te dodatkowe opcje ułatwiają 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żytkownicy mają lepszą kontrolę nad ostrością i ekspozycją oraz usprawniają przetwarzanie, np. redukcję szumów, kontrastu 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 przechwytywania klatek na klatki w trybie 1:1. Żądania zawierają wszystkie informacje o konfiguracji dotyczące przechwytywania i przetwarzania ramki. Obejmuje to rozdzielczość i format pikseli, ręczne sterowanie czujnikiem, obiektywem i lampą błyskową, tryby działania 3A, przetwarzanie RAW → YUV, generowanie statystyk itd.

Mówiąc najprościej, platforma aplikacji wysyła żądanie klatki 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 kolorów i cieniowanie 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 oraz listę powierzchni wyjściowych, do których mają trafiać bufory obrazów dla tego żądania (spośród wszystkich skonfigurowanych zestawów). Żądanie może być jednorazowe (z capture()) lub powtarzane w nieskończoność (z setRepeatingRequest()). Przechwytywanie ma wyższy priorytet niż powtarzające się żądania.

Model danych kamery

Rysunek 1. Model podstawowej operacji kamery

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 zdjęć z serii, który należy do 2 trybów działania.

Schemat bloku kamery

Rysunek 2. Części do aparatów

Android 7.0 nadal obsługuje interfejs 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. Moduł 2 lub nowszy aparatu obsługuje urządzenia 2 lub nowsze, które mogą występować w różnych wersjach aparatów (mamy na myśli, że Android obsługuje obie interfejsy HAL).