在做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，由于不能修改，就只能接受这个现实了。
（二）
android 4.0为了防止一些malware（恶意软件）不经用户启动就在后台运行，默认安装的程序在用户启动前是完全被系统忽略的，即使程序注册了广播，系统也不会给该程序传递广播。只有程序被用户运行过之后，消息广播才会生效。而且，即使程序已经运行过了，如果被用户Force Stop（强制停止），又会回到被系统忽略的状态。这个问题其实从3.1的时候就已经有了，最近用4.0的系统测试才发现了这个问题的存在，引起不少麻烦。
Broadcast Regression Confirmed
In a previous post, I cited evidence that the BOOT_COMPLETED broadcast will not work out of the box on Android 3.1 until the user uses your app.
It’s actually somewhat bigger than that.
In the issue that I filed seeking clarification, Ms. Hackborn indicated:
Starting with 3.1 when applications are installed they are in a “stopped” state so they will not be able to run until the user explicitly launches them. Pressing Force Stop will return them to this state.
As a result, when applications are first installed, they are totally ignored by the system until and unless the user manually launches something: clicking on a launcher activity or adding an app widget, most likely.
Developers who had been relying upon getting some sort of system broadcast without user intervention will need to adjust their apps for Android 3.1.
As I wrote in the previous post:
I expect that most apps will be OK. For example, if your boot receiver is there to establish an AlarmManager schedule, you also needed to establish that schedule when the app is first run, so the user does not have to reboot their phone just to set up your alarms. That pattern doesnot change – it’s just that if the user happens to reboot the phone, it will not set up your alarms, until the user runs one of your activities.
UPDATE: To clarify the above quote, once the user runs the app for the first time (and does not Force Stop it), everything behaves as before — a reboot will cause BOOT_COMPLETED broadcasts to be received and so on. However, if the user installs the app, until and unless they run the app manually, no broadcasts will be received. And if the user force-stops the app, until and unless they run the app manually, no broadcasts will be received.
This change is not terribly shocking, as it ratchets up the security another notch by limiting ways malware can run without user knowledge. While it does not offer perfect security — the malware can still install its own copy of an Angry Birds launcher icon and hope users screw up — it is an improvement.
