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!

Compose does not ensure repeatable read consistency across a sub-composition boundary (that is we do not guarantee that a mutable value read by the parent composition will be the same value read by the sub-composition).

However, as I noted above, we will be changing the runtime to avoid recomposing sub-compositions that have been detected in the parent composition as being removed, point (2) in comment #3 above. This change should land this week. This changes requires an API change to how composition interacts with the recomposer so it is not a candidate for cherry-picks to earlier versions and, as it is a behavior change, requires going though the our normal release cycle to ensure it doesn't regress behavior or performance. We will also be landing, as a separate change, a solution to (1) above, which will also require API changes. (1) is riskier and we are doing it as a separate change as (2) is strictly an improvement over current behavior (much less likely to cause a regression) than (1) and can land independently of (1).

These two changes will change the rules so that the assumption how data dependencies are handled across sub-composition boundaries, as is implied by the assert above in comment #1, will be honored for composition scheduled by the recomposer. However, as composition can occur at anytime for a sub-composition, there are cases where the assert above will throw and assuming it will always being true should not be relied on. These changes make it so the recomposer, at least, will not introduce violations to this assumption, and will require explicit calls to setContent of a Composition to be violated. When and why setContent is called is in the hands to the code that created the composition, not the recomposer, or the rest of the runtime, which is why we cannot guarantee the assert assumption will always hold.

Theses changes will not ensure repeatable read consistency across a sub-composition boundary, but they will make it much easier for code to avoid requiring it by avoiding recomposing code that is being removed. Because repeatable read consistency is not guaranteed it is recommended that code not rely on it and avoid it by avoiding repeating reads as shown in the examples in comment #5.

I am sorry if my calling this a feature request above implied a lack of priority. We are treating this change as a high priority change for the next feature release. As it requires an API change and a change to the rules of how composition works I think of it as a feature request but will leave it marked as a bug type to avoid confusion.

As Ben and I found a relatively fast and safe way to fix this that didn't involve an API changes, we have started the process to cherry-pick this to earlier releases.

Which version is this in / going to be in?

This issue will be updated when it lands in a stable release.

I could not reproduce the crash above with 1.6.0-alpha01

The steps I took where:

1. Created a new android project using Android Studio Giraffe | 2022.3.1 RC 1
2. Replaced Greeting with the code in #1 (fixing the imports)
3. Ran the program
4. Pressed the button (crash reproduced)
5. Added the line implementation("androidx.compose.runtime:runtime:1.6.0-alpha01") to the dependencies
6. Update the compile sdk to 34.
7. Sync'ed gradle
8. Ran the program
9. Pressed the button (no crash)

Note the above fix is only a partial fix. There are cases that will continue to violate the implied constraint until the second part of the fix lands (explained above).

Also note that this doesn't guarantee the constraint implied by the assert will always hold, only that the runtime will try to avoid recomposing sub-compositions that might be exposed to the constraint. Any use of sub-composition can violate this constraint as the value might change between the time the main composition composes and the sub-composition composes and before the main composition can be recomposed to remove the sub-composition.

If you require consistency between a composition and its subcomposition you need to capture the state as #5, above. This change just avoids a common case would violate this constraint.