文／Jollen Chen（原文刊載於 CTimes 零組件雜誌，2011年11月號）

經過10個月的等待，最新的Android源碼，千呼萬喚始出來。Android開始源碼專案，稱之為Android Open Source Project（即AOSP)，目前的最新版本是2.3，下一個AOSP將會是4.0。Google跳過Android 3.0的原因，據信是因為「Android 3.0程式碼不適合開源」，從技術面的角度來看，可能是碼源的組織結構尚未建全，以及架構設計並未經過全面驗證。

從目前已公開的Android 4.0 SDK來看，確實是一個「跨裝置」的作業系統。代號為Ice Cream Sandwich的Android 4.0強調「手機與平板」通用，在新特色列表裡，我們也能發現，應用程式面的特色增加不少。事實上，這次Android 4.0的發佈，Google並沒有說明框架或底層技術細節的變動，而是強調應用軟體面的新功能。

Android 4.0可以說是Android發展史的「第三個重要時代」。熱呼呼的Android 4.0源碼即將到手，廠商應該如何調整接下來的研發策略？在此提供一些想法，請不吝指教。

第一、產品公司的利基已經顯現。第三個Android發展時期，即Android 4.0的時代，訴求已經很明顯，那就是「應用軟體」。重視應用軟體，並不等於組織一個應用軟體研發團隊。實際上，Android Market近20萬個軟體，都是最好的「創意庫」。因此，Android 4.0對於產品公司特別有利基點，因為有了自有產品，才有機會專注在應用軟體與網路服務的整合，發展創新特色。

第二、系統廠應消除研發累贅。所謂的研發累贅，廣義上來說，可以是符合以下二個條件的工作：1. 重覆性工作、2. 研發成本過高的活動。重覆性工作視廠商性質不同而定，例如：感測器研發系統廠，「Android 移植」就是一個重覆性工作，因為接下來，廠商將能直接由「社群」或是「處理器原廠」取得完整度很高的參考設計，只需將重心放在感測器本身的整合，以及應用層面的創新等工作即可。研發成本過高的活動，說明在第三點。

第三、研發成本很低或無限大。研發成本過高的活動，內容千羅萬象，在這裡舉一個例子：「技術研究」。技術研究的目的在於「精確掌握接下來的軟體與技術趨勢」，例如：多核心（Multi-core）接下來的主流會是「異質性」或「同質性」模型。這樣的能力通常只有專家型公司辦得到，例如：知名的技術服務公司Infosys就是一個例子。Infosys曾經提過，「當企業無法跟上技術變化，創新過程將變得緩慢」，因為一但走錯研發方向，修正錯誤的代價將極為昂貴。因此，技術研究是自組團隊，或尋求專家公司的協助，需要經營者的智慧。

以上三個想法，主要是推測Android 4.0降臨後，產業現況可能會發生的化學效應，並取其重，當然還會有更多的變化，不只於這三個想法。面臨變化，新策略的制定，過去的經驗是否有幫助，這可能需要省思。企業經理人，可以從彼得杜拉克「巨變時代的管理」一書中找到一些想法，包含「徹底改造」也是巨變時代的一個藥方。

Google 將 Android 4.0 釋出後，製造了一波移植運動。Linaor 或是 xda-developer 上，都已經發佈 Ice Cream Sandwich 的移植成果。一些大家手邊常見的開發板，像是 PandaBoard 等，也都能運行最新的 Android 4.0 系統了。

在 Android 4.0 AOSP 上線後，手邊也開始了一個移植專案；經過一個多禮拜的努力，就在大有斬獲時，開發板就被 Porting 到壞掉了。不過，Ice Cream Sandwich 移植是一個令人熱血沸驣的工作，怎麼能這樣就休息呢。於是把在上課使用的 devkit8000 開發板拿出來「試試看」，這是我手邊現有的唯一開發板。

雖然 devkit8000 的硬體配置不算頂級（Cortex A8 600MHz 處理器、256M 記憶體），但因為 Linaro 發佈的 Release 11.11 與 11.12 都把 ICS 移植到 PandaBoard 與 BeagleBoard 了，所以我想 devkit8000 「應該」也不成問題。

