针对不同的 API 级别创建多个 APK

如果您将应用发布到 Google Play,您应构建并上传 Android App Bundle 文件。当您执行此操作时,Google Play 会针对每个用户的设备配置自动生成并提供经过优化的 APK,以便他们仅下载运行您的应用所需的代码和资源。如果您不将应用发布到 Google Play,那么发布多个 APK 很有用,但您必须自行构建和管理每个 APK 并为其签名。

如果您要在开发 Android 应用时利用 Google Play 上的多个 APK,请务必从一开始就采用一些好的做法,以免在开发过程中遇到不必要的麻烦。本课介绍了如何为应用创建多个 APK,并使每个 APK 支持的 API 级别范围略有不同。此外,您还将获得一些必要的工具,帮助您尽可能轻松地维护多 APK 代码库。

确认您需要多个 APK

在尝试创建可在多代 Android 平台上运行的应用时,您自然希望应用在利用新设备上的新功能,同时不影响向后兼容性。乍一看,支持多 APK 似乎就是最佳解决方案,但事实往往并非如此。多 APK 开发者指南的改用单个 APK 部分提供了一些有关如何使用单个 APK 实现该目标的实用信息,包括如何使用我们的支持库。您还可以了解如何在单个 APK 中编写仅在特定 API 级别运行的代码,而不借助计算开销非常大的技术,例如 这篇文章中的反射技术。

如果您可以管理应用,将应用限制为单个 APK 有多项优势,包括:

  • 发布和测试更加轻松
  • 只需要维护一个代码库
  • 您的应用可以适应设备配置的变化
  • 可以跨设备执行应用恢复
  • 您不必担心市场偏好、从一个 APK“升级”到下一个 APK 的行为,或者哪个 APK 与哪类设备相匹配

本课的其余部分假定您已研究该主题,认真学习了链接资源中的相关资料,并确定使用多个 APK 是适合您应用的正确路径。

制作您的需求图表

首先,您可以创建一个简单的图表,快速确定您需要多少个 APK,以及每个 APK 所支持的 API 范围。为方便您参考,Android 开发者网站的平台版本页面提供了运行给定版本的 Android 平台的活跃设备相对数量数据。此外,虽然跟踪每个 APK 的目标 API 级别一开始听起来很简单,但很快就会变得非常困难,特别是在存在一些重叠(经常存在)的情况下。幸运的是,您可以轻松快速地绘制出您的要求图表,以便于日后参考。

若要创建多 APK 图表,首先要有一行单元格表示 Android 平台的不同 API 级别。在末尾添加一个额外的单元格,用于表示 Android 的未来版本。

3 4 5 6 7 8 9 10 11 12 13 +

现在只需在图表中着色,使每种颜色代表一个 APK。以下示例说明了如何将每个 APK 应用于特定范围的 API 级别。

3 4 5 6 7 8 9 10 11 12 13 +

创建此图表后,将其分发给您的团队。项目之间的团队沟通立即变得简单了,因为您不用再问“API 级别 3 到 6 的 APK 怎么样,Android 1.x 1 怎么样了。进展如何?”此类复杂的问题,您只需要问“蓝色 APK 进展如何?”

将所有通用代码和资源放在一个库项目中

无论您是修改现有 Android 应用,还是从头开始构建应用,对代码库都是应做的第一件事,也是迄今为止最重要的事情。纳入库项目的所有内容都只需更新一次(例如经过本地化的字符串、颜色主题、在共享代码中修复的 bug),这样可以缩短开发时间,降低出现那些本来可以很容易避免的错误的可能性。

注意:虽然有关如何创建和包含库项目的实现详情不在本课的讨论范围内,但阅读创建 Android 库有助于您跟上学习进度。

如果您要将现有应用转换为支持多 APK 的应用,请在代码库中搜索每个本地化的字符串文件、值列表、主题颜色、菜单图标和布局,这些元素在不同 APK 之间不会发生变化,并将它们全部放在库项目中。不会发生太大变化的代码也应纳入到库项目中。您可能会发现自己需要扩展这些类,以便在 APK 和 APK 之间添加一两个方法。

另一方面,如果您要从头开始创建应用,请尽可能多地在库项目中编写代码,然后在必要时才将其移到单个 APK 中。从长远来看,这比将 blob 依次添加到一个、另一个、另一个,然后几个月后尝试确定是否可以将此 blob 移到库部分而不造成任何损坏,这样管理起来要容易得多。

创建新的 APK 项目

您应该为要发布的每个 APK 单独创建一个 Android 项目。为了便于整理,请将库项目和所有相关的 APK 项目放在同一父文件夹下。另请注意,每个 APK 都需要具有相同的软件包名称,但不一定需要与库共享软件包名称。如果您有 3 个遵循上述方案的 APK,您的根目录可能如下所示:

alexlucas:~/code/multi-apks-root$ ls
foo-blue
foo-green
foo-lib
foo-red

项目创建完毕后,请将库项目作为引用添加到各个 APK 项目中。如果可能,请在库项目中定义启动 activity,并在 APK 项目中扩展该 activity。在库项目中定义启动 activity 可让您有机会将所有应用的初始化集中到一个位置,这样每个单独的 APK 就不必重新实现“通用”任务,例如初始化 Analytics、运行许可检查,以及从 APK 到 APK 没有太大变化的任何其他初始化过程。

