Cykl życia FCM

Wersja platformy Android ma wiele macierzy zgodności ram (FCM) — po jednej dla każdej wersji docelowej FCM, którą można aktualizować — które określają, z czego może korzystać struktura i wymagania dotyczące wersji docelowej FCM. W ramach cyklu życia FCM system Android wycofuje i usuwa warstwy HAL HIDL, a następnie modyfikuje pliki FCM, aby odzwierciedlić stan wersji HAL .

Aby włączyć OTA oparte wyłącznie na frameworku we własnych ekosystemach, partnerzy, którzy rozszerzają interfejsy dostawców, powinni również wycofać i usunąć HIDL HAL przy użyciu tych samych metod.

Terminologia

Macierz zgodności ram (FCM) Plik XML określający wymagania ramowe dotyczące zgodnych implementacji dostawców. Macierz kompatybilności jest wersjonowana, a nowa wersja jest zamrażana dla każdego wydania platformy. Każda wersja platformy zawiera wiele FCM.
Wersje platformy FCM ( SF ) Zestaw wszystkich wersji FCM w wersji ramowej. Ramy mogą 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 wersji ramowej.
Docelowa wersja FCM (V) Docelowa wersja FCM (z SF ), zadeklarowana jawnie w manifeście urządzenia, którą spełnia implementacja dostawcy. Implementacja dostawcy musi zostać wygenerowana na podstawie opublikowanego FCM, chociaż może zadeklarować nowsze wersje HAL w swoim manifeście urządzenia.
Wersja HAL Wersja HAL ma format foo@xy , gdzie foo to nazwa HAL, a xy to konkretna wersja; np. nfc@1.0 , keymaster@3.0 (przedrostek katalogu głównego, np. android.hardware , jest pomijany w tym dokumencie).
Manifest urządzenia Pliki XML określające, które wersje HAL udostępnia 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ę HAL, które są ściśle nowsze w stosunku do FCM odpowiadającej wersji V.
HAL urządzeń Warstwy HAL wymienione (dostarczone) w manifeście urządzenia i wymienione (wymagane lub opcjonalne) w macierzy zgodności struktury (FCM).
Macierz zgodności urządzeń (DCM) Plik XML, który określa wymagania dostawcy dotyczące zgodnych implementacji ramowych. Każde urządzenie zawiera jeden DCM.
Manifest ramowy Plik XML określający, które wersje warstwy HAL zapewnia strona szkieletowa interfejsu dostawcy, w tym system, system_ext i obrazy produktów. Warstwy HAL w manifeście struktury są wyłączane dynamicznie zgodnie z wersją docelowego FCM urządzenia.
Struktury HAL Warstwy HAL wymienione w manifeście struktury i wymienione jako wymagane lub opcjonalne w macierzy zgodności urządzeń (DCM).

Rozwój w nowej wersji FCM

Android zwiększa wersję FCM dla każdej wersji platformy (np. Android 8, 8.1 itd.). Podczas opracowywania tworzony jest nowy plik compatibility_matrix.F.xml , a istniejący compatibility_matrix.f.xml (gdzie f < F ) nie jest już zmieniany.

Aby rozpocząć programowanie w nowej wersji FCM F :

  1. Skopiuj najnowszy plik 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.

Przedstawiamy nowy HAL

Podczas opracowywania, wprowadzając nową warstwę HAL (Wi-Fi, NFC itp.) do systemu Android w bieżącej wersji FCM F , dodaj warstwę HAL do compatibility_matrix.F.xml z następującymi optional ustawieniami:

  • optional="false" jeśli urządzenia dostarczane z V = F muszą być uruchamiane z tą warstwą HAL,

    LUB
  • optional="true" , jeśli urządzenia dostarczane z V = F mogą być uruchamiane bez tej warstwy HAL.

Na przykład system Android 8.1 wprowadził cas@1.0 jako opcjonalną warstwę HAL. Urządzenia uruchamiane z systemem Android 8.1 nie muszą implementować tej warstwy HAL, dlatego następujący wpis został dodany do pliku compatibility_matrix.F.xml (który w trakcie opracowywania tej wersji miał tymczasowo nazwę compatibility_matrix.current.xml ):

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

Uaktualnianie HAL (podrzędne)

Podczas opracowywania, gdy HAL ma uaktualnienie wersji pomocniczej z xz do x.(z+1) w bieżącej wersji FCM F , jeśli ta wersja to:

  • Wymagany w przypadku urządzeń uruchamianych z V = F , compatibility_matrix.F.xml musi określać x.(z+1) i optional="false" .
  • Niewymagane na urządzeniach uruchamianych z V = F , compatibility_matrix.F.xml musi skopiować xy-z i opcjonalność z compatibility_matrix.<F-1>.xml i zmienić wersję na xw-(z+1) (gdzie w >= y ).

