Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

支持 16 KB 页面大小

从历史上看，Android 仅支持 4 KB 内存页面大小，这优化了系统内存性能，以适应 Android 设备通常拥有的平均总内存量。从 Android 15 开始，AOSP 支持配置为使用 16 KB 页面大小的设备（16 KB 设备）。如果您的应用直接或通过 SDK 间接使用任何 NDK 库，则需要重新构建应用，才能在这些 16 KB 设备上运行。

随着设备制造商不断制造出具有更大物理内存 (RAM) 的设备，许多此类设备将采用 16 KB（最终甚至更大）的页面大小来优化设备性能。添加对 16 KB 页面大小设备的支持，可让您的应用在这些设备上运行，并帮助您的应用受益于相关的性能改进。如果不重新编译，应用将无法在未来 Android 版本的 16 KB 设备上运行。

为帮助您为应用添加支持，我们提供了相关指南，介绍了如何检查应用是否受到影响、如何重新构建应用（如果适用），以及如何使用模拟器（包括 Android 模拟器的 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) 文件（如有）。如果存在任何共享对象文件，则表明您的应用使用了原生代码。对齐列会针对存在对齐问题的任何文件显示警告消息。如果不存在共享对象文件或 lib 文件夹，则表示您的应用未使用原生代码。

通过自动检查检测对齐问题

如果预构建的库或 APK 不符合 16 KB 的要求，Android Studio 会主动发出警告。使用 APK 分析器工具查看哪些库需要更新，或者是否需要进行任何代码更改。

Android Studio 中的 Lint 还会突出显示未按 16 KB 对齐的原生库。

检查共享库的 ELF 段的对齐情况

对于任何共享库，请验证共享库的 ELF 段是否已使用 16 KB 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 管理器或 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 文件的名称。如果所有共享库都正确对齐，则输出的最后一行将显示“Verification successful”。

如果验证失败，则需要重新对齐一些共享库，因此您需要更新这些库的打包方式，然后重新编译应用，并按照本部分中的步骤重新测试。

检查 RELRO 安全标志

为了缓解安全漏洞，现代链接器使用 Relocation Read-Only (RELRO) 标志在加载后将共享对象文件的重定位部分设为只读。在build中启用 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 文件。

下面是一个包含 RELRO 段的对齐 .so 文件示例：

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 设备的 Android 应用

如果您的应用使用原生代码，请完成以下部分中列出的步骤，以确保您的应用支持 16 KB 设备：

更新共享库的打包方式
使用 16 KB ELF 对齐方式编译应用
修复代码并解决运行时问题
优化自定义内存分配器（如果适用）
检查 SDK 是否支持 16 KB

更新共享库的打包方式

升级到 AGP 版本 8.5.1 或更高版本，并使用未压缩的共享库。

使用 `bundletool` 验证 ZIP 对齐情况

如需查看您的软件包的对齐情况，请使用：

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 或更低版本

如果您使用的是 8.0 或更低版本的 AGP，则还需要在 gradle.properties 文件中停用 App Bundle 的未压缩原生库选项：

android.bundle.enableUncompressedNativeLibs=false

使用 16 KB ELF 对齐方式编译应用

16 KB 设备要求使用 16 KB ELF 对齐方式正确对齐共享库的 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

以下是更新 build 系统配置文件的方法：

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) 将内存释放回操作系统（例如，仅在活动对象占用的内存小于 8 KB 时释放内存）。

在 16 KB 系统上，即使是单个 16 字节的有效对象也会固定整个 16 KB 页面（大于 8 KB）。因此，永远无法达到释放阈值，分配器也永远不会将周围未使用的内存返回给内核。

应采取的措施：切勿将硬编码的字节常量用于页面释放启发式方法。使用 sysconf(_SC_PAGESIZE) 在运行时根据实际页面大小动态扩缩版本阈值。

2. 先填满已使用的页面（密集优先分配）

如果分配器以先进先出 (FIFO) 或轮循顺序分配内存，则新的分配会分散在许多部分填充的 16 KB 页面中。页面上的单个对象会将所有 16 KB 页面保留在物理 RAM 中。

操作方法：在触及空页面或使用较少的页面之前，始终从最满（最密集）的页面或 slab 分配新对象。将新分配集中在已脏页上，可让轻度使用的页面自然地排空到零个活跃对象，从而将整个 16 KB 页面释放给操作系统。

3. 将内存池对齐到 16 KB，并保持池大小适中

专为 4 KB 系统设计的多页 span 可能会在 16 KB 内核上保留过多未释放的内存空闲空间。此外，无法均匀划分为 16 KB 的大小类会导致每个页面末尾出现碎片。

操作步骤：

确保所有内存池、slab 边界和缓冲区对齐都是运行时页面大小的整数倍。
重新评估了小对象类的多页跨度大小，以避免分配过大的 slab 导致空闲内存被困住。

4. 立即释放缓存的大型缓冲区所占用的物理内存

自定义分配器通常会将大型缓冲区（> 64 KB）缓存在内存中池中，以便重复使用，而无需支付 mmap 或 munmap 系统调用的开销。不过，在等待逐出计时器期间，将这些脏缓冲区保留在内存中会浪费数兆字节的物理 RAM。

应采取的措施：保留为快速重用而预留的虚拟内存地址范围，但在将缓冲区返回到缓存时立即调用 madvise(..., MADV_DONTNEED) 或 madvise(..., MADV_FREE)。操作系统会立即回收物理 RAM，而您的应用仍可以立即重复使用虚拟地址，而无需重新分配。

5. 在释放时（而非分配时）将内存清零，以便进行 ZRAM 压缩

Android 使用压缩交换空间 (ZRAM) 将后台应用保留在内存中。在 16 KB 设备上，如果一个页面即使只包含一个活动对象，整个 16 KB 页面也会保持常驻或被交换到 ZRAM。该页面先前释放的部分中残留的垃圾数据（例如过时的指针和字符串）压缩效果不佳。

如果您的分配器会将内存归零（例如出于安全考虑或为了进行零初始化分配），请考虑在解除分配 (free()) 时归零，而不是在分配时归零：

固定页面的开销更低：在 ZRAM 中，部分填充的 16 KB 页面上的空闲内存会压缩到几乎为零，因此固定页面不会浪费物理交换空间。
最小的缓存开销：在调用 free() 时，内存已在 CPU 缓存中预热，从而避免了后续的额外缓存未命中。

建议摘要

领域	建议	预期影响
清除阈值	使用 `sysconf(_SC_PAGESIZE)` 动态调整发布阈值。	防止释放逻辑永久死锁。
分配顺序	首先从最密集（几乎已满）的页面或 slab 中分配。	通过将活跃对象打包在一起，减少常驻内存 (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 模拟器

如需使用 Android 模拟器设置 16 KB 环境，请按以下步骤操作：

在 Android Studio 中，依次点击 Tools > SDK Manager。
在 SDK Platforms 标签页中，选择 Show Package Details，然后展开 Android VanillaIceCream 或更高版本部分，并根据要创建的虚拟设备选择以下一个或两个模拟器系统映像：
- Google APIs Experimental 16 KB Page Size ARM 64 v8a System Image
- Google API 实验性 16 KB 页面大小 Intel x86_64 Atom 系统映像
注意：如果您打算模拟受支持的 Google Pixel 设备，则只需 ARM 64 v8a 系统映像。
点击应用 > 确定，下载您选择的所有系统映像。
按照为 Android 15 设置虚拟设备中的步骤操作，当系统提示您选择系统映像时，选择您下载的 16 KB 系统映像。如果系统未自动推荐，您可以在 Other Images 标签页中找到 16 KB 系统映像。

启动模拟器

完成 Android 模拟器和虚拟设备的设置后，从目标设备菜单或从命令行启动模拟器。

使用开发者选项在设备上启用 16 KB 模式

切换以 16KB 页面大小启动设备开发者选项，以在 16 KB 模式下启动设备。

在 Android 15 的 QPR 版本中，您可以使用某些设备上提供的开发者选项，以 16 KB 模式启动设备并执行设备端测试。在使用开发者选项之前，请依次前往设置 > 系统 > 软件更新，并应用所有可用的更新。

此开发者选项适用于以下设备：

Pixel 8 和 Pixel 8 Pro（搭载 Android 15 QPR1 或更高版本）
Pixel 8a（搭载 Android 15 QPR1 或更高版本）
Pixel 9、9 Pro 和 9 Pro XL（搭载 Android 15 QPR2 或更高版本）
Pixel 9a（搭载 Android 16 或更高版本）

16 KB 向后兼容模式

页面大小兼容模式下的警告

当设备运行 16 KB 内核时，16 KB 向后兼容选项可用。当满足以下条件时，软件包管理系统会以 16 KB 向后兼容模式运行应用：

如果应用具有 4 KB LOAD 分段对齐的 ELF 文件（扩展名为 .so）。
如果压缩后的 APK 包含 4 KB ZIP 对齐的未压缩 ELF 文件。

如果软件包管理系统为某应用启用了 16 KB 向后兼容模式，该应用在首次启动时会显示一条警告，表明它正以 16 KB 向后兼容模式运行。

16 KB 向后兼容模式可让部分应用正常运行，但为了实现最佳可靠性和稳定性，应用仍应以 16 KB 对齐。

在应用信息页面上的高级下，调整以页面大小兼容模式运行应用这项设置的切换开关，为特定应用启用或停用 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 属性设为“enabled”或“disabled”，以在特定应用的 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 设备的 Android 应用

更新共享库的打包方式

使用 bundletool 验证 ZIP 对齐情况

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 模拟器

启动模拟器

使用开发者选项在设备上启用 16 KB 模式

16 KB 向后兼容模式

支持 16 KB 页面大小

使用 `bundletool` 验证 ZIP 对齐情况