I upgraded my Xperia X to the latest RC 2024-W30/2 on August 17, and since then, the GPS is no longer getting a fix (even waiting for hours). Previously I was running RC 2024-W03, and GPS worked fine (I used it on August 13).
I wish to reinstall that previous version, but I have not found detailed steps explaining how to do that. I guess I should run

sudo system-image-cli ...

in an adb shell but I don't know how to specify the image I want. Does anyone has experience doing such downgrade?

@TakoR see a fix in the Xperia X sub-forum

@los-tioz said in Sony Xperia X loses Wifi Connection:

Has anyone updated Ubuntu Touch from version 16.04 to 20.04? Is the problem with the Wlan also present there?

Wifi reconnects much more reliably in 20.04.

@TakoR I only recently made the move to focal (RC 2024-W03) and saw the same problem of hotspot only working with no password.
Some research revealed that Volla devices also had a similar problem that has been solved by adding a file in Networkmanager configuration.

The same fix (detailed below) works also for the Xperia X. You will need to reapply it at each upgrade of the OS until it is merged in the device tree, if ever.

1-From a computer open a terminal session on your phone using either "adb shell" or ssh. Alternatively you can do it in terminal app on the phone itself, but it is very cumbersome.

2-make the image writable (until reboot) :

sudo mount -o remount,rw /

3-create the new file with appropriate content:

cat << EOF > /etc/NetworkManager/conf.d/fix-ap-with-password.conf
[main]
wifi-wpa-psk-pmf-no-optional-ap=yes
EOF

4-reboot the phone

5- my (linux) laptop could still not pair with the hotspot at that point. So I deleted the failed wifi hotspot config on the laptop and also edited the hoptspot config on the phone, changing the password and rebooted the phone again. After that, the laptop could connect the hotspot with password. I guess that not all of these last steps are needed.

Besides that issue and other minor quirks, I am very pleased with the OS upgrade. I just changed the channel, and upgraded as I had done before for the xenial upgrade. After that, I upgraded all apps. The new version has about a doubled battery life (for my rather lite use case, at least) compared to xenial and it solved the bug which made the camera app record half-green pictures about 1/3 of the time.

@los-tioz

I have an F5122 and in my case, the loss of Wifi connectivity has no definite pattern that I can see: Sometimes it would reconnect when getting back in range and sometimes not, apparently not dependent on the duration I was connected or out of range. When wifi does not reconnect within seconds, rebooting is the only way to fix it (and it works 99% of time).

Much less often (every couple of months, perhaps), I experience a loss of cell connectivity : the phone would suddenly declare it has no sim card, requiring a reboot to recover. Although infrequent, this later issue can indeed lead to missed calls, as it is entirely up to you to realize you are out of reach (in my case it can last hours...). It's definitely not an electrical problem but really a software problem which was already present when I was running SailfishOS on that phone and that is linked to my carrier using a form of "roaming" with another carrier where it lacks covering. Besides this rare issue, calling and receiving works fine for me and those who call me.

However, unlike in you report, my connectivity issues do not prevent launching the applications I use (camera, browser, email...). But of course, apps needing connectivity do not function properly. For me, commands entered in the terminal perform as expected.

Finally, I'm glad you report here the rebooting issue because I have had this issue too for a few months, after an update (on the candidate channel). When asking for a shutdown or a reboot (most of the time for restoring wifi connectivity) the screen goes black and the phone freezes in that state (power button is inactive unless volume up id pressed simultaneously). However, if you wait long enough (7-8 min?) the phone eventually reboots. I guess some process does not honour the termination request and the kernel waits a long time before forcefully terminating it.

Hey thanks @keneda, problem solved! I wish that piece of information were more obvious...

I have downloaded the latest click package, but struggled a bit finding how one is supposed to manually install such a click package. I did

pkcon install-local --allow-untrusted pantalaimon.thrrgilag_0.5.0_arm64.click

Then I could open launch the app, configure it, start the service. All seemed fine. However, Fluffychat does not connect through pantalaimon (" no connection "). And Fluffychat can connect directly to my homeserver.

