How Phone Makers Ruin Android with Bloatware, Heavy Skins, and Broken Updates

Date: 11/08/2025

In one of our previous pieces, we took a close look at why Apple smartphones have been—and will continue to be—faster than current Android flagships. The article sparked lively debate and mixed reactions. With that in mind, we decided to take the topic further and dig deeper, discussing the roadblocks Android smartphone makers themselves put in the way of what is, fundamentally, a solid platform.

Android: the Good and the Bad

This article won’t cover the bugs and quirks of stock Android—the reference build made up of AOSP plus Google services that ships on Android One devices, Google Pixel phones, and handsets from a few OEMs (like Motorola and Nokia). We’ll call this Android “good”: whether you like its features or not, it’s how the system was originally designed. Compared to OEM-skinned versions, “good” Android is typically better optimized and more likely to receive regular updates—at least from manufacturers that have made “pure Android” a key selling point.

Right now, we’re going to talk about how manufacturers—HTC, LG, Samsung, and others—try to improve the system, and how that actually turns out.

Bells and Whistles: Good Intentions, the Asian Way

The first thing that greets you when you power on any brand‑new flagship is the animated boot screen. American makers are modest: on iPhones and iPads you get nothing but a white, static Apple logo for the entire boot. Windows 10 Mobile phones do the same with a static blue Windows logo. Google is far less modest, showing a playful multicolor animation that even changes between Android versions.

What do the splash screens from these manufacturers have in common? They don’t bother us with unnecessary sounds.

“La-la-la!” shout LG phones when they power on. “Oops—boom-ts!” proclaims an HTC flagship as it boots, blasting through its BoomSound speakers. Phones kitted out with that first and foremost bell-and-whistle—tailored to Asian tastes—serve up all sorts of equally loud jingles. And while the Chinese Lenovo, dressed up as the American Motorola, lets you disable that noisemaker, an LG or HTC that decides to reboot itself in the middle of the night will be sure to celebrate the occasion by waking its drowsy owner.

Notifications

Android has a well-thought-out, excellently implemented notification system—head and shoulders above iOS. What could there possibly be to improve? Unfortunately, some Asian manufacturers have tried—and every such “improvement” ends up being destructive.

Let’s start with HTC. For some reason, reviewers keep repeating that the latest versions of HTC Sense are basically stock Android, lightly refined in all the right places. Sorry, dear reviewers, but you can’t “improve” Android with ham‑fisted tweaks. Here’s what HTC’s developers did to notifications.

“Ever since the update, apps keep sending audible notifications, even though the default is set to silent—and everything worked fine on Android 7,” the user complains. What follows is a sprawling set of instructions on where to go and how to disable sound for every installed and system app, as well as for subcategories within each app. The result: “It helped, but not much—sound turning on by itself happens less often on the phone, but it hasn’t gone away.”

Let’s look at the first screenshot.

What are we looking at here? Just the standard notification sound settings in stock Android. What could possibly go wrong? Set notification sounds to silent and enjoy the peace; the phone will still ring for calls, but it won’t beep, blare, or chirp across the room for every incoming email.

Sorry, but HTC’s developers know better what you need. Notifications without sound? Perish the thought. So they “improve” Android by slapping on their own janky layer for granular notification controls. Now every single one of your apps—no matter how many you’ve installed—couldn’t care less about the silent notification mode you set in Settings and is instead governed by something like what you see in the screenshot below.

In stock Android, even notifications that are allowed to make noise still come in silently. HTC went the other way: every notification will play some tone, completely unrelated to what you picked in settings. Got a hundred apps? Better go through HTC’s settings and disable sound for each one. Installed a new app? Don’t forget to open its notification settings and turn off its sound, or you might get an unpleasant surprise.

Why did such a trivial thing take so many words? Simply because on my own HTC U11 I burned more than an hour and a half trying to disable sound notifications for all apps—and the phone still chirps every now and then. Honestly, this “improvement” alone is reason enough to ditch that obnoxious flagship.

You’ll say it’s a bug and they’ll fix it in a future release? Let’s see. Android 8.0 with this “improvement” rolled out to the HTC U11 in December 2017. January, February, March… no updates, and no clear indication whether they’ll fix the bug at all—or if it’s actually a feature.

By the way, after calling out HTC, I have to mention LG’s interface as well: it doesn’t let you choose a “silent” notification tone at all. It’s as if the idea that someone might not want their phone constantly chirping never occurred to LG’s developers.

