Stos czujników

Ilustracja poniżej przedstawia stos czujników Androida. Każdy składnik komunikuje się tylko z komponentami znajdującymi się bezpośrednio nad i pod nim, chociaż niektóre Gdy czujniki są obecne, mogą omijać centrum czujników. Kontroluj przepływy ze strony z aplikacji do czujników, a dane przepływają z czujników do aplikacji.

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

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

Pakiet SDK

Aplikacje uzyskują dostęp do czujników przez interfejs API Sensors SDK (Software Development Kit). Pakiet SDK zawiera funkcje służące do wyświetlania listy dostępnych czujników i rejestrowania .

Gdy rejestrujesz się w czujniku, aplikacja określa preferowane próbkowanie i wymogach związanych z opóźnieniami.

  • Na przykład aplikacja może zarejestrować się na domyślnym akcelerometrze, wysyłania żądań zdarzeń z częstotliwością 100 Hz, co umożliwia raportowanie zdarzeń z jednosekundową opóźnienia.
  • Aplikacja będzie odbierała zdarzenia z akcelerometru o prędkości co najmniej 100 Hz, z opóźnieniem do 1 sekundy.

Więcej informacji o pakiecie SDK znajdziesz w dokumentacji dla programistów.

Platforma

Platforma odpowiada za łączenie kilku aplikacji z HAL. Sama lista HAL jest pojedynczym klientem. Bez tego multipleksu nie ma miejsca na poziomie platformy, tylko jedna aplikacja miała dostęp do każdego czujnika danego czasu.

  • Gdy pierwsza aplikacja rejestruje się w czujniku, platforma wysyła żądanie do interfejsu HAL, aby aktywować czujnik.
  • Gdy dodatkowe aplikacje rejestrują się w tym samym czujniku, platforma zajmuje uwzględnia wymagania każdej aplikacji i wysyła zaktualizowane do interfejsu HAL.
    • Częstotliwość próbkowania jest maksymalna z żądanych częstotliwości próbkowania, co oznacza, że: aplikacje będą otrzymywać wydarzenia z częstotliwością większą niż poproszono o dostęp.
    • Maksymalny czas oczekiwania na raportowanie będzie równy minimalnemu opóźnieniu w żądaniu. Jeśli jedna aplikacja o nie prosi z maksymalnym opóźnieniem raportowania wynoszącym 0, wszystkie aplikacje otrzymują zdarzeń z tego czujnika w trybie ciągłym, nawet jeśli niektóre zażądały, przy maksymalnym opóźnieniu raportowania niezerowym. Więcej informacji znajdziesz w sekcji Grupowanie wsadowe.
  • Gdy ostatnia aplikacja zarejestrowana na jednym z czujników się z niego wyrejestruje, platformy wysyła do HAL żądanie dezaktywacji czujnika, dzięki czemu zasilanie i niepotrzebnie wykorzystywane.

Wpływ multipleksowania

Potrzeba warstwy multipleksowania w ramach platformy wyjaśnia pewne zagadnienia podejmują decyzje.

  • Gdy aplikacja żąda określonej częstotliwości próbkowania, nie ma masz pewność, że wydarzenia nie będą pojawiać się szybciej. Jeśli inna aplikacja szybsze żądania tego samego czujnika, pierwsza aplikacja również otrzymywać je w szybkim tempie.
  • Ten sam brak gwarancji dotyczy żądanego maksymalnego opóźnienia raportowania: aplikacje mogą odbierać zdarzenia ze znacznie mniejszym opóźnieniem, niż oczekiwały.
  • Oprócz częstotliwości próbkowania i maksymalnego opóźnienia raportowania aplikacje nie mogą konfigurować parametry czujnika.
    • Wyobraźmy sobie np. czujnik fizyczny, który może działać zarówno w dokładności” i „małej energii”.
    • Na urządzeniu z Androidem można używać tylko jednego z tych trybów, ponieważ w przeciwnym razie aplikacja może zażądać trybu wysokiej dokładności, a druga tryb oszczędzania baterii; nie byłoby możliwe, by platforma spełniała zarówno aplikacji. Platforma musi zawsze być w stanie zaspokoić potrzeby wszystkich klientów, Nie ma takiej możliwości.
  • Nie ma mechanizmu wysyłania danych z aplikacji do czujników ani ich kierowców. Dzięki temu żadna aplikacja nie może zmieniać działania funkcji czujniki, które psują działanie innych aplikacji.

Połączenie czujnika

Platforma Androida zapewnia domyślną implementację dla niektórych elementów złożonych i czujników. Gdy na urządzeniu są dostępne żyroskop, akcelerometr i magnetometr, ale nie ma żadnych czujników wektora obrotu, grawitacji i przyspieszenia liniowego, platforma wykorzystuje te czujniki, aby aplikacje te mogły ale nadal możesz z nich korzystać.

Domyślna implementacja nie ma dostępu do wszystkich danych które mają dostęp i muszą działać w układzie SoC, tak dokładny ani tak energooszczędny jak inne implementacje. Tylko to możliwe, producenci urządzeń powinni opracować własne połączone czujniki (obrotowe) wektorowego, grawitacyjnego i przyspieszenia liniowego, a także nowszych czujników złożonych, takich jak wektor obrotu gry), zamiast polegać na tej domyślnej implementacji. Producenci urządzeń mogą mogą także poprosić dostawców układów scalonych o udostępnienie im implementacji.

