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 określają, z czego może korzystać platforma, oraz 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 umożliwić 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

Programowanie w nowej wersji FCM

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

Aby rozpocząć programowanie w nowej wersji FCM F :

1. Skopiuj najnowszą compatibility_matrix.current.xml compatibility_matrix.<F-1>.xml do compliance_matrix.current.xml .
2. Zaktualizuj atrybut level w pliku do 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 F FCM, dodaj warstwę HAL do pliku compatibility_matrix.current.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ą zostać uruchomione bez tej warstwy HAL.

Na przykład Android 8.1 wprowadził cas@1.0 jako opcjonalną warstwę HAL. Urządzenia uruchamiane z systemem Android 8.1 nie są wymagane do zaimplementowania tej warstwy HAL, więc następujący wpis został dodany do compatibility_matrix.current.xml (po wydaniu systemu Android 8.1 zmieniono jego nazwę na compatibility_matrix.2.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 warstwy HAL (drobna)

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

• Wymagany na urządzeniach uruchamianych z V = F , compatibility_matrix.current.xml musi zawierać x.(z+1) i optional="false" .
• Nie jest to wymagane na urządzeniach uruchamianych z V = F , compatibility_matrix.current.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 system Android 8.1 wprowadził broadcastradio@1.1 jako pomniejszą 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 pliku compatibility_matrix.current.xml (zmienionego na compatibility_matrix.2.xml po wydaniu Androida 8.1) 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>

Aktualizacja HAL (główna)

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

• option optional="false" tylko w wersji 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 tagu <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 system Android 9 wprowadza health@2.0 jako aktualizację głównej wersji warstwy HAL 1.0 i wycofuje warstwę HAL 1.0. Starsza wersja, health@1.0 , jest opcjonalna dla urządzeń z systemem Android 8.0 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.2.xml , compatibility_matrix.legacy.xml i compatibility_matrix.1.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 pliku compatibility_matrix.current.xml (zmieniony na compatibility_matrix.3.xml w wersji Android 9) i zmodyfikowany 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ż 2.0 HAL jest w compatibility_matrix.3.xml z optional="false" , urządzenia uruchamiane z Androidem 9 muszą być dostarczane z 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ą udostępniać warstwy HAL 1.0 (ponieważ ta warstwa HAL jest uważana za przestarzałą).
• Ponieważ warstwa HAL 1.0 jest obecna 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ą HAL 1.0 (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. Zmień nazwę compatibility_matrix.current.xml na compatibility_matrix.F.xml .
2. Upewnij się, że plik ma atrybut level="F" .
3. Edytuj odpowiednie reguły kompilacji, aby odzwierciedlić zmianę nazwy pliku.
4. Upewnij się, że wszystkie urządzenia są budowane i uruchamiane.
5. Zaktualizuj testy VTS, aby upewnić się, że urządzenia uruchamiane z najnowszą platformą (opartą na poziomie Shipping API) mają docelową wersję FCM V >= F .
6. Opublikuj plik w AOSP.

Tego pliku nie można zmienić po zmianie nazwy i opublikowaniu. Na przykład podczas tworzenia systemu Android 9 budowane są następujące pliki dla hardware/interfaces/compatibility_matrices/ :

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

Po wydaniu systemu Android 9 nazwa compatibility_matrix.3.xml compatibility_matrix.current.xml a następujące pliki zostały zbudowane dla hardware/interfaces/compatibility_matrices/ :

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

Testy VTS zapewniają, że urządzenia uruchamiane z systemem Android 9 mają docelową wersję FCM >= 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 wersji FCM 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

Gdy dane urządzenie HAL foo@xy jest przestarzałe w wersji FCM F , oznacza to, że każde urządzenie uruchamiane z docelową wersją FCM V = F lub nowszą nie może implementować foo w wersji xy lub jakiejkolwiek wersji starszej niż xy . Przestarzała wersja warstwy HAL jest nadal obsługiwana przez platformę uaktualniania 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 wprowadzane 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żany za przestarzały.

Wycofaj framework HAL

Gdy dana platforma HAL foo@xy jest przestarzała w wersji FCM F , oznacza to, że każde urządzenie uruchamiane z docelową wersją FCM V = F lub nowszą nie może oczekiwać, że struktura dostarczy 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ń.

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 , framework nie zapewnia HAL foo@xy . Macierz zgodności urządzeń na urządzeniach uruchamianych z V = F nie może wyświetlać ramowych warstw HAL z max-level < V .

Na przykład w systemie Android 12 schedulerservice@1.0 jest przestarzały. Jego atrybut max-level jest ustawiony na 5 , wersja FCM wprowadzona w Androidzie 11. Zobacz manifest platformy Android 12 .

Usunięcie wsparcia dla docelowych wersji FCM

Gdy aktywne urządzenia określonej docelowej wersji FCM V spadną poniżej określonego progu, docelowa wersja FCM jest usuwana z zestawu _SF następnej wersji platformy. Odbywa się to w obu następujących krokach:

• Usunięcie compatibility_matrix.V.xml z reguł kompilacji (aby nie było zainstalowane w obrazie systemu) i usunięcie dowolnego kodu, który zaimplementował lub zależał od usuniętej funkcjonalności.
• Usuwanie warstw HAL platformy z max-level niższym lub równym V z manifestu platformy i usuwanie dowolnego kodu, który implementuje usunięte warstwy HAL platformy.

Urządzenia z docelową wersją FCM poza _SF dla danej wersji frameworka nie mogą 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 warstwy HAL, które znajdują się tylko w compatibility_matrix.current.xml . Przykłady:

• Podczas opracowywania systemu Android 9 (zanim compatibiility_matrix.current.xml zmieniono nazwę na compatibility_matrix.3.xml ), warstwa HAL health@2.0 była uważana za niepublikowaną warstwę HAL.
• teleportation@1.0 HAL nie znajduje się w żadnej opublikowanej macierzy kompatybilności i jest również uważany za niewydany 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 warstwy HAL znajduje się w dowolnej publicznej i zamrożonej macierzy zgodności, zostaje ona wydana. Na przykład po zamrożeniu FCM w wersji 3 (gdy compatibiility_matrix.current.xml zmieniono nazwę na compatibility_matrix.3.xml ) i opublikowaniu w AOSP, HAL health@2.0 jest uważany za wydaną i aktualną wersję warstwy HAL.

Jeśli wersja warstwy HAL znajduje się w publicznej i zamrożonej macierzy zgodności, która ma najwyższą wersję FCM (z wyłączeniem compatibility_matrix.current.xml ), wersja warstwy 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 wydane i bieżące wersje HAL.

W przypadku ramowych warstw HAL, jeśli wersja HAL znajduje się w manifeście frameworka najnowszej wydanej gałęzi bez atrybutu max-level lub (co jest rzadkością) z max-level równym lub wyższym niż wersja FCM wydana w tej gałęzi, jest uważana za wydaną i aktualna wersja HAL. Na przykład, displayservice HAL został wydany i jest aktualny w systemie Android 12, zgodnie z 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:

• HAL health@1.0 znajduje się w compatibility_matrix.legacy.xml , compatibility_matrix.1.xml i compatibility_matrix.2.xml , ale nie w compatibility_matrix.3.xml . Dlatego jest uważany za przestarzały w Androidzie 9.
• Power HAL ma mniejszą wersję w systemie Android 9, ale power@1.0 jest nadal w compatibility_matrix.3.xml .
  • power@1.0 znajduje się w compatibility_matrix.2.xml , compatibility_matrix.legacy.xml , i compatibility_matrix.1.xml .
  • power@1.0-1 compatibility_matrix.3.xml

Stąd power@1.0 jest aktualny, ale NIE przestarzały, w Androidzie 9.

W przypadku ramowych warstw HAL, jeśli wersja warstwy HAL znajduje się w manifeście platformy najnowszej 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ę warstwy HAL. Na przykład warstwa HAL usługi schedulerservice została wydana, ale przestarzała w systemie Android 12, zgodnie z 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ł wcześniej wydany.
• 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ł wcześniej wydany.
• Nie ma go w żadnym manifeście frameworku w najnowszej wydanej gałęzi.

Starsze modele FCM

Dziedzictwo docelowej wersji FCM to specjalna wartość dla wszystkich urządzeń innych niż Treble. Starszy FCM, compatibility_matrix.legacy.xml , zawiera listę wymagań struktury na starszych urządzeniach (tj. urządzeniach uruchomionych przed Androidem 8.0).

Jeśli ten plik istnieje dla FCM w wersji F , każde urządzenie inne niż Treble może zostać uaktualnione do F , pod warunkiem, że jego manifest urządzenia jest zgodny 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

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

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