Status Update
Comments
yc...@gmail.com <yc...@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
ze...@google.com <ze...@google.com>
ra...@google.com <ra...@google.com>
ma...@google.com <ma...@google.com> #3
yc...@gmail.com <yc...@gmail.com> #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
yc...@gmail.com <yc...@gmail.com> #5
Sorry I think I made a mistake in step 4 and 7 (was confusing with
The original <flavor>Release
build (assembleProdRelease
) does pickup both profiles if they're placed under src/<variant>/generated/baselineProfiles
.
The <flavor>BenchmarkRelease
task generated by the baseline profile plugin however can't seem to be able to pickup files in src/<variant>/generated/baselineProfiles
, but src/<variant>/baselineProfiles
works.
So to reproduce it you can run ./gradlew assembleDevBenchmarkRelease
with the profiles in src/<variant>/generated/baselineProfiles
VS src/<variant>/baselineProfiles
, and compare app/build/intermediates
folder:
intermediates/merged_startup_profile/
is produced if the startup profile lives insrc/<variant>/baselineProfiles
- no
merged_startup_profile
folder is produced if the startup profile lives insrc/<variant>/generated/baselineProfiles
What this effectively means is without changing baselineProfileOutputDir
to point to src/<variant>/baselineProfiles
, the app being benchmarked won't include the profiles provided by the app which is how I found this issue (see
ma...@google.com <ma...@google.com> #6
Thank you for spending the time to reexplain this.
I went through it and found the bug.
I'm going to create a patch for the plugin.
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit 72443347a8fa1ad4c1a54af7d1a93e5296418ab8
Author: Marcello Albano <maralb@google.com>
Date: Wed Apr 10 14:54:23 2024
Add baseline profile srcset to benchmark variants
Due to a bug the baseline profile srcset for a release variant is not
being added to the ones for a benchmark variant. This PR fixes that.
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Bug: 333024280
Relnote: "Fix to ensure benchmarks use generated baseline profiles when
`automaticGenerationDuringBuild` is off"
Change-Id: Ic144f394c09ec666d4892a4168a2197dc5031039
M benchmark/baseline-profile-gradle-plugin/src/main/kotlin/androidx/baselineprofile/gradle/consumer/BaselineProfileConsumerPlugin.kt
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/consumer/BaselineProfileConsumerPluginTest.kt
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/utils/Constants.kt
ma...@google.com <ma...@google.com> #8
The patch should be in baseline profile gradle plugin 1.2.4 and 1.3.0-alpha03
na...@google.com <na...@google.com> #9
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.2.4
androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.3.0-alpha03
yc...@gmail.com <yc...@gmail.com> #10
I can still reproduce this in 1.3.0-alpha03. I've pushed a
- run
./gradlew assembleDevBenchmarkRelease
- the
android/app/build/intermediates/merged_startup_profile/devBenchmarkRelease/mergeDevBenchmarkReleaseStartupProfile/
folder is still empty - the
android/app/build/intermediates/merged_art_profile/devBenchmarkRelease/mergeDevBenchmarkReleaseArtProfile/baseline-prof.txt
only has profiles from libraries - the build completes even when the
baseline-prof.txt
andstartup-prof.txt
insrc/main/generated/baselineProfiles
have unparsable contentfoo
andbar
.
ma...@google.com <ma...@google.com> #11
Was looking at the project and I think the issue is here:
beforeVariants {
it.enable = it.name in listOf(
"devDebug",
"demoDebug",
"mockDebug",
"prodRelease",
"devNonMinifiedRelease",
"devBenchmarkRelease",
"prodBenchmarkRelease",
)
}
In this beforeVariants
block, the variant devRelease
is disabled, so the onVariants
callback for that variant won't run. The set up work for devBenchmarkRelease
is done in that callback.
Unfortunately this code is a bit tricky because it's not possible to access a variant from another variant, using the variant api. So the baseline profile plugin processes the base variant and then schedules some work for when the benchmark variant is processed, in order to add the baseline profile src sets.
The (non-optimal) "fix" here would be to re-enable devRelease
.
yc...@gmail.com <yc...@gmail.com> #12
Thanks, enabling devRelease
does work. For now I've worked around this by enabling benchmark related variants only when running benchmarks by checking gradle.startParameter
.
Description
Using the baseline profile gradle plugin, the
startup-prof.txt
is copied intosrc/sourceSet/generated/baselineProfiles
by default.The file is not being picked up by AGP when compiling the release build
STEPS TO REPRODUCE:
android/app/src/main/generated/baselineProfiles/startup-prof.txt
foo
./gradlew assembleProdRelease
startup-prof.txt
toandroid/app/src/main/baselineProfiles
./gradlew assembleProdRelease
ERROR: /path/android/app/build/intermediates/merged_startup_profile/prodRelease/mergeProdReleaseStartupProfile/startup-prof.txt: R8: Unable to parse rule at line 1 from ART profile: foo
Studio Build: Android Studio Koala 2024.1.1 Canary 3
Version of Gradle Plugin: 8.5.0-alpha03
Version of Gradle: 8.7
Version of androidx.baselineprofile: 1.3.0-alpha02
Version of Java: 21
OS: macOS