Android 双开沙箱 VirtualApp 源码分析(四)启动插件 Service

本文是Android双开沙箱VirtualApp源码分析第四篇,聚焦启动插件Service。先介绍原生Service创建过程,指出在VA中可绕过AMS,直接调用ApplicationThread方法。接着阐述startService实现,包括Hook、业务交予VAMS,跳过AMS创建Service等,还提及bindService调用方式。

Android 双开沙箱 VirtualApp 源码分析(四)启动插件 Service

原生 Service 创建过程

首先有必要了解一下原生 framework 对 Service 的创建,因为在 VA 中启动 Service 和 Activity 有很大的区别。

首先入口 ContextWrapper.startService():

@Override
    public ComponentName startService(Intent service) {
        return mBase.startService(service);
    }

mBase 是 ContextImpl,所以调用到 ContextImpl.startService():

 @Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, mUser);
    }
    private ComponentName startServiceCommon(Intent service, UserHandle user) {
        try {
            validateServiceIntent(service);
            service.prepareToLeaveProcess(this);
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                            getContentResolver()), getOpPackageName(), user.getIdentifier());
            if (cn != null) {
                if (cn.getPackageName().equals("!")) {
                    throw new SecurityException(
                            "Not allowed to start service " + service
                            + " without permission " + cn.getClassName());
                } else if (cn.getPackageName().equals("!!")) {
                    throw new SecurityException(
                            "Unable to start service " + service
                            + ": " + cn.getClassName());
                }
            }
            return cn;
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
    }

Client 的流程最后到 ActivityManagerNative.startService():

public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
            String resolvedType, IBinder resultTo, String resultWho, int requestCode,
            int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeStrongBinder(caller != null ? caller.asBinder() : null);
        data.writeString(callingPackage);
        intent.writeToParcel(data, 0);
        data.writeString(resolvedType);
        data.writeStrongBinder(resultTo);
        data.writeString(resultWho);
        data.writeInt(requestCode);
        data.writeInt(startFlags);
        if (profilerInfo != null) {
            data.writeInt(1);
            profilerInfo.writeToParcel(data, Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
        } else {
            data.writeInt(0);
        }
        if (options != null) {
            data.writeInt(1);
            options.writeToParcel(data, 0);
        } else {
            data.writeInt(0);
        }
        // 远程调用 AMS
        mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);
        reply.readException();
        int result = reply.readInt();
        reply.recycle();
        data.recycle();
        return result;
    }

不出所料,逻辑再一次转移到远程的 AMS 中,然后我们先忽略 AMS 中的一堆逻辑,最后 AMS 调用到这:

    private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            sendServiceArgsLocked(r, execInFg, true);
    }

这里的 ProcessRecoder.thread 是 AMS 持有的 Client App 的 IBinder 句柄,通过他可以远程调用到 Client App 的 ApplicationThread 中的 scheduleCreateService 方法:

public final void scheduleCreateService(IBinder token,
                ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
            updateProcessState(processState, false);
            CreateServiceData s = new CreateServiceData();
            s.token = token;
            s.info = info;
            s.compatInfo = compatInfo;

            sendMessage(H.CREATE_SERVICE, s);
        }

这里大家可能发现了,Intent 在 AMS 绕了一圈又回来了,事实上 AMS 在其中好像没有发挥什么作用,其实在外部环境 AMS 还是很重要的,但是在 VA 中,AMS 在 Service 调度中其实没有发挥什么作用。原因有以下几点:

  1. 首先 VA 内部的插件 Service 没有比较暴露给外部 App 调用,所以让 AMS 知晓 Service 的意义不大。
  2. 其次和 Activity 必须有个 StubActivity 让 AMS 持有不一样,Service 生命周期和功能都极其简单,并且没有界面,没有交互,换句话说 Service 和其他 Framework Service(例如 WMS) 没有任何关系,所以其实并不需要 AMS 这一步存在。

那么综上所诉,为了启动插件 Service 我们其实可以绕过 AMS,直接调用 ApplicationThread 中的 scheduleCreateService 方法,Service 的会话储存交给 VAMS 就行。

startService 的实现

和 startActivity 一样,首先是 Hook:

static class StartService extends MethodProxy {

        @Override
        public String getMethodName() {
            return "startService";
        }

