Status Update
No update yet.
Comments
ap...@google.com
Great
ib...@google.com
Branch: androidx-main
commit a735aaa4d06c90454de772fae5a02f6cbde210b3
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Feb 28 22:58:23 2023
Ensure FragmentNavigator destroys intermediate entries on popUpTo
We need to make sure that when Fragment are destroyed their entries are
also always destroyed.
RelNote: "Fixes a regressions in previous release that caused the wrong
BottomNav menu item to be highlighted when using system back to go
between tabs."
Test: Added FragmentNavigatorTest
Bug: 270447657
Change-Id: I634f6047b7016bcb8b690047605a6f66b2dc1438
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
ib...@google.com
This has been fixed internally and will be available in the Navigation 2.6.0-alpha07 release.
ib...@google.com
Branch: androidx-main
commit 96cee05bdb8f61a92e4be00a52b991cfc1ed2f4e
Author: Clara Fok <clarafok@google.com>
Date: Wed Mar 01 12:28:09 2023
Add FragmentNavigator test to assert entry destroyed
Add test to assert that NavBackStackEntry is destroyed after being restored upon recreation/configuration change.
Asserts that the fix on this bug also fixes
Test: ./gradlew navigation:navigation-fragment
Bug: 270447657
Change-Id: I8874d2dfaa17e560dd2f6d9da54e435494c187d2
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
ib...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-fragment:2.6.0-alpha07
ib...@google.com
Branch: androidx-main
commit 7cf55857f0db6bd1a1e1f95be7374ed5cf3eca58
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Mar 15 16:59:50 2023
Fix system back after popUpTo
After you do a popUpTo inclusive while using Navigation with Fragments,
if you attempt to do a system back call, the Navigation back stack is
never updated.
The reason for this is that when fragment views are DESTROYED, we need
for the observer in the FragmentNavigator to update the state so we know
that the entry was already popped.
RelNote: "When using system back after doing a navigate with popUpTo,
the state of the NavController will pop to the correct entry."
Test: Added OnBackPressedTest
Bug: 270447657
Change-Id: I3a8ec072ba6d1655ab054cc081961825909088e6
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/OnBackPressedTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
ch...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-fragment:2.6.0-alpha08
ib...@google.com
I'm curious about why this issue only happens when setting a FUSED location data but does not happen when setting a GPS location data? Does the FUSED location data in Exif actually occupy a little bit more size than GPS location data? So it causes the different result?
Good question - I actually only got as far as playing with the image provided inside MyApplication-ExifLocationIssue.zip, I didn't look at CameraXBasic-WriteFusedLocation.zip, and as you noted in
ib...@google.com
I've decided to go with option 4 from saveAttributes in order to avoid creating a corrupted image. I've filed a new issue to track the possibility of adding multi-segment support in the future:
ap...@google.com
Branch: androidx-main
commit c6bbc03f39f811ac546882880be46380cb31f5d5
Author: Ian Baker <ibaker@google.com>
Date: Tue Mar 07 11:09:08 2023
Throw an exception if trying to write a JPEG APP1 segment that's too large
jpeg_with_full_app_segment.jpg is an image taken with a Samsung A32
with a nearly-full APP1 segment due to a 64,000 byte thumbnail:
$ exiftool -v3 jpeg_with_exif_full_app1_segment.jpg
<snip>
JPEG APP1 (65072 bytes):
<snip>
| 5) ThumbnailLength = 64000
Bug: 263747161
Test: ./gradlew :exifinterface:exifinterface:connectedAndroidTest
Change-Id: Id421cd36d974ad4f29a2c6d6c730d99d8986d917
M exifinterface/exifinterface/build.gradle
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/jpeg_with_exif_full_app1_segment.jpg
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ib...@google.com
mw...@gmail.com
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
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 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
0x10030bytes 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
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
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
Description
Component used: Version used: Devices/Android versions reproduced on: Samsung A32 (sm-a325f) Android 12 (also A12/A13 mentioned in
When reporting bugs, please always include:
Where possible, please also provide: