1、放到安卓系統中，每個應用都可以訪問
將編譯好的libmono2.so放到系統的/system/lib目錄下。打開Eclipse上ADT插件裡面的File Explorer工具，點擊/system/lib目錄，選擇右上角有個push a file onto devices，打開對話框後，再選擇libmono2.so文件，確定後即可將lib文件放到手機中了。（如果不行也可以使用ADB自帶adb push命令）。再設置其許可權為744，命令如下：
#用命令行方式訪問手機設備
adb shell
#進入/system/lib目錄
cd /system/lib
#設置libmono2.so許可權為744
chmod 744 libmono2.so
此時利用Jni機制編寫裝載Jni庫方法的類，類裡面需要嚴格按照Jni機制進行編寫Jni介面
2、放到應用軟體中，只有自己的應用可以訪問
①在軟體工程下新建libs/armeabi文件夾，並將libmono2.so庫拷貝進去。
②接下來做的就是重寫Jni介面，和方法1的最後過程是一樣的。
Ⅱ 請教linux 遷移到 android 方法
比如以移植一個helloworld程序作為例子。
#include<stdio.h>
voidmain()
{
printf("HelloWorld! ");
}
輸入命令進行靜態編譯：arm-none-linux-gnueabi-gcc hello.c -static -o hello.out
然後利用adb push 將helllo.out放進android設備的/system/bin目錄中，
用chmod 755 /system/bin/hello.out 更改其為執行許可權。
輸入： hello.out 即可看到屏幕上輸出HelloWorld!
Ⅲ android中如何編譯出64位so文件
如果是在Linux下編譯Android源碼，有可能是兩個原因：
1. lunch命令有32位和64位的區別，注意選能夠編譯64位so的命令
2. mk文件中有LOCAL_MODULE_PATH的值比如為$(TARGET_OUT_SHARED_LIBRARIES)/hw的改為LOCAL_MODULE_RELATIVE_PATH := hw，後一種可以分別在lib和lib64下分別生成32位和64位的so文件，這個看看編譯後的信息就知道了．
Ⅳ linux下編譯ffmpeg 以及交叉編譯並引入Android
在Linux環境下，編譯ffmpeg並進行Android交叉編譯的步驟如下：
首先，為支持mp3編碼，你需要安裝lame庫，可通過`ffmpeg -i audio.wav -acodec libmp3lame audio.mp3`進行測試。然後，編譯ffmpeg，常用的配置命令是`./configure --prefix=/usr/local/ffmpeg --enable-debug=3`，但可能會遇到錯誤，如gcc編譯器問題或nasm/yasm未找到。遇到這些問題，建議更新ffmpeg版本並檢查config.log日誌。
編譯時，可能遇到許可權問題，如`mkdir: cannot create directory '...': Permission denied`，這時需要確保有足夠的許可權。環境變數的配置也很重要，可以在.profile文件中添加`path`和`pkg_config_path`，配置後通過`source .profile`使更改生效。
在編譯過程中，如果ffplay沒有出現在bin目錄中，可能需要安裝sdl2並重新configure、make和install。如果遇到so文件鏈接問題，可以編輯`/etc/ld.so.conf`並運行`ldconfig`來解決。
為了在Android設備上使用ffmpeg，你需要下載Android NDK，然後執行`make-standalone-toolchain.sh`生成交叉編譯工具鏈。創建一個腳本（build_ffmpeg.sh），包含針對不同架構的編譯命令，注意調整工具鏈路徑、架構和輸出目錄。
在編譯ffmpeg時，可能需要額外添加x264支持以處理h264編碼。下載x264源碼後，同樣使用configure進行配置，但可能需要解決缺少nasm的問題。
總的來說，編譯ffmpeg涉及多個步驟，包括安裝依賴庫、配置環境、處理編譯錯誤和生成針對Android的交叉編譯版本。務必查閱文檔以確保正確設置和執行每個步驟。
Ⅳ 如何加快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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。
Ⅵ 如何在APK程序里執行linux命令
Android的底層是Linux內核，因此在shell環境下可以運行Linux命令，尤其是經過root處理的android系統，基本上可以通過調用Linux命令完全控制手機，下面的RootCmd.java代碼可以實現運行Linux外部命令。
packagemy.android.code;
importandroid.os.Environment;
importdalvik.annotation.Signature;
importjava.io.BufferedReader;
importjava.io.DataInputStream;
importjava.io.DataOutputStream;
importjava.io.File;
importjava.io.FileReader;
importjava.io.InputStream;
importjava.io.OutputStream;
importjava.util.Vector;
publicfinalclassRootCmd
{
//執行linux命令並且輸出結果
(StringparamString)
{
VectorlocalVector=newVector();
try
{
ProcesslocalProcess=Runtime.getRuntime().exec("su");//經過Root處理的android系統即有su命令
OutputStreamlocalOutputStream=localProcess.getOutputStream();
=newDataOutputStream(localOutputStream);
InputStreamlocalInputStream=localProcess.getInputStream();
=newDataInputStream(localInputStream);
Stringstr1=String.valueOf(paramString);
Stringstr2=str1+" ";
localDataOutputStream.writeBytes(str2);
localDataOutputStream.flush();
Stringstr3=localDataInputStream.readLine();
localVector.add(str3);
localDataOutputStream.writeBytes("exit ");
localDataOutputStream.flush();
localProcess.waitFor();
returnlocalVector;
}
catch(ExceptionlocalException)
{
localException.printStackTrace();
}
}
//執行linux命令但不關注結果輸出
(StringparamString)
{
try
{
ProcesslocalProcess=Runtime.getRuntime().exec("su");
ObjectlocalObject=localProcess.getOutputStream();
=newDataOutputStream((OutputStream)localObject);
Stringstr=String.valueOf(paramString);
localObject=str+" ";
localDataOutputStream.writeBytes((String)localObject);
localDataOutputStream.flush();
localDataOutputStream.writeBytes("exit ");
localDataOutputStream.flush();
localProcess.waitFor();
localObject=localProcess.exitValue();
returnlocalObject;
}
catch(ExceptionlocalException)
{
localException.printStackTrace();
}
}
//判斷機器Android是否已經root，即是否獲取root許可權
()
{
inti=execRootCmdSilent("echotest");//通過執行測試命令來檢測
if(i!=-1)returntrue;
retrunfalse;
}
}
Ⅶ 如何在Linux平台下編譯android工程
我是在windows下做開發的，但是編譯環境還是在linux上。。大體的步驟如下：
1.首先在windows環境下編寫工程（eclipse下編寫android工程）
2.打開linux開發環境(tcl平台：\\10.120.90.207\longc\workspace\code\project\kernel\android\JB)
3.將運行環境的腳本文件運行./evnsetup:配置android運行環境
/JB/build/
找到envsetup.sh
運行.envsetup.sh(source envsetup.h或./envsetup)
所有操作都在終端完成
4.將工程文件拷貝到指定目錄下（TCL平台下的自帶程序在package\TCL_Apps目錄下）
5.刪除一些文件
保留/res,/src,AndroidManifest.xml三個文件
創建Android.mk(makefile文件，linux下用makefile文件來集成一些命令，運行程序的指令和設置都在此處)Android.mk的編寫
6.編譯
進入工程文件目錄
輸入mm命令進行編譯。
7.生成apk文件，編譯完成
Ⅷ Linux下如何編譯Android源碼~~~
這個問題已經找到解決方案了，方法如下：
1.在Linux設置文件共享，將項目共享，最好有個密碼什麼的。
2.在Linux上配置sshserver，用於和編譯安卓源碼3.Linuxmac通過連接，原因是有線傳輸比無線的快很多，ping只是0.3左右ms，不影響使用。然後就可以mac編寫代碼，然後ssh編譯什麼的，很方便，