[abdulraqeeb33]

Description

One Line Summary

Catch and log the IllegalStateException native Android throws for calls made before Initialize, instead of letting it crash the app.

Details

Motivation

Native Android throws IllegalStateException ("Must call 'initWithContext' before ...") from login, logout, and the User, Session, Notifications, InAppMessages, and Location getters when init has not started. The wrapper passed that to the app, so OneSignal.Login and similar crashed unless the app caught it.

SDK-5334 made this easier to hit: Initialize("") returns before InitWithContext, so a later valid Login throws. Native Android would have initialized with an empty app id. iOS already logs and returns before init.

Fixes SDK-5366.

Scope

• New NativeCall helper (Run / Get) wraps the native calls that go through waitForInit. It catches only Java.Lang.IllegalStateException, logs "<api> ignored: <native message>" at error level to logcat, and returns false, null, or the given fallback. Any other exception still reaches the app.
• Wrapped: Login, Logout, and the user, push subscription, session, notifications, and in-app messages calls.
• Observer registration in Initialize is wrapped too, one call per manager. InitWithContext returns while native init is still running, and registration waits for it, so a failed init (for example a locked device in direct boot) used to throw out of Initialize.
• Not wrapped: Debug and the consent setters (native accepts both before init). AndroidLocationManager is unchanged; it already catches.
• Native stays the only source of init state. The wrapper keeps no init flag, so calls native would accept are never skipped.
• Every InputGuard rejection (empty app id, empty login, missing tag key, and the rest) writes the debug console line and, on Android, the same message to logcat. Initialize uses the guard again.

Behavior change

A failed init after a real Initialize("appId") no longer throws from later calls. It shows up as a logcat error carrying native's message (OneSignal initWithContext failed.). This matches iOS, which logs and returns.

Known gaps

• Before init, Notifications.Permission, PushSubscription.OptedIn, and RequestPermissionAsync return false, which a caller cannot tell from a real denial. PermissionNative() returns NotDetermined.
• Writes made before init are dropped, not replayed. PushSubscription.OptOut() and InAppMessages.Paused = true are the risky ones: the app's intent is lost and only logcat shows it.
• The catch is by type, so an IllegalStateException native throws for a reason other than init is also logged and dropped.
• AndroidLocationManager catches Exception (existing behavior), so an init error there is logged as a missing location module.

Testing

Unit testing

None. This repo has no .NET test project.

Manual testing

dotnet build of OneSignalSDK.DotNet.Android passes with no warnings. Not exercised on a device yet.

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
• 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

[fadi-george]

This is for cases like
initialize('') followed by login('...')?
This breaks consistency with other sdks. I'd maybe make a thread on this that is if we should really handle this edge case.