Cykl życia FCM

Wydanie platformy Android ma wiele macierzy zgodności platformy (FCM) — po jednej dla każdej wersji docelowej FCM, którą można uaktualnić — które definiują, czego może używać platforma, oraz wymagania dotyczące wersji docelowej FCM. W ramach cyklu FCM, deprecates Android i usuwa HIDL Hals, następnie modyfikuje FCM plików odzwierciedlać stan HAL wersji .

Aby umożliwić korzystanie z OTA tylko w ramach platformy we własnych ekosystemach, partnerzy, którzy rozszerzają interfejsy dostawców, powinni również wycofać i usunąć warstwy HAL HIDL przy użyciu tych samych metod.

Terminologia

Macierz zgodności ram (FCM) Plik XML, który określa wymagania ramowe dotyczące zgodnych implementacji dostawcy. Macierz zgodności jest wersjonowana, a nowa wersja jest zamrażana dla każdego wydania frameworka. Każde wydanie platformy zawiera wiele modułów FCM.
Wersje platforma FCM (S F) Zestaw wszystkich wersji FCM w wydaniu frameworka. Struktura może współpracować z dowolną implementacją dostawcy, która spełnia jeden z tych FCM.
Wersja FCM (F) Najwyższa wersja spośród wszystkich FCM w wydaniu frameworka.
Wersja docelowa FCM (V) Docelowa wersja FCM (od S F), stwierdził wyraźnie w manifeście urządzenia, że spełnia wdrożeniowych sprzedawca. Implementacja dostawcy musi zostać wygenerowana na podstawie opublikowanego FCM, chociaż może deklarować nowsze wersje HAL w swoim Manifeście urządzenia.
Wersja HAL Hal wersja ma format foo@xy , gdzie foo jest nazwą HAL i xy jest wersja specyficzny; np nfc@1.0 , keymaster@3.0 (prefiks korzeń, np android.hardware , pominięto w niniejszym dokumencie).
Manifest urządzenia Pliki XML określające wersje HAL udostępniane przez interfejs dostawcy po stronie urządzenia, w tym obrazy dostawcy i ODM. Zawartość manifestu urządzenia jest ograniczona przez docelową wersję FCM urządzenia, ale może zawierać listę warstw HAL, które są ściśle nowsze w stosunku do FCM odpowiadającego V.
HAL urządzenia Warstwy HAL, które są wymienione (dostarczone) w manifeście urządzenia i wymienione (wymagane lub opcjonalne) w macierzy zgodności struktury (FCM).
Matryca zgodności urządzeń (DCM) Plik XML, który określa wymagania dostawcy dotyczące zgodnych implementacji frameworka. Każde urządzenie zawiera jeden DCM.
Manifest Ramowy Plik XML, który określa, które wersje warstwy HAL udostępnia strona struktury interfejsu dostawcy, w tym obrazy systemu, system_ext i produktów. Warstwy HAL w manifeście platformy są dynamicznie wyłączane zgodnie z wersją urządzenia docelowego FCM.
Ramowe warstwy HAL Warstwy HAL wymienione w manifeście platformy i wymienione jako wymagane lub opcjonalne w macierzy zgodności urządzeń (DCM).

Programowanie w nowej wersji FCM

Android zwiększa wersję FCM dla każdej wersji platformy (takiej jak Android 8, 8.1 itp.). Podczas rozwoju, nowa compatibility_matrix.current.xml jest tworzony ( F ) i istniejąca compatibility_matrix.f.xml (gdzie f < F ) nie jest już zmieniona.

Aby rozpocząć rozwijających się w nowym FCM Wersja F :

  1. Skopiować najnowszą compatibility_matrix.<F-1>.xml do compatibility_matrix.current.xml .
  2. Zaktualizować level atrybutu w pliku do F .
  3. Dodaj odpowiednie reguły kompilacji, aby zainstalować tę macierz zgodności na urządzeniu.

Przedstawiamy nowy HAL

W trakcie rozwoju, wprowadzając nową HAL (Wi-Fi, NFC, itd.) Do Androida na obecnym FCM Wersja F , dodaj HAL do compatibility_matrix.current.xml z następujących optional ustawień:

  • optional="false" , jeśli urządzenia, które są dostarczane z V = F należy uruchomić z tego HAL

    LUB
  • optional="true" , jeśli urządzenia, które są dostarczane z V = F można uruchomić bez tego HAL.

Na przykład, Android 8.1 wprowadzono cas@1.0 jako opcjonalny HAL. Urządzenia z Androidem 8.1 wodowania nie są wymagane w celu wykonania niniejszej HAL, więc następujący wpis został dodany do compatibility_matrix.current.xml (przemianowany na compatibility_matrix.2.xml po Androidzie 8.1 wydany):

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

