Add Java/Kotlin bindings

[kdewald]

Unfortunately, these are required for Android support.

[CraigHutchinson]

The majority should be possible using JNI calls but I would expect there could be some need for Java/Kotlin to handle callbacks.

As an example libusb has utilized JNI to access USB under NDK-only code on unrooted devices (#121).

Not sure if the Android BLE API is as easily adaptable to the limits of JNI. Past research made me doubt but I may be wrong.

[kdewald]

Hey @CraigHutchinson, thanks for the comments!

I've been digging a bit into this a few months ago. The challenge doesn't seem to be as hard on the JNI aside (aside from a few horrible compromises that need to be made due to the JVM not offering explicit destructors, but I got stuck in setting up the build system so that the resulting code can be packaged and consumed correctly across all OSes.

Feel free to check out this branch to see what I've done so far: https://github.com/OpenBluetoothToolbox/SimpleBLE/tree/feature/android

I am able to successfully build an Android app that invokes the correct CMake calls, but I want this to be a proper standalone library that can be pulled in from some artifact repository.

[Andrey1994]

In case if it helps I can share what I did for build system for android.

https://github.com/brainflow-dev/brainflow/blob/master/.github/workflows/run_android.yml#L54

I build using this workflow for all Android ABIs and store that as artifacts

[hellozyemlya]

Also, looks like android lacks of BLE headers in NDK... I can imagine what a horrible hacks it will to have round-trip from java->native->java->native->java code...

[CraigHutchinson]

@hellozyemlya NDK can call into the JNI so has access to the java library in a 'convoluted' manner. However using the JNI you cannot derive new class types from an interface (in the current JNI anyway) i.e. You need to implement the BLE class using Java/Kotlin and then this class can can be instantiated and used from JNI calls in NDK.
Not simple, but the libusb project has a pure-JNI implementation as the API for USB doesn't require inheritance. Would be an interesting/complex task to get BLE going but would be worth it.

Unfortunately I am leaving the job for which this work would have been relevant so no longer have this on my roadmap to look into any further :(

[hellozyemlya]

@CraigHutchinson not sure if having kotlin bindings to use simpleble in android will be beneficial, if you can just abstract ble usage in application level.

Only notable thing to have jni bindings of simpleble - build existing C/C++ code with simpleble for android applications. Desktop apps are super easy to use c variant of simplble, for example using jnr-ffi.

[Stephen-Hamilton-C]

This would be incredible if SimpleBLE could at least get Java bindings. Trying to do anything BLE on JVM is horribly documented. Kotlin/Native I think can use C libraries so that's covered at least. If Java bindings were made, Kotlin/JVM would be covered as well.

[retiutut]

+1 requesting this feature. Really enjoying working with this library so far. 👍

[kdewald]

@CraigHutchinson @Stephen-Hamilton-C @retiutut does any of you know Java/Kotlin/Android packaging well? If so, could you please reach out to have a conversation about how to make that work nicely in an automated way?

I have the JNI stuff pretty nailed down and shouldn't be hard to implement, but I'm struggling with how to automate and distribute the library once it's built.

[Andrey1994]

actually in terms of android support I am looking forward for C++ API on the NDK level and do not need a java package. Maybe its not the most common request but more likely there are other people who can find it useful.

For publishing java packages I can share how I did it in brainflow, the process of publishing to maven central is pretty complicated and there is a lot of bureaucracy. I ended up with publishing to Github Packages instead Maven central. But from automation point of view there is almost no differences between publishing to these two registries.

I believe there are github actions to simplify the process of publishing(https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven ) but I did it manually.

For github packages you need a file settings.xml https://github.com/brainflow-dev/brainflow/blob/master/java_package/brainflow/settings.xml and the command line to publish it is like here https://github.com/brainflow-dev/brainflow/blob/master/.github/workflows/deploy.yml#L199

But you also need some native libs inside your package and for android there should be in a very specific location, I am just asking users to copypaste them there and publishing archive with releases. Definitely not the best option but better than nothing I guess

[Stephen-Hamilton-C]

There is also jitpack.io which I've seen a number of JVM libs use. I couldn't offer much more info other than its existence as I haven't used it myself.

[CraigHutchinson]

@CraigHutchinson @Stephen-Hamilton-C @retiutut does any of you know Java/Kotlin/Android packaging well? If so, could you please reach out to have a conversation about how to make that work nicely in an automated way?

I have the JNI stuff pretty nailed down and shouldn't be hard to implement, but I'm struggling with how to automate and distribute the library once it's built.

Not sure if this is directly useful for what you want without lookin further but https://github.com/BareCpper/AndroidPackaging.cmake is my base framework for building NDK applications using CMake. There isn't a requirement to make it APK as output but this project only had a single production intent to do just that.

May come in useful as it instigates Gradle from cmake generated sources template. You may include java+Kotlin sources... But i never finished the add_sources cmake function which would have simplified all that etc.

[NCSwindell]

@kdewald just curious if you have made any more progress on Android support. I've pulled down the feature/android branch, have it compiling with my android app, and am starting with seeing if I can put in code to get the scan working. It is a big learning curve for me, so my progress will be slow. We use SimpleBLE already for the iOS version of the app, all our C++ code for calling into SimpleBLE for communications is already in place, so it is definitely preferred to use SimpleBLE for Android as well.

[kdewald]

Hey @NCSwindell, thanks for reaching out.

This effort is currently abandoned as there are significant hurdles that need to be solved to package this correctly to be consumed as a Java/Kotlin package. I don't expect to work on this any time soon unless this specific effort becomes sponsored or someone with knowledge in the packaging layer steps in to help.

[KlemenDEV]

Joining that this would be very useful for desktop too. There is currently no BLE desktop Java library to my knowledge (I stand corrected if that is not true) and having this library support Java would be really neat.

Desktop apps are super easy to use c variant of simplble, for example using jnr-ffi.

Are there any known implementations of this?

[CraigHutchinson]

@KlemenDEV I think I may be mixing up the OP op intent as I was refering to bindings for Android as there is no low-level native C BLE API to access to the BLE stack and this must be done via JNI and/or Java/Kotlin to provide SimpleBLE the necessary access to the hardware. Also reiterated here as the main issue: #121 (comment)

Afaik from your message wording you may be inferring the adding Java language bindings for SimpleBLE to be used in a Java desktop application? This couild be the intent of this ticket but SimpleBLE still neerds backend to work!

[KlemenDEV]

Sorry, I got confused a bit as I don't understand Android stack that much. Will do so.

[CraigHutchinson]

Sorry, I got confused a bit as I don't understand Android stack that much. Will do so.

I must be sorry too, I updated my response as realise the issue heading wasn't clear. I think @kdewald need to update the issue description to refer to Android as the op message stated "Unfortunately, these are required for Android support." while Java API bindings for SImpelBLE could themselves be of value for all existing supported platforms as you mention. Then again jnr-ffi is mentioned and this could just be somethign a documentation thing!
EDIT: Thanks for making the separate issue for the language bindings 👍