每日一问 | Service onStartCommand 返回STICKY是如何做到被拉活的？

最近一直关注合规问题，其中有一次被检测到风险是：

在Google的pixel设备中，某个进程被杀死后，然后又自动被「拉活」了，排查发现可能是各种注册的Service因为其onStartCommand返回START_STICKY导致。

那么问题来了：

• 1.当Service onStartCommand返回START_STICKY后，进程被杀系统是如何「复活」所在进程的？
• 2.面对项目中一堆Service可能返回START_STICKY，如何可以在原生系统上避免被「拉活」？

如果图片挂了看不到，请查看在线PDF文件：https://gitee.com/pgm250/blog_img_bed/raw/master/wanan/Service%20onStartCommand%20%E8%BF%94%E5%9B%9ESTICKY%E6%98%AF%E5%A6%82%E4%BD%95%E5%81%9A%E5%88%B0%E8%A2%AB%E6%8B%89%E6%B4%BB%E7%9A%84%EF%BC%9F.pdf

1.关于进程被杀系统是如何「复活」所在进程的？

1.1 如何监听进程被系统杀死

Binder机制中有 死亡讣告 的事件通知机制,当进程销毁时，其对应的 本地Binder 会通过 AppDeathRecipient 通知 代理Binder进程 销毁了。

所以当Service所在的App进程被系统杀死后，就会将这个事件通过 Binder死亡讣告 通知ActivityManagerService（管理四大组件，自然包括Service组件）。既然要知道Service如何被“复活”，那么肯定要先知道它是如何“出生”，下面是start Service的大概流程图：

由上图中我们关注一下Service进程被Zygote fork创建后执行ActivityTh.attach()方法，通过Binder调用ActivityManagerProxy.attchApplication()方法想ActivityManagerService绑定初始化当前新建的Service进程。

// frameworks/base/core/java/android/app/ActivityThread.java
public final class ActivityThread {
        ...
        final ApplicationThread mAppThread = new ApplicationThread();

        private void attach(boolean system) {
            ...
            // 获取AMS代理Binder
            final IActivityManager mgr = ActivityManagerNative.getDefault();
            try {
                // 将应用程序的本地binder对象ApplicationThread通过Binder调用传给AMS
                mgr.attachApplication(mAppThread);
            }
            ...
        }
    }
    private class ApplicationThread extends ApplicationThreadNative {...} // 继承BinderNative本地Binder对象
}

// frameworks/base/core/java/android/app/ApplicationThreadNative.java
public abstract class ApplicationThreadNative extends Binder implements IApplicationThread {...}// BinderNative对象

class ApplicationThreadProxy implements IApplicationThread {// BinderProxy对象
    private final IBinder mRemote;// 远端Binder引用
}

// frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public final class ActivityManagerService extends ActivityManagerNative ... {
    ...

    @Override
    public final void attachApplication(IApplicationThread thread) {
        synchronized (this) {
            int callingPid = Binder.getCallingPid();
            final long origId = Binder.clearCallingIdentity();
            attachApplicationLocked(thread, callingPid);
            Binder.restoreCallingIdentity(origId);
        }
    }

    private final boolean attachApplicationLocked(IApplicationThread thread,int pid) {
        ProcessRecord app;
        ...
        try {
            // 创建AppDeathRecipient监听者
            AppDeathRecipient adr = new AppDeathRecipient(app, pid, thread);
            // 建立binder死亡回调
            thread.asBinder().linkToDeath(adr, 0);
            // 赋值到进程信息类ProcessRecord
            app.deathRecipient = adr;
        } catch (RemoteException e) {
           ...
        }
    }

    private final class AppDeathRecipient implements IBinder.DeathRecipient {
        final ProcessRecord mApp; // 进程信息类
        final int mPid; // 进程号
        final IApplicationThread mAppThread; // app进程代理Binder对象
        ...
        @Override
        public void binderDied() {
            synchronized(ActivityManagerService.this) {
                // 处理进程销毁后的清理工作
                appDiedLocked(mApp, mPid, mAppThread, true);
            }
        }
    }
}

1.2 AMS知道杀死带START_STICKY标记的Service进程后，如何「复活」

在ActivityManagerService启动完成后，向Service反馈，然后Service处理完成后有汇报给ActivityManagerService，然后交给ActiveService处理，将标识START_STICKY的Service对应信息封装类ServiceRecord的stopIfKilled设为false，表示杀死之后重启。

// frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
public final class ActiveServices {
    void serviceDoneExecutingLocked(ServiceRecord r, int type, int startId, int res) {
        ...
        if (r != null) {
            if (type == ActivityThread.SERVICE_DONE_EXECUTING_START) {
                r.callStart = true;
                switch (res) {
                    case Service.START_STICKY_COMPATIBILITY:
                    case Service.START_STICKY: {
                        // 将ServiceRecord的stopIfKilled设为false，表示杀死之后重启
                        // Don't stop if killed.
                        r.stopIfKilled = false;
                        break;
                    }
                    case Service.START_NOT_STICKY: {
                        r.findDeliveredStart(startId, true);
                        if (r.getLastStartId() == startId) {
                            // 将ServiceRecord的stopIfKilled设为false，表示杀死之后不需要重启
                            // There is no more work, and this service
                            // doesn't want to hang around if killed.
                            r.stopIfKilled = true;
                        }
                        break;
                    }
                    ...
                }
                ...
            }
            ...
    }
}

承接上一小节的appDiedLocked()方法，主要是清理应用进程逻辑，对于发现符合重启条件的Service，将ServiceRestarter（实现Runnable）的任务post到ActivityManagerService的Handler执行恢复Service逻辑。

// frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public final class ActivityManagerService extends ActivityManagerNative ... {
    ...
    final ActiveServices mServices; // Service管理类

