Android虚拟化技术方案技术评测

前言

在目前Android大环境下，虚拟化技术已经很普及。对于虚拟化的运行原理，网上文章已经有一大堆。本篇文章就从实测角度来对比一下各家虚拟化产品技术的差异。

本文涉及到Android的相关知识点，我尽量用自己理解的大白话去讲，如有不对请前辈们不吝赐教。

一些术语

简称全称解释宿主宿主原应用，即应用本身子应用子应用被运行的应用PMSPackageManagerServiceAndroid中的安装包管理服务AMSActivityManagerServiceAndroid中的应用活动的管理服务NMSNotificationManagerServiceAndroid中的应用通知管理服务

虚拟化是如何运作？

关于这个问题网上已经有N + 1的类似文章，这里有几篇可以参考一下

• [Android] 浅谈虚拟框架VirtualApp原理 & 检测方案
• Android 双开沙箱 VirtualApp 源码分析
• VirtualApp源码解析

通过原理分析，我们可以看出，完成虚拟化一个应用，要做的核心事情只有一件：在运行子应用时，欺骗系统让系统误以为正在运行的是宿主，否则系统会毫不犹豫的将你杀死！！

测试的切入点

首先此文章技术细节请教了这方面的大佬，再根据我自己对这方面的研究。现针对以下几个虚拟化“重灾区”进行检验一下，为什么会这样说呢，因为根据虚拟化的技术原理或多或少不可避免的需要对环境进行修改，这里就挑一些比较典型的点来对比各个框架之间对这些细节的处理。

参与对比的产品有（如有补充可以底下留言，我继续完善）
名称官网VirtualApphttps://github.com/asLody/VirtualAppLBE平行空间http://parallelspace-app.com/index_cn.phpSpaceCorehttps://spacecore.dev/360分身大师http://fenshen.360.cn双开助手https://www.multiopen.cn/
分别对比一下以下的点：
方法正常值Context#mBasePackageName自身包名Context#mOpPackageName自身包名ActivityThread.H#mCallbacknullActivityThread#mInstrumentationandroid.app.InstrumentationPMS检测android.os.BinderProxy@xxxx
测试所用的Demo是随便写的，目的就是读一下里面的对象其实很简单。
子应用包名：com.virtualchecker

检测

读取应用：Context#mBasePackageName中的值
产品期望值实际值Android系统com.virtualchecker✅ com.virtualcheckerVirtualAppcom.virtualchecker❌ io.busniess.vaLBEcom.virtualchecker❌ com.lbe.parallel.intl.arm64SpaceCorecom.virtualchecker✅ com.virtualchecker360分身大师com.virtualchecker✅ com.virtualchecker双开助手com.virtualchecker❌ com.exceliance.dualaid

读取应用：Context#mOpPackageName中的值
产品期望值实际值Android系统com.virtualchecker✅ com.virtualcheckerVirtualAppcom.virtualchecker❌ io.busniess.vaLBEcom.virtualchecker❌ com.lbe.parallel.intl.arm64SpaceCorecom.virtualchecker✅ com.virtualchecker360分身大师com.virtualchecker✅ com.virtualchecker双开助手com.virtualchecker❌ com.exceliance.dualaid

读取应用：ActivityThread#mInstrumentation
产品期望值实际值Android系统android.app.Instrumentation@✅ android.app.Instrumentation@bfcc1e8VirtualAppandroid.app.Instrumentation@❌ com.lody.virtual.client.h.a.c@fd146bfLBEandroid.app.Instrumentation@❌ com.doubleagent.client.e@a0aac44SpaceCoreandroid.app.Instrumentation@✅ android.app.Instrumentation@153bfc9360分身大师android.app.Instrumentation@❌ com.morgoo.droidplugin.hook.handle.PluginInstrumentation@8e8d100双开助手android.app.Instrumentation@❌ com.exceliance.kxqp.platform.c.b.e.wy@38e16ce

读取应用：ActivityThread.H#mCallback
产品期望值实际值Android系统nullnullVirtualAppnull❌ com.lody.virtual.client.h.d.d.b@800e4deLBEnull❌ com.lbe.doubleagent.client.LocalActivityService$ActivityThreadCallback@3f40957SpaceCorenull❌ com.fvbox.lib.client.hook.HCallbackHook@aa9ba7e360分身大师null❌ com.morgoo.droidplugin.hook.handle.e@91b7b06双开助手null❌ com.excelliance.kxqp.platform.c.b.e.wr@153bfc9

PMS检测
产品期望值实际值Android系统android.os.BinderProxy@✅ android.os.BinderProxy@eff05b8VirtualAppandroid.os.BinderProxy@❌ com.lody.virtual.client.h.a.c@993b1e1LBEandroid.os.BinderProxy@❌ com.lbe.doubleagent.client.hook.BinderProxy@f54e1feSpaceCoreandroid.os.BinderProxy@✅ android.os.BinderProxy@c846443360分身大师android.os.BinderProxy@❌ com.morgoo.droidplugin.hook.newsolution.BinderHook$BinderWrapper@cf8d1da双开助手android.os.BinderProxy@✅ android.os.BinderProxy@eff05b8

测试结果
产品mBasePackageNamemOpPackageNamemInstrumentationPMSH#mCallbackVirtualApp❌❌❌❌❌LBE❌❌❌❌❌SpaceCore✅✅✅✅❌360分身大师✅✅❌❌❌双开助手❌❌❌✅❌
以上测试仅仅是拿出一些关键点进行检测，展示各个框架的实测情况，唯一一点全部不通过的是ActivityThread.H#mCallback，其实这个地方并不是虚拟化才会用，很多Android上的黑科技都会用到，可以避免但是没必要为了这个牺牲掉兼容性。

结论

各个框架也浅浅的分析过一遍，其实大部分框架都有比较多的技术重合点，通过上方的测试可以看出，SpaceCore对应用的入侵是比较保守的，侧面反映了内部的处理逻辑更优，但具体实现细节未知。欢迎各位前辈指正，欢迎各位交流。

本文关键词：Android虚拟化, 多开框架, 虚拟引擎, VirtualApp, LBE, SpaceCore, 360分身大师, 双开助手, 360 DroidPlugin, VMOS, Android沙箱, 插件化