[Feature Request]: Detect 5G SA vs NSA carrier capability & guard against "5G Only" signal loss

[BuddhaDiedLaughing]

Shizuku status, if applicable

Shizuku running and permission granted

Root status, if applicable

None

Current behavior

The latest DeepSeek is very confident this is exactly what you need:

Attached: 60 samples of dumpsys telephony.registry captured at 0.5s intervals over ~2 minutes while toggling between Prefer 5G and 5G Only. Extracted fields per sample: mVoiceRegState, mDataRegState, getRilDataRadioTechnology, mChannelNumber, mDataConnectionState. Raw dump available if useful.

Behavior 1 — 5G Only drops all service.
Every sample in 5G Only shows:

mVoiceRegState=1(OUT_OF_SERVICE)
mDataRegState=1(OUT_OF_SERVICE)
getRilDataRadioTechnology=0(Unknown)
mChannelNumber=-1

No fallback to LTE, no partial attach. To the user this is indistinguishable from mobile data being off. Recovery requires switching back to Prefer 5G, after which the phone attaches normally as LTE (getRilDataRadioTechnology=14).

Behavior 2 — under Prefer 5G, NR aggregates but doesn't persist.
The phone reliably attaches as LTE and shows 5G UW (NR secondary aggregated) for a short window, then reverts to plain 5G. My understanding is this is standard NSA SCG release on inactivity, so not something the app can hold — flagging it only because it shows the phone can see and use NR in this location, which means Behavior 1 isn't a coverage or hardware issue.

Context:

• Device: Snapdragon S24, One UI 8.5
• Carrier: Verizon subsidiary (Tracfone)
• Testing location: home
• Method: Shizuku
• NetToggle version: 1.2.0
• Note: UW does not appear at this location under normal use; it only showed up briefly after mode toggles triggered a fresh attach. Possible this is a corner-case cell for NR availability.

What I'm hoping to learn:

1. Is the total service drop under 5G Only expected given my carrier/SIM/plan, or is the app issuing a mode request the modem can't service gracefully?
2. If it's a codebase issue, is there a safer fallback or a pre-flight check the app could do before applying RAF_NR?

Happy to run additional captures if any particular state would be more useful.

transitions_clean.txt

[Dhangofa]

Hi @BuddhaDiedLaughing

Thank you for this clean dumpsys telephony.registry telemetry captures! This gives us the exact diagnostic visibility needed.

what is happening under the hood:

1. Is the total service drop under "5G Only" expected?

Yes, this is 100% expected behavior on Tracfone / Verizon MVNOs.

Here is why:

• 5G NSA vs. 5G SA Architecture:
  • 5G NSA (Non-Standalone): Requires an existing 4G LTE anchor cell (getRilDataRadioTechnology=14 in your logs) for control-plane signaling and voice/IMS registration, while 5G NR (e.g. n77 / C-band / UW) is aggregated dynamically as a secondary data pipe (EN-DC: E-UTRA-NR Dual Connectivity).
  • 5G SA (Standalone): Pure 5G connecting directly to a 5G Core (5GC) without any LTE dependency, using VoNR (Voice over NR).
• The Tracfone / Verizon Reality:
  • While Verizon has begun deploying 5G SA, access is currently restricted to specific Verizon postpaid accounts and enterprise SIM profiles.
  • Tracfone and almost all Verizon MVNOs (Total, Straight Talk, etc.) are strictly provisioned for 5G NSA only.
• What happens when "5G Only" is applied:
  • The app sends RAF_NR (Radio Access Family: 5G NR Only) via the standard Android Telephony API (cmd phone set-allowed-network-types-for-users).
  • Your Snapdragon X75 modem obeys faithfully: it turns off all LTE radio reception (B2, B5, B13, B66) to search exclusively for a 5G Standalone tower.
  • Because Tracfone SIMs do not have provisioning/credentials to authenticate against a 5G Standalone core, the modem is rejected, dropping immediately to mVoiceRegState=1(OUT_OF_SERVICE) and mDataRegState=1(OUT_OF_SERVICE).

Your observation about Behavior 2 is also correct: the phone attaches to LTE (getRilDataRadioTechnology=14) as the primary anchor and briefly activates the secondary cell group (SCG) for 5G UW upon reconnection before releasing it when idle.

---

2. Can NetToggle do a pre-flight check or safe fallback?

Yes, and this is something we can implement in the app:

1. Dynamic UI Locking (Similar to 2G/3G deprecation):
   Just as NetToggle disables 2G/3G toggles on carriers that sunset legacy networks, we can lock or disable the "5G Only" chip when a SIM is detected as NSA-only, displaying a badge/hint:
   "Carrier is 5G NSA only (5G Only disabled to prevent signal loss)"
   while leaving "Pref 5G" fully active.

2. Safety Fallback / Out-of-Service Watchdog:
   If a user forces 5G Only and the device remains in OUT_OF_SERVICE for longer than a grace window (e.g. 15–20 seconds), NetToggle could automatically revert to Preferred 5G to prevent leaving the user stranded without calls or data.

Thanks again for the top-tier logs and analysis! We're incorporating this carrier SA vs. NSA capability detection into upcoming work.

You can run this and share your result -

dumpsys carrier_config | grep carrier_nr_availabilities_int_array

[BuddhaDiedLaughing]

I went down a rabbit hole trying to capture actionable data. Leading with this as it is likely the most valuable:

Attached: 65-second logcat -b radio -b main capture while cycling Prefer 5G ↔ 5G Only. Toggled twice; the second 5G Only toggle is the one visible in the excerpt below.

radio_signals.txt

The key sequence, from the log:

20:02:31.442 I/IilManager<0>: handleSetPreferredNetworkType reason: 0 new NW type: 26

(26 = RAF_NR, i.e. 5G Only)

20:02:31.876 ... registrationState=NOT_REG_SEARCHING ... emergencyEnabled=true availableServices=[EMERGENCY] cellIdentity=CellIdentityLte:{ mBands=[13] ...}

20:02:32.512 D/RILJ [5846]< DATA_REGISTRATION_STATE RegStateResult{regState: REG_HOME, rat: LTE_CA, ... nrIndicators: NrIndicators{isEndcAvailable: true, isDcNrRestricted: false, isNrAvailable: true} ...}

Interpretation as I read it (please correct if wrong):

1. The app requests RAF_NR.
2. ~400ms later the modem drops to NOT_REG_SEARCHING with emergencyEnabled=true and only band 13 LTE visible — the out-of-service state I reported earlier.
3. ~1 second later the modem reattaches on LTE and explicitly reports isEndcAvailable: true, isNrAvailable: true, isDcNrRestricted: false — i.e. NR is present and permitted at this location.

That lines up with the earlier carrier_nr_availabilities_int_array = [1, 2] capture: the carrier config permits NR, and the modem can see NR, but there's no 5G SA cell to attach to here. Requesting NR-only leaves the modem with nothing to camp on, because NSA requires an LTE anchor.

So my guess is:

• Not a codebase bug in the usual sense.
• More like an environment limit the app could detect before applying RAF_NR — e.g. check isNrAvailable and whether the current serving cell only offers NSA, and if so either refuse or warn instead of dropping service entirely.

Happy to run any additional capture you want (e.g. same sequence at a different location where SA is definitely deployed, if I can find one).

---

carrier_nr_availabilities.txt

Incidentally, I went ahead and ran the poll for 60 samples at 0.5s while toggling between Prefer 5G and 5G Only twice, waiting for service / waiting for UW to release each time. carrier_nr_availabilities_int_array is [1, 2] on every sample — no variation with RAF mode. Blank samples are just grep returning empty; the underlying dumpsys call occasionally didn't return within the sample window.

So the config value is static and permissive. The 5G Only failure isn't being gated at the carrier config layer. Let me know what you'd like next — happy to poll another value with the same script, or capture the radio log buffer if you want the RIL-side view of what happens at the moment of the drop.

carrier_nr_avail_20260916_195317.txt

[Dhangofa]

Hi @BuddhaDiedLaughing,

Thank you for providing the full radio_signals.txt log buffer! Analyzing the RIL and Telephony framework timeline gives us the complete, unambiguous picture of the modem behavior.

