[$250] [Sentry: APP-8MB] HybridApp Android Urban Airship PreferenceCenterActivity crash

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-8MB

Impact (snapshot at filing)

• Users (total since first seen): 71
• Events: 76
• Users (last 7d): 32
• Events (last 7d): 32
• First seen: 2026-03-28
• Last seen: 2026-07-02 (ongoing)
• Platform: Android HybridApp
• App version(s): 9.4.23
• Affected route(s): Urban Airship preference center deep link
• Mechanism: chained (RuntimeException → IllegalArgumentException)

Stack trace (top frames, first-party only)

PreferenceCenterActivity.onCreate (Urban Airship SDK)
IllegalArgumentException: Missing required extra: EXTRA_ID

Suspected cause

HybridApp launches Urban Airship PreferenceCenterActivity without the required EXTRA_ID intent extra, causing a fatal crash on Android.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072671127625859634
• Upwork Job ID: 2072671127625859634
• Last Price Increase: 2026-07-30

Issue Owner

Current Issue Owner: @QichenZhu

[lorretheboy]

Proposal

What is the root cause of that problem?

The Airship React Native plugin unconditionally bundles the Preference Center module, so the SDK's PreferenceCenterActivity ships inside the Android HybridApp even though nothing in this repo ever configures or opens a preference center (there are zero references to it in src/ or android/):

App/package.json

Line 133 in a9e6aed

"@ua/react-native-airship": "26.5.0",

App/ios/Podfile.lock

Lines 18 to 20 in a9e6aed

	- Airship/PreferenceCenter (20.7.0):
	- Airship/Core
	- AirshipFrameworkProxy (15.8.0):

In the HybridApp that one Airship instance is shared with OldDot:

App/src/libs/Notification/PushNotification/index.native.ts

