[Q] 新启动的process是如何hook的？

[huanglongyu]

在 @tiann 的doc中，占坑用的activity是没有添加process标签，所以插件和宿主在同一个process，是相同的ActivityThread，能做hook操作。
但是在Droidplug里面占坑用的activity都是有process标签的，通过zygote fork的process是如何对ActivityThread进行hook的呢？

从Droidplug源码里面看在PluginProcessManager.preLoadApk的方法里面，有注释
/添加插件的LoadedApk对象到ActivityThread.mPackages/

但是源码只是替换了插件loadedApk的mClassLoader对象，并没有添加到mPackages中
在handleLaunchActivity后是如何命中的呢？

@cmzy @tiann

能否解答一下疑问~ 谢谢

[tiann]

第一个问题，所有进程启动都会走Application的生命周期；从Zygote出来的进程最终还是调用了ActivityThread的main函数，又通过Binder调用到了AMS的bindApplication；从而完成了进程的启动，你可以仔细看看。
第二个问题，PluginProcessManager你看的那个注释上面不是有：/添加插件的LoadedApk对象到ActivityThread.mPackages/么？

Hook的方式多种多样，不要觉得一定要怎么怎么做才能达到目的；当时分析的是一年前DP的版本，不排除现在有很多改进；文章只是思路，不要被局限了。

[huanglongyu]

感谢回答。

对于第一个问题，我可能没有说得很清楚。
虽然从zygote fork出来的进程会走到ActivityThread，但是这个ActivityThread是一个全新的ActivityThread，因为是重新fork出来的，还没有被hook，被hook的那个是宿主进程中的ActvityThread. 所以我按照你doc中的实现后，在把占坑用的activity标签加process标签后无法hook。

之所以我会添加process标签是因为droidplug里面的acitivity又是都加了process的标签，却任然可以hook住，所以这一点上让我特别疑惑。
查看droidplug的源码后发现前面和你所说流程基本相同，只是在欺骗AMS后替换回来的方式有一点不同。droidplug只是在PluginProcessManager里面只是设置了bundle的classloader。难道这是这样就可以加载插件中的class了？

[tiann]

是全新的ActivityThread没错，但是这个全新的ActivityThread会去调用一个全新Application的attachBaseContext，onCreate等方法，在这些方法里面做了手脚，于是这个全新的进程也被劫持了。

为什么要关注相不相同呢？条条大路通罗马，作者是这么做的，不是说就一定应该是这样的。我只是以一种当时看起来比较简单的方式表达作者的思路，如果你觉得插件化就应该是咋样咋样的，那我就白写了。

[huanglongyu]

第一个问题了解了
在ActivityThread的attch方法里面重新做了makeApplication
mInitialApplication = context.mPackageInfo.makeApplication(true, null); mInitialApplication.onCreate();
这个application就是宿主的Application对象，重新实例化一次后就重做了一些hook操作。

当然同意条条大路通罗马，只是看到在最后一步有点不一样觉得不会成功，但是却成功了后有点疑惑。仅此而已。;)