The result? You end up resorting to hacks, like creating a “silent” audio file. And don’t even get me started on the charging start/finish sounds you can’t disable in settings: every night the phone greets me with a cheerful chirp—“Hooray! I’m charged!”

Here’s a trick question: do you think it’s a bug? No! It’s a deliberate choice by LG’s engineers (certainly not the UI designers), carried over from one Android version to the next. 5.0, 5.1, 6.0, 7.0 — same story across the board. Bravo—terrific “improvement”!

Just like an iPhone — only lighter!

On HTC devices, notifications work and look the way Android’s designers intended. Some other manufacturers, however, like to “make it pretty,” mangling Android’s default design in an attempt to mimic the iPhone. The result… is really bad. Think 90s knockoff boomboxes with a mess of blinking lights and neon colors.

This is what it looks like on Huawei (on the right — “stock” Android):

And here’s the kind of nightmare the infamous LeEco came up with:

This is how LG envisions the ideal Android 6.0 interface: oversized navigation buttons, oversized quick-toggle icons at the top that clearly don’t fit, and the already tweaked stock toggles “improved” further with horizontal scrolling.

What’s wrong with these interfaces? Like any other bells and whistles, they not only scream bad taste (and no, “there’s no accounting for taste” doesn’t apply here; unless it’s cultivated from childhood, taste will be poor—sometimes downright awful), they also wreck the user experience with jarring switches between Android’s now-classic Material Design and the gaudy, translucent flourishes favored by some Asian developers.

Another area where some manufacturers try to mimic iOS is screen brightness control. In recent versions of Android, when auto-brightness is enabled, the slider doesn’t adjust brightness directly; it tweaks the curve that maps screen brightness to ambient light. That makes sense: set it once to what feels right, and you can forget about it.

Unfortunately, some manufacturers “improve” this logic by tying the brightness slider in auto mode directly to the screen backlight level. That’s what OnePlus did, for example (and as everyone “knows,” OxygenOS is like stock Android—only better). As a result, if the auto-selected brightness levels don’t suit you, you end up constantly sliding it back and forth. The fact that iOS manages brightness the same way doesn’t make it any less irritating.

Speaking of recent OnePlus models, there’s another “upgrade” worth mentioning. The company added a hardware alert slider—“like on the iPhone, only better.” The three-position switch on the OnePlus 5 and 5T lets you quickly move between audible and silent notification modes. Sounds handy, right? Sadly, not really: the developers didn’t manage to handle Android’s notification-mode logic and ended up ripping out a genuinely useful feature—scheduled and event-based Do Not Disturb (for example, during important calendar meetings). Users are effectively invited back to the good old days of dumb electronics and lots of physical toggles. Want silence at night? Flip the switch. Forgot to flip it and got woken up by an early-morning promo SMS? Don’t blame the devs—just remember to flip the switch next time.

Optimization

What I love about Pixel phones is their exemplary, textbook-grade optimization. Even though the first-gen Pixel ran underclocked chips and used eMMC storage that was slow by 2016 standards (while other flagships shipped with faster UFS 2.0), Google’s phones are butter-smooth. No animation lag or stutter, no surprise overheating, no awful sluggishness after waking from deep sleep. Apps launch at a predictable pace and run consistently smoothly. Honestly, that precision and fluidity are exactly what’s been noticeably missing from recent versions of iOS.

Comparing the first‑gen Pixel with HTC’s pseudo-flagship U Ultra (Snapdragon 821, UFS 2.0), it’s hard not to notice that the HTC phone: a) overheats under basic workloads, and b) stutters and lags, leaving the impression the CPU is running on fumes. Waking from deep sleep, the U Ultra spends the first few seconds moving at a snail’s pace (even the notification shade opens in jerks, and only after a noticeable delay). Is this an Android problem? No: the Pixel, running on similar hardware, shows none of this. It’s just poor—very poor—optimization.

I could cite plenty of similar cases. Take the LG G Flex 2—overheating, often while idle, when the device would suddenly start crunching numbers with the screen off, cooking your pocket. You could write a whole series about battery drain from unresolved kernel wakelocks that make a phone act up in standby; there’s no real fix even with root access—only a vendor patch or a custom ROM will help.

Critical bugs and rough edges

How would you feel if your phone turned into a brick after an update? It’s rare for most vendors, but it does happen. If a bug affects only a small number of users and only once in a while, it won’t do serious damage to the vendor’s reputation. But if every device starts locking up after an OTA update, that’s a serious problem.

That’s exactly the kind of “improvement” OnePlus’s hapless developers made to Android. With the release of Android 8, something went wrong: every OnePlus 5 user with an unlocked bootloader who installed the first, then the second, and then the third update (all pushed less than a week apart) ran into a data decryption error—the phones wouldn’t boot. Wiping the device and restoring from a cloud backup helped—right up until the next update.

Android Driver Quality

You can say a lot of good things about Android drivers, but is the device maker always to blame? Some drivers come from the chipset vendor (Qualcomm, for example), and others—like for the camera module—are provided by completely different third-party manufacturers. It’s surprising that this patchwork works at all… or wait: does it actually work?

Take OnePlus as an example: its developers made a critical mistake by overlooking the encryption quirks of Android 8. The company rolled out a “revolutionary” camera module whose sensor includes phase-detection autofocus pixels. The marketing team ran with it and launched the OnePlus 5 under the slogan “Clearer photos.” What could possibly go wrong?

Let’s take a look at this photo:

What is this? Why is the sky polka-dotted? It turns out OnePlus cut costs by buying a Sony camera module with drivers but choosing not to pay for further development and bug fixes. As a result, Sony’s drivers don’t account for the phase-detect autofocus (PDAF) pixels, which show up in photos as a polka-dot pattern. Obviously, you couldn’t market those shots as “clearer photos,” so OnePlus’s developers were tasked with masking the issue. And they did: they cranked noise reduction to extreme levels, which, along with the PDAF “peas,” also wipes out all the fine detail in the image. Problem solved!

Think it was a one-off? Not even close: six months later the company released a second phone—the OnePlus 5T—with the same hardware module, the same drivers, and the exact same problems. They made the same mistake again after prolonged, vocal user complaints? Who cares—people will buy it anyway!

Why Android phones get slower after updates

We’ve already covered driver quality. Drivers are often the reason a device performs poorly—especially when a manufacturer cuts corners by upgrading Android but leaving the original drivers untouched.

How is that even possible? Up until Android 8 and Project Treble, every new Android release brought API changes that forced chipset makers to ship new driver versions for major system updates. Driver releases aren’t free, and vendors had to pay for updated code—either per update or under a contract tied to the chip purchase. But what if the vendor doesn’t want to pay for new drivers, and the system still needs an update? In such cases, a common workaround is a software shim that translates new API calls to the API version supported by the old drivers. Strictly speaking, that’s the wrong approach; it clearly limits performance and compatibility and often blocks access to new features in the latest Android release. Nevertheless, it’s quite popular among custom ROM developers—if only because updated drivers may simply not exist. A classic recent example: custom ROMs based on Android 7, 8, and 8.1 for LeEco smartphones that never got updates beyond their original Android 6.0 base.

Unfortunately, some vendors take the exact same approach. The OnePlus 5 and 5T shipped with Android 7. The update to Android 8 reused the old drivers and a software shim.

You might think it’s a one-off, and from some fringe Chinese vendor. But what if I told you the exact same thing is being done by the largest Android smartphone manufacturer—Samsung—and not for someone else’s silicon, but for its own Exynos chipsets?

info

If you’re interested in a shim system for emulating new APIs, we recommend the article Cameras in Custom ROMs: How Developers Make Hardware Work without Source Code.

Samsung and Software Updates

To start—an article: Samsung, Exynos and AOSP Explained: A Story of Betrayal.

In this article, the developers explain in great detail how, at Samsung, just about everything that can be done wrong is done wrong. In particular, Samsung often relies on software shims—translation layers for APIs—when upgrading Android versions. Over numerous updates, the changes pile up, the shims get thicker, and performance gets worse. Because of these stacking layers, Samsung’s skin ends up running abysmally over time, even on very powerful devices. It’s not that Samsung is deliberately slowing them down; they just don’t seem to know any other way.

Samsung’s Code Quality

We’ve covered the gimmicks and the mangled UI, the lack of optimization, and the shoddy drivers. How else can you ruin Android? Turns out, it’s easy: just be Samsung.

While many vendors slap their software and drivers together with duct tape and baling wire, Samsung’s developers didn’t even get the duct tape. The result is a UI skin that manages to stutter and lag on a processor with more horsepower than many ultrabook CPUs.

You’re probably thinking: sure, everyone at Samsung is an idiot and the lone author of this piece is the only smart one. Whether that’s true or not, the skill level of Samsung’s programmers is definitely below zero. Remember the saga of the company’s in-house project, the Tizen OS, about which people literally wrote the following:

This might be the worst code I’ve ever seen. Every mistake that could be made was made. It’s obvious the code was written or reviewed by someone who understands nothing about security. It’s like asking a schoolkid to write your software.
Source

Of course Samsung couldn’t leave a claim like that unanswered. After Motherboard published the research findings, Samsung started working on fixes. The result is notable: Tizen’s code is no longer “the worst ever.” Now it’s just awful, not awful-awful.

Sure, but what does Tizen have to do with this—we’re talking about Android. And indeed, the parts of Samsung’s software that come from Google work just fine. The problem is that Samsung tries to rewrite and rework as much of Google’s OS as possible, swapping out whatever they can for their own in-house apps and changing the system both visually and under the hood. The result? Lag, stutter, garish and inconsistent UI design choices, and plenty of bugs.

And what about duplicate apps? When I bought my first Android smartphone, I was confused right away. Why are there “Contacts” and “Contacts”? Why two different browsers? Why “Clock” and “Clock”? What’s the point of two email clients? Over time, most reputable manufacturers stopped bundling their own apps that duplicate Android’s core functionality. But not Samsung, which keeps stubbornly shipping its own web browser (why? Does it translate foreign-language pages or sync passwords with your Google account?), its own email client, and a slew of other in-house utilities.

And what about the infamous Bixby button that launches the assistant if you press it by accident? You can disable it, but first you have to set up Bixby—and that requires downloading and installing a bunch of Samsung bloatware I’ve already talked about.

A special mention goes to Samsung for a brilliant security innovation.

On any other Google-certified smartphone, to unlock the bootloader you first enable OEM Unlocking in settings, then reboot into fastboot, run fastboot oem unlock (or a similar command)—and immediately lose all your data. Wiping data during bootloader unlock is a critical security measure that protects against unauthorized access via root or a custom recovery.

On Samsung devices (at least the Galaxy S8), unlocking the bootloader is as simple as enabling OEM Unlocking in the settings—and that’s it. You can then boot into a custom recovery, gain root, and extract data. It’s a glaring security gap that feels almost intentional—and the people hurt by it aren’t the tinkerers flashing root or custom ROMs, but ordinary users whose data can be easily exfiltrated via an unlocked bootloader.

If after all that you still consider Samsung’s flavor of Android “normal,” I have nothing more to add.

Software updates

A good operating system updates quickly, reliably, and on schedule. Apple’s iOS has long been considered the gold standard for updates, but there are other manufacturers that do an excellent job keeping their devices current. To start, take a look at this table (source):

As you can see, Apple and Microsoft keep their devices updated for a long time, with regular, timely releases. What’s more, Microsoft is still shipping updates for Windows 10 Mobile phones—including models made by third-party vendors—even after abandoning active development of the platform. That stance deserves respect, especially when most Android phone makers treat updates as an afterthought: if a model sells well, it might get an update someday; if not, it’s quietly forgotten.

Take HTC, for example. The not-so-cheap HTC U Ultra (Snapdragon 821) has been running the same Android 7.0 it shipped with for a full year. HTC doesn’t provide updates to intermediate Android releases. The last security patch the U Ultra received was in November, and the Android 8.0 rollout (six months after that OS version was released) keeps starting and stopping due to discovered bugs.

  • Android 8.0 update for the current flagship (U11): 99 days
  • Android 8.0 update for the previous flagship (HTC 10): 180 days
  • Update transparency: poor (only a list of devices slated to receive the update)
  • Verdict: poor

The situation is a bit better with OnePlus:

  • Android 8.0 update for the current flagship (5/5T): 137 days
  • Android 8.0 update for the previous flagship (3/3T): 91 days
  • Update communications: average (forum, open betas)
  • Verdict: mixed

Motorola was once held up as an example of a company that not only provided long-term support for its devices, but also pushed rapid updates to the latest Android releases thanks to its use of stock Android.

  • Android 8.0 update for the current flagship (Moto Z2 Force): 124 days
  • Android 8.0 update for the previous flagship (Moto Z): still not available; over 200 days
  • Update communications: poor (only a list of devices slated to receive the update)
  • Verdict: unsatisfactory

LG is infamous for dragging its feet. No surprise: updating their heavily “improved” skin means tons of work for the people who “improved” it.

  • Android 8.0 update for the current flagship (V30): 166 days
  • Android 8.0 update for the previous flagship (G6): still not available; over 200 days
  • Update communication: poor
  • Overall verdict: unsatisfactory

What about Samsung? The largest Android smartphone maker has turned out to be the slowest among its competitors.

  • Android 8.0 update for the current flagship (S8): 172 days
  • Android 8.0 update for the previous flagship (S7): still not available; 200+ days
  • Update information: poor
  • Verdict: unsatisfactory

Think Samsung is the slowest? Wait till you see BlackBerry. How fast an Android device gets updates has little to do with the brand’s clout, loud promises, or the price tag. BlackBerry promised two years of support for the DTEK60 (for the record: Snapdragon 820 and far from cheap), yet since the phone launched in 2016 it has delivered exactly zero Android OS upgrades. And that “two years of support”? Apparently, they meant security patches only.

  • Android 8.0 update for the current flagship: still no sign (200+ days and counting)
  • Android 8.0 update for the previous flagship: never
  • Android 7.0 update for the previous flagship: never
  • Update transparency: abysmal (no complete list of devices slated to get the update)
  • Verdict: as bad as it gets

Are there any vendors that reliably keep Android up to date? Yes—two: Google and Nokia. Google goes without saying: the main selling point of its devices is that they get updates directly from the manufacturer.

Android updates from Google:

  • Update to Android 8.0 for the current generation: 9 days (0 days for beta testers)
  • Update to Android 8.0 for the previous generation: 18 days (0–18 days for beta testers)
  • Update communications: good (public betas via OTA)
  • Result: excellent

Another vendor that keeps Android up to date—at least on its flagships—is the “new” Nokia run by HMD Global. So far the company has just one flagship, which launched on the previous Android release, so we don’t have much data yet. Even so, the early signs are promising.

Android updates from Nokia:

  • Android 8.0 update for the current flagship: 90 days
  • Android 8.1 update for the current flagship: 58 days
  • Update information: good
  • Result: good

Conclusion

In a good mobile OS, everything comes together: the drivers and the look and feel (even if aesthetics are subjective, consistency in applying the chosen interface paradigm is a fairly objective metric). Smooth performance is, of course, crucial. Security, vendor support, and regular updates are equally important. That’s exactly the user experience Google delivers with its Pixel and Pixel 2 lineups.

Unfortunately, things are far less rosy with other vendors. Mangled, tasteless spins on the user interface (and I’m not talking about the home screen design — swapping the launcher is easy), the usual gimmicky “bells and whistles” some Asian OEMs cram in, “enhanced” notifications you literally can’t silence, gaping security holes that look almost deliberate, and awful drivers that get papered over with shims and reused again and again in new Android releases — assuming those new releases ever arrive at all… All of this is ample fodder for criticizing Android.

Related posts:
2022.02.15 — First contact: How hackers steal money from bank cards

Network fraudsters and carders continuously invent new ways to steal money from cardholders and card accounts. This article discusses techniques used by criminals to bypass security…

Full article →
2023.04.19 — Kung fu enumeration. Data collection in attacked systems

In penetration testing, there's a world of difference between reconnaissance (recon) and data collection (enum). Recon involves passive actions; while enum, active ones. During recon,…

Full article →
2023.07.07 — Evil Ethernet. BadUSB-ETH attack in detail

If you have a chance to plug a specially crafted device to a USB port of the target computer, you can completely intercept its traffic, collect cookies…

Full article →
2022.06.01 — WinAFL in practice. Using fuzzer to identify security holes in software

WinAFL is a fork of the renowned AFL fuzzer developed to fuzz closed-source programs on Windows systems. All aspects of WinAFL operation are described in the official documentation,…

Full article →
2022.06.03 — Vulnerable Java. Hacking Java bytecode encryption

Java code is not as simple as it seems. At first glance, hacking a Java app looks like an easy task due to a large number of available…

Full article →
2023.01.22 — Top 5 Ways to Use a VPN for Enhanced Online Privacy and Security

This is an external third-party advertising publication. In this period when technology is at its highest level, the importance of privacy and security has grown like never…

Full article →
2023.07.20 — Evil modem. Establishing a foothold in the attacked system with a USB modem

If you have direct access to the target PC, you can create a permanent and continuous communication channel with it. All you need for this…

Full article →
2022.01.12 — Post-quantum VPN. Understanding quantum computers and installing OpenVPN to protect them against future threats

Quantum computers have been widely discussed since the 1980s. Even though very few people have dealt with them by now, such devices steadily…

Full article →
2023.02.21 — Pivoting District: GRE Pivoting over network equipment

Too bad, security admins often don't pay due attention to network equipment, which enables malefactors to hack such devices and gain control over them. What…

Full article →
2023.03.26 — Attacks on the DHCP protocol: DHCP starvation, DHCP spoofing, and protection against these techniques

Chances are high that you had dealt with DHCP when configuring a router. But are you aware of risks arising if this protocol is misconfigured on a…

Full article →