Hey everyone,

I wanted to give you an update from the developer team in case you aren't following the development of Ubuntu Touch very closely. To get to it quickly, it seems like we won't be able to deliver an update to Mir 1.0 or higher in Ubuntu Touch OTA-8.

There's a bit to unpack for this one. The best technical explanation can be gained from others on the team, but you're going to get me for this one.

The big problems

Apps rarely display

The most glaring issue is that apps are rarely able to display anything on the screen. They start correctly and can almost always be interacted with, but only a black box is displayed. Resizing windows in desktop mode leads to many fun effects.

To paraphrase, it seems like there is a race condition in Mir getting a display surface (a box which the app uses to draw stuff) from Android before it has to pass it to the app.

This problem is mainly exhibited on devices with Qualcomm chipsets.

Poor performance

Some actions are extremely slow. When apps display correctly, they have a very low framerate. Pulling out the dock and the app launcher is painful. There really is no excuse for this, newer versions of Mir are much more efficient than our current 0.24.

Interestingly, the performance of the indicators is almost perfect. They feel way better to use than they do under Mir 0.24. In fact, the lowered input latency of Mir >0.26 is noticeable when scrolling around the indicators. This shows us that the failures are within Unity8 itself -- Mir is functioning perfectly.

We should have known

These challenges aren't entirely unexpected. The Android->Hybris->Mir->QtMir->Unity8->QtUbuntu pipeline can't be expected to be perfectly stable when several parts of that stack change all at once. We were over-optimistic when estimating how long it'd take to solve the problems upgrading Mir and Unity8 at the same time would bring.

What's next?

I'll change gears and focus on delivering some more fixes to OTA-8 before wrapping up. Marius will continue working on Mir and other intense low-level issues.

This cycle has included a lot of behind-the-scenes fixes as we've been fixing up automated tests on many components (especially the Ubuntu UI Toolkit -- Thank you Rodney!), allowing us to bring on new code. I've been merging in some rather old PRs (sorry for the wait, everyone who opened those) and I hope to continue to clear the queue for this release.

Tomorrow we'll merge the changes from our xenial_-_edge_-_mir branch into xenial_-_edge. This will cause any Qualcomm devices on the edge channel to experience the problems I listed above (and could cause general instability on other devices). It will be difficult to update Qualcomm devices without having developer mode enabled (which I hope you have anyway, you're on the edge channel). If you are using the edge channel and are not tolerant to these issues (I question how you got on edge in the first place ), please move to rc or stable using the options in System Settings.

If you're not sure whether you're using the edge channel or not, you probably are not. The current release channel is listed in "System Settings -> Updates -> Update settings, 'Channels'"

@Flohack said in "UbuntuTouch" name:

There are no plans to change the name

There is no need for more discussion on this topic at this time. I'll lock the thread to reduce noise.

This bug is already reported: https://github.com/ubports/ubuntu-touch/issues/291

There is another report linking it to the sync of the contacts and calendar, but I'm not able to find that one right now...

Is the bootloader on your phone still locked? That is listed as "LOCK STATE" on the fastboot screen.

Hello everyone,

Sorry about the short notice, but we'll be taking this forum down for maintenance at 1930 UTC (about 30 minutes after this post) today, the 7th of February 2019. We're not sure yet how long this maintenance will take, so stay tuned for updates.

EDIT: The maintenance has been complete. Welcome back to NodeBB

I know that we generally like to keep the dreams flowing in design threads, but I see multiple problems with this design:

• It appears both the left and right swipe areas are used for events which are not unlocking the device. This is a huge change from the current design to start with, but it is also much different from the rest of the OS.
• The dock comes from the right rather than the left, and it appears to not match the current dock
• The design as a whole doesn't really match the rest of UT. I think "Sailfish" right away, actually... convoluted gestures included

Also, I know it's probably not a very popular opinion, but I really prefer the Ubuntu Touch lock screen without notification access. Checking my notifications is an active action that I must choose to perform now. On other platforms it's a passive distraction for me. I've found myself unbound from my Ubuntu Touch phone, unlike my Android phone.

Hello translators!

It's been a while since I could say this, but translations of the UBports Documentation are updating again. You can find all the details at UBports Docs in Weblate.

The documentation is much more intense than most translation. Whole paragraphs are presented to translate at once and a single change to any word will invalidate all previous work. Also, Sphinx does not strip out its formatting when creating the translation files. Please be careful while translating the documentation and never remove formatting characters, such as:

