如何借助多 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 时,未来的应用版本如何提升版本代码以及设备如何接收更新。