Fixed
Status Update
No update yet.
Comments
su...@google.com
ct...@google.com
> We accept pull requests! :)
Is there a public repo somewhere? I don't see any obvious repo for it inhttps://android.googlesource.com , and it doesn't seem to be inside https://android.googlesource.com/platform/frameworks/support .
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
Is there a public repo somewhere? I don't see any obvious repo for it in
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
ma...@gmail.com
Room supports immutability (it can use arg constructors) but does not directly support AutoValue. It is in the schedule but not high priority :/. Idk much about its internals at this stage so I'm not sure how we would implement it but should be totally doable.
Sorry we don't have the source release yet :/.
Sorry we don't have the source release yet :/.
su...@google.com
"It is in the schedule but not high priority" -- completely understandable.
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
ma...@gmail.com
Add autovalue support also means you can easily achieve parcelable by https://github.com/rharter/auto-value-parcel . Please consider support this.
ct...@google.com
AutoValue is really a handy way to ensure data integrity.
su...@google.com
su...@google.com
Please add AutoValue support. AutoValue is a Google library with really good benefits such as toString() , hashCode() , AutoValue.Builder , checks at creation time if @NonNull values are null, etc.
ma...@gmail.com
FWIW,
su...@google.com
@Yigit: That appears to be a private ticket. Any way we can have access to keep up with it?
ma...@gmail.com
Have any updates?
yo...@gmail.com
news?
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.