六年前的2007年11月，Android开源项目（简称AOSP）正式公布。当时初代iPhone才刚刚面世几个月，苹果公司凭借这一里程碑式杰作将人们的想象力与开创精神推向智能手机新时代。尽管谷歌曾经扮演过初代iPhone的应用程序合作伙伴角色，但这家技术巨头已经隐约意识到如果不出手扼止、iPhone将在未来转化为颠覆性的巨大威胁。Vic Gundotra这样转述了Andy Rubin在Android首次发布时做出的声明：

他认为，如果谷歌不采取行动，那么我们将面临着严酷的未来。到那个时候，我们将只有一个人、一家公司、一台设备以及一家运营商可以选择。

面对这种由苹果最终主宰整个移动领域的可能性，谷歌感到惊慌莫名。有鉴于此，为了帮助当时在移动领域毫无立足之地的谷歌顺利对抗iPhone，Android选择了开源这一发展路线。

在那个时候，谷歌手中可谓毫无资本——既没有用户的期待、也没有哪怕一丝一毫移动市场份额。谷歌决定将Android免费推出并利用它作为承载谷歌服务的特洛伊木马。他们的思路是，如果谷歌搜索终有一天被iPhone拒之门外，那么人们也将停止在桌面系统中使用这项服务。Android相当于环绕在谷歌搜索这座“城堡”的“护城河”——它的存在完全是为了保护谷歌旗下的在线业务在移动领域的生存权利。

Android系统的市场占有率如火箭般节节攀升。

时至今日，情况已经发生了根本性变化。Android在智能手机市场上的占有率由过去的0%跃升至如今的接近80%。我们几乎可以说Android已经赢得了智能手机这场世纪大战——但Android胜出与谷歌胜出倒未必是一码事。由于Android的开源特性，这款移动系统的王者并不真正属于谷歌。任何人都有权免费加以使用、拷贝源代码并创建自己的fork或者后备版本。

正如我们通过WindowsPhone与BlackBerry 10身上所吸取的经验，对应用程序的吸引力是移动市场上的首要资本。在这方面，Android系统庞大的安装基础意味着它必然拥有海量应用可供选择。任何一家选择了Android阵营的企业都能保证自己的操作系统与数以百万计的应用程序相兼容；企业只需要建立自己的应用程序商店并上传全部应用产品即可。从理论上讲，这相当于在打造了一款非Android系统之外、在一夜之间就拥有不计其数的应用程序。不过如果有哪家公司能在Android身上做出超越谷歌的成就，那么它将立刻成为一家不容小觑的竞争对手，并极有可能威胁到谷歌在智能手机领域的现有优势。对于谷歌目前所处的地位而言，这样一款成功且足以取代Android的移动系统堪称最大的危机。

目前也确实有一些公司开始尝试从谷歌手中夺取对Android的掌控权，其中最成功且知名度最高的要数Amazon推出的Android替代版本Kindle Fire。Amazon接手了AOSP、忽略全部常用谷歌附加服务并建立起自己的应用程序商店、内容存储、浏览器、云存储以及电子邮件方案。此外，中国全境直接忽略掉谷歌Android——大部分谷歌服务被禁用，惟一的选择只有一套替代版本。在这两种情况下，谷歌的Android代码确实被广泛使用、但这却没能给谷歌带来任何回报。

如果身处像Android刚刚面世时那样的市场垫底、份额为零的位置，我们往往能以轻松的心态舍弃一些潜在利益。但在身处绝对统治地位时，继续坚持以开放换人气的路线就不那么容易了。Android已经从当初谷歌保护自身的工具变成了如今谷歌眼中的保护对象。移动代表着互联网的明天，而对全球普及度最高的移动平台加以控制必然带来无可限量的回报。但在这方面，把开源的诺言重新吞回肚子也绝不是件容易的事。这就引出一个核心问题：我们该如何对开源项目实施控制？

