Google是如何逐步牢牢控制开源系统Android的.docx
《Google是如何逐步牢牢控制开源系统Android的.docx》由会员分享，可在线阅读，更多相关《Google是如何逐步牢牢控制开源系统Android的.docx（8页珍藏版）》请在冰豆网上搜索。
Google是如何逐步牢牢控制开源系统Android的
Google是如何逐步牢牢控制开源系统Android的？
“开源”就如一只妖精，一旦放出来让它回到水晶瓶里可没那么容易，Google究竟如何控制一个开源平台呢？
虽然Google已经在千方百计地削弱开源代码库的价值，但通过升级app并使其闭源化并非Google赢得这场博弈的唯一法门。
对绝大多数OEM品牌商、第三方应用开发者而言，选择闭源的GoogleAndoid已是一个“无法拒绝的邀约”，Google极为优质的API资源已然让OEM们和开发者在相互牵制中无以自拔地“团结”在Google周围，任何衍生版的Android（AndroidForker）都难于突围，任何违法Google禁令的依附者都不可避免地受到惩罚。
锁定OEM制造商
虽然Google已经在千方百计地削弱开源代码库的价值，但通过升级app并使其闭源化并非Google赢得这场博弈的唯一法门。
即使半路突然杀出一个更具威力的Android来，它也很难博取广大制造商的支持。
在一个充分竞争的市场中，谈妥一个OEM厂商并不是难事，但Google正让这变得越来越难。
Google在移动端的控制力主要源于app群——Gmail、Maps、GoogleNow、Hangouts、YouTube和PlayStore。
这些都是Android的杀手级应用，大大小小的制造商们都希望它们出现在自家的设备上。
可这些app并非开源的，因此它们须得到Google的授权。
这让人自然而然联想到电影《教父》中的场面，因为“这是一个无法拒绝的邀约”。
虽然这不能算是硬性条款，但加入OpenHandsetAlliance（OHA）而获得Google授权会让日子好过得多。
OHA是一个与Android——Google的Android达成协议的公司联盟，按照协定，未经Google允许各公司皆不得生产相关Android设备。
一个公司加入OHA就等同于签署了卖身契，其设备也就不能运行其它版本的Android系统了。
Acer就是因为采用了阿里巴巴的阿里云系统（一个Android衍生版本）而受到了惩罚。
Google获悉后马上就切断了它的Googleapps接入权。
为此Google甚至发了篇官博来解释：
“虽然Android面向所有人开放，但只有兼容Android的设备才能从完整的Android生态中受益。
任何加入OpenHandsetAlliance的成员都应致力于建设一体化的Android平台——而非一系列不兼容版本。
”
这让西方世界唯一一个坚挺抗争的“异端”Android设备品牌亚马逊日子很难过。
因为KindleOS属非兼容版本，任何主要的OEM厂商都不得为亚马逊生产KindleFire。
所以亚马逊寻找其下一个平板生产商时，它不得不自觉地绕过Acer、Asus、Dell、Foxconn、Fujitsu、HTC、Huawei、Kyocera、Lenovo、LG、Motorola、NEC、Samsung、Sharp、Sony、Toshiba和ZTE这一长串名单。
目前，亚马逊将其Kindle设备的订单一股脑地承包给了QuantaComputer,一个笔记本电脑生产商。
这或许是亚马逊的无奈选择吧。
这意味着任何“移情别恋”的OEM都会招致死神之吻，被踢出Android阵营。
跟Google一刀两断对任何一家OEM来说都很可怕，选择GoogleAndroid就是一条骑虎难下的不归路。
任何希望获得GoogleApps授权的OEM都要接受Google所谓“兼容性测试”。
兼容保证的是PlayStore里的应用都能在特定品牌的设备上运行。
“兼容性”对Google别有深意，在Google内部，工程师们把它称之为"让OEM言听计从的一把锁"。
虽然Google已经推出了一套自动化工具来检测设备的“兼容性”，而获取Googleapps的接入权OEM仍然需要私下里与Google邮件交流。
这些协议大抵都是在幕后达成的。
此外，凡获取Googleapps授权的OEM须对其照单全收，如果看上了Gmail和Maps，你也得一并收了GooglePlayServices、Google+和Google认为应该放在套餐里的东西。
基于位置的WiFi服务商Skyhook在为Android平台开发一款位置服务时就遇到了重重阻力。
如果OEM设备内置了Skyhook的服务，那么Google就无从收集用户的地理位置数据了。
这显然对Goolge不利，所以Skyhook就被判为“不兼容”。
Skyhook也因此把Goolge告上了法庭，案件至今还没有说法。
影子软件
对大部分OEM而言，脱离Google生态系统谋生无异于痴人说梦。
一个保持独立而又不得罪Google这个老大的办法就是额外提供一系列全套的Googleapps衍生版本，虽然这常被诟病为“冗余软件”。
三星就是一个典型的例子，它有一套自成体系的帐户系统、云端同步和应用商店，以及全套的Googleapps替代品，比如Internet、E-mail和日历等。
这些应用仍基于AOSP，只是三星长期以来一直为用户提供自家的升级服务。
一台设备上同时预装两个日历应用似乎又傻气又累赘，但很多OEM却视之为防范Goolgeapp的PlanB——万一遇不测好歹有个后路。
如果Google不按常理出牌致使自己受迫出局的话，公司至少还有拿给潜在消费者看的东西，顺便也能收集一些有价值的反馈。
何乐不为呢？
虽然这让用户感到负担和困惑，但就某些核心应用而言，也许少数用户会喜欢OEM提供的版本。
三星这么做似乎有随时跳槽的可能性，但搞出一套影子app出来其挣脱Google生态系统很有限的动作，Android真正为OEM所看重的部门其实是大量可供选择的第三方应用。
Google清楚这是自己最大的弱点，因此该公司已经在设法提高整个app生态对自己的依附性了。
锁定第三方应用
PlayService实为Google对抗衍生版本Android的一大利器。
作为Goolge的闭源app，它随GoogleApps套餐包一道被授权给OEM。
任何功能由“正常版”Android移植到GooglePlayServices都意味着由开源走向闭源。
这一招不仅想靠独家垄断的功能吊用户的胃口，目的还在于通过API的授权牢牢控制住第三方应用开发者。
脱离Google的应用生态系统似乎很容易：
搭建自己的应用商店，说服开发者在上面投放app,然后你就可以独立发展了。
可Google正在想方设法加大第三方应用对自身平台的依赖性，一方面，选择在所谓“兼容”设备上开发app的开发者生存状态越来越好了，同时在GoogleAndroid体系外的开发者状况越来越糟糕了，其战略其实是把“AndroidAppEcosystem”变成了“GooglePlayEcosystem”。
如果你使用了任何GoogleAPI接口，又试图在Kindle或其它AOSP版本上运行这个app：
surprise!
你只能眼看着它崩溃了。
GoogleAndroid占据了全球80%的市场份额，开发者真正关心的是app开发流程的简化，运行的流畅以及能否到达更多用户。
而这些需求GoogleAPI都能轻松解决，美中不足在于你的app不得不依赖于GoogleApps授权的设备。
GoogleMapsAPI
接入GoogleMaps便可获得Google地图数据的使用权，它为天气或旅行应用开发提供了很大的便利。
唯一的问题在于，这部分Google服务并非开源的Android服务。
选择MapsAPI内在地意味着选择Google兼容设备作为开发平台。
为此，亚马逊不得以只好使用诺基亚的授权地图数据并克隆了一套GoogleMapsAPI，该公司甚至还专门提供了一张页面告诉开发者如何将app从GoogleMaps迁移出来。
Google确实擅长优化自身的生态环境，这无形中就加大了外生态的生存难度系数。
要在Kindle流畅运行你就得兼容两个不同的地图API。
这让Android衍生版本的处境很尴尬，这里亚马逊要么选择常年向诺基亚支服务付许可费用，要么就得自立门户重新开发一套地图出来。
更甚之，亚马逊还得时时紧跟Google的步调调整节奏：
亚马逊的MapsAPI支持的是GoogleMapsAPIv1,但如果某开发者需要用到Mapsv2API中的新功能，亚马逊就有的忙了。
GoogleCloudMessaging
GoogleCloudMessaging（GCM）是Android平台通知推送最简单易用的方式，但它永远也不会出现在AOSP版本上。
2013年I/O大会时，它被引入至PlayServices。
GCM的作用主要在于帮开发者跨平台同步推送即时消息。
LocationAPIs
GoogleMapsAPI或许仅适用一批小众应用，但不管出于什么原因，越来越多的应用都需要嵌入消息推送功能。
这也是不甘落后的亚马逊不得不复制过来的新功能。
其衍生版本叫做“AmazonDeviceMessaging”，仅支持亚马逊设备。
跟MapsAPI的情况一样，亚马逊仍需追加苦工，但又不得不接受极小规模用户群体这一现实。
而GCM的全部功能在Amazon版本可能属于集体缺位的状态，所以亚马逊的工作量很大。
2013年GoogleI/O大会时，Google改版了AndroidLocationAPI并将其纳入了GooglePlayServices服务项目。
换句话说，Android最新的位置服务已属闭源之列了。
如果上述例证足以参考的话，之前的开源地理位置服务只好自生自灭了。
新增功能除FusedLocationProvider（据说采用了全新的位置算法）外，还有Geofencing和Activityrecognition，前者为用户提供基于地理位置的活动推荐服务，后者则结合加速计数据和精妙的算法判断用户的运动状态，如步行、骑自行车或才开车——皆无需开启GPS。
由于MapsAPI和GCM皆依托Google服务器运行，独立的app完全有理由将其整合进来。
但综观整个地理位置服务有一种Goolgle的大手无处不在的感觉。
目前获得地理位置信息服务有两种方案，一是从Google获得节能而优质的闭源服务；二是选择蹩脚的、费电的开源服务。
app内购买
Android上最有效的应用内购买无疑是发生在GooglePlayStore。
如果某开发者选择了Kindle或在中国做应用开发，他们只好另谋高就了。
这又一次证明，如果想要脱离Google的Android，就得不断复制它的服务，亚马逊就推出了AmazonIn-AppPurchasingAPI。
就连三星也在抗争，它在两年前就有了类似的举动。
PlayGames
PlayGames是另一个能够为移动开发者解决一系列难题的专属API，它允许开发者能简便地引入用户帐户，排行榜、积分管理、云端存档和多人游戏机制等模块。
它最大的优点在于跨平台运行，当然，除了AOSP的一切平台。
这又是一个第三方应用赖以生存和衍生版Android平台不得不复制的API。
亚马逊有一套叫做“GameCircle”的API，但它在功能上并不与PlayGames重合，因此选择亚马逊的游戏开发者还得额外开发一个完全独立的多人游戏模块。
通过iOS锁定开发者
Google颇为诡黠的一点在于其90%以上的API都支持iOS平台。
从开发者的角度思量下你是否会用Google的API：
Google的解决方案往往在可用性、功能性和易用性上都是一流的；它支持两大主流平台，这意味着选择Google的API就能覆盖到绝大多数的潜在用户。
它唯一的缺陷就在于不兼容衍生版Android，但任何衍生版的Andoid背后都一小波你在乎的目标设备。
也许大部分开发者都会拥抱GoogleAPI，可也须回答这个问题：
他们将如何区处Kindle和其他版本的Android呢？
开发者们完全有自主权选择其它替代性API解决方案，但这个替代品可能会有过期、不兼容、以及功能残缺等缺陷，专注于产品设计的开发者这时大都会果断地抛弃这些小众衍生版Android，从而也省去了许多无谓的工作量。
三星不成大气候
让我们解释下为什么亚马逊能够脱离Google独立生存而三星却做不到。
亚马逊虽是一个GoogleAPI复制机器，但三星在这方面却比它还不如。
关于三星脱离Google生态的任何猜测都是不成熟的，除非你看到它对外授权了地图数据或开发出了一套云端消息推送API。
亚马逊的确算得上上进，但这家公司本就出生于互联网。
服务器和软件服务是它的看家本领，因此发展出一批云服务算不得什么突破。
三星则是一家电子产品公司——它并没有云端基础设施和API开发的基因。
因此亚马逊能够在短短几年内依托其云端平台做好Google的跟班儿，但三星却还是步履维艰。
三星也算有一点进步，如刚才所说，它推出了自家的应用内购买SDK包。
有趣的是，它还有一套广告SDK包，但就没怎么赚过钱。
相反，Google则支持所括Android、iOS、衍生版Android甚至WindowsPhone上的所有广告。
可望不可及的开源
任何有心挑战GoogleAndroid的公司都得把本文中提到的服务复制一遍。
即便如此也不过是貌似与GoogleAndroid打了个平手。
你仍须给用户一个放弃GoogleAndroid而投奔你的充分理由。
Google俨然已经自成体系，它的基础云服务和Maps皆免费提供。
任何有需求的公司都难免会用到Google的服务。
亚马逊或是个例外，但比较下：
Google可依托Maps销售广告挣钱，而亚马逊却须替你用户常年向诺基亚值钱。
这就是任何一个衍生版Android所面临的宭境。
即便哪家公司能拿出一款牛B闪闪的衍生版Andoid来，它也得面对几乎所有的OEM都与Google签了卖身契这个事实。
对OEM来讲，脱离Google投身另一衍生版Android风险要远大于收益。
虽说Android是开源的，不过它是一种”可望而不可及“的开源。
所到之处，但凡没有Google的庇护，想要利用Andoid都会连连受阻。
违反了Google的禁令，就只能看着眼前的世界坍塌下来。
升级会员 