Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

支援 16 KB 頁面大小

過去 Android 僅支援 4 KB 的記憶體分頁大小，這已針對 Android 裝置通常擁有的平均總記憶體量，最佳化系統記憶體效能。從 Android 15 開始，AOSP 支援設定為使用 16 KB 頁面大小的裝置 (16 KB 裝置)。如果應用程式使用任何 NDK 程式庫 (直接或透過 SDK 間接使用)，您必須重建應用程式，才能在這些 16 KB 裝置上運作。

隨著裝置製造商持續打造實體記憶體 (RAM) 容量更大的裝置，許多裝置將採用 16 KB (最終會更大) 的分頁大小，以最佳化裝置效能。為 16 KB 頁面大小的裝置新增支援功能，可讓應用程式在這些裝置上執行，並享有相關的效能提升優勢。如果沒有重新編譯，應用程式就無法在日後的 Android 版本中，於 16 KB 裝置上運作。

為協助您為應用程式新增支援功能，我們提供了相關指南，說明如何檢查應用程式是否受到影響、如何重建應用程式 (如適用)，以及如何使用模擬器 (包括 Android Emulator 的 Android 15 系統映像檔)，在 16 KB 環境中測試應用程式。

Google Play 相容性規定

為確保應用程式能在最新版 Android 上正常運作，所有指定 Android 15 (API 級別 35) 以上版本的應用程式，都必須在 Google Play 上的 64 位元裝置上支援 16 KB 記憶體分頁大小。2027 年 2 月 1 日起，如果應用程式更新不支援 16 KB 記憶體分頁大小，就無法發布。

Google Play 管理中心警告：應用程式更新必須在 2027 年 2 月 1 日前支援 16 KB 記憶體分頁大小 — **圖 1.** Google Play 管理中心相容性警告。

優點和效能提升

以 16 KB 頁面大小設定的裝置平均會耗用較多記憶體，但系統和應用程式也能獲得各種效能改善：

系統面臨記憶體壓力時，應用程式啟動時間越短：平均低 3.16%，部分受測的應用程式還大幅改善 (最多提升 30%)
應用程式啟動期間的耗電量降幅：平均減少 4.56%
相機啟動速度更快：熱啟動速度平均快了 4.48%，冷啟動速度平均快了 6.60%
縮短系統啟動時間：縮短 8% (平均約 950 毫秒)

這些改善項目是根據初步測試結果而來，實際裝置上的結果可能會有所不同。我們會在持續測試的過程中，針對應用程式可能獲得的效益提供額外分析。

確認應用程式是否受到影響

如果應用程式使用任何原生程式碼，請重新建構應用程式，支援 16 KB 裝置。如果您不確定應用程式是否使用原生程式碼，可以使用 APK 分析工具找出是否有任何原生程式碼，然後檢查找到的任何共用程式庫的 ELF 區段是否對齊。Android Studio 也提供相關功能，可協助您自動偵測對齊問題。

如果應用程式只使用以 Java 程式設計語言或 Kotlin 編寫的程式碼 (包括所有程式庫或 SDK)，則應用程式已可支援 16 KB 裝置。不過，我們建議您在 16 KB 環境中測試應用程式，確認應用程式行為沒有發生非預期的迴歸。

應用程式是否使用原生程式碼？

如果符合下列任一條件，即表示應用程式使用原生程式碼：

應用程式使用任何 C/C++ (原生) 程式碼。如果應用程式使用 Android NDK，即表示應用程式使用原生程式碼。
應用程式連結至任何使用這些 API 的第三方原生資料庫或依附元件 (例如 SDK)。
您的應用程式是由第三方應用程式建構工具建構，該工具使用裝置上的原生資料庫。

使用 APK 分析工具找出原生資料庫

APK 分析工具可用來多方評估已建構的 APK。如要檢查應用程式是否使用原生程式碼 (無論是否支援 16 KB)，請按照下列步驟操作：

