I just went through 'journal' events (phone is now on 24.04-2.0 beta/RC) and found the following errors/warnings related to bluetooth:

Jun 23 23:29:47 ubuntu-phablet bluebinder_post.sh[2815]: Failed to get bluetooth address!

Jun 23 23:29:47 ubuntu-phablet bluetoothd[2861]: src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv Monitors: Unknown Command (0x01)
[...]
Jun 23 23:29:50 ubuntu-phablet systemd[2767]: bluez-mpris-proxy.service - BlueZ MPRIS proxy was skipped because of an unmet condition check (ConditionPathExists=!/usr/lib/systemd/user/mpris-proxy.service).

It's unclear to me whether any of those can explain the BT connection issue with the laptop, but here they are.

PhAndersson said:

I can also confirm that the RTC issue is still present on the Quintus. Just created the following issue about it: [Bug] Volla Quintus: RTC problem: correct time/date not preserved across power cycles.

That particular problem is fixed by disabling the Timekeeper service, useless on non-Qualcomm devices. Kudos to @gpatel-fr for the suggestion.

Yes! I confirm that disabling the Timekeeper service resolves the issue. The clock on the phone was still correct this morning after turning it on in "offline" mode.

Which also confirms that RTC is indeed supported natively on the Quintus.

To make double-sure, I'll let the phone NTP-synch on the WiFi at home this evening, then power it off for the night, and confirm tomorrow that its time is still "believable" after powering it up while offline.

@gpatel-fr said:

@PhAndersson

Maybe you could try to disable the Timekeeper service ?

I think you nailed it! Congrats!

After having disabled and stopped the service, I powered off the phone for a couple of hours, and when I restarted it, the clock was at the expected value (i.e. 2 hours later).

In the logs, I have the following:

Jun 05 17:36:39 ubuntu-phablet systemd[1]: Starting timekeeper.service - Timekeeper is a utility to keep/restore RTC offset for Qualcomm devices...
Jun 23 23:29:43 ubuntu-phablet systemd[1]: Finished timekeeper.service - Timekeeper is a utility to keep/restore RTC offset for Qualcomm devices.
Jun 23 23:29:43 ubuntu-phablet systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...

Jun 23 23:29:43 ubuntu-phablet systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.

As you can see, the "clock time unset or jumped backwards" message no longer appears, and the clock value only jumps once.

I'll update the Gitlab issue accordingly. I guess the Timekeeper service should only be enabled on devices that use the Qualcomm chipset, not in all cases.

Still no feedback from Volla. Created the following issue about it: [Bug] Volla Quintus: RTC problem: correct time/date not preserved across power cycles.

I can also confirm that the RTC issue is still present on the Quintus. Just created the following issue about it: [Bug] Volla Quintus: RTC problem: correct time/date not preserved across power cycles.

Bluetooth on the Quintus is still problematic as far as connecting to a laptop is concerned. The behaviour is still the same as the one described here: Noble bluetooth issues.

First feedback regarding Morph:

• general web surfing works OK (news sites, etc.)
• searching through Google works OK
• creating bookmarks works OK
• viewing the bookmarks: OK
• opening link in new tab: OK
• showing open tabs and closing some of them: OK

I also tried accessing a personal web application on my local net that uses Apache Basic Authentication method:

• Morph shows the login dialog, but it disappears as soon as you tap the username field
• navigating to the password field is not obvious
• once authentication is complete, the web app interface displays, but only part of it (disclaimer: its home page uses frames and the app was never designed to be accessed from a mobile)
• also, it seems it re-prompts for credentials in order to display the 2nd frame, instead of re-using the already provided ones

Something else I know was problematic with Morph on Focal was handling captive portals for WiFi authentication (a rather typical setup in hotels these days). This I couldn't test with 24.04-2.0 beta.

@gpatel-fr said:

@PhAndersson

then run the following command in Terminal app or via ADB/SSH:

Of course -- right under my nose. Sorry for the silly question.

Running 24.04-2.0 beta now.

Thanks much.

