I'm happy to announce that, after much anticipation, Ubuntu Touch 24.04-1.0 is scheduled to be released on 24 September 2025.

Currently, the schedule looks like this:

Date	Event
31 July 2025	Platform stability freeze, 24.04-1.0 Beta 1
14 August 2025	String freeze
28 August 2025	Branch off, 24.04-1.0 Beta 2
11 September 2025	Final freeze, 24.04-1.0 RC
24 September 2025	Release version 24.04-1.0

(See the explanation of the freezes here: https://cpad.ubports.com/sheet/#/2/sheet/view/z44Rl7-Ba5mzHRYXXuk-9l8ZweVF-+v5X30JnZw7bPw/)

We're still a number of things left to do before we can release 24.04-1.0 to all users. However, at this point, we feel confident enough to define a finish line, especially given that Canonical has ended standard support for Ubuntu 20.04.

App developers: you'll soon be able to submit applications built against 24.04-1.x to OpenStore

As part of 24.04-1.0 Beta 1 release, we'll also declare ubuntu-touch-24.04-1.x Click frameworks as stable. Applications built against 24.04-1.x will be allowed to use APIs introduced in Qt 5.15, paving a way to Qt 6 migration in the future.

We're working to make sure apps built against 24.04-1.x can be published on OpenStore. This should happen by 31 July.

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.

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.

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.

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.

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.

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.

New system-image channel name: 24.04-1.x/arm64/{hybris,android9plus}/daily

A couple weeks ago, I've done another migration to change, amongst other things. system-image channel name. The new channels are now called 24.04-1.x/arm64/{hybris,android9plus}/daily, with utnext/arm64/{hybris,android9plus}/daily becoming the alias of the former.

The change is made to streamline the process when the development release (e.g. 24.04-1.x) enters a stabilization phase. Devices receiving updates from the old channel name will not see a significant change.

Once 24.04-1.x enters a stabilization phase, utnext/arm64/{hybris,android9plus}/daily will become the aliases of the next release of Ubuntu Touch (e.g. 24.04-2.x).

Status of Ubuntu Touch 24.04-1.x

Notable progresses in the past 2 months are:

• The new logo of Ubuntu Touch has been finalized, and is now used in the boot screen and (soon) in System Settings app.

• Calendar syncing is now working again after fixing underlying issues in libraries we depend on. (MR: 1, 2)
• The problem of ADB session being closed after a few minutes has been fixed. (MR)

GitLab label & milestone cleanup, and new GitLab issue board for 24.04-1.0

A few weeks ago, I've finally got a chance to sit down and re-organize issue labels, milestones and issue boards. As a result we now have an issue board for UT 24.04-1.0 which should help showing what's left in order to have 24.04-1.0 out of the door.

As you can see, there are still a number of issues on the board that would love some help. Please join our development Telegram group and talk to us if you're interested in one of the issues on the board.

For those that are interested in development of Noble-based Ubuntu Touch, we've now published a new system-image channel devel/arm64/android9plus/daily, available on most devices which has 20.04 devel image [1]. You can switch to it using the following command:

sudo system-image-cli -v --progress=dots --switch=devel/arm64/android9plus/daily

The channel has actually been existed for some time. However, up until today images are available only on a handful of devices due to system-image server configuration limitation. Note that I haven't tested the images on devices other than a handful of devices I have, so please make sure you have a way to recover your phone before trying this.

Note that at the time of posting, the Noble-based images are still missing quite a number of functionalities. At the moment, the following features are either known to be not working, or is not tested but is likely not to be working:

• Web browser
• Media playback
• Camera
• Libertine
• Sensor
• Push notification
• Dialer, Messaging UI
• Hotspot

If you're interested in helping bringing up these features to Noble-based images, please ping me either here or on Telegram.

Do not install this image on your daily driving phone. Things will be broken. You have been warned.

[1]: more specifically, devices with 64-bit ARM architecture and Halium 9 or newer.

This is the followup from my previous call-for-testing. This time, in addition to updated PulseAudio from 16.04, this also includes:

• a fix to Bluez which should improve the experience for users that use a Bluetooth headset for calling.
• an update to the modern pulseaudio-module-droid to make sure they work with the updated version.

All devices are welcome to participate in the test.

How to test:

Make sure your device runs the latest devel image. Run the following command in the ADB shell or SSH session:

# Mount a tmpfs so apt can breathe
sudo mount -t tmpfs tmpfs /var/cache/apt/archives 
# Prevent Bluez from restarting & get stuck.
sudo mount -o remount,rw /
sudo tee /usr/sbin/policy-rc.d >/dev/null <<EOF
#!/bin/sh
exit 101
EOF
sudo chmod +x /usr/sbin/policy-rc.d
# Actually install the packages.
sudo ubports-qa install xenial_-_pulseaudio-updates-to-0ubuntu3.10
# Reboot the phone.
sudo reboot; exit

What to test:

See if there's any regression in both built-in speaker, wired headset, and Bluetooth headset. If possible, use a Bluetooth headset that can be in both music mode (hi-fidelity audio) and call mode (low-latency 2-way audio).

Two possible regressions that can happen are

• issue #528 ([xenial] Sound does not go to bluetooth headset)
• a call via Bluetooth does work but cuts off after a few seconds

I believe they're fixed, but please report if you encountered these issues.

Also, if you have a Bluetooth headset with an accept/hangup button, try pressing the button while in call and see if the call hangs up. Accepting the call or last number redial might not work, and is a known issue.

You may want to also follow this test plan from Canonical if you want to be extra sure there's no issue. However, even in the current version of PulseAudio, not all tests in this test plan pass. Thus, you may want to double-check if it's a regression or not.
https://wiki.ubuntu.com/Process/Merges/TestPlan/pulseaudio

If you found any issue/regression:

Luckily, someone has written a script that automates enabling, disabling, and collecting debug logs [1]. It's located at https://github.com/bergotorino/bt-debugging-tools

To enable debugging, run ./bt-device-enable.sh -e -p <lockscreen password>. The device will reboot automatically. Then, after reproducing the issue, run ./bt-collect-logs.sh <password>. A tarball will be produced. Please send that to me via PM or Telegram (@peat_psuwit) as it can contain sensitive information. Please also mention the brands of all devices you used to test in the PM; they'll be used to match up with what's in the log.

To disable debugging, run ./bt-device-enable.sh -d -p <password>

[1] For devices with ADB anyway. If you use a Halium 7.1 devices without ADB, you may take a look at the script, or you can ask me.

Known issues:

• The issue that the playing streams won't switch to the headset after a re-connect/connecting another device is issue #1045. The fix requires that this update works first. To workaround, please close and reopen the app playing the sound.
• Even though using the button on the headset to hangup work, using it to accept a call or redial might not work.
• It's been reported that Bluetooth on OnePlus One is unstable in general. Thus, you may want to skip testing Bluetooth on this particular device.

@Vlad-Nirky said in Call for testing: Ubuntu Touch 24.04-1.0:

@peat_psuwit
Hello.
I took some photos with my Xiaomi Redmi Note 9 Pro running UT 24.04-1.0 RC 1 during a few days of holiday.
The indoor photos are fine, but those taken outside are overexposed.
I restarted the phone, but that didn't change anything.

The image quality of the device largely depends on the hardware-specific code from device manufacturer; we don't have much control over it. As such, I would suggest you to ask your port's maintainers to take a closer look into this.

@lduboeuf said in Call for testing: Ubuntu Touch 24.04-1.0:

First impressions:
<...>
Telegram Notifications are nor overriden ( list is always growing)
<...>

You're saying that anewer notification from the same contact should replace the old one, but doesn't? That's probably lomiri-push-service as we have a big refactor there to migrate to a different DBus library. If you can turn this into a GitLab issue I would appreciate it. Otherwise I can do it too.

Update 19 September 2025: Ubuntu Touch 24.04-1.0 RC 2 has been released. This release fixes an issue with embedded webview in some applications and fixes changelog.

@stanwood said in Call for testing: Ubuntu Touch 20.04 OTA-10:

So, how will the update be rolled out to users on the stable channel? (OTA-9). Will they first receive the update to 20.04 OTA-10, then immediately afterwards the update to 24.04-1.0? Or will they have the choice between the 20.04 OTA update and the 24.04-1.0 update?
I must admit that I myself am a bit lost in all this

20.04 OTA-9 users will first receive 20.04 OTA-10 as an usual update. After that, they'll be offered an upgrade to 24.04-1.0. Users can choose whether to upgrade or not.

I'll try to make this more clear in our release announcement blog.

With Ubuntu Touch 24.04-1.0 nearing release, many app developers will probably want to make sure their applications are available after the users upgrade their phone. This post will answer a number of questions you might have in mind.

Before we continue: version terminology

Throughout this post, I may use 24.04-1.x and 24.04-1.0 interchangeably. Technically, 24.04-1.x is a series which represent 24.04-1.0, 24.04-1.1, 24.04-1.2 etc, while 24.04-1.0 is a specific version from the series. However, we intends to maintain application compatibility across all minor versions throughout 24.04-1.x series. So, from app developers perspective, what is true for 24.04-1.0 should be true for the entire 24.04-1.x series as well.

I will indicate if I say something that is applicable for 24.04-1.0 but not for the rest of the series.

Do I have to re-build my application against Ubuntu Touch 24.04-1.x?

Surprisingly, the answer is complicated. At the most basic level, applications built against Ubuntu Touch 20.04 will still be downloadable on OpenStore for 24.04-1.x users, and applications that has already been installed will still be available on users' devices. However, depends on how the application is built, it might run fine on Ubuntu Touch 24.04-1.x, or it might outright crash from the beginning.

The best way to answer this is to install Ubuntu Touch 24.04-1.0 RC 1 on one of your phone and then try to run your app on it. But the following are rules-of-thumb:

• If your application is completely QML-only: most likely, your application will just run fine on Ubuntu Touch 24.04-1.x. However, you may still have to slightly modify the code to stop using unsupported types. For example, if you use Lomiri.OnlineAccounts 0.1, you'll have to change that to SSO.OnlineAccounts 0.1 since the former is not supposed to be used, even on 20.04.
• If your application contains C or C++ code: now it depends on what library you're using:
  • If your app uses only Qt libraries (such as libQt5Core, libQt5Gui, libQt5Quick etc.), then your application should run fine, unless you use private symbols for them. [^1]
  • If your app uses other libraries, then we can't really say for sure if your application will work as-is; you'll have to test your application to be sure. In general, if your library's API/ABI is stable and used outside of Ubuntu Touch ecosystem (e.g. GLib), then chances are it'll work. But if you use some lesser-known one, then it's more likely that it won't.
  • The following non-exhaustive list of libraries lists libraries known to have API/ABI changed between 20.04 and 24.04-1.x and requires rebuild:
    • libssl1 (from OpenSSL)
    • Boost (if you use non-header-only parts; see here)
    • ICU (libicu*.so)
    • libtiff, libwebp
• If your application is written in Rust or Go and you use Qt or QML, then you'll almost certainly have to rebuild your application. This is because the integration between Rust/Go and Qt uses Qt's private symbols which have changed between Qt 5.12 (20.04) and 5.15 (24.04-1.x).

Note: if you intends to support armhf architecture (32-bit ARM), you'll have always have to recompile your application, as armhf binaries built against 20.04 will not run on 24.04-1.x. This is due to Ubuntu and Debian's 64-bit time_t transition. Note that there's currently no supported Ubuntu Touch devices with armhf architecture.

[^1]: Ideally, the sdk-libs and sdk-libs-dev seeds should defines what is stable for applications to consume. In practice, this list is poorly maintained and most people don't think about this when writing their applications. There are things that we should not promise, and there are things that we should have promised, but doesn't. So for now this list is advisory. Also so see Canonical-era wiki page about Click frameworks.

How do I build my applications against Ubuntu Touch 24.04-1.x?

The steps are:

1. Make sure you run Clickable version 8.4.0 or later, which include necessary fixes for uploading applications built against 24.04-1.x to OpenStore.
2. In clickable.yaml, specify ubuntu-touch-24.04-1.x as the framework:

framework: ubuntu-touch-24.04-1.x

Alternatively, specify framework using CLICKABLE_FRAMEWORK environment variable (useful for dual-building against both 20.04 and 24.04-1.x, see below).

export CLICKABLE_FRAMEWORK='ubuntu-touch-24.04-1.x'

3. In your manifest.json, make sure to specify framework as "@CLICK_FRAMEWORK@". Most applications is probably doing this already, but it's worth checking to be sure.

    "framework": "@CLICK_FRAMEWORK@",

4. In your AppArmor manifest file(s), specify policy_version as "@APPARMOR_POLICY@". This allows Clickable to fill in the correct AppArmor policy version corresponding to the Click framework. If you have multiple AppArmor manifiest files (e.g. for your main application and your push helper), make sure to update all of them.

    "policy_version": "@APPARMOR_POLICY@"

5. Run clickable build as usual. Now the application should be built against Ubuntu Touch 24.04-1.x.

Note that applications built against 24.04-1.x will not run on 20.04 devices. In fact, the device will outright refuse to install your Click. This is intended; your application might call APIs that has been added in between versions, so we prevent this to avoid surprises.

If I upload applications built against 24.04-1.x to OpenStore, will it be offered to devices running 20.04?

No. OpenStore will offer the latest version which is still compatible with a particular device. For example, if you uploaded version 1.2.2 built against 20.04, then subsequently upload version 1.3.0 built against 24.04-1.x, devices running 20.04 will receive version 1.2.2, while 24.04-1.x devices will receive version 1.3.0.

I want to provide updates for my app to 20.04 devices after I upload a new version for 24.04-1.x. Can I do that?

Yes. OpenStore has been updated to accept a new Click which is older than the current version, as long as the Click's framework is different. Using the previous example again, if you uploaded version 1.2.2 built against 20.04 then subsequently upload version 1.3.0 built against 24.04-1.x, you can then upload version 1.2.3 built against 20.04 and 20.04 devices will receive this update. At the same time, 1.3.0 will continue to be provided to 24.04-1.x users.

I want to provide the same versions but built against both 20.04 and 24.04-1.x. Can I do that?

Yes, with one caveat: your built Clicks must have unique versions.

Wait, that's a "no", isn't it?

Well, indeed. But here's the technique: with some configurations, you can build your application twice using the same code, and still get a different versions out of it. Here's the way I do it:

• Make manifest.json a "build-time configured file". Then, add a build-time flag to define a suffix to the version of the Click.
• In your build scripts/CI configuration, build your app twice, varying CLICKABLE_FRAMEWORK. This might be multiplied by architectures, so in practice you might build your apps 6 times.
• In clickable.yaml, set the Click's version suffix based on the ${SDK_FRAMEWORK} environment variable, which Clickable will set to the framework you defined earlier. Note that shell's command substitution/variable expansion is available for you, so you can modify this variable further.
• Make sure you leave "framework" in manifest.json as "@CLICK_FRAMEWORK@", and your "policy_version" in AppArmor manifest(s) as "@APPARMOR_POLICY@". This allows Clickable to fill in the appropriate values.

For a concrete example, see this lomiri-calendar-app MR.

Fun fact: Click package's version is not limited to just "major.minor.patch" format. Rather, it allows a full range of Debian package's version, including alphanumeric, ~, + and -. So you can include them in the version to help distinguish Git builds, Ubuntu Touch versions, and more.

My app currently doesn't build against 24.04-1.x. The version built against 20.04 doesn't start on 24.04-1.x due to missing libraries. I'm currently short on time. Is there a workaround?

There is one, indeed. Clickable has a feature to include libraries from the build environment into your Click (similar to Snapcraft's parts.<part-name>.stage). To do so, add the library names in the install-lib key of clickable.yml.

install_lib:
- libasound.so*

When your application is launched, system will make sure that your Click's library is added into LD_LIBRARY_PATH environment variable, which will make your app look into your Click first for any library it wants.

Note, however, that if you do this, you will want to make sure that the library you included is not actually depended on by one of the system library but under a different "soversion" [^2]. This is because 2 different soversions of the same library can have the same symbols; in that case, it's not guaranteed which version of the symbol will be used, and the behavior will be undefined [^3].

One way to check this is to install your Click on a 24.04-1.x device, then run:

LD_LIBRARY_PATH=/opt/click.ubuntu.com/<Click id>/current/lib/* \
  ldd /opt/click.ubuntu.com/<Click id>/current/<your app binary> | less

Then, inspect the output to make sure the same library with different "soversion" does not appear twice e.g. make sure libwebp.so.6 and libwebp.so.7 does not appear together.

(The exception to this rule is libicu*.so; ICU allows linking multiple versions of itself into one process by make sure all symbols have the version number appended. See ICU4C documentation.)

[^2]: "soversion" is the first version number after .so in the file name. For example, if a library has a file name libcurl.so.4, its "soversion" is 4.
[^3]: my understanding of the Click framework contract is that, if a library does not appear in sdk-libs or sdk-libs-dev, then you're supposed to bundle it in the Click package. However, due to this "soversion" clashing issue, I'm not sure this is the right approach to this problem...

---

I hope this post answers some of your questions and ease a migration of your apps to 24.04-1.x. If you have any question, feel free to leave a reply to this post and I'll try to answer them as best as I can.

Ubuntu Touch 24.04-1.0 RC 1 is available for testing.

Notable changes

• The dialog warning users to disable Wi-Fi before sending MMS has been removed due to false positives.
• You can now disconnect from wireless display from the virtual touchpad on the phone's screen.

(picture of the feature)

• Media playback control is fixed in the top-panel indicator, in applications, and over Bluetooth headset.
• Bug fixes and stability improvements across the system.

Known issues

• It's a long-standing issue that fingerprint sensor on Fairphone 5 does not always work. It's unclear when this might happen. This might manifest itself as keyboard for the login password prompt jumps up and down very rapidly; this is due to Lomiri repeatedly getting error from fingerprint sensor.
• You may still see a placeholder text as part of first boot's "What's new" page. We'll provide another update to fix the issue. (ubuntu-touch-meta#3)

If you're already running Ubuntu Touch 24.04-1.0 Beta 2, you'll be offered Ubuntu Touch 24.04-1.0 RC 1 automatically. Otherwise, follow the same instructions as outlined above.

Update 11 September 2025: Ubuntu Touch 20.04 OTA-10 RC 2 is published. This version includes fixes for various issues with Volla devices, along with a number of bug fixes.

The new target release date of Ubuntu Touch 20.04 OTA-10 is 25 September 2025 (the same date as Ubuntu Touch 24.04-1.0).

@Vlad-Nirky said in Call for testing: Ubuntu Touch 24.04-1.0:

In the latest build 24.04-2.x,

(Note that this thread is for 24.04-1.0 testing. 24.04-2.x is in early development and is not necessarily ready for testing.)

I noticed that when typing a sentence using the OSK, when you select a suggested word, it does not automatically add a space between the selected word and the rest of the text.

For the OSK issue, this seems to a side effect of us disabling Auto correction by default. If I enable "Auto correction" in 24.04-1.0, then selecting word suggestion adds a space. And if I disable "Auto correction" in 20.04, then the space isn't added either.

So for now you can enable "Auto correction" back on as a workaround. We'll probably fix this issue in a point release of 24.04-1.x series.

And the automatic brightness adjustment no longer works.
Xiaomi Redmi Note 9 Pro 24.04 r4

Sadly this one I cannot reproduce. I'm afraid you'll have to ask the port's maintainer for help on this one...

@lduboeuf said in Call for testing: Ubuntu Touch 24.04-1.0:

interesting, this is the first time i've heard that MMS works through Wiifi...
So with all feedbacks here, i think we have to revert the mms popup feature for now...
EDIT: https://gitlab.com/ubports/development/core/lomiri-messaging-app/-/merge_requests/369

The situation with MMS and Wi-Fi is that sending MMS with Wi-Fi on will work, if the carrier specify MessageProxy in terms of IP addresses, which is the case for @Eric-H and also for the carrier I'm using (the carrier may also specify it in terms of domain name, or may not specify it at all and use MessageCenter alone). In that case, oFono is able to set the routing table so that MMS traffic goes through cellular network, which allow it to work despite Wi-Fi being on.

For all nitty-gritty details, see https://gitlab.com/ubports/development/core/packaging/ofono-sailfish/-/issues/13

(That said, the problem with Lomiri.Connectivity reporting inaccurate info will have to be investigated as well...)

@Eric-H said in Call for testing: Ubuntu Touch 24.04-1.0:

@ftmazzone
Ok, we just have to disable wifi when sending MMS, not a problem.

As we do not anticipate when MMS will arrive, will we have to disable wifi all the time to be able to receive them ?

My understanding is that Ubuntu Touch now have a facility to retry retrieving MMS if downloading fails. So, in that case, you should get a notification, after which you can disable Wi-Fi and retry retrieving MMS (@lduboeuf please correct me on this if I'm wrong).

---

@Eric-H said in Call for testing: Ubuntu Touch 24.04-1.0:

@peat_psuwit
I followed the above procedure to update my Xiaomi Poco X3 NFC (surya) to UT 24.04-1.0 Beta 2.

This worked well except a UI issue: I had to uninstall two applications because instead of seeing the screen offering the system upgrade, I saw a screen proposing the update of Dev Tools and Pure Maps Slim

You should not have to uninstall applications; once all applications are updated, you should be offered release upgrade. This is intentional, as many times application and system updates can solve compatibility issues with the new release before the new release is being upgraded to.

@poVoq said in Call for testing: Ubuntu Touch 24.04-1.0:

Anyone tried if Bluetooth media buttons work now? Those for changing the volume, changing the music track and accepting calls.

Thank you for the report. I can reproduce this issue and will look into it.

@wally said in Call for testing: Ubuntu Touch 24.04-1.0:

I just checked the installer to see what was default, and yeah, first one listed in the Installer is 24.04-1.x/daily. Somebody has filed an issue on the installer's gitlab, as per another thread.

@Futura if the updater isn't giving you the option, I did see that there's a 24.04-1.x/rc, which is Release Candidate. You could flash the system to that with the installer, and just make sure the option that says Wipe Data (or something like that) isn't checked.

For 20.04, the installer has /stable, /rc, and /devel. I hadn't considered this potential for confusion before, but I guess "daily driver" is an awfully common term, and I can imagine new users being confused. Either going back to calling it "devel" or changing it to "nightly" might avoid the confusion.

We're going to improve installer so that it group channels by Ubuntu Touch releases, prefer stable channel, and avoid showing development release. This should largely solve confusion, at least in the installer.

As for the channel name, now that you've said it, I'll agree that nightly is probably a better name (we want to avoid devel because of an earlier mistake). Unfortunately, at this point it's going to be a hassle to change the channel name as a number of tools now depend on this. So... it is what it is.

Ubuntu Touch 24.04-1.0 Beta 2 is now available.

Notable changes

• It's now possible to send and receive MMS again as the underlying components for MMS have been fixed. Additionally, there's now a dialog telling users to disable Wi-Fi and enable mobile data before sending MMS.

• Bluetooth pairing in System Settings has been fixed.
• You can now disconnect from wireless display from the virtual touchpad on the phone's screen.
• Bug fixes and stability improvements across the system.

Known issues

• It's a long-standing issue that fingerprint sensor on Fairphone 5 does not always work. It's unclear when this might happen. This might manifest itself as keyboard for the login password prompt jumps up and down very rapidly; this is due to Lomiri repeatedly getting error from fingerprint sensor.

If you're already running Ubuntu Touch 24.04-1.0 Beta 1, you'll be offered Ubuntu Touch 24.04-1.0 Beta 2 automatically. Otherwise, follow the same instructions as outlined above.