Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bluetooth passtrough? #155

Open
kleinermob opened this issue Oct 14, 2021 · 45 comments
Open

bluetooth passtrough? #155

kleinermob opened this issue Oct 14, 2021 · 45 comments

Comments

@kleinermob
Copy link

will this be added or not? or is it already?
@ghost
Copy link

ghost commented Dec 29, 2021

+1 Bluetooth passthrough would be awesome!

I have a wireless bluetooth spectrometer whose only two software choices are either a Windows software :( or an Android app. Together with Waydroid I could use it on my convertible laptop in classrooms.

@skeydan
Copy link

skeydan commented Jan 5, 2022

Yes please :-) This would be extremely useful :-)))

@electrikjesus
Copy link
Member

In our initial tests, doing this leaves Linux host with no access to the hardware. We need to find a way for us to share access to BT hardware

@skeydan
Copy link

skeydan commented Jan 6, 2022

@electrikjesus I see! Thanks for letting us know! And best of luck (egoistically :-)))

@frikisama
Copy link

@electrikjesus would this help? I don't really know how much Android deviates from a "standard" Linux distro, that is too low level for me.

https://medium.com/omi-uulm/how-to-run-containerized-bluetooth-applications-with-bluez-dced9ab767f6

Thanks a lot for all this work! :)

@cintema
Copy link

cintema commented Feb 10, 2022

I wonder if, as a workaround, it would be possible to utilize a (second) bluetooth dongle for bluetooth in waydroid exclusively, e.g. https://www.fivebelow.com/products/usb-c-bluetooth-adapter.
In a similar manner usb-passthrough is possible in some virtual machines.

@skeydan
Copy link

skeydan commented Apr 8, 2022

Hi, would it be possible to get an update on this? (How the chances are that it might get added.) Many thanks!!!

@u8l-git
Copy link

u8l-git commented May 17, 2022

Bluetooth passthrough would be pretty nice! Any update on this?

@logan001
Copy link

logan001 commented Aug 1, 2022

@electrikjesus i could use it even losing the bluetooth device from host machine while waydroid runs. i start waydroid service manually so i have no problem with that.

@Thesola10
Copy link

Thesola10 commented Sep 27, 2022 •
edited

A solution would be to implement a replacement (or overlay?) android.bluetooth and android.bluetooth.le that connects to a proxied D-Bus interface to Bluez, using something like Flatpak's xdg-dbus-proxy.

That would involve replacing a few of these classes with D-Bus stubs. Personally, I think we could leave out A2DP for now, it would conflict with the host's audio server anyway.

Also, I think it has been done before, but with NDK BlueZ on bare-metal.

@Thesola10
Copy link

Also also, a lot of the work connecting to BlueZ in Java has already been done in bluez-dbus

@westurner
Copy link

Also, I think it has been done before, but with NDK BlueZ on bare-metal

Are any of these kernel patches still necessary to run bluez-android (~2014?): http://bluez-android.github.io/#building-own-kernel

@Thesola10
Copy link

Thesola10 commented Jan 30, 2023 •
edited

@westurner doesn't look like it, they were patches back when Android's kernel was very bare-bones. Pretty much all Linux distros now have dynamic modules, Bluetooth and Ethernet bridging enabled as standard nowadays.

Pretty sure those patches refer to running Bluez on an ancient Android kernel in the first place anyway.

But using bluez-android directly would mean running Bluez within the Waydroid sandbox which is irrelevant to our application anyway. Doesn't look like bluez-android is using D-Bus at all anyway.

@westurner
Copy link

python-dbus-next
https://github.com/altdesktop/python-dbus-next :

  • Zero dependencies and pure Python 3.
  • Support for multiple IO backends including asyncio and the GLib main loop.
  • Nonblocking IO suitable for GUI development.

@ToxicFrog
Copy link

For me, I'd much rather have "bluetooth but the host system loses access to it" than "no bluetooth at all" -- the host system isn't actually using bluetooth for anything to begin with, so it's no loss, but I have a lot of uses for it in waydroid.

@PeterGamma
Copy link

Bluetooth for waydroid would be highly desirable.

@student-sx
Copy link

Did anybody find a workaround so far?

@piggz piggz mentioned this issue May 17, 2023
Closed
@Gife72
Copy link

Gife72 commented Jul 14, 2023

Any news? Please we need it

@westurner westurner mentioned this issue Jul 25, 2023
Closed
@promeneur
Copy link

promeneur commented Jul 26, 2023 •
edited

Hello

With QEMU I use udev rules to pass usb device.

I use a second bluetooth device for QEMU VM and a second webcam (an old one)

in /etc/udev/rules.d/
i create a file 50.qemu.rules

with the contents

#Logitech, Inc. C270 Webcam
SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0825", GROUP="kvm", MODE:="0666"

Broadcom Corp. BCM20702A0 Bluetooth 4.0

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0a5c", ATTRS{idProduct}=="21e8", GROUP="kvm", MODE:="0666"

then

i update the rules

sudo udevadm control --reload-rules
sudo udevadm trigger --attr-match=subsystem=usb

Perhaps we can adapt the rules to waydroid.

Perhaps we need to replace GROUP)="kvm" by GROUP="users" or something else.

@westurner
Copy link

westurner commented Jul 26, 2023 via email

@Quackdoc Quackdoc mentioned this issue Aug 4, 2023
Open
@Haidafraid
Copy link

Just thinking. In my very humble oppinion. A passthrough should be possible if waydroid being a container and therefore some sort of VM it could emulate the bluetooth hardware like it is done with the WiFi connection. Or am I wrong?

It would really be good to sync at least sometimes apps over bluetooth.
Please make this possible.
Cheers HF

@westurner
Copy link

westurner commented Aug 21, 2023 •
edited

/? linux bluetooth simulator emulator
https://www.google.com/search?q=linux+bluetooth+simulator+emulator :

bumble

Bumble is a full-featured Bluetooth stack written entirely in Python. It supports most of the common Bluetooth Low Energy (BLE) and Bluetooth Classic (BR/EDR) protocols and profiles, including GAP, L2CAP, ATT, GATT, SMP, SDP, RFCOMM, HFP, HID and A2DP. The stack can be used with physical radios via HCI over USB, UART, or the Linux VHCI, as well as virtual radios, including the virtual Bluetooth support of the Android emulator.

gabeldorsche // bluez

@firefoxlover
Copy link

the same goes for the Sennheiser app, bluetooth passthrough would be very useful to change configs or even download firmware updates. Smartwatch apps too, Gadgetbridge, so many things. Essential for linux phones and just enabling that would solve it a lot

@Alex-Bujorianu
Copy link

I have this problem too. I need it for Sphero Edu.

@Thesola10
Copy link

Thesola10 commented Oct 20, 2023 •
edited

gabeldorsche // bluez

Oh so Gabeldorsche does support vendor-HAL Bluetooth, this is awesome news! (although it does mean we will have to enable Gabeldorsche in system by default, or use it as an "experimental Bluetooth support" switch)

Basically we need to update vendor with a Gabeldorsche driver that communicates with host Bluez over D-Bus, and patches /dev/hidraw* devices through accordingly

@mysablehats
Copy link

mysablehats commented Nov 7, 2023 •
edited

from what I could understand from the Arch wiki, waydroid uses a linux container (lxc), so according to these guys:

https://forum.proxmox.com/threads/bluetooth-device-on-container.123772/

It should just work (? I mean, if it works with anbox, which is what I think is running inside the container, idk)

maybe add a line corresponding to your device here

https://github.com/waydroid/waydroid/blob/main/tools/actions/container_manager.py#L71

(in my pc it is here /usr/lib/waydroid/tools/actions/container_manager.py, use find -name container_manager.py to figure out where it is in yours)

Haven't tested it myself, seems like a time sink...

EDIT:

I think this container_manager is only called when you create the waydroid image or something, so changing things there did nothing.
With lsusb -tvv I found what is my bt device /dev entry

With a little more digging I figured out that I could share the device putting this line:

lxc.mount.entry = /dev/bus/usb/001/012 dev/bus/usb/001/001 none bind,optional,create=file

in /var/lib/waydroid/lxc/waydroid/config_nodes but it still didn't work. Maybe my permissions are wrong?

I did sudo waydroid shell and I found with an ls -la that pipe file was there (is it still a pipe? )

crw-rw-r-- 1 root root 189,  11 2023-11-08 12:00 /dev/bus/usb/001/001

I tried adding:

 lxc.cgroup.devices.allow = c 189:4 rwm

to /var/lib/waydroid/lxc/waydroid/config but it didn't do anything (actually I am lying, it made it c--------, so made it worse, oh, I checked it now and the numbers don't match. Am I crazy and imagined a 4 for minor here? In any case, if it does work this need to be automated so it is generated every time). I have no idea where waydroid keeps the actual permissions setting script.

something like:

echo "lxc.mount.entry = `lsusb -tvv | awk '/8087:0026/ { getline; print gensub(/.*)/, "\\2", "g", $2); exit; }'` ... (but reasonable)"

Checking logcat with waydroid shell I can see that Bluetooth Intent fails.
11-08 14:56:25.662 301 320 E BluetoothManagerService: Fail to bind to: Intent { act=android.bluetooth.IBluetooth }

Then checking pm list packages I see there is no package for android.bluetooth, so no way it can run even if the bindings are correct. Maybe worth checking out https://www.android-x86.org/ if you want bluetooth support.

Truly a time sink. If anyone figures this out let me know.

@Thesola10
Copy link

What we're discussing is allowing the Bluetooth device to be co-owned by the host and Waydroid guest. I don't believe amputating Bluetooth functionality from the host is part of Waydroid's design goals.

@chriswyatt
Copy link

Any workarounds in the meantime are appreciated. I rarely use Bluetooth devices on the host and would be happy to hand over the entire device to my Waydroid guest, temporarily.

@firefoxlover
Copy link

@Thesola10 No I dont think this is the idea. If its not possible to co-own bluetooth on two hosts, a switch could be implemented to do this on demand, and switch owners.

But as it looks, as Waydroid runs in a container, it should be able to use Bluetooth from the Container.

@ToxicFrog
Copy link

ToxicFrog commented Nov 19, 2023 •
edited

As noted earlier, for my part, the host doesn't use bluetooth at all, but it's absolutely mandatory on the guest for some of the stuff I want to use it for, so the guest stealing it from the host would be a-ok. If it's not possible for them to share, a --bluetooth-takeover option or something seems appropriate.

@westurner
Copy link

westurner commented Nov 19, 2023 via email

@IPlayZed
Copy link

IPlayZed commented Dec 19, 2023 •
edited

Waydroid should have access to bluetooth devices connected to the host machine mainly, not the BT hardware itself as it compromises the use of other BT devices on the host.
This could be done in a portals-like fashion, as we are using Wayland anyway.
This would allow normal users to connect to desired stuff, like smart watches.

If the system administrator decides, Waydroid should be able to own BT hardware.
In a more general sense, it should be made easier to add hardware to the container, especially if it is USB, like a BT dongle.

@luc-spec
Copy link

In a more general sense, it should be made easier to add hardware to the container, especially if it is USB, like a BT dongle.

Couldn't agree more with @IPlayZed. I have a cheap WiFi + Bluetooth dongle on hand, if it were easy to pass in that one USB device I would have all of the wireless capability I'm looking for in Waydroid for with none of the (valid) ownership issues mentioned above.

@westurner
Copy link

westurner commented Jan 20, 2024 via email •
edited

@toni20k5267
Copy link

any news..?

@IPlayZed
Copy link

any news..?

I am sure that if progress is made you will se it in the thread, polluting it is useless. You can also help out yourself either by commenting ideas or providing changes.

@wilfridd
Copy link

wilfridd commented Feb 2, 2024 •
edited

I read the whole thread and it's rather difficult for me to guess the outcome....and sorry if the following is non sense 😊...
IMHO, the host OS should remain the "master" that controls the BT devices, I mean like scanning, pairing, connecting/disconnecting and forgetting them.
Then, a connected and eligible BT device would have an option that makes it "avalaible“ to Waydroid (container or VM) and therefore unavailable / greyed out for the host.
In Waydroid the device would be listed in BT and available to any relevant app.
Is that scenario realistic and feasible?
BR,
W.

@IPlayZed
Copy link

IPlayZed commented Feb 4, 2024

What you are referring to is a portals-like solution. In that scenario, the container does not get full control over the given hardware, but represents itself as a virtual device. Waydroid is LXC based, I am not sure how this would work, LXC's capabilities would determine this.
For a Bluetooth device the connection is still to your PC. LXC could handle in theory sending and receiving data to the container.

The other option is passthrough where a given hardware entity responsible for Bluetooth is assigned to the container (similar to GPU passthrough), this the container has full control of the hardware. This might be required for Bluetooth or similar hardware to work correctly in the container.

In my opinion the issue is not only Bluetooth but a lack of universal hardware abstraction between the container and the host system. Not just Bluetooth, but webcams, FIDO keys, etc. whatever you can imagine. As the underlying stacks might not support it, this might be a significantly harder challenge then it seems like. I think an issue should be created and possibilities currently available regarding LXC's capabilities should be mapped out as a very first step.

@PeterGamma
Copy link

PeterGamma commented Feb 4, 2024 •
edited

As someone who usually does not code, I am very interested in a solution and I highly apppreciate every contribution to resolve this issue. If waydroid Bluetooth path through works, I could get my Pinephone from the the screed and use it with Waydroid, Softmaker Office and a Bluetooth keyboard. Since LibreOffice on the Pinephone was a very negative experience for someone like me who usually does not code:

https://forum.pine64.org/showthread.php?tid=16614

Thank you all for being active resolving this isse, I am very interested in a solution. The Pinephone can also be used with the non Bluetooth Pinephone keyboard, but Waydroid Bluetooth pass through makes also Ubports phones again interesting for us personally.

