Trying to revive 'ubtd' (Bluetooth file transfer)
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
today I searched Internet on how to transfer a file from Android, succeeded to send a photo to my UT phone using Bluetooth, it works.
Great news! I don't have an Android phone, so I couldn't test that.
Notification is less clear than with Android, there is only a sound, no visual prompt, and it's necessary to open the application, see the prompt in the app, download the file to a folder, then it's finally possible to display it.
Yes, the "recommended workflow" is to start the app on the UT phone before pushing the file from the other device. I guess one way around that would be to allow OBEX to start the app when an incoming transfer is detected. This may not be trivial...
On the whole the receiving file UX is behind what Android (14 in this case) does and not as simple as transmitting files from UT toward another device.
I can't say I'm surprised by that assessment
While doing some stuff on the Android phone, I noticed that there was some sound on the UT phone, like if the 'keys' entered on the Android unlock screen had a sound echo on the other phone.
Yes, I noticed the same thing -- I don't believe it has anything to do with 'ratatoskr' as such. As soon as I connect my phone to my Linux laptop, the laptop becomes the speaker for the phone (which is very annoying when someone tries to call you). When you pair two phones together, I don't know how they decide which one will play speaker...
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
Yes it should be possible to stop the phone to being a speaker while being able to get files; I used this link, that is, used an overlay to restart the bluetooth daemin with the -C flag, used sdptool to delete all records relevants, restarted the bluetooth service, paired again the two phones, and then the Android phone could push a file to the UT one without the UT phone blaring music when the Android phone was playing something.
In fact I probably deleted more than was necessary since I did not realize that it was necessary to restart the bluetooth service after using sdptool - probably only audio sink was necessary.
I'm not familiar yet with the kind of "records" you deleted through
sdptool-- just keep in mind that in the case of a car kit, you want it to play speaker and accept files at the same time... -
All issues created in GitHub:
https://github.com/petroniusniger/ratatoskr/issues
Some of them will be documented further.
-
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
When you pair two phones together, I don't know how they decide which one will play speaker...
in the case of my test setup, it seems that Android default setup denies the speaker role for the phone.
-
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
put together a MR on gitlab to solve the obex service start failure.
not the most impressive change
-
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
All issues created in GitHub:
note that the idea of using BT sharing instead of BT plugin is a suggestion, I think (personal opinion) it's better than 'BT plugin', but it's not necessary the best idea.
Also reading them reminds me that I could take a look at the confined problem. This said, it seems that the mere fact of using 'bluetooth' makes this application something to be vetted, even if it's confined.
I don't know why, given that unrestricted applications can access Internet and (I think) the local network, it seems to me to be a risk even greater than bluetooth -
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
note that the idea of using BT sharing instead of BT plugin is a suggestion, I think (personal opinion) it's better than 'BT plugin', but it's not necessary the best idea.
Understood -- I created the issue to make sure it doesn't slip my mind. If better suggestions are offered, they are welcome!
Also reading them reminds me that I could take a look at the confined problem. This said, it seems that the mere fact of using 'bluetooth' makes this application something to be vetted, even if it's confined.
Correct.
I don't know why, given that unrestricted applications can access Internet and (I think) the local network, it seems to me to be a risk even greater than bluetooth
In theory, unconfined applications are simply forbidden, as they could do almost anything (that the user they run as could do). I'll try to contact the review team on Telegram to get the review process started. Without that, I can't distribute the
.clickpackages on the OpenStore. -
Err, I wanted to wrote 'restricted applications can access Internet'. But it don't matter much.
Anyway, I tried to regenerate the click without the unconfined template. Now, the confined app can send files to the Android phone without problem at all. It's in the other direction that I get an authorization error:
févr. 19 10:28:19 ubuntu-phablet obexd[3879]: Agent replied with an error: org.freedesktop.DBus.Error.AccessDenied, An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.0" (uid=32011 pid=3879 comm="/usr/libexec/bluetooth/obexd -P ftp,irmc,mas,pcsui" label="unconfined") interface="org.bluez.obex.Agent1" member="AuthorizePush" error name="(unset)" requested_reply="0" destination=":1.116" (uid=32011 pid=7190 comm="ratatoskr" label="ratatoskr.petroniusniger_ratatoskr_0.1.0 (enforce)")Now I don't think anymore that it's a matter of setting the system to grant the authorization. You see, in the other direction on the Android phone I get a prompt to authorize the transfer. The UT phone can't simply push files to the Android phone without any user interaction.
And I think that this should be the fix: that somehow the UT user (phablet) get a prompt to grant the other system the (temporary) right to write the file to the UT destination.
Granted, I don't have currently the slightest idea on how to proceed from that -
The MR got merged by the way. Now it's in 24.04-2, not in the stable version.
I could ask in the appropriate thread to sneak this change in the 24.04-1.2RC3 if there is any (don't seem likely). Or maybe you could ask yourself since it's your app ?
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
Anyway, I tried to regenerate the click without the unconfined template. Now, the confined app can send files to the Android phone without problem at all. It's in the other direction that I get an authorization error:
Yes, I'm aware of this -- I already reported this higher up in this thread. The SharePlugin works fine with a confined AppArmor profile. It's only the main app that needs wider rights to interact with D-Bus / OBEX.
Now I don't think anymore that it's a matter of setting the system to grant the authorization. You see, in the other direction on the Android phone I get a prompt to authorize the transfer. The UT phone can't simply push files to the Android phone without any user interaction.
And I think that this should be the fix: that somehow the UT user (phablet) get a prompt to grant the other system the (temporary) right to write the file to the UT destination.Having a prompt for the user to accept the incoming transfer is indeed needed (and already tracked through issue #6), but I don't see this as related to the fact that a confined AA profile prevents the app from issuing the "AuthorizePush" message.
This clearly needs further investigation.
-
I've hit a snag. I'm supposed to contact the review team on Telegram to try and get my app approved for publication on the OpenStore, but it seems I can't create a Telegram account through the UT Teleports app -- it says the official Android or iOS app is required to do this, which I don't have access to.
I'll try to contact 'bhdouglass' via the forum instead.
-
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
it says the official Android or iOS app is required to do this, which I don't have access to
I have heard Telegram works on Waydroid, fwiw.