To help me design a rock solid, zero overhead pre-flight detection mechanism, could you capture these specific diagnostic dumps when you have a moment?

1. While on Preferred 4G (Crucial Check)

Before switching to 5G, we need to verify if the LTE tower broadcasts 5G NR/EN-DC availability even while the phone is restricted to 4G:

1. Switch NetToggle to 4G Only (or Preferred 4G).
2. Generate some light network traffic (open a web page).
3. Run:

dumpsys telephony.registry | grep -E "mNetworkRegistrationInfos|CellIdentity|mVoiceRegState|mDataRegState|mOverrideNetworkType"

and:

dumpsys phone | grep -E "CellInfoNr|CellInfoLte|mNrState|mPrimaryCell"

2. While on Prefer 5G (Active Data) (at your current home location)

1. Switch to Prefer 5G.
2. Run a quick speed test or load a video so the NR secondary carrier (SCG) is actively engaged.
3. Run the same two commands above.

3. Comparison Capture (In a confirmed 5G Standalone / SA location, if you visit one)

If you happen to be in an area where 5G SA is live (where selecting "5G Only" attaches successfully without dropping to OUT_OF_SERVICE):

• Run the same commands.

---

What this tells us:

1. Capture 1 (4G) tells us if NetToggle can inspect the tower's NR readiness before leaving 4G.
2. Capture 2 (Prefer 5G) provides the baseline for active NSA dual-connectivity.
3. Capture 3 (5G SA) gives us the exact fingerprint of a true Standalone cell.

Thanks again for helping us make NetToggle bulletproof!

[BuddhaDiedLaughing]

issue26_evidence_bundle.zip

issue26_findings.md

NetToggle Issue #26 — Capture & Analysis Report

Environment

• Device: Samsung Galaxy S24 (Snapdragon), One UI 8.5
• Carrier: Verizon-network MVNO — MCC/MNC 311/480, APN VZWINTERNET (data call profile is LTE/EUTRAN)
• NetToggle: v1.2.0 (versionCode 34, targetSdk 37)
• Capture method: privileged shell (uid=2000, Shizuku-level ADB) — dumpsys telephony.registry, dumpsys phone, logcat -b radio
• Caveat: nrState is masked (****) at shell UID (no root). Equivalent signals used instead (see "Field mapping").

TL;DR — Root cause

"5G Only" (RAF_NR, RIL bitmap 0x80000) drops the device to complete OUT_OF_SERVICE because this device/carrier is NSA-only — there is no standalone (SA) NR cell to camp on.

On NR-only the modem enters NOT_REG_MT_SEARCHING_OP and the data controller tears down all data calls with reasons DATA_NETWORK_TRANSPORT_NOT_ALLOWED, SERVICE_OPTION_NOT_SUPPORTED, NOT_IN_SERVICE. 4G Only and Prefer 5G (NSA) both work normally.

Mode → RIL fingerprint (exact values)

NetToggle mode	RIL SET_ALLOWED_NETWORK_TYPES_BITMAP	AOSP network-mode	registry mAllowedNetworkTypeValue	Result
4G_ONLY	0x41000	11 (LTE_ONLY)	4096 (Samsung LTE-only)	✅ LTE_CA 3×, HOME
PREF_5G	0xCD387	26	916479 (0xDFBFF = full+NR)	✅ NR_NSA / NR_ADVANCED
5G_ONLY	0x80000	23	524288 (NR only)	❌ OUT_OF_SERVICE

(SemGsmCdmaPhone EVENT_SET_ALLOW_NETWORKTYPES_DONE confirms each mode as reason: user.)

Per-mode findings

#1 — 4G Only ("crucial check")

While locked to 4G:

• isNrAvailable = false, isEnDcAvailable = false
• mPhysicalChannelConfigs = 3× LTE_CA, no NR secondary
• overrideNetwork = LTE_CA / NONE

Observation: on the same cell, switching to PREF_5G immediately flips isEnDcAvailable → true and overrideNetwork → NR_NSA. This indicates Samsung gates isEnDcAvailable on the allowed network type (NR allowed?) rather than reading the cell's EN-DC capability directly — so NetToggle likely cannot reliably read "NR readiness" while restricted to 4G on this ROM.

