Ubuntu Touch 20.04 OTA-9 is released. Thank you everyone involved in the testing.

https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-ota-9-focal-release-3962

@mjosenhans said in Call for testing: Ubuntu Touch 20.04 OTA-9:

I just noticted a further issue. In call forwarding it says to forward some home calls. When selecting this, it says forward incomming calls when not available (to a german number I do not know). When removing the hook to disable this and going back to the pre vious menu, it still says forwarding some phone calls. When going back to this menu, it says that calls are still forwarded to that phone number.

First of all, thank you for additional testing (both on Waydroid and on the call forwarding issue).

On the call forwarding, some carriers use call forwarding for its own purpose and you can't really unset it (happens with my carrier at least). Please test this issue on another phone to see if this is the case.

---

@paulcarroty said in Call for testing: Ubuntu Touch 20.04 OTA-9:

Request a USB tethering test for Suzu.

@peat_psuwit make sure to include this fix.

Unfortunately, unless this is a regression or a critical problem, we cannot accept additional fixes at this stage, as it will delay 20.04 OTA-9 by at least another week. It will be included in 20.04 OTA-10 and in upcoming 24.04-1.0.

That said, I think the fix in that PR is not correct. But that's off-topic for this thread...

@mjosenhans We're unable to reproduce this issue. Please run the following commands on a computer, which will collect logs from device for debugging.

adb shell journalctl --user-unit=lomiri-app-launch--application-click--waydroidhelper.aaronhafer_waydroidhelper_3.2.0--.service >waydroid-helper.log
adb pull /home/phablet/.local/share/applications/Waydroid.desktop
tar -cv --xz -f waydroid-logs.tar.tz waydroid-helper.log Waydroid.desktop
rm -v waydroid-helper.log Waydroid.desktop

You may need to enable USB debugging first. After running commands, please attach file waydroid-logs.tar.xz.

Update 28 May 13:20 UTC: a new RC has been published. Changes include a fix for Waydroid startup race condition, an APN config update for 1&1 (a carrier in Germany), and additional security fixes from Ubuntu upstream.

@wally Thank you for your report.

@wally said in Call for testing: Ubuntu Touch 20.04 OTA-9:

• The Notification LED is not working. While I don't use this phone frequently, it definitely worked in the past. Seems to have stopped working as of this update.

The notification LED on Oneplus 5 is known to be randomly not working (depending on a race condition on boot). The fix will be implemented in a future update. In the meantime, please try rebooting the device and see if it solves the issue.

@wally said in Call for testing: Ubuntu Touch 20.04 OTA-9:

• The only other thing that I've noticed is that if I click to add an image to an SMS message, select Camera, and take a new photo, after taking the photo, in the screen where you can click to retake photo, accept photo, or cancel, the photo shows up as a solid light grey, with only a column on the far right side of the photo visible. But when sent, it sends as normal. This is a new behaviour as of this update.

This is an issue with a newly-released Camera app relating to a new on-by-default metadata privacy feature. As a workaround, you can swipe from bottom, press the mask icon, and select "Save device info". The issue will be fixed in the next release of Camera app on Open-Store.

We've just released the RC image for the Ubuntu Touch 20.04 OTA-9, which should have version 2025-W21 or newer. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

Ubuntu Touch 20.04 OTA-9 is a maintenance release with only a minimal number of changes. That said, we still have a number of changes in this OTA. We would love an extra attention to the following areas:

• Basic phone functionality (call, SMS, MMS and cellular data)
  • In particular, if your carrier supports VoLTE and you're using newer Volla phones (X23 and newer). This release include fixes which make VoLTE work on more carriers, which may introduce compatibility issues.
• If your device has an LED, please see if it works correctly.
• Whether Emojis show up correctly. (Not all of newer ones work, but the number should improve).
• Whether Waydroid works.

Please note that only critical and security fixes will be able to enter Ubuntu Touch 20.04 OTA-9 as this point. Normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

Ubuntu Touch 20.04 OTA-9 is expected to be released on 3 June 2025. We appreciate all testing we will receive.

---

Update 28 May 13:20 UTC: a new RC has been published. Changes include a fix for Waydroid startup race condition, an APN config update for 1&1 (a carrier in Germany), and additional security fixes from Ubuntu upstream.

Apologize for the late update this time. Let's get into it:

