Track Distance - GPS trip/tracking notification does not appear

[applause-bot]

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.89-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91155
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 13 / Xiaomi Poco F5
App Component: Notifications

Action Performed:

Precondition:

• Already allowed the Notification and Location permission for Expensify app

1. Navigate to WS Chat
2. Click + > Track Distance > GPS
3. Start the GPS tracking

Expected Result:

The GPS tracking in progress notification appears in the device notification drawer

Actual Result:

GPS trip/tracking notification does not appear

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166266_1780048554786.92014_-_PR91155_-_Track_Distance_-_GPS_trip_tracking_notification_does_not_appear.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7166266

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/1327356622112c5dc8d036df2b8711b4b9d1860a03ad663e25cd0bca231efada

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91155

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression introduced by #91155, which replaced the Airship LiveUpdate–based GPS notification with a native Android foreground service (GpsTripService) driven from JS via a new GpsTripServiceModule.

The likely root cause is that the staging APK is built in HybridApp mode and is initiated from the Mobile-Expensify submodule (per App/CLAUDE.md — "Mobile builds must be initiated from the Mobile-Expensify directory"). PR #91155 only updated the App-side counterparts:

• Declares the service in AndroidManifest.xml (<service android:name=".GpsTripService" android:foregroundServiceType="location" ...>).
• Registers GpsTripServiceModule in ExpensifyAppPackage.java:26.
• JS now calls NativeModules.GpsTripServiceModule.startService(title, body, deepLink) from GPSNotifications/index.android.ts:13.

These pieces only take effect in HybridApp builds if the matching changes in the corresponding Mobile-Expensify PR (#13944) are present in the staging build — i.e. the new service must be declared in the merged Android manifest and ExpensifyAppPackage must be registered by the HybridApp's MainApplication. If that PR is not yet shipped to staging:

• The OS rejects startForegroundService for an undeclared service (or NativeModules.GpsTripServiceModule is undefined), so the call silently fails and no notification is posted.
• The fact that this reproduces in staging but not production matches a partial rollout where only one half of the change is live.

A secondary risk worth ruling out on the device used to repro (Android 13, Xiaomi Poco F5): Xiaomi/MIUI is aggressive about foreground-service notifications. With IMPORTANCE_HIGH + setOngoing(true) it should still appear, but MIUI's "Autostart" and per-channel notification toggles for the freshly-created gps_foreground_service_channel are worth a quick check if (1) is ruled out.

Investigation details

New service (App side): GpsTripService.kt — uses NotificationCompat.Builder with setSmallIcon(R.drawable.ic_notification), IMPORTANCE_HIGH channel, setOngoing(true). On API ≥ 34 it correctly uses the 3-arg startForeground(id, notification, FOREGROUND_SERVICE_TYPE_LOCATION); on API < 34 it uses 2-arg startForeground (valid because manifest declares the type). Device under test is API 33, so the 2-arg path is exercised.

Native module (App side): GpsTripServiceModule.kt — calls context.startForegroundService(intent) on API ≥ 26. Exceptions are caught and logged but not surfaced to JS, so a silent failure here would match the reported symptom.

JS trigger: GPSButtons/index.tsx:91 invokes startGpsTripNotification(translate, reportID, unit) immediately after initLocationTracking succeeds. The Android handler at GPSNotifications/index.android.ts calls NativeModules.GpsTripServiceModule.startService(...) — there is no guard for a missing module, so if the module is not registered in the HybridApp build, this throws and the trip starts without a notification.

Things ruled out (App-side, Android 13):

• Manifest permissions present: FOREGROUND_SERVICE, FOREGROUND_SERVICE_LOCATION.
• Service declared with correct foregroundServiceType="location".
• POST_NOTIFICATIONS is not in the App manifest, but per Android docs foreground-service notifications are not suppressed when that permission is denied, so this is not the cause on its own. The repro precondition also says notification permission was granted.

Related issues (open):

• Expensify/App#88700 — App crashes reopening while GPS trip in progress (fix target of Fix GPS crashes in the background on Android #91155).
• Expensify/App#90931 — App crashes when tapping GPS live activity notification (fix target of Fix GPS crashes in the background on Android #91155).

Neither describes the same "notification never appears" symptom, so this is a new regression rather than a duplicate.

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

1. Confirm Mobile-Expensify alignment first. Verify that the staging build was cut from a Mobile-Expensify revision that includes the matching changes from Expensify/Mobile-Expensify#13944 — specifically the <service android:name=".GpsTripService" .../> declaration, the FOREGROUND_SERVICE_LOCATION permission, and registration of ExpensifyAppPackage (and therefore GpsTripServiceModule) on the HybridApp's React package list. If that PR is not yet in staging, bumping the submodule pointer and re-cutting staging is the fix; this is a private-repo follow-up for an internal engineer with access to Mobile-Expensify.

2. Make JS fail loudly when the native module is missing, so future HybridApp/standalone divergences surface immediately instead of silently dropping the notification. In GPSNotifications/index.android.ts:13, guard the call (e.g. if (!NativeModules.GpsTripServiceModule) { Log.warn(...); return; }) and log via the standard Log utility — currently any throw is swallowed by the caller and we have no visibility.

3. Surface native-side startForegroundService failures to JS. GpsTripServiceModule.kt:30-32 catches Exception and only logs to logcat. Returning a Promise (or invoking an error callback) would make a silent failure debuggable from JS / Sentry the next time something goes wrong on a specific OEM (e.g. MIUI restricting foreground services).

If Mobile-Expensify alignment is confirmed and the regression persists, next steps would be (a) capture adb logcat -s GpsTripService GpsTripServiceModule on the Poco F5 to confirm the service is reached and startForeground is invoked, and (b) check the GPS Trip Tracking channel state in app settings for MIUI-specific suppression.

What alternative solutions did you explore? (Optional)

• Revert Fix GPS crashes in the background on Android #91155 to unblock the deploy. Lowest-risk option to clear the deploy blocker, at the cost of re-introducing the crashes [$250] Android - App crashes reopening while the GPS trip is in progress after discard tracking twice #88700 / [$250] GPS - Android - App crashes when tap on GPS live activity notification #90931 the PR was fixing. Worth considering if the Mobile-Expensify counterpart cannot be shipped quickly.
• Roll back only the JS handler to the previous Airship-based path while keeping the new native service code in place for a follow-up. More surgical but adds churn and the Airship LiveUpdate dependency is already gone in CustomAirshipExtender.java and GPSTripStateChecker/index.native.tsx, so the cleaner revert is Some initial fixes and code style updates #1.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92073#issuecomment-melvinbot) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.