Tworzenie pliku manifestu urządzenia

Podczas opracowywania i wprowadzania na rynek nowych urządzeń dostawcy mogą zdefiniować i zadeklarować docelową wersję FCM w pliku manifestu urządzenia (DM). Podczas uaktualniania obrazu dostawcy na starszych urządzeniach dostawcy mogą wdrożyć nowe wersje HAL i zwiększyć wersję docelową FCM.

opracowywanie nowych urządzeń,

Podczas określania wersji FCM, na którą mają być kierowane reklamy na nowych urządzeniach:

  1. Pozostaw wartości DEVICE_MANIFEST_FILE i PRODUCT_ENFORCE_VINTF_MANIFEST niezdefiniowane.
  2. Wdróż warstwy HAL dla docelowej wersji FCM.
  3. Napisz prawidłowy plik manifestu urządzenia.
  4. Zapisz docelową wersję FCM w pliku manifestu urządzenia.
  5. Ustaw DEVICE_MANIFEST_FILE.
  6. Ustaw wartość PRODUCT_ENFORCE_VINTF_MANIFEST na true.

Wprowadzanie na rynek nowych urządzeń

Gdy na rynek wchodzi nowe urządzenie, należy określić jego początkową docelową wersję FCM i zadeklarować ją w manifeście urządzenia jako atrybut „target-level” w elemencie najwyższego poziomu <manifest>.

Na przykład urządzenia z Androidem 9 muszą mieć docelową wersję FCM równą 3 (najwyższą dostępną obecnie wersję). Aby zadeklarować to w manifeście urządzenia:

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

Uaktualnianie obrazu dostawcy

Podczas uaktualniania obrazu dostawcy na starszym urządzeniu dostawcy mogą wdrożyć nowe wersje HAL i zwiększyć docelową wersję FCM.

Uaktualnianie HAL-i

Podczas uaktualniania obrazu dostawcy mogą wdrażać nowe wersje HAL, pod warunkiem że nazwa HAL, nazwa interfejsu i nazwa instancji są takie same. Przykład:

  • Telefony Google Pixel 2 i Pixel 2 XL zostały wydane z docelową wersją FCM 2, która implementowała wymagany interfejs HAL audio 2.0android.hardware.audio@2.0::IDeviceFactory/default.
  • W przypadku interfejsu HAL audio 4.0, który został wydany wraz z Androidem 9, urządzenia Google Pixel 2 i Pixel 2 XL mogą używać pełnej aktualizacji OTA, aby przejść na interfejs HAL 4.0, który implementuje android.hardware.audio@4.0::IDeviceFactory/default.
  • Mimo że compatibility_matrix.2.xml określa tylko dźwięk 2.0, wymaganie dotyczące obrazu dostawcy z docelową wersją FCM 2 zostało złagodzone, ponieważ platforma Androida 9 (wersja FCM 3) uważa dźwięk 4.0 za zamiennik interfejsu HAL dźwięku 2.0 pod względem funkcjonalności.

Podsumowując, ponieważ compatibility_matrix.2.xml wymaga dźwięku w wersji 2.0, a compatibility_matrix.3.xml – w wersji 4.0, wymagania 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) Dźwięk 2.0 lub 4.0
3 (9) 3 (9) Dźwięk 4.0

Docelowa wersja FCM do uaktualnienia

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

  1. Wdróż 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ń wycofane wersje HAL.

Na przykład urządzenia Google Pixel i Pixel XL zostały wprowadzone na rynek z Androidem 7.0, więc ich docelowa wersja FCM musi być co najmniej starsza. Jednak plik manifestu urządzenia deklaruje docelową wersję FCM 2, ponieważ obraz dostawcy został zaktualizowany zgodnie z compatibility_matrix.2.xml:

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

Jeśli dostawcy nie wdrożą wszystkich wymaganych nowych wersji HAL lub nie usuną wycofanych wersji HAL, nie będzie można uaktualnić docelowej wersji FCM.

Na przykład urządzenia Google Pixel 2 i Pixel 2 XL mają docelową wersję FCM 2. Wdrażają one niektóre warstwy HAL wymagane przez compatibility_matrix.3.xml (np. audio 4.0, health 2.0 itp.), ale nie usuwają android.hardware.radio.deprecated@1.0, który jest przestarzały w wersji FCM 3 (Android 9). Dlatego nie można na nich uaktualnić docelowej wersji FCM do wersji 3.

Wymagania dotyczące jądra podczas aktualizacji OTA

Aktualizowanie urządzeń z Androidem 9 lub starszym

Na urządzeniach z Androidem 9 lub starszym sprawdź, czy te zmiany są wybrane:

Wprowadzamy w nich flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS, a w przypadku urządzeń wprowadzonych na rynek z Androidem 9 lub starszym pozostawiamy flagę nieustawioną.

  • Podczas aktualizacji do Androida 10 klienty OTA na urządzeniach z Androidem 9 lub starszym nie sprawdzają prawidłowo wymagań dotyczących jądra w pakiecie OTA. Te zmiany są potrzebne, aby usunąć wymagania dotyczące jądra z wygenerowanego pakietu OTA.
  • Podczas aktualizacji do Androida 11 możesz ustawić flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS, aby sprawdzić zgodność VINTF podczas generowania pakietu aktualizacji.

Więcej informacji o tej fladze kompilacji znajdziesz w artykule Aktualizowanie urządzeń z Androidem 10.

Aktualizowanie urządzeń z Androidem 10

Android 10 wprowadza nową flagę kompilacji, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. W przypadku urządzeń wprowadzonych na rynek z Androidem 10 ten flag jest automatycznie ustawiany na true. Gdy flaga ma wartość true, skrypt wyodrębnia wersję jądra i konfiguracje jądra z zainstalowanego obrazu jądra.

  • Podczas aktualizacji do Androida 10 pakiet aktualizacji OTA zawiera wersję jądra i konfigurację. Klienci OTA na urządzeniach z Androidem 10 odczytują te informacje, aby sprawdzić zgodność.
  • Podczas aktualizacji do Androida 11 generowanie pakietu OTA odczytuje wersję jądra i konfigurację, aby sprawdzić zgodność.

Jeśli skrypt nie może wyodrębnić tych informacji z obrazu jądra, wykonaj jedną z tych czynności:

  • Edytuj skrypt, aby obsługiwał format jądra, i prześlij go do AOSP.
  • Ustaw BOARD_KERNEL_VERSION na wersję jądra, a BOARD_KERNEL_CONFIG_FILE na ścieżkę do skompilowanego pliku konfiguracji jądra .config. Obie zmienne muszą zostać zaktualizowane po zaktualizowaniu obrazu jądra.
  • Możesz też ustawić wartość PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS na false, aby pominąć sprawdzanie wymagań dotyczących jądra. Nie zalecamy tego, ponieważ wszelkie niezgodności są ukryte i wykrywane dopiero podczas przeprowadzania testów VTS po aktualizacji.

Możesz wyświetlić kod źródłowy skryptu wyodrębniania informacji o jądrzeextract_kernel.py.