For everyone: the next Ubuntu Touch release will be called 24.04-1.0

You'll notice that this status update has a different headline format. After a discussion with UBports Foundation Board of Trustee (BoT) and with the community in general, we've decided on naming the next Ubuntu Touch release based on Ubuntu 24.04 as "Ubuntu Touch 24.04-1.0". 24.04 signifies the base Ubuntu version we're based on, and 1.0 represents whether it's a major upgrade or it's a minor update.

For now, the system-image channel will still be called utnext/{arch}/{hybris|android9plus|mainline}/daily. We will provide more updates on system-image channel in the future.

For app developers: it's now possible to build against Ubuntu Touch 24.04-1.x

Finalizing on versioning scheme means we're now able to finalize the name of Click framework. The new framework is called ubuntu-touch-24.04-1.x, with -qml variant for QML-only applications and -papi for applications without QML part. Due to the limitation of the Click file format, the AppArmor policy version is 2404.1.

Support in Clickable has been added in the recently released version 8.3.0. This means that if you specify the correct framework and AppArmor policy version, Clickable will choose the correct Docker image by itself and will produce Click packages compatible with 24.04-1.x series.

Open-Store will not yet accept applications built against Ubuntu Touch 24.04-1.x, as the framework is not quite stable yet. However, it's stable enough for developers to compile and test their applications against newer versions of libraries (such as Qt 5.15) available in Ubuntu Touch 24.04-1.x.

We intend to maintain full app compatibility between minor updates, but the same can't be said on major upgrade even when we stay on the same Ubuntu version. However, in practice the app compatibility on the same Ubuntu base version should be possible, and we'll try to maintain backwards compatibility where it makes sense.

For app developers: Ubuntu Touch 24.04-1.x will support apps built against Ubuntu Touch 20.04

Related to my last point, it turns out that it's relatively easy to maintain compatibility with apps built against Ubuntu Touch 20.04, with only a couple of compatibility libraries added to Ubuntu Touch 24.04-1.x. So, we've decided to maintain compatibility with applications which use ubuntu-sdk-20.04 framework and its variants.

This applies to most phones which has a modern 64-bit ARM processor (this applies to all devices which we currently have stable releases of Ubuntu Touch 20.04). On older phones with 32-bit ARM processor, due to a large-scale transition in Ubuntu and Debian (64-bit time_t transition), this is not possible, and compatibility will be limited to QML-only apps which use -qml variant of framework.

Status of Ubuntu Touch 24.04-1.x

At the moment, a few key items still has to be done, including but not limited to:

• Fix MMS and contacts/calendar sync.
• Re-test push notification and hotspot to ensure they actually work.
• Re-building our core applications against the new framework.
• Update our artworks to go with the new Ubuntu icon, introduced at part of Ubuntu 22.04.
• A more streamlined mechanism to upgrade Ubuntu Touch major releases.
• Infrastructure-side work to support the new Ubuntu Touch release scheme.

We still need help in many of these items. If you're interested in lending hands, please reach us on our Telegram group.

Ubuntu Touch 20.04 OTA-8 is released. Thank you everyone involved in testing.

https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-ota-8-focal-release-3953

@domubpkm So MMS used to work before installing 20.04 OTA-8 RC, and then doesn't work any longer since then?

Could you please collect the log (after a send attempt has been made) using command:

sudo journalctl --boot >journalctl.log

and send it to me? The log will contain your IMSI (roughly your SIM identifier), so please provide it via forum chat or via Telegram (@peat_psuwit).

@domubpkm said in Call for testing: Ubuntu Touch 20.04 OTA-8:

At this point, no regression observed on the Volla 22 although finding 4G seems quite long after a start-up of Volla 22 via the stages: no network, 2G, 3G, 4G. The succession of steps can take more than 30 seconds. Maybe normal ?

Hello. Do you happen to know if your Volla Phone 22 runs Ubuntu Touch based on Halium 12 or not? If your Volla Phone 22 has a replacement screen, then it is running Ubuntu Touch based on Halium 12.

Update 25 Feb 13:40 UTC: a new RC has been published which fixes mobile data issue on some Volla Phone X23 users depending on SIM slot being used.

Update 20 Feb 7:00 UTC: a new RC has been published which include a fix for Pixel 3a XL cellular breakage.

We've just released the RC image for the Ubuntu Touch 20.04 OTA-8, which should have version 2025-W08 or newer. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

