repo

安卓源码包含数百个git库, googole开发了 repo工具来管理安卓版本库。 repo 使用python对git进行了封装。

内核源码

AOSP源码中不包含内核源码,需要单独下载。

  1. common 通用的 linux内核源码
  2. msm 用于高通 MSM芯片的 linux内核源码
  3. goldfish 是用于安卓虚拟机的 linux内核源码

编译AOSP 能做什么

  1. 定制 Android 系统
  2. 将 Android 系统 刷入设备
  3. 将整个系统源码导入到 Android Studio 中
  4. 动态调试 Android 系统源码

其中第三条和第四条也可以不用编译源码来实现, 第三条

  • 只要有对应 Android 源码版本的 android.iml 和 android.ipr 两个文件就可以将源码导入到 Android Studio 中

第四条

  • 动态调试系统源码不一定非要导入整个系统源码进行调试。关于第三条和第四条的具体内容,我会在以后的内容中进行讲解。

编译系统概述

了解以下一些概念,会对 Android 编译系统有大概的了解。 Makefile Android 平台的编译系统,其实就是用 Makefile 写出来的一个独立项目。它定义了编译的规则,实现了 “自动化编译”,不仅把分散在数百个 Git 库中的代码整合起来、统一编译, 而且还把产物分门别类地输出到一个目录,打包成手机 ROM,还可以生成应用开发时所使用的 SDK、NDK 等。 因此,采用 Makefile 编写的编译系统,也可以称为 Makefile 编译系统。 Android.mk Makefile 编译系统的一部分,Android.mk 是 android 编译环境下的一种特殊的 “makefile” 文件, 它是经过了 android 编译系统处理的。Android.mk 中定义了一个模块的必要参数,使模块随着平台编译。通俗来讲就是告诉编译系统,以什么样的规则编译你的源代码,并生成对应的目标文件。

Ninja Ninja 是一个致力于速度的小型编译系统,如果把其他的编译系统看作高级语言,那么 Ninja 目标就是汇编。使用 Ninja 主要目的就是因为其编译速度快。

Soong Soong 是谷歌用来替代此前的 Makefile 编译系统的替代品,负责解析 Android.bp 文件,并将之转换为 Ninja 文件

Blueprint Blueprint 用来解析 Android.bp 文件翻译成 Ninja 语法文件。

kati kati 是谷歌专门为了 Android 而开发的一个小项目,基于 Golang 和 C++。 目的是把 Android 中的 Makefile,转换成 Ninja 文件。

Android.bp Android.bp,是用来替换 Android.mk 的配置文件。

关系图 Android.mk、Ninja、Soong、Blueprint、kati、Android.bp 的概念之间的联系为:

车载技术—CarFramework框架【AOSP 源码编译】

Blueprint 负责解析 Android.bp 文件内容,Blueprint 类似一个处理相关语法的库文件,Soong 则是定义具体如何处理相应的语法以及命令实现。通俗来讲就是 Soong 借助于 Blueprint 定义的 Android.bp 语法,完成 Android.bp 的解析,最终转换成 Ninja 文件。 Makefile 文件会通过 kati 转换为 Ninja 文件。 随着 Android 工程越来越大,采用 Makefile 的编译系统花费的时间也越来越长,因此谷歌在 Android 7.0 开始引入了 Ninja 来编译系统,相对于 Makefile 来说 Ninja 在大的项目管理中速度和并行方面有突出的优势。 Makefile 默认文件名为 Makefile 或 makefile,也常用. make 或. mk 作为文件后缀。 Ninja 的默认文件名是 build.ninja,其它文件以. ninja 为后缀。Makefile 与 Ninja 的区别在于, Makefile 是设计来给开发编写的,而 Ninja 设计出来是给其它程序生成的。如果 Makefile 是 Java 语言,那么 Ninja 就是汇编语言。

编译源码的方式

Androd 系统源码编译有很多种方式,主要有以下几种:

  • 在 Linux 中直接进行系统源码编译(Android 官方支持)
  • 在 Mac OS 中直接进行系统源码编译(Android 官方支持)
  • 使用 Docker 编译,支持 Mac OS 和 Windows