调整清单

当用户通过 Google Play 下载使用多个 APK 的应用时,系统会使用 2 条简单的规则来选择正确的 APK:

  • 清单必须显示特定的 APK 符合条件
  • 在符合条件的 APK 中,选择版本最高的一个

我们以上文中的一组多 APK 为例,假设我们尚未为任何 APK 设置最高 API 级别。单独来看,每个 APK 的可能范围将如下所示:

3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +

我们知道具有较高 minSdkVersion 的 APK 也必须具有较高的版本代码,因此就 versionCode 值而言,红色 ≥ 绿色 ≥ 蓝色。因此,我们实际上可以将该图表简化为下表:

3 4 5 6 7 8 9 10 11 12 13 +

现在,让我们进一步假设红色 APK 有一些另外 2 种颜色的 APK 所没有的要求。 Android 开发者指南中的 Google Play 上的过滤器页面上列出了所有可能的问题根源。举例来说,假设红色 APK 需要前置摄像头。实际上,红色 APK 的全部意义就是将前置摄像头与 API 11 中添加的漂亮新功能相结合。但事实是,有些 API 11+ 设备根本没有前置摄像头!这太糟糕了!

幸运的是,如果用户在此类设备上浏览 Google Play,Google Play 会查看该清单,看到红色列出了前置摄像头作为一项要求,并安静地忽略它,并已确定红色和该设备在数字天堂中不匹配。然后,它会发现绿色不仅向前兼容具有 API 11 的设备(因为未定义 maxSdkVersion),而且还不在乎是否有前置摄像头!用户仍然可以从 Google Play 下载该应用,因为尽管发生了前置摄像头的小意外,但仍然有 APK 支持该特定的 API 级别。

为了便于区分各个 APK,必须制定有效的版本代码方案。您可以在开发者指南的版本代码部分找到推荐的方案。由于这组示例 APK 仅涉及 3 个可能维度中的一个,因此将每个 APK 相隔 1000 就足够了,将前几位设为该特定 APK 的 minSdkVersion,然后从这里递增。相应版本代码可能类似如下:

蓝色:03001, 03002, 03003, 03004...
绿色:07001, 07002, 07003, 07004...
红色:11001, 11002, 11003, 11004...

综上所述,您的 Android 清单可能如下所示:

蓝色:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    ...

绿色:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="7" />
    ...

红色:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    ...

检查发布前核对清单

在上传到 Google Play 之前,请仔细检查以下各项内容。请注意,这些内容都是与多个 APK 相关的,并不能代表上传到 Google Play 的所有应用的完整核对清单。

  • 所有 APK 必须具有相同的软件包名称
  • 所有 APK 必须使用相同的证书签名
  • 如果 APK 在平台版本上出现重叠,则 minSdkVersion 较高的 APK 应具有更高的版本号
  • 仔细检查您的清单过滤器是否有冲突的信息(仅在特大屏幕上支持 Cupcake 的 APK 不会被任何人看到)
  • 每个 APK 的清单必须至少在一个受支持的屏幕、OpenGL 纹理或平台版本中是唯一的
  • 尝试在至少一个设备上测试所有 APK。除此之外,您的开发计算机上还有业内自定义程度最高的设备模拟器之一,您可以尽情地测试!

此外,在推向市场之前还应该检查已编译的 APK,以确保不会出现任何可能使您的应用无法在 Google Play 上隐藏的意外情况。使用“aapt”工具其实很简单。Aapt(Android 资源打包工具)是创建和打包 Android 应用的构建流程的一部分,也是检查这些应用的一种便捷工具。

>aapt dump badging
package: name='com.example.hello' versionCode='1' versionName='1.0'
sdkVersion:'11'
uses-permission:'android.permission.SEND_SMS'
application-label:'Hello'
application-icon-120:'res/drawable-ldpi/icon.png'
application-icon-160:'res/drawable-mdpi/icon.png'
application-icon-240:'res/drawable-hdpi/icon.png'
application: label='Hello' icon='res/drawable-mdpi/icon.png'
launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''
uses-feature:'android.hardware.telephony'
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

检查 aapt 输出时,请务必检查 supports-screens 和 compatible-screens 的值是否存在冲突,以及是否有因您在清单中设置的权限而添加了意外的“uses-feature”值。在上面的示例中,很多设备都看不到 APK。

为什么?添加必要的 SEND_SMS 权限时,就隐式添加了 android.hardware.telephony 功能要求。由于 API 11 是 Honeycomb(专为平板电脑优化的 Android 版本),并且 Honeycomb 设备均未配备电话硬件,因此 Google Play 在所有情况下都会过滤掉此 APK,直到未来出现 API 级别更高且具备电话硬件的设备。

幸运的是,通过将以下内容添加到清单可轻松解决此问题:

<uses-feature android:name="android.hardware.telephony" android:required="false" />

此外,还隐式添加了 android.hardware.touchscreen 要求。如果您希望在不属于触摸屏设备的电视上看到您的 APK,则应将以下内容添加到清单中:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

完成发布前核对清单后,就可以将您的 APK 上传到 Google Play。您的应用可能需要一段时间才会在 Google Play 中显示,但在它显示后,您还需执行最后一项检查。将应用下载到您可能拥有的任何测试设备上,确保 APK 定位到正确的设备。恭喜您大功告成了!