标签:
正常情况下启动一个Activity,首先需要在AndroidManifest文件中声明,其次需要把该应用安装到手机系统中。
而插件apk是没有正在安装到手机系统中的,也就按照正常的启动流程插件Activity是不能启动的。另外插件apk的类需要加载进来是需要指定ClassLoader。前面的文章也大概讲过,当启动一个插件Activity时,先是用预定义的代理Activity替换目标Activity(及插件Activity)去启动,当AMS处理完回调到应用空间时(及回到运行Activity的进程空间时)再用目标Activity替换回来,去调用目标Activity的声明周期。再这个过程中,要实例化目标Activity用到了PluginClassLoader,自定义的ClassLoader来加载实例化目标Activity.
总结:也就是说要启动插件Activity DroidPlugin至少需要解决以下三个问题:
1 在启动Activity进入到AMS前需要用预定义的代理Activity替换目标Activity(及插件Activity)。
2 请完成后进入到运行Activity的进程中时,需要将目标activity替换回来。
3 需要用自定义的PluginClassLoader加载目标Activity。
通过分析Android Framework源码可以了解到(这里没有分析全部的Activity启动流程,只是针对上面三个问题的源码处理流程,这样能帮助理解DroidPlugin的篡改处理流程)
1 启动一个Activity最终都会通过调用ActivityManagerProxy 也就是AMS服务的代理来请求AMS启动。
2 AMS做完相关Activity的启动工作以后
A 会通过ActivityThread的内部类ApplicationThread这个binder对象回调到运行Activity的进程空间。
B 然后通过调用ActivityThread成员变量mH这个继承自Handler类的对象往主线程发送一条LAUNCH_ACTIVITY的消息。
C 在Handler分发消息的流程函数dispatchMessage中可以了解到,Handler有一个成员变量mCallback,如果不为空则调用mCallback.handleMessage(msg),当callback的handleMessage函数返回True时直接返回了, 就不会执行handleMessage(msg);函数。Activity正常启动的情况下会调用mH.handleMessage函数。执行LAUNCH_ACTIVITY消息对应的处理函数handleLaunchActivity函数启动Activity(也就是调用Activity的生命周期)
3 实例化目标Activity过程。
A 在执行LAUNCH_ACTIVITY消息时,会调用ActivityThread的getPackageInfoNoCheck函数获取一个LoadedApk对象。获取过程中会先通过包名从ActivityThread的成员变量mPackages中去查找是否有包名对应的LoadedApk存在,如果不存在则创建一个LoadedApk对象并以当前包名为key保存到mPackages中。同时将创建的LoadedApk保存到ActivityClientRecord的成员变量packageInfo中。在LoadedApk的构造函数中还会初始化一个mClassLoader的成员变量,默认情况下这个mClassLoader是一个PathClassLoader的对象。
B 创建完LoadedApk对象之后就会调用handleLaunchActivity函数,在这个函数里面会调用performLaunchActivity函数中会获取ActivityClientRecord的成员变量packageInfo内部的mClassLoader来加实例化目标Activity对象。
DroidPlugin就是在上面三段代码处理流程中找到Hook点来解决上面三个问题实现插件Activity的启动的。
1 启动前用代理Activity替换目标Activity:
在DroidPlugin中这个ActivityManagerProxy也已经被Hook,(如何Hook 可以看IActivityManagerHook的Install函数,了解AMS的Hook过程)那么只需要在IActivityManagerHook对应的处理分发类IActivityManagerHookHandle中对ActivityManagerProxy的StartActivity函数进行处理Activity的替换就行了。
2 启动后用目标Activity替换回代理Activity。
在DroidPlugin中通过PluginCallbackHook Hook了ActivityThread中的成员变量mH这个Handler的成员变量mCallback,特别对Id为LAUNCH_ACTIVITY的消息做了将目标Activity替换回代理Activity的预处理。(如何Hook 可以看PluginCallbackHook 的Install函数)
3 篡改实例化目标Activity(插件Activity)的过程。
前面分析了正常Activity对象是通过LoadedApk的成员变量mClassLoader来是实例化的,而在前面的文章也说过插件Activity要想加载,必须通过自定义的继承自DexClassLoader的PluginClassLoader来实例化,因此DroidPlugin用插件Apk的包名为key,伪造了一个LoadedApk对象为Value,保存到了ActivityThread的成员变量mPackages中同时用PluginClassLoader的对象替换了原本保存在LoadedApk成员变量mClassLoader中的ClassLoader对象。
接下来就通过源码分析DroidPlugin对上面三个流程源码的处理:
一 IActivityManagerHook对目标Activity的替换流程。
通过Hook的过程分析可以知道,IActivityManagerHook是通过IActivityManagerHookHandle对AMS各个函数分发处理类,而startActivity是通过startActivity类的函数beforeInvoke来处理的。
startActivity的beforeInvoke函数如下:
protected boolean beforeInvoke(Object receiver, Method method, Object[] args) throws Throwable {
RunningActivities.beforeStartActivity();
boolean bRet = true;
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR2) {
bRet = doReplaceIntentForStartActivityAPILow(args);
} else {
bRet = doReplaceIntentForStartActivityAPIHigh(args);
}
if (!bRet) {
setFakedResult(Activity.RESULT_CANCELED);
return true;
}
return super.beforeInvoke(receiver, method, args);
}
}
A 此函数中首先调用的是RunningActivities.beforeStartActivity();
分析此函数前线了解RunningActivities类的一个内部类和几个成员变量的作用。
内部类RunningActivityRecord及其四个成员变量: 记录运行时Activity的一个数据类,
activity:Activity类,保存目标Activity对象。
targetActivityInfo: ActivityInfo类,保存目标ActivityInfo对象。
stubActivityInfo: ActivityInfo类,保存预定义代理ActivityInfo对象。
index: 记录activity启动时的顺序。
mRunningActivityList : 以activity对象为key, RunningActivityRecord对象为Value。保存所有当前进程所有运行的Activity。
mRunningSingleStandardActivityList,mRunningSingleTopActivityList,mRunningSingleTaskActivityList, mRunningSingleInstanceActivityList,
以activity的启动顺序为key,以RunningActivityRecord为Value分别保存四种不同启动模式的Activity。
RunningActivities.beforeStartActivity()函数如下:
public static void beforeStartActivity() {
synchronized (mRunningActivityList) {
for (RunningActivityRecord record : mRunningActivityList.values()) {
if (record.stubActivityInfo.launchMode == ActivityInfo.LAUNCH_MULTIPLE) {
continue;
} else if (record.stubActivityInfo.launchMode == ActivityInfo.LAUNCH_SINGLE_TOP) {
doFinshIt(mRunningSingleTopActivityList);
} else if (record.stubActivityInfo.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
doFinshIt(mRunningSingleTopActivityList);
} else if (record.stubActivityInfo.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
doFinshIt(mRunningSingleTopActivityList);
}
}
}
}
这个函数主要是遍历mRunningActivityList,然后根据RunningActivityRecord的类型,除Standard启动模式外,其他三种启动模式分别调用doFinshIt并以分别保存正在运行的其他三种启动模式的map对象为参数。
继续看doFinshIt函数:
private static void doFinshIt(Map<Integer, RunningActivityRecord> runningActivityList) {
if (runningActivityList != null && runningActivityList.size() >= PluginManager.STUB_NO_ACTIVITY_MAX_NUM - 1) {
List<RunningActivityRecord> activitys = new ArrayList<>(runningActivityList.size());
activitys.addAll(runningActivityList.values());
Collections.sort(activitys, sRunningActivityRecordComparator);
RunningActivityRecord record = activitys.get(0);
if (record.activity != null && !record.activity.isFinishing()) {
record.activity.finish();
}
}
}
这个函数主要就是,获取保存对应启动模式Activity的map对象不为空,且的size大于等于3的情况下,调用activity的finish函数结束最早启动的activity。
也就是说doFinishIt函数是当预定义的Activity不够用时,在启动新的Activity前把最早启动的activity Finish掉。
看完这段代码我有两个疑问:
疑问1: 为什么要在beforeStartActivity函数中遍历mRunningActivityList而不是直接调用doFinishIt函数三次?遍历可能会多次调用同一种启动模式的doFinishIt函数啊。多次调用和调用一次,结果是一样的啊?
疑问2: 为什么doFinishIt函数中最大值是三呢?而不是4?除Standard启动模式之外的三种启动模式预定义了四个啊?还有DialogTheme的Activity也预定义了4个?如果存在如下情况,启动了一个Activity,三个DialogThemeActivity,现在又要启动一个Activity,那不是第一个Activity错杀了?(可能哪里没有理解透彻,希望大虾解答!)
B 回到beforeInvoke继续分析,下面的代码中正对不同阶段的版本调用了不同的函数,最后这两个函数在正常处理完成的逻辑下会返回True,也就是返回super.beforeInvoke,而这个函数默认是返回false的,当beforeInvoke返回false时,就会直接调用被代理的函数去执行。也就是说替换一定发生在这两个函数中,这里就以高版本的处理函数来分析(基本包含低版本的处理逻辑)。
doReplaceIntentForStartActivityAPIHigh函数如下:
protected boolean doReplaceIntentForStartActivityAPIHigh(Object[] args) throws RemoteException {
int intentOfArgIndex = findFirstIntentIndexInArgs(args);
if (args != null && args.length > 1 && intentOfArgIndex >= 0) {
Intent intent = (Intent) args[intentOfArgIndex];
if (!PluginPatchManager.getInstance().canStartPluginActivity(intent)) {
PluginPatchManager.getInstance().startPluginActivity(intent);
return false;
}
ActivityInfo activityInfo = resolveActivity(intent);
if (activityInfo != null && isPackagePlugin(activityInfo.packageName)) {
ComponentName component = selectProxyActivity(intent);
if (component != null) {
Intent newIntent = new Intent();
ClassLoader pluginClassLoader = PluginProcessManager.getPluginClassLoader(component.getPackageName());
setIntentClassLoader(newIntent, pluginClassLoader);
newIntent.setComponent(component);
newIntent.putExtra(Env.EXTRA_TARGET_INTENT, intent);
newIntent.setFlags(intent.getFlags());
String callingPackage = (String) args[1];
if (TextUtils.equals(mHostContext.getPackageName(), callingPackage)) {
newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
}
}
args[intentOfArgIndex] = newIntent;
args[1] = mHostContext.getPackageName();
}
}
}
return true;
}
1 从参数中找到Intent参数的位置,取出Intent,然后判断是否能启动插件Activity,如果不能则调用PluginPatchManager的startPluginActivity延迟启动。
能否启动取决于一下两个条件:
条件1:PluginManagerService是否已经启动。
条件2:启动Activity的包名和宿主进程的包名不一样。
2 调用resolveActivity函数从插件服务中找到启动插件插件ActivityInfo。resolveActivity函数不做过多分,看过插件安装的文章中讲过保存的过程,这里只是获取。
3 判断获取到的activityInfo不为空,且是插件中的Activity,然后调用selectProxyActivity(此函数在进程管理文章中已近有分析)找到合适的代理Activity。
4 创建一个新的Intent,设置启动Activity为前面找到的代理Activity,并把目标activity保存到新的Intent中.最后判断调用者的包名是不是宿主进程包名,然后把新的Intent替换掉之前找到的Intent参数的位置。
至此替换过程已经完成。
二:AMS处理完成回到运行Activity进程空间,完成目标Activity替换回来,以及目标Activity实例化过程。
A 前面已经分析过了具体的处理类,直接看PluginCallback对LAUNCH_ACTIVITY的处理函数:handleLaunchActivity:考虑到函数比较长分段阅读:
1 找出目标Activity
private boolean handleLaunchActivity(Message msg) {
try {
Object obj = msg.obj;
Intent stubIntent = (Intent) FieldUtils.readField(obj, "intent");
stubIntent.setExtrasClassLoader(mHostContext.getClassLoader());
Intent targetIntent = stubIntent.getParcelableExtra(Env.EXTRA_TARGET_INTENT);
// 这里多加一个isNotShortcutProxyActivity的判断,因为ShortcutProxyActivity的很特殊,启动它的时候,也会带上一个EXTRA_TARGET_INTENT的数据,就会导致这里误以为是启动插件Activity,所以这里要先做一个判断。之前ShortcutProxyActivity错误复用了key,但是为了兼容,所以这里就先这么判断吧。
if (targetIntent != null && !isShortcutProxyActivity(stubIntent)) {
IPackageManagerHook.fixContextPackageManager(mHostContext);
ComponentName targetComponentName = targetIntent.resolveActivity(mHostContext.getPackageManager());
ActivityInfo targetActivityInfo = PluginManager.getInstance().getActivityInfo(targetComponentName, 0);
if (targetActivityInfo != null) {
if (targetComponentName != null && targetComponentName.getClassName().startsWith(".")) {
targetIntent.setClassName(targetComponentName.getPackageName(), targetComponentName.getPackageName() + targetComponentName.getClassName());
}
ResolveInfo resolveInfo = mHostContext.getPackageManager().resolveActivity(stubIntent, 0);
ActivityInfo stubActivityInfo = resolveInfo != null ? resolveInfo.activityInfo : null;
if (stubActivityInfo != null) {
PluginManager.getInstance().reportMyProcessName(stubActivityInfo.processName, targetActivityInfo.processName, targetActivityInfo.packageName);
}
1.1 是从msg.obj中获取代理Intent参数,然后从代理Intent中获取启动之前保存的目标intent。
1.2 判断目标Intent是否存在,而且不是一个ShortcutProxyActivity然后调用IPackageManagerHook.fixContextPackageManager(mHostContext);
要创建的Activity(及ContextImpl)有一个成员变量mPackageManager 是一个ApplicationPackageManager类对象,再ApplicationPackageManager类里面有一个成员变量,mPM,保存了PackageManager服务的代理对象。
这一步要做的事情就是保证这个代理对象是之前Hook过的对象。
1.3 接下来的代码就是设置目标intent具体的类,然后找到目标ActivityInfo和代理ActivityInfo。最后提交管理。
2 创建插件Activity加载环境:
PluginProcessManager.preLoadApk(mHostContext, targetActivityInfo);
ClassLoader pluginClassLoader = PluginProcessManager.getPluginClassLoader(targetComponentName.getPackageName());
setIntentClassLoader(targetIntent, pluginClassLoader);
setIntentClassLoader(stubIntent, pluginClassLoader);
这里就是前面DroidPlugin中需要解决的第二个问题,预存LoadedApk,并替换LoadedApk中的ClassLoader。以便加载插件Activity。
先分析完这个函数在分析PluginProcessManager.preLoadApk函数的实现。
3 最后一段代码比较长,而且都是在做兼容处理,就不贴代码了。
具体做的事情就是把目标ActivityInfo和代理ActivityInfo保存到目标Intent中。在msg.obj中把目标Intent替换到原来的代理intent,再把目标ActivityInfo替换掉代理ActivityInfo。
4 PluginProcessManager.preLoadApk还是分段阅读:
public static void preLoadApk(Context hostContext, ComponentInfo pluginInfo) throws IOException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, PackageManager.NameNotFoundException, ClassNotFoundException {
/*添加插件的LoadedApk对象到ActivityThread.mPackages*/
boolean found = false;
synchronized (sPluginLoadedApkCache) {
Object object = ActivityThreadCompat.currentActivityThread();
if (object != null) {
Object mPackagesObj = FieldUtils.readField(object, "mPackages");
Object containsKeyObj = MethodUtils.invokeMethod(mPackagesObj, "containsKey", pluginInfo.packageName);
if (containsKeyObj instanceof Boolean && !(Boolean) containsKeyObj) {
final Object loadedApk;
if (VERSION.SDK_INT >= VERSION_CODES.HONEYCOMB) {
loadedApk = MethodUtils.invokeMethod(object, "getPackageInfoNoCheck", pluginInfo.applicationInfo, CompatibilityInfoCompat.DEFAULT_COMPATIBILITY_INFO());
} else {
loadedApk = MethodUtils.invokeMethod(object, "getPackageInfoNoCheck", pluginInfo.applicationInfo);
}
sPluginLoadedApkCache.put(pluginInfo.packageName, loadedApk);
这段代码主要做了如下工作:获取ActivityThread对象的成员变量mPackages,并判断mPackages是否包含当前插件包名为key的LoadedApk对象。如果不包含则调用ActivityThread的getPackageInfoNoCheck函数创建LoadedApk对象。以插件包名为key将创建的LoadedApk对象保存到sPluginLoadedApkCache中。
String optimizedDirectory = PluginDirHelper.getPluginDalvikCacheDir(hostContext, pluginInfo.packageName);
String libraryPath = PluginDirHelper.getPluginNativeLibraryDir(hostContext, pluginInfo.packageName);
String apk = pluginInfo.applicationInfo.publicSourceDir;
if (TextUtils.isEmpty(apk)) {
pluginInfo.applicationInfo.publicSourceDir = PluginDirHelper.getPluginApkFile(hostContext, pluginInfo.packageName);
apk = pluginInfo.applicationInfo.publicSourceDir;
}
if (apk != null) {
ClassLoader classloader = null;
try {
classloader = new PluginClassLoader(apk, optimizedDirectory, libraryPath, ClassLoader.getSystemClassLoader());
} catch (Exception e) {
}
if(classloader==null){
PluginDirHelper.cleanOptimizedDirectory(optimizedDirectory);
classloader = new PluginClassLoader(apk, optimizedDirectory, libraryPath, ClassLoader.getSystemClassLoader());
}
synchronized (loadedApk) {
FieldUtils.writeDeclaredField(loadedApk, "mClassLoader", classloader);
}
sPluginClassLoaderCache.put(pluginInfo.packageName, classloader);
Thread.currentThread().setContextClassLoader(classloader);
found = true;
}
ProcessCompat.setArgV0(pluginInfo.processName);
}
}
}
这段代码的主要工作是:
1 获取optimizedDirectory,libraryPath,apk三个插件路径(看过插件安装应该非常熟悉了),创建PluginClassLoader对象classloader。
2 替换到LoadedApk中的成员变量mClassLoader.然后以插件包名为key保存到sPluginClassLoaderCache中。
3 设置当前线程ClassLoader为PluginClassLoader对象classloader。
4 设置当前进程名字为插件包名,这个不一定能实现。至少我的手机上还是显示的预定义的pluginXX.
if (found) {
PluginProcessManager.preMakeApplication(hostContext, pluginInfo);
}
}
最后这段代码主要是为之前创建的LoadedApk对象内部的成员mApplication。而preMakeApplication其实就是调用了LoadedApk的makeApplication函数。就不贴代码了。
三: 创建插件Activity创建之前的其他工作:
阅读DroidPlugin的源码可以发现,其实还通过InstrumentationHook Hook了Instrumentation类,查看InstrumentationHook的onInstall函数可以知道实际就是通过PluginInstrumentation 类对象替换了ActivityThread的成员变量mInstrumentation原来的值。
通过源码分析了解到,在performLaunchActivity函数中会调用mInstrumentation.callActivityOnCreate(activity, r.state);而在callActivityOnCreate函数中才会整整调用activity.performCreate来真正执行activity的onCreate函数。也就是说DroidPlugin Hook mInstrumentation变量就是想在执行activity的onCreate函数之前做了一些工作:
具体来看PluginInstrumentation的callActivityOnCreate函数:
@Override
public void callActivityOnCreate(Activity activity, Bundle icicle) {
if (enable) {
IWindowManagerBinderHook.fixWindowManagerHook(activity);
IPackageManagerHook.fixContextPackageManager(activity);
PluginProcessManager.fakeSystemService(mHostContext, activity);
onActivityCreated(activity);//放到最后分析
fixBaseContextImplOpsPackage(activity.getBaseContext());
fixBaseContextImplContentResolverOpsPackage(activity.getBaseContext());
}
//上面代码是实际调用activity onCreate函数前的处理。
if (mTarget != null) {
mTarget.callActivityOnCreate(activity, icicle);
} else {
super.callActivityOnCreate(activity, icicle);
}
}
1 IWindowManagerBinderHook.fixWindowManagerHook(activity);
在Activity对象内部有一个PhoneWindow类的成员变量 mWindow, 在PhoneWindow类中有一个内部类WindowManagerHolder,他里面有一个成员变量sWindowManager 保存了WindowManager服务的代理。
这一步要做的事情就是保证PhoneWindow 内部类WindowManager的静态成员变量SwindowManager这个WindowManager代理对象也是我们Hook过的WindowManager。
2 IPackageManagerHook.fixContextPackageManager(activity);这个前面已经分析过了。
3 PluginProcessManager.fakeSystemService(mHostContext, activity);
分析前现需要理解两个变量 SYSTEM_SERVICE_MAP 以及 mServiceCache 是做什么的?
ContextImpl 在类加载的时候会有静态代码块,初始化封装一些系统服务。
静态代码块中,会以要封装服务的名字为key ,以ServiceFetcher 对象为value 保存在SYSTEM_SERVICE_MAP中,其中在创建ServiceFetcher对象时实现了创建封装服务的方法。
当用户需要获取某一个系统服务时,通过ContextImpl getSystemService函数以及服务名字,这个函数就会从SYSTEM_SERVICE_MAP中获取ServiceFetcher对象,
然后调用ServiceFetcher对象的getService来获取。getService中,会先从ContextImp的成员变量mServiceCache,ServiceFetcher对象中有一个mContextCacheIndex保存了
一个位置,如果ServiceFetcher中的服务已近缓存了,那就必定就在mServiceCache的mContextCacheIndex位置,
如果不存在那么就直接调用ServiceFetcher的createService,创建服务对象并缓存到mServiceCache的mContextCacheIndex位置。
有了上面的理解,接下来fakeSystemService这个函数就好理解了:
这个函数调用了另外一个函数fakeSystemServiceInner
在fakeSystemServiceInner中主要做的事情就是:
事情一:保证新创建的Activity(及ContextImpl)中mServiceCache缓存的服务对象都是我们Hook过的。
事情二:为了兼容性跳过一些不能篡改的服务sSkipService。
事情三:在确保ContextImplement成员变量mServiceCache中缓存的服务是已经Hook过的以后,把这个ContextImplement 保存到mFakedContext。
这个函数的目的,因为系统服务可能缓存在多个地方,所以需要保证多个地方的服务都是Hook过的,从而保证插件正常运行。
4 fixBaseContextImplOpsPackage(activity.getBaseContext());
修改ContextImpl中的成员变量mOpPackageName 为宿主进程的包名。
5 fixBaseContextImplContentResolverOpsPackage
修改ContentResolver的成员变量,mPackageName
6 onActivityCreated
这个函数主要做的事情如下:
事情一:从目标Intent中获取目标ActivityInfo和代理ActivityInfo,调用RunningActivities.onActivtyCreate记录运行的Activity信息。
事情二:设置目标Activity屏幕请求方向。
事情三:调用PluginManager.getInstance().onActivityCreated添加到进程已经Activity管理中。
到这里DroidPlugin对插件Activity的处理全部分析完了。
标签:
原文地址:http://blog.csdn.net/zhangyawen1i/article/details/52001924