Środowisko wykonawcze centrum kontekstu (CHRE)

Smartfony zawierają wiele procesorów, z których każdy jest zoptymalizowany do wykonywania różnych zadań. Android działa jednak tylko na jednym procesorze: procesorze aplikacji (AP). 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. Środowiska oprogramowania w tych energooszczędnych procesorach są jednak bardziej ograniczone i mogą się znacznie różnić, co utrudnia tworzenie aplikacji na wiele platform.

Środowisko wykonawcze Context Hub (CHRE) zapewnia wspólną platformę do uruchamiania aplikacji na procesorze niskonapięciowym za pomocą prostego, ujednoliconego interfejsu API, który ułatwia implementację. CHRE ułatwia producentom urządzeń i ich zaufanym partnerom przeniesienie przetwarzania z procesora na procesor graficzny, oszczędzanie energii i ulepszanie różnych aspektów wrażeń użytkownika oraz udostępnianie funkcji zawsze włączonych i świadomych kontekstu, zwłaszcza tych, które wykorzystują uczenie maszynowe do wykrywania otoczenia.

Kluczowych pojęć

CHRE to środowisko oprogramowania, w którym małe aplikacje natywne, 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 i abstrakcje dla sprzętu i oprogramowania za pomocą serii 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 rzecz biorąc, architekturę CHRE można porównać z architekturą Androida jako całości. Istnieją jednak pewne ważne różnice:

  • CHRE obsługuje tylko nanoaplikacje napisane w natywności (C lub C++). Java nie jest obsługiwana.
  • 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 modułu sensorów i CHRE często używa się tego samego sprzętu, CHRE nie zapewnia możliwości sensorów wymaganych przez interfejs HAL czujników Androida. CHRE jest powiązany z interfejsem HAL usługi Context Hub i działa jako klient interfejsu czujnika na potrzeby odbioru danych z czujnika bez udziału AP.

Architektura ram CHRE

Rysunek 1. Architektura ram CHRE

Context Hub HAL

Warstwę sprzętową abstrakcji (HAL) Context Hub stanowi interfejs między platformą Android a implementacją CHRE na urządzeniu, zdefiniowany w hardware/interfaces/contexthub. Interfejs Context Hub HAL definiuje interfejsy API, za pomocą których platforma Android framework wykrywa dostępne huby kontekstowe i ich nanoaplikacje, wchodzi z nimi w interakcje poprzez przesyłanie wiadomości oraz umożliwia ich wczytywanie i wylogowywanie. 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.

Inicjowanie

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ące wywołanie jednorazowe, 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 Context Hub obsługuje też wczytywanie i wylogowywanie nanoaplikacji dynamicznie w czasie działania za pomocą funkcji loadNanoApp() i unloadNanoApp(). Nanoaplikacje są dostarczane do HAL w formacie binarnym, który jest specyficzny dla sprzętu i oprogramowania CHRE.

Jeśli implementacja ładowania nanoaplikacji polega na zapisaniu jej w pamięci nieulotnej, takiej jak pamięć flash podłączona do procesora, który uruchamia CHRE, implementacja CHRE musi zawsze uruchamiać się z tymi dynamicznymi nanoaplikacją w wyłączonym stanie. Oznacza to, że żaden kod nanoaplikacji nie jest wykonywany, dopóki nie zostanie otrzymane żądanie enableNanoapp() przez HAL. Wstępnie wczytane nanoaplikacje mogą się uruchamiać w stanie włączonym.

Ponowne uruchamianie 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 ona na celu zapewnienie zgodności kodu nanoaplikacji na wszystkich urządzeniach obsługujących CHRE, co oznacza, że kodu źródłowego nanoaplikacji nie trzeba modyfikować, aby obsługiwać nowy typ urządzenia. Może jednak być konieczne ponowne skompilowanie kodu na potrzeby zestawu instrukcji procesora lub interfejsu binarnego aplikacji (ABI) urządzenia docelowego. 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. Inaczej mówiąc, jeśli binarny plik nanoaplikacji działa na urządzeniu obsługującym interfejs CHRE API w wersji 1.3, a to urządzenie zostanie zaktualizowane do wersji CHRE API 1.4, ten sam binarny plik nanoaplikacji będzie 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.

Nowe wersje interfejsu CHRE API są publikowane wraz z Androidem, ale ponieważ implementacja CHRE jest częścią implementacji dostawcy, wersja interfejsu CHRE API obsługiwana na urządzeniu nie jest koniecznie 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 z poprzednimi wersjami. 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. Pełne informacje 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 wczytywania i wylogowywania 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 dla Chrome OS. 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ątkowa standardowej biblioteki, w tym nagłówków C++11: <thread>, <mutex>, <atomic>, <future>.
  • Standardowe biblioteki wejścia/wyjścia w językach 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 nieobjęte standardami języka C99 ani C++11

W wielu przypadkach funkcje interfejsu 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. Implementacja platformy może udostępniać te funkcje za pomocą bibliotek statycznych, aby uwzględnić je w pliku binarnym nanoaplikacji, lub za pomocą dynamicznego łączenia między nanoaplikacją a systemem. Dotyczy to między innymi:

  • Narzędzia do obsługi ciągów i tablic: memcmp, memcpy, memmove, memset, strlen

  • Biblioteka matematyczna: najczęściej używane funkcje zmiennoprzecinkowe o pojedynczej precyzji:

    • Podstawowe operacje: 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 biblioteki standardowej.

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 kompilowania i wczytywania.

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 czujników Androida, w tym obsługę grupowania próbek czujników w celu zmniejszenia zużycia energii. Przetwarzanie danych czujnika w ramach CHRE umożliwia znacznie mniejsze zużycie energii i opóźnienie w przetwarzaniu sygnałów ruchu w porównaniu z wykorzystaniem procesora AP.

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 sieci Wi-Fi mogą dostarczyć dokładnych informacji o lokalizacji w pomieszczeniach i w rozwiniętych obszarach. 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 o identyfikacji komórki dla komórki obsługującej i jej sąsiadów, które są zwykle używane do celów lokalizacji o niskiej dokładności.

Audio

CHRE może przetwarzać partie danych audio z mikrofonu o niskim poborze mocy, który zwykle wykorzystuje sprzęt używany do implementacji interfejsu 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-i na Androida, implementacja referencyjna CHRE korzysta z różnych abstrakcji platformy, aby umożliwić dostosowanie jej do dowolnego urządzenia spełniającego wymagania minimalne.

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