Status Update
Comments
cc...@google.com <cc...@google.com> #2
cc...@google.com <cc...@google.com> #3
cc...@google.com <cc...@google.com> #4
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
ap...@google.com <ap...@google.com> #5
Branch: androidx-main
commit 274ff7860d569477ba45d2d48c73bce4a62241ad
Author: Chris Craik <ccraik@google.com>
Date: Thu Oct 05 13:59:01 2023
Disable method tracing by default on API 34+
Bug:303660864
Bug:303686344
Test: ./gradlew bench:b-c:cC
Test: ModifiersBenchmark # on API 33, 34
Method tracing resets compilation state, which doesn't recover on API 34.
Changing method tracing to be off by default while we investigate this.
Change-Id: I568fc7a8a1029250df183bd65baa6b360cd105d5
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
jo...@google.com <jo...@google.com> #6
Thanks for the quick response, Chris!
cc...@google.com <cc...@google.com> #7
Chuck reported this same issue today, where another new benchmark being added was performing far worse on runs after the first, this time on Sargo API 31.
Inspecting the trace showed that the
Chuck's repro device:
google/sargo/sargo:12/SQ1A.220205.002/8010174:userdebug/dev-keys
package:com.google.android.art versionCode:341010052
My device that didn't repro:
google/bramble/bramble:12/SQ1A.220205.002/8010174:userdebug/dev-keys
package:com.google.android.art versionCode:310924000
The reason I'd not been reproducing this bug generally was because I test on devices not connected to wifi. Chuck had a connected device (for adb over wifi), and had received a mainline update I hadn't been seeing in my previous experiments with the bug, where I tested on both api 33 and api 34. API 34 exhibits the bug without a mainline update, but anything 31+ can exhibit the bug.
For now, I'll turn off method tracing by default on API 31+ to be safe.
In the future, we'll look at something based more specifically on mainline versions, and bundling mainline updates with the fix (once available) into the library or gradle plugin, but we can't make it transparent locally, as mainline updates require a reboot.
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit 6ae6408d8845038d1982cfc26b282939fdcebf18
Author: Chris Craik <ccraik@google.com>
Date: Mon Dec 04 16:30:20 2023
Disable method tracing by default on API 31+
Bug: 303660864
Bug: 303686344
Test: Compose benchmarks with multiple ART mainline versions
As the method tracing bug known to affect API 34 has been backported
to older releases via mainline updates, conservatively avoid method
tracing by default on all potentially affected devices (Android 12+).
Ideally we'd check against the versions known to cause the regression,
this is the simpler immediate fix.
Change-Id: I6b01006fc48e9d3bdec99ed2c22b5d424ae7e492
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
na...@google.com <na...@google.com> #9
@chris is this bug fixed?
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit d592fecfc81fc38de896124a34d75a1b78da3d7f
Author: Chris Craik <ccraik@google.com>
Date: Mon Dec 11 10:31:13 2023
Disable method tracing by default, everywhere
Test: VectorBenchmark # API 30
Test: BenchmarkStateTest
Bug: 313868903
Bug: 303660864
We've observed that method tracing regresses performance in subsequent
benchmarks on at least API 29/30 without mainline updates (as they
aren't supported).
This change simply disables method tracing as the default while we
sort out in which situations it's safe to enable it.
Change-Id: I7b86146c22ac2fbfcd47cb64638c684d85161acb
M benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/BenchmarkStateTest.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/Arguments.kt
cc...@google.com <cc...@google.com> #11
Marking as fixed since the default is now working correctly, filed
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit 625c86746fb820045d8dca4180f4d880b4b0492b
Author: Chris Craik <ccraik@google.com>
Date: Wed Jan 17 17:02:28 2024
Set upper bound for method tracing workaround
Bug:303660864
Test: Verified method tracing still bypassed prior to mainline update
Change-Id: I648793bb789d16edbaec67fa5a0fcd5f51feeeb1
M benchmark/benchmark-common/src/main/java/androidx/benchmark/DeviceInfo.kt
pr...@google.com <pr...@google.com> #13
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.3.0-alpha01
cc...@google.com <cc...@google.com> #14
This isn't fully addressed - we noticed that the error for measurement after method tracing isn't on by default, working on a CL for that.
ap...@google.com <ap...@google.com> #15
Branch: androidx-main
commit 8f4d7d8e380dd1e374328fd5535f6d932e71b879
Author: Chris Craik <ccraik@google.com>
Date: Fri May 10 11:38:14 2024
Throw if measuments taken after method trace discards aot
Fixes: 303660864
Test: Ran SampleCustomBenchmark variant with 2 method traces sequentially, throw observed (mokey 34)
Relnote: "Microbenchmark will now correctly throw to prevent method
tracing from interfering with measurements. This occurs on certain
devices when method tracing is forced on (via instrumentation args or
MicrobenchmarkConfig), and if a measurement is attempted after a
method trace. Affected devices are running API 26-30 or certain ART
mainline module versions affected by this interference, and can be
detected at runtime via
`ProfilerConfig.MethodTracing.affectsMeasurementOnThisDevice`."
Change-Id: Iafb92c47c76bf257c047634b61401d873ce85cc5
M benchmark/benchmark-common/api/current.txt
M benchmark/benchmark-common/api/restricted_current.txt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/BenchmarkState.kt
M benchmark/benchmark-common/src/main/java/androidx/benchmark/ProfilerConfig.kt
M benchmark/benchmark/src/androidTest/java/androidx/benchmark/benchmark/SampleCustomBenchmark.kt
pr...@google.com <pr...@google.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.3.0-beta01
cc...@google.com <cc...@google.com> #17
Romain saw this on an API 35 device, reopened the ART bug, and marking this blocked on that.
ap...@google.com <ap...@google.com> #18
Project: platform/frameworks/support
Branch: androidx-main
Author: Chris Craik <
Link:
Fix method tracing affecting measurements when art built from source on API 34
Expand for full commit details
Fix method tracing affecting measurements when art built from source on API 34
Fixes: 303660864
Test: TrivialKotlinBenchmark (with duplicated benchmark on VP1A.230706.001)
Test: DeviceInfoTest
Change-Id: Ic7cad122150c515779365d6565f1c62c69213f82
Files:
- M
benchmark/benchmark-common/src/androidTest/java/androidx/benchmark/DeviceInfoTest.kt
- M
benchmark/benchmark-common/src/main/java/androidx/benchmark/DeviceInfo.kt
- M
benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Metric.kt
Hash: 4774190a430d12b3be4b2f3c8880334e2cf66a51
Date: Tue Jan 21 17:04:10 2025
na...@google.com <na...@google.com> #19
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-common:1.4.0-alpha07
androidx.benchmark:benchmark-macro:1.4.0-alpha07
Description
Hi, We are facing an issue that if we run the whole ModifiersBenchmark class, we get different results from running each test individually. For instance, running the whole test class for Modifier on a Mokey device (with the clocks locked), the results are as seen in the attached snapshot (ModifiersBenchmark class run). However, running one test individually gives a different result. For example, running the base case alone gives the following result attached in the snapshot (ModifiersBenchmark individual run).
Relevant links: Trace files for base case when running the whole ModifersBenchmark class: Base Case class run
Trace files for base case when running the Base test only: Base Case individual run