本发明涉及计算机虚拟化技术领域，具体是指一种多系统虚拟化的移动设备。
背景技术：
随着个人电脑市场的成熟饱和，个人计算机已经进入到后pc时代，这一时代的重要特点就是移动计算设备的普及，而在智能手机的操作系统中，android系统装机量最高，占据了80％左右的市场，android系统平台独特的优势在于其开放性，但是许多恶意软件厂商利用android系统的开放性特点，利用漏洞制造了很多恶意应用软件，对客户的个人隐私信息以及财产安全造成了威胁，为解决这一问题，最大限度的保护用户的个人信息，提出了android虚拟化来解决这一问题，android虚拟化是指在在一台android设备上运行多个android操作系统，这些操作系统相互之间隔离，安装在一个系统中的应用软件以及数据不对其他系统造成影响，这样就可以将用户的个人信息封锁在某一个系统中，即使其他系统中安装了恶意软件也不会对个人信息构成威胁。
计算机经过多年的发展，软件和硬件种类越来越多，整个系统也越来越难管理，于是虚拟化技术出现，虚拟化技术是对计算机系统进行了抽象，即加入了虚拟化层，该层将计算机系统的硬件资源进行管理然后向上层提供统一的接口，加入虚拟化技术后，不同系统之间的硬件差异被屏蔽，比如安装的操作系统可以不用关心真正的处理器指令集，按照自己系统的方式执行后由虚拟层转换，即上层软件可以直接运行在相应的虚拟平台上，虚拟化技术的引入，打破了计算机系统中软硬件紧密耦合的关系，为计算机带来了新的活力，解决了许多问题，计算机本身采用了分层结构，所以目前虚拟化技术解决方案可以在不同层次上实现，不同的实现方式和抽象层次，虚拟化有不同的特性，从实现的技术上主要分为四种，指令级虚拟化，硬件级虚拟化，操作系统级虚拟化和编程语言级虚拟化。
计算机的虚拟化技术已经日趋成熟，但是手机上的虚拟化技术还很欠缺，目前市面上并没有专门的双系统或者多系统的android手机。
android系统一般都运行在智能手机平台上，有时会运行在更小的嵌入式平台上，与通用的pc虚拟化或者服务器虚拟化相比，面临着许多问题，主要体现在下面几个方面：
(1)内存资源限制
android系统运行的硬件平台资源有限，比如智能手机的内存为2g，如果虚拟化的两个操作系统平均每个操作系统只能得到1g内存，还要保障通话和短信这些实时性较高的应用正常运行，如何高效使用内存是android系统虚拟化必须要考虑的问题。
(2)计算处理能力有限
与个人电脑和服务器通常采用的intel处理器不同，intelx86设计的目标是性能优先，而android运行的硬件一般为arm架构处理器，为了降低功耗，arm架构的计算机处理能力比x86弱，虚拟化需要保证多个android系统中的应用程序能够流畅运行。
(3)设备功耗限制
智能手机都用锂电池供电，需要采用有效的手段进行电源管理，android系统本身具有电源管理模块，比如待机的时候关闭不再使用的设备，无触屏按键操作超时后关闭背光等，如果采用的虚拟化技术加入vmm层，则vmm需要管理客户操作系统android系统，原有的电源管理不再适用，vmm即使有电源管理，需要针对android内部机制进行特别设计，会比较复杂。
(4)android设备的多样性
android设备种类繁多，主要包括智能手机和平板电脑，但每个硬件厂商都会针对自己产品的特点做特殊的硬件配置，所以每个设备都有自己定制修改的android系统，android系统虚拟化需要整合各个系统的差异性。
对于不同层面上的android虚拟化也存在许多问题：
指令级虚拟化需要模拟每一条指令的执行，指令翻译非常占用cpu计算资源，会导致系统运行不顺畅，比如bochs系统，能够模拟大多数版本的x86系统，从加电开机到定制的外围设备启动都能模拟，但是效率非常低。
硬件级虚拟化需要硬件cpu的支持，目前android系统主要运行在arm平台上，在arm系列cpu中，目前支持硬件辅助虚拟化的是cortex-a15架构，该系列cpu在android移动设备还不够广泛，硬件级虚拟化一般需要加入vmm管理层，比如xen虚拟化中的hypervisor层，对于虚拟化android的设备来说多一个管理层需要更多的内存和cpu，所以硬件级虚拟化也不是最佳的android虚拟化方案。
编程语言级虚拟化已经在android系统中使用，android运行的apk包一般就是java编写的，虽然针对每个用户程序使用了dalvik虚拟机，但是还是无法解决恶意应用程序直接读取通讯录或通话记录的问题。
技术实现要素：
本发明要解决的技术问题是，针对以上问题提供一种能够有效执行双系统，并且互不干扰的设备。
为解决上述技术问题，本发明提供的技术方案为：一种多系统虚拟化的移动设备，包括采用系统级虚拟化技术对android手机进行虚拟化操作，设计一个特殊的多系统的android手机，用于实现在android系统的手机上可以运行两个系统，所述的多系统手机上不仅能实现不同系统之间的输入输出之间互不影响，所述的输入输出之间互不影响包括键盘输入以及屏幕复用，还要保证多个系统之间的通话能够互相区别和正常进行。
本发明与现有技术相比的优点在于：与宿主机使用同一个内核，性能损耗小，不需要指令级模拟，不需要即时(just-in-time)编译，容器可以在cpu核心的本地运行指令，不需要任何专门的解释机制，避免了准虚拟化和系统调用替换中的负载性，轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享。
作为改进，修改宿主机内核以适配客户机的正常运行。
作为改进，通过过滤输入事件对客户机的输入功能进行修改。
作为改进，对客户机的输出事件进行过滤实现屏幕复用。
作为改进，对内核binder进行修改保证宿主机和客户机正常通信。
附图说明
图1是多系统虚拟化android机的整体流程图。
图2是本发明一个实施例的架构图。
图3是输入系统结构图。
图4是eventhub::getevents()函数的流程图。
图5是android显示模块的图形显示流程图。
图6是修改后的binder驱动架构图。
图7是服务名过滤转换流程图。
具体实施方式
下面结合附图对本发明做进一步的详细说明。
本发明在具体实施时，对客户机和宿主机输入切换的设计技术方案如下：首先在宿主机和客户机的容器中均运行输入模块的各个组件，这样每个容器都能从输入设备中读取到输入事件；然后在输入事件的传递路径上添加一个过滤器，由过滤器根据当前容器的状态来对输入事件进行过滤，如果当前容器在前台，那么事件通过过滤器继续传递，否则事件将被抛弃。通过输入的修改，可以实现多系统android机输入之间互不影响，在当前系统中从键盘输入。
实现屏幕复用的技术方案思路如下：在输出事件的传递路径上添加一个过滤器，由过滤器根据当前容器的状态来对输出事件进行过滤，如果当前容器在前台，那么事件通过过滤器继续传递，否则事件将被抛弃。
对binder修改的技术方案思路如下：在基于lxc的android虚拟化中，客户机与宿主机系统使用同一个linux内核，而binder驱动属于linux内核，即两个android系统都会使用binder驱动，但是android系统中binder驱动实现的时候未考虑多个系统使用的情况，如果直接让多个系统访问，原生的binder驱动只能注册一个android宿主机的servicemanager，即句柄为0的标号，其他android客户机如果再以0号句柄进行注册就会失败，如果以其他句柄号注册则无法表示为servicemanager，所以宿主机和客户机系统只能够通过binder驱动注册一个servicemanager。如果整个系统中只存在一个servicemanager，客户机和宿主机中的服务都会注册到该servicemanager中，但是宿主机和客户机中很多服务名字是相同的，注册时会产生冲突，导致后续的服务无法注册或者servicemanager无法区分这些服务是来自哪个android系统，如哪些服务属于客户机，哪些服务属于宿主机，所以要对binder驱动中将不同android系统的服务进行区分。对通信子系统修改的思路是在客户机和宿主机中创建分别创建一个特殊标识的文件，在服务请求的时候会根据特殊的标识来辨别不同的android系统，进而实现两者之间的通信互不影响，并且能够正常进行。
实施例：设计多系统虚拟化android真机需要对android手机的内核进行修改以适配客户机，本发明实施进行操作的android系统版本为android4.3，内核版本为3.4版本。
图2为本发明一个实施例整体的架构图，当前实施例中包括一个宿主机和一个客户机，在宿主机内部署lxc工具，通过lxc工具创建一个linux环境的容器，在该容器中创建android系统的客户机。
在对android内核编译的时候需要开启内核的相关配置来适配客户机的部署，在linux/arm3.4.0kernelconfiguration中开启generalsetup的posixmessagequeues、namespacesupport以及controlgroupsupport中排除memoryresourcecontrollerforcontrolgroups之外的其他选项，开启devicedrivers中的characterdevices选项，将编译好的内核刷入手机中。
由于android系统不支持lxc工具，需要将lxc工具进行交叉编译，将交叉编译好的lxc文件拷贝到android手机中，执行lxc-execute命令，创建一个容器，在此运行客户机。
成功启动android客户机后需要对客户机进行事件子系统、显示子系统、通信子系统进行修改，以确保宿主机和客户机完全隔离，相互不影响。
对事件子系统的修改即修改客户机的输入功能。
由于宿主机与客户机使用同一套linux内核，多个输入设备，如触摸屏、按键灯，会被两个系统所公用，每个输入设备的事件都会发送到所有的android系统中，但是对于虚拟化后的多个android，在同一个时刻运行在前台的系统只有一个，输入设备的事件消息只需要运行在前台的android系统处理就可以，android系统是通过读取linux输入设备文件来获取输入的信息事件，这些设备文件位于/dev/input目录下，比如键盘设备对应的是event2，图3为输入系统结构图。
输入事件的传递路径中的组件包括输入设备、输入设备驱动、eventhub、inputreader、inputdispatcher、inputmanager和应用程序，其中输入设备和输入设备驱动由客户机和宿主机共享，不宜在其中修改代码针对宿主机和客户机做不同处理，选择的组件越底层效率越高，因为所有容器中处于过滤器所在组件下层的组件都必须对输入事件进行处理，将过滤器设置在层次越低的组件，需要处理输入事件的总组件数越少，从输入系统的结构图中得知android系统输入操作交给上层应用程序前是由windowsmanagerservice服务处理，该服务收到的信息来自于下一层eventhub模块，它实现了input输入设备驱动的控制，并从中获取输入操作事件和信号，所以选择eventhub作为修改对象。
eventhub负责从输入设备中读取输入事件并对其进行包装然后传递到上层，其实例对象由nativeinputmanager在构造时创建，然后该实例被传递给inputreader，由后者进行管理，inputreader在其线程的主函数中调用eventhub的getevents()来获取事件，eventhub的主要逻辑都位于该函数中，如图4为eventhub：：getevents()函数的流程图，自定义一个输入事件过滤函数将其添加在eventhub：：getevents()函数中，过滤的具体操作为调用libcontainer提供的接口iscurrentcontainerinfront()判断当前容器是否在前台，如果是则对事件进行正常处理，不是则跳过该事件直接处理下一条事件请求，这样就可以实现宿主机和客户机输入的相互隔离。
对显示子系统的修改是为了实现屏幕的复用。
android系统显示模块的图形显示流程如图5，整个流程可以分为两个步骤：绘图和合成。绘图是指各个应用程序绘制其视图组件的过程，绘图的最终结果是应用程序的各个视图都在对应的图形缓冲区上渲染出需要绘制的图像，首先应用程序调用绘图api提供绘图操作，此时surfaceflinger调用gralloc的alloc模块分配一块图形缓冲区，应用程序获取到该缓冲区之后将使用2d或3d的图形库将需要绘制的图形渲染到这块缓冲区上，合成则是surfaceflinger将各个绘制好的视图合成最终屏幕显示图像的过程，surfaceflinger获取到应用程序提交的图形缓冲区后，会请求windowmanager提供这些图形缓冲区对应的视图的参数，然后根据窗口参数计算出各个视图最终在屏幕上的显示区域，从而将所有视图合成为一块完整的屏幕显示帧，合成时各个视图的裁剪、放缩、变形和消隐均由windowmanager提供的参数控制，合成过程使用硬件辅助。
通过对android系统的代码分析，其中显示输出相关的代码在surfaceflinger服务中，所以在该代码中添加一个自定义的输出事件过滤函数，当surfaceflinger服务响应的时候，该代码会判断当前容器是否在前台，如果是则对事件进行正常处理，如果不是则跳过该事件直接处理下一条事件请求，这样就可以实现宿主机和客户机屏幕的复用。
对通信子系统即binder进行修改以确保客户机能够正常通信。
图6为修改后的binder驱动架构，在新的驱动架构中，在宿主机和客户机中分别创建一个特殊的文件来区分表示不同的两个系统，比如在宿主机中该文件存储标识1，在客户机中该文件存储标识0，当服务的注册和服务的请求消息传到binder驱动时，binder驱动会读取该系统中的特殊文件，并将特殊标识标识到该服务名中，这样就可以区分该服务是来自客户机还是宿主机，之后判断当前容器是否在前台，如果是则继续向下执行，如果不是则将该服务过滤掉，不执行该服务。
服务名过滤转换的流程如图7，在整个系统中只启用了一个servicemanager服务，该服务在宿主的android系统中启动，管理了android宿主系统和android客户系统中的所有服务，在客户机与服务机中加入特殊的表示文件，使binder驱动能够区分来自上层的不同android系统的服务，将不同android系统中相同命名的服务进行区分，使得不同的android系统的服务能够正确的注册到servicemanager服务中，并且不同的android系统的客户端能够通过binder驱动获取自己系统中对应的服务，进而实现客户机和宿主机之间互不干扰的正常通信。
以上对本发明及其实施方式进行了描述，这种描述没有限制性，以上所示的也只是本发明的实施方式之一，实际的结构并不局限于此。总而言之如果本领域的普通技术人员受其启示，在不脱离本发明创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本发明的保护范围。