写点什么

Android- 黑科技保活实现原理揭秘,kotlin 开发微信

用户头像
Android架构
关注
发布于: 刚刚

第二种方法就比较强力了,一般来说被 force-stop 之后,App 就只能乖乖等死了。


因此,要实现保活,我们就得知道 force-stop 到底是如何运作的。既然如此,我们就跟踪一下系统的 forceStopPackage 这个方法的执行流程:


首先是 ActivityManagerService 里面的 forceStopPackage 这方法:


public void forceStopPackage(final String packageName, int userId) {// .. 权限检查,省略 long callingId = Binder.clearCallingIdentity();try {IPackageManager pm = AppGlobals.getPackageManager();synchronized(this) {int[] users = userId == UserHandle.USER_ALL? mUserController.getUsers() : new int[] { userId };for (int user : users) {// 状态判断,省略..int pkgUid = -1;try {pkgUid = pm.getPackageUid(packageName, MATCH_DEBUG_TRIAGED_MISSING,user);} catch (RemoteException e) {}if (pkgUid == -1) {Slog.w(TAG, "Invalid packageName: " + packageName);continue;}try {pm.setPackageStoppedState(packageName, true, user);} catch (RemoteException e) {} catch (IllegalArgumentException e) {Slog.w(TAG, "Failed trying to unstop package "


  • packageName + ": " + e);}if (mUserController.isUserRunning(user, 0)) {// 根据 UID 和包名杀进程 forceStopPackageLocked(packageName, pkgUid, "from pid " + callingPid);finishForceStopPackageLocked(packageName, pkgUid);}}}} finally {Binder.restoreCallingIdentity(callingId);}}


在这里我们可以知道,系统是通过 uid 为单位 force-stop 进程的,因此不论你是 native 进程还是 Java 进程,force-stop 都会将你统统杀死。我们继续跟踪 forceStopPackageLocked 这个方法:


final boolean forceStopPackageLocked(String packageName, int appId,boolean callerWillRestart, boolean purgeCache, boolean doit,boolean evenPersistent, boolean uninstalling, int userId, String reason) {int i;// .. 状态判断,省略 boolean didSomething = mProcessList.killPackageProcessesLocked(packageName, appId, userId,ProcessList.INVALID_ADJ, callerWillRestart, true /* allowRestart /, doit,evenPersistent, true / setRemoved */,packageName == null ? ("stop user " + userId) : ("stop " + packageName));didSomething |=mAtmInternal.onForceStopPackage(packageName, doit, evenPersistent, userId);// 清理 service// 清理 broadcastreceiver// 清理 providers// 清理其他 return didSomething;}


这个方法实现很清晰:


先杀死这个 App 内部的所有进程,然后清理残留在 system_server 内的四大组件信息;我们关心进程是如何被杀死的,因此继续跟踪 killPackageProcessesLocked,这个方法最终会调用到 ProcessList 内部的 removeProcessLocked 方法, removeProcessLocked 会调用 ProcessRecord 的 kill 方法,我们看看这个 kill:


void kill(String reason, boolean noisy) {if (!killedByAm) {Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "kill");if (mService != null && (noisy || info.uid == mService.mCurOomAdjUid)) {mService.reportUidInfoMessageLocked(TAG,"Killing " + toShortString() + " (adj " + setAdj + "): " + reason,info.uid);}if (pid > 0) {EventLog.writeEvent(EventLogTags.AM_KILL, userId, pid, processName, setAdj, reason);Process.killProcessQuiet(pid);ProcessList.killProcessGroup(uid, pid);} else {pendingStart = false;}if (!mPersistent) {killed = true;killedByAm = true;}Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);}}


这里我们可以看到,首先杀掉了目标进程,然后会以 uid 为单位杀掉目标进程组。


如果只杀掉目标进程,那么我们可以通过双进程守护的方式实现保活;


关键就在于这个 killProcessGroup,继续跟踪之后发现这是一个 native 方法,它的最终实现在 libprocessgroup 中,代码如下:


int killProcessGroup(uid_t uid, int initialPid, int signal) {return KillProcessGroup(uid, initialPid, signal, 40 /retries/);}


注意这里有个奇怪的数字:40。


我们继续跟踪:


static int KillProcessGroup(uid_t uid, int initialPid, int signal, int retries) {// 省略 int retry = retries;int processes;while ((processes = DoKillProcessGroupOnce(cgroup, uid, initialPid, signal)) > 0) {LOG(VERBOSE) << "Killed " << processes << " processes for processgroup " << initialPid;if (retry > 0) {std::this_thread::sleep_for(5ms);--retry;} else {break;}}// 省略}


瞧瞧我们的系统做了什么骚操作?循环 40 遍不停滴杀进程,每次杀完之后等 5ms,循环完毕之后就算过去了。


看到这段代码,我想任何人都会蹦出一个疑问:假设经历连续 40 次的杀进程之后,如果 App 还有进程存在,那不就侥幸逃脱了吗?

2 实现方法

那么,如何实现这个目的呢?


我们看这个关键的 5ms。假设,App 进程在被杀掉之后,能够以足够快的速度(5ms 内)启动一堆新的进程,那么系统在一次循环杀掉老的所有进程之后,sleep 5ms 之后又会遇到一堆新的进程;如此循环 40 次,只要我们每次都能够拉起新的进程,那我们的 App 就能逃过系统的追杀,实现永生。


是的,炼狱般的 200ms,只要我们熬过 200ms 就能渡劫成功,得道飞升。


不知道大家有没有玩过打地鼠这个游戏,整个过程非常类似,按下去一个又冒出一个,只要每次都能足够快地冒出来,我们就赢了。


现在问题的关键就在于:


如何在 5ms 内启动一堆新的进程?


再回过头来看原来的保活方式,它们拉起进程最开始通过 am 命令,这个命令实际上是一个 java 程序,它会经历启动一个进程然后启动一个 ART 虚拟机,接着获取 ams 的 binder 代理,然后与 ams 进行 binder 同步通信。


这个过程实在是太慢了,在这与死神赛跑的 5ms 里,它的速度的确是不敢恭维。


后来,MarsDaemon 提出了一种新的方式,它用 binder 引用直接给 ams 发送 Parcel,这个过程相比 am 命令快了很多,从而大大提高了成功率。其实这里还有改进的空间,毕竟这里还是在 Java 层调用,Java 语言在这种实时性要求极高的场合有一个非常令人诟病的特性:


垃圾回收(GC);虽然我们在这 5ms 内直接碰上 gc 引发停顿的可能性非常小,但是由于 GC 的存在,ART 中的 Java 代码存在非常多的 checkpoint;


想象一下你现在是一个信使有重要军情要报告,但是在路上却碰到很多关隘,而且很可能被勒令暂时停止一下,这种情况是不可接受的。因此,最好的方法是通过 native code 给 ams 发送 binder 调用;


当然,如果再底层一点,我们甚至可以通过 ioctl 直接给 binder 驱动发送数据进而完成调用,但是这种方法的兼容性比较差,没有用 native 方式省心。


通过在 native 层给 ams 发送 binder 消息拉起进程,我们算是解决了「快速拉起进程」这个问题。但是这个还是不够。还是回到打地鼠这个游戏,假设你摁下一个地鼠,会冒起一个新的地鼠,那么你每次都能摁下去最后获取胜利的概率还是比较高的;


但如果你每次摁下一个地鼠,其他所有地鼠都能冒出来呢?这个难度系数可是要高多了。如果我们的进程能够在任意一个进程死亡之后,都能让把其他所有进程全部拉起,这样系统就很难杀死我们了。


新的黑科技保活中通过 2 个机制来保证进程之间的互相拉起:


2 个进程通过互相监听文件锁的方式,来感知彼此的死亡。通过 fork 产生子进程,fork 的进程同属一个进程组,一个被杀之后会触发另外一个进程被杀,从而被文件锁感知。


具体来说,创建 2 个进程 p1, p2,这两个进程通过文件锁互相关联,一个被杀之后拉起另外一个;同时 p1 经过 2 次 fork 产生孤儿进程 c1,p2 经过 2 次 fork 产生孤儿进程 c2,c1 和 c2 之间建立文件锁关联。这样假设 p1 被杀,那么 p2 会立马感知到,然后 p1 和 c1 同属一个进程组,p1 被杀会触发 c1 被杀,c1 死后 c2 立马感受到从而拉起 p1,因此这四个进程三三之间形成了铁三角,从而保证了存活率。


分析到这里,这种方案的大致原理我们已经清晰了。


基于以上原理,我写了一个简单的 PoC,代码在这里:https://github.com/tiann/Leoric


有兴趣的可以看一下。


为了文章的严谨性(注一位读者 Rikka 的回复):


文章中说需要“在 5ms 内启动一堆新的进程”,但其实并不需要。


AMS 在执行杀进程时是一个 ProcessRecord 一个地来的( https://a


《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


ndroid.googlesource.com/platform/frameworks/base/+/4f868ed/services/core/java/com/android/server/am/ActivityManagerService.java#5766),也就是最终会执行多次 libprocessgroup 里的 killProcessgroup。


这样只要在杀死属于某个 cgroup 的进程时,另外的进程只要成功启动一次 android:process 是另外的的进程即可活下来。因为新对应新的 ProcessRecord,不会在上面那个循环里被杀死。此外,循环四十次反而给了超长的时间来启动新的,观察 log 可以发现 killProcessgroup 的间隔长达几十到一百多 ms。

3 改进空间

本方案的原理还是比较简单直观的,但是要实现稳定的保活,还需要很多细节要补充;特别是那与死神赛跑的 5ms,需要不计一切代价去优化才能提升成功率。


具体来说,就是当前的实现是在 Java 层用 binder 调用的,我们应该在 native 层完成。笔者曾经实现过这个方案,但是这个库本质上是有损用户利益的,因此并不打算公开代码,这里简单提一下实现思路供大家学习:


如何在 native 层进行 binder 通信?


libbinder 是 NDK 公开库,拿到对应头文件,动态链接即可。


难点:依赖繁多,剥离头文件是个体力活。


如何组织 binder 通信的数据?


通信的数据其实就是二进制流;具体表现就是 (C++/Java) Parcel 对象。native 层没有对应的 Intent Parcel,兼容性差。


方案:


Java 层创建 Parcel (含 Intent),拿到 Parcel 对象的 mNativePtr(native peer),传到 Native 层。native 层直接把 mNativePtr 强转为结构体指针。fork 子进程,建立管道,准备传输 parcel 数据。子进程读管道,拿到二进制流,重组为 parcel。

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
Android-黑科技保活实现原理揭秘,kotlin开发微信