Status Update
Comments
mg...@google.com <mg...@google.com> #2
Branch: androidx-master-dev
commit ae09f6e6686b32c5677c086d51d5737553e2aeb9
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
gr...@gmail.com <gr...@gmail.com> #3
We've fixed this internally and are preparing a DrawerLayout 1.1.1
release with this fix.
ma...@marcardar.com <ma...@marcardar.com> #4
Branch: snap-temp-L48600000649720827
commit 6e863d72d89137a408907be4c44f5444b51f8dab
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
sj...@gmail.com <sj...@gmail.com> #5
Branch: snap-temp-L11100000649726887
commit 4b1419f8d1c41233b1af357a178c1eb6e71e3fb0
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
ha...@gmail.com <ha...@gmail.com> #6
Branch: snap-temp-L37200000649809909
commit 8e12fa9761f7d1ad254bd278392ed2020de2cec1
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
th...@gmail.com <th...@gmail.com> #7
Branch: snap-temp-L59700000649811929
commit 8c0814d1467e02e617f002b61b09a5737a3a1e94
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
mg...@google.com <mg...@google.com> #8
Branch: snap-temp-L27600000649911717
commit 63fcaff3662ea1236d84e644362f35b7618b56dd
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
mg...@google.com <mg...@google.com>
th...@tempo.co.nz <th...@tempo.co.nz> #9
Branch: snap-temp-L68100000649916060
commit e33fcbc8c30a40594cfcfbb643018e2bfe024820
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
ju...@veepee.com <ju...@veepee.com> #10
Branch: snap-temp-L86900000650841826
commit 3ad4cab4e570828fddbf650934a4e9efdd8405e0
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
mg...@google.com <mg...@google.com> #11
Branch: snap-temp-L89900000650843240
commit 978cae5a010bf4c0c1b6fcfd68fd1b1c7802e126
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
sj...@gmail.com <sj...@gmail.com> #12
Branch: snap-temp-L89900000650864753
commit 2754768be7ccfd570f9355ab74406157e3a69d92
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
ap...@google.com <ap...@google.com> #13
The following changes were cherrypicked through
Release Track:
Changes: aosp/1373433
bo...@gmail.com <bo...@gmail.com> #14
The following changes were cherrypicked through
Release Track:
Changes: aosp/1378185
ra...@gmail.com <ra...@gmail.com> #15
ma...@gmail.com <ma...@gmail.com> #16
The following changes were cherrypicked through
Release Track:
Changes: aosp/1451099
fi...@gmail.com <fi...@gmail.com> #17
The ./gradlew app:dependencies --configuration releaseRuntimeClasspath
I couldn't find any Compose library resolved to alpha versions, the highest version was 1.6.5.
Is the statement correct? Or do I misinterpret it?
sj...@gmail.com <sj...@gmail.com> #18
@
Lifecycle does not have a transitive dependency on Compose since it's not strictly related to Compose. It's more like Compose 1.7 has been adjusted to Lifecycle 2.8.0. So you need to explicitly update your Compose dependencies.
mg...@google.com <mg...@google.com> #19
lifecycle-runtime-compose
2.8.* does not explicitly depend on compose-ui
1.7.* but there is a behavior compatibility issue between the versions - meaning standard POM dependency version checks will not detect the problem.
To understand the issue better, let’s go step by step on what happened:
- We have introduced a new
LocalLifecycleOwner
insidelifecycle-runtime-compose
. - We have inverted the dependency between
compose-ui
andlifecycle-runtime-compose
.- Before:
lifecycle-runtime-compose
- depends on ->compose-ui
. - After:
compose-ui
- depends on ->lifecycle-runtime-compose
.
- Before:
- We have changed the “old”
LocalLifecycleOwner
fromcompose-ui
to return the new one inlifecycle-runtime-compose
for binary compatibility.compose-ui
1.6.*, sets up the “old”LocalLifecycleOwner
at runtime.compose-ui
1.7.*, sets up the “new”LocalLifecycleOwner
at runtime.
lifecycle-runtime-compose
2.7.* needs the “old”LocalLifecycleOwner
.lifecycle-runtime-compose
2.8.* needs the “new”LocalLifecycleOwner
.
Now, when combining compose-ui
1.6.* and lifecycle-runtime-compose
2.8.* or compose-ui
1.7.* and lifecycle-runtime-compose
2.7.*, they will reference to different LocalLifecycleOwner
instances at runtime.
Since there's no direct dependency between them, standard POM checks cannot detect this issue. A call chain analysis would have been required to identify the behavior incompatibility between stable versions.
fi...@wartek.belajar.id <fi...@wartek.belajar.id> #20
mg...@google.com <mg...@google.com>
ap...@google.com <ap...@google.com> #21
Branch: androidx-main
commit 59dd212495f4378911cbb310367743b2aae734a3
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Wed May 29 17:49:02 2024
Make `LocalLifecycleOwner` backward compatible with Compose 1.6.*
Lifecycle 2.8.* requires Compose 1.7.* for correctness, but
Compose 1.7.* have not yet reached stable.
For allowing Lifecycle 2.8.* to be used with Compose 1.6.*, we are
introducing the following measures:
* When Lifecycle 2.8.* detects it's running with Compose 1.6.*, it
uses reflection to access the previous version of
`androidx.compose.ui.platform.LocalLifecycleOwner`.
* A custom Proguard rule has been added to prevent the obfuscation of
`androidx.compose.ui.platform.LocalLifecycleOwner` when using
Compose 1.6.*. This ensures the reflection approach works correctly.
We have tested these backward compatibility measures in various
scenarios, including:
* Projects with and without Navigation Compose integrated.
* Compose versions 1.6.* and 1.7.*.
* Builds both with and without Proguard obfuscation applied.
Please note that backward compatibility reflection will be removed once
Compose 1.7.* is stable. A Gradle dependency constraint should be
put in place to ensure smooth migration for clients.
Fixes:
Test: manual
Change-Id: I3d0666a88eb309aae9a5c60eacc6818f52dd0bfd
M lifecycle/lifecycle-runtime-compose/build.gradle
A lifecycle/lifecycle-runtime-compose/proguard-rules.pro
A lifecycle/lifecycle-runtime-compose/src/androidMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.android.kt
M lifecycle/lifecycle-runtime-compose/src/commonMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.kt
A lifecycle/lifecycle-runtime-compose/src/desktopMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.desktop.kt
ca...@careem.com <ca...@careem.com> #22
Looking at the
mg...@google.com <mg...@google.com> #23
Lifecycle 2.8.1 was released last week (May 29, 2024). The workaround was merged yesterday (June 4, 2024), so it is not included in version 2.8.1. Please note that the "Date: Wed May 29" in the CL header above is a metadata that indicates when the CL was created, not when it was merged.
We intend to include it in the very next release, Lifecycle 2.8.2.
va...@cloudkitchens.com <va...@cloudkitchens.com> #24
pr...@google.com <pr...@google.com> #25
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-android:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.2
li...@gmail.com <li...@gmail.com> #26
eg...@gmail.com <eg...@gmail.com> #27
Can confirm, the issue reproduces on release build
[Deleted User] <[Deleted User]> #28
ma...@gmail.com <ma...@gmail.com> #29
kr...@gmail.com <kr...@gmail.com> #30
Same for me too. I updated the Lifecycle lib to v2.8.2 and Compose BOM to v2024.06.00 which incorporate v1.6.8 of Compose libs. Still, the app got this exception and crashed, but only in the release mode and not in debug mode. Unfortunately, I got the crash in the production app after its release. After downgrading the Lifecycle lib to v2.7.0, it is working fine in the production app. Immediately, I had to release another patch version, so the users do not complain about app not working.
mg...@google.com <mg...@google.com> #31
We have received a similar report at -keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }
to your ProGuard rules).
Although we have included a custom ProGuard rule as part of our fix, the rule is not working as intendend across all projects. We are currently investigating the problem, see
ba...@gmail.com <ba...@gmail.com> #32
Updating to 2.8.2 with Compose BOM "2024.06.00" the app is crashing on Release build with the error "CompositionLocal LocalLifecycleOwner not present".
A proguard rules should be provided or another version with fix.
su...@gmail.com <su...@gmail.com> #33
However, for the visitors
"-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }"
Add this to your app proguard file and it'll work fine.
ih...@enverus.com <ih...@enverus.com> #34
mo...@gmail.com <mo...@gmail.com> #35
I can confirm it's still an issue for me with Compose BOM "2024.06.00" and lifecycle 2.8.2.
I added these lines to proguard to fix the issue:
-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
mg...@google.com <mg...@google.com> #36
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #37
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #38
Lifecycle 2.8.3 is now available on
pr...@google.com <pr...@google.com> #39
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01
Description
Version used:
lifecycle-runtime-compose:2.8.0-alpha03
androidx.compose.ui:ui-android:1.7.0-alpha03
When
Devices/Android versions reproduced on: Android14
When running collectAsStateWithLifecycle in setContent inside the fragment, the following error occurs.
Could any of the changes in lifecycle 2.8.0-alpha03 be caused by LocalLifecycleOwner's has different directory?
"LocalLifecycleOwner moved from Compose UI to lifecycle-runtime-compose so that its Compose-based helper APIs can be used outside of Compose UI"
java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:26)
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:25)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at androidx.compose.runtime.LazyValueHolder.getCurrent(ValueHolders.kt:29)
at androidx.compose.runtime.LazyValueHolder.getValue(ValueHolders.kt:31)
at androidx.compose.runtime.CompositionLocalMapKt.read(CompositionLocalMap.kt:90)
at androidx.compose.runtime.ComposerImpl.consume(Composer.kt:2135)
at androidx.lifecycle.compose.FlowExtKt.collectAsStateWithLifecycle(FlowExt.kt:180)