Środowisko wykonawcze centrum kontekstowego (CHRE)

Smartfony zawierają wiele procesorów, każdy zoptymalizowany do wykonywania różnych zadań. Jednak Android działa tylko na jednym procesorze: procesorze aplikacji (AP). Punkt dostępowy jest dostrojony pod kątem zapewniania doskonałej wydajności w zastosowaniach związanych z ekranem, np. w grach, ale jest zbyt energochłonny, aby obsługiwać funkcje wymagające częstego, krótkiego przetwarzania przez cały czas, nawet gdy ekran jest wyłączony. Mniejsze procesory są w stanie efektywniej obsługiwać te obciążenia, wykonując swoje zadania bez zauważalnego wpływu na żywotność baterii. Jednakże środowiska oprogramowania w tych procesorach o niskim poborze mocy są bardziej ograniczone i mogą się znacznie różnić, co utrudnia rozwój międzyplatformowy.

Context Hub Runtime Environment (CHRE) zapewnia wspólną platformę do uruchamiania aplikacji na procesorze o niskim poborze mocy, z prostym, ustandaryzowanym, przyjaznym dla wbudowanych interfejsem API. CHRE ułatwia producentom OEM urządzeń i ich zaufanym partnerom odciążenie przetwarzania od punktu dostępowego, oszczędzanie baterii i poprawę różnych obszarów doświadczenia użytkownika, a także udostępnienie klasy zawsze włączonych, świadomych kontekstu funkcji, szczególnie tych obejmujących zastosowanie maszyn nauka wyczuwania otoczenia.

Kluczowe idee

CHRE to środowisko oprogramowania, w którym małe aplikacje natywne, zwane nanoaplikacjami , działają na procesorze o niskim poborze mocy i wchodzą w interakcję z systemem bazowym za pośrednictwem wspólnego interfejsu API CHRE. Aby przyspieszyć prawidłową implementację interfejsów API CHRE, w AOSP uwzględniono wieloplatformową referencyjną implementację CHRE. Implementacja referencyjna obejmuje wspólny kod i abstrakcje podstawowego sprzętu i oprogramowania poprzez szereg warstw abstrakcji platformy (PAL). Nanoaplikacje są prawie zawsze powiązane z jedną lub większą liczbą aplikacji klienckich działających w systemie Android, które wchodzą w interakcję z CHRE i nanoaplikacjami za pośrednictwem interfejsów API systemu ContextHubManager o ograniczonym dostępie.

Na wysokim poziomie można dostrzec podobieństwa między architekturą CHRE i Androidem jako całością. Istnieje jednak kilka ważnych rozróżnień:

  • CHRE obsługuje uruchamianie wyłącznie nanoaplikacji opracowanych w kodzie natywnym (C lub C++); Java nie jest obsługiwana.
  • Ze względu na ograniczenia zasobów i bezpieczeństwa CHRE nie jest otwarte do użytku przez dowolne aplikacje na Androida innych firm. Dostęp do niego mają tylko aplikacje zaufane przez system.

Należy również dokonać istotnego rozróżnienia pomiędzy koncepcją CHRE a koncentratorem czujników. Chociaż do wdrożenia koncentratora czujników i CHRE często używa się tego samego sprzętu, samo CHRE nie zapewnia funkcjonalności czujnika wymaganej przez Android Sensors HAL . CHRE jest powiązany z kontekstową strukturą HAL i działa jako klient specyficznej dla urządzenia struktury czujników w celu odbierania danych z czujników bez angażowania punktu dostępowego.

Architektura szkieletowa CHRE

Rysunek 1. Architektura frameworka CHRE

Centrum kontekstowe HAL

Warstwa abstrakcji sprzętu Kontekst Hub (HAL) to interfejs między platformą Android a implementacją CHRE urządzenia, zdefiniowaną w hardware/interfaces/contexthub . Kontekst HAL definiuje interfejsy API, za pomocą których platforma Android wykrywa dostępne centra kontekstu i ich nanoaplikacje, wchodzi w interakcję z tymi nanoaplikacjami poprzez przekazywanie komunikatów oraz umożliwia ładowanie i rozładowywanie nanoaplikacji. Referencyjna implementacja kontekstowej warstwy HAL, która współpracuje z referencyjną implementacją CHRE, jest dostępna pod system/chre/host .

