I compile this for android. I want to share my jar.

[aicodex]

I add all android platform : arm,arm-v7a,arm64,mips,mips64,x86,x86_64. It just 1.9mb. and I import it to my android app, Us Android Studio . when the app installed, it can auto deploy the .so file to /data/app/xxx.xxx.xxx/lib/arm64 or /data/app/xxx.xxx.xxx/lib/arm and so on… I use two of your samples to test it. and found HistogramAMD.java line 87 maxWorkGroupSize should be "long" in android. And JOCLSample_1_2_KernelArgs.java line 173 clGetDeviceIDs(platform, deviceType, 0, null, numDevicesArray);
the deviceType can't be CL_DEVICE_TYPE_ALL but can be CL_DEVICE_TYPE_CPU/GPU/DEFAULT

[aicodex]

If you want, you can visit my fork https://github.com/aicodex/JOCL/

[gpu]

Thank you for your contribution.

A few years ago, I created a version of JOCL for Android using the NDK, but that was rather an experiment. Beyond that, I'm not so familair with Android, particularly the deployment process of native libraries.

Are there any further changes necessary (for the makefiles, for example)?

I also wonder about one change here: aicodex@1872587 :

From where did you get these strings "aarch64", "armv5tel" and "armv7hl"? The case that the architecture starts with "arm" is no longer covered now (i.e. if the string was "armXYZ", then none of the conditions would match) - it's subtle...

---

Regarding the maxWorkGroupSize: This is, in fact, a bug. It should always be a long. I'll fix this ASAP (although I want to move the samples to GitHub anyhwo - maybe I can do this in one run...)

[aicodex]

I get the string aarch64 just from my phone.
My phone have an arm64 cpu Qualcomm Snapdragon 650. I just run System.getProperty("os.arch") on My phone, so I got aarch64. armv7hl from my another phone nexus 5 with Qualcomm Snapdragon 800, and others i just guess and search from google. I think armv5tel、armv7hl、aarch64 all are android's cpu type name. In fact that armv5tel and armv7hl are all support armeabi's so. but armv5tel don't support armeabi-v7a. The reason I consider to compile armeabi-v7a's so is that the armeabi-v7a cpu can support hardware float compute.
I guess the armeabi-v7a is called "armv7hl" the arm64-v8a is called "armv5tel" just because some language like java c , don't support variable name contain "-".
I found the .jar/lib/x86 or .jar/lib/arm64-v8a when android studio compile , It will be the same .apk/lib/x86 or .apk/lib/arm64-v8a. and when you install apk , it will auto extract to /data/xxx.xxx.xxx/lib/arm64. and I try to delete some folder or rename folder. I found it can auto select one ".so" nearer to your cpu. such as if you don't have arm64-v8a,but have armeabi folder, It will create an /data/xxx.xxx.xxx/lib/arm folder and extract the armeabi into.
I haven't so many device , so I can't test armv5tel. I guess in Raspberry Pi os will be "linux" arch will be arm or arm64.
But by the way, I think you need't support armv5tel… because many this type of cpu don't support Open Cl. I think the most valuable platform is armeabi-v7a arm64-v8a with Open Cl 1.2 full or newer. It can support many work in Machine Learning and Deep Learning. I don't know mips cpu… but I found one thing that in mobile platform , the device which support Open Cl just is gpu… The cpu don't support, so you just need to collect GPU information in mobile platform . and some Deep learning framework are base on Open Cl 1.2. So I think today 1.2 is most valuable Open Cl version.

[gpu]

Admittedly, I didn't understand this in all depth. However, regarding a new release, the most important parts will be the update of the LibUtils, as well as the corresponding native libraries (.so files).

Beyond that, I'd still have to read more about the deployment process of native libraries for Android. How do you eventually build the APK file? The question may be naive, but ... is there any point in adding these natives in the JAR that is available in Maven central?