開啟 Android Studio，然後依序點選「File」>「Open」，並選擇任一專案。
在選單列中，依序點選「Build」>「Analyze APK...」。
選擇要分析的 APK。
查看 lib 資料夾，其中會代管共用物件 (.so) 檔案 (如有)。如果存在任何共用物件檔案，表示應用程式使用原生程式碼。「Alignment」欄會顯示任何有對齊問題的檔案警告訊息。如果沒有共用物件檔案或 lib 資料夾，表示應用程式未使用原生程式碼。

透過自動檢查功能偵測對齊問題

如果預建程式庫或 APK 不符合 16 KB 的規定，Android Studio 會主動顯示警告。使用 APK 分析器工具，查看需要更新的程式庫，或是否需要進行任何程式碼變更。

Android Studio 中的 Lint 也會醒目顯示未對齊 16 KB 的原生資料庫。

檢查共用程式庫的 ELF 區隔對齊

對於任何共用程式庫，請使用 16 KB ELF 對齊方式，確認共用程式庫的 ELF 區段已正確對齊。如果您是在 Linux 或 macOS 上開發，可以使用 check_elf_alignment.sh 指令碼，如下一節所述。您也可以直接使用指令列工具。

使用 check_elf_alignment.sh 指令碼 (Linux 或 macOS)

請按照下列步驟，使用 check_elf_alignment.sh 指令碼檢查 ELF 區段的對齊方式：

將 check_elf_alignment.sh 指令碼儲存至檔案。
對應用程式的 APK 檔案執行指令碼：
```
check_elf_alignment.sh APK_NAME.apk
```
指令碼會為所有 arm64-v8a 共用程式庫輸出 ALIGNED 或 UNALIGNED。
如果任何 arm64-v8a 或 x86_64 共用資料庫是 UNALIGNED，您需要更新這些資料庫的封裝，然後重新編譯應用程式，並按照本節中的步驟重新測試。

直接使用指令列工具

請按照下列步驟，直接使用指令列工具檢查 ELF 區隔是否對齊：

請務必使用 Android Studio 的 SDK Manager 或 sdkmanager 指令列工具，安裝 Android SDK Build-Tools 35.0.0 以上版本和 Android NDK。

解壓縮應用程式的 APK 檔案：

Linux 或 macOS

unzip APK_NAME.apk -d /tmp/my_apk_out

Windows (PowerShell)

Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out

在您解壓縮 APK 檔案的暫存目錄中，檢查 lib 目錄的內容，找出共用物件 (.so) 檔案。這些共用物件檔案與您使用 APK 分析工具識別原生資料庫時看到的檔案相同。請對每個共用物件檔案執行下列指令：

Linux 或 macOS

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD

Windows (PowerShell)

SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"

其中 SDK_ROOT_LOCATION 是您安裝 Android SDK 的目錄路徑，SHARED_OBJECT_FILE 是您要檢查的共用物件檔案名稱，NDK_VERSION 是您安裝的 Android NDK 版本 (例如 28.0.12433566)。您檢查的每個檔案輸出內容會類似如下：

LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14

檢查輸出內容，確保載入區隔的值不小於 2**14。如果任何載入區段的值為 2**13、2**12 或更低，您必須更新這些程式庫的封裝，然後重新編譯應用程式，並按照本節中的步驟重新測試。
接著，在應用程式的 APK 檔案上執行 zipalign 指令列工具：
Linux 或 macOS
SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
Windows (PowerShell)
SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
其中 SDK_ROOT_LOCATION 是 Android SDK 安裝目錄的路徑，APK_NAME 則是應用程式 APK 檔案的名稱。如果所有共用資料庫都正確對齊，輸出內容的最後一行會顯示「驗證成功」。

如果驗證失敗，表示部分共用程式庫需要重新對齊，因此您必須更新這些程式庫的封裝，然後重新編譯應用程式，並按照本節中的步驟重新測試。

檢查 RELRO 安全性標記

