UBports community delivers 'second-largest release of Ubuntu Touch ever'

UBports, a community project to build Ubuntu for smartphones, has released OTA-16, a new version of Ubuntu Touch with numerous updates – yet the dream of a viable alternative to iOS and Android seems as distant as ever. Ubuntu Touch was originally an official Canonical project, with version 1.0 released in 2013, but the …

[Joe W]

Yes.

"The thinking behind Ubuntu Touch, and a possible way out of the problem, was always convergence – the idea that one carefully designed OS can run on both mobile and desktop, and perhaps both at once via connection to a desktop display, keyboard, and mouse. It is a long-standing concept that seems to make sense, but has proved so far impossible to implement well enough to win mass appeal. "

Which is what brought anger upon Microsift for Windows 8, and also lead to MS abandoning windows phone (plus the issue with the few available apps, and the ever-changing way apps were built and how developers were treated...).

So convergence did fail then. It will still fail, because what makes sense on a small screen with touch capabilities is ugly and stupid on a regular desktop. Windwos 8 did make sense on a small-ish touch screen machine, and Windows phone was really easy and welcoming and great to use (and that's coming from a Linux user).

[ChrisElvidge]

Re: Yes.

"Windows phone was really easy and welcoming and great to use (and that's coming from a Linux user)."

And it still is!

[karlkarl]

Re: Yes.

Even better, now that Microsoft has given up on it, you are free to enjoy the Windows phone and not be spammed with updates and other monetization strategies.

Since my phone doesn't connect to the internet (... because its a phone), I believe it to be much safer than an always connected Android / iOS.

[Anonymous Coward]

Why not fork Android + make it a shell

Why try to beat Android, why not just fork it and make it better. Do a proper tablet treatment on it. No more full screen phone dialers, and full screen single pane control panels with one button on them, no more apps that require you pick up the tablet, its keyboard and case and hold it portrait to use the app! 512MB heap limit.... that doesn't need to be, it could have a proper virtual memory manager.. Give Android a proper app lifecycle and port Libre Office to it.

It's waiting to be done, and it could be done as an Ubuntu shell if you want.

I've got my Chuwi Hipad plus tablet and the hardware is great, brilliant 4:3 huge screen, cheap price, fast processor,... but Android....this is the first time I've had to deal with a pure Google Android and I'm not happy.

For example, the navigation bar is huge, it eats a big chunk of the lower screen, it looks like its sized bigger because it can waste more screen! As if peoples fingers grow larger with available screen space. No option to make it smaller. If I switch to gestures, the gesture works anywhere along the bottom screen, so all the swipe up trays I had to use to get me more screen space now also swipe away the app. You lose the whole bottom edge not just the middle portion.

I can pin the app, with app pinning, so gesture swipe doesn't swipe away the app, but some idiot decided they should also hide the status bar notifications for pinned apps, even notifications FOR THE APPLICATION PINNED. So the app is important enough to pin it, yet unimportant enough that you don't need to see its notifications!??

The same random slowdown when crunching a big model too, sometimes it's fast, sometimes its really really slow, I've been seeing this on every Android tablet since Android 9. Let me guess some idiotic AI based thread scheduler? Think you're optimizing for efficiency but actually confusing efficiency with power consumption? Some lazy garbage collect... why garbage collect if Android is only supposed to run mini applets? Something like that? Ditch the idiotic AI in it.

White notification icons?? No wonder OEM's don't follow Google on this. I have color coordinated icons, I can glance and see the category from the color, then the detail of the icon tells me if I need to deal with it now, or it can wait. I can just look, I don't need to swipe down the tray. But under pure Android 10, the icons are blended to remove the detail and look like plain colored dots on the notification tray, these become white dots on the status bar. A line of useless white dots conveying no information at all, I have to swipe it down everytime.

Form over function.

Now it fights harder to get you to enable Google Play Services, I do not want this google crap on a tablet, but its gonna beep at me endlessly till I complete the setup with no chance of disabling those notifications or that setup app.

Build a firewall in it FFS.

I get it, Android is a toy, a way for Google to spy on users, *but* that also makes it forkable and it could be the basis for a half decent OS on tablets that is sorely missing right now.

But not with Google at the helm.

[Anonymous Coward]

Re: Why not fork Android + make it a shell

You mean /e/ as stated in the article!?

But if you bother to look at any of the alternate OSes listed, there's not a single 2020 or later phone supported that I could see. /e/ are the best, but most of the 2018/19 phones are marked (beta)

Sad, but I'm not digging my N4 out of the draw, things have moved on.

[Anonymous Coward]

Re: Why not fork Android + make it a shell

/e/ is a vanilla port.

[Anonymous Coward]

Re: Why not fork Android + make it a shell

Look Ubuntu guys.

1) Fix Android, adult interface choices, proper memory manager, proper lifecycle on a solid OS.

2) Do it as a proper compositing GUI, not a crappy 'memory composite' refreshed into a window, aka ChromeOS. Adding a gui around a gui is to add nothing of value, and just makes the refresh really crap.

3) Port Libreoffice, Thunderbird, Firefox to it, you will have proper lifecycles, memory management and so on, so you don't need crappy Android half assed versions.

4) Take Android from Google, this is Android without Google spyware.

[AMBxx]

Re: Why not fork Android + make it a shell

You'll come back to the same problem that Microsoft and BB OS faced - a lack of apps. Android itself is open source, but the App Store can only be installed with Google's permission. You may be able to sideload it, but how viable is that for the mass market?

[Youngone]

Re: Why not fork Android + make it a shell

You're right about the lack of apps.

I have UBports installed on a Huawei Nexus 6p phone, and it works really well. I can make and receive calls and texts, take photos, browse the web and whatnot, but there are a couple of apps I use every day that are not available, and won't ever be.

That said, I could probably work out workarounds for the apps I'm missing, and there is a browser plugin (at least I think that is what it is) that will let me pin web pages on the home screen sort of like an app, which is something.

I am still awaiting this particular update though.

[doublelayer]

Re: Why not fork Android + make it a shell

Primarily, because they want a more controllable thing. If they fork Android, they can do a port without changing much, like the various semipopular custom distributions, which wouldn't make you happy since the Android UI hasn't been changed. That is the option which keeps most app compatibility, but you have to live with Android's UI.

Or they could do what you ask, keep some of Android, but do a bunch of work to make the UI different. Result: some Android apps wouldn't work because the UI's too different, so now they have to do extra work to emulate the old structure so things aren't broken. In the meantime, they have to work with other problems in Android which they might want to fix. For example, Android's handling of external storage devices which isn't the clearest or easiest to manage. People who are used to the old Android interface may not recognize this one either, meaning more complaints about how they don't like the UI choices made. Meanwhile, Google keeps developing new Android things and, if this fork is to stay up to date, the devs have to keep backporting the Google updates which are important. That's a full-time job for several developers even when few changes have been made; doing it with a very different fork is intensive.

For people willing to do some of this work, they're probably not that happy with half-measures. If you're going to change a lot of things in Android, why not give a full Linux-style interface a go? If you want to solve Android's storage thing, you could do a bunch of work on Android itself or just run more typical Linux userland software which already knows how to manage that. This also lets you develop things without having to worry about Google changing Android in such a way that it's hard to integrate again.

[gobaskof]

Re: Why not fork Android + make it a shell

There is a difference between a fork and a downstream.

If you fork Android you must continue doing all the dev work for android forever more, you soon become out of sync and incompatible with new android and you are maintaining a huge codebase that for years has been designed to be incomplete and require proprietary services.

If you make a downstream, as people have tried before you are at the mercy of Google each time they pull a part of the OS you are relying on. Bering 100% at the mercy of the competition is not a good place to be.

I do worry that Ubuntu touch/Plasma active are developing too slow to ever be good enough. But at least if they do they will be maintained by a community that built them and understand them. Unfortunately as a frequent traveller to areas where WiFi is not a thing and 4G is the only means of communication, I rely on my phone too heavily to experiment with the OS. But then I have been in lockdown for a year, and all my funding has been cut by the AID budget reduction, so I am probably not going anywhere too sool. Maybe I should build a time machine and install Plasma active this time last year?

[Peter Gathercole]

Re: Why not fork Android + make it a shell

I haven't checked this version, but UBports used to use an android kernel with Ubuntu tooling over the top.

I was skeptical about MIR and the Ubuntu desktop on computers. I could not cope with how much it wanted everything to run full screen, was difficult to have more than one window of each type (for example a terminal session), and how inflexible it was, making customization difficult. I still used Ubuntu, but used another GUI.

But as a phone GUI, it works well.

The lack of apps makes me use a more mainstream phone as my main phone, but I do keep a Nexus 4 with UBports on it (even with an active SIM) just to see what is happening. I would like to put it on a more modern device, but the list of supported phones is still quite small.

[stuartnz]

Waiting to land my Sailfish

If Sailfish extends to Oppo/RealMe devices, I'd be keen to give it a go. Especially now it's up to Android 9 in its compatibility mode, that's close enough to the 10 my phone uses.

[Warm Braw]

Convergence

I don't think you can get away from the fact a device with a physically small screen that you jab with a finger and a physically small battery that you have to conserve will always be a very different creature to a device with a big screen, big battery, separate keyboard and precision pointing device. Especially when people don't want to change their glasses just to answer an incoming phone call.

You may well be able to converge the operating systems - and, indeed, below Android lurks a Linux kernel - but the application layer is inevitably going to look very different for the two very different modes of interaction. Anything that tries to combine the two is going to be very much like those toasters that also warm beans: why would you take up more bench space with a dual-function device when you already have a toaster and a microwave.

[vogon00]

Ohhh...real shops!

"elicit blank looks for those who enquire about them at their local mobile phone stores"

IMO, you get the same 'blank' look from the spotty yoof therein when you enquire about *anything*. Also, this isn't restricted to mobile phone shops, either :-)

My last visit to a 'real' mobile phone shop was only on impulse as I was walking right past it with my rather knackered mobe handy... I got so disappointed with the service from and product knowledge of the staff, especially the constant and obvious efforts to 'upsell' me into their own walled garden, that I've decided not to bother with any of their ilk in the future.

[matjaggard]

Re: Ohhh...real shops!

What kind of a walled garden can you find in a phone shop?! Not that I'd go into one, I'm under 50.

[Peter Gathercole]

Re: Ohhh...real shops!

I've got a particular problem. Years ago, I bought a mobile phone on a contract for one of my kids.

They're kind of wedded to the number on that contract (even though it's actually well out of contract), but it's in my name, even though they've taken over paying for it.

So we want to move the number to another contract in his name. It's proved difficult over the phone, because it seems it needs a three way call with the phone provider's call center, and we both have to prove who we are, which seems too difficult for the call center operatives to get their heads around.

One time, before the lockdown and while he was visiting, we decided that it might be better to visit the company's shop, so we both loaded ourselves up with ID, and travel to the nearest shop (~25 miles).

We walk in, and explain to the young person there what we wanted to do, and after his face paled for a few seconds, he said "No, I can't do that here, you'd be better off calling the call center."

Made me wonder what the purpose of the shop actually was.

[CrackedNoggin]

Perhaps the most likely evolution for a breakthrough Google-free phone wannabe is not try to duplicate Google with a big app store, but to act as a secondary device, e.g., for keeping passwords, or 2FA information, or managing other things that a Google (or Apple) phone doesn't do well(*). Of course 2 SIMS is too expensive, but the SIM itself is a security risk. If necessary the secondary phone could VPN through the primary phones SIM. (*Personally I don't keep passwords or 2FA on my main phone because (1) I doubt the security, and (2) in case the phone is stolen.)

More generally - suppose a company wants a secure device for scanning, measuring, tracking, communicating - a cheap cell phone form factor with an ultra dry OS the allows a single app to run without a lot of background junk - maybe in near realtime - that could be marketable.

[Anonymous Coward]

The one main thing that bothers me is that open source smaller mobile phone OS projects lack the privacy and security or other options.

I've installed EOS from https://e.foundation on a Samsung S8. This phone was bought in England and has nothing Russian about it, but when I use TOR browser on it the duckduckgo settings default to Russian results despite the exit node not ever being based in Russia. Something about the handset/app is suggesting Russian connotations.

Additionally, the default E OS app store appears to be a mirror of another store, but is registered anonymously and has an opaque operating policy. These are just a couple of examples from one OS - which, otherwise, is a really great implementation of a de-googled handset. But the next concern after de-googling a handset using one of these operating systems is the true boundary security of the device. If we are using our mobile phones for email,texting,perhaps banking, then is it a case of choosing a better master?

For example, should I just use apple iOS and have some degree of known privacy successes and failings but be happy they are a known known? If I use EOS on the Samsung S8 it seems completely obvious that I should not be doing internet banking on the device, as I cant guarantee the authenticity of the side loaded banking apps or reliability of the EOS app store.

People like me want to use an open source OS on their mobile phone but have nagging doubts and valid worries about security. Surely I cant be the only one worried that EOS and others are actually inherently insecure, customising aspects of android that the open source developers dont fully understand all aspects of android and the technical changes they are making to parts of the core operating system.

[doublelayer]

I don't think that should be your primary concern. Of course such an OS could be compromised by developers who are incompetent or malicious, but the same is true of closed-source versions. In each case, you have to use your own judgement about the software which is run, which can be tricky. Here are some more specific answers about your concerns.

"This phone was bought in England and has nothing Russian about it, but when I use TOR browser on it the duckduckgo settings default to Russian results despite the exit node not ever being based in Russia. Something about the handset/app is suggesting Russian connotations."

This is probably a browser setting. I don't know if the E OS has set Russian somewhere in the defaults, but you can check by checking the settings for DDG here: https://duckduckgo.com/settings. If it says it's using the browser's default language, then check in the settings to see if Russian is set as one of your languages. I often get this just for having set a priority queue of languages on my phone.

"Additionally, the default E OS app store appears to be a mirror of another store, but is registered anonymously and has an opaque operating policy."

This is one of the features of the E people. They want a mirror of a lot of Google Play apps, which isn't supposed to happen. You have to trust them to do it correctly. Or you could avoid their store or use a different version. Lineage OS, for example, does not operate a store so you may trust it more.

[Taking some things out of order]

"If I use EOS on the Samsung S8 it seems completely obvious that I should not be doing internet banking on the device, as I cant guarantee the authenticity of the side loaded banking apps or reliability of the EOS app store."

This is now your responsibility. You have to check the authenticity of your critical apps. You can do that by downloading them directly from the original source, whether that's FDroid, the writer's site, or Google Play (you can use a few open clients for the Play store or another device). You could get a malware-laden version by searching for someone who cached an APK, but you have the option not to and it's not difficult.

"But the next concern after de-googling a handset using one of these operating systems is the true boundary security of the device. [...] People like me want to use an open source OS on their mobile phone but have nagging doubts and valid worries about security. Surely I cant be the only one worried that EOS and others are actually inherently insecure, customising aspects of android that the open source developers dont fully understand all aspects of android and the technical changes they are making to parts of the core operating system."

In this case, you are worried about something that usually goes the other way. I can't speak for all custom versions of Android, but I can about Lineage OS. In that case, they are using the open source AOSP code, which is maintained by the Android developers who already know about many details. They also release security updates daily. Compared to the average manufacturer which at best releases those updates monthly (normally much worse). They use known code which can be audited, unlike manufacturers who provide closed-source additional layers which they don't continue to update. You can and will have vulnerabilities in anything open, but you are virtually guaranteed to have more in the style of closed that most Android OEMs are using.

In your opening line, you also mentioned privacy. Nearly everything open source is not selling your information, meaning you're almost certainly guaranteed to be improving your privacy by using them. Privacy and security are among open source's strongest aspects. They will certainly not be perfect, and there are occasions where they will be bad, but I would not have the concerns that you have.