Stos czujników

Poniższy rysunek przedstawia stos czujników Androida. Każdy komponent komunikuje się tylko z komponentami znajdującymi się bezpośrednio nad nim i pod nim, chociaż niektóre czujniki mogą ominąć koncentrator czujników, jeśli jest on obecny. Sterowanie przepływa z aplikacji do czujników, a dane przepływają z czujników do aplikacji.

Warstwy i właściciele stosu czujników Androida

Rysunek 1. Warstwy stosu czujników Androida i ich właściciele

SDK

Aplikacje uzyskują dostęp do czujników za pośrednictwem interfejsu API Sensors SDK (Software Development Kit) . SDK zawiera funkcje umożliwiające wyświetlenie listy dostępnych czujników i zarejestrowanie się w czujniku.

Podczas rejestracji w czujniku aplikacja określa preferowaną częstotliwość próbkowania i wymagania dotyczące opóźnienia.

  • Na przykład aplikacja może zarejestrować się w domyślnym akcelerometrze, żądając zdarzeń z częstotliwością 100 Hz i umożliwiając raportowanie zdarzeń z 1-sekundowym opóźnieniem.
  • Aplikacja będzie odbierać zdarzenia z akcelerometru z częstotliwością co najmniej 100 Hz i ewentualnie z opóźnieniem do 1 sekundy.

Więcej informacji na temat pakietu SDK można znaleźć w dokumentacji dla programistów .

Struktura

Struktura odpowiada za połączenie kilku aplikacji z warstwą HAL . Sama warstwa HAL jest pojedynczym klientem. Bez multipleksowania na poziomie frameworka dostęp do każdego czujnika w danym momencie mogłaby uzyskać tylko jedna aplikacja.

  • Kiedy pierwsza aplikacja rejestruje się w czujniku, struktura wysyła żądanie do warstwy HAL w celu aktywacji czujnika.
  • Gdy dodatkowe aplikacje rejestrują się w tym samym czujniku, platforma uwzględnia wymagania każdej aplikacji i wysyła zaktualizowane żądane parametry do warstwy HAL.
    • Częstotliwość próbkowania będzie maksymalną z żądanych częstotliwości próbkowania, co oznacza, że ​​niektóre aplikacje będą odbierać zdarzenia z częstotliwością wyższą niż żądana.
    • Maksymalne opóźnienie raportowania będzie minimalne z żądanych. Jeśli jedna aplikacja zażąda jednego czujnika z maksymalnym opóźnieniem raportowania równym 0, wszystkie aplikacje otrzymają zdarzenia z tego czujnika w trybie ciągłym, nawet jeśli niektóre zażądały czujnika z niezerowym maksymalnym opóźnieniem raportowania. Aby uzyskać więcej informacji, zobacz Dozowanie wsadowe .
  • Kiedy ostatnia aplikacja zarejestrowana na jednym czujniku wyrejestruje się z niego, framework wysyła żądanie do warstwy HAL w celu dezaktywacji czujnika, aby nie zużywać niepotrzebnie energii.

Wpływ multipleksowania

Ta potrzeba warstwy multipleksowania w ramach wyjaśnia niektóre decyzje projektowe.

  • Gdy aplikacja żąda określonej częstotliwości próbkowania, nie ma gwarancji, że zdarzenia nie będą pojawiać się szybciej. Jeśli inna aplikacja zażądała tego samego czujnika z większą szybkością, pierwsza aplikacja również otrzyma je z większą szybkością.
  • Ten sam brak gwarancji dotyczy żądanego maksymalnego opóźnienia raportowania: aplikacje mogą odbierać zdarzenia ze znacznie mniejszymi opóźnieniami, niż żądały.
  • Oprócz częstotliwości próbkowania i maksymalnego opóźnienia raportowania aplikacje nie mogą konfigurować parametrów czujnika.
    • Wyobraźmy sobie na przykład czujnik fizyczny, który może działać zarówno w trybie „wysokiej dokładności”, jak i „niskiego poboru mocy”.
    • Na urządzeniu z Androidem można używać tylko jednego z tych dwóch trybów, ponieważ w przeciwnym razie aplikacja mogłaby zażądać trybu wysokiej dokładności, a inna trybu niskiego zużycia energii; framework nie byłby w stanie zaspokoić obu zastosowań. Framework musi zawsze być w stanie zadowolić wszystkich swoich klientów, więc nie wchodzi to w grę.
  • Nie ma mechanizmu przesyłania danych z aplikacji do czujników lub ich sterowników. Dzięki temu jedna aplikacja nie może modyfikować zachowania czujników, zakłócając pracę innych aplikacji.

Fuzja czujników

Struktura systemu Android zapewnia domyślną implementację niektórych czujników kompozytowych. Gdy w urządzeniu znajduje się żyroskop , akcelerometr i magnetometr , ale nie ma czujników wektora obrotu , grawitacji i przyspieszenia liniowego , platforma implementuje te czujniki, dzięki czemu aplikacje mogą nadal z nich korzystać.

Domyślna implementacja nie ma dostępu do wszystkich danych, do których mają dostęp inne implementacje, i musi działać na SoC, więc nie jest tak dokładna ani tak energooszczędna, jak mogą być inne implementacje. W miarę możliwości producenci urządzeń powinni zdefiniować własne połączone czujniki (wektor obrotu, grawitacja i przyspieszenie liniowe, a także nowsze czujniki złożone, takie jak wektor rotacji gry ), zamiast polegać na tej domyślnej implementacji. Producenci urządzeń mogą również zwrócić się do dostawców chipów czujnikowych o zapewnienie im implementacji.

