Środowisko wykonawcze centrum kontekstu (CHRE)

Smartfony zawierają wiele procesorów, z których każdy jest zoptymalizowany do wykonywania różnych zadań. Jednak na Androidzie działa tylko jeden procesor: procesor aplikacji. Procesor AP zapewnia wysoką wydajność w przypadku takich zastosowań jak granie, ale zużywa zbyt dużo energii, aby obsługiwać funkcje wymagające częstych, krótkich okresów przetwarzania w ciągu całego dnia, nawet gdy ekran jest wyłączony. Mniejsze procesory są w stanie efektywniej obsługiwać takie obciążenia, wykonując swoje zadania bez zauważalnego wpływu na czas pracy na baterii. Jednak środowiska oprogramowania w procesorach o niskiej mocy są bardziej ograniczone i mogą się znacznie różnić, co utrudnia programowanie na wielu platformach.

Środowisko Context Hub Runtime (CHRE) zapewnia wspólną platformę do uruchamiania aplikacji na procesorze niskonapięciowym przy użyciu prostego, ujednoliconego interfejsu API, który ułatwia implementację. CHRE ułatwia producentom urządzeń i ich zaufanym partnerom odciążenie przetwarzania danych od punktu dostępowego, co pozwala oszczędzać baterię i poprawiać wrażenia użytkowników w różnych obszarach. Umożliwia też korzystanie z klasy zawsze włączonych, rozpoznawanych kontekstowo funkcji, zwłaszcza takich, które dotyczą zastosowania uczenia maszynowego do wykrywania otoczenia.

Kluczowych pojęć

CHRE to środowisko oprogramowania, w którym małe natywne aplikacje, zwane nanoaplikacjami, działają na procesorze oszczędzającym energię i współdziałają z podstawowym systemem za pomocą wspólnego interfejsu CHRE API. Aby przyspieszyć prawidłową implementację interfejsów API CHRE, w AOSP uwzględniono implementację referencyjną CHRE na wiele platform. Implementacja referencyjna obejmuje wspólny kod oraz abstrakcje dotyczące sprzętu i oprogramowania stanowiące podstawę oprogramowania w postaci szeregu warstw abstrakcji platformy (PAL). Nanoaplikacje są prawie zawsze powiązane z co najmniej 1 aplikacją klienta działającą w Androidzie, która wchodzi w interakcje z CHRE i nanoaplikacją za pomocą interfejsów API systemu o ograniczonym dostępie (ContextHubManager).

Ogólnie można połączyć architekturę CHRE i Androida jako całości. Istnieją jednak pewne ważne różnice:

• CHRE obsługuje tylko nanoaplikacje stworzone w kodzie natywnym (C lub C++). Nie obsługujemy języka Java.
• Ze względu na ograniczenia zasobów i ograniczenia bezpieczeństwa CHRE nie jest dostępna dla dowolnych aplikacji innych firm na Androida. Dostęp do niego mają tylko zaufane aplikacje.

Należy też wyraźnie rozróżniać pojęcia CHRE i huba czujników. Chociaż do implementacji sensora hub i CHRE często używa się tego samego sprzętu, CHRE nie zapewnia możliwości sensora wymaganych przez interfejs HAL czujników Androida. CHRE jest powiązany z interfejsem HAL centrum kontekstu i działa jako klient platformy czujnika urządzenia, która odbiera dane z czujników bez korzystania z punktu dostępu.

Rysunek 1. Architektura ram CHRE

Context Hub HAL

Warstwą abstrakcji sprzętowej (HAL) w ramach Context Hub jest interfejs między platformą Android a implementacją CHRE na urządzeniu, zdefiniowany w hardware/interfaces/contexthub. HAL centrum kontekstu definiuje interfejsy API, za pomocą których platforma Androida wykrywa dostępne centra kontekstu i ich nanoaplikacje, wchodzi w interakcje z tymi nanoaplikacjami w ramach przekazywania wiadomości oraz umożliwia ładowanie i usuwanie nanoaplikacji. Referencyjne wdrożenie interfejsu Context Hub HAL, które współpracuje z referencyjną implementacją CHRE, jest dostępne pod adresem system/chre/host.

W przypadku sprzeczności między tą dokumentacją a definicją HAL obowiązuje definicja HAL.

