android源码树

1. 如何针对特定机型，编译cwm recovery

你必须使用32位或64位Ubuntu系统，关于如何建立编译环境和同步源码的指导，请自己查找有关指导的文章。
1,
安装所需要的包
2,
建立编译的环境，并同步CWM所需的源码，CyanogenMod源码中附带CWM源码
CWM
5
-
Gingerbread
CWM
6
-
Jellybean
3,
下面我们进入真正的编译阶段，确保你已经使用“repo
sync
”命令同步了最新的源码
进入源码的目录
放出以下命令：
make
-j4
otatools
3.5,
如果你的机型不被CM10官方支持，请执行这一步
在你的手机终端上执行以下命令，
mp_image
boot
/sdcard/boot.img
这将boot镜像导出到你手机的sdcard，复制该镜像至你的home目录下
为一款新设备编译android源码，需要建立相应的配置文件和makefile文件，这通常比较麻烦，如果仅仅编译recovery镜像，会容易的多。在android源码根目录下（假设已运行envsetup.sh），运行以下命令（使用适当的名称取代命令中的名称）
build/tools/device/mkvendor.sh
device_manufacturer_name
device_name
/your/path/to/the/boot.img
例如，你拥有Samsung
Galaxy
Ace这款设备，你应该使用以下这条命令
build/tools/device/mkvendor.sh
Samsung
cooper
~/boot.img
Please
note
that
Cooper
is
the
device
name.
Only
use
"~/boot.img"
if
you
have
the
boot
image
in
your
home
directory.
Or
else
please
specify
the
correct
path.
如果所有都工作正常，你将看到"Done!"这样的确认信息。mkvendor.sh脚本也将在你的android源码树中创建以下目录：
manufacturer_name/device_name
4，
现在你已经拥有相关的配置文件
在源码目录下，在terminal终端下键入以下命令
.
build/envsetup.sh
这一步将为你建立编译环境
现在使用这条命令
lunch
full_device_name-eng
这将为你的设备建立起build
system。用文件管理器或IDE打开目录，你应该拥有以下文件：
AndroidBoard.mk,
AndroidProcts.mk,
BoardConfig.mk,
device_.mk,
kernel,
system.prop,
recovery.fstab,
和
vendorsetup.sh
对你感兴趣的应该是recovery.fstab和kernel这两个文件，kernel这个文件是你之前从boot.img文件中提取出的。recovery.fstab将适用于大部分拥有
mtd,
emmc,或者其他分区的设备。如果没有，recovery.fstab将需要优化以支持加载这些点。例如
/sdcard被加载至/dev/block/mmcblk1p1，
你需要将下面这段加入到你的BoardConfig.mk文件中
/sdcard
vfat
/dev/block/mmcblk1p1
一旦recovery.fstab已经适当的装载，你可以开始下一步了
5，
现在，我们开始编译Recovery
make
-j4
recoveryimage
这个命令用于编译recovery镜像
你能使用这个命令
make
-j4
recoveryzip
用于建立一个临时的recovery.zip刷机包在你真实的设备上测试
你编译好的recovery可以在"your_source_directory/OUT/target/proct/device/recovery.img"目录下找到。而.zip刷机包可以在相同目录下的utilities文件夹下找到。
如果各项测试正常，就可以有一个成功的recovery
一旦你编译通过了recovery，通知"koush"，在Github上，他就能根据你的编译文件发放官方版的CWM
Recovery，并使Rom
Manager提供相应的支持。
小贴士：
如果你想编译CWM6，使用以下命令同步jellybean分支源码
repo
init
-u
git://github.com/CyanogenMod/android.git
-b
jellybean

repo
sync
如果你改变了BoardConfig.mk文件，在编译期间运行"make
clobber"，否则你做的更改就不会生效。

2. 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

3. 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 ! ***

4. android系统源码有多少行

大概有10G的源代码，一Byte一个字符，也就是说有超过100亿个字符，每行按标准80字符来算的话，超过1亿行。开放的WinXP系统有2亿行，从数量级上来看的话，应该差不多。Android 4.4，是由Google公司制作和研发的代号为KitKat的手机操作系统，于北京时间2013年9月4日凌晨对外公布了该Android新版本的名称，为Android 4.4(代号 KitKat 奇巧)。据悉，该代号来自雀巢的KitKat巧克力。"Kit Kat"原本是雀巢公司的一款巧克力名称。谷歌表示，他们非常感谢雀巢授权使用该名称，但使用的时候会将中间的空格去掉。Android 4.4 KitKat针对RAM占用进行了优化，甚至可以在一些仅有512MB RAM的老款手机上流畅运行。它也进一步优化了系统在低配硬件上的运行效果， 支持内核同页合并 KSM,zRAM 交换，似乎是为了更好地在众多智能穿戴设备上运行。
是指sdk的源码，还是android操作系统的源码，不过都有10G左右，另外sdk的源码是用git管理的，一次下载后，用git check就可以切换到各个版本。Android SDK是用于开发Android上JAVA应用程序的，另外发布Android NDK，可以添加一些C语言写的链接库，至于Linux代码，可以在Android源代码中找到（SDK程序中只有编译好的测试映像）。应用程序开发用不到Linux代码（搞嵌入式开发才会用到，而SDK不负责底层开发）。

