[Player model] Handle DeadSystemException

[jkasten2]

Description

One Line Summary

Catch DeadSystemException to prevent red herring crash reports.

Details

Motivation

DeadSystemException happens after a the app is in a bad state, not the root cause. Suppressing these as they are a red herring.

Scope

Wrap Android APIs known to throw DeadSystemException in helper functions to handle this exception. This includes; getApplicationInfo, getPackageInfo, and isHuaweiMobileServicesAvailable (seems to use getPackageInfo under its hood).

What is a DeadSystemException

From Android's docs:

The core Android system has died and is going through a runtime restart. All running apps will be promptly killed.

Also from Android's source code:

 * Exception thrown when a call into system_server resulted in a
 * DeadObjectException, meaning that the system_server has died or
 * experienced a low-level binder error.  There's nothing apps can
 * do at this point - the system will automatically restart - so
 * there's no point in catching this.

Since this exception is not the fault of the app (or SDK) there isn't anything the app (or SDK) can do to recover from such a state. Catching and ignoring these won't improve the end-user experience since the app is already being killed, however doing so will clean up the noise from crash statistics, hopefully allowing the developer to discover the root cause.

Testing

Unit testing

Manual testing

Tested with an Android 14 emulator, device subscribes and receives notifications. Also ensured disabling badges works. Also on a Android 6.0 emulator, ensuring the notification title defaults to the app label correctly.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
  • Some tests are failing on main already.
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is