三星安卓系统BUG排查记录：云闪付、铁路12306、个人所得税、中国移动等App，长期闪退的根本原因分析

内容介绍、背景

这次我在三星OneUI系统发现的BUG，影响范围大，存在时间久，我觉得有几个原因：

• 从0复现的难度高，彻底理清机制之前很难用测试机稳定复现，只有日常使用三星才容易遇到
• 未经过梆梆企业版加固的包，不容易直观发现这个问题
• 由于这个BUG的机制，被结束的App不属于崩溃，APM平台统计不到数据，难以引起重视
• 这个BUG代码进行了判断，只有大陆用户触发，三星在大陆地区市场占有率很低

也因此才终于有这么一篇我认为值得分享的分析记录，上次写的分析证明系统BUG的博客是小米手机MIUI的setSystemGestureExclusionRects不生效的问题，都过去两年了。

---

这个BUG最开始是在云闪付App遇到的，为了领取国补，不得不下载和注册，但是当我接收验证码的时候，下拉状态栏查看验证码，云闪付App就直接闪退了。在App内的客服页面，想发录屏，选择文件之后又闪退。和App内的客服沟通的最后一句话，是问我手机是不是安装了Xposed等软件。我是绝对没有安装的。但是频繁闪退，我已经没心思在App回复客服了。

购买必需品，领不到国补很冤，像是硬亏几百块。想起工信部经常通报App违规收集信息，我先是给工信部反馈此问题，得到回应是它们不负责这方面。我又在云闪付App里面发现了中国银联的客服电话，向银联客服反馈几天后，接到回电，我又听到电话另一头云闪付的开发人员让客服问我是不是安装了Xposed等软件。又过了几天，客服通过了我的微信请求，我发过去录屏，客服给了我10元红包补偿。

再后来，我又在其他App 遇到了崩溃问题，但是这款App性质和云闪付类似，我还只是怀疑是不是它们有什么公共SDK存在问题（就像有些App检测frida，实际上只是某OAID相关的库libmsaoaidsec.so在检测frida）。再后来听说它们没有特有的公共SDK，然后我发现它们的特征是都使用了梆梆加固企业版，我又找了几个梆梆加固企业版的样本，发现确实和此有关，怀疑梆梆的检测环境逻辑在三星手机存在误判。

但是现象又和以往遇到的触发加固壳检测不太像，我印象中，梆梆的加固壳检测到环境异常，一般是在native层崩溃，并且给某些寄存器设置成错误编号，便于它们加固厂商排查问题和加白名单等，还有些壳是直接kill自身进程，或者固定延迟10秒再kill自身进程。而这些App，多点几次，比如尝试打开10次，会有一次不闪退，然后下拉状态栏或者切换App前后台，又闪退。

网络上有一些偏方，比如关闭RAM Plus，或者是进入开发者选项开启"禁用子进程限制"，确实可以解决这个问题，但是前者只是临时解决问题，没多久还会闪退，只是临时降低了存储空间占用+重启手机，临时避开了BUG逻辑而已。而后者，只是掩盖了问题，确实不再闪退，但是BUG仍然在对系统造成消耗，很快就有几百，甚至上千个没意义的进程默默在后台浪费系统资源，甚至由于文件描述符过多占用，造成系统进程异常，手机突然黑屏重启。还有一些其他偏方此处不提了，也不过是误打误撞，只有这篇文章才真正首次分析出根本原因。

排查此问题走的弯路还蛮多的：

• 系统刷新和回收幻影进程有特定的时机，对寻找稳定复现的路径造成了一点点误导
• 创建最终会被泄露的进程有特定的冷却时间，对寻找稳定复现的路径造成了一点点误导
• 最初没找到相应逻辑位置，中途误以为在vdex文件中，消耗了一点时间编译windows版本的vdexExtracter
• 手机没有Root，纯静态分析很麻烦，所以中途又去研究了是否有不存在变砖风险的临时Root漏洞可以利用
• 反编译了"智能管理器"之类的三星特有的系统App找线索

