為何要使用 VNDK？

VNDK的全稱是Vendor Native Development Kit，是Android 8.0引入的一種新技術(shù)。它表現(xiàn)一系列庫的合集，用于讓供應商開發(fā)自己的HALs。VNDK 包含在 system.img 中，并在運行時與供應商代碼動態(tài)關(guān)聯(lián)。

官方文檔的解釋給我的感覺其目的就是收斂Android的碎片化。不僅僅VNDK，Android 8.0引入許多的技術(shù)都是為了將System與Vendor分割開來。這樣可以保持Android核心系統(tǒng)的純凈性，而將碎片化扔給供應商維護。漸漸的芯片供應商和設(shè)備廠商可以無需關(guān)心Android系統(tǒng)的實現(xiàn)，僅僅使用VNDK就可以完成產(chǎn)品開發(fā)。

VNDK相關(guān)概念

供應商模塊

供應商模塊是特定于供應商的可執(zhí)行文件或共享庫，這些模塊將安裝到供應商分區(qū)中。

• 在 Android.bp 文件中，供應商模塊必須將vendor或proprietary屬性設(shè)置為 true。
• 在 Android.mk 文件中，供應商模塊必須將 LOCAL_VENDOR_MODULE 或 LOCAL_PROPRIETARY_MODULE 設(shè)置為 true。

Framework共享庫

在理想的Android 8.0及更高版本環(huán)境中，F(xiàn)ramework進程不加載供應商共享庫，而供應商進程僅加載供應商共享庫（和一部分Framework共享庫）。Framework進程與供應商進程之間的通信由HIDL和hardware binder控制。

供應商進程需要使用Framework共享庫可能隨系統(tǒng)的更新而發(fā)生變化。為了保證供應商模塊在多個Android版本上皆可正常工作，根據(jù)Framework共享庫的特性不同，將其三個子類別：

• LL-NDK庫：已知穩(wěn)定的Framework共享庫，它們的開發(fā)者致力于保持其 API/ABI 穩(wěn)定性。LL-NDK 包含以下庫：libEGL.so、libGLESv1_CM.so、libGLESv2.so、libGLESv3.so、libandroid_net.so、libc.so、libdl.so、liblog.so、libm.so、libnativewindow.so、libneuralnetworks.so、libsync.so、libvndksupport.so 和 libvulkan.so。

• 合格的 VNDK 庫 (VNDK)：可以安全復制兩次的Framework共享庫。Framework模塊和供應商模塊可以與其各自的庫副本相關(guān)聯(lián)。Framework共享庫只有滿足以下條件才能成為合格的 VNDK 庫：

  • 不向Framework發(fā)送或從Framework接收 IPC。
  • 與 ART 虛擬機無關(guān)。
  • 不讀寫文件格式不穩(wěn)定的文件/分區(qū)。
  • 沒有需要法律審查的特殊軟件許可。
  • 其代碼所有者不反對供應商使用該庫。

• 框架專用庫 (FWK-ONLY) ：不屬于上述類別的Framework共享庫。此類庫具有以下特點：

  • 被視為Framework內(nèi)部實現(xiàn)細節(jié)。
  • 不得由供應商模塊訪問。
  • 具有不穩(wěn)定的 ABI/API，無 API/ABI 兼容性保證。
  • 不會被復制。

LL-NDK

LL-NDK 共享庫是具有穩(wěn)定 ABI 的共享庫?？蚣苣K和供應商模塊均具有相同的最新實現(xiàn)。對于每個 LL-NDK 共享庫，Android.bp 都包含一個 llndk_library 模塊定義：

llndk_library {
    name: "libvndksupport",
    symbol_file: "libvndksupport.map.txt",
}

該模塊定義指定了模塊名稱和符號文件，后者描述了對供應商模塊可見的符號。例如：

LIBVNDKSUPPORT {
  global:
    android_load_sphal_library; # vndk
    android_unload_sphal_library; # vndk
  local:
    *;
};

Same-Process HAL (SP-HAL)

Same-Process HAL (SP-HAL) 是預定義的的一組HAL，作為供應商共享庫進行實現(xiàn)，并被加載到Framework進程中。SP-HAL 必須僅依賴于 LL-NDK 和 VNDK-SP。VNDK-SP 是一部分預定義的符合條件的 VNDK 庫。VNDK-SP 庫會被仔細審查，以確保將 VNDK-SP 庫雙重加載到Framework進程中不會導致問題。SP-HAL 和 VNDK-SP 均由 Google 定義，并通過鏈接器命名空間進行隔離。

