Fixed
Status Update
No update yet.
Comments
ad...@google.com
se...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ja...@jackcheung.com
yea i'll take it.
se...@google.com
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
se...@google.com
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
se...@google.com
With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)
ch...@google.com
yea sorry immediate does not fix it.
I actually have a WIP fix for it:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
I actually have a WIP fix for it:
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
se...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
https://android-review.googlesource.com/1112186
https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
se...@google.com
I'm not really sure that it is expected behavior, because it is impossible for us as library developers to guess that this will happen.
al...@google.com
This seems like obviously broken "expected" behavior that will affect existing libraries.
We will eventually address this with Gradle metadata indicating a required minimum compileSdkVersion, but that's likely a year out and won't help developers until they update to a newer Studio / AGP version. It also won't help library developers who aren't Google.
Edit: I'll acknowledge that this is _technically_ correct and in the absence of a SDK 29 android.jar the methods are indistinguishable from methods that can be safely pruned; however, we need a better solution here than "add one-off keep rules." Every overridden "new SDK" method should be kept by default.
We will eventually address this with Gradle metadata indicating a required minimum compileSdkVersion, but that's likely a year out and won't help developers until they update to a newer Studio / AGP version. It also won't help library developers who aren't Google.
Edit: I'll acknowledge that this is _technically_ correct and in the absence of a SDK 29 android.jar the methods are indistinguishable from methods that can be safely pruned; however, we need a better solution here than "add one-off keep rules." Every overridden "new SDK" method should be kept by default.
ch...@google.com
I am not arguing that this behavior is intended or easy to understand for developers. It is expected from a compilation point of view, though, since the compiler is not given the right inputs and therefore cannot know that methods such as ActivityLifecycleCallbacks.onActivityPostCreated() are any different from MyActivity.entirelyUnusedMethod().
I can think of a few different ways to address this issue until a minimum compileSdkVersion is required.
1) Developers use `compileSdkVersion 29` if their app uses any APIs that are not present in SDK 28. Unfortunately, it is not easy for developers to know that a given library uses APIs that are only available in SDK 29.
2) Library developers add a `-keepclassmembers` rule for the APIs that they use that are only present in SDK 29. This way the implementation of these APIs will not be considered dead even when developers that depend on the library use `compileSdkVersion 28`. The advantage of this is that developers do not need to upgrade to a newer AGP version, only a newer version of the library. The disadvantage is that this only solves the problem for a single library. That may or may not be a problem depending on the number of libraries that actually overrides APIs that are only available in SDK 29. As with (1), it is not easy for library developers to know that they need to add these rules.
3) We add special handling for the APIs that are only available in SDK 29 in AGP/R8 (or the APIs in SDK i+1 that are not in SDK i). There are many ways to do this, but all of them require developers to upgrade to a newer AGP version. One way would be to auto-generate a `-keepclassmembers` rule for each of the (visible, virtual) methods from SDK 29 that are not available in SDK 28. These rules could then be included by AGP, or added to, for example,https://android.googlesource.com/platform/sdk/+/master/files/proguard-android.txt and https://android.googlesource.com/platform/sdk/+/master/files/proguard-android-optimize.txt . One disadvantage is that this only solves the problem up to SDK 29, since we don't know what newer SDKs look like.
4) Note that (3) is largely equivalent to having AGP pass the union of android-28.jar and android-29.jar to R8 instead of android-28.jar. For this reason, it might also be interesting to look into the possibility of having AGP pass the union of all android-x.jar files to R8, instead of the SDK specified in `compileSdkVersion`. This would solve the issue for all APIs that are available in SDK i+1 but not SDK i. For this to work with SDKs that are not available at a given AGP version, AGP would need a mechanism for fetching more recent android-x.jar files, such that it can build the union of android-1.jar to android-x.jar, x > 29, when android-x.jar becomes available. Otherwise developers would have to upgrade to a newer AGP version if they use a library that depends on APIs in an SDK that was not available by the time of the AGP version (which may also be acceptable).
A concern is that both (3) and (4) require developers to upgrade to a newer AGP version and they solve a problem that will be solved when a minimum compileSdkVersion will be required.
I can think of a few different ways to address this issue until a minimum compileSdkVersion is required.
1) Developers use `compileSdkVersion 29` if their app uses any APIs that are not present in SDK 28. Unfortunately, it is not easy for developers to know that a given library uses APIs that are only available in SDK 29.
2) Library developers add a `-keepclassmembers` rule for the APIs that they use that are only present in SDK 29. This way the implementation of these APIs will not be considered dead even when developers that depend on the library use `compileSdkVersion 28`. The advantage of this is that developers do not need to upgrade to a newer AGP version, only a newer version of the library. The disadvantage is that this only solves the problem for a single library. That may or may not be a problem depending on the number of libraries that actually overrides APIs that are only available in SDK 29. As with (1), it is not easy for library developers to know that they need to add these rules.
3) We add special handling for the APIs that are only available in SDK 29 in AGP/R8 (or the APIs in SDK i+1 that are not in SDK i). There are many ways to do this, but all of them require developers to upgrade to a newer AGP version. One way would be to auto-generate a `-keepclassmembers` rule for each of the (visible, virtual) methods from SDK 29 that are not available in SDK 28. These rules could then be included by AGP, or added to, for example,
4) Note that (3) is largely equivalent to having AGP pass the union of android-28.jar and android-29.jar to R8 instead of android-28.jar. For this reason, it might also be interesting to look into the possibility of having AGP pass the union of all android-x.jar files to R8, instead of the SDK specified in `compileSdkVersion`. This would solve the issue for all APIs that are available in SDK i+1 but not SDK i. For this to work with SDKs that are not available at a given AGP version, AGP would need a mechanism for fetching more recent android-x.jar files, such that it can build the union of android-1.jar to android-x.jar, x > 29, when android-x.jar becomes available. Otherwise developers would have to upgrade to a newer AGP version if they use a library that depends on APIs in an SDK that was not available by the time of the AGP version (which may also be acceptable).
A concern is that both (3) and (4) require developers to upgrade to a newer AGP version and they solve a problem that will be solved when a minimum compileSdkVersion will be required.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 714063ab71dff7b514b9c5f6489190c9d4fffda9
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Mon Oct 21 11:32:58 2019
Fix lifecycle-runtime for compileSdkVersion 28 + minification
bug: 142778206
Test: manually ran a testcase from
Change-Id: I81b47999effbd1e099a8876b9133db4f8a0d899b
M lifecycle/lifecycle-process/build.gradle
A lifecycle/lifecycle-process/proguard-rules.pro
M lifecycle/lifecycle-runtime/proguard-rules.pro
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
https://android-review.googlesource.com/1147717
https://goto.google.com/android-sha1/714063ab71dff7b514b9c5f6489190c9d4fffda9
Branch: androidx-master-dev
commit 714063ab71dff7b514b9c5f6489190c9d4fffda9
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Mon Oct 21 11:32:58 2019
Fix lifecycle-runtime for compileSdkVersion 28 + minification
bug: 142778206
Test: manually ran a testcase from
Change-Id: I81b47999effbd1e099a8876b9133db4f8a0d899b
M lifecycle/lifecycle-process/build.gradle
A lifecycle/lifecycle-process/proguard-rules.pro
M lifecycle/lifecycle-runtime/proguard-rules.pro
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-lifecycle-release
commit 46fef0f000d93c584c46f2a5f764475d3df4824e
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Mon Oct 21 11:32:58 2019
Fix lifecycle-runtime for compileSdkVersion 28 + minification
bug: 142778206
Test: manually ran a testcase from
Change-Id: I81b47999effbd1e099a8876b9133db4f8a0d899b
(cherry picked from commit 714063ab71dff7b514b9c5f6489190c9d4fffda9)
M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
A lifecycle/lifecycle-common-java8/api/2.2.0-rc02.txt
A lifecycle/lifecycle-common-java8/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-common-java8/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/restricted_2.2.0-rc02.txt
M lifecycle/lifecycle-process/build.gradle
A lifecycle/lifecycle-process/proguard-rules.pro
A lifecycle/lifecycle-reactivestreams-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/restricted_2.2.0-rc02.txt
M lifecycle/lifecycle-runtime/proguard-rules.pro
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
A lifecycle/lifecycle-service/api/2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/restricted_2.2.0-rc02.txt
https://android-review.googlesource.com/1151593
https://goto.google.com/android-sha1/46fef0f000d93c584c46f2a5f764475d3df4824e
Branch: androidx-lifecycle-release
commit 46fef0f000d93c584c46f2a5f764475d3df4824e
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Mon Oct 21 11:32:58 2019
Fix lifecycle-runtime for compileSdkVersion 28 + minification
bug: 142778206
Test: manually ran a testcase from
Change-Id: I81b47999effbd1e099a8876b9133db4f8a0d899b
(cherry picked from commit 714063ab71dff7b514b9c5f6489190c9d4fffda9)
M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
A lifecycle/lifecycle-common-java8/api/2.2.0-rc02.txt
A lifecycle/lifecycle-common-java8/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-common-java8/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-common/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-extensions/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-core/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-livedata/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-process/api/restricted_2.2.0-rc02.txt
M lifecycle/lifecycle-process/build.gradle
A lifecycle/lifecycle-process/proguard-rules.pro
A lifecycle/lifecycle-reactivestreams-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-reactivestreams/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-runtime-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-runtime/api/restricted_2.2.0-rc02.txt
M lifecycle/lifecycle-runtime/proguard-rules.pro
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
A lifecycle/lifecycle-service/api/2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-service/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel-ktx/api/restricted_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/public_plus_experimental_2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/res-2.2.0-rc02.txt
A lifecycle/lifecycle-viewmodel/api/restricted_2.2.0-rc02.txt
an...@google.com
d4...@gmail.com
The proguard rule for the `ReportFragment` suggested in one of the above commits didn't work for me, I had to use
-keepclassmembers class androidx.lifecycle.ReportFragment$** { *; }
https://stackoverflow.com/questions/58671715
-keepclassmembers class androidx.lifecycle.ReportFragment$** { *; }
ag...@google.com
Sergey, doing bug cleanup, is this fixed on your end?
se...@google.com
Yep, it is fixed on our end
Description
Version used: Android 10
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on:
## Details
App is stuck on `INITIALIZED` state, even the activity has already finished `onResume()` method call
## Steps to Reproduce
- Build a signed production release `apk` with proguard `minifyEnabled true` (default)
- Install on `Pixel 3a` running `Android 10`
- Tap `UPDATE STATUS` button to examine the retrieved current state
- Note that the expected word shall be `RESUMED`, as is on other devices (even on Android 10 emulator) except `Pixel 3a / Android 10`
## Notes
- `'androidx.lifecycle:lifecycle-runtime:2.1.0'` doesn't have the issue
- disable or removed `proguard` works
- code demonstrating the issue can be checked out here:
-