improvement: Offloaded work on background threads.

[abdulraqeeb33]

Description

One Line Summary

Move slow/IO-bound parts of initWithContext off the main thread and add an async overload with a completion callback for internal usage. Added new suspend methods.

Motivation

Avoid main-thread stalls and potential ANRs during initialization, especially when SharedPreferences or other disk/network operations are involved. Provide an async path so app components (Activities/Receivers) can trigger initialization without blocking UI or risking Receiver timeouts.

Scope

• initWithContext(context, appId): now move all initialization to background and return immediately.
• initWithContext(context) is now suspend and can only be called from a coroutine. This method should used by internal classes only. It will remain suspend until all initialization is completed.
• Accessors remain blocked if called immediately after initWithContext and before initialization is fully completed. This is to ensure no breaking change or expectation on existing consumer use cases.
• Receivers will now call initWithContext(contex) in background, and switch back to main on tasks that must be executed in main thread, eg, finish(), startActivity() and other app lifecycle or UI operations.
• Workers run doWork() in background will now directly call initWithContext(contex)
• Retain the existing synchronous overload for backward compatibility; the new overload provides a non-blocking path with a completion callback.
• Introduces a centralized ANR timeout constant.
• No behavioral change to notification delivery formats, APIs, or user-visible features.

OPTIONAL - Other

OPTIONAL - Feel free to add any other sections or sub-sections that can explain your PR better.

Testing

Unit testing

• New Robolectric/Kotest tests cover initWithContext in different scenarios. Ex:
  • Accessors throw before initialization.
  • Init does not block even when SharedPreferences access is artificially delayed.
  • Tags, local onesignalId, push subscription, and immediate login right after init.
• LatchAwaiterTests testing the genetic functionalities of the waiter.

Manual testing

• Cold-start the sample app with logging at VERBOSE. Ensure all initial operations are created in the same order.
• Trigger init from an Activity and verify UI remains responsive.
• For Receivers: simulate a boot or FCM broadcast; verify the receiver returns promptly (no >10s wait), and OneSignal completes initialization shortly after.
• Notification click when app is killed / backgrounded.
• Login, logout, addTag, addTrigger, permission update, IAM interaction
• Environment: Android Studio Hedgehog or later; Pixel 6 emulator API 33; fresh install of the demo app.

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