Msm8960(APQ8064)平台的MSM-AOSP-kitkat编译适配(1)：基础知识

讨论QQ群：304570451(仅接受各开发组成员，各论坛开发者，广告、推销者勿扰)

这一篇是这一系列文章的起始，就暂不进入正题，先啰嗦一下一些基本的常识和一些题外话吧，这些知识也挺重要的，建议急性子的读者也多了解一下。

声明：本系列文章并非百科全书，笔者也不指望靠这些文章就能把一个初学适配者指导成一个高手，所以请读者碰到问题时请多动手尝试。

一、目的

写这一系列文章的目的，是为了总结出一种通用的方法，一种门槛不高，且不需要很深的编程基础，适用于大众的编译适配方法；使用这种方法，可以为各种基于高通msm8960平台的手机，编译适配出msm-aosp。

二、Android版本

4.4即kitkat是目前比较稳定的版本，也被大部分android手机所支持，所以笔者本系列文章专门针对此版本。但有些经验、方法总是共通的，其它的版本的系统甚至cm的编译适配也可以部分地参考本系列文章。

三、Rom的分类

虽然aosp是原生系统，但相对于官方系统来说，也属于第三方系统的范畴。
总之除了官方rom、基于官方优化(汉化)的rom以外，其它种类的rom都属于第三方rom。
而第三方rom按照其产生的方式仍然可以再分类：编译，插桩，移植
那么一共就有4个分类
优化：指的是修改优化官方rom(包括汉化)
编译：指的是从源代码编译出来的rom
插桩：指的是用代码插桩的方法适配出来的rom，一般使用patchrom系统
移植：指的是从相近配置机型的rom以及本机型的底包rom中获取资源，通过文件替换的方式，产生的rom

四、Rommer的分类

笔者暂且按照rom的分类把rommer也分为优化者、编译者、插桩者、移植者。
但并没有严格的阵营或界限，毕竟一个rommer可能做同时编译、插桩、移植、优化。
优化者就不多说了，一般接触android都是从优化系统（汉化、修改）开始，这本身就是基础，即使是适配高手，优化的手段也都必须掌握。
由于miui、乐蛙、百度等这些插桩型或移植型rom在国内的流行，所以国内的插桩者、移植者众多，相反国外的插桩者却不多，这是由国内的android生态圈所决定的。
而android open source(现在已经墙了），github(访问巨慢无比)，XDA(也是慢而且还广告满天飞)，这些优秀的开源站或开源社区都在国外，于是诞生了cm、aokp等众多第三方rom，也就催生了许多国外的编译者，相反的国内的编译适配者屈指可数，这也是由国外的大环境所决定的。

五、google-aosp与高通的msm-aosp，这二者的关系

笔者所了解的，都是从代码以及rom中了解进而总结出来的，并不是搜索或从书里得来的。如果说得不对也请见谅！
Google作为业界大佬同时也是android项目的主导者，它的aosp开源项目就是所有android的源头，即所有的andriod版本都是从google-aosp中分化演进而来，包括高通的msm-aosp。
至于为何笔者把高通的aosp当做一个相对独立的aosp系统呢？因为高通的cpu架构以及显示芯片Adreno、多媒体部分与google的标准存在差异，所以google的aosp代码不能直接用在高通平台。
于是高通就把google的aosp的代码同步回去，经过修改（硬件抽象层、系统框架、通讯层），形成自己的版本，也就是msm-aosp。那么反过来，大佬google却不会从高通这边同步代码回去来适应高通的平台，毕竟google要坚持自己的标准，三星、德仪、MTK、麒麟等平台还是遵循google的标准的(未经过求证，只是笔者的猜想)。

六、非caf内核与caf内核

高通的开源社区叫做Code Aurora Forum，缩写就是caf。
高通平台cpu用的内核一般就叫caf内核。
一般情况下除了nexus系列手机以外，都是caf内核。
那么谨记，msm-aosp必须配合caf内核，而非caf内核则可用于google aosp。
OK，那么聪明的读者应该会想到，CM等第三方rom的编译系统既可以适配出caf内核的系统也可以适用于非caf内核，到底有什么诀窍呢？
因为cm集成了google和高通两者的硬件抽象层代码。
举个例子(msm8960平台)：
cm的hardware/qcom/display对应于google-aosp的hardware/qcom/display
cm的hardware/qcom/audio对应于google-aosp的hardware/qcom/display
cm的hardware/qcom/media对应于google-aosp的hardware/qcom/display
而
cm的hardware/qcom/display-caf对应于msm-aosp的hardware/qcom/display
cm的hardware/qcom/audio-caf对应于msm-aosp的hardware/qcom/display
cm的hardware/qcom/media-caf对应于msm-aosp的hardware/qcom/display

七、代码的版本revision与tag

这里所说的版本，并不是能看到的版本，比如android4.4.2或kernel 3.4这之类的版本
而是指代码的版本，读者必须逐渐适应这个说法。
android是有许许多多个代码目录组成，这些目录都是一个个独立的项目，可能有多个不同的开发人员负责维护，而单个项目每次提交更新会形成一个版本。
而这些项目处于不断更新的状态，可能多个项目积累了几百次几千次的更新，才会形成一个大版本的跃进。
那么每次编译比如4.4.2时，可能同一个项目的代码版本并不一样，因为之前说了项目一直在更新，于是很有必要使用代码版本的概念，对于git来讲，就是revision，每一次通过测试的编译，都把每个项目的revision记下来，众多项目形成一个tag。典型且容易理解的来讲，就类似cm的snapshot，比如CM11-M4，CM11-M5这样的版本。
但高通则更为复杂一些，高通的开源站把通过release测试的tag版本都公布在这里：
https://www.codeaurora.org/xwiki/bin/QAEP/release
各种平台独立，且有一定的命名规律。

为了让读者能更直观的理解，下面的例子就是某个版本的tag，打开后可以看到各项目的 revison：

再举一个例子：msm8974平台的release tag，笔者列出了每个tag对应的android版本代号，其中KOT49H代表4.4.2_r1，KVT49L代表4.4.2_r2，KTU84L代表4.4.3，KTU84P代表4.4.4

tag版本	android版本
LNX.LA.3.5.1-01710-8x74.0.xml	KOT49H
LNX.LA.3.5.1-01710-8x74.0.xml	KOT49H
LNX.LA.3.5.1-02010-8x74.0.xml	KVT49L
LNX.LA.3.5.1-02410-8x74.0.xml	KVT49L
LNX.LA.3.5.1-02710-8x74.0.xml	KVT49L
LNX.LA.3.5.1-03010-8x74.0.xml	KVT49L
LNX.LA.3.5.1-03310-8x74.0.xml	KVT49L
LNX.LA.3.5.1-03910-8x74.0.xml	KVT49L
LNX.LA.3.5.1-04210-8x74.0.xml	KVT49L
LNX.LA.3.5.1-04510-8x74.0.xml	KVT49L
LNX.LA.3.5.1-05110-8x74.0.xml	KVT49L
LNX.LA.3.5.1-05210-8x74.0.xml	KVT49L
LNX.LA.3.5.1-05510-8x74.0.xml	KVT49L
LNX.LA.3.5.1-05710-8x74.0.xml	KVT49L
LNX.LA.3.5.1-05910-8x74.0.xml	KVT49L
LNX.LA.3.5.1-06110-8x74.0.xml	KTU84L
LNX.LA.3.5.1-06210-8x74.0.xml	KTU84L
LNX.LA.3.5.1-06310-8x74.0.xml	KTU84L
LNX.LA.3.5.1-06510-8x74.0.xml	KTU84P
LNX.LA.3.5.1-06810-8x74.0.xml	KTU84P
LNX.LA.3.5.1-06910-8x74.0.xml	KTU84P
LNX.LA.3.5.1-07010-8x74.0.xml	KTU84P
LNX.LA.3.5.1-07410-8x74.0.xml	KTU84P
LNX.LA.3.5.1-07510-8x74.0.xml	KTU84P
LNX.LA.3.5.1-07710-8x74.0.xml	KTU84P
LNX.LA.3.5.1-07910-8x74.0.xml	KTU84P
LNX.LA.3.5.1-08610-8x74.0.xml	KTU84P
LNX.LA.3.5.1-08810-8x74.0.xml	KTU84P
LNX.LA.3.5.1-09010-8x74.0.xml	KTU84P
LNX.LA.3.5.1-09110-8x74.0.xml	KTU84P

从上面的例子可以看出，并非每个tag都是一个跨越式的版本升级，有些升级只是修复bug等。所以许多代码版本是升级了，但实际上android版本并没有变化。

八、最后的重点

请务必看完并理解此段的含义。
一般情况下，通过tag同步下来的系统代码版本以时间为联系是统一的，唯有内核代码除外，因为手机的内核代码由手机厂商单独发布。
如果内核代码的版本与系统代码的版本不匹配，那么编译就会出错，甚至编译出来的系统无法使用。
那么经过思考，我们可以得出如下结论：
方法一：要么固定系统代码版本，寻找匹配的内核代码版本
方法二：要么固定内核代码版本，寻找对应的系统代码版本

对于方法一，如果同步了最新的系统代码，然后把厂商提供的内核代码也升级到最新的版本，那么这样就可以配合最新的系统代码，编译适配出完整ROM了。
但这个门槛太高，因为能看懂内核代码能编程，需要经过系统的学习，并非几篇文章就能教会，而本文所讨论的则是通用的，低门槛的方法。

所以剩下只有方法二：识别内核代码的版本，再找到对应匹配的系统代码的版本(可能不是最新的)，再来做编译适配。虽然这种方法限制很大，但确实是适合大众的方法。
那么如果我们有了厂商的内核代码，那么该如何找到匹配的系统代码呢？这个问题由之后的文章来解答。

那么，如何升级内核以适配出高版本的系统？
升级内核确实有一定的方法(后面的文章会阐述笔者总结的思路)，但如前所述，方法能总结出来，但编程技能无法靠几篇文章就能教会。
反过来讲，如果一个高手能看懂、修改、编写内核代码，那么适配系统当然得心应手，不会拘泥于用什么方法。就像武侠小说里讲的，内功高手无所谓用什么招式，只有初学者才需要学招式。