Fix Android 'Already closed' crash on receipt PDF render by wildan-m · Pull Request #94894 · Expensify/App

wildan-m · 2026-06-29T19:24:12Z

Explanation of Change

On Android, the app crashes (java.lang.IllegalStateException: Already closed, Sentry APP-1VG) when a PDF is closed while it's still rendering — for example navigating away from a receipt mid-render. A previous fix (patch 002) already told the pdfiumandroid library to ignore this case instead of crashing, but two methods on the render path — PdfDocument.openPage() and openTextPage() — don't respect that setting and still throw when the document is closed. That's the one path that keeps crashing.

There's no published version of the library that fixes this and still works with our PDF viewer — the stable line is stuck on the buggy version, and the newer line changes the API and is only in alpha. So this patch points react-native-pdf at a small fork of the current version where those two methods honor the ignore setting like the rest of the library — a Kotlin-only change, with the native code untouched and no change to how PDFs render. It also drops the older copy of the library that the PDF viewer pulls in alongside the fork, since otherwise the build fails with two copies of the same classes. The fork follows the same pattern as the other forks react-native-pdf already uses (zacharee, IvanIhnatsiuk) and can be dropped once an official fixed release is usable.

Fixed Issues

$ #93839
PROPOSAL: #93839 (comment)

Tests

Android-only native fix (a dependency repoint — no JS surface to unit-test). The crash is a non-deterministic teardown race (Sentry "Reproduction: Unknown"), so it is verified with a deterministic instrumentation regression test committed in the fork (Expensify/PdfiumAndroidKt#2) that forces openPage() on an already-closed document.

With the fix: the test passes — openPage(0) on a closed PdfDocument returns instead of throwing.
Baseline (fix reverted): fails with IllegalStateException: Already closed at PdfDocument.openPage — the exact APP-1VG signature.

📹 Recording of both runs (fail → pass):

Kapture.2026-07-12.at.19.37.19.mp4

Run it — re-runnable (clones if absent, otherwise reuses and resets the existing clone). Needs ANDROID_HOME set and an AVD; it boots a headless emulator if none is connected (then shuts it down), accepts SDK licenses, and repoints the fork's pinned NDK to whatever you have installed (the native part is a thin JNI wrapper over the prebuilt libpdfium.so, so any recent NDK works). It first reverts to the pre-fix code and runs (fails with Already closed), then restores the fix and runs again (passes):

git clone https://github.com/Expensify/PdfiumAndroidKt 2>/dev/null
if cd PdfiumAndroidKt 2>/dev/null && git rev-parse --git-dir >/dev/null 2>&1; then
  git fetch origin pull/2/head && git checkout -f FETCH_HEAD
  SDK="${ANDROID_HOME:-$ANDROID_SDK_ROOT}"; ADB="$SDK/platform-tools/adb"
  yes | "$SDK/cmdline-tools/latest/bin/sdkmanager" --licenses >/dev/null 2>&1 || true
  NDK=$(ls "$SDK/ndk" 2>/dev/null | sort | tail -1)
  [ -n "$NDK" ] && sed -i.bak "s/ndkVersion = \"[0-9.]*\"/ndkVersion = \"$NDK\"/" pdfiumandroid/build.gradle.kts
  BOOTED=""
  if [ -z "$("$ADB" devices | awk 'NR>1 && $2=="device"{print;exit}')" ]; then
    AVD=$("$SDK/emulator/emulator" -list-avds | head -1)
    [ -n "$AVD" ] && { "$SDK/emulator/emulator" -avd "$AVD" -no-window -no-boot-anim -gpu swiftshader_indirect >/dev/null 2>&1 & BOOTED=1; "$ADB" wait-for-device; until [ "$("$ADB" shell getprop sys.boot_completed 2>/dev/null | tr -d '\r')" = "1" ]; do sleep 2; done; }
  fi
  run() { ./gradlew :pdfiumandroid:connectedDebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=io.legere.pdfiumandroid.AlreadyClosedOpenPageTest; }
  F=pdfiumandroid/src/main/java/io/legere/pdfiumandroid/PdfDocument.kt
  git checkout 2052da7 -- "$F" && run; git checkout HEAD -- "$F" && run
  [ -n "$BOOTED" ] && "$ADB" emu kill
fi

baseline (fix reverted) → FAILS with IllegalStateException: Already closed at PdfDocument.openPage.
then the fix restored → PASSES (BUILD SUCCESSFUL).

The definitive production signal is the APP-1VG crash rate in Sentry after release.

Offline tests

This change does not affect offline behavior. It only changes how the native PDF library handles a render that races view teardown; an already-downloaded PDF renders identically offline.

QA Steps

Android only — on-device smoke check that PDFs still render normally and that rapidly opening/closing a rendering PDF no longer crashes. (The fix itself is covered by the regression test in Tests; the production signal is the APP-1VG crash rate in Sentry post-deploy.)

On Android, open a chat/expense with a multi-page PDF receipt or attachment (e.g. https://github.com/Expensify/App/blob/main/assets/pdfs/PDSAndFSG.pdf).
Open it full-screen, scroll through the pages, and verify it renders correctly (no regression).
Rapidly close and reopen it several times while it is rendering, and verify the app does not crash.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Kapture.2026-07-13.at.08.53.20.mp4

Android: mWeb Chrome

Kapture.2026-07-13.at.08.57.59.mp4

iOS: Native

Kapture.2026-07-13.at.07.26.21.mp4

iOS: mWeb Safari

Kapture.2026-07-13.at.08.28.51.mp4

MacOS: Chrome / Safari

Kapture.2026-07-13.at.04.28.36-compressed.mp4

…crash Repoint react-native-pdf's pdfiumandroid dependency to a JitPack fork whose PdfDocument.openPage/openTextPage route through handleAlreadyClosed instead of an unconditional check(!isClosed). The IGNORE behavior patch 002 already configures now reaches the exact call that crashed on the renderer thread when a receipt render raced with PDF view teardown.

…ready-closed-render-crash

github-actions · 2026-06-29T19:24:21Z

⚠️ This PR is possibly changing native code and/or updating libraries, it may cause problems with HybridApp. Please check if any patch updates are required in the HybridApp repo and run an AdHoc build to verify that HybridApp will not break. Ask Contributor Plus for help if you are not sure how to handle this. ⚠️

A native Android build surfaced a duplicate-class failure (:checkDuplicateClasses): AndroidPdfViewer pulls io.legere:pdfiumandroid transitively, which carries the same io.legere.pdfiumandroid.* classes as the fork under a different coordinate. Exclude the transitive copy and depend on the fork directly so a single coordinate provides those classes. Verified on a standalone NewDot Android build (BUILD SUCCESSFUL, checkDuplicateClasses passes; dependencyInsight shows the fork resolved and io.legere:pdfiumandroid absent).

wildan-m · 2026-06-30T01:30:12Z

@mountiny @eVoloshchak — quick question. It needs a small custom build of the PDF library, and I'd like to host it wherever you're comfortable.

Why we need it: the crash comes from one method in the pdfiumandroid library that throws when a PDF gets closed mid-render. The app already tells the library to ignore that case, but this one method doesn't respect that setting. No official release fixes it in a way we can use — the current 1.x line is stuck on the buggy version, and the newer line fixes it but changes the API in a way that breaks the PDF viewer we depend on (and it's still alpha). So the only option is a small patched build of the current version — a one-method change, with the native code left untouched. I've verified it: the crash reproduces before the fix and is gone after, with no rendering regression.

Where should it live? It's temporarily on my personal fork (com.github.wildan-m) like the zacharee/IvanIhnatsiuk forks already in react-native-pdf. Please let me know how to host it on Expensify's repo.

mountiny · 2026-06-30T08:00:34Z

You can make patch to the library cant you

wildan-m · 2026-06-30T14:26:38Z

@mountiny good idea, and that's actually what we already do where we can — react-native-pdf itself is in node_modules, so patch 002 patches it to flip the "ignore already-closed" switch.

The problem is the bug is one method inside pdfiumandroid, and that one isn't in node_modules — it's a prebuilt library (an .aar file) Gradle downloads from Maven at build time. There's no source file there for patch-package to edit. The only way to change a method inside it is to rebuild the library from source with the fix — and that's exactly what the fork is (the same one-line change, just compiled in).

mountiny · 2026-06-30T17:20:12Z

Ok I think given all the options our fork with the fix is the best approach

Can you point me to the right repo and version that we need to fork?

wildan-m · 2026-06-30T21:34:38Z

@mountiny fork https://github.com/wildan-m/PdfiumAndroidKt (a fork of the official johngray1965/PdfiumAndroidKt, pinned at 1.0.35 + the one-file fix). JitPack builds tag 1.0.35-already-closed-fix.3; once it's on the Expensify org I'll repoint the patch.

mountiny · 2026-07-02T15:12:13Z

Tracked the Expensify org fork request in an internal Ring Zero issue: https://github.com/Expensify/Expensify/issues/655446

@wildan-m @mountiny — once Ring Zero creates Expensify/PdfiumAndroidKt with tag 1.0.35-already-closed-fix.3 and JitPack builds com.github.Expensify:PdfiumAndroidKt:1.0.35-already-closed-fix.3, please repoint patch 004 from com.github.wildan-m to com.github.Expensify.

wildan-m · 2026-07-03T07:45:47Z

@mountiny can't acess the link. is it created?

mountiny · 2026-07-05T14:17:15Z

Fork is here https://github.com/Expensify/PdfiumAndroidKt

mountiny · 2026-07-05T14:18:25Z

thread to discuss here https://expensify.slack.com/archives/C01GTK53T8Q/p1783261052206059 @eVoloshchak

…ready-closed-render-crash

Move the PdfiumAndroidKt fork dependency off the personal com.github.wildan-m coordinate onto the Expensify org: com.github.Expensify:PdfiumAndroidKt:e6c06c2905d1adf8b76f28c7440a2006033ca4c8 Pinned by commit rather than the expensify-already-closed-fix-v1 tag because JitPack cached a transient failed build of that tag (an UnknownHostException on services.gradle.org while fetching the Gradle wrapper). The commit coordinate is a fresh JitPack version key that builds green (BUILD SUCCESSFUL, pom+aar 200) and pins the exact same immutable commit the tag points to. Can switch to the tag once an Expensify JitPack admin rebuilds it.

…ready-closed-render-crash

melvin-bot · 2026-07-13T02:05:16Z

@eVoloshchak Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7afeef740e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-07-13T02:12:11Z

+    implementation('com.github.zacharee:AndroidPdfViewer:4.0.1') {
+        exclude group: 'io.legere', module: 'pdfiumandroid'
+    }
+    implementation 'com.github.Expensify:PdfiumAndroidKt:e6c06c2905d1adf8b76f28c7440a2006033ca4c8'


Use the fork's published module coordinate

For Android builds, this dependency is resolving the JitPack root aggregate for a multi-module repo, not the pdfiumandroid AAR that replaces io.legere:pdfiumandroid. The fork's jitpack.yml only publishes the :pdfiumandroid module, and JitPack's module coordinate for that is com.github.Expensify.PdfiumAndroidKt:pdfiumandroid:<sha>; with the current root coordinate Gradle either cannot resolve the artifact or may pull the aggregate instead of the class-compatible library after the original transitive dependency has been excluded.

Useful? React with 👍 / 👎.

Thanks — I checked this against JitPack and the current root coordinate is correct; the suggested submodule coordinate doesn't exist.

com.github.Expensify:PdfiumAndroidKt:e6c06c2905d1adf8b76f28c7440a2006033ca4c8 resolves the real library AAR (.aar → 200, ~9.9 MB): a classes.jar containing the 123 io.legere.pdfiumandroid.* classes, plus jni/{arm64-v8a,armeabi-v7a,x86,x86_64}/libpdfium.so and libpdfiumandroid.so. So after excluding the transitive io.legere:pdfiumandroid, this coordinate supplies the same classes (with the fix) — it's not an empty aggregate, and nothing goes missing.

The suggested com.github.Expensify.PdfiumAndroidKt:pdfiumandroid:e6c06c2905d1adf8b76f28c7440a2006033ca4c8 returns 404 for both .pom and .aar. The fork's jitpack.yml builds only :pdfiumandroid (./gradlew :pdfiumandroid:publishToMavenLocal), so JitPack maps the root coordinate to that module's artifact — which is also why the previously build-verified com.github.wildan-m:PdfiumAndroidKt fork used the same root form.

eVoloshchak · 2026-07-13T13:09:44Z

Reviewer Checklist

Screenshots/Videos

Android: HybridApp

screen-20260713-182957-1783960147652.mp4

Android: mWeb Chrome

Screen.Recording.2026-07-13.at.18.53.28.mov

iOS: HybridApp

Screen.Recording.2026-07-13.at.18.45.07.mov

iOS: mWeb Safari

Screen.Recording.2026-07-13.at.18.50.42.mov

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/69474603-854a-4f68-8e50-3a06669f01e8

mountiny · 2026-07-13T13:19:18Z

How is this looking @eVoloshchak @wildan-m ?

wildan-m · 2026-07-13T14:02:05Z

@mountiny @eVoloshchak PR is ready, let me know if you have any feedback

eVoloshchak · 2026-07-13T14:19:00Z

Testing this at the moment

eVoloshchak

LGTM!

mountiny

Thank you

github-actions · 2026-07-13T18:02:10Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-07-13T18:26:14Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #94894.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-0c03997e60d-3fececf-cf20453f4f8d49e391bade9488d84b8e9080c819/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-0c03997-3fececf-339c3c260792fc150a49b3004e21a2f5f2edcb36/index.html

Web 🕸️
https://94894.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-07-14T11:36:22Z

🚀 Deployed to staging by https://github.com/mountiny in version: 9.4.34-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

wildan-m added 2 commits June 18, 2026 00:12

Merge remote-tracking branch 'upstream/main' into wildan/93839-pdf-al…

1ec9aea

…ready-closed-render-crash

melvin-bot Bot assigned wildan-m Jun 29, 2026

eVoloshchak mentioned this pull request Jul 6, 2026

Already closed openpage fix Expensify/PdfiumAndroidKt#1

Closed

2 tasks

wildan-m mentioned this pull request Jul 7, 2026

Honor AlreadyClosedBehavior in openPage/openTextPage (v1.0.35-based, for the Expensify JitPack pin) Expensify/PdfiumAndroidKt#2

Open

wildan-m added 4 commits July 11, 2026 04:12

Merge remote-tracking branch 'upstream/main' into wildan/93839-pdf-al…

f24922f

…ready-closed-render-crash

docs(patch 004): add PR-introducing-patch link to match house style

2aeae32

Merge remote-tracking branch 'upstream/main' into wildan/93839-pdf-al…

7afeef7

…ready-closed-render-crash

wildan-m marked this pull request as ready for review July 13, 2026 02:05

wildan-m requested a review from a team as a code owner July 13, 2026 02:05

melvin-bot Bot requested review from eVoloshchak and removed request for a team July 13, 2026 02:05

chatgpt-codex-connector Bot reviewed Jul 13, 2026

View reviewed changes

eVoloshchak approved these changes Jul 13, 2026

View reviewed changes

melvin-bot Bot requested a review from mountiny July 13, 2026 17:13

mountiny approved these changes Jul 13, 2026

View reviewed changes

mountiny merged commit 0c03997 into Expensify:main Jul 13, 2026
29 of 32 checks passed

OSBotify mentioned this pull request Jul 14, 2026

Deploy Checklist: New Expensify 2026-07-14 #96044

Open

Uh oh!

Conversation

wildan-m commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

wildan-m commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mountiny commented Jun 30, 2026

Uh oh!

wildan-m commented Jun 30, 2026

Uh oh!

mountiny commented Jun 30, 2026

Uh oh!

wildan-m commented Jun 30, 2026

Uh oh!

mountiny commented Jul 2, 2026

Uh oh!

wildan-m commented Jul 3, 2026

Uh oh!

mountiny commented Jul 5, 2026

Uh oh!

mountiny commented Jul 5, 2026

Uh oh!

melvin-bot Bot commented Jul 13, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 13, 2026

Choose a reason for hiding this comment

Uh oh!

wildan-m Jul 13, 2026

Choose a reason for hiding this comment

Uh oh!

eVoloshchak commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

mountiny commented Jul 13, 2026

Uh oh!

wildan-m commented Jul 13, 2026

Uh oh!

eVoloshchak commented Jul 13, 2026

Uh oh!

eVoloshchak left a comment

Choose a reason for hiding this comment

Uh oh!

mountiny left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Jul 13, 2026

Uh oh!

github-actions Bot commented Jul 13, 2026

Uh oh!

OSBotify commented Jul 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wildan-m commented Jun 29, 2026 •

edited

Loading

wildan-m commented Jun 30, 2026 •

edited

Loading

eVoloshchak commented Jul 13, 2026 •

edited

Loading