android源码内核

‘壹’ Android socket源码解析(三)socket的connect源码解析

上一篇文章着重的聊了socket服务端的bind，listen，accpet的逻辑。本文来着重聊聊connect都做了什么？

如果遇到什么问题，可以来本文 https://www.jianshu.com/p/da6089fdcfe1 下讨论

当服务端一切都准备好了。客户端就会尝试的通过 connect 系统调用，尝试的和服务端建立远程连接。

首先校验当前socket中是否有正确的目标地址。然后获取IP地址和端口调用 connectToAddress 。

在这个方法中，能看到有一个 NetHooks 跟踪socket的调用，也能看到 BlockGuard 跟踪了socket的connect调用。因此可以hook这两个地方跟踪socket，不过很少用就是了。

核心方法是 socketConnect 方法，这个方法就是调用 IoBridge.connect 方法。同理也会调用到jni中。

能看到也是调用了 connect 系统调用。

文件：/ net / ipv4 / af_inet.c

在这个方法中做的事情如下：

注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .

文件：/ net / ipv4 / tcp_ipv4.c

本质上核心任务有三件:

想要能够理解下文内容，先要明白什么是路由表。

路由表分为两大类：

每个路由器都有一个路由表(RIB)和转发表 (fib表)，路由表用于决策路由，转发表决策转发分组。下文会接触到这两种表。

这两个表有什么区别呢？

网上虽然给了如下的定义：

但实际上在linux 3.8.1中并没有明确的区分。整个路由相关的逻辑都是使用了fib转发表承担的。

先来看看几个和FIB转发表相关的核心结构体：

熟悉Linux命令朋友一定就能认出这里面大部分的字段都可以通过route命令查找到。

命令执行结果如下：

在这route命令结果的字段实际上都对应上了结构体中的字段含义：

知道路由表的的内容后。再来FIB转发表的内容。实际上从下面的源码其实可以得知，路由表的获取，实际上是先从fib转发表的路由字典树获取到后在同感加工获得路由表对象。

转发表的内容就更加简单

还记得在之前总结的ip地址的结构吗？

需要进行一次tcp的通信，意味着需要把ip报文准备好。因此需要决定源ip地址和目标IP地址。目标ip地址在之前通过netd查询到了，此时需要得到本地发送的源ip地址。

然而在实际情况下，往往是面对如下这么情况：公网一个对外的ip地址，而内网会被映射成多个不同内网的ip地址。而这个过程就是通过DDNS动态的在内存中进行更新。

因此 ip_route_connect 实际上就是选择一个缓存好的，通过DDNS设置好的内网ip地址并找到作为结果返回，将会在之后发送包的时候填入这些存在结果信息。而查询内网ip地址的过程，可以成为RTNetLink。

在Linux中有一个常用的命令 ifconfig 也可以实现类似增加一个内网ip地址的功能：

比如说为网卡eth0增加一个IPV6的地址。而这个过程实际上就是调用了devinet内核模块设定好的添加新ip地址方式，并在回调中把该ip地址刷新到内存中。

注意 devinet 和 RTNetLink 严格来说不是一个存在同一个模块。虽然都是使用 rtnl_register 注册方法到rtnl模块中：

文件：/ net / ipv4 / devinet.c

文件：/ net / ipv4 / route.c

实际上整个route模块，是跟着ipv4 内核模块一起初始化好的。能看到其中就根据不同的rtnl操作符号注册了对应不同的方法。

整个DDNS的工作流程大体如下：

当然，在tcp三次握手执行之前，需要得到当前的源地址，那么就需要通过rtnl进行查询内存中分配的ip。

文件：/ include / net / route.h

这个方法核心就是 __ip_route_output_key .当目的地址或者源地址有其一为空，则会调用 __ip_route_output_key 填充ip地址。目的地址为空说明可能是在回环链路中通信，如果源地址为空，那个说明可能往目的地址通信需要填充本地被DDNS分配好的内网地址。

在这个方法中核心还是调用了 flowi4_init_output 进行flowi4结构体的初始化。

文件：/ include / net / flow.h

能看到这个过程把数据中的源地址，目的地址，源地址端口和目的地址端口，协议类型等数据给记录下来，之后内网ip地址的查询与更新就会频繁的和这个结构体进行交互。

能看到实际上 flowi4 是一个用于承载数据的临时结构体，包含了本次路由操作需要的数据。

