Android 17 Moved Cellular-Attack Detection Into the Platform

For years, if you wanted to know whether your phone was talking to a fake cell tower, you needed a rooted device and a specialist app like SnoopSnitch or Darshak, or a software-defined radio and the patience to tune it. Detecting IMSI catchers, the rogue base stations also called stingrays or cell-site simulators, lived at the edge of the platform, in tooling that reached into the baseband’s diagnostic interface from the outside. It was never something Android itself knew how to talk about.

In 17 that changed, and it is not in the consumer release notes. It showed up in the radio HAL freeze diff: the modem interface now carries an entire vocabulary for reporting cellular attacks.

What is new in the radio HAL#

The whole radio HAL family moved to v5, and the relevant additions are in the network and messaging interfaces. radio.network gained a NetworkSecurityEvent type and an onNetworkSecurityEvents callback. radio.messaging gained a newSecureSms path that carries a security event alongside the message. In other words, the modem now has a defined way to tell the rest of the system “something about this network looks wrong,” and the framework has a defined way to receive it.

The substance is the taxonomy underneath: thirteen alert categories and twenty-eight reason codes, and they read like a field guide to how cellular attacks actually work.

(The full set adds the rest of the downgrade family, DOWNGRADE, DOWNGRADE_3G, DOWNGRADE_4G, and AUTH_PASSED.) An empty or invalid neighbor list, a silent SMS used to ping your location, a cell advertising parameters that match a known IMSI catcher: these are exactly the tells that stingray-detection researchers have looked for by hand for years.

And each event carries the cell it came from, the AIDL documents the fields itself: cellId (“the Cell Identity”), physicalCellId (“the Physical Cell ID”), arfcn (the frequency channel), plmn (the network operator), rat (the radio technology), plus an isEmergency flag that the source documents as whether the device is in an emergency session, for example making an emergency call. So it is not just “something is wrong,” it is “this specific cell, on this frequency, in this network, did this specific thing, while you were dialing 911.”

It reports, and it can also fight back#

This is not purely a reporting interface, and that is the source’s own framing: the alertStatus field is documented as “indicating whether it was only detected or if a mitigation action was taken.” Those mitigation states are MITIGATED_CELL_BARRED and MITIGATED_CELL_DEPRIORITIZED, so the modem can bar or deprioritize a cell it does not trust, not just describe it after the fact. There is also a getSupportedNetworkAlertCategories capability query, which I will come back to.

And there is a lever one layer up that ties into the same theme: Android 17 also gives carriers a new way to configure the 2G toggle so that 2G defaults to off. That is the policy partner to the DOWNGRADE_2G detection. So the same threat is addressed in three places:

2G is the most attackable generation, the one downgrade attacks try to force you onto, and now there is a supported way to refuse it by default in areas where the old infrastructure is no longer maintained. Detection in the modem, mitigation in the modem, and policy at the carrier layer.

Where this came from#

This did not appear from nowhere, and the lineage is worth knowing because it tells you where the direction is heading. Android 15 and 16 added cellular cipher transparency: a way for the platform to be told what cipher a network was using, so it could notice, for instance, a null cipher or a downgrade in the encryption itself. That was the first step, and it was narrow, it answered “what is this network doing to my traffic.” Version 5 takes that same idea and widens it from reporting the cipher to reporting the network. It turns a transparency feature into a rogue-network intrusion-detection vocabulary.

It is also worth saying plainly that Android did not invent this threat model. The categories and reason codes map almost one-for-one onto what the IMSI-catcher research community has been describing and detecting for over a decade. What is new is not the knowledge. What is new is that the knowledge is now a first-class part of the platform’s radio interface, where any modem vendor can implement it and the framework can consume it, instead of living in a rooted-phone app reading the diagnostic port.

What actually ships, and what does not#

The interface is not the same thing as the detection behind it, and conflating the two is the easy mistake.

The radio HAL is a contract. It defines a place for the modem to report these events and a place for the framework to receive and act on them. The VTS test that ships with it exercises the indication path, it verifies that the reporting plumbing works. It does not, and cannot, certify that any given modem actually detects an IMSI catcher well, or at all. That is why getSupportedNetworkAlertCategories exists: a device declares which of the thirteen categories it can report, which is a quiet admission that none of them are guaranteed. Detection quality lives in the baseband firmware, and the baseband firmware is the vendor’s.

There is one more tell in the source worth noting: the NetworkSecurityEvent parcelable is marked @hide. As it ships in 17, this is an internal interface, not public API. So today it is a signal the platform and privileged tooling can act on, not something an app you install can read. Whether it ever surfaces to the person holding the phone is a product decision that is open by construction.

The precise version is narrower. Android 17 did not make your phone a stingray detector. It made cellular-attack detection a defined, vendor-implementable, framework-consumable part of the platform. Whether your specific device detects a fake tower depends on whether its modem vendor implemented v5, and how well. That is a narrower statement than the headline version, it is the one that is actually true, and it is still a significant change.

Why it matters#

The significance is the move itself. A capability that required a rooted phone and specialist software is now a standard interface that every Android modem can speak. For most people that will be invisible, the way most security plumbing is. For the people who actually live with this threat, journalists, activists, anyone who has reason to think they are targeted, the difference between “you need a rooted device and SnoopSnitch” and “the platform has a defined, supported place for this” is not small. It is the difference between a research project and a feature.

It is also telling what got said and what did not. Google’s own security writeup for 2026 mentions the new 2G default, the visible, easy-to-explain piece. It does not mention the NetworkSecurityEvent taxonomy at all. (I checked: the cellular section is one sentence, and it is the 2G one.) The interesting half of the cellular-security story this release is the half that only shows up if you read the HAL.

So I will leave it where the real questions are. Which modem vendors will actually implement v5, and how completely? Will any of this surface to users, as a warning that you may be on a fake tower, or will it stay an internal signal that feeds enterprise and carrier tooling and never reaches the person holding the phone? The contract is now in the platform. What gets built on top of it is the part worth watching, and I would be curious whether anyone reading this is already planning to implement against it.

Found in the Android 16 to 17 radio HAL freeze diff and confirmed against AOSP. Sources: NetworkSecurityEvent.aidl (radio HAL v5, 17 tag) · Google’s 2026 Android security and privacy post (mentions only the 2G default) · the IMSI-catcher detection lineage (AIMSICD).