Warstwa abstrakcji sprzętu aparatu (HAL) na Androidzie łączy interfejsy API platformy aparatu wyższego poziomu w pakiecie 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, czyli zmianę interfejsu API HAL aparatu na stabilny interfejs zdefiniowany przez język opisu interfejsu HAL (HIDL). Jeśli masz już opracowany moduł HAL aparatu i sterownik dla Androida 7.0 i starszych wersji, pamiętaj o istotnych zmianach w potoku aparatu.
Warstwa HAL aparatu AIDL
W przypadku urządzeń z Androidem 13 lub nowszym framework 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-i.
Implementowanie interfejsu HAL aparatu AIDL
Przykładową implementację interfejsu HAL aparatu AIDL znajdziesz w tym
hardware/google/camera/common/hal/aidl_service/
.
Specyfikacje interfejsu HAL aparatu AIDL 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ą być zmuszeni do zmodyfikowania zasad SELinux w Androidzie (sepolicy) i plików 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
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 wysokiej jakości, które mogą działać niezawodnie na różnych urządzeniach, 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. Ponadto ten uproszczony widok ułatwia 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 aparatu, a ten 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.
- Jako wyjścia można skonfigurować tylko niewielką liczbę powierzchni (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 podstawowego działania aparatu
Omówienie HAL1 aparatu
Wersja 1 podsystemu aparatu została zaprojektowana jako czarna skrzynka z elementami sterującymi wyższego poziomu i 3 trybami działania:
- Podgląd
- Nagrywanie filmu
- Zdjęcia
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 dwoma 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 w Androidzie obsługuje też implementację obu interfejsów HAL (1 i 3), co jest przydatne, gdy chcesz obsługiwać mniej zaawansowany aparat przedni za pomocą interfejsu HAL aparatu 1 i bardziej zaawansowany aparat tylny za pomocą interfejsu HAL aparatu 3.
Jest jeden moduł HAL aparatu (z własnym numerem wersji), który zawiera listę wielu niezależnych urządzeń z aparatem. 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 (to mamy na myśli, gdy mówimy, że Android obsługuje implementację obu interfejsów HAL).