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.

Hello jEzEk,

There are both technical and societal reasons as to why we have decided to not accept new features into the Xenial line of update anymore, even the ones which is developed against Xenial and is near ready.

First, the technical reason: due to a large number of changes involve in making all Ubuntu Touch components works with the new version of Ubuntu, compound with desire to realize the rename in this release, we've decided early on to have a separated branch of code for almost every component we have. Unfortunately, this resulted in a largely separated development between Xenial and Focal, and while one is busy making a component runs on Focal, another proceeds to add new features onto the existing codebase on Xenial. And because we didn't realize this problem early enough, this means now we have quite a backlog to visit. Also, since the code diverged a lot since we start the branches for Focal, sometimes it's not straight forward to port changes to Focal. So, limiting the amount of changes that enters Xenial directly reduces the amount of work needed to make Ubuntu Touch based on Focal a reality.

Now, the societal reason: as mentioned by many people above, we're a small group of people and unfortunately can't do everything at once. In addition to adding the amount of changes we need to carry to Focal, time spent reviewing changes for Xenial is time not spent developing or reviewing changes for Focal. Given that Xenial has been out of support for over a year at this point, it has become our priority to provide our users with the up-to-date base for the security of our users, and that means we need to reduce as much work as possible.

In addition, many people might consider Focal complete when it reaches feature parity to Xenial. However, if more changes keeps being added to Xenial, it becomes harder to realize that objective. Having to chase a moving target is not fun, and personally I already have that feeling when I realized that the contact backend changes will land in OTA-24. Fortunately that didn't happen in the end, but even for smaller features it can easily be unexpectedly hard to bring to Focal.

So, please accept my apology that we cannot accept more changes into Xenial line of update anymore. We want to have an up-to-date and secure operating system, and we cannot have that with an out-of-date base.

---

On the side of device support, the primary limiting factor at the moment is due to the inevitable change of the init system from Upstart to Systemd. Systemd uses a number of modern features of Linux kernel, and as such requires a (moderately) modern Linux kernel. The version of systemd requires Linux >= 3.13, however the recent version raised that a bit.

It's possible to backport certain changes into an older kernel to make systemd runs, but it's a tedious manual task that has to be done per kernel tree [1]. A rule of thumb is that if the device launches with Android 9 it should be fine, but for older devices one must check the Linux kernel version.

[1] For example, I've done such job on FP2, which allows me to run an old image of Plasma Mobile which uses systemd.

I've (re-)imported the changes made to Pulseaudio in Ubuntu 16.04. This primarily improves the experience of using Bluetooth headsets with the phone. However, there's a report of regression due to these changes before. I've fixed that one specific regression, but I'm not sure if there's any other regression due to these changes.

Please only test this change on a device running the latest images from the devel channel, and test responsibly! In other words, try it on a spare device or when you know you'll be near a computer you can use for reflashing. [1]

To test, please follow the instruction:

1. Mount a tmpfs so apt can breathe: sudo mount -t tmpfs tmpfs /var/cache/apt/archives
2. Install the repository: sudo ubports-qa install xenial_-_pulseaudio-updates-to-0ubuntu3.10
3. Reboot your phone.

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

You may want to also follow this test plan from Canonical if you want to be extra sure there's no regression: https://wiki.ubuntu.com/Process/Merges/TestPlan/pulseaudio

Note for OnePlus One users: 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.

Known issue: The issue that the playing streams won't switch to the headset after a re-connect is known, and will be fixed after this [2].

[1] This specific instruction courtesy of Dalton Durst.
[2] https://github.com/ubports/ubuntu-touch/issues/1045

As you might already know, I'm currently making GStreamer-droid works properly in Ubuntu Touch as a replacement for qtubuntu-camera. This will make video recording works for Halium 7.1 based port, as otherwise a set of custom patches on the Android side (which isn't easy to forward-port) is required.

How can you test this out?

If you're interested in testing this out, please follow these instructions:

Halium side preparation

Due to breaking API change in droidmedia, you'll need to make sure you have a recently-built Halium image. If you build your own Android image, make sure your Halium tree is recently synced as of 8 June 2020. Otherwise, please make sure you have the latest image built on or after that date.

Install GStreamer-droid

