Fred's blog

話說，Android 在某個版本後，開始提供了 USB Host API，這代表開發者可以不必再用 NDK 和硬梆梆的 C 語言去開發 USB 裝置的驅動程式，而可以完全用 Java 來開發。但是，現實往往沒有這麼美好。 日前，就協助了一個案子，解決了一個 USB 裝置驅動程式的問題，起因就是客戶用了 Android USB Host API 去控制 USB 裝置，但發現 USB 裝置的回應一直不如預期，有時像是掉資料，有時像是沒反應。而同樣的控制邏輯，用純 C 開發的驅動程式配上 libusb 就完全正常，所以我們相信肯定不是控制邏輯上的問題。 剛開始，大家都懷疑是 Java 本身的問題，懷疑是不是 JVM 執行驅動程式太慢，而造成接收 USB 裝置的資料時來不及。但我一直保持著懷疑，因為 USB 裝置回傳的資料並不多，如果 JVM 本身的效能連處理這幾 KB 的資料量都如此差，就實在是太可笑了，我無論如何不相信。 還好最後還是解決了，雖然過程曲折。 USB Request Block 的 16KB 限制 事實上，每次最多傳送 16KB 資料，是一個 bulk transfer 的 URB 限制，使用 Android USB Host API 就會直接遭遇到這個問題，所以不管用什麼方法，怎麼收資料，只要資料太大，你最多一次就只能收到 16KB。 多次收資料所發現的延遲問題 當然，既然一次最多只能收 16KB，我們可以分多次向 USB 裝置要求收資料，但就會發現會莫名掉資料。從 USB 的分析器上來看，該有的命令都有，但就是有掉，後續的資料不管怎麼取都是 0。 後續資料為 0，在這個案子的 USB 裝置設計上是可以理解的狀況，因為該 USB 裝置只會保留資料一小段時間，然後就會清空，所以若之後跟它要任何資訊，他都會回傳空的東西回來。這很明顯，就是我們要資料的過程時間，已經超過了該 USB 裝置正常的情況。 而從收到的資料來看，有收到的資料，經驗證過後發現是斷斷續續的，中間有漏資料。經過測試，發現是每個命令之間的間距時間太長，因為該 USB 裝置會不斷復寫一段緩衝區，如果我們太慢去要資料，那段緩衝區就會被新的資料蓋掉，理所當然的，我們就會漏掉一些資料。 經過各種測試紀錄，很明顯的，Android USB Host API 並沒...

這是創業者的心聲，我們永遠為了為數不多的錢，拼老命和客戶周旋。在客戶面前包到好包到腳，扛的責任何其多，回來後又當業務又當 PM 還要當 R&D，最後還得當會計，數不盡的心酸誰知道。沒辦法，對我們來說，現金流（CashFlow）比什麼都還重要，能不能挺過這個月或下個月，維持周轉才是首要任務，為此，任何苦我們也得吃下。 筆者做了幾年的 Outsourcing，雖然不是當初創業的核心目標，但為了養家活口，接案卻成了主要業務。不過，筆者確實也因接案而活了下來並壯大團隊，能夠有機會持續朝理想發展。接案的過程中，風風雨雨自然不在話下，但慶幸受到前輩和朋友間的提攜，近來也總算是開始有個根基，剛好穩住腳。 接案就是這樣，有一頓沒一頓，如果要穩定收入，案子的價與量就必需相應提高，這是所有以接案當食糧的創業者，所都要經歷的過程。但是，往往在提升價和量後，案子開始會吃掉團隊的全部時間，漸漸失去當初創業的核心目標。然後，進入了『招人力』後『招案子』再『招更多人力』後『招更多案子』的惡性輪迴中，最終你會想：『辛苦到快暴斃，工時責任換算下來，賺得比去上班來得少，那我何必創業？』。如果你有同感，不用灰心，因為現在有無數的創業團隊和創業者， 也都正面對著同樣問題，甚至面臨崩潰。 有鑑於此，筆者尋思，何不與大家分享自己的經營成果，讓大家各自都能得到更多時間經營自己的核心目標？創業者、SOHO族和個人接案者所需要的源源不絕的食糧，不必各自重新發展重新耕耘，只需要從筆者這接手過去即可。由於舊有團隊原本已經有業務和PM的佈署，大家也可專注於技術性的工作，並提供如自來水般的技術供應即可。 對筆者來說，自己的核心技術團隊得以鬆口氣， 能慢慢以階段性放下養活自己的短期目標，有更多時間朝自己原本創業的核心目標前進。另一方面，也能給予其他創業者、SOHO族和個人接案者穩定的收入支持，不必重蹈覆徹筆者同樣的道路。如此雙贏的局面，樂見其成。 所以，如果你們是有技術的創業者或創業團隊，SOHO族或個人接案者，趕緊來報到吧！ 後記 無論你是專精或有經驗於哪一領域（Web、Linux、Android System（Integration/Porting）、Android App、iOS App 或 Embedded System... etc），都歡迎來信，最少先交個朋友也是不錯的。:-)

你將為自家的產品，選用什麼樣的作業系統？我想，這年頭，不外乎是 Android。但是，可能不是最佳選擇。 我想大多數人都會同意，由於智慧型行動裝置的掘起，Google Android 在業界大放異彩，使用 Linux 作業系統核心的 Android，實現了許多華麗的UI，也讓眾多廠商取得入門門票，有機會與 Apple iOS 一爭長短。許多人都相信，未來是 Android 的天下，除了手機要用 Android，電視要 Android，救人一命的醫療器材也要用 Android，所謂的 Android anywhere 是終極目標。 不過，經過這幾年下來，許多人發現這不過是我們資訊科技業一廂情願，有太多的領域是難以使用 Android，如工控市場等，無論是以穩定、價格、移植維護成本考量的因素，都可能是無法使用 Android 的重點。因此，如今要選擇作業系統解決方案，又變成一個需要思考的難題。 筆者擔任顧問時，每當面對客戶躊著於這個問題時，我總問他們幾個大問題： 你們的產品用途是否單一且單純？是否要有讓使用者自行上網安裝其他第三方軟體的擴充性？ 你們的產品是否為消費行電子產品？是否需要高可用行和高穩定性？ 你們的軟體需要有華麗特效的 UI 嗎？你們現在擁有的人員有哪些開發 UI 程式的經驗？ 有網路的需求嗎？如果有，需要哪些需求？Ethernet、Wifi、3G？ 計劃中的產品硬體規格？ 有多少規模的人可以參與開發？ 很明顯的，對於手機和行動裝置業者是這樣的答案：（他們都會選用 Android） 用途不單一，需要讓使用者任意自行上網安裝軟體。 是功能複雜的消費性電子產品，所以客戶多多少少能接受偶爾當機 UI 需要有華麗的特效。開發人員都熟悉並使用 Java 的經驗。 有所有網路的需求。 擁有一定等級以上或是當前最頂級的 ARM 處理器。 最少數十個，多半是上百人甚至上千人的研發人員。 如果你是『非手機』和『非行動裝置』業者，你的產品可能不完全具備這些條件。建議您，一旦有任何一點不具備，請慎重考慮是否使用 Android 還是有機會選擇其他的解決方案。 而當前的解決方案主要常見有三種： Android Linux + Qt Framework Linux + Own Application 限於篇幅，太細節的評估無法一...

有鑑於 Android 問題太多，只好定了個系列標題『Android 問題百出』當開頭，並將碰到的問題和解決或避開的方法記錄在內。話說回來，筆者個人其實相當討厭 Android，自 Android 出現以來，從未真的投入其中並賺過什麼錢，會接觸，多半是興趣玩弄或是幫一些朋友的公司臨時打工救火。不過，既然是救火，任何千奇百怪的問題或狀況都會遭遇到，甚至還得『限時』解決別人解決不了的問題。 這次碰到的問題就是 Android 2.3.x Gingerbread 缺少 JavaScript Interface 的實作，如果你的應用程式有自己實作 API 供 JavaScript 程式使用，那這些 API 將會完全失效。而這樣的問題，對於使用 Web 技術（HTML5 + Javascript）的應用程式來說，相當嚴重。 話說 Android 在 2.3 版本之後，採用了 V8 做為 JavaScript Engine。在快速掃過 Android 關於 WebView 和 WebKit 的程式碼後，發現不幸的是『Google 再次未將程式寫完』。但這一次，不只是功能未完成，而是將原本可以用的功能（在 Android 2.2），變成不能用。這讓筆者非常不能理解，為何 Google 換了 V8 Engine 後，明知功能沒有改完，卻仍將這部份實作隨新版 Android 釋出？然後，絕大多數廠商，在毫無感覺之下，直接繼承了這樣的 Bug。 對硬體裝置的廠商來說，重新實作這個 JavaScript Interface 支援是最佳的解決辦法，髒一點的方法是將 V8 改回舊的 JSCore。但很可惜的是，就算有人改好了，也沒有廠商願意釋出這部份的程式碼。（所以才會不停有人願意花大錢找筆者這種臨時救火工呀。） 此外，如果你是一般的應用程式開發者，因為動不了底層，則完全無解。但是，這邊有個 Workaround，可以暫時代替 JavaScript Interface，讓應用程式開發者可以避開這問題（以下假設自定的 JavaScript Interface Class 為 myAPI）。 定義將會用到的變數： /* Define private variable */ private static WebView mWebView; private static myA...

或許有些過於危言聳聽，但我們確實得正視這樣的議題：『資料無故從手機中消失』。這是可能發生的問題，原因在於 Android Dalvik VM 的 Garbage Collection 機制太過強大，如果程式開發者在寫程式的過程中都沒注意到這問題，那這肯定是個不定時炸彈。 話說，寫過 Android Application 的人應該都很習慣了變數宣告後，用完了就不管他，彷彿系統會有無限量供應的記憶體一般。不過，這對『慣C』一族來說，永遠是種荒繆的事，實在無法想像『憑什麼』不用釋放記憶體。其實說穿了，這一切是 VM 裡面的 Garbage Collection 在『Hold 住』場面，他會自動將目前 Reference 數量稀少的記憶體回收，以避免系統記憶體被用光後又不釋放。而所有回收的動作，有一系列『聰明』的演算法，有興趣的人可以自己去找相關資訊閱讀。 但是別以為 Garbage Collection 可以聰明到百分之百準確知道，什麼東西回收後是對系統或是應用程式無傷的，因為這就算要人腦來判斷，也一定會犯錯。更者，也別以為 Garbage Collection 不太會動當前正在跑的程式，因為只要符合條件，就算是你程式當前不斷在用的變數，也可能消失被回收，導致程式錯亂，就像被鬼憑空抓走一般。 如果你認為這只是理論，那你就錯了，這問題實際發生在最近筆者幫忙救火的案子裡。詳細情況是，這是瀏覽器相關的案子，當時我們宣告了幾個 Private 變數，然後使該變數在使用者操作觸發後，會被設定了一些數值供接下來的許多運算使用。一般情況下，我們實作的程式都很正常，不過，一旦開到比較複雜或充滿 JavaScript 的網站後，我們的程式彷彿就開始像中邪，完全不照我們的想像去執行，無論怎麼找問題，也找不出個所以然。 由於問題的發生是過程中變數無故被歸零，而我們又確定沒有任何一段自己的程式會讓他歸零，所以只剩下一種可能：『Garbage Collection 為了因應 WebView 過多的需求，而把變數給回收了。』 最後，我們將這變數設為 static 以解決這問題。不過，雖然用 static 暫時解決了問題，那也只是減少變數不被回收的機會，並不是最妥當的做法。 後記 別小看這問題，其實在 Android Framework 中也處處藏滿類似的問題，只是不知道...

還記得在某次的 COSCUP 與 Google 的龐教授，交流了一些 Android 方面的意見。由於他專精於 Compiler，我們也對 Dalvik Virtual Machine 的部份有些許的討論。當時感到非常榮幸，也覺得驕傲，因為這樣發光於全球的 Project ，也有華人在其中，更難得的是就在眼前。 最近空閒時間在研究一些 Android 的實作，煩腦之際，於 Google Code 發現了一個對岸朋友針對 apk 的逆向工程研究，有對 Dalvik VM 做了一系列的研究和說明，並開發了一支 apk 反組譯工具 [ dex2jar ]。如其名，該工具能將 DEX（Android apk 的格式）還原成 Java class 檔案，但更有趣的是，反向工程後的結果，不單只是 Binary 或 Bytecode，而是有『相當完整』的 Java 原始程式碼。 此外，在該 Project 的 Wiki 上，作者用『中文』記載了 [dex2jar] 的設計細節和反向工程所遭遇的問題，並寫了相應的解決手段，對技術有興趣的人可以去看看。 :-P 後記 如同該 Project 首頁所標註，還是請玩家在把玩這支程式時要『遵循 Google 相關協議與相關法律法規』。

As you know, Android was designed for mobile device, so there is no large value from Android for desktop environment. But there is no denying that Android has extreme applications resources. If we can combine Android and desktop environment, it will make great experience on Linux. By hacking Android framework, we made Android work on X with success, it is a "real" X application right now. You can see these screenshots: From screenshots, Android is running on Chromium OS, based on Android-x86 project . Currently, we can use chromium browser to surf internet and use Android application in the same time. In first screenshot, using "ps ax" to show all process on system to prove Android is running on X Server rather than emulator.

As you know, I've done Android Eclair porting for Devkit8000 in the past, which is based on Embinux. It's a experimental work for passing time, I have no time to maintain and fix bugs friends reported after that. However, I think it is not good because the result will be getting lost as time goes by. 0xdroid is another Android distribution which is different from Embinux, its developer  Jim Huang(jserv)  who has contacted me a few months ago, and he hope that I can try porting 0xdroid on the Devkit8000. Actually, I am glad to make 0xdroid takes over my work, it is the best result for me. Currently, I've done most works, 0xdroid can run on Devkit8000 with success. And also, My patches have been committed to 0xlab-devel mailing list. Because I have another platform SBC8100 which is also produced by Embest, I've done works on that as well. You can see my patches from 0xlab-devel mailing list, or you can visit my website to download it directly: http://people.lin...