#2 — Prefer 5G + active data (YouTube streaming)

• isNrAvailable = true, isEnDcAvailable = true
• mPhysicalChannelConfigs = P:LTE_CA/10000 + S:NR/0 → NR secondary (SCG) engaged
• overrideNetwork transitions NR_NSA → NR_ADVANCED during active data
• getRilDataRadioTechnology = 14 (LTE) (NSA anchor), registrationState = HOME

#3 — 5G Only (the failure)

• mAllowedNetworkTypeValue → 524288 (NR only); preferred_network_mode global does not change (NetToggle drives the RIL bitmap directly, not that setting).
• Drop within ~33 ms of the toggle: mVoiceRegState=1, mDataRegState=1, getRilDataRadioTechnology=0(Unknown), registrationState=NOT_REG_SEARCHING, accessNetworkTechnology=UNKNOWN.
• Stays OUT_OF_SERVICE the entire 25 s capture (49/50 samples).
• Recovery within ~1.3 s of returning to PREF_5G.

Failure sequence (radio log, verbatim essentials)

RILJ [6503]> SET_ALLOWED_NETWORK_TYPES_BITMAP networkTypeBitmask: 0x80000(23) [PHONE0]
NetworkTypeController: [0] NrConnectedState: process EVENT_PREFERRED_NETWORK_MODE_CHANGED
RILJ [UNSL]< UNSOL_RESPONSE_NETWORK_STATE_CHANGED [PHONE0]
RILJ < DATA_REGISTRATION_STATE RegStateResult{regState: NOT_REG_MT_SEARCHING_OP, rat: UNKNOWN, reasonForDenial: NONE, ...} [PHONE0]
RILJ < VOICE_REGISTRATION_STATE RegStateResult{regState: NOT_REG_MT_SEARCHING_OP, rat: UNKNOWN, ...} [PHONE0]
DNC-0 Data evaluation: ... Data disallowed reasons: DATA_NETWORK_TRANSPORT_NOT_ALLOWED NO_SUITABLE_DATA_PROFILE SERVICE_OPTION_NOT_SUPPORTED NOT_IN_SERVICE, ... network type=UNKNOWN, reg state=NOT_REG_SEARCHING
RILJ [UNSL]< UNSOL_DATA_CALL_LIST_CHANGED [] [PHONE0]          <-- all data calls torn down

Note: the data profile / SETUP_DATA_CALL uses accessNetworkType=EUTRAN (LTE) — i.e. there is no NR data profile, consistent with NSA-only operation.

Field mapping (Samsung vs. the suggested commands)

The suggested dumpsys phone | grep CellInfoNr|CellInfoLte|mNrState|mPrimaryCell returns zero matches on this device. The equivalent data is in dumpsys telephony.registry:

Suggested	Actual on this device
mOverrideNetworkType	overrideNetwork= inside mTelephonyDisplayInfo (NR_NSA/NR_ADVANCED/LTE_CA/NONE)
CellInfoLte	mCellInfo (registry)
CellInfoNr	❌ none reported — NR is NSA-secondary; see mPhysicalChannelConfigs + mSignalStrength.mNr
mNrState	masked (nrState=****) at shell UID
mPrimaryCell	❌ absent — use mPhysicalChannelConfigs (PrimaryServing/SecondaryServing + RAT)

Artifacts (attached)

• 4G_ONLY_*/ — compact CSV, radio log, 3× full raw dumps, dev_cmd1_registry_grep.txt, samsung_substitute_grep.txt
• PREF_5G_*/ — same layout
• issue26_*/ — 3-phase run (PREF_5G → 5G_ONLY → PREF_5G) + merged issue26_timeline.csv
• nr_poll.sh, probe_issue26.sh, capture_raw.sh — reproducible capture scripts

What this means for NetToggle

A "5G Only" tile on an NSA-only carrier will always produce this outcome — there is no SA NR cell to attach to. Possible guardrails: detect isEnDcAvailable/nrState/no-SA-cell before applying RAF_NR, or fall back to PREF_5G when NR-only registration is not achievable within a timeout.

[Dhangofa]

