In This Article
Follow BestForAndroid
A security fix for Android has a long commute. Google writes it, names it in the monthly bulletin, and hands it over.
Then it queues. Silicon vendors patch their own drivers. Samsung, Xiaomi and the rest fold everything into their own builds. Carriers certify the network-branded versions.
Only then does a phone in somebody’s pocket get the notification, and only if that model is still on the support list at all.
Every stop in that chain is a window. Exploiting a known vulnerability has now overtaken stolen credentials as the most common way attackers get their first foothold, at roughly 31 percent of the breaches in Verizon’s Data Breach Investigations Report. A published fix is also a published map of the bug.
Why updates carry the weight
Nothing running on top of the system can repair the system
Cybersecurity depends on more than antivirus software or a strong password. The operating system supplies the controls that keep apps apart, encrypt files at rest, gate permissions and verify who is signing in.
When a flaw turns up in that foundation, an update is usually the only real fix. No third-party app can patch a hole in the kernel. It is running on top of the thing that is broken.
For businesses, this connects directly to the broader idea of a security posture, which covers an organisation’s ability to prevent, detect and respond to threats across its technology, processes, people and suppliers.
Mobile devices are part of that picture, especially once employees use their phones to reach business accounts or company data. An outdated Android device is therefore more than a personal problem. It is another way into the systems and accounts that device can reach.
One word, four completely different delivery routes
“Install the update” is doing a lot of work as a phrase. It covers four separate pipelines with different owners, different cadences and very different odds of ever reaching a given handset.
| Where the fix lands | Typical example | How it reaches your phone |
|---|---|---|
| Kernel and device drivers | Memory corruption in a Wi-Fi, modem or graphics driver | Full over-the-air build from your manufacturer |
| Modular system components | Media parsing, network stack, permission handling | Google Play system update, often with no reboot |
| Google Play services | Play Protect detection rules and API-level fixes | Silent background update |
| Sandbox and permission defaults | Tighter limits on background location, clipboard and sensors | Annual Android release |
Only the first row depends on your manufacturer shipping a build. That distinction is the difference between a fix that lands this week and one that waits for a release cycle.
Security got layered
Modern Android security is built from several layers rather than one headline feature. Updates strengthen different points along the way: permissions, authentication, app isolation, encryption, vulnerability management. None of it is a single wall you either have or do not.
Mainline took device makers off the critical path for most fixes
The most useful change of recent years is also the hardest to see. Since Android 10, Google has carved parts of the operating system into modules it can update through the Play Store, an effort called Mainline.
Android 10 shipped with about a dozen of those modules. Recent releases carry roughly three times that number, covering media codecs, the network stack, permission handling and a long tail of core components that now patch the way an app patches.
The practical effect is that a large share of fixes no longer waits on a manufacturer build at all. The monthly Android Security Bulletin spells out which issues went out that way and which still need a full over-the-air release.
The safest vulnerability is the one nobody ever wrote
Another layer is quietly being rebuilt underneath. Google has been writing new Android code in memory-safe Rust instead of C and C++, and memory-safety flaws have fallen from more than 75 percent of Android’s vulnerabilities to under 20 percent for the first time.
Google puts the memory-safety defect density of its Rust code around a thousand times lower than the equivalent C and C++. There is a delivery story in the same numbers, which is the part engineering managers tend to notice: Rust changes roll back about four times less often and spend roughly a quarter less time in code review.
A bug that never gets written needs no patch, no bulletin and no reboot. That is the only intervention in this whole article with a zero-day delivery time.
The monthly volume is the tell, not the drama
Samsung offers a useful illustration of the scale involved. It recently confirmed a large set of Android security updates covering dozens of fixes, and coverage of that release cycle counted 38 new updates in a single month. Security updates of that kind close vulnerabilities that would otherwise sit exposed on affected devices until the next cycle.
That is routine, not an emergency. A recent monthly bulletin listed 107 flaws across supported Android versions, two of them already under limited, targeted exploitation before the fix shipped.
The delay is the risk
The biggest problem in mobile security is not the absence of a patch. It is the interval between a fix becoming available and a device actually receiving it.
The vulnerability is public by then. The fix and the exploit start racing each other, and the exploit does not have to pass carrier certification. Google’s own security researchers have made the point bluntly: a long enough patch gap makes an n-day about as useful to an attacker as a zero-day, and considerably cheaper.
The numbers in the panel above are not estimates. They come from device-centric research that walked more than half a million update records across roughly 900 models, six manufacturers and dozens of countries. Devices still nominally under support turned up at the far end of that distribution.
Two patch levels, and only one of them is the whole month
Android reports its patch state as a date, and that date comes in two flavours. One ends in -01 and one ends in -05.
The -01 level covers the core framework fixes everyone gets. The -05 level adds the vendor and driver fixes on top of it. A phone showing only the earlier of the two is missing part of that month’s work, which is exactly the sort of thing that never makes it onto a spec sheet.
Support windows have split the market into two different products
Android’s size means the experience varies by manufacturer, model, carrier and software version. At the top of the market the promise has stretched dramatically. At the bottom it has barely moved.
| Device tier | OS upgrades | Security patches |
|---|---|---|
| Pixel 8 and later, Galaxy S24 and later | 7 years | 7 years |
| Older flagships, Pixel 6 and 7 era | 5 years | 5 years |
| Mid-range Samsung A series and equivalents | 4 years | 5 years |
| Budget and unbranded handsets | 1 to 2 years, sometimes none | Often 2 years or unstated |
For organisations, that makes device inventories the unglamorous priority. Security teams need to know which phones are in use, which operating systems they run, and whether those systems are still getting patches at all. A phone nobody has counted is a phone nobody is patching.
The same principle applies to the business information sitting on those devices. People depend on a phone for authentication, email, documents and messaging, so losing access to old conversations creates real operational headaches, which is why practical tools such as SMS recovery stay relevant to Android users long after the novelty of a new handset wears off.
Read your own patch state
Thirty seconds in Settings, on any manufacturer build
- Open Settings, then Security and privacy, then System and updates. Menu names differ between manufacturers; searching Settings for “update” gets you there on any build.
- Read the Android security update date. That is your patch level. More than two or three months old means your device is behind.
- Read the Google Play system update date separately. That is the Mainline channel, and it moves independently of the main OS update, so the two dates are often nowhere near each other.
- Check your model’s support window on the manufacturer’s own page. Once a device drops off that list, no future patch is coming, whatever the phone still says on screen.
The same two values, read from code rather than a menu
Anything you can read in Settings you can also read on device. Build.VERSION.SECURITY_PATCH has been public since API level 23 and returns the framework patch level as a plain year-month-day string, which makes it trivial to compare against a threshold and log.
The vendor half lives in a separate system property, and it is the half that lags. Reading only the framework value will tell you a device is current when its driver stack is a quarter behind.
Play Integrity already treats patch level as a gate
This is the part most teams have not caught up with. From API level 33 onwards, the strongest Play Integrity device verdict is no longer just a statement about hardware-backed boot. It also requires security updates within the last twelve months on every partition, the vendor partition included.
A device that falls behind quietly drops out of that tier. If your app already calls the Integrity API, you are receiving a patch-state signal on every request whether you act on it or not.
The rule of thumb
Two to three months behind is normal for a mid-range phone on a carrier build. Six months behind means the update path has stalled somewhere and is unlikely to restart. No update at all in a year, on a model the maker no longer lists, means the phone should stop touching anything that matters: banking, work mail, two-factor codes.
Worth pairing with the handful of Android security settings that actually change your exposure, most of which take a minute each.
Beyond the handset
A compromised phone exposes far more than personal photos. Employees use Android devices to reach corporate email, cloud applications, collaboration platforms, customer records and internal systems.
The handset is a key ring, and it is usually the least supervised item in the building.
Mobile security sits inside access control, not beside it
Strong authentication limits what a stolen password is worth. It does not cancel out a flaw in an unpatched operating system.
An attacker running code on the device often does not need to defeat the login at all, because they arrive after it, holding the session the user already opened. Every control that assumes a trustworthy endpoint inherits the endpoint’s patch level.
The same issue turns up when staff send large volumes of business communication from a phone. Email security depends partly on how messages, accounts and devices are configured, so guidance on mass email security belongs alongside the rest of the organisation’s controls rather than in a separate document nobody opens.
Automating the fleet
Once an organisation passes a few dozen devices, manual checks stop working. Automation can surface outdated systems, flag unusual activity and rank vulnerabilities by what they would actually cost if exploited.
Machine learning reads the log volume nobody has time for
Pattern detection across large log sets is where the current generation of tooling genuinely earns its keep. It cuts the time it takes to notice something wrong. A wider discussion of AI in cybersecurity shows how those capabilities are being applied well beyond traditional endpoint protection.
For Android specifically, automation buys visibility: which OS versions are in the building, which patch levels, which apps, which permissions. That matters most for remote workers and second devices, because those are exactly the phones that quietly fall off the inventory.
Make the patch level a condition of access, not a line in a report
Android Enterprise already exposes the pieces. A device owner app can set a system update policy, and a management API policy can require a minimum security patch level and quarantine anything below it.
Most compliance engines will then act on that signal directly, unenrolling a device or cutting its access to corporate resources when it drifts out of range. The capability is rarely the blocker. Deciding the threshold is.
The useful version of this is unglamorous. Pull patch levels from every enrolled device on a schedule. Alert before a model crosses its end-of-support date, not after. Then send the lot somewhere a human will actually look, which for most teams means the SIEM they already run.
Where teams get this wrong
The inventory is built once, during a compliance push, and then never refreshed. Six months later it lists devices that have been replaced, misses the ones bought since, and reports a patch compliance figure that is technically accurate and completely useless.
What to watch
Android security will keep changing as vulnerabilities emerge and manufacturers rework their platforms. For individuals, the list worth tracking is short.
- Buy for the support window, not just the spec sheet. The update promise now separates devices further than the camera does.
- Install updates when they arrive rather than deferring them for a fortnight, since the gap is the whole risk.
- Treat an end-of-support device as end of life for anything sensitive, even if it still runs perfectly well.
- Keep Google Play Protect switched on, and check the Play system update date as well as the OS one.
Businesses carry a wider version of the same job. Mobile devices belong in asset inventories, access policies, vulnerability management programmes and incident response plans.
Somebody also needs to have decided in advance what happens when a handset reaches the end of its supported life. That decision is far easier to make on a quiet Tuesday than during an incident, which is also the argument for testing defences before you need them.
The bottom line
Regular Android updates cannot eliminate every threat. They close known weaknesses and harden the operating system’s defences, which is a smaller claim and a more reliable one.
As phones get wired further into business systems, keeping those systems current stops being maintenance and starts being a control. The practical version is smaller than the strategy. Know your patch level. Know your support window. Do not let either drift.
Worth remembering
The operating system is the control layer, and updates are how it gets fixed. No app patches the thing it runs on.
Mainline lets Google patch parts of Android through the Play Store, so check both update dates in Settings, not just the headline one.
The delay between a patch shipping and a device installing it is where the risk actually lives, and it is measured in weeks for most of the market.
Support windows are now a buying decision: seven years at the top of the market, two at the bottom.
For fleets, patch level is an input to access control. Play Integrity and Android Enterprise both already treat it that way.
