[SDK-758] Report a failed pre-init switch the same way iOS does

[joaodordio]

📝 Summary

A failed switchProject before init now reports SWITCHED_WITH_WARNINGS, matching iOS. Success stays SWITCHED_CLEANLY.

🎟️ Jira Ticket: SDK-758

📖 Description

switchProject before initialization always reported SWITCHED_CLEANLY, even when initialization failed. iOS already reports .switchedWithWarnings when start() fails.

Android now forwards whether initializeInBackground succeeded. A successful cold start is still SWITCHED_CLEANLY. A timeout or an exception is SWITCHED_WITH_WARNINGS. The SDK is still left pointed at the requested project.

IterableInitializationCallback is unchanged. It still only means initialization finished. The success flag is an internal listener, because adding an argument to the public callback would break every app that implements it.

The two failure signals are not the same event. On iOS, failure is start() returning false, usually the first in-app sync. On Android, initialize() does not fail when in-app sync fails. The signal forwarded here is the one initializeInBackground already had: timeout or exception. Reasoning is on the Jira ticket.

Targets feature/SDK-673-switch-project. Independent of SDK-757. iOS: Iterable/iterable-swift-sdk#1094

🧪 How to test?

./gradlew :iterableapi:testDebugUnitTest --tests com.iterable.iterableapi.IterableSwitchProjectTest.testSwitchBeforeInitializeBehavesAsInitialize --tests com.iterable.iterableapi.IterableSwitchProjectTest.testSwitchBeforeInitializeReportsWarningsWhenInitializationFails

The first test is the successful cold start. The second forces the next background initialization to fail and expects SWITCHED_WITH_WARNINGS.

🧾 Changelog

Updated the unreleased switchProject entry. The note that Android cannot distinguish a failed initialization is removed. A failed or timed-out cold start now reports SWITCHED_WITH_WARNINGS.

📹 Loom recording if applicable

N/A

🐞 Github Issues solved

None

📚 Docs PR if applicable

No docs PR. switchProject is not in iterable-docs yet. That write-up is SDK-676, and this result contract is noted there.

[rtlsilva]

Approved with 1 non-blocking documentation-contract finding.

[rtlsilva]

This new failure meaning conflicts with the rest of the public callback contract.

IterableProjectSwitchResult, IterableProjectSwitchCallback, and the @param below still say warnings only describe teardown/cleanup, neither result is a failure, and the SDK is running on the new project.

An initialization exception can occur before IterableApi.initialize runs - as the new test demonstrates - so those guarantees are no longer true.

Suggest updating all public Javadocs to cover this case and state what callers can safely assume or do after it.