fix: [SDK-4845] always finish base notification trampoline via finally#2681
Merged
Conversation
NotificationOpenedActivityBase called AndroidUtils.finishSafely only on the success path: an init failure early-returned and a thrown processFromContext both skipped it, stranding the transient trampoline activity. This is the same early-return-before-finish shape removed from the HMS trampoline in #2678. Wrap the coroutine body in try/finally so finishSafely always runs on the main thread after processing, an early return, or an exception. Keeping finish in finally (after processFromContext) preserves the Xiaomi startActivity()-before-finish() ordering. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
📊 Diff Coverage ReportDiff Coverage Report (Changed Lines Only)Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff). Changed Files Coverage
Overall (aggregate gate)0/8 touched executable lines covered (0.0% — requires ≥ 80%) Per-file detail (informational; gate is aggregate above):
❌ Coverage Check FailedAggregate coverage on touched lines is 0.0% (minimum 80%). |
…st intent Address review feedback on the base-trampoline finally fix: - Rename the success-path test to reflect it is an ordering guard (finish after processFromContext), not the core regression. - Add a regression test asserting the trampoline is still finished when processFromContext throws (the exception propagates, but finally must have finished the activity first). - Drain the main-thread looper before asserting isFinishing so the assertions don't rely on runOnUiThread happening to run synchronously. Co-authored-by: Cursor <cursoragent@cursor.com>
Keep the comments concise and free of ticket numbers. Co-authored-by: Cursor <cursoragent@cursor.com>
fadi-george
approved these changes
Jul 8, 2026
This was referenced Jul 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to SDK-4734 / #2678, addressing @fadi-george's review comment on that PR.
PR #2678 fixed the HMS trampoline so
finish()always runs (viatry/finally) even when init fails or processing throws.NotificationOpenedActivityBase— the GMS / base trampoline used byNotificationOpenedActivityandNotificationOpenedActivityAndroid22AndOlder— still had the same early-return-before-finish shape:OneSignal.initWithContext(...)returnsfalse, the coroutine early-returns andAndroidUtils.finishSafely(...)is skipped.openedProcessor.processFromContext(...)throws,finishSafely(...)is likewise skipped.In both cases the transient trampoline activity is never dismissed and lingers in its task. Not a crash (
suspendifyOnDefaultcatches/logs and the init branch is a plain early return), but a real, low-frequency lifecycle strand that is inconsistent with the now-fixed HMS path.Fix
Wrap the coroutine body in
try { ... } finally { runOnUiThread { AndroidUtils.finishSafely(this) } }so the trampoline is always dismissed on the main thread after processing, an early return, or an exception. Keepingfinish()infinally(afterprocessFromContext) preserves the documented Xiaomi requirement thatstartActivity()runs beforefinish().Test plan
Added two regression tests to
NotificationOpenedActivityBaseTestmirroring the HMS coverage:does not finish the base trampoline until after open processing runs— asserts the synchronous part does not finish the activity, and it finishes only afterprocessFromContextruns.always finishes the base trampoline even when initialization fails— asserts the activity is finished on theinitWithContext == falseearly-return path (the core regression) without invokingprocessFromContext.Full module unit tests and detekt pass locally.
Made with Cursor