差不多在三月三號，也就是我拿到小禮物那天，符合資格的開發者就已經收到這個通知信了。像我的朋友 LIME IME 的作者就得到通知。

• Google 提供免費手機給開發者
• Google 拉攏開發商 免費賺到一隻 Nexus One

雖然一開始有人以為是詐騙信，不過在求證 Google 後似乎已經得到了證實。看來 Google 為了力拼 Android 的佔有率，不惜砸下重金，以拉攏全世界的開發者，對抗競爭者(Apple?)。

當然這個機會目前是給已在 Android Market 經營出良好成績的開發者。如果現在才要開始寫還有機會得到手機嗎? 我也不知道啦。但我想應該是很有機會的… 只可惜我大部分的工作都是在做 Android 底層的移植，極少在寫上層的應用程式。不然我也想來試試…

老實說 Google 這樣的做法真的很聰明(或者說很邪惡?)。雖然說看似要花不少錢，但是跟 Google 一年的營收比起來真是不足微道。更何況它的效益驚人。因為開發者都是 power user，能帶來良好口碑和一票的用戶。這比其它的行銷方式更有效。

其實我當年在 ASUS 透過 EeeCommunity 計劃推動捐贈 Eee PC 給 Linux 社群的開發者就有同樣的意圖。只是我們的規模和強度完全無法和 Google 現在的做法相提並論…

今天就是這個 Developer Lab 在台北舉辦的日子。不過事情很多，加上這個會議從中午 12 點半就開始，連午飯都來不及吃。其實一開始有點不太想去。但為了有機會和 Android 開發者近距離接觸，還是決定參加。還好去了，否則可就後悔莫及。

報到時，領到一張綠色貼紙，被要求貼在胸前。我不是很喜歡在身上亂貼東西，不過還是照辦了。遇到在台北 Google 工作的朋友，他告訴我，等會將發小禮物。我問每個人都有嗎? 要是用抽獎的，我一定抽不到啦。他說是的，每個人都有。我心想 Google 給的禮物應該不會太差吧? 但了不起就是 T-恤之類的紀念品吧?

想不到，Google 的這個禮物還真不小哩! 接近中場休息時，台上的講者宣佈，Google 將贈送每位參加者一支 Android 手機。因為是用英文講的，我還以為我聽錯了。直到主持人用中文再宣佈一次，並要大家到外面排隊領手機，我們才知道這不是在開玩笑。工作人員在我們胸前的綠色貼紙上蓋了章。而我們拿到手的，竟然就是我哈很久的，最新的 Google Android 手機 Nexus One。市價將近台幣兩萬元，Google 一口氣就送出兩三百支，真是大手筆呀! 現場看過去，每個人都是眉開眼笑。雖然有個人告訴我，他才剛買了一支，不到一個月，真是冤枉。我笑說早買早享受嘛，何況你還可以賣掉!

接下來的議程 Android 開發者在講解 Android 2.1 SDK 的新特色，例如 live wallpaper 的製作方式。不過說實在的，我們大都沒心情聽，只在把玩手上的小禮物。由於會場的電源插座不夠，我只能用 USB 線連接 Eee PC 充電。所謂拿人的手短，本來還想罵罵 Google 的，也暫時先封口囉… :p

唯一的副作用是，回到家後，老婆看了也很心動，看起來很想再敗一支的樣子。我警告她別衝動，免得我的卡要遭殃…

本來要寫開箱文的。不過看起來有人動作很快，已經寫了。我就偷懶一下。想看照片的請自行跳轉過去吧…

新聞也報出來了：

• Google送台灣Android開發者Nexus One手機
• Google台灣開發者大會 每人送一支Nexus One

不過現場有歡呼聲嗎? 我記得是沒有啦。因為剛宣佈時，大家都是一副不可置信的表情，還以為是在作夢哩!

Mksh 是從 Ksh 衍生而來的，主要用在 MirBSD 當中。其採用的授權是 BSD style，因此和 Android 的 Apache 授權相容。目前 mksh 的 patches 已經被提交到 Gerrit code review 審核當中。這是由 mksh 開發者 Thorsten Glaser 所提供。

我們用 mksh 來取代原本 Android 功能很弱的 /system/bin/sh。它擁有現代 shell 的許多特色，包括了指令歷史記錄(可用上下鍵選擇)、Tab 補齊(按 Tab 鍵可補齊指令、檔名等)、歷史搜尋(按 Ctrl-R)等。它也內建了 test 指令(也就是 if test … 這樣的指令可以執行了)。細節請參考 mksh 的網站： http://mirbsd.de/mksh。

答案當然是肯定的。經過一番嘗試後，發現只要稍微修改一下應用程式的 Android.mk 就行。具體的做法如下：

首先，將應用程式的目錄搬到 AOSP tree 的 packages/apps/ 目錄下。例如 packages/apps/hello。

再來，建立 packages/apps/hello/Android.mk，內容如下：

$(call build-package)

LOCAL_PATH:= $(LOCAL_PATH)/jni
include $(CLEAR_VARS)

