[Image_picker] fix rotation regression on Android.

[cyanglaz]

Description

A regression was introduced in #2293 where the image file seems to lose rotation when not scaled. Reverting to previous approach: directly return the original image file path solves the issue.
The root cause of why image file would lose rotation after compressing is unknown.

Related Issues

flutter/flutter#45905

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[cyanglaz]

@mklim Could you take a look at this one? Should be pretty straight forward.

[mklim]

The previous PR was fixing a crash though, wasn't it? Do we want to completely revert it to fix the rotation issue and then re-introduce the crash? I think it may be better to try to root cause the issue and forward fix it in this case, especially since this has been landed for awhile now.

[cyanglaz]

The previous PR was fixing a crash though, wasn't it? Do we want to completely revert it to fix the rotation issue and then re-introduce the crash? I think it may be better to try to root cause the issue and forward fix it in this case, especially since this has been landed for awhile now.

We didn't completely revert it in this PR. We only revert the part that caused the rotation issue. Which also won't reintroduce the crash.
However, the root cause of rotation issue is that in the last PR we copied the file even if we don't scale. I'm not sure why it caused the rotation issue through.

This PR remove the copy file part if we don't have to do anything with the image (scaling, compression, etc).

[ened]

@cyanglaz how could we test this PR? There are no test_driver calls (I guess it's not feasible to pick image in a automated way) plus the example has no fields / configuration for maxWidth, maxHeight or imageQuality.

As a first start, could you possibly add some sort of configuration UI to the example so that manual tests could be done?

[mklim]

LGTM pending testing discussion.

@ened there is a small change to the Robolectric ImageResizerTest.java that checks part of the behavior in this PR and meets our minimum testing requirement, but it's not really catching the main rotation regression like you've pointed out. I'm not sure of a good way to test this either. Flutter driver would be ideal if we could make that work, but I suspect getting a working test here may not be totally feasible. I think the best compromise would be to add something to ImageResizerTest that actually catches the rotation issue, but IIRC that's not really going to be possible either because Robolectric itself stubs out Bitmap with dummy data values that always return the same thing regardless of what "real" images you try to create with the code under test. @cyanglaz do you have any ideas for how to test the rotation regression specifically?

[cyanglaz]

@mklim I couldn't find a good way to add an integration test for this. I think what @ened mentioned about adding a manual test makes sense. It would help us test the plugin easier manually in the future. I'm going to add one in the example app and ping you once it's done.

[ened]

In my mind, the pragmatic way would be to implement a Android instrumentation (not unit) test, that copies a set of pre-defined assets onto a device. The test then runs a ImageResizer implementation against those and checks the output file (like a golden test, really).
There are some risks like different Android phones (& their JPG encoders) may have a tiny bit of different output, but that should be a solved problem in the testing world.

Secondly, the e2e test should have a way to assert the correct ImageResizer implementation is called.

All in all quite complicated so perhaps easier to solve the problem first and add a way for developer-users to manually test the function. That is still a lot better than anything we have now.
Anything we can give people to verify the correct function of a plugin will be helpful.

[cyanglaz]

@ened @mklim Added a dialog to specify maxWidth, maxHeight and quality when picking image in the example app. That should be able to help manual test.

[ened]

LGTM

[mklim]

LGTM

[mklim]

nit: This title isn't really descriptive. "Set image size" maybe?

[cyanglaz]

good find! Thanks. I updated it Add optional parameters