fix(android): Prevent out of memory errors on Android when selecting large media (video) files from the gallery picker.

[Exigerr]

Platforms affected

Android

Motivation and Context

Changes from #906 resulted in all gallery picker results being read in full into a byte array.
See this line.

Reading in the data fully into memory works generally fine when dealing with images.
When handling larger files (videos for example), it will nearly always result in an out of memory error (reading too much data in one go).
With videos no transformation is required, the URI simply need to be returned.

Steps to recreate issue:

• On Android, trigger camera.getPicture with
  • destinationType as Camera.DestinationType.FILE_URI
  • mediaType as Camera.MediaType .VIDEO
  • sourceType as Camera.PictureSourceType.PHOTOLIBRARY
• Select a large video (typically > 200mb will do it for most devices)
• App will crash due to an Out of Memory exception
  • Similar to

  AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 268435472 byte allocation with 100663296 free bytes and 123MB until OOM, target footprint 239130480, growth limit 268435456

Description

Re-ordered and cleaned up the code for processResultFromGallery to only read the file data when required.
If its a video or MIME type which it cannot transform, then simply return the URI.
Similarly if the special case for just returning the path without scaling is met, avoid reading in any data.

Testing

• Tested image selection from gallery on Pixel 6a (Android 14 & Android 15) and Samsung S10 (Android 12) devices.
  • Range of different sized (MB) images.
• Tested video selection from gallery on Pixel 6a (Android 14 & Android 15) and Samsung S10 (Android 12) devices.
  • Range of different sized (MB) videos (10MB - 1GB).

No issues spotted. Images and videos were selected and saved into application storage without issue.

Checklist

• I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change
• Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• I've updated the documentation if necessary

[Exigerr]

@breautek thanks for triggering the automated checks.

Would you be able to kindly confirm that the failures on the automated checks are due to environment timeouts as opposed to this PRs code changes?

I've looked through the logs. From what I can tell they seem to be failing due to either timeouts when trying to setup devices or not having a suitable runner (iOS).

[breautek]

@breautek thanks for triggering the automated checks.

Would you be able to kindly confirm that the failures on the automated checks are due to environment timeouts as opposed to this PRs code changes?

I've looked through the logs. From what I can tell they seem to be failing due to either timeouts when trying to setup devices or not having a suitable runner (iOS).

Don't worry about Chrome and iOS here. Chrome always fails for anything that requires user intervention (aka to accept browser permissions).

iOS seems outdated, but your PR doesn't modify any shared code (e.g. JS) or iOS platform code, so you're good there.

Android 7.1 test is also probably CI environmental. Specifically that one fails frequently for some reason, across all of our repos. It's likely not related to your PR. I've only taken a glance at the PR myself but tbh I think you're good there.

[gabides]

Hi @breautek @Exigerr is there plans on merging this and deploying it? We think this could fix some of our issues with v8.0.0 of the plugin