以下庫是經(jīng)過批準的 SP-HAL：

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• android.hardware.renderscript@1.0-impl.so
• android.hardware.graphics.mapper@2.0-impl.so

以下庫是 SP-HAL 可以訪問的 VNDK-SP 庫：

• android.hardware.graphics.common@1.0.so
• android.hardware.graphics.mapper@2.0.so
• android.hardware.renderscript@1.0.so (Renderscript)
• libRS_internal.so (Renderscript)
• libbase.so
• libc++.so
• libcutils.so
• libhardware.so
• libhidlbase.so
• libhidltransport.so
• libhwbinder.so
• libion.so
• libutils.so
• libz.so

以下 VNDK-SP 依賴項 (VNDK-SP-Private) 對 SP-HAL 來說是不可見的：

• libRSCpuRef.so (Renderscript)
• libRSDriver.so (Renderscript)
• libbacktrace.so
• libblas.so (Renderscript)
• libbcinfo.so (Renderscript)
• liblzma.so
• libunwind.so

以下是具有 RS 例外的框架專用庫 (FWK-ONLY-RS)：

• libft2.so (Renderscript)
• libmediandk.so (Renderscript)

VNDK 庫簡介

VNDK 定義了可與供應商代碼相關(guān)聯(lián)的庫集：VNDK-core、VNDK-SP 和 LL-NDK，并阻止供應商使用不在 VNDK 集內(nèi)的庫。

VNDK-core 庫安裝在 /system/lib[64]/vndk-${VER} 中，僅適用于 API 級別為 ${VER} 的供應商進程。${VER} 可以通過/vendor/default.prop中的系統(tǒng)屬性ro.vndk.version獲取。系統(tǒng)進程不得使用這些庫，而必須使用安裝在 /system/lib[64] 中的庫。由于每個進程都具有嚴格的命名空間限制，因此不會造成重復加載 VNDK-core 庫。要在 VNDK-core 中添加庫，請將以下內(nèi)容添加到 Android.bp 中：

vendor_available: true,
vndk: {
    enabled: true,
},

VNDK-SP 庫安裝在 /system/lib[64]/vndk-sp-${VER} 中，可以被供應商進程和系統(tǒng)進程（通過安裝在供應商分區(qū)中的 SP-HAL 庫）使用。VNDK-SP 庫可以重復加載。要在 VNDK-SP 中添加庫，請將以下內(nèi)容添加到 Android.bp 中：

vendor_available: true,
vndk: {
    enabled: true,
    support_system_process: true,
},

LL-NDK 庫安裝在 /system/lib[64] 中。供應商模塊可以使用 LL-NDK stub訪問 LL-NDK 庫的預選符號。LL-NDK 庫必須支持向后兼容，且具有 ABI 穩(wěn)定性，以便舊版供應商模塊使用新版 LL-NDK 庫。由于 LL-NDK 具有 ABI 穩(wěn)定特性，VNDK 快照無需包含舊版供應商映像的 LL-NDK 庫。

目錄

VNDK庫可以大致劃分為以下目錄：

• /system/lib[64] 包含所有Framework共享庫，具體包括 LL-NDK、VNDK 和Framework專用庫（包括 LL-NDK-Private 和一些與 VNDK-SP 中的庫同名的庫）。
• /system/lib[64]/vndk-sp 包含適用于 Same-Process HAL 的 VNDK-SP 庫。
• /vendor/lib[64] 包含供應商擴展的 VNDK 庫（DXUA 庫或 DXUX VNDK 庫）、Same-Process HAL 實現(xiàn)，以及其他供應商共享庫。
• /vendor/lib[64]/vndk-sp 可能包含供應商擴展的 VNDK-SP 庫。

供應商模塊從 /system/lib[64] 中加載 VNDK 庫。

VNDK 電子表格

Google 會提供一個符合條件的 VNDK 電子表格（例如 eligible-list.csv），該電子表格會標記可由供應商模塊使用的框架共享庫：

下表描述了適用于供應商共享庫的標記：

