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.

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.

@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...)

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

@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.

@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

@RJDan Have you tried the waydroid helper app? I think it has workarounds for some problems.

@Eric-H There hasn't been any commit since then, if you want to re-build with a newer rootfs, without doing it on your computer, fork the repository and trigger the pipeline. I don't think it will work, if it did then the developer wouldn't say he gave up on it.
(I don't have the device myself, just explaining the procedure for anyone wanting to test the images.)

@Eric-H You don't have to build them, they are already built: https://gitlab.com/ubports/porting/community-ports/android12/google-pixel-3a/google-sargo/-/pipelines.

@RJDan You can encrypt them through terminal, the utilities are already installed. There are also apps on the OpenStore that can achieve this: tedit can encrypt text files, and enigma encrypts files with PGP, but it hasn't been updated for 20.04.

Was /data mounted correctly when you pushed the rootfs? Did you format userdata? Also, you seem to have overlaystore enabled but overlayfs in kernel is not enabled (unless I missed something).

Anyway, it is better for you to ask in t.me/ubports_porting, there are more knowledgeable than me people there that can help you, and real-time communication is preferred because porting can take a long time to succeed.

@arjune Yes, and make sure that /data is formatted to ext4 (with fastboot format:ext4 userdata) and mounted when you pushed it.

Be aware that the device will probably fail to boot on first try.

@arjune Yes, just flashing the 2 partitions is enough. Also, boot.img can be flashed in either bootloader or fastbootd mode, while system.img only on fastbootd (it is a sparse image).

TWRP says that boot.img is larger than target device

It should be flashed with fastboot flash boot boot.img, make sure deviceinfo_bootimg_partition_size is set correctly. TWRP is the recovery, I don't get how it is involved.

@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...)

@arjune Don't use the halium-install script. Use only the commands at the end of the standalone kernel method.
Build:

./build.sh -b workdir
./build/prepare-fake-ota.sh out/device_genia_usrmerge.tar.xz ota
./build/system-image-from-ota.sh ota/ubuntu_command images

Install:
Flash boot.img to boot partition.
If you have systempart in your cmdline flash system.img to system, otherwise push rootfs.img to data partition as ubuntu.img.

---

As stanwood said, the telegram porting group is more active.

@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.