Rozwój manifestu urządzenia

Podczas opracowywania i wydawania nowych urządzeń dostawcy mogą definiować i deklarować docelową wersję FCM w manifeście urządzenia (DM). Podczas uaktualniania obrazu dostawcy dla starych urządzeń dostawcy mogą zdecydować się na zaimplementowanie nowych wersji warstwy HAL i zwiększenie docelowej wersji FCM.

Opracowywanie nowych urządzeń

Podczas definiowania urządzenia Docelowa wersja FCM dla nowych urządzeń:

  1. Leave DEVICE_MANIFEST_FILE i PRODUCT_ENFORCE_VINTF_MANIFEST niezdefiniowane.
  2. Implementuj warstwy HAL dla docelowej wersji FCM.
  3. Napisz poprawny plik manifestu urządzenia.
  4. Zapisz docelową wersję FCM w pliku manifestu urządzenia.
  5. Zestaw DEVICE_MANIFEST_FILE .
  6. Zestaw PRODUCT_ENFORCE_VINTF_MANIFEST się true .

Wydawanie nowych urządzeń

Kiedy nowe urządzenie zostanie zwolniony, jego początkowa docelowa FCM Wersja musi być określony i ogłoszony w manifeście urządzenia jako „ target-level ” atrybutu w górnym poziomie <manifest> elementu.

Na przykład urządzenia uruchamiane z systemem Android 9 muszą mieć docelową wersję FCM równą 3 (w tej chwili dostępna jest wyższa wersja). Aby zadeklarować to w manifeście urządzenia:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Aktualizowanie obrazu dostawcy

Podczas uaktualniania obrazu dostawcy dla starego urządzenia dostawcy mogą zdecydować się na zaimplementowanie nowych wersji HAL i zwiększenie docelowej wersji FCM.

Uaktualnianie HAL

Podczas uaktualniania obrazu dostawcy dostawcy mogą wdrażać nowe wersje warstwy HAL pod warunkiem, że nazwa warstwy HAL, nazwa interfejsu i nazwa wystąpienia są takie same. Na przykład:

  • Google Pixel 2 i Pixel 2 XL uwalniane z urządzenia docelowego FCM Version 2, który realizowany jest wymagane dźwięku 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default .
  • Dla dźwięku 4.0 HAL że wydany z Androidem 9, Google i urządzenia Pixel 2 Pixel 2 XL mogą korzystać z pełnej OTA upgrade do 4.0 HAL, który realizuje android.hardware.audio@4.0::IDeviceFactory/default .
  • Chociaż compatibility_matrix.2.xml określa tylko dźwięk 2.0, wymaganie na obrazie sprzedawca z docelowymi FCM Wersja 2 została poluzowana, ponieważ Android 9 ramy (FCM Wersja 3) uważa dźwięku 4.0 zastąpienie dźwięku 2.0 HAL pod względem funkcjonalności .

Podsumowując, biorąc pod uwagę, że compatibility_matrix.2.xml wymaga dźwięku 2.0 i compatibility_matrix.3.xml wymaga dźwięku 4.0, wymagania są następujące:

Wersja FCM (system) Docelowa wersja FCM (dostawca) Wymagania
2 (8.1) 2 (8.1) Dźwięk 2.0
3 (9) 2 (8.1) Dźwięk 2.0 lub 4.0
3 (9) 3 (9) Dźwięk 4.0

Aktualizacja docelowej wersji FCM

Podczas uaktualniania obrazu dostawcy dostawcy mogą również zwiększyć docelową wersję FCM, aby określić docelową wersję FCM, z którą uaktualniony obraz dostawcy może współpracować. Aby podbić docelową wersję FCM urządzenia, dostawcy muszą:

  1. Zaimplementuj wszystkie nowe wymagane wersje HAL dla docelowej wersji FCM.
  2. Zmodyfikuj wersje HAL w pliku manifestu urządzenia.
  3. Zmodyfikuj docelową wersję FCM w pliku manifestu urządzenia.
  4. Usuń przestarzałe wersje HAL.

