Obiekt interfejsu dostawcy

W tym dokumencie opisano projekt obiektu interfejsu dostawcy ( obiekt VINTF), który agreguje istotne informacje o urządzeniu i udostępnia te informacje za pośrednictwem interfejsu API, z którym można korzystać .

Projektowanie obiektów VINTF

Obiekt VINTF zbiera niektóre potrzebne informacje bezpośrednio z urządzenia. Inne aspekty, takie jak manifesty, są opisane statycznie w XML.

Rysunek 1. Manifesty, macierze zgodności i informacje gromadzone w czasie wykonywania

Projekt obiektu VINTF zapewnia następujące elementy dla komponentów urządzenia i struktury:

Do urządzenia W przypadku ram
  • Definiuje schemat dla składnika statycznego ( plik manifestu urządzenia ).
  • Dodaje obsługę czasu kompilacji w celu zdefiniowania pliku manifestu urządzenia dla danego urządzenia.
  • Definiuje interfejs API z możliwością zapytania w czasie wykonywania, który pobiera plik manifestu urządzenia (wraz z innymi informacjami gromadzonymi w czasie wykonywania) i pakuje je do wyniku zapytania.

Obiekt VINTF musi być niezawodny i zapewniać te same kompletne informacje niezależnie od tego, kiedy obiekt jest żądany (zobacz Ostrzeżenia ).

Manifesty i matryce

Począwszy od systemu Android 8.0, interfejs API środowiska wykonawczego pyta, co jest na urządzeniu i wysyła te informacje do serwera aktualizacji OTA (Over-the-Air) i innych zainteresowanych stron (takich jak CTS DeviceInfo ). Niektóre informacje są pobierane w czasie wykonywania, a niektóre są definiowane statycznie.

  • Manifest urządzenia opisuje statyczny składnik tego, co urządzenie może dostarczyć do struktury.
  • Macierz zgodności struktury opisuje, czego platforma Android oczekuje od danego urządzenia. Macierz to statyczna jednostka, której skład jest określany ręcznie podczas opracowywania kolejnej wersji platformy Android.
  • Manifest platformy opisuje usługi wysokiego poziomu, które platforma może zapewnić urządzeniu.
  • Macierz zgodności urządzeń opisuje usługi, których obraz dostawcy wymaga od struktury. Jego skład jest określany ręcznie podczas opracowywania urządzenia.

Te dwie pary manifestów i macierzy muszą zostać uzgodnione w czasie OTA, aby zapewnić urządzeniu możliwość pobierania aktualizacji struktury zgodnych z możliwościami urządzenia. Ogólnie rzecz biorąc, manifest opisuje, co jest dostarczane, a macierz zgodności opisuje, co jest wymagane.

Ta sekcja zawiera następujące szczegóły dotyczące manifestów i macierzy:

  • Manifesty definiują manifest urządzenia, manifest platformy i schemat pliku manifestu.
  • Macierze zgodności definiują schemat macierzy zgodności.
  • Cykl życia FCM zawiera szczegółowe informacje o tym, jak HIDL HAL są przestarzałe i usuwane oraz jak pliki FCM są modyfikowane w celu odzwierciedlenia stanu wersji HAL.
  • DM Development opisuje, w jaki sposób dostawcy mogą definiować i deklarować docelową wersję FCM w manifeście urządzenia dla nowych urządzeń lub wdrażać nowe wersje HAL i zwiększać docelową wersję FCM podczas uaktualniania obrazu dostawcy dla starych urządzeń.
  • Reguły dopasowania definiują reguły udanego dopasowania między macierzą zgodności a manifestem.