Ilustracja poniżej przedstawia stos czujników Androida. Każdy komponent komunikuje się tylko z komponentami znajdującymi się bezpośrednio nad i pod nim, chociaż niektóre czujniki mogą omijać koncentrator czujników, jeśli jest on obecny. Sterowanie przepływa z aplikacji do czujników, a dane – z czujników do aplikacji.
Rysunek 1. Warstwy stosu czujników Androida i ich właściciele
SDK
Aplikacje uzyskują dostęp do czujników za pomocą interfejsu API pakietu SDK (Software Development Kit) Sensors. Pakiet SDK zawiera funkcje umożliwiające wyświetlanie listy dostępnych czujników i rejestrowanie się w a 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 zezwalając na raportowanie zdarzeń z opóźnieniem 1 sekundy.
- Aplikacja będzie otrzymywać zdarzenia z akcelerometru z częstotliwością co najmniej 100 Hz, z opóźnieniem do 1 sekundy.
Więcej informacji o pakiecie SDK znajdziesz w dokumentacji dla deweloperów.
Platforma
Platforma odpowiada za łączenie kilku aplikacji z warstwą HAL. Sama warstwa HAL jest przeznaczona dla jednego klienta. Bez tego multipleksowania na poziomie platformy tylko jedna aplikacja mogłaby w danym momencie uzyskać dostęp do każdego czujnika.
- Gdy pierwsza aplikacja zarejestruje się w czujniku, platforma wysyła do warstwy HAL żądanie aktywowania czujnika.
- Gdy dodatkowe aplikacje zarejestrują się w tym samym czujniku, platforma uwzględnia
wymagania każdej aplikacji i wysyła do warstwy HAL zaktualizowane żądane
parametry.
- Częstotliwość próbkowania będzie maksymalną z żądanych częstotliwości próbkowania, co oznacza, że niektóre aplikacje będą otrzymywać zdarzenia z częstotliwością wyższą niż żądana.
- Maksymalne opóźnienie raportowania będzie minimalną z żądanych wartości. Jeśli jedna aplikacja zażąda jednego czujnika z maksymalnym opóźnieniem raportowania wynoszącym 0, wszystkie aplikacje będą otrzymywać zdarzenia z tego czujnika w trybie ciągłym, nawet jeśli niektóre z nich zażądały czujnika z maksymalnym opóźnieniem raportowania innym niż 0. Więcej informacji znajdziesz w sekcji Przetwarzanie wsadowe.
- Gdy ostatnia aplikacja zarejestrowana w czujniku wyrejestruje się z niego, platforma wysyła do warstwy HAL żądanie dezaktywowania czujnika, aby nie zużywać niepotrzebnie energii.
Wpływ multipleksowania
Konieczność użycia warstwy multipleksowania w platformie wyjaśnia niektóre decyzje projektowe.
- Gdy aplikacja zażąda określonej częstotliwości próbkowania, nie ma gwarancji, że zdarzenia nie będą przychodzić z większą częstotliwością. Jeśli inna aplikacja zażąda tego samego czujnika z większą częstotliwością, pierwsza aplikacja również będzie otrzymywać zdarzenia z tą częstotliwością.
- Ta sama gwarancja dotyczy żądanego maksymalnego opóźnienia raportowania: aplikacje mogą otrzymywać zdarzenia z opóźnieniem znacznie mniejszym niż żądane.
- Oprócz częstotliwości próbkowania i maksymalnego opóźnienia raportowania aplikacje nie mogą
konfigurować parametrów czujnika.
- Wyobraź sobie na przykład czujnik fizyczny, który może działać w trybie „wysoka dokładność” i „niskie zużycie energii”.
- Na urządzeniu z Androidem można używać tylko jednego z tych 2 trybów, ponieważ w przeciwnym razie jedna aplikacja mogłaby zażądać trybu wysokiej dokładności, a druga – trybu oszczędzania baterii. Platforma nie mogłaby spełnić wymagań obu aplikacji. Platforma musi zawsze być w stanie spełnić wymagania wszystkich klientów, więc to nie jest możliwe.
- Nie ma mechanizmu wysyłania danych z aplikacji do czujników ani ich sterowników. Dzięki temu jedna aplikacja nie może modyfikować zachowania czujników, co mogłoby spowodować problemy w innych aplikacjach.
Łączenie danych z czujników
Platforma Androida udostępnia domyślną implementację niektórych czujników złożonych. Jeśli urządzenie ma żyroskop, akcelerometr i magnetometr, ale nie ma czujników wektora rotacji, grawitacji i przyspieszenia liniowego, platforma implementuje te czujniki, aby aplikacje mogły 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 układzie SoC, więc nie jest tak dokładna ani energooszczędna jak inne implementacje. Producenci urządzeń powinni w miarę możliwości definiować własne czujniki łączone (wektor rotacji, 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ą też poprosić dostawców układów czujników o udostępnienie implementacji.
Domyślna implementacja łączenia danych z czujników nie jest utrzymywana i może powodować, że urządzenia, które z niej korzystają, nie przejdą testów CTS.
Pod maską
Ta sekcja zawiera informacje dodatkowe dla osób, które utrzymują kod platformy Projekt Android Open Source (AOSP). Nie jest ona istotna dla producentów sprzętu.
JNI
Platforma korzysta z interfejsu Java Native Interface (JNI) powiązanego z android.hardware i znajdującego się w frameworks/base/core/jni/ katalogu. Ten kod wywołuje
kod natywny niższego poziomu, aby uzyskać dostęp do sprzętu czujnika.
Platforma natywna
Platforma natywna jest zdefiniowana w frameworks/native/ i zapewnia natywny
odpowiednik pakietu android.hardware. Platforma natywna wywołuje proxy Binder IPC, aby uzyskać dostęp do
usług specyficznych dla czujników.
Binder IPC
Proxy Binder IPC ułatwiają komunikację między procesami.
HAL
Interfejs API warstwy abstrakcji sprzętowej (HAL) Sensors to interfejs między sterownikami sprzętu a platformą Androida. Składa się z 1 interfejsu HAL sensors.h i 1 implementacji HAL, którą nazywamy sensors.cpp.
Interfejs jest definiowany przez Androida i współtwórców AOSP, a implementacja jest dostarczana przez producenta urządzenia.
Interfejs HAL czujnika znajduje się w hardware/libhardware/include/hardware.
Więcej informacji znajdziesz w pliku sensors.h.
Cykl premierowy
Implementacja HAL określa, którą wersję interfejsu HAL
implementuje, ustawiając your_poll_device.common.version. Obecne wersje interfejsu HAL
są zdefiniowane w pliku sensors.h, a funkcje są powiązane z tymi
wersjami.
Platforma Androida obsługuje obecnie wersje 1.0 i 1.3, ale wersja 1.0 wkrótce nie będzie już obsługiwana. Ta dokumentacja opisuje działanie wersji 1.3, do której powinny zostać zaktualizowane wszystkie urządzenia. Więcej informacji o aktualizacji do wersji 1.3 znajdziesz w artykule Wycofywanie wersji HAL.
Sterownik jądra
Sterowniki czujników współdziałają z urządzeniami fizycznymi. W niektórych przypadkach implementacja HAL i sterowniki to ten sam element oprogramowania. W innych przypadkach, integrator sprzętu prosi producentów układów czujników o udostępnienie sterowników, ale to oni piszą implementację HAL.
W każdym przypadku implementacja HAL i sterowniki jądra są odpowiedzialnością producentów sprzętu, a Android nie udostępnia preferowanych metod ich pisania.
Koncentrator czujników
Stos czujników urządzenia może opcjonalnie zawierać koncentrator czujników, który jest przydatny do wykonywania niektórych obliczeń niskiego poziomu przy niskim zużyciu energii, gdy układ SoC może być w trybie zawieszenia. Na przykład na tych układach można wykonywać zliczanie kroków lub łączenie danych z czujników. Jest to też dobre miejsce na implementację przetwarzania wsadowego czujników, dodając sprzętowe kolejki FIFO dla zdarzeń czujników. Więcej informacji znajdziesz w sekcji Przetwarzanie wsadowe.
Uwaga: aby opracowywać nowe funkcje ContextHub, które korzystają z nowych czujników lub diod LED, możesz też użyć koncentratora czujników Neonkey podłączonego do płyty deweloperskiej Hikey lub Hikey960.
Sposób realizacji koncentratora czujników zależy od architektury. Czasami jest to osobny układ, a czasami jest on wbudowany w ten sam układ co SoC. Ważne cechy koncentratora czujników to: powinien on zawierać wystarczającą ilość pamięci do przetwarzania wsadowego i zużywać bardzo mało energii, aby umożliwić implementację czujników Androida o niskim zużyciu energii. Niektóre koncentratory czujników zawierają mikrokontroler do obliczeń ogólnych i akceleratory sprzętowe, które umożliwiają obliczenia o bardzo niskim zużyciu energii w przypadku czujników o niskim zużyciu energii.
Android nie określa architektury koncentratora czujników ani sposobu jego komunikacji z czujnikami i układem SoC (szyna I2C, szyna SPI itp.), ale powinien on minimalizować ogólne zużycie energii .
Jedną z opcji, która wydaje się mieć znaczący wpływ na uproszczenie implementacji jest użycie 2 linii przerwań prowadzących z koncentratora czujników do układu SoC: jednej dla przerwań wybudzających (dla czujników wybudzających) i drugiej dla przerwań niewybudzających (dla czujników niewybudzających).
Czujniki
Są to fizyczne układy MEMS, które wykonują pomiary. W wielu przypadkach, na tym samym układzie znajduje się kilka czujników fizycznych. Na przykład niektóre układy zawierają akcelerometr, żyroskop i magnetometr. (Takie układy są często nazywane układami 9-osiowymi, ponieważ każdy czujnik dostarcza dane w 3 osiach).
Niektóre z tych układów zawierają też logikę do wykonywania typowych obliczeń, takich jak wykrywanie ruchu, wykrywanie kroków i łączenie danych z czujników 9-osiowych.
Chociaż wymagania i zalecenia dotyczące mocy i dokładności w dokumencie CDD dotyczą czujnika Androida, a nie czujników fizycznych, te wymagania wpływają na wybór czujników fizycznych. Na przykład wymaganie dotyczące dokładności wektora rotacji gry ma wpływ na wymaganą dokładność żyroskopu fizycznego. Wymagania dotyczące czujników fizycznych musi określić producent urządzenia.