@westurner
Copy link

westurner commented Feb 4, 2024 via email

@westurner
Copy link

westurner commented Feb 4, 2024 via email

@wilfridd
Copy link

wilfridd commented Feb 4, 2024

What you are referring to is a portals-like solution. In that scenario, the container does not get full control over the given hardware, but represents itself as a virtual device. Waydroid is LXC based, I am not sure how this would work, LXC's capabilities would determine this. For a Bluetooth device the connection is still to your PC. LXC could handle in theory sending and receiving data to the container.

The other option is passthrough where a given hardware entity responsible for Bluetooth is assigned to the container (similar to GPU passthrough), this the container has full control of the hardware. This might be required for Bluetooth or similar hardware to work correctly in the container.

In my opinion the issue is not only Bluetooth but a lack of universal hardware abstraction between the container and the host system. Not just Bluetooth, but webcams, FIDO keys, etc. whatever you can imagine. As the underlying stacks might not support it, this might be a significantly harder challenge then it seems like. I think an issue should be created and possibilities currently available regarding LXC's capabilities should be mapped out as a very first step.

Thank you for your reply!
Biometric hardware would also be a candidate...

@wilfridd
Copy link

wilfridd commented Feb 4, 2024

Thank

Thank you very much for your detailed reply. Would this apply to both portals-like and passthru scenario or passthru only?

@renhiyama
Copy link

from what I could understand from the Arch wiki, waydroid uses a linux container (lxc), so according to these guys:

https://forum.proxmox.com/threads/bluetooth-device-on-container.123772/

It should just work (? I mean, if it works with anbox, which is what I think is running inside the container, idk)

maybe add a line corresponding to your device here

https://github.com/waydroid/waydroid/blob/main/tools/actions/container_manager.py#L71

(in my pc it is here /usr/lib/waydroid/tools/actions/container_manager.py, use find -name container_manager.py to figure out where it is in yours)

Haven't tested it myself, seems like a time sink...

EDIT:

I think this container_manager is only called when you create the waydroid image or something, so changing things there did nothing. With lsusb -tvv I found what is my bt device /dev entry

With a little more digging I figured out that I could share the device putting this line:

lxc.mount.entry = /dev/bus/usb/001/012 dev/bus/usb/001/001 none bind,optional,create=file

in /var/lib/waydroid/lxc/waydroid/config_nodes but it still didn't work. Maybe my permissions are wrong?

I did sudo waydroid shell and I found with an ls -la that pipe file was there (is it still a pipe? )

crw-rw-r-- 1 root root 189,  11 2023-11-08 12:00 /dev/bus/usb/001/001

I tried adding:

 lxc.cgroup.devices.allow = c 189:4 rwm

to /var/lib/waydroid/lxc/waydroid/config but it didn't do anything (actually I am lying, it made it c--------, so made it worse, oh, I checked it now and the numbers don't match. Am I crazy and imagined a 4 for minor here? In any case, if it does work this need to be automated so it is generated every time). I have no idea where waydroid keeps the actual permissions setting script.

something like:

echo "lxc.mount.entry = `lsusb -tvv | awk '/8087:0026/ { getline; print gensub(/.*)/, "\\2", "g", $2); exit; }'` ... (but reasonable)"

Checking logcat with waydroid shell I can see that Bluetooth Intent fails. 11-08 14:56:25.662 301 320 E BluetoothManagerService: Fail to bind to: Intent { act=android.bluetooth.IBluetooth }

Then checking pm list packages I see there is no package for android.bluetooth, so no way it can run even if the bindings are correct. Maybe worth checking out https://www.android-x86.org/ if you want bluetooth support.

Truly a time sink. If anyone figures this out let me know.

Is it not possible for waydroid devs to add this package? Looks like it's 90% there - we just need to add in the "drivers" or the package on the Android side and it should have been working then?

Most of the users here are happy to transfer the whole control to waydroid, if that means waydroid can use Bluetooth perfectly.

@pfcdx pfcdx mentioned this issue Mar 5, 2024
Open
@pfcdx
Copy link

pfcdx commented Mar 5, 2024

As a "temporary" solution (like @ToxicFrog mentioned), I think it is important to pass main BT device to Waydroid.
But as a permanent solution, it is worth finding solutions around co-ownership of the main BT device. This thread should live.

We also can design it to use multiple interfaces (if exists), so that host still can use BT. (And container will, too)

First, check all BT devices currently connected to host. If multiple, (hci0, hci1, hci2...) check which one of these being actively used on host, and pass the "inactive" one.
If not multiple, then we might consider adding optional arguments for further configuration. (Such as deciding whether or not to sacrifice BT on the host)

Diagram below.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests