Android系统的现状
在 Android Q 版本以前的 Android 无论在前台后台都可以通过调用 startActivity 来启动。但这会出现一个问题，例如你正在用 Googlemap 来导航，但突然弹出了一个广告。这个行为其实会对用户带来很大的困扰，用户可能会卸载应用。
我们也在 Googleplay 上收到了一些用户反馈，其中一个用户提到，当他正在拍摄一个子女的重要时刻（毕业典礼或是孩子生日）时突然出现了一个弹出广告，错过了拍摄。
所以我们在 Android 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
这个场景较为复杂，需要看情况：| 案例 | 情况 | 是否允许 |
|---|---|---|
| 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
例如，你的应用是用来控制完全托管的企业设备，以及数字标牌和信息亭等专用设备。如果你是 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 和 Beta2 时你能看到 toast，但 Beta3 之后再不会看到它，但我们仍有一个 setting 可以让你暂时的去 disabled 它，叫做 allow background activity starts。如果你开了这个功能，你的应用可以暂时从后台启动这个 activity，但我们只建议在适配时使用。
如果你想了解更详细的文档，请进入这个网站：
Android Q Labs 直播专题页面
Android Q Labs 开场演讲
Android Q 有哪些更新
Android Q 现代化您的应用
Android Q 分区存储
Android Q 手势导航
Jetpack 更新
Android Q 在折叠屏设备的适配
通用系统映像介绍
Google Play 商店政策
Android Q 地理位置权限变更
Android Q 深色主题
Android Q Labs 总结演讲