Smartfony zawierają kilka procesorów, z których każdy jest zoptymalizowany pod kątem wykonywania różnych zadań. Android działa jednak tylko na jednym procesorze: procesorze aplikacji (AP). Procesor aplikacji jest dostosowany do zapewniania wysokiej wydajności w przypadku korzystania z urządzenia przy włączonym ekranie, np. podczas grania, ale zużywa zbyt dużo energii, aby obsługiwać funkcje, które wymagają częstych, krótkich serii przetwarzania przez cały czas, nawet gdy ekran jest wyłączony. Mniejsze procesory mogą wydajniej obsługiwać te obciążenia, wykonując zadania bez zauważalnego wpływu na baterię. Jednak środowiska oprogramowania w tych procesorach o niskim poborze mocy są bardziej ograniczone i mogą się znacznie różnić, co utrudnia tworzenie aplikacji na różne platformy.
Środowisko wykonawcze Context Hub (CHRE) zapewnia wspólną platformę do uruchamiania aplikacji na procesorze o niskim poborze mocy, z prostym, standardowym interfejsem API, który jest łatwy do osadzenia. CHRE ułatwia producentom urządzeń i ich zaufanym partnerom odciążanie procesora aplikacji, co pozwala oszczędzać baterię i poprawiać różne aspekty wygody użytkowników, a także umożliwia korzystanie z funkcji działających w trybie ciągłym i uwzględniających kontekst, 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 o niskim poborze mocy i współpracują z systemem bazowym za pomocą wspólnego interfejsu CHRE API. Aby przyspieszyć prawidłową implementację interfejsów API CHRE, w AOSP znajduje się referencyjna implementacja CHRE na różne platformy. Implementacja referencyjna zawiera wspólny kod i abstrakcje dotyczące sprzętu i oprogramowania bazowego w postaci serii warstw abstrakcji platformy (PAL). Nanoaplikacje są prawie zawsze powiązane z co najmniej 1 aplikacją kliencką działającą na Androidzie, która wchodzi w interakcję z CHRE i nanoaplikacjami za pomocą interfejsów API systemu o ograniczonym dostępieContextHubManager.
Ogólnie rzecz biorąc, można znaleźć podobieństwa między architekturą CHRE a Androidem jako całością. Istnieje jednak kilka ważnych różnic:
- CHRE obsługuje tylko nanoaplikacje opracowane w kodzie natywnym (C lub C++); Java nie jest obsługiwana.
- Ze względu na ograniczenia zasobów i bezpieczeństwa CHRE nie jest dostępny dla dowolnych aplikacji na Androida innych firm. Dostęp do niego mają tylko aplikacje zaufane przez system.
Ważne jest też rozróżnienie między koncepcją CHRE a centrum czujników. Chociaż często używa się tego samego sprzętu do implementacji koncentratora czujników i CHRE, CHRE samo w sobie nie zapewnia możliwości czujników wymaganych przez HAL czujników Androida. CHRE jest powiązany z HAL koncentratora kontekstowego i działa jako klient platformy czujników specyficznej dla urządzenia, aby odbierać dane z czujników bez angażowania procesora aplikacji.
Rysunek 1. Architektura platformy CHRE
Context Hub HAL
Warstwa abstrakcji sprzętu (HAL) Context Hub to interfejs między platformą Android a implementacją CHRE na urządzeniu, zdefiniowany w hardware/interfaces/contexthub.
Warstwa HAL Centrum kontekstowego definiuje interfejsy API, za pomocą których platforma Android wykrywa dostępne centra kontekstowe i ich nanoaplikacje, wchodzi z nimi w interakcje za pomocą przekazywania wiadomości oraz umożliwia wczytywanie i zwalnianie nanoaplikacji. Implementacja referencyjna interfejsu HAL Context Hub, która działa z implementacją referencyjną CHRE, jest dostępna pod adresem system/chre/host.
W przypadku sprzeczności między tą dokumentacją a definicją HAL pierwszeństwo ma definicja HAL.
Inicjowanie
Po uruchomieniu Androida usługa ContextHubService wywołuje funkcję HAL getHubs(), aby sprawdzić, czy na urządzeniu są dostępne jakiekolwiek koncentratory kontekstowe. Jest to blokujące wywołanie jednorazowe, więc musi się szybko zakończyć, aby nie opóźniać uruchamiania, i musi zwracać dokładny wynik, ponieważ nie można później wprowadzać nowych centrów kontekstowych.
Wczytywanie i zwalnianie nanoaplikacji
Centrum kontekstowe może zawierać zestaw nanoaplikacji, które są uwzględnione w obrazie urządzenia i ładowane po uruchomieniu CHRE. Są one nazywane wstępnie załadowanymi nanoaplikacjami i powinny być uwzględnione w pierwszej możliwej odpowiedzi na queryApps().
Interfejs HAL Context Hub obsługuje też dynamiczne wczytywanie i zwalnianie nanoaplikacji w czasie działania za pomocą funkcji loadNanoApp() i unloadNanoApp(). Nanoaplikacje są dostarczane do HAL w formacie binarnym specyficznym dla sprzętu CHRE i implementacji oprogramowania urządzenia.
Jeśli implementacja wczytywania nanoaplikacji obejmuje zapisywanie jej w pamięci trwałej, np. w pamięci flash podłączonej do procesora, na którym działa CHRE, implementacja CHRE musi zawsze uruchamiać się z tymi dynamicznymi nanoaplikacjami w stanie wyłączonym. Oznacza to, że żaden kod nanoaplikacji nie jest wykonywany, dopóki przez HAL nie zostanie odebrane enableNanoapp()żądanie. Wstępnie wczytane nanoaplikacje mogą się inicjować w stanie włączonym.
Ponowne uruchomienia centrum kontekstowego
CHRE nie powinien być ponownie uruchamiany podczas normalnego działania, ale może być konieczny w przypadku nieoczekiwanych sytuacji, takich jak próba uzyskania dostępu do niezmapowanego adresu pamięci. W takich sytuacjach CHRE uruchamia się ponownie niezależnie od Androida. HAL powiadamia o tym system Android za pomocą zdarzenia RESTARTED, które musi wysłać dopiero po ponownym zainicjowaniu CHRE do momentu, w którym może on akceptować nowe żądania, takie jak queryApps().
Omówienie systemu CHRE
CHRE jest zaprojektowany w oparciu o architekturę opartą na zdarzeniach, w której podstawową jednostką obliczeniową jest zdarzenie przekazywane do punktu wejścia obsługi zdarzeń w aplikacji nano. Chociaż platforma CHRE może być wielowątkowa, dana nanoaplikacja nigdy nie jest wykonywana z wielu wątków równolegle. Platforma CHRE wchodzi w interakcję z daną nanoaplikacją za pomocą jednego z 3 punktów wejścia nanoaplikacji (nanoappStart(), nanoappHandleEvent() i nanoappEnd()) lub za pomocą wywołania zwrotnego podanego w poprzednim wywołaniu interfejsu CHRE API. Nanoaplikacje wchodzą w interakcję z platformą CHRE i systemem bazowym za pomocą interfejsu CHRE API. Interfejs CHRE API udostępnia zestaw podstawowych funkcji oraz narzędzi do uzyskiwania 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 dostawcy, które będą używane przez nanoaplikacje tego dostawcy.
System kompilacji
Chociaż HAL Context Hub i inne niezbędne komponenty po stronie AP są tworzone razem z Androidem, kod działający w CHRE może mieć wymagania, które sprawiają, że jest on niezgodny z systemem kompilacji Androida, np. potrzebę specjalistycznego łańcucha narzędzi. Dlatego projekt CHRE w AOSP udostępnia uproszczony system kompilacji oparty na GNU Make, który umożliwia kompilowanie nanoaplikacji i opcjonalnie platformy CHRE do bibliotek, które można zintegrować z systemem. Producenci urządzeń dodający obsługę CHRE powinni zintegrować z AOSP obsługę systemu kompilacji dla swoich urządzeń docelowych.
Interfejs CHRE API jest napisany w standardzie języka C99, a implementacja referencyjna korzysta z ograniczonego podzbioru C++11 odpowiedniego dla aplikacji o ograniczonych zasobach.
CHRE API
CHRE API to zbiór plików nagłówkowych C, które definiują interfejs oprogramowania między nanoaplikacją a systemem. Został on zaprojektowany tak, aby kod nanoaplikacji był zgodny ze wszystkimi urządzeniami obsługującymi CHRE. Oznacza to, że kod źródłowy nanoaplikacji nie musi być modyfikowany w celu obsługi nowego typu urządzenia, chociaż może wymagać ponownej kompilacji specjalnie dla zestawu instrukcji procesora urządzenia docelowego lub interfejsu ABI. Architektura CHRE i projekt interfejsu API zapewniają też binarną zgodność nanoaplikacji z różnymi wersjami interfejsu CHRE API. Oznacza to, że nanoaplikacji nie trzeba ponownie kompilować, aby uruchomić ją w systemie, który implementuje inną wersję interfejsu CHRE API niż docelowy interfejs API, z którym jest skompilowana. Innymi słowy, jeśli binarna wersja nanoaplikacji działa na urządzeniu, które obsługuje interfejs CHRE API w wersji 1.3, a to urządzenie zostanie uaktualnione do obsługi interfejsu CHRE API w wersji 1.4, ta sama binarna wersja nanoaplikacji będzie nadal działać. Podobnie nanoaplikacja może działać w interfejsie CHRE API w wersji 1.2 i określać w czasie działania, czy do osiągnięcia zamierzonego celu potrzebuje funkcji z interfejsu API w wersji 1.3, czy może działać bez nich, być może z ograniczeniem niektórych funkcji.
Nowe wersje interfejsu CHRE API są wydawane wraz z Androidem, ale ponieważ implementacja CHRE jest częścią implementacji dostawcy, wersja interfejsu CHRE API obsługiwana na urządzeniu nie musi być powiązana z wersją Androida.
Podsumowanie wersji
Podobnie jak schemat wersji HIDL Androida, interfejs CHRE API jest zgodny z wersjonowaniem semantycznym.
Wersja główna wskazuje zgodność binarną, a wersja podrzędna jest zwiększana, gdy wprowadzane są funkcje zgodne wstecznie. Interfejs CHRE API zawiera adnotacje w kodzie źródłowym, które wskazują, w której wersji wprowadzono funkcję lub parametr, np. @since v1.1.
Implementacja CHRE udostępnia też wersję poprawki specyficzną dla platformy za pomocą interfejsu chreGetVersion(), który 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 timery.
Wersja 1.1 (Android 8)
Wprowadza funkcje lokalizacji za pomocą lokalizacji GNSS i surowych pomiarów, skanowania Wi-Fi i informacji o sieci komórkowej, a także ogólne ulepszenia umożliwiające komunikację między nanoaplikacjami i inne usprawnienia.
Wersja 1.2 (Android 9)
Dodaje obsługę danych z mikrofonu o niskim poborze mocy, pomiarów odległości Wi-Fi RTT, powiadomień o wybudzeniu i uśpieniu punktu dostępu oraz inne ulepszenia.
Wersja 1.3 (Android 10)
Zwiększa możliwości związane z danymi kalibracji czujników, dodaje obsługę opróżniania na żądanie danych czujników w pakietach, definiuje typ czujnika wykrywania kroków i rozszerza zdarzenia lokalizacji GNSS o dodatkowe pola dokładności.
Wersja 1.4 (Android 11)
Dodano obsługę informacji o sieci komórkowej 5G, zrzutu debugowania nanoaplikacji i innych ulepszeń.
Obowiązkowe funkcje systemowe
Źródła sygnałów kontekstowych, takie jak czujniki, są podzielone na opcjonalne obszary funkcji, ale kilka podstawowych funkcji jest wymaganych we wszystkich implementacjach CHRE. Obejmuje to podstawowe interfejsy API systemu, takie jak interfejsy do ustawiania timerów, wysyłania i odbierania wiadomości do klientów na procesorze aplikacji, rejestrowania zdarzeń i inne. Szczegółowe informacje znajdziesz w artykule Nagłówki interfejsu API.
Oprócz podstawowych funkcji systemowych skodyfikowanych w interfejsie CHRE API istnieją też obowiązkowe funkcje systemowe CHRE na poziomie HAL centrum kontekstowego. Najważniejszą z nich jest możliwość dynamicznego wczytywania i zwalniania nanoaplikacji.
Biblioteka standardowa 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 w czasie działania. Zgodnie z tymi zasadami niektóre funkcje są wyraźnie wykluczone ze względu na wymagania dotyczące pamięci i rozbudowane zależności na poziomie systemu operacyjnego, a inne dlatego, że zostały zastąpione bardziej odpowiednimi interfejsami API specyficznymi dla CHRE. Poniższa lista nie jest wyczerpująca, ale te funkcje nie są przeznaczone dla nanoaplikacji:
- Wyjątki C++ i informacje o typie w czasie działania (RTTI)
- Obsługa wielowątkowości w bibliotece standardowej, w tym nagłówki C++11
<thread>,<mutex>,<atomic>,<future> - Biblioteki standardowych operacji wejścia/wyjścia w językach C i C++
- Biblioteka szablonów standardowych C++ (STL)
- Biblioteka wyrażeń regularnych w C++
- Dynamiczne przydzielanie pamięci za pomocą standardowych funkcji (np.
malloc,calloc,realloc,free,operator new) i innych standardowych funkcji biblioteki, które z natury wykorzystują dynamiczne przydzielanie pamięci, takich jakstd::unique_ptr. - Obsługa lokalizacji i znaków Unicode
- Biblioteki 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,getenv - Biblioteki POSIX i inne biblioteki, które nie są uwzględnione w standardach języka C99 ani C++11
W wielu przypadkach równoważne funkcje są dostępne w funkcjach interfejsu CHRE API i bibliotekach narzędziowych. Na przykład chreLog może służyć do rejestrowania informacji debugowania przeznaczonych dla systemu logcat Androida, podczas gdy bardziej tradycyjny program może używać printf lub std::cout.
Z kolei niektóre funkcje biblioteki standardowej są wymagane. To implementacja platformy decyduje o tym, czy udostępniać je za pomocą bibliotek statycznych do włączenia w plik binarny nanoaplikacji, czy przez dynamiczne łączenie nanoaplikacji z systemem. Obejmuje to między innymi:
- Narzędzia do obsługi ciągów znaków i tablic:
memcmp,memcpy,memmove,memset,strlen Biblioteka matematyczna: powszechnie używane funkcje zmiennoprzecinkowe 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 hiperboliczne:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Podstawowe operacje:
Niektóre platformy bazowe obsługują dodatkowe funkcje, ale nanoaplikacja nie jest uznawana za przenośną w różnych implementacjach CHRE, chyba że ogranicza swoje zależności zewnętrzne do funkcji interfejsu CHRE API i zatwierdzonych funkcji biblioteki standardowej.
Funkcje opcjonalne
Aby promować sprzęt i oprogramowanie, interfejs CHRE API jest podzielony na obszary funkcji, które z perspektywy interfejsu API są opcjonalne. Chociaż te funkcje mogą nie być wymagane do obsługi zgodnej implementacji CHRE, mogą być niezbędne do obsługi konkretnej nanoaplikacji. Nawet jeśli platforma nie obsługuje danego zestawu interfejsów API, nanoaplikacje, które odwołują się do tych funkcji, muszą być w stanie się skompilować i wczytać.
Czujniki
Interfejs CHRE API umożliwia wysyłanie zapytań o dane z czujników, w tym akcelerometru, żyroskopu, magnetometru, czujnika jasności otoczenia i czujnika zbliżeniowego. Te interfejsy API mają zapewniać zestaw funkcji podobny do interfejsów Android Sensors API, w tym obsługę grupowania próbek z czujników w celu zmniejszenia zużycia energii. Przetwarzanie danych z czujników w CHRE umożliwia znacznie mniejsze zużycie energii i krótszy czas oczekiwania podczas przetwarzania sygnałów ruchu w porównaniu z przetwarzaniem na procesorze aplikacji.
GNSS
CHRE udostępnia interfejsy API do wysyłania żądań dotyczących danych o lokalizacji z globalnego systemu nawigacji satelitarnej (GNSS), w tym GPS i innych konstelacji satelitarnych. Obejmuje to żądania okresowych poprawek pozycji, a także surowe dane pomiarowe, choć obie te funkcje są niezależne. CHRE ma bezpośrednie połączenie z podsystemem GNSS, więc 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 cykl życia sesji lokalizacji.
Wi-Fi
CHRE umożliwia interakcję z chipem Wi-Fi, głównie na potrzeby lokalizacji. GNSS dobrze sprawdza się w przypadku lokalizacji na zewnątrz, ale wyniki skanowania Wi-Fi mogą dostarczać dokładnych informacji o lokalizacji w pomieszczeniach i na obszarach zabudowanych. Oprócz uniknięcia kosztów wybudzania procesora aplikacji na potrzeby skanowania CHRE może nasłuchiwać wyników skanowania Wi-Fi wykonywanego przez oprogramowanie sprzętowe Wi-Fi na potrzeby łączności, które zwykle nie są dostarczane do procesora aplikacji ze względu na oszczędność energii. Wykorzystywanie skanowania łączności do celów kontekstowych pomaga zmniejszyć łączną liczbę skanowań Wi-Fi, co pozwala oszczędzać energię.
Obsługa Wi-Fi została dodana w interfejsie CHRE API w wersji 1.1. Obejmuje ona możliwość monitorowania wyników skanowania i wywoływania skanowania na żądanie. W wersji 1.2 rozszerzyliśmy te możliwości o pomiar czasu RTT w przypadku punktów dostępu, które obsługują tę funkcję. Umożliwia to dokładne określanie względnej pozycji.
WWAN
Interfejs CHRE API umożliwia pobieranie informacji o identyfikatorze komórki dla komórki obsługującej i jej sąsiadów, co jest zwykle wykorzystywane do określania przybliżonej lokalizacji.
Audio
CHRE może przetwarzać partie danych audio z mikrofonu o niskim poborze mocy, który zwykle korzysta ze sprzętu używanego do implementacji interfejsu HAL SoundTrigger. Przetwarzanie danych audio w CHRE może umożliwić ich łączenie z innymi danymi, np. z czujników ruchu.
Implementacja referencyjna
Kod referencyjny platformy CHRE jest zawarty w AOSP w system/chreprojekcie i został zaimplementowany w C++11. Chociaż nie jest to bezwzględnie wymagane, zalecamy, aby wszystkie implementacje CHRE były oparte na tym kodzie, co pomoże zapewnić spójność i przyspieszyć wdrażanie nowych funkcji. Ten kod można traktować jako odpowiednik podstawowej struktury 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 dostawcy, ale zalecamy, aby wspólny kod był jak najbardziej zbliżony do kodu referencyjnego. Podobnie jak w przypadku warstw HAL w Androidzie, referencyjna implementacja CHRE korzysta z różnych abstrakcji platformy, dzięki czemu można ją dostosować do dowolnego urządzenia spełniającego minimalne wymagania.
Szczegóły techniczne i przewodnik po przenoszeniu znajdziesz w pliku README
dołączonym do projektu system/chre.