经研究，某些加固（如 Protectt.ai）通过直接启动对应应用主界面（如 KernelSU 管理器）的方式进行检测。由于直接启动活动并不在软件包可见性的限制范围内，用户需要手动启用激进的意图过滤器，HMA 才能拦截。之前我认为这种方式会破坏用户体验，因此加固不会使用，看来我高估它们的底线了。
举个例子说明为什么默认不启用该功能：如果用户对京东启用了白名单，且未将微信加入可见应用列表，则若未开启激进的意图过滤器，京东是可以直接拉起微信支付的；若开启了激进的意图过滤器，京东则无法拉起微信。因此，建议用户在任何时候都只使用黑名单模式。
此外，AOSP 仍存在大量软件包可见性问题（如我们昨天发现，通过传递错误的 display id 可以在不启动应用的情况下探测软件包存在性），考虑到谷歌认为非跨用户的软件包可见性问题均为低危，在可预计的将来，HMA 将仍是必需品。
—————————————
Research has shown that certain app protections (such as Protectt.ai) detect application existence by directly launching the target app’s main activity (for example, the KernelSU Manager). Since directly starting an activity is not restricted by the app visibility limitations, users need to manually enable the aggressive intent filter to intercept it. I previously thought this approach would harm user experience, so protections wouldn’t use it—but it seems I overestimated their restraint.
Here’s why this feature is not enabled by default: for example, if a user has used whitelist mode on JD (Jingdong) but has not added WeChat to the list of visible apps, if the aggressive intent filter is off, JD can still directly launch WeChat. If the aggressive intent filter is on, JD cannot launch WeChat. Therefore, it is recommended that users always use blacklist mode only.
In addition, AOSP still has numerous package visibility issues (for example, as we discovered yesterday, it is possible to know the existence of a package without launching the app by passing an invalid display ID). Considering that Google regards non-cross-user package visibility issues as low risk, HMA will remain essential for the foreseeable future.
548
160
60
18
17
12
4
4
3
3
1October 18, 2025 89K 117