(In the initial PR for Android support, at #4 , there was some related discussion, but not so much regarding the deployment)

[aicodex]

You're very considerate.
Adding .so to a JAR in Maven central is really pointless.
Compiling an aar is worth considering.(aar is an Android library with so and java classes)
Another way to do this is just talk them to download the zip package with so in your website. They all know how to deal with it.
The #4 mentioned that you just need put them in lib/* folder. like lib/x86 lib/armabi just like my fork. https://github.com/aicodex/JOCL/tree/master/nativeLibraries android don't need linux or mac os .so or win dll.
And you need to update the LibUtils like #4 mentioned . you just need to put the so folder. The android jvm can auto load it. you just need to use the same so name like JOCL_2_0_0-android they can load the so in /lib/${my-phone-arch}/libJOCL_2_0_0-android.so

Infact when android studio compile a apk with a jar or arr library just like this:
——jar/arr——=====================>>>——apk——
—src ===========================>>>—classes.dex
——com.xx.xx __________________________________________...
—lib============================>>>—lib
——armabi===========================>>>——armabi
———libJOCL_2_0_0-android.so================>>>———libJOCL_2_0_0-android.so
——armabi-v7a========================>>>——armabi-v7a
———libJOCL_2_0_0-android.so================>>>———libJOCL_2_0_0-android.so
——arm64-v8a========================>>>——arm64-v8a
———libJOCL_2_0_0-android.so================>>>———libJOCL_2_0_0-android.so
——JOCL_2_0_0-windows-x86.dll==========>>>——JOCL_2_0_0-windows-x86.dll

when you install the apk. Android will select the folder that your phone supports.just like this:
——apk—— ==========================>>>>——Android:/data/apk/com.example——
—lib
——armabi
———libJOCL_2_0_0-android.so
——armabi-v7a=======if your cpu is 32-bit======>>>>——lib/arm
———libJOCL_2_0_0-android.so
——arm64-v8a=======if your cpu is 64-bit======>>>>——lib/arm64
———libJOCL_2_0_0-android.so
——JOCL_2_0_0-windows-x86.dll
And in android, every app havs it's env config. Then the lib/arm. or lib/arm64 will be configed to the app's javapath env. so you just need to use System.loadLibrary("libJOCL_2_0_0-android").it can auto find it.
I found the some times it will copy two folder. Perhaps a sequential selection of so files can support more platforms.

[gpu]

Apologies for being so hesitant. The point is: I cannot test this. And I'd really like to avoid breaking existing processes. The compilation of native libraries, and particularly loading them in Java, has some caveats.

(It would really be great if @phlip9 could say whether the compilation works for him with these changes. When it works for two different systems, it's likely to work for more)

In any case, I really appreciate your contribution and support.

Assuming that putting the .SOs into the jar does not make sense, offering the result as a downloadable .ZIP file on jocl.org would probably make most sense.

I'll add some comments in the pull request, though...

[gpu]

Hello @aicodex

I tried to extract the relevant parts of #16 and committed them in a branch at 14cc906

Using the libraries that you provided with the PR, I created a JAR. It contains the native libraries, in the sub-folders that you also used, and I have uploaded it to http://jocl.org/jocl-2.0.1-SNAPSHOT-2017-08-31.jar

It would be great if you could test this, or give any other feedback. Two points are particularly relevant for me now:

• Will the current JAR be usable in Android? Or should it rather be a ZIP-file? For example, a ZIP contains the pure Java JAR, and the native libraries, in the dedicated sub-folders? If so: What should be the names of these folders? I have read https://stackoverflow.com/a/27523384/3182664 , but now am not sure whether the name should be libs, jniLibs, jni or lib ...
• Does it make sense to include the non-Android-binaries in the same JAR at all? (I don't think so...)

If this works and makes sense, I'd add the JAR (or ZIP) as a dedicated "Android JOCL" JAR at http://www.jocl.org/downloads/downloads.html (with credits to you, of course)

[aicodex]

OK,I will test it and give you feedback. Recently, the Android developer have a new way to package the source with native library is to package it to arr(just a Android library project package, because many Android library is some UI implement, so they should package not only native library but also xml and permission configuration).
But I think maybe the old way: provide a jar without native library or just use the pc's JOCL jar provide them the addition zip with Android Sos is change less. Because only the new phone publish after 2014 can support OpenCL. Android developer also consider its compatibility. So maybe create a new branch is not valuable?
The folder name is config by gradle or maven. so if you provide the Sos, you don't need to consider the lib folder name, you just need to consider the Arch folder name. Because the IDE will package it to apk's "libs" folder (apk is just a zip package you can rename it to *.zip and unzip it).
I don't know how to test all OCL APIs, I will just run all your JOCL example without JOGL.