嵌入式虚拟化简化Android迁移

　　在不到18个月的时间里，Google Android平台已从一名“新生儿”成长为全球移动市场乃至移动领域之外其他智能设备领域内的重要成员。越来越多的手持设备开始部署Android平台，到2010年末，预计还会诞生数十种采用Android的手机设计，除此以外，Android在其他领域的应用也日益广泛。

　　Android平台具有两大吸引力：Android为OEM提供了一个功能丰富的开源移动 *** 作系统，让设备不仅做到“开箱即用”，而且能够支持第三方应用程序;Android Market应用程序商店中第三方应用程序的产品组合不断增加，拉升了对基于Android的设备的需求，同时为整个生态系统带来了新的商机。但另一方面，以Android为目标的设备硬件也为开发人员带来了一系列挑战：内核对CPU及SoC的支持、驱动程序开发、性能优化、与其他系统软件的整合等等。

　　本文将探讨这些难题，并着重讲述移动/嵌入式虚拟化如何能够帮助OEM及其他开发人员简化Android支持和迁移。特别地，本文将结合使用流行的Beagle Board与OKL4 Microvisor。此外，文中还将以安全VoIP作为应用示例，演示hypervisor技术如何帮助开发人员构建和部署更加稳健的Android设备及运行于其上的软件和服务。

　　在BeagleBoard及其他硬件上支持Android