Uaktualnianie warstwy HAL (drobna)

W trakcie rozwoju, kiedy HAL ma aktualizacji moll wersja z xz do x.(z+1) przy prądzie FCM Wersja F , jeśli ta wersja jest:

  • Wymagane urządzenia do wodowania z V = F , w compatibility_matrix.current.xml państwo musi x.(z+1) oraz optional="false" .
  • Nie wymagane urządzenia do wodowania z V = F The compatibility_matrix.current.xml należy skopiować xy-z i opcjonalności z compatibility_matrix.<F-1>.xml i zmienić wersję do xw-(z+1) (gdzie w >= y ).

Na przykład, Android 8.1 wprowadzono broadcastradio@1.1 w wersji drobne uaktualnienia 1,0 HAL. Starsza wersja, broadcastradio@1.0 , jest opcjonalna dla urządzeń z Androidem 8.0 wodowania natomiast nowsza wersja, broadcastradio@1.1 , jest opcjonalna dla urządzeń do wodowania z Androidem 8.1. W compatibility_matrix.1.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Ten wpis został skopiowany do compatibility_matrix.current.xml (przemianowany na compatibility_matrix.2.xml po Androidzie 8.1 wydany) i wprowadza się następujące zmiany:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Aktualizacja HAL (główna)

W trakcie rozwoju, kiedy HAL ma uaktualnienie poważnych wersji na prąd FCM Wersja F , nowa wersja główna x.0 dodaje do compatibility_matrix.current.xml z następujących optional ustawień:

  • optional="false" z jedyną wersją x.0 , czy urządzeń, które są dostarczane z V = F należy uruchomić z x.0 .
  • optional="false" , ale wraz ze starszymi wersjami w tej samej <hal> Tag, czy urządzeń, które są dostarczane z V = F konieczne jest rozpoczęcie tej HAL, ale może uruchomić ze starszej wersji głównej.
  • optional="true" , jeśli urządzenia, które są dostarczane z V = F nie trzeba uruchomić HAL.

Na przykład, Android 9 wprowadza health@2.0 jako poważnej wersji upgrade 1.0 HAL i deprecates 1.0 HAL. Starsza wersja, health@1.0 , jest opcjonalna dla urządzeń z Androidem 8.0 do wodowania i Android 8.1. Urządzenia uruchamiane z systemem Android 9 nie mogą udostępniać przestarzałej warstwy HAL 1.0 i zamiast tego muszą zapewniać nową wersję 2.0. W compatibility_matrix.legacy.xml , compatibility_matrix.1.xml i compatibility_matrix.2.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Ten wpis jest kopiowany do compatibility_matrix.current.xml (przemianowany na compatibility_matrix.3.xml z Androidem 9 uwalnianiu) i wprowadza się następujące zmiany:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Ograniczenia:

  • Ponieważ 2,0 HAL jest w compatibility_matrix.3.xml z optional="false" , uruchomienie urządzeń z Androidem 9 musi wysyłać 2,0 HAL.
  • Ponieważ 1,0 HAL nie jest compatibility_matrix.3.xml urządzenia, które uruchamiają Android 9 nie może dostarczyć 1,0 HAL (tak jak to jest uważane za przestarzałe HAL).
  • Ponieważ 1.0 HAL jest obecny w legacy/1/2.xml (starsze wersje FCM, z którymi może współpracować system Android 9) jako opcjonalna warstwa HAL, platforma Android 9 może nadal współpracować z warstwą 1.0 HAL (która nie jest uważana za usuniętą wersję warstwy HAL ).

Nowe wersje FCM

Proces zwalniania wersji FCM na partycji systemowej jest wykonywany wyłącznie przez Google w ramach wydania AOSP i obejmuje następujące kroki:

  1. Zmiana nazwy compatibility_matrix.current.xml do compatibility_matrix.F.xml .
  2. Upewnij się, że plik ma atrybutu level="F" .
  3. Edycja odpowiadające zasady kompilacji , aby odzwierciedlić zmianę nazwy pliku.
  4. Upewnij się, że wszystkie urządzenia się budują i uruchamiają.
  5. Aktualizacja VTS testów w celu zapewnienia Urządzenia spustowe z najnowszymi ram (w przeliczeniu na poziomie API Shipping) mają docelowa FCM Wersja V >= F .
  6. Opublikuj plik w AOSP.

Plik ten nie może być zmieniona raz przemianowany i publikowane. Na przykład, podczas Androida 9 rozwoju następujące pliki są zbudowane na hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Kiedy Android 9 jest zwolniony, compatibility_matrix.current.xml zostaje zmieniona na compatibility_matrix.3.xml oraz następujące pliki są zbudowane dla hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

Testy VTS zapewnić, że urządzenia uruchamianego Androida 9 mają docelowa FCM wersja> = 3.

Ponadto moduły FCM produktu i system_ext mogą również zawierać listę wymagań dla każdej wersji modułu FCM platformy. Wydanie wersji FCM na partycjach produktu i system_ext jest wykonywane odpowiednio przez właściciela tych obrazów. Numery wersji FCM na partycjach produktu i system_ext muszą być zgodne z numerami na partycji systemowej. Podobnie jak w przypadku wersji FCM na partycji systemowej, macierz zgodności w FCM w wersji F w partycjach produktu i system_ext odzwierciedla wymagania urządzenia z docelową wersją FCM F.

Wycofanie wersji HAL

Wycofanie wersji HAL to decyzja programisty (tj. w przypadku warstw AOSP HAL decyzję podejmuje Google). Może się to zdarzyć, gdy zostanie wydana wyższa wersja HAL (czy to minor, czy major).

Wycofaj urządzenie HAL

Kiedy dany wyrób HAL foo@xy jest przestarzałe w FCM Wersja F , oznacza to, że każde uruchomienie urządzenia z systemem TARGET FCM Wersja V = F lub później nie musi wdrożyć foo w wersji xy lub dowolnej wersji starszej niż xy . Przestarzała wersja warstwy HAL jest nadal obsługiwana przez platformę uaktualniania urządzeń.

Kiedy FCM Wersja F jest zwolniony, Hal Wersja foo@xy jest uznawane za przestarzałe, jeśli specyficzny HAL wersja nie jest wyraźnie określone w najnowszym FCM dla docelowego FCM Wersja V = F . W przypadku urządzeń do wodowania z V = F , jeden z następujących warunków:

  • Framework wymaga wyższej wersji (głównej lub drugorzędnej);
  • Framework nie wymaga już warstwy HAL.

Na przykład w Androidzie 9, health@2.0 jest wprowadzony jako ważne uaktualnienie wersji 1,0 HAL. health@1.0 jest usuwany z compatibility_matrix.3.xml ale występuje w compatibility_matrix.legacy.xml , compatibility_matrix.1.xml i compatibility_matrix.2.xml . Stąd health@1.0 jest uważane za przestarzałe.

Wycofaj framework HAL

Kiedy dana ramy HAL foo@xy jest przestarzałe w FCM Wersja F , oznacza to, że każde uruchomienie urządzenia z systemem TARGET FCM Wersja V = F lub nowszej nie należy oczekiwać, że ramy w celu zapewnienia foo w wersji xy , lub w dowolnej wersji starszej niż xy . Przestarzała wersja warstwy HAL jest nadal udostępniana przez platformę do uaktualniania urządzeń.

Kiedy FCM wersja F jest zwolniony, Hal Wersja foo@xy jest uznawane za przestarzałe, jeśli ramowe manifest określa max-level=" F - 1 " dla foo@xy . W przypadku urządzeń do wodowania z V = F , ramy nie zapewnia HAL foo@xy . Matryca kompatybilność urządzenia urządzeń rozpoczyna się V = F nie muszą być wymienione HAL zrębowych max-level < V .

Na przykład, w Androida 12 schedulerservice@1.0 jest przestarzała. Jej max-level atrybut jest ustawiony na 5 , wersja FCM wprowadzonego w Android 11. Zobacz Androida 12 ramowej manifeście .

Usunięcie wsparcia dla docelowych wersji FCM

Gdy aktywne urządzenia o określonej docelowej FCM wersji V spadnie poniżej pewnej wartości progowej, docelowy FCM wersji jest usuwany z zestawu S F następnej wersji ramowej. Odbywa się to za pomocą obu następujących kroków:

  • Usuwanie compatibility_matrix.V.xml z zasadami budowania (tak, że nie jest on zainstalowany na obrazie systemu) i usuwanie dowolnego kodu, który realizowany lub zależy od usuniętego funkcjonalności.
  • Usuwanie warstwy HAL ramowych z max-level niższym lub równym V z manifeście ramowej i usuwanie kodu, który implementuje usunięte HALS ramowe.

Urządzenia z docelowym FCM Wersja zewnątrz S F dla danego wydania ramowej nie można uaktualnić do tej wersji.

Stan wersji HAL

Poniższe sekcje opisują (w porządku chronologicznym) możliwe stany wersji HAL.

Niewydany

W przypadku licencji HAL urządzeń, jeśli wersja warstwy HAL nie znajduje się w żadnej z publicznych i zamrożonych macierzy zgodności, jest uważana za niewydaną i prawdopodobnie w fazie rozwoju. Obejmuje to wersje HAL, które są tylko w compatibility_matrix.current.xml . Przykłady:

  • Podczas rozwoju Androida 9 (przed compatibiility_matrix.current.xml zostaje zmieniona na compatibility_matrix.3.xml ), przy czym health@2.0 HAL uznano za niepublikowany HAL.
  • teleportation@1.0 HAL nie jest w żaden zwolnionych matryc zgodności, a także jest uważany za niepublikowany HAL.

