eabiandroid

① android中libs目錄下armeabi和armeabi-v7a的區別

您好，很高興能幫助您
在我們android APK的根目錄有一個 libs文件夾，此文件夾下包含了armeabi 和armeabi-v7a兩個文件夾，我們的c代碼編譯成的本地庫（各種.so）就會放在這兩個文件夾其中的一個。那armeabi-v7a 與 armeabi有什麼區別，都是什麼意思呢？

armeabi和armeabi-v7a是表示cpu的類型，我們知道一般的手機或平板都是用arm的cpu（mips的就悲催的被忽視了），不同的cpu的特性不一樣，armeabi就是針對普通的或舊的arm cpu，armeabi-v7a是針對有浮點運算或高級擴展功能的arm cpu。

在android.mk里可配置以下宏：

TARGET_CPU_API := armeabi

APP_ABI := armeabi
你的採納是我前進的動力，
記得好評和採納，答題不易，互相幫助，

② android中libs目錄下armeabi和armeabi-v7a的區別

1、armeabi armeabi是指的該so庫用於Arm的通用CPU。

2、armeabi-v7a
v7a的CPU支持硬體浮點運算。

3、共同點
armeabi和armeabi-v7a是表示cpu的類型。

4、不同點
因此armeabi通用性強，但速度慢，而v7a能充分發揮v7a CPU的能力。armeabi就是針對普通的或舊的armcpu，armeabi-v7a是針對有浮點運算或高級擴展功能的arm cpu。

③ android APK根目錄下 libs文件夾的armeabi和armeabi-v7a的區別

在我們android
APK的根目錄有一個
libs文件夾，此文件夾下包含了armeabi
和armeabi-v7a兩個文件夾，我們的c代碼編譯成的本地庫（各種.so）就會放在這兩個文件夾其中的一個。那armeabi-v7a
與
armeabi有什麼區別，都是什麼意思呢？
armeabi和armeabi-v7a是表示cpu的類型，我們知道一般的手機或平板都是用arm的cpu（mips的就悲催的被忽視了），不同的cpu的特性不一樣，armeabi就是針對普通的或舊的arm
cpu，armeabi-v7a是針對有浮點運算或高級擴展功能的arm
cpu。
在android.mk里可配置以下宏：
TARGET_CPU_API
:=
armeabi
APP_ABI
:=
armeabi
如果我的回答沒幫助到您，請繼續追問。

④ android中libs目錄下armeabi和armeabi-v7a的區別

armeabi默認選項，
支持基於
ARM*
v5TE
的設備
支持軟浮點運算（不支持硬體輔助的浮點計算）
支持所有
ARM*
設備
armeabi-v7a
支持基於
ARM*
v7
的設備
支持硬體
FPU
指令
支持硬體浮點運算
不同手機由於cpu的不同，使用不同的驅動。
ABI:指應用基於哪種指令集來進行編譯，ABI總共有四種，分別是armeabi、armeabi-v7a、mips、x86，它們都是表示cpu的類型。

⑤ 最新android工程目錄下armeabi-v7a，armeabi的具體含義，有什麼區別

1.在Android APK的根目錄有一個 libs文件夾（一般會有，但最新版的studio好像沒有），此文件夾下包含了armeabi 和armeabi-v7a兩個文件夾，我們的c代碼編譯成的本地庫（各種.so）就會放在這兩個文件夾其中的一個。

2.
那armeabi-v7a 與 armeabi有什麼區別？
armeabi和armeabi-v7a是表示cpu的類型，一般的手機或平板都是用arm的cpu，不同的cpu的特性不一樣，armeabi就是針對
普通的或舊的arm cpu，armeabi-v7a是針對有浮點運算或高級擴展功能的arm cpu。

在android.mk里可配置以下宏：

TARGET_CPU_API := armeabi
APP_ABI := armeabi1212

3.當你編譯時出現一些鏈接動態庫的undefine錯誤，或你的apk運行時出現裝載.so動態庫錯誤時，不妨看一下這個cpu類型的配置是否有誤。

⑥ Android中的armeabi、armeabi-v7a、arm64-v8a及x86的詳解

一. lib和libs
放在lib中的是被reference的，放在libs中的是被include的。
放在libs中的文件會自動被編輯器所include。所以不要把API放到libs里去。
lib的內容是不會被打包到APK中，libs中的內容是會被打包進APK中

二. .so庫
NDK編譯出來的動態鏈接庫。
一些重要的加密演算法或者核心協議一般都用c寫然後給java調用。這樣可以避免反編譯後查看到應用的源碼。

三. .so庫該如何存放
放置 .so 文件的正確姿勢其實就兩句話：
• 為了減小 apk 體積，只保留 armeabi 和 armeabi-v7a 兩個文件夾，並保證這兩個文件夾中 .so 數量一致
• 對只提供 armeabi 版本的第三方 .so，原樣復制一份到 armeabi-v7a 文件夾
存放so的規則：
你應該盡可能的提供專為每個ABI優化過的.so文件，但要麼全部支持，要麼都不支持：你不應該混合著使用。你應該為每個ABI目錄提供對應的.so文件。

四. libs下armeabi等的作用是什麼
存放.so庫，主要針對不同的設備兼容，也可以說是專門針對不同Android手機下CPU架構的兼容。
Android 設備的CPU類型(通常稱為」ABIs」)

早期的Android系統幾乎只支持ARMv5的CPU架構，後面發展到支持七種不同的CPU架構：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯著一個相應的ABI。
應用程序二進制介面（Application Binary Interface）定義了二進制文件（尤其是.so文件）如何運行在相應的系統平台上，從使用的指令集，內存對齊到可用的系統函數庫。在Android 系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。

armeabi-v7a: 第7代及以上的 ARM 處理器。2011年以後生產的大部分Android設備都使用它.
arm64-v8a: 第8代、64位ARM處理器，很少設備，三星 Galaxy S6是其中之一。
armeabi: 第5代、第6代的ARM處理器，早期的手機用的比較多。
x86: 平板、模擬器用得比較多。
x86_64: 64位的平板。

如果項目只包含了 armeabi，那麼在所有Android設備都可以運行；
如果項目只包含了 armeabi-v7a，除armeabi架構的設備外都可以運行；
如果項目只包含了 x86，那麼armeabi架構和armeabi-v7a的Android設備是無法運行的； 如果同時包含了 armeabi， armeabi-v7a和x86，所有設備都可以運行，程序在運行的時候去載入不同平台對應的so，這是較為完美的一種解決方案，同時也會導致包變大。

最後，如果我們只想支持armeabi-v7a，那麼需要在gradle中配置

因為默認情況下，打包後會自動生成armeabi 到 x86的所有文件夾。這就有可能導致一些x86的設備因為在x86文件夾下找不到so文件而崩潰。

⑦ arm-linux-androideabi於arm-linux-gnueabi區別

現在android的工程大部分是用clang編譯，在之前的android工程主要是使用gcc，也就是arm-linux-androideabi-gcc，但是其他嵌入式系統使用的是arm-linux-gnueabi，那麼這兩個有什麼區別呢？ 能不能混用呢？
先說區別，根據linaro給的，主要有三處
1）There are a few differences between the Linux EABI and Android EABI definitions - most notably, Android defines the size of an enum to 32 bits while regular Linux defines it as variable.
2）Android does not currently use the hardfloat ABI conventions that have become common in regular Linux.
3）Android uses the Gold linker by default while the regular Linux builds default to using the BFD linker (this is for upstream compatibility - Android uses gold while most regular Linux distributions use the BFD linker).
翻譯後是兩者之前區別很少，主要有enum不一樣，谷歌定義enum為32為，而其他的都定義為變數。android編譯器使用的是softfp，而其他的使用的是hardfloat，如果使用linux-arm-gnueabi編譯android工程的話，會出現「unrecognized option '-mfloat-abi=softfp'」就是指的這個，第三個是linker不同，這個應該好理解，android在bionic中定製了linker。