上週在進行「Android Porting」的教育訓練時，也跟同學提到，「要把 Android 移植到可以開機」，並不是很難的工作，所以，這個任務的目標，就定為「只到可以開機就好」。於是，利用了週末以及今天下午的時間，進行了這項任務。

為了實驗：從 AOSP（Android Open Source Project）到能開機，並不是難事，所以我就從 AOSP 上取得原生的 Android 程式碼，開始了移植作業。Android 4.0 Porting 很有趣，而且也有一點挑戰性。

由於 Android 4.0 使用到 Wakelock 的 Early-suspend 功能，所以必須重新編譯 kernel，把 Power sysfs 打開。原本打算取用 Linaor 的 kernel，不過後來還是決定使用 rowboat 的版本，再加上 devkit8000 的 4.3 吋 LCD Panel 需要打一些補丁，最後是下載了 0xdroid 的 kernel tree，除了有包含 rowboat 的分支外，也維護了 devkit8000 的相關 patch。

工程師初老症第一條：能找到別人維護好、現成可用的 source tree，就不會有自已維護、打補丁的念頭。

不過最後還是對 kernel 做了一點小修改，包含 Touch Screen 的邊緣沒反應等小問題。這個版本目前維護在 moko365 的 github 上。

移植 Android 時，也修改了一些小細節。不過，大致上「編譯後放到板子上」就可以開機了。由於 dexopt 的 verify-and-optimize 所製造出來的 cache 資料量比較大，以及為了方便測試，所以我就把 kernel、ramdisk 與整個 system 都放到 SD Card 上開機。

最後做出一個只能開機的 Android 4.0 + Devkit8000。Graphics 的部份，使用的是 libEGL_android.so，也就是 Software OpenGL，並沒有硬體加速的功能。最後就是影片中看到的：Launcher2 起來後就掛了。所以，要到真正能用，還要再加點工。

在 Po 壞的板子維修完成前，Devkit8000 大概還要再陪我過幾天乾癮。

12.07 更新：Launcher 順利啟動

2011歲末時刻，要好好為自已上一堂「Lessons Learned」課程。

今年度有幾個 Android 專案，特別令人印象深刻，其中一個是有關於 Android 瀏覽器與 webkit 的計畫。因為開發專案的需要，修改了 Android 瀏覽器 (Browser) 的程式碼，也對 Webkit 做了些研究，沒想到這整個過程，倒是有點出乎我的意料之外；原本以為這是一個簡單，且能輕易結案的計畫，沒想到踩到 AOSP 的地雷。在這個瀏覽器開發專案接近尾聲時，在這裡分享一點甘苦談。

Google 採用 Webkit 做為 Android 內建瀏覽器的 HTML 引擎，Webkit 是相當知名的 HTML 引擎，由 Apple 公司做了早期的開發，現在則是成為了一個開源計畫，由社群開發者，以及部份公司，共同貢獻程式碼。

這個開發專案需要基於現有的 Android 2.2/2.3 瀏覽器，加入一些功能，並能整合伺服器端的服務，其中一個功能，需要使用到瀏覽器的 Copy/Selection 功能。就如同大家所知道的，Android 2.2 的 WebView 並沒有 Selection API，Android 2.3 在 WebView 加入了 Selection API，「但是卻沒有完整且良好的實作」。

原本天真的以為，「把沒有實作完成的 API 做完」，就可以交卷了，沒想到後續發展，根本沒有辦法寫劇本，到後期則是在兵恾馬亂的情況下，「補洞」加「救火隊」的方式搞定專案。這一切都要從 Android 的設計與實作講起。

部份的 API 設計過於鬆散，有些程式碼的實作也還是 prototype 階段；這就是開發 AOSP 的惡夢，工程師要面對鬆散的設計，以及不完整的實作，到最後只能拋開一切理想化的做法，開始進行捕洞與救火工程，然後希望下一個洞不要出現，眼不見為淨，希望專案早早收尾。

由於廠商需要同時推出 Android 2.2 與 2.3 的平板電腦，所以需要同時開發 2.2 與 2.3 的瀏覽器。但是，二個版本的瀏覽器程式碼有一些差距，為了簡化開發工作，並且讓程式碼更一致性，首先我做了一個工作，就是將 Android 2.3 的瀏覽器 Backport 至 Android 2.2。

這期間遇到一些小問題，例如：Android 2.2 並沒有 EdgeGlow 的功能。為了讓 Android 2.3 的瀏覽器可以在 2.2 上正常執行，也修改了 WebView 以及一小部份的 native webkit。Android 2.3 雖然支援了 selection API，但是並沒有實作「彈出視窗」的功能，在這個部份花了一點時間實作，因為希望儘量不去破壞 WebView 的 behavior，所以對 WebView 做了一次完整的研究。專案開始的初期，花費許多時間在了解 WebView 的設計。

文／Jollen Chen（原文刊載於零組件雜誌2011年12月號）

現在已經是軟體的時代了，有一個很有趣的現象在發生，部份軟體公司，「想連硬體設計都一起做」；許多硬體公司，積極想在軟體層面有所突破。從技術上的做法來看，軟體整合是硬體廠尋求突破很好的方向，但技術性太高。因此，若以軟硬結合取代軟硬整合，也就是硬體廠結合軟體公司，成為伙伴關係，或許是另一個不錯方向。

軟硬整合的難度有多高？Steve Jobs打從創立蘋果之初，就決心走軟硬整合的路，今天許多偉大的產品，雖然並不光靠「軟硬整合」技術取勝，但單就技術面來看，這肯定是一條「非常漫長的道路」。因此，硬體廠與軟體公司結合，成為策略合作伙伴，將是比較聰明又有效率的選擇。另外一個原因是，軟硬整合做得好，長期來看，應該要往消費性產品公司的願景邁進。

這半年來，為許多企業進行訓練工作時，可以感受到「決心改變」的氣氛；最特別的是，過去一些被認為是純硬體廠的企業，正努力地尋找好的「軟體策略」；因此，在這裡提出一些個人觀察與想法。

第一、軟硬結合。技術研發上，硬體廠透過軟體公司的協助，可以為硬體建立更多價值，並且也能在新商業模式的建立上有所突破。因此，與軟體公司或是軟體團隊，建立伙伴關係，並且學習新的軟體研發管理模式，是重要的功課。建立與軟體公司的伙伴關係，並且成功打造突破性產品的成功例子，當屬三星的手機產品。伙伴關係是一種共生系統架構（Ecosystem），對硬體廠來說才是最有利的做法，因為可以建立軟體伙伴對自已的認同感。

第二、研發管理。過去的軟體研發，特別在台灣，都是屬於門內做法（In-door），意思是招募自有的軟體工程師，並在內部完成研發專案。現在，有許多專案在初始階段（Initial Development Pase）都是採用戶外做法（Out-door）；簡單說，就是我們談論很久的社群模式，透過外部力量來完成工作。 軟體的研發方法不一樣了，關於這點，或許可以從我個人經營的軟體服務業務來說明；目前與客戶進行的部份軟體專案，客戶也接受了新的做法，讓社群上的個人開發者參與專案。因此，若採用戶外模式，專案的成功關鍵因素，在於是否能建立正確的研發管理方法。

第三、軟體是知識。軟體並不是程式碼，而是「知識」。知識包含想法、創意與專業學科等等。過去在本論壇，也和大家分享過「寫程式並不等於做軟體」的觀點。由於軟體是無疆界的「知識」，因此，策略與專案內容的擬定上，「不應該以硬體平臺做為出發點」；這是過去一直不斷發生的問題，許多計畫都是以硬體角度出發，容易因小失大。簡單說，專案的出發點，以及結果，「都只是在為硬體寫程式」，這是過去近二年觀察到的問題。

一直以來，硬體廠把軟體視為附屬品，或是將軟體公司做為外包廠的現象，在這半年來有了相當大幅度的轉變。這是一個以軟體為主的新時代，台灣硬體廠雖然一開始應變速度慢，起步也較晚，但是觀念的轉換速度卻很快，希望大家以期待的心情來看待。