由一份 log 看 Binder

前言

前段时间调查一个死机重启问题，里面涉及到 Binder 调用的一些比较细节的地方，因此将 binder 调用的整个过程大致缕了一遍，并将所得整理下来。

问题 log

10-17 12:13:02.006  2096  5712 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
10-17 12:13:02.006  2096  5712 E JavaBinder: java.lang.RuntimeException: Could not copy bitmap to parcel blob.
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.graphics.Bitmap.nativeWriteToParcel(Native Method)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.graphics.Bitmap.writeToParcel(Bitmap.java:1553)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.widget.RemoteViews$BitmapCache.writeBitmapsToParcel(RemoteViews.java:984)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.widget.RemoteViews.writeToParcel(RemoteViews.java:2854)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.app.Notification.writeToParcel(Notification.java:1687)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.service.notification.StatusBarNotification.writeToParcel(StatusBarNotification.java:124)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.service.notification.IStatusBarNotificationHolder$Stub.onTransact(IStatusBarNotificationHolder.java:53)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.os.Binder.execTransact(Binder.java:453)
10-17 12:13:02.007  3362 15429 W Binder  : Caught a RuntimeException from the binder stub implementation.
10-17 12:13:02.007  3362 15429 W Binder  : java.lang.NullPointerException: Attempt to invoke virtual method 'android.app.Notification android.service.notification.StatusBarNotification.getNotification()' on a null object reference
10-17 12:13:02.007  3362 15429 W Binder  :  at android.service.notification.NotificationListenerService$INotificationListenerWrapper.onNotificationPosted(NotificationListenerService.java:692)
10-17 12:13:02.007  3362 15429 W Binder  :  at android.service.notification.INotificationListener$Stub.onTransact(INotificationListener.java:71)
10-17 12:13:02.007  3362 15429 W Binder  :  at android.os.Binder.execTransact(Binder.java:453)

下面我们来看一下这段 log 究竟是如何产生的。

一、这样的调用栈是如何产生的？

1. 三个进程

从未贴出的 log 可以看出，这段 log 是在 app 更新或者添加 notification 的过程中产生的，所以我们先看一下更新或添加 notification 的调用流程：

点击查看大图

• 不同的颜色代表不同的进程，红色运行在 app 进程，黑色在 system_server 进程，蓝色在 systemui （也可能是其他注册过的进程）进程
• 其中涉及到三次跨进程调用，依次为：app 进程调用 system_server 进程的 enqueueNotificationWithTag 方法、system_server 进程调用 systemui 进程的 onNotificationPosted 方法、systemui 进程调用 system_server 进程的 get 方法

第一次跨进程调用很常见，我们就不做讨论了，主要看一下第二、三次跨进程调用是如何实现的。首先，我们需要了解一下 NotificationListener 的注册流程（以 systemui 为例），如下图所示：

点击查看大图

• 其中红色部分运行在 systemui 进程，蓝色部分运行在 system_server 进程
• StatusBar 的成员 mNotificationListener 是一个 NotificationListenerService 实例，其会调用 registerAsSystemService 方法来进行注册
  

下面我们来看一下 registerAsSystemService 的实现：

1.1 NotificationListenerService.registerAsSystemService

NotificationListenerService.java

public void registerAsSystemService(Context context, ComponentName componentName,
        int currentUser) throws RemoteException {
    mSystemContext = context;
    if (mWrapper == null) {
        mWrapper = new INotificationListenerWrapper();
    }
    INotificationManager noMan = getNotificationInterface();
    noMan.registerListener(mWrapper, componentName, currentUser);
    mCurrentUser = currentUser;
}

• 通过 getNotificationInterface 方法得到 NMS (NotificationManagerService) 的代理，NMS 是在 ServiceManager 中注册过的
• 如果 mWrapper == null，那么创建一个 INotificationListenerWrapper 对象（INotificationListenerWrapper extends INotificationListener.Stub）赋给它
• 将 mWrapper 作为参数（其写入 parcel 时会调用 writeStrongBinder 方法，将其 IBinder 对象写入），调用 NMS 的 registerListener 方法，由此看来 mWrapper 提供了一个匿名 Binder 服务
  

（匿名 Binder 服务机制，本文不详细展开）
下面我们来看一下 registerService 的实现：

1.2 ManagedServices.registerService

ManagedServices.java

