即便是应用没有target O，其实在Android O上也还是会受到一些限制。其中最显著的一个限制就是后台wake-lock。Android M 和 N 上，息屏并保持静止一个小时后，doze启动，wake-lock才会释放；从Android O开始，应用的进程一旦空闲（通常也就是后台服务结束）或终止，wake-lock就会立即释放。但只要还有后台服务还在运行，wake-lock就仍然要等到doze启动后才会释放。
从Android O DP2开始，即便应用没有target O，用户现在也可以在系统设置中主动激活针对任何应用的后台限制（仅就原生Android O而言）。这也算是Google的一个曲线策略了，就如同当年Android 4.3时的AppOps隐藏设置。但是否会导致应用功能异常，以及限制程度与target O有否差别，就需要进一步观察了。
补充：验证发现DP2的后台限制对MiPush SDK的后台进程无效，依然可以长期存活。
----- 2017.7.26 更新：DP4 的大逆转 ----
在 DP2 和 DP3 中验证后台限制对大部分国内应用无效后，我向 Google 提交了一个 issue 反馈这个缺陷。在跟进过程中，发现了另一个去年他人提交的 issue，其中指出了一个从 Android N 开始就存在的低级代码bug，正是这个 bug 导致 Android N 的 OPS 限制 RUN_IN_BACKGROUND 和 Android O 的后台服务限制都只能停掉应用的第一个后台服务。如果应用有超过一个后台服务，则仍会继续在后台运行。（PS，向 Google 提交 issue 务必要严格按照模板附上所有必要的信息，否则很可能就会被对方直接忽略，造成像那一位同学去年就提交的 issue，还遗留到 Android O 差点酿成悲剧）
好消息是，DP4 终于修复了这个 bug，现在后台控制已经全面按照其设计预期生效。只要应用面向 Android O 开发或是用户主动开启了应用的后台限制，那么这个应用进入后台的1分钟后，其全部服务就会直接停止。之后只要它还处于后台状态，就无法再启动任何服务了，无论是通过自身的定时任务还是由其他应用主动启动。
不过事情也不是就此圆满了，这里还是得泼点冷水：
服务的启动（startService）在后台被屏蔽，但服务的调用（bindService）不受限制。也就是说大家所熟知的交叉唤醒还会继续肆虐，那些过去使用启动服务方式的交叉唤醒估计很快会转向调用服务方式。
服务的启动虽然在后台期间被屏蔽了，但应用中被设计为定期保活服务的周期任务还是会继续的周期运行，尽管它们并不明白自己已经无法启动服务了。也就是说 CPU 依然会被它们频繁唤醒，待机耗电并不能得到有效改善。
原文链接：