长久以来，谷歌一直利用某些保护手段对抗其它Android后备版本。很多人认为“Android”概念其实已经分裂成了两大类别：来自Android开源项目（简称AOSP）的开放部分，也就是Android的真正基础；以及闭源部分，由众多带有谷歌商标的应用程序构成。尽管谷歌永远不会极端到彻底取消Android的开源属性，但这家技术巨头似乎正想尽一切办法从这个无比耀眼的开源项目身上榨取回报。谷歌公司采取的主要方式就是把越来越多应用归纳闭源“谷歌”的大旗之下。

闭源蜕变

谷歌应用程序其实一直以来始终在走闭源道路。最初，闭源阵营中包含谷歌的多款在线服务，例如Gmail、谷歌地图、Talk以及YouTube等。当时Android手中毫无市场份额可言，谷歌也就安心保护好这几款应用，同时将Android的其它部分真正按照开源项目进行打理。随着Android在移动领域的地位日益提升，谷歌终于做出决定——需要对公共源代码拥有更多控制权。

对于其中某些应用程序来说，它们似乎仍然可以与AOSP划上等号；但随着其专有版本的推出，AOSP版本的所有工作都被叫停。开源代码的减少意味着谷歌的竞争对手需要将更多精力投入到研发当中。虽然我们无法真正扼杀一款开源应用，但却完全可以通过将其开发工作转为闭源模式实现遗弃效果。谷歌每一次对应用程序进行品牌化调整或者在Play Store中发布其新版本，就几乎意味着这款应用的源代码将被彻底关闭、AOSP版本也由此寿终正寝。

我们可以将搜索应用作为典型规范，看看谷歌如何在自己的品牌之下重复AOSP版本的功能。

2010年8月，谷歌推出了语音操作（Voice Actions）功能。在它的帮助下，该公司将谷歌搜索推向了当时的Android Market。当时的Android版本为“冻酸奶”，上图显示的正是AOSP搜索最新版本与Android4.3当中谷歌搜索之间的区别之处。如大家所见，AOSP搜索仍然停留在“冻酸奶”，也就是Android 2.2时代。一旦谷歌将其转化为闭源应用并投入运行，其开源版本的生命也会立刻走到终点。谷歌版本的搜索功能支持语音搜索、音频搜索、文本到语音转换、应答服务以及Google Now集成——也就是谷歌眼中的助理功能。而AOSP版本则只能进行网络与本地搜索以及……没了，就这些。

音乐

谷歌公司在2010年的谷歌I/O大会上首次展示了其云音乐服务，不出所料，就在同一时间AOSP的音乐应用被永远定格在了当时的版本。时至今日，AOSP音乐在外观与操作方式上仍然属于典型的“冻酸奶”应用。

Play Music能够访问谷歌的云音乐存储，外加大量音乐存储以及订阅选项。Play Music还经历了一系列用户界面重复设计，并逐步迎来对Equalizer均衡器以及Chromecast电视棒的支持。现在看来，AOSP音乐与Play Music已经完全不同，我们很难想象它们曾经一体同源。

日历

谷歌日历是闭源时间最晚的应用程序之一。谷歌将这一闭源消息丢给Android社区的方式相当有趣：现在stock calendar已经可以为每一位用户服务啦！我们现在能够通过PlayStore对其进行升级！还有更多功能等待着大家！（哦，在兴奋之余需要泼盆冷水，现在它已经变成闭源项目了。）

由于此次闭源转换刚刚结束，两个版本之间的差别还不是很大。谷歌日历能够在多台设备之间实现通知消息同步，应用图标也更具现代感。我是不指望AOSP日历能在未来的任何时刻获得这些更新了。

对比两张键盘设置界面的截图，我们会发现AOSP版本明显少了很多功能。

即使键盘设置这样的角落也未能逃脱闭源蜕变的魔爪。就在几个月之前，谷歌在键盘方案中引入了类似于Swype的手段打字功能，并将其作为新应用发布在Play Store当中——美其名曰“谷歌键盘”。猜猜由此产生的源代码怎么着了？在AOSP中不见踪影。通过上图，大家可以清楚地看到两套键盘方案在设置方面的差异。谷歌键盘拥有手势输入选项，AOSP则没有——随着谷歌键盘的发布，AOSP被无情抛弃了。

画廊/照相机

其实照相机与画廊同属于一个单独的APK（即Android应用程序包文件）。在AOSP版本中，该文件名为“Gallery2.apk”，而谷歌版本则名为“GalleryGoogle.apk”。如上图所示，大家会发现Photospheres功能这种创新型拍照模式仅存在于谷歌版本当中，AOSP就没这样的福气了。开源版本还缺乏Google+相册整合功能，它只能分别显示基于云的Google+相册与本地相册。

不过在这里我们需要对谷歌提出表扬。虽然AOSP版本仍然没能在功能方面跟上节奏，但在Android 4.3版本中出现的新设计已经被划归Android源代码之列。

未来动向

虽然目前尚未推出，但接下来将被转为闭源的应该是短信应用。尽管很多用户希望能在Android平台上享受到整合了短信功能的iMessage带来的视频群聊功能，但这同时也意味着我们将彻底告别短信功能的开源时代。一旦谷歌完成了这次转换，我预计这在未来一到两个版本中将会成为现实，那么短信应用将成为系统中的默认应用——正如谷歌利用Chrome取代网络浏览器一样（虽然Chrome的大部分组件属于开源）。

当Hangouts视频群聊应用与短信完成整合之后，AOSP的消息应用将被彻底抛弃。事实上，目前消息应用也已经半死不活了。（自从Android 4.0版本以来，它就没有获得过任何重大更新。）因此，当一切真正发生时，大家就会认识这一切的真正目的：开源短信应用已死、闭源短信应用当立。

左图：Android最新版本“巧克力棒”当中的“谷歌图片（Google Photos）”。右图：目前的“G+图片（G+ Photos）”图标。

下一位面临枪决的应用是开源版本的画廊。在Android下一个版本“巧克力棒”的流出图片中，我们发现一个名为“谷歌图片”的新图标。如果按照字母排序，那么“画廊（Gallery）”应该排在“电子邮件（E-mail）”与“Gmail”之间——但它非常可疑地没有出现。虽然我们之前从来没见过什么“谷歌图片”应用，但它与目前的“G+图片”应用图标完全一样。看起来AOSP画廊快要被遗弃了，顶替上来的是一款调度依赖Google+的闭源应用。好了，关于谷歌一手打造的“围墙花园”，我们先讲这么多。

锁定制造商

虽然谷歌正想尽一切办法拉低开源代码库的价值，但在这场权力的游戏中、应用程序并不是谷歌夺取控制权的惟一战场。

如果一家公司曾经管理过AOSP fork、克隆过谷歌应用并打造出一位足以向谷歌Android挑战的竞争者，恐怕仍然很难拉拢到厂商为其制造设备。在开放市场当中，我们能够比较轻松地找到Android OEM合作伙伴并在过程中推动其转变阵营，但谷歌希望让自己的地位变得更加稳固。谷歌在移动领域的真正王牌在于对谷歌应用的牢牢掌控——主要成员为Gmail、谷歌地图、Google Now、Hangouts、YouTube以及Play Store。这些才是Android的左膀右臂，而且每一家或大或小的设备制造商都希望它们能够登陆自己的手机产品。由于这些应用并非开源，因此只有获得了谷歌授权才能合法使用。说到这里，大家脑海里大概出现了一位完美的“教父”形象——没错，想使用这些应用程序，制造商当然得付出一点“小小的代价”。

尽管并不属于官方要求，但大家在加入了开放手机联盟之后会发现获取谷歌应用授权的难度会显著降低。所谓开放手机联盟是一系列向Android（注意，是谷歌的Android）做出承诺的厂商，其成员需要签订协议、声明自身不会开发未经谷歌批准的移动设备。没错，加入开放手机联盟意味着企业永远无法打造出可与谷歌Android进行竞争的Android fork衍生产品。

宏碁就曾经吃过苦头，当时该公司正尝试在中国打造运行阿里巴巴推出的阿里云操作系统的移动设备。阿里云属于Android fork，当谷歌听到风声之后、立即要求宏碁停止项目研发，否则将失去谷歌应用的授权许可。谷歌甚至在一篇公开博文中表示：

虽然Android仍然在以免费形式提供给任何用户，但只有与Android兼容的设备才能从整套Android生态系统当中获利。通过加入开放手机联盟，每一位成员都应为Android平台的创建做出贡献——而不是推出一大堆存在兼容性问题的版本。

这就让一众设备制造商的日子过得十分艰难，除了来自美国西部的无耻之徒Amazon。由于KindleOS属于Android的非兼容性衍生版本，没有哪家OEM厂商愿意为Amazon提供Kindle Fire的生产支持。有鉴于此，Amazon希望用钱买通制造商，旨在打造自己的下一代平板设备——在当时的收购名单中，这位云服务与零售业巨头曾考虑过宏碁、华硕、戴尔、富士康、富士通、HTC、华为、京瓷、联想、LG、摩托罗拉、NEC、三星、夏普、索尼、东芝以及中兴。目前，Amazon的签约合作伙伴是广达电脑公司，这是一家主营笔记本产品的企业——Amazon恐怕也没有太多其它选择。

对于OEM厂商而言，这意味着他们无法逐步从谷歌Android过渡到其它fork版本。只要他们推出一台运行着竞争fork的设备，下一秒就会受到死亡的威胁——被立即踢出Android大家庭，这样的严酷环境让每位成员都生活得战战兢兢。按照谷歌的计划，任何一家有意转投其它Android fork怀抱的厂商都将面临严厉制裁——别无选择的制造商只能跳下谷歌设置的悬崖、再无回头路可走。

而每一家希望获利谷歌应用许可的OEM厂商都必须通过谷歌提出的“兼容性”测试，从而证明自身符合授权资格。兼容性意在确保Play Store当中的所有应用都将正常运行在每一台设备之上。而对于谷歌来说，“兼容性”同时也是一种模棱两可的概念。正如某位Android工程师曾在一次内部发言中所说，这是一场“针对OEM厂商的考试，目的是确保他们按照我们的需要行事。”尽管谷歌如今推出了自动化工具来测试设备的“兼容性”，但要想获利谷歌应用许可，厂商还需要向谷歌发送私人邮件来“讨好对方”——当然，这是比较直白的说法。其中大部分沟通源自暗箱协议与秘密合同，所以我们的资料主要来自双方的公开争论以及谷歌与潜在Android叛逃者之间的法律诉讼（参见宏碁）。

另一大控制机制在于，谷歌应用的授权许可将全部应用作为一个单独整体来处理。也就是说，如果大家想要Gmail与谷歌地图，则必须同时带上Google Play Services、Google+以及其它任何一款谷歌想要添加进这份名单的应用。一家名为Skyhook的公司就用自身的惨痛经历证实了获取许可的艰辛道路。当时该公司打算开发一项与Android存在竞争关系的定位服务，如果用户开始选择Skyhook的服务，就意味着谷歌将无法从用户身上收集位置数据。这对谷歌而言当然不是好消息，于是Skyhook被理所当然地宣布为“兼容性测试不合格”。最终，OEM厂商只能在Skyhook服务与谷歌应用之间二选其一。虽然Skyhook公司就此提起诉讼，但目前诉讼结果仍然悬而未决。

利用臃肿软件进行试水

对于大多数OEM厂商而言，在脱离谷歌生态系统的同时还想继续保持成功无异于痴人说梦。惟一一种既开发自有应用、又不至于激怒谷歌大神的途径就是由OEM厂商自主打造免费的谷歌应用替代版本。这就是被大多数人就为“臃肿软件”的应用方案。臃肿软件的工作机制很像是软件工程中的“what if”逻辑关系，OEM厂商们通过复制谷歌旗下的全部核心应用来试探“围墙花园”之外的生活到底有多么艰辛。

三星的梦想：免费的谷歌替代方案。

三星这方面的工作做得相当“出色”，即尽可能多地推广自己的用户账户系统、后台同步机制乃至应用程序商店。但与此同时，设备上依然保留谷歌应用的整套原始方案。其中很大一部分，例如互联网、电子邮件以及日历应用，都立足于AOSP，但三星在谷歌放弃了这些开源方案转向闭源替代品后仍然继续为其添加新型功能。