Na przykład Android 8.1 wprowadził broadcastradio@1.1 jako niewielką aktualizację wersji 1.0 HAL. Starsza wersja, broadcastradio@1.0 , jest opcjonalna dla urządzeń uruchamianych z systemem Android 8.0, podczas gdy nowsza wersja, broadcastradio@1.1 , jest opcjonalna dla urządzeń uruchamianych z systemem Android 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.F.xml i zmodyfikowany w następujący sposób:

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

Uaktualnienie HAL (główne)

Podczas opracowywania, gdy HAL ma uaktualnienie wersji głównej w bieżącej wersji FCM F , nowa wersja główna x.0 jest dodawana do compatibility_matrix.F.xml z następującymi optional ustawieniami:

  • optional="false" tylko z wersją x.0 , jeśli urządzenia dostarczane z V = F muszą być uruchamiane z x.0 .
  • optional="false" , ale wraz ze starszymi wersjami głównymi w tym samym znaczniku <hal> , jeśli urządzenia dostarczane z V = F muszą być uruchamiane z tą warstwą HAL, ale mogą być uruchamiane ze starszą wersją główną.
  • optional="true" , jeśli urządzenia dostarczane z V = F nie muszą uruchamiać warstwy HAL.

Na przykład Android 9 wprowadza health@2.0 jako uaktualnienie wersji głównej 1.0 HAL i wycofuje wersję 1.0 HAL. Starsza wersja, health@1.0 , jest opcjonalna dla urządzeń uruchamianych z systemem Android 8.0 i Android 8.1. Urządzenia uruchamiane z systemem Android 9 nie mogą udostępniać przestarzałej wersji 1.0 HAL i zamiast tego muszą udostępniać 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.F.xml i modyfikowany w następujący sposób:

<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ż warstwa HAL 2.0 znajduje się w compatibility_matrix.3.xml z optional="false" , urządzenia uruchamiane z systemem Android 9 muszą być dostarczane z warstwą 2.0 HAL.
  • Ponieważ warstwa HAL 1.0 nie znajduje się w compatibility_matrix.3.xml , urządzenia uruchamiane z systemem Android 9 nie mogą zapewniać warstwy HAL 1.0 (ponieważ ta warstwa HAL jest uważana za przestarzałą).
  • Ponieważ warstwa HAL 1.0 jest obecna w pliku legacy/1/2.xml (starsze wersje FCM, z którymi może współpracować system Android 9) jako opcjonalna warstwa HAL, struktura systemu Android 9 może nadal działać z warstwą HAL 1.0 (która nie jest uważana za usuniętą wersję HAL ).

Nowe wersje FCM

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

  1. Upewnij się, że compatibility_matrix.F.xml ma atrybut level="F" .
  2. Upewnij się, że wszystkie urządzenia są kompilowane i uruchamiane.
  3. Zaktualizuj testy VTS , aby upewnić się, że urządzenia uruchamiane z najnowszą strukturą (w oparciu o poziom interfejsu Shipping API) mają docelową wersję FCM V >= F .
  4. Opublikuj plik w AOSP.

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

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

Wycofanie wersji HAL

Wycofanie wersji HAL jest decyzją programisty (tj. w przypadku AOSP HAL decyzję podejmuje Google). Może się to zdarzyć, gdy zostanie wydana wyższa wersja HAL (podrzędna lub główna).

Wycofaj urządzenie z warstwy HAL

Gdy dane urządzenie HAL foo@xy jest przestarzałe w FCM w wersji F , oznacza to, że żadne urządzenie uruchamiane z docelową wersją FCM V = F lub nowszą nie może implementować foo w wersji xy ani żadnej wersji starszej niż xy . Przestarzała wersja HAL jest nadal obsługiwana przez platformę do aktualizacji urządzeń.

Po wydaniu FCM w wersji F wersja HAL foo@xy jest uważana za przestarzałą, jeśli konkretna wersja HAL nie jest wyraźnie określona w najnowszym FCM dla docelowej wersji FCM V = F . W przypadku urządzeń uruchamianych z V = F spełniony jest 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 systemie Android 9 health@2.0 jest wprowadzana jako główne uaktualnienie wersji 1.0 HAL. health@1.0 jest usuwany z compatibility_matrix.3.xml , ale jest obecny w compatibility_matrix.legacy.xml , compatibility_matrix.1.xml i compatibility_matrix.2.xml . W związku z tym health@1.0 jest uważane za przestarzałe.

Wycofaj platformę HAL

Kiedy dana struktura HAL foo@xy jest przestarzała w wersji FCM F , oznacza to, że żadne urządzenie uruchamiane z wersją Target FCM V = F lub nowszą nie może oczekiwać, że struktura zapewni foo w wersji xy lub w dowolnej wersji starszej niż xy . Przestarzała wersja HAL jest nadal dostarczana przez platformę do aktualizacji urządzeń.

Po wydaniu FCM w wersji F wersja HAL foo@xy jest uważana za przestarzałą, jeśli manifest platformy określa max-level=" F - 1 " dla foo@xy . W przypadku urządzeń uruchamianych z V = F struktura nie zapewnia warstwy HAL foo@xy . Macierz zgodności urządzeń na urządzeniach uruchamianych z V = F nie może zawierać HAL platformy z max-level < V .

