Fixed
Status Update
Comments
ba...@gmail.com <ba...@gmail.com> #2
Comment has been deleted.
ba...@gmail.com <ba...@gmail.com> #3
cc...@google.com <cc...@google.com> #4
Project: platform/frameworks/support
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 ( b/140759491 ).
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
https://android-review.googlesource.com/1288456
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
ml...@google.com <ml...@google.com> #5
I was thinking, since this is already in beta03
, should we treat it as a bug and not addition to 1.3?
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
commit 3bfcb889231d3254cf9e8db8df0c2a06f58c152a
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Apr 02 14:14:17 2024
TraceSectionMetric now supports slices created using `Trace.{begin|end}AsyncSection`.
* TraceSectionMetric now additionally looks at Perfetto `process_track`s when looking at named slices.
Test: PerfettoTraceProcessorTest
Fixes: 300434906
Relnote: TraceSectionMetric now supports slices created using `Trace.{begin|end}AsyncSection`.
Change-Id: I91b326e121fcca4b3ce8f65381eea87de796cdd1
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/perfetto/PerfettoTraceProcessorTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/perfetto/PerfettoTraceProcessor.kt
https://android-review.googlesource.com/3023506
Branch: androidx-main
commit 3bfcb889231d3254cf9e8db8df0c2a06f58c152a
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Apr 02 14:14:17 2024
TraceSectionMetric now supports slices created using `Trace.{begin|end}AsyncSection`.
* TraceSectionMetric now additionally looks at Perfetto `process_track`s when looking at named slices.
Test: PerfettoTraceProcessorTest
Fixes: 300434906
Relnote: TraceSectionMetric now supports slices created using `Trace.{begin|end}AsyncSection`.
Change-Id: I91b326e121fcca4b3ce8f65381eea87de796cdd1
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/perfetto/PerfettoTraceProcessorTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/perfetto/PerfettoTraceProcessor.kt
na...@google.com <na...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-macro:1.3.0-alpha03
Description
Component used: Macrobench ToT, androidx.tracing alpha 1.3.0-alpha02
When you add an asynchronous trace section to the app with
Trace.beginAsyncSection
, it doesn't contain information about the thread and thus the default parametertargetPackageOnly=true
ofTraceSectionMetric
won't find this section.For example, this trace from FTL contains
InteropTransitionToFirstDraw
When checking the slice without the
thread_track
, it's returned properlyBut when simulating the
targetPackageOnly = true
query, it's not found because of thethread_track
Can we improve this query somehow? Maybe if we used
LEFT JOIN
and check if the slice actually have any thread data then we can filter based on package?