5. 按android官网下载的android源码里面有linux内核kernel吗

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

6. android开发用libcurl多吗

下面是移植步骤：
1. 下载curl源码
我这里下载的是curl-7.22.0，源码下载地址为：http://curl.haxx.se/download.html

2. 准备android源码编译环境，
android源码应已全部编译过，具体细节这里不详述，我这里使用的是android2.2 froyo源码树。

3. 在android中编译curl
在最新的curl源码里其实已经带有Android.mk这个编译文件了，而且在这文件的开头注释部分比较详细地介绍编译方法。
1）拷贝curl源码至android源码树下的external/curl

2）cd 到 external/curl目录下，输入（红色字部分根据自己的环境做相应的更改）：
ANDROID_HOME=/home/braincol/workspace/android/froyo && \
NDK_HOME=/home/braincol/workspace/android/froyo/ndk && \
PATH="$ANDROID_HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin:$PATH" \
./configure --host=arm-linux CC=arm-eabi-gcc --with-random=/dev/urandom \
CPPFLAGS="-I$NDK_HOME/platforms/android-8/arch-arm/usr/include \
-I $ANDROID_HOME/external/curl/include/ \
-I $ANDROID_HOME/external/curl/3rd/include \
-I $ANDROID_HOME/external/curl \
-I $ANDROID_HOME/out/target/proct/generic/obj/STATIC_LIBRARIES/libcurl_intermediates \
-I $ANDROID_HOME/dalvik/libnativehelper/include/nativehelper \
-I $ANDROID_HOME/system/core/include \
-I $ANDROID_HOME/hardware/libhardware/include \
-I $ANDROID_HOME/hardware/libhardware_legacy/include \
-I $ANDROID_HOME/hardware/ril/include \
-I $ANDROID_HOME/dalvik/libnativehelper/include \
-I $ANDROID_HOME/frameworks/base/include \
-I $ANDROID_HOME/frameworks/base/opengl/include \
-I $ANDROID_HOME/frameworks/base/native/include \
-I $ANDROID_HOME/external/skia/include \
-I $ANDROID_HOME/out/target/proct/generic/obj/include \
-I $ANDROID_HOME/bionic/libc/arch-arm/include \
-I $ANDROID_HOME/bionic/libc/include \
-I $ANDROID_HOME/bionic/libstdc++/include \
-I $ANDROID_HOME/bionic/libc/kernel/common \
-I $ANDROID_HOME/bionic/libc/kernel/arch-arm \
-I $ANDROID_HOME/bionic/libm/include \
-I $ANDROID_HOME/bionic/libm/include/arch/arm \
-I $ANDROID_HOME/bionic/libthread_db/include \
-include $ANDROID_HOME/system/core/include/arch/linux-arm/AndroidConfig.h \
-I $ANDROID_HOME/system/core/include/arch/linux-arm/ \
-D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -DANDROID -DNDEBUG -DNDEBUG -DHAVE_CONFIG_H" \
CFLAGS="-fno-exceptions -Wno-multichar -msoft-float -fpic -ffunction-sections \
-funwind-tables -fstack-protector -Wa,--noexecstack -Werror=format-security \
-fno-short-enums -march=armv5te -mtune=xscale -Wno-psabi -mthumb-interwork \
-fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith \
-Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point \
-g -Wstrict-aliasing=2 -finline-functions -fno-inline-functions-called-once \
-fgcse-after-reload -frerun-cse-after-loop -frename-registers -UDEBUG \
-mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 \
-Wpointer-arith -Wwrite-strings -Wunused -Winline -Wnested-externs \
-Wmissing-declarations -Wmissing-prototypes -Wno-long-long -Wfloat-equal \
-Wno-multichar -Wsign-compare -Wno-format-nonliteral -Wendif-labels \
-Wstrict-prototypes -Wdeclaration-after-statement -Wno-system-headers" \
LIBS="-nostdlib -Bdynamic -Wl,-T,$ANDROID_HOME/build/core/armelf.x \
-Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,noreloc \
-L$ANDROID_HOME/out/target/proct/generic/obj/lib -Wl,-z,noexecstack \
-Wl,-rpath-link=$ANDROID_HOME/out/target/proct/generic/obj/lib \
-lc -llog -lcutils -lstdc++ \
-Wl,--no-undefined $ANDROID_HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0/libgcc.a \
$ANDROID_HOME/out/target/proct/generic/obj/lib/crtend_android.o \
-lm $ANDROID_HOME/out/target/proct/generic/obj/lib/crtbegin_dynamic.o \
-L$ANDROID_HOME/external/curl/3rd/libs"

