chore(android): Mark MemoryLimiter sessions as having exited abnormally (JAVA-687)

[0xadam-brown]

📜 Description

Follow up to #6111.

PR marks recovered MemoryLimiter exits as abnormal session endings so release health no longer treats the terminated process as a healthy exit.

To do so, we piggyback on the existing AbnormalExit repair path currently used by ANRs. That makes sense as it's the sanctioned path for sessions that end abnormally, which fits MemoryLimiter kills.

Note: The possible session states are: Ok (ie, start state / pre-exit), Exited (normal exit), Crashed, Abnormal, and Unhandled (used by Flutter). See here.

💡 Motivation and Context

#6111 introduced the event path for generating SentryEvents from ApplicationExitInfo records produced by MemoryLimiter process kills. This PR finishes that work by adding the session-repair path. Without it, previous session records would report healthy exits when in fact they'd been killed via the MemoryLimiter.

The PR works by having MemoryLimiterHint implement the AbnormalExit interface, just like AnrHint and AnrV2Hint do today. That interface is read by:

• ApplicationExitInfoEventProcessor, which backfills the synthetic SentryEvent with contextual data from the killed process.
• SentryClient, which marks the session as abnormal.
• EnvelopeCache, which finalizes the prior session on disk.

Because MemoryLimiterHint implements Backfillable, it's not sent to the MainEventProcessor, and hence it isn't given a record of the current process's threads. That's good b/c the current process isn't the one that was killed. (AnrV2Hint similarly implements Backfillable and skips MainEventProcessor.)

addresses: JAVA-687

💚 How did you test it?

Unit tests + I had my clanker manually test behavior against the (yet-to-be introduced) MemoryLimiter sample app.

📝 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

• PR introducing the MemoryLimiter sample app.

#skip-changelog (the CHANGELOG entry from #6111 covers both it and this, as we'll merge both PRs simultaneously / incorporate them into the same release.

[linear-code]

JAVA-687

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit e3d925c. Configure here.}

[0xadam-brown]

(Fyi, I checked those call sites in connection with the work here, and we didn't need to make any changes.)