乱搞Android之Binder生命周期探讨

从匿名binder服务来研究其生命周期

问题提出

在测试binder传输IPackageDeleteObserver接口对象IPackageDeleteObserver.Stub实现回调的时候，把卸载操作getPackageManager().deletePackage("com.tencent.mm", observer, 0);写在了onClick方法中，如下：

        private static final String TAG = "MyService";

    public class PackageDeleteObserver extends IPackageDeleteObserver.Stub { 

        public void packageDeleted(boolean succeeded) {    

            Log.i(TAG, "======= UNINSTALL_COMPLETE =========="); 

        }

        public void packageDeleted(String s, int i)

        {

                 Log.i(TAG, "=======1 UNINSTALL_COMPLETE ==========");

        } 

    } 

       

        public void onClick(View src)

        {

                Log.i(TAG, "onClick: starting service");

               

                PackageDeleteObserver observer = new PackageDeleteObserver(); 

                getPackageManager().deletePackage("com.tencent.mm", observer, 0); 

                Log.i(TAG, "onClick: starting service, end of onClick");

        }

 

测试结果是回调方法packageDeleted被执行了

01-08 09:13:57.251972 22122 22122 I MyService: onClick: starting service

 

01-08 09:13:57.253983 20174 22360 D PackageManager: deletePackageAsUser: pkg=com.tencent.mm user=0 deleteAllUsers: false

01-08 09:13:57.254316 22122 22122 I MyService: onClick: starting service, end of onClick

 

01-08 09:13:58.079372 2212222133 I MyService: =======1 UNINSTALL_COMPLETE ==========

 

接下来一个疑问，onClick很快就返回了，01-08 09:13:57.254316 22122 22122 I MyService: onClick: starting service, end of onClick

为什么过了一会，回调函数还可以被执行？

01-08 09:13:58.079372 2212222133 I MyService: =======1 UNINSTALL_COMPLETE ==========

 

查看代码，原来，Java层的Binder对象构造的时候，和native层的JavaBBinder是关联起来的，这个过程以后再介绍。

在传送IPackageDeleteObserver接口对象IPackageDeleteObserver.Stub数据的时候，调用到Parcel的writeStrongBinder方法，继续调用到native方法

static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)

{

    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);

    if (parcel != NULL) {

        const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));

        if (err != NO_ERROR) {

            signalExceptionForError(env, clazz, err);

        }

    }

}

其中调用ibinderForJavaObject对IPackageDeleteObserver接口对象进行了处理。

sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)

{

    if (obj == NULL) return NULL;

 

    if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {

        JavaBBinderHolder* jbh = (JavaBBinderHolder*)

            env->GetLongField(obj, gBinderOffsets.mObject);

        return jbh != NULL ? jbh->get(env, obj) : NULL;

    }

 

    if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {

        return (IBinder*)

            env->GetLongField(obj, gBinderProxyOffsets.mObject);

    }

 

    ALOGW("ibinderForJavaObject: %p is not a Binder object", obj);

    return NULL;

}

 

其中调用到JavaBBinderHolder的get方法

class JavaBBinderHolder : public RefBase

{

public:

    sp<JavaBBinder> get(JNIEnv* env, jobject obj)

    {

        AutoMutex _l(mLock);

        sp<JavaBBinder> b = mBinder.promote();

        if (b == NULL) {

            b = new JavaBBinder(env, obj);

            mBinder = b;

            ALOGV("Creating JavaBinder %p (refs %p) for Object %p, weakCount=%" PRId32 "\n",

                 b.get(), b->getWeakRefs(), obj, b->getWeakRefs()->getWeakCount());

        }

 

        return b;

    }

其中new了一个JavaBBinder对象，注意，参数obj是Java层的IPackageDeleteObserver接口对象，查看JavaBBinder构造方法

class JavaBBinder : public BBinder

{

public:

    JavaBBinder(JNIEnv* env, jobject object)

        : mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object))

    {

        ALOGV("Creating JavaBBinder %p\n", this);

        android_atomic_inc(&gNumLocalRefs);

        incRefsCreated(env);

    }

 

对Java对象进行了NewGlobalRef操作，所以Java层的PackageDeleteObserver observer对象不会轻易的释放了。

 

我们继续测试来进行验证

 

修改PackageManagerService.java

定义一个IPackageDeleteObserver指针gObserver

public IPackageDeleteObserver gObserver = null;

 

对指针赋值

    public void deletePackageAsUser(String packageName, IPackageDeleteObserver observer, int userId,

            int flags) {

//卸载微信作为触发

if ("com.tencent.mm".equals(packageName))

{

        gObserver = observer;

        Log.d(TAG, "======== deletePackageAsUser,  gObserver = observer");

}

        deletePackage(packageName, new LegacyPackageDeleteObserver(observer).getBinder(), userId,

                flags);

    }

 

在dump方法里的-h选项后面增加调试代码

else if ("-testCallBinder".equals(opt))

{

        pw.println("======  testCallBinder");

            if (gObserver == null) return;

            try {

                pw.println("goint to call");

                gObserver.packageDeleted("mm", 0);

            } catch (RemoteException ignored) {

pw.println("RemoteException");

            } catch (Exception e) {

Slog.d(TAG, "================ test catch  ============");

e.printStackTrace();

}

 

        return;

}

卸载微信（com.tencent.mm）后，打印出

01-01 07:13:45.723 9023-9023/? I/MyService: onClick: starting service

01-01 07:13:45.737 9023-9023/? I/MyService: onClick: starting service, end of onClick

01-01 07:13:46.252 9023-9034/? I/MyService: =======1 UNINSTALL_COMPLETE ==========

 

在adb shell中执行dumpsys package -testCallBinder，又打印出MyService: =======1 UNINSTALL_COMPLETE ==========，如下所示

01-01 07:13:49.610 9023-9034/? I/MyService: =======1 UNINSTALL_COMPLETE ==========

 

我忍不住又按了几次dumpsys package -testCallBinder

01-01 07:13:52.659 9023-9035/? I/MyService: =======1 UNINSTALL_COMPLETE ==========

01-01 07:13:54.095 9023-9034/? I/MyService: =======1 UNINSTALL_COMPLETE ==========

 

 

说明应用中的packageDeleted被执行了。应用中的PackageDeleteObserver observer = new PackageDeleteObserver();作为一个binder服务端长期存在。

 

查看log，可以发现，执行packageDeleted的并不是主线程9023

01-01 07:13:49.610 9023-9034/? I/MyService: =======1 UNINSTALL_COMPLETE ==========

 

子线程是如何产生的呢？这又是另外一个问题了，有空再聊