Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

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

Wersja platformy Androida zawiera wiele tablic zgodności platformy (FCM), po jednej dla każdej docelowej wersji FCM, która może być uaktualniona. Określają one, czego może używać platforma, oraz wymagania dotyczące docelowej wersji FCM. W ramach cyklu życia FCM Android wycofuje i usuwa interfejsy HIDL HAL, a następnie modyfikuje pliki FCM, aby odzwierciedlały stan wersji interfejsu HAL.

Aby umożliwić OTA tylko dla frameworków w ich własnych środowiskach, partnerzy, którzy rozszerzają interfejsy dostawców, powinni też wycofać i usunąć interfejsy HIDL HAL, używając tych samych metod.

Terminologia

Tablica zgodności frameworków (FCM): Plik XML określający wymagania dotyczące ram dla implementacji zgodnych dostawców. Matryca zgodności jest wersjonowana, a nowa wersja jest blokowana w przypadku każdej wersji frameworka. Każda wersja frameworka zawiera wiele FCM.
Wersje platformy FCM (S_F): Zbiór wszystkich wersji FCM w ramach wersji frameworku. Platforma może działać z dowolną implementacją dostawcy, która spełnia co najmniej 1 z tych FCM.
Wersja FCM (F): Najwyższa wersja wśród wszystkich wersji FCM w ramach danej wersji frameworka.
Docelowa wersja FCM (V): Docelowa wersja FCM (z S_F), zadeklarowana wyraźnie w manifeście urządzenia, której implementacja spełnia wymagania. Implementacja dostawcy musi być wygenerowana na podstawie opublikowanego FCM, ale może deklarować nowsze wersje HAL w pliku manifestu urządzenia.
Wersja HAL: Wersja HAL ma format foo@x.y, gdzie foo to nazwa HAL, a x.y to konkretna wersja, np. nfc@1.0, keymaster@3.0 (w tym dokumencie pomijamy prefiks katalogu głównego, np. android.hardware).
Plik manifestu urządzenia: pliki XML określające wersje HAL, które interfejs dostawcy (w tym obrazy dostawcy i ODM) udostępnia po stronie urządzenia. Zawartość pliku manifestu urządzenia jest ograniczona przez docelową wersję FCM urządzenia, ale może zawierać listę interfejsów HAL, które są nowsze niż interfejs FC odpowiadający wersji V.
Interfejsy HAL urządzeń: HAL, które są wymienione (udostępnione) w pliku manifestu urządzenia i wymienione w ramach tabeli zgodności (FCM).
Tablica zgodności urządzeń (DCM): Plik XML określający wymagania dostawcy dotyczące implementacji zgodnych z ramami. Każde urządzenie zawiera 1 DCM.
Plik manifestu frameworku: Plik XML, który określa, które wersje HAL są dostępne po stronie interfejsu frameworka dostawcy, w tym system, system_ext i obrazy produktów. HAL-e w pliku manifestu frameworku są dynamicznie wyłączane zgodnie z docelową wersją FCM urządzenia.
Framework HAL: HAL, które są wymienione w manifeście frameworku i w macierz zgodności urządzeń (DCM).

Cykl życia FCM w bazie kodu

Ten dokument zawiera ogólny opis cyklu życia FCM. Obsługiwane manifesty znajdziesz w pliku hardware/interfaces/compatibility_matrix.<FCM>.xml, w którym znajduje się FCM (system/libvintf/include/vintf/Level.h).

Urządzenie z odpowiednią wersją Androida powinno mieć wartość FCM większą lub równą odpowiedniemu poziomowi. Na przykład urządzenie z Androidem 11 zwykle ma poziom FCM 5, ale implementuje FCM 6 lub nowszy, co wiąże się z różnymi dodatkowymi wymaganiami określonymi w matrycach zgodności. Obsługiwane poziomy w Androidzie 15:

FCM	Wersja Androida
5	Android 11/R
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V

Poziom FCM jest równy lub nowszy niż poziom interfejsu API dostawcy.

Gdy Android wycofa poziom FCM, nadal będzie on obsługiwany na dotychczasowych urządzeniach. Urządzenia kierujące reklamy na niższe poziomy FCM mogą domyślnie używać interfejsów HAL wymienionych na nowszych poziomach FCM, o ile są one dostępne w gałęzi.

Tworzenie aplikacji w nowej wersji FCM

Android zwiększa wersję FCM dla każdej wersji platformy (np. Android 8 i 8.1). Podczas tworzenia nowe compatibility_matrix.F.xml jest tworzone, a istniejące compatibility_matrix.f.xml (gdzie f < F) nie jest już zmieniane.

Aby rozpocząć tworzenie aplikacji w nowej wersji FCM:F

Skopiuj najnowszy plik compatibility_matrix.<F-1>.xml do pliku compatibility_matrix.F.xml.
Zmień atrybut level w pliku na F.
Dodaj odpowiednie reguły kompilacji, aby zainstalować tę tablicę zgodności na urządzeniu.

Wprowadzenie nowego HAL-a

Podczas tworzenia nowego interfejsu HAL (Wi-Fi, NFC itp.) na Androida w ramach bieżącej wersji FCM F dodaj ten interfejs do pliku compatibility_matrix.F.xml.

Na przykład Android 8.1 wprowadził cas@1.0. Urządzenia z Androidem 8.1 mogą stosować ten interfejs HAL, dlatego do pliku compatibility_matrix.F.xml (który tymczasowo podczas opracowywania tej wersji nazywał się compatibility_matrix.current.xml) dodano ten wpis:

<hal format="hidl">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Uaktualnianie interfejsu HAL (wersja podrzędna)

Wersje AIDL HAL są traktowane jako wersje podrzędne HAL. Wersje interfejsu HIDL mają wersje major.minor, np. 1.2.

Podczas tworzenia, gdy interfejs HAL AIDL zostanie uaktualniony z wersji 2 do 3 w ramach bieżącej wersji FCM F, nowa wersja zostanie dodana do wpisu interfejsu HAL w pliku compatibility_matrix.F.xml. Pole wersji w pliku HAL akceptuje zakresy takie jak 2-3.

Na przykład w Androidzie FCM F wprowadzono foo@3 jako wersję podrzędną interfejsu HAL. Starsza wersja (foo@2) jest używana na urządzeniach kierowanych na starsze rozwiązania FCM, a nowsza wersja (foo@3) może być używana na urządzeniach kierowanych na rozwiązanie FCM dla Androida (F). Wpis w starszych usługach FCM przed wersją 2 wygląda tak:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Ten wpis został skopiowany do pliku compatibility_matrix.F.xml i zmodyfikowany w celu obsługi wersji 3 w ten sposób:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Uaktualnienie interfejsu HAL (duże)

Podczas tworzenia, gdy HAL ma uaktualnienie do wersji głównej w obecnej wersji FCM F, nowa wersja główna x.0 jest dodawana do compatibility_matrix.F.xml z tymi ustawieniami:

Tylko wersja x.0, jeśli urządzenia dostarczane z wersją V = F muszą być uruchamiane z wersją x.0.
ze starszymi głównymi wersjami w tym samym tagu <hal>, jeśli urządzenia z wersją V = F mogą uruchamiać starsze główne wersje.

Na przykład wersja FCM F wprowadza foo@2.0 jako nową wersję główną interfejsu HAL 1.0 i zastępuje interfejs HAL 1.0. Starsza wersja foo@1.0 jest używana na urządzeniach kierowanych na wcześniejsze wersje FCM. Urządzenia kierujące żądania do wersji FCM F muszą udostępniać nową wersję 2.0, jeśli udostępniają interfejs HAL. W tym przykładzie poprzednie wersje FCM zawierają ten wpis:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Skopiuj ten wpis do pliku compatibility_matrix.F.xml i zmień go w ten sposób:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Ograniczenia:

Biblioteka HAL 1.0 nie jest dostępna w wersji compatibility_matrix.F.xml, więc urządzenia kierowane na wersję FCM F nie mogą udostępniać biblioteki HAL 1.0 (ponieważ jest ona wycofana).
Interfejs HAL 1.0 jest dostępny w starszych wersjach FCM, więc framework może nadal współpracować z interfejsem HAL 1.0, co zapewnia zgodność wsteczną ze starszymi urządzeniami, które korzystają ze starszych wersji FCM.

Nowe wersje FCM

Proces publikowania wersji FCM na partycji systemowej jest wykonywany wyłącznie przez Google w ramach wersji AOSP i obejmujący te kroki:

Upewnij się, że element compatibility_matrix.F.xml ma atrybut level="F".
Upewnij się, że wszystkie urządzenia są skompilowane i uruchamiane.
Zaktualizuj testy VTS, aby mieć pewność, że urządzenia korzystające z najnowszej wersji frameworka (na podstawie poziomu interfejsu API) mają ustawioną docelową wersję FCM V >= F.
Opublikuj plik w AOSP.

Na przykład testy VTS zapewniają, że urządzenia z Androidem 9 mają ustawioną docelową wersję FCM >= 3.

Dodatkowo w usługach i systemach FCM mogą też być wymienione wymagania dotyczące poszczególnych wersji platformy FCM. Wersje FCM na partycjach product i system_ext są publikowane przez właściciela tych obrazów. Numery wersji FCM na partycjach product i system_ext muszą być zgodne z numerami na partycji system. Podobnie jak w przypadku wersji FCM w partycji systemowej, w matrici zgodności w wersji FCM F w partycjach product i system_ext uwzględniono wymagania dotyczące urządzenia z docelową wersją FCM F.

Wycofanie wersji HAL

Wycofanie wersji HAL jest decyzją dewelopera (np. w przypadku interfejsów HAL AOSP decyzję podejmuje Google). Może się tak zdarzyć, gdy zostanie wydana nowsza wersja HAL (podrzędna lub główna).

wycofanie interfejsu HAL urządzenia,

Gdy w wersji F Komunikacji w chmurze Firebase (FCM) wycofany jest interfejs HAL foo@x.y, oznacza to, że żadne urządzenie z docelową wersją FCM V = F lub nowszą nie może implementować interfejsu foo w wersji x.y ani żadnej wersji starszej niż x.y. Framework nadal obsługuje przestarzałą wersję interfejsu HAL, aby umożliwić uaktualnianie urządzeń.

Gdy zostanie wydana wersja FCM F, wersja HAL foo@x.y zostanie uznana za przestarzałą, jeśli nie jest ona wyraźnie wymieniona w najnowszej wersji FCM dla docelowej wersji FCM V = F. W przypadku urządzeń uruchamianych z użyciem V = F spełniony jest jeden z tych warunków:

platforma wymaga nowszej wersji (głównej lub podrzędnej);
Platforma nie wymaga już HAL.

Na przykład w Androidzie 9 wprowadzono interfejs health@2.0 jako nową wersję interfejsu HAL 1.0. Element health@1.0 został usunięty z pliku compatibility_matrix.3.xml, ale jest obecny w plikach compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml. Dlatego health@1.0 jest uważane za przestarzałe.

wycofanie frameworka HAL,

Gdy dana platforma HAL foo@x.y została wycofana w wersji FCM F, oznacza to, że żadne urządzenie uruchamiane z docelową wersją FCM V = F lub nowszą nie może oczekiwać, że platforma będzie udostępniać foo w wersji x.y lub w wersji starszej niż x.y. Framework nadal udostępnia przestarzałą wersję HAL na potrzeby aktualizacji urządzeń.

Gdy zostanie wydana wersja FCM F, wersja HAL foo@x.y zostanie uznana za przestarzałą, jeśli manifest platformy określa wartość max-level="F - 1" dla foo@x.y. W przypadku urządzeń z V = F platforma nie udostępnia interfejsu HAL foo@x.y. Na urządzeniach z uruchomionym V = F w macierzy zgodności nie może być widocznych ramek HAL z uwzględnieniem max-level < V.

Na przykład w Androidzie 12 funkcja schedulerservice@1.0 została wycofana. Atrybut max-level ma wartość 5, czyli wersję FCM wprowadzoną w Androidzie 11. Zapoznaj się z ramówką manifestu Androida 12.

Wycofanie obsługi docelowych wersji FCM

Gdy liczba aktywnych urządzeń z ustawionymi ustawieniami docelowej wersji FCM V spadnie poniżej określonego progu, ta wersja zostanie usunięta z zestawu S_F w przyszłej wersji platformy. Aby to zrobić, wykonaj te 2 czynności:

Usunięcie compatibility_matrix.V.xml z reguł kompilacji (aby nie było instalowane w obrazach systemu) oraz usunięcie kodu, który został zaimplementowany lub który zależał od usuniętych funkcji.
usunięcie z manifestu frameworka HAL-i frameworka o wartości max-level mniejszej lub równej V oraz usunięcie kodu implementującego usunięte HAL-e frameworka,

Urządzenia z docelową wersją FCM spoza grupy S_F danej wersji frameworka nie mogą zostać zaktualizowane do tej wersji.

Usuwanie całkowicie wycofanych HAL-i

Gdy usuniesz wersję FCM, niektóre interfejsy HAL lub ich wersje nie będą już dostępne w żadnym FCM. Oznacza to, że Android nie obsługuje już tych urządzeń, nawet w przypadku aktualizacji.

Gdy interfejs HAL przestanie być obsługiwany, deweloperzy usuwają odwołania do niego z Androida, w tym z kodu klienta w ramach, implementacji domyślnej i przypadków testowych VTS.

Jeśli nie ma obsługiwanych HAL-i, które dziedziczą z usuniętego HAL-a, można usunąć definicję HAL-a, wykonując kilka dodatkowych czynności.

Usuń z kodu źródłowego definicję interfejsu HAL. Obejmuje to pliki *.aidl i moduł Android.bp aidl_interface.
Jeśli jest to HIDL, usuń HASH z hardware/interfaces/current.txt.
Jeśli jest to AIDL, usuń katalog aidl_api z zamrożonymi plikami AIDL.
Usuń interfejs z hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

Stan wersji HAL

W następnych sekcjach opisano (w kolejności chronologicznej) możliwe stany wersji HAL.

Niewydane

W przypadku interfejsów HAL urządzeń, jeśli wersja interfejsu HAL nie znajduje się w żadnej z publicznych ani zamrożonych matryc zgodności, jest uznawana za nieopublikowaną i prawdopodobnie w trakcie opracowywania. Dotyczy to wersji HAL, które są dostępne tylko w compatibility_matrix.F.xml. Przykłady:

Podczas tworzenia Androida 9 interfejs API health@2.0 był uważany za nieopublikowany i był obecny tylko w wersji compatibility_matrix.3.xml.
Interfejs HAL teleportation@1.0 nie jest uwzględniony w żadnych opublikowanych tabelach zgodności i jest też uznawany za nieopublikowany interfejs HAL.

W przypadku interfejsów HAL frameworku, jeśli wersja HAL znajduje się tylko w pliku manifestu frameworku w niepowiązanej gałęzi rozwoju, jest ona uważana za niewydaną.

Wydane i aktualne

W przypadku interfejsów HAL urządzeń, jeśli wersja HAL znajduje się w jakiejkolwiek publicznej i zamrożonej matrycy zgodności, jest ona udostępniana. Na przykład po zamrożeniu wersji 3 FCM i opublikowaniu jej w AOSP interfejs HAL health@2.0 jest uznawany za opublikowaną i aktualną wersję interfejsu HAL.

Jeśli wersja HAL znajduje się w publicznej i zamrożonej tabeli zgodności, która ma najwyższą wersję FCM, wersja HAL jest aktualna (czyli nie jest wycofana). Na przykład istniejące wersje HAL (takie jak nfc@1.0 wprowadzona w compatibility_matrix.legacy.xml), które nadal są dostępne w compatibility_matrix.3.xml, są też uznawane za wydane i obecne wersje HAL.

