Crash (NullPointerException) in EuiccManagementFragment during UI refresh due to OMAPI transmit error (Motorola Moto G35 5G) #334

Closed
opened 2026-04-28 14:34:16 +02:00 by r0m4n · 1 comment

Describe the bug:

The application fails to retrieve the EID and crashes/fails to load profiles when refreshing the main UI.
It correctly detects the eUICC on slot 0, but throws an OMAPI APDU exception (java.io.IOException: Error in transmit()).
Because the APDU transmission fails, LocalProfileAssistantImpl.getEID() seemingly returns a null/invalid value, which is not handled gracefully and leads to a NullPointerException inside EuiccManagementFragment$doRefresh.

Environment:

Device: Motorola Moto G35 5G
Android Version: 15 (SDK 35)
App Version: v1.6.2-unpriv

Steps to Reproduce:

Open the EasyEUICC / OpenEUICC app.
The app attempts to read the eUICC on slot 0.
Observe the crash / failure to load profiles during the refresh operation.

Expected behavior:

The app should catch the OMAPI transmit() exception gracefully and display a proper error message (e.g., "OMAPI transmission failed / No access to eUICC") instead of throwing a NullPointerException.
(Optional) If there is a known workaround for OMAPI restrictions on this Motorola device (Android 15), it would be great to implement it or add a hint for the user.

Relevant logcat snippets:

First, the OMAPI fails to transmit:

04-28 14:17:23.947  3982  4041 E OmapiApduInterface: OMAPI APDU exception
04-28 14:17:23.947  3982  4041 W System.err: java.io.IOException: Error in transmit()
04-28 14:17:23.947  3982  4041 W System.err: 	at android.se.omapi.Channel.transmit(Channel.java:174)
04-28 14:17:23.947  3982  4041 W System.err: 	at im.angry.openeuicc.core.OmapiApduInterface.transmit(OmapiApduInterface.kt:66)

Which immediately leads to the crash during the UI refresh:

04-28 14:17:23.949  3982  3982 W System.err: java.lang.NullPointerException
04-28 14:17:23.949  3982  3982 W System.err: 	at net.typeblog.lpac_jni.impl.LocalProfileAssistantImpl.getEID(LocalProfileAssistantImpl.kt:170)
04-28 14:17:23.949  3982  3982 W System.err: 	at im.angry.openeuicc.core.LocalProfileAssistantWrapper.getEID(LocalProfileAssistantWrapper.kt:30)
04-28 14:17:23.949  3982  3982 W System.err: 	at im.angry.openeuicc.ui.EuiccManagementFragment$doRefresh$profiles$1.invokeSuspend(EuiccManagementFragment.kt:216)

Additional context:

I have attached the full log file for further investigation.

Update from a second logcat:
I reproduced the issue again and captured another log (attached below). Please note that this second log is more detailed because I enabled the "verbose logging" option in the app settings.

This new log reveals something crucial: OMAPI is not completely blocked.

With verbose logging on, we can see that some APDU commands are actually transmitted successfully and return correct responses from the eUICC, for example:
D OmapiApduInterface: OMAPI APDU: 81E2910003BF2200
D OmapiApduInterface: OMAPI APDU response: BF227E810302030182...

However, moments later, subsequent APDUs sporadically fail with the same java.io.IOException: Error in transmit().
This indicates that the OMAPI service on this Motorola Moto G35 5G is highly unstable, drops the connection, or times out randomly.

The application still crashes with a NullPointerException right after the transmission failure because the null response is unhandled (this time also occurring at MainActivity$init$3$1$1.invokeSuspend(MainActivity.kt:179) during app startup).

### Describe the bug: The application fails to retrieve the EID and crashes/fails to load profiles when refreshing the main UI. It correctly detects the eUICC on slot 0, but throws an OMAPI APDU exception (`java.io.IOException: Error in transmit()`). Because the APDU transmission fails, `LocalProfileAssistantImpl.getEID()` seemingly returns a null/invalid value, which is not handled gracefully and leads to a `NullPointerException` inside `EuiccManagementFragment$doRefresh.` ### Environment: Device: Motorola Moto G35 5G Android Version: 15 (SDK 35) App Version: v1.6.2-unpriv ### Steps to Reproduce: Open the EasyEUICC / OpenEUICC app. The app attempts to read the eUICC on slot 0. Observe the crash / failure to load profiles during the refresh operation. ### Expected behavior: The app should catch the OMAPI transmit() exception gracefully and display a proper error message (e.g., "OMAPI transmission failed / No access to eUICC") instead of throwing a NullPointerException. (Optional) If there is a known workaround for OMAPI restrictions on this Motorola device (Android 15), it would be great to implement it or add a hint for the user. ### Relevant logcat snippets: First, the OMAPI fails to transmit: ``` 04-28 14:17:23.947 3982 4041 E OmapiApduInterface: OMAPI APDU exception 04-28 14:17:23.947 3982 4041 W System.err: java.io.IOException: Error in transmit() 04-28 14:17:23.947 3982 4041 W System.err: at android.se.omapi.Channel.transmit(Channel.java:174) 04-28 14:17:23.947 3982 4041 W System.err: at im.angry.openeuicc.core.OmapiApduInterface.transmit(OmapiApduInterface.kt:66) ``` Which immediately leads to the crash during the UI refresh: ``` 04-28 14:17:23.949 3982 3982 W System.err: java.lang.NullPointerException 04-28 14:17:23.949 3982 3982 W System.err: at net.typeblog.lpac_jni.impl.LocalProfileAssistantImpl.getEID(LocalProfileAssistantImpl.kt:170) 04-28 14:17:23.949 3982 3982 W System.err: at im.angry.openeuicc.core.LocalProfileAssistantWrapper.getEID(LocalProfileAssistantWrapper.kt:30) 04-28 14:17:23.949 3982 3982 W System.err: at im.angry.openeuicc.ui.EuiccManagementFragment$doRefresh$profiles$1.invokeSuspend(EuiccManagementFragment.kt:216) ``` ### Additional context: I have attached the full log file for further investigation. **Update from a second logcat:** I reproduced the issue again and captured another log (attached below). Please note that this second log is more detailed because I enabled the "verbose logging" option in the app settings. This new log reveals something crucial: OMAPI is **not completely blocked**. With verbose logging on, we can see that some APDU commands are actually transmitted successfully and return correct responses from the eUICC, for example: `D OmapiApduInterface: OMAPI APDU: 81E2910003BF2200` `D OmapiApduInterface: OMAPI APDU response: BF227E810302030182...` However, moments later, subsequent APDUs sporadically fail with the same `java.io.IOException: Error in transmit()`. This indicates that the OMAPI service on this Motorola Moto G35 5G is highly unstable, drops the connection, or times out randomly. The application still crashes with a `NullPointerException` right after the transmission failure because the null response is unhandled (this time also occurring at `MainActivity$init$3$1$1.invokeSuspend(MainActivity.kt:179)` during app startup).
Owner

W System.err: at android.se.omapi.Channel.transmit(Channel.java:174)

Not our bug.

> W System.err: at android.se.omapi.Channel.transmit(Channel.java:174) Not our bug.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PeterCxy/OpenEUICC#334
No description provided.