標記之間的關(guān)系：

VNDK 快照

VNDK 快照就是一組預編譯的庫文件和配置文件的集合。因為VNDK的實質(zhì)就是要規(guī)范供應商的開發(fā)，如果保證VNDK接口穩(wěn)定的標準化，供應商就無需修改VNDK庫。系統(tǒng)只要提供所有VNDK版本的二進制文件，就可以滿足供應商的開發(fā)。這些需求的文件就是VNDK快照需要提供的內(nèi)容。

VNDK 快照包含以下文件：

• VNDK-core 和 VNDK-SP 共享庫的供應商變體。

  • 無需 LL-NDK 共享庫，因為這類庫是向后兼容的。
  • 對于 64 位目標，TARGET_ARCH 和 TARGET_2ND_ARCH 庫都將被編譯并包含在內(nèi)。
• VNDK-core、VNDK-SP、LL-NDK 和 VNDK-private 庫的列表，文件為 [vndkcore|vndksp|llndk|vndkprivate].libraries.txt。
• 鏈接器配置文件為 ld.config.txt。
• 許可文件。
• module_paths.txt。記錄所有 VNDK 庫的模塊路徑；檢查 GPL 項目是否已在指定 Android 源代碼樹中發(fā)布源代碼時，需要用到這種文件。

以下示例展示了 arm64 (TARGET_ARCH=arm64) VNDK 快照 ZIP 文件 (android-vndk-arm64.zip) 的目錄結(jié)構(gòu)。

供應商鏡像會依賴于特定版本的VNDK，所以系統(tǒng)鏡像中應該提供供應商需求的VNDK版本的鏡像。即使系統(tǒng)鏡像與供應商鏡像使用不同版本的Android進行編譯，但是只要保證系統(tǒng)鏡像能夠提供正確的VNDK就保證正常運行。下圖展示了Android P系統(tǒng)鏡像使用Android O供應商鏡像的場景。

啟用 VNDK

編譯選項

在 BoardConfig.mk添加BOARD_VNDK_VERSION=current可以在編譯過程開啟VNDK。也可以在編譯模塊時傳遞該編譯選項，例如： m -j BOARD_VNDK_VERSION=current MY-LIB）。

當啟用 BOARD_VNDK_VERSION=current 后，編譯系統(tǒng)會檢查庫的依賴性和頭文件的合法性。

• 確保vendor對象僅依賴于VNDK庫集：VNDK-core、VNDK-SP 和 LL-NDK。確保core組件不依賴與vendor組件。
• 移除全局頭文件的依賴項，以便編譯器可以明確是否使用-D__ANDROID_VNDK__來編譯頭文件。就是說全局頭文件無法再使用傳遞方式包含在頭文件內(nèi)。

啟用 BOARD_VNDK_VERSION后，系統(tǒng)會移除多個默認的全局頭文件搜索路徑。模塊使用這些路徑下的頭文件時，需要明確指定與 header_libs、static_libs 和/或 shared_libs 的依賴關(guān)系。這些路徑中包括：

• frameworks/av/include
• frameworks/native/include
• frameworks/native/opengl/include
• hardware/libhardware/include
• hardware/libhardware_legacy/include
• hardware/ril/include
• libnativehelper/include
• libnativehelper/include_deprecated
• system/core/include
• system/media/audio/include

供應商變體庫

在 Android.bp 文件中，cc_library、cc_library_static、cc_library_shared 和 cc_library_headers 模塊定義支持三個與 VNDK 相關(guān)的屬性：vendor_available、vndk.enabled 和 vndk.support_system_process。

如果 一個庫標記為vendor_available 或 vndk.enabled 為 true，則可能被編譯兩次，生成兩種變體：核心變體和供應商變體。

• 核心變體被視為Framework模塊，將安裝到 /system/lib[64] 中。
• 而供應商變體應被視為供應商模塊。系統(tǒng)根據(jù)模塊依賴性來決定是否編譯變體，并進行依賴性檢查。供應商變體安裝路徑會根據(jù) Android.bp中的屬性來決定。

下表總結(jié)了編譯系統(tǒng)如何處理供應商變體，

注意：供應商可以為其模塊設(shè)置 vendor_available，但不得設(shè)置 vndk.enabled 和 vndk.support_system_process，因為供應商模塊無法在通用系統(tǒng)映像 (GSI) 中找到它們。

