Two years ago to this day, Canonical announced the discontinuation of Ubuntu Touch. But, you know, as a valued community member, that we have all worked hard to keep Ubuntu Touch alive and the project is stronger than ever.

We are proud to announce that UBports is now about to be granted the status of an official foundation that is recognized by the authorities in Berlin!

Read our official announcement here:
https://ubports.com/blog/ubports-blog-1/post/it-s-official-the-ubports-foundation-is-ready-for-launch-215

Thank you for all of your support, and we look forward to even better years to come.

TL;DR

• The revised Unity8 and Mir 1.x are coming in OTA-12
• You may wish to switch from the devel to rc release channel on any devices you're using daily.
• We might need to rewrite history on some git repositories. If this happens, we will keep a tag named xenial-before-2019-edge-merge to preserve the history.

The rest

We've been talking about "the Edge merge" for a while, and I understand that it is a rather opaque term to many people. I hope I'm able to answer your questions about what "the Edge merge" really is.

In short, what we'll be doing over the next few days is merging code which currently deploys to our Edge channel into branches which deploy to our normal release cycle. That releases daily into devel, which gets promoted to rc, which in turn gets promoted to stable. The next update on our stable channel will be OTA-12.

In order to understand why this is important, first I'll differentiate Edge from the normal release cycle. Ideally, most of our maintenance and feature work gets deployed into our xenial repository. This repository is used, along with the default Ubuntu repositories, to build the Ubuntu Touch images which land in devel. The Edge images are built with the xenial_-_edge repository overlayed on our xenial repository, allowing us to test large migrations before they impact a large number of users. So, at a base level, Edge is just devel with newer or more experimental packages laid over it.

Currently, we are using the Edge repository to test a huge migration away from Mir 0.24 and Unity8 from 2015 - as deployed in Ubuntu Touch up until now - to Mir 1.x and Unity8 from 2017 - the latter had begun to neglect phone users in an attempt to bring it to the desktop faster. That neglect caused a large number of issues which needed to be fixed. Having these changes built into images for every device every day (in Edge) for months has allowed us to iron out most of these issues.

We will also need to rewrite git history on the xenial branch in some cases, as the phone and desktop platforms diverged enough to prevent them from being merged cleanly. In these cases, we will save the old xenial branch in a tag called xenial-before-2019-edge-merge to ensure the history is preserved.

During this time, we will pause updates to the devel channel for all devices. This will prevent you from receiving an update which could be very broken and, possibly, render your device unbootable. If you don't want to come right onto the bleeding edge when we re-enable those updates, now is a good time to switch to rc or stable using the UBports Installer (don't check the option to wipe your device) or by heading to "Settings -> Updates -> Update Settings -> Channels".

Ubuntu Touch will have many fixes after this merge is finished, but it will also be broken in some new and interesting ways. Our goal as we reach OTA-12 is ensuring that the transition from OTA-11 is smooth. This will involve fixing those new and interesting issues.

Hi everyone,

It's been about two years since we added QtWebEngine to Ubuntu Touch, beginning the arduous process of replacing Canonical's Oxide rendering engine.

At the time, all of the webapps and HTML5 apps on the store relied on Oxide's unique quirks. Some expected the behavior from Ubuntu.Web, others explicitly imported Oxide libraries.

Since then, things have changed. We've become increasingly present on 64-bit ARM devices where Oxide simply isn't available. Many of our users coming to the platform now can't take advantage of these apps.

Many app developers have released their apps to take advantage of Morph.Web or direct QtWebEngine imports. However, I believe there are still some holdouts on the store... Either by lack of maintainership or by choice. The Ogra webapp container in particular only uses the Oxide rendering engine. Any apps made with it simply don't work on the PinePhone, Volla Phone, Xperia X, Nexus 6P, or many other new ports...

With this in mind, I propose that we make OTA-15 of Ubuntu Touch the final release which includes the Oxide rendering engine. In other words, OTA-16 should not include Oxide. That gives a roughly three-month period to transition any remaining apps to the new rendering engine (on top of the two years already provided).

Removing the Oxide rendering engine takes a pretty large, not-updated piece of code out of the image. That means smaller updates for everyone, more space in the rootfs to provide newer features, and a more secure device overall.

