android AMS原理解析

startactivity

app启动过程

启动下半场，AMS返回后

部分结构继承关系

AMN策划AMS服务，AMS继承AMN实现具体细节

获取AMP

static public IActivityManager getDefault() {
        return gDefault.get();
    }
    private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");//1   AMS  binder引用
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);//2
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }+
    };
}

插件虚拟化

总结下以前研究过的virtualapp的原理，思路就是把apk按照插件的方式加载到自己virtualapp框架中，但启动插件的关键startActivity会在AMS检查xml文件当中是否声明了插件的名称，如果没有，就无法启动。但如果利用预留stubActivity到xml配置项中，并反射劫持AMS在startActivity过程的一些关键点，那我们就可以把我们真正启动的apk的名称换成stubActivity，直接按插件的形式启动apk。但这种方式需要分别劫持四大组件的启动过程，还要严格生成apk的声明周期，对不同版本的android系统适配来说是个不小的工作。但反观虚拟大师之类的虚拟攻击，采用了namespace方式直接个里启动新内核，产生的兼容问题将会小的多。