你以為 Android 是開放的嗎？Google 採用了一系列的控制手段來保證每一部 Android 手機上都有它指定的軟體和硬體規格。然而，他們同時又利用 Android SDK 裡面的 Apache 許可證來大肆鼓吹 Android 是開放的。

沒錯，Google 的移動平臺是當前最聰明的利用開源來驅動商業議程的實現。但在我們深入探討這個為什麼之前，我們先說說為什麼 Android 的成功和開源並沒有什麼關係吧。

是什麼成就了 Android

雖然早期飽受質疑，Google 的 Android 移動平臺已經在移動行業得到了營運商和手機廠商的廣泛支援，僅剩固執的諾基亞。Android 從 08 年的一款機型發展到 10 年的 50 多款，發展之快讓絕大多數的業內觀察家們吃驚。

Android 的成功和開源毫無關係。它的成功依靠下列三個主要因素：

- 蘋果 . 這點看起來很奇怪，Android 竟然是靠它的主要對手發家的？讓我來分析下。在 iPhone 空前絕後的成功以及蘋果對網路營運商傲慢苛刻的態度下，營運商們迫切的在尋找一種更便宜的選擇; 因此這些第一層最大的營運商們開始積極的用 Android 來開發手機給那些買不起 iPhone 的使用者，更重要的是，他們不需要每賣一部手機就給 Apple 300 歐元以上的回扣。

- 全世界的營運商們迫切希望自己鶴立雞群 . Android 給他們提供了一個統一的軟體平臺; 他們可以很方便的定製自己想要的系統，而且花費的代價也很低（3 個月的時間，這個比 SavaJe 12 個月以上的定製週期要短很多）。對大型的營運商來說，Android 也降低了他們在智慧手機軟體方面的投資。這也是為什麼大多數的 Android 手機專案背後都是營運商和 OEM 廠商的組合。

- 高通 . 這個市值 100 億美元的晶片廠商對 Android 的崛起功不可沒。手機開發產商可以直接拿高通已經為 Android 整合好的方案，在 9－12 個月的時間內向市場上推廣。（相比起來摩托羅拉的 CLIQ 花了 16 個月，而 HTC G1 則花費了 2 年多的時間）。除了高通，我們還有 TI 的 OMAP3 平臺（摩托羅拉 Droid／Milestone 基於此方案）。ST Ericsson 和 Broadcom 也在做 Android 的整合方案。

換句話說，在 Android 手機上，大多數的 OEM 預算花在了定製方面。而 Symbian 的絕大部分預算花在無線通訊的移植和硬體整合上了（Symbian 2001 年所做決定的結果）。總的來說，Android 使 OEM 廠商可以大幅削減研發預算，把錢花在定製這個刀刃上。當然我們不能忘記 Android 是免費的。這個免費讓眾多廠商激動不已。

話說回來，Android 用開源來做市場宣傳，非常成功的攪亂了整個行業，導致了諾基亞對 Symbian 的收購以及 Windows Mobile 的全面崩潰（不過譯者覺得 iPhone OS 4 的多重任務機制的釋出讓 WP7 真正成了杯具帝）。不過更重要的是，利用開源的名號和 Google 的魅力，Android 吸引了成千上萬的開發者，雖然 Android 並不能讓開發者們賺到很多錢，而且 Android 手機的數量不到蘋果產品的十分之一（連支援收費的國家都比蘋果少6倍）。

在開源的面紗後面

讓人更驚訝的是 Android 到底有多封閉，儘管外面包裹著 Google“不作惡”的口號和 Apache 授權許可證模式。借用亨利福特在 Model-T 相關的書裡的一句話：“任何人都可以自由挑選 Android 的顏色，只要那是黑色”（anyone can have Android in their own colour as long as it’s black）。Android 是一個絕好的商業案例——展現一家公司是如何用開源來贏得關注和社群參與，而且同時保持一個非常嚴密的商業運作。

Google 是如何控制著每臺 Android 手機裡採用什麼服務、軟體和硬體的？這個搜尋巨人建立了一套很完善的控制管理系統。為了挖掘更多的資訊，我們花了兩個月，和很多與 Android 有著緊密聯絡的內部人士進行了討論。我們發掘出的事實讓人震驚。從巨集觀方面說，Google 控制 Android 手機構成以下八宗罪：

1. 私有分枝 . Android 有多個私有分枝，這些只給幾個特定合作伙伴，往往是那些開發 Android 的 OEM 廠商，而且這些只提供給需要知道的人。這些私有分枝比已經公佈的 SDK 要超前起碼 6 個月，也是 OEM 廠商可以保持競爭力的關鍵。而公開的 SDK 則是為第三方應用提供私有分枝裡釋出的最新功能。

