CN102129369B

CN102129369B - 在Android手机上整合TinxX图形界面的方法

Info

Publication number: CN102129369B
Application number: CN201010619543.3A
Authority: CN
Inventors: 王承志; 徐鼎鼎; 毛德操
Original assignee: INSIGMA TECHNOLOGY Co Ltd
Current assignee: INSIGMA TECHNOLOGY Co Ltd
Priority date: 2010-12-22
Filing date: 2010-12-22
Publication date: 2014-05-21
Anticipated expiration: 2030-12-22
Also published as: CN102129369A

Abstract

本发明涉及一种在Android手机上整合TinxX图形界面的方法，1.1)每当启动一个Linux GUI应用时，就在Android系统中为其创建一个代理进程AppProxy，这个进程与实际的应用进程有着相同的生存期；1.2)由应用代理进程AppProxy创建一个FB刷新线程；1.3)修改TinyX的代码，将本来要写入FB的内容作为一个Bitmap写入一个中间文件；1.4)FB刷新线程每隔一段时间就将这个中间文件的当前内容通过drawBitmap()画入FB，就象一个普通的Android应用需要画一个Bitmap一样。本发明有益的效果是：本发明提供了一种代理机制，在Android系统中为运行于Android以外的Linux GUI应用提供一个作为Android进程的代理，使Linux GUI应用通过TinyX进行的屏幕显示最终要通过这个代理才能显示出来，其效果是实现了TinyX图形界面与Android的整合。

Description

在Android手机上整合TinxX图形界面的方法

技术领域

本发明涉及Android手机领域，尤其是一种在Android手机上整合TinxX图形界面的方法。

背景技术

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

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

在带图形界面的Linux操作系统中，有关图形界面的功能都是由X视窗系统提供的。运行着应用软件的进程都不直接访问显示屏，也不直接进行图形方面的操作运算，而只是通过进程间通信将绘图命令发送给X服务进程，由X服务进程加以实施。X视窗属于另一个开源软件项目，早在Unix时代即已存在。由于Linux系统大多离不开图形界面，X视窗实际上已经成了Linux操作系统的一部分。为适应手机和其它嵌入式系统的需要，人们还将X视窗加以裁剪、缩编、简化，成为一个小型化的版本称为TinyX，所以TinyX是专门与嵌入式Linux配对使用的X视窗系统。

而在包括Android手机在内的Android系统中，则甩开了X视窗，所有的图形界面功能全都由Android自己提供。所以，Android手机上的图形界面是Android自己“原生”的。之所以如此，主要是因为Android需要向应用软件提供一个Java语言的程序设计界面(API)和运行环境，预期中的Android应用都是用Java语言编写的。

可是原来为Linux开发的应用却并不使用Android的API和运行环境，这些软件大多使用C/C++语言，并且是依赖于X视窗的。要在Android系统上运行这些软件，就还是得要在Android系统上安装TinyX。显然，Android的设计者原来是不打算在Android系统上运行此类软件的，但是实际上在一些特殊的条件下仍有这样的必要。例如，正在进行中的一个项目是要在OPhone上直接运行WinCE和WM(Windows Mobile)的应用软件，这显然有助于扩展OPhone的应用软件来源。为达到这个目的，我们可以借助一个称为Wine的开源软件，把这个软件移植到手机上。但是在这种情况下WinCE/WM软件是作为Linux的GUI应用运行的，都离不开TinyX。

然而，当TinyX和Android并存于同一台机器上时，就有了问题，那就是两个图形界面互相冲突、干扰的问题。

一般而言，不管是手机还是别的什么系统，也不管在上面运行什么软件，使用者看到的总是同一个显示屏，如果有两个进程都要显示，那就得有个仲裁和协调的机制，不能各自无序地在显示屏上写，否则就会互相干扰。这个问题不解决，就实际上不能在Android系统上运行Linux的GUI应用。

其实Android内部也有类似的问题。Android是个多任务、多进程的系统，其内部的不同进程之间也共用同一个显示屏，也有可能会互相冲突，也需要有仲裁和协调的机制；而Android也确实提供了这样的机制。Android有个函数drawBitmap()，这个函数内部就有对于显示屏的仲裁和协调，如有多个Android进程通过调用这个函数显示一幅画面的Bitmap(位图)，就会自动受到Android的仲裁和协调。但是，TinyX服务进程并非Android内部的进程，TinyX和Android是两个不同的系统，所以drawBitmap()无法把TinyX也纳入其仲裁和协调的范围。这样，要在Android系统上运行Linux的GUI应用，图形界面的整合就还是成为问题。

而本发明的内容和特点就是：为这个问题的解决提供一种方法，将TinyX提供的图形界面整合到Android原生的图形界面中，使Linux的GUI应用可以在包括Android手机在内的Android系统上正常运行。

发明内容

