对于GUI来说，输入设备(如键盘和鼠标)和显示设备 (如LCD)都是与硬件相关的。在前面关于《事件源(FtkSource)》的一节中，我们看到了FtkSource很好的抽象了输入设备，让FTK独立于具体的输入设备，从而提高了FTK的可移植性。同样为了提高FTK的可移植性，我们需要对显示设备进行抽象。这里我们引入接口FtkDisplay来抽象显示设备：

在《主循环》一节中， 我们介绍了MainLoop 处理各个事件源的方法，它在事件源上等待事件发生，然后调用事件源的处理函数去处理事件。事件源(FtkSource)是对事件来源的一种抽象，事件的来源可能是一个输入设备(如键盘和触摸屏)，可能是一个定时器，也可能是一个网络套接字或管道。总之，只要实现FtkSource要求的接口，就可以让 MainLoop来处理了。

用Android模拟器运行FTK

以前写过一篇文章介绍如何在Androidr模拟器上运行FTK（http://www.limodev.cn/blog/archives/1400），那种方法有点别扭，而且要下载Android 的源代码才能编译。最近几个开发板都坏了，所以上周末研究了一下Android模拟器，自己生成文件系统，只是利用Android的模拟器来运行FTK。

Android的模拟器是基于qemu的，个人感觉qemu不好用，除了用Openmoko做的模拟器外，我还没成功用qemu来模拟运行过arm linux。Android在qemu做了不少人性化的工作，用起来比较方便。

0.请参考网上的方法安装Android SDK。

1.生成自己的init程序。

创建几个基本目录。

int init_dirs(void)
{
    umask(0);
    mkdir("/dev", 0755);
    mkdir("/system", 0777);
    mkdir("/dev/block", 0755);
 
    return 0;
}

创建MTD设备的结点。

int init_dev_nodes(void)
{
    int ret = 0;
    ret = mknod("/dev/block/mtdblock0", 0755|S_IFBLK, makedev(31, 0));
    printf("mknod /dev/block/mtdblock0 ret = %d errno=%d\n", ret, errno);
 
    return 0;
}

加载system.img 分区。

int mount_filesystem(void)
{
    int ret = 0;
    ret = mount("/dev/block/mtdblock0", "/system", "yaffs2", 0, NULL);
    printf("mount /dev/block/mtdblock0 ret = %d errno=%d\n", ret, errno);
 
    return 0;
}

运行FTK的桌面。

int startup_desktop(const char* name)
{
    struct stat st = {0};
    int ret = stat(name, &st);
 
    if(ret != 0)
    {
       return -1;
    }
 
    printf("starting the second init: %s.\n", name);
 
    if(fork() == 0)
    {
       ret = execl(name, name);
    }
 
    return ret;
}
 
int switch_root(void)
{
    int ret = chroot("/system");
    ret = startup_desktop("/opt/bin/desktop");
 
    return ret;
}

2.生成ramdisk.img

rm -rf ramdisk
mkdir ramdisk
 
cd init && make; cd - >/dev/null
 
echo "Generating ramdisk..."
 
cd ramdisk && find . | cpio -c -o > ../initrd; cd - >/dev/null
gzip initrd && mv initrd.gz ramdisk.img

3.生成system.img

if [ ! -d rootfs ]
then
    tar xf rootfs.tar.gz
fi

(在这里解压编译好的FTK（ftk-dist.tar.gz）到rootfsrts)

./mkyaffs2image rootfs system.img

4.拷贝生成的ramdisk.img system.img到SDK目录里。

echo "Copying files..."
for f in ramdisk.img system.img
do
    echo "  $f --> $ADNROID_SDK_IMAGES_DIR"
    mv -f $f $ADNROID_SDK_IMAGES_DIR
done

完整源代码和脚本请到这里下载：
svn checkout http://ftke.googlecode.com/svn/trunk/android-ftk-emu android-ftk-emu

hotmail的邮件搜索功能太难用了，逼着我用gmail了:xianjimli at gmail.com

这几天做Broncho A1的Android兼容性测试(CTS)，研究了一下Android的自动测试功能。它的执行流程如下：

Broncho A1还不支持基站和WIFI定位，Android的老版本里是有NetworkLocationProvider的，它实现了基站和WIFI定位，但从 android 1.5之后就被移除了。本来想在broncho A1里自己实现NetworkLocationProvider的，但一直没有时间去研究。我知道 gears(http://code.google.com/p/gears/)是有提供类似的功能，昨天研究了一下Gears的代码，看能不能移植到 android中来。

Broncho & A1

今天整理了一下以前写的一些小程序，全部开放源代码。详细见：

http://www.limodev.cn/projects.html

欢迎使用和完善。

在默认情况下，adb logcat只能显示应用程序的调试信息，我把logcat.cpp修改了一下，让它同时可以打印内核调试信息

Broncho新版网站上线欢迎访问

前段时间写一个程序，要向系统中注入mouse事件，我又不想信赖于具体的GUI，就写一个虚拟mouse设备驱动程序，感觉挺好用的，不过后来发现linux其实有一个uinput驱动程序实现了类似的功能。幸好后来才发现uinput这玩意儿，否则就没有机会去写了，有时真是宁愿知识面窄一点，这样才有机会重复发明一些轮子，从中获得一些乐趣。

有的应用程序起动过程比较长，在起动之后，一定时间内没有反应。为了避免让用户等得不耐烦，或者误以为死机了。在此期间，提供一个动画或者其它东西来标识正在起动的状态，可能会更友好一些。Startup notification的初衷也在于此，它跟踪应用程序的起动过程，以便给用户提供一些反馈信息。

KJAVA虚拟机Hack笔记-MIDP HighLevel GUI概述

MIDP 高级图形用户界面提供三种窗口，它们都从Displayable类继承过来：

共享内存

大家都知道，进程的地址空间是独立的，它们之间互不影响。比如同样地址为0xabcd1234的内存，在不同的进程中，它们的数据是完全不同的。这样做的好处有：首先是每个进程的地址空间变大了，让编写程序更为容易。其次是一个进程崩溃了，不会影响其它进程，提高了系统的稳定性。

金沙湾猎豹野战记

手机内置FLASH容量有限，在磁盘空间不足的情况下，应该提醒用户进行磁盘清理。这个处理在哪里做比较好呢？每次写入数据时由调用者检测显然是不合理的，因为处理的太多了，何况修改SQLITE等第三方程序也是不明智的，那样会给升级版本带来麻烦。比较好的办法是在文件系统中做处理，最近同事修改了yaffs2支持磁盘满通知功能。做法如下：

这两天在分析yaffs2文件系统，花了几天时间把yaffs2的代码通读了几遍，基本脉络差不多搞清楚了。在网上找到一些资料，对我的阅读有很大帮助，不过它们介绍得不太完整。接下来有时间的话，我会写一个yaffs2源代码分析的系列。一方面进一步加深对yaffs2的理解，另外一方面也希望对分析yaffs2的朋友有所帮助。

我们知道函数名就是一个内存地址，这个地址指向函数的入口。调用函数就是压入参数，保存返回地址，然后跳转到函数名指向的代码。问题是，如果函数在共享库中，共享库加载的地址本身就不确定，函数地址也就不确定了，那如何调用共享库中的函数呢？这就是本文要回答的。

非常高兴看到Android公布源代码，虽然这证明我对于android开放性的质疑是错误(其它观点保留)。

两则glib使用技巧

glib是Broncho平台的基石，几乎任何函数库，任何应用程序，以及任何daemon服务进程，都大量使用glib提供的函数。glib在我们平台中的地位有如STL在C++中的地位一样，熟练使用glib，对于提高开发效率有特别的意义，这里总结两则技巧供大家参考。

昨天从整体上介绍了一下音频处理流程，让大家对音频处理有个大致的概念，以便进行深入的研究。

昨天看了一下介绍蓝牙协议文档，今天索性对照看了看kernel里的代码(bluez)，这里记点笔记，还是继承了老毛病，只关注整体流程而忽略细节，先了解个大概，等真正需要时再仔细分析。