Na przykład w systemie Android 12 schedulerservice@1.0 jest przestarzała. Jego atrybut max-level jest ustawiony na 5 , czyli wersję FCM wprowadzoną w systemie Android 11. Zobacz manifest struktury systemu Android 12 .

Usunięcie obsługi docelowych wersji FCM

Gdy aktywne urządzenia określonej docelowej wersji FCM V spadną poniżej określonego progu, docelowa wersja FCM zostanie usunięta z zestawu SF następnej wersji platformy. Odbywa się to za pomocą obu następujących kroków:

  • Usunięcie compatibility_matrix.V.xml z reguł kompilacji (aby nie był instalowany w obrazie systemu) oraz usunięcie dowolnego kodu, który implementował usuniętą funkcjonalność lub od niej zależał.
  • Usunięcie warstw HAL platformy z max-level niższym lub równym V z manifestu platformy oraz usunięcie dowolnego kodu, który implementuje usunięte warstwy HAL platformy.

Urządzenia z docelową wersją FCM poza SF dla danej wersji platformy nie mogą dokonać aktualizacji do tej wersji.

Stan wersji HAL

W poniższych sekcjach opisano (w porządku chronologicznym) możliwe stany wersji HAL.

Niewydany

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

  • Podczas opracowywania systemu Android 9 warstwa HAL health@2.0 była uważana za niewydaną warstwę HAL i była obecna tylko w compatibiility_matrix.3.xml .
  • teleportation@1.0 HAL nie znajduje się w żadnych wydanych macierzach zgodności i jest również uważany za niewydaną warstwę HAL.

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

Wydany i aktualny

W przypadku warstw HAL urządzeń, jeśli wersja HAL znajduje się w dowolnej publicznej i zamrożonej macierzy zgodności, zostaje zwolniona. Na przykład po zamrożeniu wersji 3 FCM i opublikowaniu jej w AOSP warstwa HAL health@2.0 jest uważana za wydaną i aktualną wersję HAL.

Jeśli wersja HAL znajduje się w publicznej i zamrożonej macierzy zgodności, która ma najwyższą wersję FCM, wersja HAL jest aktualna (tj. 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 zwolnione i aktualne wersje HAL.

W przypadku ramowych warstw HAL, jeśli wersja HAL znajduje się w manifeście platformy ostatniej wydanej gałęzi bez atrybutu max-level lub (nietypowo) max-level równego lub wyższego niż wersja FCM wydana w tej gałęzi, jest uważana za wydaną i aktualną wersję HAL. Na przykład displayservice HAL jest wydana i aktualna w systemie Android 12, jak określono w pliku Android 12framework manifest .

Wydany, ale przestarzały

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

  • Zostaje wydany.
  • To nie jest w publicznej i zamrożonej macierzy kompatybilności, która ma najwyższą wersję FCM.
  • Struktura nadal obsługuje publiczną i zamrożoną macierz kompatybilności.

Przykłady:

Dlatego power@1.0 jest aktualne, ale NIE jest przestarzałe, w Androidzie 9.

W przypadku warstw HAL platformy, jeśli wersja HAL znajduje się w manifeście struktury ostatnio wydanej gałęzi z atrybutem max-level niższym niż wersja FCM wydana w tej gałęzi, jest uważana za wydaną, ale przestarzałą wersję HAL. Na przykład schedulerservice HAL została wydana, ale jest przestarzała w systemie Android 12, jak określono w pliku Android 12framework manifest .

REMOVED

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

  • Został wydany wcześniej.
  • Nie ma go w żadnej publicznej i zamrożonej macierzy kompatybilności obsługiwanej przez platformę.

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, aby można było pisać testy VTS w celu upewnienia 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ł wydany wcześniej.
  • Nie ma go w żadnym ramowym manifeście najnowszej wydanej gałęzi.

Starsze FCM

Starsza wersja Target FCM to specjalna wartość dla wszystkich urządzeń innych niż Treble. Starszy FCM, compatibility_matrix.legacy.xml ”, zawiera listę wymagań platformy na starszych urządzeniach (tj. urządzeniach wprowadzonych na rynek przed Androidem 8.0).

Jeśli ten plik istnieje dla FCM w wersji F , każde urządzenie inne niż Treble można uaktualnić do F , pod warunkiem, że jego manifest urządzenia jest zgodny z tym plikiem. Jego usunięcie przebiega zgodnie z tą samą procedurą, co FCM dla innych docelowych wersji FCM (usunięte, gdy liczba aktywnych urządzeń wcześniejszych niż 8.0 spadnie poniżej określonego progu).

Wydane wersje FCM

Listę wydanych wersji FCM można znaleźć w hardware/interfaces/compatibility_matrices .

Aby znaleźć wersję FCM wydaną z określoną wersją systemu Android, zobacz Level.h .