Android Q Labs| 后台Activity启动的限制
Android系统的现状
但这会出现一个问题，例如你正在用 Googlemap 来导航，但忽然弹出了一个广告。这个行为其实会对用户带来很大的困扰，用户可能会卸载应用。android
咱们也在 Googleplay 上收到了一些用户反馈，其中一个用户提到，当他正在拍摄一个子女的重要时刻（毕业典礼或是孩子生日）时忽然出现了一个弹出广告，错过了拍摄。post
因此咱们在 Android Q 版本中加了一个新的限制：应用只有在有可见的窗口，或是响应用户操做的时候才能够启动 Activity。 测试
你能够看到，如今咱们在进行导航的时候，若是有其余应用尝试启动 Activity，咱们会显示 “toast” 以提醒开发者，他的应用不能够在后台启动 Activity，须要尽快修改应用。优化
容许 Activity Starts 的九个条件
开发者必定会问：那在何时可以启动 Activity 呢？有什么条件呢？网站
咱们已经在官方文档中总结了九个主要的条件：google
1.该应用有可见的窗口，例若有一个 Activity 在前台
也就是说，你的应用是用户正在使用的。可是有一点要注意的是，在 Activity 启动的前提下，前台服务不等同于该应用在前台。3d
2.该应用程序有一个 activity 在 foreground task stack
举个例子，上图中，activity Y 是暂时不在前台的，在 foreground activity starts 的上面，但这时 activity Y 其实也是能够启动新的 activity 的。cdn
3.可见的应用程序绑定到应用程序的 service
好比说你的应用是为一个可见的第三方开发者提供 SDK ，而这个 SDK 绑定到你的应用的 service 上面，这时你的应用在后台其实也是能够启动 activity 的。blog
4.可见的应用程序发送该程序的 pending intent
例如你的应用为第三方开发者提供 SDK，一个可见的应用发送一个 pending intent 到你的 SDK 上，这样的状况也是能够启动 activity 的。事件
可是有一个要留意的地方：若是发送的是 broadcast 或者 service 的 pending intent，你只会有几秒钟的时间启动 activity，时间过了就没法启动。
5.系统发送该应用程序的pending intent
| 案例 | 状况 | 是否容许 |
|---|---|---|
| 1 | 应用程序从通知点击启动UI | 容许 |
| 2 | 使用 AlarmManager 安排报警去发送 pending intent 来启动 activity | 不容许 |
6.系统发送broadcast到该应用程序
这个场景也须要分类：
| 案例 | 状况 | 是否容许 |
|---|---|---|
| 1 | 你的应用具备接受 NEW_OUTGOING_CALL的broadcast receiver | 容许 |
| 2 | 你的应用具备接受 BOOT_COMPLETED 的 broadcast receiver | 不容许 |
须要注意的是，案例一中 NEW_OUTGOING_CALL intent 在 Q 开始以前就 broadcast这个intent。
咱们在 Android Q 版本中加了一个相对较新的 API，叫做 call redirection service，若是你的应用是用来接受 incoming call 或者是要处理一些打电话进来的状况，咱们会建议在 Q 版本开始调用新的 APIs 。
7.系统绑定到应用程序的服务
| 案例 | 状况 | 是否容许 |
|---|---|---|
| 1 | 你的应用程序提供了 Autofill service 的实现 | 容许 |
| 2 | 你使用 JobScheduler 安排工做。当系统绑定到你的 JobServicfe，你但愿应用程序启动 activity | 不容许 |
8.该应用程序经过 CompanionDeviceManager APIs 与配套硬件设备相关联
例如，若是你的应用有 Wear OS by Google的支持，能够响应用户在配对设备上执行的操做。好比说，user在他的手表上作一些动做，companion APP 要弹出一个UI，在那样的场景中是容许启动activity的。
9.该应用程序是在 Device Owner 模式下运行的 Device Policy Controller
你受影响了吗？
咱们但愿开发者们能尽快注意这些方面：
- 您目前是否有从后台启动 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 和 Beta2 时你能看到 toast，但 Beta3 以后再不会看到它，但咱们仍有一个 setting 可让你暂时的去 disabled 它，叫作 allow background activity starts。若是你开了这个功能，你的应用能够暂时从后台启动这个 activity，但咱们只建议在适配时使用。
若是你想了解更详细的文档，请进入这个网站：