LOCAL_MODULE := libhello
LOCAL_SRC_FILES := hello.c
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
LOCAL_SHARED_LIBRARIES :=

include $(BUILD_SHARED_LIBRARY)

這個 Android.mk 包含了兩部分。第一部分是編譯 java code 產生 apk，這是由 build-package macro 所完成。這個 macro 是 Android-x86 加入的。若你用的是原始的 Google AOSP 並沒有此 macro。不過用原本的 Android build system 規則，直接指定 LOCAL_PACKAGE_NAME、LOCAL_SRC_FILES 等變數也可以。

第二部分就是 native libraries 的編譯規則。其中有幾個和 NDK 裡 Android.mk 不同的地方值得注意。一是要在 LOCAL_C_INCLUDES 指定 nativehelper 目錄的位置。否則的話，就要修改源碼中的 #include <jni.h> 成為 #include <nativehelper/jni.h>，不然會找不到 jni.h。另一個不同的地方是，若原本在 LOCAL_LDLIBS 指定 link 了其它的 libraries，要改成用 LOCAL_SHARED_LIBRARIES 來指定用 AOSP 的 libraries。以 san-angeles 這個 sample 為例，它原本是

LOCAL_LDLIBS := -lGLESv1_CM -ldl -llog

必須改為

LOCAL_SHARED_LIBRARIES := libGLESv1_CM liblog

還有一點不同是，LOCAL_MODULE 一定要以 lib 開頭(上例就是 libhello)。不像 NDK 的 Android.mk 裡，好像用 hello 或 libhello 都行。

這樣子照原本編譯 AOSP 的方法，就可以編出包含此應用程式的 image 了。不過和 NDK 不同的是，它的 shared libraries 是放進 /system/lib 裡，apk 裡並不包含 .so 檔(可以用 unzip 解開來看)。

參考：

• Android Native code 不用 NDK

如果有人有更好的做法，歡迎分享。

首先，用 SDK 的 android 指令建立一個 project：

$ android create project -t android-4 -k app.hello -a HelloActivity -p apps/hello/project

其中的參數：

• -t 指定 Android API level，android-4 代表 Android 1.6 版。
• -k 代表 package namespace。
• -a 代表 Activity 的名稱。
• -p 代表 project 的放置路徑。

再來，建立 apps/hello/project/jni/ 目錄，並將你的 C/C++ code 放置於此。然後建立 apps/hello/project/jni/Android.mk 內容類似如下：

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := libhello
LOCAL_SRC_FILES := hello.c

include $(BUILD_SHARED_LIBRARY)

其中 LOCAL_MODULE 就是 native shared library 的名稱，而 LOCAL_SRC_FILES 裡應列出這個 library 的所有 C/C++ 源碼。

再來建立 apps/hello/Application.mk 如下：

APP_PROJECT_PATH := $(call my-dir)/project
APP_MODULES      := hello

如此就可以透過 NDK 和 Ant 來編譯，產生 apk 了：

$ make -jX V=1 APP=hello
$ ant -f apps/hello/project/build.xml debug

另外 AOSP (以及 Android-x86)的 source tree 雖含有 NDK 和 toolchains，但 NDK 卻無法直接使用 AOSP 的 toolchains。還要叫使用者自行下載，真是多此一舉。

經過我的修改後，讓 development/ndk 可以直接的使用 prebuilt 中的 toolchains。同時，預設的 toolchains 就是 x86。因此不需要再指定 TARGET_PRODUCT=eeepc 了。

簡單來說，只需下列步驟就可以使用 Android-x86 source tree 中的 NDK：

$ cd development/ndk
$ sh build/host-setup.sh
Checking host development environment.
NDK Root   : /home/cwhuang/git/android-x86-2.1/development/ndk
GNU Make   : make (version 3.81)
Awk        : awk
Platform   : linux-x86
Generate   : out/host/config.mk
Toolchain  : Checking for arm-eabi-4.2.1 prebuilt binaries
Toolchain  : Checking for i686-unknown-linux-gnu-4.2.1 prebuilt binaries

Host setup complete. Please read docs/OVERVIEW.TXT if you don't know what to do.
$ make APP=hello-jni

其中 hello-jni 也可以換成其它的 sample applications：hello-gl2, san-angeles, two-libs

如果想編譯給 arm 用的版本也可以。只要指定 NDK_TOOLCHAIN 為 arm 版本就行。例如：

$ make NDK_TOOLCHAIN=arm-eabi-4.4.0 APP=xxx 

記得 repo sync 一下取得我最新的修改。

經過一番努力，我們已成功將 Android-x86 更新到 eclair 2.1 branch 上。遵循 Google 的慣例，這個分支就叫做 eclair-x86 branch 吧。取得的方法和以前差不多：

$ repo init -u git://git.android-x86.org/manifest.git -b eclair-x86
$ repo sync

也可從 SourceForge 上的 mirror 下載。

不過 2.1 版新增的許多 3D 效果，像 Gallery3D，在 x86 版本上不是跑不動就是會 crash。又有許多苦功要做了…

雖然經過兩個月的努力，問題仍未完全解決。比較重要的有：

