Środowisko wykonawcze centrum kontekstu (CHRE)

Smartfony są wyposażone w kilka procesorów, z których każdy jest zoptymalizowany pod kątem wydajności. różne zadania. Jednak Android działa tylko na jednym procesorze: aplikacje procesorem (AP). AP jest skonfigurowany pod kątem wysokiej wydajności przy włączonym ekranie takich jak granie w gry, ale zużywają zbyt dużo energii, aby obsługiwać funkcje, wymagają częstych, krótkich przerw w przetwarzaniu przez cały czas, nawet jeśli ekran jest wyłączony. Mniejsze procesory radzą sobie lepiej z tymi zadaniami, wykonywanie zadań bez zauważalnego wpływu na żywotność baterii. Jednak w procesorach o małej mocy środowiska oprogramowania są bardziej ograniczone mogą się znacznie różnić, co utrudnia programowanie na wielu platformach.

Środowisko wykonawcze centrum kontekstu (CHRE) udostępnia wspólną platformę do uruchamiania na procesorze o niskiej mocy, a także prosty, ustandaryzowany i łatwo dostępny. CHRE ułatwia producentom urządzeń OEM i ich zaufanym odciążanie przetwarzania danych od punktu dostępu, aby oszczędzać baterię i ulepszać obszarów wygody użytkowników, i udostępnić klasę zawsze włączonych, kontekstowo znane funkcje, w szczególności te związane z zastosowaniem z systemami uczącymi się na wykrywanie otoczenia.

Kluczowych pojęć

CHRE to środowisko programistyczne, w którym małe aplikacje natywne nanoapps, są wykonywane na procesorze o małej mocy i wchodzą w interakcję z za pomocą wspólnego interfejsu API CHRE. Aby przyspieszyć prawidłowe wdrożenie CHRE API, referencyjna implementacja CHRE na wielu platformach jest uwzględniona w AOSP. Implementacja referencyjna zawiera wspólny kod i abstrakcje dotyczące na bazowym sprzęcie i oprogramowaniu przez szereg warstw abstrakcji platformy (PAL). Nanoaplikacje są prawie zawsze powiązane z co najmniej jedną aplikacją kliencką Android, który współdziała z CHRE i nanoaplikacjami w ramach ograniczonego dostępu ContextHubManager. i systemowych interfejsów API.

Ogólnie można połączyć architekturę CHRE i architektury równoległej z Androidem jako całością. Istnieje jednak kilka ważnych różnic:

  • CHRE obsługuje tylko nanoaplikacje stworzone w kodzie natywnym (C lub C++); Język Java nie jest obsługiwany.
  • Ze względu na ograniczenia zasobów i zabezpieczeń CHRE jest niedostępny do użytku w dowolnych aplikacjach innych firm na Androida. Tylko aplikacje zaufane dla systemu uzyskać do niego dostęp.

Należy także wprowadzić istotne rozróżnienie między koncepcją CHRE, i centrum czujników. Powszechną praktyką jest używanie tego samego sprzętu do implementacji centrum czujników i CHRE, sam CHRE nie zapewnia funkcji czujników wymagane przez czujniki Androida HAL. CHRE jest powiązany z interfejsu HAL centrum kontekstu i działa jako klient czujnika urządzenia, jako platformę do odbierania danych z czujników bez angażowania punktu dostępu.

Architektura platformy CHRE

Rysunek 1. Architektura platformy CHRE

HAL centrum kontekstu

Warstwa abstrakcji sprzętowej centrum kontekstu (HAL) to interfejs między platformy Androida i implementacji CHRE na urządzeniu, zdefiniowane na stronie hardware/interfaces/contexthub HAL centrum kontekstu definiuje interfejsy API, za których pomocą platforma Androida wykrywa dostępne centra kontekstu i ich nanoaplikacje, nanoaplikacje dzięki przekazywaniu wiadomości, a także ładowanie nanoaplikacji wyładowano z pamięci. Referencyjna implementacja interfejsu HAL centrum kontekstu, która działa z referencyjna implementacja CHRE jest dostępna na stronie system/chre/host

