[$250] [Sentry: APP-8MA] HybridApp Android expo video FullscreenPlayerActivity crash

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-8MA

Impact (snapshot at filing)

• Users (total since first seen): 51
• Events: 55
• Users (last 7d): 28
• Events (last 7d): 28
• First seen: 2026-03-28
• Last seen: 2026-07-02 (ongoing)
• Platform: Android HybridApp
• App version(s): 9.4.23
• Affected route(s): expo video fullscreen player
• Mechanism: chained (RuntimeException → UninitializedPropertyAccessException)

Stack trace (top frames, first-party only)

FullscreenPlayerActivity.onCreate
FullscreenPlayerActivity.finish
UninitializedPropertyAccessException: lateinit property videoViewId has not been initialized

Suspected cause

expo.modules.video FullscreenPlayerActivity is started or finished before videoViewId is initialized, crashing on Android HybridApp.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072671136961070616
• Upwork Job ID: 2072671136961070616
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @KJ21-ENG

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 13:35:48 UTC.

Proposal

What is the root cause of that problem?

The crash is in the pinned Android implementation of expo-video@55.0.3, not in our JS video controls. Our wrapper renders Expo's VideoView with fullscreen enabled, and the fullscreen button calls videoViewRef.current?.enterFullscreen(), which hands the Android fullscreen lifecycle to Expo's native FullscreenPlayerActivity.

App/src/components/VideoPlayer/BaseVideoPlayer.tsx

Lines 604 to 612 in a9e6aed

	<VideoView
	fullscreenOptions={{enable: true}}
	player={videoPlayerRef.current}
	style={[styles.w100, styles.h100, videoPlayerStyle, hasErrorIconVisible && {opacity: 0}]}
	nativeControls={isFullScreen}
	playsInline
	testID={CONST.VIDEO_PLAYER_TEST_ID}
	ref={videoViewRef}
	contentFit="contain"

App/src/components/VideoPlayer/VideoPlayerControls/index.tsx

Lines 117 to 120 in a9e6aed

	const enterFullScreenMode = useCallback(() => {
	updateCurrentURLAndReportID(url, report, reportID);
	videoViewRef.current?.enterFullscreen();
	}, [report, reportID, updateCurrentURLAndReportID, url, videoViewRef]);

The App currently pins expo-video to 55.0.3. In that package, FullscreenPlayerActivity declares videoViewId as lateinit, catches an initialization failure in onCreate, calls finish(), and finish() unconditionally reads videoViewId to reattach the player. If the activity is finished before that id is assigned, the recovery path throws the Sentry UninitializedPropertyAccessException instead of exiting cleanly.

App/package.json

Line 153 in a9e6aed

"expo-video": "55.0.3",

https://github.com/Expensify/App/blob/a9e6aedb99c6a426f1321a28019b530bd255fe0a/package-lock.json#L24965-L24968

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:30

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:69

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:71

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:116

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:119

Expo already fixed this exact failure after 55.0.3; the 55.0.5 changelog includes the Android FullscreenPlayerActivity init-failure crash fix, and the fixed source makes videoViewId nullable and guards the finish() reattach.

https://github.com/expo/expo/blob/sdk-55/packages/expo-video/CHANGELOG.md#L89-L95

https://github.com/expo/expo/blob/sdk-55/packages/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt#L28-L33

https://github.com/expo/expo/blob/sdk-55/packages/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt#L116-L119

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

Update expo-video from 55.0.3 to at least 55.0.5 and refresh package-lock.json so Android HybridApp includes Expo's upstream fix for the fullscreen activity init-failure crash. Because this repo already has an expo-video patch for a web playback issue, port that patch to the new expo-video package version by regenerating or renaming the patch-package file and updating patches/expo-video/details.md.

App/patches/expo-video/details.md

