在做Android开发时，很多应用由于各种目的，希望在机器启动时被唤醒，一般的做法是写一个BroadcastReceiver，接收对应的boot action，当然别忘了在Manifest中添加permission "android.permission.RECEIVE_BOOT_COMPLETED“。但是最近在做4.0开发时，有同事声称这个广播接收不到了， 同时其他有人又说自己的能接收到，到底是怎么回事呢。
原来，在3.1之后，系统的package manager增加了对处于“stopped state”应用的管理，这个stopped和Activity生命周期中的stop状态是完全两码事，指的是安装后从来没有启动过和被用户手动强制停止 的应用，与此同时系统增加了2个Flag：FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES ，来标识一个intent是否激活处于“stopped state”的应用。当2个Flag都不设置或者都进行设置的时候，采用的是FLAG_INCLUDE_STOPPED_PACKAGES的效果。
有了上面的新机制之后，google觉得给所有的广播intent默认加上FLAG_EXCLUDE_STOPPED_PACKAGES会非常的Cooooool，能在一定程度上避免流氓软件、病毒啊干坏事，还能提高效率，就导致了本文题目中说的问题，RECEIVE_BOOT_COMPLETED广播如果用户没有运行过应用，就不会响应了。
不过google还是留了点余地，允许应用和后台服务通过给广播intent设置FLAG_INCLUDE_STOPPED_PACKAGES来唤醒处于“stopped state”的程序，也就是用户自己写的广播intent可以控制这个机制，但是系统自带的广播intent，由于不能修改，就只能接受这个现实了。
在3.1的更新文档中，能够找到上述修改的说明：http://developer.android.com/sdk/android-3.1.html#launchcontrols
但是如果是系统级的app就不受此限制