Using Android on Devkit8000, we have problem of getting back to previous screen. The touchscreen can only be used to decide whether you select item or not, so a BACK button would be needed absolutely for Android. Devkit8000 board has four buttons on the corner, we can set one of it as Back functionality. First step, add a option to kernel config file to enable GPIO keyboard device: CONFIG_KEYBOARD_GPIO=y Second step, set USER_KEY as ESC Keycode for back functionality: diff --git a/arch/arm/mach-omap2/board-omap3devkit8000.c b/arch/arm/mach-omap2/board-omap3devkit8000.c index e86d254..ec17311 100644 --- a/arch/arm/mach-omap2/board-omap3devkit8000.c +++ b/arch/arm/mach-omap2/board-omap3devkit8000.c @@ -462,9 +462,11 @@ static struct platform_device leds_gpio = { static struct gpio_keys_button gpio_buttons[] = { { - .code = BTN_EXTRA, +// .code = BTN_EXTRA, + .code = KEY_ESC, .gpio = 26, .desc = "user", + .active_low = 1, .wakeup = 1, }, ...

If you would like to make Android work on Devkit8000, you can follow to patch your kernel which is mentioned in my old article( Android Eclair Porting for Devkit8000 ). After that you might notice the touchscreen doesn't work, it is a ads7846 kernel driver bug from Embinux. So I modified a few lines of code to fix the bug. Here is the patch: http://people.linux.org.tw/~fred/patches/devkit8000-touchscreen-android-kernel.patch

It's not only for fun! Porting Android is a great practice for me as well. Devkit8000 is a clone of OMAP3 Beagle(Beagleboard), so we can found many porting informations of Beagleboard from internet. It's helpful for us, we only need to deal with a few places which are some differences between Devkit8000 and Beagleboard. Google Android Eclair is working well on the Devkit8000 board now after I tried to port it last weekend. Here is the patch: http://people.linux.org.tw/~fred/patches/devkit8000-android-kernel.patch Based on Embinux , I added the Devkit8000 support, which includes: OMAP DSS Driver for display 4.3 inch LCD Panel support (480x272 60Hz) 7 inch LCD Panel support (800x480 60Hz) Touchscreen ADS7846 support Sound Codec (TWL4030) Keypad (TWL4030) Ethernet Device support (DM9000) Kernel Config for Android Compile Kernel with Devkit8000 kernel config: make omap3_devkit8000_android_defconfig make CROSS_COMPILE=arm-linux-gnueabi- uImage Kernel Comman...

近來，Android 的確炒翻了天，有人是欣賞稱讚它的設計，有人是衝著 Google 的名頭，仿彿 Android 就是所有未來，不但手機和 MID 上要用 Android ，就連 PC 上也要用 Android，是不是不久的將來，馬桶蓋上也要使用 Android？就像『奈米科技』一詞，Android 除了可以殺菌除臭，還可以烹調食物，增進色香之外亦可添加豐富的維他命 X 群，更或許還能抗掉髮，改善凸頭並加速毛法生長。Google Android 就如大家所說的，是一顆救全世界的萬靈丹？ PC 終究是 PC Android 的 Design，一開始就是以 Mobile 為出發點，它的用途不外乎就是手機、MID和一些零零星星的嵌入裝置，但因為一些廠商們的炒作，似乎有意將 Android 更進一步推至低價電腦(Netbook)的領域之上，在此不論廠商們的一廂情願，就以現在人們對低價電腦(Netbook)的觀點來看，Android 根本不可能勝任 PC 上的應用，至少，一般電腦使用者想要在 PC 上做的，Android 一定滿足不了。同樣原因，這也是為什麼 Windows XP 最後仍打敗了眾 Linux，在低價電腦市場中勝出的原因。 不適用的使用邏輯 Android 終究是為了 Mobile Device 而開發，同時間單功能的使用邏輯，完全不合 PC 族群的使用習慣，如此低價電腦(Netbook)只會變成大螢幕的手機，說它是手機不方便，說它是電腦又不好用，試問誰又會去買這樣一個四不像的產品？ 因為這樣的產品並不合使用者的需求，但卻肯定可以騙取一筆財富，無論是資金或是股票等等，所以，對於一般 PC 使用者，許多廠商宣布將會推出 Android Netbook，可稱之為騙錢，若嫌說法太惡毒，換種婉轉的說法就是商業手法和噱頭。可以預見，若與號稱輕量化且可在 Netbook 上跑的 Windows 7，Android Netbook 可說會再次重蹈 Linux on Netbook 的覆徹。一般用戶會買？沒人會信。 相差甚遠的架構 因為 Android 使用 Framebuffer 做繪圖，又有自己的一套 Framework，所以和傳統 Linux 上的 X/Xlib 架構相差甚遠，這意味著目前現成的 Linux Application 都無法在 Android Platfo...

外界炒得沸沸揚揚的『 Google Android 』手機平台，就在最近發佈了可移植到 x86 系統的消息，目前在官方的 Repository 上，立即可以取得針對 EeePC 701 的移植成果和所有 Source Code，令許多想玩 Gphone 卻苦無機會的人，燃起一線在 PC 上嘗鮮的希望，而更多的 netbook 廠商，更希望能夠讓 Android 在自己的硬體上玩耍一番。 Android 是一個 Google 所提出的開放手機平台計劃，先不論成果如何，就光憑著這樣大的名頭在後面撐腰，就已經足以席卷憾動整個資訊產業了。陸陸續續， HP 2133 也成為了可以支援 Andriod 的硬體名單之一，更多人在此時已經全心全意投入 Porting 的行列，可以預見，因為有心人的努力，未來應該可以看到 Andriod 在各種裝置上出現。 經過這兩天的努力，解決了一些問題後，可以很開心的向大家公開，『Acer AspireOne』也可以跑 Android 了！當然，有圖有真相： 由於 Android 並不是使用 X Server 做為影像的處理和輸出，而是直接存取 FrameBuffer，目前還無法在 x86 啟用繪圖晶片的硬體加速功能，所以在顯示效能上還有待加強，此外，一些硬體仍無法完全順利被 Framework 所支援，目前充其量只是有個展示可運作罷了。 畢竟 Android 還是以手機為起點，許多設計仍在 netbook 上格格不入，甚至是不良於使用，還需等待各界共同的改進。