在做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就不受此限制