android O 对后台服务的限制
https://www.jianshu.com/p/1af2ce1f985c
现象
android o版本（8.0）及以上版本，当应用处于后台时执行startService时，会抛出如下异常：
image
Caused by: java.lang.IllegalStateException: Not allowed to start service ... app is in background uid UidRecord ...
初步理解为由于app处于后台时startServic不被允许
原因分析
从android O版本开始，google为了控制资源使用增加了两项后台限制：
-
后台服务
-
广播
其中对于后台服务的限制，指的是如果应用处于后台，则不允许直接使用startService。
那什么是后台应用？后台的对立面是前台，google对于前台的定义如下：
-
具有可见的activity（不管该activity已启动还是已暂停）
-
具有前台服务
-
有关联的前台应用（如壁纸，通知侦听器等）
具体可参考官方链接：
https://developer.android.com/about/versions/oreo/background
解决方案
既然我们使用了后台服务，必然是一些无需用户感知的场景，故考虑替换为前台服务的可能性不大；
从google对前台应用的解释入手，可以通过制造前台场景的方式使自己的应用处于前台；
官方还提及了JobScheduler替代后台服务的方案，可以根据的业务场景选择是否使用；
startService的方式也不需要完全放弃。为了适配8.0手机，需要先判断应用是否在前台再决定是否使用startService；
判断应用是否在前台的方式很多，主要原理有两种：
-
通过AM判断应用前台activity个数
-
通过actvitiy生命周期回调计数（Activity回调、ActivityLifecycleCallbacks）判断是否有前台界面
实现的方式很多，自行google
设置targetSdk < 26也可以实现该新特性规避。
源码分析
startService大致流程如下：
ContextImpl#startServce ->
ContextImpl#startServceCommon ->
AMS#startService ->
ActiveServices#startServiceLocked ->
AMS#checkAllowBackgroundLocked
8.0.0
ContextImpl.java#startServiceCommon
image
红框中为日志信息的来源
ActivityServices.java#startServiceLocked
image
另一处Log信息的来源：app is in background
r.startRequested第一次初始化，默认为false；fgRequired为传入的值false，故可以进入后续逻辑；
通过AMS#getAppStartModeLocked获取的allowed为决定值，意思是是否允许后台运行，返回值有多种类型（从代码提交中可以看出原先是boolean，现在是int）。
google 在一年前（2016~2017）针对后台应用的判断以及后台执行限制做了大量的提交，从记录中可以看到：
image
image
之前提到通过设置targetSdk<26的方式就可以，但是这仅仅是从8.0特性的代码层面分析得知，这种方式并不能阻止7.x系统中对后台服务的限制。
ActiveServices.java # startServiceLocked
image
7.1.1 AMS 是否允许后台服务启动所关心的主要还是 当前进程的优先级 和 是否有后台运行权限
image
8.0 AMS 中间的流程较7.x稍微复杂一些，大致流程如下：
AMS # getAppStartModeLocked ->
AMS # appServicesRestrictedInBackgroundLocked ->
AMS # appRestrictedInBackgroundLocked
image
这里相当于是后台服务特权的检查，只要满足三者之一：
-
有persistent权限
-
后台运行白名单
-
电源优化白名单
就直接可以使用后台服务，前两个均为系统应用才能设置；
均不满足则继续走后面的判断流程，重点来了，8.0中优先判断targetSdk是否在O版本及以上，是则直接返回不允许，否才会判断是否有后台运行权限！
image
所以，如果需要有后台运行的逻辑，8.0以下版本优先开启后台运行权限，8.0及以上版本优先开启电源优化白名单。
随着Android版本的更新，早先年使用的保活黑科技逐渐都失效了，现在需要着重在产品层面设计，引导用户开启相关权限才是迫在眉睫的需求。
总之，Google对后台的限制越来越严格，不仅限制了各种拉活行为，也限制了抢占后台资源的行为，各大app需要提前做好高版本适配。
更多相关文章
- AES加解密在Android(安卓)4.2上的Encryption error
- Android沉浸式标题栏状态栏字体颜色修改（小米和魅族以及Android6.
- Android(安卓)View requires API level 14 (current min is 8):
- 使用百度地图SDK 这是之前版本 现在的sdk v2-1-2使用方法完全改
- android 无界面service编程
- 获得联系人姓名，相关电话以及邮件地址sdk2.0
- Android(安卓)Studio 3.5 安装apk失败问题
- Android(安卓)获取git 版本号
- Android(安卓)SDK版本号 与 API Level 对应关系