Skip to content

Conversation

@alpesh12
Copy link
Contributor

@alpesh12 alpesh12 commented Jan 16, 2018

Platforms affected

  • Android

What does this PR do?

  • Throws an exception which can be caught by the error block in Cordova app which uses the plugin
  • Does not crash the Cordova app which uses the plugin with corrupted image

What testing has been done on this change?

Tested with cordova-android 7.0.0

Checklist

  • Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
  • Reported an issue in the JIRA database
  • Added automated test coverage as appropriate for this change.

@alpesh12
Copy link
Contributor Author

@infil00p
Can you please merge this changes to master because i have not change anything related to iOS platform.

try {
fileStream = FileHelper.getInputStreamFromUriString(imageUrl, cordova);
image = BitmapFactory.decodeStream(fileStream);
} catch (OutOfMemoryError e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to catch any exception and not only OutOfMemoryError, it might fail due to other reasons, and then in the error callbackContext.error provide the exception message

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Exception will catch all exceptions including OutOfMemoryError. So do I need to change or you will?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alpesh12 You need to change this before I accept the PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@infil00p ok will do after testing.

Copy link
Contributor Author

@alpesh12 alpesh12 Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@infil00p @jcesarmobile Now its done can you please merge changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@infil00p i just check travis build failed for iOS can you please help or guide me to successful complete travis test
Thank you

@alpesh12 alpesh12 changed the title CB-13415 (android) Importing corrupt images using the Camera plugin c… CB-13415 (android)(iOS) Importing corrupt images using the Camera plugin c… Jan 19, 2018
@infil00p
Copy link
Member

We're still getting Travis issues on iOS 10 since the change to iOS.

@alpesh12
Copy link
Contributor Author

@infil00p Whats is the next step to pass Travis test any guideline or help will be appreciates

@jcesarmobile
Copy link
Member

I would keep the iOS and the Android parts separated (i.e. creating a new issue for iOS and removing the iOS code from this PR, and then send a new PR with the iOS code)
I don't really like the iOS approach, there are probably better solutions than using ALAssetsLibrary. Also the possible errors are just being logged, but not returned to the user.

@alpesh12
Copy link
Contributor Author

@jcesarmobile
Removed iOS code from this PR.

@alpesh12 alpesh12 changed the title CB-13415 (android)(iOS) Importing corrupt images using the Camera plugin c… CB-13415 (android)Importing corrupt images using the Camera plugin c… Jan 25, 2018
@alpesh12 alpesh12 changed the title CB-13415 (android)Importing corrupt images using the Camera plugin c… CB-13415 (android) Importing corrupt images using the Camera plugin c… Jan 25, 2018
@alpesh12
Copy link
Contributor Author

@jcesarmobile @infil00p

Can you please check appveyor test i think there are some issue with that, for all last build it will take only 2-3 minutes but this time it will take 5hr then also its on queue state.
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-plugin-camera/history
Thank you

@jcesarmobile
Copy link
Member

Sometimes tests take a lot of time, I don't think we can control that.
The iOS file is still a bit different, can you remove it from the PR?

@alpesh12
Copy link
Contributor Author

alpesh12 commented Jan 25, 2018

@jcesarmobile Done
Also for iOS PR i am not able to fork new one, so i have to wait for complete this PR right?

@jcesarmobile
Copy link
Member

Best thing is to work in branches, so you can create a new CB-13415 branch with your current content, and reset your master to match the apache master, then create a new branch from master and do the changes there

@alpesh12
Copy link
Contributor Author

@jcesarmobile
When this changes are merged to master?

@jcesarmobile
Copy link
Member

When somebody has time to properly test it and merge it.
Please, relax and stop pinging people every day, this is a free open source project and we do things in our spare time (or me at least).

BTW, I still see the iOS file as modified, even though it shows not changes. Can you remove the file from the PR entirely?

@jcesarmobile
Copy link
Member

I've finally tested and the problem is only present when Camera.DestinationType.DATA_URL, so I don't think the problem is the corrupted image itself, but the common out of memory problem when using DATA_URL. The sample image is 4MB, that shouldn't be a problem, but maybe being corrupted increase the memory needed to handle it.

In the docs you can read:

NOTE: Photo resolution on newer devices is quite good. Photos selected from the device's gallery are not downscaled to a lower quality, even if a quality parameter is specified. To avoid common memory problems, set Camera.destinationType to FILE_URI rather than DATA_URL.

So, I don't think you should hardcode the OutOfMemoryError to corrupted image as any big image not corrupted will also cause the OutOfMemoryError.
So, @infil00p do you think we should hardcode it to something else? or just return the e.getMessage() or e.getLocalizedMessage()?
The truth is the messages returned are not very helpful, is "failed to allocate xxxx byte allocation with yyyy free bytes and zzMB until OOM"

@ShemrickFlannigan
Copy link

@jcesarmobile @infil00p I agree that the OutOfMemoryError is a catch all that is not specific to corrupt images.
But in our testing, the OutOfMemoryError is the only exception which we've found that successfully captures the corrupt images.
In our testing, there is no correlation with file size. The corrupts sample image which has been provided is < 5MB. The Cordova Camera app can handle non-corrupt images which are 40MB.

Here are the sample images:

Corrupt 5MB image:
https://www.dropbox.com/s/s7jh3eay3y23oy1/5mb_13500x13500.D2%5B1%5D.jpg?dl=0

Valid 40MB image:
https://www.dropbox.com/s/cnxykbcvkbc2k1k/Airbus_Pleiades_50cm_8bit_RGB_Yogyakarta.jpg?dl=0

I would like to move forward with the generic OutOfMemoryError as a catch all exception within this Pull Request, as it solves a high impact error (corrupt images crashing the entire Cordova app). Later, if/when a more accurate exception is found, it can be applied as an enhanced exception.

@jcesarmobile
Copy link
Member

I'm just talking about the error message returned
callbackContext.error("Corrupted image selected.");

I don't think we should hardcode the out of memory to "corrupted image selected".
In your tests a regular image of 40MB is not crashing, but probably in low end devices will crash, so with the update it will get the "Corrupted image selected." when that is not true.
In fact, I have tested your 40MB image in my moto G and I get the "Corrupted image selected.

@ShemrickFlannigan
Copy link

@jcesarmobile
Thanks for the clarification. I definitely agree that the error message should not be set to the fixed message "Corrupt image selected". I agree with your suggestion of returning the e.getMessage() or e.getLocalizedMessage() value

@alpesh12
Copy link
Contributor Author

@jcesarmobile @ShemrickFlannigan
added dynamic message as you suggest also @jcesarmobile for iOS code its showing me no changes can you please confirm.

@alpesh12
Copy link
Contributor Author

alpesh12 commented Feb 1, 2018

@jcesarmobile @infil00p
Any updates regarding merge

@jcesarmobile
Copy link
Member

jcesarmobile commented Feb 1, 2018

I would use the same e.getMessage() or e.getLocalizedMessage() for both, not one with e.getMessage() and the other e.getLocalizedMessage() (for consistency).

I've checked other plugins and cordova-plugin-file uses e.getLocalizedMessage(), so I would use e.getLocalizedMessage() for both.

The iOS file shows no changes, but appears as modified, so you should remove it from the PR, maybe with a git reset or something.

Ah, and remove the comments, I think there is no need.

@dwlrathod
Copy link

+1
This bug really need to fix. Facing same issue for big images.

@jcesarmobile
Copy link
Member

@alpesh12 can you remove the code comments?

Removed comments from CameraLauncher.java
@alpesh12
Copy link
Contributor Author

alpesh12 commented Feb 8, 2018

@jcesarmobile comment removed as you suggested.

@jcesarmobile jcesarmobile merged commit bf935df into apache:master Feb 8, 2018
@jcesarmobile
Copy link
Member

Merged, thanks!

Will try to take a look into the iOS one this weekend, but no promises

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants