本文主要是介绍Android 开源的真相: 无法fork，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
虽然是名义上的开源系统，但如果微软的手机采用 Android 系统，那将是个巨大的错误，诺基亚都不行，因为 Google 把 Android 做得无人可改。不止一次了，总有人跳出来「建议」微软采用 Android，替换掉市场乏力的 Windows Phone 系统。这种口水文章估计将来也不会停。
说这话的人到底是人笨呢，还是心眼坏。Google 这么多年来，已经把 Android 做成了本质上无法分支(fork)的软件，开源只是名义上的，对于其他手机厂来说毫无意义。没人能再 fork 出自己的 Android，同时保证可用性，吸引大量的开发者和海量的软件。
「微软该转 Android」的论点是：Windows Phone 平台没能吸引到足够的开发者投入精力，也没能为开发者创造收入，但是 Android 两者兼备。如果从 Android fork出一个微软自己的系统来，微软就能一箭双雕——在 Android 上部署自己最擅长的服务，包括 Exchange，Active Dictory 和 System Center 或者 InTune；给予消费者完整的 office 体验——并且替换掉 Google 的服务，完全基于自己的云套件(Bing搜索，Bing 地图，Azure) 。同时还能保留大量用户需要的 Android 应用。
按照这种逻辑，Android 的丰富应用和巨大市场号召力会吸引消费者购买微软的产品，更多熟悉 Android API 的开发者会入场。微软的开发成本也会降低，因为核心的维护工作就让 Google 去做好了。
这种事情根本没法弄的原因在于，Android 平台的正确用法不是这个样子的，Android 本来就不是为了大家一起玩而设计的，它是一个Google控制的「庄家定规则的游戏」，随着 Android 的每一次新版本发布，Google 正把这种想法变得更加不切实际。
代码开源不彻底
大体上说，Google 写了两大坨代码。
第一坨是核心的 Android 开源平台(AOSP)底层代码，它提供了整个智能手机系统的基础骨架：包括一份 Android 专用的 Linux 内核，Dalvik 虚拟机，和部分基础的用户界面(设置、消息面板、锁屏界面)。这部分代码以 GPL 和 Apache 的混合授权模式发布。虽然 Google 周期性地发布这部分的开源代码包，但被行业批评为「一副关起门来闷头搞」的不合作腔调。
第二坨称之为「Google 服务套件(GMS)」。GMS 又分为两大块：Google Play Services 提供了海量的 API 和系统服务，包括 Google 地图，位置服务和内购功能；Google+ 集成；远程 Wipe；恶意软件扫描等等。还有就是一些 Google 自己的软件：搜索，Gmail，Chrome 浏览器，Gogole 地图等。
GMS 提供了很多重要的系统特性。而且 GMS 是闭源的。任何人可以拿到 AOSP 的代码编译好刷进任何一台手机。但是 GMS 可不能这么搞，为了获得 GMS 的授权，设备必须符合 Google 的硬件标准(性能，屏幕分辨率等等)，而且必须通过 Google 的测试。虽然 Google 表示 GMS 套件是免费的，但测试是收费的，平均每部配置 GMS 套件的 Android 手机都得支付给 Google 0.75美元的测试费。换句话说，除了最有用的部分，Android 的确都开源的。
GMS 也没法分割：如果手机要通过 Google 的测试，那么它必将装载上全部的 Google 软件。
而且对于开发者来说，AOSP 和 GSM 也是水乳交融，分不清彼此。Google 正慢慢地把越来越多的功能从 AOSP 从 开源的 AOSP 迁徙到闭源的 GMS 里去。举个栗子，在五太子 Nexus 5 上，手机的界面——你用来显示图标和加载程序的核心功能已经滚到了 GMS 套件的 Search 组件里。
类似的，API 也发生了相应的修改。比如 AOSP 本来是有一个位置服务的 API 可用，但 GMS 提供了一个很好，更新，提供更多功能的 API。Google 鼓励开发者用 GMS 里的 API。AOPS 里的那个老 API 从 Android 1.5 以后就没有更新过。这样造成的结果就是很多新的第三方 Android 软件其实很难说是 Android 的软件，其实它们更应该是 GMS 软件，离开闭源的 GMS 就没法工作。
Android 的四种用法(只有一种是正确的)
对于手机厂来说，采用 Android 系统的方式一共有四种。
第一种就是 Google 希望各家采用的方式：同时使用 AOPS 和 GMS。提交通过测试，装载全部 Google 的服务和应用套件。这就是三星，HTC 和 LG 采用的方式。这条道路还是给手机厂留下了一些自定义的空间。OEM 厂可以在 Google 应用以外，装载自己的相同的应用。但貌似 Google 对各厂在这点空间搞的花头也不满意了，有报道说 Google 和三星谈判，三星同意减少在手机界面上的各种奇葩修改，特别是移除与 Google 应用重复的其他应用。
这种方式因为提供了完整的 AOPS 和 GMS 的 API， 也就保证了最佳的软件兼容性。同时也最大程度地保证了 Android 系统的用户体验，不管各厂怎么折腾界面，Google 的软件总是存在的，用户体验总是一致的。
这让 Google 也最大程度地保持自己对 Android 系统的控制力，而且这种控制力只会与日俱增。每一次新版本 Android 的发布，Google 就会把更多的 API 弄到 GMS 套件里去，慢慢把 AOSP 上的肉一点点剃掉，只剩一个底层的骨架。
第二种极端做法，整个移除 GMS 服务包，基于 AOSP 开发一些粗制滥造的替代品。当然，这样做的结果，就是用户得到的体验会差很多，所谓能用就行了。在一些低端机上，很多厂家就是这么干的，特别是在中国市场。只要你敢用，厂家提供了自己的软件市场和各种替代软件，填平 Google 软件缺失所留下的空隙，但这些产品和采用 GMS 套件的手机比起来，在水准上要低很多，这些手机不兼容很多基于 GMS 开发的软件，而且数量不少，比如很多软件依赖 GMS 的内购功能。
第三种做法介于第一种和第二种之间：发布基于AOSP的设备，但是开发与 GMS 一样的 API 以保证兼容性，比如GPS和地图服务，但是基于微软而不是 Google 的。很少有厂家选择这条道路，最接近这种做法的只有 Amazon，它们提供了 GMS API 的替代方案(特别是地图服务)，但完全没法跟上 Google 的开发迭代速度。
是从技术上说，如果一家公司足够土豪心，豹子胆，完全开发出自己的 API, 整个端掉 GMS，这代价也绝对没法让人淡定。特别是为了保证兼容性，这活不光是提供与 GMS 想通的功能，还包括提供和 GMS 提供的开发框架和开发者工具。
另外，GMS 还有一些无法替代的东西，比如「Google+ 分享」，很少有公司能提供能与之匹敌的替代方案。又比如，GMS里有一个 API 提供了多人回合游戏功能，虽然厂家可以提供自己的API，并建设自己的后台硬件支持回合制游戏服务，但显然这完全脱离 GMS 的做法，无法让游戏开发者接受。
更不要说这么大费周章搞掉 GMS，定是不小心忘了 Google 和 Oracle 之间关于这些 API 的漫长的专利官司。事实上，能做出这样事情的厂家，不可能不引起 Google 法务部门的疯狂点赞。Google有钱啊，如果他愿意，法庭当茶馆，慢慢和你谈。
除了以上三条路以外，总有狠人能比划出第四条道路：只用 AOSP 的最基础的功能，比如硬件支持层、通讯模块什么的，余下的全部推墙揭瓦，自己开发……但这相当于又把 Android 从头开发了一遍。Amazon 的自有API 可以归入这种「猛人」行列，提供了功能一样，但是实现了与 GMS 完全不兼容的 API。我想不太会有厂家能做出 Amazon 这种事情。虽然还有像 Ubuntu for Android 这种怪东西，但那只是精神可嘉。
嘛？ C.O.S. 比这还猛？但是这货比划的实在太猛了，我连呵呵都不敢。
兼容性与控制权，鱼和熊掌不可兼得
以上四种途径中，第一种 AOSP 加 GMS 的做法是唯一能提供完整 Android 体验的方法，并能保证开发者不会有任何别扭的地方，也是唯一能兼容所有Andoid第三方应用的途径。但显然，这种做法不是微软能接受的，这等于帮 Google 做硬件，让 Google 唱戏，而且这一唱就没有翻身之日了。
第二种 —— 在 AOSP 的基础上提供一些替代应用，这可以让微软在 Android 上集成自己的服务。这样虽然能支持不少 Android 应用，但能支持多少并不确定。但至少肯定没法支持像 植物大战僵尸2，愤怒的小鸟这些依赖 GMS，并且有大量内购利润的大牌应用，但如果这部手机就是设计来主要使用内置应用就行的(比如相机，浏览器，邮件客户端)，那丢掉些兼容性也无大碍。
NOKIA 传说中在开发的 Android 手机可能就是以这种方式实现：AOSP作为底层，上面全是诺基亚自己的服务。
这种做法可能只适合于对软件兼容性要求不高的低端市场，能不能打正版僵尸无所谓的超低价手机，也是很多中国厂家采用的方案。但是对于微软来说，这完全搞错了方向：这家公司已经有了一个不能支持许多高大上赚钱应用的鸡肋系统，干嘛还要再搞一个？！
而且，能想象这种 Android 手机的用户体验有多差。Google 已经把众多核心功能迁移到 GMS 框架内，比如短信和 Chrome 浏览器。AOSP 是一个多bug、老旧，基本上不会再有后续维护的框架。想要抛开 GMS 从 AOSP 开始重起炉灶，开发出同等用户体验的系统，那前面就是两万五千里长征在欢迎你。因为 Android 开源的部分很差。
Amazon 的 Kindle Fire 就是一个例子告诉你从 AOSP 平地起楼有多难。Kindle Fire 不支持最新最酷的游戏，因为开发者没兴趣去同时维护一个不依赖 GMS 框架的产品线，虽然两者之间看上去很像。Windows Phone 所遇到的问题，换了 Android 也完全没有解决。只能带上 GMS 才能玩得开。
第三条道路，就是在 AOSP 的基础上，从头开发与 GMS 完全兼容的接口——或许可以解决这个问题，但这也把做 Android 分支的工作量放大到极大。但如果能做到完全提供与 GMS 一样的接口，开发者和用户的体验，以及那些只基于 AOSP 的程序的兼容性都可以得到保证。
但这个工作量……打个比方，大概和把 Windows Phone 的壳和 API 全部套在桌面版的 Windows 系统一样。某种程度上，这个工作量可能会更大，比如在 AOSP 上重新开发一遍 IE 浏览器。
更重要的是，Google 还是把着上游控制权，因为 Android 系统的表现，完全是基于底层 API 提供的功能的：比如「分享到」功能，完全是 Android 自己的方法和风格，而这都是由 Google 决定的，这就限制了下游开发者无法反驳 Google 的选择。
最后一个 —— 除了 AOSP，其他全部推翻重来。自由度和灵活度都有了，然后呢？内核其实根本不重要好不好，不就是个内核么！微软已经有了一个手机系统的内核了，在 Window Phone 8 用的好好的。很明显，对微软来说，抛弃整个 Windows Phone 系统不是说连这内核都能不要了。这已经是一个为微软量身打造的手机系统内核，没道理用别人的。而且内核真的不是整件事情最难的部分。
所以，别闹了
如果 Android 真的和 Firefox OS 或者 Ubuntu 一样的开源境界，那么「微软你就从了 Android 吧」这种话题才有意义。但是 Android 和 GMS 已经密不可分。如果所有东西都在 AOSP 的开源框架下，其他人才能把后台服务的一块块代码替换掉，以较小的工作量，同时又不毁掉兼容性，这件事情才有可能。
但显然事情已经不是这样。不光因为 Android 骨子里根本就不开源，而且 Google 正努力把它搞得越来越不开源。所以对于想 fork 自己的 Android 系统的人来说，选择只有两个：要么受制于 Google 得到其他的好处，要么把控制权拿来，并放弃一切。
Android 天生就不是让你来随便 fork 的。因为 GMS，Google 摆明了就是不许别人 fork。那些建议微软从了 Android 的人，不是居心叵测，就是根本不懂 Google 为什么要做「开源」的 Android。
还有一件事
别忘了 Google 和硬件商签订的授权协议里规定了，通过 Google 授权采用 Android 系统的厂家不允许制造不含GMS套件但又基于 AOSP ，同时兼容 GMS API 的手机设备。换句话说，如果有厂家敢为其他软件商制造纯 AOSP 的设备，将被完全拒绝使用任何 GMS 的软件和 API 服务。Amazon 只好费尽力气在地球上找到一家这样的 OEM 厂家来给他们代工造 Kindle，这必定是一家对自己的 Android 产品的没有任何市场野心的公司。
[Junius_Lou via ars]
转载于 ：http://linux.cn/thread/12318/1/1/
这篇关于Android 开源的真相: 无法fork的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
