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ń:
- Pozostaw
DEVICE_MANIFEST_FILE
iPRODUCT_ENFORCE_VINTF_MANIFEST
niezdefiniowane. - Zaimplementuj warstwy HAL dla docelowej wersji FCM.
- Zapisz poprawny plik manifestu urządzenia.
- Zapisz docelową wersję FCM w pliku manifestu urządzenia.
- Ustaw
DEVICE_MANIFEST_FILE
. - Ustaw
PRODUCT_ENFORCE_VINTF_MANIFEST
natrue
.
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ą:
- Zaimplementuj wszystkie nowe wymagane wersje HAL dla docelowej wersji FCM.
- Zmodyfikuj wersje HAL w pliku manifestu urządzenia.
- Zmodyfikuj docelową wersję FCM w pliku manifestu urządzenia.
- 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 iBOARD_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
nafalse
, 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
.