执行的事务如下：

想要弄清楚ip路由表的核心逻辑，必须明白路由表的几个核心的数据结构。当然网上搜索到的和本文很可能大为不同。本文是基于LInux 内核3.1.8.之后的设计几乎都沿用这一套。

而内核将路由表进行大规模的重新设计，很大一部分的原因是网络环境日益庞大且复杂。需要全新的方式进行优化管理系统中的路由表。

下面是fib_table 路由表所涉及的数据结构：

依次从最外层的结构体介绍：

能看到路由表的存储实际上通过字典树的数据结构压缩实现的。但是和常见的字典树有点区别，这种特殊的字典树称为LC-trie 快速路由查找算法。

这一篇文章对于快速路由查找算法的理解写的很不错: https://blog.csdn.net/dog250/article/details/6596046

首先理解字典树：字典树简单的来说，就是把一串数据化为二进制格式，根据左0，右1的方式构成的。

如图下所示：

这个过程用图来展示，就是沿着字典树路径不断向下读，比如依次读取abd节点就能得到00这个数字。依次读取abeh就能得到010这个数字。

说到底这种方式只是存储数据的一种方式。而使用数的好处就能很轻易的找到公共前缀，在字典树中找到公共最大子树，也就找到了公共前缀。

而LC-trie 则是在这之上做了压缩优化处理，想要理解这个算法，必须要明白在 tnode 中存在两个十分核心的数据：

这负责什么事情呢？下面就简单说说整个lc-trie的算法就能明白了。

当然先来看看方法 __ip_dev_find 是如何查找

文件：/ net / ipv4 / fib_trie.c

整个方法就是通过 tkey_extract_bits 生成tnode中对应的叶子节点所在index，从而通过 tnode_get_child_rcu 拿到tnode节点中index所对应的数组中获取叶下一级别的tnode或者叶子结点。

其中查找index最为核心方法如上，这个过程，先通过key左移动pos个位，再向右边移动（32 - bits）算法找到对应index。

在这里能对路由压缩算法有一定的理解即可，本文重点不在这里。当从路由树中找到了结果就返回 fib_result 结构体。

查询的结果最为核心的就是 fib_table 路由表，存储了真正的路由转发信息

文件：/ net / ipv4 / route.c

这个方法做的事情很简单，本质上就是想要找到这个路由的下一跳是哪里？

在这里面有一个核心的结构体名为 fib_nh_exception 。这个是指fib表中去往目的地址情况下最理想的下一跳的地址。

而这个结构体在上一个方法通过 find_exception 获得.遍历从 fib_result 获取到 fib_nh 结构体中的 nh_exceptions 链表。从这链表中找到一模一样的目的地址并返回得到的。

文件：/ net / ipv4 / tcp_output.c

‘贰’ 如何在Android 内核源码树中添加app应用

1. 不带jni本地代码

首先，在Android内核源码中选择一个目录来存放HelloWorld应用的源码，比如放到/packages/apps目录下。和陪

（1） 在HelloWorld目录下新建Android.mk文件，示例如下：

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := eng
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := HelloWorld
include $(BUILD_PACKAGE)

注：LOCAL_MODULE_TAGS的备选值有user，eng，tests，optional，这里使用的TAGS值为eng，因此，毁前仅当用户指定的编译纤棚清选项为eng时才会编译该工程。

‘叁’ android内核源代码有多大

每个版本的源代码不同，几百兆到几G不等。
Android是一种基于Linux的自由及开放源桥袜代码敏弊激的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发，主卜颂要支持手机。

‘肆’ 如何在 Android 源码环境下增大 Linux 内核的 kernel log 的缓存...

需要修改 Linux 内核源码中的一个控制 log buffer size 的宏：CONFIG_LOG_BUF_SHIFT，buffer size 是 2 ^ shift，加大这个就可以。

一、配置

$ make menuconfig

General setup
（18）Kernel log buffer size (16 => 64KB，17 => 128KB)

二、源码

kernel/printk.c

#define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)

static char __log_buf[__LOG_BUF_LEN];

可以看到，是已经在编译时定死的一块静态空间，不能动态调整了。对于内核日志，唯一乱瞎嫌可以调整的在：/proc/sys/kernel/printk*

三、限制

init/Kconfig

config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 =>哗手 128KB)"神宴
range 12 21
default 17
help
Select kernel log buffer size as a power of 2.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB

可以看到 shift 最大值限制到了 21，也就是：2 M

$ echo "(2^21)/1024/1024" | bc
2

如果再要加大，只能改源码了。

‘伍’ Android源码解析RPC系列(一)---Binder原理

看了几天的Binder，决定有必要写一篇博客，记录一下学习成果，Binder是Android中比较综合的一块知识了，目前的理解只限于JAVA层。首先Binder是干嘛用的？不用说，跨进程通信全靠它，操作系统的不同进程之间，数据不共享，对于每个进程来说，它都天真地以为自己独享了整个系统，完全不知道其他进程的存在，进程之间需要通信需要某种系统机制才能完成，在Android整个系统架构中，采用了大量的C/S架构的思想，所以Binder的作用就显得非常重要了，但是这种机制为什么是Binder呢？在Linux中的RPC方式有管道，消息队列，共享内存等，消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，这样就有两次拷贝过程。共享内存不需要拷贝，但控制复杂，难以使用。Binder是个折中的方案，只需要拷贝一次就行了。其次Binder的安全性比较好，好在哪里，在下还不是很清楚，基于安全性和传输的效率考虑，选择了Binder。Binder的英文意思是粘结剂，Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，这个进程一般是Server端，该对象提供了一套方法用以实现对服务的请求，而它的引用却遍布于系统的各个进程（Client端）之中，这样Client通过Binder的引用访问Server，所以说，Binder就像胶水一样，把系统各个进程粘结在一起了，废话确实有点多。

为了从而保障了系统的安全和稳定，整个系统被划分成内核空间和用户空间
内核空间：独立于普通的应用程序，可以访问受保护的内存空间，有访问底层硬件设备的所有权限。
用户空间：相对与内核空间，上层运用程序所运行的空间就是用户空间，用户空间访问内核空间的唯一方式就是系统调用。一个4G的虚拟地址空间，其中3G是用户空间，剩余的1G是内核空间。如果一个用户空间想与另外一个用户空间进行通信，就需要内核模块支持，这个运行在内核空间的，负责各个用户进程通过Binder通信的内核模块叫做Binder驱动，虽然叫做Binder驱动，但是和硬件并没有什么关系，只是实现方式和设备驱动程序是一样的，提供了一些标准文件操作。

在写AIDL的时候，一般情况下，我们有两个进程，一个作为Server端提供某种服务，然后另外一个进程作为Client端,连接Server端之后，就 可以使用Server里面定义的服务。这种思想是一种典型的C/S的思想。值得注意的是Android系统中的Binder自身也是C/S的架构，也有Server端与Client端。一个大的C/S架构中，也有一个小的C/S架构。

先笼统的说一下，在整个Binder框架中，由系列组件组成，分别是Client、Server、ServiceManager和Binder驱动程序，其中Client、Server和ServiceManager运行在用户空间，Binder驱动程序运行内核空间。运行在用户空间中的Client、Server和ServiceManager，是在三个不同进程中的，Server进程中中定义了服务提供给Client进程使用，并且Server中有一个Binder实体，但是Server中定义的服务并不能直接被Client使用，它需要向ServiceManager注册，然后Client要用服务的时候，直接向ServiceManager要，ServiceManager返回一个Binder的替身（引用）给Client，这样Client就可以调用Server中的服务了。

场景 ：进程A要调用进程B里面的一个draw方法处理图片。

分析 ：在这种场景下，进程A作为Client端，进程B做为Server端，但是A/B不在同一个进程中，怎么来调用B进程的draw方法呢，首先进程B作为Server端创建了Binder实体，为其取一个字符形式，可读易记的名字，并将这个Binder连同名字以数据包的形式通过Binder驱动发送给ServiceManager，也就是向ServiceManager注册的过程，告诉ServiceManager，我是进程B，拥有图像处理的功能，ServiceManager从数据包中取出名字和引用以一个注册表的形式保留了Server进程的注册信息。为什么是以数据包的形式呢，因为这是两个进程，直接传递对象是不行滴，只能是一些描述信息。现在Client端进程A联系ServiceManager，说现在我需要进程B中图像处理的功能，ServiceManager从注册表中查到了这个Binder实体，但是呢，它并不是直接把这个Binder实体直接给Client,而是给了一个Binder实体的代理，或者说是引用，Client通过Binder的引用访问Server。分析到现在，有个关键的问题需要说一下，ServiceManager是一个进程，Server是另一个进程，Server向ServiceManager注册Binder必然会涉及进程间通信。当前实现的是进程间通信却又要用到进程间通信，这就好象蛋可以孵出鸡前提却是要找只鸡来孵蛋，确实是这样的，ServiceManager中预先有了一个自己的Binder对象（实体），就是那只鸡，然后Server有个Binder对象的引用，就是那个蛋，Server需要通过这个Binder的引用来实现Binder的注册。鸡就一只，蛋有很多，ServiceManager进程的Binder对象（实体）仅有一个，其他进程所拥有的全部都是它的代理。同样一个Server端Binder实体也应该只有一个，对应所有Client端全部都是它的代理。

