在Android手机上实现WinCE/Android混合API的方法

摘要

本发明涉及一种在Android手机上实现WinCE/WM和Android混合API的方法，在Android系统中为运行于Android外部的WinCE/WM应用提供一个作为Android进程的代理进程，并为其提供一个虚拟的API中介层，将应用程序对Android API函数的调用转化成操作请求并发送给代理进程，由代理进程调用相应的Android功能并将结果发回给应用进程。本发明有益的效果是：使程序员们可以为WinCE/WM模式应用的开发提供一个混合API，使这些应用可以在程序中调用由Android提供的功能。

说明书

技术领域

本发明涉及一种Android手机领域，尤其是一种在Android手机上实现WinCE/Android混合API的方法，其显著的特点是使程序员在开发Android应用软件时在程序中既可以调用WinCE的功能，又可以调用Android本身的功能。

背景技术

以手机为代表的智能化移动终端设备既是计算机技术的一个重要发展方向，又是一个竞争十分激烈的市场。自从谷歌公司和开放手机联盟推出Android操作系统和基于Android的手机以来，很快就在世界手机市场上占有了不小的份额，各种Android手机层出不穷，由中国移动开发并推出的OPhone也是基于Android的，也是一种Android手机。

所谓Android操作系统，实际上是对Linux操作系统的一种改编和扩充，它的内核基本上就是Linux的内核，但是在用户空间却专门针对手机和移动终端设备的特点作了大幅的改进和增强，这些改动大都与编程模式和图形界面、即图形化用户界面(GUI)有关。

另一种常用于手机的操作系统是微软的WinCE和WM、即Windows Mobile，这是在微软的Windows操作系统上发展起来的。基于WinCE/WM的手机也在市场上占不小的份额，并且开发出了数量不小的WinCE/WM应用软件。如果能把这些应用软件拿到Android手机上运行，对于提高Android手机的市场占有率显然是有利的。

通过把开源软件Wine移植到Android手机上，把本应由Windows提供的支撑嫁接到Linux上，并对其加以扩充、使其支持WinCE/WM，可以让WinCE/WM应用软件直接在Android手机上运行、实际上是在Android手机的Linux内核上运行。这样，原来熟悉WinCE/WM软件开发的人就可以按原来的模式、在原来的开发环境中、使用原来的开发工具、像开发WinCE/WM软件一样地开发Android软件，而且开发出来的软件既是WinCE/WM软件又可以在Android手机上运行，这对于开发者也是很有利的。

可是，这样开发出来的软件实质上仍是纯粹的WinCE/WM软件，其基础是由WinCE/WM承诺提供的各项功能。事实上，没有一种应用软件能事无巨细完全由自己提供所有的功能，都是建立在别的软件如操作系统、基础平台、中间件等等所提供的更为基本的功能的基础上。反过来，凡是承诺为别的软件提供某些功能的软件，则要定义、即明确说明自己能提供一些什么样的功能，以及怎样调用这些功能。这样的定义称为“应用程序编程界面”、即API。另一方面，软件的功能是由“函数”实现和提供的，这样的软件既然要为别的软件提供某些功能，就必须提供一个实际上实现了这些功能的函数集合，所以API的另一个意思就是指这样的一个函数集合。可见，上述为WinCE/WM平台开发的应用软件都是基于WinCE/WM的API。而“正宗”的Android软件，则是基于Android自己的API。移植了Wine以后，这两种应用软件虽然都能在Android上运行，实际上却是井水不犯河水、互不相干。从原理上说，WinCE/WM的API与Android的API在功能方面应该是等价的对应物，但是实际上只能是大体上如此，二者还是有些区别，所以即使是针对Android手机而开发的WinCE/WM应用，也不能充分利用Android的优势。因为这些功能是在Android框架的内部运行，而WinCE/WM软件虽然能在Android手机的Linux内核上面运行，却是在Android框架的外部。更重要的是，Android是个开放的系统，不断有许多新的基本功能被创造出来并增添到Android的API中，可是在为WinCE/WM编写的程序中就不能调用这些功能了。

可以想像，要是能为WinCE/WM应用的开发者提供一个“混合API”，使他们在程序中既能如常调用由WinCE/WM的API所提供的功能，又能调用由Android提供的一些特殊或新颖的功能，这些开发者们就可以为Android开发出更多更好的应用软件。举例言之，对于来自Google的Android，地图功能是它的一个强项，如果开发的是“正宗”的Android应用，在程序中调用与地图有关的功能是比较容易的。但是，如果开发的是WinCE/WM模式的应用，尽管目的也是在Android手机上运行，却无法调用这些功能。由此可见，提供一个混合API，使WinCE/WM模式的应用也可以在程序中调用Android所特有的功能，是很有意义的。

但是，要提供这样的API并非易事。

发明内容

为解决提供混合API的问题，本发明提供了一种在Android手机上实现WinCE/Android混合API的方法，是一种采用代理机制的方法，在Android系统中为运行于Android外部的WinCE/WM应用提供一个作为Android进程的代理进程，并为其提供一个虚拟的API中介层，将应用程序对Android API函数的调用转化成操作请求并发送给代理进程，由代理进程调用相应的Android功能并将结果发回给应用进程。

本发明解决其技术问题采用的技术方案：本发明所述的这种在Android手机上实现WinCE/WM和Android混合API的方法，要点为：

●每当要在Android手机上启动一个WinCE/WM应用时，就在Android系统中为其创建一个代理进程AppProxy，这个进程与实际的应用进程“同生共死”，有着相同的生存期。实际的应用进程和代理进程都跟TinyX服务进程有socket连接。

●在Android外部为WinCE/WM应用提供一个虚拟的Android API中介模块，由这个中介模块提供与Android功能相对应的API函数。这个中介模块与原有的Wine模块合在一起既提供WinCE/WM的API，也提供Android的API，所以称为“混合API”。

●每当WinCE/WM应用程序调用由API中介层模块提供的Android API函数时，中介层模块将其转化成操作请求，并将其发送给TinyX服务进程。

●TinyX服务进程将操作请求转发给代理进程。

●代理进程根据操作请求在Android框架内部调用相应的Android功能，并将运行结果经由TinyX服务进程发回给Android外部的应用进程。

●应用进程从对Android API函数的调用中返回。

这里的操作请求和运行结果之所以要由TinyX服务进程转发，是因为应用进程本来就与TinyX服务进程有socket连接，而代理进程要与TinyX服务进程建立socket连接又很方便。在Linux平台上，TinyX或X服务进程是为Linux应用统一提供图形显示和人机交互输入的服务进程。不过，TinyX服务进程这一个环节也可以跳过，改成由应用进程和代理进程直接建立socket连接并直接通信。

这样，虽然WinCE/WM应用是在Android框架的外部运行，但是对Android所提供功能的调用却是由代理进程在Android框架的内部完成的。相比之下，应用程序对WinCE/WM API函数的调用则与Android无关。从程序设计的角度看，WinCE/WM应用可以利用的API是个混合API。

本发明有益的效果是：使程序员们可以为WinCE/WM模式应用的开发提供一个混合API，使这些应用可以在程序中调用由Android提供的功能。本发明直接的目的是为在Android手机上运行的WinCE/WM应用提供混合API、即由WinCE/WM API和Android API混合构成的API；但是实际上也可以用来为在Android手机上运行的Linux应用提供混合API、即由Linux API和Android API混合构成的API。

附图说明

图1是按本发明所述方法提供混合API之前的系统示意图；

图2是按本发明所述方法提供混合API之后的系统示意图；

图3是AppProxy的程序流程图。

具体实施方式

下面结合附图和实施例对本发明作进一步说明：

图1中的竖直虚线将系统分成两半，右边是Android系统及其应用，左边是Linux本身的应用，二者共用同一个Linux内核。图中的右边有两个Android进程，它们都通过Android的API调用由Android提供的各种基本功能，而Android则又通过Linux内核的API(称为“系统调用”)调用由内核提供的更基本的功能。相比之下，左边是Linux本身的应用，图中的Wine模块把本来只能在WinCE/WM上运行的应用转化成Linux应用，或者说：WinCE/WM应用+Wine＝Linux应用。但是，尽管如此，WinCE/WM应用与Wine之间的界面却仍旧是WinCE/WM的API。这样，那怕Android的API提供了很好的功能，在WinCE/WM应用里面也无法加以调用。

图2中在Android这一边多了一个应用代理进程AppProxy，这个代理进程相当于一个Android应用，它可以调用Android的API所提供的任何一种功能。而在Linux这一边，则多了一个中介模块。这个中介模块在Linux这一边提供一个虚拟的Android API。之所以说虚拟，是因为这个模块并不真的在Linux这一边对这些功能实际上加以实现，而是通过Socket连接向Android这一边的代理进程AppProxy发出操作请求，由AppProxy在Android的框架中予以实现。这样，由中介模块提供的API，加上由Wine模块提供的API，合在一起就构成了一个混合API。

实际上，由中介模块提供的API不必是完整的Android API，而只需是后者的一个子集，因为AndroidAPI所提供的大部分功能在WinCE/WM API中都有，需要由中介模块提供的只是Android API中一些比较有特色的功能。

图3中，当用户要启动一个带图形界面的Linux应用时，实际启动的是AppProxy，原本用来启动Linux应用所需的命令行则作为(对于AppProxy的)命令行参数传给AppProxy。启动之后，AppProxy就进入一个循环，在循环中等待来自WinCE/WM应用的请求，一旦有请求到来就加以解析和执行，并将结果发回给WinCE/WM应用，然后就进入下一轮循环。

在本方法的具体实施中，WinCE/WM应用进程与代理进程AppProxy之间的通信都经过TinyX服务进程的中转。这是因为，现在的Linux平台都是带图形化人机交互界面(GUI)的，一般的Linux应用(除Android外)在运行时都得与提供人机交互界面的TinyX服务进程打交道。这些Linux应用进程在启动时就自动与TinyX服务进程建立Socket连接。而代理进程AppProxy，也很容易跟TinyX服务进程建立起Socket连接，因为后者本来就是个服务进程，本来就在等待别的进程跟它建立连接。所以，本方法的具体实施涉及对TinyX即X的源代码的修改，X是开源软件，其源代码可从有关网站获取。

假定Android的API中定义了一个功能，是播放一段背景音乐，我们想让WinCE/WM应用中可以调用这个功能。Android的框架采用Java语言，一个功能称为一个“方法(Method)”，这个方法的名称是start_music，在API中的定义是：

public boolean start_music(String[]filename，int volume)；

这个“方法”有两个参数，第一个是音频文件的文件名，第二个是播放的音量。我们的目的是将Android API中的这个功能作为混合API中的一个函数提供给WinCE/WM应用。

下面分五个方面说明本方法的一个实施例。注意同一个方法可以有多种不同的实施，这里所提供的只是其中之一。

1、作为应用代理的可执行程序AppProxy

为在Android框架中执行来自WinCE/WM应用和中介模块的Android API函数操作请求，需要在Android这一边创建一个代理进程，由这个代理进程在Android这一边调用Android API所提供的各种函数。

在Android系统中，一个应用进程称为一个Activity，是一个Java语言中的“类(Class)”，将这种类扩展成一个自定义的类，就是一个Android应用，最后在Android的显示屏上就会有一个图标，点击这个图标就会执行这个类中的“方法(Method)”onCreate()。所以，onCreate()就相当于C程序中的main()。下面给出有关的伪代码

这个Activity首先要启动Linux那一边的应用，具体方法是通过Java语言的JNI机制调用其方法startApp，而JNI机制会自动将其转化成对C语言函数Java_Android_AppProxy_jni_JniMethod_startApp()的调用：

这段程序通过Linux的系统调用fork()创建一个子进程，然后让这子进程执行Linux那一边的具体应用程序。这样就保证了代理进程与应用进程的“同生”；但是这还不够，还得保证二者的“共死”，为此可以把“退出运行”也定义为一种附加的操作请求，由应用进程在退出运行前夕向代理进程发送这种请求，使代理进程及时退出运行。

2、定义一个双方通信的协议

当WinCE/WM应用根据混合API中的Android部分调用其某个函数时，实际受到调用的是中介模块中的某个与之对应的函数，这个函数将向代理进程AppProxy发出特定的操作请求，由代理进程加以执行，操作请求是作为“消息”发送的。为此，需要在中介模块与代理进程之间定义一个双方通信的协议，使代理进程能正确地理解中介模块的意图。

所谓双方通信的协议、一方面是消息的格式，一方面是消息的类型。

作为实施例，消息的格式可以这样定义：

●消息中的第一个32位整数表示消息类型，一个消息类型代表着API中的一个函数(即一种特定的功能)。

●消息中的第二个32位整数分成两半，其高16位表示参数的个数，低16位表示整个整个消息的长度。

●消息中的第三个32位整数开始为调用参数。如果参数的类型为指针(根据API函数定义可以知道)，则要把所指向的数据结构抄写在消息中，再使这个指针指向这个数据结构的副本在消息中的起点。例如，假定按API中参数2是字符串指针，那就要把这字符串抄写在消息中，然后使参数2指向这个副本。

至于消息类型，在我们这个实施例中可以这样定义：

如前所述，我们以播放音乐的功能start_music为例，所以这里只列出了一个类型即PROXY_START_MUSIC的定义。实际上有多少需要放在混合API中的函数就要定义多少不同的消息类型。注意这里把PROXY_START_MUSIC定义成0x80000020，其最高位为1，这是为了跟TinyX本身的绘图命令区分开来，TinyX本身的绘图命令不会使用这么大的数值。

3、在中介模块中提供相应的混合API函数

中介模块实现成一个动态连接库、即DLL。同时还要有一个配套的.h文件，这个.h文件就是API的定义，里面给出了所有API函数的原型定义。由于我们要提供start_music这个功能，就在这.h函数中加上：

int start_music(char*filename，int volume)；

这与前面的定义略有不同，是因为前面的定义采用Java语言，而这里采用C语言，实际上是一样的。

这样WinCE/WM的程序中就可以include这个.h文件，然后就可以在程序中调用这个函数了。当然，在中介模块的程序中得要提供start_music()这个函数。但是如前所述在中介模块提供的这个函数并不真的播放音乐，而只是向应用进程发送一个操作请求，下面是这个函数的伪代码：

4、由TinyX将来自中介模块的消息转发给应用代理

TinyX是个服务进程，其主循环是Dispatch()，这个函数的代码在Xserver\dix\dispatch.c中。在这个主循环中，TinyX的主线程在一个函数WaitForSomething()中通过系统调用select()监视来自外部设备和Socket的输入，这段代码在源文件Xserver\os\WaitFor.c中：

每当TinyX的这个线程从系统调用select()返回时，必定是某个socket或I/O端口上发生了什么事，返回值i指明具体的socket或端口，下面就由WakeupHandler()加以处理并作出反应。在WakeupHandler()要作一些修改：对于socket，而且消息中第一个32位字的最高位为1，就说明这是为实现混合API而发送的消息，此时就要由函数serv_api()加以处理，这个函数是为实现混合API而新加的，其伪代码如下：

这样，以PROXY_START_MUSIC为例，这个消息就会被转发给应用代理。

5、由应用代理执行操作请求

如前所述，每当应用代理接收到由TinyX转发过来的消息时，就要加以解析并调用相应的方法(函数)加以执行。为此，对于需要在混合API上提供的每一个函数都要在应用代理中增添一个与此对应的方法。以start_music()为例，就在应用代理中增添一个方法do_start_music()，其伪代码如下：

注意WinCE/WM应用进程在其中间模块中有个API函数start_music()，Android的API中也有个start_music()，但是这二者完全不同，并且是在两个不同的进程中。自从中间模块中的start_music()将消息发送给TinyX以后，就一直在睡眠中等待，直到TinyX把应用代理发回的执行结果转发回来才被唤醒，再从start_music()返回到应用程序中。

除上述实施例外，本发明还可以有其他实施方式。凡采用等同替换或等效变换形成的技术方案，均落在本发明要求的保护范围。