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.

Hello. After sorting out some billing issue with Cloudflare and re-adding our domain to Read the Docs, https://docs.ubports.com/ is now online again. We apologize for any inconvenience caused by this.

I just realize that there has been a lack of a long-form communication from the Ubuntu base upgrade side, which causes some frictions and confusions when trying to contribute to Ubuntu Touch during this transition period. This post aims to provide status updates and information that I think everyone has to know.

Name changes for Noble-based images

Due to some confusion in the word devel which has been used differently before, I've decided to rename the word devel that is used in various places to just next or utnext. In practice, this means:

• The image name from the rootfs job will be in the format of e.g. ubuntu-touch-android9plus-rootfs-next-arm64.tar.gz
• The system-image channel for testing out Noble-based is now called utnext/arm64/android9plus/daily. Note that we've set up redirection in place, so if you're already on the old channel, you'll automatically be redirected to this new name.
• The Clickable images (which we're still working on) will be available under the version next.

The name next is chosen to represent that this will become the "next" major release of Ubuntu Touch. When we enters the phase where we stabilize the release, we'll produce another set of channels, rootfs and Clickable images with the release number (which is yet to be finalized).

Status of Noble-based Ubuntu Touch

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

• Web Browser
• Media Playback
• Sensor

This may seem not much, but more features are already in the code review phase. It could even be possible that we'll have the image in the state ready for wider testing before the Chrismas. We'll see...

Please be careful when submitting changes to core applications

Mike Gabriel and his team is currently working to package up a number of UT/Lomiri core applications for Debian, making them available on a more up-to-date OS with newer Qt compared to Ubuntu 20.04 our current images are based on. Meanwhile, our Noble-based Ubuntu Touch image is start to be more usable. Both of these expose our applications to new warnings which has not appeared before on Ubuntu Touch 20.04 with Qt 5.12.

However, in many cases, the only way to solve those warnings is to migrate the code to the new syntax. Syntax which is not compatible with Qt 5.12. In particular, those syntax changes include:

• Using function onFoo () { } form for Connection { } component.
• Setting restoreMode property of Binding { } component.

Since we've not make a separated branch for 20.04 just yet (and we can't do so because Clickable support for Noble-based Ubuntu Touch is not available yet), please don't introduce those changes into our core application repositories (more specifically, repositories under "ubports/development/apps" GitLab group). We've yet to decided if we need a separated branch for Ubuntu Touch 20.04 compatibility, but personally I would prefer that we don't need one.

Also, please be reminded that these applications are first and foremost core applications for Ubuntu Touch. When submitting changes for them, please be mindful of this fact. When reviewing changes, please think of a possible breakage on phone (and wrt. Click packaging). Preferably test them on a phone first if the change seems big.

Side note: we're planing to ship an environment variable drop-in file to silence deprecation warnings for the 2 syntax changes above. This should ease your eyes when reading through the log on the device.

Heads up for porters: please drop touch.pa overlay if possible

We expect ports that are available on Ubuntu Touch 20.04 to require only minimal changes in order to run on Noble-based Ubuntu Touch (unlike the 16.04 -> 20.04 transition). We've yet to finalize all changes that will be required. However, one change is certain: touch.pa will have to be updated, or be dropped if possible.

This is due to how a newer Pulseaudio changes how it handles Bluetooth audio, requiring us to update the configuration for the Bluetooth module. However, if touch.pa file is overlaid from ports, the old configuration would be used, preventing voice call over Bluetooth headset to work properly.

If your port requires overlaying touch.pa to hard-code the API level of pulseaudio-module-droid to 30, then you'll be glad to know that it will no longer required when MR at [1] is merged, as it will now happen automatically when required. If, however, your port requires overlaying touch.pa to specify quirks to pulseaudio-module-droid, we'll soon provide a way to specify this quirk without overlaying touch.pa. And if you need to overlay touch.pa for other reasons, please tell us so that we can understand your need better.

[1]: https://gitlab.com/ubports/development/core/hybris-support/pulseaudio-module-droid-discover/-/merge_requests/6

Another thing that might require special consideration is that, if your port overlays binary files (which we would not recommend, for security update reason and other reasons), please make sure that your overlaid binary can be executed on Noble-based images, as not every library retains its interface and/or soname.

Heads-up for app developers: you'll need to re-build your app

Due to changes in Ubuntu 24.04, we cannot guarantee that every application built against Ubuntu Touch 20.04 will run on Noble-based Ubuntu Touch. As such, we'll enforce it through Click's framework system that every native applications must be re-built against the next Ubuntu Touch version.

However, we've not finalized how the Clickable support for the new release scheme will look like. So you can't quite do that just yet. Sorry for the delay.

Meanwhile, if your application is QML-only, and the Click package declare this fact through Click framework (i.e. by using ubuntu-sdk-20.04-qml framework), your application should work as-is without any change. However, due to a shortcoming in Clickable, you might not be able to do that just yet. Please follow issue at [2] to see if this has been solved.

[2]: https://gitlab.com/clickable/clickable/-/issues/444

---

Phew! That's a lot of stuffs. I didn't expect it to be this long when I first decided to sit down and start writing this up. But here we are.

If you still have any question, feel free to reply to this post or to ping me on Telegram in the "UBports Development" channel. I'll try to answer as much as I can.

@domubpkm I'm sorry I didn't notice this before start rolling out. However, since this should be able to be remedied later via Open-Store, I've decided to not holding back the system update.

I personally am unable to reproduce the crash, but maybe I don't understand the reproduction steps well. Could you please elaborate more on this at Music app's issue tracker?

https://gitlab.com/ubports/development/apps/lomiri-music-app/-/issues

As for the Music app being unable to re-install, please help us gathering the log and then follow the workaround at:

https://gitlab.com/ubports/development/core/click/-/issues/27

(Music app's click package id is music.ubports)

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

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

@Kinuk We've not encountered any application trying to exploit this yet. That said, because Pulseaudio (the audio server) doesn't log a successful attempt at loading/unloading modules, should any application try to exploit this, there would be no evidence that we can see. This is one of the reason we've decided to roll out this update as soon as possible.

We're going to release Ubuntu Touch 20.04 OTA-7 earlier than schedule to fix a number of security issues affecting Pulseaudio, our audio server. One of the issue affects privacy of Ubuntu Touch users, and thus we've decided to release an out-of-schedule update.

The issues are as follow:

• Confined applications can remove the Trust Store permission system module from Pulseaudio, allowing such applications to access the phone's microphone without user knowing, amongst a number of privileged actions.
• Confined applications are able to crash Pulseaudio by performing a volume control on a specific virtual device when a Bluetooth headset is connected.

Both of the issues are specific to the way Ubuntu Touch patches and uses Pulseaudio. However, the second issue has a potential to affect some Ubuntu 16.04 installations running non-default configuration (newer versions are not affected). As such, we've coordinated with Canonical on the timing before making this announcement.

Due to the way our release pipeline works, Ubuntu Touch 20.04 OTA-7 will also contain a number of fixes which are not related to the aforementioned issues. Thus, we'll release an RC for 20.04 OTA-7 in upcoming days and we'll announce a call-for-testing. We plan to release Ubuntu Touch 20.04 OTA-7 on Friday 29 November 2024.

Updated: Ubuntu Touch 20.04 OTA-7 RC is out, which should have version 2024-W47. Please take some time to switch your spare/development phone to the 20.04 RC channel and test this OTA.

Update: Ubuntu Touch 20.04 OTA-7 is released. Thank you everyone involved in testing.

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

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