Domyślna implementacja fuzji czujników nie jest utrzymywana i może spowodować, że urządzenia na niej korzystające zawiodą CTS.

Pod maską

Ta sekcja zawiera podstawowe informacje dla osób zajmujących się obsługą kodu platformy Android Open Source Project (AOSP). Nie dotyczy to producentów sprzętu.

JNI

Framework wykorzystuje natywny interfejs Java (JNI) powiązany z android.hardware i znajdujący się w katalogu frameworks/base/core/jni/ . Ten kod wywołuje kod natywny niższego poziomu w celu uzyskania dostępu do sprzętu czujnika.

Natywny framework

Natywny framework jest zdefiniowany w frameworks/native/ i zapewnia natywny odpowiednik pakietu android.hardware . Natywna struktura wywołuje serwery proxy Binder IPC w celu uzyskania dostępu do usług specyficznych dla czujnika.

Spoiwo IPC

Serwery proxy Binder IPC ułatwiają komunikację ponad granicami procesów.

HAL

Interfejs API warstwy abstrakcji sprzętu (HAL) firmy Sensors to interfejs pomiędzy sterownikami sprzętowymi a platformą Android. Składa się z jednego interfejsu HAL czujniki.h i jednej implementacji HAL, którą nazywamy czujnikami.cpp.

Interfejs jest definiowany przez autorów Androida i AOSP, a implementację zapewnia producent urządzenia.

Interfejs HAL czujnika znajduje się w hardware/libhardware/include/hardware . Dodatkowe szczegóły można znaleźć w czujnikach.h .

Cykl zwolnienia

Implementacja HAL określa, jaką wersję interfejsu HAL implementuje, ustawiając your_poll_device.common.version . Istniejące wersje interfejsu HAL są zdefiniowane w Sensors.h i funkcjonalność jest powiązana z tymi wersjami.

Struktura Androida obsługuje obecnie wersje 1.0 i 1.3, ale wersja 1.0 wkrótce nie będzie już obsługiwana. Niniejsza dokumentacja opisuje zachowanie wersji 1.3, do której powinny zostać zaktualizowane wszystkie urządzenia. Aby uzyskać szczegółowe informacje na temat aktualizacji do wersji 1.3, zobacz wycofywanie wersji HAL .

Sterownik jądra

Sterowniki czujników wchodzą w interakcję z urządzeniami fizycznymi. W niektórych przypadkach implementacja HAL i sterowniki to ta sama jednostka oprogramowania. W innych przypadkach integrator sprzętu żąda od producentów chipów czujników dostarczenia sterowników, ale to oni piszą implementację HAL.

We wszystkich przypadkach za implementację HAL i sterowniki jądra odpowiadają producenci sprzętu, a system Android nie zapewnia preferowanych metod ich pisania.

Koncentrator czujnika

Stos czujników urządzenia może opcjonalnie zawierać koncentrator czujników, przydatny do wykonywania obliczeń niskiego poziomu przy niskim poborze mocy, podczas gdy SoC może znajdować się w trybie zawieszenia. Na tych chipach można na przykład wykonać zliczanie kroków lub łączenie czujników. Jest to również dobre miejsce na wdrożenie dozowania czujników, dodając sprzętowe FIFO dla zdarzeń czujnika. Aby uzyskać więcej informacji, zobacz Dozowanie .

Uwaga: Aby opracować nowe funkcje ContextHub wykorzystujące nowe czujniki lub diody LED, można również użyć Neonkey SensorHub podłączonego do płytki rozwojowej Hikey lub Hikey960.

Sposób materializacji koncentratora czujnika zależy od architektury. Czasami jest to oddzielny chip, a czasami zawarty w tym samym chipie co SoC. Ważną cechą koncentratora czujników jest to, że powinien on zawierać wystarczającą ilość pamięci do przetwarzania wsadowego i zużywać bardzo mało energii, aby umożliwić wdrożenie czujników Android o niskim poborze mocy. Niektóre koncentratory czujników zawierają mikrokontroler do ogólnych obliczeń i akceleratory sprzętowe umożliwiające obliczenia przy bardzo niskim poborze mocy dla czujników o małej mocy.

Architektura koncentratora czujników oraz sposób, w jaki komunikuje się z czujnikami i SoC (magistrala I2C, magistrala SPI,…) nie jest określona przez system Android, ale powinno mieć na celu zminimalizowanie ogólnego zużycia energii.

Jedną z opcji, która wydaje się mieć znaczący wpływ na prostotę implementacji, są dwie linie przerwań biegnące od koncentratora czujnika do SoC: jedna dla przerwań wybudzenia (dla czujników wybudzenia), a druga dla przerwań innych niż wybudzenie (dla czujników niebudzących).

Czujniki

To fizyczne chipy MEM dokonujące pomiarów. W wielu przypadkach w tym samym chipie znajduje się kilka czujników fizycznych. Na przykład niektóre chipy zawierają akcelerometr, żyroskop i magnetometr. (Takie chipy są często nazywane chipami 9-osiowymi, ponieważ każdy czujnik dostarcza dane w 3 osiach.)

Niektóre z tych układów zawierają również logikę do wykonywania typowych obliczeń, takich jak wykrywanie ruchu, wykrywanie kroków i łączenie czujników 9-osiowych.

Chociaż wymagania i zalecenia dotyczące mocy i dokładności CDD dotyczą czujnika Androida, a nie czujników fizycznych, wymagania te wpływają na wybór czujników fizycznych. Na przykład wymóg dokładności wektora rotacji gry ma wpływ na wymaganą dokładność żyroskopu fizycznego. Określenie wymagań dotyczących czujników fizycznych należy do producenta urządzenia.