Status Update
Comments
il...@google.com <il...@google.com> #2
me...@gmail.com <me...@gmail.com> #3
If the width or height is greater than 8191, left-shifting causes the sign bit to be lost, turning a '1' into a '0', which results in an incorrect width or height.
I agree there's a bug here, but I'm not sure this is quite a precise description of the problem. A quick experiment suggests that the left shift (<<
) works fine (if we are just looking at bits), but the right shift (>>
) is where the problem is introduced, because >>
does "sign extension" in Java - meaning if input value is negative (the MSB of the 32-bit int is 1
), then the result will be negative too. This can be fixed by using the unsigned right shift operator (>>>
).
You can see this in jshell
:
$ jshell
| Welcome to JShell -- Version 22
| For an introduction type: /help intro
jshell> int width = 5
width ==> 5
jshell> int height = 8192
height ==> 8192
jshell> int widthAndHeight = (width << 16) | height
widthAndHeight ==> 335872
jshell> (widthAndHeight << 18) >> 18
$8 ==> -8192
jshell> (widthAndHeight << 18) >>> 18
$9 ==> 8192
That said, I also agree that your change in
me...@gmail.com <me...@gmail.com> #4
Thanks for your reply. So it it ok to be merged?
lb...@gmail.com <lb...@gmail.com> #5
Branch: androidx-main
commit 59e5677498b92689c2c92801c1f371f24ca7024e
Author: Ian Baker <ibaker@google.com>
Date: Thu Aug 01 16:12:27 2024
Add a test WebP image with a height of 8192px
This exercises the bug reported in
The test is disabled for now. It can be enabled as part of merging the
fix in
This image was generated using imagemagick:
$ convert webp_without_exif.webp \
-resize 6144x8192 \
webp_without_exif_height_8192px.webp
Bug: 342697059
Test: ExifInterfaceTest
Change-Id: Ib014f54fbe8d28579f95d5d2f34e302cdd569fb9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/webp_without_exif_height_8192px.webp
me...@gmail.com <me...@gmail.com> #6
il...@google.com <il...@google.com>
mi...@gmail.com <mi...@gmail.com> #7
Branch: androidx-main
commit e6f75a0d1eb7fe104812ffaa108b71ed7a86b2d4
Author: Ian Baker <ibaker@google.com>
Date: Tue Aug 06 13:59:45 2024
Add missing comment to @SdkSuppress annotation
This explains why this test is skipped on API 21.
Test: ExifInterfaceTest
Bug: 342697059
Change-Id: I49b364107f52827417540e87704010cbc8f5a02e
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
lb...@gmail.com <lb...@gmail.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-alpha01
ab...@gmail.com <ab...@gmail.com> #9
me...@gmail.com <me...@gmail.com> #10
ab...@gmail.com <ab...@gmail.com> #11
Can you update regarding any progress on this issue.
jb...@google.com <jb...@google.com>
sa...@google.com <sa...@google.com>
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 50f098644adc703ae218b0b7e999629f516a0241
Author: sanura <sanura@google.com>
Date: Thu Mar 02 00:11:35 2023
Add check to only invalidate options menu when contributing menu items
FragmentManager previously appropriately only added
a MenuProvider when the host is a MenuHost **and**
we are at the root fragment that is providing the
menu items. This behavior should be mirrored when
removing a MenuProvider as well, so that only
components that directly contribute menu items will
invalidate the options menu.
Bug: 244336571
Test: all tests pass
Change-Id: I9404ee9fcc9ce6b80d70a93bea720fe4ccf583a0
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerInflatedFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/OptionsMenuFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/test/FragmentTestActivity.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
sa...@google.com <sa...@google.com>
lb...@gmail.com <lb...@gmail.com> #14
Please show what to write on gradle file.
jb...@google.com <jb...@google.com> #15
This has been fixed internally and will be available in the Fragment 1.6.0-alpha07
release.
lb...@gmail.com <lb...@gmail.com> #16
It's part of the material dependency, perhaps?
na...@google.com <na...@google.com> #17
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.6.0-alpha07
lb...@gmail.com <lb...@gmail.com> #18
lb...@gmail.com <lb...@gmail.com> #19
It says "Duplicate class found".
The IDE doesn't provide any useful explanation of what is the class that is duplicated and what to do about it.
Please help.
pr...@google.com <pr...@google.com> #20
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.5.6
lb...@gmail.com <lb...@gmail.com> #21
th...@gmail.com <th...@gmail.com> #22
@21 androidx.fragment:fragment:1.5.6 is a STABLE release. It has the fix we need. The androidx.fragment:fragment:1.6.0-alpha07 is an alpha as it says. 1.6 is "work in progress". 1.6.0 is still not a stable release. Use "alpha" only for testing
Description
Version used: 1.5.2
Devices/Android versions reproduced on: Android 12
I'm using SearchView in my Activity. If SearchView is expanded and i'm opening DialogFragment on the top of the activity and then dismissing it, SearchView is being collapsed. It must not collapse.
Seems like some bug in Fragment 1.5.0 - 1.5.2 version. In 1.4.1 version everything is working fine.
Please suggest some workarounds or how to fix this issue?