如何借助多 APK 支持在面向 x86 安卓设备的 Google Play* 上发布应用

Google Play has 新增面向 x86 CPU 架构的多 APK 支持。该  特性支持您针对定位于 x86 CPU 架构的应用发布不同的 APK。APK 是一套完整且独立的应用版本,它使用与 Google Play 上相同的应用列表,而且必须使用相同的软件包名称并使用相同的 release key 进行签名。当您的应用无法通过一个 APK 覆盖所有目标设备时,例如使用 Androind NDK 开发的应用,该特性将十分有用。您可以访问  Google 多 APK 支持页面(安卓开发人员站点),了解完整信息。

下面的会话专门针对希望对应用进行打包以便支持安卓 x86 设备的安卓开发人员而创建:

创建多 APK

一旦您决定要发布多 APK,您可能需要为每个要发布的 APK 创建单独的安卓项目,以便能够单独地进行开发。您只需复制现有的项目并取一个新的名称即可。(或者,您可以使用能够输出不同来源的构建系统—例如纹理—基于构建配置。)

Tip: 避免复制大片应用代码的一个方法是使用库项目.库项目中含有共享的代码和资源,您可以在自己的实际应用项目中予以使用。

为相同的应用创建多个项目时,建议识别每个带有名称的项目,该名称说明了设备在 APK 上的限制,这样您便能够轻松地识别他们。例如,"HelloWorld_8" 这个名称可能非常适用于针对 API 第 8 级和更高级别而设计的应用。

Note:您针对相同应用发布的所有 APK 必须具有相同的软件包名称,并且使用相同的证书密钥签名。确保您了解多 APK 的每条规则

分配版本代码

针对相同应用的每个 APK 必须具有唯一的版本代码,该代码由android:versionCode属性指定。发布多 APK 时需要分配版本代码,这时请务必小心。这些代码必须是不同的,但是在某些情况下,必须以特定的顺序进行定义,这取决于每个 APK 所支持的配置。

版本代码顺序

需要更高 API 级别的 APK 通常具有更高版本的代码。例如,如果您创建两个 APK 来支持不同的 API 级别,那么更高 API 级别的 APK 必须要具备更高版本的代码。如果设备收到系统更新,然后能够安装面向更高 API 级别的 APK,这有助于确保用户收到更新应用的通知。有关此要求的详细信息,请参阅上面的多 APK 规则

此外,您还应考虑版本代码的顺序如何影响您的用户所接收的 APK,其原因包括不同 APK 之间的重叠以及未来可能对 APK 所作出的修改。

例如,如果您具有基于屏幕大小的不同 APK,例如一个针对小型-正常的 APK 以及一个针对大型-超大型的 APK,但是您将来可能对 APK 进行更改,以便获得一个针对小型的 APK 和一个针对正常-超大型的 APK,这时您需要提高大型-超大型 APK 的版本代码。通过这种方式,当您进行更改时,正常尺寸的设备将会收到相应的更新,这是因为版本代码从当前的 APK 提升至支持该设备的新 APK。

此外,当创建多 APK 时(具体的区别取决于所支持的 OpenGL 纹理压缩格式的不同),请注意许多设备都支持多种格式。当两个 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 设备将优先使用 x86 APK;ARMv7 设备将优先使用 ARMv7 APK。

使用版本代码方案

为了使不同的 APK 能够相互独立地更新其版本代码(例如,如果您要修复一个 APK 中的漏洞,那么便无需更新所有 APK),您应当使用能够在每个 APK 之间提供充足空间的版本代码方案,这样您便可以提升一个 APK 中的代码,而不会对其他 APK 造成影响。此外,代码中还应包括实际的版本名称(即用户可见的版本分配到android:versionName),这样您便能够轻松地关联版本代码和版本名称。

Note:当您提高 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 级别)和屏幕大小进行划分的示例。ABI 密钥为:7 - x86_64、6 - x86, 3 - ARM64-V8A、2 - ARMv7、1 - ARMv5TE。

图 1。 推荐的版本代码方案,第一个数字用于 ABI,第二和第三个数字用于 API 级别, 第四和第五个数字则为最小和最大屏幕尺寸(1 - 4 代表 4 种尺寸)或表示纹理格式,最后三个数字则表示应用版本。ABI 密钥为:7 - x86_64、 6 - x86、2 - ARMv7、1 - ARMv5TE。例如, x86_64 ABI 的版本代码以及 API 19 级 APK 大致为 71900310 这样的形式

该版本代码方案提供了相关的建议,可帮助您建立一种能够随着应用的演进而进行扩展的模式。该方案并没有展示能够识别不同纹理压缩格式的解决方案。其中一种方式可能是定义您自己的表,以便为您的应用所支持的每种不同的压缩格式指定不同的整数。

您可以使用所需要的任意方案,但是您应认真考虑当设备配置发生变化(比如系统更新)或者当您修改配置以支持一个或多个 APK 时,未来的应用版本如何提升版本代码以及设备如何接收更新。

有关编译器优化的更完整信息,请参阅优化通知