为了测试能否在更多设备上复现，我跑了两家三星体验店，一家得知我想测试低存储空间的情况，直接说"所有手机品牌剩余3GB的时候都会打不开软件，不是三星的问题"，怕我测出BUG，直接劝我走，说我"在这里会浪费时间影响他人体验"。然后我又去了5公里外的另一家体验店，刚把剩余存储空间小于3GB的触发条件达成，才发现展示机不能修改手机时间，如果不改时间，想自然复现此bug，至少需要大约3小时，而且一但屏幕关闭，体验店的展示机就会还原数据，一切白费，时间成本太高了，然后云测平台虽然免费，但是里面的测试机都是海外版，而从代码来看，只有大陆版本才会触发此BUG。

不过最后还是找到了一个大陆版本的云测平台。找了一部OneUI8.5的设备提取了相关文件，确定三星已在OneUI8.5版本修复此问题。 但是BUG代码属于apex模块，apex模块的版本和系统版本不一定完全对应。后续或许更低的OneUI版本也会收到相关模块的OTA。

从日志找线索

接下来的步骤再换到另一个App：用铁路12306演示。

不要对logcat过滤，放开全部级别、全部标签、全部包名的日志，搜索即将闪退的包名，比如铁路12306的com.MobileTicket，从最后一个倒着往前看。

这里AMS只是说进程退出了，但AMS这条日志不包含进程退出的原因，但是可以根据这个日志确定退出前pid是1760，继续搜索1760。

倒着找，可以看到进程被结束的原因是

Killing PhantomProcessRecord {c4b77f2 1815:1760:com.MobileTicket/u0a295}: Trimming phantom processes

进程是AMS主动结束的，这里提到了一个关键词phantom processes，本文这里就统一称作"幻影进程"。这里提到"Trimming phantom processes"，后文会根据此在AOSP中搜索，展开具体的清理逻辑。

---

Android普通应用App想创建进程，有两种方式，一种是在manifest里面给某个组件声明processName，另一种是fork创建子进程，加固壳或者是需要快速拷贝一份内存的时候（比如xcrash在捕获到崩溃时）常用到，还有就是结合execve一起用，比如执行某个命令，本质就是fork+execve，例如常见的捕获日志的方案就是用Runtime.exec或者ProcessBuilder启动logcat。

App进程通过fork创建的子进程，就是幻影进程。注意这里说的是普通应用App，所以Zygote调用fork创建出来的普通App进程不被定义成幻影进程。

梆梆企业版加固壳会通过fork创建子进程执行检测相关代码，如果fork创建的进程被结束，被保护的App进程也会跟随退出。

manifest里processName是给四大组件声明的，所以AMS本来就能管理它们的生命周期，但是native层调用fork创建出来的进程，framework没办法直接感知到，不容易管理，为了避免滥用，Android12开始限制了幻影进程的数量，默认32个。

进入adb shell之后，用dumpsys activity processes可以打印出来当前有哪些幻影进程。在可以复现崩溃的手机上执行之后：

e1q:/ $
e1q:/ $ dumpsys activity processes | grep -A 5 "PhantomProcessRecord"
    proc #0: PhantomProcessRecord {ec6ced2 1743:2588:top/1000}
      user #0 uid=1000 pid=1743 ppid=2588 knownSince=-22m26s620ms killed=false
      lastCpuTime=0 oom adj=-900 seq=3963
    proc #1: PhantomProcessRecord {6163ba3 2655:2588:top/1000}
      user #0 uid=1000 pid=2655 ppid=2588 knownSince=-10h16m30s253ms killed=false
      lastCpuTime=10 timeUsed=+60ms oom adj=-900 seq=3963
    proc #2: PhantomProcessRecord {b53ea0 4792:2588:top/1000}
      user #0 uid=1000 pid=4792 ppid=2588 knownSince=-8h19m1s625ms killed=false
      lastCpuTime=10 timeUsed=+40ms oom adj=-900 seq=3963
    proc #3: PhantomProcessRecord {6009a59 5690:2588:top/1000}
      user #0 uid=1000 pid=5690 ppid=2588 knownSince=-13h28m38s82ms killed=false
      lastCpuTime=10 timeUsed=+100ms oom adj=-900 seq=3963
    proc #4: PhantomProcessRecord {71f061e 8009:2588:top/1000}
      user #0 uid=1000 pid=8009 ppid=2588 knownSince=-6h16m7s358ms killed=false
      lastCpuTime=10 timeUsed=+20ms oom adj=-900 seq=3963
    proc #5: PhantomProcessRecord {546eeff 8181:2588:top/1000}
      user #0 uid=1000 pid=8181 ppid=2588 knownSince=-5h7m32s244ms killed=false
      lastCpuTime=10 timeUsed=0 oom adj=-900 seq=3963
    proc #6: PhantomProcessRecord {43fa4cc 8980:2588:top/1000}
      user #0 uid=1000 pid=8980 ppid=2588 knownSince=-4h37m15s947ms killed=false
      lastCpuTime=0 oom adj=-900 seq=3963
    proc #7: PhantomProcessRecord {5178315 10626:2588:top/1000}
      user #0 uid=1000 pid=10626 ppid=2588 knownSince=-13h51m27s689ms killed=false
      lastCpuTime=10 timeUsed=+90ms oom adj=-900 seq=3963
    proc #8: PhantomProcessRecord {c31662a 12436:2588:top/1000}
      user #0 uid=1000 pid=12436 ppid=2588 knownSince=-13h9m24s922ms killed=false
      lastCpuTime=10 timeUsed=+90ms oom adj=-900 seq=3963
    proc #9: PhantomProcessRecord {ca57c1b 14163:2588:top/1000}
      user #0 uid=1000 pid=14163 ppid=2588 knownSince=-8h52m42s943ms killed=false
      lastCpuTime=10 timeUsed=+50ms oom adj=-900 seq=3963
    proc #10: PhantomProcessRecord {62841b8 15184:2588:top/1000}
      user #0 uid=1000 pid=15184 ppid=2588 knownSince=-10h42m34s355ms killed=false
      lastCpuTime=10 timeUsed=+60ms oom adj=-900 seq=3963
    proc #11: PhantomProcessRecord {f7a3b91 15367:2588:top/1000}
      user #0 uid=1000 pid=15367 ppid=2588 knownSince=-11h53m21s647ms killed=false
      lastCpuTime=10 timeUsed=+80ms oom adj=-900 seq=3963
    proc #12: PhantomProcessRecord {857baf6 16294:2588:top/1000}
      user #0 uid=1000 pid=16294 ppid=2588 knownSince=-5h1m13s120ms killed=false
      lastCpuTime=10 timeUsed=0 oom adj=-900 seq=3963
    proc #13: PhantomProcessRecord {895bef7 17702:2588:top/1000}
      user #0 uid=1000 pid=17702 ppid=2588 knownSince=-9h18m23s947ms killed=false
      lastCpuTime=10 timeUsed=+60ms oom adj=-900 seq=3963
    proc #14: PhantomProcessRecord {1fbc164 17916:2588:top/1000}
      user #0 uid=1000 pid=17916 ppid=2588 knownSince=-12h26m38s906ms killed=false
      lastCpuTime=10 timeUsed=+70ms oom adj=-900 seq=3963
    proc #15: PhantomProcessRecord {475ffcd 18682:2588:top/1000}
      user #0 uid=1000 pid=18682 ppid=2588 knownSince=-5h49m46s190ms killed=false
      lastCpuTime=10 timeUsed=+20ms oom adj=-900 seq=3963
    proc #16: PhantomProcessRecord {fbc9082 19708:2588:top/1000}
      user #0 uid=1000 pid=19708 ppid=2588 knownSince=-7h4m42s286ms killed=false
      lastCpuTime=10 timeUsed=+20ms oom adj=-900 seq=3963
    proc #17: PhantomProcessRecord {ddd5393 19949:2588:top/1000}
      user #0 uid=1000 pid=19949 ppid=2588 knownSince=-11h31m48s133ms killed=false
      lastCpuTime=10 timeUsed=+60ms oom adj=-900 seq=3963
    proc #18: PhantomProcessRecord {d658fd0 20100:2588:top/1000}
      user #0 uid=1000 pid=20100 ppid=2588 knownSince=-13h41m24s354ms killed=false
      lastCpuTime=10 timeUsed=+100ms oom adj=-900 seq=3963
    proc #19: PhantomProcessRecord {efcbc9 20546:2588:top/1000}
      user #0 uid=1000 pid=20546 ppid=2588 knownSince=-10h59m58s866ms killed=false
      lastCpuTime=10 timeUsed=+60ms oom adj=-900 seq=3963
    proc #20: PhantomProcessRecord {ca732ce 20678:2588:top/1000}
      user #0 uid=1000 pid=20678 ppid=2588 knownSince=-6h9m4s943ms killed=false
      lastCpuTime=10 timeUsed=+10ms oom adj=-900 seq=3963
    proc #21: PhantomProcessRecord {dff95ef 22114:2588:top/1000}
      user #0 uid=1000 pid=22114 ppid=2588 knownSince=-8h25m48s257ms killed=false
      lastCpuTime=10 timeUsed=+40ms oom adj=-900 seq=3963
    proc #22: PhantomProcessRecord {b5bd8fc 22234:2588:top/1000}
      user #0 uid=1000 pid=22234 ppid=2588 knownSince=-4h55m37s266ms killed=false
      lastCpuTime=0 oom adj=-900 seq=3963
    proc #23: PhantomProcessRecord {1205b85 22569:2588:top/1000}
      user #0 uid=1000 pid=22569 ppid=2588 knownSince=-12h2m43s261ms killed=false
      lastCpuTime=10 timeUsed=+70ms oom adj=-900 seq=3963
    proc #24: PhantomProcessRecord {487adda 25387:2588:top/1000}
      user #0 uid=1000 pid=25387 ppid=2588 knownSince=-12h16m17s235ms killed=false
      lastCpuTime=10 timeUsed=+70ms oom adj=-900 seq=3963
    proc #25: PhantomProcessRecord {559a20b 26665:2588:top/1000}
      user #0 uid=1000 pid=26665 ppid=2588 knownSince=-10h52m53s85ms killed=false
      lastCpuTime=10 timeUsed=+70ms oom adj=-900 seq=3963
    proc #26: PhantomProcessRecord {60b88e8 26831:2588:top/1000}
      user #0 uid=1000 pid=26831 ppid=2588 knownSince=-5h44m9s538ms killed=false
      lastCpuTime=10 timeUsed=+20ms oom adj=-900 seq=3963
    proc #27: PhantomProcessRecord {2102b01 27440:2588:top/1000}
      user #0 uid=1000 pid=27440 ppid=2588 knownSince=-6h25m40s471ms killed=false
      lastCpuTime=10 timeUsed=+20ms oom adj=-900 seq=3963
    proc #28: PhantomProcessRecord {1c2cda6 28494:2588:top/1000}
      user #0 uid=1000 pid=28494 ppid=2588 knownSince=-9h0m16s439ms killed=false
      lastCpuTime=10 timeUsed=+40ms oom adj=-900 seq=3963
    proc #29: PhantomProcessRecord {efe53e7 30564:2588:top/1000}
      user #0 uid=1000 pid=30564 ppid=2588 knownSince=-4h49m9s391ms killed=false
      lastCpuTime=10 timeUsed=0 oom adj=-900 seq=3963
    proc #30: PhantomProcessRecord {b844b94 31655:2588:top/1000}
      user #0 uid=1000 pid=31655 ppid=2588 knownSince=-12h39m2s871ms killed=false
      lastCpuTime=10 timeUsed=+80ms oom adj=-900 seq=3963
    proc #31: PhantomProcessRecord {ed3763d 31761:2588:top/1000}
      user #0 uid=1000 pid=31761 ppid=2588 knownSince=-11h19m4s341ms killed=false
      lastCpuTime=120 timeUsed=+70ms oom adj=-900 seq=3963

  Foreground Processes:
    PID #12330: ImportanceToken { 2468a7a setProcessImportant() 12330 android.os.BinderProxy@a96522b }
