@domubpkm said:

@phandersson ok. I switched to dev channel and i tried to send a (big) file from my Volla 22 with UT to a Volla with volla OS with your last update : it works now. .

Excellent news -- thanks for the feedback.

But i found the transfer speed was very slow. Could it be improve or not ?

Could you be a bit more specific, please? From what I read online, typical Bluetooth transfer speeds are between 1 and 3 Mbps.

When I tested the app prior to releasing v0.1.1, I measured 1.3 Mbps when pushing a large file from my (Linux) laptop to the phone (Pixel 3a).

Do you get a comparable bandwidth, or something much lower? (to measure it, I simply time the transfer and divide it by the file size).

@domubpkm said:

@PhAndersson Can connect with bluetooth a Volla with Volla OS to a Volla 22 with UT noble.

There is currently a bug in Noble (up to 24.04-1.2) that prevents the OBEX daemon from starting.

The fix exists and is already merged. Here is the related MR: https://gitlab.com/ubports/development/core/ubuntu-touch-session/-/merge_requests/81. It is supposed to be part of the upcoming 24.04-1.3.

Based on earlier tests by @gpatel-fr, once this fix is available, 'ratatoskr' should work on Noble as well.

I need to amend the statement above. After further tests, the code that has been used to generate the packages is the correct one, so all the latest functionalities are present, and both sending and receiving files should work.

The only problem is that the wrong version string has been used when building.

Sure, Tweak Tool, of course -- sorry.

I just checked on my phone and it shows there, yes. Just look under the name 'Ratatoskr' (that's the actual name I gave the app -- "Bluetooth file transfer" is only a description).

It's the first UT app I built, so I'm not familiar yet with all the intricacies of the dev. workflow.

In any case, it seems there was a mixup, as the packages that were pushed on the server are v0.1.0, not v0.1.1. The "file sending" functionality may not be functional in that version (the receiving one should be).

I'll try to get this fixed tomorrow.

@domubpkm said:

@PhAndersson Should the app be shown in UT TT apps ? I don't see anything on my Volla 22.

I'm sorry, I guess I'm a bit slow tonight, but I'm not clear on what 'TT' means in this context. Can you clarify?

What should be the names of the cache config data directories ?

The app cache is in ~/.cache/ratatoskr.petroniusniger/. This is where incoming files are kept -- but there is no config data there (the app doesn't store any configuration data at this stage).

OK -- replying to my own post

To resolve the issue, I decided to revive the old 'ubtd' app. Its new incarnation has passed the code review and v0.1.1 is now available on the OpenStore.

You will find it under the name "Ratatoskr (Bluetooth file transfer)", in the "Utilities" category.

If you install it, may I suggest that you check the README here: https://github.com/petroniusniger/ratatoskr/tree/main for a brief description of how to use it most effectively?

Also, should you discover any bug, please report them here: https://github.com/petroniusniger/ratatoskr/issues

Final status update: the app has passed the code review and v0.1.1 is now available on the OpenStore.

You will find it under the name "Ratatoskr (Bluetooth file transfer)", in the "Utilities" category.

If you install it, may I suggest that you check the README here: https://github.com/petroniusniger/ratatoskr/tree/main for a brief description of how to use it most effectively?

Also, should you discover any bug, please report them here: https://github.com/petroniusniger/ratatoskr/issues

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:

• https://github.com/petroniusniger/ratatoskr/issues/12 (new one)
• https://github.com/petroniusniger/ratatoskr/issues/6 (known issue)

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):

@PhAndersson

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