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

We are Facing this same issue after updating to compose 1.3.0 and also only on Android 9 Devices.

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

Note: Some of the latest comments from

b/212982463

could be relevant to this issue

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

Hi, Is there any update on this. Any temp workaround would be helpful as well. Currently we have 10s of thousand users per day getting affected by this.

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

Project: platform/frameworks/support
Branch: androidx-main

commit e3164fbf4137f9cf60da424aef4b1d9ea5202b6c
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Thu Dec 15 18:00:23 2022

Make our fake Views we use as graphic layer to save nothing as the View's saved instance state.

Because the Views were attached to the hierarchy and had an id their state was saved polluting the state Activity saves in Bundle. Such views have no real state as they are not used as real views.

Test: ComposeViewSavedStateSizeTest
Bug: 260322832
Change-Id: I0b755a3d6a164b6c26aa592e13e206dc45cd5dd9

A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/platform/ComposeViewSavedStateSizeTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt

https://android-review.googlesource.com/2359699

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

Project: platform/frameworks/support
Branch: androidx-main

commit 326b394002e0f899fdc0bffc622761bc67bca21b
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Thu Dec 15 16:16:31 2022

Destroy layers added on the nodes when the node is removed

Currently the layer objects are not being removed from the AndroidComposeView in this situation, which means we are not reusing the layers and we keep them attached until the whole AndroidComposeView is not garbage collected.

Test: new test in MeasureAndLayoutDelegateTest
Bug: 260322832
Change-Id: Iaeee5662b4646230cebdafd2484c691df657edda

M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/Helpers.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/MeasureAndLayoutDelegateTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/NodeCoordinator.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/NodeKind.kt

https://android-review.googlesource.com/2359119

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

Great. Thank you very much for fixing this. Really appreciate the quick response. Could you share which version this fix will be released?

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

Hi there! Most likely next release of Compose UI, by mid January. Cheers.

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

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

androidx.compose.ui:ui:1.3.3
androidx.compose.ui:ui:1.4.0-alpha04

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

Issue is still existing with the same rate in 1.3.3 and similar reproduction steps. Since this ticket is already set as fixed, should we file a new bug?

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

Hey. Please check that you can reproduce the same issue with the latest 1.4 release and if yes please file a new bug. 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

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.

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

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

androidx.exifinterface:exifinterface:1.4.0-alpha01

Issue 263747161

Description

Issue summary

Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Add comment

Issue metadata