Hundreds of millions of Android phones still in daily use can no longer receive security patches, leaving their owners exposed to known software flaws that device makers and Google have stopped fixing. A large-scale academic study of Android patched vulnerabilities found that once a version falls outside the support window defined by Android Security Bulletins, it becomes permanently exposed to exploits already documented in public databases. The research, which analyzed thousands of vulnerabilities using AOSP source code and Git commit histories, concluded that older versions are “likely affected but no longer patched,” a finding with direct consequences for anyone carrying a phone that has aged out of the update cycle.
Why outdated Android versions create growing security gaps
The core problem is structural. Google publishes monthly Android Security Bulletins that list newly discovered vulnerabilities and the patches that address them. But those bulletins only cover versions that Google and its hardware partners actively support. When a version drops off the list, every vulnerability discovered after that cutoff goes unpatched on devices still running the older software. The academic preprint available on the arXiv platform examined this pattern across thousands of patched Android vulnerabilities and found that patch attention shifts quickly toward newer releases while older ones are abandoned.
That abandonment matters because phones do not stop working when they stop receiving updates. People continue using them for banking, messaging, and storing personal data. Each month that passes after support ends adds another layer of unpatched flaws, and attackers can study the publicly disclosed fixes for supported versions to reverse-engineer exploits targeting unsupported ones. The gap between a vulnerability being publicly documented and a device being permanently unable to receive its fix is where risk concentrates.
A testable hypothesis follows from this pattern: devices outside Android Security Bulletin coverage should experience measurably higher rates of exploit attempts than supported devices. Carrier telemetry and app-store install data, correlated with version-support timelines from the study, could confirm whether unsupported phones face disproportionate targeting. No public dataset currently answers that question, but the research establishes the preconditions by showing how quickly versions lose patch coverage.
What the arXiv vulnerability study actually found
The study drew on multiple data sources to map the lifecycle of Android security patches. Researchers cross-referenced Android Security Bulletins with AOSP code repositories and Git commit logs to trace when fixes were written, when they were published, and which versions received them. The analysis covered a wide range of vulnerability types addressed in the bulletins, from kernel-level flaws to application-framework bugs.
One of the study’s central findings was the speed at which older versions lose coverage. Once Google designates a version as end-of-life, patches for newly discovered flaws are written only for supported releases. The older version remains vulnerable, and because the bulletin publicly describes the flaw, attackers gain a roadmap to exploit it. The researchers noted that affected devices are “likely affected but no longer patched,” a phrase that captures the gap between known risk and absent remedy. The paper is hosted on arXiv’s open-access service, which is operated by Cornell University and widely indexed across academic databases.
The study did not rely on estimates of how many phones are affected. Instead, it focused on the mechanics of the patching process itself, documenting delays between vulnerability disclosure and patch availability even for supported versions. Those delays compound the problem for unsupported devices, which never receive the fix at all. The research also examined how patch metadata in the bulletins sometimes obscured which versions were tested, making it harder for users and security analysts to assess their own exposure.
Because the work appears as a preprint, it reflects a snapshot of the Android ecosystem at the time of analysis rather than a definitive, final account. The authors rely on publicly available code and bulletin information, which means their conclusions are constrained by what Google and device makers choose to document. Nonetheless, by systematically mapping patches to versions, the study offers one of the clearest pictures yet of how Android’s support lifecycle leaves older devices behind.
Gaps in the evidence and what to watch next
The study’s scope creates several open questions. It analyzed the patch record but did not measure real-world exploitation rates on unsupported devices. That means the connection between missing patches and actual attacks remains inferred rather than directly observed. Google does not publish granular data on malware infection rates broken down by Android version and patch level, so independent verification of the risk differential is difficult.
Device manufacturers add another layer of uncertainty. Samsung, Xiaomi, Motorola, and other makers each set their own support timelines, which often end before Google drops a version from its bulletins. A phone might stop receiving updates from its manufacturer years before the underlying Android version itself loses Google’s attention. The study did not track manufacturer-specific support windows, so the actual number of devices left without patches could be larger than the version-level analysis suggests.
Google has taken steps to address fragmentation in recent years, including Project Mainline, which allows some security components to be updated through the Play Store independently of full system updates. But Project Mainline only works on newer Android versions, and its coverage does not extend to the kernel or hardware-level drivers where many of the most severe vulnerabilities reside. Whether these efforts meaningfully reduce the exposure of the broader device population is an open question that the current research does not answer.
Another unknown is user behavior. Even when updates are available, many owners delay installing them, and some disable automatic updates entirely. The study focuses on the structural limits of patch distribution, not on how quickly users apply patches once they are released. That leaves a separate, behavioral gap in protection that could compound the risks identified in unsupported versions.
What Android users can do now
For anyone using an Android phone that no longer receives monthly or quarterly security updates, the practical first step is to check the device’s current patch level under Settings, then compare it against the latest Android Security Bulletin date listed in Google’s documentation. If the gap is more than a few months, the device is accumulating unpatched vulnerabilities with each passing bulletin cycle. Replacing the phone is the most direct way to restore a regular flow of fixes, especially for critical kernel and driver flaws that third-party tools cannot address.
Where replacement is not immediately possible, users can still take steps to reduce exposure. Limiting app installations to reputable stores, avoiding sideloaded APKs, and revoking unnecessary permissions can all shrink the attack surface. Keeping sensitive activities such as mobile banking or password management on a better-supported device, when available, can also reduce the consequences if an older phone is compromised.
For researchers and policymakers, the study underscores the need for more transparent reporting on device support lifecycles. Clearer commitments from manufacturers about how long each model will receive security patches would help consumers make informed purchasing decisions. Better public data on exploitation trends by version would also allow independent experts to validate whether unsupported devices are, in practice, bearing the brunt of attacks.
Finally, the existence of this work on an open repository highlights the role of public infrastructure in security research. The preprint is freely accessible thanks in part to community-backed initiatives that keep hosting and curation available to academics and the public. Readers who find value in this kind of analysis can support that ecosystem directly through arXiv’s donation page, helping ensure that future studies of software security lifecycles remain openly available rather than locked behind paywalls.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