W przypadku rozbieżności między tą dokumentacją a definicją HAL, Definicja HAL ma pierwszeństwo.

Inicjalizacja

Po uruchomieniu Androida ContextHubService, wywołuje funkcję HAL getHubs(), aby określić, czy któreś centrum kontekstu dostępnych na urządzeniu. Jest to jednorazowe połączenie blokujące, więc musi zostać zakończone. aby uniknąć opóźnień w uruchamianiu i zwracać dokładny wynik centrów kontekstu nie można później wprowadzać.

Wczytywanie i usuwanie nanoaplikacji

Centrum kontekstu może zawierać zestaw nanoaplikacji zawartych w urządzeniu i są ładowane po uruchomieniu CHRE. Są to tzw. wstępnie wczytane nanoaplikacje, i należy go uwzględnić w pierwszej możliwej odpowiedzi na zapytanie queryApps().

Interfejs HAL centrum kontekstu obsługuje również dynamiczne wczytywanie i usuwanie nanoaplikacji w czasie działania aplikacji za pomocą funkcji loadNanoApp() i unloadNanoApp(). Nanoaplikacje są przekazywane do HAL w formacie binarnym specyficznym dla sprzętu CHRE. po wdrożeniu oprogramowania urządzenia.

Jeśli implementacja wczytywania nanoaplikacji wymaga zapisu w niezmiennej np. pamięci flash podłączonej do procesora, który obsługuje CHRE, Implementacja CHRE musi się zawsze uruchamiać w tych dynamicznych nanoaplikacjach wyłączone. Oznacza to, że żaden kod nanoaplikacji nie jest wykonywany do momentu Żądanie enableNanoapp() zostało odebrane przez HAL. Wstępnie wczytane nanoaplikacje mogą jest zainicjowany w stanie włączenia.

Ponowne uruchomienia centrum kontekstu

Chociaż CHRE nie powinien zostać uruchomiony ponownie podczas normalnego działania, może być konieczne, aby naprawić sytuację w nieoczekiwanych warunkach, takich jak próba uzyskanie dostępu do niezmapowanego adresu pamięci. W takich sytuacjach CHRE uruchamia się ponownie niezależnie od Androida. HAL powiadamia o tym Androida za pomocą Zdarzenie RESTARTED, które może zostać wysłane dopiero po ponownym zainicjowaniu CHRE o tym, że może przyjmować nowe żądania, np. queryApps().

Omówienie systemu CHRE

CHRE charakteryzuje się architekturą opartą na zdarzeniach, w której to zdarzenie przekazywane do punktu wejścia obsługi zdarzeń nanoaplikacji. Choć platforma CHRE może być wielowątkowa, dana nanoaplikacja nigdy nie jest wykonywana przez wiele wątków. Platforma CHRE współpracuje z daną nanoaplikacją przez jeden z trzech punktów wejścia nanoaplikacji (nanoappStart(), nanoappHandleEvent() i nanoappEnd()) lub przez wywołanie zwrotne w poprzedniego wywołania interfejsu CHRE API, a nanoaplikacje współdziałają z platformą CHRE i za pomocą CHRE API. CHRE API zapewnia zestaw podstawowych a także możliwości dostępu do sygnałów kontekstowych, w tym czujników, GNSS, Wi-Fi, WWAN i audio. Można ją rozszerzyć za pomocą dodatkowych rozwiązania konkretnego dostawcy do wykorzystania przez nanoaplikacje konkretnego dostawcy.

System kompilacji

Interfejs Context Hub HAL i inne niezbędne komponenty po stronie AP są tworzone oprócz Androida kod działający w CHRE może podlegać wymaganiom, niezgodne z systemem kompilacji Androida. Na przykład wymaga z łańcuchem narzędzi. Dlatego projekt CHRE w AOSP zapewnia uproszczoną kompilację, oparty na platformie GNU Make do kompilowania nanoaplikacji oraz opcjonalnie CHRE do bibliotek, które można zintegrować z systemem. Urządzenie producenci dodający obsługę CHRE powinni zintegrować obsługę systemu kompilacji urządzeń docelowych na AOSP.

