時(shí)代在發(fā)展科技在進(jìn)步

1.問題簡述

我們公司是做智能電話的，隨著我們自己的應(yīng)用增多，還有方便讀取外置SD卡，都給了所有的程序系統(tǒng)權(quán)限，我們進(jìn)程間的通訊基本上都是使用的廣播，可以說是廣播滿天飛的狀態(tài)，同時(shí)打印的日志也是非常多的，這時(shí)候發(fā)現(xiàn)在打印的日志中存在Sending non-protected broadcast的Error信息，但是不會(huì)導(dǎo)致程序crash掉，因?yàn)榇蛴〉姆浅６?，因此想把它給解決掉不再讓他提示
還有發(fā)現(xiàn)就是非系統(tǒng)級(jí)應(yīng)用給系統(tǒng)級(jí)應(yīng)用發(fā)送廣播后，不會(huì)存在此提示

Sending non-protected broadcast

2.查找問題原因

查看源碼在ActivityManagerService中有個(gè)checkBroadcastFromSystem方法

    private void checkBroadcastFromSystem(Intent intent, ProcessRecord callerApp,
            String callerPackage, int callingUid, boolean isProtectedBroadcast, List receivers) {
        if ((intent.getFlags() & Intent.FLAG_RECEIVER_FROM_SHELL) != 0) {
            // Don't yell about broadcasts sent via shell
            return;
        }

        final String action = intent.getAction();
        if (isProtectedBroadcast
                || Intent.ACTION_CLOSE_SYSTEM_DIALOGS.equals(action)
                || Intent.ACTION_DISMISS_KEYBOARD_SHORTCUTS.equals(action)
                || Intent.ACTION_MEDIA_BUTTON.equals(action)
                || Intent.ACTION_MEDIA_SCANNER_SCAN_FILE.equals(action)
                || Intent.ACTION_SHOW_KEYBOARD_SHORTCUTS.equals(action)
                || Intent.ACTION_MASTER_CLEAR.equals(action)
                || Intent.ACTION_FACTORY_RESET.equals(action)
                || AppWidgetManager.ACTION_APPWIDGET_CONFIGURE.equals(action)
                || AppWidgetManager.ACTION_APPWIDGET_UPDATE.equals(action)
                || LocationManager.HIGH_POWER_REQUEST_CHANGE_ACTION.equals(action)
                || TelephonyManager.ACTION_REQUEST_OMADM_CONFIGURATION_UPDATE.equals(action)
                || SuggestionSpan.ACTION_SUGGESTION_PICKED.equals(action)
                || AudioEffect.ACTION_OPEN_AUDIO_EFFECT_CONTROL_SESSION.equals(action)
                || AudioEffect.ACTION_CLOSE_AUDIO_EFFECT_CONTROL_SESSION.equals(action)) {
            // Broadcast is either protected, or it's a public action that
            // we've relaxed, so it's fine for system internals to send.
            return;
        }

        // This broadcast may be a problem...  but there are often system components that
        // want to send an internal broadcast to themselves, which is annoying to have to
        // explicitly list each action as a protected broadcast, so we will check for that
        // one safe case and allow it: an explicit broadcast, only being received by something
        // that has protected itself.
        if (intent.getPackage() != null || intent.getComponent() != null) {
            if (receivers == null || receivers.size() == 0) {
                // Intent is explicit and there's no receivers.
                // This happens, e.g. , when a system component sends a broadcast to
                // its own runtime receiver, and there's no manifest receivers for it,
                // because this method is called twice for each broadcast,
                // for runtime receivers and manifest receivers and the later check would find
                // no receivers.
                return;
            }
            boolean allProtected = true;
            for (int i = receivers.size()-1; i >= 0; i--) {
                Object target = receivers.get(i);
                if (target instanceof ResolveInfo) {
                    ResolveInfo ri = (ResolveInfo)target;
                    if (ri.activityInfo.exported && ri.activityInfo.permission == null) {
                        allProtected = false;
                        break;
                    }
                } else {
                    BroadcastFilter bf = (BroadcastFilter)target;
                    if (bf.requiredPermission == null) {
                        allProtected = false;
                        break;
                    }
                }
            }
            if (allProtected) {
                // All safe!
                return;
            }
        }

        // The vast majority of broadcasts sent from system internals
        // should be protected to avoid security holes, so yell loudly
        // to ensure we examine these cases.
        if (callerApp != null) {
            Log.wtf(TAG, "Sending non-protected broadcast " + action
                            + " from system " + callerApp.toShortString() + " pkg " + callerPackage,
                    new Throwable());
        } else {
            Log.wtf(TAG, "Sending non-protected broadcast " + action
                            + " from system uid " + UserHandle.formatUid(callingUid)
                            + " pkg " + callerPackage,
                    new Throwable());
        }
    }

其中的一段話描述

image.png

大致的意思我理解為，系統(tǒng)級(jí)應(yīng)用發(fā)送的廣播應(yīng)該受到保護(hù)，以防止有居心不良之人，利用這些廣播找到漏洞
然后在看框架層代碼中顯示如下
frameworks\base\core\res\AndroidManifest.xml

image.png

3.解決方法

目前從看到的方法有

方案1.修改源碼

從frameworks層找到ActivityManagerService的checkBroadcastFromSystem這個(gè)函數(shù)，修改這個(gè)函數(shù)，徹底解除系統(tǒng)的這個(gè)消息

方案2.修改框架層的AndroidManifest

將自定義添加的廣播，添加至frameworks\base\core\res\AndroidManifest.xml 文件中，這樣也不會(huì)報(bào)錯(cuò)
格式為<protected-broadcast android:name="com.pzdf.action_checkNetState" />

方案3.修改自己應(yīng)用的AndroidManifest

同上一個(gè)方法一樣，也可以將廣播添加到自己系統(tǒng)級(jí)應(yīng)用的AndroidManifest.xml文件中，效果與上一個(gè)方法一致

方案4.給廣播添加上權(quán)限

AndroidManifest.xml添加權(quán)限
<permission android:name="com.android.permission" />
<uses-permission android:name="com.my.permission" />
發(fā)送接收廣播地方
sendBroadcast(intent, "com.android.permission")
registerReceiver(receiver, filter,"com.android.permission", null)

4.題外話

在使用方案2或者方案3的時(shí)候會(huì)有個(gè)問題
非系統(tǒng)權(quán)限的應(yīng)用給系統(tǒng)級(jí)應(yīng)用發(fā)送廣播會(huì)報(bào)出安全異常
如下

Permission Denial