Domyślna implementacja czujnika Fusion nie zostanie zachowana i może spowodować, że korzystające z niego urządzenia przestaną działać CTS.

Opcje zaawansowane

Ta sekcja zawiera podstawowe informacje dla osób, które zarządzają Kod platformy Android Open Source Project (AOSP). Nie dotyczy producentów sprzętu.

JNI

Platforma korzysta z natywnego interfejsu Java (JNI) powiązanego z android.hardware i znajdującym się w katalogu frameworks/base/core/jni/. Ten kod wywołuje metodę kod natywny niższego poziomu w celu uzyskania dostępu do czujnika.

Platforma natywna

Środowisko natywne jest zdefiniowane w frameworks/native/ i zapewnia odpowiednik pakietu android.hardware. Natywna platforma wywołuje serwery proxy IPC Binder, aby uzyskać dostęp do usług związanych z czujnikami.

IPC wiązań

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

HAL

Interfejs Sensors Hardware Abstraction Layer (HAL) API to interfejs między sterowników sprzętowych i platformy Androida. Składa się z jednego interfejsu HAL sensor.h i jedna implementacja HAL, którą określamy jako sensor.cpp.

Interfejs jest zdefiniowany przez współtwórców Androida i AOSP, a interfejs Indywidualne wdrożenie jest dostarczane przez producenta urządzenia.

Interfejs HAL czujnika znajduje się w: hardware/libhardware/include/hardware. Zobacz sensors.h. aby dowiedzieć się więcej.

Cykl wydania

Implementacja HAL określa, której wersji interfejsu HAL należy implementowanych przez ustawienie your_poll_device.common.version. Istniejąca lista HAL a wersje interfejsu są zdefiniowane w Czujnikze.h, a funkcje są z nimi powiązane. wersji.

Platforma Androida obsługuje obecnie wersje 1.0 i 1.3, ale wersja 1.0 wkrótce nie będą już obsługiwane. Ta dokumentacja opisuje działanie wersji 1.3, do której należy uaktualnić wszystkie urządzenia. Aby dowiedzieć się, jak przejść na 1.3, zobacz Wycofanie wersji HAL.

Sterownik jądra

Sterowniki czujników wchodzą w interakcje z urządzeniami fizycznymi. W niektórych przypadkach kod HAL oraz sterowniki to ten sam podmiot oprogramowania. W innych przypadkach integrator sprzętu prosi producentów układów scalonych o udostępnienie ale to oni tworzą implementację HAL.

We wszystkich przypadkach za wdrożenie HAL oraz sterowniki jądra odpowiedzialność producentów sprzętu, a Android nie podaje preferencyjnych rozwiązań, je napisać.

Koncentrator czujników

Stos czujników urządzenia może opcjonalnie zawierać centrum czujników, co pomaga i wykonywać niskopoziomowe obliczenia przy małej mocy, podczas gdy układ SOC trybu zawieszenia. Na przykład liczenie kroków lub połączenie czujnika te układy. Jest to również dobre miejsce do implementacji grupowania czujników, sprzętowe FIFO dla zdarzeń z czujników. Więcej informacji znajdziesz w sekcji Grupowanie wsadowe.

Uwaga: aby tworzyć nowe funkcje ContextHub, które użyj nowych czujników lub diod LED, możesz też użyć Urządzenie Neonkey SensorHub podłączone do Płyta deweloperska Hikey lub Hikey960.

Sposób zbudowania centrum czujników zależy od jego architektury. Czasami osobny układ scalony, a czasem także ten sam układ scalony co układ SoC. Ważne! centrum czujników jest takie, że powinno mieć wystarczającą ilość pamięci. do przetwarzania wsadowego i zużywania bardzo małej ilości energii, co umożliwia wdrożenie niskich zasilania czujników Androida. Niektóre koncentratory czujników są wyposażone w mikrokontroler do oraz akceleratory sprzętowe, które umożliwiają obliczenia bardzo małej mocy obliczeniowej czujników o niskim napięciu.

Architektura centrum czujników i sposób komunikacji z czujnikami a procesor SoC (magistrala I2C, magistrala SPI itp.) nie jest określony przez Androida, ale powinien w celu minimalizacji ogólnego zużycia energii.

Opcja, która wydaje się mieć znaczny wpływ na implementację dla prostoty polega na tym, że 2 linie przerywane przechodzące z centrum czujników do układu SOC: jedno do przerywania wybudzenia (dla czujników wybudzania), a drugie – do braku wybudzenia przerywa (dla czujników niewybudzających).

Czujniki

Są to fizyczne układy MEM służące do wykonywania pomiarów. W wielu przypadkach W tym samym układzie scalonym znajduje się kilka czujników fizycznych. Na przykład niektóre elementy takich jak akcelerometr, żyroskop i magnetometr. (takie elementy są często 9-osiowych, ponieważ każdy czujnik dostarcza dane na 3 osiach).

Niektóre z tych układów zawierają również funkcje logiczne służące do wykonywania typowych obliczeń, za pomocą wykrywania ruchu, wykrywania kroków oraz 9-osiowego czujnika Fusion.

Chociaż wymagania i zalecenia CDD dotyczące mocy i dokładności dotyczą Czujniki systemu Android, a nie fizyczne czujniki, mają wpływ na różnych czujników fizycznych. Na przykład wymagania dotyczące dokładności w grze ma wpływ na wymaganą dokładność żyroskop. To producent urządzenia ustala wymagania czujniki fizyczne.