Podczas opracowywania i publikowania nowych urządzeń dostawcy mogą zdefiniować i zadeklarować docelową wersję FCM w pliku manifestu urządzenia (DM). Uaktualnianie obrazu dostawcy W przypadku starych urządzeń dostawcy mogą wdrożyć nowe wersje HAL i zwiększać docelową wersję FCM.
Tworzenie nowych urządzeń
Podczas określania docelowej wersji FCM dla nowych urządzeń:
- Wyjdź z:
DEVICE_MANIFEST_FILE
i Nie zdefiniowanoPRODUCT_ENFORCE_VINTF_MANIFEST
. - Wdróż HAL dla docelowej wersji FCM.
- Zapisz poprawny plik manifestu urządzenia.
- Zapisz docelową wersję FCM w pliku manifestu urządzenia.
- Ustaw
DEVICE_MANIFEST_FILE
. - Ustaw
PRODUCT_ENFORCE_VINTF_MANIFEST
natrue
.
Publikowanie nowych urządzeń
Po wprowadzeniu na rynek nowego urządzenia jego początkowa wersja docelowa FCM musi być
określone i zadeklarowane w pliku manifestu urządzenia jako
„target-level
” atrybut najwyższego poziomu
<manifest>
.
Na przykład urządzenia z Androidem 9 muszą docelowa wersja FCM to 3 (wyższa wersja, która jest obecnie dostępna). Aby zadeklarować to w pliku manifestu urządzenia:
<manifest version="1.0" type="device" target-level="3"> <!-- ... --> </manifest>
Uaktualnij obraz dostawcy
Podczas aktualizacji obrazu dostawcy starego urządzenia dostawcy mogą zaimplementuj nowe wersje HAL i zwiększ docelową wersję FCM.
Uaktualnij HAL
Podczas uaktualniania obrazu dostawcy dostawcy mogą wdrażać nowe wersje HAL pod warunkiem, że nazwa HAL, nazwa interfejsu i nazwa instancji są takie same. Dla: przykład:
- Premiery urządzeń Google Pixel 2 i Pixel 2 XL z docelową wersją FCM
2, która wdrożyła wymagany kod HAL audio 2.0.
android.hardware.audio@2.0::IDeviceFactory/default
- W przypadku interfejsu HAL audio 4.0 wydanego wraz z Androidem
9, Google Pixel 2 i Pixel 2 XL mogą korzystać
pełne aktualizacje OTA do wersji HAL 4.0, która udostępnia
android.hardware.audio@4.0::IDeviceFactory/default
- Mimo że
compatibility_matrix.2.xml
określa dźwięk 2.0 wymaga tylko, aby obraz dostawcy z docelowym FCM w wersji 2 był wymagany. ponieważ platforma Androida 9 (wersja FCM) 3) pod względem funkcjonalności uznaje audio 4.0 za zamiennik HAL audio 2.0.
Podsumowując, biorąc pod uwagę, że compatibility_matrix.2.xml
wymaga
audio 2.0 i compatibility_matrix.3.xml
wymaga dźwięku 4.0,
są następujące:
Wersja FCM (system) | Docelowa wersja FCM (dostawca) | Wymagania |
---|---|---|
2 (8.1) | 2 (8.1) | Audio 2.0 |
3 (9) | 2 (8.1) | Audio 2.0 lub 4.0 |
3 (9) | 3 (9) | Audio 4.0 |
Uaktualnij docelową wersję FCM
Podczas uaktualniania obrazu dostawcy dostawcy mogą też zwiększyć docelową wartość FCM. wersji, by określić docelową wersję FCM, z którą może działać uaktualniony obraz dostawcy. z naszymi usługami. Aby zmienić docelową wersję urządzenia w FCM, dostawcy muszą:
- Wdróż wszystkie nowe wersje HAL wymagane dla docelowej wersji FCM.
- Zmodyfikuj wersje HAL w pliku manifestu urządzenia.
- Zmień docelową wersję FCM w pliku manifestu urządzenia.
- Usuń wycofane wersje HAL.
Na przykład urządzenia Google Pixel i Pixel XL wprowadzone na rynek z Androidem 7.0
więc ich docelowa wersja FCM musi być co najmniej starsza. Jednak urządzenie
manifest deklaruje docelową wersję FCM w wersji 2, ponieważ obraz dostawcy zawiera
zaktualizowano w celu dostosowania do wymagań compatibility_matrix.2.xml
:
<manifest version="1.0" type="device" target-level="2">
Jeśli dostawcy nie wdrażają wszystkich wymaganych nowych wersji HAL lub nie usuwają wycofane wersje HAL, docelowej wersji FCM nie można uaktualnić.
Na przykład urządzenia Google Pixel 2 i Pixel 2 XL mają docelowy system FCM w wersji 2.
Mimo że wdrażają pewne HAL wymagane przez
compatibility_matrix.3.xml
(np. audio 4.0, stan 2.0 itp.),
nie usuwają android.hardware.radio.deprecated@1.0
, czyli
wycofane w FCM w wersji 3 (Android 9). Z tego powodu
urządzeń nie można uaktualnić docelowej wersji FCM do wersji 3.
Obowiązywanie wymagań dotyczących jądra podczas OTA
Aktualizowanie urządzeń z Androidem 9 lub starszym
Na urządzeniach z Androidem 9 lub starszym upewnij się, że te listy zmian są prawidłowe wybór wiśni:
Te zmiany wprowadzają flagę kompilacji
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
i opuszczaj
flaga nieskonfigurowana w przypadku urządzeń z Androidem 9 lub
obniżysz się.
- Podczas aktualizowania Androida do wersji 10 klienty OTA na urządzeniach z Androidem 9, nie sprawdzają poprawnie wymagań jądra w pakiecie OTA. Te zmiany są konieczne, aby usunąć wymagania jądra z wygenerowanej aktualizacji OTA pakietu SDK.
-
Przy aktualizacji do Androida 11 możesz opcjonalnie ustawić
Flaga kompilacji
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
do sprawdzenia VINTF zgodność podczas generowania pakietu aktualizacji.
Więcej informacji o tej flagi kompilacji znajdziesz w artykule Aktualizowanie urządzeń z Androida 10.
Aktualizowanie urządzeń z Androidem 10
Android 10 wprowadza nową flagę kompilacji,
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
Urządzenia
na Androidzie 10, ta flaga to
automatycznie ustawiona na true
. Gdy flaga jest ustawiona na
true
, skrypt wyodrębnia wersję jądra i jądro.
z obrazu zainstalowanego jądra.
- W przypadku Androida 10 pakiet aktualizacji OTA zawiera wersji i konfiguracji jądra systemu operacyjnego. klienty OTA na urządzeniach z Androidem, 10 przeczytaj te informacje, aby sprawdzić, zgodność.
- Gatunek pakietu OTA podczas aktualizowania do Androida 11 odczytuje wersję i konfigurację jądra, aby sprawdzić zgodność.
Jeśli nie uda się wyodrębnić skryptu te informacje do obrazu jądra wykonaj jedną z następujące:
- Edytuj skrypt, aby obsługiwał format jądra i wspieraj AOSP.
- Ustaw
BOARD_KERNEL_VERSION
na wersję jądra iBOARD_KERNEL_CONFIG_FILE
na ścieżkę utworzonego jądra systemu.config
. Musisz zaktualizować obie zmienne po zaktualizowaniu obrazu jądra. - Możesz też ustawić
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
dofalse
, aby pominąć sprawdzanie wymagań jądra. Nie jest to zalecane, ponieważ wszelkie niezgodności są ukryte i wykrywane tylko podczas przeprowadzania testów VTS po aktualizacji.
Możesz wyświetlić kod źródłowy skryptu wyodrębniania informacji o jądrze
extract_kernel.py