如果你在開發 Android 的應用程式，或即將打算開發，趕快加緊你的腳步吧! 只要在 Android Market 上，擁有評價 3.5 顆星以上，或是超過 5000 次以上的唯一下載次數，就有資格拿到 Google Nexus One 或 Motorola Droid 手機。不過僅有在這兩支手機已通過認證國家的開發者才有機會拿到。還好台灣也是其中之一。
差不多在三月三號，也就是我拿到小禮物那天，符合資格的開發者就已經收到這個通知信了。像我的朋友 LIME IME 的作者就得到通知。
雖然一開始有人以為是詐騙信，不過在求證 Google 後似乎已經得到了證實。看來 Google 為了力拼 Android 的佔有率，不惜砸下重金，以拉攏全世界的開發者，對抗競爭者(Apple?)。
當然這個機會目前是給已在 Android Market 經營出良好成績的開發者。如果現在才要開始寫還有機會得到手機嗎? 我也不知道啦。但我想應該是很有機會的… 只可惜我大部分的工作都是在做 Android 底層的移植，極少在寫上層的應用程式。不然我也想來試試…
老實說 Google 這樣的做法真的很聰明(或者說很邪惡?)。雖然說看似要花不少錢，但是跟 Google 一年的營收比起來真是不足微道。更何況它的效益驚人。因為開發者都是 power user，能帶來良好口碑和一票的用戶。這比其它的行銷方式更有效。
其實我當年在 ASUS 透過 EeeCommunity 計劃推動捐贈 Eee PC 給 Linux 社群的開發者就有同樣的意圖。只是我們的規模和強度完全無法和 Google 現在的做法相提並論…
一個多月前收到關於 Google Android Developer Lab 的消息。那時幾乎已經是報名的最後一天，趕緊上網填了資料寄出。過年前就收到通知，我得到參加的資格。也沒多想，直接記在行事曆當中。
今天就是這個 Developer Lab 在台北舉辦的日子。不過事情很多，加上這個會議從中午 12 點半就開始，連午飯都來不及吃。其實一開始有點不太想去。但為了有機會和 Android 開發者近距離接觸，還是決定參加。還好去了，否則可就後悔莫及。
報到時，領到一張綠色貼紙，被要求貼在胸前。我不是很喜歡在身上亂貼東西，不過還是照辦了。遇到在台北 Google 工作的朋友，他告訴我，等會將發小禮物。我問每個人都有嗎? 要是用抽獎的，我一定抽不到啦。他說是的，每個人都有。我心想 Google 給的禮物應該不會太差吧? 但了不起就是 T-恤之類的紀念品吧?
想不到，Google 的這個禮物還真不小哩! 接近中場休息時， Read more »
我已經將 MirBSD Korn Shell，簡稱 mksh，加入到 Android-x86 的 source tree 當中。版本是 R39c。和往常一樣，請利用 repo sync 取得並編譯。
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 SDK 和 NDK 來編譯含 JNI 的 Android 應用程式。但若是已有 Android (或 Android-x86)的 source tree，可能就不會再想安裝 SDK 和 NDK。因為 AOSP tree 本身就包含完整的 SDK 和 NDK。那麼是不是可以將含有 native libraries 的應用程式，加入到 AOSP 的 build system 中編譯? 這麼做還有一個更重要的理由，就是把你的應用程式和 AOSP 的源碼結合在一起，用單一步驟就可以完成所有的編譯。這樣有助於維護單一而自我包含(self-contained)的源碼。
答案當然是肯定的。經過一番嘗試後，發現只要稍微修改一下應用程式的 Android.mk 就行。具體的做法如下：
首先，將應用程式的目錄搬到 AOSP tree 的 packages/apps/ 目錄下。例如 packages/apps/hello。
再來，建立 packages/apps/hello/Android.mk，內容如下： Read more »
一般要建立 Android 的應用程式使用 Eclipse + ADT 最為方便。不過若是像我一樣慣用 command line 的人，可能會希望直接用指令完成。這可利用 Android SDK 和 NDK 辦到。
首先，用 SDK 的 android 指令建立一個 project：
$ android create project -t android-4 -k app.hello -a HelloActivity -p apps/hello/project
|
其中的參數：
Read more »
藉著 eclair-x86 branch 的釋出，順便 review 了一下 NDK for x86 的支援。原本的做法，要編譯給 x86 的 shared libraries 時需要指定 TARGET_PRODUCT=eeepc。但在加入多 x86 平台支援之後，「eeepc」其實已經不代表通用的 x86 平台。因此這個用法有商榷的必要。
另外 AOSP (以及 Android-x86)的 source tree 雖含有 NDK 和 toolchains，但 NDK 卻無法直接使用 AOSP 的 toolchains。還要叫使用者自行下載，真是多此一舉。
經過我的修改後，讓 development/ndk 可以直接的使用 prebuilt 中的 toolchains。同時，預設的 toolchains 就是 x86。因此不需要再指定 TARGET_PRODUCT=eeepc 了。
Read more »
一個多禮拜前 Google Android 開發者在 Android-platform 討論群上宣佈釋出 Android 2.1 版的消息。不過並不是放在 master branch 而是在 eclair branch。沒錯，2.1 版仍是叫做 eclair，因此只能算是個小改版吧?
經過一番努力，我們已成功將 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。又有許多苦功要做了…
Yi 已經釋出了 Android-x86 的最新測試版，這是基於 Android 2.0 (Eclair)的版本，距離上回的 1.6 版釋出已將近兩個月。之所以會拖這麼久，除了這段時間我們都比較忙碌外，最主要原因還是因為從 1.6 到 2.0 的變動相當大，但 Google 釋出的源碼僅是最後的 snapshot，中間沒有任何的修改歷程(changes log)。這造成我們 merge 上的許多困難。許多原本會動的東西都壞掉了，包括滑鼠、Wifi、Ethernet 和 suspend & wakeup 等，幾乎都得重新來過。
雖然經過兩個月的努力，問題仍未完全解決。比較重要的有：
- 沒有 i915 的 3D 硬體加速
- 雖然可連上藍牙耳機，但聲音出不來。
- 錄影功能無法使用。
不過除此之外，在 Android-x86 1.6 版所擁有的功能在這個測試版應該都具備了。
當然這個版本也加入了一些新的特色。 Read more »
關注 Android 開放源碼計劃(AOSP)的朋友應該會注意到，在 Google 的嚴密掌控下，Android 已經離開放源碼社群愈來愈遠。雖然形式上 Android 的確符合開放源碼的定義。但本質上，它是不折不扣的 Google 計劃，而非一個社群的計劃。從幾件事情上可以看出這樣的傾向：
- 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-x86 計劃開始之初，便已考量到儘量支援各式各樣不同的 x86 平台。在 Android build system 中一個 target 是指一項特定的產品。但 x86 平台有千百種產品，這樣的架構似乎並不很適用。只是一開始對 Android build system 系統也不是那麼熟悉，一時沒有更好的解決辦法。只好先沿用原本的 eeepc target，但其實並不是真的針對 eeepc，而包含所有可能的 x86 支援。反正先做再說，邊做邊改。
不過在更多開發者加入後，特別是加入了 q1u 這個 target 之後，這個問題已經到了必須解決的時刻。否則每一個 x86 target 都會有非常類似的檔案，這會造成維護上的很大負擔。
仔細研究 build system 後，發覺 target 之間是可以繼承的。例如大部分的 target 都繼承自 generic.mk 所定義的 generic target。仿照這樣的做法，我們可以定義一個 generic_x86 的 target，讓所有其它的 x86 target 來繼承。這樣做法有兩大優點： Read more »
回應(0) 