W przypadku ramowych warstw HAL, jeśli wersja warstwy HAL znajduje się tylko w manifeście platformy niepowiązanej gałęzi programistycznej, jest uważana za niewydaną.

Wydane i aktualne

W przypadku warstw HAL urządzeń, jeśli wersja HAL znajduje się w dowolnej publicznej i zamrożonej macierzy zgodności, jest ona wydana. Na przykład, po FCM Wersja 3 jest zamrożony (gdy compatibiility_matrix.current.xml zostaje zmieniona na compatibility_matrix.3.xml ) i opublikowane na AOSP The health@2.0 HAL jest uważana za zwolniony i aktualnej wersji HAL.

Jeśli HAL wersja jest w publicznym i mrożone zgodności matrycy, która ma najwyższy FCM wersja (bez compatibility_matrix.current.xml ), wersja HAL jest aktualny (nie przestarzałe). Na przykład, istniejące wersje HAL (takie jak nfc@1.0 wprowadzonego w compatibility_matrix.legacy.xml ), które nadal istnieją w compatibility_matrix.3.xml są również uważane za uwolnionych i aktualne wersje Hal.

Dla HAL ramowych, jeżeli wersja HAL jest w manifeście ramowej najnowszej wydanej gałęzi bez max-level atrybutu lub (nietypowo) o max-level równym lub wyższym niż wersja FCM wydany w tej branży, to jest uważany za wydany i aktualna wersja HAL. Na przykład, displayservice HAL jest zwalniany i prądu w Androida 12, jak wskazany przez Android 12framework manifest .

Wydany, ale przestarzały

W przypadku warstw HAL urządzeń wersja HAL jest przestarzała wtedy i tylko wtedy, gdy spełnione są wszystkie poniższe warunki:

  • Jest zwolniony.
  • Nie znajduje się w publicznej i zamrożonej macierzy kompatybilności, która ma najwyższą wersję FCM.
  • Rama nadal obsługuje publiczną i zamrożoną macierz kompatybilności.

Przykłady:

Stąd power@1.0 jest obecny, ale nie przestarzałe, w Androidzie 9.

Dla HAL ramowych, jeżeli wersja HAL jest w manifeście ramowej najnowszej wydanej gałęzi z max-level atrybutu niższa od wersji FCM wydany w tej branży, to jest uważany za wydany ale przestarzała wersja HAL. Na przykład, schedulerservice HAL uwalnia ale przestarzałe Android 12, jak wskazany przez Android 12framework manifest .

REMOVED

W przypadku licencji HAL urządzenia wersja HAL jest usuwana wtedy i tylko wtedy, gdy spełnione są następujące warunki:

  • Została wcześniej wydana.
  • Rama nie jest obsługiwana w żadnej publicznej i zamrożonej macierzy kompatybilności.

Macierze zgodności, które są publiczne, zamrożone, ale nie są obsługiwane przez platformę, są przechowywane w bazie kodu w celu zdefiniowania zestawu usuniętych wersji HAL, dzięki czemu można napisać testy VTS, aby upewnić się, że usunięte warstwy HAL nie znajdują się na nowych urządzeniach.

W przypadku ramowych warstw HAL wersja HAL jest usuwana wtedy i tylko wtedy, gdy spełnione są następujące warunki:

  • Została wcześniej wydana.
  • Nie ma go w żadnym manifeście frameworku w najnowszej wydanej gałęzi.

Starsze modele FCM

Starsze wersje docelowej wersji FCM to specjalna wartość dla wszystkich urządzeń innych niż Treble. Spuścizna FCM, compatibility_matrix.legacy.xml , wymienia wymogami ramowego na urządzeniach starszego typu (tj Urządzenia uruchomiony przed Android 8.0).

Jeśli istnieje plik dla FCM wersji F , każde urządzenie non-Treble można uaktualnić do F warunkiem jego manifest urządzenie jest kompatybilne z tym plikiem. Jego usunięcie odbywa się zgodnie z tą samą procedurą, co FCM dla innych docelowych wersji FCM (usuwane po tym, jak liczba aktywnych urządzeń przed wersją 8.0 spadnie poniżej pewnego progu).

Wydane wersje FCM

Lista wydanych wersjach FCM można znaleźć pod hardware/interfaces/compatibility_matrices .

Aby znaleźć wersję FCM zwolniony z konkretnej wersji Androida, zobacz Level.h .