[Due for payment 2026-08-11] [$250] [Sentry: APP-1A] HybridApp Android ART InvokeVirtualOrInterfaceWithVarArgs native crash

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-1A

Impact (snapshot at filing)

• Users (total since first seen): 117
• Events: 294
• Users (last 14d, 9.4.x releases): 10
• First seen: 2025-10-29
• Last seen: ongoing
• Platform: Android HybridApp
• App version(s): 9.4.5–9.4.9
• Affected route(s): unknown (native crash)
• Mechanism: signalhandler (SIGSEGV)

Stack trace (top frames, first-party only)

art::InvokeVirtualOrInterfaceWithVarArgs
SIGSEGV: Segfault

Suspected cause

Native ART crash during JNI bridge invocation; stack is largely unsymbolicated — needs native debugging.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Prior GH issues: none

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067266114365125843
• Upwork Job ID: 2067266114365125843
• Last Price Increase: 2026-07-15

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

[$250] [Sentry: APP-1A] HybridApp Android ART InvokeVirtualOrInterfaceWithVarArgs native crash

What is the root cause of that problem?

I traced this to the path that handles APP, HybridApp, ART:

• src/HybridAppHandler.tsx:25 (endSpan): endSpan(CONST.TELEMETRY.SPAN_APP_STARTUP);
• src/HybridAppHandler.tsx:59 (startSpan): startSpan(CONST.TELEMETRY.SPAN_OD_ND_TRANSITION_LOGGED_OUT, {
• src/HybridAppHandler.tsx:62 (HybridAppHandler): startTime: hybridAppSettings.hybridApp.transitionStartTimestamp,
• The local evidence matches this recurring failure shape: native callback assumes current policy/report still exists. Here, src/HybridAppHandler.tsx:25 and src/HybridAppHandler.tsx:59 do not agree on the same APP, HybridApp, ART value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/HybridAppHandler.tsx:25 to derive APP, HybridApp, ART from the matched app state path that owns this flow before the value is consumed.
• Carry the same normalized value through src/HybridAppHandler.tsx:59; that follows the safer family move to add the guard at the ownership boundary, not only at render, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Sentry Crash, Null/Undefined, Native Hybrid surface and avoid changing do not hide crashes with blanket catch, native platform differences.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/**/*.ts for the exact issue flow: [$250] [Sentry: APP-1A] HybridApp Android ART InvokeVirtualOrInterfaceWithVarArgs native crash.
2. Cover the counter-case near src/HybridAppHandler.tsx:25 so valid existing APP, HybridApp, ART behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, HybridApp, ART consistent at the first read/write boundary shown above.

[MelvinBot]

⚠️ Preliminary analysis (low confidence) — this is an unsymbolicated native crash, so the exact faulting code can't be pinpointed from the stack alone.

Issue Analysis

What this is: A native Android crash (SIGSEGV) inside the Android Runtime, not a JavaScript/TypeScript error. The single first-party frame, art::InvokeVirtualOrInterfaceWithVarArgs, is ART's internal routine for invoking a Java method through JNI with varargs. A segfault here means native C++ code crashed while calling into Java across the JNI bridge — typically a stale/freed jobject, a JNI reference used after the JVM detached the thread, or a bad argument marshalled into the varargs call. It is HybridApp-Android-only, which points squarely at the OldDot↔NewDot native bridge rather than RN/JS app logic.

Where the fix likely lives (outside this repo): The HybridApp JS↔native boundary is the @expensify/react-native-hybrid-app native module and the OldDot Android shell in Mobile-Expensify. Both are native code outside Expensify/App. Because the root cause is in native code I can't access here, I'm not proposing an App-side code fix — this needs an internal engineer with Mobile-Expensify / native module access.

Why the existing proposal is wrong: The proposal above attributes the crash to telemetry span calls in src/HybridAppHandler.tsx and talks about keeping an "APP, HybridApp, ART value" consistent. That is not a real value in the code, those startSpan/endSpan calls are pure JS telemetry that cannot produce a native SIGSEGV, and the cited line numbers don't match the described code. It should be disregarded.

Most useful next step: This stack is unsymbolicated (art::InvokeVirtualOrInterfaceWithVarArgs + SIGSEGV only). Before any fix is possible, the Sentry issue APP-1A needs symbolicated native frames (upload the Android NDK debug symbols / ProGuard mapping for 9.4.5–9.4.9) so the actual JNI call site is visible. Without that, any code-level root cause is guesswork.

Investigation details

• HybridApp startup invokes the native module via HybridAppModule (@expensify/react-native-hybrid-app) in src/libs/actions/HybridApp/index.ts — this is the JS→Java entry point for the OldDot→NewDot transition.
• HybridAppHandler (source) only orchestrates splash state and telemetry spans in JS; it has no native call that could segfault.
• art::InvokeVirtualOrInterfaceWithVarArgs is called by the RN/Hermes JNI layer (and native modules) when C++ invokes a Java method. A SIGSEGV in it is a native-memory fault, consistent with a JNI lifecycle bug in the HybridApp bridge, not a JS exception.
• Impact snapshot: 117 users / 294 events, Android HybridApp, versions 9.4.5–9.4.9, first seen 2025-10-29, ongoing.
• Alternative explanations not ruled out (need symbols to distinguish): (a) JNI local/global ref misuse in the HybridApp native module; (b) a more generic RN/Hermes JNI crash incidentally surfacing on HybridApp builds; (c) an OldDot Android-shell call into NewDot with a stale object. (a) and (c) are the most likely given the HybridApp-only signature.
• No prior related GH issues found.

---

Next Steps: This requires native debugging in Mobile-Expensify / the HybridApp native module by an internal engineer — please escalate. The most immediate action is to symbolicate APP-1A in Sentry so the real JNI frame is visible. Reply with @MelvinBot <your feedback> to refine this analysis.

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 15:51:27 UTC.

Proposal

What is the root cause of that problem?

art::InvokeVirtualOrInterfaceWithVarArgs is the ART path that invokes a Java/Kotlin method from a jvalue argument list. On the HybridApp New Architecture bridge, a null/garbage jstring pushed into that varargs invoke against a Kotlin parameter typed non-null String is dereferenced during marshalling → SIGSEGV. This is uncatchable from Kotlin try/catch, so Sentry only sees the unsymbolicated native frame.

The latent defect is a contract inconsistency in the shared TurboModule spec. signInToOldDot is the only HybridApp method whose codegen spec declares its string params non-null:

App/modules/hybrid-app/src/NativeReactNativeHybridApp.ts

Line 15 in 6ea10e7

signInToOldDot: (autoGeneratedLogin: string, autoGeneratedPassword: string, authToken: string, email: string, policyID: string, signingInWithSAML?: boolean) => void;

The native signatures generated from that spec are likewise non-null String, unlike switchAccount/sendAuthToken, which correctly use String?:

App/modules/hybrid-app/android/src/main/java/com/expensify/reactnativehybridapp/ReactNativeHybridApp.kt

Lines 28 to 64 in 6ea10e7

	override fun switchAccount(
	newDotCurrentAccountEmail: String?,
	authToken: String?,
	policyID: String?,
	accountID: String?
	) {
	Log.d(NAME, "`switchAccount` should never be called in standalone `New Expensify` app")
	}
	override fun sendAuthToken(authToken: String?) {
	Log.d(NAME, "`sendAuthToken` should never be called in standalone `New Expensify` app")
	}
	override fun getHybridAppSettings(promise: Promise) {
	Log.d(NAME, "`getHybridAppSettings` should never be called in standalone `New Expensify` app")
	promise.reject("NOT_IMPLEMENTED", "getHybridAppSettings is not implemented in standalone New Expensify app")
	}
	override fun getInitialURL(promise: Promise) {
	Log.d(NAME, "`getInitialURL` should never be called in standalone `New Expensify` app")
	promise.reject("NOT_IMPLEMENTED", "getInitialURL is not implemented in standalone New Expensify app")
	}
	override fun onURLListenerAdded() {
	Log.d(NAME, "`onURLListenerAdded` should never be called in standalone `New Expensify` app")
	}
	override fun signInToOldDot(
	autoGeneratedLogin: String,
	autoGeneratedPassword: String,
	authToken: String,
	email: String,
	policyID: String,
	signingInWithSAML: Boolean?
	) {
	Log.d(NAME, "`signInToOldDot` should never be called in standalone `New Expensify` app")
	}

The iOS spec has the same shape (NSString * rather than nullable):

App/modules/hybrid-app/ios/ReactNativeHybridApp.mm

Line 46 in 6ea10e7

- (void)signInToOldDot:(NSString *)autoGeneratedLogin autoGeneratedPassword:(NSString *)autoGeneratedPassword authToken:(NSString *)authToken email:(NSString *)email policyID:(NSString *)policyID signingInWithSAML:(NSNumber *)signingInWithSAML {

Importantly, the App-side auto-sign-in caller is currently safe — it already guards authToken and defaults the rest, so on this path nothing undefined is sent:

App/src/libs/HybridApp.ts

Lines 86 to 113 in 6ea10e7

	if (!session?.authToken || !hybridApp?.useNewDotSignInPage) {
	return;
	}
	if (isAnonymousUser(session)) {
	setReadyToShowAuthScreens(true);
	return;
	}
	if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword || account?.requiresTwoFactorAuth === undefined || account?.needsTwoFactorAuthSetup === undefined) {
	return;
	}
	// Skip if we're already in the signing in flow, preventing multiple calls to signInToOldDot
	if (session?.autoAuthState === CONST.AUTO_AUTH_STATE.SIGNING_IN) {
	return;
	}
	Log.info(`[HybridApp] Performing sign-in on OldDot side`);
	HybridAppModule.signInToOldDot({
	autoGeneratedLogin: credentials.autoGeneratedLogin,
	autoGeneratedPassword: credentials.autoGeneratedPassword,
	authToken: session.authToken,
	email: getCurrentUserEmail() ?? '',
	// eslint-disable-next-line rulesdir/no-default-id-values
	policyID: activePolicyID ?? '',
	signingInWithSAML: hybridApp?.signingInWithSAML ?? false,
	});

So the crash does not come from this guarded path forgetting a check. It comes from the bridge contract itself promising "never null" for signInToOldDot while every sibling method tolerates null. Any caller that ever reaches this method with a null/absent string — including the Mobile-Expensify transition flows that implement the same generated spec — hits a hard native crash instead of a safe no-op, which is exactly the InvokeVirtualOrInterfaceWithVarArgs signature here.

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

Make the bridge contract null-safe so a null fails gracefully instead of segfaulting, and back it up at the single JS convergence point:

1. In the codegen spec, declare signInToOldDot's string params nullable (string | null), mirroring how switchAccount/sendAuthToken are already typed:

App/modules/hybrid-app/src/NativeReactNativeHybridApp.ts

Line 15 in 6ea10e7

signInToOldDot: (autoGeneratedLogin: string, autoGeneratedPassword: string, authToken: string, email: string, policyID: string, signingInWithSAML?: boolean) => void;

2. Update the native signatures generated against that spec to String? (Android) and nullable NSString (iOS), matching the siblings:

App/modules/hybrid-app/android/src/main/java/com/expensify/reactnativehybridapp/ReactNativeHybridApp.kt

Lines 55 to 64 in 6ea10e7

	override fun signInToOldDot(
	autoGeneratedLogin: String,
	autoGeneratedPassword: String,
	authToken: String,
	email: String,
	policyID: String,
	signingInWithSAML: Boolean?
	) {
	Log.d(NAME, "`signInToOldDot` should never be called in standalone `New Expensify` app")
	}

3. Coerce to concrete primitives at the single JS wrapper that all callers funnel through, so even a future/forgotten caller can never push undefined across the bridge:

App/modules/hybrid-app/src/index.native.ts

Lines 32 to 34 in 6ea10e7

	signInToOldDot({autoGeneratedLogin, autoGeneratedPassword, authToken, email, policyID, signingInWithSAML}) {
	ReactNativeHybridApp.signInToOldDot(autoGeneratedLogin, autoGeneratedPassword, authToken, email, policyID, signingInWithSAML);
	},

Together, (1)+(2) remove the non-null contract violation at the root, and (3) guarantees the data and the contract agree at the one chokepoint.

What alternative solutions did you explore? (Optional)

Adding another authToken (or per-field) guard in the JS sign-in caller. This is insufficient/redundant: authToken is already guarded and the other fields are already defaulted at src/libs/HybridApp.ts:86-113, so that path is not the source, and scattering per-call guards is more fragile than fixing the shared contract that all callers — including Mobile-Expensify's transition flows — depend on.

App/src/libs/HybridApp.ts

Lines 86 to 113 in 6ea10e7

	if (!session?.authToken || !hybridApp?.useNewDotSignInPage) {
	return;
	}
	if (isAnonymousUser(session)) {
	setReadyToShowAuthScreens(true);
	return;
	}
	if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword || account?.requiresTwoFactorAuth === undefined || account?.needsTwoFactorAuthSetup === undefined) {
	return;
	}
	// Skip if we're already in the signing in flow, preventing multiple calls to signInToOldDot
	if (session?.autoAuthState === CONST.AUTO_AUTH_STATE.SIGNING_IN) {
	return;
	}
	Log.info(`[HybridApp] Performing sign-in on OldDot side`);
	HybridAppModule.signInToOldDot({
	autoGeneratedLogin: credentials.autoGeneratedLogin,
	autoGeneratedPassword: credentials.autoGeneratedPassword,
	authToken: session.authToken,
	email: getCurrentUserEmail() ?? '',
	// eslint-disable-next-line rulesdir/no-default-id-values
	policyID: activePolicyID ?? '',
	signingInWithSAML: hybridApp?.signingInWithSAML ?? false,
	});

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The crash is most likely coming from the Android share-intent bridge, not from a normal React screen render.

ShareRootPage calls the custom native module ShareActionHandler.processFiles() as soon as the share flow opens or resumes. That Android bridge method then does all parsing and media probing synchronously before calling the JS callback. For videos it creates MediaMetadataRetriever, points it at the shared file path with setDataSource(content), extracts width/height metadata, and releases the retriever.

That is a fragile place to do native media inspection. The path comes from an external Android share intent and can point at provider-backed or device-specific media that Android's native media stack cannot safely parse from a raw file path. If that native call segfaults, Kotlin try/catch cannot catch it, and Sentry only sees a native ART/JNI frame such as art::InvokeVirtualOrInterfaceWithVarArgs while RN is invoking the bridge method.

There is also a smaller contract mismatch in the same bridge: TypeScript documents the callback as a single result argument, but Android error paths call callback.invoke(error, null). That should be cleaned up too, but the native crash risk is the synchronous MediaMetadataRetriever work inside the bridge invocation.

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

Move Android share-file metadata extraction out of this crash-prone native bridge path and make the bridge return a stable payload shape.

Concretely:

1. Stop using MediaMetadataRetriever.setDataSource(content) inside ShareActionHandlerModule.processFiles(). For videos, return the shared URI/path, mime type, id, and timestamp without probing video dimensions in the native bridge. Let the existing JS/native attachment preview pipeline derive dimensions later where failures are recoverable, or use a safer content-resolver/file-descriptor based helper that can fail closed without crashing the bridge.
2. Keep image handling lightweight, but also make it fail closed: if bounds decoding cannot produce dimensions, return a default aspect ratio instead of treating metadata as required for opening the share flow.
3. Normalize the callback contract so Android always invokes the callback with exactly one JSON payload, matching the TS caller. Represent errors as a JSON object/status instead of sometimes passing two callback arguments.
4. Add a focused Android regression test/manual case for sharing a normal video, a provider-backed video/content URI, and an invalid or inaccessible media path into Expensify. The expected result is that the share flow opens or shows a validation error, but the app process does not crash.

What alternative solutions did you explore? (Optional)

Wrapping the existing retriever code in more try/catch is not enough because this is a native SIGSEGV, not a Kotlin exception. Moving the retriever call to another thread would reduce bridge blocking, but it would still leave the app process exposed to the same native crash. The safer fix is to avoid mandatory native video metadata probing during the RN bridge call and make media metadata best-effort.

[lorretheboy]

Corrected the root cause: authToken is already guarded at HybridApp.ts:86 and all other params are defaulted, so our "add an authToken guard" step was a no-op. Refocused on the real latent defect — signInToOldDot is the only HybridApp bridge method with a non-null String contract — and hardening it null-safe like its siblings.