Ubuntu Touch 20.04 OTA-8 is a maintenance release with only a minimal number of changes. That said, we still have a number of changes in this OTA. We would love some extra attention to the following areas:

• Basic phone functionality (calls, SMS, MMS and cellular data)
• Address book app
• Web browser
• Wi-Fi settings
• If you were affected by mobile data breakage issue in OTA-6 testing cycle, please check if mobile data is working for you in this RC. You might be affected if you use Volla Phone X23, live in Germany, and Telekom is your carrier.
• If you're using Volla Phone 22 with a new replacement screen, we would appreciated it if you can spare your time testing this RC.

Please note that only critical and security fixes will be able to enter Ubuntu Touch 20.04 OTA-8 as this point. Normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

Ubuntu Touch 20.04 OTA-8 is expected to be released on 28 Februrary 2025. We appreciate all testing we will receive.

Update 19 Feb 13:40 UTC: earlier version of the announcement mentioned contact syncing as an area of interest for testing. It was included by accident, and has been removed.

Update 20 Feb 7:00 UTC: a new RC has been published which include a fix for Pixel 3a XL cellular breakage.

Update 25 Feb 13:40 UTC: a new RC has been published which fixes mobile data issue on some Volla Phone X23 users depending on SIM slot being used.

@gandalf said in On the subject of Ubuntu Touch versioning scheme:

I know I'm too late to the party; but if you're already staying this close to the current naming scheme why not go all the way to 24.04 OTA-1.0? Everyone is familiar with that naming convention already, and introducing a minor version number is "backwards" compatible by calling every previous OTA-x.0 if needed. And soon when UT reaches version parity with ubuntu 24.04 the colloquial OTA-x(.y) will be back in action offering an easy shortcut to identify the current release.

We've considered 24.04 OTA-x.y. Unfortunately, (re-)using the word OTA could set the wrong expectation; by using the word OTA, many users will expect incremental, frequent updates (AKA rolling release).

Aka I'm getting old and grumpy, but I really can't stand the relentless reshuffling of naming schemes that usually offer no improvement and just increase the mental load on trying to figure out wtf is going on again

I'm really sorry that you have this sentiment. I also don't want to change the versioning scheme, but both the technical and practical reasons forced us to re-think how we will version Ubuntu Touch.

In the Board of Trustees meeting on 4th February, I've brought the release version numbering up as a discussion topic. The attendees considered the comments on this post and have agreed that it's important to still reference Ubuntu version in our versioning scheme, while it would be beneficial development-wise to have a major-minor release system in place.

As such, we've come up with a versioning scheme of "Ubuntu Touch [Ubuntu version]-[release version]" (a variant of option 3). For example, the next version of Ubuntu Touch would be referred to as "Ubuntu Touch 24.04-1.0".

We believe this versioning scheme is both understandable and practical.

@lduboeuf See https://gitlab.com/clickable/clickable-docker-images/-/merge_requests/150

@TheKit said in On the subject of Ubuntu Touch versioning scheme:

Could you please elaborate why this type of version scheme makes it harder to introduce larger changes? We could always have OTA-x.y if needed for smaller changes in-between (and in practice already done so when specific issues/devices needed hotfixes), but I wonder what is the issue for larger ones?

A special consideration is needed in order to isolate changes in-pipeline from hotfixes. For example, suppose we've landed multi-component code which improves Wayland application support but require some more testing (the larger change). But then there's a severe vulnerability in QtWebEngine which we have to patch as soon as possible. The original 20.04 OTA-x scheme doesn't have a way to do that; we would have to wait until the change is tested before we can release the next OTA.

One way to alleviate that is to take a procedure from Canonical days and take an Apt snapshot at the OTA release time (nowadays trivially doable using Aptly), then binary-copy the QWE package from the current devel archive to the snapshot archive and build an rootfs image from that.

Or am I understanding your question wrong?

@Fuseteam said in On the subject of Ubuntu Touch versioning scheme:

I would like to propose option 2 but keeping the "." between year and month

so if the next version is released in may 2025 it would be called 25.05.0

[...]

i think we can work around the confusion with the Ubuntu version we're based on by utilizing code names in the release announcement similar to upstream ubuntu

e.g. Ubuntu 24.04 Noble Numbat vs Ubuntu Touch 25.03.0 Marvelous Moon