• 沒有 i915 的 3D 硬體加速
• 雖然可連上藍牙耳機，但聲音出不來。
• 錄影功能無法使用。

不過除此之外，在 Android-x86 1.6 版所擁有的功能在這個測試版應該都具備了。

當然這個版本也加入了一些新的特色。最重要的一點大概是由 Bryan 為 Q1U 所加入的觸控螢幕校正功能，已經整合到一般的 target 上。一個 target 只要定義 BOARD_USES_TSLIB=true，在開機進入 Android-x86 之前，便會先執行 tslib 的工具程式 ts_calibrate 來做校正。只要在左上、右上、右下、左下和中間的十字各點一下，就能完成校正。接著進入 Android-x86 後就能正確的使用觸控螢幕。校正的結果只需做過一次便會儲存下來，下次開機就不用再做了。當然這是指安裝到硬碟的情況，若用 live CD 或 live USB 的方式開機，就無法儲存了。(其實也不完全正確，如果你懂得設定 DATA 變數的話還是可以儲存下來)。另一個改進是加入 Eee PC 的螢幕背光控制。這也是在有了x86 多平台支援後才加入的最佳化功能。

想要嘗鮮的人可以下載回來試試。不過若是以為 Eclair 版本有什麼令人驚艷之處，恐怕要大失所望了。光是圖型處理的效率非常低落，就令人難以接受。只希望在加回 3D 硬體加速之後能有所改善。但如果你是開發者，歡迎跳下來一起幫忙 debug!

• Android 2.0 完全沒有發展歷程(git log / history)。
• 其實根本沒有 Android 2.0 的源碼。目前 AOSP 上的版本是介於 2.0 到 2.0.1 之間的一個 “snapshot”。更遑論即將上市的所謂 2.1 版了。
• 絕大部分社群送上去的 patches 都被忽略。從 eclair 之後似乎僅有五個 patches 被接受而已。
• Project roles 頁面被修改，移掉大部分讓社群參與的字眼 (剛好被人抓包，把舊的頁面 diff 呈現在此)。
• Google 的工程師不在 android.git.kernel.org 上工作。
• 愈來愈多衍生的開放源碼計劃(android-x86, embinux, 0xdroid, rowboat, odroid, …)，代表許多社群開發者已受不了 Google 的態度。

誠心的建議，Google 應該捫心自問，當初決定開放源碼的初衷是什麼? 到底要走向開放的市集模式，擁抱社群，還是走回更封閉的教堂模式，關起門來自己搞?

如果決定擁抱社群，便應該回歸開放源碼開發模式的基本精神，「儘早釋出、儘快釋出」，讓更多人有機會檢視 Android 的最新源碼，因為「在眾人面前，所有的錯誤都是淺顯的」(Linus 定律)。同時更應重視社群的力量，儘快的 review 社群所提出的修改建議，絕不可放著幾個月都不理。這樣有心貢獻的人心早涼了! 唯有在對的方向做對的事情，才能讓開放源碼的輪子順利轉動，帶起 Android 開放社群的蓬勃進步。

明天下午有機會應邀到台灣 Google 演講，正好把這些觀點與 Google 的工程師討論討論。投影片已公開在 Google docs 上：

參考：

• Android 不是那麼開放
• AOSP 週年慶…

不過在更多開發者加入後，特別是加入了 q1u 這個 target 之後，這個問題已經到了必須解決的時刻。否則每一個 x86 target 都會有非常類似的檔案，這會造成維護上的很大負擔。

仔細研究 build system 後，發覺 target 之間是可以繼承的。例如大部分的 target 都繼承自 generic.mk 所定義的 generic target。仿照這樣的做法，我們可以定義一個 generic_x86 的 target，讓所有其它的 x86 target 來繼承。這樣做法有兩大優點：

• 將所有 x86 平台共用的規則集中在此，避免重複，方便維護。
• 讓特定的 target 有機會針對其硬體做最佳化。

經過一段時間的試驗修改，已完成了 generic_x86 target。仿照 generic target，放在 build/target/board/generic_x86。將原本 eeepc target 之下大部分的東西都移到這裡，例如 keymap 和 firmware 的檔案。相對的，eeepc target 已修改為僅支援 ASUS Eee PC family，包括 Eee PC 背光支援以及針對 Eee PC 最佳化的 kernel 設定檔。

請特別注意這意味著 eeepc target 將不再支援一般的 x86 平台。也就是說，如果你用的不是 Eee PC，那麼指定 eeepc 為 target 所編出來的 image 很可能在你的機器上開不起來。

解決的方法有兩種：

• 改用 generic_x86 target
  

  $ make iso_img TARGET_PRODUCT=generic_x86

  其實 TARGET_PRODUCT=generic_x86 可省略，它是預設的 target。

• 針對你的硬體自訂一個 target。細節請參考這封信的說明。我建議你儘量這樣做，一來可以針對你的平台做最佳化，二來可以把你的成果貢獻回來。

目前多平台的支援僅放在發展中的 master branch。至於是否反向移植到 donut-x86 branch 還在考慮中。