News and Update
Marius and AppLee presented.
Volla Phone are one of our long time sponsors and they are offering a chance to win a Volla 22. In addition they are donating €10 to Ubports for every phone sold with UT pre-installed.
A first meeting of an introduction to Ubports group took place recently by video link. The purpose was to explain to newcomers how they might get into being a UT developer or helping in other practical ways. At one point there were twenty people in live chat. We will be holding more of these sessions so watch out for opportunities to join. They will be posted on the Forum and on the News channel. If you are not a developer you can still get involved with testing, documentation and other activities.
A build of UT has been merged, for Pinephones and PineTab 2.
A memory fault in VideoRecorder has been fixed. This will put an end to some crashes while watching video. Rachanan had to dig deep into libhybris to figure out what was going wrong. Alfred fixed a bug related to video decoding in the browser so that has also contributed to stability. The next OTA should contain a lot of browser improvements, including hardware optimisation. 4K videos will now work nicely on more powerful devices.
Marius has done more work on the high level road map for the next three or four months. aGPS has been mentioned before. Bluetooth in general is an issue for us but audio is a special priority, including in-car use.
Sponsors were thanked. We are truly grateful for every donation and making a donation is very easy to do. Select one of our options.
The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat,Telegram and Matrix are other places to post a question.
If you didn't know, the Forum questions get priority.
How GitLab and GitHub are organised
AppLee asked Marius to describe how GitHub and GitLab are organised and how we use them in the development of UT.
There is still some content on Github, in the form of repositories. Those are a kind of folder which contains resources but also bug reports and pull requests. A pull request is simply someone wanting to add code to a repository. The main thing we have on there still is the infrastructure server. Eventually we will move that to GitLab too. It is the ‘building operation’ and alongside it is the Installer support. In the case of the Installer, it is a rare use by us of the Snap architecture and since GitLab doesn’t support Snap, we have to leave that on GitHub for now.
We are very involved in the Halium project but we don’t own it and that is still operating on GitHub, so that is where we participate.
Libhybris is something that we use extensively but again there are other groups which rely on it too. It is on GitHub and any move would not be our decision to make.
Most of our project is on GitLab now. One of the things we like about it is that it offers organisation by group and sub-group. For project management, that makes life much easier. Issues can be created which are attached to one repository or a cluster of repositories or to the whole project. Again, this is great for managing our activity.
In terms of our principles, GitHub is closed source, whereas GitLab is open source. Obviously that reflects our thinking better. GitHub is now a Microsoft company, which of course is controversial.
From a user perspective, if you lodge an issue in the wrong area it is no problem at all. You can drag and drop the issue anywhere, rather than having to delete and start a new entry. It may be that an issue is correctly assigned initially but that the solution has a knock on effect elsewhere. The partially resolved issue can then be moved along with its history to the next problem area.
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.
Snap
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.
Moving to Focal, is it already time?
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.
OTA-3
Domubpkm asked whether it is still the plan to have OTA-3 be the first properly stable version under Focal? The answer is yes. Our plan is that it should be solid by then. At that point it will be in a better place than Xenial ever was.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.
Fairphone 5
V64rd wondered whether there will be support for Fairphone 5? Marius is getting one soon, so the answer is probably yes. The workings share a lot with earlier Fairphone models so we should have a head start.
How to help
Arkenyon would like to help but knows nothing about what would be involved. If you go to the Community section of our website you will find a lot of information about the different ways in which you can get involved. Donating needs no knowledge or skills at all!
Used languages
We use C++ mainly because we rely on Qt and the two integrate. That is a major reason why we are not actively looking to use other languages. Mojo apparently has some interesting features.
See you next time :-)