如果$ANDROID_HOME目录下没有ndk的开发包，那么到google的官网上下载一个放进去就行了。

3）cd 到源码根目录 mmm extern/libcurl：
编译完成之后，会生成静态库：out/target/proct/generic/obj/STATIC_LIBRARIES/libcurl_intermediates/libcurl.a 。

4）如果要生成动态库需要修改curl下的Android.mk ：
LOCAL_PRELINK_MODULE := false
LOCAL_MODULE:= libcurl
LOCAL_MODULE_TAGS := optional
# Copy the licence to a place where Android will find it.
# Actually, this doesn't quite work because the build system searches
# for NOTICE files before it gets to this point, so it will only be seen
# on subsequent builds.
ALL_PREBUILT += $(LOCAL_PATH)/NOTICE
$(LOCAL_PATH)/NOTICE: $(LOCAL_PATH)/COPYING | $(ACP)
$(-file-to-target)
#include $(BUILD_STATIC_LIBRARY)
include $(BUILD_SHARED_LIBRARY)

4. 在android中测试curl
1）在android froyo源码树中下建立一个mytest目录，该目录下再建立一个curltest目录。

2）在目录curtest下创建curl-test.cpp：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include "curl/curl.h"
#include <stdio.h>;
int main() {
CURL *curl;
CURLcode res;

curl_global_init(CURL_GLOBAL_ALL);

curl = curl_easy_init();
if (curl) {
curl_easy_setopt(curl, CURLOPT_URL, "http://www.cnblogs.com/hibraincol/");
res = curl_easy_perform(curl);
if (0!=res) {
printf("curl error: %d\n", res);
}

curl_easy_cleanup(curl);
}

curl_global_cleanup();
return 0;
}

3）在目录curtest下创建Android.mk：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# curl test executable
#
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_C_INCLUDES += \
$(LOCAL_PATH)/3rd/include

LOCAL_SRC_FILES:= curl-test.cpp

# No shared libraries.
LOCAL_SHARED_LIBRARIES :=

# No static libraries.
LOCAL_STATIC_LIBRARIES := libcurl

LOCAL_MODULE := curl-test
include $(BUILD_EXECUTABLE)

4）把libcurl的头文件拷贝到curtest目录下的3rd/include目录下：
cp -rf out/target/proct/generic/obj/include/libcurl/curl mytest/curltest/3rd/include

5）到android源码树的根目录下：mmm /mytest/curltest/
braincol@ubuntu:~/workspace/android/froyo$ mmm mytest/curltest/
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.2
TARGET_PRODUCT=generic
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=MASTER
============================================
make: Entering directory `/home/braincol/workspace/android/froyo'
target thumb C++: curl-test <= mytest/curltest/curl-test.cpp
mytest/curltest/curl-test.cpp:2:19: warning: extra tokens at end of #include directive
target Executable: curl-test (out/target/proct/generic/obj/EXECUTABLES/curl-test_intermediates/LINKED/curl-test)
target Non-prelinked: curl-test (out/target/proct/generic/symbols/system/bin/curl-test)
target Strip: curl-test (out/target/proct/generic/obj/EXECUTABLES/curl-test_intermediates/curl-test)
Install: out/target/proct/generic/system/bin/curl-test
make: Leaving directory `/home/braincol/workspace/android/froyo'

可以看到在out/target/proct/generic/system/bin/下生成了curl-test这个测试程序。

6）将curl-test拷贝到真机或者模拟器中运行。
a.我这里是在android真机的根目录下建立了一个test目录.
b.然后通过adb push将curl-test拷贝到该目录下，并更改curl-test为可执行权限：chmod 777 curl-test.
c. adb shell 进入shell控制台，然后cd到test目录下， ./curl-test 执行，可以看到打印出的网页源码，移植成功。

这样在之后的android app开发中，如果需要用到libcurl的库，就可以直接out/target/proct/generic/obj/include/libcurl/curl里的头文件和out/target/proct/generic/obj/STATIC_LIBRARIES/libcurl_intermediates/libcurl.a拿到app工程中去用就行了。

7. 编译android 源码需要sdk环境吗

下面是android学习手册，可以查看编译源码，360手机助手中下载，

编译环境：ubuntu9.10，widnows平台目前不被支持。

1）安装必要的软件环境

$ sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev

官方推荐的就是上面这些，如果在编译过程中发现某些命令找不到，就apt-get它。可能需要的包还有：

$ sudo apt-get install make
$ sudo apt-get install gcc
$ sudo apt-get install g++
$ sudo apt-get install libc6-dev