I'm not sure that could really workaround the confusion though. For example, suppose we have a release in April 2026 then the version number would be e.g. Ubuntu Touch 26.04.0 Callisto [1]. But then we're likely not quite ready to base our system on Ubuntu 26.04 I think that unless we carry our codename everywhere (impractical, IMHO), I think confusions will ensue.

[1]: someone suggested using moons in solar system as a codename in the UBports development channel.

Hello. I'm Ratchanan Srirattanamet, a member of Ubuntu Touch core developer team. We need your opinion on how we version the next version of Ubuntu Touch.

Early last year, we - the core developer team - had a discussion on how we can improve our release pipelines. One of the results that came out of it was that we want to de-couple our versioning scheme from Ubuntu LTS version we use as our base, to give us flexibility when doing a large-scale feature release independently of Ubuntu releases. This lead to our announcement in February 2024 announcing the intention to change.

However, as we sort out technical challenges to get the changes we announced implemented, one of our community members voiced a concern that, by using our own versioning scheme, we might distance ourselves from the broader Ubuntu community even more than we already have. And it also hits me that versioning scheme is the matter of project identity.

Fortunately (or unfortunately), at this point nothing is really set in stone yet. So we still can change up how we do versioning.

We have a few options:

Option 1: Keep the current versioning scheme

The current versioning scheme (20.04 OTA-x) comes from the necessity that we needed to provide parallel support for Ubuntu 16.04-based OTAs at the same time as we developed our Ubuntu 20.04-based OTAs. We could keep this versioning scheme, which will essentially make us continue to use rolling-release scheme with more-or-less the same way we have been operating.

This 20.04 OTA-x, 24.04 OTA-x, etc. version scheme makes it clear which version of Ubuntu we're based on. However, this will make it harder for us to introduce larger, system-wide changes which takes time to develop and require more comprehensive testing. It also make it harder to offer hotfixes in between OTA releases when changes in the pipeline might not be ready for shipment yet.

Option 2: Complete decouple of Ubuntu version

On the opposite side there is a scheme similar to the announcement we mentioned above. The current revision we have after a few discussions is to drop the "." between year and month to avoid confusion with the Ubuntu version we're based on. For example, if the next major release of Ubuntu Touch was planned to be released in May 2025, we would then call this release "2505.0".

Between major releases, we'll backport bug fixes, security updates, and small improvements, providing them as minor point releases of the previous major release (e.g. 2505.1, 2505.2, etc.). This scheme makes it more clear which of the updates are feature updates vs. bugfixes, and allows us to publish security fixes and important bugfixes more frequently, with less testing effort and shorter development freeze phases.

To implement this scheme, the following changes have been/will be implemented:

1. When we started working on Ubuntu Touch 24.04, we introduced ubports/focal Git branches across all code compenents' Git repositories. This allows us to bring individual code changes to the next 20.04 OTA-x while all the development for the next UT based on Ubuntu 24.04 LTS happens on the main branches of the Git repositories. With this move, we detached developed of the next major version of Ubuntu Touch from preparation of the next stable 20.04 OTA-x release.

2. With this split branching in place, we added a development policy: a code change can only land in the next UT stable release (i.e. next 20.04 OTA-x, i.e. on the component's ubports/focal Git branch), if it has been accepted for the next major release (i.e. on the component's main branch). This protects us from issues being fixed for UT 20.04 while still unfixed for the next major UT release.

3. The next policy we chose to constrain ourselves with: no invasive changes for UT 20.04 OTA-x release. Once a major release has been published, our goal is to stabilize and consolidate it more and more. New features these days only get accepted on components' main branches, i.e. they can only become a feature of the next major release of UT.

However, as I mentioned earlier, this will unfortunately mean Ubuntu Touch will be more "on its own" in comparison to the rest of the Ubuntu ecosystem & community. It would be harder for us if, in the future, we would like to become an Ubuntu flavor again.

Option 3: Incorporate Ubuntu version in the versioning scheme, but adapt it for major release scheme

A sort-of middle ground between these 2 schemes is to still use Ubuntu version in our version, but then add a suffix to the version to distinguish each of our major release. For example, the next Ubuntu Touch version could be called "Ubuntu Touch 24.04.0" to indicate that this is the first major release of Ubuntu Touch based on Ubuntu 24.04. Then, the next major version could be called "Ubuntu Touch 24.04.1", "Ubuntu Touch 24.04.2" and so on. To be clear, we want to tie into only the major version numbers of Ubuntu e.g. 24.04, and not any of its point releases.

For minor releases, we could call it something like "Ubuntu Touch 24.04.0.1", or we could borrow a convention from OpenSSH and do something like "Ubuntu Touch 24.04.0p1".

This scheme could give benefit of both worlds, allowing distinction on major releases vs. minor releases while still having a tie with Ubuntu version we use. However, there's a large potential that our versioning will get confused with Ubuntu's point releases. If we want to go this route, we might have to choose a better suffix to make a relationship between Ubuntu version and our version clearer.

Option 4: Complete rolling-release; call it OTA-x at all time

For completeness, it might be worth mentioning that Ubuntu Touch has not always been referred to by its Ubuntu version. Both in the Canonical time and after UBports initially adopt the project, Ubuntu Touch updates were referred to simply as "OTA-n" without regards to base Ubuntu version. Even when UBports had its first-ever Ubuntu base upgrade, it was called simply OTA-4, not 16.04 OTA-1.

However, I believe this would give the worst of both worlds: decoupling from Ubuntu version while stucking with rolling-release scheme with all its limitation and risks regarding software stability.

---

I believe it's important for our community to have a say in this matter. We appreciate all feedback and suggestions, including suggestions of the new scheme not on the list above. Thank you.

Status of Noble-based Ubuntu Touch (UTNext)

Since the last time I made a forum post, the following features has become usable:

• GPS
• NFC
• Phone call & SMS
  • Note that MMS is blocked until very recently. We'll have to recheck if it has been fixed or not.
• Camera, include picture and video recording.

Progress is a bit slower than we expected. But we still are progressing nicely.

For app developers: it's now possible to build & test your apps against UTNext

After a long await, you can now start attempting to rebuild your app against Noble-based UTNext. This should allow you to test whether your app has any problem with the Noble-based images, especially if the app was unable to start on them before due to shared library changes.

For now, you'll need to get a nightly build of Clickable. After that, specify ubuntu-touch-next-internal as the framework inside clickable.yaml and specify policy_version of the AppArmor profile to 9999. You may also also have to make sure your manifest.json specifies @CLICK_FRAMEWORK@ in the framework field so that the correct version is filled in automatically by Clickable (sadly a similar mechanism doesn't exist yet for AppArmor policy - see this issue). When building, you'll have to specify --accept-review-errors for now, as click-reviewer-tools has not been updated.

ubuntu-touch-next-internal is a framework which corresponds to the on-going development of UTNext. The -internal part indicates that there is no formal "contract" for this framework. In other words, we don't guarantee forward- and backward- compatibility with any past and future Ubuntu Touch versions. The framework is intended for testing only and is not intended to be published to the Open Store; you'll have to switch to the final framework when it's available.

Due to delays and ongoing discussions, we at the core team are still unable to settle on what versioning scheme and what version number we will use for the next Ubuntu Touch release, and subsequently as the final framework name. We'll have a separated post discussing this in more details and allow you to chime in. We're sorry for this; as soon as we're able to finalize this detail, we'll provide an update to you.

Update: please see a separated post for a discussion around version number: https://forums.ubports.com/post/84517

For porters: it's now possible to drop touch.pa overlay (for UTNext, at least) now possible on both UTNext and 20.04

If your port is one of the port which has to overlay /etc/pulse/touch.pa to provide additional arguments to pulseaudio-module-droid-discover or pulseaudio-modules-droid-card-<API>, it's now possible to instead provide extra arguments using an Deviceinfo property. The property is called PulseaudioModulesDroid_ExtraCardArgs [1] and accept all arguments which you may add to pulseaudio-modules-droid-card-<API>. For example, you can put this in your Deviceinfo overlay to set sampling rate of your device's audio chip:

  PulseaudioModulesDroid_ExtraCardArgs: "rate=48000"

Combined with a change which allow you not to hard-code API level, it should now be possible to drop touch.pa overlay entirely. This feature is now merged into UTNext and 20.04, so you'll be able to share your device tarball between 20.04 and UTNext.

[1]: In case you're wondering, yes, there are PulseaudioModulesDroid_ExtraGlueArgs and PulseaudioModulesDroid_ExtraHidlArgs as well. However, I believe you won't need them.