Jpeg image corruption if writing location after updating some Exif attributes [263747161]

Fixed

Bug

Status Update

No update yet.

Description

ch...@google.com

created issue #1

Dec 27, 2022 02:07AM

Component used: Version used: Devices/Android versions reproduced on: Samsung A32 (sm-a325f) Android 12 (also A12/A13 mentioned in b/263289024)

When reporting bugs, please always include:

A full bug report as an attachment, captured during or shortly after experiencing the issue.

Bugreport on Samsung sm-a325f:

About 17:41 Install and launch the first test app to run with self-copy-exif and write-location-data on

About 17:42 Install and launch the second test app to take a picture

Reproduction steps, being as specific as possible.

I’m working for the CameraX project and one Exif location related issue (b/263289024) was reported. The issue seems like that can be reproduced on specific Samsung Android 12 devices (A13, A32, A12). I can reproduce the issue on a Samsung A32 (sm-a325f) Android device. After some investigation, I wrote a sample app which can reproduce the issue.

i. Please refer to the sample project in the attached MyApplication-ExifLocationIssue.zip. I use CameraX to capture a JPEG image on a Samsung A32 device and use it (put in the project assets folder) to reproduce the issue. Please compile and run the sample app to check the following cases and results: (This can be run on any device)

Self copy Exif Write location data Decode result file

Yes Yes Failed

Yes No Passed

No Yes Passed

Yes No Passed

ii. I don’t know what affects the test results. When using the above sample app, no matter which location provider data is set, the issue can be reproduced. But if I set the location data by CameraXBasic sample app just as what is reported in b/263289024. The issue only happens if the location data is specified as LocationManager#FUSED_PROVIDER data. The issue won’t happen when setting it as LocationManager#GPS_PROVIDER data. Please compile the attached CameraXBasic-WriteFusedLocation.zip and modify the location provider setting in the CameraFragment.kt to check the results. (This can be run on the problematically devices)

Self copy Exif	Write location data	Decode result file
Yes	Yes	Failed
Yes	No	Passed
No	Yes	Passed
Yes	No	Passed

How reproducible the issue is on the affected device.

100% on Samsung A32 (sm-a325f) Android 12 device

If known, how reproducible the issue is on other devices and OS versions.

Where possible, please also provide:

A sample project that reproduces the issue.

Please see the attached sample apps

A screenrecord or screenshots showing the issue.

dumpstate-2022-12-26-17-43-03.zip

13 MB

Download

deleted

Restricted+

0 B

CameraXBasic-WriteFusedLocation.zip

680 KB

Download

Comments

ap...@google.com <ap...@google.com> #2Jan 3, 2023 03:18AM

Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.

ib...@google.com <ib...@google.com> #3Mar 6, 2023 01:53PM

My chroming bug

ib...@google.com <ib...@google.com> #4Mar 6, 2023 04:04PM

We’d appreciate any update or timeline for fixing this issue.

I currently blocks any debugging on x86_64 emulators using Qt (see

https://bugreports.qt.io/browse/QTBUG-77113).

Thanks!

ib...@google.com <ib...@google.com> #5Mar 6, 2023 04:17PM

Allow I dont know what it all is

ib...@google.com <ib...@google.com> #6Mar 6, 2023 04:23PM

Feedback

ib...@google.com <ib...@google.com> #7Mar 6, 2023 04:54PM

Feedback

ch...@google.com <ch...@google.com> #8Mar 7, 2023 10:00AM

Hi, we recently pushed an emulator update to stable that should include SSE 4.1 support on macOS.

ib...@google.com <ib...@google.com> #9Mar 7, 2023 10:07AM

aaireill111@gmail.com

ib...@google.com <ib...@google.com> #10Mar 7, 2023 02:09PM

I can confirm that this works with the latest Android Studio. I think the issue can be closed.

ap...@google.com <ap...@google.com> #11Mar 7, 2023 04:16PM

jfinder@google.com - can you please assign this out? Thanks.

ib...@google.com <ib...@google.com> Mar 7, 2023 04:16PM

Marked as fixed.

mw...@gmail.com <mw...@gmail.com> #12Mar 7, 2023 05:51PM

This bug appears to have been fixed back in 2020 (comment #8), confirmed in 2021 (comment #10). I'll track down someone who can properly mark this bug as "fixed".

ib...@google.com <ib...@google.com> #13Mar 7, 2023 05:58PM

Are you sure it's an issue with the APP1 segment being too large with the FUSED location? I was thinking perhaps there's some issue with the length calculation that's happening as we were able to fix these images by just detecting the start of the jpeg image data and re-writing the length field based on that detection.

This fix is consistent with the current failure mode of ExifInterface when the APP1 segment gets 'too large' (before my change linked above in comment #11). The image ends up 'corrupt' because we have 0x10030 bytes to write to the APP1 segment, and ExifInterface does two things:

When writing the length of the APP1 segment it truncates this to 0x0030
It writes all those 0x10030 bytes out, and then it writes the rest of the image.

A JPEG parser (I assume) comes along and reads the length of the APP1 segment (0x30) and skips that many bytes, then expects to find JPEG data - but it's actually in the middle of the Exif and so it fails.

If you manually find the start of the JPEG data then you obviate both of the problems - and the image is 'fixed'.

na...@google.com <na...@google.com> #14Dec 13, 2023 06:33PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.exifinterface:exifinterface:1.3.7

na...@google.com <na...@google.com> #15Nov 13, 2024 06:19PM