android系統內核編譯

① 如何自己編譯android系統並製作刷機包

android系統製作刷機包方法：

【一】：下載安裝最新版ROM助手（市場中有很多類似的製作工具，關鍵要求操作簡單，功能強大），安裝程序非常簡單，只需在一隻蘑菇首頁內直接下載，並解壓到自己的電腦安裝即可。

【二】：如果已經下載了與機型匹配的ROM刷機包，那麼現在可以直接打開ROM助手了，接下來繪制專屬個性的完美刷機包就從這里開始吧。

【三】：打開軟體後，它會自動升級到最新版本，另外打開主界面後，會直觀簡明的顯示出它的所有功能，例如：性能優化，系統精簡，預裝APK，簽名打包等等。提醒大家，不要貪心哦，要根據自己的需求點擊需要操作的功能，如系統精簡，然後進入操作界面，所有功能全部修改一遍也無妨，反正都是一鍵操作，省時省力。

② android 怎樣編譯kernel 命令 make

方法如下：
在linux的環境下:
建立目錄:

mkdir ~/android-kernel cd android-kernel

下載源代碼, 大概有280MB, 慢慢等哈~~~ (當然你要先安裝git) git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
類似的屏幕信息:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/ remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016) Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done. Resolving deltas: 100% (755115/755115), done. Checking out files: 100% (22584/22584), done.
然後去到htc-msm branch: cd kernel
git checkout -b htc-msm origin/htc-msm
屏幕信息:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm. Switched to a new branch "htc-msm"

下載ARM的toolchain, 大概64MB左右, 下到~/android-kernel: 下
載
:
http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
編譯kernel

准備預設的Kaiser 配置文件.config
cd ~/android-kernel/kernel

make htckaiser_defconfig ARCH=arm
然後編譯zImage:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
編譯好的在: ~/android-kernel/kernel/arch/arm/boot/zImage

如果你的機器是多核的, 可以編譯的時候用-j <cores/cpus_number>來加速:
比如, 雙核的可以:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi
滿意請採納謝謝

③ 編譯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內核編譯時如何獲得.config文件

得到config之後，直接復制到你下載來的內核文件夾kernel下，更名為.config，打開終端，進入此目錄（假設你放在里你的home下,即~/kernel）運行make ARCH=arm menuconfig（ARCH=arm表示編譯的是arm平台的）

⑤ 在編譯android內核的時候出現下面的錯誤，是怎麼回事

解決方案：找到工程中Makefile文件，將其中 「-m64" 字元串刪除即可。
原因：gcc 3.4 或者更高版本，已經將其去除了，所以會出現上面的錯誤！
去android源代碼網站找樓主編譯android版本的對應GCC，安裝後重新編譯

⑥ 自己編譯的android內核怎麼燒錄到手機上

------解決方案--------------------------------------------------------自己編譯的android內核燒上去應該有問題，有沒有相應的驅動
------解決方案--------------------------------------------------------MTK有出Android的方案，你首先應該問MTK技術支持去拿下載工具。
------解決方案--------------------------------------------------------如果你沒有對應的硬體驅動是白做功夫
在搞定display driver的基礎上能顯示機器人 然後就卡住了
等你搞定驅動之後 並且把這個集到ROM裡面的時候
燒錄就很簡單了 flashtool / 超級終端
無數的軟體都可以下載前提是兄弟你的COM口/下載口驅動沒有問題

⑦ 如何加快linux android 的編譯速度

項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。

tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。

ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

⑧ 為了能從sd卡啟動android系統，內核應該怎麼編譯

本人使用mini6410開發了一個sqlite資料庫的程序，在mini6410的linux系統下已經能夠成功運行了。因為Android使用的也是linux內核，所以我想當然的認為按照同樣的方法將程序移植到mini6410的android系統中也可以成功運行，但是當我運行程序的時候卻提示我不能找到可執行文件（xlisten-arm是交叉編譯出來的可執行文件）：

/ # ./xlisten-arm
/system/bin/sh: ./xlisten-arm: not found

1.探索：

在網上搜索起初認為可能是庫文件的不全導致的，於是在查看可執行文件xlisten-arm所需要的動態鏈接庫：

執行語句：

# arm-linux-readelf -a ./xlisten-arm | grep "Shared"
0x00000001 (NEEDED) Shared library: [libsqlite3.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libcrypt.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libc.so.6]

知道所需的動態鏈接庫後，到android文件系統中去照著寫庫文件，在目錄/system/lib 中，果然缺少相應的庫文件，於是認為找到了我問題的根源所在，在復制相應庫文件的時候為了保留原來的屬性，還特意用了

#cp -a filename dir

誰知將這些庫都添加進去以後，仍然無濟於事！

看來不僅僅事庫文件缺失的問題了，而且一般來說，如果真的是因為缺少庫文件而導致的問題，終端會提示我們鏈接某庫文件時沒有找到該庫文件。

2.正確的解決方法：

將程序編譯的時候選擇靜態編譯，即使用選項 -static

我是對Makefile文件中的CFLAG變數進行修改

CFLAGS = -Wall

改為;

CFLAGS = -Wall -static

然而此時又出現問題了:

undefined reference to `pthread_mutex_*'

undefined reference to `dl*'

提示沒有定義這些函數，於是在包含的庫文件中添加了這兩個庫文件

在Makefile中，修改LIBS變數;

LIBS = -lsqlite3 -lm -lcrypt

改為：

LIBS = -lsqlite3 -lm -lcrypt -lpthread -ldl

然後進行交叉編譯，成功了！

編譯出來的可執行文件比較大，因為事靜態編譯的，我的有2M多，

拷貝到開發板的andriod系統中，

修改許可權：

#chmod 777 xlisten-arm

執行：

/ # ./xlisten-arm

OK!能夠正確的執行了！

⑨ 安卓系統是用什麼語言編的

安卓系統的編程語言，C/C++（底層） Java等（應用層）。

1、Android是一種基於Linux的自由及開放源代碼的操作系統。主要使用於移動設備，如智能手機和平板電腦，由Google（谷歌）公司和開放手機聯盟領導及開發。

2、尚未有統一中文名稱，中國大陸地區較多人使用「安卓」或「安致」。Android操作系統最初由Andy Rubin開發，主要支持手機。

(9)android系統內核編譯擴展閱讀：

1、Android在運行一個程序時首先需要UnZip，然後類似Symbian那樣直接執行安裝，和Windows Mobile中的PE文件有區別。

2、這樣做對於程序的保密性和可靠性不是很高，通過dexmp命令可以反編譯，但這樣做符合發展規律，微軟的 Windows Gadgets或者說WPF也採用了這種構架方式。

3、在Android平台中dalvik vm的執行文件被打包為apk格式，最終運行時載入器會解壓然後獲取編譯後androidmanifest.xml文件中的permission分支相關的安全訪問，但仍然存在很多安全限制，如果你將apk文件傳到/system/app文件夾下會發現執行是不受限制的。

4、最終我們平時安裝的文件可能不是這個文件夾，而在android rom中系統的apk文件默認會放入這個文件夾，它們擁有著root許可權。