1. Make sure you're running the latest devel or edge channel image. If you're interested in testing video recording too, please make sure that audio for your port works correctly.
2. Run sudo umount /lib/udev/rules.d/70-android.rules. This prevents failure in the following step.
3. Run sudo ubports-qa install xenial_-_gst-droid to add the repository containing the packages. UBports-qa will upgrade the already installed packages to the latest version and install the new packages.
   • If you encountered unable to make backup link of '<a path>' before installing new version: Invalid cross-device link error, unmount it by running sudo umount <path without the prepending dot> it and try again.
   • The error ERROR:ubports-qa:Failed to remount root filesystem read-only. is normal and expected. Proceed to the next step.
4. Reboot your phone to make sure everything is in place.

Install updated camera-app

You'll also need the updated camera-app. To install, grab the correct binary for armhf or arm64, then install with pkcon install-local --allow-untrusted <file name>. UPDATED to version 3.1.3.

If you're interested in the changes I've made, take a look here.

How to debug

If things don't go as it should, you can add additional debug information by running the camera-app from the command line.

(cd /opt/click.ubuntu.com/com.ubuntu.camera/current && GST_DEBUG=droidcamsrc:4 ./camera-app --desktop_file_hint=com.ubuntu.camera_camera)

About the upgrading

Please note that by installing packages via ubports-qa or apt, you should not install system updates via the system settings app anymore (you'll overwrite this change otherwise). Instead, you'll need to use sudo apt update and sudo apt upgrade like on the desktop. This is temporary, and won't be required after this is merged into the proper xenial branch.

Also, even though this procedure works on devices on the stable channel, note that following this procedure essentially upgrades the entire device to devel channel. Please test responsibly and don't use it on your daily driver. This will be merged to the xenial branch soon and testing should be easier when that happens.

@Fla We're working towards that goal, but the base system requires more changes to support Halium 7.1 ports better before we can release any Halium 7.1 port as an official port.

This is a Halium 7.1 based port for Fairphone 2. The current port is based on Android 5.1 and has quite a few band-aids and workarounds. This port is completely new and isn't based on the current port.

Sources:
Kernel: https://github.com/Halium/android_kernel_fairphone_msm8974/tree/halium-7.1
Device: https://github.com/Halium/android_device_fairphone_FP2/tree/halium-7.1_ubuntu
Manifest: https://github.com/Halium/halium-devices/blob/halium-7.1/manifests/fairphone_FP2.xml (This manifest doesn't point to the Ubuntu Touch additions. Add revision="refs/heads/halium-7.1_ubuntu" to the device tree tag to retrieve them.)

Status:

• Working:
  • Display, Wi-Fi, Audio, Battery indicator, Bluetooth, Video playback, Vibration, GPS, Accelerometer
  • Camera (Needs gst-droid, see the instruction in another post.)
  • Audio (Headphone detection now works correctly.)
  • Cellular (Both SIM slots work. Voice call, SMS, MMS, mobile data works.)
  • Front LED (fixed in the rootfs)
• Not working:
  • Flashlight
  • Abysmal battery life with the Wi-Fi on.

Install:
No prebuilt image has been made yet. Thus, you're required to build the image from source.

This is a call for testing the updated Systemd package, imported from Ubuntu 16.04.

Wait, doesn't Ubuntu Touch still run Upstart? Well, systemd is far wider than an init system and includes an essential component (udev) for the system. Besides, some other packages are still installed in the rootfs.

Some of the imported releases are security releases, however, not all of them are related to the components Ubuntu Touch uses. I personally think it's still better to import all of them, as it'll be easier to import those that are related to us in the future.

I also improve our patch a bit by fixing memory leak and improve error handling.

To test out, make sure you're on the devel channel. Then, run:

sudo mount -t tmpfs tmpfs /var/cache/apt/archives
sudo ubports-qa install systemd-packaging 1
sudo reboot; exit

For more information, see the PR: https://github.com/ubports/systemd-packaging/pull/1

Hello,

I've pushed an update to the repository to fix an issue with the Bluetooth headsets without high-quality audio mode. If you have such a headset, I encourage you to test this new version.

Thank you to everyone for testing this out.

@Kyrylo Please make sure the Android image containing Droidmedia is up-to-date. If you use the image from system-server, you may have to re-flash the image to retrieve the latest Android image and re-do the instruction again.

@Stefano Please see the updated instruction. This should fix video recording on arm64-based images.

@ComLarsic I've updated the instruction to include the arm64 binary and the link to my modification. Thank you for raising that up!

Hello jEzEk,

There are both technical and societal reasons as to why we have decided to not accept new features into the Xenial line of update anymore, even the ones which is developed against Xenial and is near ready.

First, the technical reason: due to a large number of changes involve in making all Ubuntu Touch components works with the new version of Ubuntu, compound with desire to realize the rename in this release, we've decided early on to have a separated branch of code for almost every component we have. Unfortunately, this resulted in a largely separated development between Xenial and Focal, and while one is busy making a component runs on Focal, another proceeds to add new features onto the existing codebase on Xenial. And because we didn't realize this problem early enough, this means now we have quite a backlog to visit. Also, since the code diverged a lot since we start the branches for Focal, sometimes it's not straight forward to port changes to Focal. So, limiting the amount of changes that enters Xenial directly reduces the amount of work needed to make Ubuntu Touch based on Focal a reality.

Now, the societal reason: as mentioned by many people above, we're a small group of people and unfortunately can't do everything at once. In addition to adding the amount of changes we need to carry to Focal, time spent reviewing changes for Xenial is time not spent developing or reviewing changes for Focal. Given that Xenial has been out of support for over a year at this point, it has become our priority to provide our users with the up-to-date base for the security of our users, and that means we need to reduce as much work as possible.

In addition, many people might consider Focal complete when it reaches feature parity to Xenial. However, if more changes keeps being added to Xenial, it becomes harder to realize that objective. Having to chase a moving target is not fun, and personally I already have that feeling when I realized that the contact backend changes will land in OTA-24. Fortunately that didn't happen in the end, but even for smaller features it can easily be unexpectedly hard to bring to Focal.

So, please accept my apology that we cannot accept more changes into Xenial line of update anymore. We want to have an up-to-date and secure operating system, and we cannot have that with an out-of-date base.

---

On the side of device support, the primary limiting factor at the moment is due to the inevitable change of the init system from Upstart to Systemd. Systemd uses a number of modern features of Linux kernel, and as such requires a (moderately) modern Linux kernel. The version of systemd requires Linux >= 3.13, however the recent version raised that a bit.

It's possible to backport certain changes into an older kernel to make systemd runs, but it's a tedious manual task that has to be done per kernel tree [1]. A rule of thumb is that if the device launches with Android 9 it should be fine, but for older devices one must check the Linux kernel version.

[1] For example, I've done such job on FP2, which allows me to run an old image of Plasma Mobile which uses systemd.

@Isaac Sorry, forget to check the forum. One specific thing to test is changing timezone in the system settings. Other than that, just try using the phone as normal.

@tigerpro Do you have any update?

This is a call for testing the updated Systemd package, imported from Ubuntu 16.04.

Wait, doesn't Ubuntu Touch still run Upstart? Well, systemd is far wider than an init system and includes an essential component (udev) for the system. Besides, some other packages are still installed in the rootfs.

Some of the imported releases are security releases, however, not all of them are related to the components Ubuntu Touch uses. I personally think it's still better to import all of them, as it'll be easier to import those that are related to us in the future.

I also improve our patch a bit by fixing memory leak and improve error handling.

To test out, make sure you're on the devel channel. Then, run:

sudo mount -t tmpfs tmpfs /var/cache/apt/archives
sudo ubports-qa install systemd-packaging 1
sudo reboot; exit

For more information, see the PR: https://github.com/ubports/systemd-packaging/pull/1

@Fla

The biggest issue currently is that the phone tends to reboot itself when trying to power it off. The issue has been traced to be related to the Android container. However, I haven't looked into it further.

Other than that, there are some other issues I can't remember off the top of my head. There's also the USB mode issue, but that I prefer a more proper solution than the one currently implemented in other ports.

@Fla We're working towards that goal, but the base system requires more changes to support Halium 7.1 ports better before we can release any Halium 7.1 port as an official port.

@Luksus Thank you for bringing the version issue to my attention. I've rebased and released the new version based on version 3.1.3 (with version bump, of course). Also, I've also switched to GitLab-hosted link. Please report any problem on downloading the app!

@mihael Could you please test if the noise problem is a regression from the current version in the system image? You may do so by running ubports-qa remove xenial_-_pulseaudio-updates-to-0ubuntu3.10 or by re-flashing the phone.

If it's not a regression, I'll consider the test successful and proceed to merge this into the main branch.

Hello,

I've pushed an update to the repository to fix an issue with the Bluetooth headsets without high-quality audio mode. If you have such a headset, I encourage you to test this new version.

Thank you to everyone for testing this out.

@Kyrylo I guess you can attach the Gstreamer log in this thread. I believe it shouldn't contain any sensitive information.

@mihael Please follow the debugging instruction and send the log to me.