As we near the OTA-6 release, I would like to gather what I believe are the most important points from this post: Everyone wants "release faster", without a doubt. "Release faster" depends on having enough confidence that software being released to stable is well-tested, which we do not have. Some things which would translate into more release confidence include: Automated tests on all system components Integration tests between system components Automated full-device testing, such as Canonical's fabled "Frankenstein device lab" Formalized manual testing by users who can confirm stability Even with full release confidence (but especially without), an automatic release model requires the ability to roll back to a previous version of apps and the full system image Aside: I want to experiment with one of the new atomic release models like OSTree which allows agnostic packaging formats to be installed on top. From my quick foray, I see: Benefits: Automatic and manual rollbacks, automatic diffing, and switchable roots Drawbacks that make this a long-term or impossible idea for our existing devices Probably requires newer kernel versions than 3.4 or 3.10 We don't have enough engineering power to concoct a solution which would allow converting a system-image system to OSTree in-flight, so we'd probably require users to manually switch. I think that bringing up the edge channel as a place to do a large migrations out-of-band with the normal release cadence is going to have a huge impact on how quickly we can release in the future. Previously, @mariogrip's work on bringing us to upstream Libhybris would have had to wait until after OTA-6 lands, and then it would have delayed OTA-7 until we had proper confidence in it. With edge, we can have people help us test these huge changes with the ability to roll back and without disrupting current users. To respond to my earlier hindsight: OTA-6 was not (yet ) taken away by TDS. We did not hit the original deadline set, but we will still be within our 6-8 week cycle when it releases. This includes our testing and release admin stage, which we are currently in. All of this while I'm not sweating bullets from pushing a release on ourselves before we're sure we're ready. We have ended up in "Gotta release slower" in this cycle without a doubt. I hope to make the improvements we've identified here so "gotta release fast" can become a reality. I also hope to be able to take our release management up so that we hit 2-4 weeks development, 2 weeks testing. This means we'll get faster releases, but we still won't hit fast releases. Important note for anyone interested in contributing to... basically anything I've said here: I'll be holding an OTA-7 development meeting at the start of the cycle where we'll discuss how we want to improve during the OTA-7 cycle and taking bugs from the tracker for the release. Only assigned tickets will be added to this milestone, so if you have a pet bug that you want fixed now is the time to get involved to help fix it! Subscribe to this GitLab issue for more information as the day draws nearer.

You're not that horrible, @unisuperbox.

@dobey said in Language packs as click packages: call to arms!: @mardy Are we discussing language packs as clicks, or a more general solution to "what apps are installed by default" when flashing a phone? Because those seem like two separate things, and we should not use one of them as a reason to do another thing (or to not do some other different thing instead), I think. I'm not using one as a reason to do the other, but rather I'm explaining how I imagine this evolving into, to convince you that we can get a nice user experience even with selectable language packs. I also disagree with the idea of anecdotal argumentation of well, it's a waste in the rootfs for me, so why should it be there for others. I think it would be best to not go down this route. There are plenty of things in the rootfs which are meaningless for me too. And what I'm suggesting is that, if those things could easily be installed as clicks, and if doing so would save a considerable amount of space, then it's something we might want to try out. It's a question on whether it's worth the effort. I did start with language packs because I thought that it would be an easy pick, since they are data-only. And so far it looks like it's something easily doable. [...] Maybe having langpacks is something we will need to do in the future. But I think right now, we should not rush into this as a solution to the problems we have, as there are plenty of larger concerns at the moment. And if we rush into it, we will be stuck for a long time, even if we discover some other solutions to whatever problem this is meant to solve, instead. I'm not requesting that people spend their time on this. If @bhdouglass told me that he has no time to review the changes I'll eventually submit to the Open Store, then I certainly wouldn't force him, but it looks like he likes the idea as well. And I'll try not to rush: I do want to see a good implementation of this (especially because, as I said, I plan to apply a similar scheme for navigation data, later on). Could I spend my time in a better way? Probably, but I'm doing this as a hobby in my spare time, so I tend to work on those things that interest me first

