Can we fix Android?

Last updated : 15/10/2024 (stub - I just wanna leave this one out FAST)

Introduction

<h1> tag said it all. As a base for custom ROMs, Android (or more exactly AOSP) is not a good one. Heck, if you see my best custom ROM page, you'll see that there are multiple things that should have been a part of stock AOSP.

I actually wrote this article somewhere before 2024, but left it in the backlog for too long as I had already became too jaded with Android at that point. So yeah... enjoy this barely researched, mouth-to-word textspam.

For this article, Android will be used to refer to stock AOSP.

What's wrong with Android?

Straight out of my own anecdotes (and copping off some of IT Vision's take (archive.org) wherever it applies)

1. Core platform
• Deep Google integration. IT Vision explicitly mentioned this point as an advantage of Android, but I disagree.
• Broken battery reporting & management, though it seems to be fixed in ≥A14. Earlier Android builds had to use some 3rd-party app (with varying degrees of issues & reliability) just to get around this issue.
• Forking the Linux kernel is fine, but Android forks it in a way Git becomes useless.
• Android process management. System takes up a bunch of gigabytes, but you aren't exposed to what does what.
• No option to simply restart certain misbehaving services, other than rebooting the entire device.
• Fucked up file management.
• File transfer progress? Oh yeah sure, lemme see... 20 seconds left. No wait - 1 minute. No wait it's 2 hours. Oh shit it's 3 days now. Nonononono it's 4 weeks sur. Oh wait - now it's 15 seconds now (and so on until progress reaches 100% where it sometimes decides to stick there & not clear out the notification it used for some time, or randomly failing to copy files and only reporting that, without dropping any reasoning whatsoever). How am I supposed to know exactly how long it's supposed to take, especially when there's nothing to show on the data transfer speed (something shown by the desktop)?
• File copies management - when I copy & paste a file with the same name in the desktop, I get offered to either replace, skip, or keep the copy with it appended to differentiate it from the original. On Android, I am forced to keep that appended copy, without being asked about it. This also applies to folders as well.
• Whenever my microSD card is read for the first time (and sometimes when it is re-attached), Android fills it with a bunch of folders, most of which I'd not use at all (Audiobooks, Notifications, Podcasts, Ringtones) & one I would prefer to use under a different name (Movies > Videos).
• Stuff not possible without root access (or any other levels of elevated permission), which is getting increasingly locked down. Yes, it is not going to be secure, but it transfers the responsibility of managing the device's security to the user.
• Accessing user data partition. Not /Android/data (it'll be discussed next), but just /data.
• Tampering with /Android partition. Sure, non-inbuilt storage managers could do this, but ≥A13 makes it essentially impossible without root access, if at all.
• Accessing system partitions to delete unwanted bloat. Not the most relevant issue since some custom recoveries allow accessing those partitions.
• Setting CPU / GPU frequencies and/or schedulers. And that's before we talk overclocking & undervolting.
• Modifying user interface to resemble older Android. Some customization-focused ROMs do include some overlays to allow these, but this assumes you can install them in the first place.
• Android randomly revealing (or leaking) device identifiers. Unfortunately this isn't something I can mitigate at the moment.
• Class / Type 0 SMS cannot be rejected by the user. So far, only Jaguar ROM implemented any sort of mitigation against Type 0, but since Jaguar is closed source we cannot see how it works.
• Support for ≥5GB files being all over the place. FAT32 is the most stable (and the default whenever Android decides it wants to wipe your microSD), except no support whatsoever. exFAT is the least stable (getting less reliable if exceeding 50% of internal storage), but at the very least it could support those files.
2. Apps
• AOSP apps being generally not good for daily use. We have decent alternatives to some of these apps, but the useless apps cannot just be disabled and/or "uninstalled" without elevated access.
• AndroidManifest.xml allowBackup. An Android feature that allows some apps to not be backed up.
• Network & sensor permission considered immutable by default. As far as I know, LineageOS' per-app data restriction is merely spoofing some no-network status on apps in the hope of making said app think there's no internet access.
• Full-screen / video advertisements. Though that's only an issue with most stuff from Google Play Store.
• No way to roll back updates, unless uninstalling, re-installing, & re-setting up counts.
• Stock launcher handling recents. It sometimes breaks when using 3rd-party launcher & gesture navigation bar.
3. User interface
• Display resolution adjustment absent by default. Some vendors (LG, Samsung) do include this option, but only on their stock ROMs.
• Custom display width management hidden in the developer settings by default.
• 3-button navigation bar is set to back > home > recents by default, with no default option to flip it the other way. Sure, the navbar was made with the left-handed in mind, but for right-handers (such as yours truly, who uses the 3-button navbar in recents > home > back) we either have to tolerate an awkward interface, hope some adb command fixes them for us, or use some custom ROM that still allows fixing that setup.
• Navbar edges reserved for some "smart" actions like changing keyboard or triggering screen rotation, with no way to disable them in the GUI. You can disable the latter (screen rotation suggestions) using ADB.
• Touch vibrations - meant to manage the vibration of every user interaction for the system (Haptic feedback for tap, keyboard, and more); but keyboard vibration settings remain untouched until A13, where disabling it (sometimes renamed to touch feedback) also fucks up the keyboard vibration settings.
• No options to manage default network connections (like captive portal & NTP server) using the GUI. While I could put this in core platform issue, the fact that there is a way to modify these connections (albeit using ADB commands) keeps it down here.
• Settings that don't actually mean what they say
• Do Not Disturb not automatically rejecting calls from non-contacts when it is set to only allow calls from contacts. Also, by default, DND is set to allow "repeat callers & starred contacts". The former (repeat callers) could be one of those advertiser bastards (either humanlike or straight-up robot) for what we know.
• "Always-on VPN" & "Block connections without VPN" still leaking revealing DNS traffic (archive.org).
4. Google
Honestly, Google is the biggest contributor to Android. However, Google is very much aware of this position and abuses it, as befitting of one who has complete monopoly.

• No work done to base AOSP apps, essentially making them horrible to use. Google has its own app suite, but part of me believes it was only because the higher ups left the AOSP apps maintenance team unmanned on purpose (or something within that line).
• Anti-user "security additions" like SafetyNet Play Integrity allowing any soydevs to force users into dropping their custom ROMs. Good luck chasing the big PASS status again & again just so you are allowed to get that little discount... or use public transportation. Or access some fund that used to be yours until you "stored" them in those banks. Or literally any daily life stuff that is forcefully made to be dependent on a device you should have owned.
• Limited work done to secure Android from leaks, if at all. Perhaps those leaks were intended all along'
• Play Services taking over more of what Android can do by default. Direct Share immediately comes to mind - it directly replaces the AOSP-derived Android Beam.
• Play Store generally sucking.
• The American court somewhat agrees with me in claiming Google has monopoly over Android, but the "tech enthusiast religion" really wants the Goolag way.
• Of course, I can easily forget mentioning that Play Services are closed source & allows Google to monitor everything you do. But then again, we all kind of knew that, no?
5. Vendors


• Bloated with tonnes of random system & "system" apps that the user can only disable (if they can be disabled in the first place - some needed ADB, and some just straight up can't be disabled at all, like Samsung's Game Optimizer). Sure, unlocking bootloader & switching ROMs does mitigate this, however...
• Increasing lockdown of bootloader unlocking. Or it being sometimes killed off, like ASUS, Huawei, & Xiaomi.
And we also have the oligopoly of carriers who would like nothing more than to abuse their clients, sometimes by requesting the manufacturers to not provide bootloader unlocking.


• As if the AOSP kernel mess wasn't enough, vendors are allowed to fork & patch them in a way they can no longer be sensibly improved without breaking stuff.
6. Other miscellaneous issues

User side

Interface

When it comes to interface, stock AOSP is mostly usable, but only if you don't mind not having a sensible navigation bar button setup if you're a right-hander. And not being able to long-press to quickly uninstall some apps.

This is quite easy to fix for as long as we're talking A11. Take most of the UI stack of ArrowOS and weld their "overlays" to stock Android. However, since I'm not exactly a fan of A11's quick settings, I also propose taking A12(L)'s quick settings interface, but with the default background opacity of its A11 predecessor & none of that unified Internet toggle which just bloats the quick step to disable mobile data and/or wi-fi. I'm also not really a fan of A11's dashboard icons in settings, but Jaguar has an option that changes it to follow our accent color (sorta like material you but user-customizable), so we'll add that in too.

As for ≥A12 UI, allow me to requote something I once said & still mostly stood by : Speaking of infants, the wobble when you scroll past the end makes me think A12 is developed for some soydev's (or the soydev's boss?) newly spawned creatures instead of actual humans of all ages.

Features

Features we need to add and/or keep in

• Mutable network permission, in addition to the already present sensors permission ArrowOS had.
• Split up the Touch vibrations settings into individual settings for whatever it is currently dealing with, except for keyboard. Keyboard vibration should be handled by the keyboard apps themselves.

Features we leave out

• /apex. Sure, it allows updating some parts of the system independently, but not only have I not seen how it works for myself, it also allows some bloat (like Bluetooth in ≥A13) to be unnecessarily made as a dependency for Android.
• GmsCompat and/or microG. With our new AOSP, we will not have any need for either, for the functions of Play Services (with mitigations from either of the aforementioned 2 implementations) has been properly implemented.
• SafetyNet Play Integrity. Any serious developer for server-side stuff will know that per has to secure the server before even thinking about discriminating against responsible power users in an attempt to block off the morons who attach ≥69 mods up their systems (and some of them are either parasites that cycrims use to indirectly collect your stuff and/or highly questionable stuff with some reputation for fucking up whatever device it gets installed to).
• The volume limiter. Sure, let EU whine about stuff being too loud (a.k.a. barely audible when using some over-ear headphone).
• Per-app data restriction. Sure, that might've been necessary back when nobody figured out how to properly mute the network permission if there was one at all. However, with it being mutable nowadays (with proper implementaion) I now consider PADR obsolete.

Stuff we can & will debate about

New AOSP apps

If you've used AOSP apps from Google's latest AOSP GSI (not Google's own apps), you will notice that they're not good for daily use in various ways.

Instead of re-inventing the wheel or trying to fix off the increasingly massive technical debt of maintaining AOSP apps, we might as well use most of Fossify's app suite to replace our new AOSP apps, with some changes.

• The music app can't just be rebased to Fossify's suite - we have to start from SMT's Simple Music 5.17.1. However, just upstreaming it (to Simple Music ≥5.18.0 or Fossify's latest version) (which includes adding in Exoplayer libs) will nuke our triple tap to rewind, so we need to keep that in as well, if only to keep an established standard around.
• Speaking of established standard, Exoplayer must support triple tap to rewind by default.
• Simple Launcher (since there's no Fossify equivalent yet) works rather finely as a base, though Nova's infinite scroll feature makes it nicer to use.

Developer side

Consider this section not well thought out yet, at least for now.

Solving Android - the corpo way

Since I don't have a solid grasp on Android development myself (if at all) here is how I might see Android get solved, at least by some decent corpo (let's call them Android Enterprises, or AE for short; for this one). If it looked very much like IT Vision's vision on solving Linux (sorry, but I can't be bothered to find a better word for this one), it's because it mostly is, save for some parts.

• Start with someone (maybe you!) having a REALLY DEEP pocket. I don't know - like billions of USD? Anyway, with that much cash, you make AE & somehow position it as the leader for Android development, because handing the greater Android development to anyone else (particularly the big tech & the Chinese tyrants' corpos) led us to this point.
• Hire decent Android developers & hackers. Or the questionable ones like Andy Rubin (or insert any other capable Android developers with known controversies and/or personality issues), if you can keep them controlled enough to avoid any controversies that you will have to face head on.
• Have the changes I outlined implemented.
• Implement a strict quality assurance and/or checking process.
• Create yet another open application store where apps & libraries can be sold, but with direct integration to development platforms.

On paper, this sounds quite neat because we now have a decent leader. However, IT Vision missed one potentially fatal thing that I will mention here. How does our AE keep itself afloat. This issue does put the AE solution in jeopardy, if not managed properly.

• Donations and/or investments, particularly from the economically thriving. On paper (within the capitalists' point of view), this makes sense. However, those donators / investors also get a free pass to altering AE from the inside out, especially if they send their people into our AE & sabotage it from within. Limiting the donators / inestors influence might be a good move here.
As a great example, Mozilla alone fits really well. Another example would be Linux Foundation barely supporting Linux (archive.org / archive.is), if at all.


• App store revenue. Too small to actually matter, so no dice.

Main Page