Warstwa abstrakcji sprzętu (HAL) aparatu na Androidzie łączy interfejsy API frameworka aparatu wyższego poziomu w android.hardware.camera2 z podstawowym sterownikiem i sprzętem aparatu. Od Androida 13 interfejs HAL aparatu jest tworzony przy użyciu AIDL. W Androidzie 8.0 wprowadzono Treble, co spowodowało zmianę interfejsu API HAL aparatu na stabilny interfejs zdefiniowany przez język opisu interfejsu HAL (HIDL). Jeśli masz już moduł HAL aparatu i sterownik dla Androida 7.0 lub starszego, pamiętaj o istotnych zmianach w potoku aparatu.
Warstwa HAL aparatu AIDL
W przypadku urządzeń z Androidem 13 lub nowszym platforma aparatu obsługuje interfejsy HAL aparatu AIDL. Framework aparatu obsługuje też interfejsy HAL aparatu HIDL, ale funkcje aparatu dodane w Androidzie 13 lub nowszym są dostępne tylko przez interfejsy HAL aparatu AIDL. Aby wdrożyć takie funkcje na urządzeniach, które zostaną zaktualizowane do Androida 13 lub nowszego, producenci urządzeń muszą przenieść proces HAL z interfejsów aparatu HIDL na interfejsy aparatu AIDL.
Więcej informacji o zaletach AIDL znajdziesz w artykule AIDL dla HAL-ów.
Implementowanie interfejsu HAL aparatu AIDL
Przykładową implementację interfejsu HAL aparatu AIDL znajdziesz w tym artykule:
hardware/google/camera/common/hal/aidl_service/
Specyfikacje AIDL HAL aparatu znajdują się w tych lokalizacjach:
- Dostawca aparatu:
hardware/interfaces/camera/provider/aidl/ - Urządzenie z aparatem:
hardware/interfaces/camera/device/aidl/ - Metadane aparatu:
hardware/interfaces/camera/metadata/aidl/ - Typowe typy danych:
hardware/interfaces/camera/common/aidl/
W przypadku urządzeń przechodzących na AIDL producenci mogą musieć zmodyfikować zasady SELinux w Androidzie (sepolicy) i pliki RC w zależności od struktury kodu.
Weryfikacja interfejsu HAL aparatu AIDL
Aby przetestować implementację AIDL HAL aparatu, upewnij się, że urządzenie przechodzi wszystkie testy CTS i VTS. Android 13 wprowadza test AIDL VTS
test,
VtsAidlHalCameraProvider_TargetTest.cpp.
Funkcje Camera HAL3
Celem przeprojektowania interfejsu Android Camera API jest znaczne zwiększenie możliwości sterowania przez aplikacje podsystemem aparatu na urządzeniach z Androidem przy jednoczesnym przeorganizowaniu interfejsu API, aby był bardziej wydajny i łatwiejszy w utrzymaniu. Dodatkowa kontrola ułatwia tworzenie na urządzeniach z Androidem aplikacji aparatu o wysokiej jakości, które mogą działać niezawodnie na różnych produktach, a jednocześnie w miarę możliwości korzystać z algorytmów specyficznych dla danego urządzenia, aby zmaksymalizować jakość i wydajność.
Wersja 3 podsystemu aparatu porządkuje tryby działania w jednym ujednoliconym widoku, którego można używać do implementowania wszystkich poprzednich trybów i kilku innych, np. trybu zdjęć seryjnych. Dzięki temu użytkownik ma większą kontrolę nad ostrością i ekspozycją, a także może przeprowadzać więcej operacji przetwarzania końcowego, takich jak redukcja szumów, kontrast i wyostrzanie. Ten uproszczony widok ułatwia też deweloperom aplikacji korzystanie z różnych funkcji aparatu.
Interfejs API modeluje podsystem aparatu jako potok, który konwertuje przychodzące żądania przechwytywania klatek na klatki w stosunku 1:1. Żądania zawierają wszystkie informacje o konfiguracji dotyczące przechwytywania i przetwarzania klatki. Obejmuje to rozdzielczość i format pikseli, ręczne sterowanie czujnikiem, obiektywem i lampą błyskową, tryby działania 3A, sterowanie przetwarzaniem RAW->YUV, generowanie statystyk itp.
Mówiąc prościej, platforma aplikacji wysyła żądanie klatki do 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żna traktować jako potok do jednokierunkowej transmisji wersji 1. Każde żądanie przechwytywania jest konwertowane na 1 obraz zarejestrowany przez czujnik, który jest przetwarzany na:
- Obiekt wyniku z metadanymi dotyczącymi przechwytywania.
- Od 1 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 stałej rozdzielczości.
- Jednocześnie można skonfigurować tylko niewielką liczbę powierzchni jako wyjścia (około 3).
Żądanie zawiera wszystkie wybrane ustawienia przechwytywania i listę powierzchni wyjściowych, do których mają być przesyłane bufory obrazów (z całego skonfigurowanego zestawu). Żądanie może być jednorazowe (z capture()) lub powtarzane w nieskończoność (z setRepeatingRequest()). Zrzuty mają priorytet przed powtarzającymi się żądaniami.
Rysunek 1. Model podstawowej operacji aparatu
Omówienie HAL1 aparatu
Wersja 1 podsystemu kamery została zaprojektowana jako czarna skrzynka z kontrolkami wysokiego poziomu i 3 trybami działania:
- Podgląd
- Nagrywanie filmu
- Zdjęcie
Każdy tryb ma nieco inne i częściowo pokrywające się możliwości. Utrudniało to wdrażanie nowych funkcji, takich jak tryb zdjęć seryjnych, który mieści się między 2 trybami działania.
Rysunek 2. Komponenty aparatu
Android 7.0 nadal obsługuje komponent HAL1 aparatu, ponieważ wiele urządzeń nadal z niego korzysta. Usługa aparatu Androida obsługuje też implementację obu komponentów HAL (1 i 3), co jest przydatne, gdy chcesz obsługiwać mniej zaawansowany aparat przedni za pomocą komponentu HAL aparatu 1 i bardziej zaawansowany aparat tylny za pomocą komponentu HAL aparatu 3.
Jest jeden moduł HAL kamery (z własnym numerem wersji), który zawiera listę wielu niezależnych urządzeń z kamerą. Każde z nich ma własny numer wersji. Moduł aparatu w wersji 2 lub nowszej jest wymagany do obsługi urządzeń w wersji 2 lub nowszej. Takie moduły aparatu mogą mieć różne wersje urządzenia z aparatem (w tym sensie Android obsługuje implementację obu interfejsów HAL).