I've been trying to follow this sample on github to get a basic spotify implementation working, I've followed the setup steps, installed all the required libraries etc but keep getting the following error during the native build stage.
**** Build of configuration Default for project LoginActivity ****
c:\Android-ndk\android-ndk-r8e\ndk-build.cmd NDK_NO_WARNINGS=1 all
Install : libspotify.so => libs/armeabi/libspotify.so
c:/Android-ndk/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/arm-linux-androideabi-strip:./libs/armeabi/libspotify.so: File format not recognized
make: *** [libs/armeabi/libspotify.so] Error 1
make: *** Deleting file `libs/armeabi/libspotify.so'
**** Build Finished ****
I downloaded the android specific library, then tried various combinations of Linux ARM libraries just to see what would happen and the result is always the same. When removing libspotify.so from the directory the build fails as expected because the file can't be found so I know the script is trying to process the file.
As far as I can tell I've followed the setup to the letter, my current guess is that the problem is related to running a 64 bit version of eclipse/java etc. Can anyone shed any light on this issue?
You need to find out what is the compilable target of this file. If you use linux, run the following command:
$ file libspotify.so
You will see if it can compile with armeabi or x86. Then, in application.mk, you need to set up the APP_ABI to armeabi or APP_ABI:X86.
It turns out this issue was caused by a corrupt archive with the .so file.
When I re-downloaded it, it worked fine. Thanks for the assistance.
EDIT
I found a version of the libspotify.so file which had been extracted properly here.
I believe you may have accidentally extracted libspotify.so (21 bytes), which is only a Unix symlink to the shared library libspotify.so.12.1.51 (1,961,644 bytes).
At least that's what I had just done which led me here. The latter needs to be renamed to the lookup name (libspotify.so) and then NDK makes fine.
Hope this helps another tired soul, at least. :)
Related
In Ubuntu 16.04, when running an Android Tensorflow TFDetect implementation using my protobuf file, I received an error stating "No OpKernel was registered to support Op 'ceil'". I had to modify the mobile build to include the proper .cc files and I then proceeded to run the following command to build the jar after rebuilding Tensorflow:
bazel build -c opt
//tensorflow/contrib/android:libtensorflow_inference.so
--crosstool_top=//external:android/crosstool --host_crosstool_top=#bazel_tools//tools/cpp:toolchain --cpu=armeabi-v7a
I then receive the error stating that the build was not complete due to stdlib.h missing:
In file included from
external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/algorithm:62:
In file included from
external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/stl_algo.h:59:
external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdlib:72:10:
fatal error: 'stdlib.h' file not found
I see many others being told to use the prebuilt binaries, but this will not work for me as I need some additional kernels that are stripped for mobile.
Anyone have any ideas as to how I can build the necessary android jar?
Well I found the issue. At the following link below it states that bazel is not supported by NDK version 16. I had originally installed 14b, but at one point when I opened my project in Android Studio, it asked to update the NDK and I upgraded. When I happened to be troubleshooting this issue I noticed that it was version 16 and then ended up removing that and installing version 14. After rebuilding all source and then performing the above call to bazel, everything went through smoothly. Stupid mistake on my part.
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/examples/android/README.md
Since updating my Android SDK about a month ago I've had endless problems leaving me with a non-functional development environment.
Initially the problem was with the v7-appcompat support library which threw up about 100 errors relating to various resources. It was fairly obvious they were resources relating to Android v5 and a quick search on Stack Overflow meant I realised the v7-appcompat library was targeting API 19. Changing the relevant settings to target API 21 fixed the resource errors.
However, the problem I've had since then is any attempt to build the library project quickly finishes with...
Error executing aapt: Return code 132
...and the library project isn't built correctly.
My original setup was with Eclipse Kepler but then I tried Android Studio v1.0.1 (same aapt error code) and today I installed Eclipse Luna to a separate directory from Kepler AND a fresh installation of ADT and SDK. Each version of Eclipse also have their own workspaces.
So basically I have two versions of Eclipse (each with their own ADT / SDK setups and workspaces) and Android Studio with its own directory structure and all three exhibit the same problem.
The question is, how do I go about diagnosing this issue? The common denominator is obviously an aapt issue but I have no idea how to fix it.
I'm running on a Debian Wheezy (32-bit) setup and I've got Java 1.7 installed correctly (as recommended).
There seems to be an issue with aapt on some 32 bit systems. It throws an error 132 on app:processDebugResources which is when aapt is 'crunching' png files ready for inclusion in the apk package. You can see more details at https://code.google.com/p/android/issues/detail?id=75110
Some people have reported that 'fixing' the offending png files (e.g. by opening in Gimp and saving) sorts the problem. When they are 'built in' to appcompat it's much harder to do of course.
Before getting into detail can you just say if you are indeed running on a 32 bit processor, and if so which one? use lscpu to find out.
OK, if anyone is interested, here is a work around so you can use your old laptop to build apps with Android Studio. Basically you strip all the png files in the appcompat-v7 library and then do a build using two versions of aapt. Yuk.
Find the appcompat-v7.aar which will be somewhere like ~/Android/Sdk/extras/android/m2repository/com/android/support/appcompat-v7/22.0.0
Extract it (it's a zip file really) to a temporary directory
Strip all the png files: find . -name "*.png" -exec mogrify -strip {} \;
Pack the files back up again: pushd appcompat-v7-22.0.0; zip -r ../appcompat-v7-22.0.0.aar; popd
Move the new aar file to replace the original (that may be enough to get a good build but it wasn't for me)
Now find an old version of aapt (I went to https://dl-ssl.google.com/android/repository/build-tools_r17-linux.zip)
Copy the version of aapt from the zip you've just picked up into the Android/Sdk/build-tools directory as aapt-17 or whatever
Rename the original aapt to aapt-0
Alternate between the two versions of aapt (e.g. ln -sf aapt-17 aapt) and you should find you can get a good build. One version will fail in one place, the other in another, getting you past all the bumps.
I know it stinks but I was desperate!!
Here's what I did, which is enough to get a successful build. Inspired by peterthevicar's answer.
downgrade sdk to 19.1.0, you can install it from studio and then change buildToolsVersion in build.gradle
rename aapt to aapt.bin and put a shell script in its place that intercepts just the png crunch (args: s -i infile -o outfile) and does a simple cp instead. would paste it here but SO's syntax highlighting suuuucks
I'm relatively new to Android and I have a problem using the ndk-build command.
I use the NDK r9d under Windows 7 64bits.
When I run my build system which creates my Android project (makefiles etc...) and then creates a process running ndk-build.cmd (I checked that it is call in the Android project) I get the error:
make.exe: *** create_child_process: DuplicateHandle(In) failed (e=6)
But when I run ndk-build.cmd "manually" in the windows command console in the same Android project created by my build system (or any Android project) everything is working.
I did find some related questions like here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014825836
https://cygwin.com/ml/cygwin/2004-09/msg01506.html
But all I found says either that it's a problem of make version which is not (I think) since ndk-build works fine when I use it "manually" or it says that it is related to stdin handling and again I don't think that the issue here. Plus all the anwsers that I found was related to a similar error but not exactly the same:
process_easy: DuplicateHandle(In) failed (e=6)
Maybe someone knows the meaning of my error message. I don't think that's specific to Android ndk-build but maybe.
Thank you for reading (and sorry for any english mistakes, I am french and not fluent in english)
Finaly, I found a solution to my problem here:
http://www.zeusedit.com/zforum/viewtopic.php?t=174
I am not sure about what the problem was but according to this link, it was related to the make environment and the handles.
The solution : Instead of using the createProcess function (from Windows) directly to call ndk-build.cmd, I created a batch file containing:
start ndk-build.cmd
And I called this batch (.bat) via the createProcess function.
I let you see the link for more details.
I'm trying to compile the Hello-jni sample but I still get this error :
*ERROR: You are using a non-Cygwin compatible Make program.
Currently using: C:/AndroidNDK/android-ndk-r8e/prebuilt/windows-x86_64/bin/make
To solve the issue, follow these steps:
1. Ensure that the Cygwin 'make' package is installed.
NOTE: You will need GNU Make 3.81 or later!
2. Define the GNUMAKE environment variable to point to it, as in:
export GNUMAKE=/usr/bin/make
3. Call 'ndk-build' again.*
First time I got this error, I found the issue about the space in the install directory (It was installed in c:\Program Files...). SoI moved it into C:/AndroidNDK/android-ndk-r8e/ but I still got the error. Then I tryed to re-install cygwin (with the make package), android-NDK but the error is always here !
When I echo the $CYGWIN_GNUMAKE I have this :
$ ndk-build NDK_LOG=1
HOST_OS=cygwin
HOST_ARCH=x86
HOST_TAG=cygwin-x86
GNUMAKE=/cygdrive/c/AndroidNDK/android-ndk-r8e/prebuilt/windows-x86_64/bin/make (system path)
CYGWIN_GNUMAKE=C:/AndroidNDK/android-ndk-r8e/build/core/check-cygwin-make.mk:43: Android.mk hello-jni.c Android NDK: C:/AndroidNDK/android-ndk-r8e/prebuilt/windows-x86_64/bin/make is not cygwin-compatible. Stop.
Cygwin-compatible GNU make detected
make: /cygdrive/c/AndroidNDK/android-ndk-r8e/build/core/build-local.mk: No such file or directory
make: *** No rule to make target `/cygdrive/c/AndroidNDK/android-ndk-r8e/build/core/build-local.mk'. Stop.
The strange thing is that here I have the message "Cygwin-compatible GNU make detected" but it still doesn't work. If somebody has an idea I would really appreciate, it has been two days now that I'm trying to fix it...
By the way, I'm a very beginner with linux shell :)
Thanks swetha kini for your help but, as I said, my directory's name does not contain space (ie. C:\AndroidNDK\android-ndk-r8e). Finally I found the issue : in the cygwin path "C:\AndroidNDK\android-ndk-r8e" was before "/usr/local/bin:/usr/bin:/bin", I just swap and now it works.
I am trying to build the bitmap-plasma sample that is included with the ndk, but getting an error. I run ndk-build from the samples/bitmap-plasma directory, and the error it displays is that it cannnot locate android/bitmap.h file.
How do i direct the ndk-build script to the file it needs?
Using android-ndk-r4 on Ubuntu Lucid 10.04
Well it's working now, so in case anyone was having my same problem:
There as an android-ndk-r4b bugfix release today, which it seems no longer has this problem.
Available to download here.
http://developer.android.com/sdk/ndk/index.html
With Ubuntu 10.04 and NDK r5b, I have just posted a bug report (with the fix included) for build_platforms.sh. See http://code.google.com/p/android/issues/detail?id=15180 for details. Essentially, the local declarations in the symlink routine must be amended. Otherwise, it only links the first file (alphabetically) from each directory, and truncates the remainder from the list.
Correcting this allowed the symbolic links to be fully populated, thereby filling in the missing header files and libraries and allowing the samples to build successfully.