为解决整合TinyX和Android两个图形界面的问题，本发明提供了一种在Android手机上整合不同图形界面的方法，使嵌入式Linux操作系统上由TinyX提供的图形界面与Android手机原生的图形界面相整合，使得在Android手机上可以和谐自然地运行带图形界面的Linux软件。

无论是TinyX还是Android，最终都是通过“画面缓冲区(Frame Buffer，下面简称FB)”将图形画在屏幕上。所谓FB，是将Linux的设备文件/dev/fb映射到内存中的一个缓冲区中，有了这样的映射之后，写入FB的内容就会出现在屏幕上。可是，如果让TinyX和Android都互相独立地使用FB，就会出现双方抢夺FB，互相干扰、互相覆盖的现象。所以必须要加以协调，由一个统一的机制来控制FB的使用。

本发明采用的方法是：在Android这一边为Linux GUI应用创建一个代理，凡是LinuxGUI通过TinyX实施的屏幕显示必须经由这个代理；由Android统一管理FB的使用。

1.1)每当启动一个Linux GUI应用时，就在Android系统中为其创建一个代理进程AppProxy，这个进程与实际的应用进程“同生共死”，有着相同的生存期。

1.2)由应用代理进程AppProxy创建一个FB刷新线程；

1.3)修改TinyX的代码，将本来要写入FB的内容作为一个Bitmap写入一个中间文件；

1.4)FB刷新线程每隔一段时间就将这个中间文件的当前内容通过drawBitmap()画入FB，就象一个普通的Android应用需要画一个Bitmap一样。

这样，Linux GUI应用把屏幕显示委托给TinyX，而TinyX并不直接访问与显示屏相连的FB，而是把显示的内容写入一个中间文件，而对于FB的写入则是由AppProxy通过调用由Android提供的drawBitmap()完成的，所以会受到Android的仲裁和协调，其效果是实现了TinyX图形界面与Android的整合。

由于TinyX是X视窗的一个子集，其源代码就是X视窗的源代码的一部分，本发明所述方法同样也适用于X视窗。

本发明有益的效果是：本发明提供了一种代理机制，在Android系统中为运行于Android以外的Linux GUI应用提供一个作为Android进程的代理，使Linux GUI应用通过TinyX进行的屏幕显示最终要通过这个代理才能显示出来。而这个代理，则由于是Android内部的进程，也通过drawBitmap()进行显示，因此也受到Android内部的仲裁和协调；其效果是实现了TinyX图形界面与Android的整合。

附图说明

附图1是TinyX的图形界面与Android整合之前的系统示意图；

附图2是按本发明所述方法将TinyX的图形界面与Android整合之后的系统示意图；

附图3是AppProxy的程序流程图。

具体实施方式

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

附图1中的竖直虚线将系统分成两半，右边是Android系统及其应用，左边是Linux本身的应用，二者共用同一个Linux内核。图中有两个Android进程，它们都通过Android访问内核中的一个屏幕缓冲区FB，而FB则与物理的显示屏相连。由于都经过Android，两个Android进程对FB的访问都受到Android的仲裁和协调，不会互相干扰。而Linux这一边，则Linux应用进程通过进程间通信(IPC，由图中的大箭头表示)将显示命令发送给TinyX服务进程，由TinyX执行具体的绘图命令，然后写入内核中的另一个FB、或者也可以是同一个FB，但是最终这两个FB都通往同一个物理显示屏。由于TinyX无法调用Android内部的功能，它对FB的访问是独立于Android之外的，所以不受其仲裁和协调，于是就有了互相冲突和干扰的问题。

附图2中在Android这一边多了一个应用代理进程AppProxy，而FB则只有一个，并且都要经过Android才能访问。TinyX将原本要写入FB的信息写入一个中间文件，这个中间文件相当于一个屏幕缓冲区。然后，AppProxy每隔一段时间、例如每隔50毫秒，就将中间文件的内容通过Android抄写到FB中。这样，TinyX的输出就受到Android的仲裁和协调，因此就不会发生因争夺屏幕而致的冲突和干扰。换言之，TinyX的图形界面被整合到了Android里面。

注意这里采用中间文件只是众多实施方式中的一种，实际上也可以采用共享内存区(SharedMemory)等等别的方式，这并不影响本发明的实质。

附图3是AppProxy的程序流程。当用户要启动一个带图形界面的Linux应用时，实际启动的是AppProxy，原本用来启动Linux应用所需的命令行则作为(对于AppProxy的)命令行参数传给AppProxy。启动之后，AppProxy首先创建一个FB刷新线程，而主线程则根据命令行参数启动Linux应用，然后就等待Linux应用的运行结束。一旦Linux应用结束运行，整个AppProxy进程便立即退出运行。注意这里是整个AppProxy进程退出运行，包括FB刷新线程在内。这样，AppProxy与具体的Linux应用便有(基本)相同的生存期，成为同生共死的关系。

至于FB刷新线程的流程则很简单，只是在一个定时的循环中把中间文件的内容通过由Android提供的drawBitmap()抄写到FB中，下面给出了具体的实施方式。