        @Override
        public Object call(Object who, Method method, Object... args) throws Throwable {
            IInterface appThread = (IInterface) args[0];
            Intent service = (Intent) args[1];
            String resolvedType = (String) args[2];
            if (service.getComponent() != null
                    && getHostPkg().equals(service.getComponent().getPackageName())) {
                // for server process
                return method.invoke(who, args);
            }
            int userId = VUserHandle.myUserId();
            // 如果是内部请求,获取原来的 Service
            if (service.getBooleanExtra("_VA_|_from_inner_", false)) {
                userId = service.getIntExtra("_VA_|_user_id_", userId);
                service = service.getParcelableExtra("_VA_|_intent_");
            } else {
                if (isServerProcess()) {
                    userId = service.getIntExtra("_VA_|_user_id_", VUserHandle.USER_NULL);
                }
            }
            service.setDataAndType(service.getData(), resolvedType);
            ServiceInfo serviceInfo = VirtualCore.get().resolveServiceInfo(service, VUserHandle.myUserId());

            if (serviceInfo != null) {
                // 远程调用 VAMS.startService()
                return VActivityManager.get().startService(appThread, service, resolvedType, userId);
            }
            return method.invoke(who, args);
        }

        @Override
        public boolean isEnable() {
            return isAppProcess() || isServerProcess();
        }
    }

