Tworzenie pliku manifestu urządzenia

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Podczas opracowywania i wydawania nowych urządzeń sprzedawcy mogą definiować i deklarować docelową wersję FCM w pliku manifestu urządzenia (DM). Podczas aktualizacji obrazu dostawcy na starszych urządzeniach dostawcy mogą wdrożyć nowe wersje HAL i zwiększyć docelowa wersję FCM.

opracowywać nowe urządzenia;

Podczas definiowania wersji docelowej FCM na nowe urządzenia:

1. Pozostaw wartości DEVICE_MANIFEST_FILE i PRODUCT_ENFORCE_VINTF_MANIFEST nieokreślone.
2. Wdrożyć pliki HAL dla docelowej wersji FCM.
3. Utwórz prawidłowy 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.

publikowanie nowych urządzeń;

Gdy zostanie wydane nowe urządzenie, należy określić jego początkową docelową wersję FCM i zadeklarować ją w pliku manifestu 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 3 (wyższą wersję dostępną w danym momencie). Aby zadeklarować to w pliku manifestu urządzenia:

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

Aktualizowanie obrazu dostawcy

Podczas uaktualniania obrazu dostawcy na starym urządzeniu dostawcy mogą zaimplementować nowe wersje HAL i zwiększyć wersję docelową FCM.

Uaktualnianie HAL-i

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

• Urządzenia Google Pixel 2 i Pixel 2 XL z docelową wersją FCM 2, która zawiera wymagany interfejs audio HAL 2.0.android.hardware.audio@2.0::IDeviceFactory/default
• W przypadku interfejsu audio HAL 4.0, który został wydany wraz z Androidem 9, urządzenia Google Pixel 2 i Pixel 2 XL mogą korzystać z pełnej aktualizacji OTA, aby przejść na interfejs audio HAL 4.0, który implementuje android.hardware.audio@4.0::IDeviceFactory/default.
• Chociaż w compatibility_matrix.2.xml określono tylko interfejs audio 2.0, wymagania dotyczące obrazu dostawcy z docelową wersją FCM 2 zostały złagodzone, ponieważ w ramach Androida 9 (wersja FCM 3) interfejs audio 4.0 zastępuje interfejs audio HAL 2 pod względem funkcjonalności.

Podsumowując, ponieważ compatibility_matrix.2.xml wymaga audio 2.0, a compatibility_matrix.3.xml wymaga audio 4.0, wymagania są następujące:

Uaktualnianie docelowej wersji FCM

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

1. Wdrożyć wszystkie nowe wymagane wersje HAL dla docelowej wersji FCM.
2. Zmień 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, aby był zgodny 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 uaktualnić docelowej wersji FCM.

Na przykład urządzenia Google Pixel 2 i Pixel 2 XL mają docelową wersję FCM 2. Chociaż implementują one niektóre interfejsy HAL wymagane przez compatibility_matrix.3.xml (np. audio 4.0, health 2.0 itp.), nie usuwają interfejsu android.hardware.radio.deprecated@1.0, który został wycofany w wersji 3 interfejsu FCM (Android 9). Dlatego na tych urządzeniach nie można 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 wersje są wybrane:

• CL 722283
• CL 722284
• CL 722345

Te zmiany wprowadzają flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS i pozostawiają flagę niezdefiniowaną na urządzeniach z Androidem w wersji 9 lub starszej.

• Podczas aktualizacji do Androida 10 klienci OTA na urządzeniach z Androidem 9 lub starszym nie sprawdzają poprawnie wymagań 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 opcjonalnie ustawić flagę kompilacji PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS, aby sprawdzić zgodność z VINTF podczas generowania pakietu aktualizacji.

Więcej informacji o tej opcji 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. Na urządzeniach z Androidem 10 ten parametr jest automatycznie ustawiany na true. Gdy flaga jest ustawiona natrue, 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ę i konfigurację jądra. Klienci OTA na urządzeniach z Androidem 10 odczytują te informacje, aby sprawdzić zgodność.
• Podczas aktualizacji do Androida 11 generowanie pakietu OTA odczytuje wersję i konfigurację jądra, aby sprawdzić zgodność.

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

• Zmodyfikuj skrypt, aby obsługiwał format jądra, i prześlij go do AOSP.
• Ustaw BOARD_KERNEL_VERSION na wersję jądra i BOARD_KERNEL_CONFIG_FILE na ścieżkę do skompilowanego pliku konfiguracji jądra (.config). Obie zmienne muszą zostać zaktualizowane, gdy obraz jądra zostanie zaktualizowany.
• 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 zostają wykryte dopiero podczas uruchamiania testów VTS po aktualizacji.

Kod źródłowy skryptu do wyodrębniania informacji o rdzeniu można wyświetlić tutaj: extract_kernel.py.