如何使用多 APK 支持在 Google Play 上发布适用于 x86 设备的应用

Intel® Developer Zone 提供跨平台应用开发工具和操作指南、平台和技术信息、代码示例以及同行专业知识，帮助开发者创新和成功。加入我们的社区，了解 Android、物联网、Intel® RealSense™ 技术 和 Windows，以下载工具、访问开发套件、与志同道合的开发者分享想法，并参与编程马拉松、竞赛、路演和本地活动。

Google Play 已为 x86 CPU 架构添加了多 APK 支持。此功能允许您为您的应用程序发布不同的 APK，每个 APK 都针对 x86 CPU 架构。APK 是您应用程序的完整独立版本，但它在 Google Play 上共享相同的应用程序列表，并且必须共享相同的包名并使用相同的发布密钥签名。此功能对于您的应用程序无法通过单个 APK（例如使用 Android NDK 开发的应用程序）覆盖所有所需设备的情况非常有用。您可以访问 Android 开发者网站上的 Google 多 APK 支持页面以获取完整信息。

以下课程专门为希望打包应用程序以支持 Android x86 设备（以 x86 处理器为基础的设备）的 Android 开发人员而设。

创建多个 APK

一旦您决定发布多个 APK，您可能需要为您打算发布的每个 APK 创建单独的 Android 项目，以便您可以适当地单独开发它们。您可以通过简单地复制现有项目并为其指定新名称来完成此操作。（或者，您可以使用一个构建系统，该系统可以根据构建配置输出不同的资源——例如纹理。）

提示：避免复制应用程序大部分代码的一种方法是使用库项目。库项目包含共享代码和资源，您可以将其包含在实际的应用程序项目中。

为同一应用程序创建多个项目时，最好用一个名称来标识每个项目，该名称表示要对 APK 施加的设备限制，这样您就可以轻松识别它们。例如，“HelloWorld_8”可能是为 API 级别 8 及以上设计的应用程序的好名称。

注意：您为同一应用程序发布的所有 APK 必须具有相同的包名并使用相同的证书密钥签名。请务必理解多 APK 的规则中的每个规则。

分配版本代码

同一应用程序的每个 APK 必须具有唯一的版本代码，由 android:versionCode 属性指定。发布多个 APK 时，必须谨慎分配版本代码，因为它们必须彼此不同，但在某些情况下，必须或应该根据每个 APK 支持的配置以特定顺序定义。

版本代码排序

需要更高 API 级别的 APK 通常必须具有更高的版本代码。例如，如果您创建两个 APK 来支持不同的 API 级别，则用于更高 API 级别的 APK 必须具有更高的版本代码。这确保了如果设备接收到系统更新，从而使其有资格安装用于更高 API 级别的 APK，用户会收到更新应用程序的通知。有关此要求如何适用的更多信息，请参阅上面关于多 APK 规则的部分。

您还应该考虑版本代码的顺序可能如何影响您的用户收到的 APK，这可能是由于不同 APK 覆盖范围的重叠，或者您可能对 APK 进行的未来更改。

例如，如果您的 APK 基于屏幕尺寸（例如一个用于小 - 正常，一个用于大 - 超大），但预见到将来您会将 APK 更改为一个用于小，一个用于正常 - 超大，那么您应该将大 - 超大 APK 的版本代码设置得更高。这样，当您进行更改时，正常尺寸的设备将收到适当的更新，因为版本代码会从现有 APK 增加到现在支持该设备的新 APK。

此外，在创建基于对不同 OpenGL 纹理压缩格式的支持而不同的多个 APK 时，请注意许多设备支持多种格式。由于当两个 APK 之间的覆盖范围存在重叠时，设备会收到版本代码最高的 APK，因此您应该对 APK 之间的版本代码进行排序，以便具有首选压缩格式的 APK 具有最高的版本代码。例如，您可能希望使用 PVRTC、ATITC 和 ETC1 压缩格式对您的应用程序进行单独构建。如果您按此精确顺序优先使用这些格式，则使用 PVRTC 的 APK 应该具有最高的版本代码，使用 ATITC 的 APK 具有较低的版本代码，而使用 ETC1 的版本具有最低的版本代码。因此，如果设备同时支持 PVRTC 和 ETC1，它将收到带有 PVRTC 的 APK，因为它具有最高的版本代码。

许多设备还支持多种 ABI，例如 ARMv7 和 ARMv5TE。许多 x86 ABI 设备也可以运行 ARMv7 和 ARMv5TE 二进制文件。您应该对版本代码进行排序，以便具有最佳性能的 APK 在每个设备上运行。例如，对版本代码进行排序，使 x86 APK 具有最高的版本代码，其次是 ARMv7，然后是 ARMv5TE。因此，x86 APK 将是 x86 设备的首选，而 ARMv7 APK 是 ARMv7 设备的首选。

使用版本代码方案

为了允许不同的 APK 独立更新其版本代码（例如，当您只在一个 APK 中修复错误时，无需更新所有 APK），您应该为您的版本代码使用一个方案，该方案在每个 APK 之间提供足够的空间，以便您可以在一个 APK 中增加代码而无需在其他 APK 中增加代码。您还应该在代码中包含实际的版本名称（即分配给 android:versionName 的用户可见版本），以便您可以轻松地将版本代码和版本名称关联起来。

注意：当您增加 APK 的版本代码时，Google Play 将提示以前版本的用户更新应用程序。因此，为避免不必要的更新，您不应增加实际上未包含更改的 APK 的版本代码。

我们建议使用至少 8 位数字的版本代码。表示支持配置的整数位于高位，版本名称（来自 android:versionName）位于低位。例如，当应用程序版本名称为 3.1.0 时，ARMv7 ABI 和 API 级别 4 APK 的版本代码将类似于 20400310。再例如，当应用程序版本名称为 3.1.0 时，x86 ABI 和 API 级别 11 APK 的版本代码将类似于 61100310。第一位数字表示支持的 ABI，第二位和第三位数字保留给 API 级别（分别为 4 和 11），第四位和第五位数字用于屏幕尺寸或 GL 纹理格式（在这些示例中未使用），最后三位数字用于应用程序的版本名称 (3.1.0)。图 1 显示了两个基于 ABI、平台版本 (API Level) 和屏幕尺寸进行拆分的示例。ABI 密钥为：7 - x86_64，6 - x86，3 - ARM64-V8A，2 - ARMv7，1 - ARMv5TE。

此版本代码方案只是对您应该如何建立一个可随应用程序演进而扩展的模式的建议。特别是，此方案并未展示用于识别不同纹理压缩格式的解决方案。一个选项可能是定义您自己的表格，该表格为您的应用程序支持的每种不同压缩格式指定一个不同的整数（例如，1 可能对应于 ETC1，2 对应于 ATITC，依此类推）。

您可以使用任何您想要的方案，但您应该仔细考虑应用程序的未来版本将如何需要增加其版本代码，以及当设备配置发生变化（例如，由于系统更新）或当您修改一个或多个 APK 的配置支持时，设备如何接收更新。