和 startActivity 一样将真正业务交给 VAMS.startService():

 private ComponentName startServiceCommon(Intent service,
                                             boolean scheduleServiceArgs, int userId) {
        ServiceInfo serviceInfo = resolveServiceInfo(service, userId);
        if (serviceInfo == null) {
            return null;
        }
        ProcessRecord targetApp = startProcessIfNeedLocked(ComponentUtils.getProcessName(serviceInfo),
                userId,
                serviceInfo.packageName);

        if (targetApp == null) {
            VLog.e(TAG, "Unable to start new Process for : " + ComponentUtils.toComponentName(serviceInfo));
            return null;
        }
        IInterface appThread = targetApp.appThread;
        ServiceRecord r = findRecordLocked(userId, serviceInfo);
        boolean needCreateService = false;
        if (r == null) {
            r = new ServiceRecord();
            r.name = new ComponentName(serviceInfo.packageName, serviceInfo.name);
            r.startId = 0;
            r.activeSince = SystemClock.elapsedRealtime();
            r.process = targetApp;
            r.serviceInfo = serviceInfo;
            needCreateService = true;
        } else {
            if (r.process == null) {
                r.process = targetApp;
                needCreateService = true;
            }
        }

        // 如果 service 尚未创建
        if (needCreateService) {
            try {
                // 调用 ApplicationThread.scheduleCreateService 直接创建 Service
                IApplicationThreadCompat.scheduleCreateService(appThread, r, r.serviceInfo, 0);
            } catch (RemoteException e) {
                e.printStackTrace();
            }

            // Note: If the service has been called for not AUTO_CREATE binding, the corresponding
            // ServiceRecord is already in mHistory, so we use Set to replace List to avoid add
            // ServiceRecord twice
            // 将 ServiceRecorder 推入 history
            addRecord(r);

            // 等待 bindService,如果是通过 bindService 自动创建的 Service,在创建 Service 完成后会进入 bindService 流程
            requestServiceBindingsLocked(r);
        }

        r.lastActivityTime = SystemClock.uptimeMillis();
        if (scheduleServiceArgs) {
            r.startId++;
            boolean taskRemoved = serviceInfo.applicationInfo != null
                    && serviceInfo.applicationInfo.targetSdkVersion < Build.VERSION_CODES.ECLAIR;
            try {
                IApplicationThreadCompat.scheduleServiceArgs(appThread, r, taskRemoved, r.startId, 0, service);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }
        return ComponentUtils.toComponentName(serviceInfo);
    }

这里主要做了以下几个工作:

  1. 和 Activity 创建的时候一样,调用 startProcessIfNeedLocked 检查 Application 是否初始化,没有则开始初始化 Application 流程。
  2. 准备 ServiceRecord 和 ServiceInfo。
  3. 如果 service 还没有创建,则直接调用 ApplicationThread.scheduleCreateService 创建 Service,可以看出这里直接跳过了 AMS。
  4. 将 ServiceRecord 记录到 Service 列表,等待 bindService,如果是通过 bindService 自动创建的 Service,在创建 Service 完成后会进入 bindService 流程。

同样的 bindService 也是直接调用系统的 ApplicationThread.scheduleBindService

好了,由于 Service 的特点,startService 看上去比 startActivity 简单多了。接下来要分析的是 BroacastReceiver。

转载:https://blog.csdn.net/ganyao939543405/article/details/76208729

内容概要:本文提出了一种基于瞬态三角哈里斯鹰算法(TTHHO)的多无人机协同集群在三维空间中的避障路径规划方法,旨在通过优化路径长度、飞行高度、威胁规避和转弯角度等关键因素,实现以最低综合成本为目标的全局路径规划。该方法结合智能优化算法与多智能体协同机制,在复杂三维环境中有效解决动态障碍物规避与飞行安全性问题,并通过Matlab平台进行算法编码实现与仿真实验,验证了其在路径最优性、收敛速度和避障能力方面的优越性能。研究涵盖了三维空间建模、目标函数构建、约束条件处理及多无人机协同策略设计,提升了无人机系统在实际应用场景中的自主导航与智能化决策水平。; 适合人群:具备一定编程基础,熟练掌握Matlab仿真环境,从事无人机路径规划、智能优化算法、多智能体协同控制等相关方向研究的科研人员、工程技术人员及研究生。; 使用场景及目标:① 实现多无人机在复杂三维环境下的协同避障路径规划,确保飞行安全与任务效率;② 研究基于哈里斯鹰算法及其改进版本(如TTHHO)的智能优化机制在路径规划中的应用;③ 推动多目标优化(路径最短、能耗最低、威胁最小、飞行平稳)下无人机自主导航系统的开发与落地; 阅读建议:此资源以Matlab代码实现为核心支撑,建议读者深入理解TTHHO算法原理的基础上,结合文中提供的仿真模型进行代码调试与参数调优,进一步探索不同环境设置和约束条件下算法的适应性与鲁棒性,鼓励通过扩展威胁模型或引入通信延迟等现实因素开展深化研究。
内容概要:本文档聚焦于“三相并网逆变器虚拟阻抗+统一有源阻尼策略SVPWM+SPWM调制仿真”这一核心技术主题,系统研究了在三相并网逆变系统中引入虚拟阻抗与统一有源阻尼的控制策略,旨在提升系统在弱电网条件下的稳定性、动态响应能力及并网电能质量。通过Simulink仿真平台,详细构建了包含SVPWM(空间矢量脉宽调制)与SPWM(正弦脉宽调制)两种主流调制方式的控制系统模型,深入对比分析了不同调制策略对系统性能的影响,并验证了所提出策略在抑制LC谐振、降低电流畸变、增强系统鲁棒性方面的有效性。文档还整合了大量电力电子与新能源领域的相关仿真研究案例,涵盖光伏逆变、储能控制、微电网调度、VSG控制等多个方向,展现出丰富的技术内涵和扎实的工程应用背景。; 适合人群:适用于具备电力电子技术、自动控制理论及新能源发电系统等相关专业知识背景的科研人员、电气工程类研究生以及从事并网逆变器、微电网控制、电力系统仿真等方向的工程技术人员。; 使用场景及目标:① 深入理解并掌握虚拟阻抗与统一有源阻尼技术在三相并网逆变器中的设计原理与实现方法;② 对比分析SVPWM与SPWM调制策略在系统稳定性、谐波抑制和动态性能上的差异;③ 基于Simulink平台进行逆变器并网控制算法的建模、仿真与验证,服务于高水平科研项目、学位论文撰写或实际工程项目开发。; 阅读建议:建议读者结合文档中提及的Simulink仿真模型及相关代码资源,亲自动手搭建和调试核心控制回路,重点关注虚拟阻抗的参数整定、电流内环与电压外环的协同控制结构、以及SVPWM/SPWM调制模块的具体实现细节,从而深化对系统稳定机理和高性能控制策略的理解。
内容概要:抠图王是一款基于AI技术的智能图片处理工具,核心功能包括一键智能抠图、制作商品白底图、处理人像抠图、移除图片水印、生成标准证件照、修复老照片画质、输出透明PNG图、去彩边净化边缘以及批量处理商品图等。软件通过先进的深度学习模型精准识别主体边缘,实现高效、精准的图像分割与后续处理。 适用人群:本软件广泛适用于电商卖家、摄影师、平面设计师、社交媒体运营者、普通家庭用户以及需要经常处理图片的办公人员。无论是专业设计还是日常修图,都能从中获得便利。 使用场景及目标:典型使用场景包括电商卖家快速制作统一风格的商品图和详情页主图;摄影爱好者移除照片中的路人或杂物,获得干净的人像作品;家庭用户修复泛黄模糊的老照片,保留珍贵回忆;个人用户制作证件照或社交头像,去除图片中的水印等。通过一键式操作,大幅缩短图像处理时间,提升工作效率,使用户无需具备专业技能即可获得专业效果。 其他说明:软件支持Windows操作系统,提供绿色免安装版本,下载后即可直接运行。核心图像处理过程在本地内存中完成,不长期保存图片文件,保护用户隐私。部分功能需要联网进行AI推理,但用户数据不会上传至服务器,确保安全。软件界面简洁,操作直观,适合各类用户快速上手。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值