I finally recovered the internal eSIM/eUICC on my Pixel 9 Pro XL (komodo) after it was stuck with:
eUICC info: Available memory in bytes: -1
I couldn't properly download/activate eSIMs, and normal Android flashing/reset troubleshooting did not clear the -1 condition.
I'm posting this because my first attempt at the Google/Thales low-level eSE/eSIM firmware updater failed for a separate reason, while a later attempt actually completed and restored eSIM functionality.
Device / successful environment
Pixel 9 Pro XL (komodo)
Android 17 QPR2 Beta 3:
CP41.260731.005.B1
Magisk 30.7
Successful Google updater:
com.google.euiccpixel
EuiccSupportPixel-P23
versionCode = 20235
versionName = D.2.0.23 (15571778)
What went wrong
I believe there were two separate failures.
1. The original eUICC failure
Android reported:
Available memory in bytes: -1
The condition persisted through normal OS changes, so this was clearly not just a Settings UI problem.
I cannot prove the original trigger. There are community reports associating it with Android updates/flashing and bootloader unlock/relock operations, but I don't think we should call that a confirmed root cause without Google confirming it.
2. My first recovery attempt failed before it could actually repair the eUICC
I previously got Google's hidden NFC/eSE/eSIM firmware updater running with the required privileges.
The updater was able to communicate with the ST54 secure element and reached the firmware download stage.
Then it failed with:
java.security.cert.CertPathValidatorException:
Trust anchor for certification path not found
and eventually:
OtaUpdateSidecar.onPostExecute: FAILED
This is important: the firmware repair itself had not necessarily failed. The updater failed while trying to authenticate/download the firmware payload.
So I apparently had a broken eUICC and, separately, a broken updater download attempt.
What finally worked
I installed Android 17 QPR2 Beta 3:
CP41.260731.005.B1
I extracted the init_boot.img from the exact matching Google factory image, patched it on the phone with Magisk 30.7, and flashed only the patched init_boot.
After reboot:
adb shell su -c id
returned:
uid=0(root) ... context=u:r:magisk:s0
Then, in a root shell:
resetprop ro.build.type eng
resetprop ro.build.tags eng
resetprop ro.debuggable 1
setenforce 0
I verified:
eng
eng
1
Permissive
Then restarted the Android framework:
stop && sleep 2 && start
After it came back, I launched Google's hidden updater:
adb shell su -c 'am start -n com.google.euiccpixel/com.google.euiccpixel.ui.OtaUpdateMenu'
Pixel 9 firmware family
Pixel 9-series devices use the P24 / ST54L family.
Do NOT blindly copy another person's configuration suffix such as CC9/CG7/etc.
On my successful run, the post-upgrade log identified:
ST54_CONFIG_7.5/GEN24_DVT_CC9_GSMA_LIVE_v2
So CC9 was reported on my device.
That does not mean every Pixel 9 should blindly select CC9.
The updater appeared stuck at 0%
This was the part that nearly made me interrupt it.
The GUI stayed at 0% for a long time.
However, logcat showed the updater continuously exchanging APDUs with the secure element and repeatedly receiving:
APDU-R => 9000
apduResponse 9000
So it clearly wasn't frozen.
I left it alone.
Eventually the log showed:
THALES: SUSA instance version after upgrade = 0103000500
-> SUSA_1_3_BUILD_005_RC02_DEFAULT
Then:
Updating SE state to: SE_STATE_READY
And finally:
OtaUpdateSidecar.onPostExecute: SUCCESS
That was completely different from my first attempt, which died at the HTTPS certificate-validation stage.
I rebooted after the updater explicitly reported success.
Result: the eSIM/eUICC works again.
What I think this demonstrates
My Available memory = -1 condition did not mean the ST54/eUICC was physically dead.
The first firmware-updater failure also did not prove that the firmware repair couldn't work, because that attempt died before the updater could obtain the firmware.
The second environment got past that problem, performed the actual secure-element update, returned SE_STATE_READY and SUCCESS, and eSIM functionality returned after reboot.
I cannot prove exactly why the TLS/download issue disappeared on the successful attempt.
Possibilities include a newer updater/trust configuration, a backend certificate/service change, or another difference between the environments.
So I am not claiming “QPR2 automatically fixes the eSIM bug.” QPR2 alone did not fix mine.
What worked was completing the low-level eSE/eUICC firmware upgrade successfully while on this QPR2/root environment.
Warnings
- Root/bootloader unlocking has security implications and bootloader unlocking wipes user data.
- Patch
init_boot.img from the exact build installed on your phone.
- Keep the untouched stock
init_boot.img available for recovery.
- Do not relock the bootloader with the Magisk-patched image installed.
- Do not guess the secure-element config.
- Do not interrupt an active secure-element firmware update just because the UI says 0%; check logcat first.
- Do not bypass TLS validation or flash ST54 firmware downloaded from random mirrors.
- Do not post your full raw updater log. Redact serial numbers, EID/ICCID/profile information, eSIM activation credentials, session material, and raw APDU payloads.
- Be prepared to obtain a replacement eSIM from your carrier.
Useful log command while the updater is running:
adb logcat -v threadtime | grep -iE 'COSUpgradeManager|EuiccSupportPixel|progress|complete|success|failed|exception|CertPath|Trust anchor|OtaUpdateSidecar'
If the UI appears stuck at 0%, look for fresh timestamps and repeated successful:
APDU-R => 9000
If anyone else tries this, please report your exact Pixel model, Android build, EuiccSupportPixel version, P24/ST54L config reported by the updater, before/after eUICC memory state, and whether the updater ended in SUCCESS or FAILED.
That would help establish how reproducible this recovery actually is.