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 wdrożenie 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. Pozostaw 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. Ustaw DEVICE_MANIFEST_FILE .
6. Ustaw PRODUCT_ENFORCE_VINTF_MANIFEST na true .

Wydawanie nowych urządzeń

Po wydaniu nowego urządzenia jego początkowa docelowa wersja FCM musi zostać określona i zadeklarowana 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 (aktualnie dostępna wyższa wersja). Aby to zadeklarować 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 wdrożenie nowych wersji HAL i zwiększyć docelową wersję FCM.

Aktualizowanie 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:

• Urządzenia Google Pixel 2 i Pixel 2 XL wydane z Target FCM w wersji 2, które zaimplementowały wymaganą warstwę audio 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default .
• W przypadku warstwy 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 uaktualnienia 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 docelowym FCM w wersji 2 zostały poluzowane, 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:

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 manifest urządzenia deklaruje docelową wersję FCM w wersji 2, ponieważ obraz dostawcy został zaktualizowany, aby był compatibility_matrix.2.xml z compliance_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ą Target FCM w wersji 2. Chociaż implementują niektóre warstwy HAL wymagane przez compatibility_matrix.3.xml (takie jak audio 4.0, zdrowie 2.0 itp.), nie usuwają sprzętu android.hardware.radio.deprecated@1.0 . 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 3.

Narzucanie wymagań jądra podczas OTA

Aktualizowanie urządzeń z Androida 9 lub starszego

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

• CL 722283
• CL 722284
• CL 722345

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

• Podczas aktualizacji do systemu Android 10 klienci OTA na urządzeniach z systemem Android 9 lub niższym nie sprawdzają poprawnie wymagań jądra w pakiecie OTA. Te zmiany 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 podczas generowania 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

Android 10 wprowadza 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 systemu Android 10 pakiet aktualizacji OTA zawiera wersję i konfigurację jądra. Klienci OTA na urządzeniach z systemem Android 10 czytają te informacje, aby sprawdzić zgodność.
• Podczas aktualizacji do systemu Android 11 gatunkowanie pakietów OTA odczytuje wersję jądra i konfigurację w celu sprawdzenia zgodności.

Jeśli skryptowi nie uda się 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ółpracował z AOSP.
• Ustaw BOARD_KERNEL_VERSION na wersję jądra i BOARD_KERNEL_CONFIG_FILE na ścieżkę do 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ż wszelkie niezgodności są ukryte i są wykrywane tylko podczas uruchamiania testów VTS po aktualizacji.

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