W 2026 r., aby dostosować się do naszego modelu stabilnego rozwoju trunk i zapewnić stabilność platformy w ekosystemie, będziemy publikować kod źródłowy w AOSP w drugim i czwartym kwartale. Do tworzenia i współtworzenia AOSP używaj gałęzi android-latest-release. Gałąź manifestu android-latest-release będzie zawsze odwoływać się do najnowszej wersji przesłanej do AOSP. Więcej informacji znajdziesz w artykule Zmiany w AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ConfigStore HAL

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 HAL ConfigStore został wycofany.

HAL ConfigStore pozostaje w AOSP, aby obsługiwać starsze partycje dostawców. Na urządzeniach z Androidem 10 lub nowszym surfaceflinger najpierw odczytuje właściwości systemu. Jeśli dla elementu konfiguracji w SurfaceFlingerProperties.sysprop nie jest zdefiniowana żadna właściwość systemu, surfaceflinger wraca do 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 z modułów zainstalowanych w partycji systemowej należy usunąć kompilację warunkową. Moduły te muszą określać konfigurację systemu w czasie działania (i zachowywać się inaczej w zależności od tej konfiguracji).

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. Ta strona opisuje projekt HAL ConfigStore (i dlaczego do tego 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, a wszystko to na przykładzie surfaceflinger. Aby uzyskać pomoc dotyczącą klas interfejsów ConfigStore, zobacz Dodawanie klas i elementów interfejsów.

Dlaczego nie używać właściwości systemu?

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

Limity długości wartości. Właściwości systemu mają ścisłe limity długości wartości (92 bajty). Ponadto, ponieważ te limity zostały bezpośrednio udostępnione aplikacjom na Androida jako makra C, zwiększenie długości może spowodować problemy ze zgodnością wsteczną.
Brak obsługi typów. Wszystkie wartości są zasadniczo ciągami znaków, a interfejsy API po prostu analizują ciąg znaków na int lub bool. Inne złożone typy danych (np. tablica i struktura) powinny być kodowane i dekodowane przez klientów (np. "aaa,bbb,ccc" można zakodować jako tablicę 3 ciągów znaków).
Nadpisywanie. Ponieważ właściwości systemu tylko do odczytu są implementowane jako właściwości jednokrotnego zapisu, dostawcy i producenci OEM, którzy chcą zastąpić wartości tylko do odczytu zdefiniowane w AOSP, muszą zaimportować własne wartości tylko do odczytu przed wartościami tylko do odczytu zdefiniowanymi w AOSP. Powoduje to, że wartości do zapisu zdefiniowane przez dostawcę są zastępowane wartościami zdefiniowanymi w 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 systemu są grupowane w jednostki prop_area 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 są przeznaczone 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 kilku dynamicznie aktualizowanych elementów w czasie rzeczywistym w całym Androidzie, i że potrzebny jest nowy system przeznaczony do uzyskiwania dostępu do elementów konfiguracji tylko do odczytu.

Projekt HAL ConfigStore

Podstawowy projekt jest prosty:

Projekt Configstore HAL

Rysunek 1. Projekt HAL ConfigStore

Opisz flagi kompilacji (używane do kompilacji warunkowej platformy) w HIDL.
Dostawcy i producenci OEM udostępniają wartości flag kompilacji specyficzne dla SoC i urządzenia, implementując usługę HAL.
Zmodyfikuj platformę, aby używała usługi HAL do znajdowania wartości elementu konfiguracji w czasie działania.

Elementy konfiguracji, do których odwołuje się platforma, są zawarte w pakiecie HIDL z numerem wersji (android.hardware.configstore@1.0). Dostawcy i producenci OEM udostępniają wartości elementów konfiguracji, implementując interfejsy w tym pakiecie, a platforma używa tych interfejsów, gdy potrzebuje uzyskać wartość elementu konfiguracji.

Względy bezpieczeństwa

Flagi kompilacji zdefiniowane w tym samym interfejsie podlegają tej samej zasadzie SELinux. Jeśli co najmniej 1 flaga kompilacji ma mieć inne zasady SELinux, należy ją oddzielić do innego interfejsu. Może to wymagać poważnej zmiany android.hardware.configstore package, ponieważ oddzielone interfejsy nie są już zgodne wstecz.