本方法的具体实施涉及对TinyX即X的源代码的修改，X是开源软件，其源代码可从有关网站获取。下面分三个方面说明本方法的一个实施例。注意同一个方法可以有多种不同的实施，这里所提供的只是其中之一。

1、修改TinyX的源代码，使其将输出不写入FB而写入一个中间文件

TinyX在一个函数fbdevInitialize()中通过mmap()将设备文件/dev/fb0映射到内存中的一个区间，这段代码在源文件Xserver\hw\kdrive\fbdev\fbdev.c中：

这个函数先打开设备文件/dev/fb0，然后将其映射到某个内存地址(由内核决定)，并将这个地址保存在priv-＞fb_base中。这样，priv-＞fb_base、实际上是与页面边界对齐以后的priv-＞fb，就成了FB即屏幕在Xserver中的映像。

现在要做的是用一个中间文件/tmp/TinyXfb取代/dev/fb0，然后同样把这个文件mmap()到内存中的一个区间，这就为Xserver建立了一个虚拟的FB。这样，Xserver写入这个内存区间、并且自以为写入了屏幕FB的图形，就实际上写入了这个中间文件。于是，Xserver成为这个中间文件的内容提供者。

将/dev/fb0替换成TinyXfb之后，这里的priv-＞fd就代表着这个中间文件，而不再是设备文件/dev/fb0。但是针对设备文件/dev/fb0的ioctl()操作FBIOGET_FSCREENINFO和FBIOGET_VSCREENINFO对于中间文件TinyXfb是无意义的，所以要将这里的两个调用ioctl()的语句删去。

注意这里把打开设备文件直接改成打开中间文件是因为TinyX的实现建立在mmap()的基础上，此后对FB的访问已不再采用文件读写、而改成了对内存缓冲区的访问，有关的计算(例如计算像素位置等等)都由TinyX自身提供的代码完成，而并不依赖于FB设备文件的驱动程序。反之，如果不采用mmap()，而采用read()、write()等文件操作实现对FB的读写，那就不能这样简单替换了，因为中间文件是普通文件，与FB设备文件的驱动不同。

另一方面，TinyX通过访问内存读写这个映射到内存的中间文件时是把它看成FB的，TinyX的有关代码保证了这一点，所以中间文件的大小始终是固定的，而不会随时间而不断增大，文件的大小取决于显示屏的分辨率和显示模式。

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

为把Linux应用的人机交互输入整合到Android，需要在Android这一边为Linux应用创建一个代理进程，由这个代理进程在Android这一边定期将(TinyX生成的)中间文件的内容刷新到Android这一边的屏幕缓冲区FB中。

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

这个Activity的任务之一是创建FB刷新线程，另一个任务就是启动Linux那一边的应用，具体方法是通过Java语言的JNI机制调用其方法startApp，而JNI机制会自动将其转化成对C语言函数Java_Android_AppProxy_jni_JniMethod_startApp()的调用：

这段程序通过Linux的系统调用fork()创建一个子进程，然后让这子进程执行Linux那一边的具体应用程序，并等待其退出，一旦应用程序推出就使整个代理进程退出运行，这样就保证了代理进程与应用进程的“同生共死”。

有关的这些程序设计对于Android应用的开发者而言应该没有什么困难，如有困难可参阅“深入浅出Google Android”、“Pro Android”等参考书。

注意这里的系统调用system()要到作为目标的Linux应用退出运行或运行失败时才会返回，所以一旦程序从system()返回便退出整个AppProxy的运行。

3、FB刷新线程。

FB刷新线程的实现也很简单，下面给出其伪代码：

以上三个方面的实施保证了应用代理AppProxy具有与具体Linux应用基本相同的生存期，而TinyX的输出都要经过AppProxy才能到达FB和显示屏，由于AppProxy通过由Android提供的drawBitmap()访问FB，受到Android的仲裁和协调，这就把TinyX的图形界面整合进了Android。

最后，TinyX是X视窗的一个子集，TinyX的源代码是X视窗源代码的一部分，本发明所述的方法虽以TinyX为目标，但同样也适用于X视窗。

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

Claims

1.一种在Android手机上整合TinxX图形界面的方法，其特征在于：

1.1) 每当启动一个Linux GUI应用时，就在Android系统中为其创建一个应用代理进程AppProxy，这个进程与实际的应用进程有着相同的生存期；

1.2) 由应用代理进程AppProxy创建一个画面缓冲区FB刷新线程；

1.3) 修改X视窗系统的小型化版本TinyX 的代码，将本来要写入画面缓冲区FB的内容作为一个Bitmap写入一个中间文件；

1.4) 画面缓冲区FB刷新线程每隔一段时间就将这个中间文件的当前内容通过用来画位图的函数drawBitmap()画入画面缓冲区FB，就象一个普通的Android应用需要画一个Bitmap一样。