Lines 1 to 5 in a9e6aed

	# `expo-video` patches
	### [expo-video+55.0.3+001+catch_play_abort_error.patch](expo-video+55.0.3+001+catch_play_abort_error.patch)
	- Reason: When rapidly seeking a video via the progress bar on web, `HTMLVideoElement.play()` returns a Promise that gets rejected with `AbortError` if `pause()` is called before it resolves. This patch wraps all 5 `video.play()` call sites in `VideoPlayer.web.js` with `.catch()` to silently swallow `AbortError` while re-throwing any other errors. This is the [standard fix recommended by Chrome](https://developer.chrome.com/blog/play-request-was-interrupted).

App/scripts/postInstall.sh

Lines 31 to 32 in a9e6aed

	# Apply packages using patch-package
	scripts/applyPatches.sh

App/scripts/applyPatches.sh

Lines 27 to 32 in a9e6aed

	find ./patches -type f -name '*.patch' -exec cp {} "$TEMP_PATCH_DIR" \;
	if [[ "$IS_HYBRID_APP_REPO" == "true" && "$NEW_DOT_FLAG" == "false" ]]; then
	find ./Mobile-Expensify/patches -type f -name '*.patch' -exec cp {} "$TEMP_PATCH_DIR" \;
	fi
	if ! npx patch-package --patch-dir "$TEMP_PATCH_DIR" --error-on-fail --color=always; then

Test coverage: run the package install/patch validation so the updated expo-video patch applies cleanly, then smoke-test Android HybridApp by opening a chat video, entering fullscreen, immediately exiting fullscreen, and backgrounding/foregrounding while fullscreen is active. Confirm there is no FullscreenPlayerActivity crash and that normal fullscreen enter/exit playback still works.

What alternative solutions did you explore? (Optional)

We could add a local native patch against expo-video@55.0.3, but the exact crash already has an upstream SDK 55 patch release, so upgrading avoids carrying another custom dependency patch. Guarding the JS enterFullscreen() call would not fix this, because the crash happens after JS has handed control to Expo's Android activity lifecycle.

[melvin-bot]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The crash is inside expo-video's native Android code, not our JS. We ship expo-video 55.0.3:

App/package.json

Line 153 in a9e6aed

"expo-video": "55.0.3",

In that version's node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt, videoViewId is a lateinit var that only gets assigned in onCreate, from the launch intent's VideoManager.INTENT_PLAYER_KEY extra. When that extra can't be resolved, onCreate bails out early by calling finish(). But the activity overrides finish() and unconditionally reads videoViewId there (to look up the VideoView and call its exit-fullscreen cleanup). So the causal chain is: Android relaunches FullscreenPlayerActivity in a fresh process (the OS killed the app while the fullscreen player was on top — common on HybridApp Android, where the OldDot native side adds memory pressure) → the new process can't resolve the player from the intent → onCreate takes the early-exit finish() path before the lateinit assignment ran → the overridden finish() dereferences the uninitialized videoViewId → UninitializedPropertyAccessException, which Android wraps in the RuntimeException seen in Sentry APP-8MA (matching the onCreate → finish frames in the stack).

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

Add a patch-package patch for expo-video's Android sources — we already patch this package, so this follows the existing convention:

App/patches/expo-video/details.md

Lines 1 to 5 in a9e6aed

	# `expo-video` patches
	### [expo-video+55.0.3+001+catch_play_abort_error.patch](expo-video+55.0.3+001+catch_play_abort_error.patch)
	- Reason: When rapidly seeking a video via the progress bar on web, `HTMLVideoElement.play()` returns a Promise that gets rejected with `AbortError` if `pause()` is called before it resolves. This patch wraps all 5 `video.play()` call sites in `VideoPlayer.web.js` with `.catch()` to silently swallow `AbortError` while re-throwing any other errors. This is the [standard fix recommended by Chrome](https://developer.chrome.com/blog/play-request-was-interrupted).

In FullscreenPlayerActivity.finish(), guard the cleanup with Kotlin's standard lateinit check so the early-exit path just closes the activity instead of crashing:

override fun finish() {
    super.finish()
    if (!this::videoViewId.isInitialized) {
        return
    }
    // existing cleanup that uses videoViewId
}

finish() is the single convergence point — every bail-out in onCreate (missing intent extra, video view no longer registered) goes through it, so one guard covers all of them. When the activity is recreated after process death there is nothing to clean up anyway; closing silently returns the user to the app.

What alternative solutions did you explore? (Optional)

Bumping expo-video to a newer version that includes the upstream guard would also fix it, but a version bump pulls in unrelated native changes and is much riskier for HybridApp than a one-line patch; we can drop the patch when we next upgrade Expo.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

This is a native crash inside the expo-video library (expo-video@55.0.3), on the FullscreenPlayerActivity that backs the Android fullscreen video player. The chained exception in the Sentry report (RuntimeException in onCreate → UninitializedPropertyAccessException: lateinit property videoViewId has not been initialized in finish) maps to an exact code path.

videoViewId is a lateinit property, assigned as the first statement of the onCreate try block:

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt#L30

private lateinit var videoViewId: String

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt#L43-L73

try {
  videoViewId = intent.getStringExtra(VideoManager.INTENT_PLAYER_KEY)
    ?: throw FullScreenVideoViewNotFoundException()   // L44-L45: throws BEFORE videoViewId is assigned
  ...
} catch (e: CodedException) {
  Log.e("ExpoVideo", "${e.message}", e)
  finish()                                            // L71: calls the overridden finish()
  return
}

When the activity is launched without the INTENT_PLAYER_KEY extra (e.g. the intent is recreated by the OS after process death / config change, or the player view was already torn down), line 44 throws FullScreenVideoViewNotFoundException (a CodedException) before videoViewId is assigned. Control jumps to the catch block, which calls the overridden finish().

finish() unconditionally dereferences videoViewId:

node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt#L116-L119

override fun finish() {
  super.finish()
  didFinish = true
  VideoManager.getVideoView(videoViewId).attachPlayer()   // L119: reads uninitialized lateinit → crash
  ...
}

Because videoViewId was never initialized, reading it at line 119 throws UninitializedPropertyAccessException, which crashes the app. This exactly matches the Sentry stack (onCreate → finish → videoViewId not initialized).

So: intent missing INTENT_PLAYER_KEY → onCreate throws at L44 before videoViewId is set → catch calls finish() at L71 → finish() reads the uninitialized lateinit videoViewId at L119 → UninitializedPropertyAccessException crashes the app.

Note this is Android-native only (this Activity is Android-specific), consistent with the "Android HybridApp" platform in the report. It is a library bug, not an App-side regression — there is no App PR to blame here; the fix belongs in a patch-package patch, which we already do for this exact library (see the existing patches/expo-video/expo-video+55.0.3+001+catch_play_abort_error.patch).

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

Guard the videoViewId access in finish() with Kotlin's built-in lateinit initialization check (::videoViewId.isInitialized), so the cleanup path is safe when onCreate bailed out before assigning it. This is the idiomatic Kotlin pattern for exactly this situation and is a one-line, root-cause fix with zero behavioral change on the normal path.

In node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt (finish(), around L116-L119):

  override fun finish() {
    super.finish()
    didFinish = true
-   VideoManager.getVideoView(videoViewId).attachPlayer()
+   if (::videoViewId.isInitialized) {
+     VideoManager.getVideoView(videoViewId).attachPlayer()
+   }

When onCreate fails before initializing videoViewId, there is no player to re-attach anyway, so skipping the attachPlayer() call in that case is correct — we simply let the aborted activity finish cleanly.

Delivery: add this as a new patch-package patch patches/expo-video/expo-video+55.0.3+002+guard_uninitialized_videoViewId.patch (and a details.md entry), following the existing convention for this library. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Wrap the body of finish() in a try/catch (or make videoViewId a nullable var initialized to null). Both work, but ::videoViewId.isInitialized is the smallest, most explicit fix: it targets precisely the uninitialized-lateinit root cause without swallowing unrelated exceptions (a broad try/catch would) and without changing the property type or every other videoViewId usage in the file (onCreate L44/L56, onDestroy's videoView cleanup). It also matches upstream expectations — this can be contributed back to expo/expo.

[trasnake87]

Proposal

What is the root cause of that problem?

The crash lives entirely inside expo-video@55.0.3's native FullscreenPlayerActivity.kt, on the early-exit path in onCreate. The first line of the try block assigns the lateinit videoViewId from the launch intent:

// node_modules/expo-video/android/src/main/java/expo/modules/video/FullscreenPlayerActivity.kt:44
videoViewId = intent.getStringExtra(VideoManager.INTENT_PLAYER_KEY)
  ?: throw FullScreenVideoViewNotFoundException()

When Android relaunches this activity in a fresh process (OS reclaimed the app while the fullscreen player was on top — routine on HybridApp Android, where the OldDot native layer adds memory pressure), the redelivered/reconstructed intent has no INTENT_PLAYER_KEY extra, so getStringExtra returns null and the ?: throw fires before videoViewId is ever assigned. The catch at line 69 then calls finish().

But finish() is overridden and unconditionally dereferences the still-uninitialized property:

// FullscreenPlayerActivity.kt:116-119
override fun finish() {
  super.finish()
  didFinish = true
  VideoManager.getVideoView(videoViewId).attachPlayer()   // videoViewId not initialized → throws

→ UninitializedPropertyAccessException, wrapped by Android in the RuntimeException seen in APP-8MA, matching the onCreate → finish → videoViewId not initialized frames exactly.

Why guarding only finish() is insufficient — the critical trap: after finish() returns during onCreate, Android proceeds straight to onDestroy(), which also dereferences lateinit fields that were never assigned on this path:

// FullscreenPlayerActivity.kt:160-162
videoView.exitFullscreen()                        // videoView lateinit → throws
...
orientationHelper.stopOrientationEventListener()  // orientationHelper lateinit → throws

A finish()-only guard simply moves the same crash into onDestroy(). There is also a third failure variant: when the intent does carry the id but VideoManager.getVideoView(videoViewId) (line 56) throws because the in-memory registry is empty in the recreated process — videoViewId is set but the lookup itself fails. Guarding on ::videoViewId.isInitialized misses this; the correct sentinel is whether the resolved videoView object was actually assigned.

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

Add a patch-package patch under the existing patches/expo-video/ directory (e.g. expo-video+55.0.3+002+guard_uninitialized_fullscreen_cleanup.patch), following the convention already in place:

App/patches/expo-video/details.md

Lines 1 to 5 in a9e6aed

	# `expo-video` patches
	### [expo-video+55.0.3+001+catch_play_abort_error.patch](expo-video+55.0.3+001+catch_play_abort_error.patch)
	- Reason: When rapidly seeking a video via the progress bar on web, `HTMLVideoElement.play()` returns a Promise that gets rejected with `AbortError` if `pause()` is called before it resolves. This patch wraps all 5 `video.play()` call sites in `VideoPlayer.web.js` with `.catch()` to silently swallow `AbortError` while re-throwing any other errors. This is the [standard fix recommended by Chrome](https://developer.chrome.com/blog/play-request-was-interrupted).

The patch must guard both finish() and onDestroy() on ::videoView.isInitialized (not videoViewId), and replace the VideoManager.getVideoView(videoViewId) re-lookup in finish() with the already-resolved field, eliminating the third crash variant:

// finish() — FullscreenPlayerActivity.kt:116
override fun finish() {
  super.finish()
  didFinish = true
  if (::videoView.isInitialized) {
    videoView.attachPlayer()
  }
  // ...window/transition code unchanged...
}

// onDestroy() — FullscreenPlayerActivity.kt:150
override fun onDestroy() {
  super.onDestroy()
  captioningChangeListener?.let { /* unchanged */ }
  if (::videoView.isInitialized) {
    videoView.exitFullscreen()
  }
  VideoManager.unregisterFullscreenPlayerActivity(hashCode().toString())
  if (::orientationHelper.isInitialized) {
    orientationHelper.stopOrientationEventListener()
  }
}

Add a details.md entry explaining the guarded fields and why videoView (not videoViewId) is the correct check. File the fix upstream to expo/expo so it lands when we next upgrade the dependency.

Repro: open a fullscreen video on HybridApp Android, background the app, enable Developer Options → "Don't keep activities" (or run adb shell am kill <pkg>), then relaunch from recents — the activity restarts without its player intent extra and crashes on the uninitialized cleanup path.