Fixed
Status Update
No update yet.
Comments
su...@google.com
since these are in public API (:/) we need to do this in 1.2
ct...@google.com
since it is already marked as deprecated, we can probably do it by now.
ma...@gmail.com
Opening diff shortly
su...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/61 .
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/1396827
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request from
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
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.