[Due for payment 2026-06-30] [$250] [Sentry: APP-4FK] HybridApp Android NullPointerException in expo TaskService.executeTask

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-4FK

Impact (snapshot at filing)

• Users (total since first seen): 154
• Events: 5,369
• Users (last 14d): ongoing on 9.3.89–9.3.91
• First seen: 2026-01-22
• Last seen: now (ongoing)
• Platform: Android, hybrid_app
• App version(s): seen through 9.3.91
• Mechanism: chained, fatal

Stack trace (top frames, first-party only)

expo.modules.taskManager.TaskService in executeTask
  -> java.lang.NullPointerException

Suspected cause

Expo background TaskService receives a null context or task payload on Android HybridApp when executing a registered background task.

Reproduction

Unknown deterministically — see linked Sentry events for Android HybridApp sessions.

Related

• Sibling Sentry IDs (if any): none identified
• Prior GH issues: none
• Production scan: releases 9.3.89, 9.3.90, 9.3.91 (2026-06-02)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061885299179690169
• Upwork Job ID: 2061885299179690169
• Last Price Increase: 2026-06-16

Issue Owner

Current Issue Owner: @GCyganek

[melvin-bot]

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

[melvin-bot]

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

[trasnake87]

Proposal

Android HybridApp users crash with a fatal NullPointerException inside Expo's native expo.modules.taskManager.TaskService.executeTask. The only expo-task-manager task this app registers is the GPS distance-tracking background task, so every event in APP-4FK originates from the GPS distance-request feature.

Root cause

The app defines exactly one Expo task — 'background-location-tracking' — registered at startup in src/setup/backgroundLocationTrackingTask/index.native.ts:13 and started through expo-location's startLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME, BACKGROUND_LOCATION_TASK_OPTIONS) (src/pages/iou/request/step/IOURequestStepDistanceGPS/GPSButtons/index.tsx:74 and src/components/GPSTripStateChecker/index.native.tsx:75). The crash has two compounding causes.

1 - No Android foreground service forces delivery through the crashing headless path. The task options are minimal — no foreground service:

// src/pages/iou/request/step/IOURequestStepDistanceGPS/const.ts:6-9 (current)
const BACKGROUND_LOCATION_TASK_OPTIONS: LocationTaskOptions = {
    accuracy: Accuracy.Highest,
    distanceInterval: GPS_DISTANCE_INTERVAL_METERS,
};

Without a foregroundService, Android does not keep the JS runtime alive while tracking. When a location update fires after the process is backgrounded/killed, Expo's native TaskService.executeTask calls getTaskManager(appScopeKey), finds no running task manager, and falls into the headless branch that must resurrect a React host to run the JS callback. In HybridApp the React Native runtime is hosted inside the OldDot native shell and there is no Expo app record/host registered the way a standalone Expo app expects, so that headless branch dereferences a null context/app record → NullPointerException. Critically, this throws in native code before our defineTask callback runs, so the existing JS-level error handling in the task body cannot catch it.

2 - Orphaned task registration survives process death and re-fires indefinitely. expo-location persists the registration to disk; it outlives the process. The only paths that stop it are:

• GPSTripStateChecker unmount cleanup — src/components/GPSTripStateChecker/index.native.tsx:47-55 — which never runs when the OS kills a backgrounded process.
• Sign-out — src/pages/settings/InitialSettingsPage.tsx:237-240.
• Explicit user stop — stopGpsTrip in src/libs/GPSDraftDetailsUtils.ts:103-108.

So if a trip is interrupted by an OS kill, 'background-location-tracking' stays registered and the OS keeps re-entering the crashing path. This explains the event/user ratio (5,369 events / 154 users ≈ 35× per user) — a stuck registration firing repeatedly per device. The startup effect that should heal this returns early without clearing the orphan:

// src/components/GPSTripStateChecker/index.native.tsx:33-45 (current)
async function handleGpsTripInProgressOnAppRestart() {
    await checkAndCleanGpsNotification();
    const gpsTrip = await OnyxUtils.get(ONYXKEYS.GPS_DRAFT_DETAILS);

    if (!gpsTrip?.isTracking) {
        return; // <-- leaves a possibly-registered task alive
    }
    setShowContinueTripModal(true);
}

Proposed fix

Fix 1 — Run a foreground service so updates reach the live runtime (avoids the headless branch entirely). Convert the static options to a builder so the notification can be localized, and add foregroundService:

// src/pages/iou/request/step/IOURequestStepDistanceGPS/const.ts
import {Accuracy} from 'expo-location';
import type {LocationTaskOptions} from 'expo-location';

const GPS_DISTANCE_INTERVAL_METERS = 100;
const BACKGROUND_LOCATION_TRACKING_TASK_NAME = 'background-location-tracking';

function getBackgroundLocationTaskOptions(notificationTitle: string, notificationBody: string): LocationTaskOptions {
    return {
        accuracy: Accuracy.Highest,
        distanceInterval: GPS_DISTANCE_INTERVAL_METERS,
        pausesUpdatesAutomatically: false,
        // Android: keep the process alive via a foreground service so updates are delivered to the
        // running JS runtime (getTaskManager() != null). Without this the OS resurrects the app
        // headlessly and Expo's TaskService.executeTask dereferences a null React host in HybridApp.
        foregroundService: {
            notificationTitle,
            notificationBody,
            killServiceOnDestroy: true,
        },
    };
}

export {getBackgroundLocationTaskOptions, BACKGROUND_LOCATION_TRACKING_TASK_NAME, GPS_DISTANCE_INTERVAL_METERS};

Update the two call sites to pass localized strings (add gps.backgroundTracking.title/.body to the existing gps namespace at src/languages/en.ts:8589):

