btleplug VS ndk

You're absolutely correct! I mention this elsewhere in the documentation even. Buttplug really is just a userland HID manager at its core. The only specialized part is the context of commands we send to devices.

The original plan (and it may still happen, who knows) was to figure out a way to chop off that top message layer and create a generalized system for doing exactly what you've said. That was going to be called 'deviceplug', and it's why btleplug is under the 'deviceplug' org on github (https://github.com/deviceplug/btleplug). I've just never gotten around to it because I'm not quite ready for the additional support burden yet.

All that said, Buttplug is also a haptics experimentation project aimed at finding out what it's like to create a way to communicate about a very specific type of touch via technology and programming. There are specific goals within the project related to that, but the amount of tech required to actually pull that off means I end up with what basically amounts of a fleet management framework. :)

In case someone is curious: https://github.com/deviceplug/btleplug/pull/279/files

Is something wrong with https://github.com/deviceplug/btleplug or you haven't found it? You could also use bindings to platform libraries like https://github.com/microsoft/windows-rs and https://github.com/rust-mobile/ndk if btleplug doesn't have something fundamental to you.

One of the worst/best parts of buttplug is that I ended up needed to maintain my own Bluetooth LE library: btleplug (https://github.com/deviceplug/btleplug).

Worst because working with bluetooth is always THE WORST, best because of the submissions and community that've grown around it.

There's 2 types of PRs to btleplug:

- People going "here's a PR but uh, why is the library named btleplWAIT WHAT"

- People going "here is a PR specifically to fix something in Buttplug thank you"

"In its dev branch"

I've always been annoyed at the cross-platform story for Bluetooth. GATT is one of my favorite protocols because it is so simple, but writing simple code against this simple protocol is _not_ portable:

iOS and macOS have CoreBluetooth, Linux has BlueZ, Windows has Windows.Devices.Bluetooth and Android has android.bluetooth.

I've seen a few projects trying to fix this, like https://github.com/deviceplug/btleplug, and I hope one of them becomes production ready.

But, that's an ongoing problem. In terms of "done", I think the next big milestone will be mobile app support. We work on mobile web browsers in a couple of different ways, but Buttplug still needs app support, both native and for things like cordova/react native/etc... The biggest issue there at the moment lies in our bluetooth library (btleplug, https://github.com/deviceplug/btleplug), because getting the FFI via JNI to android is going to suck (even though I can crib off Servo's WebBluetooth impl, which worked on Android).

You can already. The ndk allows any language to be compiled to android. For rust see

https://github.com/rust-mobile/ndk

Which has the tools to do this.

I found an official introduction to the topic: https://source.android.com/docs/setup/build/rust/building-rust-modules/overview I found these bindings and even tried to make the examples work without luck: https://github.com/rust-mobile/ndk There even exists an interface with the C++ library I am using: https://docs.rs/oboe/latest/oboe/

Is something wrong with https://github.com/deviceplug/btleplug or you haven't found it? You could also use bindings to platform libraries like https://github.com/microsoft/windows-rs and https://github.com/rust-mobile/ndk if btleplug doesn't have something fundamental to you.

There's cargo-apk which is godsent extension making the process of building an apk as easy as cargo apk build. Although I wasn't able to make it fully work on my native machine, so I used miniquad's docker image, installed cargo-apk, and then built.