其中需要注意的是,Docker 的最低支持版本为 Windows7,建议用 Windows10 环境下使用 Docker,因为在 Windows7 中还需要借助 Docker Toolbox 和 VirtualBox 中的容器进行通信,效率相对低些。 考虑到大多数人的设备和上手难易程度,本为讲解在 Linux 中直接进行系统源码编译。

编译步骤

编译三部曲:

  • 初始化编译环境
  • 选择产品
  • 编译
​
ldswfun@android:/mnt/ext-disk1/a10-aosp$  source build/envsetup.sh
​
ldswfun@android:/mnt/ext-disk1/a10-aosp$  lunch
​
You're building on Linux
​
Lunch menu... pick a combo:
​
     1. aosp_arm-eng
     2. aosp_arm64-eng
     3. aosp_blueline-userdebug
     4. aosp_bonito-userdebug
     5. aosp_car_arm-userdebug
     6. aosp_car_arm64-userdebug
     7. aosp_car_x86-userdebug
     8. aosp_car_x86_64-userdebug
     9. aosp_cf_arm64_phone-userdebug
     10. aosp_cf_x86_64_phone-userdebug
     11. aosp_cf_x86_auto-userdebug
     12. aosp_cf_x86_phone-userdebug
     13. aosp_cf_x86_tv-userdebug
     14. aosp_coral-userdebug
     15. aosp_coral_car-userdebug
     16. aosp_crosshatch-userdebug
     17. aosp_crosshatch_car-userdebug
     18. aosp_flame-userdebug
     19. aosp_marlin-userdebug
     20. aosp_sailfish-userdebug
     21. aosp_sargo-userdebug
     22. aosp_sunfish-userdebug
     23. aosp_taimen-userdebug
     24. aosp_walleye-userdebug
     25. aosp_walleye_test-userdebug
     26. aosp_x86-eng
     27. aosp_x86_64-eng
     28. beagle_x15-userdebug
     29. car_x86_64-userdebug
     30. fuchsia_arm64-eng
     31. fuchsia_x86_64-eng
     32. hikey-userdebug
     33. hikey64_only-userdebug
     34. hikey960-userdebug
     35. hikey960_tv-userdebug
     36. hikey_tv-userdebug
     37. m_e_arm-userdebug
     38. mini_emulator_arm64-userdebug
     39. mini_emulator_x86-userdebug
     40. mini_emulator_x86_64-userdebug
     41. poplar-eng
     42. poplar-user
     43. poplar-userdebug
     44. qemu_trusty_arm64-userdebug
​
Which would you like? [aosp_arm-eng]  //选择27
​
ldswfun@android:/mnt/ext-disk1/a10-aosp$  make  -j6

编译出错处理

车载技术—CarFramework框架【AOSP 源码编译】

A交换分区扩大到3-4G, 请参考以下链接:

B 若扩展好之后还报错,可尝试虚机关机,然后重启再编译一次。

user和eng版本说明

车载技术—CarFramework框架【AOSP 源码编译】

镜像使用

Android源码编译出来的镜像,可以通过Android自带的emulator来运行。emulator就是平常所说的模拟器, 在用户没有真机的情况, 通过启动模拟器来完成对系统和程序的调试和开发。emulator内部是基于Qemu+KVM虚拟化技术, 通过Qemu模拟出CPU ,硬件总线和外设,emulator在传统的qemu技术上, 增加了各种传感器的模拟, 如重力传感器, gps,电话模块等, 从而实现模拟出一个虚拟机的手机。

emulator启动方法:

ldswfun@android:/mnt/ext-disk1/a10-aosp$  source build/envsetup.sh
​
ldswfun@android:/mnt/ext-disk1/a10-aosp$  lunch  aosp_x86_64-eng
​
ldswfun@android:/mnt/ext-disk1/a10-aosp$  emulator  -verbose  -show-kernel -cores 4

车载技术—CarFramework框架【AOSP 源码编译】

总结

Android源码编译是比较费资源的, 并且启动emulator需要的cpu和内存负载都比较大, 如果慢的话,属于正常现象。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。