Status Update
Comments
br...@google.com <br...@google.com> #2
I work on the ATD images. Can you provide a code sample of what isn't working? ATD ships with HardwareRenderer#isDrawingEnabled off by default, so perhaps that intefers with the frame statistics.
cc...@google.com <cc...@google.com> #3
Wojtek - what's the goal here, is this for baseline profile tests? Are you suppressing an emulator warning?
Brett - for some context, macrobenchmark has found that platfrom am start -w
isn't reliable in itself for capturing end of first activity frame, so instead we do a combination of that + getting framestats from dumpsys gfxinfo <package> framestats
. See commit message:
- Is there a good way to detect isDrawingEnabled from within test, or from shell command, pre T?
- Does isDrawingEnabled=false just disable renderthread, or does it remove rendering behavior at the view level too (in which case we should discourage it for baseline profile generation)
br...@google.com <br...@google.com> #4
You can use
jreck can give the authoritative answer, but IIUC isDrawingEnabled=false doesn't disable renderthread per say, it just makes renderthread skip forwarding draw commands to the hardware.
wk...@google.com <wk...@google.com> #5
@ccraik - yes, this is for baseline profiles. This is low priority, but I thought I'd file it anyway in case it's a symptom of some larger problem either with our Activity launch detection or with ATDs.
More context why I'm investigating this: I want to make it as easy as possible for apps and libraries to integrate generating profiles into their build/CIs, and with Gradle Managed Devices it becomes really easy and we can give folks a copy-pasteable recipe for doing it in Gradle, regardless of CI system used etc.
Using Automated Test Device images (when running with Gradle Managed Devices) would be even faster and require fewer resources (important for example on CIs with limited RAM etc), but it's not critical, hence the lower priority.
cc...@google.com <cc...@google.com> #6
How do I download the managed device? The
./gradlew wear:compose:integration-tests:macrobenchmark:rootedDeviceAtdDebugAndroidTest
(Tried also with -Pandroid.sdk.channel=3
)
and I get the error:
> Task :wear:compose:integration-tests:macrobenchmark:rootedDeviceAtdSetup FAILED
WARNING:system-images;android-31;default;x86_64 package is not installed.
...
* What went wrong:
Execution failed for task ':wear:compose:integration-tests:macrobenchmark:rootedDeviceAtdSetup'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.ManagedDeviceSetupTask$ManagedDeviceSetupRunnable
> Generated invalid hash string "system-images;android-31;default;x86_64" from the DSL. This should not occur.
wk...@google.com <wk...@google.com> #7
they should be downloaded automatically, but I vaguely remember having a similar problem... I think this mention in the docs was what helped me:
Before getting started, make sure you update the Android Emulator to the latest available version
Can you launch the canary version of Android Studio and "Check for updates..." to make sure you have the latest version of emulator installed? You could also try deleting ~/.android/gradle/avd
Let me know if that helped and if not I can look into it more
cc...@google.com <cc...@google.com> #8
Tried updating to "Android Emulator (revision: 31.3.7)", which didn't help.
I don't see ~/.android/gradle/avd
, did you mean ~/.android/avd
? Should this be separate from all my standard emulators?
I'll just upload a speculative fix, and let you try it out with a snapshot, since that's easy.
ar...@google.com <ar...@google.com> #9
Daniel, can you help with the download issue?
da...@google.com <da...@google.com> #10
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> #11
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> #12
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
Description
startActivityAndWait can't detect Activity launch on Automated Test Devices, a type of Gradle Managed Device that is headless:
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.