IssueTracker

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

1. Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.

2. Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

Thank you, I'll try it and check.

Hello. I have similar experience.

• I'm using mlkit-language 16.1.1
• I didnot meet this error until using AGP 4.2
• I can get this error since using AGP 7.0
• This error raised on Release build only(minimized by R8)
• This error raised without obfuscation.

Also I found there is a post which presents same issue on stackoverflow.

https://stackoverflow.com/questions/68832304/mlkit-translate-sdk-crashes-in-release-build

I tried the repro steps but got a NPE when I run ./gradlew :app:pPRUA

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.NullPointerException
> java.lang.NullPointerException (no error message)

Could you also check if this is reproducible on 17.0.0 or 17.0.1? If yes, could you attach the full log that I can take a look? Thanks!

Here are gradle build scan logs for each branches.
All builds were clean build, and disabled build cache.

• mlkit_agp7 : https://scans.gradle.com/s/qrymdqfzwokbq
• mlkit_agp42 : https://scans.gradle.com/s/b6644hzfyfhaw
• mlkit_agp7_r8_disable_inline_optimizer : https://scans.gradle.com/s/c6h5hy2nxod4u
  • You can see R8 debug mode on build log : https://scans.gradle.com/s/c6h5hy2nxod4u/console-log#L95

Also, I pushed to update MLKit Language Id version 17.0.1 on mlkit17_agp7 branch And here is gradle build scan

• https://scans.gradle.com/s/ytaa2kkbp5vc4
  • Here is version of com.google.mlkit:language-id

And here is crash log after apply 17.0.1
You can see that BuildId of liblanguage_id_l2c_jni.so was changed from 859ec0ec2000a39e6ae8ed42e1704f46 to be6e59455cc10135330c93acdebfc121

10-20 03:07:24.522 24587 24628 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426 in tid 24628 (pool-3-thread-3), pid 24587 (e.myapplication)
10-20 03:07:25.190 24710 24710 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-20 03:07:25.190 24710 24710 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-20 03:07:25.190 24710 24710 F DEBUG   : Revision: 'MP1.0'
10-20 03:07:25.190 24710 24710 F DEBUG   : ABI: 'arm64'
10-20 03:07:25.190 24710 24710 F DEBUG   : Timestamp: 2021-10-20 03:07:24.583346246+0900
10-20 03:07:25.190 24710 24710 F DEBUG   : Process uptime: 0s
10-20 03:07:25.190 24710 24710 F DEBUG   : Cmdline: com.example.myapplication
10-20 03:07:25.190 24710 24710 F DEBUG   : pid: 24587, tid: 24628, name: pool-3-thread-3  >>> com.example.myapplication <<<
10-20 03:07:25.190 24710 24710 F DEBUG   : uid: 10240
10-20 03:07:25.190 24710 24710 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426
10-20 03:07:25.190 24710 24710 F DEBUG   :     x0  0000007b54da9d30  x1  0000007d9a5fe7cc  x2  0000000000000000  x3  0000000000000010
10-20 03:07:25.190 24710 24710 F DEBUG   :     x4  0000000000000000  x5  0000007c34dbc79c  x6  0000002f0000083b  x7  000003c300002dd5
10-20 03:07:25.190 24710 24710 F DEBUG   :     x8  0000000000000001  x9  0000000000000004  x10 0000000000000010  x11 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x12 0000000000000000  x13 000000000000217e  x14 0000007acf9932a8  x15 000000000000217e
10-20 03:07:25.190 24710 24710 F DEBUG   :     x16 0000000000000000  x17 0000007d9a564c78  x18 0000007a6ef18000  x19 0000007c34dbc580
10-20 03:07:25.190 24710 24710 F DEBUG   :     x20 0000007ca4dc7170  x21 0000007ca4dc7800  x22 0000007ca4dc71e0  x23 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x24 0000000000000018  x25 0000000000000007  x26 0000000000000006  x27 0000000000000004
10-20 03:07:25.190 24710 24710 F DEBUG   :     x28 0000007ca4dc7090  x29 0000007cb4da9940
10-20 03:07:25.190 24710 24710 F DEBUG   :     lr  0000007a770a9624  sp  0000007a6f7de9c0  pc  0000007a770a96a8  pst 0000000020000000
10-20 03:07:25.190 24710 24710 F DEBUG   : backtrace:
10-20 03:07:25.190 24710 24710 F DEBUG   :       #00 pc 00000000000386a8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #01 pc 00000000000388a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #02 pc 00000000000844a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #03 pc 000000000008783c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #04 pc 0000000000035fc4  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #05 pc 0000000000034954  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #06 pc 00000000000340e8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (Java_com_google_mlkit_nl_languageid_internal_ThickLanguageIdentifier_nativeIdentifyPossibleLanguages+108) (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #07 pc 00000000002d9a44  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #08 pc 000000000020a700  /apex/com.android.art/lib64/libart.so (nterp_helper+5648) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #09 pc 00000000000cd0dc  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #10 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #11 pc 00000000000ccfa8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #12 pc 0000000000557cb4  /system/framework/arm64/boot-framework.oat (android.os.Binder.transact+148) (BuildId: 43a571a0ad85d6451b47016336a541ecb0eb12bb)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #13 pc 000000000020b53c  /apex/com.android.art/lib64/libart.so (nterp_helper+9292) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #14 pc 00000000000b7aba  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #15 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #16 pc 00000000000a7496  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #17 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #18 pc 00000000000a7360  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #19 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #20 pc 000000000009e46c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #21 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #22 pc 00000000000d33d6  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #23 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #24 pc 000000000009df0a  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #25 pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #26 pc 000000000009e350  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #27 pc 000000000037b9ac  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #28 pc 00000000003751d4  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #29 pc 000000000020aec4  /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #30 pc 000000000009e370  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #31 pc 00000000001bf35c  /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #32 pc 00000000002d0164  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #33 pc 000000000031ccac  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #34 pc 00000000003cf8a0  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #35 pc 0000000000460894  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #36 pc 00000000000b1910  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #37 pc 00000000000513f0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)

Cross-posted on R8 issue tracker. https://issuetracker.google.com/issues/203573699

Hi,

Looks like we figured out the root cause in b/203573699

For temporary workarounds for the existing SDKs, you need to add this rule

-keep class com.google.mlkit.nl.languageid.internal.LanguageIdentificationJni { *; }

for language-id 16.1.1, and add this rule

-keep class com.google.mlkit.nl.languageid.internal.ThickLanguageIdentifier { *; }

for version language-id 17.0.0+ for the newer model.

We'll fix this issue in the upcoming release so that you'll not need these workarounds in the future release.

Thanks a lot for reporting this issue!

Added workarounds in Known issues section in public docs.

I have found a workaround that works for me.

The LazyPagingItems.kt file was copied from the androidx.paging:paging-compose artifact into my project (it doesn't have any other dependencies).

I modified it to add a flag inside the LazyPagingItems class:

    /**
     * The number of items which can be accessed.
     */
    val itemCount: Int get() = itemSnapshotList.size


    // The code below was added:

    /**
     * Added to fix scroll state restoration - wait for this flag to be set to true
     * before setting your [LazyListState] on the [LazyColumn].
     * 
     * @author Baptiste Candellier
     */
    var hasRestoredItems: Boolean = false
        private set

The flag is set inside the updateItemSnapshotList() method

    private fun updateItemSnapshotList() {
        itemSnapshotList = pagingDataDiffer.snapshot()

        // The code below was added:
        hasRestoredItems = true
    }

Then on my composable, I wait for this flag to become true to pass the "real" LazyListState, that comes from a ViewModel.

            LazyColumn(
                // Wait for the items to be restored to set the real list state, so that it isn't reset in the meantime
                state = if (lazyPagingItems.hasRestoredItems) lazyListState else LazyListState()
            ) {
                // ... your items here

There might be edge cases but it works for me, I hope it helps.

rememberLazyListState() is doing pretty much the same internally. Could you please elaborate a bit more on why the build in solution doesn't work for you?

Ouch! I'm new on Compose, so don't know how state, rememberLazyListState() works so i directly pass

fun ProfileTab() LazyVerticalGrid( state = rememberLazyListState(), ) }

and while i switch tab from 1->2 and back from 2-> the state of LazyVerticalGrid regenerated, but i didn't try to save in state on globally and pass in composable.

After i seeing this https://developer.android.com/jetpack/compose/state, i understand state and usage of state, and also found that i make mistake previously comment.

https://issuetracker.google.com/issues/177245496#comment20 its works and thank you for check my request and guiding me.

as a lot of people mentioned, LazyColumn can't restore position correct when Paging has a Header
this is because rememberLazyListState can restore position when there are at least 1 element in the list
but if there is a Header or Footer in LazyColumn, then it will restore in first frame when paging's item count is still 0

so I store listState in ViewModel and restore it when Paging item count > 0

val listState = if (pagingData.itemCount > 0) viewModel.listState else rememberLazyListState()

Try this workaround, you need to check lazyPagingItems before use:

    @Composable
    fun MainFrame(lazyPagingItems: LazyPagingItems<PerformanceEvent.Building>) {
        val refresh = lazyPagingItems.loadState.refresh

        // My temp solution
        if (lazyPagingItems.itemCount == 0 && refresh is LoadState.NotLoading ) return //skip dummy state, waiting next compose

        LazyColumn { ... }
     }

Here is a workaround:

@Composable
fun <T : Any> LazyPagingItems<T>.rememberLazyListState(): LazyListState {
    // After recreation, LazyPagingItems first return 0 items, then the cached items.
    // This behavior/issue is resetting the LazyListState scroll position.
    // Below is a workaround. More info: https://issuetracker.google.com/issues/177245496.
    return when (itemCount) {
        // Return a different LazyListState instance.
        0 -> remember(this) { LazyListState(0, 0) }
        // Return rememberLazyListState (normal case).
        else -> androidx.compose.foundation.lazy.rememberLazyListState()
    }
}

Should we still expect a fix from any Jetpack library ?

If your project does not have a deep dependency on the paging3 library, I recommend implementing a simple paging library yourself to avoid all the weird features of paging3. Paging library needs the coordination of the view layer and the model layer. It doesn't make sense to encapsulate these together.

Here's an example from my project. If you don't need to modify the list, it can be implemented much simpler.

https://gist.github.com/FishHawk/6e4706646401bea20242bdfad5d86a9e

Still not fixed in latest versions, workaround works. Please consider re-opening the issue.

Seconded. Still a problem in 1.3.1

https://issuetracker.google.com/issues/177245496#comment24 works

The default case (all of your items are loaded asynchronously) was fixed in comment#2. For Paging, there is the additional requirement that you must be using cachedIn in your layer above Compose (e.g., your ViewModel layer).

However, the case where you have some items available immediately (like a header and footer) and some items available only asynchronously, is not fixed. This is broken whether you use Paging or not - any data loaded from a Flow would suffer this same problem (as they also would not be available in the first composition).

Creating an generic API for informing the Lazy Layout of when all asynchronously loaded items have finished loading (particularly noting that there can be multiple items blocks loading from multiple asynchronous sources) is not something we can solve in the short or medium term.

That being said, we believe there may be a way to solve this in the specific case of headers+footers and a single call to collectAsLazyPagingItems without having to wait for an overhaul of either the Paging or Lazy layout APIs, so we will be reopening this issue to track that internal investigation.

Sounds like Paging and Component are being developed with a lot of various serious issues that are piling with each version, and the team does not have any intention of fixing them. That's alright, at least now we can finally stop waiting for this to be fixed and instead stop using them entirely. Good luck with this.

Compose requires an initial state for valid first composition.

Paging 3's entire architecture is based around emitting data through a Flow that doesn't emit until collected.

Therefore, significant changes within Paging 3 are required to enable initial states in paging-compose without collection. While these changes are not easily resolvable, we hope to address them in the coming year.

https://issuetracker.google.com/issues/177245496#comment23 - how this condition is going to help if you completely remove the list from composition?

This has been fixed internally and will be available in the next release. The next release version is TBD.

In short, the fix works by making cached data immediately available for presentation after config change / navigation. This prevents the list from having zero items right after config change/ navigation so the scroll state will be preserved without requiring workarounds such as comment#24.

That said, it only works if there is cached data to begin with. This means you need pager.flow.cachedIn(scope). Note that any PagedData mapping/transformations should be applied prior to cachedIn(), such as

val pager = pager.flow.map { pagingData -> 
    pagingData.map {
       // map items
    }
}.cachedIn(scope)

Is it going to fix incorrect loadState (Loading) as well (to avoid displaying incorrect refresh indicator to users)?

val lazyPagingItems = viewModel.pagingDataExample.collectAsLazyPagingItems()
val loadState = lazyPagingItems.loadState.refresh // loadState == Loading initially on config changes/navigation

It should be NotLoading if data is returned from cahce and no request to refresh is triggered

Yes it will start with NotLoading if displaying cachedData.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-common:3.2.0-alpha05

I'll note that while some of the changes from this bug made it into Paging 3.2.0-alpha05, the important ones did not - it'll be in the next release of Paging.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-compose:1.0.0-alpha20

comment#51 are you using cachedIn and paging-common 3.2.0-alpha06?

Re comment#51 - please file a new bug with a sample project that reproduces your issue.

comment#52, comment#53- Sorry, I did a mistake, I used function instead of val in viewmodel. Bug has been fixed now. Tested...

Regarding the workaround from comment#24, if you want firstVisibleItemIndex and firstVisibleItemScrollOffset to continue to remain the same in case other code depends on them, it looks like the workaround should be modified to this?

@Composable
fun <T : Any> LazyPagingItems<T>.rememberLazyGridState(): LazyGridState {
    val state = androidx.compose.foundation.lazy.grid.rememberLazyGridState()

    return when (itemCount) {
        // Return a different LazyListState instance.
        0 -> remember(this) {
            LazyGridState(
                firstVisibleItemIndex = state.firstVisibleItemIndex,
                firstVisibleItemScrollOffset = state.firstVisibleItemScrollOffset
            )
        }
        // Return rememberLazyListState (normal case).
        else -> state
    }
}

If there is a combined flow, cachedIn does not seem to work. Could you please confirm?

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

If you call the pager again with collectAsLazyPagingItems(), LoadState will be called LoadState.Loading rather than LoadState.NotLoading.

Re comment#56 - please file a new bug with a sample project that reproduces your issue

Re comment#58 - there's no difference between navigating a single screen away and navigating multiple screens away - in either case, the ViewModel for your original screen stays in memory the entire time and the composition for the old screen is removed.

Please file a new issue with a sample project that reproduces your issue if you are seeing something different.

im having a similar problem as comment#58 but when navigating to another screen. I update some of the room paging elements in the previous composable with lazy column and when i return scroll state is lost, if i navigate and the return without changing any items from room, state is preserved. The workaround of the mentioned comment is working for me so guess it has to do with the paging behaviour rather than my implementation .... version 3.2.1 too

Re comment#60 can you please file a separate bug with a sample app that reproduces the issue?

Yes they do not want the if and placeholders to be inside the LazyColumn we are supposed to use if outside of the LazyColum.

The workaround is to use a fake lazystate until your data is loaded.

See for example solution https://issuetracker.google.com/issues/177245496#comment62

re comment#62 if you are caching the pager flow with cachedIn(), you shouldn't need a workaround. Can you upload a sample app for me to take a look?

Cachein does not keep the data when the app is killed in the background or viewmodel is unloaded.

That's cute but you might actually want to read the issue.

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

my-version = androidx.paging:paging-compose:3.3.5

When otherFlow updates data, an error occurs: Attempt to collect twice from pageEventFlow, which is an illegal operation. Did you forget to call Flow<PagingData<*>>.cachedIn(coroutineScope)?

comment#69 can you please file a separate bug for your issue?