Android8.0 静态广播的接收方式改变

Android O 广播机制的改变

---

  在Android O之前，Broadcast广播作为Android系统的四大组件之一，其使用简单，操作方便，占用资源小等优点，使其成为了Android开发中最常用的夸进程通讯方案(比AIDL、ContentProvider使用的更为频繁)。但由此带来的隐患也是显而易见的，并且这种隐患快要达到不可控制的地步。主要表现在：

• 导致大量的第三方应用程序开机自启动。因为每个应用都有监听开机广播的权利，每个程序都可以在开机后迅速自我启动，最终导致大量进程在后台运行，系统资源消耗过度，带来系统运行卡顿、机器发热等问题。
• 肆意的广播发送和监听，再配合Android的Service组件，可以很容易的实现所谓的”不死程序“，各大第三方应用为了抢占市场，几乎都将自己变成”不死程序“，这更加剧了系统资源的占用和消耗，可以说，Android系统就是在这种恶意竞争中逐渐沦为”Android机不行，三个月之后就会越来越卡，能用两年已经很了不起了！“

  基于以上种种原因，从Android O开始，Google做了一系列规避措施，最直接的体现在两个方面：

1. 取消静态广播的支持。
   以前很好用的静态广播消息将接收不到，比如开机广播：“android.intent.action.BOOT_COMPLETED”，网络状态发生改变广播：“android.net.conn.CONNECTIVITY_CHANGE”。必须以动态的方式才能接收到，这就保证了”只有用户将你的应用置为前台应用，也就是用户正在使用你的应用的时候，该应用才有可能收到广播“。这一举措旨在解决应用开机自启动泛滥的问题。
2. 更改Service的启动方式。
   如果一个应用在后台去startService(比如在broadcast中)，企图在后台悄悄的运行跑流量，这将直接抛出异常。和广播类似，要启动一个服务，必须是”用户正在使用你的应用期间“才可行，或者你的服务是一个前台服务。这一举措旨在解决”应用后台自启动，成为不死应用，占用大量资源“的问题。

---

开机广播

对于android.intent.action.BOOT_COMPLETED 这个广播，虽然被禁用了，但是在实际的开发中还是很有必要的存在，很多操作还是需要该广播的支持。所以Google也没有把这个广播完全封死，如果应用的android:sharedUserId=“android.uid.system”，那么该应用还是可以以静态广播的方式注册和监听到它。而对于第三方应用，显然已经无法再收到这条广播了。

---

网络状态改变广播

对于android.net.conn.CONNECTIVITY_CHANGE，显然就没这么友好了，即使是android:sharedUserId=“android.uid.system” 的应用，也将收不到静态注册的广播消息。如要接收该消息，只能是两种方式：

1. 以动态注册广播形式注册
2. 以静态注册广播形式注册，在AndroidManifest.xml中指明该应用的SDK为低于26，比如 < uses-sdk android:minSdkVersion=“23” android:targetSdkVersion=“23” />。