Fixed
Status Update
No update yet.
Comments
su...@google.com
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
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
[Deleted User] <[Deleted User]>
su...@google.com
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1288456
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
il...@google.com
Are you enqueuing Work with WorkManager while in Direct Boot mode (i.e., before the device is unlocked)?
su...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit f3e63e3a3432b5fb941aec3d4a21e9a5ea42f1d1
Author: Sumir Kataria <sumir@google.com>
Date: Fri Aug 17 14:34:56 2018
Explicitly label WM components as direct boot unaware.
Because WM defaults to a database in encrypted storage, it
cannot run while in direct boot. By explicitly labelling the
components this way, they cannot inherit a directBootAware
flag from the merged <application> xml.
In the future, we will provide a version of WorkManager that
is direct-boot aware. See the tracking feature request at
https://issuetracker.google.com/112773820 This is something
that might land post-1.0.
Bug: 112665532
Test: Ran some integration tests in a test app.
Change-Id: Ide87b8e4c5dfefb88a54c3ce4c45262335f47e96
M work/workmanager/src/main/AndroidManifest.xml
https://android-review.googlesource.com/734390
https://goto.google.com/android-sha1/f3e63e3a3432b5fb941aec3d4a21e9a5ea42f1d1
Branch: androidx-master-dev
commit f3e63e3a3432b5fb941aec3d4a21e9a5ea42f1d1
Author: Sumir Kataria <sumir@google.com>
Date: Fri Aug 17 14:34:56 2018
Explicitly label WM components as direct boot unaware.
Because WM defaults to a database in encrypted storage, it
cannot run while in direct boot. By explicitly labelling the
components this way, they cannot inherit a directBootAware
flag from the merged <application> xml.
In the future, we will provide a version of WorkManager that
is direct-boot aware. See the tracking feature request at
that might land post-1.0.
Bug: 112665532
Test: Ran some integration tests in a test app.
Change-Id: Ide87b8e4c5dfefb88a54c3ce4c45262335f47e96
M work/workmanager/src/main/AndroidManifest.xml
su...@google.com
[Deleted User] <[Deleted User]>
1st exception:
java.lang.IllegalStateException: SharedPreferences in credential encrypted storage are not available until after user is unlocked
2nd exception:
java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
I'm enqueuing Work with WorkManager on some specific activity or fragment. So I tried to call WorkManager.initialize() on my launch activity after the 1st exception is thrown. The 2nd exception happened only once after clicking on the launch icon.I am not sure how to reproduce the 2nd one.
java.lang.IllegalStateException: SharedPreferences in credential encrypted storage are not available until after user is unlocked
2nd exception:
java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
I'm enqueuing Work with WorkManager on some specific activity or fragment. So I tried to call WorkManager.initialize() on my launch activity after the 1st exception is thrown. The 2nd exception happened only once after clicking on the launch icon.I am not sure how to reproduce the 2nd one.
ra...@google.com
The ContentProvider attempted to initialize WorkManager, when it was in direct boot mode. That failed (because the device was in direct boot mode). Hence WorkManager was not initialized.
So the subsequent calls to use the application after the device is unlocked will fail, as WorkManager has still not been initialized.
So the subsequent calls to use the application after the device is unlocked will fail, as WorkManager has still not been initialized.
ma...@gmail.com
tolonglah
so...@gmail.com
is workmanager now available with boot aware changes.
Please let me know will library version it is.
Please let me know will library version it is.
so...@gmail.com
is workmanager now available with boot aware changes.
Please let me know will library version it is.
Please let me know will library version it is.
Description
My app starts by receiving "android.intent.action.LOCKED_BOOT_COMPLETED", WorkManager initial before user unlocked.
It cause crash:
java.lang.IllegalStateException: SharedPreferences in credential encrypted storage are not available until after user is unlocked
Because WorkManager use context.applicationContext accessing data/data/package/xxxx.
I tried to disable WorkManagerInitializer in AndroidManifest.xml and initial WorkManager on my first activity.But it cause another crash:
08-16 11:02:07.441 E/AndroidRuntime(19740): java.lang.RuntimeException: Unable to create service androidx.work.impl.background.systemjob.SystemJobService: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3415)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.app.ActivityThread.-wrap4(Unknown Source:0)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1738)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.os.Handler.dispatchMessage(Handler.java:106)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.os.Looper.loop(Looper.java:164)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.app.ActivityThread.main(ActivityThread.java:6618)
08-16 11:02:07.441 E/AndroidRuntime(19740): at java.lang.reflect.Method.invoke(Native Method)
08-16 11:02:07.441 E/AndroidRuntime(19740): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
08-16 11:02:07.441 E/AndroidRuntime(19740): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:810)
08-16 11:02:07.441 E/AndroidRuntime(19740): Caused by: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
08-16 11:02:07.441 E/AndroidRuntime(19740): at androidx.work.impl.background.systemjob.SystemJobService.onCreate(SystemJobService.java:67)
08-16 11:02:07.441 E/AndroidRuntime(19740): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3405)
08-16 11:02:07.441 E/AndroidRuntime(19740): ... 8 more