Fixed
Status Update
Comments
ti...@google.com <ti...@google.com>
ib...@google.com <ib...@google.com> #2
Thanks for the report - do you have any reproduction steps?
ja...@gmail.com <ja...@gmail.com> #3
Nevermind, this has been fixed and will be available in an upcoming release.
ib...@google.com <ib...@google.com> #4
An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
ib...@google.com <ib...@google.com> #5
Since the
Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.
ib...@google.com <ib...@google.com>
ja...@gmail.com <ja...@gmail.com> #6
I can confirm that using fragment 1.2.2 resolves the issue, thank you!
Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).
Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-main
Author: Ian Baker <
Link:
Exclude trailing non-WebP data from length when writing new file
Expand for full commit details
Exclude trailing non-WebP data from length when writing new file
Some files have trailing data outside the length defined by the RIFF
header. ExifInterface previously naively copied this data and then
calculated a new RIFF length which included it, resulting in an invalid
file.
This change only copies RIFF-defined data from the old file before
calculating the new RIFF length, and then appends any additional data
after that - in order to more closely mimic the input file's structure
without throwing away the trailing data.
Test: ExifInterfaceTest
Bug: 385766064
Change-Id: I8a955cf85d229ad4af5a1e02aa891cfca0e54d60
Files:
- M
exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
- A
exifinterface/exifinterface/src/androidTest/res/raw/webp_without_exif_trailing_data.webp
- M
exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
Hash: d21234605366120bb1af4ea1109e15b6c23d93f0
Date: Fri Jan 03 11:30:32 2025
pr...@google.com <pr...@google.com> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-beta01
Description
Version used: 1.4.0-alpha01
Devices/Android versions reproduced on: Pixel 8a
After calling saveAttributes on an webp image, the image can not be viewed anymore on an Android device. Windows can for some reason still display the image with the inbuilt Photos program and e.g.