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