Android Binder异常传递流程分析

从一个异常日志开始

作为Android程序员，经常会遇到如下的异常日志:

AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.qiku.activitylifecycletest/com.qiku.activitylifecycletest.MainActivity}: java.lang.SecurityException: Permission Denial: killBackgroundProcesses() from pid=4752, uid=10125 requires android.permission.KILL_BACKGROUND_PROCESSES
AndroidRuntime:     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2808)   
AndroidRuntime:     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2886)    
AndroidRuntime:     at android.app.ActivityThread.-wrap11(Unknown Source:0)                         
AndroidRuntime:     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1603)         
AndroidRuntime:     at android.os.Handler.dispatchMessage(Handler.java:106)                         
AndroidRuntime:     at android.os.Looper.loop(Looper.java:164)                                      
AndroidRuntime:     at android.app.ActivityThread.main(ActivityThread.java:6538)                    
AndroidRuntime:     at java.lang.reflect.Method.invoke(Native Method)                               
AndroidRuntime:     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:453)
AndroidRuntime:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:833)                 
AndroidRuntime: Caused by: java.lang.SecurityException: Permission Denial: killBackgroundProcesses() from pid=4752, uid=10125 requires android.permission.KILL_BACKGROUND_PROCESSES
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:2004)                            
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:1950)                            
AndroidRuntime:     at android.app.IActivityManager$Stub$Proxy.killBackgroundProcesses(IActivityManager.java:6426)
AndroidRuntime:     at android.app.ActivityManager.killBackgroundProcesses(ActivityManager.java:3739)
AndroidRuntime:     at com.qiku.activitylifecycletest.MainActivity.onCreate(MainActivity.java:36)   
AndroidRuntime:     at android.app.Activity.performCreate(Activity.java:7000)                       
AndroidRuntime:     at android.app.Activity.performCreate(Activity.java:6991)                       
AndroidRuntime:     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1215)  
AndroidRuntime:     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2761)

导致该异常的代码如下：

    ActivityManager am = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
    am.killBackgroundProcesses("com.tencent.mm");

该异常会导致app crash。关键信息如下

Caused by: java.lang.SecurityException: Permission Denial:killBackgroundProcesses() from pid=4752, uid=10125 requires android.permission.KILL_BACKGROUND_PROCESSES

意思就是当前进程调用ActivityManager的killBackgroundProcesses，而没有android.permission.KILL_BACKGROUND_PROCESSES这个权限，所以导致crash。

到底在哪里抛出的异常

我们想找到这个抛异常的地方，然后就在aosp的源码中寻找。因为调用的是ActivityManager的方法，所以，凭借经验，我们应该知道，调用killBackgroundProcesses这个方法，会通过binder调到ActivityManagerService中，并且只有系统服务才能鉴定app是否有权限。所以，在ActivityManagerService的killBackgroundProcesses方法中，找到了抛异常的地方。

@Override
    public void killBackgroundProcesses(final String packageName, int userId) {
        if (checkCallingPermission(android.Manifest.permission.KILL_BACKGROUND_PROCESSES)
                != PackageManager.PERMISSION_GRANTED &&
                checkCallingPermission(android.Manifest.permission.RESTART_PACKAGES)
                        != PackageManager.PERMISSION_GRANTED) {
            String msg = "Permission Denial: killBackgroundProcesses() from pid="
                    + Binder.getCallingPid()
                    + ", uid=" + Binder.getCallingUid()
                    + " requires " + android.Manifest.permission.KILL_BACKGROUND_PROCESSES;
            Slog.w(TAG, msg);
            throw new SecurityException(msg);
        }

        userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
                userId, true, ALLOW_FULL_ONLY, "killBackgroundProcesses", null);

那么问题来了:

抛异常的位置位于ActivityManagerService中，是运行在system_server进程中的，
为什么system_server进程没有崩溃，反而导致app进程崩溃呢？

App中调用栈分析

我们再仔细分析一下app崩溃时的调用栈。

AndroidRuntime: Caused by: java.lang.SecurityException: Permission Denial: killBackgroundProcesses() from pid=4752, uid=10125 requires android.permission.KILL_BACKGROUND_PROCESSES
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:2004)                            
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:1950)                            
AndroidRuntime:     at android.app.IActivityManager$Stub$Proxy.killBackgroundProcesses(IActivityManager.java:6426)
AndroidRuntime:     at android.app.ActivityManager.killBackgroundProcesses(ActivityManager.java:3739)
AndroidRuntime:     at com.qiku.activitylifecycletest.MainActivity.onCreate(MainActivity.java:36) 

可以看到在Activity的onCreate中，调用了ActivityManager.killBackgroundProcesses
ActivityManager.killBackgroundProcesses又调用了```killBackgroundProcesses`

根据Android中实现java层的binder调用的套路，IActivityManager是一个aidl文件，该文件经过aidl处理，生成IAcitivityManager.java文件，IAcitivityManager.java文件中存在一个IActivityManager接口，定义了app可以调用ams的方法，IActivityManager中有一个抽象类Stub，该Stub类实现IActivityManager接口，并继承Binder:

public interface IActivityManager extends android.os.IInterface {
    /**
     * Local-side IPC implementation stub class.
     */
    public static abstract class Stub extends android.os.Binder implements android.app.IActivityManager {
        private static final java.lang.String DESCRIPTOR = "android.app.IActivityManager";

并且Stub中又有一个叫做Proxy的内部类，该Proxy实现IActivityManager

       private static class Proxy implements android.app.IActivityManager {
            private android.os.IBinder mRemote;

Proxy用于app端使用，当app端调ActivityManager的方法的时候，就会调到IActivityManager$Stub$Proxy

我们看一下IActivityManager$Stub$Proxy的killBackgroundProcesses方法:

            public void killBackgroundProcesses(java.lang.String packageName, int userId) throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    _data.writeString(packageName);
                    _data.writeInt(userId);
                    mRemote.transact(Stub.TRANSACTION_killBackgroundProcesses, _data, _reply, 0);
                    _reply.readException();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
            }

mRemote是一个IBinder对象，专门用来调用远程进程的。这个方法中把所有的参数收集到一个名为_data的Parcel对象中，并且创建一个叫_reply的空Parcel对象，然后调用mRemote.transact进行binder调用。调用完这个方法后，app中的当前线程就暂停了，然后ActivityManagerService开始执行，等ActivityManagerService执行完之后，app中的当前线程继续执行，这时候_reply里面存放的就是ActivityManagerService的执行结果。

mRemote.transact之后，继续调用_reply.readException，app就是从这里崩溃的:

AndroidRuntime: Caused by: java.lang.SecurityException: Permission Denial: killBackgroundProcesses() from pid=4752, uid=10125 requires android.permission.KILL_BACKGROUND_PROCESSES
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:2004)                            
AndroidRuntime:     at android.os.Parcel.readException(Parcel.java:1950)   

我们看一下Parcel的readException实现：

