Trying to revive 'ubtd' (Bluetooth file transfer)
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
excellent !
For the record, I remember that you are using Focal on your phone. If you did not look at the last QA for Ubuntu Touch, there was a mention of the 'last' Focal OTA, meaning that 20.04 is on limited life support.Thanks for letting me know. I'll try to get myself a 3rd phone and flash it with Noble, so I can port the app to it while maintaining the original version for a little while.
Do you know what device offers the best user experience under Noble?
-
sorry I have only one phone so I can't give you any advice.
I think that Bluetooth support could matter for you.
However I have noticed that the recent kernel change for the Fairphone 5 (my phone) was entirely to fix Bluetooth support, although there was no notice of any problem with Bluetooth on the device page at ubports.com, neither can I remember having seen posts complaining about Bluetooth with the FP5 - so relying on Internet information to pick a phone can be tricky.
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
how about setting up a public directory of what you have (if you have cleared the license question) ? It'll allow me to test it under Noble and possibly send a MR to gitlab once I'm sure that it works.
Done. I've created the GitHub project, pushed my repo and tagged it v0.1.0. You can get the code here:
https://github.com/petroniusniger/ratatoskr
The README file contains instructions on how to build (
build.shis a wrapper aroundclickablethat I needed in order to get version strings based on git tags).I'll now start submitting the app on the OpenStore and create GitHub issues with the open items in my roadmap.
-
I could test it with my low cost Android phone. Magic ! I see that you even solved the addressing by Mac address since I could use the Android phone actual name. I'll admit that doing 3 quick file transfers I got 2 successes and 1 failure (that's what is reported by the Android phone) but I'm not even attempting to understand what happened when it did not work, the glass is more than half full that's all that counts, everything blends beautifully with the UT UX paradigm.
I was just flabbergasted that it worked with my 24.04-1.2RC2... until I remembered that I had done an overlay to start the obexd service.
Now I have removed the overlay, rebooting the phone to see what happens... what's this ? I have no keyboard to enter the unlock ! that's not so good ! oh well, connect with ssh, reenable the overlay, restart, no keyboard.
Reconnect with ssh, remove the bt plugin, restart the phone, no keyboard. Reconnect with ssh, uninstall the fscitx5 keyboard, restart the phone, no keyboard. Reconnect with ssh, take a look at the keyboard configuration, realize with horror that fscitx5 uninstalls very badly, hacks around savagely to restore the lomiri-keyboard, restart the phone -> pfff, I have the default lomiri keyboard back.Now back to the original test, reinstall the bt plugin, test with the overlay, works again. Disable the overlay (that is, having the obex service not functional), restart the phone: every transfer attempt I do ends in failure. That's expected in fact. Now for my first problem with the software itself: it is not reporting what's wrong. That's a common theme with Ubuntu touch (and well, most modern software): when things go swimmingly, all is good. When the going gets though, user experience goes pear shaped. In a word, good notifications are missing. I'm very interested in notifications in UT to be frank, given that the average UT software is not reporting problems any better than the Bt plugin.
Second problem: when I had made the obex service functional again, I (unwittingly) messed up the transfer from the other side of the exchange (the Android phone); instead of clicking the arrow to open the notification on the Android screen, I pressed it, that had the side effect of dismissing it. On the UT side, the exchange was not stopped but not dismissed either. I swiped the whole thing away and tried to repeat the operation. After I think 3 times, the exchange failed always, even if I did the right thing from the Android side. I rebooted the UT phone and things got back to successful transfers.
I have not attempted the transfer in the other direction since I don't know how to start it from Android
I don't want to give the impression that things are bad, just report what happened. The real news is that things look real good like I said at the beginning, however I need to do quite a few things:
- put together a MR on gitlab to solve the obex service start failure.
- investigate the keyboard crash. Maybe it was fscitx5 related and it was coincidental entirely. But it will have to be tested a bit.
- more long term: take a look at the code and see if it could be made more robust against user mistakes and system failures, report problems better.
As a final note, I'd say that maybe having the plugin named 'BT sharing' instead of 'BT plugin' could be clearer for users that have not followed things and read the README.md.
It's not because technically it's a plugin that users need to learn to speak and understand the UT lingo. Maybe it's just me of course.In the same vein, could the 'app plugin' be not present at all in the drawer? I don't see why the plugin has to appear in the drawer, especially while trying to open it ends in a error message saying that it's not appropriate to call it from here...
-
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.
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. 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.
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. Looking at it a bit more, playing a sound on the Android phone is done on the UT phone. If one don't want to turn the UT phone into a speaker, it's a bit disturbing. It's not a problem with the app itself it seems, as when pairing under UT there is no idea of well, rights, it's all or nothing. To compound the problem, the UT phone is turned into a speaker to the point that the hardware controls on the phone have no effect on the sound level - it's entirely controlled from the Android phone.
Edit: I tried to play a sound on the UT phone and it played on the UT phone, not the Android. So clearly it's technically possible to accept files without being a speaker, however it does not seem possible on Ubuntu Touch. A quick search of the issues does not bring anything related so either I'm mistaken or no one sees this as a problem.
-
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.
-
First of all, many thanks for your extensive tests -- your feedback is invaluable.
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
I could test it with my low cost Android phone. Magic ! I see that you even solved the addressing by Mac address since I could use the Android phone actual name. I'll admit that doing 3 quick file transfers I got 2 successes and 1 failure (that's what is reported by the Android phone) but I'm not even attempting to understand what happened when it did not work, the glass is more than half full that's all that counts, everything blends beautifully with the UT UX paradigm.
I was just flabbergasted that it worked with my 24.04-1.2RC2... until I remembered that I had done an overlay to start the obexd service.
Nonetheless, that's excellent news! It means that if the obexd issue can be solved at platform level, the app could be ported to 24.04 with minimum effort.
Now back to the original test, reinstall the bt plugin, test with the overlay, works again. Disable the overlay (that is, having the obex service not functional), restart the phone: every transfer attempt I do ends in failure. That's expected in fact. Now for my first problem with the software itself: it is not reporting what's wrong. That's a common theme with Ubuntu touch (and well, most modern software): when things go swimmingly, all is good. When the going gets though, user experience goes pear shaped. In a word, good notifications are missing. I'm very interested in notifications in UT to be frank, given that the average UT software is not reporting problems any better than the Bt plugin.
That's a fair comment. At this stage, if anything goes wrong, you'll have to dig through 'journal' to try and understand why, which is not for the faint-hearted.
Second problem: when I had made the obex service functional again, I (unwittingly) messed up the transfer from the other side of the exchange (the Android phone); instead of clicking the arrow to open the notification on the Android screen, I pressed it, that had the side effect of dismissing it. On the UT side, the exchange was not stopped but not dismissed either. I swiped the whole thing away and tried to repeat the operation. After I think 3 times, the exchange failed always, even if I did the right thing from the Android side. I rebooted the UT phone and things got back to successful transfers.
That's a good catch!
I don't want to give the impression that things are bad, just report what happened.
And I'm truly grateful for it
The real news is that things look real good like I said at the beginning, however I need to do quite a few things:
- put together a MR on gitlab to solve the obex service start failure.
That would be great indeed!
- investigate the keyboard crash. Maybe it was fscitx5 related and it was coincidental entirely. But it will have to be tested a bit.
I've never played with alternative keyboards on the phone. I doubt it could be related, but who knows...
- more long term: take a look at the code and see if it could be made more robust against user mistakes and system failures, report problems better.
Indeed.
As a final note, I'd say that maybe having the plugin named 'BT sharing' instead of 'BT plugin' could be clearer for users that have not followed things and read the README.md.
Sure, that's easily fixed
It's not because technically it's a plugin that users need to learn to speak and understand the UT lingo. Maybe it's just me of course.
In the same vein, could the 'app plugin' be not present at all in the drawer? I don't see why the plugin has to appear in the drawer, especially while trying to open it ends in a error message saying that it's not appropriate to call it from here...
That's already on my to-do list and the result of a conscious design choice. I wanted to provide the basic functionalities as fast as possible, just to bridge what I perceived to be a big gap in the current app offering, even if that meant a first version that would seem a bit clunky...
I took note of all the problems you reported and of your suggestions and I will create issues out of them on GitHub, along with the other open points on my to-do list. That will make them easier to follow.
-
@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