Assigned
Status Update
No update yet.
Comments
ro...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
cc...@google.com
yea i'll take it.
ma...@google.com
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.
ro...@google.com
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()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
ap...@google.com
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)
ap...@google.com
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} )
}
I actually have a WIP fix for it:
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} )
}
ap...@google.com
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
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
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit f32334a2f282467d49820319b94948ad80ac3768
Author: Chris Craik <ccraik@google.com>
Date: Wed Jun 21 15:20:13 2023
Add CpuEventCounters to microbenchmarks behind flag, root required
Test: CpuEventCounterTest
Test: TrivialKotlinBenchmark
Test: PerfettoOverheadBenchmark
Test: SynchronizedBenchmark
Test: CpuEventCounterBenchmark
Test: LazyListScrollingBenchmark
Bug: 286306579
Also improves warmup to use repeat duration directly, instead of
bypassing pause during warmup, since this was necessary to avoid
`measureRepeated { runWithTimingDisabled {} }` from taking an
extremely long time. What would happen is that the loop would take
e.g. 10ns during warmup, and say 2000ns during the actual run, since
starting/stopping counters is non-trivial. This would mean that
warmupManager would overshoot the target duration by 20x, since it
wasn't accounting for the true cost of pausing/resuming. Now, warmup
much more closely matches timing, which also helps us avoid hitting
cold code suddenly.
Set flags like the following:
```
testInstrumentationRunnerArguments["androidx.benchmark.cpuEventCounters.enable"]= 'true'
testInstrumentationRunnerArguments["androidx.benchmark.cpuEventCounters.timingPhaseMask"]= 'Instructions,CpuCycles'
```
Example output:
PerfettoOverheadBenchmark.traceBeginEnd
timeNs min 1,495.7, median 1,511.2, max 1,620.2
Instructions min 3,845.0, median 3,845.0, max 4,007.1
CpuCycles min 1,635.5, median 1,642.2, max 1,817.4
allocationCount min 0.0, median 0.0, max 0.0
PerfettoSdkOverheadBenchmark.traceBeginEnd_perfettoSdkTrace
timeNs min 580.8, median 585.4, max 653.6
Instructions min 3,830.6, median 3,959.1, max 3,969.1
CpuCycles min 1,642.3, median 1,650.5, max 1,668.8
allocationCount min 0.0, median 0.0, max 0.0
LazyListScrollingBenchmark.scrollProgrammatically_newItemComposed[LazyColumn]
timeNs min 273,686.5, median 275,024.7, max 364,566.3
Instructions min 642,749.5, median 642,837.1, max 683,841.6
CpuCycles min 706,229.0, median 709,797.1, max 808,859.2
allocationCount min 490.3, median 490.3, max 490.4
Change-Id: Ic938690476296899f058271ed56dfc3ee95aa2cf
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateConfigTest.kt
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/CpuEventCounterTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricsContainer.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MicrobenchmarkPhase.kt
D benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/CpuCounterBenchmark.kt
A benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/CpuEventCounterBenchmark.kt
https://android-review.googlesource.com/2634235
Branch: androidx-main
commit f32334a2f282467d49820319b94948ad80ac3768
Author: Chris Craik <ccraik@google.com>
Date: Wed Jun 21 15:20:13 2023
Add CpuEventCounters to microbenchmarks behind flag, root required
Test: CpuEventCounterTest
Test: TrivialKotlinBenchmark
Test: PerfettoOverheadBenchmark
Test: SynchronizedBenchmark
Test: CpuEventCounterBenchmark
Test: LazyListScrollingBenchmark
Bug: 286306579
Also improves warmup to use repeat duration directly, instead of
bypassing pause during warmup, since this was necessary to avoid
`measureRepeated { runWithTimingDisabled {} }` from taking an
extremely long time. What would happen is that the loop would take
e.g. 10ns during warmup, and say 2000ns during the actual run, since
starting/stopping counters is non-trivial. This would mean that
warmupManager would overshoot the target duration by 20x, since it
wasn't accounting for the true cost of pausing/resuming. Now, warmup
much more closely matches timing, which also helps us avoid hitting
cold code suddenly.
Set flags like the following:
```
testInstrumentationRunnerArguments["androidx.benchmark.cpuEventCounters.enable"]= 'true'
testInstrumentationRunnerArguments["androidx.benchmark.cpuEventCounters.timingPhaseMask"]= 'Instructions,CpuCycles'
```
Example output:
PerfettoOverheadBenchmark.traceBeginEnd
timeNs min 1,495.7, median 1,511.2, max 1,620.2
Instructions min 3,845.0, median 3,845.0, max 4,007.1
CpuCycles min 1,635.5, median 1,642.2, max 1,817.4
allocationCount min 0.0, median 0.0, max 0.0
PerfettoSdkOverheadBenchmark.traceBeginEnd_perfettoSdkTrace
timeNs min 580.8, median 585.4, max 653.6
Instructions min 3,830.6, median 3,959.1, max 3,969.1
CpuCycles min 1,642.3, median 1,650.5, max 1,668.8
allocationCount min 0.0, median 0.0, max 0.0
LazyListScrollingBenchmark.scrollProgrammatically_newItemComposed[LazyColumn]
timeNs min 273,686.5, median 275,024.7, max 364,566.3
Instructions min 642,749.5, median 642,837.1, max 683,841.6
CpuCycles min 706,229.0, median 709,797.1, max 808,859.2
allocationCount min 490.3, median 490.3, max 490.4
Change-Id: Ic938690476296899f058271ed56dfc3ee95aa2cf
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateConfigTest.kt
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/CpuEventCounterTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricsContainer.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MicrobenchmarkPhase.kt
D benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/CpuCounterBenchmark.kt
A benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/CpuEventCounterBenchmark.kt
ma...@google.com
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.2.0-beta01androidx.benchmark:benchmark-junit4:1.2.0-beta01androidx.benchmark:benchmark-macro:1.2.0-beta01
cc...@google.com
cc...@google.com
Over to Marcello to enable this in CI
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 3383ab2cbccb3015549fb91a945678310e75f625
Author: Marcello Albano <maralb@google.com>
Date: Tue Oct 17 14:51:39 2023
Fixed tests and added measure api to CpuEventCounter
Bug: 286306579
Test: existing
Change-Id: Ia2bf481ae6e7e2f95e5b3727bb6686eafb3ba5a6
M buildSrc-tests/src/test/java/androidx/build/testConfiguration/AndroidTestConfigBuilderTest.kt
M buildSrc/private/src/main/kotlin/androidx/build/testConfiguration/AndroidTestConfigBuilder.kt
https://android-review.googlesource.com/2795174
Branch: androidx-main
commit 3383ab2cbccb3015549fb91a945678310e75f625
Author: Marcello Albano <maralb@google.com>
Date: Tue Oct 17 14:51:39 2023
Fixed tests and added measure api to CpuEventCounter
Bug: 286306579
Test: existing
Change-Id: Ia2bf481ae6e7e2f95e5b3727bb6686eafb3ba5a6
M buildSrc-tests/src/test/java/androidx/build/testConfiguration/AndroidTestConfigBuilderTest.kt
M buildSrc/private/src/main/kotlin/androidx/build/testConfiguration/AndroidTestConfigBuilder.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e52411023650ad95306ddf4db1dd3b757cb39348
Author: Marcello Albano <maralb@google.com>
Date: Tue Oct 24 10:13:35 2023
Fixed name in cpu counter events
To be consistent we want all the cpu counter event names to be camel
case.
Bug: 286306579
Test: existing
Change-Id: Id6642294c3884047166a28b738ee53f9444080a6
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricNameUtils.kt
https://android-review.googlesource.com/2800260
Branch: androidx-main
commit e52411023650ad95306ddf4db1dd3b757cb39348
Author: Marcello Albano <maralb@google.com>
Date: Tue Oct 24 10:13:35 2023
Fixed name in cpu counter events
To be consistent we want all the cpu counter event names to be camel
case.
Bug: 286306579
Test: existing
Change-Id: Id6642294c3884047166a28b738ee53f9444080a6
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricNameUtils.kt
ma...@google.com
CI integration had to be reverted because of
It seems that all the benchmarks are slowing down because of enabling the cpu counters.
cc...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 5de09686debf78730da51df37c78f91e77d3dbc5
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:30:55 2024
Fix pause/resume ordering to preserve metric priority
Test: MetricsContainerTest#validatePriorityOrder
Bug: 286306579
Bug: 307445225
Relnote: "Fix resumeTiming/runWithTimingDisabled to respect metric
priority order, and significantly reduce impact of lower priority
metric pause/resume on higher priority metric results. For example, if
using cpu perf counters via `cpuEventCounter.enable` instrumentation
argument, timeNs is no longer significantly reduced when pause/resume
occur."
Drastically reduces impact of perf event counters on timeNs measurements
-- Baseline, perf counters disabled -- (here and below running on mokey 32 bit, jit disabled)
136,714 ns 11 allocs Trace LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
-- Before Change, perf counters enabled --
LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
timeNs min 172,242.6, median 185,443.2, max 216,688.5
Instructions min 87,728.2, median 88,600.8, max 93,946.2
CpuCycles min 145,951.4, median 151,045.5, max 174,344.5
allocationCount min 11.0, median 11.0, max 11.0
-- After Change, perf counters enabled --
LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
timeNs min 140,890.3, median 149,411.4, max 199,267.2
Instructions min 87,940.5, median 89,342.1, max 95,317.8
CpuCycles min 146,792.6, median 152,793.3, max 180,540.3
allocationCount min 11.0, median 11.0, max 11.0
Change-Id: I39c2eb911129927972740d074ee8f2adca7bda1a
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricsContainerTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricsContainer.kt
https://android-review.googlesource.com/3197014
Branch: androidx-main
commit 5de09686debf78730da51df37c78f91e77d3dbc5
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:30:55 2024
Fix pause/resume ordering to preserve metric priority
Test: MetricsContainerTest#validatePriorityOrder
Bug: 286306579
Bug: 307445225
Relnote: "Fix resumeTiming/runWithTimingDisabled to respect metric
priority order, and significantly reduce impact of lower priority
metric pause/resume on higher priority metric results. For example, if
using cpu perf counters via `cpuEventCounter.enable` instrumentation
argument, timeNs is no longer significantly reduced when pause/resume
occur."
Drastically reduces impact of perf event counters on timeNs measurements
-- Baseline, perf counters disabled -- (here and below running on mokey 32 bit, jit disabled)
136,714 ns 11 allocs Trace LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
-- Before Change, perf counters enabled --
LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
timeNs min 172,242.6, median 185,443.2, max 216,688.5
Instructions min 87,728.2, median 88,600.8, max 93,946.2
CpuCycles min 145,951.4, median 151,045.5, max 174,344.5
allocationCount min 11.0, median 11.0, max 11.0
-- After Change, perf counters enabled --
LazyListScrollingBenchmark.drawAfterScroll_newItemComposed[LazyColumn]
timeNs min 140,890.3, median 149,411.4, max 199,267.2
Instructions min 87,940.5, median 89,342.1, max 95,317.8
CpuCycles min 146,792.6, median 152,793.3, max 180,540.3
allocationCount min 11.0, median 11.0, max 11.0
Change-Id: I39c2eb911129927972740d074ee8f2adca7bda1a
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricsContainerTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricsContainer.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 06edd596b9ced3114159059ba176c7ec173fc51d
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:46:39 2024
Fix corrupted counter outputs by fixing flag caching
Bug: 286306579
Test: MetricCaptureTest#cpuEventCounterCapture_multi
Relnote: "Fix `androidx.benchmark.cpuEventCounter` producing corrupt
values for non-Instruction events"
Previously, running multiple benchmarks in a row with cpu event
counters would oly capture Instructions after the first benchmark,
with garbage values for the rest. This was caused by improper caching
of flags above the native layer. Moved the cache to a lower level to
avoid this problem.
Also moves the DEFAULT_METRICS definition inline to avoid a class init
ordering problem in tests, which further avoids this problem by not
caching a used CounterCapture instance across multiple tests
Change-Id: I7386abe3494b2b11a2447fa85a4109613857c28c
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricCaptureTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
https://android-review.googlesource.com/3197015
Branch: androidx-main
commit 06edd596b9ced3114159059ba176c7ec173fc51d
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:46:39 2024
Fix corrupted counter outputs by fixing flag caching
Bug: 286306579
Test: MetricCaptureTest#cpuEventCounterCapture_multi
Relnote: "Fix `androidx.benchmark.cpuEventCounter` producing corrupt
values for non-Instruction events"
Previously, running multiple benchmarks in a row with cpu event
counters would oly capture Instructions after the first benchmark,
with garbage values for the rest. This was caused by improper caching
of flags above the native layer. Moved the cache to a lower level to
avoid this problem.
Also moves the DEFAULT_METRICS definition inline to avoid a class init
ordering problem in tests, which further avoids this problem by not
caching a used CounterCapture instance across multiple tests
Change-Id: I7386abe3494b2b11a2447fa85a4109613857c28c
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricCaptureTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
cc...@google.com
Remaining work (moved to 1.4 hotlist):
- Renaming counters to be
camelCase - Fixing API 28 permission errors, which failed in ABTD
- Enabling for AndroidX in CI
- Experimental public MetricCapture API (with simplified lifecycle)
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 0df5a6108af99875485daacf7c7c82680fe2eeaa
Author: Chris Craik <ccraik@google.com>
Date: Wed Jul 31 14:11:24 2024
Use camelCase for cpu event counter metrics
Bug: 286306579
Test: cpuEventCounterCapture_outputName
This was already done for instrumentation arg output, this change
makes it consistent across Studio and JSON as well.
Also switches to fixed Locale so test device locale doesn't affect
test output formatting.
Change-Id: I9d74f0327536866b54605b2ed2f61d4c04c468f3
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricCaptureTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricNameUtils.kt
https://android-review.googlesource.com/3204974
Branch: androidx-main
commit 0df5a6108af99875485daacf7c7c82680fe2eeaa
Author: Chris Craik <ccraik@google.com>
Date: Wed Jul 31 14:11:24 2024
Use camelCase for cpu event counter metrics
Bug: 286306579
Test: cpuEventCounterCapture_outputName
This was already done for instrumentation arg output, this change
makes it consistent across Studio and JSON as well.
Also switches to fixed Locale so test device locale doesn't affect
test output formatting.
Change-Id: I9d74f0327536866b54605b2ed2f61d4c04c468f3
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/MetricCaptureTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricCapture.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/MetricNameUtils.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 2550048909d02279f8a0e759e7c21dabab35f93a
Author: Chris Craik <ccraik@google.com>
Date: Thu Aug 01 15:48:29 2024
Change perf event enable logic to run on API 23+
Test: Tested on API 23, 27, 28, all of which needed this change (Unable to get access to a lower API physical device at the moment)
Bug: 286306579
Bug: 357101113
Change-Id: I283018817556b18cbedb77e11a3c95916e3c7ed3
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/CpuEventCounterTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
https://android-review.googlesource.com/3204894
Branch: androidx-main
commit 2550048909d02279f8a0e759e7c21dabab35f93a
Author: Chris Craik <ccraik@google.com>
Date: Thu Aug 01 15:48:29 2024
Change perf event enable logic to run on API 23+
Test: Tested on API 23, 27, 28, all of which needed this change (Unable to get access to a lower API physical device at the moment)
Bug: 286306579
Bug: 357101113
Change-Id: I283018817556b18cbedb77e11a3c95916e3c7ed3
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/CpuEventCounterTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/CpuEventCounter.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 992cb25c28026d5f259edb7459f6d7c6be43ce34
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:59:45 2024
Reapply "Fixed tests and added measure api to CpuEventCounter"
Bug: 286306579
Bug: 307445225
Test: AndroidTestConfigBuilderTest
Reenables microbenchmark cpu counters in CI, now that intrusiveness
has been addressed.
This reverts commit 698248c877020adb675fd30becc55551e8ffc281.
Change-Id: I024f82907805d54eaf98c9233c1766e79a1b5dfd
M buildSrc-tests/src/test/java/androidx/build/testConfiguration/AndroidTestConfigBuilderTest.kt
M buildSrc/private/src/main/kotlin/androidx/build/testConfiguration/AndroidTestConfigBuilder.kt
https://android-review.googlesource.com/3195021
Branch: androidx-main
commit 992cb25c28026d5f259edb7459f6d7c6be43ce34
Author: Chris Craik <ccraik@google.com>
Date: Fri Jul 26 15:59:45 2024
Reapply "Fixed tests and added measure api to CpuEventCounter"
Bug: 286306579
Bug: 307445225
Test: AndroidTestConfigBuilderTest
Reenables microbenchmark cpu counters in CI, now that intrusiveness
has been addressed.
This reverts commit 698248c877020adb675fd30becc55551e8ffc281.
Change-Id: I024f82907805d54eaf98c9233c1766e79a1b5dfd
M buildSrc-tests/src/test/java/androidx/build/testConfiguration/AndroidTestConfigBuilderTest.kt
M buildSrc/private/src/main/kotlin/androidx/build/testConfiguration/AndroidTestConfigBuilder.kt
cc...@google.com
Punting the last bit to 1.5:
- Experimental public MetricCapture API (with simplified lifecycle)
Description
Planning to take code from Filament's Profiler.