使用匿名binder实现client向server端的死亡通知

一、引言
因为binder是跨进程通信，难免会遇到服务端出现异常挂死的情况，这个时候需要通知到客户端进行相应的处理，在网络通信中是非常常见的机制，当然，在binder中，Android也为我们写好了相关的框架，但通过binder源码分析，你会发现，服务端挂死能通知到客户端，可是客户端挂死了却不能通知到服务端。有没有别的解决方案呢？分析Android源码，还真发现了一个不错的处理方案—使用匿名binder，简单来说，就是把客户端挂在实名binder下面，让自己成为一个匿名binder的服务端，好像有点绕？没关系，我们挨个分析如下的问题：

1.binder框架是如何实现服务端挂死通知到客户端的？
2.什么是匿名binder？
3.Android源码中匿名binder的巧用

二、DeathRecipient的使用
IBinder类中有一个抽象类DeathRecipient，所有的客户端想要实现服务端对其的死亡通知，都需要实现一个该抽象类的子类：

class DeathRecipient : public virtual RefBase
{
public:
    virtual void binderDied(const wp<IBinder>& who) = 0;
};

当服务端出现挂死时，会回调子类的binderDied函数，客户端可在该函数中实现需要的处理。下面看一下客户端是如何注册到服务端的，IBinder类中提供了linkToDeath和unlinkToDeath两个纯虚函数用于实现双端关联：

/**
 * Register the @a recipient for a notification if this binder
 * goes away.  If this binder object unexpectedly goes away
 * (typically because its hosting process has been killed),
 * then DeathRecipient::binderDied() will be called with a reference
 * to this.
 *
 * The @a cookie is optional -- if non-NULL, it should be a
 * memory address that you own (that is, you know it is unique).
 *
 * @note You will only receive death notifications for remote binders,
 * as local binders by definition can't die without you dying as well.
 * Trying to use this function on a local binder will result in an
 * INVALID_OPERATION code being returned and nothing happening.
 *
 * @note This link always holds a weak reference to its recipient.
 *
 * @note You will only receive a weak reference to the dead
 * binder.  You should not try to promote this to a strong reference.
 * (Nor should you need to, as there is nothing useful you can
 * directly do with it now that it has passed on.)
 */
// NOLINTNEXTLINE(google-default-arguments)
virtual status_t        linkToDeath(const sp<DeathRecipient>& recipient,
                                    void* cookie = nullptr,
                                    uint32_t flags = 0) = 0;

/**
 * Remove a previously registered death notification.
 * The @a recipient will no longer be called if this object
 * dies.  The @a cookie is optional.  If non-NULL, you can
 * supply a NULL @a recipient, and the recipient previously
 * added with that cookie will be unlinked.
 *
 * If the binder is dead, this will return DEAD_OBJECT. Deleting
 * the object will also unlink all death recipients.
 */
// NOLINTNEXTLINE(google-default-arguments)
virtual status_t        unlinkToDeath(  const wp<DeathRecipient>& recipient,
                                        void* cookie = nullptr,
                                        uint32_t flags = 0,
                                        wp<DeathRecipient>* outRecipient = nullptr) = 0;

binder源码框架中，BBinder和BpBinder均继承自IBinder，那么是否意味着，Bp和Bn都可以实现linkToDeath和unlinkToDeath呢？很遗憾，只有BnBinder才能这么做，上面的注释已经说明了在Bn端调用linkToDeath将会返回非法操作，我们看下源码Binder.cpp：

status_t BBinder::linkToDeath(
    const sp<DeathRecipient>& /*recipient*/, void* /*cookie*/,
    uint32_t /*flags*/)
{
    return INVALID_OPERATION;
}

再看下BpBinder.cpp：