Interfejs CHRE API jest napisany zgodnie ze standardem języka C99, a plik referencyjny implementacja korzysta z ograniczonego podzbioru języka C++11, odpowiedniego dla ograniczonych zasobów aplikacji.

Interfejs API CHRE

Interfejs CHRE API to zbiór plików nagłówka C, które definiują oprogramowanie między nanoappiem a systemem. Służy do tworzenia nanoaplikacji kompatybilny na wszystkich urządzeniach obsługujących CHRE, co oznacza, że kodu źródłowego nanoaplikacji nie trzeba modyfikować pod kątem obsługi nowego urządzenia ale może wymagać ponownej skompilowania specjalnie pod kątem zbiór instrukcji dla procesora lub interfejsu binarnego aplikacji (ABI). CHRE architektura i projekt interfejsów API zapewniają również zgodność nanoaplikacji z plikami binarnymi w różnych wersjach CHRE API, co oznacza, że nanoaplikacja muszą zostać skompilowane ponownie, aby działać w systemie, który implementuje inną wersję CHRE API w porównaniu z docelowym interfejsem API, pod kątem którego kompilowana jest nanoaplikacja. Inaczej mówiąc, jeśli plik binarny nanoaplikacji działa na urządzeniu, które obsługuje interfejs CHRE API wersji 1.3 i urządzenia zostaną zaktualizowane, aby obsługiwały CHRE API v1.4, tę samą aplikację nanoapp kod binarny nie przestanie działać. Nanoapp może również działać w interfejsie CHRE API v1.2, i może określić w czasie działania, czy wymaga on funkcji z interfejsu API w wersji 1.3 czy może działać bezproblemowo, pogorszenie działania funkcji.

Oprócz Androida udostępniane są nowe wersje CHRE API, ale jako CHRE jest częścią wdrożenia przez dostawców, wersja interfejsu CHRE API obsługiwana na urządzeniu nie musi być powiązana z Wersja Androida.

Podsumowanie wersji

Podobne do Schemat wersji Androida HIDL, interfejs CHRE API jest zgodny z semantyczną obsługą wersji. Wersja główna wskazuje zgodność plików binarnych, a wersja podrzędna to zwiększa się po wprowadzeniu funkcji zgodnych wstecznie. CHRE API zawiera adnotacje do kodu źródłowego wskazujące, w której wersji wprowadzono funkcję lub parametr, np. @since v1.1.

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

Wersja 1.0 (Android 7)

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

Wersja 1.1 (Android 8)

Udostępnia funkcje lokalizacyjne dzięki lokalizacjom GNSS i nieprzetworzonym pomiarom. Skanowanie Wi-Fi, informacje o sieci komórkowej oraz ogólne zawężenia do komunikacji między aplikacjami nanoapp-nanoapp oraz inne ulepszenia.

Wersja 1.2 (Android 9)

Dodano obsługę danych z mikrofonu o małej mocy, zakresu RTT Wi-Fi i punktu dostępowego. powiadomienia o wybudzeniu i uśpieniu oraz inne ulepszenia.

Wersja 1.3 (Android 10)

Ulepszone możliwości związane z danymi kalibracyjnymi czujnika oraz obsługę usuwanie grup danych z czujnika na żądanie, określa typ czujnika wykrywania krokowego oraz rozszerza zdarzenia lokalizacji GNSS o dodatkowe pola dokładności.

Wersja 1.4 (Android 11)

Dodaje obsługę informacji o komórce 5G, zrzutu debugowania nanoaplikacji i innych wiele ulepszeń.

Obowiązkowe funkcje systemowe

Źródła sygnałów kontekstowych, takie jak czujniki, są podzielone na opcjonalne obszarów cech, w ramach CHRE wymaganych jest kilka podstawowych funkcji, implementacji. Obejmuje to podstawowe interfejsy API systemu, np. do konfigurowania liczniki czasu, wysyłanie i odbieranie wiadomości do klientów w procesorze aplikacji, rejestrowanie danych i inne. Szczegółowe informacje znajdziesz tutaj: Nagłówki interfejsu API.

