Fixed
Status Update
No update yet.
Comments
su...@google.com
Can you please attach a sample project that reproduces this issue? Can you also attach a full bugreport? If the issue is - as you said - that your services are being initialized before the application object on particular devices, that's definitely a problem with their fork of Android and it does not meet compatibility requirements. That being said, I'm not sure how that's even possible given the codebase.
ct...@google.com
I wonder whether Xiaomi has modified the client-side framework to break the ordering of component creation. That would be pretty gross. :(
ma...@gmail.com
Hi,
I can't attach full bugreport as I can't reproduce it manually, but stacktraces are definitely referring for the case when WorkManager.getInstance() returned null in SystemJobService.
I created a sample projecthttps://github.com/andkulikov/WorkManagerNpeSample and tested it on my Xiaomi MI 5(Android ver 7.0) but it is not crashing unfortunately. Only strange behaviour I currently found during the testing:
a) after swiping away the app from recent apps scheduled periodic job will not be executed.
b) after the phone restart it will not be executed as well, but in this case probably the app is considered as force-stopped as well (when I restarted the App manually I saw "Application was force-stopped, rescheduling." in the logs)
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.
I can't attach full bugreport as I can't reproduce it manually, but stacktraces are definitely referring for the case when WorkManager.getInstance() returned null in SystemJobService.
I created a sample project
a) after swiping away the app from recent apps scheduled periodic job will not be executed.
b) after the phone restart it will not be executed as well, but in this case probably the app is considered as force-stopped as well (when I restarted the App manually I saw "Application was force-stopped, rescheduling." in the logs)
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
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.