為降低安全漏洞，現代連結器會使用重新定位唯讀 (RELRO) 旗標，在載入後將共用物件檔案的重新定位區段設為唯讀。在建構中啟用 RELRO 旗標。

如果 RELRO 區段的起始位址加上區段大小 (MemSize) 未對齊 16 KB，應用程式會在執行階段因區隔錯誤而停止運作。如果 .so 檔案是以 NDK 工具鍊 r27 以下版本建構，且未啟用相關旗標，就會發生這種情況。

在每個共用物件檔案 (Linux 或 macOS) 上執行下列指令：

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

如果有 RELRO 區段，系統會顯示 GNU_RELRO 字串。

接著，將 RELRO 區段的虛擬偏移位址 (VirtAddr) 加上區段記憶體大小 (MemSiz)，然後除以 16 KB (0x4000)，檢查 RELRO 區段對齊情形。如果餘數 (模數) 為零，則 RELRO 區段已對齊 16 KB。

以下是未對齊的 .so 檔案範例：

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

公式：(VirtAddr + MemSiz) % 0x4000 == 0

結果：(0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

由於 0x1000 不是零，因此這個 .so 檔案不符合 16 KB 規定。從 DC000 (前一個分頁符號) 到 E4000 的 RELRO 保護範圍為唯讀，但 Android 連結器預期從 E1000 到 E4000 的子範圍可寫入，因此導致區隔錯誤。在這種情況下，請按照「使用 16 KB ELF 對齊編譯應用程式」一節所述，重新建構 .so 檔案。

以下是已對齊的 .so 檔案範例，其中包含 RELRO 區隔：

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1

以下是沒有 RELRO 區隔的 .so 檔案範例：

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align

這是符合 16 KB 規範的微不足道 .so 檔案，沒有任何 RELRO 區段。

以下是經過對齊的 .so 檔案範例，其中 GNU_RELRO 位於其專屬的 LOAD 區隔中：

Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000680 0x000680 R E 0x4000
LOAD           0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 RW  0x4000
GNU_RELRO      0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 R   0x1

公式：(VirtAddr + MemSiz) % 0x4000 == 0

結果：(0x4680 + 0x0980) % 0x4000 = 0x5000 % 0x4000 == 0x1000

雖然 0x1000 不是零，但這個 .so 檔案仍符合 16 KB 規定。

當 GNU_RELRO 與後續可寫入資料 (例如 .data 或 .bss) 共用 LOAD 區段時，系統會套用模數公式。

如要檢查 GNU_RELRO 是否位於自己的 LOAD 區段，請執行 llvm-readelf -Wl 並使用 grep 'LOAD\|RELRO\|Type' 篩選，檢查程式標頭。比較 GNU_RELRO 的 VirtAddr 和 MemSiz 與包含的 LOAD 區隔。在本範例中，兩者都有 VirtAddr 0x4680 和 MemSiz 0x0980。

由於整個 LOAD 區段僅包含 RELRO 資料，因此 0x5000 至 0x8000 的子範圍內沒有可寫入的資料。此外，任何後續可寫入的 LOAD 區段都會從獨立的 16 KB 頁面邊界 (0x8000 或以上) 開始。連結器的唯讀保護不會與任何可寫入資料重疊，因此不會發生區隔錯誤。

建構應用程式，支援 16 KB 裝置

如果應用程式使用原生程式碼，請完成下列各節所述步驟，確保應用程式支援 16 KB 裝置：

更新共用程式庫的封裝
使用 16 KB ELF 對齊編譯應用程式
修正程式碼並解決執行階段問題
最佳化自訂記憶體配置器 (如適用)
檢查 SDK 是否支援 16 KB

更新共用程式庫的封裝

升級至 AGP 8.5.1 以上版本，並使用未壓縮的共用程式庫。

使用 `bundletool` 驗證拉鍊對齊

如要查看套裝組合的對齊方式，請使用：

bundletool dump config --bundle=<my .aab>  | grep alignment

如果看到 PAGE_ALIGNMENT_16K，表示套件要求 16 KB ZIP 對齊。如果看到 PAGE_ALIGNMENT_4K，表示從這個 AAB 建構的 APK 應在 ZIP 檔案中，有 4 KB 對齊的 .so 檔案。

AGP 8.5.1 以上版本

16 KB 裝置需要應用程式隨附未壓縮的共用程式庫，並將其對齊 16 KB 的 zip 對齊邊界。為此，您需要升級至 Android Gradle 外掛程式 (AGP) 8.5.1 以上版本。如要進一步瞭解升級程序，請參閱「Android Gradle 外掛程式升級小幫手」一節。

AGP 8.5 以下版本

如果無法將 AGP 升級至 8.5.1 以上版本，可以改用壓縮的共用程式庫。更新 Gradle 設定，讓 Gradle 在封裝應用程式時壓縮共用程式庫，避免未對齊的共用程式庫造成應用程式安裝問題。

Groovy

在 build.gradle 檔案中，新增下列選項：

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

Kotlin

在 build.gradle.kts 檔案中，新增下列選項：

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP 8.0 以下版本

如果您使用的 AGP 版本為 8.0 以下，也需要在 gradle.properties 檔案中停用應用程式套件的未壓縮原生程式庫選項：

android.bundle.enableUncompressedNativeLibs=false

使用 16 KB ELF 對齊方式編譯應用程式

如要在 16 KB 裝置上執行應用程式，共用程式庫的 ELF 區段必須使用 16 KB ELF 對齊方式正確對齊。

遊戲開發人員：如果遊戲是透過 Unity 遊戲引擎執行，請參閱 Unity 指南。如果您的遊戲是透過 Unreal 遊戲引擎執行，請參閱 Unreal 指南。如果是原生遊戲引擎，請繼續閱讀本指南。

如要使用 16 KB ELF 對齊方式編譯應用程式，請根據您使用的 Android NDK 版本，完成下列其中一節的步驟。

Android NDK r28 以上版本

NDK r28 以上版本預設會編譯 16 KB 對齊。

Android NDK r27 以下版本

如要使用 Android NDK 第 r27 版或更舊版本，編譯與 16 KB 對齊的共用程式庫，請使用下列連結器標記：

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

更新建構系統設定檔的方法如下：

ndk-build

如果您使用 ndk-build，請更新 Android.mk，啟用 16 KB ELF 對齊功能：

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

CMake

如果您使用 CMake，請更新 CMakeLists.txt，啟用 16 KB ELF 對齊：

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

修正程式碼並解決執行階段問題

即使應用程式已對齊 16 KB，如果程式碼中的位置假設裝置使用特定頁面大小，應用程式仍可能發生錯誤。為避免這種情況，請完成下列步驟：

移除參照 PAGE_SIZE 常數的任何硬式編碼依附元件，或程式碼邏輯中假設裝置頁面大小為 4 KB (4096) 的執行個體。

請改用 getpagesize() 或 sysconf(_SC_PAGESIZE)。
找出 mmap() 和其他需要頁面對齊引數的 API 用法，並視需要替換為替代方案。

在某些情況下，如果應用程式使用 PAGE_SIZE 做為與基礎分頁大小無關的便利值，則在 16 KB 模式下使用時，不會導致應用程式中斷。不過，如果這個值是透過 mmap 傳遞至核心，但沒有 MAP_FIXED，核心仍會使用整個頁面，這會浪費部分記憶體。因此，在 NDK r27 以上版本啟用 16 KB 模式時，PAGE_SIZE 未定義。

如果應用程式以這種方式使用 PAGE_SIZE，且從未直接將這個值傳遞至核心，請建立新變數並使用新名稱，反映該變數用於其他用途，且不反映實際記憶體頁面，而非使用 PAGE_SIZE。

最佳化自訂記憶體配置器

在 16 KB 系統上，作業系統分配的最小實體記憶體單位，是 4 KB 系統的四倍。如果自訂分配器是根據 4 KB 假設設計，可能會將小型物件分散到多個 16 KB 頁面，並保留不必要的空白記憶體。這可能會大幅增加實體記憶體用量 (RSS)，並降低壓縮交換空間 (ZRAM) 的效率。

如果程式碼會管理自己的記憶體集區，請依循以下建議事項：

1. 避免使用硬式編碼位元組門檻釋出記憶體

許多配置器會使用固定的位元組限制，決定何時使用 madvise(MADV_DONTNEED) 將記憶體釋放回 OS (例如，只有在活動物件佔用少於 8 KB 時才釋放記憶體)。

在 16 KB 系統中，即使是單一 16 位元組的即時物件，也會釘選整個 16 KB 頁面 (大於 8 KB)。因此，系統永遠不會達到發布門檻，配置器也永遠不會將周圍未使用的記憶體傳回核心。

建議做法：請勿使用硬式編碼位元組常數，做為頁面釋出啟發式演算法。使用 sysconf(_SC_PAGESIZE)，在執行階段根據實際頁面大小動態調整釋放門檻。

2. 優先填滿已使用的頁面 (密集優先分配)

如果配置器以先進先出 (FIFO) 或輪流方式分配記憶體，新的配置就會分散在許多部分填滿的 16 KB 頁面。頁面上的單一物件會將所有 16 KB 的資料保留在實體 RAM 中。

建議做法：一律先從最滿 (最密集) 的頁面或板塊分配新物件，再處理空白或使用率低的頁面。將新的配置集中在已變更的頁面上，可讓使用率低的頁面自然減少到零個有效物件，這樣整個 16 KB 頁面就能釋出給 OS。

3. 將記憶體集區對齊 16 KB，並保持適當大小

專為 4 KB 系統設計的多頁面範圍，可能會在 16 KB 核心上保留過多的未釋放記憶體空間。此外，如果大小類別無法平均分割成 16 KB，每個頁面結尾就會出現片段。

該做什麼：

請確保所有記憶體集區、板塊邊界和緩衝區對齊方式都是執行階段頁面大小的確切倍數。
重新評估小型物件類別的多頁跨度大小，避免分配過大的 slab，導致閒置記憶體受困。

4. 立即釋出快取大型緩衝區的實體記憶體

自訂配置器通常會在記憶體內集區中快取大型緩衝區 (> 64 KB)，以便重複使用，而不會產生 mmap 或 munmap 系統呼叫的負擔。不過，在等待清除計時器時，將這些髒緩衝區保留在記憶體中會浪費數 MB 的實體 RAM。

建議做法：保留虛擬記憶體位址範圍，以便快速重複使用，但在將緩衝區傳回快取時，請立即呼叫 madvise(..., MADV_DONTNEED) 或 madvise(..., MADV_FREE)。作業系統會立即回收實體 RAM，而應用程式仍可立即重複使用虛擬位址，不需重新分配。

5. 在釋出記憶體時將記憶體歸零，而非在分配記憶體時歸零，以便進行 ZRAM 壓縮

Android 會使用壓縮交換空間 (ZRAM)，將背景應用程式保留在記憶體中。在 16 KB 裝置上，如果頁面含有一個使用中的物件，整個 16 KB 頁面就會保留或交換至 ZRAM。先前釋放的網頁部分中，剩餘的垃圾資料 (例如過時的指標和字串) 壓縮效果不佳。

如果分配器會將記憶體歸零 (例如基於安全性或零初始化分配)，請考慮在取消分配 (free()) 時歸零，而非在分配時歸零：

固定頁面成本較低：部分填滿的 16 KB 頁面上的閒置記憶體，在 ZRAM 中會壓縮到幾乎為零，因此固定頁面不會浪費實體交換空間。
快取負擔極小：呼叫 free() 時，記憶體已在 CPU 快取中熱啟動，可避免日後發生額外的快取失敗。

建議摘要

領域	建議	預期影響
清除門檻	使用 `sysconf(_SC_PAGESIZE)` 動態調整版本門檻。	防止釋放邏輯永久死鎖。
分配順序	先從最密集的頁面或板塊 (幾乎全滿) 分配。	將作用中的物件封裝在一起，減少常駐記憶體 (RSS)。
跨度大小	將大小類別對齊 16 KB 的倍數，並避免過大的 slab。	消除尾頁片段，並減少記憶體閒置。
緩衝區快取	快取大型緩衝區時，請立即呼叫 `madvise(MADV_DONTNEED)`。	消除閒置 RAM 膨脹，同時保持快速虛擬重複使用。
交換 / ZRAM	在 `free()` 上將記憶體歸零，而非在分配時歸零。	提高 ZRAM 壓縮率，降低固定頁面的成本。

檢查 SDK 是否支援 16 KB

許多 SDK 都與 16 KB 分頁大小相容，尤其是自行建構或取得近期預先建構的 SDK。不過，部分 SDK 預建版本或 SDK 版本與 16 KB 不相容，因此請查看各 SDK 供應商的網站，判斷要與 16 KB 搭配使用的版本。

在 16 KB 環境中測試應用程式

建構支援 16 KB 裝置的應用程式後，請在 16 KB 環境中測試應用程式，確認應用程式體驗是否發生任何迴歸問題。如要進行這項作業，請按照以下步驟操作：

設定 Android 15 SDK 以上版本。
設定下列其中一種測試環境：
啟動測試裝置，然後執行下列指令，確認裝置使用 16 KB 環境：
```
adb shell getconf PAGE_SIZE
```
指令應傳回 16384 值。
執行下列 zipalign 指令，確認應用程式已對齊 16 KB，其中 APK_NAME 是應用程式 APK 檔案的名稱：
```
zipalign -c -P 16 -v 4 APK_NAME.apk
```
請徹底測試應用程式，著重於可能受到參照特定頁面大小的程式碼執行個體變更影響的任何區域。

使用 16 KB 系統映像檔設定 Android Emulator

如要使用 Android 模擬器設定 16 KB 環境，請按照下列步驟操作：

在 Android Studio 中，按一下「Tools」(工具) >「SDK Manager」。
在「SDK Platforms」分頁中，選取「Show Package Details」，然後展開「Android VanillaIceCream」或更高版本部分，並根據要建立的虛擬裝置，選取下列一或兩個模擬器系統映像檔：
- Google API 實驗性 16 KB 分頁大小 ARM 64 v8a 系統映像檔
- Google API 實驗性 16 KB 頁面大小 Intel x86_64 Atom 系統映像檔
注意： 如果您打算模擬支援的 Google Pixel 裝置，則只需要 ARM 64 v8a 系統映像檔。
依序按一下「Apply」>「OK」，下載所選的系統映像檔。
按照步驟設定 Android 15 虛擬裝置，並在系統提示選取系統映像檔時，選取下載的 16 KB 系統映像檔。如果系統未自動建議，您可以在「Other Images」(其他映像檔) 分頁中找到 16 KB 的系統映像檔。

啟動模擬器

設定完 Android 模擬器和虛擬裝置後，請從目標裝置選單或指令列啟動模擬器。

使用開發人員選項在裝置上啟用 16 KB 模式

切換「以 16KB 頁面大小啟動」開發人員選項，即可在 16 KB 模式下啟動裝置。

在 Android 15 的 QPR 版本中，您可以使用特定裝置上的開發人員選項，以 16 KB 模式啟動裝置，並執行裝置端測試。使用開發人員選項前，請依序前往「設定」>「系統」>「軟體更新」，並套用所有可用的更新。

下列裝置提供這項開發人員選項：

Pixel 8 和 8 Pro (搭載 Android 15 QPR1 以上版本)
Pixel 8a (搭載 Android 15 QPR1 以上版本)
Pixel 9、Pixel 9 Pro 和 Pixel 9 Pro XL (搭載 Android 15 QPR2 以上版本)
Pixel 9a (搭載 Android 16 以上版本)

16 KB 回溯相容模式

頁面大小相容模式的警告

當裝置搭載 16 KB 核心時，可以使用 16 KB 回溯相容選項。符合下列條件時，套件管理員會以 16 KB 向後相容模式執行應用程式：

應用程式含有 ELF 檔案 (副檔名為 .so)，且 LOAD 區隔對齊為 4 KB。
如果壓縮的 APK 含有未壓縮的 ELF 檔案，且這些檔案為 4 KB 的 ZIP 對齊檔案。

如果套件管理員已為應用程式啟用 16 KB 向後相容模式，應用程式首次啟動時會顯示警告，指出應用程式正在 16 KB 向後相容模式下執行。

16 KB 回溯相容模式可讓部分應用程式運作，但為了確保最佳可靠性和穩定性，應用程式仍應採用 16 KB 對齊。

在應用程式資訊頁面的「Advanced」下方，切換「Run app with page size compat mode」設定，即可啟用或停用特定應用程式的 16 KB 回溯相容模式。只有在裝置以 16 KB 頁面大小執行時，才會顯示這項設定。

頁面大小相容模式設定

頁面大小相容模式設定

如要強制裝置上的所有應用程式啟用 16 KB 回溯相容性，請按照下列步驟操作：

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

如要強制關閉裝置上所有應用程式的 16 KB 回溯相容性，請執行以下指令：

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

在 Android 17 中，您也可以強制關閉每個應用程式的 16 KB 回溯相容性，並立即終止任何不相容的二進位檔：

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

將 android:pageSizeCompat 屬性設為啟用或停用，即可在特定應用程式的 AndroidManifest.xml 中開啟或關閉回溯相容模式。設定這項屬性後，應用程式啟動時就不會顯示回溯相容模式警告。

支援 16 KB 頁面大小 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Google Play 相容性規定

優點和效能提升

確認應用程式是否受到影響

應用程式是否使用原生程式碼？

使用 APK 分析工具找出原生資料庫

透過自動檢查功能偵測對齊問題

檢查共用程式庫的 ELF 區隔對齊

使用 check_elf_alignment.sh 指令碼 (Linux 或 macOS)

直接使用指令列工具

Linux 或 macOS

Windows (PowerShell)

Linux 或 macOS

Windows (PowerShell)

Linux 或 macOS

Windows (PowerShell)

檢查 RELRO 安全性標記

建構應用程式，支援 16 KB 裝置

更新共用程式庫的封裝

使用 bundletool 驗證拉鍊對齊

AGP 8.5.1 以上版本

AGP 8.5 以下版本

Groovy

Kotlin

AGP 8.0 以下版本

使用 16 KB ELF 對齊方式編譯應用程式

Android NDK r28 以上版本

Android NDK r27 以下版本

ndk-build

CMake

修正程式碼並解決執行階段問題

最佳化自訂記憶體配置器

1. 避免使用硬式編碼位元組門檻釋出記憶體

2. 優先填滿已使用的頁面 (密集優先分配)

3. 將記憶體集區對齊 16 KB，並保持適當大小

4. 立即釋出快取大型緩衝區的實體記憶體

5. 在釋出記憶體時將記憶體歸零，而非在分配記憶體時歸零，以便進行 ZRAM 壓縮

建議摘要

檢查 SDK 是否支援 16 KB

在 16 KB 環境中測試應用程式

使用 16 KB 系統映像檔設定 Android Emulator

啟動模擬器

使用開發人員選項在裝置上啟用 16 KB 模式

16 KB 回溯相容模式

支援 16 KB 頁面大小

使用 `bundletool` 驗證拉鍊對齊