技术简介

一般Linux-based的系统通常在应用软件部分都是可以互相流通的，但Android的应用软件却不行，是因为Google在考虑资源有限的情况下，自行发展出与一般Linux版本不同的许多套件，首先，它不使用glibc为它的C函式库，而是采用Google自行开发的Bionic Libc。Bionic Libc大小约为glibc的一半，并提供Android所需要的重要函数，但不完全支持posix标准，且在加载动态库时不是使用常用的linker等。

再者，在GUI方面，不使用在Linux平台上通用的X window system，而是自行开发一个完整的图形环境。并为了使用Apache Harmony所提供大量的Java函式库，采用Java为开发Android 应用程序的语言，而且自行开发Java Virtual Machine - Dalvik VM，设计上使用较少的内存资源等。在Linux kernel也新增了一些Driver提供上层使用，譬如Binder Driver，提供给上述图形环境有效率及安全的IPC, 另外还有Log Driver，Low Memory Killer等。

因此，若想要将Android的应用程序在其它Linux上运行，除了会遇到Java Virtual Machine的不同问题，还会有应用程序跟Android整个环境的相依性的问题。当笔者深入了解Android整个启动流程，发现Android的应用程序倚赖着Android Framework: Activtiy Manager、Package Manager、Window Manager、Resource Manager等服务，所以理论上在相似的平台上，只要这些服务正常运作，Android的应用程序就可以执行。

故，笔者实行的方法，主要就是让Android的服务在其他Linux版本上运行，并为了与原本存在其他Linux版本上的窗口环境结合，改变其输入设备的事件处理及画面的输出的方式。

实作上，利用一支Linux程序去启动所有Android的服务，并撰写一支X client的程序输出Android的画面，以及接收X server的input events。整个Android操作系统像是一支程序，而非每支Android行程都独立出一个窗口，但由于Android本身每支程序都是独占画面，因此这样的结合让画面看起来仍是流畅的，进而提供了一个简单的方式让Android可以在其它Linux版本运行。

在此笔者采Moblin为实作的平台，Moblin使用一般Linux平台上glibc及X window system，并可使用标准的Linux kernel。

整合步骤

笔者提出的整合架构如图一所示。在一个硬件平台上，将Android及Moblin用user space及kernel space的角度分开来看，在kernel space，Moblin与Android共享Linux kernel，而在user space部分，Moblin applications及Android applications使用各自独立的GUI环境及libraries，而衔接两者最重要的地方就在pipes、Shared Memory及X client，这让Android可以与X window system共存。

以下笔者分别就 Linux Kernel、Root Filesystem以及Android Services这三部份来讨论详细的整合流程。

《图一 Android over Moblin架构图》

Linux Kernel —

如上所述，Android上层应用程序依赖Android对标准kernel外加的驱动程序之支持，而Moblin或大部份其它Linux平台虽在kernel也有些修改，但主要都是针对kernel内部效能的调教，所以不会对user space的应用程序构成兼容的问题，因此笔者选用Android发布的kernel当整合后平台的kernel。另外，kernel的选项则要考虑到两个系统应用程序的需求，如在此笔者需打开KMS以支持Moblin，同时也需开启对Android驱动程序的支持。

Root Filesystem —

完成kernel的设定后，就可以开始user space的整合。一般Linux版本的root filesystem主要目录结构如图二所示。在笔者要整合的两个平台中， Moblin使用与表一同样的目录结构，而Android则不尽然相同，其保有/sbin、/proc、/sys以及/dev，而把所有工具、应用程序和函式库等都放到/system下，因此/system在Android中占有重要地位，也因为函式库路径不同，Android链结的函式库得以跟Moblin分开，避开同样是libc函式库，实际上却使用不同函式库的问题，让这部分不需额外处理。

由于/proc、/sys以及/dev都是kernel产生与系统相关的目录，因此不需另外处理；而/sbin(内只含adbd)里的档案则需保留进Moblin的/sbin里，/system则需整个复制到Moblin的root filesystem下。

《图二 图二：Linux Root Filesystem 目录结构》

Android Services

如简介中提到的，笔者须先让Android 系统服务在其他Linux平台中执行起来，如此Android的应用程序就可以在此平台上执行。由于Android开机的第一支程序init替Android的应用程序准备好执行环境（Runtime），除了叫起一些需要的Linux daemons，如adbd、vold、mediaserver及installd外，并启动Android中很重要的程序—Zygote，Zygote控管Android的Java行程，依据要求产生Dalvik VM，并在init里，会先生出一个Dalvik VM跑system_server，而system_server开启了所有Android重要的服务。

另外所有用户界面上主要的应用程序，如calendar、media及alarmclock等等，也都是执行在Zygote生出的Dalvik VM内。因此笔者修改init这支程序，使其在Moblin上将Android的执行环境准备好。

除此之外，原本Android单独存在时，Android的画面是将要显示的数据直接写到显示适配器的framebuffer去显示，与用户互动的输入是直接收kernel送出的events，而当运行在Moblin上时，由于Moblin有另外一套GUI程序也会存取硬件资源，因此Android直接存取硬件资源会与Moblin不兼容，所以Android必须与Moblin上其他GUI程序一样使用X window system，显示及接收用户的输入都要透过X server。而显示及接受输入的程序代码分别写在EGLDisplaySurface.cpp及EventHub.cpp里，一种作法是将里面的函式更改成使用X library与X server做沟通，但是，像前面所讲的，由于Android使用的libc函式库非一般在Linux上使用的glibc，在linker方面也非一般Linux使用的ld.so，要将庞大的X library重新用Android的toolchain重新编译是件大工程，因此笔者采一个较为简洁的方法，另外写一支X client，并利用Shared Memory及pipes去跟Android做连接（

如前述图一），而非将Android内部的程序改成使用X library。

另外，针对设备的新增及移除，Linux kernel会发送uevent来告知，专职的程序如udev就可以利用uevent夹带的讯息来判断设备的类型跟状态，并做相对应的动作，如在/dev下新增或移除一个device node等。Moblin上使用常用的udev来做设备的管理，而Android则是设计了一个占据较少资源的设备管理员。然而，同一平台上不需要两个设备管理员，因此需移除Android的设备管理员，并将Android对其特殊设备的设定加到udev的rules里，由udev全权管理。

照着以上的更改完后，笔者就可以在Moblin上将Android像启动一般UI应用程序般启动。接下来就谈到设备共享的部份 :

设备共享

在设备方面，笔者以一些设备为例，如Camera、GPS及SD Card/USB Storage等来说明同时使用时的状况。在大部分的实作上跟将Android移植到x86架构上类似，但由于是与Moblin系统共存，很多功能可能与Moblin原本拥有的应用程序相同，所以除了考虑系统上可能的冲突外，开启程序时也要注意到是否硬件已经在使用中。

Camera & GPS

Android 对于一些特殊的硬件装置大多使用定义好的HAL（hardware abstract layer） 作为中介层，因此基本上只需要实作与硬件相关的程序代码将HAL与底层 driver 提供的接口衔接起来即可，至于HAL如何与上层的service做沟通，Android 本身已经具有相当完整的实作，故不需要另外处理。像Camera以及GPS即属于这类装置， 当共享时，只需考虑到是否有其他程序已经在使用这项设备，实作上则与移植Android到x86架构相同，如下：

Camera

Android定义好HAL接口， 但是并没有真正实作从镜头撷取影像的功能。因此笔者主要的工作便是利用V4L（Video for Linux）来撷取影像。Video4linux 是Linux中对底层影像撷取设备的驱动，必须先行编译kernel使其支持该功能。而影像撷取的大致流程如下: 打开影像撷取设备（/dev/video0）、 读取设备讯息、 初始化设备、影像撷取、图像处理或转换、 关闭设备 。

GPS

一般蓝芽的 GPS 装置连接后，在 Linux 内通常会以 rfcomm（radio frequency communication） 的接口出现，该接口的操作就相当于一般的 RS-232 serial port 相同。将其开启后，GPS 装置就会传送一系列 NMEA 编码的数据过来，于是笔者便能使用此数据来让 HAL 能读取并转送 GPS 坐标给上层的 location service。

在实作上，主要要实作的就是一个 GPS library，而 Android 在原始的程序代码内就有一个可以参考的程序代码

（$ANROID_SRC_ROOT/hardware/libhardware_legacy/gps/gps_qemu.c），所以只需对其稍加修改，自 rfcomm 接口读取目前的 GPS 数据，基本上就能顺利的将 Android 与 GPS 装置衔接起来。

《图三 HAL》

SD Card/USB Storage

在storage方面，Android 版本1.5后采用vold来挂载小型周边。vold里没有针对USB storage所属的block device做处理，因此如想要挂载USB storage，需自行增加处理block device。跟前面所讲到的设备管理器一样，vold是利用uevent来判断硬件状态，除对装置新增移除的动作外，在同时也会依状态决定是否要通知media scanner针对储存装置里的内容做扫描，以供预览。由于有些功能与udev重复，因此在处理函式里要考虑到会冲突的部份，譬如说在收到uevent时，不对装置做新增移除的动作，让udev去完成这部份。

相关研究

前面所述是直接修改Android与硬件衔接的部份，去达成让Android与其它Linux-based系统并行，以下提出其他方式：

Virtual Machine

透过Virtual Machine，如使用Android SDK提供的仿真器Qemu也可以让Android与其它系统共存上，但这种作法由于Android不是跑在原生硬件（Native Hardware）上，效能上会比较差。

Android execution environment by Canonical

目前让Android不另外透过仿真器，还有Ubuntu的商业赞助商Canonical的作法。

Canonical在建造一个Android execution environment，虽未公布其完整的实作方法与产品，但在网络上已有部分实作结果及进展。其方法使用了glibc而非bionic，忽略掉Android为IPC所做的Binder driver，并打算删掉一些特殊组件，因此目前还有许多限制及功能不能使用，但设计上让Android的应用程序能透过Android execution environment 独立执行，并不像笔者是将整个Android当成一个应用程序，因此更无缝的结合，也增加了实作上的困难及复杂度。

结语

Canonical在建造一个Android execution environment，虽未公布其完整的实作方法与产品，但在网络上已有部分实作结果及进展。其方法使用了glibc而非bionic，忽略掉Android为IPC所做的Binder driver，并打算删掉一些特殊组件，因此目前还有许多限制及功能不能使用，但设计上让Android的应用程序能透过Android execution environment 独立执行，并不像笔者是将整个Android当成一个应用程序，因此更无缝的结合，也增加了实作上的困难及复杂度。