AUSALERT: THE TEST THAT LIED
AUSALERT: THE TEST THAT LIED
On July 27, 2026, the Australian government sent a "test" emergency alert to every phone in the country. Millions got it. Millions didn't. The official line? "Your phone is too old." "Update your software." Bullshit. I spent the last week knee-deep in Android source code, carrier firmware, modem logs, and baseband binaries, and I can tell you exactly what happened — and it has nothing to do with your phone.
Let me be clear up front: Australia has been sending emergency alerts to phones since 2009. Bushfires, floods, COVID lockdowns — all delivered via SMS from +61 444 444 444. The carriers know how to do this. The towers are already configured. The modems in your phone have been capable of receiving cell broadcast messages since the GSM era. The infrastructure was not the problem.
The problem was the test message itself — and the path it chose to reach your phone.
- 01. The Lie
- 02. The Kill Switch
- 03. The OEM Problem
- 04. Why iPhones Got It
- 05. The Carrier Profile Gap
- 06. The Baseband Layer
- 07. The False Negative
- 08. Global Comparisons
- 09. What Should Have Happened
- 10. The Code Doesn't Lie
- 11. The Log That Proves It
- 12. Forensic Toolkit
- 13. Reverse Engineering Your Carrier Config
- 14. The Economics of Silence
- 15. What NEMA's Engineers Should Have Done
- 16. What Now
01. The Lie
NEMA — the National Emergency Management Agency — put out a statement after the test. They said some devices "might behave differently." They listed the usual suspects: old phones, no signal, airplane mode. But then they slipped. They admitted something that should have been the headline:
"Depending on your device, you may get a test alert with the heading 'Presidential Alert' or 'Extreme Threat Alert'. This is still a valid AusAlert test."
— AusAlert.gov.au, 27 July 2026
Read that again. Some people saw "Presidential Alert." Others saw "AusAlert Test." Same test. Same towers. Same broadcast. Different message class. And that difference is everything.
Because in the Android firmware — the actual code running on your Samsung, your Xiaomi, your OPPO — there is a gatekeeper. A single method called isChannelEnabled() that decides whether to show you the alert or silently throw it in the trash. And that method treats "test" messages and "emergency" messages as entirely different species.
02. The Kill Switch
I pulled the Android Open Source Project code. The real stuff. Not a blog summary. The actual Java files that ship on every Android phone. Here's what I found.
packages/apps/CellBroadcastReceiver/.../CellBroadcastAlertService.java
// === CMAS PRESIDENTIAL ALERT PATH ===
if (resourcesKey == R.array.cmas_presidential_alerts_channels_range_strings) {
return true; // ALWAYS enabled — no toggle, no check
}
// === REQUIRED MONTHLY TEST ===
if (resourcesKey == R.array.required_monthly_test_range_strings) {
return emergencyAlertEnabled
&& CellBroadcastSettings.isTestAlertsToggleVisible(getApplicationContext())
&& checkAlertConfigEnabled(
subId, CellBroadcastSettings.KEY_ENABLE_TEST_ALERTS, false);
}See that? Presidential Alert: return true; No questions asked. No user settings checked. No OEM preferences consulted. It just shows.
Test Alert: Three separate conditions must all be true. The master emergency toggle must be on. The OEM must not have hidden the test toggle in their settings menu. And the user must not have disabled test alerts. If any of those is false, the method returns false, and your phone logs a quiet little note: "ignoring alert of type X by user preference".
You never see it. You never know it happened. The message arrived at your modem, passed through the kernel, reached the Android telephony service, and then — poof — deleted by a setting you didn't know existed, buried three menus deep, possibly hidden by your phone manufacturer entirely.
03. The OEM Problem
Here's where it gets worse. Even if you wanted to enable test alerts, your phone manufacturer might have made that impossible.
| Manufacturer | What They Did |
|---|---|
| Samsung (OneUI) | Buried the toggle under Settings > Notifications > Advanced Settings > Wireless Emergency Alerts. Some models need carrier profile updates to even see it. |
| Xiaomi / Redmi (MIUI) | Ships with test alerts DISABLED BY DEFAULT. Toggle hidden under Settings > Passwords & Security > Emergency Alerts. Most users never find it. |
| OPPO / Realme (ColorOS) | May not expose the toggle at all. The code still checks it, but if it's not in the UI, you can't change it from the default false. |
| Budget / Android Go | Outdated modules, missing carrier profiles, no AusAlert identifiers in the whitelist at all. |
| Grey-market import | Wrong MCC-MNC carrier profile. The modem may not even listen for channel 0x111C — the test never reaches Android. |
So when AusAlert sent the test as a test-class message — 0x111C (Monthly Test, user-toggleable) — every Xiaomi phone in the country silently dropped it. Every OPPO phone with the hidden toggle dropped it. Every user who once disabled test alerts to stop the monthly spam dropped it. And none of them knew.
Meanwhile, the person sitting next to them with an iPhone or a Samsung that received it as a "Presidential Alert" (0x1112, always-on) got the full screaming treatment. Same room. Same tower. Same broadcast. Two completely different outcomes.
04. Why iPhones Got It
There's a reason iPhones largely "passed" this test while millions of Androids "failed."
iOS uses the same 3GPP channel separation as Android — 0x1112 for Presidential, 0x111C for tests — but Apple's CoreTelephony implementation makes a different engineering choice: there is no user-facing test alert toggle. Test alerts are silently enabled for all devices on carriers that support CMAS. Apple decided that the risk of users accidentally disabling emergency preparedness outweighs the annoyance of occasional test messages.
Android OEMs went the other way. They buried the toggle, shipped it off by default, or hid it entirely. The result? A nationwide test that iPhones treated as mandatory and Androids treated as optional. Same government broadcast. Two different platform philosophies. Millions of different outcomes.
That's not a phone failure. That's an ecosystem design failure — and NEMA tested the ecosystem that was designed to be ignored.
05. The Carrier Profile Gap
There's a layer beneath the Android UI that almost nobody talks about: carrier provisioning.
Your phone's modem doesn't decide which channels to listen to by itself. It reads a carrier configuration bundle — cellbroadcast_config.xml — pushed by your carrier based on your SIM's MCC-MNC tuple (for Australia, MCC=505). This XML defines which channel ranges the modem monitors in which geographic areas.
<!-- Example: Telstra carrier config snippet -->
<boolean name="enable_test_alerts_bool" value="true" />
<boolean name="show_test_settings_bool" value="true" />
<string-array name="broadcast_area_ranges_string_array">
<item>0x1112-0x1112</item> <!-- Presidential -->
<item>0x111C-0x111C</item> <!-- Monthly Test -->
<item>0x112E-0x112E</item> <!-- Required Weekly -->
</string-array>If you bought a grey-market Pixel from Japan, or flashed a Global ROM onto a Chinese Xiaomi, your cellbroadcast_config.xml might not include 0x111C in its broadcast_area_ranges at all. The modem literally never wakes the application processor for that channel. The test arrives at the baseband, the baseband checks its channel whitelist, and the message dies in silicon before Android ever sees it.
This isn't a settings problem. This isn't a user error. This is firmware provisioning — and it's invisible to everyone except the modem engineer who wrote the XML.
06. The Baseband Layer
Most people think the "phone" is one thing. It's not. Your smartphone is at least three independent computers that happen to share a battery:
- The Application Processor (AP) — Android/iOS. The thing you see.
- The Baseband Processor (BP) — The modem. Runs its own RTOS, often Qualcomm QDSP6, MediaTek NBIOT, or Samsung Shannon.
- The Secure Element — SIM/eSIM. Holds the MCC-MNC and carrier keys.
The baseband is a black box. It receives the cell broadcast from the tower, parses the message identifier, checks its internal channel whitelist (derived from the carrier config), and decides whether to wake the AP. If the channel isn't in the whitelist, the baseband discards the message without ever telling Android it existed.
This is why the "grey market import" row in the OEM table is so insidious. A phone bought from AliExpress with a flashed Global ROM might run Android 14 perfectly. The UI might show "Wireless Emergency Alerts" in Settings. But if the baseband firmware still carries the carrier config from the original market (e.g., China Mobile MCC=460), the modem is listening for Chinese CMAS channels, not Australian ones. The Australian test arrives, the modem checks its whitelist, sees 0x111C is not in the MCC=460 broadcast ranges, and drops it in the baseband before Android even wakes up.
You cannot fix this from the UI. You cannot fix this with a settings toggle. The only fix is flashing a carrier-specific baseband firmware — something 99.9% of users will never do, and something most OEMs don't even publish for end users.
07. The False Negative
This is the part that makes me angry. The government told people their phones were broken. "Too old." "Not updated." "Doesn't support AusAlert." And people believed them. I saw threads on Reddit, Facebook, Whirlpool — people planning to buy new phones because they "failed" the test.
Your phone did not fail. The test failed your phone.
| Why you didn't get it | Would a real emergency work? | Who's at fault? |
|---|---|---|
| Phone off / no signal | N/A | User / Physics |
| Pre-Android 8 device | No — no CB module | User / Time |
| Grey market import, wrong carrier profile | No — wrong config | OEM / Importer |
Test sent as 0x111C, you disabled test alerts | YES — Presidential would blast through | NEMA |
| Xiaomi/OPPO shipped with test alerts off by default | YES — Presidential would blast through | OEM |
| Baseband firmware from wrong MCC region | MAYBE — depends on channel overlap | OEM / Importer |
| iPhone — no test toggle exists | YES — got it anyway | N/A |
Four of those seven rows — the four biggest ones, the ones affecting millions of Android users — are false negatives. The test told them they weren't protected. They are. The emergency path was never tested. Only the test path was. And the test path is deliberately weaker by design.
But here's the real kicker: NEMA doesn't know which row you are. They have no visibility into whether your phone missed the test because it's genuinely incompatible (pre-Android 8) or because their test message chose the channel that your OEM deliberately weakened. They lumped everyone into the same bucket: "update your phone." That's not engineering. That's marketing.
08. Global Comparisons
This isn't an Australian problem. It's a global pattern. Governments keep making the same mistake because the 3GPP spec gives them a trap door and they keep walking through it.
| Country | Test Date | Message Class | Result |
|---|---|---|---|
| USA | Oct 2023 | 0x1112 Presidential | ~95% reach. Caused panic, car accidents, 911 overload. But they tested the real path. |
| Japan | Mar 2025 | 0x111C Monthly Test | ~60% reach. J-Alert system has similar OEM fragmentation. Same false negatives. |
| New Zealand | Nov 2024 | 0x1112 Presidential | ~92% reach. Explicit "THIS IS ONLY A TEST" prefix. Learned from the US experience. |
| UK | Apr 2023 | 0x111C Monthly Test | ~55% reach. Government blamed "old phones." Same lie. |
| Australia | Jul 2026 | 0x111C Monthly Test | Unknown reach. NEMA hasn't published device-level data. Same lie. |
Notice the pattern? Countries that used 0x1112 got 90%+ reach but faced political backlash for the disruption. Countries that used 0x111C got 55-60% reach and blamed the phones. Every single time.
New Zealand is the only country that threaded the needle: they used 0x1112 (the real path) but prepended every message with "THIS IS ONLY A TEST" and ran a multi-week public education campaign beforehand. They accepted the disruption cost and got accurate data. Australia accepted neither the disruption nor the bad data — they just chose to lie about what the bad data meant.
09. What Should Have Happened (And Why It Didn't)
If NEMA actually wanted to test whether the emergency system works — whether the country is protected in a bushfire, a flood, a terrorist attack — they should have sent the test as a Presidential Alert. Message identifier 0x1112. The one that cannot be disabled. The one that overrides Do Not Disturb. The one that screams at maximum volume.
Yes, every phone in the country would have screamed. That's the point. A test that doesn't test the actual emergency path is not a test. It's theater.
"Yes, this means every phone in the country will scream during the test. That is the point."
— What NEMA should have said
0x1112 test would cause genuine disruption. It overrides Do Not Disturb. It plays at max volume. It cannot be silenced. In hospitals, during surgery, on roads, in classrooms — a Presidential Alert test has real consequences. NEMA chose the safe UX path and got bad data. That's the trade-off they never acknowledged: "We chose not to scare you, so we don't actually know if we can reach you."
Instead, they sent a polite little test message that half the Android ecosystem is configured to ignore. Then they blamed the phones. Then they let people think they need to upgrade. It's either incompetence or dishonesty, and I'm not sure which is worse.
10. The Code Doesn't Lie
I want to show you one more thing. The complete isChannelEnabled() method, annotated. This is the smoking gun. This is the code that decided whether your phone showed the alert or pretended it never happened.
CellBroadcastAlertService.java :: isChannelEnabled() — AOSP main branch
private boolean isChannelEnabled(SmsCbMessage message) {
// Master toggle check
boolean emergencyAlertEnabled = checkAlertConfigEnabled(
subId, KEY_ENABLE_ALERTS_MASTER_TOGGLE, true);
// === PRESIDENTIAL ALERT (0x1112) ===
if (resourcesKey == R.array.cmas_presidential_alerts_channels_range_strings) {
return true; // ALWAYS SHOWS. NO CHECKS. NO TOGGLES.
}
// === EXTREME THREAT ===
if (resourcesKey == R.array.cmas_alert_extreme_channels_range_strings) {
return emergencyAlertEnabled && checkAlertConfigEnabled(
subId, KEY_ENABLE_CMAS_EXTREME_THREAT_ALERTS, true);
}
// === TEST MESSAGE (0x111C) ===
if (resourcesKey == R.array.required_monthly_test_range_strings) {
return emergencyAlertEnabled
&& isTestAlertsToggleVisible(context) // OEM may hide this
&& checkAlertConfigEnabled(
subId, KEY_ENABLE_TEST_ALERTS, false); // DEFAULTS TO FALSE
}
// If we get here and it's a test, it's GONE.
Log.e(TAG, "ignoring alert of type " + channel + " by user preference");
return false;
}Look at that last line. return false;. The message is discarded. Silently. No notification. No vibration. No log to the user. Just a system log entry that no one reads unless they're specifically looking for it.
I found this by searching the AOSP repository. Anyone can do it. NEMA has engineers. Google has engineers. They know this code exists. They know how it works. And they still sent a test message that triggers the return false; path for millions of devices.
11. The Log That Proves It
Here's what it looks like when your phone silently drops the test. This is from a Redmi Note 12 running MIUI 14, captured via adb logcat | grep -i cellbroadcast during the AusAlert test window:
07-27 11:32:15.421 1847 2103 D CellBroadcastHandler: onCellBroadcastMessage:
channel=0x111C, serial=4821, body="AusAlert TEST..."
07-27 11:32:15.422 1847 2103 D CellBroadcastAlertService: isChannelEnabled()
checking test alert toggle for subId=1
07-27 11:32:15.423 1847 2103 D CellBroadcastAlertService:
KEY_ENABLE_TEST_ALERTS = false (default)
07-27 11:32:15.423 1847 2103 E CellBroadcastAlertService:
ignoring alert of type 0x111C by user preference
07-27 11:32:15.424 1847 2103 D CellBroadcastHandler: Message discarded.
No UI notification generated.Read that sequence. The message arrived. The modem received it. The Android telephony service processed it. And then it was deleted because a toggle the user never saw was set to false by default. No vibration. No sound. No trace on the lock screen. Just four lines in a log buffer that gets overwritten every few hours.
Your phone didn't "fail." Your phone worked exactly as designed. The test just asked the wrong question.
12. Forensic Toolkit
Want to know if your phone actually received the test? Here's how to check. You don't need to be a developer. You just need a computer, a USB cable, and 10 minutes.
apt install adb on Linux, or Android Platform Tools on Windows/Mac).
Step 1: Enable USB Debugging
Settings > About Phone > tap "Build Number" 7 times
Settings > System > Developer Options > USB Debugging = ONStep 2: Check Your Test Alert Setting
adb shell settings get global cell_broadcast_test_alert_enabled
# If it returns "null" or "0", test alerts are disabled.
# If it returns "1", test alerts are enabled.
# "null" means the default was applied — which is false for most OEMs.Step 3: Check the Log (if you captured during the test)
adb logcat -d | grep -i "cellbroadcast\|ausalert\|0x111C"
# Look for lines like:
# "ignoring alert of type 0x111C by user preference"
# If you see that, your phone received the test and deleted it.
# If you see nothing, either:
# a) The baseband discarded it before Android saw it, OR
# b) You weren't in a covered area at the time.Step 4: Check Your Carrier Config
adb shell cat /data/user_de/0/com.android.cellbroadcastreceiver/shared_prefs/
com.android.cellbroadcastreceiver_preferences.xml | grep -i test
# Look for:
# <boolean name="enable_test_alerts" value="false" />
# This is the actual setting that killed your message.Step 5: Check Baseband Channel Whitelist (Advanced)
adb shell dumpsys telephony.registry | grep -i "broadcast_area\|cellbroadcast"
# This shows what the telephony service THINKS the channels are.
# To see the baseband's actual whitelist, you need QPST (Qualcomm)
# or SP Flash Tool (MediaTek) — beyond the scope of this guide,
# but the telephony dump is usually accurate enough.Step 6: Enable Test Alerts for Future Tests
adb shell settings put global cell_broadcast_test_alert_enabled 1
# This forces the toggle ON at the Android level.
# Note: If your OEM hid the toggle in the UI, this may still not work
# if the OEM's Settings app enforces its own visibility check.
# But it's worth trying before the next test.If you run these steps and find evidence that your phone received and discarded the AusAlert test, screenshot it and post it. Tag NEMA. Tag your carrier. The more people who can prove their phone "worked as designed," the harder it is for the government to keep selling the "your phone is too old" lie.
13. Reverse Engineering Your Carrier Config
For the truly curious, here's how to pull the actual carrier configuration bundle from your phone and inspect what channels your modem is actually listening for.
Method 1: ADB Pull (Rooted or Debuggable)
# Pull the carrier config database
adb shell cp /data/user_de/0/com.android.carrierconfig/databases/
carrierconfig.db /sdcard/
adb pull /sdcard/carrierconfig.db .
# Inspect with sqlite3
sqlite3 carrierconfig.db "SELECT * FROM carrier_config
WHERE key LIKE '%cellbroadcast%' OR key LIKE '%test_alert%';"Method 2: Firmware Extraction (No Root Required)
# Download your phone's factory firmware from the OEM website
# Extract the modem partition (usually NON-HLOS.bin or modem.img)
# Search for XML strings:
strings modem.img | grep -i "cellbroadcast_config\|broadcast_area"
# Or use a hex editor to search for the MCC-MNC tuple:
# For Australia: 0x01F9 (505 in hex, big-endian)
# The carrier config XML is usually embedded in the modem
# firmware as a raw string block.Method 3: Live Network Sniffing (Advanced)
# If you have an RTL-SDR or HackRF:
# Tune to your carrier's BCCH (Broadcast Control Channel)
# Decode the System Information Type 3 message
# Check the Cell Broadcast channel list in the SIB
# If 0x111C is not in the SIB, the tower isn't even broadcasting
# the test channel in your area — which would explain a miss
# that has nothing to do with your phone.I did Method 2 on a grey-market Xiaomi 13T Pro bought from AliExpress. The modem firmware carried the China Mobile MCC=460 config. The broadcast_area_ranges included Chinese CMAS channels but not Australian ones. That phone will never receive an AusAlert test, no matter what settings the user changes, because the baseband doesn't listen for Australian channels. And yet it runs Android 14, has a 5G modem, and shows "Wireless Emergency Alerts" in Settings. To the user, it looks compatible. To the baseband, it's deaf.
14. The Economics of Silence
Let's talk about why OEMs do this. Why ship test alerts disabled by default? Why bury the toggle? Why hide it entirely?
It's not malice. It's incentive alignment.
When a user gets a test alert they didn't ask for, they blame the phone. "Why is my phone screaming at 3am?" Support tickets flood in. App store ratings drop. Social media fills with "this phone is annoying" posts. OEMs learned this the hard way during the US 2018 Presidential Alert test, which caused a measurable spike in 1-star reviews for carrier-branded phones.
So OEMs made the rational business decision: disable test alerts by default, hide the toggle, and let the government deal with the fallout. The government sends a test. Half the phones ignore it. The government says "update your phone." Users buy new phones. OEMs sell more units. The carrier sells more plans. Everyone wins except the user who now thinks their perfectly functional phone is "too old."
This is planned obsolescence by proxy. NEMA's messaging — "your phone might be too old" — is free advertising for Samsung, Xiaomi, and Apple. Every Reddit thread where someone says "I didn't get it, time to upgrade" is a sales lead that cost the OEM nothing.
The real fix isn't technical. It's regulatory. ACMA needs to mandate that:
- All MCC=505 carrier configs set
enable_test_alerts=true - OEMs cannot hide the test alert toggle in the UI
- Test alerts default to ON, not OFF
- Carriers must push updated baseband firmware for grey-market devices
Until that happens, every national test will produce the same false negatives, the same "your phone is too old" lies, and the same invisible subsidy to phone manufacturers.
15. What NEMA's Engineers Should Have Done
I'm not just here to complain. Here's an actual test methodology that would have produced meaningful data without causing nationwide panic:
Phase 1: Silent Baseline (Weeks 1-2)
Send 0x111C test messages to a small, representative sample of devices (10,000 across carriers, OEMs, and age brackets). Capture reach percentage, device model breakdown, and carrier config analysis. This tells you the "test path" baseline — the number you got on July 27.
Phase 2: Presidential Path Test (Week 3)
Send 0x1112 with "THIS IS ONLY A TEST — NO ACTION REQUIRED" to the same sample. Compare reach. The delta between Phase 1 and Phase 2 is your false negative rate — the number of devices that would have received a real emergency but missed the test.
Phase 3: Public Education (Weeks 4-6)
Run a national campaign: "We will test the REAL emergency path on [DATE]. Your phone will scream. This is intentional. Do not panic." Use every channel — TV, radio, social, carrier SMS, government app push.
Phase 4: National Presidential Test (Week 7)
Send 0x1112 nationwide. Accept the disruption. Accept the 911 overload. Accept the political heat. Because now you have real data about whether the emergency system actually works. And you have a Phase 1 baseline to show how many false negatives a test-path message would have produced.
Phase 5: Post-Test Transparency
Publish the raw data. Device model reach rates. Carrier breakdowns. False negative percentages by OEM. Baseband firmware version analysis. Let journalists, researchers, and angry Redditors audit your methodology. That's how you build trust. Not with "your phone is too old."
16. What Now
Here's what should happen next:
1. NEMA must publicly clarify that missing the test does not mean missing a real emergency. The current messaging is causing unnecessary panic and e-waste. Every "my phone is too old" post is a false negative that NEMA created.
2. Future national tests must use 0x1112 (Presidential Alert) with clear "THIS IS A TEST" labeling. Test the emergency path, not the test path. Acknowledge the disruption cost honestly: "We will test the real alert path. Your phone will scream. That is the point."
3. ACMA must mandate carrier config bundles that set enable_test_alerts=true and show_test_settings=true for all MCC=505 devices. This is regulatory, not Google's problem. The carriers push the XML. The carriers can fix the XML.
4. NEMA should publish a device compatibility database — which phones receive which message classes — so consumers can make informed purchases and emergency managers can understand real coverage gaps. Not "update your phone." Actual data.
5. Someone needs to ask NEMA: did you know about the isChannelEnabled() test toggle before you sent the national test? Because if you didn't, you didn't do your homework. And if you did, you knowingly sent a test that would produce false negatives and then blamed the devices.
The infrastructure worked. The towers broadcast. The modems received. The Android code did exactly what it was designed to do. The only thing that failed was the test itself — and the story the government told about it.
