ConfigStore HAL

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W systemie Android 10 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 przy użyciu HIDL (jest to również prawdą w systemie Android 9). Jednak ze względu na duże zużycie pamięci i trudności w użyciu, warstwa HAL ConfigStore została przestarzała.

ConfigStore HAL pozostaje w AOSP, aby obsługiwać partycje starszych dostawców. Na urządzeniach z Androidem 10 lub nowszym surfaceflinger najpierw odczytuje właściwości systemu; jeśli żadna właściwość systemowa nie jest zdefiniowana dla elementu konfiguracji w `SurfaceFlingerProperties.sysprop`, `surfaceflinger` powraca do warstwy HAL ConfigStore.

System Android 8.0 dzieli monolityczny system operacyjny Android na partycje ogólne ( system.img ) i partycje 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 i takie moduły 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 do uzyskiwania dostępu do elementów konfiguracji tylko do odczytu używanych do konfigurowania platformy Android. Na tej stronie opisano projekt warstwy HAL ConfigStore (i dlaczego nie użyto w tym celu właściwości systemu); inne strony w tej sekcji szczegółowo opisują interfejs HAL , implementację usługi i użycie po stronie klienta , wszystkie na przykładzie surfaceflinger . Aby uzyskać pomoc dotyczącą klas interfejsu ConfigStore, zobacz Dodawanie klas interfejsu i elementów .

Dlaczego nie korzystać 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:

  • Limity długości wartości. Właściwości systemu mają ścisłe limity długości swoich wartości (92 bajty). Ponadto, ponieważ ograniczenia te zostały bezpośrednio ujawnione aplikacjom na Androida jako makra w języku C, zwiększenie długości może powodować problemy ze zgodnością wsteczną.
  • Brak obsługi typów. Wszystkie wartości są zasadniczo ciągami, a interfejsy API po prostu analizują ciąg w 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ć zakodowana jako tablica trzech ciągów).
  • Zastępuje. Ponieważ właściwości systemowe tylko do odczytu są implementowane jako właściwości jednorazowego zapisu, 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 wartości wielokrotnego zapisu zdefiniowane przez dostawcę są zastępowane przez wartości zdefiniowane przez AOSP.
  • Uwzględnij wymagania dotyczące miejsca. 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 dostęp do jednej właściwości systemowej jest możliwy. Może to powodować problemy na urządzeniach 32-bitowych, gdzie przestrzeń adresowa jest cenna.

Próbowaliśmy przezwyciężyć te ograniczenia bez poświęcania kompatybilności, ale nadal obawialiś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 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 potrzeba nowego systemu przeznaczonego do uzyskiwania dostępu do elementów konfiguracji tylko do odczytu.

Projekt HAL ConfigStore

Podstawowy projekt jest prosty:

Projekt HAL Configstore

Rysunek 1. Projekt warstwy HAL ConfigStore

  • Opisz flagi kompilacji (obecnie używane do warunkowego kompilowania frameworka) w HIDL.
  • Dostawcy i producenci OEM zapewniają wartości SoC i specyficzne dla urządzenia dla flag kompilacji, implementując usługę HAL.
  • Zmodyfikuj platformę tak, aby korzystała z usługi HAL w celu znalezienia wartości elementu konfiguracji w czasie wykonywania.

Elementy konfiguracji, do których obecnie odwołuje się struktura, są zawarte w wersjonowanym pakiecie HIDL ( android.hardware.configstore@1.0 ). Dostawcy/OEM dostarczają wartości do elementów 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 wpływa ta sama polityka SELinux. Jeśli jedna lub więcej flag kompilacji ma mieć różne polityki SELinux, muszą one być oddzielone od innego interfejsu . Może to wymagać poważnej zmiany android.hardware.configstore package ponieważ oddzielne interfejsy nie są już kompatybilne wstecz.