// NOLINTNEXTLINE(google-default-arguments)
status_t BpBinder::linkToDeath(
    const sp<DeathRecipient>& recipient, void* cookie, uint32_t flags)
{
    Obituary ob;
    ob.recipient = recipient;
    ob.cookie = cookie;
    ob.flags = flags;

    LOG_ALWAYS_FATAL_IF(recipient == nullptr,
                        "linkToDeath(): recipient must be non-NULL");

    {
        AutoMutex _l(mLock);

        if (!mObitsSent) {
            if (!mObituaries) {
                mObituaries = new Vector<Obituary>;
                if (!mObituaries) {
                    return NO_MEMORY;
                }
                ALOGV("Requesting death notification: %p handle %d\n", this, mHandle);
                getWeakRefs()->incWeak(this);
                IPCThreadState* self = IPCThreadState::self();
                self->requestDeathNotification(mHandle, this);
                self->flushCommands();
            }
            ssize_t res = mObituaries->add(ob);
            return res >= (ssize_t)NO_ERROR ? (status_t)NO_ERROR : res;
        }
    }

    return DEAD_OBJECT;
}

Bp端将通过requestDeathNotification函数将通知注册到底层的binder驱动，驱动里面的分析这里就不去深究了，有兴趣的可翻墙看这篇博客，讲的很详细（Android Binder 分析——死亡通知（DeathRecipient））。
通过上面两个源码的分析解释了为何服务端挂死能通知到客户端，而客户端挂死却无法通知到服务端了，当服务端出现挂死后，底层驱动会层层调用至reportOneDeath@BpBinder：

void BpBinder::reportOneDeath(const Obituary& obit)
{
    sp<DeathRecipient> recipient = obit.recipient.promote();
    ALOGV("Reporting death to recipient: %p\n", recipient.get());
    if (recipient == nullptr) return;

    recipient->binderDied(this);
}

recipient->binderDied(this)就调用到客户端子类的实现函数binderDied中了。

三、何为匿名binder？
binder分为实名binder和匿名binder，实名binder即注册到Service Manager中的binder，你可以通过service list查询到的服务，匿名binder则不需要注册到SM中，因此你在SM中是找不到匿名binder的。实名binder与匿名binder区别在于是否有如下注册语句：

defaultServiceManager()->addService(
            String16("media.player"), new MediaPlayerService());

以MediaPlayerService为例，这里的defaultServiceManager即获取SM：

sp<IServiceManager> defaultServiceManager()
{
    std::call_once(gSmOnce, []() {
        sp<AidlServiceManager> sm = nullptr;
        while (sm == nullptr) {
            sm = interface_cast<AidlServiceManager>(ProcessState::self()->getContextObject(nullptr));
            if (sm == nullptr) {
                ALOGE("Waiting 1s on context object on %s.", ProcessState::self()->getDriverName().c_str());
                sleep(1);
            }
        }

        gDefaultServiceManager = new ServiceManagerShim(sm);
    });

    return gDefaultServiceManager;
}

需要注意的是，匿名binder必须基于已经创建好的binder连接，不然没法通过Parcel将相关binder数据写入到驱动中并创建对应的binder node。

四、Android源码中对匿名binder的巧用
以AudioFlinger中的一段源码来看看Android是如何使用匿名binder对服务端进行死亡通知的。
AudioFlinger是音频系统中的执行者，同时也是实名binder服务IAudioFlinger的Bn端，它有一个内部类NotificationClient：

class NotificationClient : public IBinder::DeathRecipient {
public:
                        NotificationClient(const sp<AudioFlinger>& audioFlinger,
                                            const sp<IAudioFlingerClient>& client,
                                            pid_t pid,
                                            uid_t uid);
    virtual             ~NotificationClient();

            sp<IAudioFlingerClient> audioFlingerClient() const { return mAudioFlingerClient; }
            pid_t getPid() const { return mPid; }
            uid_t getUid() const { return mUid; }

            // IBinder::DeathRecipient
            virtual     void        binderDied(const wp<IBinder>& who);

private:
    DISALLOW_COPY_AND_ASSIGN(NotificationClient);

    const sp<AudioFlinger>  mAudioFlinger;
    const pid_t             mPid;
    const uid_t             mUid;
    const sp<IAudioFlingerClient> mAudioFlingerClient;
};

从前面的分析已知，继承自IBinder::DeathRecipient的类一般都是Bp端去实现的，可为什么Bn端会有这个一个类呢？其实，这个类是用于注册到匿名binder服务IAudioFlingerClient中的。我们先看一下起IAudioFlingerClient的地方，在AudioSystem.cpp中，存在如下函数：

