W Androidzie 10 HAL ConfigStore 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 (dotyczy to też Androida 9). Jednak ze względu na duże zużycie pamięci i trudności w użytkowaniu warstwa HAL ConfigStore została wycofana.
HAL ConfigStore pozostaje w AOSP, aby obsługiwać starsze partycje dostawców. Na urządzeniach z Androidem 10 lub nowszym surfaceflinger
najpierw odczytywane są właściwości systemu. Jeśli dla elementu konfiguracji w pliku `SurfaceFlingerProperties.sysprop` nie zdefiniowano żadnej właściwości systemu, usługa `surfaceflinger` wraca do interfejsu HAL ConfigStore.
Android 8.0 dzieli monolityczny system operacyjny Android na partycje ogólne (system.img) i zależne od sprzętu (vendor.img i odm.img). W wyniku tej zmiany kompilacja warunkowa musi zostać usunięta z modułów zainstalowanych na partycji systemowej, a takie moduły muszą określać konfigurację systemu w czasie działania (i zachowywać się inaczej w zależności od tej konfiguracji).
Warstwa HAL ConfigStore udostępnia zestaw interfejsów API do uzyskiwania dostępu do elementów konfiguracji tylko do odczytu, które służą do konfigurowania platformy Android. Na tej stronie opisujemy projekt HAL ConfigStore (i wyjaśniamy, dlaczego w tym celu nie użyto właściwości systemu); na innych stronach w tej sekcji szczegółowo omawiamy interfejs HAL, implementację usługi i użycie po stronie klienta, używając jako przykładu surfaceflinger. Więcej informacji 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 wykryliśmy kilka podstawowych problemów, m.in.:
- Ograniczenia długości wartości. Właściwości systemowe mają ścisłe ograniczenia dotyczące długości wartości (92 bajty). Ponadto te limity są bezpośrednio udostępniane aplikacjom na Androida jako makra C, więc zwiększenie długości może powodować problemy ze zgodnością wsteczną.
- Brak obsługi typów. Wszystkie wartości są w zasadzie ciągami tekstowymi, a interfejsy API po prostu analizują ciąg tekstowy i przekształcają go w wartość
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ć kodowany jako tablica 3 ciągów znaków). - Zastąpienia. Właściwości systemu tylko do odczytu są implementowane jako właściwości, które można zapisać tylko raz, dlatego dostawcy/producenci OEM, którzy chcą zastąpić zdefiniowane w AOSP wartości tylko do odczytu, muszą zaimportować własne wartości tylko do odczytu przed wartościami zdefiniowanymi w AOSP. W konsekwencji wartości zdefiniowane przez dostawcę, które można ponownie zapisywać, są zastępowane wartościami zdefiniowanymi przez AOSP.
- Wymagania dotyczące przestrzeni adresowej. Właściwości systemowe zajmują stosunkowo dużą przestrzeń adresową w każdym procesie. Właściwości systemu są grupowane w
prop_areajednostki o stałym rozmiarze 128 KB, z których wszystkie są przydzielane do przestrzeni adresowej procesu, nawet jeśli dostępna jest tylko jedna właściwość systemu. Może to powodować problemy na urządzeniach 32-bitowych, na których przestrzeń adresowa jest cenna.
Próbowaliśmy przezwyciężyć te ograniczenia bez utraty zgodności, ale nadal martwiliśmy się, że właściwości systemu nie zostały zaprojektowane do obsługi dostępu do elementów konfiguracji tylko do odczytu. Ostatecznie doszliśmy do wniosku, że właściwości systemu lepiej nadają się do udostępniania w czasie rzeczywistym kilku dynamicznie aktualizowanych elementów we wszystkich wersjach Androida, a także że istnieje potrzeba stworzenia nowego systemu przeznaczonego do uzyskiwania dostępu do elementów konfiguracji tylko do odczytu.
Projekt HAL ConfigStore
Podstawowa konstrukcja jest prosta:
Rysunek 1. Projekt HAL ConfigStore
- Opisz flagi kompilacji (obecnie używane do warunkowej kompilacji frameworka) w HIDL.
- Dostawcy i producenci OEM udostępniają wartości flag kompilacji specyficzne dla układu SOC i urządzenia, implementując usługę HAL.
- Zmodyfikuj platformę, aby korzystała z usługi HAL do znajdowania wartości elementu konfiguracji w czasie działania.
Elementy konfiguracji, do których obecnie odwołuje się platforma, są zawarte w wersjonowanym pakiecie HIDL (android.hardware.configstore@1.0). Dostawcy/producenci OEM podają wartości elementów konfiguracji, implementując interfejsy w tym pakiecie, a platforma używa tych interfejsów, gdy potrzebuje wartości elementu konfiguracji.
Bezpieczeństwo
Flagi kompilacji zdefiniowane w tym samym interfejsie podlegają tym samym zasadom SELinux. Jeśli co najmniej 1 flaga kompilacji powinna mieć inne zasady SELinux, musi być oddzielona od pozostałych w innym interfejsie. Może to wymagać poważnej zmiany android.hardware.configstore package, ponieważ rozdzielone interfejsy nie są już zgodne wstecznie.