Lines 83 to 87 in a9e6aed

	// In the HybridApp, the contact identity is set on the YAPL side after sign-in.
	// Since the Airship instance is shared between NewDot and OldDot,
	// NewDot users won't see the push notification permission prompt as we return early in this case.
	// Therefore, we cannot handle the HybridApp scenario here.
	if (!CONFIG.IS_HYBRID_APP && userID === notificationID.toString()) {

When an "open preference center" request hits that shared instance (the uairship://preferences deep link attached to marketing pushes / the OldDot notification-preferences flow), the activity gets started without a preference-center ID: the SDK's own launcher (PreferenceCenter.open(id)) always sets EXTRA_ID, so a launch missing it means the ID was null/absent at the call site (a null passes unchecked from Java into the Kotlin parameter, and putExtra(EXTRA_ID, null) makes getStringExtra return null). PreferenceCenterActivity.onCreate does requireNotNull(intent.getStringExtra(EXTRA_ID)), so it throws IllegalArgumentException: Missing required extra: EXTRA_ID before rendering — Android wraps that in the fatal RuntimeException ("Unable to start activity") seen in Sentry. Our notification layer never handles any preference-center event — it only registers PushReceived and NotificationResponse — so nothing on our side can catch or recover from this:

App/src/libs/Notification/PushNotification/index.native.ts

Lines 65 to 74 in a9e6aed

	const init: Init = () => {
	// Setup event listeners
	Airship.addListener(EventType.PushReceived, (notification) => pushNotificationEventCallback(EventType.PushReceived, notification.pushPayload));
	// Note: the NotificationResponse event has a nested PushReceived event,
	// so event.notification refers to the same thing as notification above ^
	Airship.addListener(EventType.NotificationResponse, (event) => pushNotificationEventCallback(EventType.NotificationResponse, event.pushPayload));
	ForegroundNotifications.configureForegroundNotifications();
	};

In short: an unused-but-bundled SDK activity hard-requires an ID that the HybridApp launch path never supplies.

What changes do you think we should make in order to solve the problem?

Stop the SDK's built-in UI from ever launching, at the single point where we initialize Airship. In init(), next to the existing listeners, add:

Airship.preferenceCenter.setAutoLaunchDefaultPreferenceCenter(false);

App/src/libs/Notification/PushNotification/index.native.ts

Lines 65 to 74 in a9e6aed

	const init: Init = () => {
	// Setup event listeners
	Airship.addListener(EventType.PushReceived, (notification) => pushNotificationEventCallback(EventType.PushReceived, notification.pushPayload));
	// Note: the NotificationResponse event has a nested PushReceived event,
	// so event.notification refers to the same thing as notification above ^
	Airship.addListener(EventType.NotificationResponse, (event) => pushNotificationEventCallback(EventType.NotificationResponse, event.pushPayload));
	ForegroundNotifications.configureForegroundNotifications();
	};

The setting is persisted in the Airship proxy store and applies to the shared HybridApp instance, so any preference-center open request (deep link, push action, OldDot) is converted into a DisplayPreferenceCenter JS event we simply don't subscribe to, instead of starting the crashing activity. Since we never configure a preference center, this loses no functionality.

The Mobile-Expensify half: the OldDot call site that triggers the preference center should pass the configured preference-center ID (or early-return with a log when it's empty) so the activity is never asked to start without one.

What alternative solutions did you explore? (Optional)

Strip the unused activity from the merged manifest with <activity android:name="com.urbanairship.preferencecenter.ui.PreferenceCenterActivity" tools:node="remove"/> (here and in the Mobile-Expensify manifest). It removes the crash surface entirely, but turns a stray launch into an ActivityNotFoundException risk and needs the change duplicated in two repos, so disabling auto-launch is safer and smaller. Upgrading @ua/react-native-airship once upstream handles a missing EXTRA_ID gracefully would also resolve it, but with no control over timing.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @QichenZhu (External)

[KJ21-ENG]

Proposal

What is the root cause of that problem?

Android includes Airship through @ua/react-native-airship, and the app registers an Airship extender during SDK initialization.

App/package.json

Lines 129 to 133 in a9e6aed

	"@sentry/core": "10.39.0",
	"@sentry/react-native": "8.2.0",
	"@shopify/flash-list": "2.3.0",
	"@shopify/react-native-skia": "^2.4.14",
	"@ua/react-native-airship": "26.5.0",

App/android/app/src/main/AndroidManifest.xml

Lines 176 to 178 in a9e6aed

	<meta-data
	android:name="com.urbanairship.plugin.extender"
	android:value="com.expensify.chat.customairshipextender.CustomAirshipExtender" />

That extender only replaces the push notification provider. It does not intercept Airship Preference Center display requests before Airship falls back to its default PreferenceCenterActivity, so a HybridApp preference-center action/deep link that arrives without a valid preference-center id can reach the SDK activity and crash with IllegalArgumentException: Missing required extra: EXTRA_ID.

App/android/app/src/main/java/com/expensify/chat/customairshipextender/CustomAirshipExtender.java

Lines 11 to 15 in a9e6aed

	public void onAirshipReady(@NonNull Context context) {
	PushManager pushManager = Airship.getPush();
	CustomNotificationProvider notificationProvider = new CustomNotificationProvider(context, Airship.getAirshipConfigOptions());
	pushManager.setNotificationProvider(notificationProvider);

HybridApp also overrides the normal React Native initial URL path, while Android still advertises new-expensify:// as the custom URI handler used for Urban Airship deep links. That leaves Airship Preference Center display handling outside the normal NewDot route validation path.

App/src/setup/hybridApp/index.native.ts

Lines 5 to 9 in a9e6aed

	if (CONFIG.IS_HYBRID_APP) {
	// On HybridApp we need to shadow official implementation of Linking.getInitialURL on NewDot side with our custom implementation.
	// Main benefit from this approach is that our deeplink-related code can be implemented the same way for both standalone NewDot and HybridApp.
	// It's not possible to use the official implementation from the Linking module because the way OldDot handles deeplinks is significantly different from a standard React Native app.
	Linking.getInitialURL = () => HybridAppModule.getInitialURL();

App/android/app/src/main/AndroidManifest.xml

Lines 55 to 63 in a9e6aed

	<!-- Custom URI handlers. Used to intercept Urban Airship deep links. -->
	<intent-filter android:autoVerify="true">
	<action android:name="android.intent.action.VIEW" />
	<category android:name="android.intent.category.DEFAULT" />
	<category android:name="android.intent.category.BROWSABLE" />
	<data android:scheme="new-expensify" />
	</intent-filter>

What changes do you think we should make in order to solve the problem?

In CustomAirshipExtender.onAirshipReady, register a Preference Center open listener before returning. The listener should validate the incoming preferenceCenterId and return true for missing, blank, or unsupported ids so Airship does not launch the default Preference Center UI from malformed display requests.

For a known supported preference-center id, either route through the app-owned deep link/custom UI path or return false to allow Airship's default handling only after the id is known to be valid. The existing Android intent handling is too late for this crash because it only runs after MainActivity receives an intent, while this crash happens inside Airship's activity creation path.

App/android/app/src/main/java/com/expensify/chat/MainActivity.kt

Lines 63 to 84 in a9e6aed

	if (intent != null) {
	handleIntent(intent)
	}
	}
	override fun onNewIntent(intent: Intent) {
	super.onNewIntent(intent)
	if (intent.hasCategory(Intent.CATEGORY_LAUNCHER)
	&& intent.getAction() != null
	&& intent.getAction().equals(Intent.ACTION_MAIN)) {
	wasAppRelaunchedFromIcon = true
	}
	setIntent(intent) // Must store the new intent unless getIntent() will return the old one
	handleIntent(intent)
	}
	private fun handleIntent(intent: Intent) {
	try {
	val intenthandler = IntentHandlerFactory.getIntentHandler(this, intent.type, intent.toString())
	intenthandler?.handle(intent)

Test coverage:

• Add an Android unit/Robolectric test around the Airship extender preference-center open listener verifying malformed or unsupported ids are consumed and do not start the SDK activity.
• Add a positive test for a supported preference-center id so the intended app routing or default Airship handling still works.
• Manually verify the Android HybridApp Urban Airship preference-center action/deep link no longer crashes, and that normal report push notification deep links still route through new-expensify://.

What alternative solutions did you explore? (Optional)

We could try to catch this in MainActivity, but that is too late because the failing stack is in Airship's PreferenceCenterActivity.onCreate. We could also remove the Preference Center module entirely, but guarding display requests at the Airship extension point is narrower and preserves any valid Preference Center behavior.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022072671127625859634

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android HybridApp, opening a push notification (or handling an Airship deep-link) that triggers Urban Airship's PreferenceCenterActivity crashes the app with IllegalArgumentException: Missing required extra: EXTRA_ID because the activity is launched without the required com.urbanairship.preference_center_id intent extra. Expected behavior: the notification/deep-link should either open a valid preference center screen or be handled gracefully (routed to the app's own settings) without crashing.

What is the root cause of that problem?

The app registers CustomAirshipExtender (android/app/src/main/java/com/expensify/chat/customairshipextender/CustomAirshipExtender.java:9-16) via the com.urbanairship.plugin.extender meta-data in android/app/src/main/AndroidManifest.xml:176-178, but onAirshipReady only configures a CustomNotificationProvider — it never installs a PreferenceCenter.OnOpenListener and never overrides the default open_preference_center_action. When an Airship-side campaign/deep-link fires a preference_center action, the Airship SDK falls back to launching its stock PreferenceCenterActivity via an Intent with no EXTRA_ID (because the payload doesn't include one, or the extras are stripped by the app's MainActivity singleTask deep-link interception at AndroidManifest.xml:41-63), which causes the crash in the SDK's onCreate. The consumer of the missing extra is Airship's own PreferenceCenterActivity.onCreate; the producer is the un-guarded Airship action dispatch — the app never provides an OnOpenListener to intercept it.

What changes do you think we should make in order to solve the problem?

1. In android/app/src/main/java/com/expensify/chat/customairshipextender/CustomAirshipExtender.java:11 onAirshipReady, register PreferenceCenter.shared().setOpenListener(...) returning true so the SDK skips its default activity launch, and either route to the app's in-app settings screen or no-op when the id is null/empty.
2. Alternatively, override the open_preference_center_action in the Airship action registry inside the same onAirshipReady to a custom action that validates presence of the preference-center id before dispatch and drops the action silently when missing.
3. Add a defensive check on the launched intent: if unavoidable, register an Application.ActivityLifecycleCallbacks in MainApplication.onCreate that intercepts PreferenceCenterActivity instantiation and finishes it when EXTRA_ID (com.urbanairship.preference_center_id) is absent, preventing the SDK crash.
4. Log the offending payload via Airship's AutopilotListener/deep-link listener so we can identify which campaign is emitting malformed preference-center actions and correct it server-side.

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @aswin-s Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.