條件編譯

默認情況下，Android 編譯系統(tǒng)會為供應商變體和 VNDK 擴展定義 __ANDROID_VNDK__。您可以使用 C 預處理器防護程序保護代碼：

void all() { }

#if !defined(__ANDROID_VNDK__)
void framework_only() { }
#endif

#if defined(__ANDROID_VNDK__)
void vndk_only() { }
#endif

除了 __ANDROID_VNDK__，還可以在 Android.bp 中指定不同的 cflags 或 cppflags。在 target.vendor 中指定的 cflags 或 cppflags 是專門針對供應商變體的。

例如，以下 Android.bp 定義了 libexample 和 libexample_ext。它為libexample的供應商變體定義了"LIBEXAMPLE_ENABLE_VNDK=1"，為libexample的擴展庫定義了 "LIBEXAMPLE_ENABLE_VNDK=1" 和"LIBEXAMPLE_ENABLE_VNDK_EXT=1"。

cc_library {
    name: "libexample",
    srcs: ["src/example.c"],
    vendor_available: true,
    vndk: {
        enabled: true,
    },
    target: {
        vendor: {
            cflags: ["-DLIBEXAMPLE_ENABLE_VNDK=1"],
        },
    },
}

cc_library {
    name: "libexample_ext",
    srcs: ["src/example.c"],
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libexample",
    },
    cflags: [
        "-DLIBEXAMPLE_ENABLE_VNDK=1",
        "-DLIBEXAMPLE_ENABLE_VNDK_EXT=1",
    ],
}

VNDK 擴展

Android還提供了VNDK擴展的方法，就是使用自己修改的VNDK共享庫來替換原始的VNDK共享庫。因為供應商很可能根據(jù)自己的需求來更改AOSP庫的源碼，可能是為了提高性能，或者添加新鉤子、新 API 或新功能。VNDK 擴展庫會安裝到 /vendor/lib[64]/vndk[-sp] 中，并在系統(tǒng)運行時會替換原始的 VNDK 共享庫。

在 Android 9 及更高版本中，Android.bp 本身支持 VNDK 擴展。要編譯 VNDK 擴展，請定義另一個具有 vendor:true 和 extends 屬性的模塊：

cc_library {
    name: "libvndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    },
}

cc_library {
    name: "libvndk_ext",
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libvndk",
    },
}

具有 vendor:true、vndk.enabled:true 和 extends 屬性的模塊可定義 VNDK 擴展：

• extends 屬性必須指定基礎(chǔ) VNDK 共享庫名稱（或 VNDK-SP 共享庫名稱）。
• VNDK 擴展（或 VNDK-SP 擴展）以擴展時所基于的基礎(chǔ)模塊名稱命名。例如，libvndk_ext 的輸出二進制文件是 libvndk.so，而非 libvndk_ext.so。
• VNDK 擴展將安裝到 /vendor/lib[64]/vndk 中。
• VNDK-SP 擴展將安裝到 /vendor/lib[64]/vndk-sp 中。
• 基礎(chǔ)共享庫必須同時具有 vndk.enabled:true 和 vendor_available:true。

VNDK-SP 擴展必須從 VNDK-SP 共享庫進行擴展，就是說在定義時必須包含相同的vndk.support_system_process 。VNDK 擴展（或 VNDK-SP 擴展）也可以依賴于其他供應商共享庫：

cc_library {
    name: "libvndk_sp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    },
}

