feat: Add Kotlin MainApplication and suspend initialization support #2374

abdulraqeeb33 · 2025-10-01T21:22:15Z

Create MainApplicationKT.kt as Kotlin version of MainApplication.java
Add initWithContextSuspend() method for async initialization
Refactor OneSignalImp to use IO dispatcher internally for initialization
Add comprehensive unit tests for suspend initialization
Rename LatchAwaiter to CompletionAwaiter for better semantics and unify suspend and blocking thread notification
Add helper classes for user management (AppIdHelper, LoginHelper, LogoutHelper, UserSwitcher)
Ensure ANR prevention by using background threads for initialization

Description

One Line Summary

Modernizing the SDK to use Kotlin Coroutines

Details

Motivation

Convert MainApplication from Java to Kotlin with modern async handling using coroutines, add suspend methods to OneSignal SDK for better ANR prevention, and deprecate the Java implementation to encourage migration to the improved Kotlin version.

Scope

SDK Initialization
Added new public APIs

Testing

Unit testing

Added a bunch of tests

Manual testing

Tested happy path

Affected code checklist

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

- Add MainApplicationKT.kt as Kotlin version of MainApplication.java - Add initWithContextSuspend() method for async initialization - Refactor OneSignalImp to use IO dispatcher internally for initialization - Add comprehensive unit tests for suspend initialization - Rename LatchAwaiter to CompletionAwaiter for better semantics - Add helper classes for user management (AppIdHelper, LoginHelper, LogoutHelper, UserSwitcher) - Update build.gradle to include Kotlin coroutines dependency - Ensure ANR prevention by using background threads for initialization

abdulraqeeb33 · 2025-10-02T20:44:38Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/core/internal/startup/StartupService.kt

+    @OptIn(DelicateCoroutinesApi::class)
    fun scheduleStart() {
-        Thread {
+        GlobalScope.launch(Dispatchers.Default) {


Creating a thread is very expensive. Google promotes usages of Dispatcher

https://kotlinlang.org/docs/coroutines-basics.html#coroutines-are-light-weight

abdulraqeeb33 · 2025-10-02T20:48:23Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/internal/OneSignalImp.kt

+    }.build()
+
+    // get the current config model, if there is one
+    private val configModel: ConfigModel by lazy { services.getService<ConfigModelStore>().model }


earlier it was a var and we could probably run into race conditions.
lazy is thread safe and handles concurrent access automatically.
and most importantly its null safe and we dont need to use !! anymore.

abdulraqeeb33 · 2025-10-02T20:51:23Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/internal/OneSignalImp.kt

+    private val logoutLock: Any = Any()
+    private val userSwitcher by lazy {
+        val appContext = services.getService<IApplicationService>().appContext
+        UserSwitcher(


the class is broken down significantly into all these subclasses to address seperation of concern and improve testability

abdulraqeeb33 · 2025-10-02T20:52:41Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/internal/OneSignalImp.kt

        jwtBearerToken: String?,
    ) {
-        Logging.log(LogLevel.DEBUG, "login(externalId: $externalId, jwtBearerToken: $jwtBearerToken)")
+        Logging.log(LogLevel.DEBUG, "Calling deprecated login(externalId: $externalId, jwtBearerToken: $jwtBearerToken)")


Logging deprecate calls so that someday we can get an estimate its usage and plan on its removal.

abdulraqeeb33 · 2025-10-02T20:53:07Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/internal/OneSignalImp.kt

+            if (AndroidUtils.isRunningOnMainThread()) {
+                Logging.warn("This is called on main thread. This is not recommended.")
+            }
+        } catch (e: RuntimeException) {


The exception catch here is for mostly testing

abdulraqeeb33 · 2025-10-02T23:34:51Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/IOneSignal.kt

+     */
+    suspend fun login(
+        context: Context,
+        appId: String,


I see a bunch of crashes where login is called before initializing the SDK.

Is it ok to just accept the appId and context here and initialize the SDK (if its not done already) and continuing with the login process? It shouldn't be very hard for the consumer to pass the AppId IMHO.

Does it impact anything else?

Thinking about this as a consumer of this SDK, having both initialize and login with appId raises questions;

Does it matter if which one I pass appId to?

Is one better than the other?, which one is preferred?

Does this means login is designed to move the User to a different OneSignal app?

As far as internals of the SDK goes, it doesn't matter, but you see the confusion this would add to the public API.

abdulraqeeb33 · 2025-10-02T23:35:00Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/IOneSignal.kt

+     */
+    suspend fun logout(
+        context: Context,
+        appId: String,


same with logout.

jkasten2 · 2025-10-03T19:22:18Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/IOneSignal.kt

+    @Deprecated(message = "Use suspend version", ReplaceWith("suspend fun logout()"))
    fun logout()


There isn't a return value, so it is valid to call it and not wait. What do you think about keeping both for these cases?

AR Abdul Azeez added 6 commits October 1, 2025 16:19

Added more tests

ad2197c

mandating passing app id in the login/logout methods

533bb44

linting

f7c4496

Made app id mandatory for login and logout.

1ebe5af

cleanup

d936022

abdulraqeeb33 marked this pull request as ready for review October 3, 2025 00:08

abdulraqeeb33 commented Oct 3, 2025

View reviewed changes

reduce the forks

a35c578

jkasten2 reviewed Oct 3, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: Add Kotlin MainApplication and suspend initialization support #2374

feat: Add Kotlin MainApplication and suspend initialization support #2374

Uh oh!

abdulraqeeb33 commented Oct 1, 2025 •

edited

Loading

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

jkasten2 Oct 3, 2025

Uh oh!

abdulraqeeb33 Oct 2, 2025

Uh oh!

jkasten2 Oct 3, 2025

Uh oh!

Uh oh!

		@Deprecated(message = "Use suspend version", ReplaceWith("suspend fun logout()"))
		fun logout()

feat: Add Kotlin MainApplication and suspend initialization support #2374

Are you sure you want to change the base?

feat: Add Kotlin MainApplication and suspend initialization support #2374

Uh oh!

Conversation

abdulraqeeb33 commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

One Line Summary

Details

Motivation

Scope

Testing

Unit testing

Manual testing

Affected code checklist

Checklist

Overview

Testing

Final pass

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

abdulraqeeb33 commented Oct 1, 2025 •

edited

Loading