    final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread,boolean fromBinderDied) {
        ...
        handleAppDiedLocked(app, false, true);
        ...
    }

    private final void handleAppDiedLocked(ProcessRecord app,boolean restarting, boolean allowRestart) {
        ...
        // 清理应用进程数据
        boolean kept = cleanUpApplicationRecordLocked(app, restarting, allowRestart, -1,false /*replacingPid*/);
        ..
    }

    private final boolean cleanUpApplicationRecordLocked(ProcessRecord app,boolean restarting, boolean allowRestart, int index, boolean replacingPid) {
       ...
       // 杀死Service
       mServices.killServicesLocked(app, allowRestart);
       ...
    }
}

// frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
public final class ActiveServices {
    ...
    // 重启Service的ServiceRecord列表
    final ArrayList<ServiceRecord> mRestartingServices = new ArrayList<>();

    final void killServicesLocked(ProcessRecord app, boolean allowRestart) {
        ...
        for (int i=app.services.size()-1; i>=0; i--) {
            ServiceRecord sr = app.services.valueAt(i);
            ...
             // 超过两次的要避免再次重启Service，但是进程还是会被唤醒 如果是ApplicationInfo.FLAG_PERSISTENT表示系统应用则无视，仍旧重启
            if (allowRestart && sr.crashCount >= 2 && (sr.serviceInfo.applicationInfo.flags
            &ApplicationInfo.FLAG_PERSISTENT) == 0) {
                ...
                // 结束Service
                bringDownServiceLocked(sr);
            } else if (!allowRestart || !mAm.isUserRunningLocked(sr.userId, false)) { // 不允许重启的
             // 结束Service
                bringDownServiceLocked(sr);
            } else { // 允许重启的
                // START_STICKY标识的Service返回值canceled为false
                boolean canceled = scheduleServiceRestartLocked(sr, true);

                 // START_STICKY标识的Service的ServiceRecord的stopIfKilled为false，
                 // 在前面serviceDoneExecutingLocked()方法看得到，故不用结束Service
                if (sr.startRequested && (sr.stopIfKilled || canceled)) {
                        ...
                        // 结束Service
                        bringDownServiceLocked(sr);
                        ...
                    }
                }
            }
        }
        ...
    }

    private final boolean scheduleServiceRestartLocked(ServiceRecord r,boolean allowCancel) {
        boolean canceled = false;
        ...
        if (!mRestartingServices.contains(r)) {
            ...
            // 将重启Service的ServiceRecord添加进mRestartingServices
            mRestartingServices.add(r);
            ...
        }
        ...
        // 往ActivityManagerService的Handler里面移除过时的ServiceRestarter，并将更新的ServiceRestarter添加定时执行
        mAm.mHandler.removeCallbacks(r.restarter);
        mAm.mHandler.postAtTime(r.restarter, r.nextRestartTime);
        ...
        return canceled;
    }

    private class ServiceRestarter implements Runnable {// 实现Runnable，被添加到Handler执行
        private ServiceRecord mService; // Service信息封装类

        void setService(ServiceRecord service) {
            mService = service;
        }

        public void run() {
            synchronized(mAm) {
                // 执行重启Service逻辑
                performServiceRestartLocked(mService);
            }
        }
    }

    final void performServiceRestartLocked(ServiceRecord r) {
        if (!mRestartingServices.contains(r)) {
            return;
        }
        ...
        try {
            // 拉起进程并重启Service
            bringUpServiceLocked(r, r.intent.getIntent().getFlags(), r.createdFromFg, true);
        }
        ...
    }

    private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
            boolean whileRestarting) throws TransactionTooLargeException {
        ...
        //  移除重启Service列表的ServiceRecord
        if (mRestartingServices.remove(r)) {
            r.resetRestartCounter();
            clearRestartingIfNeededLocked(r);
        }
        ...
        if (!isolated) {
            ...
            if (app != null && app.thread != null) {
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                    // 启动Service
                    realStartServiceLocked(r, app, execInFg);
                    return null;
                } 
                ...
            }
        }
    }
}

2.面对项目中一堆Service可能返回START_STICKY，如何可以在原生系统上避免被「拉活」？

一般来说Service拉活，无论是官方方法还是黑科技在国产ROM一般不管用，当然洋叔是在Pixel机子上原生系统遇到这问题，只能从项目的方面入手，而不是FrameWork。毫无疑问解决方法非常有限：Hook收敛 。依据业务建立黑白名单管理，根据需求Hook掉Service的onStartCommand(),将其返回值设为START_NOT_STICKY即能解决拉活问题。Hook方案很多，根据项目实际任君选择：