I have pushed 4.19.265 to the repos, daily images should pick it up any moment now.

We're getting closer!

Best you can do is update to the daily channel of your current baseline Ubuntu Touch version, and not update it for a while. It would have been to risky including the workaround that late in the release process. But yeah, the problem has been identified as being partially caused by opportunistic auto suspend of the phone.

Good news, the xtables-enabled Docker Snap is now available in the edge channel. I've updated the How to section with the new install commands. If you want to refresh: sudo snap refresh docker --edge --devmode

@fair For the Fairphone 5 I've implemented something which should help you, it's available in latest daily channels. The change is here: https://gitlab.com/ubports/porting/reference-device-ports/android11/fairphone-5/fairphone-fp5/-/commit/13884b434abf95f643f41f04c62b22e73be9fe1c

What it does is keep the device awake once Waydroid starts. That means it won't opportunistically autosuspend anymore while Waydroid is running.

For those wanting to try clickable with the new docker snap, or wanting to build other images on your devices, I noticed a serious performance hit in creating clickable images with the new Docker 29.0.0 which is due to the containerd-snapshotter feature. You can disable it easily though, restoring snapshot creation to a previous codepath. You'll just have to edit your /var/snap/docker/current/config/daemon.json configuration:

$ cat /var/snap/docker/current/config/daemon.json
{
    "log-level":        "error",
    "features": {
        "containerd-snapshotter": false
    }
}

Make sure to restart your Docker daemon afterwards: sudo snap restart docker

@projectmoon overlayfs not being available is a kernel problem, for which you should contact your device maintainer.

Hello again.

Some things happened since I posted the original post above. I've gone ahead and added automatic detection for xtables vs nftables to the Docker Snap, which was received quite positively by the maintainers. Here's the PR for those who are interested: https://github.com/canonical/docker-snap/pull/329

You can install the Snap via:

sudo snap install docker --channel=edge/pr-329

If you've already installed the test package from the Downloads link above, you will have to instead run:

sudo snap refresh docker --channel=edge/pr-329 --amend

When this lands it will first land in the edge channel before promotion to a more "stable" channel, so keep that in mind once you see the PR merged.

@nparafe That device's kernel is too old for using cgroupv2 and eBPF to mediate device access, it's advised in the port to set the kernel cmdline systemd.unified_cgroup_hierarchy=0 and recompile the kernel image. Please tell your device maintainer about this.

@uxes IIRC with fscrypt in place, just replacing shadow breaks the protectors of fscrypt, leaving the system with a broken state. Also that's the dog biting it's tail: decrypting based on the password while the file containing the password is locked, that doesn't work.

Regarding bluez data: that would break bluetooth at the greeter, which might be required for some usecases.

@ikoz Encrypting apps would prevent tampering with executables and replacing them with malicious ones by evil actors.

I want to start a discussion about encrypting more data stored in the /userdata partition, for extra security/paranoia.

Right now we have /home/phablet encrypted when done so via system-settings, but there's room for improvement. I would like to also encrypt:

• Wifi settings
• Apps
• Potentially more which I don't see yet

For apps I have created a script which does the encryption in an easy-to-follow manner. This will require a device with policy version 2 support. It's available here: https://gist.github.com/fredldotme/696ab1e22bec4ed296caee471aa89a87

ATTENTION: Don't try to force the script to run on a system which only supports v1 policies, this will break app installation and uninstallation.

The script keeps the unencrypted original in /userdata/system-data/opt/click.ubuntu.com-bak which you will have to remove manually after rebooting.

Encrypting data which is usually accessed by non-phablet users will require v2 policy suppport, so keep that in mind when coming up with ideas.

Any input?

I've updated the kernel to 4.19.242 now locally, will test further and merge this ASAP.

Some hours, 4 cans of XL energy drink, and some patience later and I upgraded the kernel to 4.19.198. That's 41 patch versions fresher than before!

I will do these updates in stages. First I'll update until I feel comfortable with it, test it for a day, then merge it into the release branch. Also I've been able to catch some discrepancies I wouldn't have been able to catch otherwise if I just merged the latest upstream git into our kernel. Leaves me some peace of mind.

Hello there!

I am using the Fairphone 4 as my daily driver at the moment, and I want to ensure good security of the device. Henceforth I am updating the kernel from 4.19.157 to the last stable release 4.19.325 from December 2024. While no major update this will ensure added patches to known CVEs.

Please be aware that this is a tedious process, taking incremental patches from upstream kernel.org, applying them, checking conflicts, building them and testing them on the device. It will take some time until we reach 4.19.325, so please be patient.

If you think that's a worthwhile thing to do, please leave a donation (I could really need it). Links below in my signature.

@gpatel-fr I agree your approach using overlayfs is better, puts the file in the same place we would regularly put our customizations.

@pparent a technical explanation as to why this app will always be slow with Xwayland:

X11 historically uses GLX for passing buffers from the client to the server, and GLX inherently is tied to Desktop OpenGL. Desktop OpenGL and OpenGL ES as used on Ubuntu Touch devices are different. The only way forward would be EGL and that would require changes to Xwayland to handle the Android driver's/libhybris EGL implementation.

I tried bringing hardware acceleration to Xwayland once and it resulted in only one device (the JingPad) being remotely capable of doing it, with render artifacts. Since then we run Xwayland in shm mode which guarantees software rendering in all cases. So whatever you perceived as hardware accelerated before must have been a placebo.

@nielsbasjes you can use systemd mount units for this, we allow writes to /etc/systemd/system:

• Copy your modified NetworkManager.conf to /etc/writable as a safe spot
• Create a file /etc/systemd/system/etc-NetworkManager-NetworkManager.conf.mount with the following contents:

[Mount]
What=/etc/writable/NetworkManager.conf
Where=/etc/NetworkManager/NetworkManager.conf
Type=none
Options=bind

[Install]
WantedBy=local-fs.target

• Enable the mount unit: sudo systemctl daemon-reload && sudo systemctl enable etc-NetworkManager-NetworkManager.conf.mount

Let me know if it works for you, a quick reboot with this applied on my FP4 resulted in the same IP assigned as before.

@Thomas I presume your choice between a de-Googled Android and Ubuntu Touch should revolve around whether you want Ubuntu as your Operating System on the phone or not. We take security seriously and we're slowly catching up, see encryption of your data being a thing on 24.04.

@arubislander Regarding containers not having access to the internet: It might be the device is using "Paranoid Android Networking" in the kernel, stemming from Android, which limits use of sockets to a special group ID.

To device maintainers wanting to support LXD, you will want to check whether CONFIG_ANDROID_PARANOID_NETWORK is in your kernel tree (simply grep recursively for it) and if so, set CONFIG_ANDROID_PARANOID_NETWORK=n in your defconfig. I've since fixed this on the FP4 and verified working networking on the FP5.

And here a little success story on combining the Clickable Snap & the Docker Snap, allowing to build AND test a click package directly on the device (in this case a JingPad). Photo courtesy of Sander: