Status update:
'ratatoskr' source code has just been reviewed by @bhdouglass (OpenStore team), and two issues have been identified that should be resolved before allowing publication of the .click packages:
I'll work on resolving those 2 issues and release a v0.1.1 of the code before re-submitting it for publication.
@projectmoon said in Hardware recommendation for Noble:
Volla Quintus has served me well so far. It's also one of the only devices that is officially commercially supported for UT. Volla has someone working on UT for their devices.
Many thanks -- I'll give it a look. I guess flashing my first 2 phones with fastboot and adb earned me a few nerd points, but I won't complain either if the next one comes pre-installed 
@MrT10001 said in Hardware recommendation for Noble:
The Google Pixel 3a is a good device, but unfortunately lacks the VoLTE support
Indeed -- the support for that device is excellent overall. I'm very happy with it. It's just a pity that the HW specs are a bit basic.
For me and this is what you will get as everyones experience varies the devices I recommend are OP5 and OP5T, Nord N100 and Nord N10 5G, Xiaomi Redmi Note 9 Pro and Xiaomi POCO X3 NFC...
OK, thanks -- I'll have a look at those.
Anything device that has worked with Focal should clean install to Noble with a few exceptions (OP6 and OP6T and Xiaomi Mi A2).
You surprise me -- I thought the Mi A2 was never ported to Focal. I have one, but it's still on Xenial.
Hello everyone,
I'm currently using Focal on a Google Pixel 3a as daily driver, and I would prefer to wait a bit before upgrading it to Noble. But I would also like to start porting an app I'm writing to the latest UT platform.
Could you please tell me which phone would provide the best user experience (considering a scenario where it would be imaged with Noble straight away, not upgraded from Focal, and use the latest available version, not /stable)?
Side question: do we still need to start from Android 9 before installing Noble?
Thanks in advance for any recommendation.
@paulcarroty said in Trying to revive 'ubtd' (Bluetooth file transfer):
@PhAndersson there's active OpenStore matrix room.
Many thanks -- I just joined it.
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
as they say in open source, 'unfortunately' the MR was backported to the 24.04-1.x too late to be included in the 24.04-1.2 version
. That means that your app will not work at all in this version unless some system fiddling is done by the user.
So this means waiting for 24.04-2/stable, I guess...
@arubislander said in Trying to revive 'ubtd' (Bluetooth file transfer):
@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.
Thanks for the tip -- I'll give it a look.
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.
@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.
@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 .click packages on the OpenStore.
All issues created in GitHub:
https://github.com/petroniusniger/ratatoskr/issues
Some of them will be documented further.
@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...
@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...
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):
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 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?
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 said in Trying to revive 'ubtd' (Bluetooth file transfer):
there is no MR yet, it's for this issue
OK, understood -- I take your point and I'll try to publish ASAP.
@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. 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.
Another quick update.
I'm really pleased to announce that I got the SharePlugin part of the app working as well. I successfully pushed a file from my Pixel 3a to my (Linux) laptop over BT, but even more importantly for me, I was able to push selected contacts to my car kit
The user interface is still too rough for the app to be published as is (at this stage, you have to select the target device based on its MAC address, which is far from convenient), but I'm working on it.