I tried to find a pattern to reproduce this issue. But there is none. The best way is to restart the phone, open the browser + uapp-explorer+youtube-app. Load something and begin switching. Mostly it works in the actual RC channel well, then something starts hanging which makes the browser restart and reload the startpage. Same thing happens with browser+N5-camera that crashes. Email i didnt test since dekko2 has problems. I also saw with systemsettings., but not often. Could be an out of memory issue, but i could not trigger it...

Hi! I don't think there are any tutorials out there, but the source for all the different calendar layouts are here: https://github.com/ubports/keyboard-component They are basically collections of qml files, but that's about the extent of my knowledge.

The recovery image is based on an older version of TWRP. However, as UT is not an Android ROM, we cannot really support most of the features of TWRP which are designed around Android, rather than alternate systems. This is why the recovery is stripped down.

Just a little sideways move to a better location.

@domubpkm Morph Browser is found in the RC channel as well - more stable than the developement one...

@flohack Perhaps I misread the canonical write-up as to why snaps couldn't run then, but I was under the assumption that snaps couldn't work on the Flo because of some LXC features being unavailable. If that's incorrect, that's awesome and makes me wanna try to get Anbox up and running on the Flo! I was also unable to create a LXC container when I attempted on my Flo last, claimed it was missing some sort of kernel support (I can't remember the exact message, but I'm going to be reinstalling UT here soon, so I can attempt again!) and was the same reason Libertine hardcoded itself to chroot if running on a vivid-based device iirc (unless I misunderstood that requirement, in which case, my apologies for the misinformation then!) Also, I mis-spoke in my previous reply, Flo is on 3.4.0, not 3.5.0 ^_^; (EDIT: I also want to mention that I had forgotten to state that I was writing using what I had thought was the case from Vivid, I admit I haven't tried LXC on Xenial yet) Btw, I'm literally ALWAYS happy to learn, so if I'm incorrect about ANYthing, please don't hesitate to correct me and let me know. I realize I'm human and can misunderstand what I read a lot. EDIT: just finished attempting LXC inside UT, nope. fails initializing CGroup support, and libertine-container-manager claims "System kernel does not support lxc type containers. Please either use chroot or omit the -t option."

Treble is more about easing the process of updating the device and making it harder for an update to brick the device. Treble requires the phone to maintain two system partitions, similar to ChromeOS. When an update comes in, it's applied to the unused system partition and then boot is switched it it. Unfortunately, it doesn't solve the issue of drivers because, as stated above, it's simply a more safe and efficient update system. The drivers are still installed via the system update being applied to the unused partition as they were traditionally (they'd have to be, otherwise you'd have say 7.1 blobs on an 8.x systemand be unable to boot), and not coming from someplace else stored on the phone. So sadly, other than making use of Treble's A/B partition update style, it doesn't help the issue of propreitary blobs.

@Flohack that explains a lot then. I had tried previously to being up Halium with the mainline Flo kernel and had problem after problem because the Android image wouldn't compile under it due to some missing APIs that the camera libraries we're expecting. Good to know it wasn't because I was being an idiot and missing repos or something like that!

@jezek : Hum, I don't know ... It seems to be scripts using rfcomm. bt-serial : Connects to a specific RFCOMM based service on a remote device and then creates a RFCOMM TTY device for it Not installed by default I think. So, a bit out of scope. Best regards Pulsar33

Hi @Andreas-Pokorny, I know you've made some progress updating the hybris/android platform. Could you post an update?

This channel would be useless to me and to many other developers, but if it brings benefits to halium developers, then why not. But then, why not call it "halium", "porters" or some other name that makes it clear what its target audience is? "edge" to me means "more ahead than devel", but there's again the assumption that packages from this channel will eventually end up in "devel", "rc" and "stable"; so, I would suggest a different, more specific name.

The information provided here: http://docs.ubports.com/en/latest/userguide/dailyuse/anbox.html doesn't mention the Nexus 4. Since it's been edited 3 weeks ago, the aticle is still up to date, I guess.