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ę. Macierze te określają, 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 framework 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, który określa wymagania dotyczące platformy w przypadku implementacji dostawców zgodnych z tą platformą. 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 (SF)
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)
Wersja FCM (z SF) zadeklarowana w manifeście urządzenia, z którą implementacja dostawcy jest zgodna. 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 wersji V.
Warstwy HAL urządzenia
HAL-e wymienione (dostarczone) w manifeście urządzenia i w macierzy zgodności platformy (FCM).
Device Compatibility Matrix (DCM)
Plik XML, który określa 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 wersji FCM urządzenia docelowego.
Warstwy HAL platformy
HAL-e, które są wymienione jako dostarczone 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ą do publikacji Androida powinno mieć wartość FCM większą lub równą odpowiedniemu poziomowi. Na przykład urządzenie dostarczane z Androidem 12 zwykle ma 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 dostawcy 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 dotychczasowych 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.

Tworzenie aplikacji 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:

  1. Skopiuj najnowszą wersję compatibility_matrix.<F-1>.xml do compatibility_matrix.F.xml.
  2. Zaktualizuj atrybut level w pliku na F.
  3. 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, dlatego 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 w AIDL są traktowane jako wersje podrzędne HAL. Wersje interfejsu HIDL mają wersje takie jak 1.2.major.minor

Podczas tworzenia, 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, np. 2-3.

Na przykład Android FCM F został wprowadzony foo@3 jako uaktualnienie 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 (wersja główna)

Podczas opracowywania, gdy 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ą być uruchamiane 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 framework 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:

  1. Sprawdź, czy element compatibility_matrix.F.xml ma atrybut level="F".
  2. Sprawdź, czy wszystkie urządzenia są zbudowane i uruchomione.
  3. 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.
  4. Opublikuj plik w AOSP.

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

Dodatkowo FCM-y dotyczące produktu i systemu_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 (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. Wersja HAL, która została wycofana, 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ń wprowadzanych 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 jest usuwany z compatibility_matrix.3.xml, ale występuje w compatibility_matrix.legacy.xml, compatibility_matrix.1.xmlcompatibility_matrix.2.xml. W związku z tym środowisko 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 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 SF następnej wersji platformy, wykonamy te 2 czynności:

  1. Usuń compatibility_matrix.V.xml z reguł kompilacji (aby nie był instalowany w obrazie systemu) i usuń cały kod, który implementował usunięte funkcje lub od nich zależał.

  2. 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 wersji, 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 z docelową wersją FCM poza SF w przypadku danej wersji platformy nie mogą zostać zaktualizowane do tej wersji.

Usuwanie całkowicie wycofanych HAL-i

Gdy wersja FCM zostanie usunięta, niektóre interfejsy HAL lub wersje interfejsów HAL 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.

  1. Usuń definicję interfejsu HAL z kodu źródłowego. Obejmuje to pliki *.aidl i moduł Android.bp aidl_interface.
  2. Jeśli jest to HIDL, usuń HASH z hardware/interfaces/current.txt.
  3. Jeśli AIDL, usuń katalog aidl_api z zamrożonymi plikami AIDL.
  4. Usuń interfejs z 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ądzenia, 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 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ą.

Wersja opublikowana i bieżąca

W przypadku interfejsów HAL urządzenia, jeśli wersja interfejsu HAL znajduje się w dowolnej publicznej i zamrożonej macierzy zgodności, jest ona udostępniana. Na przykład po zamrożeniu i opublikowaniu w AOSP wersji 3 interfejsu FCM health@2.0 HAL 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 przestarzała). 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ż uważane 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 HAL jest wydany i aktualny w Androidzie 12, zgodnie z manifestem platformy Androida 12.displayservice

Wydane, ale wycofane

W przypadku warstw HAL urządzeń wersja HAL jest wycofywana tylko wtedy, gdy spełnione są wszystkie te warunki:

  • zostanie opublikowany.
  • Nie ma go w publicznej i zamrożonej macierzy zgodności, która ma najwyższą wersję FCM.
  • Jest ona dostępna w publicznej i zamrożonej macierzy zgodności, którą platforma nadal obsługuje.

Przykłady:

Dlatego w Androidzie 9 interfejs power@1.0 jest aktualny, ale NIE wycofany.

W przypadku HAL-i platformy, jeśli wersja HAL-u znajduje się w manifeście platformy najnowszej opublikowanej gałęzi z atrybutem max-level o wartości niższej niż wersja FCM w tej gałęzi, jest ona uznawana za opublikowaną, ale wycofaną wersję HAL-u. 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ń ramowych 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 znaleźć wersję FCM wydaną z określoną wersją Androida, zobacz Level.h.