// establish binder interface to AudioFlinger service
const sp<IAudioFlinger> AudioSystem::get_audio_flinger()
{
    sp<IAudioFlinger> af;
    sp<AudioFlingerClient> afc;
    bool reportNoError = false;
    {
        Mutex::Autolock _l(gLock);
        if (gAudioFlinger == 0) {
            sp<IServiceManager> sm = defaultServiceManager();
            sp<IBinder> binder;
            do {
                binder = sm->getService(String16("media.audio_flinger"));
                if (binder != 0)
                    break;
                ALOGW("AudioFlinger not published, waiting...");
                usleep(500000); // 0.5 s
            } while (true);
            if (gAudioFlingerClient == NULL) {
            	/* 创建匿名binder */
                gAudioFlingerClient = new AudioFlingerClient();
            } else {
                reportNoError = true;
            }
            /* 注册AudioFlinger的死亡通知 */
            binder->linkToDeath(gAudioFlingerClient);
            gAudioFlinger = interface_cast<IAudioFlinger>(binder);
            LOG_ALWAYS_FATAL_IF(gAudioFlinger == 0);
            afc = gAudioFlingerClient;
            // Make sure callbacks can be received by gAudioFlingerClient
            ProcessState::self()->startThreadPool();
        }
        af = gAudioFlinger;
    }
    if (afc != 0) {
        int64_t token = IPCThreadState::self()->clearCallingIdentity();
        /* 调用AudioFlinger进行IAudioFlingerClient的死亡注册 */
        af->registerClient(afc);
        IPCThreadState::self()->restoreCallingIdentity(token);
    }
    if (reportNoError) reportError(NO_ERROR);
    return af;
}

首先是通过SM找到实名binder服务IAudioFlinger，然后实例化匿名binder服务AudioFlingerClient，代码中还将AudioFlingerClient的通知注册到IAudioFlinger中进行监听，以实现双向通知，我们重点跟进af->registerClient(afc)，这里会调用到IAudioFlinger的接口，看下Bp端的传输：

virtual void registerClient(const sp<IAudioFlingerClient>& client)
{
    Parcel data, reply;
    data.writeInterfaceToken(IAudioFlinger::getInterfaceDescriptor());
    data.writeStrongBinder(IInterface::asBinder(client));
    remote()->transact(REGISTER_CLIENT, data, &reply);
}

Bn端：

case REGISTER_CLIENT: {
    CHECK_INTERFACE(IAudioFlinger, data, reply);
    sp<IAudioFlingerClient> client = interface_cast<IAudioFlingerClient>(
            data.readStrongBinder());
    registerClient(client);
    return NO_ERROR;
} break;

拿到client的强引用，传入到registerClient中：

void AudioFlinger::registerClient(const sp<IAudioFlingerClient>& client)
{
    Mutex::Autolock _l(mLock);
    if (client == 0) {
        return;
    }
    pid_t pid = IPCThreadState::self()->getCallingPid();
    const uid_t uid = IPCThreadState::self()->getCallingUid();
    {
        Mutex::Autolock _cl(mClientLock);
        if (mNotificationClients.indexOfKey(pid) < 0) {
            sp<NotificationClient> notificationClient = new NotificationClient(this,
                                                                                client,
                                                                                pid,
                                                                                uid);
            ALOGV("registerClient() client %p, pid %d, uid %u",
                    notificationClient.get(), pid, uid);

            mNotificationClients.add(pid, notificationClient);

            sp<IBinder> binder = IInterface::asBinder(client);
            binder->linkToDeath(notificationClient);
        }
    }
	...
}

实际上这段代码的意思就是将IAudioFlingerClient的强引用转成binder实体，然后将AudioFlinger中的实例化的内部类NotificationClient注册到匿名binder中，那么当匿名binder出现服务挂死时，则会回调到该内部类的binderDied函数，达到死亡通知的目的以实现需要处理的业务：

void AudioFlinger::NotificationClient::binderDied(const wp<IBinder>& who __unused)
{
    sp<NotificationClient> keep(this);
    mAudioFlinger->removeNotificationClient(mPid);
}