IssueTracker

Yigit, do you have time to fix it?

reemission of the same liveData is racy

yea i'll take it.

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.

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()
        }
    }

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)

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} )
        }

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

Sorry, the right url above should be: https://developer.android.com/jetpack/docs/release-notes

I changed the ProGuard configuration as you can see it in the GitHub repository. It matches with your change here https://android-review.googlesource.com/c/platform/frameworks/support/+/782087/2/work/workmanager/proguard-rules.pro if I don't miss anything. I cannot tell why "WorkParameters" is still listed. I verified the output once again by running ./gradlew clean --info --debug aCcc34c3Release. Feel free to run the build yourself. All you need to do is to create a random release-keystore and the app/gradle.properties from the app/gradle.properties.example.

So you saying when I want to migrate my app to targetSdkVersion 26 until November I need to raise the compileSdkVersion to 28 in order to use WorkManager? Using targetSdkVersion 26 with compileSdkVersion 28 won't work?

There shouldn't be any issues with targetSdkVersion 26 and compileSdkVersion 28.

Okay. I will try that. Thanks.
Feel free to contact me if you are not able to build my project.

Does it suffice to raise the compileSdkVersion to 28 or do I also have to raise the version of the support library artifacts at the same time? I tried your suggestion in comment #11 but the build still fails.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit cee9ab55352f3ad506552afb4753baf8648b4c30
Author: Sumir Kataria <sumir@google.com>
Date:   Mon Oct 08 14:20:57 2018

    Fix class name in Proguard configuration.
   
    Bug: 116296569
    Test: N/A
    Change-Id: I3525f9d2f3b06523cbe842b35f97014677879a64

M       work/workmanager/proguard-rules.pro

https://android-review.googlesource.com/782087
https://goto.google.com/android-sha1/cee9ab55352f3ad506552afb4753baf8648b4c30

Support library as well.

Do the latest changes (WorkParameters -> WorkerParameters, NonBlockingWorker -> ListenableWorker) in the ProGuard configuration apply to WorkManager 1.0.0-alpha09 or 1.0.0-alpha10 or both?

alpha10.

Thank you. Can you please point me to the commit/file which represents the configuration for WorkManager 1.0.0-alpha09? Maybe here https://android.googlesource.com/platform/frameworks/support/+log/androidx-master-dev/work/workmanager/proguard-rules.pro?

There isn't one for alpha09... it's already released.  You can modify that commit and adapt it to alpha09.

Just change WorkParameters -> WorkerParameters.

Which commit do you refer to? The link I posted show the history of the proguard-rules.pro commits. Since the file exists for a year I would have expected that there was a version of the file which shipped with WorkManager 1.0.0-alpha which was released by September 19, 2018.

Or do you mean that the proguard-rules.pro being shipped with WorkManager 1.0.0-alpha is buggy?

Yes, alpha09 had a bug.  #19 suggests a modification to your app's proguard config to get around the issue.  alpha10 should be out soon with the fix.

Thank you for the clarification.

I prepared my test branch according to your recommendations (ProGuard, compileSdkVersion, targetSdkVersion, support libraries) as you can see here:
https://github.com/EventFahrplan/EventFahrplan/compare/master...workmanager

The release build however still fails:

00:20:09.182 [QUIET] [system.out] Note: androidx.work.impl.Schedulers: can't find dynamically referenced class androidx.work.impl.background.firebase.FirebaseJobService
00:20:09.182 [QUIET] [system.out] Note: androidx.work.impl.Schedulers: can't find dynamically referenced class androidx.work.impl.background.firebase.FirebaseJobScheduler
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.jdk8.JDK8PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.JRE8PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.jdk7.JDK7PlatformImplementations
00:20:09.210 [QUIET] [system.out] Note: kotlin.internal.PlatformImplementationsKt: can't find dynamically referenced class kotlin.internal.JRE7PlatformImplementations
00:20:09.212 [QUIET] [system.out] Note: kotlin.jvm.internal.Reflection: can't find dynamically referenced class kotlin.reflect.jvm.internal.ReflectionFactoryImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform: can't find dynamically referenced class com.android.org.conscrypt.SSLParametersImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform: can't find dynamically referenced class org.apache.harmony.xnet.provider.jsse.SSLParametersImpl
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.AndroidPlatform$CloseGuard: can't find dynamically referenced class dalvik.system.CloseGuard
00:20:09.228 [QUIET] [system.out] Note: okhttp3.internal.platform.ConscryptPlatform: can't find dynamically referenced class org.conscrypt.ConscryptEngineSocket
00:20:09.229 [QUIET] [system.out] Note: okhttp3.internal.platform.Platform: can't find dynamically referenced class sun.security.ssl.SSLContextImpl
00:20:09.955 [QUIET] [system.out] Note: the configuration keeps the entry point 'androidx.core.graphics.drawable.IconCompatParcelizer { android.support.v4.graphics.drawable.IconCompat read(androidx.versionedparcelable.VersionedParcel); }', but not the descriptor class 'androidx.versionedparcelable.VersionedParcel'
00:20:09.955 [QUIET] [system.out] Note: the configuration keeps the entry point 'androidx.core.graphics.drawable.IconCompatParcelizer { void write(android.support.v4.graphics.drawable.IconCompat,androidx.versionedparcelable.VersionedParcel); }', but not the descriptor class 'androidx.versionedparcelable.VersionedParcel'

These aren't failures (unless your configuration has a problem).  As you can see, you have things listed from other libraries like okhttp as well.

Maybe, I missing the specific part in the output. I pasted a large part of the lower end here: http://pastebin.de/8421/

You need to add:

-dontwarn sun.misc.Unsafe

Thank you. This made the release build succeed.
Can you please explain which library (version) introduces the Unsafe class?

I am still facing this issue with WorkManager-1.0.0-beta01

2018-12-31 01:40:32.701 2947-2977/de.aurora.mggvertretungsplan.debug E/WM-WorkerFactory: Could not instantiate de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker
    java.lang.IllegalAccessException: Class java.lang.Class<androidx.work.WorkerFactory> cannot access  method void de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker.<init>(android.content.Context, androidx.work.WorkerParameters) of class java.lang.Class<de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker>
        at java.lang.reflect.Constructor.newInstance0(Native Method)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
        at androidx.work.WorkerFactory.createWorkerWithDefaultFallback(WorkerFactory.java:92)
        at androidx.work.impl.WorkerWrapper.runWorker(WorkerWrapper.java:191)
        at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:125)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)
2018-12-31 01:40:32.701 2947-2977/de.aurora.mggvertretungsplan.debug E/WM-WorkerWrapper: Could not create Worker de.aurora.mggvertretungsplan.services.DownloadTimeTableWorker

My code can be found at https://github.com/d-Rickyy-b/MGGVertretungsplan.

I'd be very grateful for any kind of support.

Okay... I feel pretty stupid now - it seems that my constructor was package-private and for workmanager to work, it needed to be public. Maybe the exception could point to that issue?

That is correct. Worker must have a public constructor unless you instantiate it via your own WorkerFactory.