Na przykład urządzenia Google Pixel i Pixel XL uruchomione z systemem Android 7.0, więc ich docelowa wersja FCM musi być co najmniej starsza. Jednak oczywisty urządzenie deklaruje docelowa FCM Wersja 2 ponieważ obraz sprzedawca został zaktualizowany do zgodne z compatibility_matrix.2.xml :

<manifest version="1.0" type="device" target-level="2">

Jeśli dostawcy nie zaimplementują wszystkich wymaganych nowych wersji HAL lub nie usuną przestarzałych wersji HAL, nie można uaktualnić docelowej wersji FCM.

Na przykład, urządzenia Google Pixel 2 i Pixel 2 XL mają docelowa FCM wersji 2. Podczas robią wdrożyć pewne warstwy HAL wymaganych przez compatibility_matrix.3.xml (takich jak audio, 4,0, 2,0 zdrowia, etc.), ale nie usuwają android.hardware.radio.deprecated@1.0 , co nie jest zalecany w FCM w wersji 3 (Mobile 9). Dlatego te urządzenia nie mogą uaktualnić docelowej wersji FCM do 3.

Narzucanie wymagań jądra podczas OTA

Aktualizowanie urządzeń z systemu Android 9 lub starszego

Na urządzeniach z Androidem 9 lub starszym upewnij się, że wybrane są następujące CL:

Zmiany te wprowadzają build flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS i pozostawić rozbrojony flaga dla urządzeń uruchamianych z Androidem 9 lub niższej.

  • Podczas aktualizacji do systemu Android 10 klienci OTA na urządzeniach z systemem Android 9 lub niższym nie sprawdzają prawidłowo wymagań jądra w pakiecie OTA. Te zmiany są potrzebne, aby usunąć wymagania jądra z wygenerowanego pakietu OTA.
  • Po aktualizacji do Androida 11, to jest opcjonalne ustawienie PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS flagę build, aby sprawdzić kompatybilność VINTF gdy pakiet aktualizacji jest generowany.

Aby uzyskać więcej informacji na temat tej kompilacji flagi, patrz urządzeń z Androidem 10 Aktualizacja .

Aktualizowanie urządzeń z Androida 10

Android 10 wprowadza się nowy build flag, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . W przypadku urządzeń z Androidem rozpoczętych 10, ta flaga jest ustawiana automatycznie na true . Gdy flaga jest ustawiona na true , skrypt pobiera wersję jądra i konfiguracji jądra z zainstalowanym obrazem jądra.

  • Podczas aktualizacji do Androida 10 pakiet aktualizacji OTA zawiera wersję jądra i konfigurację. Klienci OTA na urządzeniach z Androidem 10 czytają te informacje, aby sprawdzić zgodność.
  • Podczas aktualizacji do Androida 11 gatunkowanie pakietów OTA odczytuje wersję jądra i konfigurację w celu sprawdzenia zgodności.

Jeśli skrypt nie wyodrębnić tę informację dla obrazu jądra, wykonaj jedną z następujących czynności:

  • Edytuj skrypt, aby obsługiwał format jądra i współpracował z AOSP.
  • Zestaw BOARD_KERNEL_VERSION wersji jądra i BOARD_KERNEL_CONFIG_FILE na ścieżce zbudowany jądra plik konfiguracyjny .config . Obie zmienne muszą zostać zaktualizowane podczas aktualizacji obrazu jądra.
  • Alternatywnie, zestaw PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS do false , aby pominąć sprawdzanie wymagań jądra. Nie jest to zalecane, ponieważ wszelkie niezgodności są ukryte i wykrywane tylko podczas uruchamiania testów VTS po aktualizacji.

Można zobaczyć kod źródłowy jądra informacyjnego skryptu ekstrakcji extract_kernel.py .