fix: [SDK-4193] suppress unchecked cast warnings in Android bridge

[fadi-george]

Description

One Line Summary

Add @SuppressWarnings("unchecked") to 7 methods in the Android Java bridge to eliminate unchecked cast compiler warnings.

Details

Motivation

Fixes GitHub issue #1122. Users with -Xlint:unchecked enabled in their Gradle config see 7 unchecked cast warnings when compiling the plugin. These casts are safe because Flutter's StandardMessageCodec guarantees the types from the Dart side, and most are already guarded by ClassCastException try-catch blocks.

Scope

Only affects Android Java bridge layer. No behavioral changes — warnings are suppressed, not the casts themselves.

Affected methods:

• OneSignalNotifications.getJsonFromMap() — Object → Map<String, Object>
• OneSignalUser.addAliases() — call.arguments → Map<String, String>
• OneSignalUser.removeAliases() — call.arguments → List<String>
• OneSignalUser.addTags() — call.arguments → Map<String, String>
• OneSignalUser.removeTags() — call.arguments → List<String>
• OneSignalInAppMessages.addTriggers() — call.arguments → Map<String, String>
• OneSignalInAppMessages.removeTriggers() — call.arguments → Collection<String>

Also removed redundant comments that just restated what the code does.

Testing

Manual testing

Reproduced the 7 warnings by temporarily adding -Xlint:unchecked to the plugin's build.gradle and running ./gradlew :onesignal_flutter:compileDebugJavaWithJavac from the example app. After applying the fix, all 7 warnings are resolved.

Affected code checklist

• Notifications
• In-App Messaging

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

In general, the fix is to add an explicit permissions block that grants only the minimum GITHUB_TOKEN scopes required for this workflow. Because this workflow only triggers on releases and passes github.event.release.body into a reusable workflow, the calling workflow itself does not appear to need any write permissions. A safe and minimal default is to set contents: read at the workflow level, which is equivalent to a read‑only GITHUB_TOKEN for repo contents. The reusable workflow can still request additional permissions if it truly needs them.

Concretely, in .github/workflows/linear-deployed.yml, add a permissions: block near the top level, alongside name: and on: (or immediately after name:). Set contents: read, which is the typical baseline for workflows that only need to read repository data. No imports or external dependencies are needed, since this is pure YAML configuration. Existing behavior of the workflow will remain the same in normal cases, except that unintended write capabilities via GITHUB_TOKEN will be removed unless explicitly re‑granted.