Battery life is usually less than expected due to unoptimized software and processors clocking too high. On my devices, I set the CPU governor to 'powersave', which reduces power usage but also performance.
There are multiple scaling governor settings which might not be available on all devices (depends on kernel configuration)

• performance : high frequency; slightly increased performance and battery consumption
• powersave : low frequency; reduced performance and superior batter life
• schedutil : changes according to the scheduler (default on my device)

This command list the available governors to set for each core (should be more than those I listed above)
sudo cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
Report which governors are currently selected for each core:
sudo cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Set the scaling governor to powersave to every core:
echo "powersave" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

The commands above do not need mounting root as read-write, any change is reverted on reboot.
I tried to make an app for configuring these (a while ago) but I had trouble with sudo.

@captainfunk said in Ubuntu Touch Q&A 168 call for questions:

Are you thinking or planning to implement the screen rotation to 180 degrees ?

It depends on if the porter enabled it. The configuration file is located on /etc/deviceinfo/devices/<codename>.yaml. Taking the Volla X23 configuration file as a random example:

  SupportedOrientations:
    - Portrait
    - Landscape
    - InvertedLandscape

As you can see, there is no "InvertedPortrait" mode enabled. I don't know adding it below will work.

---

Edit: (sorry, just noticed the Q&A was 3 days ago...)

It will also support mainline Linux (like the pinephone) as the patches have already been submitted: https://www.phoronix.com/news/Fairphone-6-Linux.
I suppose the Ubuntu Touch port will be Halium based but it is certainly nice anyway.

@Twigg Many questions indeed, I will try to answer them as accurately as I can, so if anyone knows more, feel free to correct me.

Before answering your questions, I think it is necessary to clear any misconceptions about the Android kernel.
Most Android devices don't support mainline Linux, so the upstream kernel can't work on the device, as it is missing specific drivers and device trees. That is because the SoC manufacturers (Qualcomm/MediaTek) use an older kernel as a base to test their new designs, and that old kernel is subsequently used by the device manufacturers (e.g. Fairphone). Of course, neither of them bother isolating the changes to create a pull request to upstream Linux (due to costs etc.). As a result, Ubuntu Touch developers have to do extra patches to make the downstream patched kernel work for them.

Does you mean that the FF5 did not support mainline Linux?

Yes, Fairphone officially didn't, but the community has (see the PostmarketOS port)

Why the change with FF6?

I don't know. Maybe they hope they can attract more Linux enthusiast (like us).

I wonder about the advantages/disadvantages to using mainline Linux vs the Hallum approach

Mainline Linux enables more flexibility and a desktop-like experience. However, it is more difficult to make everything work there, postmarketOS is a great example, as almost none of their devices currently support the same hardware features as they did on Android. Not even Qualcomm themselves have succeeded in fully working mainline Linux kernel, as the recent Snapdragon X Elite chips which were made to compete with x86 still don't have full Linux support.

Halium on the other hand uses the same downstream kernel as Android does, with some adaptations for Ubuntu. It also runs the Android drivers on an LXC container, which allows easier access to hardware. As you can imagine, this has limitations, as we can't change the Android drivers and pulling patches from upstream Linux can break functionality.

I presume that this amounts to a desktop equivilence to doing a clean install of Ubuntu, vs installing it in Windows?

I don't get your analogy. It would be more accurate to say that to install normal Ubuntu, you have to reverse engineer the Windows drivers. However, in Ubuntu Touch's case we can reuse the Android drivers as the Linux kernel remains mostly the same.

From what I have read above, it looks like there haven't been too many changes from FF5 to FF6, so perhaps that makes it easier for Ubuntu Touch to get released on the FF6?

Each device needs its own port, sometimes even devices with the same chip require very different ports. In this case FP6 seems vastly different hardware-wise than FP5 so I don't think they would be similar software-wise.

@mihael In the same directory normal Debian-based distros with NetworkManager do:
/etc/NetworkManager/system-connections/WIFI_SSID.nmconnection

@Salah I believe it should work fine, as these icons neither large (to fill the partition) nor a dependency to something.
I had modified lomiri's qml by editing some files, and there wasn't any issue.
You can try, and if it fails reflash.

@ds2k5 You can enable the SSH server from UT tweak tool.

@wally Just ported the app to 20.04, changing icons works!
This is the new repository: https://gitlab.com/ikozyris/custom-phablet-tools,
I plan to publish it to the open store if it works for others as well.
Took me ~2 hours.
I might add a way to add custom icons, currently they are downloaded from https://framagit.org/ubuntouch-fr-dev/custom-phablet-tools/raw/media/icons/[APP-NAME.EXTENSION].

@Salah I'm currently rewriting the backend to not require remounting as read-write. Currently this arm64 focal .click works. Screenshot:

@Salah said in Customizing Icons:

If you go to icons folder, you well see several icon folder with icons including the main one which if officially used (suru) and they are not used.

These are available if you click on the top-left icon. Select one from the list

Salah said in Customizing Icons:

have installed it, which apparently not available in Open Store

I submitted the app to the OpenStore, but I was suggested to rewrite the scripts so they don't require remounting the rootfs as read-write. I have made some progress, and the icon names had to be renamed. So the old versions don't work, unless it fetches the icons from a snapshot of a previous version. I can easily fix the hacky version temporary to work fully, but better way for the newer, cleaner method, which is WIP.

Salah said in Customizing Icons:

Is there any way I can Add my icons to this app !!

Yes, you have to rename your icons to match the names of those in the repo. Put them in a folder. Then write that path (absolute path and the last /) in the text box below

@domubpkm uWolf should support DoH, it may even be default. For other apps, the standard linux way (edit /etc/resolv.conf) will always work, and this is what the script you are referring to does.

@Simmonz If you are familiar with mtk client you can unlock the bootloader from there too since Volla devices have mediatek chipsets.

@techwryte It has already been ported to raspberry pi 3/4. See rootfs builder repo. You can build the raspberry image yourself, or grab an older image . I think the default rootfs would also work if you keep the fat partition.

@oldpaint That's the default for Ubuntu 20.04, the new 24.04 images have gcc 13.

@ANDROID2468 There are images for pinephone, pinetab and pinebook. However both pinephone pro and pinetab 2 are supported, so probably the image works for both pro and non-pro?
An older (2023) image is certainly for both phone versions: https://gitlab.com/ook37/pinephone-pro-debos/-/jobs/5124896891/artifacts/download?file_type=archive .

@ANDROID2468 Are you looking for this: https://ci.ubports.com/job/rootfs/job/rootfs-pinephone-systemimage/ ?

Did you fork the repo? If yes, you can push your commit to your copy. Then go to the gitlab ui and make a merge request (there should be a blue button to do that right after you push your commit).
You can also search for how to open a merge request in gitlab documentation and your favourite search engine.

@atarilinux The cp error is normal and happens on all builds, the actual problem is the last one. From my understanding based on an older discussion in the porting telegram group, the retrofitted partition is used for older devices which didn't have the new super partition. However, it shouldn't be impossible to get it working, as others got their device booting, mounting the android partitions is necessary only for getting the android container running.

Anyways, more experienced people are active on the telegram group, so you may want to ask them.

@atarilinux All modern UT devices already work with the super partition. I don't understand what you mean by "implementing" it, the only thing UT has to do is mount them, which is already done.

I am not sure of this is related, but have you formatedthe data partition to ext4?