search

Ruchika30 / javacv

Automatically exported from code.google.com/p/javacv
GNU General Public License v2.0
0 stars 0 forks source link

binaries and build scripts for Android on x86 devices and emulators #411

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Building an application that uses JavaCV
2. Deploying it on the Android accelerated emulator, Genymotion or an x86 device

What is the expected output? What do you see instead?
"cpu abi incompatible" is thrown during installation on emulators, installation 
is working on x86 devices but execution is slower.

What version of the product are you using? On what operating system?
JavaCV 0.7 for Android

Please provide any additional information below.
Please add build scripts and x86 binaries for Android. I've written an article 
and provided these here if you need: 
http://ph0b.com/getting-an-x86-version-of-javacv-for-android/ - thanks !

Original issue reported on code.google.com by xavier.h...@gmail.com on 16 Jan 2014 at 8:39

GoogleCodeExporter commented 8 years ago 
That's great, thank you very much! Good work! I'll be sure to let you know next 
time I update the binary packages so we can include that in there...

Original comment by samuel.a...@gmail.com on 19 Jan 2014 at 6:31

GoogleCodeExporter commented 8 years ago 
@xavier Actually, I'm moving all that scripting to the JavaCPP Presets, which 
is already in a much better state than the equivalent inside JavaCV at the 
moment:
    http://code.google.com/p/javacpp/wiki/Presets#CPPBuild_Scripts
If you could provide the modifications required to that set of scripts, it'd be 
great! Thanks

Original comment by samuel.a...@gmail.com on 23 Mar 2014 at 1:53

GoogleCodeExporter commented 8 years ago 
Hi Samuel,

please find attached the patch you asked. I made it after your latest commit 
(d5bd9f3afe353618a30f0fa55a38d3e10ce5643d).
All the libs are built fine when calling "bash cppbuild.sh -platform 
android-x86 install opencv ffmpeg artoolkitplus",
but I couldn't fully test my patch as javacpp was failing with this error when 
building the libs for android-x86 or android-arm platforms: 

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
com.googlecode.javacpp:javacpp:0.8-SNAPSHOT:build (process-classes) on project 
opencv: Execution process-classes of goal 
com.googlecode.javacpp:javacpp:0.8-SNAPSHOT:build failed: An API 
incompatibility was encountered while executing 
com.googlecode.javacpp:javacpp:0.8-SNAPSHOT:build: 
java.lang.IncompatibleClassChangeError: com.googlecode.javacpp.opencv_core and 
com.googlecode.javacpp.opencv_core$CvArr disagree on InnerClasses attribute

Original comment by xavier.h...@gmail.com on 24 Mar 2014 at 4:47

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks for taking care of this so quickly!

The error you're getting with Maven is probably caused by leftovers from 
previous build. Calling "mvn clean" should fix that.

Interesting, we can use the toolchain that comes with OpenCV. I thought it 
wouldn't work for creating normal shared libraries. It seems to compile fine, 
great! Does it actually work on your device?? If so, I guess we could do the 
same for the ARM build while we're at it... There's one unrelated problem 
though: The .so files installed by android-arm and android-x86 get copied in 
the same "lib" subdirectory. I guess we could tell CMake to put one set in 
lib-arm, and the other set in lib-x86. What do you think?

Original comment by samuel.a...@gmail.com on 25 Mar 2014 at 1:03

GoogleCodeExporter commented 8 years ago 
Or maybe in a subdirectory like lib/armeabi and lib/x86, to be consistent with 
the way Android actually loads them:
https://groups.google.com/forum/#!msg/adt-dev/nQobKd2Gl_8/Z5yWAvCh4h4J
(And I'll need to modify JavaCPP to let us produce such JAR files to be 
compatible with this new Gradle build system...)

Original comment by samuel.a...@gmail.com on 25 Mar 2014 at 1:18

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
You're right, I forgot "mvn clean".. it fixed the issue, thanks!

Yes it works on my device, actually that's what I already did for the previous 
version of javacv.

Without patching OpenCV CMakeLists (from opencv/opencv-2.4.8-android-*.patch), 
the libs are already generated inside "sdk/native/libs/x86/" and 
sdk/native/libs/armeabi-v7a/" - would this be ok ? Otherwise we can continue 
patching it to simply remove the "sdk/native/" part.
opencv-2.4.8/CMakeLists.txt:282 ->
  set(OPENCV_LIB_INSTALL_PATH     sdk/native/libs/${ANDROID_NDK_ABI_NAME})
  set(OPENCV_3P_LIB_INSTALL_PATH  sdk/native/3rdparty/libs/${ANDROID_NDK_ABI_NAME})
  set(OPENCV_CONFIG_INSTALL_PATH  sdk/native/jni)
  set(OPENCV_INCLUDE_INSTALL_PATH sdk/native/jni/include)

