Add bluetooth scanning

[nullablepointer]

Feel free to review and make changes!

termux-api-package pull request: https://github.com/termux/termux-api-package/pull/187

[nullablepointer]

I think this is not quite the right API to expose. IIUC what you've got is:

• start - begin collecting discovered devices in the background
• info - return a time-ordered but untimestamped list of every device-sighting since start (ed: corrected this after the initial comment)
• stop - stop collecting devices and return that list one last time

Two things feel wrong about this to me:

1. This sorta kinda resembles how bluetooth discovery UIs work, but you're building a programmatic interface. You don't need to keep history inside this API because it's going to be consumed by code, not by human eyes that might look away for a second and miss something.
2. You don't have any last-seen tracking, which means that if I wait to scan for more than a handful of seconds, I have no way to distinguish between devices I just saw and devices I saw once, right after start, and never again.

I spent a day chewing on this and imo this should be:

• start - as above
• dump or poll - return devices seen since the last dump or poll (info isn't a good verb whether you change the semantics or not)
• stop - just stop scanning, no devices returned

What do you think?

This was my initial thought process, but i realized that force quitting the process would not stop discovery. I do not have time atm, but i would be happy if someone made it automatically discover and keep the process running (so that info would be removed, so would the list).

[tstein]

I don't follow. My suggestion was purely about the ergonomics and usefulness of the API; the fact that discovery would continue if you force-stopped the main termux process (I think that's what you meant) seems the same either way.

[nullablepointer]

If the api was written in java, this would not be the case. Currently its getting through 2 languages, so its pretty hard to manage. If the api used jni, you could share types and objects (but it would be harder for a normal user to implement). If we want to include more features, we would probably need an api rework.

[tstein]

Right, but that's not an option. I'm saying that I think you can and should make those changes within the constraints of a normal termux-api API, to produce a more useful and more comfortable shell interface.