android AMS原理解析

最新推荐文章于 2024-10-07 00:14:56 发布

inquisiter

最新推荐文章于 2024-10-07 00:14:56 发布

阅读量758

点赞数

分类专栏：日常笔记android

本文链接：https://blog.csdn.net/bme314/article/details/112481406

版权

日常笔记android 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

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方式直接个里启动新内核，产生的兼容问题将会小的多。