So, I was facing an issue.

I had installed Android 6 on a Samsung Galaxy Tab 2; however, connecting to WiFi simply yielded... nothing.

It would try for about 10 seconds and then wouldn't even give me an error. It'd simply say "Saved." I've dealt with this for years on older devices, mostly accepting it without question, but this time I decided to actually question it.

I've since narrowed down the issue to the fact that my router was using PMF, and versions below Android 9 don't support it at all. But it took a decent amount of time to get there.

It didn't throw an error, at least not a meaningful one, and I only realised that I could use logcat much later.

All this is to say, I think it's quite interesting how so many of Android's problems can be attributed to the simple fact that it was foundationally Linux hacked onto a phone.

Linux utilities are meant to log an error to the journal and die while the rest of the system keeps running. It is generally bad practise for them to alert the user directly. I can't imagine translating that to a neat message box, one possibly on another thread, being easy.

And this is exactly the problem with Android's core networking system. It drops a line into logcat and just keeps going.

To turn that into a helpful user experience, the Android framework (written in Java/Kotlin) has to constantly poll or listen to these low-level native states.

Furthermore, why doesn't Google modify wpa_supplicant to throw a neat little error? It's possible, but just highly impractical.

In reality, trying to force an open-source C daemon to talk directly to a high-level Java/Kotlin framework is an architectural nightmare. Google did actually try doing things like this in the early days, and it turned into a massive engineering bottleneck for a few core reasons.

Large parts of this come down to the fact it's C. For a C utility to tell Kotlin anything, it needs to go through the Java Native Interface.

C, of course, doesn't know what a Kotlin "error" or "exception" is. Rather, it uses raw memory addresses, integer status codes, and string buffers.

Google would have to write hundreds, maybe thousands of JNI bindings for every single edge-case error condition in the low-level code. And, lest we forget, JNI calls are slow, prone to memory leaks, and notoriously hard to debug.

Oh, and that would require a fork, an architectural headache in its own right. Either way, wpa_supplicant is an independent project; it has no direct affiliation with Android.

Creating a fork would mean maintaining a special Android version of wpa_supplicant, to which they would have to manually merge every critical, urgent fix.

Don't even get me started on doing this dozens of times for every external project Android uses.

And at a certain point, you need to ask the chip what happened. Many, with their proprietary drivers, will return something close to WLAN_REASON_UNSPECIFIED. And "we don't know" doesn't look great on an error.

Locking everything in the attic

The root of the issue is that it requires ADB. You can't easily view logcat's logs from an Android device; you'll usually need a PC, or maybe you can hack something together using Shizuku.

This is the most mind-boggling part of it. If everything dumps info into logcat, why not just let someone look there?

The reason it's hidden comes down to a few things. Namely, historically, any app with the READ_LOGS permission could read the system log. This was a massive security risk because malicious apps could sniff the logs to see what other apps were doing, leak personal data, or track user activity.

Plus, logcat lists 12 new errors every time you touch the screen (I'm barely exaggerating), so it's hard to find what you're actually looking for.

Google locked this down pretty tightly. Now, apps cannot read system-level logs without root or ADB access. Even if they built a native Quick Settings tile to show logs, they would have to build a highly privileged and secure UI wrapper to expose that data without opening security vulnerabilities for the rest of the OS. Not the easiest thing in the world.

But let's be honest here, it's not exactly hard on a project of Android's scale.

And Grandma exists, sure, but it's also not exactly hard to add it as a quick settings tile that can be enabled in developer options. Android already does this.

Because you can't see that your device lacks PMF support, you never realise you need to disable it. It'd be messy, but better than nothing.

Instead, it leaves you to think "Android is buggy or broken."

I genuinely think Android is ideologically harmed by Google and fundamentally tries to hide what it was built for in fear of driving away consumers who only want an ideal frictionless appliance.

The user won't blame the march of time; they'll blame Android. And I can't help but feel like Google would rather that than admit Android is a Linux-based operating system. And Linux is just... like this.

Linux in a trenchcoat

Google has spent over a decade trying to scrub the "Linux-ness" out of Android’s public image.

In the early days, Android largely embraced its tinkering roots. It was almost encouraged to use a launcher and mess around.

Today, Google wants Android to be viewed identically to iOS, a seamless, locked-down consumer appliance.

That's not an insult to Apple, and it's not a compliment to Google's recreation.

To acknowledge that a Wi-Fi connection failed because of a low-level native daemon handshake error is to admit that Android is not a cohesive, bespoke piece of silicon magic.

It is to admit that Android is a massive, complex stack of open-source Linux utilities, legacy C code, and driver blobs shoved inside a Java virtual machine.

Linux, and the software ecosystem around it, are incredibly powerful, but it is like this. It expects configuration mismatches. It expects the administrator to look at a log, tweak a config file, and move on.

That's what the Linux networking stack is and will be for the foreseeable future. But no, Android must be some perfect, top-down piece of software. Because iOS is.

Mayday, mayday, mayday!

When Steve Jobs walked onto the stage in January 2007 to announce the iPhone, the Android team was actively working on the Sooner. It was a BlackBerry clone with a non-touch screen, physical QWERTY keyboard, d-pad navigation, and a 2G radio; it didn't even have Wi-Fi working yet.

Android was still aiming to accommodate all screen sizes, but the Sooner was meant to be released, well, sooner than the theoretical touchscreen device that was somewhat planned but also not really.

Andy Rubin famously watched that keynote from a taxi and realised their entire roadmap was instantly obsolete. They pivoted immediately to the "Dream" (the HTC G1), tacking touchscreen capabilities onto an operating system that was architected to be a keyboard-and-button messaging platform.

See, when Apple built iOS, they designed a monolithic, top-down operating system. Every single component, from display compositor to network daemon, was built from scratch to pass information cleanly up the chain to a highly controlled user interface.

In 2006, official design specs treated touchscreens as entirely optional, and physical buttons were assumed, though the architecture didn't disallow touch capabilities per se.

When Google bought Android, a startup that had briefly started in 2003 trying to build a digital camera OS, in 2005, they weren't trying to build a touch-first flagship.

Google didn't have the luxury of time that Apple had; they had only 18 months to pivot a button-oriented project into a touch-first smartphone OS.

We don't know a tonne about Android's pre-2008 development, but given that the Sooner was meant to come first, we can assume the sudden shift to a touch OS in just 18 months wasn't exactly handled with complete sobriety.

If Google had handled the launch with complete sobriety, they might have taken the time to write a proprietary, highly integrated networking stack natively unified with the UI, the way Apple did and the way they honestly should've. But they were in a literal race to stop Apple from locking down the entire mobile market forever.

Google was building Android to beat BlackBerry until Apple forced everyone to pivot. Congrats, Google; Apple doesn't have a monopoly! And the cost is permanent tech debt.

The underlying Linux system is pulling one way, and Google's product managers are pulling another. The result: "Saved."

Hardware sci-fi with usability crimes

The Sooner really could've killed BlackBerry, just not in the same way the iPhone did; it was designed to compete directly in BlackBerry's territory.

It did more than any BlackBerry could; it was in many ways better. BlackBerry occupied a distinct market from smartphones, one that still exists today, and the Sooner happened to also be in that market.

BlackBerry's death was accelerated by the iPhone, sure, but it wasn't directly caused by it. The iPhone faced major backlash at launch from "serious businessmen" who hated the lack of an actual keyboard.

The problem was largely that BlackBerry misinterpreted the iPhone. Instead of sticking to their guns, improving the platform, and keeping BlackBerry as a product alongside the iPhone, they panicked. They both didn't do enough and did too much.

When the iPhone launched in 2007, BlackBerry executives initially dismissed it as a battery-draining toy with a poor digital keyboard, choosing to double down on their physical keyboards, enterprise security, and corporate email rather than immediately changing their design path.

But that was both arrogant, as it completely dismissed the iPhone, not as a threat to adapt to but as something to ignore.

The next problem is that they didn't stick to it. They launched successful physical-keyboard devices like the Bold 9000 in 2008, but in November 2008, they released the BlackBerry Storm.

Which might've been fine, but it had a clickable screen.

You're probably as confused as I was, but the screen clicked. The entire glass display physically moved downward. Didn't catch on; you can imagine why.

Many users found the physical clicking cumbersome, stiff, and slow, and that is a moving part. If you drop it one too many times, the entire gimmick breaks. You can also imagine it being rather tiring.

The BlackBerry Storm could've worked, absolutely. The BlackBerry Storm could have worked if they had released an SDK with the new screen dimensions in advance and required all new apps to support it, made sure it was easy for existing apps to support it, and, in worst-case scenarios, just ran it in the classic form factor and added some emulated buttons.

An instant, sprawling app library and iPhone competitor. But the weird lack of dedication to touch (clickable screen, seriously?) and lack of trust in the whole "iPhone clone" thing doomed BlackBerry and made the attempts to course correct resounding failures.

Five. Hundred. Patches.

So where does Android fit into this? Well, in 2006, Android wasn't competing with Apple; it was competing with RIM. Android very well could've swooped in and stolen BlackBerry's customers while they were fumbling. But I guess you can't do that when you're making the same mistakes.

I honestly think that Google made choices when the iPhone was released that they wish they could take back. Maybe rip out the networking stack and replace it with their own, or stop dumping everything to logcat.

But when you're spiralling, and you need to get something out immediately, you don't think about portability. You make choices you cannot change.

So what has Google been doing about it? Decoupling core components and rewriting daemons in Rust and C++. This effort has seen modest success, but progress is slow.

It will take years to detangle this mess, and I highly doubt it will ever truly be as good as it could've been from the start. Every quick fix from fifteen years ago has become today's foundational architecture.

Detangling that web takes massive engineering resources, and as long as the OS's philosophy favours hiding errors over surfacing them, there's very little incentive for leadership to prioritise fixing the diagnostic pipeline.

Modern Android has actually been replacing wpa_supplicant with nl80211 / wificond / WifiNl80211Manager in recent versions to modularize the Wi-Fi stack. The fact Google is still untangling this 15+ years later shows how deep it actually runs.

Sweet nothings

There's an interesting fallacy I see often, and it's regarding simplicity.

The classic stereotype of "Grandma thinking her computer got hacked" when a popup appears comes down to a lack of phrasing and clarity.

If you pop up an error saying "Unhandled exception" with a string of arbitrary characters, what do you want people to think? That they're getting a prize?

If you phrase it correctly, you can say something like:

"This app has encountered an internal issue. [OS] and other apps will not be affected. If you want to troubleshoot it, here's more info: Unhandled exception (0x12345678)"

Or perhaps in an optimal scenario:

"Sorry, your device doesn't support (hardware feature), which is necessary for (action)."

I doubt anyone will be distressed by that.

Compare it to just something like:

"This app has encountered an error."

Grandma won't be worried, but she won't have anything to do either. Making complex systems clear makes them manageable; hiding failure states does not. And there's a difference between using layman's terms and "dumbing it down."

Simplicity is not the same as secrecy. By treating every user like they can't handle basic diagnostics, we erode general technical literacy.

We turn computing devices from tools you can understand and configure into black-box appliances you can only restart and pray over.

The final question is, Google won. Android hasn't faded into obscurity. Was it worth it? From a corporate perspective, yes, it was a home run.

Android powers roughly 70% of the world's smartphones. If they hadn't panicked, rushed, and hacked low-level Linux daemons to a Java framework in 18 months, Apple might have locked down the global smartphone market, or Microsoft/BlackBerry might have stumbled into a dominant position.

But it created a permanent tax on debuggability and software quality. We have market competition, but at the cost of jeopardising Android, in a way I fear will catch up to them within the next decade.

A large reason why Android exists today is that they were early. Nobody has disrupted Google or Apple because of their untouchable app ecosystems. It's a large reason why other Linux phones are somewhat doomed. If they didn't manage to scoop up that market share at the beginning, Android would've been a distant memory.

A necessary evil.