A New Backend - Ubuntu Touch? PostmarketOS? Something Else?

Community Forum
1

Just curious about people’s thoughts on the idea. Given that it seems like Google is charging full-speed to interfere with its app ecosystem, Linux-based phone OSes are seeming very appealing to me.

What if /e/OS was based on a Linux phone operating system instead? I know this is no small feat and would likely not happen, but I’d love to see a version of /e/ backed by something that had nothing to do with Android. Perhaps based on Ubuntu Touch, like how so many Linux distros are based on Ubuntu and Debian. Or, the upcoming PostmarketOS could be a solid option when it’s ready, given that it’s goal is to revive older phones. That would give /e/OS a lot of longevity, especially on modern devices.

Thoughts?

P.S. I know Android is based on Linux :stuck_out_tongue:

4 Likes
2

So, I don’t pretend to speak for the rest of the team…but my immediate reaction is that doing so would largely mitigate everything that makes /e/OS…/e/OS.

Let’s start with PostMarketOS. I know making a mobileOS compatible with a particular phone is not an easy task by any stretch, so I have nothing but respect for the team who makes the images. From a user standpoint though, the OS only supports about two dozen phones in total, with the newest phone that has a community build is from 2021. I’m reasonably confident that at least half of the /e/OS userbase has a newer phone than that. A lot of the handset customization of /e/OS is an android derivative - the MicroG spoofing to allow Android apps to work, the Bliss launcher, the App Lounge, the Murena account plumbing - it’s all on top of Android. Most of those things would have to be rebuilt from the ground up, if they could be created at all.
…but the real problem with PostmarketOS is that it requires an emulation layer to run Android apps. This can be helpful if one is perfectly fine using Linux apps and just needs WhatsApp or Microsoft Authenticator for work, but Waydroid-based compatibility is more resource intensive, and is tougher to spoof Android Integrity functions or other anti-tampering functions - plus all the stuff I don’t know, like how gracefully an SMS app can find images from the photo gallery, for example.

On top of this, what Murena does that a lot of the other ROM projects do not, is that they attempt to provide ecosystem alternatives, not just “here’s a browser and a dialer and a mail client, go party like you’re on Windows Mobile again”. App Lounge exists for this very reason. Same with Maps and murena.io and all of the other things that exist server-side that Murena emulates that people just take for granted that Google and Apple do for them. PostmarketOS has no analog, so everything would need to be rebuilt from the ground up to do that.

Basically all of those problems exist with Ubuntu Touch as well - no ecosystem backend, only a handful of supported phones (most of them being older and no longer available to purchase), no analogue for the /e/OS glue that makes it an easier alternative to stock Android…but with the added bonus that it doesn’t appear that Android app emulation is available at all on that platform, either.

In practice, Android is like Windows in that the gravity to the platform isn’t love of the platform, but the massive, entrenched ecosystem of third party applications that makes it difficult to just up-and-leave. Conversely, it’s not really clear how Android’s new developer verification process will impact the /e/OS ecosystem in practice. I’ll certainly accept any criticism of my limited knowledge, but I’d imagine it’s not that hard to remove the signing limits by default in /e/OS. Between F-Droid and good old fashioned webpages, there’s a way for app developers to distribute their APK’s without a dependency on Google - and favor /e/OS and other AOSP projects in the process - without submitting their IDs or paying the annual fees. Conversely, larger developers already have legal departments that have handled this and it won’t impact them in the slightest.

So…I share your disdain for how Google is closing what was once open, but I also think that rebuilding from the ground up, on a more…principled base, would have more negatives than positives in practice…though I too would love nothing more than to see some progress on these alternatives.

2 Likes
3

Totally fair views, I agree it’s not the best option to essentially rebuild from the ground up. I see it as more of a contingency plan in the event that things get far worse, that perhaps Murena should keep in the back of their mind for now. I, too, have limited knowledge of how Android etc. actually works under the hood; my main concern is Google, being the distributor of open-source android versions, making some core change to the OS that can’t be undone for /e/OS. Or worse, Google taking away open-source android, with newer versions being closed-source only. I imagine there would be plenty of forks of whatever the last open-source android version would be in that event, the community pretty much always steps in when companies pull anti-consumer nonsense (because the community is awesome!).

4

my main concern is Google, being the distributor of open-source android versions, making some core change to the OS that can’t be undone for /e/OS. Or worse, Google taking away open-source android, with newer versions being closed-source only. I imagine there would be plenty of forks of whatever the last open-source android version would be in that event

Well, I’ve got a bit of good news for you…depending on how much you trust ChatGPT’s assessment of the matter, because I had a somewhat-similar concern that I put past the system, and its response was rather promising, best summarized as “enough interdependent market forces makes it unlikely that Google is going to stop working on AOSP and move to a proprietary OS”.

AOSP isn’t just the foundation of LineageOS - in the grand Android ecosystem, Lineage and its derivatives are both useful, and rounding errors. Suppose Google were to decide tomorrow that AOSP is old hat, and the freshly minted PixelOS is what all the cool kids are running. Well, now Google has quite the tightrope to walk. Google is going to have to convince Samsung not to just fork the last AOSP release and continue using Android as their base with in-house developers continuing to work on it. Samsung already has their own App Store; telling devs “port your app, first 20,000 transactions will only pay 10% to the house, no need to re-tool”…now, Google has a respectable market share with Pixel, but Google market share gets cut in half overnight. Google already lost Huawei, who proved that it’s possible to run an Android fork and still work. Google doesn’t need that from Samsung.

This is particularly problematic because the real moneymaker for Google is the ecosystem - Drive, Gmail, Docs, Maps, Wallet…Samsung has drop-in replacements for half of these (App Store, WearOS, , and can either integrate (Gmail via IMAP), partner (“Samsung Maps Powered By HereWeGo”), or buy someone if need be…and if enough people move from the Google ecosystem to the Samsung ecosystem, Google’s ad business suddenly loses tens of millions of eyeballs in one phone generation.

Samsung isn’t the only company that would be leaving the Google ecosystem in short order. Polestar vehicle computers basically run Android. Millions of TVs run Google TV, and Android fork. A whole bunch of random things from barcode scanners to medical imaging appliances run Android under the hood. Google would make an enemy out of lots of companies - big ones, with lawyers on retainer - if they were to move off AOSP. The EU and the US alike would likely litigate.

This brings us to why Lineage and /e/OS and the other AOSP forks are useful noise - it’s basically the same reason Google funds Firefox - an alternative, even if it’s uncomfortable or hobbled in some way, is a helpful thing that Google can point to if someone tries calling ‘monopoly’. Google simply tells developers “this is a rooted phone that fails safetynet”, and it’s up to the developers to decide what to do with that information - Google itself doesn’t enforce it. The presence of the forks makes it easier for Google to argue “users have a choice” and “we provide developers with security mechanisms they can opt to ignore”.

So…perhaps /e/OS will have to ride out a particular Android release until the ecosystem catches up, but it’s more likely that Google will choose to allow app developers to tighten the screws and do a better job at detecting spoofing, than they are to throw the whole AOSP ecosystem into chaos and losing millions of ad targets because a tiny minority use forks.

2 Likes
5

That does give me some hope, thanks stranger :grinning_face_with_smiling_eyes: