Personal rules for advantages & disadvantages found in my custom ROM list.
These are features that I consider essential. Not having them counts as a disadvantage.
There are 2 ways to block apps from having internet access in Android - network permission toggle & per-app data restriction.
Network permission toggle (the more robust option, which I prefer) causes apps to declare their need to access the network (wi-fi, mobile data, VPN), and they are enabled by default to retain compatibility. Only considered valid if the toggle exists in the permissions setting. Also affects AFWall+ usage, as apps with revoked internet permission won't appear in AFWall+ without enabling "show all apps".
Per-app data restriction tricks the app into thinking it has no internet access (at least within my own perception). While it is a less robust method of blocking network access, so far it mostly works (unfortunately not against SMS AFAIK). This is easily replaceable by AFWall+, NetGuard, and/or InviZible Pro.
This causes apps to declare their need to access the device's sensors (such as microphone & gyroscope), and they are enabled by default to retain compatibility. Only considered valid if the toggle exists in the permissions setting. Typically, this feature is bundled with the network permission mentioned above, both of which came from GrapheneOS. However, some ROMs (A11 ArrowOS) implement this separately without the network permission.
This feature is a recent addition to custom ROMs (if we're counting app locker apps, not so recent) that allow you to lock down any app (from actually sensitive ones to what you think are sensitive), which should prevent anyone from being able to access that app without your permission (and/or your lockscreen password).
Similar to the per-app network restriction, it can also be a neat addition rendered irrelevant with an app locking app (which may also bring their own issues).
LineageOS implemented something roughly resembling applock in the form of Hidden & Protected apps, but it's tied to the stock Trebuchet launcher & trivially bypassed by opening it from another launcher and/or through Settings > Apps. I don't consider this a functional alternative to App Lock.
This is a frivolous addition only made possible thanks to Goolag enforcing Material You & deprecating Styles & Wallpapers as the theme settings in ≥A12. Initially, I'd consider separate theming options a disadvantage with the existence of Styles & Wallpapers, but as Material "Actually It's Papa Goolag's Arbitrarily Made Up Choices That You Can Never Defy" You enforces terrible colors & removes options, let's be honest - I can only hope they work, or Styles & Wallpapers allow the user to select actual basic colors (such as red, blue, green, yellow, and none of that pastel color bullshit) for themselves (or maybe implement kdrag0n's monet implementation).
A good example would be crDroid's implementation of Monet settings - not perfect, but better than nothing.
Also known as the traditional 3-button navigation bar, which existed long before the dawn of gesture navbars introduced in Pie & A10. Personally, I'm not a big fan of gesture navigations, even though I can agree that full display gestures from A10 are better than Pie's half-assed one (but then again, that's a low bar to pass, so... good enough to use once in a while (maybe only when it is the default after a clean flash), but still not enough for me to drop everything & use gesture navigations for everything).
Not having this feature is a disadvantage, unless you're used to gesture navigations and/or traditional Android's Back > Home > Recents setup. 31/3/2023 Update : Heard there's an ADB shell command that can change the navbar, but it could destroy systemUI (and potentially soft-brick your device in cases where you can't reset the thing). I wish I was joking on this, but this is how I soft-bricked my SOV36 - stock Sony ROM won't allow changing navbar layout by default & I couldn't factory reset the damn thing (because it doesn't have a recovery partition on stock). By the way, having this feature is not an advantage; it's mandatory.
My troubles with gesture navigation (at least the ones introduced in A10) :
On one hand, ROMs not focused on privacy (such as Lineage, crDroid, Arrow, Havoc) are exempted from this flaw (not getting disrecommended for not documenting connections) as I will (by default) assume that they use default Go-ogle connections without changing it. On the other hand, privacy, security, and/or "de-googling" focused ROMs (such as Calyx, Divest, /e/, Graphene, iode, LMODroid) are fully subject to this flaw (getting disrecommended for either not documenting connections and/or not providing an option to change it) since privacy-conscious users should know what they're connecting to & be able to change connections however they see fit.
For ROMs that simply state that they're focused on "de-googling", the reason I threw them together with privacy and/or security ROMs here is the users - they should know what Goolag alternative the ROM offers.
These features don't really matter when they're there, though having them would be an advantage (depending on your preference). However, sometimes not having these features can be a disadvantage, depending on your device and/or preferences.
Generally found in Settings > Displays > Dark Theme in A10 & A11, this feature can be used to make the interface far less annoying in the dark while saving some battery on OLED displays, especially with turned-off blacks.
If this feature is tossed into the "advanced settings" menu, I consider this a disadvantage since it's far less intuitive to dig deep into the settings just to change something that belongs in the basic settings.
Full Screen Apps (or Expanded Desktop if you're running Pie Lineage builds) is a feature that allows apps initially made for 16:9 to stretch themselves to fit taller aspect ratios.
Not having this feature would be considered a disadvantage if you're running a device with 18:9 display / taller. However, it doesn't matter if you're running 16:9 devices (or are used to pillarboxing / letterboxing), so there's no point in considering them a major feature / advantage.
Currently, I don't consider this feature to be an advantage as I no longer check it.
Smart Pixels shuffle & disable the pixels of a display in order to prevent burn-in & reduce battery usage. So far, I'm not quite sure whether the former is true / not, but at least having something to mitigate burn-in is better than nothing. On the bad side, it reduces your display's viewing quality as long as it's enabled.
Since this matters only to OLED display users, I can only consider this feature an advantage if you're using OLED. Otherwise, this feature is redundant to LCD users unless you want an even darker display than what the brightness slider could provide.
microG : An open-source re-implementation of Play Services API. Requires a special permission to function (signature spoofing), which might be a security risk depending on the user. Also requires being installed as /product/priv-app for whatever reason (doesn't work well as user-installed app, breaks boot as /system/priv-app) (14/10/2023 update : breaks boot as /priv-app unless inbuilt in first place (at least for some ROMs?), so install as user-app in any case). Some features are not fully implemented yet & might require microG to be installed as a system app (particularly important for mapping, though microG's fused location implementation does not honor AppOps, so there's a chance for microG to leak location - another red flag against microG). Compared to GmsCompat, it is more free (though not as free as using neither) as it's open source & usable as user-app (without some functionalities, most notably location), but less secure due to the added permission and its present issues with some permissions.
GmsCompat : Gives the user full access to Play Services as user-installed app, which also denies Play Services of its privileges. More secure (due to not needing signature spoofing), though debatably less free than microG (as it requires installing Goolag's closed-source Play Services, Play Store, & Play Framework) & also allegedly less private (as Play Services could still cause random Go-ogle connections if unmitigated). Also, GmsCompat has to be inbuilt into the ROM as a system app.
Originally a major advantage for custom ROMs, now moved into minor advantage as usage of these components discourage users from seeking out Play Services independent alternatives and/or drop Play Services dependent apps. If I had to pick between microG & GmsCompat, I'd definitely pick microG for easier setup (especially since I should be able to block their network access anyway in an ideal custom ROM).
A feature commonly found on security-focused ROMs (GrapheneOS & DivestOS comes to mind), this creates fresh processes for spawning applications instead of using the traditional Zygote spawning model, increasing initial memory usage & app spawning time (translation : app load times) in return for security & privacy benefits.
This mostly covers highly subjective stuff that may (not) improve your experience with using a custom ROM.
The 1st thing you'll see while booting to the system. Normally, most of them are generic, boring, and/or not worth looking at; save for the top 3:
This "advantage" is highly subjective, & thus shouldn't really be considered a factor.
After seeing a screenshot of A12's Wallpaper & style menu, I felt that I had undervalued the dedicated theming options found in some custom ROMs (AOSiP is a good example). Therefore, this may be an advantage if A12 stable only comes with "Material You", which will deny users a chance to personalize their Android devices as they see fit, without any arbitrary interferences.
Massive flaws that would instantly make me pull all recommendations for any custom ROMs.
Permissive SELinux is only fine if it's on initial Alpha build & the developer(s) (and the users too, if they're willing to help out) are actively doing work to ensure that the next release would have Enforcing SELinux. Otherwise, keeping SELinux in Permissive even after at least 3 builds are released is equal to giving an unofficial backdoor to custom ROM users who might not know what they're doing.
This flaw is also applicable if a custom ROM has the ability to switch SELinux mode directly from the settings (For example, the aforementioned PocoParts, Mi Extras, & AICP Extras), since anyone with physical access could just toggle something in the settings to deactivate a good chunk of Android security. While the user should always be able to choose which spectrum of security they're at (secure but limited applicable mods / unlimited mod potential but insecure for example), the toggle being there gives anyone the ability to decide which side you're on, if they have access to it.
References & explanations for SELinux can be found in :
More readings as to why Permissive SELinux is bad :
This feature is better off contained in an app, such as SD Maid. Having the ability to remove system apps without having to either boot to recovery / install the likes of SD Maid could leave the user with a non-functional system, especially if they (or someone else with physical access) are deleting system apps they don't know they need.
This flaw is found in (at least) AICP & Baikal; & I hope other ROMs don't include these in the settings. In their (undeserved) defense however, you could deny root access to advanced settings / Quickstep & they won't work. But still, the only acceptable alternative would be to not include them in the first place.
Back in the Pie era, when Poco F1 builds didn't have prebuilt vendor partition, various ROMs for F1 enable USB debugging on boot, which enables itself every time it boots, even if USB debugging had been explicitly disabled.
This "feature" is a flaw that gets annoying especially for ADB-hating game (such as Fate/GO) players who reboot their devices every once in a while, because they will also have to remember to disable a setting after a reboot.
I'm fine with USB debugging enabled on 1st boot if it stays disabled after I explicitly disable it in Developer settings. On the other hand, if USB debugging enables itself on boot even after it's disabled, I'm not going to recommend any users install that ROM (at least until this issue is fixed).
Basically minor niggles that are debatably tolerable, depending on the user.
One "advanced" settings won't be enough to sin a custom ROM, since basically everyone except Lineage & Arrow are using this. However, bring 2 in (such as BaikalOS in A10) & it's a disadvantage. Putting basic stuff such as dark theme (RR & Nusantara are examples of those guilty of this) will also warrant calling it a disadvantage (this is a repeat of the Dark Theme section found above).
An exception that will immediately make me remove any recommendation for a ROM on a device would be "advanced" settings with SELinux switchers, such as PocoParts & Mi Extras (both have a tendency to provide a SELinux switcher toggle, though sometimes they don't). They're probably fine in unofficial builds (though I'd still avoid them), & any maintainers and/or developers who adds these settings on Official builds must immediately lose their rights to maintain their "official" builds unless they remove it & re-release their builds without them.
While it is probably nice to have a toggle-able inbuilt ad-blocking hosts, they are not as ideal as using a dedicated hosts manager.
A bug that resets time to a certain preset time on each boot. A minor but annoying issue for anyone who has a habit of powering off their devices before sleeping & enabling it after waking up. By the way, after re-plugging in the battery on a device with "non-replaceable" battery, time will also reset on first boot (this point obviously doesn't count towards this flaw, I'm just pointing this one out).
While having inbuilt root access sounds convenient, I'd rather flash something that gives me root access if I needed it, instead of a custom ROM that has it present in the first place.
14/10/2023 Update : Quoting optimumpro / SecureOS from Jaguar ROM in Telegram regarding KernelSU:
Restating my position on KernelSU, which is a security hole. Differences between Magisk and KernelSU:
Magisk creates a layer which makes system believe that whatever is there belongs to System. Magisk manager stands as a guard between that layer and applications. In other words, apps are not able to access root without asking Magisk manager.
KernelSU makes kernel itself rootable. KernelSU manager stands as a guard between kernel and applications, which have to ask for root. But, if something exploits/takes over your kernel, it will have root rights regardless of KernelSU manager.
With Magisk, if something takes over your kernel, it will NOT have root. For that it would have to circumvent Magisk manager. That's the difference and that's why KernelSU will never be a part of Jaguar kernel.
Sounds scary, I know (and it's probably already patched in KernelSU 0.6.9, so it's probably obsolete). However, this solidifies my belief that root access shouldn't be inbuilt in "official" releases - root should be a choice for power users, not something enforced for everyone, power user or not. And no, I'm not talking about adb root (which is inbuilt in LineageOS for the record) as it can't really tamper with system files the way Magisk and/or KernelSU would. Though, if I must pick between KernelSU / Magisk as enforced inbuilt root access... I might as well switch to something else that allows me to pick whichever root solution I desire.
Self explanatory - if you refuse my patronage without me sucking up to your demands, I'll move on, perma-boycott you, and find someone else who'd accept my patronage without demanding me to be your cuckslave. Or find the stuff you allegedly lock up in the seven seas (or just ignore them all altogether).
But still, this is a minor disadvantage since you don't need to use the corresponding dis-service (aforementioned Netflix, GApps) on the ROM & the spoofing stuff shouldn't work without it.
Personally, I didn't really mind userdebug builds as long as they just work. One bonus of running it is that users can help developers with finding bugs. However, in terms of security, userdebug is quite weak, with security protocols so relaxed Google deemed userdebug unfit for production.
But still - I consider userdebug minor disadvantage since basically everyone (except security-focused ones) does it.
The "feature" nobody asked for, allegedly to "protect the users' hearing". In truth, it is exactly what the title said. An arbitrary volume limiter (which only applies when an audio equipment is plugged in) whose existence is only to appease the sensibilities of well-intentioned morons (both the soydevs of Goolag & developers of custom ROMs who either left this "feature" in or made it even worse by setting the limiter at levels so irresponsibly low your weakest earphones are barely making any decent sound), whose implementation can't tell the difference betweeen an earphone that starts damaging someone's ears from 40%, a big ol' Bluetooth-compatible Harman Kardon speaker that would only start being audible beyond 75% without Bluetooth & its own line of issues, and a casual over-ear headphone that starts sounding nice somewhere above 50%. And it re-enables itself after either a set time or a reboot without any reliable way to permanently disable it, so we are forced to deal with it every now & then, especially if our devices' audio performance is so weak we had to reach above the arbitrary volume limiter just so our earphones STARTED to sound good.
This "feature" is actually inbuilt in AOSP, and could have caused me to give up on custom ROMs even earlier on, had this crap been so deeply rooted in AOSP no developers were actually able to remove it (but then ArrowOS & Jaguar ROM removed the arbitrary limiter for their A11 implementations, proving it wasn't so deeply rooted). That said, I can only consider this a minor issue as this is an usability issue, not some massive hazard waiting for some cycrim to exploit. And yes, I also don't want to deal with the pains of finding out which ROMs leave the limiter in & how limited the volume levels are going to be, especially considering the variety of implementations between official & unofficial ROMs (and various devices as well).
This section applies to developers & maintainers.
Generally, a ROM can be exposed as a Limbo ROM if at least 3 have a Goolag-only release while the rest of them are either Vanilla-only or Vanilla/Goolag. However, if at least 3 devices are available as Vanilla-only builds & there are no Goolag-only builds, this doesn't apply, though their consistency should be questioned.
Here's some examples:
Obviously, a custom ROM can't be made available without someone to make them available, so let's discuss about the maintainers - those who make it possible for a phone to receive a custom ROM.
The maintainers are, obviously, developers who make sure a custom ROM works on their phones, as well as the users who use the ROM.
Sometimes, a maintainer's actions can expose a ROM as a Limbo. The BlissROMs example above should suffice for an explanation.
There are also cases of maintainers releasing Official builds with PocoParts (no more SELinux switcher as of August 2021) / Mi Extras, "advanced" settings that don't belong in Official builds thanks to the footguns that often come with them.
One-dev shows aren't that much of a problem if the developer remains active enough to keep their project running. However, the primary issue of one-dev-shows is that they are more likely to change course and/or get discontinued at any time, as shown by examples below. In addition, even with the project being active, one-dev-shows might not be able to pick up issues quickly enough to stay relevant. Granted, there are projects that get killed despite having more than 1 developers (such as RevengeOS, XenonHD, & AOSiP). However, projects with 1 developer are more likely to do so than those with several.
Anti-Stallman open letter, for example : (archive.org)
On one hand, this should not be an issue as the only thing that should matter is the developers' competence. However, more often than not, some developers would rather kowtow with the latest fads & psyops over focusing on making their shit work well according to their users. The Anti-Stallman open letter itself is a decent example - LineageOS & CalyxOS, the 2 custom ROM groups signing this open letter, took their sweet time to release pure black theme for A12L (July 2022 & 2/9/2022 as "August update" respectively) while crDroid has them added in 16/4/2022. Granted, both Lineage & Calyx are not focused on adding theming options (though Lineage promised to focus on personalization right on their index page for what it's worth), but still.
Automatic updates can be useful to deliver security patches & bug fixes, but its issues tend to outdo whatever benefit it could have offered. Here are some things that can be done by automatic updates : (sourced from a snapshot of DigDeeper / Nanon with some additions)
Conclusion? Delete the auto updater (and seek alternatives if the updater is so tightly welded the system won't boot if updater is wiped out). Most developers might not be malicious enough to actively fuck with you using auto-updates (except for the aforementioned Mozilla & Windows), but still. Updates should ALWAYS be a choice the user makes, not something enforced by the developers. Oh yeah - this is not set as a "disadvantage" of any kind as auto-updater can be removed (on most custom ROMs) & most custom ROMs do this (if there's a custom ROM that makes updater a hard dependency of course it'll go to Major Disadvantages and therefore cannot be recommended).
Pictured above is Game Space, which is meant to be an open source alternative to Goolag's proprietary Game Dashboard, which provides an user interface for the Android Game Mode API. Listed below are some clarifications of why Game Space is irrelevant to me. (in a nutshell, most of these either could be disabled and/or have more effective substitutes in the ROM's settings, and what cannot be disabled could with some change in device usage)
Conclusion : I'd just put Game Space in the "doesn't matter to me" section here as it can be taken down in the same way the auto-updaters mentined above are. Sure, Game Space setting will never work again afterwards, but since I don't care on the long run...
Not as properly explained as sensors permission.
Also known as the thing that stands between you & the system on 1st boot that's found in LineageOS, Lineage-based ROMs, & CarbonROM. For those 3, unless it's replaced with Goolag SetupWizard, you don't really need internet connection to get through (some ROMs, such as GApps variants of WaveOS demand internet access).
As I also mentioned Goolag SetupWizard, I don't consider them as a part of this, since it could force you to connect to the internet on 1st boot. In that sense, it goes in Major Disadvantages, but then again GApps-only alone (or Limbo) instantly disqualifies a custom ROM for me so...
This feature disables charging when a given level is reached to protect battery health. However, some devices (such as X3N/P) has an issue where its power management chip could bug out if this feature is enabled (forcing a reboot to bootloader just to charge).
I consider this feature not important as this is easier to replicate (probably without fucking up the power management chip as well, so it might be safer as well) by simply charging from 20% (15% is the lowest I generally reach) to at least 80% (at which point it will be unplugged). Battery monitoring / alarm tools (such as Accubattery / BatteryBot Pro / ≥A14 battery menu in Settings) helps as well. You might want to replace your charging port after several years of use though (if it wears out), assuming you keep using the same device for the foreseeable future.
Imagine having already set up your apps to your liking, and having to replace your device's battery (which resets device time for some reason, particularly on those "non-replaceable" batteries). And then, you re-correct the device's time (because after all that repairs the system decides to rollback the time to when it was built)... only for the system to notify that you haven't "used" some apps - let's say FGO as an example. After notifying, AOSP immediately wipes out the "temporary file", which unfortunately also counts your account in, forcing you to recover the account (hope you have your keys updated).
Now, that one might not be true (especially regarding how Unused apps work), since I haven't really encountered that issue - let alone had it actually happen on me (at worst Simple Draw & LineageOS recorder, but I don't really use those). But still - if I wanted to deal with apps I don't use, it has to be on my hands. By the way, this "feature" is inbuilt in AOSP.
Back to top