Prevent ANRs when backgrounding app

[jkasten2]

Description

One Line Summary

Prevent ANRs when app is backgrounded due to some disk I/O with session logic and AndroidX Worker usage.

Details

Motivation

The time spent on the main thread in this scenario is significantly contributing to ANRs. The Google Play store penalizes apps with ANRs with lower search rankings and possibly some other negatives.

Scope

Simply move code to a new background thread. No logic changes. Longer term in the 5.0.0 release we can use a thread pool or Kotlin suspend instead.

Full Details

Move calls to methods that do disk I/O from the main thread to a new background thread.

There are reports where this can cause a significant amount of time on main thread. Any disk I/O is a risk on the main thread and should not be done as there is no upper bond of how long it can take. ANRs trigger after 5 seconds of the main thread being busy.

The stacktrace of reported ANRs confirm that appStopped then calls getSessionInfluences which can result in waiting on disk I/O. We have also seen stacktraces with scheduling a AndroidX worker so that was moved into this background thread as well. I isn't known if it does any disk I/O but it was significant enough to show up in some ANRs.

Testing

Unit testing

No unit testing changes.

Manual testing

Confirmed code still fires when the app is backgrounded on an Android 13 emulator.

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
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• 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
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[emawby]

LGTM!