Android Pony EXpress (APEX) 容器格式是在 Android 10 中引入的，它用於較低層級系統模組的安裝流程。這種格式有利於不適合標準 Android 應用程式模型的系統元件的更新。一些範例元件包括本機服務和函式庫、硬體抽象層 ( HAL )、執行時間 ( ART ) 和類別庫。
術語“APEX”也可以指 APEX 檔。
背景
儘管 Android 支援透過軟體包安裝程式應用程式（例如 Google Play 商店應用程式）更新適合標準應用程式模型（例如服務、活動）的模組，但對較低級別的作業系統元件使用類似的模型具有以下缺點：
- 基於 APK 的模組不能在啟動順序的早期使用。套件管理器是有關應用程式資訊的中央儲存庫，只能從活動管理器啟動，活動管理器在啟動過程的後期階段準備就緒。
- APK 格式（尤其是清單）是為 Android 應用程式設計的，系統模組並不總是合適。
設計
本節介紹 APEX 檔案格式和 APEX 管理員（管理 APEX 檔案的服務）的進階設計。
有關為什麼選擇 APEX 的這種設計的更多信息，請參閱開發 APEX 時考慮的替代方案。
頂點格式
這是 APEX 檔案的格式。
圖 1. APEX 檔案格式
在頂層，APEX 檔案是一個 zip 文件，其中文件以未壓縮的方式存儲，並且位於 4 KB 邊界處。
APEX 檔案中的四個檔案是：
-
apex_manifest.json -
AndroidManifest.xml -
apex_payload.img -
apex_pubkey
apex_manifest.json檔案包含套件名稱和版本，用於識別 APEX 檔案。這是 JSON 格式的ApexManifest協定緩衝區。
AndroidManifest.xml檔案允許 APEX 檔案使用 APK 相關工具和基礎設施，例如 ADB、PackageManager 和套件安裝程式應用程式（例如 Play Store）。例如，APEX 檔案可以使用現有工具（例如aapt來檢查檔案中的基本元資料。該檔案包含套件名稱和版本資訊。此資訊通常也可以在apex_manifest.json中找到。
對於處理 APEX 的新程式碼和系統，建議使用apex_manifest.json而不是AndroidManifest.xml 。 AndroidManifest.xml可能包含其他可供現有應用程式發布工具的定位資訊。
apex_payload.img是 dm-verity 支援的 ext4 檔案系統映像。影像在運作時透過環回設備安裝。具體來說，哈希樹和元資料塊是使用libavb庫創建的。不解析檔案系統有效負載（因為映像應該可以就地安裝）。常規檔案包含在apex_payload.img檔案內。
apex_pubkey是用於對檔案系統映像進行簽署的公鑰。在執行時，此金鑰可確保下載的 APEX 與在內建分割區中簽署相同 APEX 的相同實體進行簽署。
APEX 命名指南
為了幫助防止隨著平台的進步，新 APEX 之間發生命名衝突，請使用以下命名準則：
-
com.android.*- 為 AOSP APEX 保留。並非任何公司或設備所獨有。
-
com.<companyname>.*- 為公司保留。可能被該公司的多個設備使用。
-
com.<companyname>.<devicename>.*- 為特定設備（或設備子集）特有的 APEX 保留。
頂點經理
APEX 管理器（或稱apexd ）是一個獨立的本機進程，負責驗證、安裝和卸載 APEX 檔案。該進程在啟動序列的早期啟動並準備就緒。 APEX 檔案通常預先安裝在裝置上的/system/apex下。如果沒有可用的更新，APEX 管理器預設使用這些軟體包。
APEX的更新順序使用PackageManager類，如下所示。
- APEX 檔案是透過軟體包安裝程式應用程式、ADB 或其他來源下載的。
- 套件管理器開始安裝程序。在識別出該檔案是 APEX 後，套件管理器將控制權轉移給 APEX 管理員。
- APEX 管理器驗證 APEX 檔案。
- 如果 APEX 檔案經過驗證，APEX 管理器的內部資料庫將會更新，以反映 APEX 檔案在下次啟動時被啟動。
- 安裝請求者在成功驗證軟體包後會收到廣播。
- 若要繼續安裝，必須重新啟動系統。
下次啟動時，APEX 管理器啟動，讀取內部資料庫，並對列出的每個 APEX 檔案執行以下操作：
- 驗證 APEX 檔案。
- 從 APEX 檔案建立環回設備。
- 在環回設備之上建立設備映射器塊設備。
- 將裝置映射器區塊裝置安裝到唯一路徑（例如，
/apex/ name @ ver）。
當內部資料庫中列出的所有 APEX 檔案都已安裝時，APEX 管理員會為其他系統元件提供綁定器服務，以查詢已安裝 APEX 檔案的資訊。例如，其他系統元件可以查詢設備中安裝的 APEX 檔案的列表，或查詢安裝特定 APEX 的確切路徑，以便可以存取這些檔案。
APEX檔是APK文件
APEX 檔案是有效的 APK 文件，因為它們是包含AndroidManifest.xml檔案的簽章 zip 檔案（使用 APK 簽章方案）。這允許 APEX 檔案使用 APK 檔案的基礎設施，例如軟體包安裝程式應用程式、簽署實用程式和軟體套件管理器。
APEX 檔案內的AndroidManifest.xml檔案很小，由套件name 、 versionCode和可選的targetSdkVersion 、 minSdkVersion和maxSdkVersion組成，用於細粒度定位。此資訊允許透過現有管道（例如軟體包安裝程式應用程式和 ADB）傳送 APEX 檔案。
支援的文件類型
APEX 格式支援以下檔案類型：
- 本機共享庫
- 本機可執行檔
- JAR 文件
- 資料檔案
- 設定檔
這並不意味著 APEX 可以更新所有這些檔案類型。文件類型是否可以更新取決於平台以及文件類型介面定義的穩定性。
簽名選項
APEX 檔案有兩種簽章方式。首先，使用金鑰對apex_payload.img （具體來說，附加到apex_payload.img的 vbmeta 描述符）檔案進行簽署。然後，使用APK簽章方案v3對整個APEX進行簽章。在此過程中使用兩個不同的密鑰。
在裝置端，安裝了與用於簽署 vbmeta 描述符的私鑰相對應的公鑰。 APEX 管理員使用公鑰來驗證要求安裝的 APEX。每個 APEX 必須使用不同的金鑰進行簽名，並在建置時和執行時強制執行。
內建分割區中的 APEX
APEX 檔案可以位於內建分割區，例如/system 。該分割區已經通過 dm-verity，因此 APEX 檔案直接安裝在環回裝置上。
如果內建分割區中存在 APEX，則可以透過提供具有相同套件名稱且大於或等於版本號碼的 APEX 套件來更新 APEX。新的 APEX 儲存在/data中，與 APK 類似，新安裝的版本會隱藏內建分割區中已存在的版本。但與 APK 不同的是，新安裝的 APEX 版本僅在重新啟動後才會啟動。
內核要求
要在 Android 裝置上支援 APEX 主線模組，需要以下 Linux 核心功能：環回驅動程式和 dm-verity。環回驅動程式將檔案系統映像安裝在 APEX 模組中，並且 dm-verity 驗證 APEX 模組。
使用 APEX 模組時，環回驅動程式和 dm-verity 的效能對於實現良好的系統效能非常重要。
支援的核心版本
使用核心版本 4.4 或更高版本的裝置支援 APEX 主線模組。搭載 Android 10 或更高版本的新裝置必須使用核心版本 4.9 或更高版本才能支援 APEX 模組。
所需的內核補丁
支援 APEX 模組所需的核心補丁包含在 Android 公共樹中。若要取得支援 APEX 的補丁，請使用最新版本的 Android 公共樹。
核心版本4.4
此版本僅支援從 Android 9 升級到 Android 10 並希望支援 APEX 模組的裝置。要取得所需的補丁，強烈建議從android-4.4分支進行向下合併。以下是核心版本 4.4 所需的各個補丁的清單。
- UPSTREAM：循環：新增 ioctl 來改變邏輯區塊大小（ 4.4 ）
- 後向連接埠：區塊/循環：設定 hw_sectors ( 4.4 )
- UPSTREAM：循環：在 compat ioctl 中新增 LOOP_SET_BLOCK_SIZE ( 4.4 )
- ANDROID：mnt：修正 next_descendent ( 4.4 )
- ANDROID：mnt：重新安裝應該會傳播到從屬的從屬（ 4.4 ）
- ANDROID：mnt：正確傳播重新安裝（ 4.4 ）
- 恢復「ANDROID：dm verity：新增最小預取大小」（ 4.4 ）
- UPSTREAM：循環：如果 offset 或 block_size 更改則刪除快取（ 4.4 ）
核心版本4.9/4.14/4.19
若要取得內核版本 4.9/4.14/4.19 所需的補丁，請從android-common分支向下合併。
所需的內核配置選項
以下列表顯示了支援 Android 10 中引入的 APEX 模組的基本配置要求。帶有星號 (*) 的項目是 Android 9 及更低版本的現有要求。
(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support
核心命令列參數要求
為了支援 APEX，請確保核心命令列參數符合以下要求：
- 不得設定
loop.max_loop -
loop.max_part必須 <= 8
建構一個 APEX
本節介紹如何使用 Android 建置系統建置 APEX。以下是名為apex.test的 APEX 的Android.bp範例。
apex {
name: "apex.test",
manifest: "apex_manifest.json",
file_contexts: "file_contexts",
// libc.so and libcutils.so are included in the apex
native_shared_libs: ["libc", "libcutils"],
binaries: ["vold"],
java_libs: ["core-all"],
prebuilts: ["my_prebuilt"],
compile_multilib: "both",
key: "apex.test.key",
certificate: "platform",
}
apex_manifest.json範例：
{
"name": "com.android.example.apex",
"version": 1
}
file_contexts範例：
(/.*)? u:object_r:system_file:s0
/sub(/.*)? u:object_r:sub_file:s0
/sub/file3 u:object_r:file3_file:s0
APEX 中的檔案類型和位置
| 文件類型 | 位於 APEX 的位置 |
|---|---|
| 共享庫 | /lib和/lib64 （ /lib/arm用於 x86 翻譯後的arm） |
| 執行檔 | /bin |
| Java 函式庫 | /javalib |
| 預製件 | /etc |
傳遞依賴
APEX 檔案自動包含本機共用程式庫或執行檔的傳遞依賴項。例如，如果libFoo依賴libBar ，則當native_shared_libs屬性中僅列出libFoo時，就會包含這兩個函式庫。
處理多個 ABI
為裝置的主要和輔助應用程式二進位介面 (ABI) 安裝native_shared_libs屬性。如果 APEX 面向具有單一 ABI 的裝置（即僅限 32 位元或僅限 64 位元），則僅安裝具有對應 ABI 的程式庫。
僅為設備的主要 ABI 安裝binaries屬性，如下所述：
- 如果裝置僅為 32 位，則僅安裝二進位檔案的 32 位元變體。
- 如果裝置僅為 64 位，則僅安裝二進位檔案的 64 位元變體。
若要新增對本機程式庫和二進位檔案的 ABI 的細微控制，請使用multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries]屬性。
-
first：匹配設備的主要 ABI。這是二進位檔案的預設設定。 -
lib32：符合裝置的 32 位元 ABI（如果支援）。 -
lib64：匹配裝置的 64 位元 ABI，它支援。 -
prefer32：符合裝置的 32 位元 ABI（如果支援）。如果不支援 32 位元 ABI，則符合 64 位元 ABI。 -
both：符合兩個 ABI。這是native_shared_libraries的預設值。
java 、 libraries和prebuilts屬性與 ABI 無關。
此範例適用於支援 32/64 但不喜歡 32 的裝置：
apex {
// other properties are omitted
native_shared_libs: ["libFoo"], // installed for 32 and 64
binaries: ["exec1"], // installed for 64, but not for 32
multilib: {
first: {
native_shared_libs: ["libBar"], // installed for 64, but not for 32
binaries: ["exec2"], // same as binaries without multilib.first
},
both: {
native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
binaries: ["exec3"], // installed for 32 and 64
},
prefer32: {
native_shared_libs: ["libX"], // installed for 32, but not for 64
},
lib64: {
native_shared_libs: ["libY"], // installed for 64, but not for 32
},
},
}
vb元簽名
使用不同的金鑰對每個 APEX 進行簽署。當需要新金鑰時，建立公私金鑰對並建立apex_key模組。使用key屬性來使用金鑰對 APEX 進行簽署。公鑰自動包含在 APEX 中，名稱為avb_pubkey 。
# create an rsa key pairopenssl genrsa -out foo.pem 4096# extract the public key from the key pairavbtool extract_public_key --key foo.pem --output foo.avbpubkey# in Android.bpapex_key { name: "apex.test.key", public_key: "foo.avbpubkey", private_key: "foo.pem", }
在上面的範例中，公鑰 ( foo ) 的名稱成為金鑰的 ID。用於簽署 APEX 的密鑰 ID 寫入 APEX 中。在執行時， apexd使用裝置中具有相同 ID 的公鑰來驗證 APEX。
APEX簽約
簽署 APEX 的方式與簽署 APK 的方式相同。對 APEX 進行兩次簽章；一次用於迷你檔案系統（ apex_payload.img檔案），一次用於整個檔案。
若要在檔案層級簽署 APEX，請透過以下三種方式之一設定certificate屬性：
- 未設定：如果未設定值，則 APEX 使用位於
PRODUCT_DEFAULT_DEV_CERTIFICATE的憑證進行簽署。如果未設定標誌，則路徑預設為build/target/product/security/testkey。 -
<name>：APEX 使用與PRODUCT_DEFAULT_DEV_CERTIFICATE位於同一目錄中的<name>憑證進行簽章。 -
:<name>：APEX 使用名為<name>的 Soong 模組定義的憑證進行簽署。證書模組可以定義如下。
android_app_certificate {
name: "my_key_name",
certificate: "dir/cert",
// this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}
安裝 APEX
若要安裝 APEX，請使用 ADB。
adb install apex_file_nameadb reboot
如果在apex_manifest.json中將supportsRebootlessUpdate設為true並且目前安裝的 APEX 未使用（例如，它包含的任何服務已停止），則可以使用--force-non-staged標誌安裝新的 APEX，無需重新啟動。
adb install --force-non-staged apex_file_name
使用 APEX
重新啟動後，APEX 將安裝在/apex/<apex_name>@<version>目錄中。同一 APEX 的多個版本可以同時掛載。掛載路徑中，最新版本對應的掛載路徑為/apex/<apex_name> 。
客戶端可以使用綁定安裝路徑從 APEX 讀取或執行檔。
APEX 通常如下使用：
- 設備出貨時，OEM 或 ODM 會在
/system/apex下預先載入 APEX。 - APEX 中的檔案可透過
/apex/<apex_name>/路徑存取。 - 當 APEX 的更新版本安裝在
/data/apex中時，路徑在重新啟動後指向新的 APEX。
使用 APEX 更新服務
若要使用 APEX 更新服務：
將系統分區中的服務標記為可更新。將
updatable選項新增至服務定義。/system/etc/init/myservice.rc: service myservice /system/bin/myservice class core user system ... updatable為更新的服務建立新的
.rc檔。使用override選項重新定義現有服務。/apex/my.apex/etc/init.rc: service myservice /apex/my.apex/bin/myservice class core user system ... override
服務定義只能在 APEX 的.rc檔中定義。 APEX 不支援操作觸發器。
如果標記為可更新的服務在 APEX 啟動之前啟動，則啟動會延遲，直到 APEX 啟動完成。
設定係統以支援 APEX 更新
將下列系統屬性設為true以支援 APEX 檔案更新。
<device.mk>:
PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true
BoardConfig.mk:
TARGET_FLATTEN_APEX := false
要不就
<device.mk>:
$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)
扁平化頂點
對於舊設備，有時不可能或不可行更新舊核心以完全支援 APEX。例如，核心可能是在沒有CONFIG_BLK_DEV_LOOP=Y情況下建構的，這對於在 APEX 內掛載檔案系統映像至關重要。
Flattened APEX 是專門建置的 APEX，可在具有舊核心的裝置上啟動。扁平化APEX中的檔案直接安裝到內建分割區下的目錄。例如，扁平 APEX my.apex中的lib/libFoo.so安裝到/system/apex/my.apex/lib/libFoo.so 。
啟動扁平 APEX 不涉及循環設備。整個目錄/system/apex/my.apex直接綁定安裝到/apex/name@ver 。
扁平化的 APEX 無法透過從網路下載 APEX 的更新版本來更新，因為下載的 APEX 無法扁平化。扁平化 APEX 只能透過常規 OTA 進行更新。
扁平 APEX 是預設配置。這表示預設情況下所有 APEX 都是扁平化的，除非您明確將裝置配置為建置非扁平化 APEX 以支援 APEX 更新（如上所述）。
不支援在設備中混合展平和非展平 APEX。設備中的 APEX 必須全部非扁平化或全部扁平化。當為 Mainline 等專案提供預先簽署的 APEX 預先建置時，這一點尤其重要。未預先簽署（即從來源建置）的 APEX 也應該是非扁平化的，並使用正確的金鑰進行簽署。設備應繼承自updatable_apex.mk ，如使用 APEX 更新服務所述。
壓縮 APEX
Android 12 及更高版本具有 APEX 壓縮功能，可減少可更新 APEX 套件的儲存影響。安裝 APEX 更新後，雖然不再使用其預安裝版本，但仍佔用相同的空間量。所佔用的空間仍然不可用。
APEX 壓縮透過在唯讀分割區（例如/system分割區）上使用高度壓縮的 APEX 檔案集來最大限度地減少這種儲存影響。 Android 12 及更高版本使用 DEFLATE zip 壓縮演算法。
壓縮不會對以下內容提供優化：
需要在引導序列的早期安裝的引導 APEX。
不可更新的 APEX。只有當 APEX 的更新版本安裝在
/data分割區上時，壓縮才有用。模組化系統元件頁面上提供了可更新 APEX 的完整清單。動態共享庫 APEX。由於
apexd始終啟動此類 APEX 的兩個版本（預先安裝和升級），因此壓縮它們不會增加價值。
壓縮 APEX 檔案格式
這是壓縮 APEX 檔案的格式。
圖 2.壓縮的 APEX 檔案格式
在頂層，壓縮的 APEX 檔案是一個 zip 文件，其中包含壓縮形式的原始 apex 文件，壓縮等級為 9，其他文件未壓縮儲存。
四個檔案組成一個 APEX 檔：
-
original_apex：壓縮等級為 9 的壓縮 這是原始的、未壓縮的APEX 檔。 -
apex_manifest.pb：僅存儲 AndroidManifest.xml：僅儲存apex_pubkey：僅儲存
apex_manifest.pb 、 AndroidManifest.xml和apex_pubkey檔案是original_apex中對應檔案的副本。
建構壓縮的 APEX
可以使用位於system/apex/tools的apex_compression_tool.py工具建立壓縮 APEX。
建置系統中提供了與 APEX 壓縮相關的多個參數。
在Android.bp中，APEX 檔案是否可壓縮由compressible屬性控制：
apex {
name: "apex.test",
manifest: "apex_manifest.json",
file_contexts: "file_contexts",
compressible: true,
}
PRODUCT_COMPRESSED_APEX產品標誌控制從來源建置的系統映像是否必須包含壓縮的 APEX 檔案。
對於本機實驗，您可以透過將OVERRIDE_PRODUCT_COMPRESSED_APEX=設為true來強制建置壓縮 APEX。
建置系統產生的壓縮 APEX 檔案具有.capex副檔名。此擴充功能使區分 APEX 檔案的壓縮版本和未壓縮版本變得更加容易。
支援的壓縮演算法
Android 12 僅支援 deflate-zip 壓縮。
在啟動期間啟動壓縮的 APEX 文件
在啟動壓縮的 APEX 之前，其中的original_apex檔案將被解壓縮到/data/apex/decompressed目錄中。產生的解壓縮 APEX 檔案硬連結到/data/apex/active目錄。
考慮以下範例來說明上述過程。
將/system/apex/com.android.foo.capex視為正在啟動的壓縮 APEX，版本代碼為 37。
-
/system/apex/com.android.foo.capex中的original_apex檔案被解壓縮到/data/apex/decompressed/com.android.foo@37.apex。 - 執行
restorecon /data/apex/decompressed/com.android.foo@37.apex以驗證它是否具有正確的SELinux標籤。 - 對
/data/apex/decompressed/com.android.foo@37.apex執行驗證檢查以確保其有效性：apexd檢查/data/apex/decompressed/com.android.foo@37.apex中捆綁的公鑰驗證它是否等於/system/apex/com.android.foo.capex中捆綁的那個。 -
/data/apex/decompressed/com.android.foo@37.apex檔案硬連結至/data/apex/active/com.android.foo@37.apex目錄。 - 未壓縮 APEX 檔案的常規啟動邏輯在
/data/apex/active/com.android.foo@37.apex上執行。
與OTA交互
壓縮的 APEX 檔案會對 OTA 交付和應用產生影響。由於 OTA 更新可能包含版本等級高於裝置上活動文件的壓縮 APEX 文件，因此在重新啟動裝置以套用 OTA 更新之前，必須保留一定量的可用空間。
為了支援 OTA 系統， apexd公開了這兩個 Binder API：
-
calculateSizeForCompressedApex- 計算解壓縮 OTA 套件中的 APEX 檔案所需的大小。這可用於在下載 OTA 之前驗證裝置是否有足夠的空間。 -
reserveSpaceForCompressedApex- 保留磁碟上的空間以供apexd將來用於解壓縮 OTA 套件內的壓縮 APEX 檔案。
對於 A/B OTA 更新， apexd會在背景嘗試解壓縮，作為安裝後 OTA 例程的一部分。如果解壓縮失敗， apexd將在應用 OTA 更新的引導期間執行解壓縮。
開發 APEX 時考慮的替代方案
以下是 AOSP 在設計 APEX 檔案格式時考慮的一些選項，以及包含或排除它們的原因。
常規套件管理系統
Linux 發行版具有dpkg和rpm等套件管理系統，它們功能強大、成熟且健壯。但是，它們沒有被 APEX 採用，因為它們無法在安裝後保護軟體包。僅在安裝軟體包時才執行驗證。攻擊者可以在不被注意的情況下破壞已安裝軟體包的完整性。這是 Android 的回歸，其中所有系統元件都儲存在唯讀檔案系統中，其完整性受到每個 I/O 的 dm-verity 保護。對系統組件的任何篡改都必須被禁止，或者是可檢測的，以便設備在受到損害時可以拒絕啟動。
dm-crypt 的完整性
APEX容器中的檔案來自受dm-verity保護的內建分割區（例如/system分割區），即使在掛載分割區後也禁止對檔案進行任何修改。為了給檔案相同等級的安全性，APEX 中的所有檔案都儲存在與雜湊樹和 vbmeta 描述符配對的檔案系統映像中。如果沒有 dm-verity， /data分割區中的 APEX 很容易受到驗證和安裝後的意外修改。
事實上， /data分割區也受到dm-crypt等加密層的保護。儘管這提供了一定程度的防篡改保護，但其主要目的是隱私，而不是完整性。當攻擊者獲得對/data分區的存取權限時，就無法提供進一步的保護，與/system分區中的每個系統元件相比，這又是一種倒退。 APEX 檔案內的哈希樹與 dm-verity 一起提供相同等級的內容保護。
將路徑從 /system 重定向到 /apex
打包在 APEX 中的系統元件檔案可以透過/apex/<name>/lib/libfoo.so等新路徑存取。當檔案是/system分區的一部分時，可以透過/system/lib/libfoo.so等路徑存取它們。 APEX 檔案（其他 APEX 檔案或平台）的用戶端必須使用新路徑。由於路徑更改，您可能需要更新現有程式碼。
儘管避免路徑更改的一種方法是將 APEX 文件中的文件內容覆蓋到/system分區上，但 Android 團隊決定不在/system分區上覆蓋文件，因為這可能會影響效能，因為覆蓋的文件數量會增加（甚至可能一個接一個地堆疊）增加。
另一個選擇是劫持檔案存取函數，例如open 、 stat和readlink ，以便以/system開頭的路徑被重定向到/apex下的對應路徑。 Android 團隊放棄了這個選項，因為更改所有接受路徑的函數是不可行的。例如，一些應用程式靜態連結 Bionic，它實現了功能。在這種情況下，這些應用程式不會被重新導向。