详解VirtualApk启动插件Activity
插件以APK的形式保存在SD卡上,通过startActivity方式启动Activity需要首先将Activity注册到AndroidManifest.xml,如果没有注册就会出现如下错误。
Instrymentation.checkStartActivityResult
要实现插件Activity的启动需要解决以下问题:
1、插件的Activity需要在宿主的AndroidManifest.xml上注册。
2、插件Activity需要具有生命周期,能够响应onPause onResume onStart onDestroy等生命周期函数。
带着这两个问题,我们看下Activity的启动过程。
Activity启动流程
当调用startActivity后到调用Activity.onCreate会经过如下流程:
1、调用Instrumentation.execStartActivity
execStartActivity
该方法首先调用AMS.startActivity启动对应的Activity,然后通过checkStartActivityResult来对启动结果进行检查,如果没有在AndroidManifest.xml中注册该Activity,就会报出ActivityNotFoundException的错误。调用AMS.startActivity其实就是通过binder方式调用远程接口。
2、调用AMS.startActivity
AMS.startActivity会调用AcctivityStackSupervisor.startActivityMayWait函数;然后调用AcctivityStackSupervisor.startActivityLocked;接着调用AcctivityStackSupervisor.startActivityUncheckedLocked;最终调用了AcctivityStackSupervisor.startSpecificActivityLocked。
startSpecificActivityLocked
startSpecificActivityLocked中会判断app是否为空,app实际类型是ProcessRecord,代表Activity所属的进程信息。如果为空就调用AMS.startProcessLocked创建进程。
realStartActivityLocked中的实现
如果进程已经存在,就调用realStartActivityLocked函数,realStartActivityLocked会调用app.thread.scheduleLaunchActivity,app.thread时IApplicationThread,这到底是个是什么呢。
我们知道AMS运行在SystemServer进程,而要启动的Activity运行在APP进程,SystemServer进程要启动APP进程中的Activity就需要通过binder方式进行操作,这时AMS相当于Client,APP相当于Server,ApplicationThread就是AMS进程调用APP进程的桥梁。ApplicationThread是在APP进程启动的时候创建的。
上面已经知道AMS.startProcessLocked会创建APP进程:
startProcessLocked
startProcessLocked中会调用Process.start来创建APP进程,
Process.start
Process.start最终通过Zygote来创建进程,并运行进程的入口类ActivityThread.main函数。ApplicationThread就是在这里创建的。
ActivityThread.main
main函数里面给主线程创建了Looper对象,thread.attach将ApplicationThread对象传给了AMS。
ActivityThread.attach
mAppThread是ApplicationThread类型,mgr是AMS的本地代理,mgr.attachApplication将mAppThread传给AMS,这样AMS就可以和APP进程交互了。
ApplicationThread
ApplicationThread提供了众多方法,包启动Ativity Service等。
3、ApplicationThread.scheduleLaunchActivity
Activity的创建是在APP进程中完成的,scheduleLaunchActivity通过发送消息到H类型的Handler,最终调用了ActivityThread.performLaunchActivity
ActivityThread.performLaunchActivity
ActivityThread.performLaunchActivity完成Ativity实例的加载,和onCreate的调用。到这里,Activity就已经创建完成了。
文章一开始也提到启动插件Activity的两个问题。理解了Activity的启动过程后,我们可以通过如下方式来解决ActivityNotFound的问题。
1、在宿主APP的AndroidManifest.xml注册占坑Activity
2、Hook调ActivityThread的Instrumentation对象,当检测到startActivity启动的是插件Activity时,将目标Activity替换成宿主占坑的Activity,这样就绕过了ActivityNotFound问题。
3、hook调ActivityThread的mInstrumentation对象的newActivity函数,这样当发现启动的是宿主占坑Activity时,在将宿主占坑Activity换成插件Activity,ClassLoader加载的实际上是插件的Activity对象。
实际上VirtualApk就是这么做的。
宿主占坑Activity
宿主AndroidManifest.xml中配置了各种启动模式的占坑Activity。
PluginManager.hookInstrumentationAndHandler
PluginManager.hookInstrumentationAndHandler,hook掉APP进程的ActivityThread中的Instrumentation对象。
Instrumentation.execStartActivity
execStartActivity是ContextImpl.startActivity调用的第一个函数,VirtualApk通过hook这个函数,markIntentIfNeeded函数将启动插件的Intent转换成启动占坑的Activity。
转换Intent
dispatchStudActivity完成插件Activity和宿主Activity的转换。
调用员来mInstrumentation.execStartActivity
转换完成后就继续调用原来mInstrumentation对象的execStartActivity函数,继续调用AMS相关的方法。
newActivity
刚刚完成了狸猫换太子,绕过了ActivityNotFound的检测,在newActivity创建Activity对象的时候需要再换回来,也就是将宿主占坑Activity的调用换回到实际插件Activity的加载。
callActivityOnCreate
newActivity加载完插件Activity会调用callActivityOnCreate,但此时插件Activity对象的resource资源、context都是宿主的,hook调callActivityOnCreate可以自己设置插件的Resources Context等信息。
到这里就解决了加载插件的第一个问题(ActivityNotFound),那么这样创建的Activity具有生命周期么?能够响应onPause onResume等生命周期方法么?
答案是肯定的,我们以onPause方法为例。
当要调用Activity.onPause时,调用流程如下:AMS.activityPause-->ActivityStack.activityPausedLocked-->....ApplicationThread.schedulePauseActivity-->ActivityThread.handlePauseActivity-->ActivityThread.performPauseActivity
ActivityThread.performPauseActivity
ActivityThread.performPauseActivity根据token来查找要pause的Activity,那么这个token是哪里来的呢?
ActivityThread.performLaunchActivity
跟踪代码发现ActivityThread.performLaunchActivity在创建Activity对象的时候做了mActivities的保存。r.token也就是ActiviyClientRecord中的token对象,是AMS传过来的,该token和Activity类名无关,只要能找到token和Activity对应关系即可。因此不影响Activity的生命周期。
至此,就解决了启动插件Activity的两个问题。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。