Email me: jollen # jollen.org

more: Jollen 的 Embedded Linux 教育訓練

« November 2011 | (回到Blog入口) | January 2012 »

December 2011 歸檔

December 5, 2011

Android 4.0 源碼即將登場:產業將再起什麼變化?

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

移植 Android 4.0 到 Devkit8000 開發板 (OMAP3),只能開機、沒有硬體加速

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 順利啟動

December 23, 2011

Android 瀏覽器與 Webkit 專案心得:AOSP 心酸說不完

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 的設計。

December 31, 2011

硬體廠的軟體經營策略:建立軟體伙伴關係

文/Jollen Chen(原文刊載於零組件雜誌2011年12月號)

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

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

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

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

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

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


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

關於 December 2011

此頁面包含了在December 2011發表於Jollen's Blog的所有日記,它們從老到新列出。

前一個存檔 November 2011

後一個存檔 January 2012

更多信息可在 主索引 頁和 歸檔 頁看到。

Top | 授權條款 | Jollen's Forum: Blog 評論、討論與搜尋
Copyright(c) 2006 www.jollen.org