Rysunek poniżej przedstawia zestaw czujników Androida. Każdy element komunikuje się tylko z elementami bezpośrednio nad i pod nim, ale niektóre czujniki mogą pomijać koncentrator czujników, jeśli jest on obecny. Sterowanie jest przekazywane z aplikacji do czujników, a dane z czujników do aplikacji.
Rysunek 1. Warstwy pakietu czujników Androida i ich właściciele
Pakiet SDK
Aplikacje uzyskują dostęp do czujników za pomocą interfejsu Sensors SDK (Software Development Kit) API. Pakiet SDK zawiera funkcje wyświetlania listy dostępnych czujników i rejestrowania się w czujniku.
Podczas rejestracji w czujniku aplikacja określa preferowaną częstotliwość próbkowania i wymagania dotyczące opóźnienia.
- Aplikacja może na przykład rejestrować dane z domyślnego akcelerometru, wysyłając żądania zdarzeń z częstotliwością 100 Hz i 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 s.
Więcej informacji o pakiecie SDK znajdziesz w dokumentacji dla programistów.
Platforma
Framework odpowiada za łączenie różnych aplikacji z HAL. HAL jest przeznaczony dla jednego klienta. Bez tego multipleksowania na poziomie frameworku tylko jedna aplikacja mogłaby w danym momencie uzyskać dostęp do każdego czujnika.
- Gdy pierwsza aplikacja rejestruje się w czujniku, framework wysyła do HAL żądanie aktywacji czujnika.
- Gdy dodatkowe aplikacje rejestrują się w tym samym czujniku, framework uwzględnia wymagania każdej aplikacji i wysyła zaktualizowane żądane parametry do HAL.
- 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ęstością wyższą niż ta, o którą prosiły.
- Maksymalny czas oczekiwania na raport będzie najmniejszym z wymaganych czasów oczekiwania. Jeśli jedna aplikacja żąda jednego czujnika z maksymalnym opóźnieniem raportowania 0, wszystkie aplikacje będą otrzymywać zdarzenia z tego czujnika w trybie ciągłym, nawet jeśli niektóre z nich żądają czujnika z niezerowym maksymalnym opóźnieniem raportowania. Więcej informacji znajdziesz w sekcji przetwarzanie zbiorcze.
- Gdy ostatnia aplikacja zarejestrowana w danym czujniku anuluje rejestrację, framework wysyła do HAL żądanie dezaktywacji czujnika, aby nie zużywał on niepotrzebnie energii.
Wpływ multipleksowania
Potrzebowaliśmy warstwy multipleksowania w ramach, co tłumaczy niektóre decyzje projektowe.
- Gdy aplikacja prosi o określoną częstotliwość próbkowania, nie można zagwarantować, że zdarzenia nie będą docierać z szybszym tempem. Jeśli inna aplikacja poprosi o te same dane z większą częstotliwością, pierwsza aplikacja również otrzyma je z większą częstotliwością.
- Brak gwarancji dotyczy również żądanego maksymalnego opóźnienia raportowania:aplikacje mogą otrzymywać zdarzenia z opóźnieniem znacznie krótszym niż żądane.
- Poza częstotliwością próbkowania i maksymalnym opóźnieniem raportowania aplikacje nie mogą konfigurować parametrów czujnika.
- Wyobraź sobie na przykład czujnik fizyczny, który może działać w trybie „wysokiej dokładności” i „niskiego poboru mocy”.
- Na urządzeniu z Androidem można użyć tylko jednego z tych trybów, ponieważ w przeciwnym razie jedna aplikacja mogłaby poprosić o tryb wysokiej dokładności, a druga – o tryb niskiego poboru mocy. Framework nie mógłby wtedy spełnić wymagań obu aplikacji. Platforma musi zawsze spełniać oczekiwania wszystkich klientów, więc ta opcja nie wchodzi w rachubę.
- Nie ma mechanizmu przesył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.
Zdejmowanie danych z różnych czujników
Platforma Androida udostępnia domyślną implementację niektórych złożonych czujników. Jeśli na urządzeniu są dostępne żyroskop, akcelerometr i magnetometr, ale nie ma czujników obrotu, 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 SoC, więc nie jest tak dokładna ani tak energooszczędna jak inne implementacje. Producenci urządzeń powinni w miarę możliwości definiować własne czujniki złożone (wektor obrotu, grawitacji i przyspieszenia liniowego, a także nowsze czujniki złożone, takie jak wektor obrotu gry), zamiast polegać na tej domyślnej implementacji. Producenci urządzeń mogą też poprosić dostawców układów czujników o ich implementację.
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 ogólne dla osób, które zajmują się utrzymaniem kodu frameworku w ramach Projektu Android Open Source (AOSP). Nie ma to zastosowania w przypadku producentów sprzętu.
JNI
Framework używa interfejsu natywnego Java (JNI) powiązanego z 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
Natywny framework jest zdefiniowany w frameworks/native/ i zapewnia natywną implementację pakietu android.hardware. Natywne środowisko wywołuje pośredniki IPC Bindera, aby uzyskać dostęp do usług związanych z konkretnym czujnikiem.
Binder IPC
Pośrednicy IPC Binder ułatwiają komunikację między procesami.
HAL
Interfejs API warstwy abstrakcji sprzętowej czujników (HAL) to interfejs między sterownikami sprzętowymi a platformą Android. Składa się z jednego interfejsu HAL (sensors.h) i jednego interfejsu HAL (sensors.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.
Więcej informacji znajdziesz na stronie sensors.h.
Cykl premierowy
Implementacja HAL określa, która wersja interfejsu HAL jest implementowana, za pomocą ustawienia your_poll_device.common.version. Istniejące wersje interfejsu HAL są zdefiniowane w pliku sensors.h, a ich funkcjonalność jest powiązana z tymi wersjami.
Platforma Androida obsługuje obecnie wersje 1.0 i 1.3, ale wkrótce nie będzie już obsługiwać wersji 1.0. Ta dokumentacja opisuje działanie wersji 1.3, do której powinny przejść wszystkie urządzenia. Szczegółowe informacje o przechodzeniu na wersję 1.3 znajdziesz w artykule Wycofanie wersji HAL.
Sterownik jądra
Sterowniki czujników współpracują 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 przekazanie sterowników, ale to on sam pisze implementację HAL.
W żadnym przypadku implementacja HAL i sterowniki jądra nie są obowiązkiem producentów sprzętu, a Android nie podaje preferowanych sposobów ich pisania.
Centrum czujników
Zestaw czujników urządzenia może opcjonalnie zawierać moduł czujników, który umożliwia wykonywanie niektórych obliczeń na niskim poziomie przy niskim poborze mocy, gdy SoC może być w trybie zawieszenia. Na tych elementach można na przykład wykonywać zliczanie kroków lub fuzje czujników. Jest to też dobre miejsce na implementację grupowania czujników i dodawania kolejek FIFO sprzętowych dla zdarzeń czujników. Więcej informacji znajdziesz w artykule o przetwarzaniu zbiorczym.
Uwaga: aby opracowywać nowe funkcje ContextHub, które korzystają z nowych czujników lub diod LED, możesz też użyć Neonkey SensorHub połączonego z płytą rozwojową Hikey lub Hikey960.
Sposób materializacji koncentratora czujników zależy od architektury. Czasami jest to osobny układ, a czasami jest on zawarty na tym samym układzie SoC. Ważną cechą modułu sensorycznego jest to, że powinien on zawierać wystarczającą ilość pamięci do grupowania i powinien zużywać bardzo mało energii, aby umożliwić implementację energooszczędnych czujników Androida. Niektóre koncentratory czujników zawierają mikrokontroler do ogólnego przetwarzania oraz akceleratory sprzętowe, które umożliwiają przetwarzanie przy bardzo niskim poborze mocy przez czujniki o niskim poborze mocy.
Android nie określa architektury ani sposobu komunikacji modułu czujników z czujnikami i systemem SoC (szyna I2C, szyna SPI itd.), ale powinno się dążyć do minimalizacji ogólnego zużycia energii.
Jedną z opcji, która wydaje się mieć znaczący wpływ na prostotę wdrożenia, jest stosowanie dwóch linii przerwania od modułu czujników do modułu SoC: jednej dla przerwania pobudki (dla czujników pobudki) i drugiej dla przerwania niebędącego pobudką (dla czujników niebędących pobudką).
Czujniki
To są fizyczne układy MEMS, które wykonują pomiary. W wielu przypadkach na jednym układzie znajduje się kilka fizycznych czujników. Na przykład niektóre układy scalone zawierają akcelerometr, żyroskop i magnetometr. (takie układy scalone są często nazywane układami 9-osiowymi, ponieważ każdy czujnik dostarcza dane z 3 osi)
Niektóre z tych układów zawierają też logikę do wykonywania typowych obliczeń, takich jak wykrywanie ruchu, wykrywanie kroków i 9-osiowe fuzje czujników.
Chociaż wymagania i zalecenia dotyczące mocy i dokładności CDD dotyczą czujnika Androida, a nie czujników fizycznych, mają one wpływ na wybór czujników fizycznych. Na przykład wymóg dokładności wektora obrotu gry ma wpływ na wymaganą dokładność fizycznego żyroskopu. Wymagania dotyczące czujników fizycznych zależą od producenta urządzenia.