Czujniki wielofunkcyjne HAL

Platforma Sensors Multi-HAL umożliwia współdziałanie HAL czujników kodami HAL innych czujników. Interfejs Sensors Multi-HAL dynamicznie wczytuje podrzędne wartości HAL czujników przechowywane jako biblioteki dynamiczne na partycji dostawcy i zwracają do nich żądania który może obsługiwać wysyłanie zdarzeń oraz pobieranie i zwalnianie blokady uśpienia. Sub-HAL czujnika to moduł HAL czujnika wbudowany we wspólny obiekt w partycjonowanie dostawcy i jest używane przez platformę obsługi wielu HAL. Te podrzędne konta HAL nie zależą od siebie lub od kodu HAL zawierającego funkcję główną na temat całego procesu.

Czujniki Multi-HAL 2.1, dostępne na urządzeniach z Androidem 11 lub wyższej, jest powtórzenia interfejsu Sensors Multi-HAL 2.0, który obsługuje wczytywanie podrzędnych list HAL, które mogą ujawnić kąt zawiasu typu czujnika. Aby obsługiwać ten typ czujnika, podrzędne interfejsy HAL muszą używać interfejsów API podrzędnych HAL. zdefiniowane w 2.1 Nagłówek SubHal.

Na urządzeniach z Androidem 13 lub nowszym, na których: HAL AIDL, możesz użyć podkładka z wieloma HAL, która umożliwia obsługę wielu HAL. Szczegóły implementacji: zobacz Korzystanie z czujników Multi-HAL z czujnikami AIDL HAL.

Różnica między czujnikami Multi-HAL 2 a czujnikami HAL 2

Czujniki Multi-HAL 2, dostępne na urządzeniach z Androidem 10 lub więcej, wprowadza kilka abstrakcji oprócz HAL Sensors, 2, aby ułatwić do interakcji z interfejsami HAL API. Interfejs Sensors Multi-HAL 2 wprowadza Serwer proxy do obsługi implementacji interfejsu Sensors HAL 2 oraz V2_1/SubHal. (lub V2_0/SubHal). aby umożliwić HalProxy wchodzenie w interakcję z sub-HAL.

Interfejs ISensorsSubHal różni się od interfejsu 2.1/ISensors.hal. (lub 2.0/ISensors.hal). w następujący sposób:

• Metoda inicjowania przekazuje IHalProxyCallback zamiast dwóch FMQ i ISensorsCallback.
• Sub-HAL musi obsługiwać funkcję debugowania informacje w raportach o błędach.
• Sub-HAL musi obsługiwać funkcję nazw, odróżniać się od innych subkont HAL.

Główna różnica między Czujnikami Multi-HAL 2 a Czujnikami HAL 2 polega na tym, zainicjuj funkcje. Zamiast wprowadzenia FMQ, IHalProxyCallback udostępnia 2 metody – jedną z nich do wysyłania zdarzeń z czujników do czujników. oraz jedną metodę tworzenia blokad uśpienia. Działanie czujnika Multi-HAL zarządza wszystkimi interakcjami z FMQ, aby zapewnić terminowe dostarczanie zdarzeń z czujników dla wszystkich podrzędnych kart HAL. Zdecydowanie zalecamy, aby w przypadku podrzędnych list pośrednich (HAL) zdecydowanie zalecamy stosowanie atrybutu Metoda createScopedWakelock przenosząca obciążenie związane z czasem wygaszania blokad uśpienia do: z funkcjami Sensors Multi-HAL i scentralizowaniu użycia blokad uśpienia w ramach jednej wspólnej blokady uśpienia dla całego interfejsu Sensors Multi-HAL, co minimalizuje blokowanie i odblokowywanie połączeń.

Czujniki Multi-HAL 2 mają też wbudowane funkcje bezpieczeństwa. Obsługuje gdy czujnik FMQ jest pełny lub gdy uruchomi się ponownie i trzeba zresetować stan czujnika. Ponadto, jeśli zdarzenia są została opublikowana w klasie HalProxy, ale platforma czujnika nie akceptuje zdarzenia od razu, funkcja Sensors Multi-HAL może przenieść je w tle w wątku, aby umożliwić kontynuowanie pracy na wszystkich podrzędnych listach HAL podczas oczekiwania na wydarzenia, które mają zostać opublikowane.

Implementacja kodu źródłowego i referencyjnego

Kod HAL wszystkich czujników jest dostępny w hardware/interfaces/sensors/common/default/2.X/multihal/ Oto kilka linków do materiałów.

• HalProxy.h: Wystąpienie obiektu HalProxy jest tworzone przez Sensors Multi-HAL i obsługuje przekazywanie danych z Sub-HAL do platformy czujnika.
• HalProxy.cpp: Implementacja HalProxy zawiera wszystkie funkcje logiczne niezbędne do komunikacji Multiplex między podrzędnymi produktami HAL a platformą czujnika.

• SubHal.h: Interfejs ISensorsSubHal definiuje interfejs, w którym podrzędne produkty HAL muszą , aby były zgodne z HalProxy. Sub-HAL implementuje aby można było używać obiektu HalProxyCallback postEvents i createScopedWakelock.

  W przypadku implementacji Multi-HAL 2.0 użyj wersji 2.0 SubHal.h

• hardware/interfaces/sensors/common/default/2.X/multihal/tests/: Te testy jednostkowe sprawdzają implementację HalProxy.

• hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/: Ta przykładowa implementacja sub-HAL wykorzystuje fałszywe czujniki, aby wygenerować fałszywe i skalowalnych danych. Ta opcja jest przydatna do sprawdzania, jak różne części podrzędne HAL współdziałają na urządzeniu.

Implementacja

W tej sekcji opisujemy, jak wdrożyć rozwiązanie Czujniki Multi-HAL w następujących sekcjach: w sytuacjach:

• Korzystanie z czujników Multi-HAL z czujnikami AIDL HAL
• Stosowanie czujników w formacie Multi-HAL 2.1
• Przenoszenie z Sensors Multi-HAL 2.0 na Multi-HAL 2.1
• Przenoszenie z poziomu Sensors HAL 2.0
• Przenoszenie z poziomu Sensors HAL 1.0
• Przenoszenie z sensorów Multi-HAL 1.0

Używaj czujników Multi-HAL z czujnikami AIDL HAL

Aby umożliwić obsługę wielu HAL za pomocą interfejsu HAL Sensors AIDL, zaimportuj AIDL Moduł warstwowej podkładki HAL, który znajduje się w sprzęt/interfejsy/czujniki/aidl/default/multihal/. Moduł obsługuje konwersję między czujnikami AIDL i HIDL i definiuje otokę wokół interfejsu HAL opisanego w Implementacja czujników Multi-HAL 2.1. Multi-HAL AIDL warstwa podkładkowa jest zgodna z urządzeniami z obsługą Sensors Multi-HAL 2.1.

Warstwa podkładek AIDL multi-HAL pozwala odsłonić tracker na głowie Ograniczone typy czujników IMU w interfejsie Sensors AIDL HAL. Aby użyć tego czujnika zdefiniowane przez interfejs AIDL HAL, ustaw pole type w Struktura SensorInfo w implementacji getSensorsList_2_1(). To jest bezpieczne ponieważ pola typu czujnika z wspieranym liczbą całkowitą w czujnikach AIDL i HIDL nie nakładają się na siebie.

Zastosuj czujniki Multi-HAL 2.1

Aby wdrożyć Sensors Multi-HAL 2.1 na nowym urządzeniu, wykonaj te czynności:

1. Zaimplementuj interfejs ISensorsSubHal, tak jak to opisano w SubHal.h
2. Zaimplementuj tag sensorsHalGetSubHal_2_1 w metodzie SubHal.h.

3. Dodaj cel cc_library_shared, aby utworzyć nowo wdrożoną podrzędną listę klientów (HAL). Podczas dodawania środowiska docelowego:

   1. Sprawdź, czy środowisko docelowe jest przekazywane do dowolnego miejsca u dostawcy partycję urządzenia.
   2. W pliku konfiguracyjnym znajdującym się pod adresem /vendor/etc/sensors/hals.conf dodaj ścieżkę do biblioteki w nowym wierszu. W razie potrzeby utwórz hals.conf.

   Przykładowy wpis Android.bp dotyczący tworzenia biblioteki podrzędnej HAL znajdziesz tutaj hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp

4. Usuń wszystkie wpisy (android.hardware.sensors) z manifest.xml. zawierający listę obsługiwanych kodów HAL na urządzeniu.

5. Usuń wszystkie usługi android.hardware.sensors i service.rc pliki z plik device.mk i dodaj do niego android.hardware.sensors@2.1-service.multihal i android.hardware.sensors@2.1-service.multihal.rc do PRODUCT_PACKAGES.

Podczas uruchamiania HalProxy szuka nowo wdrożonej części podrzędnej HAL i inicjuje go przez wywołanie sensorsHalGetSubHal_2_1

Port z Czujników Multi-HAL 2.0 na Multi-HAL 2.1

Aby zmienić protokół Multi-HAL 2.0 na Multi-HAL 2.1, zaimplementuj klucz SubHal i ponownie skompilować sub-HAL.

Różnice między interfejsami SubHal w wersjach 2.0 i 2.1:

• Funkcja IHalProxyCallback używa typów utworzonych w wersji 2.1 specyfikacji ISensors.hal.
• Funkcja initialize() przekazuje nowy IHalProxyCallback. zamiast interfejsu 2.0 SubHal.
• Sub-HAL musi implementować getSensorsList_2_1 i injectSensorData_2_1 zamiast getSensorsList i injectSensorData, ponieważ te metody używają nowe typy dodane w wersji 2.1 specyfikacji ISensors.hal.
• Sub-HAL musi udostępniać element sensorsHalGetSubHal_2_1, a nie sensorsHalGetSubHal dla multi-HAL, aby traktować je jako wersję 2.1 sub-HAL.

Port z Czujnika HAL 2.0

Uaktualnienie do systemu Sensors Multi-HAL 2.0 z modelu Sensors HAL 2.0, sprawdź, czy HAL spełnia poniższe wymagania.

Inicjowanie HAL

HAL 2.0 ma funkcję inicjowania, która umożliwia usłudze czujnika przekazywać sygnały FMQ i dynamiczne wywołanie zwrotne czujnika. W interfejsie Sensors Multi-HAL 2.0 Funkcja initialize() przekazuje jedno wywołanie zwrotne, które musi zostać użyte do opublikowania zdarzeń z czujników, uzyskiwanie blokad uśpienia oraz powiadamianie o dynamicznym połączeniu z czujnikiem oraz odłączania kont.

Publikuj zdarzenia z czujników w implementacji Multi-HAL

Zamiast publikować zdarzenia z czujników przez FMQ, interfejs podrzędny HAL musi zapisywać dane czujnika wydarzeń na IHalProxyCallback gdy dostępne są zdarzenia z czujnika.

Zdarzenia WAKE_UP

W przypadku interfejsu Sensors HAL 2.0 HAL może zarządzać blokadą uśpienia w ramach implementacji. W Czujniki Multi-HAL 2.0, podrzędne karty HAL umożliwiają implementację Multi-HAL zarządzać blokadami uśpienia i może zażądać uzyskania blokady uśpienia przez wywołanie createScopedWakelock Blokada uśpienia o zakresie zablokowanym musi zostać uzyskana i przekazana do postEvents, gdy publikowanie zdarzeń wybudzenia w implementacji Multi-HAL.

Czujniki dynamiczne

Czujniki Multi-HAL 2.0 wymagają tych elementów: onDynamicSensorsConnected i onDynamicSensorsDisconnected in IHalProxyCallback. są wywoływane zawsze, gdy zmienią się dynamiczne połączenia czujnika. Te wywołania zwrotne są dostępne w ramach wskaźnika IHalProxyCallback dostarczanego przez funkcji initialize().

Port z Czujnika HAL 1.0

Uaktualnienie do systemu Sensors Multi-HAL 2.0 z modelu Sensors HAL 1.0, sprawdź, czy HAL spełnia poniższe wymagania.

Inicjowanie HAL

W celu ustanowienia wywołania zwrotnego między funkcją initialize() musi być obsługiwana zarówno w przypadku treści podrzędnych, jak i multi-HAL.

Udostępnij dostępne czujniki

W przypadku Sensors Multi-HAL 2.0 funkcja getSensorsList() musi zwracać tę samą wartość podczas jednego rozruchu urządzenia, nawet wtedy, gdy HAL uruchamia się ponownie. Dzięki temu platformy do podejmowania prób ponownego nawiązania połączeń z czujnikiem, jeśli serwer systemu uruchomi się ponownie. Wartość zwrócona przez funkcję getSensorsList() może się zmienić, gdy urządzenie po ponownym uruchomieniu.

Publikuj zdarzenia z czujników w implementacji Multi-HAL

W usłudze Sensors HAL 2.0 zamiast czekać na wywołanie funkcji poll(), można użyć jej musi aktywnie zapisywać zdarzenia czujnika w IHalProxyCallback. .

Zdarzenia WAKE_UP

W przypadku interfejsu Sensors HAL 1.0 HAL może zarządzać blokadą uśpienia w celu jej implementacji. W Interfejsy Sensors Multi-HAL 2.0, podrzędne listy HAL umożliwiają implementację Multi-HAL zarządzać blokadami uśpienia i może zażądać uzyskania blokady uśpienia przez wywołanie createScopedWakelock Blokada uśpienia o zakresie zablokowanym musi zostać uzyskana i przekazana do postEvents, gdy publikowanie zdarzeń wybudzenia w implementacji Multi-HAL.

Czujniki dynamiczne

W HAL 1.0 czujniki dynamiczne są zwracane przez funkcję poll(). Czujniki Multi-HAL 2.0 wymagają tych elementów: onDynamicSensorsConnected i onDynamicSensorsDisconnected in IHalProxyCallback. są wywoływane zawsze, gdy zmienią się dynamiczne połączenia czujnika. Te wywołania zwrotne są dostępne w ramach wskaźnika IHalProxyCallback dostarczanego przez funkcji initialize().

Port z Czujnika Multi-HAL 1.0