cc_library {
    name: "libvndk_sp_ext",
    vendor: true,
    vndk: {
        enabled: true,
        extends: "libvndk_sp",
        support_system_process: true,
    shared_libs: [
        "libvendor",
    ],
}

cc_library {
    name: "libvendor",
    vendor: true,
}

如果供應商模塊依賴于由 VNDK 擴展定義的其他 API，則該模塊必須在其 shared_libs 屬性中指定 VNDK 擴展的名稱：

// A vendor shared library example
cc_library {
    name: "libvendor",
    vendor: true,
    shared_libs: [
        "libvndk_ext",
    ],
}

// A vendor executable example
cc_binary {
    name: "vendor-example",
    vendor: true,
    shared_libs: [
        "libvndk_ext",
    ],
}

如果供應商模塊依賴于 VNDK 擴展，則這些 VNDK 擴展將自動安裝到 /vendor/lib[64]/vndk[-sp] 中。如果某個模塊不再依賴于 VNDK 擴展，請向 CleanSpec.mk 添加一個清理步驟，以移除共享庫。例如：

$(call add-clean-step, rm -rf $(TARGET_OUT_VENDOR)/lib/libvndk.so)

規(guī)則和Sepolicy

VNDK 規(guī)則

完整的 VNDK 規(guī)則列表如下。

• 框架進程不得從供應商分區(qū)中加載非 SP-HAL 共享庫（此規(guī)則從 Android 8.1 開始嚴格地強制實施）。
• 供應商進程不得從系統(tǒng)分區(qū)中加載非 LL-NDK 庫、非 VNDK-SP 庫和非 VNDK 庫（Android O 中并未嚴格地強制實施此規(guī)則，但未來版本中會這么做）。
• 注意：要想從未來版本（比 Android 8.0 更高的版本）僅針對框架的 OTA 中受益，就不得在搭載 Android 8.0 出廠的設(shè)備中違反此規(guī)則。
• 已安裝的 VNDK 庫必須是由 Google 定義的合格 VNDK 庫的子集。

• SP-HAL 和 SP-HAL-Dep 的外部依賴項必須僅限于 LL-NDK 庫或由 Google 定義的 VNDK-SP 庫。

  • SP-HAL 共享庫的依賴項必須僅限于 LL-NDK 庫、由 Google 定義的 VNDK-SP 庫、其他 SP-HAL 庫和/或可標記為 SP-HAL-Dep 庫的其他供應商共享庫。
  • 只有當供應商共享庫不是 AOSP 庫，且其依賴項僅限于 LL-NDK 庫、由 Google 定義的 VNDK-SP 庫、SP-HAL 庫和/或其他 SP-HAL-Dep 庫時，才可標記為 SP-HAL-Dep 庫。
• VNDK-SP 必須保持獨立。在 Android 8.0 中，系統(tǒng)以一種特殊方式處理 libRS_internal.so，但在未來版本中，其處理方式會被重新考慮。
• 不得通過非 HIDL 接口（包括但不限于 Binder、套接字、共享內(nèi)存、文件等）進行框架-供應商通信。
• 系統(tǒng)分區(qū)必須足夠大，以便容納所有符合條件的 VNDK 庫的兩個副本，以及不符合條件的框架共享庫的一個副本。

sepolicy

本部分中介紹的框架進程對應于 sepolicy 中的 coredomain，而供應商進程對應于 non-coredomain。例如，/dev/binder 只能在 coredomain 中被訪問，而 /dev/vndbinder 只能在非 coredomain 中被訪問。

類似政策會限制對系統(tǒng)分區(qū)和供應商分區(qū)上的共享庫的訪問。下表列出了訪問不同類別的共享庫時所需的權(quán)限：

LL-NDK-Private 和 VNDK-SP-Private 必須從這兩個域中都可訪問，因為非 coredomain 會間接訪問這些庫。同樣，SP-HAL-Dep 必須可從 coredomain 訪問，因為 SP-HAL 依賴該域。

same_process_hal_file 標簽

供應商分區(qū)中包含下面幾個庫。確保這些庫既可以從 coredomain 訪問，又可以從非 coredomain 訪問。

• VNDK-SP-Ext，位于 /vendor/lib[64]/vndk-sp
• SP-HAL，位于 /vendor/lib[64] 或 /vendor/lib[64]/hw
• SP-HAL-Dep，位于 /vendor/lib[64] 或 /vendor/lib[64]/hw

將這些文件明確標記為 same_process_hal_file。因為在默認情況下，從 coredomain 無法訪問 vendor 分區(qū)中的任何內(nèi)容。請向供應商特定的 file_contexts 文件中添加與以下命令行類似的命令行：

/vendor/lib(64)?/hw/libMySpHal\.so        u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/vndk-sp/libBase\.so      u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/libBaseInternal\.so      u:object_r:same_process_hal_file:s0

參考文檔：

Android Source: VNDK

以上就是Android VNDK使用及原理深入探究的詳細內(nèi)容，更多關(guān)于Android VNDK使用原理的資料請關(guān)注腳本之家其它相關(guān)文章！