Trying to revive 'ubtd' (Bluetooth file transfer)

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

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. Don't want to harass you of course, it's up to you to decide.

Yes, the licensing issue has been cleared up. Michael Zanetti agreed with me using the GPL v3.

What I'm working on right now is getting the code in a state where I could submit it on the OpenStore (with the understanding that it would need a full review as it still uses an unconfined profile). Of course, in the process, I will also push the code to a public Github repository.

Can you clarify what the Gitlab merge request you mentioned would be about? I'm afraid I missed a step here.

gpatel-fr

@PhAndersson

there is no MR yet, it's for this issue

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

there is no MR yet, it's for this issue

OK, understood -- I take your point and I'll try to publish ASAP.

PhAndersson

Further update: I successfully tested the SharePlugin part of the app while using the enforcing AppArmor profile, which is great news.

This means that only the main app (used for receiving files) will need an updated AA profile. But this will wait until after publication of the first version.

gpatel-fr

@PhAndersson

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.

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

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?

gpatel-fr

@PhAndersson

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.

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

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.sh is a wrapper around clickable that 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.

gpatel-fr

@PhAndersson

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...

gpatel-fr

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.