Aby zachować zgodność z naszym modelem rozwoju gałęzi głównej i zapewnić stabilność platformy w ekosystemie, w II i IV kwartale 2026 r. opublikujemy kod źródłowy w AOSP. Do tworzenia i współtworzenia AOSP zalecamy używanie android-latest-release zamiast aosp-main. Gałąź android-latest-release manifestu zawsze będzie odnosić się do najnowszej wersji przesłanej do AOSP. Więcej informacji znajdziesz w sekcji Zmiany w AOSP.

Cykl życia FCM

Wersja platformy Android ma wiele macierzy zgodności platformy (FCM), po jednej dla każdej wersji FCM, do której można uaktualnić platformę. Określają one, z czego może korzystać platforma, oraz wymagania dotyczące wersji FCM. W ramach cyklu życia FCM Android wycofuje i usuwa interfejsy HAL HIDL, a następnie modyfikuje pliki FCM, aby odzwierciedlały stan wersji interfejsu HAL.

Aby włączyć aktualizacje OTA obejmujące tylko platformę w swoich ekosystemach, partnerzy, którzy rozszerzają interfejsy dostawców, powinni też wycofać i usunąć interfejsy HAL HIDL, korzystając z tych samych metod.

Terminologia

Macierz zgodności platform (FCM): Plik XML określający wymagania dotyczące platformy w przypadku implementacji dostawców zgodnych z tymi wymaganiami. Macierz zgodności jest wersjonowana, a nowa wersja jest zamrażana dla każdej wersji platformy. Każda wersja platformy zawiera wiele modułów FCM.
Wersje platformy FCM (S_F): Zbiór wszystkich wersji FCM w wersji platformy. Platforma może współpracować z dowolnym wdrożeniem dostawcy, które spełnia jedno z tych wymagań.
Wersja FCM (F): Najwyższa wersja spośród wszystkich modułów FCM w wersji platformy.
Docelowa wersja FCM (V): Docelowa wersja FCM (z S_F) zadeklarowana w manifeście urządzenia, z którą jest zgodna implementacja dostawcy. Implementacja dostawcy musi być generowana na podstawie opublikowanego FCM, chociaż w pliku manifestu urządzenia może deklarować nowsze wersje HAL.
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 (prefiks główny, np. android.hardware, jest pomijany w całym tym dokumencie).
Plik manifestu urządzenia: Pliki XML określające, które wersje HAL udostępnia strona urządzenia interfejsu dostawcy, w tym obrazy dostawcy i ODM. Zawartość pliku manifestu urządzenia jest ograniczona przez docelową wersję FCM urządzenia, ale może zawierać HAL-e, które są ściśle nowsze w porównaniu z FC odpowiadającym V.
Warstwy HAL urządzeń: HAL-e wymienione (dostarczone) w manifeście urządzenia i w macierzy zgodności platformy (FCM).
Device Compatibility Matrix (DCM): Plik XML określający wymagania dostawcy dotyczące implementacji zgodnych platform. Każde urządzenie zawiera 1 moduł DCM.
Plik manifestu platformy: Plik XML, który określa, które wersje HAL udostępnia strona platformy interfejsu dostawcy, w tym obrazy systemowe, system_ext i obrazy produktów. HAL-e w pliku manifestu platformy są dynamicznie wyłączane w zależności od docelowej wersji FCM urządzenia.
Warstwy HAL Framework: HAL-e, które są wymienione jako dostarczane w manifeście platformy i w macierzy zgodności urządzeń (DCM).

Cykl życia FCM w bazie kodu

W tym dokumencie opisujemy cykl życia FCM w sposób abstrakcyjny. Listę obsługiwanych plików manifestu znajdziesz w sekcji hardware/interfaces/compatibility_matrices/compatibility_matrix.<FCM>.xml gdzie można znaleźć FCM w 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 12 ma zwykle poziom FCM 6, ale może implementować poziom FCM 7 lub wyższy, co zmienia działanie Androida i wymusza używanie nowszych interfejsów API dostawców zgodnie z macierzami zgodności. Poziomy obsługiwane w przypadku Androida 16 to:

FCM	Wersja Androida
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V
202504	Android 16/B

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

Gdy ogłoszono Project Treble, obrazy systemu Android zostały opracowane tak, aby były wstecznie zgodne z 3 poprzednimi wersjami implementacji dostawców (łącznie 4). Aby wydłużyć okres eksploatacji urządzeń, ten zakres został zwiększony, aby obsługiwać bieżącą i 6 poprzednich wersji FCM (łącznie 7) w przypadku 202404 i nowszych.

Gdy Android wycofuje poziom FCM, jest on nadal obsługiwany na istniejących urządzeniach. Urządzenia, które są zgodne z niższymi poziomami FCM, mogą korzystać z interfejsów HAL wymienionych na wyższych poziomach FCM, o ile są one dostępne w danej gałęzi.

Programowanie w nowej wersji FCM

Android zwiększa numer wersji FCM w przypadku każdej wersji platformy (np. Androida 8 i 8.1). Podczas tworzenia nowej wersji compatibility_matrix.F.xml istniejąca wersja compatibility_matrix.f.xml (gdzie f < F) nie jest już zmieniana.

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

Skopiuj najnowszą wersję compatibility_matrix.<F-1>.xml do compatibility_matrix.F.xml.
Zaktualizuj atrybut level w pliku na F.
Dodaj odpowiednie reguły kompilacji, aby zainstalować tę macierz zgodności na urządzeniu.

Wprowadzenie nowej warstwy HAL

Podczas tworzenia, gdy wprowadzasz nowy HAL (Wi-Fi, NFC itp.) do Androida w bieżącej wersji FCM F, dodaj go do compatibility_matrix.F.xml.

Na przykład w Androidzie 8.1 wprowadzono cas@1.0. Urządzenia z Androidem 8.1 mogą implementować ten HAL, więc do pliku compatibility_matrix.F.xml (który w trakcie opracowywania tej wersji tymczasowo nosił nazwę 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 HAL (wersja podrzędna)

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

Podczas opracowywania, gdy wersja AIDL HAL zostanie uaktualniona z 2 do 3 w bieżącej wersji FCM F, nowa wersja zostanie dodana do wpisu HAL w compatibility_matrix.F.xml. Pole wersji w pozycji HAL akceptuje zakresy takie jak 2-3.

Na przykład Android FCM F został wprowadzony foo@3 jako aktualizacja HAL do wersji podrzędnej. Starsza wersja, foo@2, jest używana w przypadku urządzeń korzystających ze starszych wersji FCM, a nowsza wersja, foo@3, może być używana w przypadku urządzeń korzystających z FCM na Androidzie w wersji F. W starszych wersjach FCM przed wersją 2 wpis 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 usługi 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>

Uaktualnianie HAL (główne)

Podczas opracowywania, gdy interfejs HAL ma aktualizację do nowej wersji głównej w bieżącej 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 V = F muszą być uruchamiane z V = F.x.0
W przypadku starszych wersji głównych w tym samym tagu <hal> urządzenia dostarczane z V = F mogą uruchamiać się ze starszą wersją główną.

Na przykład wersja FCM F wprowadza foo@2.0 jako uaktualnienie głównej wersji interfejsu HAL 1.0 i wycofuje interfejs HAL 1.0. Starsza wersja, foo@1.0, jest używana w przypadku urządzeń, które korzystają ze starszych wersji FCM. Urządzenia, które korzystają z FCM w wersji F, muszą udostępniać nową wersję 2.0, jeśli udostępniają 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 compatibility_matrix.F.xml i zmodyfikuj 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:

Ponieważ interfejs HAL w wersji 1.0 nie jest w compatibility_matrix.F.xml, urządzenia, które są zgodne z wersją FCM F, nie mogą udostępniać interfejsu HAL w wersji 1.0 (ponieważ jest on uznawany za przestarzały).
Interfejs HAL w wersji 1.0 jest obecny w starszych wersjach FCM, więc platforma może nadal z nim współpracować.Zapewnia to zgodność wsteczną ze starszymi urządzeniami, które są przeznaczone do starszych wersji FCM.

Nowe wersje FCM

Proces udostępniania wersji FCM na partycji systemowej jest przeprowadzany wyłącznie przez Google w ramach wersji AOSP i obejmuje te kroki:

Sprawdź, czy element compatibility_matrix.F.xml ma atrybut level="F".
Sprawdź, czy wszystkie urządzenia są zbudowane i uruchomione.
Zaktualizuj testy VTS, aby urządzenia wprowadzane na rynek z najnowszą platformą (opartą na poziomie interfejsu API dostawy) miały docelową wersję FCM V >= F.
Opublikuj plik w AOSP.

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

Dodatkowo FCM-y dotyczące produktu i system_ext mogą też zawierać wymagania dotyczące poszczególnych wersji FCM-ów na platformach. Wersje FCM są udostępniane na partycjach product i system_ext przez właściciela tych obrazów. Numery wersji FCM w przypadku partycji product i system_ext muszą być zgodne z numerami wersji w przypadku partycji system. Podobnie jak w przypadku wersji FCM na partycji systemowej, macierz zgodności w wersji FCM F na partycjach product i system_ext odzwierciedla wymagania dotyczące urządzenia z docelową wersją FCM F.

Wycofanie wersji HAL

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

Wycofywanie warstwy HAL urządzenia

Gdy dany HAL urządzenia foo@x.y zostanie wycofany w wersji FCM F, oznacza to, że każde urządzenie z wersją docelową FCM V = F lub nowszą nie może implementować foo w wersji x.y ani w żadnej wersji starszej niż x.y. Wycofana wersja HAL jest nadal obsługiwana przez platformę na potrzeby uaktualniania urządzeń.

Gdy zostanie wydana wersja FCM F, wersja HAL foo@x.y jest uznawana za przestarzałą, jeśli nie jest wyraźnie wymieniona w najnowszej wersji FCM dla docelowej wersji FCM V = F. W przypadku urządzeń, które są wprowadzane na rynek z V = F, spełniony jest jeden z tych warunków:

platforma wymaga nowszej wersji (głównej lub pomocniczej);
Platforma nie wymaga już warstwy HAL.

Na przykład w Androidzie 9 wprowadzono health@2.0 jako aktualizację do nowej wersji interfejsu HAL 1.0. health@1.0 został usunięty z compatibility_matrix.3.xml, ale występuje w compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml. W związku z tym środowisko wykonawcze health@1.0 zostało wycofane.

Wycofywanie HAL platformy

Gdy dana warstwa HAL foo@x.y jest wycofywana w wersji FCM F, oznacza to, że każde urządzenie wprowadzane na rynek z docelową wersją FCM V = F lub nowszą nie może oczekiwać, że platforma będzie udostępniać foo w wersji x.y ani w żadnej wersji starszej niż x.y. Wycofana wersja HAL jest nadal udostępniana przez platformę na potrzeby uaktualniania urządzeń.

Gdy zostanie wydana wersja FCM F, wersja HAL foo@x.y jest uznawana za wycofaną, jeśli plik manifestu platformy określa wartość max-level="F - 1" dla foo@x.y. W przypadku urządzeń z V = F platforma nie udostępnia HAL foo@x.y. Macierz zgodności urządzeń na urządzeniach wprowadzanych na rynek z V = F nie może zawierać interfejsów HAL platformy z max-level < V.

Na przykład w Androidzie 12 funkcja schedulerservice@1.0 została wycofana. Jego atrybut max-level ma wartość 5, czyli wersję FCM wprowadzoną w Androidzie 11. Zobacz plik manifestu struktury Androida 12.

Wycofanie obsługi docelowych wersji FCM

Aby zachować zgodność przez wymagany czas i spełnić wymagania partnerów dotyczące urządzeń o dłuższej żywotności, stosujemy proces oparty na harmonogramie, który określa, kiedy usunąć docelową wersję FCM.

Gdy usuniemy docelową wersję FCM ze zbioru S_F następnej wersji platformy, wykonujemy te 2 czynności:

Usuń compatibility_matrix.V.xml z reguł kompilacji (aby nie był instalowany na obrazie systemu) i usuń cały kod, który implementował usunięte funkcje lub od nich zależał.
Usuń z manifestu platformy interfejsy HAL platformy o wartości max-level mniejszej lub równej V i usuń kod, który implementuje usunięte interfejsy HAL platformy.

Stopniowe wycofywanie konfiguracji wersji

Strategia rozgałęziania Trunk Stable, w której kwartalne wersje platformy (QPR) są pobierane bezpośrednio z git_main zamiast z osobnych gałęzi deweloperskich, wymaga stopniowego wycofywania. Wersja FCM może zostać usunięta z trunk_staging wczesnych kompilacji, ale nadal będzie obsługiwana w gałęzi wydania, aby uwzględnić urządzenia, które otrzymują QPR w ciągu roku.

Zwykle wersja platformy obsługuje 6 wersji FCM: 1 aktualną, 4 poprzednie i 1 dodatkową, która obsługuje QPR. Ta liczba może wzrosnąć, jeśli określone wersje FCM (np. 202404 w Androidzie 15) będą miały wydłużony okres obsługi urządzenia.

Urządzenia z docelową wersją FCM poza S_F w przypadku danej wersji platformy nie mogą zostać zaktualizowane do tej wersji.

Usuwanie całkowicie wycofanych warstw HAL

Gdy wersja FCM zostanie usunięta, niektóre interfejsy HAL lub ich wersje nie będą już obecne w żadnych FCM. Oznacza to, że Android nie obsługuje ich już w żaden sposób, nawet w przypadku uaktualniania urządzeń.

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

Jeśli nie ma obsługiwanych interfejsów HAL dziedziczących po usuwanym interfejsie HAL, samą definicję interfejsu HAL można usunąć, wykonując kilka dodatkowych czynności.

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

Stan wersji HAL

W sekcjach poniżej opisujemy (w kolejności chronologicznej) możliwe stany wersji HAL.

Niewydane

W przypadku warstw HAL urządzeń, jeśli wersja HAL nie znajduje się w żadnej z publicznych i zamrożonych macierzy zgodności, jest uznawana za niewydaną 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 HAL health@2.0 był uznawany za nieopublikowany interfejs HAL i występował tylko w compatibility_matrix.3.xml.
Interfejs HAL teleportation@1.0 nie występuje w żadnej opublikowanej macierzy zgodności i jest też uważany za nieopublikowany interfejs HAL.

W przypadku HAL-i platformy, jeśli wersja HAL-u znajduje się tylko w manifeście platformy niepowiązanej gałęzi deweloperskiej, jest uznawana za nieopublikowaną.

Wydane i aktualne

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

Jeśli wersja HAL znajduje się w publicznej i zamrożonej macierzy zgodności, która ma najwyższą wersję FCM, jest ona aktualna (tzn. nie jest wycofana). Na przykład istniejące wersje HAL (takie jak nfc@1.0 wprowadzone w compatibility_matrix.legacy.xml), które nadal istnieją w compatibility_matrix.3.xml, są również uznawane za wydane i aktualne wersje HAL.

W przypadku HAL-i platformy, jeśli wersja HAL-u znajduje się w manifeście platformy najnowszej opublikowanej gałęzi bez atrybutu max-level lub (rzadko) z atrybutem max-level o wartości równej lub wyższej niż wersja FCM opublikowana w tej gałęzi, jest ona uznawana za opublikowaną i aktualną wersję HAL-u. Na przykład displayserviceHAL jest wydany i aktualny w Androidzie 12, zgodnie z manifestem frameworka Androida 12.

Wydane, ale wycofane

W przypadku interfejsów HAL urządzeń wersja HAL jest wycofana tylko wtedy, gdy spełnione są wszystkie te warunki:

Zostanie opublikowany.
Nie ma go w publicznej i niezmiennej macierzy zgodności, która ma najwyższą wersję FCM.
Znajduje się ona w publicznej i zamrożonej macierzy zgodności, którą platforma nadal obsługuje.

Przykłady:

Interfejs HAL health@1.0 jest dostępny w tych krajach: compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml, ale nie w tym kraju: compatibility_matrix.3.xml. Dlatego w Androidzie 9 jest uznawana za wycofaną.
W Androidzie 9 nastąpiła niewielka aktualizacja wersji HAL zasilania, ale power@1.0 nadal jest w 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 w Androidzie 9 funkcja power@1.0 jest aktualna, ale NIE jest wycofana.

W przypadku interfejsów HAL platformy, jeśli wersja interfejsu HAL znajduje się w manifeście platformy najnowszej opublikowanej gałęzi z atrybutem max-level niższym niż wersja FCM w tej gałęzi, jest ona uznawana za opublikowaną, ale wycofaną wersję interfejsu HAL. Na przykład schedulerserviceHAL został wydany, ale w Androidzie 12 jest już przestarzały, co zostało określone w manifeście platformy Androida 12.

Usunięta

W przypadku interfejsów HAL urządzenia wersja interfejsu HAL jest usuwana tylko wtedy, gdy spełnione są te warunki:

Został już wcześniej opublikowany.
Nie ma go w żadnej publicznej i zamrożonej macierzy zgodności, którą obsługuje platforma.

Macierze zgodności, które są publiczne, zamrożone, ale nie są obsługiwane przez framework, są przechowywane w bazie kodu, aby zdefiniować usunięty zestaw wersji HAL, dzięki czemu można pisać testy VTS, aby mieć pewność, że usunięte interfejsy HAL nie znajdują się na nowych urządzeniach.

W przypadku HAL-i platformy wersja HAL-u jest usuwana tylko wtedy, gdy spełnione są te warunki:

Został już wcześniej opublikowany.
Nie ma go w żadnym pliku manifestu platformy w najnowszej opublikowanej gałęzi.

Starsze FCM

Wersja FCM starszego typu to specjalna wartość dla wszystkich urządzeń innych niż Treble. Starsza wersja FCMcompatibility_matrix.legacy.xml zawiera listę wymagań dotyczących 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ż Treble można uaktualnić do wersji F, o ile jego manifest urządzenia jest zgodny z tym plikiem. Jego usunięcie przebiega tak samo jak w przypadku FCM w innych wersjach docelowych FCM (jest usuwany, gdy liczba aktywnych urządzeń z Androidem w wersji starszej niż 8.0 spadnie poniżej określonego progu).

Opublikowane wersje FCM

Listę opublikowanych wersji FCM znajdziesz w sekcji hardware/interfaces/compatibility_matrices.

Aby sprawdzić, która wersja FCM została opublikowana z określoną wersją Androida, zobacz Level.h.