在Android Dev Summit上宣布了各种新工具和功能之后，应特别注意应用内更新（IAU）API，使开发人员可以提高向活动用户交付功能，错误修复和性能改进的速度。 由于此功能终于在Google I / O 2019之后发布 ，因此在本文中，我将深入探讨IAUs API，详细介绍建议的用户流程并提供一些代码示例。 此外，我将分享在中国商品市场平台Pandao应用中IAU集成的一些经验。

新的API允许开发人员启动新的应用内更新请求流程，以推动活动用户更新应用。 IAU对现有的Google Play自动更新机制进行了补充，但不幸的是，它对某些用户禁用任何类型的更新的意图没有任何影响。 IAU的请求可以通过两种方式实现，它们提供了完全不同的用户体验。

1. 灵活的流程提示用户在后台下载更新并在方便的时候进行安装。 应该在某些情况下使用它，尽管仍然适合用户在发布新版本的同时使用旧版本的应用程序。
   
   
   
2. 立即流程要求用户下载并安装更新，然后才能继续使用该应用程序。 它应在某些情况下使用，对于开发人员在应用更新之前阻止其使用对于开发人员而言至关重要。
   
   
   

由于后一种用例对于Pandao应用不太重要且不适合使用，因此我们将详细讨论前一种用例。

IAU的灵活流集成

用例

灵活的IAU流程包括以下步骤。

1. 该应用要求Google Play使用Play核心库检查可用更新。
   
2. 如果有可用更新，则该应用会请求Google Play显示IAU对话框。 Google Play向用户显示更新请求对话框。
   
3. 如果用户接受更新请求，则Google Play会在后台下载更新，从而在状态栏为用户提供优美的状态监视。
   
4. 如果在后台运行该应用程序时下载过程完成，则Google Play会自动完成安装。 对于在应用程序处于前台时下载完成的情况，我们必须定义自定义逻辑以完成更新。 考虑实施的几种最佳实践。
   
   
   1. 该应用程序会启动安装过程，同时向用户显示Google Play屏幕并向用户显示安装进度。 安装完成后，该应用程序将重新启动并打开更新的版本。 在这种情况下，建议显示其他对话框，以允许用户明确确认他或她现在准备重新启动应用程序。 这是一个强烈建议的流程 。
      
   2. 该应用程序等待，直到它进入后台，然后以静默方式完成更新。 一方面，就用户体验而言，此选项的侵入性较小。 但另一方面，它要求开发人员实现一项棘手的功能，以检测应用程序何时进入后台。
      

在特殊情况下，更新的完成将自动推迟到Google Play后台任务。 不建议将该选项显式使用，因为它不提供有关安装更新的任何保证。

手动测试的基本要求

为了在测试设备上手动执行完整的更新流程，您应至少拥有两个版本的应用程序，且版本号不同：源版本和目标版本。

• 具有较高版本号的源版本应在Google Play上发布，该版本将被Google Play识别为可用更新。 具有较低版本号和集成IAU功能的目标版本应安装在您的设备上，这是将更新的版本。 问题是，当应用程序请求Google Play检查可用更新时，它会将安装的应用程序的版本号与Google Play中最后一个可用版本的版本号进行比较。 因此，只有在Google Play中的版本号高于设备上应用程序的实际版本的情况下，才会触发IAUs功能。
  
• 源版本和目标版本都必须具有相同的软件包名称，并应使用相同的发行证书进行签名。
  
• Android 5.0（API级别21）或更高版本。
  
• 播放Core库1.5.0或更高版本。
  

样例代码

本节包含一些有关IAU使用的示例代码，也可以在官方文档中找到它们。 首先，必须将Play Core库添加到模块级gradle文件。

dependencies { ... implementation "com.google.android.play:core:1.5.0" } 

接下来，让我们创建IAUs管理器的实例，并将回调添加到AppUpdateInfo任务。 该任务的结果包含有关更新可用性的信息，启动更新的意图（如果可用）以及更新下载的当前进度（如果已经启动）。

 // Create instance of the IAUs manager. val appUpdateManager = AppUpdateManagerFactory.create(context) // Add state listener to app update info task. appUpdateManager.appUpdateInfo.addOnSuccessListener { appUpdateInfo -> // If there is an update available, prepare to promote it. if (appUpdateInfo.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE) { // ... } // If the process of downloading is finished, start the completion flow. if (appUpdateInfo.installStatus() == InstallStatus.DOWNLOADED) { // ... } } .addOnFailureListener { e -> // Handle the error. } 