Can you try also Pref 4G, I am getting 5G capabilities from tower, wanted to check if it is same behaviour ther also.

Other results are matching with my results also.
Just check this pref 4G once.

[BuddhaDiedLaughing]

Ran the command you asked for:

dumpsys carrier_config | grep carrier_nr_availabilities_int_array
# → carrier_nr_availabilities_int_array = [1, 2]

In AOSP this maps to the NR availability bitmask: 1 = NR (SA) and 2 = NR NSA/EN-DC. So the carrier profile advertises both SA and NSA as technically available, yet the SA attach still fails — which lines up exactly with your read that the block is at the SIM-provisioning layer (no 5G-SA core credentials on Tracfone/MVNO), not the modem or the app.

Happy to run anything else that helps the SA-vs-NSA detection work.

[Dhangofa]

Sorry I asked this to run while in Pref 4G, so that we can understand while pref 4G are we getting the broadcast from the tower that it supports 5G or not.

dumpsys telephony.registry | grep -E "mNetworkRegistrationInfos|CellIdentity|mVoiceRegState|mDataRegState|mOverrideNetworkType"

[BuddhaDiedLaughing]

@Dhangofa — ran your dumpsys telephony.registry command. Note: the device is currently on LTE (RAT=14), not an explicit "Pref 4G" override, but the registration state is what matters for the SA/NSA question. Cell identifiers are redacted.

Key signal (DataSpecificRegistrationInfo)

accessNetworkTechnology=LTE
DataSpecificRegistrationInfo: { maxDataCalls=16 isDcNrRestricted=false isNrAvailable=true isEnDcAvailable=true ... }

Cell-level signal (CellConfigLte, per-cell)

CellConfigLte: { isEndcAvailable = false }   ← on EVERY cell (serving + neighbors)

What this means

There are two different "NR available" flags, and they disagree:

1. Upper-layer capability (isNrAvailable=true, isEnDcAvailable=true) — this comes from the carrier config / RIL upper-layer indication and matches the carrier_nr_availabilities_int_array = [1,2] we found earlier. It says NR SA + NSA are "technically available".

2. Cell-level EN-DC (CellConfigLte.isEndcAvailable = false) — this is what the serving LTE cell actually broadcasts in its SIB2 upper-layer-indication. It is false on every visible cell.

So: the network is NOT advertising 5G NSA (EN-DC) support at the cell level, even though the carrier profile claims NR is available. This is consistent with the block being at the SIM-provisioning / network layer (no 5G-SA core credentials on this MVNO), not the modem or the app.

If you want the exact "Pref 4G" capture specifically (forced network-mode override, rather than the current auto LTE), I can set the mode and re-run — just confirm the mode value you want (e.g. LTE_ONLY / PREF_4G).

Cell identity fields (mCi/mPci/mTac/mEarfcn/MCC/MNC) redacted.

[BuddhaDiedLaughing]

@Dhangofa — here is the Pref 4G result you asked for. Note: the SET_MODE broadcast did work — the preferred_network_mode global setting stays 26,26 because NetToggle applies the mode via a per-subscription override, not that raw setting, so the radio state is the authoritative signal.

Before vs after (Pref 4G)

State	isNrAvailable	isEnDcAvailable	CellConfigLte.isEndcAvailable
Before (5G auto)	true	true	false
After (Pref 4G)	false	false	false

What this confirms

Forcing "Pref 4G" makes the network stop advertising NR availability entirely — isNrAvailable and isEnDcAvailable both drop from true to false in DataSpecificRegistrationInfo. This is the expected, correct behavior: the preferred-network-mode override gates the NR capability advertisement.

The CellConfigLte.isEndcAvailable was false in both states (the serving cell never broadcasts EN-DC in its SIB2 upper-layer indication), which is the separate, network-side observation from before — but the upper-layer isNrAvailable flag is cleanly toggled by the mode switch, exactly as you expected.

So the full picture: the mode override works correctly (NR capability advertisement flips with Pref 4G), and the reason 5G-SA attach still fails in 5G mode is the network/SIM-provisioning layer (no SA core credentials on this MVNO), not the mode-switch mechanism or the app.

Cell identity fields redacted.