Add Android Support

[qdot]

Same idea as blurmac. Fork bluedroid, bring in code, fit to whatever our API surface is.

[mvniekerk]

Hi - I see this sits on Jan 11. How can I help?

[kitlith]

may be worth looking into using https://github.com/jni-rs/jni-rs when pulling in blurdroid, it currently appears to use rust -(ffi)-> c -(jni)-> java wrapper -> android bluetooth. I'd think we'd be able to strip out the C layer, at least.

[gedgygedgy]

I intend to work on this, because I want it for one of my own projects.

I looked into blurdroid, and I see three problems with it:

1. As mentioned above, it has a C middleware layer which can and should be stripped out and replaced with pure Rust.
2. It is asynchronous in nature, due to Android's asynchronous Bluetooth API. This needs to be made synchronous.
3. And of course, it does not match the btleplug API whatsoever.

Changing these three things effectively amounts to a complete rewrite. Blurdroid will certainly serve as a useful reference, but I believe it will be easier to start from scratch.

[qdot]

@gedgygedgy You'll definitely want to work off the dev branch too, which has an API completely reworked for rust async. It's 100+ commits ahead of master, and we'll hopefully be merging it with master soon, so consider it the place to start.

[gedgygedgy]

The new async API definitely changes things, and will probably make it easier to port to Android.

One problem I see is that doing anything Java-related in Rust requires a JavaVM, which unfortunately can't be obtained from JNI_CreateJavaVM() or JNI_GetCreatedJavaVMs(). It can only be obtained by implementing JNI_OnLoad() in your library or as a parameter to a JNI function. This makes it impossible to implement Java support without either:

1. Adding parameters to Manager::new() or
2. Creating a global variable (ick!) which is initialized by JNI_OnLoad() (or some init function which gets called by another library), similar to how blurdroid does it.

Manager::new() is not currently bound by a trait, which makes it tempting to simply add a JavaVM argument to Manager::new(), but this would make things slightly more difficult for Android clients, which now have to conditionally (by #[cfg]) pass a JavaVM around in their Bluetooth code.

Using a global init approach limits the library to a single Java VM (which isn't a problem in Android, since Android only allows one VM per process anyway), requires the client to call the init function if it already implements JNI_OnLoad(), and makes Rust angry by creating global variables.

Neither option is very appealing. What are your thoughts? Any other ideas on how to make this work?

[gedgygedgy]

Personally, I would prefer to add a parameter to Manager::new(). The Manager will (hopefully) be created early on, at a high level in the program, where it will be easier to conditionally pass a JavaVM around, and there will likely only be one Manager.

[kitlith]

personally, I'm more inclined to go the route of the global variable than I am of adding an argument to the manager, just to reduce the amount of #[cfg]s necessary. Expose a function to set the JavaVM for the library, use a OnceCell or similar to store it, call it a day. I will note that said function does not need to be called in JNI_OnLoad (though it is convienent), just sometime before someone calls Manager::new().

it also means that you can have a library A, which uses btleplug and doesn't care about android at all, and application B that runs on android, which uses library A, and application B can just pass the JavaVM to btleplug, still without needing library A to care at all.

[gedgygedgy]

After seeing how easy OnceCell is to use (doesn't even require unsafe), I am now thoroughly convinced that a blteplug::platform::init() approach is the right way to go.

I've started working on the Android port. You can check out my progress here.

[gedgygedgy]

I've created a small crate, jni-utils-rs, to do some extra stuff that jni-rs doesn't do, specifically async and futures. I'm using this as the foundation of my Android port.

[gedgygedgy]

What is btleplug's expectation for attempting to run two async commands at the same time? For example, one thread calls Peripheral::connect(), and then another thread calls Peripheral::disconnect() before Peripheral::connect() is finished. Is btleplug supposed to handle this, or is the user just supposed to not do this? Android's Bluetooth system doesn't seem to handle simultaneous commands very well, so I'm wondering if I need to set up some sort of command queue.

Upon thinking about this some more, it doesn't seem very Rustacean to provide an API that can fail so easily. I will go forward with a command queue to make sure only one command gets executed at a time.

[qdot]

Upon thinking about this some more, it doesn't seem very Rustacean to provide an API that can fail so easily. I will go forward with a command queue to make sure only one command gets executed at a time.

Well if it makes you feel any better, I was gonna say command queue too. It's what I usually do in this case. :)

[gedgygedgy]

I have a working Peripheral::connect() and Peripheral::disconnect() implementation. It's a bit of a proof-of-concept and needs to be cleaned up with a proper command queue, but it works.

[qdot]

I have a working Peripheral::connect() and Peripheral::disconnect() implementation. It's a bit of a proof-of-concept and needs to be cleaned up with a proper command queue, but it works.

WOOOOOOOOOOOOOOOOOOOO 👍🏻 💯 🥇 🚀

[gedgygedgy]

I've added a command queue to ensure commands execute one at a time. Peripheral::discover_characteristics(), Peripheral::read(), and Peripheral::write() are all working. The rest of the functionality is on its way.