android插件化欺骗AMS

反射到ActivityManagerNative—gDefault-----Singleton—mInstance ,因为mInstance是ActivityManager类型的，而ActivityManage是接口类型，所以动态构造代理替换startActivty实现目标Activity替换stubactivity绕过 AMS对activity得检查。

通过反射currentThread一路反射H类，反射hook mH父类Handler接口callback handleMessage，在其中的handleLunachactivity中替换回目标Activity，然后启动。

最后是绕过安装检测不说了。

反射目测只能hook接口类中的函数，或是直接替换字段。

virtualapp

我这里总结者个其实是为研究virtualapp的实现机制，研究了下发现后半部分和以上实现类似，但在前半部分替换singleton出现了差异。
这里先说下这个架构里的反射模块。

笔走龙蛇的反射hook

整个反射可谓被搞的完全变了样，
我们这里以ActivityManagerStub为例说明下，

1.类实现
public class ActivityManagerStub extends MethodInvocationProxy

核心类和接口实现如图，addMethodProxy 通过两层重载，维护了一个叫做mInteralMethodProxies的Map映射，来添加对函数的hook或替换。
这里重点来了，我们怎么确定实现的是按个类里的hook。

这里我们看ActivityManagerStub构造函数
public ActivityManagerStub(){
super(new MethodInvocationStub<>(ActivityManagerNative.getDefault.call()))
}
这里是通过反射得到default构建见一个MethodInvocationStub类，而这个类里恰好是对传入参数的代理构造。也就是说我们实现了参数类的hook。

2. 利用方式
   
   还是以ActivityManagerStub说明，在构造类default的代理后，我们通过MethodInvocationProxy里重载的addMethodProxy添加需要hook的函数。完成AMS的服务的欺骗。

3. 问题
   问题是替换activities的操作不在这里，尴尬了。

实现自己的启动流程

如图，virtualApp实现了自己的AMS管理流程，只在最后hook了ActivityThreadH替换了下。估计是考虑到Android系统兼容性问题。