• `
• <>
• _

I would like to add that if either device is connected to Wi-Fi, it will degrade the speed and reliability of any transfer. Bluetooth uses the 2.4Ghz Wi-Fi radio to send and receive transmissions. Any use of the radio could cause a break in communications long enough to lose the transfer.

Also, other devices using 2.4Ghz Wi-Fi in the vicinity could cause further problems. It is best to make your environment as Wi-Fi quiet as possible to avoid interference that could change the results of your tests.

So:

• Perform the tests away from other active Wi-Fi devices
• Do not download files or stream video or audio from the internet while attempting to transfer files with Bluetooth

Hey @chrisc, the issue you opened has been closed. Can you check to ensure it is working correctly?

Today I was trying to test Bluetooth for this issue request, to see if I could find some patterns to how it worked or didn't work. I figured I'd get a large enough file and transfer it around, see what happens. I started with the Fairphone 2, then thought I'd compare against the Nexus 5, then I got carried away.

My test file was Aury88's Infinite Sea. At 6.4MB, it's a hulking file for a slow protocol like Bluetooth. If I was going to cause an error, this would be the file I'd do it with. The only app available to facilitate file transfer over Bluetooth is Bluetooth File Transfer from Ian L. I shared the image to it from the Gallery, then used it to ship the file everywhere.

I tested file sending and receiving from multiple devices:

• FP2 running Ubuntu Touch
• Oneplus One running Ubuntu Touch
• Nexus 5 running Ubuntu Touch
• Nexus 5X running LineageOS 15.1
• Moto X 2013 (ghost / XT1060) running Android
• Asus T300 CHI running Windows 10
• A desktop PC with a Qualcomm CSR8510 Bluetooth dongle, running Kubuntu 18.04
• A Dell XPS 13 9370 running Pop!_OS 18.04

For all of the Ubuntu Touch devices, I had to pair them using Bluetooth settings before I was able to send files. For the Windows device, I had to open "Receive files" from the Bluetooth menu in the notification area AND have Bluetooth settings open. The Plasma desktop required that the Bluetooth adapter was in "Visible" (discoverable) mode while GNOME required that Bluetooth settings was open.

The transfers worked in many cases. Here were my observations in cases where they did not:

• Fairphone Two
  • To Oneplus One -> Failed (local obexd says: obexd[2616]: Unable to find service record)
  • The bluetooth daemon occasionally segfaults and won't restart.
• Oneplus One
  • Once a connection or transfer failed, the device sometimes needed to be rebooted for Bluetooth to become reliable again. It would not reboot cleanly and required I hold the power button or issue reboot -f.
  • To Nexus 5X -> Failed (local obexd says: obexd[2433]: Transport got disconnected, Android says Request can't be handled correctly)
  • To FP2 -> Failed (local obexd says: obexd[2433]: Transfer(0xb75c1bd0) Error: Timed out waiting for response; obexd[2433]: Transport got disconnected, remote obexd says: https://paste.ubuntu.com/p/8RhvqPfFYb/)
  • To Nexus 7 2013 -> Failed (local obexd says: obexd[2300]: connect error: Connection timed out (110), remote says nothing. Pairing or telling these devices to connect is not reliable. Bluetooth on both devices became unstable after a connection attempt and they had to be rebooted to resume normal operation. https://paste.ubuntu.com/p/BVPgM33MXT/)
  • To XPS 13 -> failed (local obexd says: https://paste.ubuntu.com/p/Z7drPW2ZFN/, remote says nothing.)
• Nexus 5
  • To desktop -> failed (device locks up after failure, does not output any log messages)
  • To Oneplus One -> Failed (local obexd says: obexd[2616]: Unable to find service record)
• Nexus 7
  • Some Bluetooth service occasionally crashed and required a reboot of the device to continue, the following log would appear from the Bluetooth file transfer app: https://paste.ubuntu.com/p/ryGmbRcgRD/. The device would not reboot normally and required I hold the power button or issue reboot -f to force a reboot.
  • I stopped testing more since this crash kept occurring. Someone would have to continue to look for the appropriate logs, then file a bug with the information they found.

There were some cases where a transfer would start, get about 25-50% done, and then time out and fail. On a retry, the transfer would be successful. I did not list those here because turning off other Bluetooth or Wi-Fi devices in the vicinity seemed to make these cases succeed more reliably. I suspect interference is to blame.

Overall, I was mostly impressed with Bluetooth file transfer performance under Ubuntu Touch. In any case, it was not less reliable than any of my previous attempts from Android to a desktop operating system or Android to Android... except on the Oneplus One and Nexus 7.

I'd like to open the floor to others on this issue: Try transferring files around between your devices and see what happens! The relevant logs are:

• Obexd / bluez: logs to /var/log/syslog
• A Bluetooth service log can be found at /var/log/upstart/bluetooth.log, but it doesn't seem very useful.

Use tail -f to watch these logs as you perform the file transfer, then collect only the messages that appear during or after the failed transfer. That will ensure we can find any pattern in the failures, and possibly a bug to fix!