Just tried to upgrade the Quintus to 24.04-2.0. As recommended, I switched to the 'release candidate' channel and checked for updates. It downloaded an image identified as "version 15", which I installed. The robot character announced the install and the phone rebooted without issue, but Settings still shows it as 24.04-1.3, still on the RC channel (24.04-1.x/arm64/android9plus/rc), but with no further update waiting.

Have I missed anything?

@rduivenvoorde said:

Non related to this: should a phone work in a car using Bluetooth? It see it connects as a headset, so I can talk/hear. But I does not present a phone or contacts to the car?

To push your contact to the car kit, you can try using 'Ratatoskr' (https://next.open-store.io/app/ratatoskr.petroniusniger/). I haven't tested it on Noble yet, but I've already received positive reports from other users.

@messayisto said:

@phandersson May I ask if Morph is/was working for you on the Volla Quintus in 24.02-2.x?

I've not tried 24.04-2.x yet, but I can do so and report back.

Regarding Morph in particular, what kind of test are you interested in?

@gpatel-fr said:

@PhAndersson said:

(Volla Quintus upgraded to 24.04-1.3 from 20.04/OTA-12). obexd is not started by default,

that's strange.

What's the output of

systemctl --user cat obex

# /usr/lib/systemd/user/obex.service
[Unit]
Description=Bluetooth OBEX service

[Service]
Type=dbus
BusName=org.bluez.obex
ExecStart=/usr/libexec/bluetooth/obexd

[Install]
Alias=dbus-org.bluez.obex.service

# /usr/lib/systemd/user/obex.service.d/ubuntu-touch-session.conf
[Service]
ExecStart=
ExecStart=/usr/libexec/bluetooth/obexd -P ftp,irmc,mas,pcsuite -r $HOME

and

systemctl --user status obex

○ obex.service - Bluetooth OBEX service
     Loaded: loaded (/usr/lib/systemd/user/obex.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/obex.service.d
             └─ubuntu-touch-session.conf
     Active: inactive (dead)

I also checked 'journal' for any OBEX-related message, but there aren't any.

@gpatel-fr said:

@PhAndersson

I have just switched my phone back to 24.04-1.3 and obex is definitely started automatically.

Not in my case (Volla Quintus upgraded to 24.04-1.3 from 20.04/OTA-12). obexd is not started by default, but Ratatoskr is still able to start it transparently, so the end result is the same.

But the Quintus is currently unable to successfully connect over BT to my laptop (or another UT phone, for that matter) -- see Noble bluetooth issues -- so I'm a bit stuck in my plans to validate Ratatoskr on Noble at the moment.

@lduboeuf said:

FYI, on 24.04.2 and 26.04 obexd is now auto started

That's good to know -- thanks!

@domubpkm said:

Make Ratatoskr recognize various extensions?

I just wanted to give a quick feedback on this request. I initially thought it would be a simple matter of registering the BT SharePlugin for all file types. It turns out it's not as easy as that: as currently written, the ContentHub component of UT doesn't allow that (although it allows it for "destinations", e.g. when using FileManager to "download" a file). To make a long story short, if I register the BT SharePlugin for all file types, it no longer appears for any file type.

I tried another approach, which was to report unknown file types as Documents. This sort of works, but it has two shortcomings:

• it only works from inside Ratatoskr, i.e. you could re-share arbitrary files that are already sitting in the app cache, but you could still not use FileManager to share them directly.
• now, when sharing a raw binary file from Ratatoskr, the "share with" dialog also offers unsuitable apps like the editor.

Considering this, I'm rather reluctant to implement this "half-baked" workaround. There is already an enhancement request on the ContentHub's Gitlab to "cover all file types for the Share functionality", but it's open since 2021 and doesn't seem to be getting much traction.

The behaviour of the Quintus seems related to this Gitlab issue:

Bluetooth sometimes in a state where not all paired devices are listed and can be connected

@musicologist I also noticed this issue (24.04-1.3). It doesn't occur every time (AFAIK) and in my case it can't be linked to turning mobile data on and off, as I've not used that feature yet on the Quintus.

When I noticed it, turning WiFi off and then back on was enough to make the SSIDs visible, though.

@gpatel-fr said:
I don't know what this could mean for Volla phones.

Neither do I -- I just created a support ticket with them that includes all the troubleshooting info I have. We'll see...