[abdulraqeeb33]

Description

One Line Summary

Composite login is no longer a public method, so 5.11.0 cannot ship login(externalId, profile) while the remaining bugs are still open.

Details

Fixes SDK-5616. Stacked on #2816, which is stacked on #2815.

Motivation

login(externalId, profile) is public on main. SDK-5606 and SDK-5615 are still open, and the rest of the fix will take longer than this release.

Scope

The profile overload is removed from OneSignal and IOneSignal. login(externalId) and loginSuspend are unchanged.

The implementation stays on OneSignalImp, which is outside the public API dump, so the fixes above can keep calling it. The demo app no longer has the "Login with profile" button.

OneSignalUserProfile and LoginData stay public types. Nothing public accepts or returns them.

Testing

Unit testing

OneSignalSuspendMethodsExistTest now asserts the profile login is absent from OneSignal. The composite login tests still call the method on OneSignalImp.

Manual testing

Not run on a device. This removes a public method and a demo button. It does not change the identity-only login path.

Affected code checklist

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

Made with Cursor

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• IOneSignal.kt: 1/7 touched executable lines (14.3%) (all lines — could not resolve diff)
  • 6 uncovered touched lines in this file
• OneSignal.kt: 3/56 touched executable lines (5.4%) (all lines — could not resolve diff)
  • 53 uncovered touched lines in this file
• OneSignalResult.kt: 1/1 touched executable lines (100.0%) (3 touched lines in diff)
• OneSignalResultData.kt: 1/1 touched executable lines (100.0%) (2 touched lines in diff)
• OneSignalUserProfile.kt: 1/1 touched executable lines (100.0%) (7 touched lines in diff)
• OneSignalImp.kt: 2/2 touched executable lines (100.0%) (2 touched lines in diff)
• LoginUserOperation.kt: 1/1 touched executable lines (100.0%) (1 touched lines in diff)

Overall (aggregate gate)

10/69 touched executable lines covered (14.5% — requires ≥ 80%)

Per-file detail (informational; gate is aggregate above):

• IOneSignal.kt: 14.3% (6 uncovered touched lines)

• OneSignal.kt: 5.4% (53 uncovered touched lines)

❌ Coverage Check Failed

Aggregate coverage on touched lines is 14.5% (minimum 80%).

📥 View workflow run

[fadi-george]

Consider:

• Possibly blocking: OneSignalUserProfile.kt:12, OneSignalResultData.kt:27, core.api: OneSignalUserProfile, LoginData and OneSignalResult still ship as public in 5.11.0 with nothing public using them, so their shape gets frozen before SDK-5606/5615 land. Since main is unreleased, could we make them internal (or opt-in) for now? The profile KDoc also still says it's applied at login.
• Non-blocking: OneSignalSuspendMethodsExistTest.kt:160, also assert the profile overload is absent from IOneSignal::class, not just OneSignal.
• Nit: OneSignalResult.kt:26, the Kotlin KDoc example uses result without declaring it. Drop it until a public API returns OneSignalResult.
• Nit: OneSignalImp.kt:854, consider marking the profile login overload internal so Java can't reach it.

[abdulraqeeb33]

Done in d60006c.

1. OneSignalUserProfile, LoginData, and OneSignalResult are internal, and dropped from core.api.
2. Profile and result KDoc no longer describe them as public login API.

[fadi-george]

Click preview stack at the top

[fadi-george]

Thanks, heres some more findings

• Possibly blocking: OneSignalError.kt, OneSignalResultData.kt, core.api: ErrorCode, ErrorSource, OneSignalError, OneSignalResultData, InitData, LogoutData and UpdateUserJwtData are still public and unreleased, but nothing public uses them now. Should they go internal too, unless something else in 5.11.0 needs them?
• Non-blocking: the coverage gate fails because it counts all of OneSignal.kt and IOneSignal.kt ("could not resolve diff") for deletion-only changes. Probably needs an override. Detekt failures look inherited from fix: [SDK-5615] merge the anonymous user on composite login #2816.
• Nit: OneSignalSuspendMethodsExistTest.kt:160, also check IOneSignal::class.
• Nit: OneSignalImp.kt:854, mark the profile login overload internal.

[abdulraqeeb33]

Closing this. The product wants composite login to ship with the enabled=false option, so a customer can collect the email unsubscribed when the user has not consented to marketing email.

If the backend team does not change Create User, we can discuss other options before releasing this on the other SDKs. Hiding the public method is not the path for now.