Status Update
No update yet.
Comments
em...@getkeepsafe.com
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
se...@google.com
se...@google.com
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
em...@getkeepsafe.com
Thank you for taking a look at this.
Please let me know if I can help in the investigation.
se...@google.com
once aosp/2227317 lands you can try it out snapshot build. From what I see, performance is much better, but not ideal. But I'm afraid ideal requires much intrusive changes, that we don't want to do right before beta.
se...@google.com
em...@getkeepsafe.com
I understand.
Is there a way to tell if the snapshot includes the changes from aosp/2227317 in
se...@google.com
mmm, yeah, seems like there is no information about it there. I'll let you know which build includes it.
em...@getkeepsafe.com
Thank you for all the help.
I'll test it out as soon at it's available and update here.
ap...@google.com
Branch: androidx-main
commit 0bed2f8a6c5c94e5bfcfe7a4e7c13ba1b7ca4166
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Thu Sep 22 16:27:56 2022
Make GreedyScheduler do less "startWork" calls
bug: 248111307
Test: new integration test
Change-Id: I9686ba0810e4444b41ae7d638a6b8db3943da8cb
M work/work-runtime/src/main/java/androidx/work/impl/StartStopToken.kt
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/work-runtime/src/main/java/androidx/work/impl/background/greedy/GreedyScheduler.java
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/StressTest.kt
M work/integration-tests/testapp/src/main/res/values/donottranslate-strings.xml
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
se...@google.com
Build 9098985 and newer has the change.
em...@getkeepsafe.com
I've verified the changes in I9686ba0810e4444b41ae7d638a6b8db3943da8cb improved the performance of the workers being executed. I tested using the
I updated the
Will the changes in I9686ba0810e4444b41ae7d638a6b8db3943da8cb be included in the next alpha build?
I was hoping to update the WorkManager since it's required for compatibility with targeting Android SDK 31.
Thank you for the support.
se...@google.com
Yeah, it will be included in the next release, which is 2.8.0-beta01.
na...@google.com
This bug was linked in a change in the following release(s):
androidx.work:work-runtime:2.8.0-beta01
em...@getkeepsafe.com
Thank you!
eo...@gmail.com
FYI, I get an error in Room DB with this version:
androidx.work:work-runtime:2.8.0-beta01
See error below
# code block
[ERROR] [system.err] /home/eoinzy/workspace/android/myapp/data/build/generated/source/kapt/debug/com/myapp/data/MyAppDatabase_Impl.java:188: error: onCreate(SupportSQLiteDatabase) in <anonymous com.myapp.data.MyAppDatabase_Impl$1> cannot override onCreate(SupportSQLiteDatabase) in Delegate
[ERROR] [system.err] protected void onCreate(SupportSQLiteDatabase _db) {
[ERROR] [system.err] ^
[ERROR] [system.err] attempting to assign weaker access privileges; was public
[ERROR] [system.err] /home/eoinzy/workspace/android/myapp/data/build/generated/source/kapt/debug/com/myapp/data/MyAppDatabase_Impl.java:218: error: onValidateSchema(SupportSQLiteDatabase) in <anonymous com.myapp.data.MyAppDatabase_Impl$1> cannot override onValidateSchema(SupportSQLiteDatabase) in Delegate
[ERROR] [system.err] protected RoomOpenHelper.ValidationResult onValidateSchema(SupportSQLiteDatabase _db) {
[ERROR] [system.err] ^
[ERROR] [system.err] attempting to assign weaker access privileges; was public
[ERROR] [system.err] 2 errors
The issue isn't present in androidx.work:work-runtime:2.8.0-alpha04
da...@google.com
Re room-compiler and room-runtime do you have declared in your project? Can you try using the latest 2.5.0-beta01? I think what is happening is that work-runtime is using a newer version of room-runtime than the one declared in your project but room-compiler is not being updated to match that version as it should be.
eo...@gmail.com
Yes, that's exactly the issue. Using 2.5.0-beta01 seems to fix it. Apologies for the false alarm.
Description
Component used: WorkManager Version 2.8.0-alpha04
Devices/Android versions reproduced on:
Please see demo project:https://github.com/emarc-m/work-manager-oom
Steps to Reproduce:
QUEUE WORKERSbutton to enqueue1_000one-time unique workersTestWMto inspect the progress of the workers runningComparing when the workers gets executed with WorkManager 2.8.0-alpha04 vs version 2.3.4, version 2.3.4 would execute the workers immediately compared to 2.8.0-alpha04. It sometimes look like the WorkManager using 2.8.0-alpha04 is not executing any of the queued workers.
I also noticed that there's more logging like this in 2.8.0-alpha04:
For comparison, the sample project can also be built using WorkManager 2.3.4.
Expected behavior: The work manager should execute workers similar to 2.3.4.
Note: This is related to