$ sudo apt-get install patch
$ sudo apt-get install texinfo

$ sudo apt-get install zlib1g-dev
$ sudo apt-get install valgrind
$ sudo apt-get install python2.5（或者更高版本）

需要注意的是，官方文档说如果用sun-java6-jdk可出问题，得要用sun-java5- jdk。经测试发现，如果仅仅make（make不包括make sdk），用sun-java6-jdk是没有问题的。而make sdk，就会有问题，严格来说是在make doc出问题，它需要的javadoc版本为1.5。

因此，我们安装完sun-java6-jdk后最好再安装sun-java5-jdk，或者只安装sun-java5-jdk。这里sun-java6-jdk和sun-java5-jdk都安装，并只修改javadoc.1.gz和javadoc。因为只有这两个是make sdk用到的。这样的话，除了javadoc工具是用1.5版本，其它均用1.6版本：

$ sudo apt-get install sun-java6-jdk

修改javadoc的link：

$ cd /etc/alternatives
$ sudo rm javadoc.1.gz
$ sudo ln -s /usr/lib/jvm/java-1.5.0-sun/man/man1/javadoc.1.gz javadoc.1.gz
$ sudo rm javadoc
$ sudo ln -s /usr/lib/jvm/java-1.5.0-sun/bin/javadoc javadoc

2）设置环境变量

$ emacs ~/.bashrc

在.bashrc中新增或整合PATH变量，如下：

#java 程序开发/运行的一些环境变量

JAVA_HOME=/usr/lib/jvm/java-6-sun
JRE_HOME=${JAVA_HOME}/jre
export ANDROID_JAVA_HOME=$JAVA_HOME
export CLASSPATH=.:${JAVA_HOME}/lib:$JRE_HOME/lib:$CLASSPATH
export JAVA_PATH=${JAVA_HOME}/bin:${JRE_HOME}/bin
export JAVA_HOME;
export JRE_HOME;
export CLASSPATH;
HOME_BIN=~/bin/
export PATH=${PATH}:${JAVA_PATH}:${HOME_BIN};

保存后，同步更新：

source ~/.bashrc

3）安装repo（用来更新android源码）

创建~/bin目录，用来存放repo程序，如下：

$ cd ~
$ mkdir bin

并加到环境变量PATH中，在第2步中已经加入。

下载repo脚本并使其可执行：

$ curlhttp://android.git.kernel.org/repo>~/bin/repo
$ chmod a+x ~/bin/repo

4）初始化repo

repo是android对git的一个封装，简化了一些git的操作。

创建工程目录：

$ mkdir android
$ cd android

repo初始化：

$ repo init -u git://android.git.kernel.org/platform/manifest.git

在此过程中需要输入名字和email地址。初始化成功后，会显示：

repo initialized in /android

在~/android下会有一个.repo的隐藏目录。

5）同步源代码

$ repo sync

这一步要很久很久。

6）编译android源码,并得到~/android/out目录

$ cd ~/andoird
$ make

这一过程很久。

7）在模拟器上运行编译好的android

编译好android之后，emulator在~/android/out/host/linux-x86/bin下，ramdisk.img，system.img和userdata.img则在~/android/out/target/proct/generic下。

$ cd ~/android/out/host/linux-x86/bin

增加环境变量

$ emacs ~/.bashrc

在.bashrc中新增环境变量，如下

#java 程序开发/运行的一些环境变量

export ANDROID_PRODUCT_OUT=~/android/out/target/proct/generic
ANDROID_PRODUCT_OUT_BIN=~/android/out/host/linux-x86/bin
export PATH=${PATH}:${ANDROID_PRODUCT_OUT_BIN}:${ANDROID_PRODUCT_OUT};

最后，同步这些变化：

$ source ~/.bashrc
$ cd ~/android/out/target/proct/generic
$ emulator -system system.img -data userdata.img -ramdisk ramdisk.img

最后进入android桌面，就说明成功了。

8）编译模块

android中的一个应用程序可以单独编译，编译后要重新生成system.img。

在源码目录下执行

$ . build/envsetup.sh （.后面有空格）

就多出一些命令：

- croot: Changes directory to the top of the tree.
- m: Makes from the top of the tree.
- mm: Builds all of the moles in the current directory.
- mmm: Builds all of the moles in the supplied directories.
- cgrep: Greps on all local C/C++ files.
- jgrep: Greps on all local Java files.
- resgrep: Greps on all local res/*.xml files.
- godir: Go to the directory containing a file.

可以加—help查看用法。

我们可以使用mmm来编译指定目录的模块，如编译联系人：

$ mmm packages/apps/Contacts/

编完之后生成两个文件：

out/target/proct/generic/data/app/ContactsTests.apk
out/target/proct/generic/system/app/Contacts.apk

可以使用

$ make snod

重新生成system.img，再运行模拟器。

9）编译SDK

直接执行make是不包括make sdk的。make sdk用来生成SDK，这样，我们就可以用与源码同步的SDK来开发android了。

a）修改/frameworks/base/include/utils/Asset.h

‘UNCOMPRESS_DATA_MAX = 1 * 1024 * 1024’ 改为 ‘UNCOMPRESS_DATA_MAX = 2 * 1024 * 1024’

原因是eclipse编译工程需要大于1.3M的buffer；

b）编译ADT

由于本人不使用eclipse，所以没有进行这步；

c）执行make sdk

注意，这里需要的javadoc版本为1.5，所以你需要在步骤1中同时安装sun-java5-jdk

$ make sdk

编译很慢。编译后生成的SDK存放在out/host/linux-x86/sdk/，此目录下有android-sdk_eng.xxx_linux- x86.zip和android-sdk_eng.xxx_linux-x86目录。android-sdk_eng.xxx_linux-x86就是 SDK目录。

实际上，当用mmm命令编译模块时，一样会把SDK的输出文件清除，因此，最好把android-sdk_eng.xxx_linux-x86移出来。

此后的应用开发，就在该SDK上进行，所以把7）对于~/.bashrc的修改注释掉，增加如下一行：

export PATH=${PATH}:~/android/out/host/linux-x86/sdk/android-sdk_eng.xxx_linux-x86/tools

注意要把xxx换成真实的路径；

d）关于环境变量、android工具的选择

目前的android工具有：

A、我们从网上下载的Android SDK，如果你下载过的话（ tools下有许多android工具，lib/images下有img映像）
B、我们用make sdk编译出来的SDK（ tools下也有许多android工具，lib/images下有img映像）
C、我们用make编译出来的out目录（ tools下也有许多android工具，lib/images下有img映像）

那么我们应该用那些工具和img呢？

首先，我们一般不会用A选项的工具和img，因为一般来说它比较旧，也源码不同步。其次，也不会用C选项的工具和img，因为这些工具和img没有经过SDK的归类处理，会有工具和配置找不到的情况；事实上，make sdk产生的很多工具和img，在make编译出来out目录的时候，已经编译产生了，make sdk只是做了而已。

e）安装、配置ADT
略过；

f）创建Android Virtual Device

编译出来的SDK是没有AVD（Android Virtual Device）的，我们可以通过android工具查看：

$ android list

创建AVD：

$ android create avd -t 1 -n myavd

可以android –help来查看上面命令选项的用法。创建中有一些选项，默认就行了。

再执行android list，可以看到AVD存放的位置。

以后每次运行emulator都要加-avd myavd或@myavd选项：

$ emulator -avd myavd

10）编译linux内核映像

a）准备交叉编译工具链

android代码树中有一个prebuilt项目，包含了我们编译内核所需的交叉编译工具。

b）设定环境变量

$ emacs ~/.bashrc

增加如下两行：

export PATH=$PATH:~/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
export ARCH=arm

保存后，同步变化：

$ source ~/.bashrc

c）获得合适的内核源代码

$ cd ~/android

获得内核源代码仓库

$ git clone git://android.git.kernel.org/kernel/common.git kernel
$ cd kernel
$ git branch

显示

* android-2.6.27

说明你现在在android-2.6.27这个分支上，也是kernel/common.git的默认主分支。

显示所有head分支：

$ git branch -a

显示

* android-2.6.27
remotes/origin/HEAD -> origin/android-2.6.27
remotes/origin/android-2.6.25
remotes/origin/android-2.6.27
remotes/origin/android-2.6.29
remotes/origin/android-goldfish-2.6.27
remotes/origin/android-goldfish-2.6.29

我们选取最新的android-goldfish-2.6.29，其中goldfish是android的模拟器模拟的CPU。

$ git checkout -b android-goldfish-2.6.29 origin/android-goldfish-2.6.29
$ git branch

显示

android-2.6.27
* android-goldfish-2.6.29

我们已经工作在android-goldfish-2.6.29分支上了。

d）设定交叉编译参数

打开kernel目录下的Makefile文件，把CROSS_COMPILE指向刚才下载的prebuilt中的arm-eabi编译器.

CROSS_COMPILE ?= arm-eabi-

把

LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,
$(call ld-option, -Wl$(comma)–build-id,))

这一行注释掉，并且添加一个空的LDFLAGS_BUILD_ID定义，如下:

LDFLAGS_BUILD_ID =

e）编译内核映像

$ cd ~/android/kernel
$ make goldfish_defconfig
$ make

f）测试生成的内核映像

$ emulator -avd myavd -kernel ~/android/kernel/arch/arm/boot/zImage

8. 如何在Android上集成ffmpeg

下面把具体编译步骤描述如下，假定NDK安装在~/android-ndk-r7：
1. 首先从FFmpeg官网下载最新的release版本源码ffmpeg-0.11.tar.gz解压缩到Android源码树的ffmpeg/下。
2 准备一个编译脚本build_android.sh并放在ffmpeg/下面，这个脚本也是Rockplayer提供的，需做一些修改，其内容附在后面。目前用的也会附在后面。
3 在ffmpeg目录下运行./build_android.sh开始编译FFmpeg，编译好的libffmpeg.so会放在文件夹android里面，一共有3个版本分别对应3种ARM体系结构，包括armv7-a、armv7-a-vfp、armv6_vfp，根据所运行的硬件平台选取其中一个版本。为了编译使用FFmpeg的程序时可以方便地找到libffmpeg.so，可将它复制到$OUT/system/lib/和$OUT/obj/lib/，当然这一步也可以加在build_android.sh中做。
4. 接下来就是编译可执行文件ffmpeg了，这个工具可以在命令行下完成FFmpeg提供的几乎所有功能包括编码、解码、转码等，也是用来调试和验证很有用的工具。其实上述编译完后在$ANDROID_BUILD_TOP/external/ffmpeg/下也会生成ffmpeg，但是在设备上无法运行。为了编出能在设备上运行的ffmpeg，可以写一个简单的Android.mk，

9. android 系统签名

也有提到怎么单独给一个apk签名，这里补充一下android的签名权限控制机制。

android的标准签名key有：

     testkey

     media

    latform

    hared

    以上的四种，可以在源码的/build/target/proct/security里面看到对应的密钥，其中shared.pk8代表私钥，shared.x509.pem公钥，一定是成对出现的。

    其中testkey是作为android编译的时候默认的签名key，如果系统中的apk的android.mk中没有设置LOCAL_CERTIFICATE的值，就默认使用testkey。

   而如果设置成：

   LOCAL_CERTIFICATE := platform

    就代表使用platform来签名，这样的话这个apk就拥有了和system相同的签名，因为系统级别的签名也是使用的platform来签名，此时使用android:sharedUserId="android.uid.system"才有用！

     在/build/target/proct/security目录下有个README，里面有说怎么制作这些key以及使用问题（android4.2）：

     从上面可以看出来在源码下的/development/tools目录下有个make_key的脚本，通过传入两个参数就可以生成一对签名用的key。

    其中第一个为key的名字，一般都默认成android本身有的，因为很多地方都默认使用了这些名字，我们自定义的话只需要对第二个参数动手脚，定义如下：

    C ---> Country Name (2 letter code) ST ---> State or Province Name (full name) L ---> Locality Name (eg, city) O ---> Organization Name (eg, company) OU ---> Organizational Unit Name (eg, section) CN ---> Common Name (eg, your name or your server’s hostname) emailAddress ---> Contact email addre

    另外在使用上面的make_key脚本生成key的过程中会提示输入password，我的处理是不输入，直接enter，不要密码！后面解释，用自定义的key替换/security下面的。

    可以看到android源码里面的key使用的第二个参数就是上面README里面的，是公开的，所以要release版本的系统的话，肯定要有自己的签名key才能起到一个安全控制作用。

    在上面提到如果apk中的编译选项LOCAL_CERTIFICATE没有设置的话，就会使用默认的testkey作为签名key，我们可以修改成自己想要的key，按照上面的步骤制作一个releasekey，修改android配置在/build/core/config.mk中定义变量：

在主makefile文件里面：

ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)

  BUILD_VERSION_TAGS += release-key

这样的话默认的所有签名将会使用releasekey。

修改完之后就要编译了，如果上面的这些key在制作的时候输入了password就会出现如下错误：

我在网上找到了合理的解释：

其实会出现这个错误的最根本的原因是多线程的问题。在编译的时候为了加速一般都会执行make -jxxx，这样本来需要手动输入密码的时候，由于其它线程的运行，就会导致影响当前的输入终端，所以就会导致密码无法输入的情况！

再编译完成之后也可以在build.prop中查看到变量：

这样处理了之后编译出来的都是签名过的了，系统才算是release版本

我发现我这样处理之后，整个系统的算是全部按照我的要求签名了。

网上看到还有另外的签名release办法，但是应该是针对另外的版本的，借用学习一下：

make -j4 PRODUCT-proct_mol-user dist

这个怎么跟平时的编译不一样,后面多了两个参数PRODUCT-proct_mol-user 和 dist. 编译完成之后回在源码/out/dist/目录内生成个proct_mol-target_files开头的zip文件.这就是我们需要进行签名的文件系统.

我的proct_mol 是full_gotechcn,后面加“-user”代表的是最终用户版本，关于这个命名以及proct_mol等可参考http://blog.csdn.net/jscese/article/details/23931159

编译出需要签名的zip压缩包之后，就是利用/security下面的准备的key进行签名了：

./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security  out/dist/full_gotechcn-target_files.zip   out/dist/signed_target_files.zi

签名目标文件 输出成signed_target_files.zi

如果出现某些apk出错，可以通过在full_gotechcn-target_files.zip前面加参数"-e =" 来过滤这些apk.

然后再通过image的脚本生成imag的zip文件，这种方式不适用与我目前的工程源码，没有做过多验证！

Android签名机制可划分为两部分：（1）ROM签名机制；（2）第三方APK签名机制。

Android APK实际上是一个jar包，而jar包又是一个zip包。APK包的签名实际上使用的是jar包的签名机制：在zip中添加一个META的子目录，其中存放签名信息；而签名方法是为zip包中的每个文件计算其HASH值，得到签名文件(*.sf)，然后对签名文件(.sf)进行签名并把签名保存在签名块文件(*.dsa)中。

在编译Android源码生成ROM的过程中，会使用build/target/proct/security目录中的4个key（media, platform, shared, testkey）来对apk进行签名。其中，*.pk8是二进制形式（DER）的私钥，*.x509.pem是对应的X509公钥证书（BASE64编码）。build/target/proct/security目录中的这几个默认key是没有密码保护的，只能用于debug版本的ROM。

要生成Release版本的ROM，可先生成TargetFiles，再使用带密码的key对TargetFiles重新签名，最后由重签名的TargetFiles来生成最终的ROM。

可以使用Android源码树中自带的工具“development/tools/make_key”来生成带密码的RSA公私钥对（实际上是通过openssl来生成的）: $ development/tools/make_key media ‘/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName’ 上面的命令将生成一个二进制形式（DER）的私钥文件“media.pk8”和一个对应的X509公钥证书文件“media.x509.pem”。其中，/C表示“Country Code”，/ST表示“State or Province”，/L表示“City or Locality”，/O表示“Organization”，/OU表示“Organizational Unit”，/CN表示“Name”。前面的命令生成的RSA公钥的e值为3，可以修改development/tools/make_key脚本来使用F4 (0×10001)作为e值（openssl genrsa的-3参数改为-f4）。

也可以使用JDK中的keytool来生成公私钥对，第三方APK签名一般都是通过keytool来生成公私钥对的。

可以使用openssl x509命令来查看公钥证书的详细信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout

还可以使用JDK中的keytool来查看公钥证书内容，但其输出内容没有openssl x509全面： $ keytool -printcert -v -file media.x509.pem

有了key之后，可以使用工具“build/tools/releasetools/sign_target_files”来对TargetFiles重新签名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目录中需要有四个key（media, platform, shared, releasekey）。注意：这里的releasekey将代替默认的testkey（请参考build/tools/releasetools/sign_target_files脚本实现），也就是说，如果某个apk的Android.mk文件中的LOCAL_CERTIFICATE为testkey，那么在生成TargetFiles时是使用的build/target/proct/security/testkey来签名的，这里重新签名时将使用new_keys_dir/releasekey来签名。

uild/tools/releasetools/sign_target_files_apks是通过host/linux-x86/framework/signapk.jar来完成签名的。也可以直接使用host/linux-x86/framework/signapk.jar来对某个apk进行签名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，”-w”表示还对整个apk包(zip包）进行签名，并把签名放在zip包的comment中。

对于第三方应用开发者而言，对APK签名相对要简单得多。第三方应用开发一般采用JDK中的keytool和jarsigner来完成签名密钥的管理和APK的签名。

使用keytool来生成存储有公私钥对的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000

查看生成的密钥信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （注：获取Base64格式的公钥证书，RFC 1421）

导出公钥证书： $ keytool -export -keystore mystore -alias mykey -file my.der （注：二进制格式公钥证书，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （注：Base64格式公钥证书，PEM）

对APK进行签名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey

验证签名： $ jarsigner -verify -verbose -certs my_application.apk

在进行Android二次开发时，有时需要把build/target/proct/security下面的公私钥对转换为keystore的形式，可以参考这篇文章：把Android源码中的密码对转换为keystore的方法。

10. 如何在Eclipse中编译hierarchy viewer

首先，你要保证你的手机能够开启View Server，具体见http://maider.blog.sohu.com/255448342.html

按照http://www.cnblogs.com/vowei/archive/2012/08/03/2618753.html里的步骤操作即可将hierarchyviewer2的源码导入Eclipse并运行.
2013.3.15更新：在android源码android-4.2.2_r1分支之前，hierarchyviewer2的源码位于 SOURCE_ROOT/sdk/hierarchyviewer2文件夹内，而在android-4.2.2_r1分支之后的源代码，hierarchyviewer2的源码移至了SOURCE_ROOT/tools/swt/hierarchyviewer2文件夹内.本篇文章后续内容按照android-4.2.2_r1分支之前的代码结构讲解。而若想了解新版Android源码树的SDK工具结构，请移步：号外：Android 4.2.2 推至 AOSP master后 sdk工具大转移

(不会下载Android源码？请参考：http://maider.blog.sohu.com/250854034.html)

再仔细看下http://www.cnblogs.com/vowei/archive/2012/08/08/2627614.html这篇文章中对后台源码的分析

我现在来讲讲在Windows下，初始化AndroidDebugBridge可能会出现问题：
hierarchy viewer后台的入口点在 SOURCE_ROOT/sdk/hierarchyviewer2/app/src/com/android/hierarchyviewer/HierarchyViewerApplication.java
中的createContents(Composite parent)函数:
====================================================================================================
@Override
protected Control createContents(Composite parent) {
// create this only once the window is opened to please SWT on Mac
mDirector = .createDirector();
mDirector.initDebugBridge();
mDirector.startListenForDevices();
mDirector.populateDeviceSelectionModel();
......
===================================================================================================
以上代码做了如下工作：

1，.createDirector() -- 创建一个对象

2，mDirector.initDebugBridge() -- 初始化AndroidDebugBridge

3，mDirector.startListenForDevices() -- 把mDirctor注册为AndroidDebugBridge的监听者（HierarchyViewerDirector继承了IDeviceChangeListener接口），当有设备连接、断开、改变时，mDirctor将接收到事件。

4，mDirector.populateDeviceSelectionModel() -- 获取当前已经连接的设备列表，处理并显示它们。

注意，就是第二步初始化AndroidDebugBridge，在Windows下运行下，可能会失败。

原因是：mDirector是一个HierarchyViewerDirector抽象类，HierarchyViewerDirector.java位于:

SOURCE_ROOT/sdk/hierarchyviewer2/libs/hierarchyviewerlib/src/com/android/hierarchyviewerlib文件夹中。

我们来查看HierarchyViewerDirector.java中的initDebugBridge()函数：

public void initDebugBridge() {
DeviceBridge.initDebugBridge(getAdbLocation());
}

再看看getAdbLocation()函数：

public abstract String getAdbLocation();

原来只是个抽象方法，没有定义！

刚才说了，mDirector是一个HierarchyViewerDirector抽象类，而它实际上是由这个类实现的。.java位于SOURCE_ROOT/sdk/hierarchyviewer2/app/src/com/android/hierarchyviewer 文件夹里。

我们就来看看这个类里是如何实现getAdbLocation()的：

====================================================================================================

public String getAdbLocation() {
String hvParentLocation = System.getProperty("com.android.hierarchyviewer.bindir");

//$NON-NLS-1$
// in the new SDK, adb is in the platform-tools, but when run from the command line
// in the Android source tree, then adb is next to hierarchyviewer.
if (hvParentLocation != null && hvParentLocation.length() != 0) {
// check if there's a platform-tools folder
File platformTools = new File(new File(hvParentLocation).getParent(),
SdkConstants.FD_PLATFORM_TOOLS);
if (platformTools.isDirectory()) {
return platformTools.getAbsolutePath() + File.separator + SdkConstants.FN_ADB;
}

return hvParentLocation + File.separator + SdkConstants.FN_ADB;
}

return SdkConstants.FN_ADB;
}

======================================================================================

看看里面的注释你就知道了，getAdbLocation() 这段代码是以Android源码树的结构来写的，并不是以正常安装的sdk路径来写的。所以初始化AndroidDebugBridge()会失败。

于是我在HierarchyViewerDirector.java里写了个initDebugBridge的重载方法：

===================================================================================================

public void initDebugBridge() {
DeviceBridge.initDebugBridge(getAdbLocation());
}

public void initDebugBridge(String adbLocation){
DeviceBridge.initDebugBridge(adbLocation);
}

=======================================================================================

并且将HierarchyViewerApplication.java里的createContents函数改为:

==================================================================================================

@Override
protected Control createContents(Composite parent) {
// create this only once the window is opened to please SWT on Mac
mDirector = .createDirector();
mDirector.initDebugBridge("c:/Android/platform-tools/adb.exe");
mDirector.startListenForDevices();
mDirector.populateDeviceSelectionModel();
......
===================================================================================================
即，我在 mDirector.initDebugBridge("c:/Android/platform-tools/adb.exe"); 指明了我电脑里adb的路径。这样，初始化adb就没问题了。

在Eclipse中运行hierachyviewer时，可能会遇到：
E/ddmlib: An established connection was aborted by the software in your host machine
java.io.IOException: An established connection was aborted by the software in your host machine
解决办法：关闭cmd中一切和adb有关的东西，重启Eclipse。

出自：http://maider.blog.sohu.com/255485243.html