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
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 platformy 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 (z SF ), wyraźnie zadeklarowana w manifeście urządzenia, że implementacja dostawcy spełnia wymagania. Implementacja dostawcy musi zostać wygenerowana na podstawie opublikowanego FCM, chociaż może on deklarować nowsze wersje warstwy HAL w swoim manifeście urządzenia. |
Wersja HAL | Wersja HAL ma format foo@xy , gdzie foo to nazwa warstwy HAL, a xy to konkretna wersja; np. nfc@1.0 , keymaster@3.0 (główny prefiks, np. android.hardware , jest pomijany w całym 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 Target 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 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
:
- Skopiuj najnowszą
compatibility_matrix.current.xml
compatibility_matrix.<F-1>.xml
do compliance_matrix.current.xml . - Zaktualizuj atrybut
level
w pliku doF
. - 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 zV = F
muszą być uruchamiane z tą warstwą HAL,
LUB -
optional="true"
jeśli urządzenia dostarczane zV = 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)
ioptional="false"
. - Nie jest to wymagane na urządzeniach uruchamianych z
V = F
,compatibility_matrix.current.xml
musi skopiowaćxy-z
i opcjonalność zcompatibility_matrix.<F-1>.xml
i zmienić wersję naxw-(z+1)
(gdziew >= 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 wersjix.0
, jeśli urządzenia dostarczane zV = F
muszą być uruchamiane zx.0
. -
optional="false"
, ale wraz ze starszymi wersjami głównymi w tym samym tagu<hal>
, jeśli urządzenia dostarczane zV = F
muszą być uruchamiane z tą warstwą HAL, ale mogą być uruchamiane ze starszą wersją główną. -
optional="true"
jeśli urządzenia dostarczane zV = 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
zoptional="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:
- Zmień nazwę
compatibility_matrix.current.xml
nacompatibility_matrix.F.xml
. - Upewnij się, że plik ma atrybut
level="F"
. - Edytuj odpowiednie reguły kompilacji, aby odzwierciedlić zmianę nazwy pliku.
- Upewnij się, że wszystkie urządzenia są budowane i uruchamiane.
- Zaktualizuj testy VTS, aby upewnić się, że urządzenia uruchamiane z najnowszą platformą (opartą na poziomie Shipping API) mają docelową wersję FCM
V >= F
. - 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ównymV
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ę nacompatibility_matrix.3.xml
), warstwa HALhealth@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ę wcompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
icompatibility_matrix.2.xml
, ale nie wcompatibility_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 wcompatibility_matrix.3.xml
.-
power@1.0
znajduje się wcompatibility_matrix.2.xml
,compatibility_matrix.legacy.xml
, icompatibility_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
.