Notification processing silently fails in CI magisk-debug build but works in locally compiled build #323

Closed
opened 2026-03-25 06:46:24 +01:00 by perseverance4phone · 9 comments

Device: Google Pixel 9 Pro (caiman)
ROM: LineageOS 22.1-20250204-NIGHTLY-caiman
Android version: 15 (API 35)
Magisk version: 28.1

Description

SM-DP+ notifications (install/enable confirmations) fail to process silently when using the CI-built magisk-debug artifact. Tapping long-press -> Process on a notification produces zero log output -- no errors, no network requests, nothing. The notification remains in the list unchanged.

Building from the same master branch locally with ./gradlew :app:assembleDebug and installing the resulting APK into the Magisk module's priv-app path produces a fully working build where notification processing succeeds immediately.

Steps to reproduce

  1. Install CI magisk-debug module (artifact ID 633) via Magisk on a device running LineageOS 22.1
  2. Reboot
  3. Download an eSIM profile (download itself works correctly)
  4. Go to Manage Notifications -- pending notifications are listed
  5. Long-press a notification -> Process

Nothing happens. logcat | grep openeuicc shows no output related to the process action

Expected behavior

Notification is sent to the SM-DP+ server and removed from the list.

Actual behavior

Tap is silently ignored. No log output, no network request, no error.

Workaround

  1. Clone the repo
  2. build locally using Android Studio (Build -> Build APK(s)), which invokes './gradlew :app:assembleDebug' internally.
  3. Replace the APK in the Magisk module at 'system/system_ext/priv-app/OpenEUICC/OpenEUICC.apk'.
  4. Set SELinux context with 'chcon -R u:object_r:system_file:s0' on the module directory.

The locally built version processes notifications correctly.

The difference in behavior between CI and local builds may be caused by R8/ProGuard code minification in the CI pipeline stripping or obfuscating code paths that the local debug build preserves.

Device: Google Pixel 9 Pro (caiman) ROM: LineageOS 22.1-20250204-NIGHTLY-caiman Android version: 15 (API 35) Magisk version: 28.1 ## Description SM-DP+ notifications (install/enable confirmations) fail to process silently when using the CI-built magisk-debug artifact. Tapping long-press -> Process on a notification produces zero log output -- no errors, no network requests, nothing. The notification remains in the list unchanged. Building from the same master branch locally with ./gradlew :app:assembleDebug and installing the resulting APK into the Magisk module's priv-app path produces a fully working build where notification processing succeeds immediately. ## Steps to reproduce 1. Install CI magisk-debug module (artifact ID 633) via Magisk on a device running LineageOS 22.1 2. Reboot 3. Download an eSIM profile (download itself works correctly) 4. Go to Manage Notifications -- pending notifications are listed 5. Long-press a notification -> Process Nothing happens. `logcat | grep openeuicc` shows no output related to the process action ## Expected behavior Notification is sent to the SM-DP+ server and ~~removed from the list~~. ## Actual behavior Tap is silently ignored. No log output, no network request, no error. ## Workaround 1. Clone the repo 2. build locally using Android Studio (Build -> Build APK(s)), which invokes `'./gradlew :app:assembleDebug'` internally. 3. Replace the APK in the Magisk module at `'system/system_ext/priv-app/OpenEUICC/OpenEUICC.apk'`. 4. Set SELinux context with `'chcon -R u:object_r:system_file:s0'` on the module directory. The locally built version processes notifications correctly. ## Possibly related The difference in behavior between CI and local builds may be caused by R8/ProGuard code minification in the CI pipeline stripping or obfuscating code paths that the local debug build preserves.

Did the local build with the 'master' branch, HEAD 720cb7e707

Did the local build with the 'master' branch, HEAD 720cb7e7072243df583534b590cfabd566163f71
Collaborator

Please provide verbose logs for here.

Please provide verbose logs for here.
Collaborator

"Process" and "Delete" are two separate operations

"Process" does not remove an notification item from notification list

"Process" and "Delete" are two separate operations "Process" does not remove an notification item from notification list
Owner

Notification is sent to the SM-DP+ server and removed from the list.

We never remove notifications from the list.

> Notification is sent to the SM-DP+ server and removed from the list. We never remove notifications from the list.

@PeterCxy wrote in #323 (comment):

Notification is sent to the SM-DP+ server and removed from the list.

We never remove notifications from the list.

Oh, sorry, I did not actually mean that the notification item should be removed from the list, that was a mistake when composing the bug description. In fact the notification items are still shown in the app from my local build; however, I can tell you for sure that the SM-DP+ notifications were never actually sent when using the CI-built app, but did get sent when using the local-built app.

@PeterCxy wrote in https://gitea.angry.im/PeterCxy/OpenEUICC/issues/323#issuecomment-2196: > > Notification is sent to the SM-DP+ server and removed from the list. > > We never remove notifications from the list. Oh, sorry, I did not actually mean that the notification item should be removed from the list, that was a mistake when composing the bug description. In fact the notification items are still shown in the app from my local build; however, I can tell you for sure that the SM-DP+ notifications were never actually sent when using the CI-built app, but did get sent when using the local-built app.

@septs wrote in #323 (comment):

Please provide verbose logs for here.

I was troubleshooting this yesterday, and it looks like since then those logs got overwritten by today's logs in the circular buffer; however, yesterday I did not see any log entries from when the CI-built app silently failed. However, if there is a specific log file and / or log tags you'd like me to look at please let me know.

@septs wrote in https://gitea.angry.im/PeterCxy/OpenEUICC/issues/323#issuecomment-2194: > Please provide verbose logs for here. I was troubleshooting this yesterday, and it looks like since then those logs got overwritten by today's logs in the circular buffer; however, yesterday I did not see any log entries from when the CI-built app silently failed. However, if there is a specific log file and / or log tags you'd like me to look at please let me know.
Owner

Sorry, I have no idea where to start here and unable to reproduce using CI builds myself. Waiting for any reproduction outside of this single report.

Sorry, I have no idea where to start here and unable to reproduce using CI builds myself. Waiting for any reproduction outside of this single report.
Owner

The difference in behavior between CI and local builds may be caused by R8/ProGuard code minification in the CI pipeline stripping or obfuscating code paths that the local debug build preserves.

No, ProGuard doesn't really do anything in our case. Especially not for magisk-debug. And it's not like your local builds use a different ProGuard preset anyway.

> The difference in behavior between CI and local builds may be caused by R8/ProGuard code minification in the CI pipeline stripping or obfuscating code paths that the local debug build preserves. No, ProGuard doesn't really do anything in our case. Especially not for magisk-debug. And it's not like your local builds use a different ProGuard preset anyway.
Collaborator

if a new similar report is received, it will be reopened

if a new similar report is received, it will be reopened
septs closed this issue 2026-07-02 16:22:17 +02:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
3 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#323
No description provided.