　　Beagle Board (http://beagleboard.org)拥有非常活跃的开发人员社区，为Beagle Board硬件及在其上运行的软件提供支持。基于ARM Cortex-A8 CPU架构的TI OMAP3530亦受益于强大的开源社区和商业支持，从而使得该平台成为专业人士及业余爱好者的理想测试环境。

　　Android和Beagle Board汇集了应用广泛的软硬件技术，并且Android曾多次被移植到Beagle Board上，结果各不相同。特别是Open Kernel Labs(OK Labs)团队发现了一系列的问题，如驱动程序支持有限、稳定性不够高、内核频繁紊乱或完全无法启动。这些故障不一定表明软硬件平台本身存在问题，而是由于Android项目迅速发展和研发精力分散所造成的。

　　使用虚拟化作为迁移工具

　　在企业数据中心和桌面领域，虚拟化的应用越来越普遍，其支持的使用案例和应用数不胜数，其中包括硬件整合、负载平衡、安全和沙箱、配置、多 *** 作系统支持、交叉开发和旧软件迁移等。在嵌入式特别是移动应用领域，虚拟化在开发和部署方面的应用亦日益广泛。OK Labs公司为移动手持设备制造商(OEM)提供“microvisor”──OKL4，用于在某些情况下实现有些特殊的镜像服务器及桌面虚拟化应用，如CPU整合、多核支持、安全分区和固件升级，支持多 *** 作系统(实时 *** 作系统和应用 *** 作系统，如Android、Linux和Symbian等)，以及嵌入式/移动平台迁移。将microvisor(基于微内核的嵌入式hypervisor)引入到现有设计中时绝不可影响该项设计的具体细节。microvisor应该隔离新旧的子系统，但同时让其能够像在原始环境中那样使用现有软件组件(例如Android)，从而赋予系统设计人员灵活性。基于这一理念，一个结构良好的microvisor环境应支持简单且直接的迁移流程：

　　1.Microvisor与目标硬件的集成

　　在Beagle Board与OKL4的搭配中，OKL4 Microvisor已支持大多数常用的嵌入式/移动CPU，其中包括TI OMAP3530，使集成更加方便。

　　2.Android与Microvisor的集成

　　对于集成了虚拟化支持(如Intel VT和AMD-V)的企业和桌面系统，对重要资源(如中断控制、MMU和高速缓存配置)的访问限制是通过硬件机制实现的。由于缺乏这些构件，Android(或其他“客户” *** 作系统)必须进行“准虚拟化”，即通过修改让microvisor拦截并重新实现此类 *** 作。为简化Android支持，OK Labs提供了一种现成的Android准虚拟化实现──OK:Android。

　　3.设备驱动程序迁移

　　显然，应用平台必须要与设备硬件进行交互。在最初的移动手持设备实现中，Android必须驱动LCD显示屏、触摸屏或键盘、音频输入/输出、USB、WiFi及3G网络接口、数字摄像头和加速等。对于移动领域以外的应用，如数字视频、家庭娱乐及其他领域，还必须开发高清电视、红外和无线电遥控器、以太网、家居自动化总线(如X10)等的驱动程序。

　　将驱动程序迁移到虚拟化环境是一种投资回报率的问题──有多种选择，每种方案都有相对于其投资水平的优势：

　　原地：旧驱动程序以其原始设置保留在Host *** 作系统(Linux、实时 *** 作系统等)中。这种情况下的迁移主要是集成和配置microvisor，以优化对客户 *** 作系统环境的支持。

　　原地虚拟化：现有驱动程序仍保留在其Host *** 作系统环境中，并借助额外的配置来让其他客户机能够通过OKL4 Microvisor虚拟设备框架访问这些驱动程序。

　　独立：将旧驱动程序重新托管到称作设备服务器的专用轻量级虚拟机(安全单元)中，并直接在microvisor上运行。所有客户机均使用虚拟设备，然后由microvisor强制策略进行管理。因此，独立驱动程序是目前及未来客户 *** 作系统中最为安全和最便携的驱动程序。

　　4.通信栈

　　通信栈(3G、WiFi等)通常运行于旧实时 *** 作系统之上，可以随同其原始Host *** 作系统原封不动地重新托管到microvisor环境中。在移动应用中，这种能力可避免需要重新获取网络运营商或其他监管机构的认证，而失去抢占市场先机这一巨大优势。

　　5.其他旧组件

　　其他旧组件(中间件、实用程序、原始应用程序)可以借助OKL4兼容库直接迁移至microvisor，并作为一个单元集成到最终系统中。一个典型应用示例是自定义GUI/应用程序栈，可以原封不动地移植过来，一方面节约了时间，另一方面还保留了产品的多样化特性。

　　Beagle Board上的虚拟化Android──软件架构

　　根据上述流程，我们可以搭建这样一种架构：在Beagle Board上构建一个托管Android的虚拟化环境，同时具备安全VoIP功能，如图1所示。

　　图1：图中架构包含Beagle Board OMAP CPU“裸机”上运行的OKL4 Microvisor。启动时，系统引导进入OKL4，然后由OKL4加载并协调Android及其他客户机软件的执行。

　　在特定安全单元(虚拟机)中，microvisor托管：

　　Android。该组件与其他应用关键型组件完全隔离，以确保添加至该开放 *** 作系统平台中的软件不会影响到整个系统的稳定性或安全性。事实上，即使Android发生崩溃或死锁，OKL4仍可以重新加载/重新启动Android，而不影响其他安全单元中正在运行的软件(如Linphone)。

　　Linphone(或其他VoIP栈和应用程序)。在我们的参考设计中，我们移植了Linphone以便直接在OKL4 Microvisor上运行，但如果资源允许的话，Linphone可以驻留在安全单元中的Linux实例上。我们的设计有意地将Linphone与Android隔离开来，以确保Linphone的稳定性和安全性;另一方面，将Linphone托管在OKL4 Microvisor之上还能够节约内存并提高性能。

　　音频及串口驱动程序。Android与Linphone共享音频驱动程序，即使用户禁用了Android，该驱动程序仍能够为VoIP通话提供音频输入/输出。串口驱动程序是隔离共享的，以支持系统控制台和调试。

　　运行系统功能如下：Android作为主 *** 作系统，通过Beagle Board上的OMAP显示硬件提供标准的Android用户界面呈现给客户。用户可以使用基于Android的VoIP“拨号”应用程序或Android下运行的Linphone控制台服务器来启动安全的VoIP通话。通话启动后，用户可以运行其他Android应用程序(游戏、网页浏览等)，而不影响VoIP通话的质量或安全性。此时，即使Android进入睡眠模式甚至死机，都不会导致通话中断。