W przypadku konfliktu pomiędzy niniejszą dokumentacją a definicją HAL, definicja HAL ma pierwszeństwo.

Inicjalizacja

Po uruchomieniu systemu Android usługa ContextHubService wywołuje funkcję HAL getHubs() w celu ustalenia, czy na urządzeniu są dostępne jakiekolwiek koncentratory kontekstu. Jest to blokujące, jednorazowe wywołanie, więc musi zostać zakończone szybko, aby uniknąć opóźnienia rozruchu, i musi zwrócić dokładny wynik, ponieważ nie można później wprowadzić nowych centrów kontekstowych.

Ładowanie i rozładowywanie nanoaplikacji

Centrum kontekstowe może zawierać zestaw nanoaplikacji zawartych w obrazie urządzenia i ładowanych podczas uruchamiania CHRE. Są to tak zwane wstępnie załadowane nanoaplikacje i powinny zostać uwzględnione w pierwszej możliwej odpowiedzi na queryApps() .

Koncentrator kontekstowy HAL obsługuje także dynamiczne ładowanie i rozładowywanie nanoaplikacji w czasie wykonywania za pomocą funkcji loadNanoApp() i unloadNanoApp() . Nanoaplikacje są dostarczane do HAL w formacie binarnym specyficznym dla implementacji sprzętu i oprogramowania CHRE na urządzeniu.

Jeśli implementacja ładowania nanoaplikacji obejmuje zapisanie jej w pamięci nieulotnej, takiej jak pamięć flash podłączona do procesora, na którym działa CHRE, wówczas implementacja CHRE musi zawsze uruchamiać się z dynamicznymi nanoaplikacjami w stanie wyłączonym. Oznacza to, że żaden kod nanoaplikacji nie zostanie wykonany, dopóki żądanie enableNanoapp() nie zostanie odebrane przez warstwę HAL. Wstępnie załadowane nanoaplikacje można inicjować w stanie włączonym.

Centrum kontekstowe uruchamia się ponownie

Chociaż nie oczekuje się, że CHRE uruchomi się ponownie w trakcie normalnego działania, może być konieczne przywrócenie działania w przypadku nieoczekiwanych sytuacji, takich jak próba dostępu do niezamapowanego adresu pamięci. W takich sytuacjach CHRE uruchamia się ponownie niezależnie od Androida. HAL powiadamia o tym Androida poprzez zdarzenie RESTARTED , które musi wysłać dopiero po ponownym zainicjowaniu CHRE do momentu, w którym będzie mógł akceptować nowe żądania, takie jak queryApps() .

Przegląd systemu CHRE

CHRE zaprojektowano w oparciu o architekturę sterowaną zdarzeniami, w której podstawową jednostką obliczeniową jest zdarzenie przekazywane do punktu wejścia obsługi zdarzeń nanoaplikacji. Chociaż framework CHRE może być wielowątkowy, dana nanoaplikacja nigdy nie jest wykonywana równolegle z wieloma wątkami. Struktura CHRE wchodzi w interakcję z daną nanoaplikacją poprzez jeden z trzech punktów wejścia nanoaplikacji ( nanoappStart() , nanoappHandleEvent() i nanoappEnd() ) lub poprzez wywołanie zwrotne dostarczone w poprzednim wywołaniu API CHRE, a nanoaplikacje wchodzą w interakcję ze strukturą CHRE i bazowego systemu poprzez CHRE API. Interfejs API CHRE zapewnia zestaw podstawowych funkcji, a także udogodnienia umożliwiające dostęp do sygnałów kontekstowych, w tym czujników, GNSS, Wi-Fi, WWAN i audio, i można go rozszerzyć o dodatkowe funkcje specyficzne dla dostawcy do wykorzystania przez nanoaplikacje specyficzne dla dostawcy .

Zbuduj system

Chociaż HAL kontekstu i inne niezbędne komponenty po stronie AP są budowane razem z Androidem, kod działający w CHRE może mieć wymagania, które czynią go niezgodnym z systemem kompilacji Androida, takie jak potrzeba specjalistycznego zestawu narzędzi. Dlatego projekt CHRE w AOSP zapewnia uproszczony system kompilacji oparty na GNU Make do kompilowania nanoaplikacji oraz opcjonalnie framework CHRE w biblioteki, 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 API CHRE jest napisany w standardzie języka C99, a implementacja referencyjna wykorzystuje ograniczony podzbiór języka C++ 11 odpowiedni dla aplikacji o ograniczonych zasobach.

API CHRE

CHRE API to zbiór plików nagłówkowych C, które definiują interfejs oprogramowania pomiędzy nanoaplikacją a systemem. Został zaprojektowany tak, aby kod nanoaplikacji był kompatybilny ze wszystkimi urządzeniami obsługującymi CHRE, co oznacza, że ​​kod źródłowy nanoaplikacji nie musi być modyfikowany, aby obsługiwał nowy typ urządzenia, chociaż może wymagać ponownej kompilacji specjalnie dla procesora urządzenia docelowego zestaw instrukcji lub interfejs binarny aplikacji (ABI). Architektura CHRE i projekt API zapewniają również, że nanoaplikacje są binarnie kompatybilne z różnymi wersjami CHRE API, co oznacza, że ​​nanoaplikacja nie musi być rekompilowana, aby działać w systemie, który implementuje inną wersję CHRE API w porównaniu do docelowy interfejs API, względem którego kompilowana jest nanoaplikacja. Innymi słowy, jeśli plik binarny nanoapp działa na urządzeniu obsługującym CHRE API v1.3 i to urządzenie zostanie zaktualizowane do obsługi CHRE API v1.4, ten sam plik binarny nanoapp będzie nadal działać. Podobnie nanoaplikacja może działać na interfejsie CHRE API v1.2 i może określić w czasie wykonywania, czy wymaga funkcjonalności z API v1.3, aby osiągnąć swoją funkcjonalność, czy też może działać, potencjalnie z płynną degradacją funkcji.

Nowe wersje interfejsu CHRE API są wydawane wraz z systemem Android, jednak ponieważ implementacja CHRE jest częścią implementacji dostawcy , wersja interfejsu CHRE API obsługiwana na urządzeniu niekoniecznie jest powiązana z wersją systemu Android.

Podsumowanie wersji

Podobnie jak schemat wersjonowania Androida HIDL , interfejs API CHRE opiera się na wersjonowaniu semantycznym . Wersja główna wskazuje zgodność binarną, podczas gdy wersja pomocnicza jest zwiększana, gdy wprowadzane są funkcje kompatybilne wstecz. Interfejs API CHRE zawiera adnotacje kodu źródłowego umożliwiające identyfikację, która wersja wprowadziła funkcję lub parametr, na przykład @since v1.1 .

Implementacja CHRE udostępnia również wersję poprawki specyficzną dla platformy poprzez chreGetVersion() , która wskazuje, kiedy w implementacji zostaną wprowadzone poprawki błędów lub drobne aktualizacje.

Wersja 1.0 (Android 7)

Obejmuje obsługę czujników i podstawową funkcjonalność nanoaplikacji, taką jak zdarzenia i liczniki czasu.

Wersja 1.1 (Android 8)

Wprowadza możliwości lokalizacji poprzez lokalizację GNSS i surowe pomiary, skanowanie Wi-Fi i informacje o sieci komórkowej, wraz z ogólnymi udoskonaleniami umożliwiającymi komunikację między nanoaplikacjami i innymi ulepszeniami.

Wersja 1.2 (Android 9)

Dodaje obsługę danych z mikrofonu o małej mocy, zasięg Wi-Fi RTT, powiadomienia o wybudzeniu/uśpieniu AP i inne ulepszenia.

Wersja 1.3 (Android 10)

Zwiększa możliwości związane z danymi kalibracji czujnika, dodaje obsługę opróżniania zbiorczych danych czujnika na żądanie, definiuje typ czujnika wykrywającego krok i rozszerza zdarzenia lokalizacji GNSS o dodatkowe pola dokładności.

Wersja 1.4 (Android 11)

