一种对抗AndroidNativeEmu的方法

一、目标
最近在模拟执行某个so的时候发现了一个奇怪的错误，在执行到call_object_method的时候失败，仔细看了一下，发现这个so首先获取了 Activity类的getPackageManager方法 的jmethodID，然后用一个 Application类 的对象去调用这个jmethodID。

简单的解释就是 A类的对象中调用B类的方法?

二、分析
猜测是这样的: Application和Activity类中都有getPackageManager方法，而且功能都是一样的，所以为了优雅，google工程师就把这两个jmethodID的地址设置成一样的，这样造成了Application类的对象可以调用Activity类的getPackageManager。

这个猜测是不对的，jmethodID相同的真实原因是 ： Application 和 Activity 都是 ContextWrapper 的子类， getPackageManager 是 ContextWrapper 里的方法，获取的两个 jmethodid 自然是一样的。 感谢@葫芦娃

我们赶紧证明一下：

好了，现在我们只要拿到Application的对象，然后也去调用Activity类的getPackageManager，跑到这个call_object_method，

AndroidNativeEmu就罢工了。

三、总结
开动脑筋，神奇的抵抗方式总是有的……

硬广一下， 奋飞的朋友们 的知识星球里有 全网唯一一个AndroidNativeEmu实操教程。 ε=ε=┌( >_<)┘