public void registerService(IInterface service, ComponentName component, int userid) {
    checkNotNull(service);
    ManagedServiceInfo info = registerServiceImpl(service, component, userid);
    if (info != null) {
        onServiceAdded(info);
    }
}

可以看到其分为两部分，我们主要看一下 registerServiceImpl 部分：
ManagedServices.java

private ManagedServiceInfo registerServiceImpl(final IInterface service,
        final ComponentName component, final int userid) {
    synchronized (mMutex) {
        try {
            // 这里的 service 实际上可以看作之前 mWrapper 的代理
            ManagedServiceInfo info = newServiceInfo(service, component, userid,
                    true /*isSystem*/, null, Build.VERSION_CODES.LOLLIPOP);
            service.asBinder().linkToDeath(info, 0);
            mServices.add(info);
            return info;
        } catch (RemoteException e) {
            // already dead
        }
    }
    return null;
}

• 将 service 以及 component 等数据包装成一个 ManagedServiceInfo 对象
• 将包装好的这个对象添加到 mServices 中

1.3 NotificationListeners.notifyPostedLocked

上面 1.2 中的 mServices 会在 notify notification 流程的 notifyPostedLocked 方法中用到：
NotificationManagerService.java

public void notifyPostedLocked(StatusBarNotification sbn, StatusBarNotification oldSbn) {
    ......
    for (final ManagedServiceInfo info : mServices) {
        ......
        mHandler.post(new Runnable() {
            @Override
            public void run() {
                notifyPosted(info, sbnToPost, update);
            }
        });
    }
}

从中可以看出此方法是从 mServices 中取出之前添加的 ManagedServiceInfo 对象，然后执行 notifyPosted(info, sbnToPost, update) 方法，看一下 notifyPosted 的实现：
NotificationManagerService.java

private void notifyPosted(final ManagedServiceInfo info,
        final StatusBarNotification sbn, NotificationRankingUpdate rankingUpdate) {
    final INotificationListener listener = (INotificationListener)info.service;
    StatusBarNotificationHolder sbnHolder = new StatusBarNotificationHolder(sbn);
    try {
        listener.onNotificationPosted(sbnHolder, rankingUpdate);
    } catch (RemoteException ex) {
        Log.e(TAG, "unable to notify listener (posted): " + listener, ex);
    }
}

info.service 就是包装之前的 service，因此 listener 即为之前 mWrapper 的代理，通过 listener.onNotificationPosted(sbnHolder, rankingUpdate) 也就实现了这次跨进程调用，由 system_server 进程进入了 systemui 进程。

1.4 StatusBarNotificationHolder

我们看一下 StatusBarNotificationHolder 这个类：
NotificationManagerService.java

    private static final class StatusBarNotificationHolder
            extends IStatusBarNotificationHolder.Stub {
        private StatusBarNotification mValue;

        public StatusBarNotificationHolder(StatusBarNotification value) {
            mValue = value;
        }

        @Override
        public StatusBarNotification get() {
            StatusBarNotification value = mValue;
            mValue = null;
            return value;
        }
    }

因此 notifyPosted 方法中传过去的 sbnHolder 其实与之前的 mWrapper 一致，都是为了提供一个匿名 Binder 服务，systemui 进程可以借助于其方法实现到 system_server 进程的调用。

2. Binder 调用流程

从第一段 log 我们可以看出，第一个 Exception 是在服务端执行 onTransact 中的 writeToParcel 的时候产生的，那我们思考这样几个问题：此处产生 RuntimeException 会被怎样处理？返回给 Client 端的结果会是怎样的？下一段 log 中的空指针是怎么来的？
我们看一下 IStatusBarNotificationHolder.aidl 编译出的 IStatusBarNotificationHolder.java 文件，IStatusBarNotificationHolder.aidl 中只定义了一个接口：

    StatusBarNotification get();

在 IStatusBarNotificationHolder.java 中看一下其对应的部分：

private static class Proxy implements android.service.notification.IStatusBarNotificationHolder {
    /** Fetch the held StatusBarNotification. This method should only be called once per Holder */
    @Override 
    public android.service.notification.StatusBarNotification get() throws android.os.RemoteException {
        android.os.Parcel _data = android.os.Parcel.obtain();
        android.os.Parcel _reply = android.os.Parcel.obtain();
        android.service.notification.StatusBarNotification _result;
        try {
            _data.writeInterfaceToken(DESCRIPTOR);
            mRemote.transact(Stub.TRANSACTION_get, _data, _reply, 0);
            _reply.readException();
            if ((0!=_reply.readInt())) {
                _result = android.service.notification.StatusBarNotification.CREATOR.createFromParcel(_reply);
            } else {
                _result = null;
            }
        } finally {
            _reply.recycle();
            _data.recycle();
        }
        return _result;
    }
}

由 mRemote.transact 开始的调用流程为：



最后产生 Exception 的地方是在 Server 端的 onTransact 方法中，因此，我们想知道这个 Exception 会被如何处理、以及最终返回给 Client 端的结果是什么，需要顺着 Binder 的调用流程逆推回去。

2.1 Binder.execTransact

Binder.java

    private boolean execTransact(int code, long dataObj, long replyObj,
            int flags) {
        Parcel data = Parcel.obtain(dataObj);
        Parcel reply = Parcel.obtain(replyObj);
        boolean res;
        try {
            res = onTransact(code, data, reply, flags);
        } catch (RemoteException e) {
        ...
        } catch (RuntimeException e) { // onTransact 中抛出的 RuntimeException 会被这里 catch 住
            if ((flags & FLAG_ONEWAY) != 0) { // 为 oneway 调用
                Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
            } else {
                reply.setDataPosition(0);
                reply.writeException(e);
            }
            res = true;
        } catch (OutOfMemoryError e) {
        ...
        }
        checkParcel(this, code, reply, "Unreasonably large binder reply buffer");
        reply.recycle();
        data.recycle();

        return res;
    }

由上面代码可知，onTransact 中抛出的 RuntimeException 会被 catch 住，并且 get() 方法不是 oneway 的，因此，接下来会依次执行：

                reply.setDataPosition(0);
                reply.writeException(e);

• reply.setDataPosition(0) 可以理解为将 parcel 中 mData 段上的 mDataPos 偏移置为 0

下面我们来看一下 writeException 方法
Parcel.java

    public final void writeException(Exception e) {
        int code = 0;
        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;
        }
        writeInt(code);
        StrictMode.clearGatheredViolations();
        if (code == 0) {
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            throw new RuntimeException(e);
        }
        writeString(e.getMessage());
    }

• e 不是上面判断中任何一个 Exception 的实例，所以 code 一直为 0
• 因为之前执行过 setDataPosition(0)，所以 writeInt(code) 会将 parcel 对象的 mData 上的第一个值置为 0，并将 mDataPos 增加 4（填充数据的 length），即指向下一个需要填充的数据的位置
• 上一步完成后，将 Exception e 抛出

2.2 JavaBBinder::onTransact

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);

        IPCThreadState* thread_state = IPCThreadState::self();
        const int32_t strict_policy_before = thread_state->getStrictModePolicy();
        // 调用 Binder.java 的 execTransact 方法
        jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
            code, reinterpret_cast<jlong>(&data), reinterpret_cast<jlong>(reply), flags);

        if (env->ExceptionCheck()) {
            jthrowable excep = env->ExceptionOccurred();
            report_exception(env, excep,
                "*** Uncaught remote exception!  "
                "(Exceptions are not yet supported across processes.)");
            res = JNI_FALSE;

            /* clean up JNI local ref -- we don't return to Java code */
            env->DeleteLocalRef(excep);
        }

        if (thread_state->getStrictModePolicy() != strict_policy_before) {
            set_dalvik_blockguard_policy(env, strict_policy_before);
        }

        if (env->ExceptionCheck()) {
            jthrowable excep = env->ExceptionOccurred();
            report_exception(env, excep,
                "*** Uncaught exception in onBinderStrictModePolicyChange");
            /* clean up JNI local ref -- we don't return to Java code */
            env->DeleteLocalRef(excep);

        if (code == SYSPROPS_TRANSACTION) {
            BBinder::onTransact(code, data, reply, flags);
        }
        // 这里 res == JNI_FALSE，所以 return UNKNOWN_TRANSACTION
        return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION;
    }

因为在 2.1 中的 writeException 时会 throw (RuntimeException) e; ，所以 env->ExceptionCheck() 为 true；因此会执行 report_exception，这就是下面这段 log 的由来：

10-17 12:13:02.006  2096  5712 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
10-17 12:13:02.006  2096  5712 E JavaBinder: java.lang.RuntimeException: Could not copy bitmap to parcel blob.
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.graphics.Bitmap.nativeWriteToParcel(Native Method)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.graphics.Bitmap.writeToParcel(Bitmap.java:1553)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.widget.RemoteViews$BitmapCache.writeBitmapsToParcel(RemoteViews.java:984)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.widget.RemoteViews.writeToParcel(RemoteViews.java:2854)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.app.Notification.writeToParcel(Notification.java:1687)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.service.notification.StatusBarNotification.writeToParcel(StatusBarNotification.java:124)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.service.notification.IStatusBarNotificationHolder$Stub.onTransact(IStatusBarNotificationHolder.java:53)
10-17 12:13:02.006  2096  5712 E JavaBinder:    at android.os.Binder.execTransact(Binder.java:453)

下面我们继续来看一下剩下的 log 是怎么来的

2.3 BBinder::transact

Binder.cpp

status_t BBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    data.setDataPosition(0);

    status_t err = NO_ERROR;
    switch (code) {
        case PING_TRANSACTION:
            reply->writeInt32(pingBinder());
            break;
        default:
            // err = UNKNOWN_TRANSACTION
            err = onTransact(code, data, reply, flags);
            break;
    }

    if (reply != NULL) {
        reply->setDataPosition(0);
    }

    return err;
}

由上面这段代码可知，此函数会返回 UNKNOWN_TRANSACTION，并且将 reply 对象的 mDataPos 再次置为 0

2.4 IPCThreadState::executeCommand 中的 case BR_TRANSACTION

IPCThreadState.cpp

case BR_TRANSACTION:
        {
            binder_transaction_data tr;
            result = mIn.read(&tr, sizeof(tr));
            if (result != NO_ERROR) break;

            Parcel buffer;
            buffer.ipcSetDataReference(
                reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
                tr.data_size,
                reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
                tr.offsets_size/sizeof(binder_size_t), freeBuffer, this);

            Parcel reply;
            status_t error;
            ...
            // 重点部分
            if (tr.target.ptr) {
                if (reinterpret_cast<RefBase::weakref_type*>(
                        tr.target.ptr)->attemptIncStrong(this)) {
                    // 此处调用 BBinder::transact，error = UNKNOWN_TRANSACTION
                    error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer,
                            &reply, tr.flags);
                    reinterpret_cast<BBinder*>(tr.cookie)->decStrong(this);
                } else {
                    error = UNKNOWN_TRANSACTION;
                }

            } else {
            ...
            }
            // 重点部分
            if ((tr.flags & TF_ONE_WAY) == 0) {// 不为 oneway 的情况
                LOG_ONEWAY("Sending reply to %d!", mCallingPid);
                if (error < NO_ERROR) {
                    alog << "error < NO_ERROR, reply = " << reply << endl;
                    reply.setError(error);
                }
                sendReply(reply, 0);
            } else {
                LOG_ONEWAY("NOT sending reply to %d!", mCallingPid);
            }
            ...
        }
        break;

由于 BBinder::transact 的返回值为 UNKNOWN_TRANSACTION，所以可知这里会依次调用：

• reply.setError(error); // error = UNKNOWN_TRANSACTION
• sendReply(reply, 0);

由于 IPCThreadState 的调用过程涉及到跨进程，比较复杂，所以这里详细讲解一下

2.5 IPCThreadState 的 transact 过程（非 TF_ONE_WAY）

下面看一下 IPCThreadState 是如何跨进程调用到对端的：

• talkWithDriver 时，会将 parcel 对象 mOut 的数据写入内核空间，并将读到的数据放入 parcel 对象 mIn 中
• 由用户空间传入 Binder Driver 的 cmd 是以 BC 开头的，经过 Binder Driver 的处理会转化为相应的 BR 开头的 cmd 传给对端（例如 BC_TRANSACTION -> BR_TRANSACTION）

结合我们调查的这个问题，将 IPCThreadState 跨进程调用的具体过程用图示表示出来：

点击查看大图
从图中我们可以看出：

• Server 端 waitForResponse 时，收到 Binder Driver 的 BR_TRANSACTION 指令，于是调用 executeCommand(cmd)，并进入 switch 语句的 case BR_TRANSACTION: 情况
• 执行 error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer, &reply, tr.flags); 并沿着 2 中给出的调用流程一直执行到 Server 端的业务实现，我们这里的返回值 error 为 UNKNOWN_TRANSACTION
• 当 error < NO_ERROR 时，会先 reply.setError(error); 然后再 sendReply(reply, 0);
• sendReply 时会先调用 writeTransactionData(BC_REPLY, ...) 将 cmd BC_REPLY 以及 parcel reply 写入输出 parcel mOut 中，然后再调用 waitForResponse(NULL, NULL); 收到 BR_TRANSACTION_COMPLETE 退出
• writeTransactionData(BC_REPLY, …) 时，因为 reply 中的 mError 为 UNKNOWN_TRANSACTION，所以会给传输数据 tr 添加 flag TF_STATUS_CODE，并且在 tr 的 data 数据中保存错误信息 UNKNOWN_TRANSACTION
• BC_REPLY 通过 Binder Driver 会被转化为 BR_REPLY，Client 端在 talkWithDriver() 接收到 BR_REPLY 后会进入 case BR_REPLY: 情况，可以看到因为传过来的数据 tr 带有 flag TF_STATUS_CODE，因此会执行 err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer); 获取 status code，即 err = UNKNOWN_TRANSACTION，而后执行 freeBuffer 后直接 goto finish;
• 在 finish: 中会执行 reply->setError(err); 而后 return err; 结束
• 可以看到，在我们这种情况下 Server 端传回来的数据中只有一个 status code（UNKNOWN_TRANSACTION），Client 端做的也只是提取出 status code 赋值给 reply 对象的 mError 成员，值得注意的是 Client 端的 reply 对象在此之前没有其他额外操作，也就是 reply 对象现在的 mDataSize 仍旧为 0

到此，IPCThreadState 非 oneway 情况下的 transact 过程就讲解完了，剩下的流程比较简单，沿着 2 中给出的流程图推导过去即可，这里不再详细说明；下面来具体看一下 null 是怎么来的。

2.6 null 的由来

我们继续看一下 2 中 get() 方法的代码，在 mRemote.transact(Stub.TRANSACTION_get, _data, _reply, 0); 返回后，会依次执行以下几步：

_reply.readException();
if ((0!=_reply.readInt())) {
    _result = android.service.notification.StatusBarNotification.CREATOR.createFromParcel(_reply);
}
else {
    _result = null;
}
return _result;

我们来看一下 readException() 的实现：
Parcel.java

    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) {
        ...
        }
        return code;
    }

也就是说最终还是要看 readInt() 方法，其会执行到 Parcel.cpp 的 Parcel::readAligned() 方法：
Parcel.cpp

template<class T>
T Parcel::readAligned() const {
    T result;
    if (readAligned(&result) != NO_ERROR) {
        result = 0;
    }

    return result;
}

template<class T>
status_t Parcel::readAligned(T *pArg) const {
    COMPILE_TIME_ASSERT_FUNCTION_SCOPE(PAD_SIZE_UNSAFE(sizeof(T)) == sizeof(T));

    if ((mDataPos+sizeof(T)) <= mDataSize) {
        const void* data = mData+mDataPos;
        mDataPos += sizeof(T);
        *pArg =  *reinterpret_cast<const T*>(data);
        return NO_ERROR;
    } else {
        return NOT_ENOUGH_DATA;
    }
}

2.5 中提到，reply 中的 mDataSize 为 0，所以 mDataPos+sizeof(T) 必定大于 mDataSize，因此 Parcel::readAligned(T *pArg) 返回 NOT_ENOUGH_DATA；所以 Parcel::readAligned() 最终会返回 0，由此可知：

• 这种情况下无论执行多少次 readInt() 最终得到的结果都为 0
• 需要注意的是， Parcel::readAligned(T *pArg) 时，如果 (mDataPos+sizeof(T)) <= mDataSize，那么每执行一次 Parcel::readAligned(T *pArg)，mDataPos 的值都会改变，因此 Java 层多次调用 readInt() 得到的值可以不相同，其他 read*() 函数同理；

因为 _reply.readInt() 的值为 0，因此最终会返回 null，null 的由来我们知道了，那么第二段 log 是在什么位置打印的呢？下面我们来具体看一下这个问题。

2.7 第二段 log 的打印

由 1 可知，NPE 是在 INotificationListenerWrapper 的 onNotificationPosted 中抛出的；换个角度，此时是 systemui 作为 system_server 的 Server 端，因此这个 NPE 会被 2.1 中的 execTransact 函数 catch 住；而此调用为 oneway 调用，因此如下：

        catch (RuntimeException e) {
            if ((flags & FLAG_ONEWAY) != 0) { // 执行这里
                Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
            } else {
                reply.setDataPosition(0);
                reply.writeException(e);
            }
            res = true;
        }

直接会将 NPE 信息输出，即第二段 log。