W przypadku interfejsów HAL dla frameworków, jeśli wersja HAL znajduje się w pliku manifestu frameworku najnowszej wydanej gałęzi bez atrybutu max-level lub (co jest nietypowe) z atrybutem max-level równym lub wyższym niż wersja FCM opublikowana w tej gałęzi, jest ona uważana za opublikowaną i bieżącą wersję interfejsu HAL. Na przykład interfejs displayservice HAL jest dostępny i aktualny w Androidzie 12 zgodnie z ramowym plikiem manifestu Androida 12.

Wydane, ale wycofane

W przypadku interfejsów HAL urządzenia wersja interfejsu HAL jest wycofywana, jeśli są spełnione wszystkie te warunki:

Został opublikowany.
Nie jest to publiczna ani zamrożona wersja zgodności z najwyższą wersją FCM.
Jest ona dostępna publicznie i zamrożona w ramach matrycy zgodności, którą system nadal obsługuje.

Przykłady:

Interfejs health@1.0 HAL jest dostępny w compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml, ale nie w compatibility_matrix.3.xml. Dlatego w Androidzie 9 jest ona wycofana.
W Androidzie 9 nastąpiła drobna aktualizacja interfejsu HAL dotyczącego zasilania, ale power@1.0 nadal jest w wersji compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml.
compatibility_matrix.3.xml zawiera power@1.0-1.

Dlatego power@1.0 jest aktualną, ale NIE przestarzałą funkcją w Androidzie 9.

W przypadku frameworków HAL, jeśli wersja HAL znajduje się w manifeście frameworku najnowszej gałęzi opublikowanej z atrybutem max-level niższej niż wersja FCM w tej gałęzi, jest to wersja HAL opublikowana, ale wycofana. Na przykład interfejs HAL schedulerservice został wydany, ale wycofany w Androidzie 12, zgodnie z pliku manifestu platformy Androida 12.

Usunięto

W przypadku interfejsów HAL urządzenia wersja interfejsu HAL jest usuwana, jeśli wszystkie te warunki są spełnione:

Ta wersja została już wcześniej opublikowana.
Nie znajduje się on w żadnej publicznej i zamrożonej matrycy zgodności obsługiwanej przez framework.

Publiczne, zamrożone, ale nieobsługiwane przez framework macierze zgodności są przechowywane w kodzie źródłowym, aby definiować zestawy wersji usuniętych interfejsów HAL. Dzięki temu można pisać testy VTS, aby mieć pewność, że usunięte interfejsy HAL nie są dostępne na nowych urządzeniach.

W przypadku HAL framework wersja HAL jest usuwana, jeśli są spełnione te warunki:

Ta wersja została już wcześniej opublikowana.
Nie znajduje się on w żadnym pliku manifestu frameworku w ramach najnowszej gałęzi.

Starsze usługi FCM

Wartość docelowej starszej wersji FCM to wartość specjalna dla wszystkich urządzeń innych niż Treble. W przypadku starszej wersji FCM (compatibility_matrix.legacy.xml) znajdziesz wymagania dotyczące tej platformy na starszych urządzeniach (czyli urządzeniach wprowadzonych na rynek przed Androidem 8.0).

Jeśli ten plik istnieje w przypadku FCM w wersji F, każde urządzenie inne niż z Treble można uaktualnić do wersji F, o ile plik manifestu urządzenia jest z nim zgodny. Jego usunięcie odbywa się zgodnie z tą samą procedurą co w przypadku innych docelowych wersji FCM (usuwane, gdy liczba aktywnych urządzeń z wersją starszą niż 8.0 spadnie poniżej określonego progu).

Opublikowane wersje FCM

Listę opublikowanych wersji FCM znajdziesz na stronie hardware/interfaces/compatibility_matrices.

Aby znaleźć wersję FCM opublikowaną z określoną wersją Androida, zapoznaj się z Level.h.