    public final void readException() {
        int code = readExceptionCode();
        if (code != 0) {
            String msg = readString();
            readException(code, msg);
        }
    }
    public final int readExceptionCode() {
        int code = readInt();
        if (code == EX_HAS_REPLY_HEADER) {
            int headerSize = readInt();
            if (headerSize == 0) {
                Log.e(TAG, "Unexpected zero-sized Parcel reply header.");
            } else {
                // Currently the only thing in the header is StrictMode stacks,
                // but discussions around event/RPC tracing suggest we might
                // put that here too.  If so, switch on sub-header tags here.
                // But for now, just parse out the StrictMode stuff.
                StrictMode.readAndHandleBinderCallViolations(this);
            }
            // And fat response headers are currently only used when
            // there are no exceptions, so return no error:
            return 0;
        }
        return code;
    }

public final void readException(int code, String msg) {
        switch (code) {
            case EX_PARCELABLE:
                if (readInt() > 0) {
                    SneakyThrow.sneakyThrow(
                            (Exception) readParcelable(Parcelable.class.getClassLoader()));
                } else {
                    throw new RuntimeException(msg + " [missing Parcelable]");
                }
            case EX_SECURITY:
                throw new SecurityException(msg);
            case EX_BAD_PARCELABLE:
                throw new BadParcelableException(msg);
            case EX_ILLEGAL_ARGUMENT:
                throw new IllegalArgumentException(msg);
            case EX_NULL_POINTER:
                throw new NullPointerException(msg);
            case EX_ILLEGAL_STATE:
                throw new IllegalStateException(msg);
            case EX_NETWORK_MAIN_THREAD:
                throw new NetworkOnMainThreadException();
            case EX_UNSUPPORTED_OPERATION:
                throw new UnsupportedOperationException(msg);
            case EX_SERVICE_SPECIFIC:
                throw new ServiceSpecificException(readInt(), msg);
        }
        throw new RuntimeException("Unknown exception code: " + code
                + " msg " + msg);
    }

可以看到，其实是从Parcel中读了一个code，读了一个msg字符串，然后根据code和msg抛出了对应的异常。

所以我们可以认为，ActivityManagerService在抛出异常后，把异常的信息(code和msg)放到了Parcel对象中，传递到了app进程中，app进程读到ActivityManagerService中传过来的异常信息后，又构建了对应的Exception对象，然后throw这个Exception对象，导致app进程崩溃。

所以总结一下，异常是可以通过binder来传递的，只是不是直接传递，而是传递异常类型(code)和异常相关的描述信息(msg)。binder调用端会解析这些信息创建和抛出异常。

ActivityManagerService中异常处理分析

下面我们看一下ActivityManagerService端是怎样传递这个异常的。我们需要了解一些java服务端Binder的执行流程。

binder是Android中的进程间通信方式，它是有内核中的binder驱动支持的。客户端调用binder，会从java层一直通过jni调用到native层，然后调到kernel层。kernel层的binder驱动在接到binder请求后，会确定要把这个请求分派给哪个进程的哪个线程去执行。这个流程会从kernel层调到native层，然后native层通过jni反调到java层。具体过程这里不深究，感兴趣的请自己读下源码。

我们直接给出服务端native通过jni调java层的代码，这里是ActivityManagerService在java层执行的起点，该代码实现在frameworks/base/core/jni/android_util_Binder.cpp中：

   virtual status_t onTransact(
        uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0)
    {
        JNIEnv* env = javavm_to_jnienv(mVM);

        ALOGV("onTransact() on %p calling object %p in env %p vm %p\n", this, mObject, env, mVM);

        IPCThreadState* thread_state = IPCThreadState::self();
        const int32_t strict_policy_before = thread_state->getStrictModePolicy();

        //printf("Transact from %p to Java code sending: ", this);
        //data.print();
        //printf("\n");
        jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
            code, reinterpret_cast<jlong>(&data), reinterpret_cast<jlong>(reply), flags);

首先看gBinderOffsets

const char* const kBinderPathName = "android/os/Binder";

static int int_register_android_os_Binder(JNIEnv* env)
{
    jclass clazz = FindClassOrDie(env, kBinderPathName);

    gBinderOffsets.mClass = MakeGlobalRefOrDie(env, clazz);
    gBinderOffsets.mExecTransact = GetMethodIDOrDie(env, clazz, "execTransact", "(IJJI)Z");
    gBinderOffsets.mObject = GetFieldIDOrDie(env, clazz, "mObject", "J");

    return RegisterMethodsOrDie(
        env, kBinderPathName,
        gBinderMethods, NELEM(gBinderMethods));
}

这里gBinderOffsets.mClass表示的是java层的android.os.Binder类。
gBinderOffsets.mExecTransact表示的是android.os.Binder的execTransact方法
gBinderOffsets.mObject表示的是当前的Binder服务对象。在这个例子中，就是ActivityManagerService实例，
因为ActivityManagerService继承自IActivityManager.Stub

public class ActivityManagerService extends IActivityManager.Stub
        implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {

而IActivityManager.Stub又继承自android.os.Binder。所以这里mObject就是ActivityManagerService的实例。

所以

       jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
            code, reinterpret_cast<jlong>(&data), reinterpret_cast<jlong>(reply), flags);

里面的CallBooleanMethod就是通过jni调用java层的ActivityManagerService的execTransact方法。

因为ActivityManagerService中没有定义这个方法，所以会调到父类android.os.Binder的execTransact方法：

// Entry point from android_util_Binder.cpp's onTransact
    private boolean execTransact(int code, long dataObj, long replyObj,
            int flags) {
        Parcel data = Parcel.obtain(dataObj);
        Parcel reply = Parcel.obtain(replyObj);
        // theoretically, we should call transact, which will call onTransact,
        // but all that does is rewind it, and we just got these from an IPC,
        // so we'll just call it directly.
        boolean res;
        // Log any exceptions as warnings, don't silently suppress them.
        // If the call was FLAG_ONEWAY then these exceptions disappear into the ether.
        final boolean tracingEnabled = Binder.isTracingEnabled();
        try {
            if (tracingEnabled) {
                Trace.traceBegin(Trace.TRACE_TAG_ALWAYS, getClass().getName() + ":" + code);
            }
            res = onTransact(code, data, reply, flags);
        } catch (RemoteException|RuntimeException e) {
            if (LOG_RUNTIME_EXCEPTION) {
                Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
            }
            if ((flags & FLAG_ONEWAY) != 0) {
                if (e instanceof RemoteException) {
                    Log.w(TAG, "Binder call failed.", e);
                } else {
                    Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
                }
            } else {
                reply.setDataPosition(0);
                reply.writeException(e);
            }
            res = true;
        } finally {
            if (tracingEnabled) {
                Trace.traceEnd(Trace.TRACE_TAG_ALWAYS);
            }
        }
        checkParcel(this, code, reply, "Unreasonably large binder reply buffer");
        reply.recycle();
        data.recycle();

        // Just in case -- we are done with the IPC, so there should be no more strict
        // mode violations that have gathered for this thread.  Either they have been
        // parceled and are now in transport off to the caller, or we are returning back
        // to the main transaction loop to wait for another incoming transaction.  Either
        // way, strict mode begone!
        StrictMode.clearGatheredViolations();

        return res;
    }

该方法中的data，就是app在调binder的时候传来的参数，reply就是要返回给app的数据。

首先调用的是onTransact方法，onTransact方法会调到子类IActivityManager.Stub中：

