Error: cannot access KSerializer [364634035]

Fixed

Bug

Status Update

No update yet.

Description

em...@gmail.com

created issue #1

Sep 5, 2024 03:27AM

Component used: Navigation
Version used: 2.8.0
Devices/Android versions reproduced on: Android 11
Previous working version: 2.7.7

Using Navigation 2.7.7 all works fine but when updating to 2.8.0 I get "error: cannot access KSerializer" ("class file for kotlinx.serialization.KSerializer not found") at this line:
- navGraph.(HERE IS THE MARKED POINT)setStartDestination(R.id.nav_permissions)
during "Task :app:compileDebugJavaWithJavac".

This piece of code placed in a MainActivity.onCreate() method:
- NavGraph navGraph = navController.getGraph();
- navGraph.setStartDestination(R.id.nav_permissions)

Those are my TOML libraries versions used in this project:
annotation = "1.8.2"
appcompat = "1.7.0"
constraintlayout = "2.1.4"
flexbox = "3.0.0"
gradle_plugin = "8.6.0"
kotlin = "1.9.24"
livedata = "2.8.5"
material = "1.12.0"
navigation = "2.8.0" (<-- returning to 2.7.7 solves this issue)
preference = "1.2.1"
sdk_compile = "34"
sdk_target = "33"
volley = "1.2.1"

Unfortunately the project is very big and I'm unable to cleanup to create a simple sample project for replicate this error.
I hope it would be enough those info.....

Comments

em...@gmail.com <em...@gmail.com> #2Sep 5, 2024 03:30AM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

jb...@google.com <jb...@google.com> #3Sep 5, 2024 04:52PM

yea i'll take it.

em...@gmail.com <em...@gmail.com> #4Sep 5, 2024 05:17PM

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.

jb...@google.com <jb...@google.com> #5Sep 9, 2024 03:52AM

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

si...@gmail.com <si...@gmail.com> #6Sep 23, 2024 07:33AM

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)

jb...@google.com <jb...@google.com> #7Sep 23, 2024 02:32PM

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

me...@gmail.com <me...@gmail.com> #8Sep 26, 2024 06:33AM

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

em...@gmail.com <em...@gmail.com> #9Sep 26, 2024 06:39AM

I suppose they're looking for a complete Android Studio project/solution to reploduce this issue.
Unfortunately my project is very big and it would take days of work to clean up to get an "empty and dumb container".

The code at #6 works in a new project created from scratch, so the issue should be elsewhere.

da...@gmail.com <da...@gmail.com> #10Sep 29, 2024 08:37PM

I managed to resolve this by adding the following to my apps build.gradle:

implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3'

il...@google.com <il...@google.com> #11Sep 29, 2024 11:31PM

Re comment#10 - please include a sample project that reproduces the issue!

si...@gmail.com <si...@gmail.com> #12Oct 28, 2024 07:15AM

Adding implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3' also fixes the build for me

sa...@gmail.com <sa...@gmail.com> #13Nov 25, 2024 08:45AM

comment#11

Hi, I added a sample project.
I also confirm that by manually importing
kotlinx-serialization-json (version 1.7.3 as an example), the compilation ends successfully.

in this project i am using 2.8.4, but it still reproduces.
The problem is definitely on the overload of the setStartDestination method which uses the generic T method, instead of the specific int

Message last modified on Nov 25, 2024 09:01AM

Kserialize-sample.zip

123 KB

Download

jb...@google.com <jb...@google.com> Nov 25, 2024 04:31PM

Assigned to cl...@google.com.

cl...@google.com <cl...@google.com> #14Nov 29, 2024 12:28AM

Accepted by cl...@google.com.

Yup java is pulling in the wrong overload

ap...@google.com <ap...@google.com> #15Dec 2, 2024 08:55PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <clarafok@google.com>
Link: https://android-review.googlesource.com/3383388

Fix wrong setStartDestination overload in Java

Expand for full commit details

Fix wrong setStartDestination overload in Java 
 
Java compiler links to the wrong NavGraph.setStartDestination overload which takes a `startDestination: T` instead of the correct `startDestination: Int`. 
 
The overload that takes `T` is part of the Navigation SafeArgs features for kotlin users, so we hide this overload from Java sources with @JvmSynthetic. 
This annotation is binary compatible. https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.jvm/-jvm-synthetic/ 
 
Test: manual testing 
Bug: 364634035 
Relnote: "The kotlin-specific NavGraph.setStartDestination overload for type safety is hidden from Java sources." 
Change-Id: Ic640c37f3cef5578022866529a8e576eba8d745d

Files:

M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavGraph.kt

Hash: ca3ba4e8cad00096390024507b7db28bbe6e2ed5
Date: Thu Nov 28 16:38:58 2024

cl...@google.com <cl...@google.com> #16Dec 2, 2024 09:42PM

Marked as fixed.

Fixed and available in navigation-2.9.0-alpha04

Message last modified on Dec 2, 2024 10:29PM

da...@gmail.com <da...@gmail.com> #17Dec 2, 2024 10:19PM

I have tried this fix by using navigation-2.9.0-alpha03 and removed the temp fix of implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3' however the same error has returned during build:

"class file for kotlinx.serialization.KSerializer not found"

The build is successful when retaining implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3'

Is this expected, or is there perhaps something else I'm not doing?

cl...@google.com <cl...@google.com> #18Dec 2, 2024 10:30PM

Typo - it is available in navigation-2.9.0-alpha04.

te...@gmail.com <te...@gmail.com> #19Dec 6, 2024 06:15AM