Creating an image for mobile device

Zzzz How can the repositories be used to create an image for the Pixel 3a, for example? We use Halium, which is a container for the bare minimum of Android drivers that we need to make hardware components in the phone work. It is built inside an Android open source project tree. For any Halium based device you need a kernel for that phone, you then need a specific build of that Halium container. The documentation describes how that can be done. Devices vary a lot so there is no standard off-the-peg solution which will work. A lot of adaptation is needed so it is quite a lot of work, with a lot of experimentation needed. The porting group is always ready to help you out with details. The build itself is quite fast but downloading all the components one by one is a pain.

The UT side is much easier because it is standardised and you can pick and choose from components if you want. The only complication is that we also need to build for ARM and that involves some cross-compiling. We would like better documentation around that. Newer contributors will find it easier to spot what is missing from the documentation.

Finding resources for a device build is one of the most difficult things. That becomes much easier if the device has a Lineage port because that project has done a lot of the work.

Aury88 asked several questions about Snap. Alfred is the expert on that and he was the one who referred to the obstacles. Libertine is much broader and interfaces directly with X11. To the extent that Snap works at all with UT it depends entirely on terminal, which is not very practical. Click works well. Replacing it would take a huge amount of work when we are already busy with necessities. It is hard to see any strong argument for a switch. Click is designed around utilisation of the hardware. Snaps really have no way to talk to the hardware, so there is a potential driver nightmare there.

OpenStore is based on Clicks, as is packaging and installing. There is a big infrastructure involved.

SnapD already works on Ubuntu Core so isn’t that a way forward? Well there isn’t a direct comparison. There are some parts of UT which are writeable but it is mostly write-only. Modifications don’t actually touch the system but paths are created in an overlay, much as with Snap Core.

How much work is needed to get Lomiri working with Snap OS? Goiny back a long way, there used to be a Snap package of Unity-8, so it is possible that we could build on that rather than starting from nowhere. Canonical are doing things with the Snap architecture, alongside Gnome. Maybe there are aspects of what they are doing that we can develop from? Snaps need a lot of access to the system and the apps on top of it need to know where to put their caches and buffers. Security is a major challenge because Snaps have pretty open access. In short it is very complicated and at this point it isn’t attractive to put a lot of time into it.

Basic functionality is far and away our top priority.

GT asked what advice there is for ordinary users about the timing of their move to Focal? Very simply – do it now. You can easily do it on device and it is as stable as the old version but with a future. There are maybe a few niche functions for which we don’t have a Focal app yet. If that is problem for you, go back to Xenial and flag up the problem. You can look at the Focal apps in OpenStore and compare them against the ones you are using now, to see if there are any important gaps.

After OTA-3 the system will be tweaked so that updates will automatically take you to Focal, without you having to select it.

External help

GT asked whether Sysmocom and Volla are still working with us? At the moment, all the heavy lifting is done by Marius. Of course there are many members of the community who are helping him. The problem at the moment is that the things being worked on are very complicated and very specific to UT. Only someone with an intense knowledge of the inner workings can really do this, so even if external help was offered, the work is too specialised for them to contribute much in those areas.

All the code written for VoLTE is closed source and even worse it is in Java, which doesn’t work on our system. The Java part is just a go-between. The vendor part could have been written in any language. The final stage is a SIP transaction but the problem is the messy and difficult stages before that. Finding anything that works is guesswork and trial-and-error.

Help with VoLTE

Messayisto asked if people can help out with VoLTE? Of course all help is welcomed and you can contact Marius on Telegram to offer. Realistically, he is very busy so response times are slow. We are starting from no information, so a pad where we can dump everything we find out would be useful. Everything uses binders, so searching for function calls is a nightmare. A practical consideration is that you have to run a UT system live alongside an Android system to sniff out the differences. Not many people have the luxury of having two identical phones which they don’t need as daily drivers!

Anyone who has any knowledge at all of VoLTE from any context will be able to provide useful clues. Just throwing ideas around in a small group can get things moving along more quickly.

App development

Attesa wanted to know about app development. They have finished an app but it runs unconfined and with a lot of privileges, so that is a problem. The workarounds suggested seem cranky. Are there any protocols which could be more generous towards unconfined apps? At the start there was never a plan to give UT elevated privileges, so we had to hack around to accommodate some. The result is not very elegant. A smarter solution might be valuable but we have no current plan for that. It would involve generating a task password for a specific app and a specific function. It would have to be built from the ground up and would be very sophisticated. The challenge is similar to running aGPS as a background service.