Android 插件化原理解析:Hook 机制之AMS&PMS

在前面的文章中我们介绍了DroidPlugin的Hook机制,也就是代理方式Binder Hook;插件框架通过AOP实现了插件使用和开发的透明性。在讲述DroidPlugin如何实现四大组件的插件化之前,有必要说明一下它对ActivityManagerServiche以及PackageManagerService的Hook方式(以下简称AMS,PMS)。

ActivityManagerService对于FrameWork层的重要性不言而喻,Android的四大组件无一不与它打交道:

  1. startActivity最终调用了AMS的startActivity系列方法,实现了Activity的启动;Activity的生命周期回调,也在AMS中完成;
  2. startService,bindService最终调用到AMS的startService和bindService方法;
  3. 动态广播的注册和接收在AMS中完成(静态广播在PMS中完成)
  4. getContentResolver最终从AMSgetContentProvider获取到ContentProvider

PMS则完成了诸如权限校捡(checkPermission,checkUidPermission),Apk meta信息获取(getApplicationInfo等),四大组件信息获取(query系列方法)等重要功能。

在上文Android插件化原理解析:Hook机制之Binder Hook中讲述了DroidPlugin的Binder Hook机制;我们知道AMSPMS就是以Binder方式提供给应用程序使用的系统服务,理论上我们也可以采用这种方式Hook掉它们。但是由于这两者使用得如此频繁,Framework给他们了一些“特别优待”,这也给了我们相对于Binder Hook更加稳定可靠的hook方式。

阅读本文之前,可以先clone一份 [understand-plugin-framework][2],参考此项目的ams-pms-hook模块。另外,插件框架原理解析系列文章见索引

AMS获取过程

前文提到Android的四大组件无一不与AMS相关,也许读者还有些许疑惑;这里我就挑一个例子,依据Android源码来说明,一个简单的startActivity是如何调用AMS最终通过IPC到system_server的。

不论读者是否知道,我们使用startActivity有两种形式:

  1. 直接调用Context类的startActivity方法;这种方式启动的Activity没有Activity栈,因此不能以standard方式启动,必须加上FLAG_ACTIVITY_NEW_TASK这个Flag。
  2. 调用被Activity类重载过的startActivity方法,通常在我们的Activity中直接调用这个方法就是这种形式;

Context.startActivity

我们查看Context类的startActivity方法,发现这竟然是一个抽象类;查看Context的类继承关系图如下:

我们看到诸如ActivityService等并没有直接继承Context,而是继承了ContextWrapper;继续查看ContextWrapper的实现:

@Override
public void startActivity(Intent intent) {
    mBase.startActivity(intent);
}

WTF!! 果然人如其名,只是一个wrapper而已;这个mBase是什么呢?这里我先直接告诉你,它的真正实现是ContextImpl类;至于为什么,有一条思路:mBase是在ContextWrapper构造的时候传递进来的,那么在ContextWrapper构造的时候可以找到答案
什么时候会构造ContextWrapper呢?它的子类ApplicationService等被创建的时候。

可以在App的主线程AcitivityThreadperformLaunchActivit方法里面找到答案;更详细的解析可以参考老罗的[ Android应用程序启动过程源代码分析][3]

好了,我们姑且当作已经知道Context.startActivity最终使用了ContextImpl里面的方法,代码如下:

public void startActivity(Intent intent, Bundle options) {
    warnIfCallingFromSystemProcess();
    if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
        throw new AndroidRuntimeException(
                "Calling startActivity() from outside of an Activity "
                + " context requires the FLAG_ACTIVITY_NEW_TASK flag."
                + " Is this really what you want?");
    }
    mMainThread.getInstrumentation().execStartActivity(
        getOuterContext(), mMainThread.getApplicationThread(), null,
        (Activity)null, intent, -1, options);
}

代码相当简单;我们知道了两件事:

  1. 其一,我们知道了在Service等非Activity的Context里面启动Activity为什么需要添加FLAG_ACTIVITY_NEW_TASK
  2. 其二,真正的startActivity使用了Instrumentation类的execStartActivity方法;继续跟踪:
public ActivityResult execStartActivity(
        Context who, IBinder contextThread, IBinder token, Activity target,
        Intent intent, int requestCode, Bundle options) {
    // ... 省略无关代码
    try {
        intent.migrateExtraStreamToClipData();
        intent.prepareToLeaveProcess();
        // ----------------look here!!!!!!!!!!!!!!!!!!!
        int result = ActivityManagerNative.getDefault()
            .startActivity(whoThread, who.getBasePackageName(), intent,
                    intent.resolveTypeIfNeeded(who.getContentResolver()),
                    token, target != null ? target.mEmbeddedID : null,
                    requestCode, 0, null, null, options);
        checkStartActivityResult(result, intent);
    } catch (RemoteException e) {
    }
    return null;
}

到这里我们发现真正调用的是ActivityManagerNativestartActivity方法;如果你不清楚ActivityManagerActivityManagerService以及ActivityManagerNative之间的关系;建议先仔细阅读我之前关于Binder的文章 [Binder学习指南][4]。

Activity.startActivity

Activity类的startActivity方法相比Context而言直观了很多;这个startActivity通过若干次调用辗转到达startActivityForResult这个方法,在这个方法内部有如下代码:

Instrumentation.ActivityResult ar =
    mInstrumentation.execStartActivity(
        this, mMainThread.getApplicationThread(), mToken, this,
        intent, requestCode, options);

可以看到,其实通过Activity和ContextImpl类启动Activity并无本质不同,他们都通过Instrumentation这个辅助类调用到了ActivityManagerNative的方法。

Hook AMS

OK,我们到现在知道;其实startActivity最终通过ActivityManagerNative这个方法远程调用了AMSstartActivity方法。那么这个ActivityManagerNative是什么呢?

ActivityManagerNative实际上就是ActivityManagerService这个远程对象的Binder代理对象;每次需要与AMS打交道的时候,需要借助这个代理对象通过驱动进而完成IPC调用。

我们继续看ActivityManagerNativegetDefault()方法做了什么:

    static public IActivityManager getDefault() {
        return gDefault.get();
    }

gDefault这个静态变量的定义如下:

private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
    protected IActivityManager create() {
        IBinder b = ServiceManager.getService("activity
        IActivityManager am = asInterface(
        return am;
    }
};

由于整个Framework与AMS打交道是如此频繁,framework使用了一个单例把这个AMS的代理对象保存了起来;这样只要需要与AMS进行IPC调用,获取这个单例即可。这是AMS这个系统服务与其他普通服务的不同之处,也是我们不通过Binder Hook的原因——我们只需要简单地Hook掉这个单例即可。

这里还有一点小麻烦:Android不同版本之间对于如何保存这个单例的代理对象是不同的;Android 2.x系统直接使用了一个简单的静态变量存储,Android 4.x以上抽象出了一个Singleton类;具体的差异可以使用grepcode进行比较:[差异][5]

我们以4.x以上的代码为例说明如何Hook掉AMS;方法使用的动态代理,如果有不理解的,可以参考之前的系列文章Android插件化原理解析:Hook机制之动态代理

```java
Class activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");

// 获取 gDefault 这个字段, 想办法替换它
Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
gDefaultField.setAccessible(true);
Object gDefault = gDefaultField.get(null);

top Created with Sketch.