// src/pages/iou/request/step/IOURequestStepDistanceGPS/GPSButtons/index.tsx:74
// and src/components/GPSTripStateChecker/index.native.tsx:75
await startLocationUpdatesAsync(
    BACKGROUND_LOCATION_TRACKING_TASK_NAME,
    getBackgroundLocationTaskOptions(translate('gps.backgroundTracking.title'), translate('gps.backgroundTracking.body')),
);

This requires FOREGROUND_SERVICE + FOREGROUND_SERVICE_LOCATION permissions and the expo-location foreground service declared in the Mobile-Expensify AndroidManifest.xml (expo-location's config plugin injects these for standalone builds, but HybridApp's manifest comes from the submodule and must include them).

Fix 2 — Clear an orphaned registration on cold start. In the same startup effect, when no trip is in progress, unregister any lingering task before the OS can fire it:

// src/components/GPSTripStateChecker/index.native.tsx:33-45 (replace early return)
    if (!gpsTrip?.isTracking) {
        // A prior trip may have been killed by the OS, leaving the background task registered.
        // Expo keeps firing it and the headless executeTask path NPEs in HybridApp — clear the orphan.
        const isRunning = await hasStartedLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME);
        if (isRunning) {
            stopLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME).catch((error) =>
                console.error('[GPS distance request] Failed to stop orphaned location tracking', error),
            );
        }
        return;
    }

Why this approach

Fix 1 is the structural cure: a foreground service is Expo's documented requirement for reliable Android background location, and it keeps getTaskManager() non-null so updates dispatch to the live JS task manager instead of the headless branch where the native NPE lives. Fix 2 mirrors patterns already in this component — it reuses the exact hasStartedLocationUpdatesAsync/stopLocationUpdatesAsync guard from the unmount cleanup at index.native.tsx:47-55, and sits alongside the existing checkAndCleanGpsNotification() self-heal in the same effect, extending startup recovery to the task registration. We rejected simply wrapping the task body in try/catch (the team already does this for the sibling task at src/setup/backgroundTask/index.native.ts:10-12) because the NPE is thrown in Expo's native executeTask before any JS runs, so a JS guard cannot intercept it — only avoiding the headless branch (Fix 1) and removing stale registrations (Fix 2) can.

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a crash inside the third‑party expo-task-manager native code, not in App's own code.

The only background task in App that goes through Expo's TaskService + a location consumer is the GPS distance‑tracking task, registered here: src/setup/backgroundLocationTrackingTask/index.native.ts:13.

When the app process is killed while a GPS trip is in progress, Android later restarts the headless service to deliver a queued location update and calls TaskService.executeTask(...). If the app's JS task manager isn't loaded yet, that method falls into a branch that loads the app headlessly:

// expo-task-manager 55.0.2 — TaskService.java, executeTask()
getAppLoader().loadApp(mContextRef.get(), ...)   // line ~408

getAppLoader() returns null whenever mContextRef.get() is null (the Context is held in a WeakReference and is gone after the process was killed). The call site dereferences it without a null check → NullPointerException.

The smoking gun: the sibling method invalidateAppRecord() in the same file does guard getAppLoader() for null before using it — executeTask() simply forgot to. Android‑only because iOS uses a different (non‑headless) task delivery path, which matches the Sentry data (Android, hybrid_app) and the manual repro in Expensify/App#88700.

Evidence chain

• Sentry signature: expo.modules.taskManager.TaskService → executeTask → java.lang.NullPointerException, Android / hybrid_app, 154 users, ongoing on 9.3.89–9.3.91.
• executeTask() unguarded call: node_modules/expo-task-manager/android/src/main/java/expo/modules/taskManager/TaskService.java:408 → getAppLoader().loadApp(...).
• getAppLoader() returns null when context is gone: same file, lines 433–439 (if (mContextRef.get() != null) { ... } else { return null; }).
• Guarded sibling proving the omission is a bug: same file, lines 599–606 (invalidateAppRecord() null‑checks getAppLoader() before calling invalidateApp).
• App's GPS task is the only expo-task-manager + expo-location consumer in the codebase (expo-task-manager@55.0.2, expo-location@55.1.10 in package.json).
• Likely duplicate / same root cause: [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 — "App crashes reopening while the GPS trip is in progress" (Android only, reproduced by killing the app mid‑trip).

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

Add a patch-package patch to expo-task-manager (lives in App's patches/ directory) that null‑guards getAppLoader() inside executeTask(), mirroring what invalidateAppRecord() already does. When the loader/context is unavailable, drop the queued event instead of dereferencing null:

• Capture HeadlessAppLoader appLoader = getAppLoader();
• If it's null, remove the queued event for the app scope key and return (the background update is skipped, which is acceptable — far better than a fatal crash).
• Otherwise call appLoader.loadApp(...) as before.

This is a minimal, App‑side fix and prevents the crash for all users hitting this path.

What alternative solutions did you explore? (Optional)

Alternatives considered

• Upstream fix in Expo — file the same null‑guard upstream so the patch can eventually be dropped; doesn't help our users on the current SDK now, so do it in addition to the patch.
• Stop/unregister the location task more aggressively when a trip ends or is discarded (the #88700 repro mentions "discard tracking twice"). Worth verifying the task is always unregistered via stopLocationUpdatesAsync, but this only narrows the trigger window — the headless‑restart NPE can still occur for a legitimately in‑progress trip, so the null guard is still required.
• HybridApp headless‑loader registration — the deeper reason the context/loader is unavailable on HybridApp may involve native headless‑app‑loader setup in Mobile-Expensify. That's a separate investigation; the crash guard above is the correct immediate fix and is fully within the App repo.

Possibly related / duplicate

• [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 — same crash, reproduced by killing the app while a GPS trip is in progress (Android only). Strong candidate for deduping.

---

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