Myths vs facts

Every technical field accumulates folklore, and Android has more than most because so much of it happens out of sight. The myths below are not stupid; each one was true somewhere, or is a reasonable guess from the outside. The correction is usually more interesting than the myth.

TL;DR#

• Android is Linux, but not GNU/Linux. The kernel is Linux; the C library, init, userland and programming model are Android's own.
• "Android" is three things. AOSP, Google Mobile Services and the vendor stack are maintained by different people and update differently.
• Killing apps makes things worse, not better. Android's memory model deliberately keeps processes cached, and refilling that cache costs CPU and battery.
• Deprecated does not mean removed. Deprecated APIs usually survive for years because installed apps depend on them.
• An APK is a ZIP with a contract. The archive format is the least important part; the signing block and package validation are what make it installable.

Mental model#

Folklore grows where observation is indirect.

You can see your phone's battery drain. You cannot see the scheduler, the low-memory killer's decisions, or the Binder calls behind a notification. So you build a story from the visible part: "the app was open, the battery died, therefore open apps drain the battery." The story is plausible, testable — and wrong, because the causal chain runs through a mechanism you cannot see.

Every myth below is a story of that shape. The fix is not to memorise a rebuttal but to know which mechanism to look at. That is what the "what to check" line is for.

Where the analogy breaks#

Folklore sometimes contains a real problem. Task killers existed because early Android devices had little RAM and aggressive apps really did hurt. "Android is fragmented" was a serious complaint before Treble. The myths are stale fixes for problems that the platform has since solved differently — which is why the correction is often "the platform now handles this", not "you imagined it".

The big picture#

That diagram is the antidote to the most common myth of all: that "Android" names one thing. It does not. It names a platform (AOSP), a commercial layer (GMS), and whatever the OEM put on top, and those three have different owners, different schedules and different update mechanisms.

Deep dive#

Myth 1: Android is just Linux#

The claim. Android is a Linux distribution, like Ubuntu with a phone skin.

What is true. The kernel is Linux. Android contributes drivers and features to it, and the kernel is where scheduling, memory management and SELinux enforcement happen.¹

What is not. Almost everything above the kernel is Android's own. The C library is Bionic, not glibc. There is no GNU coreutils by default. init is Android's own implementation with its own configuration language, not systemd or SysV. The primary programming environment is a managed runtime, ART, not a shell and a C compiler. The security model is built around app sandboxes and Binder, not around Unix users and pipes.

What to check. Run adb shell ls /system/bin and look for the absence of the GNU tools you would expect on a desktop distribution.

Myth 2: Android is Google#

The claim. Google owns and controls Android, so "Android" and "Google" are interchangeable.

What is true. Google leads AOSP development and owns the GMS layer. Most Android phones ship with Google's apps and services.²

What is not. AOSP is open source and can be built by anyone. Devices ship without GMS — Amazon's Fire tablets, many Chinese-market phones, and countless embedded devices. The compatibility programme (CDD and CTS) is what a device must satisfy to ship with Google's apps, not to be Android at all.³

What to check. Look for com.google.android.gms in the installed package list. Its presence or absence tells you which layer the device has.

Myth 3: You should kill apps to save battery#

The claim. Apps running in the background drain the battery, so a task killer or a regular "clean" improves battery life.

What is true. An app that is genuinely misbehaving — holding a wakelock, polling a network, or running a foreground service it does not need — does drain the battery. Android has progressively restricted exactly this, from Doze to background execution limits to foreground-service types.

What is not. Killing every background app is counterproductive. Android keeps recently used processes in memory on purpose: a cached process costs nothing while it sits there, and it makes the next launch fast. Killing it forces the system to rebuild the process from Zygote and re-run Application.onCreate, which costs CPU and therefore battery. The system's own low-memory killer, driven by lmkd, already evicts processes when memory is actually short.

What to check. Use dumpsys meminfo and battery stats rather than a task list. The question is not "what is running" but "what is holding a wakelock or waking the CPU".

Myth 4: Free RAM is good RAM#

The claim. A phone with more free memory is healthier, and "RAM cleaner" apps help.

What is true. Low available memory with no reclaimable caches is a problem.

What is not. Free memory is wasted memory. Android deliberately fills RAM with cached app processes, file cache and preloaded classes, because all of those make the next action faster. "Cleaning" memory throws away exactly the data the system was planning to reuse. The metric that matters is whether the system can reclaim memory when needed, not how much is idle.

What to check. adb shell dumpsys meminfo reports total, free, used and lost RAM. A healthy device has a large cached category.

Myth 5: Deprecated APIs are removed in the next release#

The claim. If something is deprecated, it will not work soon, so migrate immediately or your app will break.

