W Androidzie 10 interfejs ConfigStore HAL używa flag kompilacji do przechowywania wartości konfiguracji w partycji vendor, a usługa w partycji system uzyskuje dostęp do tych wartości za pomocą HIDL (tak samo jest w Androidzie 9). Jednak ze względu na duże zużycie pamięci i trudność obsługi interfejsu ConfigStore HAL został wycofany.
Interfejs HAL ConfigStore pozostaje w AOSP, aby obsługiwać starsze partycje dostawców. Na urządzeniach z Androidem 10 lub nowszym surfaceflingernajpierw odczytuje właściwości systemu. Jeśli dla elementu konfiguracji w pliku SurfaceFlingerProperties.sysprop nie jest zdefiniowana żadna właściwość systemu, surfaceflinger korzysta z interfejsu ConfigStore HAL.
Android 8.0 dzieli monolityczny system operacyjny Android na partycje ogólne (system.img) i specyficzne dla sprzętu (vendor.img i odm.img). W związku z tą zmianą należy usunąć kompilację warunkową z modułów zainstalowanych na partycji systemowej, a moduły te muszą określać konfigurację systemu w czasie działania (i działać inaczej w zależności od konfiguracji).
Interfejs ConfigStore HAL udostępnia zestaw interfejsów API umożliwiających dostęp do elementów konfiguracji tylko do odczytu, które służą do konfigurowania platformy Android. Ta strona opisuje projekt interfejsu ConfigStore HAL (oraz dlaczego właściwości systemowe nie były używane do tego celu). Na innych stronach w tej sekcji znajdziesz szczegółowe informacje o interfejsie HAL, implementacji usługi i użyciu po stronie klienta, przy czym wszystkie przykłady odnoszą się do surfaceflinger. Informacje o klasach interfejsu ConfigStore znajdziesz w artykule Dodawanie klas i elementów interfejsu.
Dlaczego nie używać właściwości systemowych?
Rozważaliśmy użycie właściwości systemowych, ale napotkaliśmy kilka podstawowych problemów, takich jak:
- Limity długości wartości. Właściwości systemowe mają ścisłe limity długości wartości (92 bajty). Ponadto te limity zostały bezpośrednio udostępnione aplikacjom na Androida jako makra C, więc zwiększenie długości może spowodować problemy ze zgodnością wsteczną.
- Brak obsługi typu. Wszystkie wartości są zasadniczo ciągami tekstowymi, a interfejsy API po prostu analizują ciąg znaków jako
intlubbool. Inne złożone typy danych (np. tablice i struktury) powinny być kodowane/dekodowane przez klientów (np."aaa,bbb,ccc"może być zakodowany jako tablica 3 ciągów znaków). - Zastępowanie Właściwości systemowe tylko do odczytu są implementowane jako właściwości tylko do odczytu, dlatego dostawcy/ODM, którzy chcą zastąpić wartości tylko do odczytu zdefiniowane przez AOSP, muszą najpierw zaimportować własne wartości tylko do odczytu. W konsekwencji wartości zdefiniowane przez dostawcę, które można zapisać, są zastępowane wartościami zdefiniowanymi przez AOSP.
- Wymagania dotyczące przestrzeni adresowej. Właściwości systemu zajmują stosunkowo dużo miejsca w przestrzeni adresowej w każdym procesie. Właściwości systemowe są grupowane w jednostki
prop_areao stałym rozmiarze 128 KB, z których wszystkie są przypisywane do przestrzeni adresowej procesu, nawet jeśli dostęp jest uzyskiwany tylko do jednej właściwości systemowej. Może to powodować problemy na urządzeniach 32-bitowych, gdzie przestrzeń adresowa jest ważna.
Próbowaliśmy przezwyciężyć te ograniczenia bez poświęcania zgodności, ale nadal obawialiśmy się, że właściwości systemu nie obsługują elementów konfiguracji tylko do odczytu. Ostatecznie stwierdziliśmy, że usługi systemowe lepiej nadają się do udostępniania w czasie rzeczywistym kilku dynamicznie aktualizowanych elementów na różnych urządzeniach z Androidem oraz że istnieje potrzeba nowego systemu zapewniającego dostęp do elementów konfiguracji w trybie tylko do odczytu.
Projektowanie interfejsu HAL ConfigStore
Podstawowy projekt jest prosty:
Rysunek 1. Projekt HAL ConfigStore
- Opisz flagi kompilacji (obecnie używane do warunkowego kompilowania frameworka) w HIDL.
- Dostawcy i producenci OEM udostępniają wartości flag kompilacji dla SoC i urządzeń, implementując usługę HAL.
- Zmodyfikuj platformę tak, aby używała usługi HAL, aby znajdować wartość elementu konfiguracji w czasie działania.
Elementy konfiguracji, do których framework obecnie się odwołuje, są zawarte w pakiecie HIDL z wersją (android.hardware.configstore@1.0). Dostawcy/OEM-y podają wartości elementów konfiguracji, implementując interfejsy w tym pakiecie, a framework używa tych interfejsów, gdy potrzebuje wartości elementu konfiguracji.
Zagadnienia związane z bezpieczeństwem
Flagi kompilacji zdefiniowane w tym samym interfejsie podlegają tym samym zasadom SELinux. Jeśli co najmniej 1 flaga kompilacji ma mieć inne zasady SELinux, należy je rozdzielić na inny interfejs. Może to wymagać gruntownej zmiany android.hardware.configstore package, ponieważ oddzielone interfejsy nie są już zgodne wstecz.