ConfigStore HAL

W systemie Android 10 ConfigStore HAL używa flag kompilacji do przechowywania wartości konfiguracyjnych na partycji vendor , a usługa w partycji system uzyskuje dostęp do tych wartości za pomocą języka HIDL (jest to również prawdą w systemie Android 9). Jednak ze względu na duże zużycie pamięci i trudne użytkowanie warstwa HAL ConfigStore stała się przestarzała.

ConfigStore HAL pozostaje w AOSP, aby obsługiwać starsze partycje dostawców. Na urządzeniach z systemem Android 10 lub nowszym surfaceflinger najpierw odczytuje właściwości systemu; jeśli dla elementu konfiguracji w `SurfaceFlingerProperties.sysprop` nie zdefiniowano żadnej właściwości systemowej, `surfaceflinger` powraca do warstwy 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 należy usunąć kompilację warunkową z modułów zainstalowanych na partycji systemowej, a moduły te muszą określać konfigurację systemu w czasie wykonywania (i zachowywać się inaczej w zależności od tej konfiguracji).

ConfigStore HAL udostępnia zestaw interfejsów API umożliwiających dostęp do elementów konfiguracji tylko do odczytu używanych do konfigurowania platformy Android. Na tej stronie opisano projekt ConfigStore HAL (i dlaczego właściwości systemu nie zostały użyte w tym celu); inne strony w tej sekcji szczegółowo opisują interfejs HAL , implementację usług i użycie po stronie klienta , a wszystko to na przykładzie surfaceflinger . Aby uzyskać pomoc dotyczącą klas interfejsu ConfigStore, zobacz Dodawanie klas i elementów interfejsu .

Dlaczego nie skorzystać z właściwości systemu?

Rozważaliśmy użycie właściwości systemu, ale znaleźliśmy kilka podstawowych problemów, w tym:

  • Ograniczenia długości wartości. Właściwości systemu mają ścisłe ograniczenia długości wartości (92 bajty). Ponadto, ponieważ te ograniczenia zostały bezpośrednio udostępnione aplikacjom na Androida jako makra C, zwiększenie długości może powodować problemy ze zgodnością wsteczną.
  • Brak obsługi typu. Wszystkie wartości są zasadniczo ciągami znaków, a interfejsy API po prostu analizują ciąg znaków w postaci int lub bool . Inne złożone typy danych (na przykład tablica i struktura) powinny być kodowane/dekodowane przez klientów (na przykład "aaa,bbb,ccc" może być kodowane jako tablica trzech ciągów).
  • Zastępuje. Ponieważ właściwości systemowe tylko do odczytu są zaimplementowane jako właściwości jednorazowego zapisu, dostawcy/dostawcy ODM, którzy chcą zastąpić wartości tylko do odczytu zdefiniowane przez AOSP, muszą zaimportować własne wartości tylko do odczytu przed wartościami tylko do odczytu zdefiniowanymi przez AOSP. To z kolei powoduje, że zdefiniowane przez dostawcę wartości wielokrotnego zapisu są zastępowane przez wartości zdefiniowane przez AOSP.
  • Wymagania dotyczące przestrzeni adresowej. Właściwości systemu zajmują stosunkowo dużą ilość przestrzeni adresowej w każdym procesie. Właściwości systemowe są pogrupowane w jednostki prop_area o stałym rozmiarze 128 KB, z których wszystkie są przydzielane do przestrzeni adresowej procesu, nawet jeśli uzyskiwany jest dostęp tylko do jednej znajdującej się w niej właściwości systemowej. Może to powodować problemy na urządzeniach 32-bitowych, gdzie przestrzeń adresowa jest cenna.

Próbowaliśmy pokonać te ograniczenia bez poświęcania kompatybilności, ale nadal obawialiśmy się, że właściwości systemu nie zostały zaprojektowane tak, aby umożliwiały dostęp do elementów konfiguracyjnych tylko do odczytu. Ostatecznie zdecydowaliśmy, że właściwości systemu lepiej nadają się do udostępniania kilku dynamicznie aktualizowanych elementów w całym systemie Android w czasie rzeczywistym i że istnieje zapotrzebowanie na nowy system zapewniający dostęp do elementów konfiguracyjnych tylko do odczytu.

Projekt ConfigStore HAL

Podstawowy projekt jest prosty:

Projekt Configstore HAL

Rysunek 1. Projekt ConfigStore HAL

  • Opisz flagi kompilacji (obecnie używane do warunkowej kompilacji frameworka) w HIDL.
  • Dostawcy i producenci OEM udostępniają flagi kompilacji SoC i wartości specyficzne dla urządzenia, wdrażając usługę HAL.
  • Zmodyfikuj strukturę, aby używać usługi HAL do znajdowania wartości elementu konfiguracji w czasie wykonywania.

Elementy konfiguracji, do których aktualnie odwołuje się platforma, są zawarte w wersjonowanym pakiecie HIDL ( android.hardware.configstore@1.0 ). Dostawcy/producenci OEM dostarczają wartości elementom konfiguracji, implementując interfejsy w tym pakiecie, a platforma używa interfejsów, gdy musi uzyskać wartość elementu konfiguracji.

Względy bezpieczeństwa

Na flagi kompilacji zdefiniowane w tym samym interfejsie mają wpływ te same zasady SELinux. Jeśli jedna lub więcej flag kompilacji powinno mieć różne zasady SELinux, należy je oddzielić do innego interfejsu . Może to wymagać poważnej rewizji android.hardware.configstore package , ponieważ oddzielne interfejsy nie są już kompatybilne wstecz.