[$250] GPS - Android - App crashes when tap on GPS live activity notification

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.75-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Mobile-Expensify/pull/13932
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

1. Open Hybrid app
2. Start a GPS live tracking session
3. Go back to Home
4. Background the app
5. Leave the phone for 1 - 2 minutes (Can lock the phone)
6. Open the phone
7. Tap on the Live tracking notification
8. Reapeat 4-7 for 2 - 3 times

Expected Result:

Live tracking session is opened

Actual Result:

App crashes

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

logs.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056275303670863490
• Upwork Job ID: 2056275303670863490
• Last Price Increase: 2026-05-18

[MelvinBot]

Proposal

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

On Android, starting a GPS live tracking session, then backgrounding the app for 1-2 minutes and tapping the GPS live tracking notification causes the app to crash. The crash becomes more likely after repeating the background/foreground cycle 2-3 times.

What is the root cause of that problem?

There are two contributing problems:

Primary: startService() called from a background context on Android 12+

GpsLiveUpdateHandler.kt:32 calls context.startService() (a regular service start) every time a LiveUpdate event fires. On Android 12+ (API 31+), starting a regular service from a background context throws IllegalStateException ("Not allowed to start service... app is in background"). After the app has been backgrounded for 1-2 minutes, Android classifies it as a background app, and the next Airship LiveUpdate callback triggers this crash. The app declares FOREGROUND_SERVICE_LOCATION permission in the manifest but GpsTripService never calls startForeground(), so it doesn't actually qualify as a foreground service.

Secondary: Race condition between notification deep link and GPSTripStateChecker

When the notification is tapped after backgrounding, two competing code paths fire:

1. The PendingIntent delivers a deep link to navigate to the GPS screen (with a reportID baked in at trip start time)
2. GPSTripStateChecker mounts and calls checkAndCleanGpsNotification() twice (once inside the async function at line 35, and once synchronously at line 46), then potentially shows a "Continue trip?" modal

If Android killed the JS process while backgrounded, the navigation ref and Onyx state may be partially initialized when the deep link fires, leading to null references downstream.

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

1. In GpsLiveUpdateHandler.kt: Replace context.startService() with context.startForegroundService(), and update GpsTripService to call startForeground() with a notification in onStartCommand(). Alternatively, wrap the startService() call in a try-catch to prevent the crash.

2. In GPSTripStateChecker/index.native.tsx: Remove the duplicate checkAndCleanGpsNotification() call on line 46 — it's already called inside handleGpsTripInProgressOnAppRestart() on line 35.

Supporting evidence

• The GpsTripService is declared with android:stopWithTask="false" in the manifest (line 35) and has no onStartCommand() override — it's a plain Service that only implements onTaskRemoved().
• The notification deep link uses a hardcoded OPTIMISTIC_TRANSACTION_ID and a reportID from trip start (index.android.ts:14), which can become stale after a process restart.
• The deep link guard in subscribe.ts:12-23 checks navigationRef.current?.getRootState(), but after a cold start this may be null, allowing the deep link through before navigation is ready.
• Related issue: [Due for payment 2026-06-09] [Due for payment 2026-06-08] [$250] Android - App crashes reopening while the GPS trip is in progress after discard tracking twice #88700 (Android crash reopening while GPS trip in progress after discarding tracking twice) — likely shares the same startService() root cause.

What alternative solutions did you explore? (Optional)

• Wrapping startService() in a try-catch: simpler but masks the underlying issue — the service should be a proper foreground service since it's associated with an ongoing GPS tracking operation.
• Using WorkManager instead of a plain Service: more robust but a larger change; the current GpsTripService is lightweight enough that converting to a foreground service is the right-sized fix.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

On Android Hybrid App, tapping the GPS live tracking notification after the app has been backgrounded/locked can crash the app instead of reopening the in-progress GPS distance request.

What is the root cause of that problem?

The GPS notification is implemented as an Android Airship LiveUpdate. Its native handler rebuilds the notification in GpsLiveUpdateHandler.onUpdate(), and for every non-END event it also starts GpsTripService:

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

Lines 24 to 33 in d8068e7

	if (event == LiveUpdateEvent.END) {
	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
	context.stopService(Intent(context, GpsTripService::class.java))
	}
	return LiveUpdateResult.cancel()
	}
	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
	context.startService(Intent(context, GpsTripService::class.java))
	}

That service is only a cleanup helper for task removal; it is not the user-visible GPS foreground service:

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

