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 specyficzne dla 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 Androida. 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 znajdziesz szczegółowe informacje o interfejsie HAL, implementacji usługi i użyciu po stronie klienta. Wszystkie te informacje są przedstawione na przykładzie surfaceflinger. Pomoc dotyczącą klas interfejsu ConfigStore znajdziesz w sekcji Dodawanie klas interfejsu i elementów.
Dlaczego nie warto używać właściwości systemowych?
Rozważaliśmy użycie właściwości systemowych, ale znaleźliś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. Ponieważ właściwości systemu tylko do odczytu są implementowane jako właściwości do zapisu jednorazowego, 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 zastąpić, są zastępowane wartościami zdefiniowanymi przez AOSP.
- Wymagania dotyczące przestrzeni adresowej. Właściwości systemu 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 pokonać te ograniczenia bez utraty zgodności, ale nadal martwiliśmy się, że właściwości systemu nie zostały zaprojektowane z myślą o dostępie do elementów konfiguracji tylko do odczytu. Ostatecznie doszliśmy do wniosku, że właściwości systemu lepiej nadają się do udostępniania kilku dynamicznie aktualizowanych elementów w czasie rzeczywistym 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.