Skip to content

feat: [SDK-4728] support disabling location module#1953

Open
fadi-george wants to merge 1 commit into
mainfrom
fadi/sdk-4728-disable-location-module
Open

feat: [SDK-4728] support disabling location module#1953
fadi-george wants to merge 1 commit into
mainfrom
fadi/sdk-4728-disable-location-module

Conversation

@fadi-george

Copy link
Copy Markdown
Collaborator

Description

One Line Summary

Adds build-time flags to exclude the native OneSignal location module from React Native apps.

Details

Motivation

Apps that do not use OneSignal.Location should be able to avoid linking native location dependencies so iOS and Android builds do not include location-specific modules or permissions.

Scope

This PR adds the core SDK support only:

  • iOS: $OneSignalDisableLocation = true switches CocoaPods from the aggregate OneSignalXCFramework pod to non-location subspecs.
  • Android: OneSignal_disableLocation=true switches Gradle from the aggregate com.onesignal:OneSignal module to non-location modules.
  • Android location bridge calls catch the missing-module path and degrade without crashing.
  • README documents the native flags for consumers.

The runnable no-location demo is intentionally split into the follow-up stacked PR.

Testing

Unit testing

No unit tests were added. This change adjusts native dependency selection and bridge handling, which is covered by manual app build/runtime checks in the stacked demo PR.

Manual testing

  • Verified the stacked no-location demo builds and launches on iOS and Android with these flags enabled.
  • Verified iOS Pod resolution excludes OneSignalLocation in the stacked demo.
  • Verified Android logs report the expected missing location module message when invoking OneSignal.Location without the location dependency.

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

Made with Cursor

@fadi-george fadi-george requested a review from a team as a code owner June 9, 2026 02:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant