Rozwój manifestu urządzenia, rozwój manifestu urządzenia

Podczas opracowywania i wypuszczania nowych urządzeń dostawcy mogą definiować i deklarować docelową wersję FCM w manifeście urządzenia (DM). Aktualizując obraz dostawcy dla starych urządzeń, dostawcy mogą zdecydować się na wdrożenie nowych wersji HAL i zwiększenie docelowej wersji FCM.

Opracowywanie nowych urządzeń

Podczas definiowania docelowej wersji FCM urządzenia dla nowych urządzeń:

  1. Pozostaw DEVICE_MANIFEST_FILE i PRODUCT_ENFORCE_VINTF_MANIFEST niezdefiniowane.
  2. Zaimplementuj warstwy HAL dla docelowej wersji FCM.
  3. Zapisz poprawny plik manifestu urządzenia.
  4. Zapisz docelową wersję FCM w pliku manifestu urządzenia.
  5. Ustaw DEVICE_MANIFEST_FILE .
  6. Ustaw PRODUCT_ENFORCE_VINTF_MANIFEST na true .

Wypuszczanie nowych urządzeń

Po wydaniu nowego urządzenia należy określić jego początkową docelową wersję FCM i zadeklarować w manifeście urządzenia jako atrybut „ target-level ” w elemencie <manifest> najwyższego poziomu.

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

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

Uaktualnianie wizerunku dostawcy

Aktualizując obraz dostawcy dla starego urządzenia, dostawcy mogą zdecydować się na wdrożenie nowych wersji HAL i zwiększenie docelowej wersji FCM.

Aktualizacja HAL

Podczas aktualizacji obrazu dostawcy dostawcy mogą wdrożyć nowe wersje HAL, pod warunkiem, że nazwa HAL, nazwa interfejsu i nazwa instancji są takie same. Na przykład:

  • Urządzenia Google Pixel 2 i Pixel 2 XL wydane z Target FCM w wersji 2, które zaimplementowały wymaganą wersję audio 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default .
  • W przypadku wersji audio 4.0 HAL wydanej z systemem Android 9 urządzenia Google Pixel 2 i Pixel 2 XL mogą korzystać z pełnej wersji OTA w celu aktualizacji do wersji 4.0 HAL, która implementuje android.hardware.audio@4.0::IDeviceFactory/default .
  • Mimo że compatibility_matrix.2.xml określa tylko dźwięk 2.0, wymagania dotyczące obrazu dostawcy z Target FCM w wersji 2 zostały złagodzone, ponieważ platforma Android 9 (FCM wersja 3) traktuje dźwięk 4.0 jako zamiennik audio 2.0 HAL pod względem funkcjonalności .

Podsumowując, biorąc pod uwagę, że compatibility_matrix.2.xml wymaga audio 2.0, a compatibility_matrix.3.xml wymaga audio 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 aktualizacji obrazu dostawcy dostawcy mogą również zwiększyć docelową wersję FCM, aby określić docelową wersję FCM, z którą może współpracować zaktualizowany obraz dostawcy. 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 działają z systemem Android 7.0, więc ich docelowa wersja FCM musi być co najmniej starsza. Jednak w manifeście urządzenia deklarowana jest docelowa wersja FCM 2, ponieważ obraz dostawcy został zaktualizowany w celu zapewnienia zgodności 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ą przestarzałych wersji HAL, nie będzie można zaktualizować docelowej wersji FCM.

Na przykład urządzenia Google Pixel 2 i Pixel 2 XL mają docelową wersję FCM 2. Chociaż implementują niektóre warstwy HAL wymagane przez compatibility_matrix.3.xml (takie jak audio 4.0, health 2.0 itp.), nie usuwają android.hardware.radio.deprecated@1.0 , który jest przestarzały w wersji 3 FCM (Android 9). Dlatego te urządzenia nie mogą zaktualizować docelowej wersji FCM do wersji 3.

Obowiązkowe wymagania jądra podczas OTA

Aktualizowanie urządzeń z Androidem 9 lub starszym

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

Te zmiany wprowadzają flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS i pozostawiają flagę nieustawioną dla urządzeń z systemem Android 9 lub starszym.

  • Podczas aktualizacji do Androida 10 klienci OTA na urządzeniach z Androidem 9 lub starszym nie sprawdzają poprawnie wymagań jądra w pakiecie OTA. Zmiany te są potrzebne, aby usunąć wymagania jądra z wygenerowanego pakietu OTA.
  • Podczas aktualizacji do systemu Android 11 opcjonalne jest ustawienie flagi kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS , aby sprawdzić zgodność z VINTF po wygenerowaniu pakietu aktualizacji.

Aby uzyskać więcej informacji na temat tej flagi kompilacji, zobacz Aktualizowanie urządzeń z systemu Android 10 .

Aktualizowanie urządzeń z Androida 10

W systemie Android 10 wprowadzono nową flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . W przypadku urządzeń z systemem Android 10 ta flaga jest automatycznie ustawiana na true . Gdy flaga jest ustawiona na 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 systemem Android 10 czytają te informacje, aby sprawdzić kompatybilność.
  • Podczas aktualizacji do Androida 11, gatunek pakietu OTA odczytuje wersję jądra i konfigurację, aby sprawdzić kompatybilność.

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

  • Edytuj skrypt, aby obsługiwał format jądra i współtwórz AOSP.
  • Ustaw BOARD_KERNEL_VERSION na wersję jądra i BOARD_KERNEL_CONFIG_FILE na ścieżkę zbudowanego pliku konfiguracyjnego jądra .config . Obie zmienne muszą zostać zaktualizowane podczas aktualizacji obrazu jądra.
  • Alternatywnie ustaw PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS na false , aby pominąć sprawdzanie wymagań jądra. Nie jest to zalecane, ponieważ jakakolwiek niezgodność jest ukryta i wykryta dopiero po uruchomieniu testów VTS po aktualizacji.

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