在一台已经具备谷歌应用的手机上同时提供两款日历应用，这似乎显得既多余又愚蠢。但很多OEM厂商仍然将臃肿软件视为一种重要的战略后备机制——也就是B计划——并在真正面临被扫地出门的危局时拿来做最后一搏。这样如果谷歌真的把事情做绝，OEM厂商这边至少不会陷入“巧妇难为无米之炊”的境地。总而言之，OEM把自己开发的应用随手机一同发售并获取宝贵的用户反馈。虽然这种冗余方案令用户感到有些摸不清头脑，但仍然有一部分用户反而更喜欢OEM的核心应用版本——这实在是个好消息。

面对如上图所示的这样一份庞大的备用应用程序列表，看起来三星似乎随时准备脱离谷歌独自发展。但单纯复刻谷歌应用还只是三星为摆脱谷歌生态系统所做出的巨大努力中的一小部分。对于Android，OEM厂商真正想要的是来自第三方应用的广泛支持。谷歌也知道这正是自己的致命要害，因此该公司已经开始努力让应用程序生态系统对谷歌自身产生依赖性。

锁定第三方应用程序

我们之前曾经探讨过PlayServices更新所带来的影响，但它同时也是谷歌对抗Android fork的有力武器。PlayServices是一款由谷歌公司持有的闭源应用，而且也是谷歌应用授权许可包中的组成部分。任何一项由“正常”Android向GooglePlay Services迁移的功能都意味着它同时由开源走向了闭源。这款应用通过这种把戏不仅成功将用户汇聚到独家所有的闭源代码功能身边，同时也将第一方开发商牢牢锁定在了谷歌的专有API身上。

将Android应用生态系统从谷歌身上剥离看起来并不困难：我们只需建立起自己的应用程序商店并说服开发者向其中上传应用产品即可——轻松步入良性发展轨道。然而由Play Services所承载的谷歌API通过增强开发商对于谷歌的依赖性无情阻止了这一势头。谷歌为Google Play Services制定的战略目标在于让开发商的开发工作在经过谷歌批准的设备上变得更轻松——同时要想尽一切办法提高开发商在未经谷歌批准的设备上实施开发的难度。

如果大家正在使用任何一款谷歌API，同时尝试着让自己的应用程序运行在Kindle或者其它任何一个非谷歌AOSP版本之上：大惊喜！您的应用将直接损坏。谷歌的Android系统在目前的Android市场上占据极高比例，而开发商们所关注的无非是让自己的应用程序变得更易用、运作效果更好并赢得更多客户的青睐。谷歌API能帮大家实现这一切愿望，但带来的副作用就是应用程序会对谷歌的应用许可产生强烈的依赖性。

谷歌地图API

谷歌地图API允许我们在自己的应用程序中使用谷歌的地图数据。对于需要在地图之上覆盖对应天气图标或者显示当前位置的旅行应用而言，这实在是一种便利之极的机制。惟一的问题在于，谷歌地图是谷歌服务的一部分——而非Android的一部分。对地图API的依赖将导致我们的应用程序无法在非谷歌批准的设备上正常工作。

为了应对这一难题，Amazon被迫从诺基亚手中弄到了地图数据的使用许可并创建出一套可以正常使用的谷歌地图API克隆方案。该公司甚至专门提供说明页面，指导大家如何将自己的应用程序从谷歌地图中迁移出来。再次强调，谷歌的宗旨在于让开发商的开发工作在经过谷歌批准的设备上变得更轻松——同时要想尽一切办法提高开发商在未经谷歌批准的设备上实施开发的难度。如果想要让应用运行在Kindle设备上，我们就必须支持两种不同的地图API。

这对于Android的fork开发者来说无疑是种非常可怕的态势，这一次倒霉的是Amazon，他们不得不在两难之间做出选择：要么无限期向诺基亚支付许可使用费、要么自己着手对整个地球进行测绘。Amazon还面临着一大新难题，即跟上谷歌那轻盈的发展步伐：Amazon的地图API只支持谷歌地图API v1，但目前谷歌已经将API升级为v2。如果开发商在自己的应用程序中采用只有地图v2 API支持的新功能，那么Amazon将无法实现同样的效果。现在看来，要做的工作还有很多。

谷歌云消息

谷歌云消息（简称GCM）是在Android系统当中推送通知信息的最便捷途径，但AOSP再一次与这一切无缘。GCM在I/O 2013大会上刚刚被正式归入Play Services，现在它不仅能够接收通知、同时也可以向上游推送消息。它还负责在不同设备之间进行通知内容同步。开发人员通常利用GCM向设备推送突发新闻、提醒应用程序有新数据到达或者实现信息同步。

尽管谷歌地图在应用程序范围内的使用频率似乎并不太高，但事实上很多应用都需要借助地图的推送信息完善自身功能与使用体验。这项功能的重要程度让Amazon不得不被迫对其进行复刻——否则云巨头将在竞争中被彻底甩在后面。Amazon的版本名为“Amazon设备消息”，顾名思义，它只能作用于Amazon设备。与地图API一样，我们需要为这一小部分用户付出大量精力从事额外工作与测试任务。GCM的每一项功能几乎都无法在Amazon版本中直接找到——这意味着大家必须自己找到解决办法。

位置API

在谷歌I/O 2013大会上，谷歌公司革新了Android位置API并将其纳入Google Play Services。换句话来说，Android的顶级位置服务现在已经转向闭源路线。通过之前提到的历史发展轨迹，我们可以看到开源位置堆栈同样会被彻底遗弃。此次新加入的功能包括Fused Location Provider，一种经过“完全重新编写”的Android位置算法；Geofencing（允许我们在地图上定义位置，并在用户抵达该位置时触发应用程序中的事件）以及Activity Recognition，即利用加速计数据与复杂的算法识别用户正在步行、骑乘还是驾驶——这一切在无需开启GPS的情况下即可实现。

此举彻底让地图API与谷歌云消息沦为专有应用，因为这些功能需要由谷歌服务器提供功能支持。不过纵观整套位置堆栈，我们会发现这是谷歌一步步从开源手中夺权的过程。现在大家有两种方式来获得位置功能：效果好、功耗低但闭源的谷歌方式；还有精度差、超费电的开源方式。

应用程序购买

如果开发商希望自己的应用能够在Kindle上运行或者进入中国市场，恐怕只能想想其它的办法了。这又是另一个问题，如果大家希望拥有一套可行的AOSP fork方案，那就必须通过复刻来实现——这正是Amazon的做法，即推出自己的Amazon应用购买API。相比之下，仍然从属于谷歌阵营的三星也显得比较激进，曾在两年之前推出过自己的应用程序购买API。

Play Games

Play Games是另一种专有API，而且确实解决了大量对于移动开发者们来说最为头痛的难题。它能够轻松访问用户账户、排行榜、成就、云进度、反盗版以及实时多人游戏（Android平台）。最妙之处在于，它几乎能与一切对象并行协作，包括Web应用、iOS以及其它Android平台。好吧，又到了核心话题——除了AOSP，开源项目可不在Play Games的支持名单当中。这又是另一项第三方应用不得不严重依赖、备用Android版本则必须复刻才能获取的要素。

Amazon推出了一系列游戏API，并将其统称为“GameCircle”，不过它并不能像Amazon地图API那样作为Play Games的直接替代方案。开发商必须花时间自己鼓捣出一整套完全独立的多人游戏方案。

通过支持iOS进一步巩固锁定效果

谷歌战略中还包含着一套充满天才构思但已经濒临邪恶边缘的部分，也就是让九成谷歌API同时支持iOS。现在大家不妨从开发商的立场出发，思考自己到底要不要使用谷歌的API：大部分谷歌解决方案都能提供堪称业界最佳的实用性、功能性以及实施便携性。谷歌同时支持两大移动平台，因此大部分潜在用户群体都被涵盖在其中。惟一的不足之处在于，谷歌坚决抵制Android fork，而且任何AOSPfork对于我们的目标设备而言都是一块食之无味的鸡肋。

大部分开发商可能会对谷歌API表示友好，那么接下来的问题在于，他们该如何面对Kindle以及其它Android fork？开发商们在很大程度上需要依靠自己找到可以替代现有API的解决方案，但这类方案要么早已过时、要么无法与现有应用完美协作。如果其它解决方案无法完美取代现有机制，开发商就必须想办法通过应用程序设计弥补可能无法正常生效的功能。与现有iOS与Android手中的用户群体相比，这样的目标客户基础实在太过渺小，我们需要认真考虑是否值得为此建立一套独立的生态系统。为此投入的时间能取得相应回报吗？面对这样的状况，大家恐怕也会选择向Android fork竖起中指、直接跳过额外工作以及复杂的问题解决流程，直接投身于轰轰烈烈的谷歌Android开发大军。

三星不会改旗易帜

这里我们要验证的是，为什么Amazon能够脱离谷歌独立生存而三星不行。这是因为Amazon采取的是直接复刻谷歌API的路线，而三星目前尚未得到太多依附于谷歌的第三方开发商的明确支持。就目前的情况看，三星短时间内根本不可能彻底抛开谷歌的生态系统——直到他们推出自己的地图数据授权或者建立起一套云消息API。

Amazon在特立独行的发展道路上走得还算顺利，但这是一家诞生于互联网的企业。服务器及软件才是这家公司的强项，因此创建大量云服务对于他们并不是什么大不了的事情。相比之下，三星电子是一家电子企业——他们在血流中就缺乏创建云基础设施并打造大量API的能力。因此，尽管Amazon很可能在未来几年中依靠自家云服务平台的支撑将移动竞争优势整合进企业运营流程，三星仍然很难跨过横亘于面前的这道技术沟壑。

三星确实取得了一点点进展。正如前文所提到，三星公司已经开发出属于自己的应用购买SDK。有趣的是，他们还拥有一套广告SDK——但广告是真正能够赚钱的业务。正因为如此，谷歌在广告方面显得非常大方，同时为Android、iOS、Android fork甚至是WindowsPhone提供支持。

谷歌的开放是“只能看、不能摸”的开放

如果一家公司认真考虑通过Androidfork建立起足以向谷歌发起冲击的竞争者，那么这篇文章中的全部内容无疑都颇具指导意义。即使如此，大家也才刚刚迈出万里长征的第一步——接下来要做的是，为用户提供一个从谷歌Android中脱离出来、转而投向新Android fork怀抱的充足理由。

谷歌在内部打理着一切工作。这家公司基本上以免费方式获取地图以及其它全部云服务。任何想要追随其发展脚步的厂商都不得不放弃谷歌核心项目名单中的一部分条目。Amazon被迫购买诺基亚地图数据的授权许可，这就是个很典型的例子。谷歌在地图服务中搭售广告——这当然帮助其赚取了大量利润——相比之下Amazon却需要为每一位用户所免费使用的地图数据买单。这种完全不同的收入态势让Android fork无时无刻不饱受折磨。谷歌的服务成本低到甚至能够带来盈余，而任何其它竞争对手都必须每月向特定企业支付许可使用费。

退一步讲，即使某家公司成功打造出自己的Android fork并在谷歌生态系统之外获得了引人注目的成就，接下来面临的就是无人愿意合作的窘境。几乎每一家设备制造商都受到合约所限，无法接手新系统设备的生产任务。即使这套Android替代方案完美无瑕，对于OEM厂商而言，贸然脱离谷歌生态系统都既麻烦又危险——而天平的另一端只是一套前途未卜的新方案。

尽管Android确实“开放”，但这是一种“只能看、不能摸”的开放形式。我们可以为Android做出贡献并使用其中的一小部分功能，但几乎在每一个领域，想要在未经谷歌允许的前提下使用Android都会遭到极为猛烈的抵制。这一秒我们刚刚打算在Android上尝试一点谷歌并未批准的东西，下一秒钟整个世界就将轰然倒塌，只留下惊慌失措的我们独自伤神。

谷歌为Android制定铁腕政策：利用一切手段掌控开源