Czujniki AIDL HAL

HAL (Sensors Hardware Abstraction Layer) to interfejs między platformy czujników systemu Android i czujniki urządzenia, takie jak akcelerometr lub żyroskop. HAL Sensors definiuje funkcje, które należy zaimplementować, które pozwalają platformie na sterowanie czujnikami.

Interfejs Sensors AIDL HAL jest dostępny na urządzeniach z Androidem 13 oraz wyższy na nowych i uaktualnionych urządzeniach. HAL Sensors AIDL, który opiera się Sensors HAL 2.1 używa Interfejs AIDL HAL oraz prezentuje głowę trackera oraz czujniki IMU o ograniczonej osi.

Interfejs AIDL HAL

Głównym źródłem dokumentacji HAL Sensors AIDL jest kod HAL definicja na hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.

Wdrażanie interfejsu HAL Sensors AIDL

Aby wdrożyć HAL Sensors AIDL, obiekt musi rozszerzyć interfejs ISensors i zaimplementować wszystkie funkcje zdefiniowane w hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.

Inicjowanie HAL

HAL czujnika musi zostać zainicjowana przez platformę czujników Androida, zanim . Platforma wywołuje funkcję initialize(), aby zapewnić 3 parametry parametry do HAL Sensors: dwa deskryptory FMQ i jeden wskaźnik do ISensorsCallback obiekt.

HAL używa pierwszego deskryptora do utworzenia zdarzenia FMQ używanego do zapisu czujnika zdarzenia do struktury. HAL używa drugiego deskryptora do utworzenia Wybudzenia Blokada FMQ używana do synchronizacji, gdy HAL zwolni blokadę uśpienia na urządzeniu WAKE_UP zdarzeniami z czujnika. HAL musi zapisać wskaźnik do obiektu ISensorsCallback, że możliwe jest wywołanie wszystkich niezbędnych funkcji wywołania zwrotnego.

Funkcja initialize() musi być pierwszą funkcją wywoływaną podczas inicjowania HAL Sensors.

Udostępnij dostępne czujniki

Aby zobaczyć listę wszystkich czujników statycznych dostępnych w urządzeniu, użyj getSensorsList(). Ta funkcja zwraca listę czujników, każdy jest jednoznacznie identyfikowany przez nick. Uchwyt danego czujnika nie może się zmieniać gdy proces hostujący HAL Sensors uruchomi się ponownie. Nicki mogą się zmieniać w na nowo uruchamianych urządzeniach oraz na wszystkich serwerach systemowych.

Jeśli kilka czujników ma ten sam typ i właściwości wybudzania, Pierwszy czujnik na liście jest nazywany czujnikiem domyślnym i wraca do aplikacje, które korzystają z getDefaultSensor(int sensorType, bool wakeUp) .

Stabilność listy czujników

Po ponownym uruchomieniu HAL Sensors, jeśli dane zwrócone przez getSensorsList() wskazuje istotną zmianę w porównaniu z listą czujników pobraną przed uruchamia ponownie platformę Środowisko wykonawcze Androida. Znaczące zmiany na liście czujników obejmują przypadki, gdy brakuje czujnika z danym nickiem, zmieniły się jego atrybuty lub stosowane są czujniki. Chociaż ponowne uruchomienie środowiska wykonawczego Androida zakłóca działanie użytkownika, jest to wymagane, ponieważ platforma Androida nie może już spełnić Umowa interfejsu API Androida, zgodnie z którą czujniki statyczne (niedynamiczne) nie zmieniają się podczas od początku istnienia aplikacji. Może to też uniemożliwić przywrócenie platformy żądań czujnika wysyłanych przez aplikacje. Dlatego zalecamy, aby dostawcy usług HAL aby zapobiec możliwym do uniknięcia zmianom listy czujników.

Aby zapewnić stabilne uchwyty czujników, HAL musi deterministycznie zmapować dany fizyczny czujnik do uchwytu urządzenia. Chociaż nie ma konkretnej implementacji jest obsługiwane przez interfejs Sensors HAL, programiści mają do wyboru wiele opcji, które spełnią ten wymóg.

Na przykład listę czujników można sortować, korzystając z kombinacji danych każdego z czujników stałe atrybuty, takie jak dostawca, model i typ czujnika. Inna opcja wymaga na fakcie, że zestaw czujników statycznych urządzenia jest zamontowany na stałe, HAL musi mieć informację o tym, że zostały zainicjowane wszystkie oczekiwane czujniki wracam z: getSensorsList(). Ta lista może być kompilowane do pliku binarnego HAL lub przechowywane w konfiguracji pliku w systemie plików. Możesz też stosować kolejność występowania aby uzyskać stabilne uchwyty. Chociaż najlepsze rozwiązanie zależy od identyfikatora HAL szczegóły implementacji, najważniejszym wymaganiem jest to, żeby czujnik nie zmieniają się po ponownym uruchomieniu HAL.

Skonfiguruj czujniki

Zanim czujnik zostanie aktywowany, musi zostać skonfigurowany za pomocą próbkowania okresu i maksymalnego opóźnienia raportowania za pomocą funkcji batch().

Czujnik musi być w każdej chwili ponownie skonfigurowany za pomocą batch() bez utraty danych z czujnika.

Okres próbkowania

Okres próbkowania ma różne znaczenie w zależności od typu czujnika konfigurowanie:

  • Ciągłe: zdarzenia z czujników są generowane w sposób ciągły.
  • W przypadku zmiany: zdarzenia są generowane nie wcześniej niż w okresie próbkowania i mogą generowane z szybkością mniejszą niż okres próbkowania, jeśli mierzona wartość nie zmienia się.
  • Jednorazowe: okres próbkowania jest ignorowany.
  • Specjalne: więcej szczegółów znajdziesz w Typy czujników.

Aby dowiedzieć się więcej o interakcji między okresem próbkowania a parametrem czujnika Dowiedz się więcej o trybach raportowania.

Maksymalne opóźnienie raportowania

Maksymalne opóźnienie raportowania określa maksymalny czas (w nanosekundach), zdarzenia mogą być opóźnione i zapisywane w sprzętowym FIFO przed ich zapisaniem w gdy komponent SOC jest wybudzony, przesyła zdarzenie FMQ przez HAL.

Wartość 0 oznacza, że zdarzenia muszą być raportowane od razu po ich wystąpieniu z pominięciem FIFO lub opróżnieniem go natychmiast w FIFO występuje jedno zdarzenie z czujnika.

Na przykład akcelerometr aktywowany przy częstotliwości 50 Hz z raportowaniem maksymalnym czas oczekiwania z 0 wyzwalaczy przerywa działanie 50 razy na sekundę, gdy układ SoC jest aktywny.

Gdy maksymalny czas oczekiwania na raportowanie jest większy niż 0, zdarzenia z czujnika które należy zgłaszać od razu po ich wykryciu. Zdarzenia mogą być tymczasowe przechowywane w sprzętowym FIFO i zgłaszane partiami, o ile żadne zdarzenia jest opóźniony o więcej niż maksymalne opóźnienie raportowania. Wszystkie zdarzenia od poprzednia grupa zostanie zarejestrowana i zwrócona jednocześnie. Zmniejsza to liczbę przerywa działanie wysyłane do układu SOC i umożliwia przejście układu SoC na tryb oszczędzania energii w czasie, gdy czujnik zbiera i grupuje dane.

Z każdym zdarzeniem jest powiązana sygnatura czasowa. Opóźnianie czasu oczekiwania na odpowiedź nie może wpływać na sygnaturę czasową tego zdarzenia. Sygnaturą czasową musi być dokładne i odpowiadają momentowi, w którym zdarzenie faktycznie miało miejsce, a nie w momencie zgłoszenia.

Dodatkowe informacje i wymagania dotyczące raportowania zdarzeń z czujnika za pomocą maksymalny czas oczekiwania na raportowanie niezerowy. Więcej informacji znajdziesz w sekcji Grupowanie wsadowe.

Aktywuj czujniki

Platforma włącza i wyłącza czujniki za pomocą funkcji activate(). Zanim aktywujesz czujnik, platforma musi go najpierw skonfigurować. za pomocą funkcji batch().

Po dezaktywacji czujnika dodatkowe zdarzenia pochodzące z tego czujnika nie mogą być być zapisywane w FMQ zdarzenia.

Czujniki płukania

Jeśli czujnik jest skonfigurowany do zbierania danych z czujnika wsadowego, platforma może wymusić natychmiastowe usunięcie grupowych zdarzeń z czujnika przez wywołanie funkcji flush(). To powoduje dla określonego uchwytu czujnika zdarzenia grupowe dla czujnika mają być natychmiastowe zapisane w FMQ zdarzenia. HAL Sensors musi dołączyć zdarzenie zakończenia opróżniania na końcu zdarzeń czujnika, które są zapisywane w wyniku wywołania funkcji flush()

Usuwanie danych odbywa się asynchronicznie (tzn. ta funkcja musi zwracać od razu). Jeśli w implementacji używany jest jeden FIFO dla kilku czujników, opróżniono, a zdarzenie zakończenia opróżniania jest dodawane tylko dla określonego czujnika.

Jeśli określony czujnik nie ma FIFO (brak możliwości buforowania) lub FIFO został puste w czasie wywołania, polecenie flush() nadal musi się udać i wysłać flush dla tego czujnika. Dotyczy to wszystkich czujników oprócz jednego ujęcia i czujników.

Jeśli zasada flush() jest wywoływana dla czujnika pojedynczego uderzenia, funkcja flush() musi zwrócić BAD_VALUE i nie generują zdarzenia zakończenia usuwania.

Zapisuj zdarzenia z czujnika w FMQ

FMQ zdarzenia używa interfejsu Sensors HAL do przekazywania zdarzeń z czujników do systemu Android. platformy czujnika.

Zdarzenie FMQ jest zsynchronizowanym FMQ, co oznacza, że każda próba zapisu zdarzeń do FMQ, niż pozwala na to dostępna przestrzeń. i zapis. W takim przypadku HAL powinien określić, czy zapisać bieżący zestaw zdarzeń jako 2 mniejszych grup zdarzeń lub zapisu wszystkich zdarzeń, jednocześnie, gdy dostępna jest wystarczająca ilość miejsca.

Gdy HAL czujnika zapisze pożądaną liczbę zdarzeń z czujnika w Zdarzenie FMQ, HAL Sensors musi powiadamiać platformę, że zdarzenia są gotowe zapisywanie bitów EventQueueFlagBits::READ_AND_PROCESS zdarzenia w FMQ zdarzenia EventFlag::wake. Flagę zdarzenia można utworzyć w FMQ zdarzenia. przy użyciu funkcji EventFlag::createEventFlag oraz zdarzeń getEventFlagWord() zdarzenia FMQ .

HAL czujnika AIDL obsługuje zarówno write, jak i writeBlocking w zdarzeniu FMQ. Domyślna implementacja dostarcza referencji do write. Jeśli używana jest funkcja writeBlocking, flaga readNotification musi być ustawiona na EventQueueFlagBits::EVENTS_READ, która jest ustawiana przez platformę, gdy odczytuje zdarzeń ze zdarzenia FMQ. Flaga powiadomienia o zapisie musi być ustawiona na EventQueueFlagBits::READ_AND_PROCESS, który powiadamia platformę, że zdarzenia zostały zapisane w FMQ – Wydarzenie.

Zdarzenia WAKE_UP

Zdarzenia WAKE_UP to zdarzenia z czujnika, które powodują, że procesor aplikacji (AP) od razu się obudzić i zajmij się tym zdarzeniem. Za każdym razem, gdy zapisywane jest zdarzenie WAKE_UP do zdarzenia FMQ, HAL Sensors musi zabezpieczyć blokadę uśpienia, system pozostaje aktywny, dopóki platforma nie będzie w stanie obsłużyć zdarzenia. Po otrzymaniu WAKE_UP, platforma zabezpiecza własną blokadę uśpienia, pozwalając Czujniki HAL w celu odblokowania blokady uśpienia. Aby zsynchronizować, gdy HAL Sensors zwalnia blokadę uśpienia, użyj blokady Wake Lock FMQ.

HAL czujników musi odczytać FMQ blokady uśpienia, aby określić liczbę WAKE_UP. zdarzenia obsłużone przez platformę. HAL powinna włączać tylko blokadę uśpienia dla WAKE_UP zdarzeń, jeśli łączna liczba nieobsługiwanych zdarzeń WAKE_UP wynosi 0. Po obsłudze zdarzeń czujnika platforma zlicza liczbę zdarzeń, które są zostanie oznaczony jako zdarzenie WAKE_UP i zapisze ten numer z powrotem w Wake Lock FMQ.

Platforma ustawia zapis w WakeLockQueueFlagBits::DATA_WRITTEN powiadomienia na Wake Lock FMQ za każdym razem, gdy zapisze dane w FMQ.

Czujniki dynamiczne

Czujniki dynamiczne to czujniki, które nie są fizycznie częścią urządzenia, ale mogą być używane jako dane wejściowe urządzenia, np. pad do gier z akcelerometrem.

Po podłączeniu czujnika dynamicznego funkcja onDynamicSensorConnected w Pole ISensorsCallback musi być wywoływane z panelu HAL Sensors. Spowoduje to powiadamianie konstrukcji nowego czujnika dynamicznego i umożliwia sterowanie czujnikiem w ramach platformy i umożliwiać klientom rejestrowanie zdarzeń z czujnika.

Podobnie, gdy czujnik dynamiczny zostanie odłączony, Funkcja onDynamicSensorDisconnected w funkcji ISensorsCallback musi być tak wywoływana że platforma może usunąć czujnik, który nie jest już dostępny.

Kanał bezpośredni

Kanał bezpośredni to metoda działania, w której zdarzenia z czujnika są zapisywane w w konkretnej pamięci, a nie w FMQ, omijając czujniki Androida. Platforma. Klient, który rejestruje kanał bezpośredni, musi odczytywać zdarzenia z czujnika bezpośrednio z pamięci użytej do utworzenia kanału bezpośredniego i nie będzie i rejestrowania zdarzeń z czujnika za pomocą platformy. configDirectReport() funkcja jest podobna do funkcji batch() w przypadku normalnego działania i konfiguruje bezpośrednie kanału raportu.

Funkcje registerDirectChannel() i unregisterDirectChannel() tworzą lub zniszczenie nowego kanału bezpośredniego.

Tryby operacji

Funkcja setOperationMode() umożliwia platformie skonfigurowanie czujnika aby platforma mogła wstrzykiwać do czujnika dane. Przydaje się to w przypadku zwłaszcza w przypadku algorytmów, które działają poniżej platformy.

Funkcja injectSensorData() jest zwykle używana do przekazywania operacji do interfejsu Sensors HAL. Za pomocą tej funkcji można też wprowadzić dane z czujnika zdarzenia do określonego czujnika.

Weryfikacja

Aby sprawdzić poprawność implementacji interfejsu HAL Sensors, uruchom CTS i VTS czujnika testów.

Testy CTS

Testy CTS czujników występują zarówno w automatycznych testach CTS, jak i ręcznym weryfikatorze CTS .

