Cykl życia FCM

Wersja platformy Android ma wiele macierzy zgodności platformy (FCM), po jednej dla każdej wersji docelowej FCM, którą można uaktualnić. Określają one, czego może używać platforma, oraz wymagania dotyczące wersji docelowej 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 tylko z ramami 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 tymi wymaganiami. Macierz zgodności jest wersjonowana, a nowa wersja jest zamrażana przy 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ń dotyczących zarządzania zgodą użytkowników.
Wersja FCM (F)
Najwyższa wersja spośród wszystkich FCM w wersji platformy.
Docelowa wersja FCM (V)
Docelowa wersja FCM (z SF) zadeklarowana w pliku manifestu 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, które określają, 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ć listę HAL-i, które są ściśle nowsze w porównaniu z FC odpowiadającym V.
Warstwy HAL urządzenia
HAL-e wymienione (dostarczone) w manifeście urządzenia i w macierzy zgodności platformy (FCM).
Macierz zgodności urządzeń (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 docelowej wersji FCM urządzenia.
Framework HAL
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ą Androida powinno mieć wartość FCM większą lub równą odpowiedniemu poziomowi. Na przykład urządzenie dostarczane z Androidem 11 zwykle ma FCM na poziomie 5, ale implementuje FCM na poziomie 6 lub wyższym, co wiąże się z różnymi dodatkowymi wymaganiami określonymi w macierzach zgodności. Obsługiwane poziomy w przypadku Androida 15 to:

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 wycofuje poziom FCM, jest on nadal obsługiwany na dotychczasowych urządzeniach. Urządzenia kierowane na niższe poziomy FCM mogą domyślnie korzystać z interfejsów HAL wymienionych na nowszych 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 opracowywania tworzony jest nowy token compatibility_matrix.F.xml, a istniejący token compatibility_matrix.f.xml (gdzie f < F) nie jest już zmieniany.

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 interfejsu HAL (wersja podrzędna)

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

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 aktualizacja HAL do wersji pomocniczej. 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 interfejsu HAL (główne)

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 x.0 muszą być uruchamiane z x.0.V = F
  • 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ą z wcześniejszych 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 uruchamiają się.
  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 produktów 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 na partycjach product i system_ext muszą być zgodne z numerami na partycji system. Podobnie jak w przypadku wersji FCM na partycji systemowej, macierz zgodności w wersji F FCM na partycjach product i system_ext odzwierciedla wymagania dotyczące urządzenia z docelową wersją F FCM.

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ń 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 został usunięty z health@1.0, ale występuje w compatibility_matrix.legacy.xml, compatibility_matrix.1.xml i compatibility_matrix.2.xml.compatibility_matrix.3.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 żadne 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 aktualizowania 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

Gdy liczba aktywnych urządzeń z określoną wersją docelową FCM V spadnie poniżej określonego progu, wersja docelowa FCM zostanie usunięta ze zbioru SF następnej wersji platformy. Obejmuje to te czynności:

  1. Usunięcie compatibility_matrix.V.xml z reguł kompilacji (aby nie był instalowany w obrazie systemu) i usunięcie kodu, który implementował usunięte funkcje lub od nich zależał.

  2. Usunięcie z manifestu platformy interfejsów HAL platformy o wartości max-level mniejszej lub równej V oraz usunięcie kodu, który implementuje usunięte interfejsy HAL platformy.

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-ów

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 interfejs HAL przestaje być obsługiwany, deweloperzy usuwają odwołania do niego 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 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 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ą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 był uznawany za nieopublikowany i występował tylko w compatibility_matrix.3.xml.health@2.0
  • Interfejs HAL teleportation@1.0 nie występuje w żadnej opublikowanej macierzy zgodności i jest 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ą.

Wydany i aktualny

W przypadku interfejsów HAL urządzeń, 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 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 wprowadzona w compatibility_matrix.legacy.xml), które nadal występują 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 interfejs 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 wycofana tylko wtedy, gdy spełnione są wszystkie te warunki:

  • Zostanie wycofane
  • Nie ma go w publicznej i niezmiennej 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 funkcja power@1.0 jest aktualna, ale NIE jest wycofana.

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 schedulerservice HAL jest udostępniany, ale w Androidzie 12 jest wycofany, co jest określone w manifestie platformy Androida 12.

Usunięto

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 manifeście 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.xmlzawiera 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 (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, zapoznaj się z Level.h.