e1q:/ $

可以发现有一堆top进程出现，而且knownSince字段可以看到启动时间没有什么周期性的规律，好像在使用手机期间更容易创建出"top"进程，ppid竟然都是2588，在我设备上就是system_server进程，uid也和system_server一样，是1000。

我这里写了个Demo，发现fork之后，dumpsys activity processes | grep -A 5 "PhantomProcessRecord"并不会立即打印出来我fork出的进程，而下拉手机状态栏的时候，才会被系统统计到，说明AMS统计幻影进程是有某些时机才触发的，系统在发现了幻影进程数量达到限制才会执行回收清理。所以下拉状态栏的时候会闪退，这也导致从现象看来太像是App自身的BUG了。

如果开发者选项里面勾选了"禁用子进程限制"，确实不再闪退了，所有App都能正常打开，正常使用，并且不久后top进程的数量就会突破32。这里调试的时候遇到了个坑，就是如果想再复现此BUG，再次关闭此选项之后，需要重启手机，否则幻影进程数量就不会再回收了。所以还有个更好的测试命令：

device_config set_sync_disabled_for_tests persistent
device_config put activity_manager max_phantom_processes 64

提升幻影进程数量上限后，短暂不再出现闪退问题，至此已经可以初步确定是系统出了BUG，一切都能说得通了，system_server进程oom_adj非常低，所以清理优先级很低，系统清理进程时是根据oom_adj清理的，所以反而是普通App的进程被清理掉了，具体的清理逻辑下文会提到。但是至此还不能确定触发top进程泄露的具体的触发时机，以及为什么top进程会出现泄露，所以还要继续分析。

尝试找top进程创建时机

top进程创建时机不太好确定，可以在adb shell里面执行一段脚本，然后正常使用手机的同时留意一下我们哪些操作触发了top进程的创建。

p=" "; while true; do for i in $(pgrep -x -u 1000 top; pgrep -x -P 2588 top); do case "$p" in *" $i "*) ;; *) T=$(date "+%Y-%m-%d %H:%M:%S.%N" | cut -c1-23); echo "$T $i"; p="$p$i ";; esac; done; sleep 0.5; done

其中2588是system_server进程pid。

通过这种方法收集到了更多信息：从launcher冷启动App、安装新的App时，会触发top进程创建。但是，并不是每次都创建，而是有几分钟的间隔时间。

反编译system_server，静态分析

为了猜测system_server为什么执行top命令，可以看一下top启动时候的参数，即使设备没有root，也可以通过/proc/[pid]/cmdline确定app启动时候的命令行参数，可以看到命令和参数是top -b -n 1：

（后来发现，其实top -b -n 1这个命令本身也可以看到top进程的命令行参数）。

用adb pull导出手机的/system/framework文件夹。由于jadx反编译出来的java代码可能有误、反编译失败、不完整，这里用baksmali，把所有jar转为smali代码。 以smali版本为准。寻找何处调用了"top"进程，搜索的关键词主要是ProcessBuilder、Runtime.exec、top，

然后发现确实没有地方启动top进程，所有调用exec的参数，都追踪了来源，确定没有地方调用top，此处几种可能：相关代码做了混淆、system_server还加载了其他位置的jar/dex、或者是逻辑位于native层。但是由于没有root权限，难以直观得知system_server进程加载了哪些dex/jar/so。

根据以往的一些积累，知道设备的/apex目录也存放了一些包含dex/so的模块。Android10开始引入apex机制，把一些模块放到/apex目录，而不是/system/framework，初衷是便于像在应用商店升级app一样动态升级某些系统模块，而不必升级整个手机操作系统。

但是由于没有root权限，也无法直接用ls获得当前设备的/apex目录列表，而/system/apex目录里面的dex在img格式文件当中，但这里不用考虑如何处理这个img文件，有个更快的技巧。system_server和普通app进程都是由zygote进程fork出来的，大部分模块早在zygote进程就加载好了。不用写代码，直接在adb shell里面run-as一个debuggable的app，再去打印相应的maps文件，如下图，通过这种方式先确定一些已经被zygote进程加载过的模块的路径，然后先把已知的模块导出，继续反编译查看是否有top相关的调用。

然而仍然没有找到关键的执行top命令的信息，但是如上图，我们看到了三星设备特有的apex路径/apex/com.samsung.android.shell/，虽然对于adb shell，/apex/不能直接ls，然而它子目录是可以的，如下图，就这样找到了存在BUG的关键文件：service-samsung-shell.jar。

就这样终于找到了调用top命令的位置：

1个函数里面的3个严重bug

对照了smali代码，确定jadx反编译出来的伪代码基本准确，直接贴出来：

private double getCpuUsage(String processName) {
    double result = 0.0d;
    try {
        Process process = Runtime.getRuntime().exec("top -b -n 1");
        BufferedReader in1 = new BufferedReader(new InputStreamReader(process.getInputStream()));
        int cnt = 8;
        while (true) {
            String str1 = in1.readLine();
            if (str1 == null) {
                break;
            }
            int cnt2 = cnt - 1;
            if (cnt <= 0) {
                break;
            }
            if (processName == null) {
                if (!str1.contains("%idle")) {
                    cnt = cnt2;
                } else {
                    String cpuTotal = str1.split("%cpu")[0];
                    String cpuIdle = str1.split(" +")[4].split("%")[0];
                    result = (Double.valueOf(cpuTotal).doubleValue() - Double.valueOf(cpuIdle).doubleValue()) / Double.valueOf(cpuTotal).doubleValue();
                    break;
                }
            } else if (!str1.contains(processName)) {
                cnt = cnt2;
            } else {
                result = Double.valueOf(str1.split(" +")[9]).doubleValue() / 100.0d;
                break;
            }
            return result;
        }
    } catch (IOException e) {
        Log.e(this.TAG, "Error getCpuUsage: \n", e);
    }
    return result;
}

我在我Android 16设备执行top -b -n 1的输出结果：

BUG 1

注意，代码里用str1.split(" +")[9]获取第10列，然而，第1列是PID，第10列是MEM，第9列才是CPU！导致获取到的CPU百分比完全错误。

或许在Android16之前的某个版本，这不是BUG，可能这是历史遗留问题，或许Android12、13还是正常的呢，但这里我觉得没必要去测试了。反正这一定是非常不好的做法，凭什么假定top命令的输出格式永远不变呢？

联想到以前的一个经历

我想起了以前一份工作中非常不好的经历，那就是领导非让用sha256sum命令获取文件的哈希值，因为领导说，"linux命令极度高效，应该会比你java效率高！"，由于领导没有系统学过计算机，甚至不了解进程和线程的关系，解释不通，也不听解释。

前同事还因此奉命使用系统自带的tar命令实现文件压缩，由于部分vivo系统对tar命令参数做了修改，导致部分用户功能异常，我们自己的测试机却无法复现，由于反馈比例较少，没有人重视，最终是随着这些机型被淘汰而不了了之，这些不好的经历还是不要展开了...。

BUG 2（本文重点）

此处使用Runtime.getRuntime().exec创建子线程，用BufferedReader读取输出结果，然而，由于cnt = 8，根本就不会把子进程的输出读取完毕，函数就退出了，子进程仍然在运行中，没有调用destroy，也没有调用close，这就是造成top进程泄露，最终引发App异常，甚至大量App闪退的根本原因。

如果用户根据网络上的教程勾选了"禁用子线程限制"，虽然表面上解决了闪退问题，但是top进程的泄露依然存在，文件描述符泄露依然存在，Android系统对单个进程的文件描述符数量做了限制，通常是1024，如果超过这个数字，会造成system_server进程异常，导致手机突然黑屏重启。

BUG 3

就算没有BUG1，也根本读取不到参数进程的CPU占用！这里cnt是8，然而根据我设备上的输出，除了读取top进程之外，只能额外读取到一个进程的CPU占用，很难刚好就是目标进程！