Aby przenieść istniejącą implementację z: Czujniki Multi-HAL 1.0, wykonaj te czynności.

1. Sprawdź, czy konfiguracja HAL czujników znajduje się w /vendor/etc/sensors/hals.conf Może to wymagać przeniesienia pliku o /system/etc/sensors/hals.conf.
2. Usuń wszelkie odniesienia do hardware/hardware.h oraz hardware/sensors.h , które nie są obsługiwane w przypadku HAL 2.0.
3. Sub-HAL portów zgodnie z opisem w sekcji Przenoszenie z Sensors Hal 1,0.
4. Ustaw Sensors Multi-HAL 2.0 jako wyznaczoną HAL, wykonując kroki 3 i 4 w sekcji Implementowanie czujników Mutli-HAL 2.0.

Weryfikacja

Uruchom VTS

Po zintegrowaniu co najmniej jednej części podrzędnej HAL z modułami Sensors Multi-Hal 2.1 skorzystaj z Vendor Test Suite (VTS), aby upewnić się, że pod-HAL spełniają wszystkie wymagania określone w interfejsie HAL Sensors.

Aby uruchomić tylko testy VTS czujników po skonfigurowaniu VTS na hoście, wykonaj te polecenia:

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

Jeśli używasz warstwy podkładowej AIDL Multi-HAL, uruchom VtsAidlHalSensorsTargetTest.

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsAidlHalSensorsTargetTest

Przeprowadzanie testów jednostkowych

Testy jednostkowe w ramach HalProxy_test.cpp testu HalProxy z wykorzystaniem fałszywych treści podrzędnych z HAL, które są tworzone w teście jednostkowym i nie są ładowane dynamicznie. Podczas tworzenia testy jednostkowe, które służą jako wskazówka, jak dodawać testy jednostkowe, Sprawdź, czy nowy podHAL został prawidłowo zaimplementowany.

Aby uruchomić testy, wykonaj te polecenia:

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

Testowanie z wykorzystaniem fałszywych sub-HAL

Fałszywe sub-HAL to fikcyjne implementacje interfejsu ISensorsSubHal. Sub-HAL zawierają różne listy czujników. Gdy czujniki są aktywne, okresowo publikują automatycznie wygenerowane zdarzenia dotyczące czujnika w usłudze HalProxy na podstawie odstępów określonych w danym żądaniu czujnika.

Fałszywe sub-HAL można wykorzystać do przetestowania działania pełnego kodu Multi-HAL części składowych HAL wczytywanych do systemu i podkreślania różnych aspektów Kod HAL czujnika.

2 fałszywe sub-HAL są dostępne na hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/

Aby utworzyć fałszywe sub-HAL i przesłać je na urządzenie, wykonaj te czynności:

1. Uruchom następujące polecenia, aby utworzyć i przekazać 3 różne fałszywe na urządzeniu:

   $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
   mma
   adb push \
     $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
     /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
   adb push \
     $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
     /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
   adb push \
     $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
     /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
   

2. Zaktualizuj konfigurację HAL czujników w domenie /vendor/etc/sensors/hals.conf za pomocą ścieżek dla fałszywych podkatalogów HAL.

   /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
   /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
   /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
   

3. Uruchom ponownie usługę HalProxy i załaduj nowe podrzędne części HAL wymienione w konfiguracji.

   adb shell stop
   adb shell start
   

Debugowanie

Deweloperzy mogą debugować platformę za pomocą polecenia lshal. Aby przesłać prośbę o dane wyjściowe debugowania HAL Sensors, uruchom to polecenie:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

Informacje o bieżącym stanie klienta HalProxy i jego podrzędnych kont HAL będą dane wyjściowe do terminala. Poniżej przedstawiono przykładowe dane wyjściowe poleceń dla polecenia HalProxy obiekt i fałszywe sub-HAL.

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

Jeśli wartość podana w polu # of events on pending write queue to duża liczba (1000 lub więcej), oznacza to, że istnieje wiele zdarzeń oczekujących na zapisanie w czujnikach. platformy. Oznacza to, że usługa czujnika jest zablokowana lub uległa awarii, nie przetwarza zdarzeń czujnika lub że duża liczba takich zdarzeń opublikowane niedawno z sub-HAL.

Jeśli liczba referencji blokady uśpienia jest większa niż 0, oznacza to, że HalProxy ma następuje blokada uśpienia. Wartość powinna być większa od 0 tylko wtedy, gdy ScopedWakelock jest celowo wstrzymany lub jeśli na urządzenie HalProxy wysłano zdarzenia związane z wybudzeniem nie zostały przetworzone przez czujnik.

Deskryptor pliku przekazywany do metody debugowania w usłudze HalProxy jest przekazywany do każdego pod-HAL, więc deweloperzy muszą wdrożyć metodę debugowania w interfejsu ISensorsSubHal.