Oprócz podstawowych funkcji systemu skodowanych w interfejsie CHRE API dostępne są także Wymagane funkcje CHRE na poziomie systemu określone na poziomie HAL centrum kontekstu. najważniejszą z nich jest możliwość dynamicznego wczytywania i wyładowywania nanoaplikacje.

Biblioteka standardowa w C/C++

Aby zminimalizować wykorzystanie pamięci i złożoność systemu, implementacje CHRE są wymagane do obsługi tylko części standardowych bibliotek C i C++ oraz funkcje językowe, które wymagają obsługi środowiska wykonawczego. Stosując się do tych zasad, funkcje są wyraźnie wykluczone ze względu na ich pamięć i rozbudowany poziom systemu operacyjnego i inne, ponieważ są one zastąpione przez bardziej odpowiednie Interfejsy API specyficzne dla CHRE. Nie jest to wyczerpująca lista, ale: funkcji nie są przeznaczone do udostępniania nanoaplikacji:

  • Wyjątki dotyczące C++ i informacje o typie środowiska wykonawczego (RTTI)
  • Obsługa wielowątkowości w bibliotece standardowej, w tym nagłówków C++11 <thread>, <mutex>, <atomic>, <future>
  • Standardowe biblioteki wejściowe/wyjściowe w C i C++
  • Biblioteka szablonów C++ (STL)
  • Biblioteka standardowych wyrażeń regularnych w C++
  • Dynamiczna alokacja pamięci za pomocą funkcji standardowych (np. malloc, calloc, realloc, free, operator new) i inne standardowe funkcje biblioteki, które z natury korzystają z alokacji dynamicznej, np. std::unique_ptr
  • Lokalizacja i obsługa znaków Unicode
  • Biblioteki daty i godziny
  • Funkcje, które modyfikują normalny przebieg programu, w tym <setjmp.h>, <signal.h>, abort, std::terminate
  • Uzyskiwanie dostępu do środowiska hosta, w tym system, getenv
  • POSIX i inne biblioteki nieuwzględnione w języku C99 lub C++11. standardowa

W wielu przypadkach funkcje interfejsu CHRE API zawierają równoważne możliwości i biblioteki narzędziowe. Przykład: chreLog może być używany do logowania debugowania kierowanych na system dzienników Androida, gdzie bardziej tradycyjny program może użyj właściwości printf lub std::cout.

Wymagane są natomiast pewne standardowe funkcje biblioteki. Zależy to tylko wdrożenie platformy i udostępnianie ich za pomocą bibliotek statycznych w plikach binarnych nanoaplikacji lub przez dynamiczne łączenie danych nanoaplikacji z systemem. Ten obejmuje 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 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 hiperboliczne: sinf, cosf, tanf, asinf, acosf, atan2f, tanhf

Niektóre bazowe platformy obsługują dodatkowe możliwości, ale aplikacja nanoapp nie jest uważana za przenośną w różnych implementacjach CHRE, chyba że ogranicza zależności zewnętrzne od funkcji interfejsu CHRE API i zatwierdzonej biblioteki standardowej funkcji.

Funkcje opcjonalne

Aby promować sprzęt i oprogramowanie, interfejs CHRE API jest podzielony na obszary funkcji: które z perspektywy interfejsu API są uznawane za opcjonalne. Funkcje dostępne w ramach tej funkcji mogą nie być wymagane do obsługi zgodnej implementacji CHRE, mogą wymaganych do obsługi konkretnej aplikacji nanoapp. Nawet jeśli platforma nie obsługuje wybranego zestawu interfejsów API nanoaplikacje, które odwołują się do tych funkcji, muszą mieć możliwość i wczytywać.

Czujniki