What is true. Deprecation is a signal that a better approach exists, and eventually some APIs do disappear.

What is not. Android almost never removes public API. AsyncTask was deprecated in Android 11 and still exists. Removal would break installed apps that cannot be updated, which is unacceptable for a platform with billions of devices. What does change is behaviour: a method can remain and start obeying a new restriction.⁴

What to check. The API diff for the level you are moving to. If a symbol is gone, it will be in the removals section; if only its behaviour changed, it will be in the behaviour-change docs and not the diff at all.

Myth 6: An APK is just a ZIP file#

The claim. Rename it to .zip and it is an ordinary archive; the format is trivial.

What is true. It is a ZIP archive, with a binary AndroidManifest.xml, classes.dex files, a resources.arsc table, and res/, lib/ and assets/ directories.

What is not. What makes it an APK is the contract around the archive: the APK Signing Block, the alignment the platform relies on, and the package manager's validation. A ZIP with the same files but no valid signature will not install. Signature schemes v2 and later sign the whole file, which is why a single changed byte invalidates them.⁵

What to check. apksigner verify --print-certs on a real APK. The output tells you which schemes are present, which is the part the ZIP listing does not show.

Myth 7: Rooting is the end of Android's security#

The claim. If an attacker gets root, the device is fully compromised and nothing else matters.

What is true. Root is a serious escalation, and an unlocked bootloader weakens verified boot and attestation.

What is not. SELinux applies to root as well. A root process still runs in a domain, and the policy decides what that domain may access. Getting root is not the same as escaping the policy; Android's security model assumes the kernel may be compromised and layers mandatory access control on top. This is why "even root cannot read another app's data by default" is closer to the truth than the myth suggests.

What to check. adb shell getenforce and the sepolicy sources. The domain a process runs in matters more than its UID.

Myth 8: Updates are slow because Google does not care#

The claim. Android updates take a year because Google is slow, or because carriers are lazy.

What is true. Updates were slow, and the reason was structural: an update had to pass through Google, the SoC vendor that supplied drivers and HALs, the phone maker, and often the carrier. Any one of them could delay it.

What is not. The delay was not primarily a motivation problem. It was a dependency problem, and the platform's response was to remove dependencies: Treble for the vendor boundary, Mainline for components, GKI for the kernel. The update situation improved because the architecture changed, not because someone tried harder.

What to check. The device's security patch level (ro.build.version.security_patch) and whether its vendor image is certified against a recent vendor interface.

Myth 9: Force-stopping an app is the same as uninstalling it#

The claim. Force stop cleans the app out, so it behaves like a fresh install.

What is true. Force stop terminates the app's processes and cancels its scheduled work.

What is not. The app's data, permissions and accounts remain. On many devices, a force-stopped app is also prevented from restarting until the user opens it again, which is different from being uninstalled and is a common source of "my background task stopped working" bug reports.

What to check. adb shell am force-stop <package> and then adb shell dumpsys package <package> — the package is still installed, with its data intact.

Why myths persist#

Three mechanisms keep these alive.

The visible proxy is misleading. Battery drain is visible; wakelocks are not. So people blame what they can see.

Old advice outlives its problem. Task killers were reasonable on a 2010 device with 256 MB of RAM and no cached-process model as aggressive as today's. The advice persisted after the mechanism changed.

A single true case generalises badly. One app with a runaway service really can drain a battery. The generalisation "background apps drain batteries" is false, but the example is real, which makes the generalisation persuasive.

How it evolved#

The background rows are the platform's response to the real version of myth 3: an app can waste power, so the platform steadily restricted what an app may do when the user is not looking. The myth and the mechanism grew up together.

Under the hood#

• ‹›OomAdjuster.java↗how process importance is computed, which is the mechanism behind the memory myths
• ‹›README.md↗Android's own init, and why the boot model is not a desktop distribution's
• ‹›PackageParser.java↗what the package manager actually validates in an APK

Curiosity corner#

• Android was originally built for cameras. The founders worked on an OS for digital cameras before pivoting to phones in 2004.
• The first Android phone had a trackball. The HTC Dream, sold as the T-Mobile G1, shipped with a slide-out keyboard.
• The compatibility programme is what makes "Android" meaningful. Without the CDD and CTS, the name would describe a source tree rather than a promise to users.

Try it#

$ adb shell dumpsys meminfo | head -40
adb shell getenforce
adb shell dumpsys package com.android.chrome | grep -E "versionName|targetSdk|firstInstallTime"

Illustrative output — values and packages differ per device.

Build it#

B03 — Tiny notes is a small app with a database and a background write, which makes the difference between "running" and "doing work" concrete.

Check yourself#

Sources#