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