Status Update
Comments
ib...@google.com <ib...@google.com>
ju...@gmail.com <ju...@gmail.com> #2
To use
The issue is happening because, starting from LocalLifecycleOwner
has been moved from androidx.compose.ui
to lifecycle-runtime-compose
, as outlined in their respective release notes. For compatibility reasons, you must update both dependencies.
For context, note these changes were made to enable the utilization of its Compose-based helper APIs beyond Compose UI (such as in
If the issue persists even after updating your Compose UI, please let us know.
Edit: please see
ib...@google.com <ib...@google.com> #3
If this change has made both libraries version dependent, it seems that guide them to the release note so that users will not experience difficulties :)
ju...@gmail.com <ju...@gmail.com> #4
lifecycle 2.8.0 is now stable but compose UI 1.7.0 is still in beta.
ap...@google.com <ap...@google.com> #5
Same problem here. Lifecycle 2.8.0
is now stable but Compose UI 1.7.0
is still beta. Of course our Dependabot didn't know about this relationship between dependencies 😬
ib...@google.com <ib...@google.com> #6
Something like that really shouldn't happen... 🤦🏻♂️
ap...@google.com <ap...@google.com> #7
Thats really really bad. I would always expect the latest stable versions to be compatible. Please add this requirement to the changelog or better add a warning at compile time if used with incompatible combinations.
na...@google.com <na...@google.com> #8
We acknowledge that the behavior dependency between Lifecycle 2.8 Stable and Compose 1.7 Beta is not ideal. This should not have occurred, and we are working in a fix and looking into how we can prevent it in the future. We have updated our release notes to clarify this issue.
In the meantime, while Compose 1.7 Stable has not been released, we have outlined some potential workarounds below. Please note that these solutions are not perfect but they could be helpful to some of you while the fix is not ready:
-
Map
androidx.compose.ui.platform.LocalLifecycleOwner
(Compose 1.6) toandroidx.lifecycle.compose.LocalLifecycleOwner
(Lifecycle 2.8). Here's an example:CompositionLocalProvider( androidx.lifecycle.compose.LocalLifecycleOwner provides androidx.compose.ui.platform.LocalLifecycleOwner.current, ) { // ... }
- Please note that when using Navigation Compose, this may be required on each navigation page (for more details, refer to
).comment #11
- Please note that when using Navigation Compose, this may be required on each navigation page (for more details, refer to
-
Manually pass
androidx.compose.ui.platform.LocalLifecycleOwner
(Compose 1.6) to Lifecycle 2.8 methods. For instance:val state by stateFlow.collectAsStateWithLifecycle( owner = androidx.compose.ui.platform.LocalLifecycleOwner.current )
Thank you.
Description
Summary:
Using ExifInterface to call saveAttributes on a WebP file corrupts the WebP file, causing it to become invalid.
Steps to Reproduce:
Use ExifInterface to load a WebP file that does not contain a VP8X header. Call saveAttributes on the ExifInterface object. Attempt to open the resulting WebP file. Expected Result: The WebP file should remain valid and openable after saving attributes.
Actual Result: The WebP file becomes corrupted and cannot be opened properly.
Root Cause Analysis:
If the WebP file does not have a VP8X header, ExifInterface writes a new VP8X header.
When the WebP file's width or height is greater than 8191, the issue arises.
The following code causes the problem:
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.
Environment