Dodaje obsługę informacji o komórkach 5G, zrzut debugowania nanoaplikacji i inne ulepszenia.

Obowiązkowe funkcje systemu

Chociaż źródła sygnałów kontekstowych, takie jak czujniki, są podzielone na opcjonalne obszary funkcji, we wszystkich implementacjach CHRE wymaganych jest kilka podstawowych funkcji. Obejmuje to podstawowe interfejsy API systemu, takie jak te służące do ustawiania liczników czasu, wysyłania i odbierania komunikatów do klientów na procesorze aplikacji, rejestrowania i inne. Aby uzyskać szczegółowe informacje, zobacz nagłówki API .

Oprócz podstawowych funkcji systemu skodyfikowanych w CHRE API, istnieją również obowiązkowe funkcje na poziomie systemu CHRE określone na poziomie HAL Context Hub. Najważniejszą z nich jest możliwość dynamicznego ładowania i rozładowywania nanoaplikacji.

Standardowa biblioteka C/C++

Aby zminimalizować zużycie pamięci i złożoność systemu, implementacje CHRE muszą obsługiwać tylko podzbiór standardowych bibliotek C i C++ oraz funkcji językowych wymagających obsługi środowiska wykonawczego. Zgodnie z tymi zasadami niektóre funkcje są wyraźnie wykluczone ze względu na ich pamięć i/lub rozległe zależności na poziomie systemu operacyjnego, a inne, ponieważ zostały zastąpione przez bardziej odpowiednie interfejsy API specyficzne dla CHRE. Chociaż lista nie jest wyczerpująca, poniższe funkcje nie są przeznaczone do udostępniania nanoaplikacjom:

  • Wyjątki C++ i informacje o typie środowiska wykonawczego (RTTI)
  • Obsługa wielowątkowości biblioteki standardowej, w tym nagłówki C++11 <thread> , <mutex> , <atomic> , <future>
  • Standardowe biblioteki wejścia/wyjścia w językach C i C++
  • Standardowa biblioteka szablonów C++ (STL)
  • Biblioteka standardowych wyrażeń regularnych C++
  • Dynamiczna alokacja pamięci poprzez standardowe funkcje (na przykład malloc , calloc , realloc , free , operator new ) i inne standardowe funkcje biblioteczne, które z natury korzystają z dynamicznej alokacji, takie jak std::unique_ptr
  • Lokalizacja i obsługa znaków Unicode
  • Biblioteki daty i godziny
  • Funkcje modyfikujące normalny przebieg programu, w tym <setjmp.h> , <signal.h> , abort , std::terminate
  • Dostęp do środowiska hosta, w tym system , getenv
  • POSIX i inne biblioteki nieuwzględnione w standardach językowych C99 lub C++11

W wielu przypadkach równoważna funkcjonalność jest dostępna w funkcjach CHRE API i/lub bibliotekach narzędzi. Na przykład chreLog może być używany do rejestrowania debugowania ukierunkowanego na system logcat systemu Android, gdzie bardziej tradycyjny program może używać printf lub std::cout .

W przeciwieństwie do tego wymagane są pewne standardowe funkcje biblioteki. Do implementacji platformy należy udostępnienie ich za pomocą bibliotek statycznych w celu umieszczenia ich w pliku binarnym nanoaplikacji lub poprzez dynamiczne połączenie między nanoaplikacją a systemem. Obejmuje to między innymi:

  • Narzędzia łańcuchowe/tablicowe: memcmp , memcpy , memmove , memset , strlen

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

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

Chociaż niektóre platformy obsługują dodatkowe funkcje, nanoaplikacja nie jest uważana za przenośną w implementacjach CHRE, chyba że ogranicza swoje zewnętrzne zależności do funkcji API CHRE i zatwierdzonych standardowych funkcji bibliotecznych.

Opcjonalne funkcje

Aby promować sprzęt i oprogramowanie, CHRE API podzielono na obszary funkcji, które z punktu widzenia API są uważane za opcjonalne. Chociaż te funkcje mogą nie być wymagane do obsługi kompatybilnej implementacji CHRE, mogą być wymagane do obsługi konkretnej nanoaplikacji. Nawet jeśli platforma nie obsługuje danego zestawu interfejsów API, nanoaplikacje odwołujące się do tych funkcji muszą mieć możliwość budowania i ładowania.

Czujniki

Interfejs API CHRE umożliwia żądanie danych z czujników, w tym akcelerometru, żyroskopu, magnetometru, czujnika światła otoczenia i czujnika zbliżeniowego. Te interfejsy API mają zapewniać zestaw funkcji podobny do interfejsów API czujników systemu Android, w tym obsługę grupowania próbek czujników w celu zmniejszenia zużycia energii. Przetwarzanie danych z czujników w CHRE umożliwia przetwarzanie sygnałów ruchu o znacznie niższym poborze mocy i mniejszych opóźnieniach w porównaniu do przetwarzania na AP.

GNSS

CHRE dostarcza interfejsy API służące do żądania danych lokalizacyjnych z globalnego systemu nawigacji satelitarnej (GNSS), w tym GPS i innych konstelacji satelitarnych. Obejmuje to żądania okresowych ustalania pozycji, a także surowe dane pomiarowe, chociaż oba są niezależnymi możliwościami. Ponieważ CHRE ma bezpośrednie połączenie z podsystemem GNSS, moc jest zmniejszona w porównaniu z żądaniami GNSS opartymi na punkcie dostępowym, ponieważ punkt dostępowy może pozostawać w stanie uśpienia przez cały cykl życia sesji lokalizacyjnej.

Wi-Fi

CHRE zapewnia możliwość interakcji z chipem Wi-Fi, głównie w celach lokalizacyjnych. Chociaż GNSS sprawdza się dobrze w przypadku lokalizacji na zewnątrz, wyniki skanów Wi-Fi mogą zapewnić dokładne informacje o lokalizacji w pomieszczeniach i na obszarach rozwiniętych. Oprócz uniknięcia kosztów wybudzania punktu dostępowego na potrzeby skanowania, CHRE może odsłuchiwać wyniki skanowań Wi-Fi wykonywanych przez oprogramowanie sprzętowe Wi-Fi w celu zapewnienia łączności, które zazwyczaj nie są dostarczane do punktu dostępowego ze względu na zasilanie. Wykorzystywanie skanów łączności do celów kontekstowych pomaga zmniejszyć całkowitą liczbę wykonywanych skanowań Wi-Fi, oszczędzając energię.

W CHRE API v1.1 dodano obsługę Wi-Fi, w tym możliwość monitorowania wyników skanowania i wyzwalania skanowania na żądanie. Możliwości te zostały rozszerzone w wersji 1.2 o możliwość wykonywania pomiarów czasu podróży w obie strony (RTT) względem punktów dostępowych obsługujących tę funkcję, co umożliwia dokładne określenie pozycji względnej.

WWAN

Interfejs API CHRE zapewnia możliwość pobierania informacji identyfikacyjnych obsługującej komórki i jej sąsiadów, co jest zwykle używane do celów gruboziarnistej lokalizacji.

Audio

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

Implementacja referencyjna

Kod referencyjny frameworka CHRE jest zawarty w AOSP w projekcie system/chre , zaimplementowanym w C++ 11. Chociaż nie jest to ściśle wymagane, zaleca się, aby wszystkie implementacje CHRE opierały się na tej bazie kodu, aby zapewnić spójność i przyspieszyć wdrażanie nowych możliwości. Kod ten można postrzegać jako analogię do podstawowej platformy Androida, ponieważ jest to implementacja interfejsów API typu open source używanych przez aplikacje, służąca jako punkt odniesienia i standard zgodności. Chociaż można go dostosować i rozszerzyć o możliwości specyficzne dla dostawcy, zaleca się utrzymanie wspólnego kodu jak najbliżej odniesienia. Podobnie jak HAL systemu Android, referencyjna implementacja CHRE wykorzystuje różne abstrakcje platform, aby umożliwić dostosowanie jej do dowolnego urządzenia spełniającego minimalne wymagania.

Szczegóły techniczne i przewodnik dotyczący przenoszenia można znaleźć w pliku README zawartym w projekcie system/chre .