就如何通过代码触发来自Google Play的更新请求对话而言，您会在AppUpdateInfo对象中收到PendingIntent ，可以从startIntentSenderForResult开始。 此对话框要求用户开始更新。

  appUpdateManager.startUpdateFlowForResult( // Pass the intent that is returned by 'getAppUpdateInfo()'. appUpdateInfo, // Or 'AppUpdateType.IMMEDIATE for immediate updates. AppUpdateType.FLEXIBLE, // The current activity. activity, REQUEST_CODE ) 

要监视更新状态，可以将InstallStateUpdatedListener添加到IAUs管理器中。 请确保您的InstallStateUpdatedListener生命周期。

 // Create a listener to track downloading state updates. val listener = InstallStateUpdatedListener { state -> // Update progress indicator, request user to approve app reload, etc. } // At some point before starting an update, register a listener for updates. appUpdateManager.registerListener(listener) // ... // At some point when status updates are no longer needed, unregister the listener. appUpdateManager.unregisterListener(listener) 

一旦下载了更新（“已DOWNLOADED状态），应重新启动应用程序以完成更新。 可以通过调用appUpdateManager.completeUpdate()轻松启动它，但建议显示一个小吃栏，以允许用户明确确认他或她现在准备重新启动应用程序。

 Snackbar.make( rootView, "An update has just been downloaded from Google Play", Snackbar.LENGTH_INDEFINITE ).apply { setAction("RELOAD") { appUpdateManager.completeUpdate() } show() } 

“更新不可用”错误

首先，请仔细检查“基本实施要求”部分中提到的要求。 如果您按照所有要求成功完成了上述步骤，尽管根据onSuccess回调仍然无法进行更新，请注意以下技巧。 最可能的原因是由于内部缓存机制的缘故，Google Play应用尚不知道该更新。 为确保在手动测试时拥有最新的缓存，您可以转到Google Play应用中的“我的应用和游戏”屏幕来刷新缓存的版本。 另外，您也可以在设置中清除Google Play应用的缓存。 请注意，这只是测试问题，不会影响最终用户，因为无论如何缓存都是每天更新的。

盘岛的IAU灵活流动

作为早期访问计划的一部分，我们将IAU的灵活流程（推荐实现）集成到了盘岛应用程序中，该应用程序提供了来自中国制造商和供应商的产品。 IAU对话框显示在主屏幕上，因此可以与之进行交互的最大用户数。 最初，我们决定每天向IAU进行不超过一次的对话，以免使用户感到烦恼。

由于A / B测试是每个新功能生命周期中的关键步骤，因此我们决定评估IAU对Pandao应用程序的影响。 我们将用户随机分为两个不重叠的组。 第一个是没有IAU功能的对照组代表“不变”基线，第二个是带有IAU对话的测试组。


图 1.在Pandao App中对IAU（灵活流）进行A / B测试。

在过去的几个版本中，我们测量了每个应用程序版本的活跃用户百分比。 发现在最新版本的可用用户中，主要用户来自B组，即具有IAUS功能的用户。 从图的紫色线条可以看到。 如图1所示，在发布1.29.1应用程序版本后的头几天，具有IAU功能的活动用户数超过了不具有此功能的用户数。 对于先前版本的应用程序，可以观察到相反的情况，在发布1.29.1应用程序版本后，请参见蓝色和红色线条。 因此，可以说具有IAU的用户倾向于更快地更新应用程序版本。


图 2.盘道应用程序中IAU对话（灵活流程）的确认率 。

根据Pandao分析数据（参见图2），在IAU对话中单击确认按钮的转换在发布的第一天达到峰值，然后不断下降直到下一次应用程序更新。 转换为在小吃店单击安装按钮时，可以观察到相同的模式，这将启动安装下载的更新。 因此，这两种情况下的平均转化率似乎都与释放频率成正比。 在盘岛，一个月内测得的平均转化率超过35％（单击确认按钮）和7％（单击安装按钮）。

我们建议随着时间的推移降低确认率只是用户体验问题，因为对新应用版本感兴趣的人将很快更新，而对更新不感兴趣的人将继续不感兴趣。 根据这些信息，我们决定退回某些用户是否对更新不感兴趣，而不是每天询问他们。 尝试基于``陈旧性''尝试不同的请求逻辑似乎是一个好习惯，即他们使用的版本多大，用户已经要求他们进行更新的次数等等，而不是冒使用户烦恼的风险。

结果，IAU在A / B测试期间展示了有价值的结果，因此我们为所有用户推出了此功能。

确认的细分

我要感谢各个同事对本文的贡献。 感谢Maryna Pliashkova Maryna_Pliashkova ，Alexander Chernyy alexchernyy ，Ilia Nazarov RolaRko ，Gleb Bodyachevskiy，Daniil Polozov jokerdab ，Anastasia Kulik，Vladislav Breus和Vladislav Goldin Vladiskus 。