I have an android system with two different CPU ABI - armeabi-v7a and x64 .For which one I have to build the application code to get it working.My application (in c language) anyway doesnt run for either of the platforms.
OR is there any common tool chain with which I can build the same.
arm-eabi-gcc?
The NDK contains all the toolchains you need to run your program on Android platforms.
To setup the architectures you need to compile to, you should set the APP_ABI variable inside Application.mk or pass it to the ndk-build command.
APP_ABI:=all will make your ndk project being built for all the supported architectures: armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips, mips64.
You can also list which architectures you want to build for: APP_ABI:= x86_64 x86 armeabi-v7a arm64-v8a and also use all32 and all64 as shortcuts to all the 32-bit and all the 64-bit architectures.
To determine which platforms are supported by a target device, you can call adb shell getprop ro.product.cpu.abi (preferred arch) and adb shell getprop ro.product.cpu.abi2 (second arch).
Starting with Android 5.0, use adb shell getprop ro.product.cpu.abilist instead, that returns a list of all the supported ABIs, sorted in preference order.
I don't think you can target completely different architecture (arm and x86) with android provided ndk (cross-compilers). You can target multiple ABI supported by arm with following variable
TARGET_ARCH_ABI
possible values are:
armeabi For ARMv5TE
armeabi-v7a
for more details you can check this link.
To run in x86 or amd64 system you can normally use a gcc to create the .so file and use JNI to test functionally (remember Android F/W will be unavailable there).
If you are looking for rapid building-testing cycle I think it's better for you to use an x86 based emulator like AndroVM (now Genymotion). In that way you can write code for android device and test it real quick.
Related
I have a small application that uses a native ARM shared library (.so). When using Genymotion, I can successfuly install the ARM translation package (just by dropping the ZIP file) and the app runs fine on a x86-based emulator.
Now I have the need to run the same app in a headless linux server, which is not supported by Genymotion. I downloaded the official google emulator and corresponding system image. After extracting the files from zip archive and uploading to /system partition, I can run houdini --version, however the application won't install (INSTALL_FAILED_NO_MATCHING_ABIS).
Can you please guide me how to run the app which contains ARM library on the official google x86 emulator?
What is the output of houdini --version ?
When you install applications PackageManager checks ABI of the app(which libraries are contained in the apk .so files) and the ABI of the system (which type of libraries system supports)
if you run getprop | grep -i abi
getprop | grep -i abi
[ro.product.cpu.abi]: [x86]
[ro.product.cpu.abilist]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [x86,armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: []
In this output, the system supports 32 bit .so files of x86, armeabi-v7a and armeabi type.
Please check this output on your device. Most probably there will be no mention of armeabi in this output.
So when PackageManager tries to install ARM app and checks that this ABI is not supported, it throws INSTALL_FAILED_NO_MATCHING_ABIS error.
So you will have to fix the system ABIs.
Edit the file /system/build.prop to add ARM support, in ro.product.cpu.abilist and ro.product.cpu.abilist32.
If you are running 64 bit Android, you will have to change these lines.
ro.product.cpu.abilist=x86_64,x86,arm64-v8a,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist64=x86_64,arm64-v8a
I would like to import the library libsndfile. According to it's doc I need a standalone toolchain for this. Now I'm trying to build said toolchain with Cygwin as described in the official guide but get the error message:
Unsupported platform: CYGWIN_NT-10.0.
I am new to android development and must admit that I struggle with the official guide quite a bit. From what I understand the --arch argument refers to the system I'm building for and the --api argument to the (minimum?) Android version it is running. Which toolkit exactly it is should be irrelevant at this point as long as they are compatible. So for now let's go with --arch x86_64 and --api 21. Overall the in- and output look as follows:
$ ./build/tools/make_standalone_toolchain.py --arch x86_64 --api 21 -v --install-dir ../toolchains/oboe_record_proto/
Unsupported platform: CYGWIN_NT-10.0
This may not be a satisfying answer but here what worked for me in the end:
According to the comment by matzeri, Cygwin is not supported (anymore). My attempts to solve it with Mingw / Msys as suggested were without success either.
Ths, I installed python under Windows and ran the script from the Windows command line.
python .\build\tools\make_standalone_toolchain.py --arch x86_64 --api 21 -v --install-dir ..\toolchains\oboe_record_proto
The toolchain was generated as expected.
How do you define the NDK installation that ndk-build uses? I used the r10e build for a good while, then updated my NDK and modified my $PATH to point to the new location, but when I build using the ndk-build command in Terminal it still uses the older android-ndk-r10e version.
I know this because I use the NDK_LOG=1 option when invoking ndk-build and it produces the following verbose information as it builds my project. Notice the references to "/NDKDev/android-ndk-r10e". That's my old installation.
~/Documents/MyNDKProject-- $ ndk-build NDK_LOG=1
HOST_OS=darwin
HOST_ARCH=x86_64
HOST_TAG=darwin-x86_64
GNUMAKE=/Users/user1/Documents/NDKDev/android-ndk-r10e/prebuilt/darwin-x86_64/bin/make (NDK prebuilt)
Android NDK: NDK installation path auto-detected: '/Users/user1/Documents/NDKDev/android-ndk-r10e'
Android NDK: GNU Make version 3.81 detected
Android NDK: Host OS was auto-detected: darwin
Android NDK: Host operating system detected: darwin
Android NDK: Host CPU was auto-detected: x86
Android NDK: HOST_TAG set to darwin-x86
Android NDK: Host tools prebuilt directory: /Users/user1/Documents/NDKDev/android-ndk-r10e/prebuilt/darwin-x86_64/bin
Android NDK: Host 'echo' tool: echo
. . .
Also note that when I enter echo $PATH at the Terminal prompt it gives:
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin/:/sbin:/usr/local/bin:/Applications/android-sdk-macosx/ndk-bundle:/Applications/android-sdk-macosx
and where you see /Applications/android-sdk-macosx/ndk-bundle is exactly where it used to refer to the android-ndk-r10e path, so I'm certain I've updated my PATH successfully. So anyhow, IF the PATH environment variable is not what ndk-build uses to determine the NDK installation to use, what does it use, and how can I modify it so that it uses my new installation which is at:
/Applications/android-sdk-macosx/ndk-bundle
Fixed. The problem was that when the .bash_profile file is successfully sourced in a given Terminal session it does not have any effect on other instances of Terminal that are open. I had two instances of Terminal open and because I hadn't closed the one with which I was calling ndk-build the changes to .bash_profile weren't being applied.
I got similar to this problem: Android Studio 64-bit ERROR: 32-bit Linux Android emulator binaries are DEPRECATED
I run android studio 2.1.1 on Gentoo Linux/amd64,
and when I try to run emulator of android android studio give me error:
/home/user/Android/Sdk/tools/emulator -netdelay none -netspeed full
-avd Nexus_5X_API_23 ERROR: 32-bit Linux Android emulator binaries are DEPRECATED, to use them
you will have to do at least one of the following:
- Use the '-force-32bit' option when invoking 'emulator'.
- Set ANDROID_EMULATOR_FORCE_32BIT to 'true' in your environment.
Either one will allow you to use the 32-bit binaries, but please be
aware that these will disappear in a future Android SDK release.
Consider moving to a 64-bit Linux system before that happens.
But
$ file /home/user/Android/Sdk/tools/emulator
/home/user/Android/Sdk/tools/emulator: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.15, stripped
As you can see emulator is 64bit binary, I run it 64bit OS,
also Tools->Android->Avd Manger show that Nexus_5X_API_23 has CPU/ABI = x86_64,
so what is "32-bit error" about?
Update
Looks like it need some permission, because of I can run emulator from root user. But still can not guess what exactly it need.
The problem was with the SHELL environment variable.
If I run emulator under root with SHELL=/bin/bash it all works fine, but if I run emulator from an ordinary user with SHELL=bash, it fails and shows the error message about 32 bit.
I try to debug a very basic example Qt 5.3 Android native C++ project, and I would like to debug it on the target without using QtCreator or any other IDE like Eclipse but only NDK tools.
This project is compiled through QtCreator tools using Android platform target, in debug mode (-O0, -g), using NDK toolchain, BUT NOT ndk-build.
Therefore I got my .apk, the application itself has been installed on the target and works, everything is fine up to that point. Now I want to execute it in debug mode using NDK tools.
I would like to use ndk-gdb as this seems to be one of the most obvious ways, therefore:
- I created manually required files under my main project directory:
bin
src
res
...
jni
|-- Android.mk
`-- Application.mk
libs
|-- armeabi-v7a
| |-- gdbserver
| |-- gdb.setup
The tree above only underline the files I added by hand, given that they are normally created by ndk-gdb.
Under the 'libs' directory is also stored the native library of the project, called by a simple java wrapper.
jni/Android.mk and jni/Application.mk contains the same single line:
APP_ABI := armeabi-v7a
gdb.setup:
set solib-search-path ./libs/armeabi-v7a
directory <myrootdir>/NDKToolchain/sysroot/usr/include <myrootdir>/NDKToolchain/include/c++/4.6 <myrootdir>/NDKToolchain/include/c++/4.6/arm-linux-androideabi/armv7-a [...]
I checked that the target was connected and accessible by installing the application using adb:
% adb install -r bin/QtApp-debug.apk
It worked ('success'), which I could check directly on the target.
Then when I try to run ndk-gdb, it failed:
% ndk-gdb --start --nowait --verbose
WARNING: The shell running this script isn't bash. Although we try to avoid bashism in scripts, things can happen.
ndk-gdb: 84: Bad substitution
Android NDK installation path: [...]
Using default adb command: [...]/sdk/platform-tools//adb
ADB version found: Android Debug Bridge version 1.0.31
Using ADB flags:
Using JDB command:
Using auto-detected project path: .
Found package name: org.qtproject.example.fridgemagnets
ABIs targetted by application: armeabi-v7a
Device API Level: 18
Device CPU ABIs: armeabi-v7a armeabi
[: 564: 1: unexpected operator
Compatible device ABI: armeabi-v7a
Using gdb setup init: ./libs/armeabi-v7a/gdb.setup
Using toolchain prefix: [...]/ndk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-
Using app out directory: ./libs/armeabi-v7a
Found debuggable flag: false
Found gdb.setup under libs/armeabi-v7a, assuming app was built with NDK_DEBUG=1
ERROR: Could not extract package's data directory. Are you sure that
your installed application is debuggable?
A previous run of ndk-gdb showed me that for some reason it wanted to use ./obj/local/armeabi-v7a as "app out directory", while I set it in gdb.set to ./libs/armeabi-v7a, therefore I had to hack the ndk-gdb script to force it to use the path I chosed. I don't believe this is related to my real issue (?)
Given that I didn't use ndk-build, I believe that my attempt to use ndk-gdb is hopeless, or at least that it will ask me too much work and hacking of NDK scripts which I don't want to do.
Thus 2 questions:
Did I miss something during my build or deployment for getting a
debuggable app ? I know that debuggable flag in Manifest being
'false' is not necessarily an issue, as I built my app with debug
flags. BTW this seems to be confirmed by the fact that the error
message I get is not related to that flag but to the fact that the
script seems to exepect a DATA_DIR folder somewhere...
Is there a
way to debug my application, without using ndk-gdb (and any IDE),
but for example just 'gdb' ?
Thanks in advance
Question 1:
I know that as of SDK r8 you can invoke ant with release or debug. Building with the debug flag might package or run your application differently. Thus allowing or disallowing debugging? This seems like it might be the issue.
Question 2:
From what I understand ndk-gdb does a lot of setup and communication with adb to allow debugging your application, as you may have seen from the script. I wouldn't suggest going down the rabbit hole of not using it.