Is this timeline with OTA-16 the first non-Oxide update feasible? What else do we need to consider before its removal that we can prioritize for OTA-14 and OTA-15?

Hello everyone,

I'm pleased to report that the first Release Candidate image in the OTA-12 cycle will ship tomorrow (Wednesday, February 12).

RC 2020-W07 image will be the same as what users in devel have today. Please see our open issues board to find what to expect when you update: https://github.com/orgs/ubports/projects/15

For users of the rc channel, this will begin the weekly release cadence anew. You will find a new update waiting for you in System Settings every Wednesday.

For users of the devel channel, you will see no changes to the daily release cadence.

This brings us closer to releasing Stable OTA-12.

As always, we rely on our users of the devel and rc channels to discuss with each other about interesting findings they have, then move those findings into good bug reports. You can learn more about reporting a bug on Ubuntu Touch at Bug reporting on the UBports Documentation.

Thank you to everyone who has tested, filed, and fixed issues with Ubuntu Touch and the new Unity8 to help us get to this point! We're almost there!

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.

Edit: Most of the problems listed here have been resolved. See https://github.com/orgs/ubports/projects/10 for more details on what's blocking the merge of unity8+Mir1.1 into the normal cadence.

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'"

After https://github.com/ubports/unity8/issues/121 was filed and we've had not one, but many sour discussions about this or related topics, I figure we should try to slow it down a bit.

People are getting antsy (read: livid) about the changes to Ubuntu Touch in upcoming releases. In this post I'll try to tackle the issue of "home." More specifically, Where is home in Ubuntu Touch now?

The case for going home

Home, in terms of an operating environment, is the first place where a user arrives and a place they can return to. It's taken many forms over the years of personal computing:

• 7000 BYTES FREE, READY.
• $ (or C:\>)
• Windows' Start menu (Then its Start screen, then its Start menu again)
• Screens which are actually called "Home" on Android and iOS

The concept of Home is slightly different for every operating environment, but it serves a few important purposes:

• It is used to start other interactions with the environment (applications, for example)
• It is "returnable," a user should always know how to get to it. Now that operating environments are used for multitasking, this shouldn't be by destroying all running activities.
• It is "safe," a user should always know what to do once they get there

Home serves as an anchor point for the environment's experience. If the user gets lost or stuck, returning home should help.

The Dash

We can currently assert the following things about Unity8 on a mobile handset:

• Long swiping from the left of the screen always returns you to the Dash.
• The Dash is a window and is shown in the app stack.
• Due to the last point, the Dash remains focused when the device is locked and unlocked.

The dash is home.

The Drawer

The following things about those assertions have changed:

• We no longer have the Dash. Long swiping from the left of the screen opens the App Drawer.
• The Drawer is not a window and does not appear in the app switcher.
• The Drawer does not remain focused when the device is locked and unlocked.

It is consistent with our desktop experience.

But it's got everyone up in arms.

Where is home now?

By far, the most important question I see us asking ourselves (indirectly) is, "where is home now?" The answer... isn't straightforward.

Is the Background home?

Users will land in the Ubuntu Touch experience at the Background (NOT the desktop, which implies you may put things on it):

When arriving at the Background, the Launcher (some call it the dock) appears to greet them. The user may arrive at the background by booting the device or closing all their apps. By offering the Launcher, the background can be used to start other interactions AND it is safe. However, it breaks one of our main rules: There is no way to return to the background without destroying all of your activities.

Is the Drawer home?

The Drawer may be opened by long-swiping from the left of the screen or tapping on the big ol' orange button:

This can be done at any time. This makes the Drawer returnable. It is very simple, so I assert it is safe. And, well, it starts new interactions.

Something about it has people really uncomfortable, though. Maybe it's the fact that, unlike the Dash (or iOS' home, or Android's home), the Drawer is dismissed when you lock the device. This resonates with me a bit, a serial home-presser before locking my device. I like to start at square one whenever I pick up my phone.

Can we find home?

Does this add a new requirement to home? Does home also need to be durable (or comfortable?), lasting through transitions to lock states or other huge events?

Or, is this okay? Is this a case of a different design being more efficient? The ideal use of Unity8 is pinning applications to the Launcher, where they can be managed and switched between (even on the lock screen).

(Maybe the Launcher is home, or the lock screen!)

Home must be durable

If home must be durable, the Background is close to being home. The only problem is we can't return to it easily. There are an infinite number of ways to solve this, here are a couple I've thought of:

Go to background as an app

Hide apps appears as another window in the app switcher. It is always located behind the most recently used app, as shown here.

Go to background as an action

We discussed having Go to background as a specific action you perform on the app switcher. It could also go somewhere else, but there's nowhere to put it. This issue proposes having it be the "Cancel" action of the app switcher, when you tap in the blank space. That caused a lot of upset since it changes the current behavior (tapping in the blank space goes to the app you were just using, today you learned) and is not explicit (as a Python developer, I agree). Here's a way to make it explicit:

(It took me twenty minutes to make that, don't judge me)

Nah, this is more efficient

If home doesn't need to be durable to be home, maybe there is a way to offer an olive branch to people who think it does?

What do you think?

Does home need to be durable? If so, is the Background a good place to have that interaction? Is there a good way to get there?

How do we keep the home interaction consistent between phone, tablet, laptop, and desktop?

Note that "just add another setting to..." is not an acceptable compromise. More customization means more development overhead, makes it more difficult to support users (you might have to do this, or you might have to do that), and takes away from a consistent experience. (If you want to discuss this metatopic, please make another thread.)

Addendum: ground rules

You're talking about a bunch of colorful rectangles, remember. Take your time when replying and keep it respectful and on-topic. This is a good place to brainstorm, but make your ideas concrete with mockups rather than talking about them abstractly.

So, what have we learned this week?

• Everyone wants a home
• No one can agree on what home is
• Some people like the desktop "stuff on your desktop" paradigm, others hate it
• New Unity8 already provides features we're used to seeing on a home screen, but not somewhere that is a home screen

Quite a few shades of gray here. I don't think we'll be able to reach consensus for everyone without just getting in and doing something, then taking the feedback from that. It's really hard to describe dynamic functionality in words and sometimes it doesn't make sense until it's put in front of you.

Personally, I think Kugi said it best early on:

I guess I could live without "home" until we get a great idea that's really a game changer

Let's try some things out and see what sticks, starting at the simplest first. The best ideas will naturally float up and get traction behind them. As they develop past their initial stages, we'll see more development toward interfaces which are consistent at every point.

I must reiterate that (since my job title is "development manager" and I feel the need to protect the time of our paid and volunteer developers) I do not support adding lots more settings or compromising between ideas. I truly believe we can make one really good way to use a mouse, keyboard, and/or touchscreen on any size personal device and the only way we'll do that is by working together. If that is totally not to someone's liking, we are not the only mobile operating system.

So, to put what is next more concretely:

• We may experiment with Jan's idea to tap the background (it's only a few lines of code to change what tapping there does) and ask for feedback from small groups.
• Otherwise, we don't want to make any huge changes to new Unity8 before it is released to Stable the first time. We'll release then iterate.

Go out and make.

Edit: The situation is now resolved.

Hello everyone,

I regret to inform you that we made an oversight and allowed the Image Signing key for https://system-image.ubports.com expire. We are working to remedy the issue, but in the mean time downloading updates to Ubuntu Touch is not possible. You will receive a "FileNotFoundError" referencing a keyring file upon trying to update.

Only the on-device image updater is affected. Installing Ubuntu Touch using the UBports Installer is still possible. You may still update apps and use your Ubuntu Touch device normally. Since there has not been a recent stable update, most users are not highly impacted by this issue.

To ensure that this never happens again, we are implementing automatic checking of the image signing keys: https://github.com/ubports/build-scripts/pull/10

This post will be updated as new information becomes available. You may also track this issue at https://github.com/ubports/ubuntu-touch/issues/1120

Thank you, everyone. Thank you for being here, for reading this, for helping us create Ubuntu Touch, and especially for helping others when it breaks. I know that sometimes it seems like the requests for help never end or that people go off into the ether after their threads are solved... but I've watched many stick around, turn around, and help others. It's all thanks to you.

I'd like to open the floor... if you've had anyone that helped you while you were getting started, and you're still here, give them a ping to show them your thanks!

I'd personally like to thank @Flohack and NotKit (who isn't on the forum, bummer!) for greeting me back in September of 2016 and helping me create the ultimately failed Nexus 5X port. Even if my original goals weren't reached, I've had three years of fun and met so many amazing people thanks to your level-headed approach to newcomers. Also, of course I need to thank @mariogrip for the opportunity to dedicate my time to the project.

How about you?

I really had no plan for where best to express this information, so here's as good a place as any.

TL;DR: It's not ready yet.

First, some definitions to make sure we're on the same page:

• Roughly speaking, anything that is merged into a xenial branch on a Debian-style package in the https://github.com/ubports organization gets built and released to devel. This is what we mean when we say "edge merge" or anything similar.
• We expect ourselves to ship a release of Ubuntu Touch every 6-8 weeks, including 2 weeks for testing. This gives us 4-6 weeks of "open merge" time in a cycle where low to critical priority changes may be merged. During the 2-week testing period that changes to merging critical priority changes only.
• Releases of Ubuntu Touch move sequentially from devel to rc to stable. That is, Stable OTA-10 is the exact same set of bits as rc 2019-W33/2, which is the exact same set of bits as devel 2019-08-16.

This is the only way we can release software. Changes we merge into a package go into devel which must go to rc which must go to stable. We cannot easily or cleanly substitute in a certain old version of a package, for example. If we merge broken changes, our options are to revert those changes or fix them so they are not broken. That was the cause of OTA-10's delay: we merged some improperly tested changes and believed we could fix them faster than we could revert them. This proved to be false.

To make it crystal clear, if something is broken in devel, it will be broken in the upcoming stable.

I'm fairly sure that it will take more than a week to merge all of the changes from xenial_-_edge into xenial, get the packages built correctly, and get the release pipelines happy again. This takes anywhere from 1/4 to 1/3 of our expected cycle time, reducing the number of bugs we can expect to fix before we can release again.

I firmly believe "if you add a little to a little, you have a big pile" (attributed to Hesiod). Check out https://github.com/orgs/ubports/projects/10. It looks like a small pile of things. However, we know that, as very early adopters of the edge software, we are imperfect testers. We aren't going to catch every regression from devel to edge. That's why we release software to devel. Lots of people testing means more bugs filed and higher quality software. In this case, that would add a little more to our little pile. Suddenly it doesn't look like such a little pile of bugs any more.

We don't want to end up with that rush or crunch. It means lower-quality software for you. Our goal is to have the number of known bugs in edge to a minimal point at the start of a cycle so we can take our 1-2 weeks to merge from xenial_-_edge to xenial. Then we can fix the myriad bugs that people will find, because they're better testers than us.

If you want to help us, try out the edge channel and report anything strange you find. This might further delay the merge, but it will ensure a smooth transition and a faster release when the merge does happen.

Ah, I was wondering when someone would make something like this. Good thing it didn't end up being us.

I actually reserved enough space on the PinePhone to create a multi-boot scenario. There's an A partition and enough space for an equally sized B partition on every Ubuntu Touch PinePhone. Given that Ubuntu Touch is about half the size of all other PinePhone distributions out-of-the-box, no one seems to have taken umbridge.

I wonder what happened with OSTree that they felt they needed an A/B system instead? Seems like everyone was planning to go the OSTree route instead of reserving twice the space.

@ubuntoutou, what would you like to know about xnux.eu?

Thank you to everyone who helped make OTA-14 possible! Despite taking only 34 days of development time, this release is HUGE!

This changelog is a non-exhaustive list of changes in this release. It was compiled manually by auditing pull requests on GitHub to ubp-5.1 and xenial branches. You won't find it anywhere in the Ubuntu Touch system yet, we haven't got that set up to work correctly.

[Marius Gripsgard]

• Allow loading media_codecs from vendor partition: ubports/apparmor-easyprof-ubuntu#18
• Remove indicator-transfer's dependency on mirclient: ubports/indicator-transfer#2
• Support external displays on Android9/hwc2 devices: ubports/mir-android-platform#23
• Replace QString::null with QString(): ubports/history-service#31
• Allow building content-hub without Libertine support: ubports/content-hub#14
• Fix history-service building with -Wall -Werror -Wextra, fixes ubports/history-service#29 and more random crashes: ubports/history-service#30
• Pay back technical debt inside mediascanner2: ubports/mediascanner2#4
• Replace deprecated QByteArray::append(const QString &str): ubports/u1db-qt#1
• Use cmake-extras instead of duplicating its logic: ubports/history-service#33
• Add enum to handle mir_window_state_attached: ubports/unity-api#26

[JBB]

• Update extra-cmake-modules to 5.70.0 from 5.52.0: ubports/extra-cmake-modules-packaging#4

[Alberto Mardegan]

• Simplify media-hub build process and improve crossbuilder support: ubports/media-hub#13
• Modernize online-accounts QML: ubports/ubuntu-system-settings-online-accounts#12
• Fix building qqc2-suru-style in crossbuilder: ubports/qqc2-suru-style#50
• Always set up a video surface since we can't know if we need it or not: ubports/media-hub#5

[Luca Weiss]

• Print glib errors to assist in diagnosing test failures: ubports/unity-api#25
• Fix ubuntu-ui-toolkit deprecation warnings on Qt 5.15: ubports/ubuntu-ui-toolkit#72
• Make ubuntu-ui-toolkit compatible with Qt 5.15: ubports/ubuntu-ui-toolkit#83
• Don't hardcode path to python3 in ubuntu-ui-toolkit: ubports/ubuntu-ui-toolkit#70
• Replace qt5_user_modules with target_link_libraries: ubports/telephony-service#10
• Fix crash when using newer glib: ubports/unity-api#24
• Fix 'missing sentinel in function call' warning: ubports/ubuntu-app-launch#11
• Fix non-standard __environ usage: ubports/ubuntu-app-launch#10
• Link trust-prompt against libintl: ubports/trust-store#13
• Fix qmenumodel building. Just in general. ubports/qmenumodel#3
• Fix ubuntu-download-manager deprecation warning: ubports/ubuntu-download-manager#27
• Handle mir_window_type_decoration: ubports/qtubuntu#9

[Lionel Duboeuf]

• Fix duplicating attachments after adding a message recipient, fixes ubports/messaging-app#229: ubports/messaging-app#236
• Show the end of the message list when opening messaging-app to a conversation from another app, fixes ubports/messaging-app#240: ubports/messaging-app#241
• Add swipe actions back to multimedia messages, fixes ubports/messaging-app#238, ubports/messaging-app#230, ubports/messaging-app#221: ubports/messaging-app#239
• Fix escaping of output file name for contacts exports, fixes ubports/address-book-app#155, ubports/address-book-app#157: ubports/address-book-app#166
• Handle SMS/MMS messages being received without an explicit "sent date": ubports/telepathy-ofono#14
• Use message send date for timestamps, not receive date: ubports/telephony-service#9
• Hide the FastScroll list when using a contact's TrailingActions, fixes ubports/address-book-app#162: ubports/address-book-app#165
• Fix display of Birthday field on a contact, fixes ubports/address-book-app#152: ubports/address-book-app#153
• Force dialer-app to display in portrait, fixes ubports/dialer-app#6: ubports/dialer-app#131
• Clean up QML warnings: ubports/messaging-app#237
• Do not show "Online Account" information in dialer, it is not implemented: ubports/dialer-app#132
• Do not overwrite written text with a saved draft, fixes ubports/messaging-app#232, ubports/messaging-app#235: ubports/messaging-app#234

[Ratchanan Srirattanamet]

• Properly reroute audio to a Bluetooth headset on reconnect, fixes ubports/ubuntu-touch#1045: ubports/pulseaudio-packaging#5
• Fix crashing when user touches an app too early in its initialization: ubports/ubuntu-ui-toolkit#90
• Import systemd 229-4ubuntu21.28: ubports/systemd-packaging#1
• Fix crash if /etc/writable/localtime is not a symlink, fixes ubports/ubuntu-touch#1585: ubports/systemd-packaging#2

[Joan "Cibersheep"]

• Add splash image to External Drives app: ubports/ciborium#37
• Fix contrast of overlayTexts, fixes ubports/ubuntu-ui-toolkit#67: ubports/ubuntu-ui-toolkit#89
• Remove 'strokeColor' from buttons. It didn't do anything anyway. ubports/system-settings#250
• Make button text take on the strokeColor if it is defined, fixes ubports/ubuntu-ui-toolkit#85: ubports/ubuntu-ui-toolkit#88