稳定触发BUG的测试路径

到这一步，就很容易找到触发BUG的必现路径了。

前面发现冷启动时会触发，以及偶然会触发，确实如此，其中一条链路梳理如下，因为三星做了一点定制，所以这里从设备导出的famework源码分析，而不能是AOSP源码。

经典面试题，App冷启动流程：用户点Launcher上的图标，ActivityStarter.execute内部调用startActivityUnchecked，调用到resolveReusableTask，获取PkgPredictorService服务，调用dexFilePreload：

直接来到刚才找到的jar中，dexFilePreload内部调用appTouchDownEvent：

然后内部用handler调用handleAppBoostTask：

handleAppBoostTask内部调用isSystemBusy，如下图，

其中的isSystemBusy调用getCpuUsage，至此BUG闭环了，如下图。另外果然App安装的时候会有地方触发它的调用，如上图。

这里贴出来，

private long getAvailRomSize() {
    File file = Environment.getDataDirectory();
    StatFs statFs = new StatFs(file.getPath());
    long blockSize = statFs.getBlockSize();
    long availableBlocks = statFs.getAvailableBlocksLong();
    long available = (((availableBlocks * blockSize) / 1024) / 1024) / 1024;
    this.SYSTEM_BUSY_UPDATE_TIME = 30000 * available;
    if (this.SYSTEM_BUSY_UPDATE_TIME < 300000) {
        this.SYSTEM_BUSY_UPDATE_TIME = 300000L;
    }
    return available;
}

public boolean isSystemBusy() {
    if (!this.mAppBoostInit) {
        return false;
    }
    if (System.currentTimeMillis() - this.mSystemBusyTime <= this.SYSTEM_BUSY_UPDATE_TIME) {
        return this.mSystemBusy;
    }
    this.mSystemBusyTime = System.currentTimeMillis();
    if (getAvailRomSize() <= this.APPBOOST_AVAILABLE_ROM_SIZE && getCpuUsage("com.google.android.providers.media.module") >= this.MP_CPU_LIMITATION) {
        this.mSystemBusy = true;
        return true;
    }
    this.mSystemBusy = false;
    return false;
}

这个函数里面用currentTimeMillis时间对上次判断结果做了缓存，这个有效期是动态计算的，在getAvailRomSize里面对缓存有效期做了更新，用手机可用空间的GB数量乘以30000毫秒（30秒），也就是说，剩余10GB的用户，缓存300秒，但是，这里还有最低阈值是300000毫秒（300秒，5分钟），也就是说最低也是5分钟才会调用到一次getCpuUsage函数。不过如果我们为了测试方便，可以直接去系统设置里面改手机时间，但是三星手机体验店里面的展示机不能改时间，云测机不太容易进入设置。

并不是说最低5分钟就一定会调用getCpuUsage，此处还有一个限制就是可用Rom空间（GB单位）必须小于APPBOOST_AVAILABLE_ROM_SIZE，这里是常量值是3，也就是说只有内存低于3GB的用户才会出现top进程泄露导致许多App闪退或者异常的问题。

所以稳定复现的路径：不要在开发者选项勾选"禁用子进程限制"（如果勾选了，需要取消勾选，然后重启手机），然后将可用内存空间调整到3GB以下，然后冷启动App大约32次，每次间隔5分钟（可以修改手机系统时间缩短间隔时间）。

还有一个前提条件，必须是中国版系统：

dexFilePreload内部没机会调用到appTouchDownEvent，也就不会触发此BUG，因为非中国版系统，mIpmAntiAgingController不被赋值：

Android16 清理幻影进程的顺序

最初和同事提到此问题时，有同事说："...我觉得不太可能是三星系统的BUG，App在前台，系统回收进程的时候不是优先回收后台的进程吗？照你这么说是Android系统有BUG吗？不太可能..."。

直接看代码，首先看前文提到的那个日志，位于trimPhantomProcessesIfNecessary函数中：

