问题提出
在应用中测试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.2543162212222122 I MyService: onClick: starting service, end of onClick
01-08 09:13:58.0793722212222133I MyService: =======1 UNINSTALL_COMPLETE ==========
接下来一个疑问，onClick很快就返回了，时间点是
01-08 09:13:57.2543162212222122 I MyService: onClick: starting service, end of onClick
为什么过了一会，回调函数还可以被执行？
01-08 09:13:58.0793722212222133I 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(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 get(JNIEnv* env, jobject obj)
{
AutoMutex _l(mLock);
sp b = mBinder.promote();
if (b == NULL) {
b = newJavaBBinder(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 IPackageDeleteObservergObserver= 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 ==========
子线程是如何产生的呢？这又是另外一个问题了，有空再聊
(代码copy过来后格式变乱了，有空再修改)