我们再次理解一下Binder是什么？在Binder通信模型的四个角色里面；他们的代表都是“Binder”，一个Binder对象就代表了所有，包括了Server，Client,ServiceManager,这样，对于Binder通信的使用者而言，不用关心实现的细节。对Server来说，Binder指的是Binder实体，或者说是本地对象，对于Client来说，Binder指的是Binder代理对象，也就是Binder的引用。对于Binder驱动而言，在Binder对象进行跨进程传递的时候，Binder驱动会自动完成这两种类型的转换。

简单的总结一下，通过上面一大段的分析，一个Server在使用的时候需要经历三个阶段

1、定义一个AIDL文件
Game.aidl

GameManager .aidl

2、定义远端服务Service
在远程服务中的onBind方法，实现AIDL接口的具体方法，并且返回Binder对象

3、本地创建连接对象

以上就是一个远端服务的一般套路，如果是在两个进程中，就可以进程通信了，现在我们分析一下，这个通信的流程。重点是GameManager这个编译生成的类。

从类的关系来看，首先接口GameManager 继承 IInterface ，IInterface是一个接口，在GameManager内部有一个内部类Stub，Stub继承了Binder，（Binder实现了IBinder），并且实现了GameManager接口，在Stub中还有一个内部类Proxy，Proxy也实现了GameManager接口，一个整体的结构是这样的

现在的问题是，Stub是什么？Proxy又是什么？在上面说了在Binder通信模型的四个角色里面；他们的代表都是“Binder”，一个Binder对象就代表了所有，包括了Server，Clinet，ServiceManager，为了两个进程的通信，系统给予的内核支持是Binder,在抽象一点的说,Binder是系统开辟的一块内存空间，两个进程往这块空间里面读写数据就行了，Stub从Binder中读数据，Proxy向Binder中写数据,达到进程间通信的目的。首先我们分析Stub。

Stub 类继承了Binder ，说明了Stub有了跨进程传输的能力，实现了GameManager接口，说明它有了根据游戏ID查询一个游戏的能力。我们在bind一个Service之后，在onServiceConnecttion的回调里面，就是通过asInterface方法拿到一个远程的service的。

asInterface调用queryLocalInterface。

mDescriptor，mOwner其实是Binder的成员变量，Stub继承了Binder，在构造函数的时候，对着两个变量赋的值。

如果客户端和服务端是在一个进程中，那么其实queryLocalInterface获取的就是Stub对象，如果不在一个进程queryLocalInterface查询的对象肯定为null，因为不同进程有不同虚拟机，肯定查不到mOwner对象的，所以这时候其实是返回的Proxy对象了。拿到Stub对象后，通常在onServiceConnected中，就把这个对象转换成我们多定义AIDL接口。

比如我们这里会转换成GameManager，有了GameManager对象，就可以调用后querryGameById方法了。如果是一个进程，那直接调用的是自己的querryGameById方法，如果不是一个进程，那调用了就是代理的querryGameById方法了。

看到其中关键的一行是

mRemote就是一个IBinder对象，相对于Stub，Proxy 是组合关系（HAS-A），内部有一个IBinder对象mRemote，Stub是继承关系(IS-A)，直接实现了IBinder接口。

transact是个native方法，最终还会回掉JAVA层的onTransact方法。

onTransact根据调用号（每个AIDL函数都有一个编号，在跨进程的时候，不会传递函数，而是传递编号指明调用哪个函数）调用相关函数；在这个例子里面，调用了Binder本地对象的querryGameById方法；这个方法将结果返回给驱动，驱动唤醒挂起的Client进程里面的线程并将结果返回。于是一次跨进程调用就完成了。

***Please accept mybest wishes for your happiness and success ! ***

‘陆’ 按android官网下载的android源码里面有linux内核kernel吗

从源代码树下载下来的最新Android源代码，是不包括内核代码的，也就是Android源代码工程默认不包含Linux Kernel代码，而是使用预先编译好的内核，也就是prebuilt/android-arm/kernel/kernel-qemu文件。

‘柒’ Android 重学系列 ion驱动源码浅析

上一篇文章，在解析初始化GraphicBuffer中，遇到一个ion驱动，对图元进行管理。首先看看ion是怎么使用的：

我们按照这个流程分析ion的源码。

如果对ion使用感兴趣，可以去这篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744

本文基于Android的Linux内核版本3.1.8

遇到什么问题欢迎来本文讨论 https://www.jianshu.com/p/5fe57566691f

什么是ion？如果是音视频，Camera的工程师会对这个驱动比较熟悉。最早的GPU和其他驱动协作申请一块内存进行绘制是使用比较粗暴的共享内存。在Android系统中使用的是匿名内存。最早由三星实现了一个Display和Camera共享内存的问题，曾经在Linux社区掀起过一段时间。之后各路大牛不断的改进之下，就成为了dma_buf驱动。并在 Linux-3.3 主线版本合入主线。现在已经广泛的运用到各大多媒体开发中。

首先介绍dma_buf的2个角色，importer和exporter。importer是dma_buf驱动中的图元消费者，exporter是dma_buf驱动中的图元生产者。

这里借用大佬的图片：

ion是基于dma_buf设计完成的。经过阅读源码，其实不少思路和Android的匿名内存有点相似。阅读本文之前就算不知道dma_buf的设计思想也没关系，我不会仔细到每一行，我会注重其在gralloc服务中的申请流程，看看ion是如何管理共享内存，为什么要抛弃ashmem。

我们先来看看ion的file_operation:

只有一个open和ioctl函数。但是没有mmap映射。因此mmap映射的时候一定其他对象在工作。

我们关注显卡英伟达的初始化模块。
文件：/ drivers / staging / android / ion / tegra / tegra_ion.c

mole_platform_driver实际上就是我之前经常提到过的mole_init的一个宏,多了一个register注册到对应名字的平台中的步骤。在这里面注册了一个probe方法指针，probe指向的tegra_ion_probe是加载内核模块注册的时候调用。

先来看看对应的结构体：

再来看看对应ion内的堆结构体：

完成的事情如下几个步骤：

我们不关注debug模式。其实整个就是我们分析了很多次的方法。把这个对象注册miscdevice中。等到insmod就会把整个整个内核模块从dev_t的map中关联出来。

我们来看看这个驱动结构体：

文件：/ drivers / staging / android / ion / ion_heap.c

这里有四个不同堆会申请出来，我们主要来看看默认的ION_HEAP_TYPE_SYSTEM对应的heap流程。

其实真正象征ion的内存堆是下面这个结构体

不管原来的那个heap，会新建3个ion_system_heap，分别order为8，4，0,大于4为大内存。意思就是这个heap中持有一个ion_page_pool 页资源池子，里面只有对应order的2的次幂，内存块。其实就和伙伴系统有点相似。

还会设置flag为ION_HEAP_FLAG_DEFER_FREE，这个标志位后面会用到。

文件：/ drivers / staging / android / ion / ion_page_pool.c

在pool中分为2个链表一个是high_items，另一个是low_items。他们之间的区分在此时就是以2为底4的次幂为分界线。

文件：/ drivers / staging / android / ion / ion.c

因为打开了标志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此会初始化两个回收函数。

文件：/ drivers / staging / android / ion / ion_heap.c

此时会创建一个内核线程，调用ion_heap_deferred_free内核不断的循环处理。不过由于这个线程设置的是SCHED_IDLE，这是最低等级的时间片轮转抢占。和Handler那个adle一样的处理规则，就是闲时处理。

在这个循环中，不断的循环销毁处理heap的free_list里面已经没有用的ion_buffer缓冲对象。

文件：/ drivers / staging / android / ion / ion_system_heap.c

注册了heap的销毁内存的方法。当系统需要销毁页的时候，就会调用通过register_shrinker注册进来的函数。

文件：/ drivers / staging / android / ion / ion_page_pool.c

整个流程很简单，其实就是遍历循环需要销毁的页面数量，接着如果是8的次幂就是移除high_items中的page缓存。4和0则销毁low_items中的page缓存。至于为什么是2的次幂其实很简单，为了销毁和申请简单。__free_pages能够整页的销毁。

文件：/ drivers / staging / android / ion / ion.c

主要就是初始化ion_client各个参数，最后把ion_client插入到ion_device的clients。来看看ion_client结构体：

核心还是调用ion_alloc申请一个ion缓冲区的句柄。最后把数据拷贝会用户空间。

这个实际上就是找到最小能承载的大小，去申请内存。如果8kb申请内存，就会拆分积分在0-4kb，4kb-16kb，16kb-128kb区间找。刚好dma也是在128kb之内才能申请。超过这个数字就禁止申请。8kb就会拆成2个4kb保存在第一个pool中。

最后所有的申请的page都添加到pages集合中。

文件：/ drivers / staging / android / ion / ion_page_pool.c

能看到此时会从 ion_page_pool冲取出对应大小区域的空闲页返回上层，如果最早的时候没有则会调用ion_page_pool_alloc_pages申请一个新的page。由于引用最终来自ion_page_pool中，因此之后申请之后还是在ion_page_pool中。

这里的处理就是为了避免DMA直接内存造成的缓存差异(一般的申请，默认会带一个DMA标志位)。换句话说，是否打开cache其实就是，关闭了则使用pool的cache，打开了则不使用pool缓存，只依赖DMA的缓存。

我们可以看另一个dma的heap，它是怎么做到dma内存的一致性.
文件： drivers / staging / android / ion / ion_cma_heap.c

能看到它为了能办到dma缓存的一致性，使用了dma_alloc_coherent创建了一个所有强制同步的地址，也就是没有DMA缓存的地址。

这里出现了几个新的结构体，sg_table和scatterlist

文件：/ lib / scatterlist.c

这里面实际上做的事情就是一件：初始化sg_table.
sg_table中有一个核心的对象scatterlist链表。如果pages申请的对象数量<PAGE_SIZE/sizeof(scatterlist),每一项sg_table只有一个scatterlist。但是超出这个数字就会增加一个scatterlist。

用公式来说：

换句话说，每一次生成scatterlist的链表就会直接尽可能占满一页，让内存更好管理。

返回了sg_table。

初始化ion_handle，并且记录对应的ion_client是当前打开文件的进程，并且设置ion_buffer到handle中。使得句柄能够和buffer关联起来。

每当ion_buffer需要销毁，

‘捌’ 编译Android源码和内核源码的区别

Android源码编译之后生成的是ramdisk.img、system.img和userdata.img。而内核源码编译完成之后生成的是ZImage。在一般情况下Android源码是不带有内核源码的，但是带有一个镜像，这样在编译完Android源码之后就可以模拟器启动了，如果要更换系统的内核，此时将高版本的内核源码进行编译生成ZImage然后替换Android系统的的镜像。这样使用模拟器启动之后就可以查看内核是否已经被刷新。
请注意，android源码和kernel源码是分开下载的

编译android源码
进入source目录下，执行make 即可。
编译完成后，可以在源码目录的out/target/proct/generic/目录下看到编译好的ramdisk.img、system.img和userdata.img了。

编译内核源码
新建Kernel/goldfish，在这个目录下进行编译

‘玖’ 安卓内核源码大小

android是一个大型的软件系统，其内核源码包含了很多不同唯顷的组件，具体的大小取决喊山拆于安装的版本。一般来说，Android 内核源码的总郑枣大小约为10GB到20GB，如果需要下载所有的源代码更新，可能会达到50GB以上。

‘拾’ android源码中已经包括了内核为什么还要goldfish

我也苦恼了几天，不过刚弄到。步骤是这样的：先进入git下面的common目录，输入命令：git branch -a会列出所有的分支：* android-2.6.36 remotes/origin/HEAD -> origin/android-2.6.36 remotes/origin/android-2.6.35 remotes/origin/android-2.6.36 remotes/origin/archive/android-2.6.25 remotes/origin/archive/android-2.6.27 remotes/origin/archive/android-2.6.29 remotes/origin/archive/android-2.6.32 remotes/origin/archive/android-gldfish-2.6.29 remotes/origin/archive/android-goldfish-2.6.27如上。然后再执行git checkout origin/archive/android-goldfish-2.6.27 -b goldfish命令，一会就可以了。这样就有golfish的部分代码了。 查看原帖>>