For the new gradle build system, you could directly produce .aar as described 
here, now that's supported: 
http://tools.android.com/tech-docs/new-build-system/aar-format

Original comment by xavier.h...@gmail.com on 25 Mar 2014 at 5:59

GoogleCodeExporter commented 8 years ago 
I wonder how they figured that "sdk/native" was a good subdirectory name, but 
yes we could work with that. Last time I didn't apply the patch, it wouldn't 
even create the normal shared libraries, so that's why I had to come up with a 
special way to build them. Good to know they changed their minds about that :)

About AAR, it looks like something that could be added on top of the JAR file 
creation, but since we don't have AAR files in Java SE, to make things more 
portable, I'd like to see if we couldn't use JAR files for native libraries on 
Android as well. What happens if we put ffmpeg-android-x86.jar in the libs 
subdirectory of an AAR artifact, for example?

Original comment by samuel.a...@gmail.com on 26 Mar 2014 at 12:29

GoogleCodeExporter commented 8 years ago 
Unfortunately, .so files inside .jar files aren't automatically included.
I'm sure they would be stripped in this case.

2014-03-26 13:29 GMT+01:00 <javacv@googlecode.com>:

Original comment by xavier.h...@gmail.com on 26 Mar 2014 at 1:56

GoogleCodeExporter commented 8 years ago 
Not according to this thread:
https://groups.google.com/forum/#!msg/adt-dev/nQobKd2Gl_8/Z5yWAvCh4h4J
If you test it out, please let me know what happens, thanks!

Original comment by samuel.a...@gmail.com on 26 Mar 2014 at 1:59

GoogleCodeExporter commented 8 years ago 
they call it a hack: it requires a specific directories organisation and it
also seems not to work at first build.
Building a proper .aar directly would be a lot cleaner, you can do so by
reusing the .jars if you want to keep some kind of portability, but
wrapping these in the libs subdir directly doesn't look right.

2014-03-26 14:59 GMT+01:00 <javacv@googlecode.com>:

Original comment by xavier.h...@gmail.com on 26 Mar 2014 at 2:28

GoogleCodeExporter commented 8 years ago 
Well, what would be best is for Google first to make up their minds about how 
we should do things on Android! I mean, why not offer "APK Expansion Files" too 
while we're at it?
http://developer.android.com/google/play/expansion-files.html

In any case, if this is something you are willing to create and maintain, sure, 
that'd be great! I'm just not sure it's the best use of my time, that's all.

Original comment by samuel.a...@gmail.com on 26 Mar 2014 at 3:18

GoogleCodeExporter commented 8 years ago 
no problem. aar is a different issue anyway, and there is no need to change
how .jars are generated for this.
Since I don't need .aar myself and also have other priorities, I would be a
bad maintainer for this feature :(

2014-03-26 16:18 GMT+01:00 <javacv@googlecode.com>:

Original comment by xavier.h...@gmail.com on 26 Mar 2014 at 4:34

GoogleCodeExporter commented 8 years ago 
Right, let's keep that on the back burner for later consideration. Anyway, for 
now, I've added a `platform.library.path` property that let's Maven create a 
JAR file as per the hack described above.

I've included that and your changes, along with other fixes in these revisions:
http://code.google.com/p/javacpp/source/detail?r=93bbeb9e7ac72f528ccab7c45c77952
3d79fc618
http://code.google.com/p/javacpp/source/detail?r=aed325a61e388ba93a8a3819c549d1a
80b7d102c&repo=presets
Let me know if that looks alright! thanks

Original comment by samuel.a...@gmail.com on 30 Mar 2014 at 5:51

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Awesome, this looks alright.
Only one little things could be added inside android-x86.properties: 
"-mfpmath=sse" for platform.compiler.fastfpu
This improves the performance a lot, allowing fpmath calculation to use sse 
instead of old x87 instructions.

Original comment by xavier.h...@gmail.com on 4 Apr 2014 at 5:22

GoogleCodeExporter commented 8 years ago 
Ah, yes, that would also be the case of other platforms using GCC. It uses SSE 
by default for the x86-64 arch, so I'm not used to think about that, but in 
32-bit mode, it uses the FPU by default. Will add that, thanks!

Original comment by samuel.a...@gmail.com on 5 Apr 2014 at 5:42

GoogleCodeExporter commented 8 years ago 
The changes have been included in the latest release of JavaCV 0.8. There are a 
lot of other changes with this release, so please make sure to read the news 
release here:
    http://bytedeco.org/release/2014/04/28/first-release.html

Incidentally, the project is now hosted on GitHub:
    https://github.com/bytedeco/javacv

Thanks once again for your contribution!

Original comment by samuel.a...@gmail.com on 29 Apr 2014 at 1:15