⑧ 說說Android項目中的armeabi，armeabi-v7a和x86

   這三者都表示的是CPU類型，早期的Android系統幾乎只支持ARMv5的CPU架構，但是現在已經有7種了。ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯著一個相應的ABI（應用程序二進制介面（ApplicationBinary Interface）定義了二進制文件（尤其是.so文件）如何運行在相應的系統平台上，從使用的指令集，內存對齊到可用的系統函數庫）。Android現在的主流CPU是armeabi-v7a。armeabi-v7a是針對有浮點運算或高級擴展功能的ARMv7 CPU。

   當一個應用安裝在設備上，只有該設備支持的CPU架構對應的.so文件會被安裝。不同CPU架構的Android手機載入時會在libs下找自己對應的目錄，從對應的目錄下尋找需要的.so文件；如果沒有對應的目錄，就會去armeabi下去尋找，如果已經有對應的目錄，但是如果沒有找到對應的.so文件，也不會去armeabi下去尋找了。
   以x86設備為例，x86設備會在項目中的 libs文件夾尋找是否含有x86文件夾，如果含有x86文件夾，則默認為該項目有x86對應的so可運行文件，只有x86文件夾而文件夾下沒有so，程序運行也是會出現findlibrary returned null的錯誤的；如果工程本身不含有x86文件夾，則會尋找armeabi或者armeabi-v7a文件夾，兼容運行。以armeabi-v7a設備為例，該Android設備當然優先尋找libs目錄下的armeabi-v7a文件夾，同樣，如果只有armeabi-v7a文件夾而沒有 so也是會報錯的；如果找不到armeabi-v7a文件夾，則尋找armeabi文件夾，兼容運行該文件夾下的so，但是不能兼容運行x86的so。所以項目中如果只含有x86的so，在armeabi和armeabi-v7a也是無法運行的。以上就是不同CPU架構運行時載入so的策略。

   目前主流的Android設備是armeabi-v7a架構的，然後就是x86和armeabi了。如果同時包含了 armeabi，armeabi-v7a和x86，所有設備都可以運行，程序在運行的時候去載入不同平台對應的so，這是較為完美的一種解決方案，但是同時也會導致包變大。
   armeabi-v7a是可以兼容armeabi的，而v7a的CPU支持硬體浮點運算，目前絕大對數設備已經是armeabi-v7a了，所以為了性能上的更優，就不要為了兼容放到armeabi下了。x86也是可以兼容armeabi平台運行的，另外需要指出的是，打出包的x86的so，總會比armeabi平台的體積更小，對於性能有潔癖的童鞋們，還是建議在打包so的時候支持x86。

   第三方的類庫只提供了armeabi下的.so文件，我們項目里適配了armeabi-v7a和x86，如果不在對應的文件下放對應的.so文件，就可能導致某些Android設備會出一些問題，我們可以復制armeabi下得.so文件到不同的文件夾下。如果第三方提供了不同平台的.so文件，則復制不同平台的.so文件到項目中對應的文件夾下即可。
   關於.so文件之前有一個坑，svn會把提交的so文件過濾掉，在接第三方SDK的時候通過SVN更新了文檔，但是沒有注意到少了幾個so文件，浪費了大把的時間去找原因。記得去掉svn對so的忽略！！！

⑨ 如何使用arm-eabi-gdb調試android c/c++程序

1.獲取gdbserver
prebuilt/android-arm/gdbserver
2.獲取arm-eabi-gdb
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
3.啟動emulator(即qemu虛擬機，調式linux內核時用到)
$adb remount && adb push gdbserver /system/bin
adb shell
#gdbserver 10.0.2.2:1234 /system/bin/ping

$telnet localhost 5554
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Android Console: type 'help' for a list of commands
OK
]
KO: unknown command, try 'help'
**cmd**redir add tcp:1234:1234
OK
exit
Connection closed by foreign host.
$cd out/target/proct/generic/symbols/system/bin && arm-eabi-gdb ping

(gdb) r
Starting program:
Don't know how to run. Try "help target".
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0xb0000100 in ?? ()
(gdb) l
1779 usage();
1780 if (argc > 5)
1781 usage();
1782 } else {
1783 if (argc > 10)
1784 usage();
1785 options |= F_SOURCEROUTE;
1786 }
1787 }
1788 while (argc > 0) {

⑩ 如何使用arm-eabi-gdb調試android c/c++程序

1，先下載最新版本的gdb源代碼包，我使用的是gdb-7.6.tar.gz，使用tar命令進行解包（tar -xvzf gdb-7.6.tar.gz）,cd進gdb-7.6/gdb目錄，使用vi找到remote.c中的如下代碼:
if(buf_len > 2 * rsa->sizeof_g_packet)
error(_("Remote 'g' packet reply is too long: %s"),rs->buf);
將上面兩行注釋掉，添加如下代碼
if(buf_len > 2 * rsa->sizeof_g_packet)
{
rsa->sizeof_g_packet = buf_len;
for(i = 0; i < gdbarch_num_regs(gdbarch); i++)
{
if(rsa->regs[i].pnum == -1)
continue;
if(rsa->regs[i].offset >= rsa->sizeof_g_packet)
rsa->regs[i].in_g_packet = 0;
else
rsa->regs[i].in_g_packet = 1;
}
}
使用如下命令對代碼進行配置、編譯和安裝
./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v
make
make install
2，gdbserver使用android4.2模擬器中自帶的版本（v7.1）
3，將NDK編譯好的C/C++可執行程序，上傳到模擬器中/data/test目錄下，假設可執行程序的名稱為testHello。
4，使用命令：gdbserver :7000 /data/test/testHello 啟動模擬器端的調試。
5，啟動arm-linux-gdb之前，使用vi打開~/.bash_profile文件，在其中添加：
export PATH=$PATH:/usr/local/arm-gdb/bin,以便在程序的其他目錄可以直接啟動arm-linux-gdb程序
6，cd至ndk編譯好的testHello文件所在目錄
7，使用如下命令進行埠映射：adb forward tcp:7000 tcp:7000,將模擬器的7000埠和本機的7000埠進行映射
8，使用命令：arm-linux-gdb testHello啟動gdb調試
9，使用target remote :7000 鏈接模擬器中gdbserver啟動的服務。
10，自此，我們就可以使用gdb命令進行代碼調試了。