Lines 8 to 20 in d8068e7

	/**
	* Lightweight service that runs alongside the Airship LiveUpdate GPS notification.
	* Its sole purpose is to cancel the notification when the app is killed,
	* since Airship LiveUpdate notifications persist beyond the app process lifecycle.
	*/
	class GpsTripService : Service() {
	override fun onBind(intent: Intent?): IBinder? = null
	override fun onTaskRemoved(rootIntent: Intent?) {
	cancelGpsNotifications()
	stopSelf()
	super.onTaskRemoved(rootIntent)

When the app is backgrounded and the user taps the live tracking notification, Airship can restore/rebuild the LiveUpdate before the React Native activity is fully foregrounded. On modern Android versions, context.startService(...) from that state can throw IllegalStateException / ForegroundServiceStartNotAllowedException. The call is not guarded, so the native notification handler can take down the app before JS navigation gets a chance to open the GPS screen.

The deep link itself is the same GPS route used by the floating GPS button and GPSTripStateChecker, so the route target is not the main problem:

App/src/pages/iou/request/step/IOURequestStepDistanceGPS/GPSNotifications/index.android.ts

Lines 10 to 20 in d8068e7

	// eslint-disable-next-line @typescript-eslint/no-unused-vars
	function startGpsTripNotification(translate: LocalizedTranslate, reportID: string, unit: Unit, distanceInMeters?: number) {
	const title = translate('gps.notification.title');
	const body = translate('gps.notification.body');
	const deepLink = ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.getRoute(CONST.IOU.ACTION.CREATE, CONST.IOU.TYPE.CREATE, CONST.IOU.OPTIMISTIC_TRANSACTION_ID, reportID);
	Airship.android.liveUpdateManager
	.start({
	name: LIVE_UPDATE_NAME,
	type: LIVE_UPDATE_TYPE,
	content: {title, body, deepLink},

There is also a cleanup race on app startup: GPSTripStateChecker calls checkAndCleanGpsNotification() inside handleGpsTripInProgressOnAppRestart() and then calls it again immediately after starting that async function.

App/src/components/GPSTripStateChecker/index.native.tsx

Lines 34 to 47 in d8068e7

	async function handleGpsTripInProgressOnAppRestart() {
	await checkAndCleanGpsNotification();
	const gpsTrip = await OnyxUtils.get(ONYXKEYS.GPS_DRAFT_DETAILS);
	if (!gpsTrip?.isTracking) {
	return;
	}
	setShowContinueTripModal(true);
	}
	handleGpsTripInProgressOnAppRestart();
	checkAndCleanGpsNotification();

That cleanup happens after JS boots, so it is too late to prevent the native LiveUpdate handler crash, and the duplicate call can race two listAll()/end() passes against the same LiveUpdate.

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

Make the Android LiveUpdate path fail-safe and make GPS notification cleanup single-owner/idempotent:

1. In GpsLiveUpdateHandler.onUpdate(), do not allow the helper-service start to crash notification handling. Wrap context.startService(Intent(context, GpsTripService::class.java)) in a targeted try/catch for Android background-service start failures, log the failure, and still return the notification builder. Since GpsTripService only exists to clean up stale notifications on task removal, failing to start that helper should never block opening the app from the notification.

2. When GpsTripService.onTaskRemoved() runs, end the Airship LiveUpdate as well as canceling the Android notification. Right now it only cancels notifications from NotificationManager, which can leave Airship's stored gps_live_update to be restored/rebuilt later.

3. In GPSTripStateChecker, remove the second immediate checkAndCleanGpsNotification() call and make checkAndCleanGpsNotification() await/end the matching LiveUpdate once. This avoids racing two JS cleanup passes and keeps restart behavior deterministic.

4. Keep the existing GPS deep link route unchanged. The expected behavior is that notification taps launch or foreground MainActivity, React Navigation receives the distance-gps link, and the in-progress trip screen opens without crashing.

Test coverage should include an Android manual/regression pass:

• Start GPS tracking.
• Background/lock the app for 1-2 minutes.
• Tap the GPS live tracking notification.
• Repeat the background/tap cycle several times.
• Confirm the GPS screen opens and no native crash occurs.
• Also verify killing the task still removes/stops the stale GPS notification/LiveUpdate.

What alternative solutions did you explore? (Optional)

I considered changing the GPS route or notification pending intent request code, but the route is shared with other working GPS entry points and the crash point is native code that runs before JS navigation can recover. The safer fix is to make the Android Airship LiveUpdate handler robust when invoked from a background/not-yet-foreground app state.

Related issue #88700 is in the same Android GPS tracking/live-update area and should be rechecked before posting/assignment. At draft time, #90931 had no comments, while #88700 was still open with proposals around stale GPS/LiveUpdate/background-task cleanup.

[melvin-bot]

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

[Abdukhamid000]

Proposal

What is the root cause of that problem?

In GPSNotifications/index.android.ts (line 14), the deepLink value passed into Airship.android.liveUpdateManager.start() is a bare relative path (e.g. create/create/start/<transactionID>/<reportID>/distance-new/distance-gps) — it has no URL scheme prefix. When the user taps the live update notification, Android resolves the deepLink field in the notification content as an Intent URI. A schemeless URI cannot be dispatched as a valid Android Intent, so the OS fails to route it, crashing the app.

The 1-2 minute delay in repro is consistent with Android killing the background process while the notification persists — on first tap the app is still warm and the crash is less likely, but after the process dies the notification tap triggers a cold launch via a malformed Intent that the system cannot handle.

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

I think we should prepend CONST.DEEPLINK_BASE_URL ('new-expensify://') to the deepLink value before passing it to liveUpdateManager.start(). This turns the bare path into a fully-qualified URL (new-expensify://create/create/start/.../distance-gps) that Android can resolve to the correct registered activity via the app's custom URL scheme. The guard already in [linkingConfig/subscribe.ts](https://github.com/Expensify/App/blob/main/src/libs/Navigation/linkingConfig/subscribe.ts#L15-L23) checks for ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route ('distance-gps') anywhere in the URL string, so it will still match and suppress double-navigation correctly once the scheme is added.

What alternative solutions did you explore? (Optional)

I considered whether the root cause was a race condition in navigation hydration (the navigation state not being ready when the notification tap arrives), but that would affect both iOS and Android equally — and the issue specifically reproduces on Android. The missing URL scheme explains the Android-only crash.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @Abdukhamid000 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[mukhrr]

Proposal

What is the root cause of that problem?

The GPS live‑update notification deep‑links to …/distance-new/distance-gps, which mounts the Money_Request_Distance_Create modal stack containing the Mapbox‑backed DistanceMapView in IOURequestStepDistanceGPS.

The only guard against re‑processing that deep link lives in subscribe.ts, and it only short‑circuits when the GPS screen is the currently focused route:

App/src/libs/Navigation/linkingConfig/subscribe.ts

Lines 12 to 23 in 47fee90

	// Skip GPS distance screen deep links when the user is already on that screen.
	// This prevents a re-navigation with animation when tapping the GPS live update notification
	// while the GPS screen is already visible.
	if (url.includes(ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route)) {
	const state = navigationRef.current?.getRootState();
	if (state) {
	const currentRoute = findFocusedRoute(state);
	if (currentRoute?.name === ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route) {
	return;
	}
	}
	}

In the repro the user goes back Home before backgrounding, so the focused route is the report/Home screen — not distance-gps. findFocusedRoute(state)?.name is therefore never equal to ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route, the guard never returns early, and listener(url) re‑runs on every notification tap. Each tap pushes a fresh Money_Request_Distance_Create modal stack with its own live Mapbox DistanceMapView instance (the previously‑opened one is still mounted underneath). On Android, several concurrent Mapbox GL surfaces exhaust native memory, and after 2–3 taps the app crashes.

So the guard is too narrow: it deduplicates only the "GPS screen is visible" case, not the "GPS screen already exists somewhere in the stack" case that this notification flow actually produces.

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

Skip the deep link whenever a GPS distance screen already exists anywhere in the navigation state, not just when it is the focused route. Walk the (nested) navigation state instead of relying on findFocusedRoute:

+function isRouteInState(state: NavigationState | PartialState<NavigationState> | undefined, routeName: string): boolean {
+    if (!state?.routes) {
+        return false;
+    }
+    return state.routes.some((route) => route.name === routeName || isRouteInState(route.state, routeName));
+}
+
 const subscribe: LinkingOptions<RootNavigatorParamList>['subscribe'] = (listener) => {
     const subscription = Linking.addEventListener('url', ({url}: {url: string}) => {
-        // Skip GPS distance screen deep links when the user is already on that screen.
-        // This prevents a re-navigation with animation when tapping the GPS live update notification
-        // while the GPS screen is already visible.
+        // Skip GPS deep links when the GPS screen already exists anywhere in the stack.
+        // Re-processing it would push another DistanceCreate modal (and another Mapbox
+        // MapView); on Android these stack up and crash on repeated notification taps.
         if (url.includes(ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route)) {
-            const state = navigationRef.current?.getRootState();
-            if (state) {
-                const currentRoute = findFocusedRoute(state);
-                if (currentRoute?.name === ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route) {
-                    return;
-                }
-            }
+            const state = navigationRef.current?.getRootState();
+            if (isRouteInState(state, ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route)) {
+                return;
+            }
         }

This keeps the single GPS screen the user already opened (the notification's purpose is just to bring the user back to the in‑progress trip, and GPSTripStateChecker already restores trip state on resume) while preventing duplicate Mapbox‑backed modal stacks from accumulating. findFocusedRoute can be dropped from the imports.

What alternative solutions did you explore? (Optional)

• Dismiss the existing GPS modal before re‑navigating (e.g., Navigation.dismissModal() then forward the URL): works, but adds a visible dismiss/re‑open animation on every tap and is racier during the background→foreground transition than simply not re‑navigating.
• De‑duplicate at the Airship/native layer in Mobile‑Expensify (PR Update version to 1.2.47-0 on staging #13932) so a second tap re‑uses the existing task instead of emitting a new deep link. This is a valid complementary hardening, but the JS navigation guard is the App‑side regression and the minimal fix.

[github-actions]

⚠️ @mukhrr Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).