Inicjalizacja

Podczas uruchamiania Androida usługa ContextHubService wywołuje funkcję HAL getHubs(), aby sprawdzić, czy na urządzeniu są dostępne jakieś kontekstowe huby. Jest to blokujący, jednorazowy wywołanie, więc musi zostać wykonane szybko, aby nie opóźniać uruchamiania. Musi też zwrócić dokładny wynik, ponieważ nowych węzłów kontekstowych nie można wprowadzić później.

Ładowanie i rozładowywanie nanoaplikacji

Centrum kontekstowe może zawierać zestaw nanoaplikacji, które są uwzględnione w obrazie urządzenia i ładują się po uruchomieniu CHRE. Są to wstępnie załadowane nanoaplikacje. Należy je uwzględnić w pierwszej możliwej odpowiedzi na queryApps().

Interfejs HAL centrum kontekstu obsługuje również dynamiczne wczytywanie i usuwanie nanoaplikacji w środowisku wykonawczym za pomocą funkcji loadNanoApp() i unloadNanoApp(). Nanoaplikacje są dostarczane do HAL w formacie binarnym, który jest specyficzny dla implementacji sprzętu i oprogramowania CHRE.

Jeśli implementacja wczytywania nanoaplikacji obejmuje zapisywanie jej w pamięci nieulotnej, np. w pamięci flash podłączonej do procesora, który uruchamia CHRE, implementacja CHRE musi się zawsze uruchamiać z tymi dynamicznymi nanoaplikacjami, gdy będzie wyłączona. Oznacza to, że żaden kod nanoaplikacji nie jest wykonywany, dopóki nie zostanie otrzymane żądanie enableNanoapp() przez HAL. Wstępnie załadowane nanoaplikacje mogą się uruchamiać w stanie włączonym.

Ponowne uruchamiania context hub

Chociaż podczas normalnej pracy nie powinno dojść do ponownego uruchamiania CHRE, może być to konieczne w nieoczekiwanych sytuacjach, takich jak próba uzyskania dostępu do niemapowanego adresu pamięci. W takich sytuacjach CHRE uruchamia się niezależnie od Androida. HAL powiadamia Androida o tym za pomocą zdarzenia RESTARTED, które musi wysłać tylko po ponownym zainicjowaniu CHRE, aby mógł akceptować nowe żądania, takie jak queryApps().

Omówienie systemu CHRE

CHRE jest oparty na architekturze opartej na zdarzeniach, w której podstawową jednostką obliczeń jest zdarzenie przekazywane do punktu wejścia nanoaplikacji do obsługi zdarzeń. Chociaż framework CHRE może być wielowątkowy, dany nanoaplikacji nigdy nie jest uruchamiany równolegle z kilku wątków. Platforma CHRE współpracuje z danym nanoaplikacją za pomocą jednego z 3 punktów wejścia nanoaplikacji (nanoappStart(), nanoappHandleEvent() i nanoappEnd()) lub za pomocą wywołania zwrotnego przekazanego w poprzednim wywołaniu interfejsu CHRE API. Nanoaplikacje współpracują z platformą CHRE i systemem podstawowym za pomocą interfejsu CHRE API. Interfejs CHRE API udostępnia zestaw podstawowych funkcji oraz możliwości dostępu do sygnałów kontekstowych, w tym czujników, GNSS, Wi-Fi, WWAN i dźwięku. Można go rozszerzyć o dodatkowe funkcje specyficzne dla danego dostawcy, aby nanoaplikacje mogły z nich korzystać.

System kompilacji

Podczas gdy interfejs HAL Context Hub i inne niezbędne komponenty po stronie AP są kompilowane razem z Androidem, kod działający w CHRE może mieć wymagania, które powodują, że jest on niezgodny z systemem kompilacji Androida, np. wymaganie specjalistycznego zestawu narzędzi. Dlatego projekt CHRE w AOSP zapewnia uproszczony system kompilacji oparty na GNU Make do kompilowania nanoaplikacji i opcjonalnie frameworku CHRE do bibliotek, które można zintegrować z systemem. Producenci urządzeń dodający obsługę CHRE powinni zintegrować obsługę systemu kompilacji dla swoich urządzeń docelowych z AOSP.

Interfejs CHRE API jest napisany w standardzie języka C99, a implementacja referencyjna używa ograniczonego podzbioru C++11, który jest odpowiedni dla aplikacji o ograniczonej ilości zasobów.

CHRE API

Interfejs CHRE API to zbiór plików nagłówków C, które definiują interfejs oprogramowania między nanoaplikacją a systemem. Ma na celu zapewnienie zgodności kodu nanoaplikacji na wszystkich urządzeniach obsługujących CHRE, co oznacza, że nie trzeba modyfikować kodu źródłowego aplikacji nanoaplikacji pod kątem obsługi nowych typów urządzeń, choć może to wymagać ponownej skompilowania pod kątem zestawu instrukcji do procesora docelowego lub interfejsu binarnego aplikacji (ABI). Architektura CHRE i projekt interfejsu API zapewniają też zgodność binarną nanoaplikacji w różnych wersjach interfejsu CHRE API, co oznacza, że nie trzeba ponownie kompilować nanoaplikacji, aby działała na systemie, który implementuje inną wersję interfejsu CHRE API niż docelowy interfejs API, dla którego została skompilowana. Innymi słowy, jeśli binarne nanoaplikacje działają na urządzeniu, które obsługuje interfejs CHRE API w wersji 1.3, a to urządzenie zostanie zaktualizowane do obsługi interfejsu CHRE API w wersji 1.4, te same binarne nanoaplikacje będą nadal działać. Podobnie nanoaplikacja może działać na interfejsie CHRE API w wersji 1.2 i może określić w czasie wykonywania, czy do działania potrzebuje funkcji z interfejsu API w wersji 1.3, czy może działać, prawdopodobnie z łagodnym ograniczeniem funkcji.

Razem z Androidem są wydawane nowe wersje interfejsu CHRE API, jednak ponieważ implementacja CHRE jest częścią implementacji od dostawcy, wersja CHRE API obsługiwana na urządzeniu nie musi być powiązana z wersją Androida.

Podsumowanie

Podobnie jak schemat wersji Androida HIDL, interfejs CHRE API stosuje semantyczne wersjonowanie. Wersja główna wskazuje zgodność binarną, a wersja podrzędna jest zwiększana, gdy wprowadzane są funkcje zgodne wstecz. Interfejs CHRE API zawiera adnotacje kodu źródłowego, które wskazują, która wersja wprowadziła daną funkcję lub parametr, np. @since v1.1.

Implementacja CHRE udostępnia też wersję poprawki dla danej platformy za pomocą chreGetVersion(), która wskazuje, kiedy w implementacji wprowadzono poprawki błędów lub drobne aktualizacje.

Wersja 1.0 (Android 7)

Obejmuje obsługę czujników i podstawowych funkcji nanoaplikacji, takich jak zdarzenia i minuty.

Wersja 1.1 (Android 8)

Wprowadza funkcje związane z lokalizacją, takie jak lokalizacja GNSS i nieprzetworzone pomiary, skanowanie Wi-Fi i informacje o sieci mobilnej, a także ogólne udoskonalenia, aby umożliwić komunikację między nanoaplikacjami i wprowadzić inne ulepszenia.

Wersja 1.2 (Android 9)

Dodaje obsługę danych z mikrofonu o niskim poborze mocy, pomiarów RTT Wi-Fi, powiadomień o przebudzeniu i zasypianiu oraz inne ulepszenia.

Wersja 1.3 (Android 10)

Ulepszone możliwości związane z danymi kalibracji czujnika, dodanie obsługi opcjonalnego czyszczenia zbiorczego danych czujnika, zdefiniowanie typu czujnika wykrywania kroków oraz rozszerzenie zdarzeń lokalizacji GNSS o dodatkowe pola dokładności.

Wersja 1.4 (Android 11)

Dodano obsługę informacji o komórkach 5G, zrzutu dzienników nanoaplikacji oraz inne ulepszenia.

Obowiązkowe funkcje systemowe

Źródła sygnałów kontekstowych, takie jak czujniki, są podzielone na opcjonalne obszary funkcji, ale w przypadku wszystkich implementacji CHRE wymagane są 2 funkcje podstawowe. Obejmuje to podstawowe interfejsy API systemu, takie jak te do ustawiania zegarów, wysyłania i odbierania wiadomości do klientów na procesorze aplikacji, rejestrowania itp. Więcej informacji znajdziesz w nagłówkach interfejsu API.

Oprócz podstawowych funkcji systemu określonych w interfejsie CHRE API istnieją też obowiązkowe funkcje CHRE na poziomie systemu określone na poziomie interfejsu HAL Context Hub. Najważniejsza z nich to możliwość dynamicznego ładowania i rozładowywania nanoaplikacji.

standardowa biblioteka C/C++,

Aby zminimalizować wykorzystanie pamięci i złożoność systemu, implementacje CHRE muszą obsługiwać tylko podzbiór standardowych bibliotek i funkcji języka C oraz C++, które wymagają obsługi w czasie wykonywania. Zgodnie z tymi zasadami niektóre funkcje są wyraźnie wykluczone ze względu na ich obszerne zależności od pamięci i systemu operacyjnego, a inne dlatego, że zostały zastąpione przez bardziej odpowiednie interfejsy API do obsługi CHR. Nie jest to pełna lista, ale te funkcje nie są dostępne w nanoaplikacji:

• Wyjątki C++ i informacje o typach w czasie wykonywania (RTTI)
• Obsługa wielowątkowości standardowej biblioteki, w tym nagłówków C++11: <thread>, <mutex>, <atomic>, <future>.
• Standardowe biblioteki wejścia/wyjścia C i C++
• Standardowa biblioteka szablonów (STL) w C++
• Standardowa biblioteka wyrażeń regularnych w C++
• dynamiczny przydział pamięci za pomocą standardowych funkcji (np. malloc, calloc, realloc, free, operator new) i innych standardowych funkcji biblioteki, które z założenia używają dynamicznego przydziału, takich jak std::unique_ptr
• Obsługa lokalizacji i znaków Unicode
• Biblioteki dotyczące daty i godziny
• Funkcje, które modyfikują normalny przepływ programu, w tym <setjmp.h>, <signal.h>, abort, std::terminate
• Dostęp do środowiska hosta, w tym system i getenv
• POSIX i inne biblioteki nieuwzględnione w standardach językowych C99 lub C++11

W wielu przypadkach funkcje CHRE API i biblioteki narzędzi oferują podobne możliwości. Na przykład chreLog może służyć do rejestrowania debugowania na potrzeby systemu logcat na Androida, podczas gdy bardziej tradycyjny program może używać printf lub std::cout.

W tym przypadku wymagane są niektóre standardowe funkcje biblioteki. Od implementacji platformy zależy, czy zostaną udostępnione za pomocą bibliotek statycznych do umieszczenia w pliku binarnym nanoaplikacji lub w wyniku dynamicznego połączenia między nanoaplikacją a systemem. Dotyczy to między innymi:

• Narzędzia związane z ciągami znaków i tablicami: memcmp, memcpy, memmove, memset, strlen

• Biblioteka matematyczna: często używane funkcje zmiennoprzecinkowe o pojedynczej precyzji:

  • Operacje podstawowe: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf, remainderf
  • Funkcje wykładnicze i potęgowe: expf, log2f, powf, sqrtf
  • Funkcje trygonometryczne i wykładnicze: sinf, cosf, tanf, asinf, acosf, atan2f, tanhf

Chociaż niektóre platformy podstawowe obsługują dodatkowe funkcje, nanoaplikacja nie jest przenośna w przypadku implementacji CHRE, chyba że jej zewnętrzne zależności są ograniczone do funkcji CHRE API i zatwierdzonych funkcji standardowych bibliotek.

Funkcje opcjonalne

Aby promować sprzęt i oprogramowanie, interfejs CHRE API został podzielony na obszary funkcji, które są uważane za opcjonalne z perspektywy interfejsu API. Chociaż te funkcje mogą nie być wymagane do obsługi zgodnej implementacji CHRE, mogą być wymagane do obsługi konkretnej nanoaplikacji. Nawet jeśli dana platforma nie obsługuje określonego zestawu interfejsów API, nanoaplikacje, które odwołują się do tych funkcji, muszą mieć możliwość ich kompilacji i wczytania.

Czujniki

Interfejs CHRE API umożliwia wysyłanie żądań o dane z czujników, takich jak akcelerometr, żyroskop, magnetometr, czujnik jasności otoczenia i czujnik zbliżeniowy. Te interfejsy API mają zapewniać zestaw funkcji podobny do interfejsów API Android Sensors, w tym obsługę grupowania próbek czujników w celu zmniejszenia zużycia energii. Przetwarzanie danych z czujnika w CHRE umożliwia znacznie mniejszą moc i mniejsze opóźnienia w przetwarzaniu sygnałów ruchu w porównaniu z obsługą punktu dostępu.

GNSS

CHRE udostępnia interfejsy API do wysyłania żądań o dane o lokalizacji z globalnego systemu nawigacji satelitarnej (GNSS), w tym GPS i innych konstelacji satelitarnych. Obejmuje to żądania okresowych poprawek pozycji oraz nieprzetworzone dane pomiarowe, choć obie te funkcje są niezależne. Ponieważ CHRE ma bezpośrednie połączenie z podsystemem GNSS, zużycie energii jest mniejsze niż w przypadku żądań GNSS opartych na AP, ponieważ AP może pozostawać w stanie uśpienia przez cały czas trwania sesji lokalizacji.

Wi-Fi

CHRE umożliwia interakcję z urządzeniem Wi-Fi, głównie na potrzeby lokalizowania. System GNSS działa dobrze w przypadku lokalizacji na zewnątrz, ale wyniki skanowania Wi-Fi mogą dostarczać dokładnych informacji o lokalizacji w pomieszczeniach i w obszarach zurbanizowanych. Oprócz unikania kosztów budzenia punktu dostępu na potrzeby skanowania CHRE może też odbierać wyniki skanowania sieci Wi-Fi przeprowadzanego przez oprogramowanie układu Wi-Fi w celu nawiązania połączenia. Zwykle nie są one przesyłane do punktu dostępu ze względu na zużycie energii. Wykorzystanie skanowania połączeń do celów kontekstowych pomaga zmniejszyć łączną liczbę skanowań Wi-Fi, co pozwala oszczędzać energię.

W interfejsie CHRE API w wersji 1.1 dodano obsługę Wi-Fi, w tym możliwość monitorowania wyników skanowania i uruchamiania skanowania na żądanie. W wersji 1.2 te możliwości zostały rozszerzone o możliwość wykonywania pomiarów czasu w podróży (RTT) w przypadku punktów dostępu, które obsługują tę funkcję. Umożliwia to dokładne określanie pozycji względnej.

WWAN

Interfejs CHRE API umożliwia pobieranie informacji identyfikacyjnych komórki obsługującej i jej sąsiadów, co zwykle jest używane do określania przybliżonej lokalizacji.

Audio

CHRE może przetwarzać partie danych dźwiękowych z mikrofonu o niskiej mocy, który zwykle wykorzystuje sprzęt używany do implementacji HAL SoundTrigger HAL. Przetwarzanie danych audio w CHRE umożliwia ich łączenie z innymi danymi, takimi jak dane z czujników ruchu.

Implementacja referencyjna

Kod referencyjny dla ram CHRE jest zawarty w AOSP w projekcie system/chre, który jest realizowany w C++11. Chociaż nie jest to wymagane, zalecamy, aby wszystkie implementacje CHRE były oparte na tej bazie kodu. Pomoże to zapewnić spójność i przyspieszyć wdrażanie nowych funkcji. Ten kod jest analogiczny do podstawowego frameworku Androida, ponieważ jest to implementacja interfejsów API typu open source, z których korzystają aplikacje. Stanowi on podstawę i standard zgodności. Można go dostosowywać i rozszerzać o funkcje specyficzne dla danego dostawcy, ale zalecamy, aby wspólny kod był jak najbardziej zbliżony do kodu referencyjnego. Podobnie jak w przypadku HAL Androida, implementacja plików referencyjnych CHRE wykorzystuje różne abstrakcje platformowe, aby umożliwić dostosowanie jej do każdego urządzenia spełniającego minimalne wymagania.

Szczegółowe informacje techniczne i poradnik portingu znajdziesz w pliku README dołączonym do projektu system/chre.