专利名称：在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的⑶I应用。其实Android内部也有类似的问题。Android是个多任务、多进程的系统，其内部 的不同进程之间也共用同一个显示屏，也有可能会互相冲突，也需要有仲裁和协调的机制； 而Android也确实提供了这样的机制。Android有个函数drawBitmap ()，这个函数内部就 有对于显示屏的仲裁和协调，如有多个Android进程通过调用这个函数显示一幅画面的 Bitmap (位图)，就会自动受到Android的仲裁和协调。但是，TinyX服务进程并非Android 内部的进程，TinyX和Android是两个不同的系统，所以drawBitmapO无法把TinyX也纳 入其仲裁和协调的范围。这样，要在Android系统上运行Linux的⑶I应用，图形界面的整 合就还是成为问题。而本发明的内容和特点就是为这个问题的解决提供一种方法，将TinyX提供的 图形界面整合到Android原生的图形界面中，使Linux的⑶I应用可以在包括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⑶I应用创建一个代理，凡是 Linux⑶I通过TinyX实施的屏幕显示必须经由这个代理；由Android统一管理FB的使用。1. 1)每当启动一个Linux⑶I应用时，就在Android系统中为其创建一个代理进 程AppProxy，这个进程与实际的应用进程“同生共死”，有着相同的生存期。1. 2)由应用代理进程AppProxy创建一个FB刷新线程；1. 3)修改TinyX的代码，将本来要写入FB的内容作为一个Bitmap写入一个中间 文件；1. 4)FB刷新线程每隔一段时间就将这个中间文件的当前内容通过drawBitmapO 画入FB，就象一个普通的Android应用需要画一个Bitmap —样。这样，Linux⑶I应用把屏幕显示委托给TinyX，而TinyX并不直接访问与显示屏 相连的FB，而是把显示的内容写入一个中间文件，而对于FB的写入则是由AppProxy通过调 用由Android提供的drawBitmapO完成的，所以会受到Android的仲裁和协调，其效果是 实现了 TinyX图形界面与Android的整合。由于TinyX是X视窗的一个子集，其源代码就是X视窗的源代码的一部分，本发明 所述方法同样也适用于X视窗。本发明有益的效果是本发明提供了一种代理机制，在Android系统中为运行于Android以外的Linux⑶I应用提供一个作为Android进程的代理，使Linux⑶I应用通过 TinyX进行的屏幕显示最终要通过这个代理才能显示出来。而这个代理，则由于是Android 内部的进程，也通过drawBitmapO进行显示，因此也受到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 里面。注意这里采用中间文件只是众多实施方式中的一种，实际上也可以采用共享内存 区(amredMemory)等等别的方式，这并不影响本发明的实质。附图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 在一个函数 fbdevlnitialize ()中通过 mmap ()将设备文件 /dev/fbO 映射 到内存中的一个区间，这段代码在源文件)(server\hw\kdrive\fbdev\fbdev. c中
6Bool fbdevlnitialize (KdCardInfo *card, FbdevPriv *priv) {
int k;
unsigned long off;
if((priv->fd = open("/dev/fbO", 0_RDWR)) < 0) { Il 将"/dev/fbO"改成"/tmp/TinyXfb，’ perror("Error opening /dev/fbO\n"); return FALSE;
}
if ((k=ioctl(priv->fd, FBIOGET FSCREENINFO, &priv->fix)) < 0) { //删去 perror("Error with /dev/fb ioctl FIOGET_FSCREENINFO")； close (priv->fd); return FALSE;
}
if((k=ioctl(priv->fd, FBIOGET—VSCREENINFO，&priv->var)) < 0) { //删去 perror("Error with /dev/fb ioctl FIOGET_VSCREENINFO"); close (priv->fd); return FALSE;
priv->fb—base = (unsigned char *) mmap ((caddr—t) NULL, priv->fix.smem_len, PROT_READ|PROT_WRITE, MAP—SHARED，
priv->fd, 0); //将中间文件“/tmp/TinyXfb”映射成虚拟的FB
if (priv->fb_base == (char *)-l)
{
perror("ERROR: mmap framebuffer fails!"); close (priv->fd); return FALSE;
off = (unsigned long) priv->fix.smem一start % (unsigned long) getpagesize(); priv->fb = priv->fb_base + off; return TRUE;
}这个函数先打开设备文件/dev/fbO，然后将其映射到某个内存地址(由内核决 定)，并将这个地址保存在priv- > fb_base中。这样，priv- > fb_base、实际上是与页面 边界对齐以后的priv- > fb，就成了 FB即屏幕在Xserver中的映像。现在要做的是用一个中间文件/tmp/TinyXfb取代/dev/fbO，然后同样把这个文 件mmapO到内存中的一个区间，这就为Xserver建立了一个虚拟的FB。这样，Xserver写 入这个内存区间、并且自以为写入了屏幕FB的图形，就实际上写入了这个中间文件。于是， feerver成为这个中间文件的内容提供者。将/dev/fbO替换成TinyXfb之后，这里的priv- > fd就代表着这个中间文件， 而不再是设备文件/dev/fbO。但是针对设备文件/dev/fbO的ioctl ()操作FBI0GET_ FSCREENINFC^P FBI0GET_VSCREENINF0对于中间文件TinyXfb是无意义的，所以要将这里的 两个调用ioctlO的语句删去。注意这里把打开设备文件直接改成打开中间文件是因为TinyX的实现建立在 mmapO的基础上，此后对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 ()。
所以，onCreateO就相当于C程序中的main()。下面给出有关的伪代码
public class RunAppActivity extends Activity {
......//这个自定义类中扩充出来的其它方法
private JniMethod mJniMethod = new JniMethod(); //需要用到 JNI
/** Called when the activity is first created. */ @Override
public void onCreate(Bundle savedlnstanceState) { //相当于C程序中的main() super.onCreate(savedlnstanceState);
创建FB刷新线程；
JniMethod.startApp(StartAppName.getBytes()); //启动执行 Linux那一边的 App
} //end onCreate
......//这个自定义类中扩充出来的更多方法
}这个Activity的任务之一是创建FB刷新线程，另一个任务就是启动Linux那一 边的应用，具体方法是通过Java语言的JNI机制调用其方法startApp，而JNI机制会自动 将其转化成对 C 语言函数 Java_Android_AppProxy_jni_JniMethod_startApp ()的调用JNIEXPORTjint JNICALL
Java_Android_AppProxyJni_JniMethod_startApp( JNIEnv *env,
j class clazz, j byte Array appName)
{
先将有关环境变量与appName整合出一个Linux App的全路径名name; pid_t pid = fork(); //创建子进程
if(pid == 0) {
//这是被创建的子进程，这个进程将运行Linux App。 system("/bin/sh", "/bin/sh", name, NULL) < 0); kill_proxy()； //使整个代理进程退出运行
return 1; //这是当前进程本身
}这段程序通过Linux的系统调用fork()创建一个子进程，然后让这子进程执行 Linux那一边的具体应用程序，并等待其退出，一旦应用程序推出就使整个代理进程退出运 行，这样就保证了代理进程与应用进程的“同生共死”。有关的这些程序设计对于Android应用的开发者而言应该没有什么困难，如有困 难可参阅“深入浅出Google Android","Pro Android”等参考书。注意这里的系统调用systemO要到作为目标的Linux应用退出运行或运行失败 时才会返回，所以一旦程序从systemO返回便退出整个AppProxy的运行。3、FB刷新线程。FB刷新线程的实现也很简单，下面给出其伪代码void fb_flush()
{
打开中间文件“/tmp/TinyXfb"; while(l) {
从中间文件读入其内容至一个缓冲区; 调用由 Android 提供的 drawBitmapO; 睡眠50毫秒；以上三个方面的实施保证了应用代理AppProxy具有与具体Linux应用基本相同 的生存期，而TinyX的输出都要经过AppProxy才能到达FB和显示屏，由于AppProxy通过 由Android提供的drawBitmap ()访问FB，受到Android的仲裁和协调，这就把TinyX的图 形界面整合进了 Android。最后，TinyX是X视窗的一个子集，TinyX的源代码是X视窗源代码的一部分，本发 明所述的方法虽以TinyX为目标，但同样也适用于X视窗。除上述实施例外，本发明还可以有其他实施方式。凡采用等同替换或等效变换形 成的技术方案，均落在本发明要求的保护范围。
权利要求
1. 一种在Android手机上整合TinxX图形界面的方法，其特征在于 1.1)每当启动一个Linux⑶I应用时，就在Android系统中为其创建一个代理进程 AppProxy，这个进程与实际的应用进程有着相同的生存期； 1. 2)由应用代理进程AppProxy创建一个FB刷新线程；1. 3)修改TinyX的代码，将本来要写入FB的内容作为一个Bitmap写入一个中间文件； 1. 4)FB刷新线程每隔一段时间就将这个中间文件的当前内容通过drawBitmapO画入 FB,就象一个普通的Android应用需要画一个Bitmap —样。
全文摘要
本发明涉及一种在Android手机上整合TinxX图形界面的方法，1.1)每当启动一个LinuxGUI应用时，就在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的整合。
文档编号G06F9/44GK102129369SQ20101061954
公开日2011年7月20日 申请日期2010年12月22日 优先权日2010年12月22日
发明者徐鼎鼎, 毛德操, 王承志 申请人:浙大网新科技股份有限公司