后台Activity启动的限制

Android系统的现状

在Q版本以前的Android无论在前台后台都可以通过调用startActivity来启动，但这会出现一个问题，例如，你正在用Googlemap来导航，但突然弹出了一个广告。这个行为其实会对用户带来很大的困扰，用户可能会卸载应用。

我们也在Googleplay上收到了一些用户反馈，其中一个用户提到，当他正在拍摄一个子女的重要时刻（毕业典礼或是孩子生日）时突然出现了一个弹出广告，错过了拍摄。

所以我们在Q版本中加了一个新的限制：应用只有在有可见的窗口，或是响应用户操作的时候才可以启动Activity。

你可以看到，现在我们在进行导航的时候，如果有其他应用尝试启动Activity，我们会显示“toast”以提醒开发者，他的应用不可以在后台启动Activity，需要尽快修改应用。

允许Activity Starts的条件

开发者一定会问：那在什么时候能够启动Activity呢？有什么条件呢？

我们已经在官方文档中总结了九个主要的条件：

现在我们来每一个都看一下。

1. 该应用有可见的窗口，例如有一个Activity在前台。

   

也就是说，你的应用是用户正在使用的。但是有一点要注意的是，在Activity启动的前提下，前台服务不等同于该应用在前台。

2.该应用程序有一个activity在foreground task stack。

举个例子，上图中，activity Y是暂时不在前台的，在foreground activity starts的上面，但这时activity Y其实也是可以启动新的activity的。

3.可见的应用程序绑定到应用程序的service。

比如说你的应用是为一个可见的第三方开发者提供SDK，而这个SDK绑定到你的应用的service上面，这时你的应用在后台其实也是可以启动activity的。

4.可见的应用程序发送该程序的pending intent。

例如，你的应用为第三方开发者提供SDK，一个可见的应用发送一个pending intent到你的SDK上，这样的情况也是可以启动activity的。

但是有一个要留意的地方：如果发送的是broadcast或者service的pending intent，你只会有几秒钟的时间启动activity，时间过了就无法启动。

5.系统发送该应用程序的pending intent。

这个场景较为复杂，需要看情况：

6.系统发送broadcast到该应用程序。

这个场景也需要分类：

需要注意的是，案例一中NEW_OUTGOING_CALL intent在Q开始之前就broadcast这个intent。

我们在Q版本中中加了一个相对较新的API，叫作call redirection service，如果你的应用是用来接受incoming call 或者是要处理一些打电话进来的情况，我们会建议在Q版本开始调用新的APIs。

7.系统绑定到应用程序的服务。

8.该应用程序通过CompanionDeviceManager APIs与配套硬件设备相关联/

例如，如果你的应用有Wear OS by Google的支持，可以响应用户在配对设备上执行的操作。比如说，user在他的手表上做一些动作，companion APP 要弹出一个UI，在那样的场景中是允许启动activity的。

9.该应用程序是在Device Owner模式下运行的Device Policy Controller。

例如，你的应用是用来控制完全托管的企业设备，以及数字标牌和信息亭等专用设备。如果你是Device Owner，也是可以在任何时间启动activity的。

你受影响了吗？

我们希望开发者们能尽快注意这些方面：

• 您目前是否有从后台启动Activity的情况？
• 您的代码库
• 在Q Beta 3开始强制执行，之前版本是在许可模式下启用，也就是说activity仍可以开启，但你会看到这样的toast：Backgroud activity start from som.google.android.dailer blocked.Seeg.co/dev/bgblock.

需要迁移的应用

1、来电处理、闹钟应用都可能收到影响（比如设定闹钟需要启动一个闹钟的UI）

2、应用会进行跨设备的登陆认证

3、在后台检测到崩溃后会自动重启activity的应用

缓解策略在我们官方文档中有一句话：

在大部分的场景，应用都可以通过notification来提供用户一些信息，让用户去决定要不要启动UI。 比如说一些时间敏感的事件，你可以通过notification APIs，创建一个高优先级的通知，给通知设置适当的类别。一个很重要的点是：在notification的时候，如果你希望它可以作为一个fullscreen的UI的话，我会建议加一个setFullScreenIntent在里面。

当然如果是用户正在用他的手机的时候，系统就会改成用一个hands-up notification来提醒用户那个通知。

notification APIs的优点

1.最大的优点就是不会打扰用户，可以让用户维持其上下文。

2.设备锁后，设置了一个full intent的话可以显示全屏UI。

3.如果用户选择了“Do Not Disturb”模式，您显示的方式是通过notification APIs，则您不用更改任何代码就会遵守用户希望的状态

4.notification通知设置提供更多透明度和控制。 我们做了很多优化，比如多加了notification channel。 。

最后一点就是，我们希望所有开发者都尊重用户正在注意的东西，不要打扰他们的使用APIs。

Android Q Beta

测试方面，在Q Beta1时我们使用一个叫许可的模式，所以在Beta1和2时你能看到toast，但Beta3之后再不会看到它，但我们仍有一个setting可以让你暂时的去disabled它，叫做allow background activity starts。如果你开了这个功能，你的应用可以暂时从后台启动这个activity，但我们只建议在适配时使用。

如果你想了解更详细的文档，请进入这个网站：