Zautomatyzowane testy znajdują się tutaj: cts/tests/sensor/src/android/hardware/cts. Te testy służą do sprawdzenia standardowych funkcji czujników, takich jak aktywacja z czujników, grupowania i częstotliwości zdarzeń z czujników.

Testy weryfikatora CTS znajdują się tutaj: cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors. Testy wymagają ręcznego wprowadzenia danych przez operatora testowego i zapewniają, że czujniki podaj dokładne wartości.

Zaliczenie testów CTS ma kluczowe znaczenie dla zapewnienia zgodności testowanego urządzenia wszystkie wymagania CDD.

Testy VTS

Testy VTS dla HAL Sensors AIDL znajdują się sprzęt/interfejsy/czujniki/aidl/vts/. Te testy służą do sprawdzenia, czy kod HAL Sensors został wdrożony prawidłowo i czy wszystkie wymagania w zakresie ISensors.aidl i ISensorsCallback.aidl są prawidłowo spełnione.

Inicjowanie HAL

Funkcja initialize() musi być obsługiwana w celu ustanowienia FMQ między platformy i HAL.

Udostępnij dostępne czujniki

W HAL interfejsu Sensors AIDL funkcja getSensorsList() musi zwracać tę samą wartość podczas jednego uruchomienia urządzenia, nawet w przypadku ponownego uruchomienia HAL Sensors. Nowe wymaganie funkcji getSensorsList() jest to, że musi ona zwracać tę samą wartość podczas pojedynczego urządzenia, nawet w przypadku ponownego uruchomienia HAL Sensors. 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.

Zapisuj zdarzenia z czujnika w FMQ

Zamiast czekać na wywołanie funkcji poll(), w interfejsie HAL Sensors AIDL HAL musi aktywnie zapisywać zdarzenia z czujnika w FMQ za każdym razem, gdy takie zdarzenie zostanie wykryte. są dostępne. HAL odpowiada również za zapisywanie prawidłowych bitów w EventFlag powoduje odczyt FMQ w ramach platformy.

Zdarzenia WAKE_UP

W przypadku interfejsu Sensors HAL 1.0 HAL był w stanie odblokować blokadę uśpienia dla każdego urządzenia WAKE_UP podczas każdego kolejnego połączenia z numerem poll() po opublikowaniu wiadomości WAKE_UP w poll(), ponieważ oznaczało to, że platforma przetworzyła cały czujnik zdarzeń i w razie potrzeby uzyskać blokadę uśpienia. Ponieważ w interfejsie Sensors AIDL HAL, HAL nie jest już powiadamiany, gdy platforma przetworzyła zdarzenia zapisanych w FMQ, Wake Lock FMQ umożliwia architekturze komunikację z HAL, jeśli obsługuje zdarzenia WAKE_UP.

W panelu HAL Sensors AIDL blokada uśpienia zabezpieczona przez HAL czujnika na WAKE_UP zdarzenia muszą zaczynać się od SensorsHAL_WAKEUP.

Czujniki dynamiczne

Czujniki dynamiczne zostały zwrócone przy użyciu funkcji poll() w programie Sensors HAL 1.0. HAL czujnika AIDL wymaga tych elementów: onDynamicSensorsConnected i Metoda onDynamicSensorsDisconnected w ISensorsCallback jest wywoływana zawsze wtedy, gdy jest dynamiczna połączenia czujnika się zmieniają. Te wywołania zwrotne są dostępne w ramach Wskaźnik ISensorsCallback dostarczany przez funkcję initialize().

Tryby operacji

Tryb DATA_INJECTION czujników WAKE_UP musi być obsługiwany.

Obsługa wielu HAL

Interfejs Sensors AIDL HAL obsługuje wiele HAL za pomocą Platforma Sensors Multi-HAL. Dla: szczegóły implementacji można znaleźć w Przenoszenie z poziomu Sensors HAL 2.1.