[0xadam-brown]

PR Stack (Nav3 Lifecycle)

• fix(android): Nav3 multi-Activity support now plays nicely with nav roots that don't have a SentryNavEffect #6480
• ref(android): [Part 1] Refactor #6481
• feat(android): [Part 2] Start a new nav transaction when returning to a nav root #6482
• fix(android): [Part 3] Stop attributing Nav3 data to screens without a SentryNavEffect #6483
• feat(android): [Part 4] Prefer Activity ui.load transactions over Nav3 transactions #6484

---

📜 Description

Starts a new Nav3 transaction for the current destination when the user returns to a nav root whose previous transaction has finished. Matches behavior of Nav2 + Compose.

Prior (and wrong) assumption	Problematic scenario	Before	After
A nav transaction only needs to start when the user navigates forward	The user returns to a nav root after its nav transaction finished	No transaction until the user navigates somewhere in the nav root's nav graph, meaning spans produced on return can be dropped	A new nav transaction starts for the returned-to nav root if its original transaction finished while unbound

How this PR fixes it

Replaces the one-shot NavTransaction with a reusable NavTransactionRequest. The request is kept until the user leaves the destination. When a nav root gets the lease back, it rebinds its unfinished transaction or starts a new one from the request.

⚠️ Callouts

[1] Quota impact: This PR increases the number of transactions some apps send. Returning to a nav root now starts a new nav transaction if the previous one finished. That includes closing an Activity that covered it, swiping back to a ViewPager2 page, or dismissing a dialog over it. Apps with lots of back-and-forth between nav roots will send more nav transactions than before. (Note: empty transactions aren't charged against user quotas, so only return transactions that have spans attached to them will count, and they're the ones users will want, anyway.)

Note that apps will still send fewer transactions with Nav3 than they do with Nav2 + Compose. Nav2 + Compose starts a new transaction on every resume; this PR starts one only if the resumed nav root's prior transaction finished in the meantime (otherwise the original transaction is re-bound).

[2] Behavior is enabled by default: I haven't bothered creating an opt-in flag b/c Nav3 support is still experimental and isn't widely used; the behavior prior to this fix looks random because it depends on i) whether the Android framework keeps the returned-to Activity or Fragment alive, and ii) how long the user spent on the non-candidate screen; and absent the fix work done upon return (eg, a data refresh when the screen resumes) would be lost.

💡 Motivation and Context

Before, a nav root returned to after its transaction finished got none until its next navigation, so spans produced on return (e.g., by work the nav root resumes) were dropped. This was most visible with ViewPager2 pages and with Activities that were covered for longer than the idle timeout.

addresses: JAVA-823

💚 How did you test it?

• Unit tests
• Integration tests
• Had my clanker thoroughly test the pre- and post-stack behavior via the Nav3 sample app i) to verify the stack really does what it claims to and ii) to ensure it doesn't introduce any regressions.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

The next PR in the stack stops attributing errors and spans from Activities and ViewPager2 pages without a SentryNavEffect to the most recently visited nav root.

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against fb99ac6

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.63.0 (1)	release

⚙️ sentry-android Build Distribution Settings