Status Update
Comments
ys...@google.com <ys...@google.com> #3
However, during predictive back animation the entering screen is drawn on top of the exiting screen as the video linked in the issue also reproduces
navigation library used: 2.8.0-alpha06
ra...@google.com <ra...@google.com> #4
It looks like a possible root cause could be that the exiting destination is correctly drawn on top when there's a pop, but predictive back press isn't actually pop and therefore isn't drawn on top.
Most of the logic seems to check composeNavigator.isPop.value || inPredictiveBack
, but targetZIndex
only checks pop when it should instead probably check for either pop or inPredictiveBack?
ys...@google.com <ys...@google.com>
ra...@google.com <ra...@google.com> #5
Once a sample project is provided we will reopen this issue, as we cannot reproduce this at the moment.
ys...@google.com <ys...@google.com> #6
I have created a sample project which reproduces the issue, and attached a video.
When enableOnBackInvokedCallback
is enabled in manifest, the pop exiting destination is incorrectly drawn underneath the pop entering destination. When it is disabled, everything works as expected (but no predictive back)
cc...@google.com <cc...@google.com> #7
It will only delete files at the beginning of runs. If you're trying to store files on device between runs, you'll already have problems due to the json file clobbering the old file for each run. Profiling/Perfetto traces are sort of coincidentally immune to this, because we have to give them unique names due to how Studio file linking works.
In general, we want persisting files from run to run to be a responsibility of the host, and we don't want to persist more data on the device run to run than gradle already does. I'll acknowledge that we don't help you out much there today though - AGP will similarly fully clear pulled test output files after each run.
Probably worth a separate bug.
ys...@google.com <ys...@google.com> #8
This might be a quirk of my currently interactive workflow. I'm in an exploratory phase for creating the macrobenchmark tests, or using it for evaluating various enabled options. I find managing an archive of trace files confusing. No objection from me.
Description
Version used: 1.2.0-alpha14
When testing variants of UIs, it would be great to be able to capture a screenshot for a macrobenchmark test. Useful for a few reasons
- understanding a failure if the ui automator can't interact at some point
- confirm the variant you are testing is as you expect
Ideally saving the screenshot with the same naming as the perfetto trace, and putting a visible trace marker in perfetto / logs.