不是所有的牛奶（以android.intent.action*开头的broadcast）都叫特仑苏（protected-broadcast）

    标题这么设置，是因为我所描述的问题非常拗口

。

    为了方便理解，我首先演示一个视频，地址在：http://v.youku.com/v_show/id_XNzc5Njk4NDc2.html

    通过视频我们可以看到，android系统都没有很好的处理这个问题，导致一个无任何权限的程序可以发送android.intent.action.CLOSE_SYSTEM_DIALOGS这个broadcast，让notification自动关闭。当然，视频中，攻击程序持续发送这个广播，让notification永远无法打开。

    现在，大多数的安卓app开发者无法区分以android.intent.action*开头的broadcast是否是protected-broadcast。另外由于碎片化的原因，一些broadcast在某系统版本下不是protected-broadcast，在另外的一些系统下，又变成了protected-broadcast了。具体可参考各版本的frameworks\base\core\res目录下的AndroidManifest.xml文件。

    目前，根据我们的观察，对protected-broadcast的处理有几种方式：

    1、明确指明发送“非”protected-broadcast的广播者所需要的权限。如，TrustlookSecurity，其在处理android.intent.action.BOOT_COMPLETED这个广播时，明确了发送者的权限：android.permission.RECEIVE_BOOT_COMPLETED。



    Trustlook Security的这种设置比较让人眼前一亮，因为很少有程序对这个广播的发送方进行限制，只是Trustlook Security支持的版本包括：

<uses-sdk

android:minSdkVersion="14"

android:targetSdkVersion="19"

> 

 

    我没有去翻阅这些版本对应的AndroidManifest.xml，尚未确认这个广播在这些系统版本下是否都是protected-broadcast，如果在某些版本下不是，那在这些版本下，TrustlookSecurity可能永远无法处理这个广播了。

 

    2、干脆不指明“疑似”protected-broadcast的广播需要的权限。目前大部分的程序都是这么处理的，这容易导致另外一个问题，即任何一个程序可以发送非protected-broadcast的广播，导致程序出现各种异常。比如facebook在处理android.intent.action.DOWNLOAD_COMPLETE时，就未对发送方进行限制，程序内又没有很好的处理这个广播，导致其崩溃。

 

    好了，现在的问题是：设置、不设置权限都不对，那这就是个无解的问题，咋整？其实我也没有个好的办法，唯一我能建议的是，不要处理这些以android.intent.action*开头的广播（除非你确认过你所支持的版本的每个AndroidManifest.xml）。如果必须使用，那应该在代码中多进行验证，确保发来的消息不致导致程序的异常。