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ą omijać hub czujników, gdy jest on obecny. Sterowanie odbywa się od aplikacji do czujników, a dane przepływają od czujników do aplikacji.
Rysunek 1. Warstwy stosu czujników Androida i ich właściciele
Pakiet SDK
Aplikacje uzyskują dostęp do czujników za pomocą interfejsu API pakietu SDK czujników (Software Development Kit). Pakiet SDK zawiera funkcje do wyświetlania listy dostępnych czujników i rejestrowania czujnika.
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 zgłaszanie zdarzeń z opóźnieniem 1 sekundy.
- Aplikacja będzie otrzymywać zdarzenia z akcelerometru z częstotliwością co najmniej 100 Hz, a opóźnienie może wynosić do 1 sekundy.
Więcej informacji o pakiecie SDK znajdziesz w dokumentacji dla programistów.
Framework
Framework odpowiada za łączenie kilku aplikacji z HAL. Sama warstwa HAL jest przeznaczona dla jednego klienta. Bez tego multipleksowania na poziomie platformy tylko jedna aplikacja mogłaby mieć dostęp do każdego czujnika w danym momencie.
- Gdy pierwsza aplikacja zarejestruje się w czujniku, platforma wysyła do HAL żądanie aktywacji czujnika.
- Gdy dodatkowe aplikacje zarejestrują się w tym samym czujniku, platforma uwzględni wymagania każdej z nich i wyśle do HAL-u 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ż ta, o którą prosiły.
- Maksymalne opóźnienie raportowania będzie najmniejszą 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 o wartości innej niż 0. Więcej informacji znajdziesz w sekcji Grupowanie.
- Gdy ostatnia aplikacja zarejestrowana w jednym z czujników wyrejestruje się z niego, platforma wysyła do HAL żądanie dezaktywacji czujnika, aby nie zużywał on niepotrzebnie energii.
Wpływ multipleksowania
Ta potrzeba warstwy multipleksowania w ramach 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ć szybciej. Jeśli inna aplikacja zażąda tych samych danych z czujnika z większą częstotliwością, pierwsza aplikacja również będzie je otrzymywać z większą częstotliwością.
- Ta sama gwarancja nie dotyczy żądanego maksymalnego czasu oczekiwania na raportowanie: aplikacje mogą otrzymywać zdarzenia z dużo mniejszym opóźnieniem niż żądane.
- Aplikacje nie mogą konfigurować parametrów czujnika, z wyjątkiem częstotliwości próbkowania i maksymalnego opóźnienia raportowania.
- Wyobraź sobie na przykład fizyczny czujnik, który może działać w trybach „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 inna – trybu niskiego zużycia energii. Platforma nie byłaby w stanie spełnić wymagań obu aplikacji. Platforma musi zawsze zaspokajać potrzeby wszystkich klientów, więc ta opcja nie jest możliwa.
- Nie ma mechanizmu wysyłania danych z aplikacji do czujników ani ich sterowników. Dzięki temu jedna aplikacja nie może modyfikować działania czujników, co mogłoby zakłócić działanie innych aplikacji.
Fuzja 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. W miarę możliwości producenci urządzeń powinni definiować własne czujniki łączone (wektor rotacji, grawitacja i przyspieszenie liniowe, a także nowsze czujniki złożone, takie jak wektor rotacji w grze), zamiast korzystać z tej domyślnej implementacji. Producenci urządzeń mogą też poprosić dostawców układów czujników o udostępnienie implementacji.
Domyślna implementacja fuzji czujników nie jest utrzymywana i może powodować, że urządzenia, które z niej korzystają, nie przejdą testów CTS.
Opcje zaawansowane
Ta sekcja zawiera informacje podstawowe dla osób, które utrzymują kod platformy Projektu Android Open Source (AOSP). Nie jest to istotne dla producentów sprzętu.
JNI
Framework korzysta z interfejsu Java Native Interface (JNI) powiązanego z pakietem android.hardware i znajdującego się w katalogu frameworks/base/core/jni/. 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 serwery proxy Binder IPC, aby uzyskać dostęp do usług związanych z czujnikami.
Binder IPC
Pełnomocnicy IPC Binder ułatwiają komunikację między procesami.
HAL
Interfejs API warstwy abstrakcji sprzętu (HAL) czujników to interfejs między sterownikami sprzętowymi a platformą Androida. Składa się z jednego interfejsu HAL sensors.h i jednej implementacji HAL, którą nazywamy sensors.cpp.
Interfejs jest definiowany przez osoby współtworzące Androida i 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 wkrótce wersja 1.0 przestanie być obsługiwana. W tym dokumencie opisujemy działanie wersji 1.3, do której powinny zostać zaktualizowane wszystkie urządzenia. Szczegółowe informacje o uaktualnianiu 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 są tym samym oprogramowaniem. W innych przypadkach integrator sprzętu prosi producentów układów czujników o dostarczenie sterowników, ale to on pisze 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.
Centrum 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 SoC może być w trybie zawieszenia. Na przykład na tych układach można wykonywać zliczanie kroków lub fuzję danych z czujników. Jest to też dobre miejsce na wdrożenie przetwarzania wsadowego danych z czujników, dodając sprzętowe kolejki FIFO dla zdarzeń z czujników. Więcej informacji znajdziesz w sekcji Grupowanie.
Uwaga: aby opracowywać nowe funkcje ContextHub, które korzystają z nowych czujników lub diod LED, możesz też używać Neonkey SensorHub podłączonego do płytki deweloperskiej Hikey lub Hikey960.
Sposób realizacji koncentratora czujników zależy od architektury. Czasami jest to osobny układ, a czasami jest on zintegrowany z układem 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ć implementację czujników Androida o niskim poborze mocy. Niektóre koncentratory czujników zawierają mikrokontroler do ogólnych obliczeń i akceleratory sprzętowe, które umożliwiają obliczenia o bardzo niskim poborze mocy w przypadku czujników o niskim poborze mocy.
Architektura koncentratora czujników i sposób jego komunikacji z czujnikami oraz układem SoC (magistrala I2C, magistrala SPI itp.) nie są określone przez Androida, ale powinny mieć na celu minimalizację ogólnego zużycia energii.
Jedną z opcji, która ma znaczący wpływ na prostotę implementacji, jest użycie 2 linii przerwań prowadzących z centrum czujników do układu SoC: jednej dla przerwań wybudzania (w przypadku czujników wybudzania) i drugiej dla przerwań niewybudzających (w przypadku czujników niewybudzających).
Czujniki
To fizyczne układy MEMS dokonujące pomiarów. W wielu przypadkach na tym samym chipie znajduje się kilka czujników fizycznych. Na przykład niektóre czipy 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 fuzja danych z 9-osiowego czujnika.
Wymagania i rekomendacje dotyczące mocy i dokładności CDD są skierowane do czujnika Androida, a nie do czujników fizycznych, ale mają wpływ na wybór czujników fizycznych. Na przykład wymagana dokładność wektora rotacji gry ma wpływ na wymaganą dokładność fizycznego żyroskopu. Wymagania dotyczące czujników fizycznych ustala producent urządzenia.