2. 封閉的評估流程 . 所有的程式碼評估員似乎都是 Google 員工，也就是說從社群提交的程式碼只有 Google 才有權力決定是否接受。而且 Google 內部還流傳著“並非此處發明”的一種思考文化，他們覺得 Google 員工寫的程式碼是天下無敵。隨便問任何一個給 Android 提交過補丁的人，你會得到一樣的答覆：幾乎沒有什麼提交被 Google 接受，而被拒絕的時候往往沒有任何理由和解釋。

3. 進化的速度 . Google 對 Android 的創新的速度是移動行業內絕無僅有的，他們在 18 個月裡釋出了四個大版本。想在 Android 上面做文章的 OEM 廠商只得緊跟 Google 的步伐（這裡想起了移動杯具的 OMS），不然就跟不上新功能的釋出和 bug 修復。Nexus One、Droid、G1 和其它帶有 Google體驗應用的手機給 Google 提供了創新的測試場。

4. 不完善的軟體 . 用公開的 SDK 並不能完整的建造手機。缺少的幾個關鍵的部份包括無線通訊的整合模組、國際化語言包、營運商資訊包以及閉源的 Google 應用，比如 Market、Gmail 和 Gtalk。雖然 Cyanogen 可以自己定製 ROM，但裡面包含的那些應用沒有授權，所以不能釋出在商業用途的 Android 手機上。

5. 閉門的開發者社群 . Android Market 是唯一一個擁有超過四萬個程式並和每個手機 OEM 廠商都簽有合約的 android 程式商店。這個限制很要命，因為沒有一個 OEM 廠商願意釋出沒有 Market 的 Android 手機（天朝是另類）。當然，在 Market 上釋出應用是個非常簡單的事情，沒有什麼審批的步驟，這個和蘋果的 AppStore 剛好相反。

6. 反分化合約 . 外界幾乎不清楚原來 OHA 的成員都簽署了反分化的合約。但這個合約更可以被理解為不能釋出沒有通過 CTS 相容測試的手機。（下面細說 CTS）（譯者注：貌似移動已經被踢出 Android 的私有分枝，是不是因為他們建立的 OMS 違反了這個協定呢？）

7. 保密的發展藍圖 . Android 的發展藍圖是很杯具的，到目前為止，公開發布的發展藍圖還停留在 2009 年的第一季度。如果想要看到內部的發展藍圖，你需要 Google 的賜福.

8. Android 商標 . Google 掌握著 Android 的註冊商標和冠名權。任何想用 Android 品牌的廠商都需要得到Google的授權。簡單的說：進 Google 的門，或者沒有門。如果你要自己做 Android 分枝，你就全部靠自己了，比如你需要中國移動那麼大的公司。

Android 的傳奇中還有個大篇章：CTS（相容測試組），也就是 Google 一套測試 Android 手機是不是達到 Google 的標準。根據我們的線人訊息，CTS 不僅僅測試軟體的 API 部份，它還包括效能測試，硬體功能，裝置設計，UI 使用者介面需求，和機內打包的服務。CTS 決定了你可以新增額外功能，但不能從最基礎的配置中削減功能。除了 CTS 以外，OEM 廠商還要和 Google 簽訂授權合同，這樣他們才能打包 Google 的服務，比如 Gmail、YouTube 等等。

CTS 限制了 OEM 定製弱化版 Android 手機的想法（譯者注：山寨的機會啊！MTK、中微星，年底釋出些低端 Android 手機吧！）這也大大限制了 Android 開拓低端市場的能力。CTS 和向前相容 4 萬多個應用的事實，極大的挑戰著 Google 想佔領智慧手機市場2位數的市場份額目標。這些限制，還有 Google 與 OEM 亦敵亦友的合作關係，使得 OEM 圈內掀起了建立 Android 基金的討論。

Google 的終極目標

手握 Android，Google 的目標是為自己產生收入的服務提供一個穩定的平臺。在當前，這個廣告生意。但未來，Google 的目標在語音服務（幾十億沒有資料服務的使用者）和 Google Checkout（比如變成移動領域的 visa 卡）。但不管 Google 的終極目標是什麼，我們應該意識到 Android 和 Windows Mobile、Mac OSX 或 PalmOS 相比，並沒有開放多少。Android 是用開源來驅動商業議程的最聰明的案例之一。Android 骨子裡並沒有我們潛意識裡所灌輸的那麼多不作惡思想。

By Andreas Constantinou from VisionMobile.com | lordhong 譯, 轉載自http://www.ifanr.com/9833

開發android程式有段時間了，moto的droid（milestone）, htc的hero，google的nexus one，都接觸過，android SDK 1.5,1.6再到2.01都使用過了，感覺這篇文章中所說的或多或少還是符合實際的