IssueTracker

The attached Build Scan log shows that the emulator process crashed unexpectedly. Could you rerun your task with --info and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true to get more information about the emualtor process logs?

https://scans.gradle.com/s/llyxjwf4ipuzc

No idea why the scan does not contain log information, here you are: https://productionresultssa13.blob.core.windows.net/actions-results/3ec7e316-56eb-4f55-a7dd-511a2f3cf729/workflow-job-run-2623c0b7-dd66-5503-5665-c65c84dbf243/logs/job/job-logs.txt?rsct=text%2Fplain&se=2024-04-02T20%3A32%3A33Z&sig=Z1BPg7s513VC7nKkyGYEmknivAGxlX3Kdx0NsX%2BttW8%3D&sp=r&spr=https&sr=b&st=2024-04-02T20%3A22%3A28Z&sv=2021-12-02

The link in comment#4 seems not to be working for me. I got "AuthenticationFailed" error. If you run task with those --info and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true, the emulator process output its kernel logging to stdout. Do you see any stacktrace or segfault in the log?

That's strange, the repo and the build is public... But I attached the logs as file

I looked into the logs and it turns out, the runner didn't have enough disk space. I guess the root cause is the Gradle update causing another Gradle major version (and its new transform-4) folder to cache was too much. Anyway, a better error message of the exit code of GMD would be helpful.

Thanks for uploading the log! Yes, the emulator kernel log says the issue was the insufficient disk space: 2024-04-02T18:31:45.7078429Z ERROR | Not enough space to create userdata partition. Available: 7177.027344 MB at /home/runner/.config/.android/avd/gradle-managed/dev34_aosp_atd_x86_64_Pixel_2.avd, need 7372.800000 MB.

Also, I agreed that GMD should diagnose errors and can provide better messages.

Let me rename this issue's title to improve the error message for disk space error.

I've added a fix that will surface all error messages from the emulator in the exception when it closes unexpectedly.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Meerkat | 2024.3.1 Canary 2
• Android Gradle Plugin 8.9.0-alpha02

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

It might be too late for some people, but if people want to know how to tackle this I've played around with it on a pet project ( didn't test this in a prod environment, so a heads up there ):

@Composable
fun <T : Any> LazyPagingItems<T>.refreshLoadState(): State<LoadState> = produceState<LoadState>(
  LoadState.NotLoading(false),
) {
  snapshotFlow { loadState }
    .drop(1)
    .map { it.refresh }
    .collect { value = it }
}

Re comment#10, as explained in comment#2 compose requires an initial state.

Given the most common use case displays paged data right away, defaulting LoadState to Loading means the most common use case will not have to drop first LoadState (versus if it were NotLoading).

I don't get how initial state being anything would affect the use case of displaying paged data right away. Wouldn't the LoadState change before the user has time to notice?

IMHO, initial state being NotLoading would be the sanest choice. In the case of waiting before starting to load data, the correct state would be shown to the user and in the case of loading data right away, it would immediately change to Loading, so the correct state would be shown to the user in this case as well.

Re comment#13, when you call collectAsLazyPagingItems compose launches collection on Pager right away. By the time pager.collectAsLazyPagingItems() returns, data is loading, so initial Loading is the correct state.

Initializing with NotLoading also causes other issues (which is why Paging with Views was also refactored to not initialize with NotLoading):

1. For users who rely on first NotLoading state as indication of refresh complete, they have to manually filter out the first NotLoading
2. If loading animation (i.e. spinners) are based on LoadStates, you could end up seeing a blank screen --> spinner --> data loaded in, and that is not a good user experience.