android編譯gcc
1. 在./development目錄下創建一目錄 如：myhello
2. 進入hello目錄，在其下編寫自己的.c文件,如: myhello.c
#include <stdio.h>
int main()
{
printf("hello world\n");
exit(0);
//return 0;
}
3. 在hello目錄中，編寫Android.mk, 內容如下：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := myhelloworld
LOCAL_SRC_FILES := myhello.c
LOCAL_MODULE_TAGS := optional
include $(BUILD_EXECUTABLE)
4. 回到Android源代碼頂層目錄，進行編譯，make myhelloworld
5. 生成的可執行文件位於:out/target/proct/lotus/system/bin/ 目錄下
6. adb push 到手機 /data 目錄下,然後進入adb shell,到data目錄下,執行./myhelloworld 皆可
手動編譯連接【arm-eabi-gcc 的目錄隨andorid的版本而有變化，還有就是需要鏈接的文件如果比較多時，需要很多-l 就很麻煩了】
7、編譯成目標文件：
#$(yourAndroid)/prebuilt/linux-x86/toolchain/[arm-eabi-4.2.1]/bin/arm-eabi-gcc -I bionic/libc/arch-arm/include/ -I bionic/libc/include -I bionic/libc/kernel/common -I bionic/libc/kernel/arch-arm -g -c helloworld.c -o hello.o
8、生成可執行代碼：
#$(yourAndroid)/prebuilt/linux-x86/toolchain/[arm-eabi-4.2.1]/bin/arm-eabi-gcc -nostdlib -Bdynamic -Wl,-T,build/core/armelf.x -Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,noreloc -o helloworld -Lout/target/proct/[generic]/obj/lib -Wl,-rpath-link=out/target/proct/[generic]/obj/lib -lc hello.o -entry=main
其中[ ]中部分根據實際情況修改
**************************************************
實驗：
1. 建目錄(my Android)/development/test， 在該目錄下新建 Android.mk和fb_test.c文件
2. Android.mk文件
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := myfbtest
LOCAL_SRC_FILES := fb_test.c
LOCAL_MODULE_TAGS := optional
include $(BUILD_EXECUTABLE)
3. 以下為fb_test.c
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>
#include <linux/kd.h>
#include <stdio.h>
#define FBBIT_PER_PIXEL 32
#define FBBIT_PIXEL_IMAGE 16
#define PIXELS_WIDTH_BYTE 4
#define BYTE_PER_PIXEL 3
#define FB_GRAPHICS_PATH "/dev/graphics/fb0"
#define DEV_TTY0_PATH "/dev/tty0"
#define DISPLAY_ERROR -1
#define DISPLAY_SUCCESS 0
#define GET_BATTERYCAPACITY_ERR -1
#define MAX_STR 255
static struct {
int fd;
void *pixels;
struct fb_fix_screeninfo fixed;
struct fb_var_screeninfo var;
int align_xres;
} fb;
int getBatteryCapacity(void)
{
FILE *in;
char tmpStr[MAX_STR + 1];
char capfile[] = "/sys/class/power_supply/battery/capacity";
if (capfile == NULL)
return GET_BATTERYCAPACITY_ERR;
in = fopen(capfile, "rt");
if (in == NULL)
return GET_BATTERYCAPACITY_ERR;
if (fgets(tmpStr, MAX_STR, in) == NULL) {
printf("Failed to read battery capacity!\n");
fclose(in);
return GET_BATTERYCAPACITY_ERR;
}
printf("Battery capacity(ascii): %s\n", tmpStr);
fclose(in);
return 0;//atoi(tmpStr);
}
static int vt_set_graphicsmode(int graphics)
{
int fd, r;
fd = open(DEV_TTY0_PATH, O_RDWR | O_SYNC);
if (fd < 0)
return DISPLAY_ERROR;
r = ioctl(fd, KDSETMODE, graphics);
close(fd);
return r;
}
int display_init(void)
{
fb.fd = open(FB_GRAPHICS_PATH, O_RDWR);
if (fb.fd < 0)
return DISPLAY_ERROR;
if (ioctl(fb.fd, FBIOGET_FSCREENINFO, &fb.fixed) < 0)
return DISPLAY_ERROR;
if (ioctl(fb.fd, FBIOGET_VSCREENINFO, &fb.var) < 0)
return DISPLAY_ERROR;
fb.align_xres = fb.fixed.line_length /
(fb.var.bits_per_pixel >> BYTE_PER_PIXEL);
fb.pixels = mmap(0, fb.fixed.line_length * fb.var.yres_virtual,
PROT_READ | PROT_WRITE, MAP_SHARED, fb.fd, 0);
if (fb.pixels == MAP_FAILED)
return DISPLAY_ERROR;
vt_set_graphicsmode(KD_GRAPHICS);
memset(fb.pixels, 0, fb.fixed.line_length * fb.var.yres_virtual);
//display_update(fb.pixels, fb.align_xres, fb.var.yres);
fb.var.activate = FB_ACTIVATE_FORCE;
ioctl(fb.fd, FBIOPUT_VSCREENINFO, &fb.var);
printf("display_init ok\n");
return DISPLAY_SUCCESS;
}
void display_on(void)
{
ioctl(fb.fd, FBIOBLANK, FB_BLANK_UNBLANK);
}
void display_off(void)
{
ioctl(fb.fd, FBIOBLANK, FB_BLANK_POWERDOWN);
}
int main()
{
display_init();
display_off();//關顯示屏
getBatteryCapacity();
sleep(5);
display_on();//開顯示屏
return 0;
}
㈡ linux編譯android gcc怎麼降低版本
sudo apt-get install gcc-4.4 安裝您想要版本的 gcc
sudo rm -rf /usr/bin/gcc /usr/bin/g++ 把以前的軟連接去掉。
sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc 新創建個軟鏈接
㈢ 在安卓平台上安裝 GCC 的方法
c4不是有一個插件，gcc，解壓這個插件，裡面有幾個編譯好的二進制文件，可以直接使用，把這幾個文件拖到system/xbin，給執行許可權，shell運行試試，不過貌似有點麻煩，當然你可以自己編譯gcc for android，不過如果不懂linux，貌似很難
㈣ 在編譯android內核的時候出現下面的錯誤，是怎麼回事
解決方案：找到工程中Makefile文件，將其中 「-m64" 字元串刪除即可。
原因：gcc 3.4 或者更高版本，已經將其去除了，所以會出現上面的錯誤！
去android源代碼網站找樓主編譯android版本的對應GCC，安裝後重新編譯
㈤ android 系統安裝linux的軟體 比如安裝一個GCC編譯器，在手機上面編譯*.c文件
不可以的，adb
shell支持的linux指令很少，而且是同名指令功能也不完善的。而且可以的安裝的話也是運行不了的，安卓運行程序還是通過Dalvik虛擬機來運行的。linux內核只是提供核心系統服務，並作為硬體和軟體間的抽象層，為上層實際系統提過統一操作硬體的方法的，並不是完整的linux系統，不具備完整linux系統的操作層。安卓2.3系統的骨頭包，也就是最精簡系統包，只有100m都不到，從這個角度你應該就知道為什麼不行了吧？這么解釋感覺也沒說清楚，希望能幫到你
㈥ 在安卓平台上安裝 GCC 的方法
android上安裝GCC的步驟腔衫：
1、准備文件：Terminal IDE.apk和GCC源文件。
2、解壓整個ZIP文件，並先將Terminal.apk文件安裝至手機中，然後把GCC整個文件一起放置到data/data/com.spartacusrex.spartacuside/files/system中。
3、者圓蘆修改data/data/com.spartacusrex.spartacuside/files/目錄下的.bashrc文件，添加以下代碼：
export CPLUS_INCLUDE_PATH=$IDESYSTEM/gcc/arm-linux-androideabi/c++/include:$CPLUS_INCLUDE_PATH
export C_INCLUDE_PATH=$IDESYSTEM/gcc/arm-linux-androideabi/include:$C_INCLUDE_PATH
export PATH=$IDESYSTEM/gcc/bin:$PATH
4、將gcc/bin下的文件改一下名，arm-linux-androideabi-g++改為g++，arm-linux-androideabi-gcc則改為gcc。
5、完成後重啟IDE即可使用GCC。
㈦ 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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。
㈧ 用gcc/g++如何編譯android工程中的.c/.cpp程序，如何查看android工程師.c/.cpp文件需要的依賴及如何解決
目前暫不支持開發工具編譯C、c++代碼生成so文件，應該後續版本會有的。.so 為共享庫,是shared object,用於動態連接的,和dll差不多，可以這樣調用so文件：得到/usr/java/jdk1.5.0_13/jre/lib/i386，將SO文件放在該目錄下運行java程序，輸出了由C語言函數計算出的結果以引擎自帶的HelloCpp為例配置C++的的自動編譯。在eclipse中導入hellocpp工程。操作路徑：eclipse--file--import工程導入後，右擊工程--properties取消CDT builder。然後點擊New新建一個我們自己的builder，選擇program。指定ndk-build.cmd來編譯我們的項目，下面的工作路徑將作為參數傳入給ndk-build.cmd添加NDK_MODULE_PATH變數，注意要寫兩個路徑[cocos2d-x安裝目錄和其目錄下\cocos2dx\platform\third_party\android\prebuilt]，用分號分開最後點OK保存。因為不是執行build_native.sh編譯本地代碼，所以別忘了手動拷貝下hellocpp工程下resource中的資源到android工程assets.可以在命令行下編譯多個C/CPP文件，通過cl -c命令來編譯類文件，編譯成obj文件後，你可以使用lib命令將其編譯為lib文件，然後使用link命令連接多個obj文件。默認生成的可執行文件的名稱是命令中第一個obj文件的名稱，具體參考代碼如下：
㈨ Android學習之Build環境介紹
這里略過對android在手機上的文件系統框架的闡述（google或者都能幫助你找到對應的信息），主要看google是如何把生成合適的rootfs的工作整合到它的build體系當中，同時，會順帶看一下CyanogenMod中對應各種機型的build機制。
首先，來看一下Android的build系統中，使用到的編譯選項和相關工具
具體的目錄在：mydroid/build/tools/下
|-- acp
這是一個稍微改良的cp命令，用來應付在windows/MAC/Linux下的cp命令的缺陷，其中的README很值得一看！
|-- adbs
這是一個用來查看crash問題的工具，詳細請看《Android調試工具之adbs》
|-- Android.mk
|-- apicheck
用來進行發布前的API檢查（參見mydroid/build/core/tasks/apicheck.mk），是否新編譯的系統中有破壞API兼容性或是非法的API
這里的代碼是用Java寫的用來檢查編譯時生成的API相關信息的xml文件（mydroid/framework/base/api/中），可以參考裡面對於xml文件解析的代碼
|-- apriori
實現prelink的工具，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- atree
為android SDK服務的一個工具，用來按照指定xxx.atree文件中的內容進行一些文件操作
|-- bin2asm
不太明白具體的用處，應該是用來應付mac上編譯android一些與gcc相關的問題
|-- buildinfo.sh
生成target中的各種xxx.prop文件，如system.prop, build.prop等
|-- check_builds.sh
包裝了diff，用來看2個發布版本之間變化
|-- check_prereq
device上進行ota升級時的工具之一
|-- compare_fileslist.py
與check_builds.sh配合完成版本比較的腳本
|-- droiddoc
Android更具javadoc的一些移植
|-- mp-package-stats
簡單的查看一個jar/apk文件內的dex和其它文件的大小信息
|-- event_log_tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- fileslist.py
簡化的列出指定目錄下所有文件及大小的腳本 -- 可以放入自己的工具庫了使用：）
|-- findleaves.py
在指定目錄中（可多個）找指定文件的腳本 -- 可以放入自己的工具庫了使用：）
|-- fixlinebreaks.sh
把windows中的換行改為linux下的 -- 可以放入自己的工具庫了使用：大散蘆）
|-- fs_config
列出指定文件夾滾帶及文件的許可權
|-- fs_get_stats
得到指定文件夾下文件的簡單stats信息
|-- iself
判斷文件是否是ELF格式
|-- isprelinked
判斷文件是否是prelink過的
|-- java-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- kcm
key character map的工具， 相關資料參照：
|-- lsd
!!!!!! ???
|-- merge-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意掘野義參見《Android學習之event-log-tags是神馬》
|-- mktarball.sh
與fs_get_stats配合而執行的打包工具
|-- print_mole_licenses.sh
顯示當前目錄下所有mole信息
|-- releasetools
-- check_target_files_signatures
|-- common.py
|-- edify_generator.py
|-- img_from_target_files
|-- ota_from_target_files
`-- sign_target_files_apks
|-- rgb2565
rgb轉換工具
|-- signapk
命令行下對jar包簽名的工具
|-- soslim
Android定製的編譯工具之一，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- warn.py
解析Android系統編譯log的工具
`-- zipalign
zipfile的對齊工具，參見該文件夾下的README.TXT
#p#副標題#e#
在來看看Android編譯系統中定義的一些通用XXX.mk文件
mydroid/build/core/
|-- armelflib.x
|-- armelf.x
|-- armelf.xsc
|-- base_rules.mk
|-- binary.mk
|-- build_id.mk
|-- build-system.html
|-- checktree
|-- cleanbuild.mk
|-- cleanspec.mk
|-- clear_vars.mk
|-- combo
|-- config.mk
|-- _headers.mk
|-- definitions.mk
|-- device.mk
|-- dex_preopt.mk
|-- distdir.mk
|-- droiddoc.mk
|-- mpvar.mk
|-- dynamic_binary.mk
|-- envsetup.mk
|-- executable.mk
|-- filter_symbols.sh
|-- find-jdk-tools-jar.sh
|-- help.mk
|-- host_executable.mk
|-- host_java_library.mk
|-- host_native_test.mk
|-- host_prebuilt.mk
|-- host_shared_library.mk
|-- host_static_library.mk
|-- java_library.mk
|-- java.mk
|-- legacy_prebuilts.mk
|-- main.mk
|-- Makefile
|-- multi_prebuilt.mk
|-- native_test.mk
|-- node_fns.mk
|-- notice_files.mk
|-- package.mk
|-- pathmap.mk |-- phony_package.mk
|-- prebuilt.mk
|-- process_wrapper_gdb.cmds
|-- process_wrapper_gdb.sh
|-- process_wrapper.sh
|-- proct_config.mk
|-- proct.mk
|-- proguard.flags
|-- proguard_tests.flags
|-- raw_executable.mk
|-- raw_static_library.mk
|-- root.mk
|-- shared_library.mk
|-- static_java_library.mk
|-- static_library.mk
|-- tasks
|-- user_tags.mk
`-- version_defaults.mk
#p#副標題#e#
這里，目錄在mydroid/build/core/tasks/有一些特別的task
|-- apicheck.mk, 判斷api是否符合AOSP的規范
|-- cts.mk cts測試， 可以在代碼根目錄， make cts, 編譯結束之後，進入out/host/linux-x86/bin/下，執行cts命令
|-- ide.mk IDE開發環境
|-- proct-graph.mk
`-- sdk-addon.mk
NDK的build環境沒有包含在標注難得AOSP的/build/目錄下
而是在mydroid/ndk/build下
$ cd ndk/build/tools
$ export ANDROID_NDK_ROOT=aosp-root/ndk
$ ./make-release --help
一些小技巧
如何顯示每次編譯所包含的所有xxx.mk文件
找到build/core/main.mk
把include $（subdir_makefiles）替換為
[plain] view plain $（foreach subdir_makefile, $（subdir_makefiles），
$（info Including $（subdir_makefile））
$（eval include $（subdir_makefile））)
subdir_makefile :=
如果遇見API相關的PACKAGING/checkapi-current-timestamp] Error 38
需要執行：make update-api
如何在AOSP代碼目錄之外編譯
[plain] view plain # Paths and settings
TARGET_PRODUCT = generic
ANDROID_ROOT = /home/karim/android/aosp-2.3.x
BIONIC_LIBC = $（ANDROID_ROOT）/bionic/libc
PRODUCT_OUT = $（ANDROID_ROOT）/out/target/proct/$（TARGET_PRODUCT）
CROSS_COMPILE =
$（ANDROID_ROOT）/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
# Tool names
AS = $（CROSS_COMPILE）as
AR = $（CROSS_COMPILE）ar
CC = $（CROSS_COMPILE）gcc
CPP = $（CC） -E
LD = $（CROSS_COMPILE）ld
NM = $（CROSS_COMPILE）nm
OBJCOPY = $（CROSS_COMPILE）obj
OBJDUMP = $（CROSS_COMPILE）objmp
RANLIB = $（CROSS_COMPILE）ranlib
READELF = $（CROSS_COMPILE）readelf
SIZE = $（CROSS_COMPILE）size
STRINGS = $（CROSS_COMPILE）strings
STRIP = $（CROSS_COMPILE）strip
export AS AR CC CPP LD NM OBJCOPY OBJDUMP RANLIB READELF
SIZE STRINGS STRIP
# Build settings
CFLAGS = -O2 -Wall -fno-short-enums
HEADER_OPS = -I$（BIONIC_LIBC）/arch-arm/include
-I$（BIONIC_LIBC）/kernel/common
-I$（BIONIC_LIBC）/kernel/arch-arm
LDFLAGS = -nostdlib -Wl,-dynamic-linker,/system/bin/linker
$（PRODUCT_OUT）/obj/lib/crtbegin_dynamic.o
$（PRODUCT_OUT）/obj/lib/crtend_android.o
-L$（PRODUCT_OUT）/obj/lib -lc -ldl
# Installation variables
EXEC_NAME = example-app
INSTALL = install
INSTALL_DIR = $（PRODUCT_OUT）/system/bin
# Files needed for the build
OBJS = example-app.o
# Make rules
all: example-app
.c.o:
$（CC） $（CFLAGS） $（HEADER_OPS） -c {1}lt;
example-app: ${OBJS}
$（CC） -o $（EXEC_NAME） ${OBJS} $（LDFLAGS）
install: example-app
test -d $（INSTALL_DIR） || $（INSTALL） -d -m 755 $（INSTALL_DIR）
$（INSTALL） -m 755 $（EXEC_NAME） $（INSTALL_DIR）
clean:
rm -f *.o $（EXEC_NAME） core
distclean:
rm -f *~
rm -f *.o $（EXEC_NAME） core
如何增加一個新的設備
[plain] view plain $ cd ~/android/aosp-2.3.x
$ . build/envsetup.sh
$ mkdir -p device/acme/coyotepad
$ cd device/acme/coyotepad
進入AndroidProcts.mk
PRODUCT_MAKEFILES :=
$（LOCAL_DIR）/full_coyotepad.mk
對於full_coyotepad.mk
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/languages_full.mk）
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/full.mk）
DEVICE_PACKAGE_OVERLAYS :=
PRODUCT_PACKAGES +=
PRODUCT_COPY_FILES +=
PRODUCT_NAME := full_coyotepad
PRODUCT_DEVICE := coyotepad
PRODUCT_MODEL := Full Android on CoyotePad, meep-meep
在BoardConfig.mk中
TARGET_NO_KERNEL := true
TARGET_NO_BOOTLOADER := true
TARGET_CPU_ABI := armeabi
BOARD_USES_GENERIC_AUDIO := true
USE_CAMERA_STUB := true
打開vendorsetup.sh
add_lunch_combo full_coyotepad-eng
#p#副標題#e#
㈩ 多台伺服器如何分布編譯一個android固件
1、首先需要distcc:替換原來的編譯器(gcc/g++)。
2、其次要編譯android編譯。把原來的編譯器替換。
3、最後多台伺服器就可以進行分布編譯一個android固件了。