在Android逆向和安全测试这个圈子里，“免Root持久化Hook”始终是个让人又爱又恨的话题。Frida作为动态插桩的标配工具，大多数时候都依赖设备Root权限来注入目标进程；一旦目标App做了Root检测、环境检测甚至反调试，这条路就会越走越窄。另一种常见方案是重打包APK塞Gadget，但又逃不过签名校验和完整性校验，商业App稍微上点强度就破功。我最近在Android 9设备上做了一套基于AOSP源码定制的方案，直接把Frida-Gadget做成系统镜像的一部分，让目标App每次启动都会自动加载Hook环境，全程不需要Root、不需要重打包目标应用，应用自己也感知不到异常进程和注入痕迹。这套方案的核心思路，就是在系统框架层“偷梁换柱”——用自己的系统镜像，让系统替你把Hook环境装进目标进程。下面把整条技术链路和踩过的坑完整复盘一遍。
1. 免Root Hook的常规路径，为什么都绕不开持久化难题
先说清楚一个前提：这里说的“免Root”，不是设备上完全没有Root权限，而是目标应用无法检测到Root环境，也不依赖你在运行时去提权注入。市面上常见的免Root注入方案有两条路：重打包APK、利用调试漏洞或旧系统漏洞提权。这两条路在Android 9这个时间节点上都存在明显短板，理解这些短板，才能理解为什么最后我会选择去改AOSP。
1.1 重打包方案与签名校验的死结
重打包的思路很朴素：把Frida-Gadget的so文件塞进目标APK的lib/目录，在smali层加一行System.loadLibrary("frida-gadget")，再用apktool回编译并重签名。流程本身不难，但在实战场景里有几个绕不开的致命点。第一是签名校验：目标App一旦在代码里调用了PackageManager去核对签名哈希，或者接入了第三方加固厂商的“完整环境校验”，重打包后的APK基本一启动就闪退或直接提示“非法篡改”。第二是DEX校验：加固过的App通常会做二次加载和完整性校验，任何smali层的改动都可能触发“文件被篡改”之类的崩溃。第三是渠道包和热更新：很多App的多渠道包会动态下发补丁，重打包的版本根本没法走正常更新链路，一升级就回到原点。
所以，重打包只适合测试那些没有安全防护的小应用，稍微正规一点的App你就得考虑别的办法。
1.2 Root注入方案与检测面的博弈
用Root权限做注入，比如Magisk模块里挂一个post-fs-data.sh脚本去ptrace或zygote注入，比重打包要优雅得多，不用改动目标App的代码。但问题在于，现代Android App对Root环境的检测已经发展成一整套体系：RootBeer、MagiskHide检测、SafetyNet、Play Integrity等等。它们会检查su二进制是否存在、/system/bin下有没有可疑工具、mountinfo里有没有被挂载的模块、当前进程是不是运行在zygote派生链上，甚至检测frida-server的默认端口。你为了注入而暴露的Root环境，恰恰是环境检测最敏感的部分。
即便你用Magisk Hide把Root藏得再好，frida-server这个进程本身也是个“靶子”：/proc/self/maps里能看到frida-agent的内存映射，SMAPS里会有frida字符串，默认端口27042更是一扫一个准。也就是说，传统注入方式的攻击面太多了。
1.3 为什么“系统镜像持久化”才是正解
换个角度想：如果注入行为发生在系统框架层，目标应用进程从zygotefork出来的那一刻就已经带着Hook环境了，那么“应用外部是否存在多余进程”这个问题就不存在；如果设备上根本没有su、没有Magisk、没有多余端口，Root检测自然也失去意义。要做到这一点，唯一的路径就是自己编译一个系统镜像，把Gadget“内建”进Android系统里。这个思路有几个天然优势：
- 目标App看到的进程树完全是干净的，没有
frida-server之类的辅助进程 - 注入时机远早于App自己的
attachBaseContext，甚至早于Application创建，Hook点覆盖面更广 - 因为Gadget是系统的一部分，SELinux、hidden API这些限制都可以在源头调整
- 只要不刷回原厂镜像，Hook环境就是持久的，重启、升级App都不会丢失
代价也很明显：你得有设备对应的AOSP源码并完成编译，把Gadget集成进系统，这个工程门槛比写个脚本要高得多。但如果你手里正好有一台可以解锁Bootloader的Pixel或一加设备，这套方案的综合体验远超前面两条路。
2. Frida-Gadget的三种加载模式，以及持久化该选哪一种
Frida-Gadget本身是Frida官方提供的一个可执行/可加载库，设计初衷就是让你不依赖frida-server完成Hook。Gadget的配置和行为由libfrida-gadget.config.so或者同名的.config.so文件控制，但很多人对它的加载模式理解不够深，导致在持久化场景里选错方案。这里先花点篇幅把Gadget的机制讲透。
2.1 Gadget的三种模式：Script、Listen、Connect
Frida-Gadget有两种主要运行形态：Script模式和Listen模式。Connect模式本质上是Listen模式的变体，只是主动去连接指定的Frida服务端。我整理了一张对照表方便你理解：
| 模式 | 配置方式 | 典型用法 | 持久化适配程度 |
|---|---|---|---|
| Script | interaction: Script，加载指定JS | 静态导出Hook脚本 | 中，脚本需打包进镜像或数据分区 |
| Listen | interaction: Listen，监听端口等待frida客户端连接 | 动态调试、交互式Hook | 高，运行时随时连接，无需重编译 |
| Connect | interaction: Connect，主动连接远端的frida-server | 远程设备管理、跨网段调试 | 低，需额外维护远端服务，且会暴露目标设备 |
Script模式的好处是“点火即跑”，App启动时Gadget自动执行JS脚本，全程不需要客户端介入，非常适合稳定的自动化检测。但代价是每改一次Hook逻辑都要更新脚本文件，而且如果你需要动态查看内存、调用栈，Script模式就不够灵活了。
Listen模式则相反，Gadget只负责把自己加载进进程并且起一个监听端口，真正的Hook逻辑由外部Frida客户端（也就是你电脑上的frida命令行工具）在需要的时候推送上去。这对测试场景非常友好：你可以先让App正常跑起来，然后随时frida -H 设备IP:端口 -f com.xxx连接进去操作，Hook逻辑可以现场改、现场试，不用反复刷机。
我在持久化方案里首选Listen模式，原因有两个：第一是灵活性，Gadget本身不携带任何业务逻辑，不会被反病毒引擎根据静态特征识别；第二是维护成本低，App每次启动都监听同一个本地端口，我可以在宿主机上写好批处理脚本，测试时一键连接，不测试时完全不打扰App运行。
2.2 Gadget的配置格式与加载顺序
Gadget被加载时会先去同目录找一个libfrida-gadget.config.so文件，如果没有，再找libfrida-gadget.so同名的.config.so；都找不到的话，Gadget会以默认的Script模式尝试加载同目录的*.js文件。这个加载顺序很容易踩坑，我最初就是把配置文件命名成了frida-gadget.config.so，结果一直没生效。
标准的Listen模式配置长这样：
{ "interaction": { "type": "listen", "address": "127.0.0.1", "port": 37008, "on_load": "resume" }, "log": { "level": "info", "file": "/data/local/tmp/frida-gadget.log" } }注意on_load: "resume"这一项。默认情况下，Gadget在Listen模式里加载完成后会让进程停留在暂停状态，等待客户端连接。如果不设置on_load: "resume"，App会在启动阶段被卡住很久，尤其是那些在主线程里做初始化的大型应用，可能直接ANR。这个字段是持久化场景下的关键配置之一。
2.3 为什么Listen模式更适合持久化
持久化的本质是“这个Hook环境长期存在、可随时使用”，而不是“每次启动固定执行一段逻辑”。如果我用Script模式，遇到需要改Hook函数参数或者绕过新检测逻辑的情况，就得想办法更新脚本文件，而在/data分区被SELinux防写、/system分区只读的情况下，更新脚本并不轻松。
Listen模式把“加载环境”和“运行逻辑”解耦了。我刷一次机，把Gadget固化进系统，之后想Hook什么、想改什么逻辑，都通过Frida客户端的Python脚本实时操作，完全不碰设备上的文件。而且因为Gadget配置里监听的地址是127.0.0.1，外部进程扫描端口时只能看到一个本地回环端口，比frida-server全局监听的方式隐蔽得多。
另外要提醒一下，监听端口可以随意改成不常见的数字，没必要用默认的27042。虽然监听在本地回环地址上已经降低了不少暴露风险，但改个高位端口总有备无患。
3. AOSP源码修改的关键点：注入时机、进程白名单与SELinux放行
这套方案里技术含量最高、也最容易翻车的部分，就是AOSP源码怎么改。如果只是把Gadget的so文件塞进/system/lib，那Gadget永远不会被自动加载，因为Android系统根本不知道有它。你得在合适的位置插入一段逻辑，让系统在特定的时间点把它加载到目标进程里去。
我以Android 9的AOSP分支为例，给你拆解三个核心修改点：注入时机、进程过滤、SELinux策略。
3.1 注入时机：把加载动作放在Zygote fork之后
Android上除了第一个system_server进程，所有应用进程都是Zygote通过fork()+execve()或纯fork()方式创建的。fork()之后子进程会继承父进程的地址空间，但如果直接改Zygote的代码，让它在fork之前就加载Gadget，那所有应用进程都会带着Gadget跑，资源开销太大，也容易被检测。正确做法是在Zygote完成fork之后、目标App的Java代码运行之前，插入一个原生层加载动作。
AOSP里负责这个过程的主要是frameworks/base/core/java/com/android/internal/os/ZygoteInit.java里的ZygoteConnection处理流程，但更底层的调度逻辑在app_main.cpp和AndroidRuntime.cpp。我在Android 9上走了一条相对干净的路径：修改ZygoteConnection.java或与之一同配合的ZygoteInit.java，在handleChildProc里根据进程名决定是否加载Gadget。
核心伪代码思路如下：
// frameworks/base/core/java/com/android/internal/os/ZygoteInit.java private static void handleChildProc(...) { // 原有逻辑 ... if (shouldLoadGadget(processName)) { try { System.load("/system/lib/libfrida-gadget.so"); } catch (Throwable t) { Log.w(TAG, "Gadget load failed for " + processName, t); } } // 继续走Application初始化 }shouldLoadGadget可以做成一个白名单方法，比如比较进程名是否等于你目标应用的包名。这样除了指定App，其他进程完全不会加载Gadget，对系统整体性能和稳定性几乎零影响。
3.2 进程白名单与多目标支持
白名单是个小函数，但设计上有讲究。如果你只有一个目标App，直接equals比较包名就行；但更常见的情况是同一个应用有多个进程，比如主进程、push进程、remote进程，你未必希望所有子进程都加载Gadget。我在白名单里用了“前缀匹配+显式排除”的策略：
private static final String[] GADGET_PROCESS_PREFIXES = { "com.target.app", // 主进程 "com.target.app:push" // 子进程 }; private static boolean shouldLoadGadget(String processName) { if (processName == null) return false; for (String prefix : GADGET_PROCESS_PREFIXES) { if (processName.startsWith(prefix)) return true; } return false; }用startsWith而不是equals，是为了稳妥应对com.target.app后面可能带.debug之类后缀的情况。这个函数本身可以后续通过配置文件动态控制，但在Android 9上为了简单，我直接硬编码进源码里了，改一次刷一次机。
3.3 SELinux策略：给Gadget放行加载和日志
Android 9对SELinux的执行已经很严格了。system_app域有默认的load_library权限，但System.load加载/system/lib下的第三方库文件，需要确保目标文件有正确的安全上下文。否则你会遇到avc: denied { execute }之类的拒绝日志，Gadget虽然被调用了，但实际上加载失败。
我在修复SELinux问题时干了这么几件事：第一，用ls -Z /system/lib/libfrida-gadget.so确认它的上下文是system_file；第二，在AOSP的sepolicy目录下新增了针对性的te规则，允许zygote域加载这个库并且执行：
// device/厂家/设备名/sepolicy/gadget.te allow zygote system_file:file { read execute map }; allow zygote system_file:file { open getattr }; allow zygote self:process { execmem };第三，如果你像我希望的那样把Gadget日志写到/data/local/tmp下，还得给zygote域加一个写tmpfs或写data_file的规则，否则log文件根本建不出来。这里要特别说明：SELinux策略没有“一刀切”的通用方案，不同厂商的te文件组织方式差异很大，最稳妥的办法是在真机上跑一遍dmesg和logcat，看avc: denied的具体类型，再针对性补规则。
3.4 修改hidden API限制为系统调用让路
Android 9引入了针对非公开SDK接口的hidden API限制，但这个问题对系统进程来说其实很小，因为系统自身代码通常不会触发限制。但我还是要提一下：如果你后续想通过Gadget在系统上下文里调用一些人人喊打的隐藏API，比如@hide的ActivityManagerNative、内部Binder服务等，需要在build.prop里加一行参数或者在AOSP的config里把目标包名加入豁免名单。这个操作不是必须的，但如果你和一样喜欢在Hook脚本里直接操作系统服务，提前做了能省很多时间。
4. 编译与集成链路：从源码到可刷入镜像的完整流程
光改代码还不行，你得把改动编进镜像里真正刷进设备。这里面有一个很容易让人半途而废的坑：AOSP编译极其耗时，而且对环境要求苛刻。我这边基于Docker Ubuntu环境编译，整个过程反复踩了不少雷，下面把完整可复现的流程给你梳理出来。
4.1 主机环境准备与磁盘规划
AOSP Android 9源码全量编译需要至少300GB磁盘空间，内存建议不低于16GB，编译过程非常吃内存和I/O。官方推荐Ubuntu 18.04，OpenJDK 8，但这些只是“推荐”，我在Docker里用Ubuntu 20.04也摔了很多跟头，关键问题通常在依赖库和老版本Python的兼容性上。
磁盘规划非常重要，一个常见的坑是把源码放在/root下，而Docker默认的overlay文件系统会让I/O性能大打折扣。我建议挂载一个独立的ext4卷到/aosp，再在Docker启动时-v /aosp:/aosp进去。源码不要放在NTFS、FAT或者网络存储上，否则编译过程中的符号链接和硬链接操作会疯狂报错。
依赖我大致列一下（Ubuntu 20.04上实测能过）：
apt-get update && apt-get install -y \ git-core gnupg flex bison build-essential zip curl zlib1g-dev \ libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev \ libxml2-utils xsltproc unzip fontconfig python python3 \ openjdk-8-jdk bc libssl-dev libncurses5-dev注意python和python3在20.04上未必同时存在，AOSP的某些脚本还硬编码了python命令，所以最好建一个软链接把python指向python3或者安装python-is-python2。
4.2 同步Android 9源码与切换分支
源码同步用repo工具，你需要先配置Git用户信息，然后初始化对应设备分支。我用的是一加或者Pixel类设备的通用分支，比如android-9.0.0_r53。如果你的设备不是官方支持的Nexus/Pixel，得先去找第三方设备树和kernel，这个我后面会单独说。
同步命令是：
repo init -u https://android.googlesource.com/platform/manifest -b android-9.0.0_r53 repo sync -c -j8repo sync会持续很久，中途网络断了能续上，-c参数表示只同步当前分支，能省不少时间和磁盘。同步完成后务必确认frameworks/base和build、system/sepolicy这些核心目录都是完整存在的，否则后面一次编译错误就能让人崩溃。
4.3 修改源码的三个文件并放入Gadget产物
刚才说到的注入逻辑需要改到真正的源码文件里，以Android 9 AOSP为例，主要涉及这几个文件：
frameworks/base/core/java/com/android/internal/os/ZygoteInit.java：注入shouldLoadGadget逻辑system/sepolicy/private/zygote.te以及设备相关te文件：放行SELinux规则build/target/product/handheld_product.mk或你的设备mk文件：把libfrida-gadget.so和配置模块加入系统镜像的/system/lib或/system/lib64
关于Gadget产物的架构要特别注意：Android 9时代，64位进程没法直接用32位so，如果你的目标App是64位进程，必须放arm64-v8a版本的Gadget到/system/lib64；如果App还是32位，放armeabi-v7a版本到/system/lib。不清楚的话，最好两个架构都放，然后在shouldLoadGadget里根据Build.SUPPORTED_64_BIT_ABIS选择路径。
我在设备mk文件里加的集成方式类似这样：
PRODUCT_COPY_FILES += \ device/厂商/设备名/gadget/libfrida-gadget.so:system/lib/libfrida-gadget.so \ device/厂商/设备名/gadget/libfrida-gadget.so:system/lib64/libfrida-gadget.so配置文件我选择以.config.so结尾命名后放在同目录，Gadget会自动加载，不需要额外改代码路径。
4.4 执行编译与处理常见编译失败
环境就绪后就可以开编了：
source build/envsetup.sh lunch <你的设备编译目标> make -j8-j8这个参数要根据CPU核心数来定，实际上很多人在Docker里把-j开太高直接OOM，我后来调到-j4才算稳定。编译时间第一次全量大概2-4小时，看机器配置。如果你只改了frameworks/base和sepolicy，没有动kernel和vendor，其实可以只编译部分模块，再用fastboot单独刷system.img，省时省力很多：
make -j4 systemimage # 然后 fastboot flash system out/target/product/你的设备/system.img编译失败是家常便饭，最常见的三类错误是：Python脚本找不到模块、Java内存不足、以及SELinux策略编译时语法错误。Python问题靠软链接和pip补包；Java内存问题在lunch之前export ANDROID_JACK_VM_ARGS="-Xmx4096m"；SELinux策略问题只能仔细看编译输出里的neverallow冲突，一般在te文件里增加对应allow规则就能解决。
4.5 刷机与开机验证
刷机之前先确认设备的Bootloader已经解锁，否则fastboot flashing直接失败。解锁Bootloader会清空数据，这在测试机上问题不大，但生产机千万别这么干。刷机顺序一般是先刷boot、system，如果vendor也要更新就一起刷，最后刷userdata清掉旧数据避免加密分区导致开机异常。
刷完开机后先别急着连Frida，第一步看Gadget有没有真的加载成功。执行：
adb shell ps -A | grep <目标App包名> adb shell cat /proc/<目标AppPID>/maps | grep frida如果maps里能看到libfrida-gadget.so，说明注入成功了一半。如果找不到，先去logcat里过滤一下ZygoteInit的TAG，看我刚才写的那个Log.w日志有没有打出来。如果没有日志，说明代码就没执行到，优先检查shouldLoadGadget的进程名匹配；如果日志打了但maps里没有，那就是SELinux或者架构问题。
5. 验证效果与排坑实录：从注入失败到SELinux权限拒绝
整个方案不是一蹴而就的，我在真机上调试时前后遇上了四五个不太容易发现的问题，每一个都花费了不少时间定位。这里按排查顺序还原完整的踩坑链路，给你做个参照。
5.1 坑一：Gadget被System.load但maps里毫无踪迹
我在第一次刷完镜像后，用白名单锁定了测试App，启动后ps能看到进程在跑，但/proc/PID/maps里死活搜不到frida相关的内存映射。回头看logcat，ZygoteInit里的Log.w根本没打出来——说明代码压根没执行到。我排查了很久才发现是进程名的坑：Android 9上的应用进程名在Zygote fork之后、真正exec之前，有一段期间还保持着类似com.android.systemui之类的默认值，或者包名还没完全初始化。我在handleChildProc里太早做了进程名判断，自然匹配不上。
解决办法是把判断逻辑延后到handleChildProc靠后的位置，甚至可以放到ActivityThread.main()外面。要记住的是，Zygote注入时机非常微妙，fork之后进程名从“命令行参数”到“最终进程名”之间有一段时间窗，最好是等系统里进程名已经完全设置好了再判断。如果拿不准，直接在白名单里把整个过程名列表打印出来，用logcat看一眼实际值，再回源码里改。
5.2 坑二：SELinux denial导致加载静默失败
第二次刷完，logcat里能看到那段日志了，但maps里依旧没有so的踪迹。我查了中招后的完整日志，发现一堆被截断的avc: denied信息。最典型的日志长这样：
avc: denied { execute } for pid=xxxx comm="app_process" name="libfrida-gadget.so" dev="sda1" ino=xxxx scontext=u:r:zygote:s0 tcontext=u:object_r:system_file:s0 tclass=file这个问题我在3.3节里提过，但真正修的时候还有一层坑：即便你给zygote域加了execute，还有execute_no_trans、execute_mmap、map等多个权限需要一起放行。而且Android 9的system_file类型默认对zygote是允许map的，但Gadget加载时会申请execmem（因为Frida需要动态生成代码），这个权限在SELinux策略里默认不允许。所以我的gadget.te里实际上写的是：
allow zygote self:process { execmem execstack }; allow zygote system_file:file { read execute execute_no_trans map open getattr };execstack单独放行会有一定风险，但它只是允许在用户态栈上执行代码，对于动态插桩来说是必要之恶。编译SELinux策略前，务必用audit2allow之类的工具分析dmesg里实际的denied信息，不要手动堆权限，否则会触发neverallow冲突。
5.3 坑三：Listen模式无响应，端口始终连不上
总算把Gadget成功加载进进程了，我满心欢喜地用frida -H 127.0.0.1:37008去连，结果一直报unable to connect to remote frida-server。查了端口，没起来；查了日志文件，发现Gadget的log里提示：
Failed to load script: libfrida-gadget.config.so问题出在Gadget会把同名的.config.so当成一个“配置文件去加载”，而我实际放的是libfrida-gadget.so和libfrida-gadget.config.so两个文件。理论上它是支持的，但AOSP拷贝文件时可能把.config.so改名成了.so，导致找不到。后来我检查/system/lib64下的文件清单，发现.config.so确实被拷贝了，问题是Gadget在加载时会自动把后缀里的.config去掉再查一次，逻辑上有歧义。稳妥的解法是把配置文件单独命名为frida-gadget.config.so，并确保和so文件在同一目录；或者在代码里用System.loadLibrary("frida-gadget")时显式传入绝对路径，同时把配置文件名改成frida-gadget.config.so。
这个坑在正常开发环境里几乎不会遇到，只有AOSP这种对文件命名和打包有严格规则的场景里才会被放大。
5.4 坑四：目标App的崩溃与ANR
当我把Gadget成功加载后，紧接而来的是目标App在某些版本上启动崩溃，某些版本上则卡在启动页。崩溃日志显示是加载了不兼容的原生库，因为Gadget使用的部分指令集和目标App里的其他so发生冲突。但更多情况是ANR——由于Gadget在Application初始化前执行，如果监听端口尚未准备好，目标进程会长时间阻塞在启动阶段。
这个问题最终是靠调整配置文件和加载时机解决的。一方面，配置里一定要加"on_load": "resume"，让Gadget不要一开始就暂停目标进程等待客户端；另一方面，我在Java层做了一个延迟加载，让Gadget不在handleChildProc里同步加载，而是发一个消息到主线程消息队列，在Application启动后再异步加载。这样既避免了ANR，又保证了Hook点不会太晚。
异步加载的伪代码大致是这样：
if (shouldLoadGadget(processName)) { new Thread(() -> { System.load("/system/lib64/libfrida-gadget.so"); }).start(); }不过线程方式有个副作用：Gadget加载的时机可能晚于attachBaseContext，如果目标App在很早的时候就有反调试或Root检测，可能错过第一波Hook时机。这个需要你在“稳定性”和“早期性”之间做取舍，我最终选了延迟100ms再加载，实测能覆盖大部分场景。
5.5 动态验证：用Frida客户端连通并执行Hook
一切跑通之后，我的验证流程是这样：先确保设备已经刷入定制镜像，目标App已经处于运行状态；然后在宿主机上执行：
frida -H 127.0.0.1:37008 -n <目标进程名> -l /path/to/hook.js由于Gadget监听的是设备本地回环地址，宿主机不能直接连接到设备端口，需要通过adb forward把本地端口转发到设备端：
adb forward tcp:37008 tcp:37008 frida -H 127.0.0.1:37008 ...连接成功后，frida会自动识别当前进程并推送hook.js里的逻辑，整个交互体验和用frida-server完全一致，但设备上没有任何frida-server进程，也没有Root权限的痕迹。这里给个小建议：验证时先做一次最基础的Java.perform输出日志，确认整个链路通了，再上复杂的Hook脚本，不然很容易区分不出是自己的JS问题还是Gadget问题。
6. 这套方案的适用边界、局限性与合规注意事项
文章写到这里，基本的技术方案和踩坑细节都讲完了。但我还是得泼点冷水：这套方案并不是万能的，它有很明确的适用边界，也有不少局限性。在动手之前把这些搞清楚，能帮你减少大量无效劳动。
6.1 适用场景：自动化测试、竞品分析、系统级调试
我做完这套方案后主要用途是系统级的自动化UI测试和性能分析。比如我需要钩住某个系统API统计冷启动时长、监控某个第三方SDK的回调链路、或者批量压测不同版本App的稳定性。这类场景要求Hook环境长期在线、稳定、不能干扰App正常运行，而且机器往往要7x24小时跑自动化，用传统Root方案很容易在长时间运行后被各种环境检测打到墙角。定制系统镜像的方案就很好地满足了这些需求：设备一旦刷好，就变成了一个自带Hook能力的“测试机”，随插随用。
如果你是做竞品分析，想摸清某个App的加密协议、网络请求结构或者内部逻辑，这套方案也很合适。但因为目标App不会感知到Hook环境，所以分析起来非常接近“黑盒中的白盒”，比抓包+重放的方式高效不少。
6.2 局限性：硬件绑定、刷机门槛、以及Gadget本身的可检测性
这套方案最大的门槛是硬件绑定：AOSP源码对应的设备有限，不是每一台手机都有完整可编译的device tree和kernel源码。而且解锁Bootloader这一关在部分地区、部分运营商政策下已经越来越难，Pixel和一加算是相对友好的，其他品牌你得事先调研清楚。另外，如果用户手机的AB分区、动态分区或dm-verity校验比较严格，后续OTA更新可能会把自定义system镜像直接覆盖掉，这也是持久化方案在真实长期使用里需要面对的运维问题。
即便我们做了一套“系统级注入”，Gadget本身在高级检测代码面前也不是完全隐形。Frida自带的一些字符串、调用栈特征、JS引擎特征在内存里仍然是可以被扫描到的，只是因为没有frida-server进程、没有Root环境，常规检测手段不容易发现而已。如果目标App真的上了商业级加固和反Frida检测，你仍然需要进一步做特征隐藏，比如编译魔改版Gadget、修改Gadget的导出符号和内置字符串。这一块细节极多，可以作为下一个阶段的专项研究。
6.3 合规注意事项
最后必须说一句：这套技术方案请只用于你自己拥有或得到了明确授权的设备与App，比如团队内部测试机、已授权的渗透测试项目、开源项目研究等。不要拿它去破坏他人的应用安全机制、绕过商业授权、或者做任何违反法律法规的事。Android系统的开放性和可定制性本意是让开发者有更多创造空间，合理使用这套技术能极大提升移动安全研究的效率，但滥用只会让整个安全社区被污名化。我在写这篇分享时，刻意隐去了具体设备和应用名，也是希望读者把关注点放在技术和原理上，而不是某个特定目标的攻防细节。
如果你最终决定走上改AOSP这条路，我的建议是先拿一台便宜的二手设备练手，把源码编译、刷机、SELinux策略这些基本功跑通之后，再考虑上正式环境。毕竟这套方案的日常运维成本几乎为零，但前期的工程量确实不小，一次成功的实践带来的收益也是不可替代的。过程中有什么新的坑和心得，欢迎随时交流。
