Włącz VNDK

Pakiet programistyczny Vendor Native Development Kit (VNDK) wymaga wprowadzenia kilku zmian w kodzie źródłowym, aby oddzielić problemy dostawcy od problemów systemu. Aby włączyć VNDK w bazie kodu dostawcy/OEM, skorzystaj z tego przewodnika.

Tworzenie bibliotek systemowych

System kompilacji zawiera kilka typów obiektów, w tym biblioteki (wspólne, statyczne i z nagłówkiem) oraz pliki binarne.

Tworzenie bibliotek systemowych

Rysunek 1. tworzyć biblioteki systemowe.

  • core biblioteki są używane przez obraz systemu. Bibliotek tych nie mogą używać biblioteki vendor, vendor_available, vndk ani vndk-sp. 
    cc_library {
    name: "libThatIsCore",
    ...
}
  • Biblioteki vendor-only (lub proprietary) są używane przez obraz dostawcy na obrazie dostawcy. 
    cc_library {
    name: "libThatIsVendorOnly",
    proprietary: true,
    # or: vendor: true, # (for things in AOSP)
    ...
}
  • Biblioteki vendor_available są używane przez obraz dostawcy (może zawierać duplikaty core). 
    cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
  • vndk biblioteki są używane przez obraz dostawcy na obrazie systemowym. 
    cc_library {
    name: "libThatIsVndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    }
    ...
}
  • Biblioteki vndk-sp są używane przez obraz dostawcy, a także pośrednio przez obraz systemu. 
    cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}
  • Biblioteki llndk są używane zarówno przez obrazy systemowe, jak i obrazy dostawcy. 
    cc_library {
    name: "libThatIsLlndk",
    llndk: {
        symbol_file: "libthatisllndk.map.txt"
    }
    ...
}

Gdy biblioteka jest oznaczona jako vendor_available:true, jest kompilowana dwukrotnie:

  • Raz na platformę (czyli zainstalowana na /system/lib)
  • raz dla dostawcy (czyli zainstalowany w /vendor/lib lub VNDK APEX);

Wersje bibliotek dostawcy są tworzone za pomocą pakietu -D__ANDROID_VNDK__. Ten parametr wyłącza prywatne komponenty systemu, które mogą się znacznie zmienić w przyszłych wersjach Androida. Ponadto różne biblioteki eksportują inny zestaw nagłówków (np. liblog). Opcje specyficzne dla wariantu dostawcy celu można określić w pliku Android.bp w następujących miejscach:

target: { vendor: { … } }

Włączanie VNDK w przypadku kodu źródłowego

Aby włączyć VNDK dla kodu źródłowego:

  1. Określ, czy spełniasz wymagania, obliczając wymagane rozmiary partycji vendor.img i system.img.
  2. Włącz BOARD_VNDK_VERSION=current. Możesz dodawać do BoardConfig.mk lub budować komponenty bezpośrednio z BoardConfig.mk (np. m -j BOARD_VNDK_VERSION=current MY-LIB).

Po włączeniu BOARD_VNDK_VERSION=current system kompilacji egzekwuje te wymagania dotyczące zależności i nagłówków.

Zarządzanie zależnościami

Obiekt vendor, który zależy od komponentu core, który nie istnieje w vndk lub jako obiekt vendor, musi zostać rozwiązany za pomocą jednej z tych opcji:

  • Można usunąć zależność.
  • Jeśli element core należy do vendor, może być oznaczony jako vendor_available lub vendor.
  • Zmiana, która powoduje, że obiekt podstawowy staje się częścią vndk, może zostać przesłana do Google.

Jeśli ponadto komponent core ma zależności od komponentu vendor, komponent vendor musi zostać przekształcony w komponent core lub zależność musi zostać usunięta w inny sposób (np. przez usunięcie zależności lub przeniesienie jej do komponentu vendor).

Zarządzanie nagłówkami

Globalne zależności nagłówka muszą zostać usunięte, aby system kompilacji wiedział, czy ma skompilować nagłówki z użyciem -D__ANDROID_VNDK__, czy bez niego. Dostęp do nagłówków libutils, takich jak utils/StrongPointer.h, można nadal uzyskać za pomocą biblioteki nagłówków libutils_headers.

Niektórych nagłówków (np. unistd.h) nie można już uwzględniać pośrednio, ale można je uwzględnić lokalnie.

Na koniec publiczna część usługi private/android_filesystem_config.h została przeniesiona do usługi cutils/android_filesystem_config.h. Aby zarządzać tymi nagłówkami, wykonaj jedną z tych czynności:

  • Usuń zależność od funkcji private/android_filesystem_config.h, zastępując wszystkie makra AID_* wywołaniami funkcji getgrnam lub getpwnam (jeśli to możliwe). Na przykład:
    • (uid_t)AID_WIFI zmienia się na getpwnam("wifi")->pw_uid.
    • (gid_t)AID_SDCARD_R zmienia się na getgrnam("sdcard_r")->gr_gid.
    Więcej informacji znajdziesz w artykule private/android_filesystem_config.h.
  • W przypadku zakodowanego w zgłoszeniu AIS podaj:cutils/android_filesystem_config.h.