     @Override
        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
            switch (code) {
                case INTERFACE_TRANSACTION: {
                    reply.writeString(DESCRIPTOR);
                    return true;
                }
                case TRANSACTION_openContentUri: {
                    data.enforceInterface(DESCRIPTOR);
                    java.lang.String _arg0;
                ......
                ......

该方法会通过传入的code，定位到killBackgroundProcesses方法:

                case TRANSACTION_killBackgroundProcesses: {
                    data.enforceInterface(DESCRIPTOR);
                    java.lang.String _arg0;
                    _arg0 = data.readString();
                    int _arg1;
                    _arg1 = data.readInt();
                    this.killBackgroundProcesses(_arg0, _arg1);
                    reply.writeNoException();
                    return true;
                }

这里的this是ActivityManagerService对象，所以会调用到ActivityManagerService的killBackgroundProcesses方法。

该方法就是抛出异常的地方：

    @Override
    public void killBackgroundProcesses(final String packageName, int userId) {
        if (checkCallingPermission(android.Manifest.permission.KILL_BACKGROUND_PROCESSES)
                != PackageManager.PERMISSION_GRANTED &&
                checkCallingPermission(android.Manifest.permission.RESTART_PACKAGES)
                        != PackageManager.PERMISSION_GRANTED) {
            String msg = "Permission Denial: killBackgroundProcesses() from pid="
                    + Binder.getCallingPid()
                    + ", uid=" + Binder.getCallingUid()
                    + " requires " + android.Manifest.permission.KILL_BACKGROUND_PROCESSES;
            Slog.w(TAG, msg);
            throw new SecurityException(msg);
        }

        userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
                userId, true, ALLOW_FULL_ONLY, "killBackgroundProcesses", null);
        long callingId = Binder.clearCallingIdentity();

那么这个异常是怎样处理的呢？我们会到android.os.Binder的execTransact方法，可以看到，它在调onTransact的时候，使用了try-catch:

try {
            if (tracingEnabled) {
                Trace.traceBegin(Trace.TRACE_TAG_ALWAYS, getClass().getName() + ":" + code);
            }
            res = onTransact(code, data, reply, flags);
        } catch (RemoteException|RuntimeException e) {
            if (LOG_RUNTIME_EXCEPTION) {
                Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
            }
            if ((flags & FLAG_ONEWAY) != 0) {
                if (e instanceof RemoteException) {
                    Log.w(TAG, "Binder call failed.", e);
                } else {
                    Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
                }
            } else {
                reply.setDataPosition(0);
                reply.writeException(e);
            }
            res = true;
        } finally {

在ActivityManagerService的killBackgroundProcesses方法中抛出的SecurityException，正好被这里的catch捕获，所以并不会导致ActivityManagerService崩溃，然后又把这个异常通过reply.writeException写入到reply中:

public final void writeException(Exception e) {
        int code = 0;
        if (e instanceof Parcelable
                && (e.getClass().getClassLoader() == Parcelable.class.getClassLoader())) {
            // We only send Parcelable exceptions that are in the
            // BootClassLoader to ensure that the receiver can unpack them
            code = EX_PARCELABLE;
        } else if (e instanceof SecurityException) {
            code = EX_SECURITY;
        } else if (e instanceof BadParcelableException) {
            code = EX_BAD_PARCELABLE;
        } else if (e instanceof IllegalArgumentException) {
            code = EX_ILLEGAL_ARGUMENT;
        } else if (e instanceof NullPointerException) {
            code = EX_NULL_POINTER;
        } else if (e instanceof IllegalStateException) {
            code = EX_ILLEGAL_STATE;
        } else if (e instanceof NetworkOnMainThreadException) {
            code = EX_NETWORK_MAIN_THREAD;
        } else if (e instanceof UnsupportedOperationException) {
            code = EX_UNSUPPORTED_OPERATION;
        } else if (e instanceof ServiceSpecificException) {
            code = EX_SERVICE_SPECIFIC;
        }
        writeInt(code);
        StrictMode.clearGatheredViolations();
        if (code == 0) {
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            throw new RuntimeException(e);
        }
        writeString(e.getMessage());
        switch (code) {
            case EX_SERVICE_SPECIFIC:
                writeInt(((ServiceSpecificException) e).errorCode);
                break;
            case EX_PARCELABLE:
                // Write parceled exception prefixed by length
                final int sizePosition = dataPosition();
                writeInt(0);
                writeParcelable((Parcelable) e, Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
                final int payloadPosition = dataPosition();
                setDataPosition(sizePosition);
                writeInt(payloadPosition - sizePosition);
                setDataPosition(payloadPosition);
                break;
        }
    }

可以看到，往reply中写异常的时候，写入的是一个code和异常的msg字符串。
这个reply会通过binder返回给app端，所以导致了app端崩溃。

总结

1 Android中Java层的Binder机制，是支持传递异常的。从Parcel中有readException和writeException方法，就可以看出来。
2 传递异常的方式是将异常的code和msg放到Parcel中进行传递
3 调用端会检查返回的Parcel中有没有异常code和msg，如果有的话，就读出这些信息，创建并抛出异常
4 虽然本文分析Binder传递异常的流程，但还是会涉及到很多关于Binder的其他知识，这些知识点没有深入分析，感兴趣的同学自行分析源码。