[Due for payment 2026-07-23] [$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: @mallenexpensify

[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.

[KJ21-ENG]

Proposal

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

Android HybridApp can fatally crash while Expo TaskManager executes the registered background location task. The Sentry frame is in expo.modules.taskManager.TaskService.executeTask, so the failure happens in Expo's native task dispatch path while the app is trying to deliver a background task event.

What is the root cause of that problem?

The app registers only one Expo TaskManager task: background-location-tracking.

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

Lines 13 to 33 in eaaffe3

	defineTask<BackgroundLocationTrackingTaskData>(BACKGROUND_LOCATION_TRACKING_TASK_NAME, async ({data, error}) => {
	if (error) {
	console.error('[GPS distance request] Long-running task error: ', {error, data});
	return;
	}
	// Use NetInfo.fetch() instead of the in-memory NetworkState.isOffline() because this
	// background task may run in a headless JS context (Android) where module-level state
	// in NetworkState.ts hasn't been populated via Onyx/NetInfo subscribers.
	const [gpsDraftDetailsPromiseResult, netInfoState] = await Promise.all([OnyxUtils.get(ONYXKEYS.GPS_DRAFT_DETAILS).catch(() => undefined), NetInfo.fetch()]);
	const gpsDraftDetails = gpsDraftDetailsPromiseResult ?? undefined;
	const isOffline = netInfoState.isConnected === false;
	const newGpsPoints = data.locations.map((location) => ({lat: location.coords.latitude, long: location.coords.longitude}));
	const updatedGpsPoints = addGpsPoints(gpsDraftDetails, newGpsPoints);
	if (shouldUpdateStartAddress(getGpsPoints(gpsDraftDetails), updatedGpsPoints)) {
	updateStartAddress(updatedGpsPoints, isOffline);
	}
	});

That task is started and restarted through Location.startLocationUpdatesAsync() from the GPS distance request flow.

App/src/pages/iou/request/step/IOURequestStepDistanceGPS/GPSButtons/index.tsx

Lines 71 to 80 in eaaffe3

	// Returns true if location tracking was successfully initialized, false otherwise
	const initLocationTracking = async (): Promise<boolean> => {
	try {
	await startLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME, BACKGROUND_LOCATION_TASK_OPTIONS);
	} catch (error) {
	console.error('[GPS distance request] Failed to start location tracking', error);
	setShouldShowStartError(true);
	return false;
	}
	return true;

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

Lines 63 to 87 in eaaffe3

	const continueGpsTrip = async () => {
	const isBackgroundTaskRunning = await hasStartedLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME);
	const unit = gpsDraftDetails?.unit;
	if (isBackgroundTaskRunning) {
	if (unit) {
	startGpsTripNotification(translate, reportID, unit, gpsDraftDetails?.distanceInMeters);
	}
	return;
	}
	try {
	await startLocationUpdatesAsync(BACKGROUND_LOCATION_TRACKING_TASK_NAME, BACKGROUND_LOCATION_TASK_OPTIONS);
	} catch (error) {
	console.error('[GPS distance request] Failed to restart location tracking', error);
	return;
	}
	if (!unit) {
	return;
	}
	startGpsTripNotification(translate, reportID, unit, gpsDraftDetails?.distanceInMeters);
	};

In expo-task-manager@55.0.2, TaskService.executeTask() queues the native task event, then assumes a headless React Native app loader is always available when no foreground task manager is registered:

https://github.com/expo/expo/blob/sdk-55/packages/expo-task-manager/android/src/main/java/expo/modules/taskManager/TaskService.java#L368-L428

The same file's getAppLoader() returns null when the weak Context reference has been cleared:

https://github.com/expo/expo/blob/sdk-55/packages/expo-task-manager/android/src/main/java/expo/modules/taskManager/TaskService.java#L433-L439

So if Android delivers a location task while the HybridApp process is in a headless/background transition and mContextRef.get() is null, executeTask() reaches getAppLoader().loadApp(...) and throws a native NullPointerException before the JS task can run or fail gracefully. This matches the Sentry top frame and why the issue is Android HybridApp-only and not tied to a deterministic user-visible screen repro.

There is also a secondary app-side assumption in our task executor: after checking error, it immediately reads data.locations.

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

Lines 13 to 27 in eaaffe3

	defineTask<BackgroundLocationTrackingTaskData>(BACKGROUND_LOCATION_TRACKING_TASK_NAME, async ({data, error}) => {
	if (error) {
	console.error('[GPS distance request] Long-running task error: ', {error, data});
	return;
	}
	// Use NetInfo.fetch() instead of the in-memory NetworkState.isOffline() because this
	// background task may run in a headless JS context (Android) where module-level state
	// in NetworkState.ts hasn't been populated via Onyx/NetInfo subscribers.
	const [gpsDraftDetailsPromiseResult, netInfoState] = await Promise.all([OnyxUtils.get(ONYXKEYS.GPS_DRAFT_DETAILS).catch(() => undefined), NetInfo.fetch()]);
	const gpsDraftDetails = gpsDraftDetailsPromiseResult ?? undefined;
	const isOffline = netInfoState.isConnected === false;
	const newGpsPoints = data.locations.map((location) => ({lat: location.coords.latitude, long: location.coords.longitude}));

Expo normally sends an empty Bundle when native data is null, but malformed/empty location events should still be ignored by this task rather than turning into a JS-side crash after the native NPE is fixed.

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

Patch expo-task-manager@55.0.2 via patch-package and add the patch under patches/expo-task-manager/.

In TaskService.executeTask():

• Resolve Context context = mContextRef.get() and HeadlessAppLoader appLoader = getAppLoader() once before calling loadApp.
• If context or appLoader is null, remove the queued event/callback for that eventId, log a warning including task.getName() and appScopeKey, and return instead of calling loadApp.
• Keep the existing behavior for a present foreground task manager, successful headless loading, AppConfigurationError, and unregister-on-load-failure paths.

This fixes the fatal native NPE at the boundary where the nullable loader is introduced, without changing the GPS feature behavior when Android can actually start the headless app.

Also harden src/setup/backgroundLocationTrackingTask/index.native.ts by validating the task payload before mapping it:

• Treat missing data, missing data.locations, or an empty/non-array locations value as a no-op.
• Keep the existing error logging, Onyx lookup, offline detection, GPS point merge, and start-address update behavior for valid location arrays.

Add/update patch metadata in patches/expo-task-manager/details.md, and add a focused unit test around the background location task executor if the existing test harness can import the task setup module; otherwise verify by building Android and confirming patch-package applies cleanly.

Scope boundaries:

• Files touched: patches/expo-task-manager/expo-task-manager+55.0.2+001+guard-null-headless-loader.patch, patches/expo-task-manager/details.md, and src/setup/backgroundLocationTrackingTask/index.native.ts.
• Native behavior touched: only Expo TaskManager's Android background/headless task dispatch when no foreground task manager exists.
• Code paths explicitly not touched: the custom @expensify/react-native-background-task module, iOS TaskManager, GPS notification UI, permission flows, trip start/stop actions, Onyx GPS draft writes, and reverse geocoding logic.
• API/backend changes: none.

What alternative solutions did you explore? (Optional)

I considered only adding a JS guard around data.locations, but that does not address the reported fatal native frame because TaskService.executeTask() can crash before the JS executor is invoked. I also considered stopping/unregistering the GPS task more aggressively on app restart, but that would risk losing legitimate distance tracking. The narrow dependency patch keeps background GPS tracking intact and only guards the nullable native loader path that Expo already exposes through getAppLoader().

At draft time there are no strict human or bot proposals on this issue. The duplicate scan found this target issue and the general monthly Sentry tracking issue only.