Status Update
Comments
cc...@google.com <cc...@google.com>
ja...@gmail.com <ja...@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
ja...@gmail.com <ja...@gmail.com> #3
ma...@google.com <ma...@google.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
ja...@gmail.com <ja...@gmail.com> #5
I would say AS isn't the problem. Even without the AS in the project that I attached the simple commands:
./gradlew assembleBenchmarkBenchmarkRelease
./gradlew assembleNonMinifiedNonMinifiedRelease
./gradlew assembleNonMinifiedBenchmarkRelease
are executed successfully and produce some apks.
ma...@google.com <ma...@google.com> #6
This is how the baseline profile works - it creates specific build types to correctly generate baseline profiles and benchmarks.
You can still disable the variants if you're not interested in one of them. But AS should not be showing them (by default, configurable through a flag).
ja...@gmail.com <ja...@gmail.com> #7
Yes, the Baseline Profile Gradle Plugin creates the appropriate build types or updates them if they already exist (or supposed to, according to the source code).
What I'm refereing to exactly is those result build variants, that don't make sence: benchmarkBenchmarkRelease
, nonMinifiedNonMinifiedRelease
and nonMinifiedBenchmarkRelease
.
AS displays whatever build variants were created by the gradle plugins and fixing this issue either on AS side or disabling all these weird build variants manually in build script seem more like treating a symptom, rather than the root cause.
ch...@google.com <ch...@google.com> #8
AS does hide these variants, but the Android Gradle Plugin needs to be 8.6.0.alpha01
or higher. We use variant's experimental properties as a flag to hide these variants and 8.6.0.alpha01
is the AGP version our model recognizes those flags.
Could you try bumping the AGP version? The attached project uses 8.5.2.
ja...@gmail.com <ja...@gmail.com> #9
I've just tried AGP 8.6.0
and 8.7.0-beta01
with the sample project I attached and both still display the redundant variants in AS Koala Feature Drop | 2024.1.2 and AS Ladybug | 2024.2.1 Beta 1.
Also, the ./gradlew tasks --all
command for both mentioned AGP versions displays all the usual tasks for each of these variants. In turn, simple command like ./gradlew :app:assemble
will assemble even the redundant variants.
The 'variant's experimental properties' were mentioned. Are they applied automatically by BP plugin or should they be specified manually somewhere?
ma...@google.com <ma...@google.com> #10
For this bug we're looking at 2 things: -
- the additional build types that are created to generate baseline profiles and benchmark
- the build types that are visible in AS
There is a bug that should be fixed by aosp/3260794 about build types that should not be created. The AS part was to check that these wouldn't be visible. Will add this to version 1.3.1.
Thanks
ap...@google.com <ap...@google.com> #11
Branch: androidx-main
commit e75f0a518d11e27d4862ef903a9b29e64c0d6625
Author: Marcello Albano <maralb@google.com>
Date: Mon Sep 09 14:00:46 2024
Don't create nonMinified and benchmark build types if existing
Bug: 361370179
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Relnote: "Due to a bug even if nonMinified and
benchmark build types existed, they were going to
be recreated."
Change-Id: Ia8934fdf3ff51d993f4fef8195821d72315026e2
M benchmark/baseline-profile-gradle-plugin/src/main/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPlugin.kt
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPluginTest.kt
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/utils/TestUtils.kt
na...@google.com <na...@google.com> #13
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.3.1
Description
Component used: Baseline Profile Gradle Plugin
Version used: 1.3.0
Devices/Android versions reproduced on: Android Studio Jellyfish/AGP 8.4.2 and Koala/AGP 8.5.2
I want to customize the generatedhttps://developer.android.com/topic/performance/baselineprofiles/configure-baselineprofiles#variant-specific-dependencies
benchmarkRelease
andnonMinifiedRelease
build variants, which are generated by the Baseline Profile Gradle Plugin. So I follow the documentation:If (as per the docs) I add
benchmarkRelease {}
andnonMinifiedRelease {}
blocks in Groovy script, I gain a bloated list of build variants. The list goes really wild havingnonMinifiedBenchmarkRelease
variant and some others. See attached screenshots. Same happens to Kotlin script, if I usecreate("benchmarkRelease") {}
, as equivalent to Groovy's code.Please fix the creating of the redundant build variants.
I have no sample project attached, as the issue is reproducible on a newly generated Android project with a freshly generated Baseline Profile Generator module. Also, the version of the latter should be bumped to 1.3.0, as the default one is 1.2.3 in AS Koala.