Looking in the logs, it seems pantalaimon has a problem

Traceback (most recent call last):
  File "peewee.py", line 3035, in connect
  File "peewee.py", line 3371, in _connect
sqlite3.OperationalError: unable to open database file

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pantalaimon", line 10, in <module>
  File "click/core.py", line 829, in __call__
 [...]
  File "peewee.py", line 3371, in _connect
peewee.OperationalError: unable to open database file
[11864] Failed to execute script pantalaimon

I suspect the way I installed the app might not give it the proper rights to operate correctly. If so can anyone tell me how one is supposed to properly install a click package manually? Otherwise, any idea how I can debug the issue?

Is it understood why HDR photo mode is gone in this new camera app? It was a very nice feature and it's sad to have to trade it off for video recording. Any hope to get it back?

@herr-b In Pure Maps you can choose among many map backgrounds, including OpenTopoMap that has contour lines, hill shadings and pathes. OpenCycleMap is pretty good too.

For offline mode, Pure Maps queries data (maps, names, addresses...) on the phone from OSM Scout Server (instead of from network servers), assuming the corresponding data was previously download on the phone. OSM Scout Server presently serves only standard OSM maps but serving other, more detailed maps is being investigated and may not be too far away from becoming a reality.

@AppLee said in Puremaps offline and OSM Scout server:

BTW switching apps is not safe while driving, but neither is looking for a destination. You should stop to start a new route.

Pure Maps routing can speak out vocal instructions so you don't have to look at the phone. And when you get off the route, it it queries the router for a new route without having to touch the phone. No usability or security issues there. I have been using it in SFOS since Pure Maps existed and it works extremely well, on par with proprietary softwares doing this in Android. The only thing missing is real-time traffic.

No background activity is a key to longer battery life and is also part of the UT experience.

However great "features" may confinement and background suspension be in theory, as long as they prevent doing what people expect from a phone nowadays (including routing and tracking), I don't think we will be able to convince ordinary folks to switch to UBports to get that user experience. Other phone OSes (SFOS, PureOS) manage these things differently and transparently for the user, and I think UBports should aim to be at least on par with these in terms of real-life user experience. I acknowledge it's probably non trivial and requiring a lot of work, but I would set it a high priority.

Regarding suspension being good for battery life, I can testify that when my phone ran SFOS (where backgrounded apps are not suspended) I had a noticeably longer battery life than now with UBports, so there is no hard evidence that backgrounded apps (when properly coded) are so detrimental. When I want to use GPS in the background (or asleep), I do expect to have higher battery drain, and accept it. Being forced presently to run GPS-using app with screen on induces obviously a far worse drain.

Hey many thanks for the tip!
I guess certain apps should be allowed to set this as default behavior on their own (without manual operation in UT Tweaks Tool which, moreover, is not part of default apps).

Since it was working in android, there must be a way to have it working in UBports. I had more or less the same issue in the Xperia X port and could make it work (see here). Turns out that the proper device to use was usb0 and not rnids0 (but editing some files was still required to have usb0 being available). If you are comfortable with linux command line and modifying bash scripts, you should try things along what I did.

Manually starting OSM Scout server is not very user friendly indeed, but there are more annoyances when using the Pure Maps/OSM Scout Server combination. For instance when you search for a location, Pure Maps won't get any answer until you manually switch the screen to OSM Scout server and back again to Pure Maps. Screen switching is also required while Pure Maps is routing you and needs re-routing to be computed. You surely realize that needing to switch screens is NOT SAFE while driving...
AFAIU the reason is that when OSM Scout Server is in the background it is actually suspended (and hence unresponsive to Pure Maps queries) in Ubports. In SailfishOS where I come from, this was working flawlessly.
I also have the same sort of frustration when using "activity tracker" : it stops logging your position when the screen goes off. Again, this was working in SFOS.
As a result, from where I come, UBports seems a particularly crippled linux. Are there way that a user can decide that some apps should remain awake when in the background? If not, could provisions be made in the OS, in the containerization or whatever so that becomes possible?