[Rodney "dobey"]

• Make ubuntu-system-settings-online-accounts build: ubports/ubuntu-system-settings-online-accounts#13
• Make qt4 dependency optional: ubports/autopilot-qt#1
• Fix translations loading on indicator-network, fixes ubports/indicator-network#12: ubports/indicator-network#44

[Florian Leeber]

• Add Nexus 6P to UBports Installer
• Change "Ubports" to "UBports" in Halium-7.1 recovery: ubports/android_bootable_recovery#10

["Guf"]

• Add Xperia Z4 Tablet to UBports Installer

["filman230"]

• Fix build on cmake 3.1 and newer: ubports/biometryd#2

[Dalton Durst]

• Allow access to qt5 translations and libraries in /usr/lib or /lib: ubports/apparmor-easyprof-ubuntu#17
• Skip test_drag_indicator_item_down_shows_menu to work around ubports/unity8#334: ubports/unity8#335

[Willem-Jan de Hoog]

• Send a default album art to indicator-sound when none is found, fixes ubports/media-hub#6: ubports/media-hub#7

[Jonatan Hatakeyama Zeidler]

• Add information on using utqemu Ubuntu Touch virtual machine, fixes ubports/utqemu#5: [ubports/utqemu#6]

[Mateo Salta]

• Fix morph-browser fullscreen mode on Wayland devices: ubports/morph-browser#378

[Alfred "fredldotme"]

• Allow reading media-hub codecs from /vendor: ubports/media-hub#17

[Michele "mymike00"]

• Remove unreachable code: ubports/ubuntu-ui-toolkit#96
• Make Dialogs follow the system theme and dim the background differently, fixes ubports/ubuntu-ui-toolkit#91: ubports/ubuntu-ui-toolkit#97

["NotKit"]

• Only switch to the speaker and wired headphone port for ringtones if it's available: ubports/telephony-service#12
• Fix physical screen size calculation on Android 9 devices: ubports/mir-android-platform@732621fe

[Kevin Keijzer]

• Add "Screenshot" button to Power menu: ubports/unity8#329

[Jami Kettunen]

• Add support for Volla Phone flashlight: ubports/indicator-power#34

Hi @Fla,

It is unfortunate that we didn't find that in time for OTA-13, but since it is already in stable I don't believe it is a reason to cancel this update.

@Manchee1017, your DRM keys are gone forever. The OEM binary/image contains proprietary drivers and firmware that Ubuntu Touch needs to work correctly. It does not contain DRM keys.

The OEM image must match what Ubuntu Touch is expecting or else it won't work properly.

If your phone doesn't work after flashing the OEM image, you can flash a different one from fastboot.

Those appear to be normal, @evilbunny.

[  104.550108] audit: type=1400 audit(1603794497.811:53): apparmor="DENIED" operation="mkdir" profile="geocaching.evilbunny_geocaching_0.0.13" name="/opt/click.ubuntu.com/geocaching.evilbunny/0.0.13/py/__pycache__/" pid=5425 comm="QPythonWorker" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011

Here your app is being denied the ability to create its pycache directory in /opt/click.ubuntu.com/. This is expected, the only directories you have permission to create files in are its named directories in ~/.cache/, ~/.local/share/, and ~/.config/.

The rest should be unconcerning unless you run into a problem in some app functionality.

Aha, I see. There was an apparmor package in xenial_-_edge that could be removed. The new version should filter in to the image with its next build.

@evilbunny

It should be on the devel and rc channels already. If it isn't let me know, I've got some investigating to do then.

Hello everyone!

The expected release date for Ubuntu Touch OTA-14 is Wednesday, November 4.

This forum post is a companion to the upcoming OTA-14 call for testing blog post.

Please post any general observations you have while testing the current image in the rc channel, as compared to OTA-13, in this thread. The current release candidate (rc) is 2020-W43

If you have any comments on any of the specific issues in the OTA-14 tracker, please post them in the issue thread so they are easier to track. OTA-14 tracker: https://github.com/orgs/ubports/projects/23

Please note that only critical and security fixes will be able to enter OTA-14 as this point, normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

This is a bit of a late reply, but I believe we've fixed this issue with https://github.com/ubports/apparmor-easyprof-ubuntu/pull/17. It will be part of OTA-14.