[$250] Android - Attachment - App crashes after taking a photo

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.28-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-7270/folder/13176710/41236934/1223431805?issue_type=jira
Email or phone of affected tester (no customers): isodjnosidjiojiojiso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Other

Action Performed:

1. Launch Expensify app.
2. Go to any chat.
3. Tap + > Add attachment > Take photo.
4. Take a photo and tap OK.

Expected Result:

App will not crash.

Actual Result:

App crashes.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7092388_1772494018585.Screen_Recording_20260303_072534_Expensify.mp4

log.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028785756915839677
• Upwork Job ID: 2028785756915839677
• Last Price Increase: 2026-03-10

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

Proposal

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

On Android, taking a photo via the attachment picker (+ > Add attachment > Take photo) causes the app to crash immediately after the user taps OK to confirm the photo.

What is the root cause of that problem?

The crash originates in react-native-image-picker v7.1.2's Utils.java. After the camera returns a result, getResponseMap calls isImageType, which calls getMimeType. Inside getMimeType, when the URI scheme is content, the code calls contentResolver.getType(uri) and then immediately invokes .isBlank() on the result — but ContentResolver.getType() is documented to return null when the type is unknown, which causes a NullPointerException crash. On Android 16 (the OS version reported in the bug), this null return appears to happen consistently for the file-provider content URI used by the camera capture flow.

https://github.com/Expensify/App/blob/bf2ae7e4cd5d3eb36199aaaf247ce37ca205a5c3/node_modules/react-native-image-picker/android/src/main/java/com/imagepicker/Utils.java#L398-L413

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

Add a third patch file for react-native-image-picker that adds a null-guard before calling .isBlank() in getMimeType. The fix follows the same patch infrastructure already used in patches/react-native-image-picker/.

// node_modules/react-native-image-picker/android/src/main/java/com/imagepicker/Utils.java

  static String getMimeType(Uri uri, Context context) {
      if (uri.getScheme().equals("file")) {
          return MimeTypeMap.getSingleton().getMimeTypeFromExtension(MimeTypeMap.getFileExtensionFromUrl(uri.toString()));
      } else if (uri.getScheme().equals("content")) {
          ContentResolver contentResolver = context.getContentResolver();
          String contentResolverMimeType = contentResolver.getType(uri);

-         if (contentResolverMimeType.isBlank()) {
+         if (contentResolverMimeType == null || contentResolverMimeType.isBlank()) {
              return getMimeTypeForContent(uri, context);
          } else {
              return contentResolverMimeType;
          }
      }

      return "Unknown";
  }

The patch file should be placed at patches/react-native-image-picker/react-native-image-picker+7.1.2+003+null-check-getMimeType.patch and a corresponding entry added to patches/react-native-image-picker/details.md. This is a one-line null-guard that matches how Android's own documentation specifies the API behaves, and it unblocks the fallback getMimeTypeForContent path that already exists for exactly this scenario.

What alternative solutions did you explore? (Optional)

N/A

[MelvinBot]

Proposal

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

On Android (Samsung Galaxy S25 FE / Android 16), the app crashes after taking a photo via Chat → + → Add attachment → Take photo → OK. This is a regression in v9.3.28-0, reproducible in both staging and production.

What is the root cause of that problem?

The crash is most likely caused by Android 16's 16KB page alignment enforcement combined with react-native-image-picker v7.1.2 never having been updated for Android 16 / SDK 36 compatibility.

The crash mechanism:

When the user taps "Take photo," the AttachmentPicker calls launchCamera (launchCamera.android.ts:12-30), which launches a camera Intent via react-native-image-picker's ImagePickerModuleImpl.java using startActivityForResult. When the system camera opens in the foreground, the OS may kill the Expensify app process to reclaim memory. After the user taps OK, Android tries to restore the Expensify process, which requires reloading all native .so libraries. If any .so file has 4KB-aligned ELF segments instead of the 16KB alignment required by Android 16, the process crashes with a native SIGBUS/SIGSEGV.

Supporting evidence:

1. The app targets SDK 36 (android/build.gradle:6-7: compileSdkVersion = 36, targetSdkVersion = 36) which requires 16KB page alignment on Android 16 devices
2. react-native-image-picker was never updated for 16KB compatibility — it still targets compileSdkVersion 33 / targetSdkVersion 33 (at node_modules/react-native-image-picker/android/build.gradle:11,29). Issue [Due for payment 2026-03-13] [Due for payment soon?] Enable 16KB memory page size on Android #63871 drove 16KB alignment updates to many libraries (VisionCamera, blob-util, expo-image, onfido, mapbox, react-native-pdf, group-ib-fp, Fresco) but react-native-image-picker was missed
3. ELF alignment enforcement had to be reverted once already — PR [NoQA] Enable ELF alignment check on android adhoc builds #82832 enabled it (2026-02-18), PR [NoQA] Set buildAdhoc validate-elf-alignment: false #82893 reverted it one day later (2026-02-19), and PR [NoQA] Enable ELF alignment CI check #82930 re-enabled it (2026-03-03). The PR [NoQA] Enable ELF alignment CI check #82930 description explicitly states a "potential fix that should go first" exists in Mobile-Expensify PR [HOLD for payment 2023-01-16] [$1000] Android - Connect Manually -The App can crash after clicking on the back button during manual Bank account flow #13857, confirming alignment issues were known
4. Samsung Galaxy S25 FE with Android 16 is one of the first consumer devices enforcing 16KB page sizes, making this the first time the issue would surface in regression testing

Alternative consideration: If the crash is not 16KB-alignment-related, a secondary candidate is a NullPointerException in Utils.getMimeType() (Utils.java:405) where contentResolver.getType(uri) can return null and .isBlank() is called without a null check. However, for camera captures, the code uses a file:// URI which takes a different code branch, making this less likely.

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

1. First: Obtain the actual crash trace (logcat/Sentry) from a Samsung Galaxy S25 FE running Android 16 to confirm whether this is a SIGBUS/SIGSEGV (alignment crash) or a Java exception
2. If alignment-related: Upgrade react-native-image-picker to a version compatible with 16KB page alignment, or patch the native build to ensure its dependencies are properly aligned. Check if Mobile-Expensify PR [HOLD for payment 2023-01-16] [$1000] Android - Connect Manually -The App can crash after clicking on the back button during manual Bank account flow #13857 already addresses this
3. If Java NPE: Apply a null-safety fix to Utils.getMimeType() by adding a null check on the contentResolver.getType(uri) return value at Utils.java:405, either by patching the library or upgrading to a newer version that fixes this

What alternative solutions did you explore? (Optional)

• Replacing react-native-image-picker entirely: The IOURequestStepScan flow already uses react-native-vision-camera directly for receipt scanning, which has been updated for 16KB alignment. The AttachmentPicker could be refactored to use VisionCamera instead, but this is a larger scope change
• Adding a custom launchCamera implementation: Use the newer Activity Result API (registerForActivityResult) instead of the deprecated startActivityForResult pattern in react-native-image-picker, which may also improve compatibility with Android 16's stricter activity lifecycle handling

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

On Android 16 (Samsung Galaxy S25 FE), the app crashes immediately after taking a photo via the attachment picker (+ > Add attachment > Take photo > OK).

What is the root cause of that problem?

The crash is a NullPointerException in react-native-image-picker's Utils. After the camera returns a result, the library calls getImageResponseMap() which calls getImageDimensions(). Inside getImageDimensions(), getOrientation() is called at line 160, which returns exifInterface.getAttribute(ExifInterface.TAG_ORIENTATION) — this can return null when the EXIF orientation tag is absent from the captured image.

The null orientation is then passed to needToSwapDimension() at line 200, which calls orientation.equals(...) on the null value, causing the NPE crash. On Android 16, certain camera implementations no longer guarantee the EXIF orientation tag is written, making this null return consistent.

This is distinct from the getMimeType() NPE identified in MobileMage's proposal. The camera capture flow uses a file:// URI (created via Uri.fromFile() at line 211), so the content:// branch in getMimeType() where contentResolverMimeType.isBlank() can NPE is never reached during camera capture. The actual crash path is: onActivityResult → onAssetsObtained → getResponseMap → getImageResponseMap → getImageDimensions → getOrientation returns null → needToSwapDimension(null) → NPE.

Additionally, setOrientation() at line 253 has the same null-unsafe pattern: orientation.equals(...) will NPE if orientation is null.

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

Add a patch file at patches/react-native-image-picker/react-native-image-picker+7.1.2+003+null-safe-orientation.patch that null-guards orientation in both needToSwapDimension and setOrientation:

--- a/node_modules/react-native-image-picker/android/src/main/java/com/imagepicker/Utils.java
+++ b/node_modules/react-native-image-picker/android/src/main/java/com/imagepicker/Utils.java
@@ -197,7 +197,10 @@ class Utils {
     }
 
     private static boolean needToSwapDimension(String orientation){
-        return orientation.equals(String.valueOf(ExifInterface.ORIENTATION_ROTATE_90))
+        if (orientation == null) {
+            return false;
+        }
+        return orientation.equals(String.valueOf(ExifInterface.ORIENTATION_ROTATE_90))
                 || orientation.equals(String.valueOf(ExifInterface.ORIENTATION_ROTATE_270));
     }
 
@@ -250,7 +253,7 @@ class Utils {
 
     static void setOrientation(File file, String orientation, Context context) throws IOException {
-        if (orientation.equals(String.valueOf(ExifInterface.ORIENTATION_NORMAL)) || orientation.equals(String.valueOf(ExifInterface.ORIENTATION_UNDEFINED))) {
+        if (orientation == null || orientation.equals(String.valueOf(ExifInterface.ORIENTATION_NORMAL)) || orientation.equals(String.valueOf(ExifInterface.ORIENTATION_UNDEFINED))) {
             return;
         }

A corresponding entry should be added to patches/react-native-image-picker/details.md.

What alternative solutions did you explore? (Optional)

MobileMage's proposal targets the getMimeType() null check on contentResolverMimeType.isBlank(). While that is a legitimate bug for the gallery/content-picker flow, it is not the crash path for camera capture — camera uses a file:// URI which takes a completely different branch in getMimeType(). That fix alone would not resolve this issue. Ideally both patches should be applied (the getMimeType null guard for gallery picks, and this orientation null guard for camera captures), but the orientation fix is the one that addresses the reported crash scenario.

[abbasifaizan70]

Proposal

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

The app crashes immediately after taking a photo via the attachment picker

What is the root cause of that problem?

When the user opens the system camera from the chat attachment flow, the main activity goes to the background. Android can recreate the activity when the user returns (e.g. due to low memory, “Don’t keep activities” in Developer Options, or normal lifecycle behavior). When the activity is recreated, the system calls onCreate(savedInstanceState) with a non-null bundle so the activity can restore its state.

In MainActivity.kt, the code calls super.onCreate(null) instead of super.onCreate(savedInstanceState).

App/android/app/src/main/java/com/expensify/chat/MainActivity.kt

Lines 38 to 42 in bf2ae7e

	override fun onCreate(savedInstanceState: Bundle?) {
	BootSplash.init(this)
	super.onCreate(null)
	if (resources.getBoolean(R.bool.portrait_only)) {
	requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT

Passing null tells the Android framework that there is no saved state, so the activity (and React Native) are treated as a fresh start. That can leave the app in an inconsistent state when the camera result is delivered (e.g. via onActivityResult). The recreated activity may try to restore or run against torn-down or mismatched UI/bridge state, which can lead to a crash instead of returning to the chat with the photo attached.

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

Pass savedInstanceState to super.onCreate() so the activity (and React Native) restore state when the activity is recreated after returning from the camera. That keeps the app in a consistent state when the image picker result is applied and prevents the crash.

Location: App/android/app/src/main/java/com/expensify/chat/MainActivity.kt

Solution (code change):

diff --git a/App/android/app/src/main/java/com/expensify/chat/MainActivity.kt b/App/android/app/src/main/java/com/expensify/chat/MainActivity.kt
index 1234567890..abcdef1234 100644
--- a/App/android/app/src/main/java/com/expensify/chat/MainActivity.kt
+++ b/App/android/app/src/main/java/com/expensify/chat/MainActivity.kt
@@ -37,7 +37,7 @@ class MainActivity : ReactActivity() {
 
     override fun onCreate(savedInstanceState: Bundle?) {
         BootSplash.init(this)
-        super.onCreate(null)
+        super.onCreate(savedInstanceState)
         if (resources.getBoolean(R.bool.portrait_only)) {
             requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
         }

Replace super.onCreate(null) with super.onCreate(savedInstanceState) so that when the activity is recreated after taking a photo, the framework restores the activity state and the app does not crash; the user returns to the chat and the captured image can be attached correctly.