源码: cs.android.com/android/pla...

/**
 * Clamp the number of phantom processes to
 * {@link ActivityManagerConstants#MAX_PHANTOM_PROCESSE}, kills those surpluses in the
 * order of the oom adjs of their parent process.
 */
void trimPhantomProcessesIfNecessary() {
    if (!mService.mSystemReady || !FeatureFlagUtils.isEnabled(mService.mContext,
            SETTINGS_ENABLE_MONITOR_PHANTOM_PROCS)) {
        return;
    }
    synchronized (mService.mProcLock) {
        synchronized (mLock) {
            mTrimPhantomProcessScheduled = false;
            if (mService.mConstants.MAX_PHANTOM_PROCESSES < mPhantomProcesses.size()) {
                for (int i = mPhantomProcesses.size() - 1; i >= 0; i--) {
                    mTempPhantomProcesses.add(mPhantomProcesses.valueAt(i));
                }
                synchronized (mService.mPidsSelfLocked) {
                    Collections.sort(mTempPhantomProcesses, (a, b) -> {
                        final ProcessRecord ra = mService.mPidsSelfLocked.get(a.mPpid);
                        if (ra == null) {
                            // parent is gone, this process should have been killed too
                            return 1;
                        }
                        final ProcessRecord rb = mService.mPidsSelfLocked.get(b.mPpid);
                        if (rb == null) {
                            // parent is gone, this process should have been killed too
                            return -1;
                        }
                        if (ra.getCurAdj() != rb.getCurAdj()) {
                            return ra.getCurAdj() - rb.getCurAdj();
                        }
                        if (a.mKnownSince != b.mKnownSince) {
                            // In case of identical oom adj, younger one first
                            return a.mKnownSince < b.mKnownSince ? 1 : -1;
                        }
                        return 0;
                    });
                }
                for (int i = mTempPhantomProcesses.size() - 1;
                        i >= mService.mConstants.MAX_PHANTOM_PROCESSES; i--) {
                    final PhantomProcessRecord proc = mTempPhantomProcesses.get(i);
                    proc.killLocked("Trimming phantom processes", true);
                }
                mTempPhantomProcesses.clear();
            }
        }
    }
}

看这里Collections.sort，直接根据mPpid（父进程的pid）的oom adj排序，然后从oom obj较大的一端开始kill，直到幻影进程数量小于MAX_PHANTOM_PROCESSES。system_server的oom obj被定义为-900，从前面的adb输出也可以看到确实如此，而普通app的oom obj，可见前台是0，可见非前台是100，上一个可见app是700，普通app的oom obj，再怎么也不能比0更小了。

另外，从源码来看，还有另一种情况就是连带父进程一起结束，代码如下，这里不继续探索了。

/**
 * Kill the given phantom process, all its siblings (if any) and their parent process
 */
@GuardedBy("mService")
void killPhantomProcessGroupLocked(ProcessRecord app, PhantomProcessRecord proc,
        @Reason int reasonCode, @SubReason int subReason, String msg) {
    synchronized (mLock) {
        int index = mAppPhantomProcessMap.indexOfKey(proc.mPpid);
        if (index >= 0) {
            final SparseArray<PhantomProcessRecord> array =
                    mAppPhantomProcessMap.valueAt(index);
            for (int i = array.size() - 1; i >= 0; i--) {
                final PhantomProcessRecord r = array.valueAt(i);
                if (r == proc) {
                    r.killLocked(msg, true);
                } else {
                    r.killLocked("Caused by sibling process: " + msg, false);
                }
            }
        }
    }
    // Lastly, kill the parent process too
    app.killLocked("Caused by child process: " + msg, reasonCode, subReason, true);
}

OneUI8.5的修复

如图所示，用proc文件系统的方式获取cpu占用率，不再用top命令获取了。

其实还没太写完，也还没来得及研究IPM这里在做什么，时间太晚了，有时间再完善吧，这周末再补充点细节，就先这样发出来了，技术交流或者别的事可以联系我微信HKHSTECH（可能会改微信号，但几周内都不会换号）。