startActivityAndWait doesn't work on Automated Test Devices [228946895]

Fixed

Bug

Status Update

No update yet.

Description

wk...@google.com

created issue #1

Apr 12, 2022 12:30PM

startActivityAndWait can't detect Activity launch on Automated Test Devices, a type of Gradle Managed Device that is headless:

android {
    ...
    testOptions {
        managedDevices {
            devices {
                rootedDeviceAtd (com.android.build.api.dsl.ManagedVirtualDevice) {
                    device = "Pixel 2"
                    // Use only API levels 27 and higher
                    apiLevel = 31
                    // To include Google services, use "google"
                    systemImageSource = "aosp-atd" // <- WORKS WITH "aosp", NOT "aosp-atd"
                }
            }
        }
    }
}

It seems that no frames in framestats are marked with 0x1 flag, so lastLaunchNs is always null. Could you fall back to lastFrameNs in that case or think of something else?

I'll try to add someone from ATD here to weigh in on this from the ATD side and why it doesn't produce launch frames.

Comments

br...@google.com <br...@google.com> #2Apr 19, 2022 12:43AM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

cc...@google.com <cc...@google.com> #3Apr 19, 2022 05:19PM

yea i'll take it.

br...@google.com <br...@google.com> #4Apr 19, 2022 05:26PM

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.

wk...@google.com <wk...@google.com> #5Apr 20, 2022 07:40AM

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

cc...@google.com <cc...@google.com> #6Apr 26, 2022 12:07AM

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)

wk...@google.com <wk...@google.com> #7Apr 26, 2022 11:08AM

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

cc...@google.com <cc...@google.com> #8Apr 26, 2022 05:29PM

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

Message last modified on Apr 26, 2022 05:30PM

ar...@google.com <ar...@google.com> #9Apr 26, 2022 08:31PM

Daniel, can you help with the download issue?

da...@google.com <da...@google.com> #10Apr 26, 2022 10:57PM

Generated invalid hash string "system-images;android-31;default;x86_64" from the DSL. This should not occur.

That looks like an aosp ("default") image not an atd image (would be system-images;android-31;aosp_atd;x86_64).

Can you run:

./gradlew --info wear:compose:integration-tests:macrobenchmark:rootedDeviceAtdSetup

And send the output?

wk...@google.com <wk...@google.com> #11May 6, 2022 02:39PM

Hey Chris, I know this is probably low priority, but just in case you did upload any fixes, I tried on latest snapshot of Macrobenchmark today and still got the same error

ap...@google.com <ap...@google.com> #12Sep 9, 2022 08:55PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-main

commit 597e8b0ade2b28bd01657b806307c6838dea54e7
Author: Chris Craik <ccraik@google.com>
Date: Thu Sep 08 16:51:06 2022

Remove check for launch flag for launch confirmation

Fixes: 244594339
Fixes: 228946895
Test: ./gradlew bench:b-m:cC

Relnote: "Fix bug where startActivityAndWait would timeout trying to
wait forlaunch completion on emulators by reducing strictness of frame
detection."

Change-Id: Ibe2c6c5519973f5c3311f4abb02e21c66a77bd2e

M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/FrameStatsResult.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/FrameStatsResultTest.kt
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/MacrobenchmarkScopeTest.kt

https://android-review.googlesource.com/2212663

cc...@google.com <cc...@google.com> Sep 9, 2022 08:59PM