发一篇推友@fake_dw的MIUI弹窗拦截的分析吧，具体的规则表就不放出来了，大家可以按照文章复现。效果：对MIUI中三方应用拉起非本应用的activity时，触发的拦截时的规则进行分析。触发拦截时的效果如下图所示。
先说结论：
分析流程，细节可能会有错误，但总体内容是正确的（因为逻辑一直在framework和service来回跳，比较绕） 首先复现弹窗，通过mCurrentFocus定位弹窗应用，如图1、2。图2，可知弹窗来自“手机管家”，提取包并逆向定位该界面。查看该activity的引用，发现没有引用。Manifest中activity为导出状态如图3
分析该activity代码后发现没有判断和前置逻辑，如图1。结合manifest的标签和logcat可以发现一个可疑的action：CHECK_ALLOW_START_ACTIVITY 如图2、3。
猜测相关逻辑实现在ams或pms中，于是提取framework和service的jar，以及miui的自定义miui-services.jar/miui-framework.jar。尝试miui-services.jar中搜索相关字串，可以有如下结果。在miui-services.jar中，分析后发现并非入口实现，但找到了发生在授权窗口启动前的调用：如图1、2
对helper代码分析后可知：1、如果uid=1000（即root应用）放行；2、intent中不包含启动检测intent放行，否则弹窗授权（”android.app.action.CHECK_ALLOW_START_ACTIVITY”）。如图1 因为此处并非初始实现位置，继续向下在miui-framework.jar中进行查找，可以找到用于判断的intent。如图2
通过此intent的调用，可以跟踪到位于该jar包miui.security.SecurityManager类中的getCheckStartActivityIntent方法。如图1
继续向上跟踪调用，可以找到再上一步中在getCheckIntent方法中发生了调用，通过对类SecurityManager的分析可知，其与位于miui-services的jar包中的SecurityManagerService通过Binder进行通信，完成了启动拦截判断、规则更新、拦截页面调用的操作。Services中：如图1、2 Framework中：如图3、4
通过对上述代码分析可知，此代码包含：MIUI图片/文件管控、唤醒拦截、唤醒弹窗授权。其主要判断位于framework内，涉及少数的远程调用不展开分析，直接给出结论。如图1 逆向代码如图2
之后进入正常的唤醒判断流程，如果目标应用已经启动，则跳过所有流程，允许唤醒。否则进行规则判断流程。
小总结
对代码分析可知规则如下：1、若“发起者” uid<10000（系统应用）或是“IFAAFaceManager.ERR_FACE_LOCKED”，放行；2、若“被唤醒”uid<10000或满足“IFAAFaceManager.ERR_FACE_LOCKED”则放行；3、若“发起者”与“被唤醒”为同包名，放行；4、若“被唤醒”应用在最近任务中，放行；5、不满足则云控弹窗
小彩蛋：弹窗授权包括了云控放行，而云控实现了按 包名/action/component 的三种方案。于是有了一个搞笑的情况：比如支付宝，miui应该是想按component或者action放行的，但他的包名又被加白了，细分规则等于白写了。然后恶意应用就可以利用支付宝浏览器任意拉起弹窗广告了。
原文始发于微信公众号（军机故阁）：MIUI弹窗拦截分析
