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
ct...@google.com
ma...@gmail.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
su...@google.com
Thanks, we'll take a further look at this crash.
Regarding point 1 (swiping away), some devices incorrectly treat this as a force-stop, in which case your job will not run until the app is restarted. It looks like this may be one of those devices. If you try this on a Pixel or AOSP device, you won't observe this behavior.
Regarding point 2, we do actually listen for boot events but if your app was previously force-stopped (say by swiping the app away), then it may not receive those events. Under "normal" circumstances, reboots will be handled just fine.
Regarding point 1 (swiping away), some devices incorrectly treat this as a force-stop, in which case your job will not run until the app is restarted. It looks like this may be one of those devices. If you try this on a Pixel or AOSP device, you won't observe this behavior.
Regarding point 2, we do actually listen for boot events but if your app was previously force-stopped (say by swiping the app away), then it may not receive those events. Under "normal" circumstances, reboots will be handled just fine.
ma...@gmail.com
Note for the point 2: I definitely did't force stop the app before reboot. I opened app and tap on restart. And boot receiver wasn't called as well. So have no ideas why it was counted as force-stop
ct...@google.com
As #5 pointed out, some OEMs have changed the framework to force-stop without an explicit user action. This breaks a lot of things. :(
su...@google.com
su...@google.com
This could be happening due to auto-backup. Do you know if that is enabled for your app?
We've put in a potential fix that should be available in alpha05.
We've put in a potential fix that should be available in alpha05.
ma...@gmail.com
We didn't specify this flag in manifest which means its enabled.
But how can it be crashing for so many users right after update? And why on Xiaomi mostly?
What do you think about the difference with Android-Job library? maybe it would be a good decision to initialize with current context in SystemJobService instead of crashing if no init yet called? What I previously wrote about it:
"Because of this issue we currently migrated our app to Evernote's Android-Job and I can say it is not crashing like this. I don't know did they do it accidentally or not but according to the sources they are not relaying on mandatory execution of InitContentProvider in their PlatformJobService or PlatformGcmService, they are calling JobManager.create(context) - analog or init(), not JobManager.instance(). Please check usages of JobManager.create(Context context) therehttps://github.com/evernote/android-job . So it will work in their implementation even if the ordering of execution of broadcasts, services is broken."
But how can it be crashing for so many users right after update? And why on Xiaomi mostly?
What do you think about the difference with Android-Job library? maybe it would be a good decision to initialize with current context in SystemJobService instead of crashing if no init yet called? What I previously wrote about it:
"Because of this issue we currently migrated our app to Evernote's Android-Job and I can say it is not crashing like this. I don't know did they do it accidentally or not but according to the sources they are not relaying on mandatory execution of InitContentProvider in their PlatformJobService or PlatformGcmService, they are calling JobManager.create(context) - analog or init(), not JobManager.instance(). Please check usages of JobManager.create(Context context) there
su...@google.com
It's still possible the Xiaomi device has a bug or non-standard behavior, as per earlier in the thread.
We cannot change to Evernote's implementation - they can freely try to create their singleton at any point because their configuration object is modifiable at runtime. Ours is not, and we think that's the correct decision. For example, we would not want to be able to change the Executor at runtime - that leads to a bunch of problems that aren't easy to reason about for us and the developer.
We cannot change to Evernote's implementation - they can freely try to create their singleton at any point because their configuration object is modifiable at runtime. Ours is not, and we think that's the correct decision. For example, we would not want to be able to change the Executor at runtime - that leads to a bunch of problems that aren't easy to reason about for us and the developer.
ma...@gmail.com
I really hope it will not be crashing after your changes, but if it still would I think you anyway will have to investigate and find a way how to handle it.
I mean once you will publish stable version and Android-Job developers would deprecate their library then way more developers could face it. And unfortunately Xiaomi is very popular device manufacturer.
I mean once you will publish stable version and Android-Job developers would deprecate their library then way more developers could face it. And unfortunately Xiaomi is very popular device manufacturer.
yo...@gmail.com
Good morning please I won't this to update imedetill thanks
Description
Version used: android.arch.work:work-runtime:1.0.0-alpha03
Devices/Android versions reproduced on: any
Stacktrace:
Caused by: java.lang.NullPointerException:
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:52)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3267)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1641)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:163)
at android.app.ActivityThread.main (ActivityThread.java:6379)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:904)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:794)
Description:
Hi,
Yes, I know its a duplicate of
We released first version of our app with WorkManager with alpha02 library and without any explicit calls to WorkManager.initialize(...) and received a lot of NPEs in our tracker for all the places with WorkManager.getInstance() calls in our code and internally in the library. We don't have multiple processes so I was sure you default initialization with empty ContentProvider should work. But looks like its not always working! (maybe it is not always working on devices based on modified Android forks?) I can't reproduce it manually, but I have a lot of submitted crashes.
Well, we added WorkManager.initialize(this, new Configuration.Builder().build()); inside our Application.onCreate() before calling super.onCreate(); and it indeed helped. We had no such exceptions on the next release.
But for the next release after it we updated library version to alpha03 and it started crashing a lot again. Even as we still have WorkManager.initialize(...) inside Application.onCreate(). Guys, issues like this are making adapting your library into real applications quite complicated, please consider reworking of the library initialization to make it more predictable.
I see that mostly it is crashing on Xiaomi devices, attaching screenshot with devices list.