CHRE API umożliwia żądanie danych z czujników, w tym akcelerometr, żyroskop, magnetometr, czujnik jasności otoczenia i zbliżeniowy. Te interfejsy API mają zapewniać zestaw funkcji podobny do czujników Android interfejsów API, w tym obsługi grupowania próbek z czujników w celu zmniejszania zużycia energii. Przetwarzanie danych z czujników w CHRE pozwala znacznie zmniejszyć moc i opóźnienia przetwarzania sygnałów ruchu w porównaniu z obsługą punktu dostępu.

GNSS

CHRE udostępnia interfejsy API do przesyłania żądań danych o lokalizacji z globalnej nawigacji systemu satelitarnego (GNSS), w tym GPS-a i innych konstelacji satelitarnych. Ten obejmuje żądania okresowej korekty pozycji oraz nieprzetworzone dane pomiarowe, jednak są to niezależne funkcje. CHRE ma bezpośredni link do GNSS moc obliczeniowa jest mniejsza w porównaniu z żądaniami GNSS opartymi na interfejsie AP, ponieważ mogą pozostać uśpione przez cały cykl życia sesji lokalizacji.

Wi-Fi

CHRE umożliwia interakcję z układem Wi-Fi, głównie w celach związanych z lokalizacją. Chociaż GNSS sprawdza się w przypadku lokalizacji na zewnątrz, wyniki Skanowanie Wi-Fi może zapewnić dokładne informacje o lokalizacji wewnątrz i w obrębie budynków nowe obszary. Oprócz uniknięcia kosztów wybudzania punktu dostępowego na potrzeby skanowania CHRE nasłuchuj wyników skanowania Wi-Fi przeprowadzonego przez Wi-Fi oprogramowanie układowe na potrzeby łączności, które zwykle nie jest dostarczane do punktu dostępu; z powodów związanych z zasilaniem. Wykorzystanie skanowań połączeń do celów kontekstowych pomaga aby zmniejszyć łączną liczbę skanowań Wi-Fi, co pozwala oszczędzać energię.

Dodaliśmy obsługę sieci Wi-Fi w interfejsie CHRE API w wersji 1.1, w tym możliwość monitorowania wyniki skanowania i aktywuje skanowanie na żądanie. Możliwości te zostały rozszerzone w v1.2, zapewniając możliwość wykonywania Czas w obie strony (RTT) wyniki z punktami dostępu, które obsługują tę funkcję, co umożliwia dokładne określanie pozycji względnej.

sieć WWAN,

Interfejs CHRE API umożliwia pobieranie informacji identyfikacyjnych komórek dla komórki obsługującej i jej sąsiadów, co zwykle jest używane w celu uzyskania dokładnej lokalizacji.

Dźwięk

CHRE może przetwarzać partie danych dźwiękowych z mikrofonu o małej mocy, zwykle korzysta ze sprzętu używanego do implementacji HAL SoundTrigger HAL. Przetwarzam dane dźwiękowe w CHRE mogą zostać połączone z innymi danymi, takimi jak dane o ruchu i czujników.

Implementacja referencyjna

Kod referencyjny platformy CHRE jest zawarty w AOSP w system/chre wdrożony w C++11. Chociaż nie jest to ścisłe wymagane, zalecane w przypadku wszystkie implementacje CHRE oparte na tej bazie kodu, i przyspieszyć wdrażanie nowych funkcji. Ten kod jest widoczny jako analogię do podstawowej platformy Androida, bo jest to oprogramowanie typu open source, wdrożenia interfejsów API używanych przez aplikacje i służą jako podstawowe i standardowe rozwiązanie, pod kątem zgodności. Można ją dostosowywać i rozszerzać za pomocą rozwiązań specyficznych dla danego dostawcy. zalecamy pozostawienie wspólnego kodu jak najbliżej jak najściślej. Podobnie jak w przypadku list HAL Androida, CHRE odniesień korzysta z różnych abstrakcji platformy, aby umożliwić adaptację z każdym urządzeniem, które spełnia minimalne wymagania.

Szczegółowe informacje techniczne i przewodnik po przenoszeniu znajdziesz na stronie README dostępne w projekcie system/chre.