Status Update
Comments
st...@gmail.com <st...@gmail.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
ma...@gmail.com <ma...@gmail.com> #3
o....@afse.eu <o....@afse.eu> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
sa...@gmail.com <sa...@gmail.com> #5
cc...@google.com <cc...@google.com> #6
Can someone hitting this error please attach the .perfetto-trace files for the given failing test? The path is printed in logcat, if they aren't copied to the host already.
Is this only reproducing on beta03?
ma...@gmail.com <ma...@gmail.com> #7
Regarding the .perfetto-trace while from Android Studio the trace is readable, I tried uploading it to
cc...@google.com <cc...@google.com> #8
I think I've been able to reproduce the issue locally - on a Pixel 2 API 29, I've seen cold startup benchmarks specifically, fail, though they have a different stack:
02-11 11:37:32.531 13395 13429 E TestRunner: java.util.NoSuchElementException: Collection contains no element matching the predicate.
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.perfetto.StartupTimingQuery.findEndRenderTimeForUiFrame(StartupTimingQuery.kt:202)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.perfetto.StartupTimingQuery.getFrameSubMetrics(StartupTimingQuery.kt:171)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.StartupTimingMetric.getMetrics$benchmark_macro_debug(Metric.kt:275)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.MacrobenchmarkKt.macrobenchmark(Macrobenchmark.kt:208)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.MacrobenchmarkKt.macrobenchmarkWithStartupMode(Macrobenchmark.kt:300)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.junit4.MacrobenchmarkRule.measureRepeated(MacrobenchmarkRule.kt:102)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.macro.junit4.MacrobenchmarkRule.measureRepeated$default(MacrobenchmarkRule.kt:92)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.testutils.MacrobenchUtilsKt.measureStartup(MacrobenchUtils.kt:81)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.testutils.MacrobenchUtilsKt.measureStartup$default(MacrobenchUtils.kt:75)
02-11 11:37:32.531 13395 13429 E TestRunner: at androidx.benchmark.integration.macrobenchmark.TrivialStartupBenchmark.startup(TrivialStartupBenchmark.kt:40)
...
Traces attached from the same benchmark run - iter 0 has the process named correctly, iter 1 does not - Perfetto is using the shortened process name. +Lalit - we're using bundled perfetto in this case.
We previously supported truncated process names in our queries, but thought we'd fixed all the cases where they occur as part of
Lalit - is the problem here that we're
Re
cc...@google.com <cc...@google.com> #9
Running TrivialStartupBenchmark, COLD only. Pixel 2, 4 parameterized tests, 10 iters each.
API 29 Bundled perfetto:
proc_stats_poll_ms = 10000, // 4 failures
proc_stats_poll_ms = 1000, // 4 failures
proc_stats_poll_ms = 500, // 3 failures
proc_stats_poll_ms = 100, // 0 failures
API 29 Unbundled perfetto:
proc_stats_poll_ms = 10000, // 0 failures
API 30 Bundled perfetto:
proc_stats_poll_ms = 10000, // 0 failures
Looks like proc_stats_poll_ms
is the problem when using bundled perfetto, and that scan_all_processes_on_start = true
isn't supported on the bundled copy until API 30.
Will put up a CL to use unbundled perfetto on API 29, and avoid throwing in this case.
la...@google.com <la...@google.com> #10
The problem is not actually that scan_all_processes_on_start = true
is not supported - scan_all_processes_on_start
was added in P (API 29) - see aosp/675862.
I looked a bit into the traces you linked Chris and it seems like for some reason, we do not scan the pid for the startup process on demand - I tried to do some git archeology to find which CL between Q and R fixed the issue but didn't get anywhere - since you've found a workaround for this anyway, I didn't look too much further.
ap...@google.com <ap...@google.com> #11
Branch: androidx-main
commit 11761ea71f42977ab15356a8d3a71cfb56034591
Author: Chris Craik <ccraik@google.com>
Date: Fri Feb 11 15:16:07 2022
Fix process naming in benchmarks on Android 10
Test: StartupTimingQueryTest
Test: TrivialStartupBenchmark
Fixes: 218668335
Relnote: "Fix missing metrics on Android 10, and
`NoSuchElementException` caused by process names not being captured
correctly in traces."
Change-Id: Ib4c173655d87ff8f5a8dd9959e6639fbb66e0ecd
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoCapture.kt
D benchmark/benchmark-macro/lint-baseline.xml
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoConfig.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/perfetto/StartupTimingQuery.kt
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/perfetto/StartupTimingQueryTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/perfetto/PerfettoCaptureWrapper.kt
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit 6d3e54e18cbe32cf99f75a433c440294997b1104
Author: Chris Craik <ccraik@google.com>
Date: Fri Feb 11 15:34:43 2022
Add api29_cold_startup_processname_truncated trace
Represents uncommon process name truncation issue observed on API 29,
with unbundled perfetto and large proc_stats_poll_ms values.
Bug: 218668335
Change-Id: I5998eadfb9f8aa1c831016fe99db0d2090bf7912
A testdata/api29_cold_startup_processname_truncated.perfetto-trace
cc...@google.com <cc...@google.com> #13
This fix should be available in beta04 next week.
Note that the fix assumes that the problem only occurs on Android 10 / API 29. If you have seen this problem on any other os version, please comment with the device, os version, and the trace from the failing iteration.
cc...@google.com <cc...@google.com> #15
The problem in
Tomas, can you try working around by adding a Thread.sleep(500)
and seeing if that solves the problem? Either the frames are being produced, and am start -W
isn't waiting for them (my guess), or the frame isn't getting rendered (much less likely).
ml...@google.com <ml...@google.com> #16
Thread.sleep(500)
helps.
Tried 5x 3iterations
- without sleep -> fails every time
- with sleep -> success every time
cc...@google.com <cc...@google.com> #17
Can you try and repro on API 30, and attach a few success traces?
I'll put up a workaround, and pass to Rahul to file a platform bug.
It's super weird this only affects warm startup, and not hot/cold.
cc...@google.com <cc...@google.com> #18
Passing over to Rahul.
I started a WIP CL for this, but found I wasn't able to repro the behavior in
Left some ideas for next investigation steps in that CL:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1991372
If am start -w
is still unreliable, we can consider something more complex to detect end of frame after startup, like polling dumpsys gfxinfo <pkg> report
:
ra...@google.com <ra...@google.com> #20
I can't reproduce this on API 32 for iosched
.
StartupBenchmark_startup[mode=COLD]
timeToInitialDisplayMs min 285.0, median 288.6, max 296.9
Traces: Iteration 0 1 2
StartupBenchmark_startup[mode=WARM]
timeToInitialDisplayMs min 84.2, median 85.0, max 89.2
Traces: Iteration 0 1 2
StartupBenchmark_startup[mode=HOT]
timeToInitialDisplayMs min 44.7, median 53.1, max 70.0
Traces: Iteration 0 1 2
ra...@google.com <ra...@google.com> #21
This is using 1.1.0-beta04
.
ml...@google.com <ml...@google.com> #22
Hm, so I tested the 1.1.0-beta04
on user
builds on:
- SM-F711B (API 30)
- Pixel3 (API 31)
- Pixel6 (API 32)
It always fails for WARM
on Pixel3 (API 31).
If I uninstall the target app from the devices (and let the tests install it), it even fails on the Pixel6 (API 32) for HOT
.
ra...@google.com <ra...@google.com> #23
mlykotom@ can you try reproducing this with this fix ? I can help you create a local maven artifact if that helps.
ap...@google.com <ap...@google.com> #24
Branch: androidx-main
commit c561b23db0af7e40bd7d3c023059c8e8615c4f27
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 07 16:38:29 2022
`am start -W` does not wait for the process to be up sometimes.
* This in turn causes failures due to missing metrics in the trace.
* To work around this we check for `Shell.isPackageAlive(packageName)`.
* Wait for upto an additional second for the process to be up.
Test: Ran `TrivialStartupBenchmark`s.
Fixes:
Change-Id: Id97312c8471a4707183ee39bfbe06e103487cf46
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/ShellTest.kt
ra...@google.com <ra...@google.com> #25
Can you try using ab/8275593 once its available (on androidx.dev) to see if you can still reproduce this issue ?
ml...@google.com <ml...@google.com> #26
The Pixel6 looks like fixed, but Pixel 3 Android 12 with StartupMode.WARM
still fails, but I found out it always happens for the last iteration.
E.g. if I specify iterations=7
, it will fail when running the 8th time (because one is for warmup).
ra...@google.com <ra...@google.com> #27
mlykotom@ can you add a device.waitForIdle()
in the measure block and see if that helps ?
cc...@google.com <cc...@google.com> #28
The CL as written doesn't do anything for warm startups, since the process is already alive.
Given how flaky this wait has been, I'm just had the thought we can rewrite this await behavior using gfxinfo to see if a frame has been produced. Will need to handle named subprocesses correctly though.
Rahul, can you file a big to the platform with the repro from your CL? am start -w should definitely wait for the process to come alive (and really, for the first frame too).
ra...@google.com <ra...@google.com> #29
Filed a platform bug at
cc...@google.com <cc...@google.com> #30
The remaining problem with startups not being detected should be solved by
If anyone hitting this problem still sees it in beta05 (with the workaround in 1.2.0-SNAPSHOT
with build 8353149 or later (once a snapshot build catches up).
cc...@google.com <cc...@google.com> #31
Last patch fixes startup benchmark, but has caused failures in the multiprocess benchmark, as well as all scrolling benchmarks since the launch pattern isn't consistent with startup mode. Working on these.
Description
Devices/Android versions reproduced on: Pixel XL Android 10
Running macrobenchmark for my app with StartupMode.COLD and
pressHome()
startActivityAndWait() with an additional Thread.sleep(500) as suggested in
The same completes successfully in Nokia x20 Android 12
I get the following:
java.lang.IllegalArgumentException: Unable to read any metrics during benchmark (metric list: [androidx.benchmark.macro.StartupTimingMetric@f783ee0]).
Check that you're performing the operations to be measured. For example, if
using StartupTimingMetric, are you starting an activity for the specified package
in the measure block?
at androidx.benchmark.macro.MacrobenchmarkKt.macrobenchmark(Macrobenchmark.kt:236)
at androidx.benchmark.macro.MacrobenchmarkKt.macrobenchmarkWithStartupMode(Macrobenchmark.kt:300)
at androidx.benchmark.macro.junit4.MacrobenchmarkRule.measureRepeated(MacrobenchmarkRule.kt:102)
at androidx.benchmark.macro.junit4.MacrobenchmarkRule.measureRepeated$default(MacrobenchmarkRule.kt:92)
at com.example.benchmark.ExampleStartupBenchmark.startup(ExampleStartupBenchmark.kt:46)
at com.example.benchmark.ExampleStartupBenchmark.startupNoCompilation(ExampleStartupBenchmark.kt:33)