Status Update
Comments
ad...@gmail.com <ad...@gmail.com> #2
I suspect this change is the culprit.
ra...@google.com <ra...@google.com> #3
Bug reproducible in compose NavHost when compose sets same graph consecutively.
Upon setting same graph the second time, the original _graph
nodes were not properly replaced by the new graph
node instances. When navigating to new destination in addEntryToBackstack
:
findDestination(destination.id)
was not able to find destination node (a new instance) amongst the old nodes (old instances). Therefore it proceeds to re-add new node's hierarchy resulting in duplicated root node.
The fix to
ra...@google.com <ra...@google.com> #4
Branch: androidx-main
commit 5499d88b63726e63900b89d3100be1b3a17b84ce
Author: Clara Fok <clarafok@google.com>
Date: Tue Mar 28 17:00:19 2023
Fix set same graph to replace old destinations
When setting the same graph (exact same routes and destinations but different instances), NavController would keep the original graph but replace the existing graph's nodes with the new graph's nodes. Fix the replace logic to ensure this replacement happens. Also replace backqueue's entry destinations with new instances to ensure the graph and backstack is in sync.
Test: ./gradlew navigation:navigation-compose:cC
Bug: 275258161
Bug: 275407804
Relnote: "When NavController sets the same graph with same route and destinations, it now properly replaces its current graph nodes and its bacstack destinations with new instances."
Change-Id: I5bc582e315578ee53383596070ee3ea4a23aed69
M navigation/navigation-compose/build.gradle
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ra...@google.com <ra...@google.com> #5
Fixed internally and will be available navigation 2.6.0-alpha09
ra...@gmail.com <ra...@gmail.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.6.0-alpha09
androidx.navigation:navigation-runtime:2.6.0-alpha09
ra...@google.com <ra...@google.com> #7
It looks good to me. At least, this specific behaviour seems to be fixed.
ra...@google.com <ra...@google.com> #8
[Deleted User] <[Deleted User]> #9
ra...@google.com <ra...@google.com> #10
ad...@gmail.com <ad...@gmail.com> #11
#3 * Can you reproduce this issue at all on your end ?
We can not. We have done tests with several devices that we have here and it does not happen.
#3 * Can you send us a breakdown of devices and total # of users affected ?
Here you can see the devices and the total number of errors in the last 7 days for each one.
Moto C Plus (panell_s) 6,624 33.9%
Moto C (namath) 4,909 25.1%
Moto C Plus (panell_dl) 1,227 6.3%
Aquaris A4.5 (Aquaris_A45_sprout) 1,197 6.1%
Moto C Plus (panell_dt) 1,030 5.3%
LAIQ_Monaco 838 4.3%
Moto C Plus (panell_d) 686 3.5%
Alcatel 1C (U5A_PLUS_3G) 332 1.7%
4047G (U5_3G) 257 1.3%
BLADE A612 (P635F50) 236 1.2%
Xperia XA (F3111) 230 1.2%
HUAWEI Y5 2018 (HWDRA-MG) 201 1.0%
Aquaris M5 (Aquaris_M5) 179 0.9%
S550 (S550) 153 0.8%
Nokia 2 (E1M) 144 0.7%
F23 (HS6737MT) 134 0.7%
LG K20 Plus (lv517) 120 0.6%
iris80 (iris80) 96 0.5%
KIICAA MIX (KIICAA_MIX) 92 0.5%
Wooze L (Wooze_L) 78 0.4%
Others 788 4.0%
96% of these devices use Android 7.0
The total number of users affected by this error is 325 currently, which is a very very small percentage of active users with the latest update.
#4 * Also from the first screenshot, it looks like you are also seeing IllegalStateException's in SystemJobService#onCreate().
* The only reason that happens is if WorkManager is not been initialized for your process. Do you have multiple processes at all ?
We call "WorkManager.getInstance()...." whenever it is used, and no special initialization is made. It is called in 3 different places:
a) By using Broadcast,
Specifically when restarting the phone with: "android.intent.action.BOOT_COMPLETED"
and on the other hand when making an update with: "android.intent.action.MY_PACKAGE_REPLACED" or "android.intent.action.PACKAGE_REPLACED"
b) When starting the app (main thread).
c) Within a "Worker",
Some workers can start others.
#5 * Are you initializing WorkManager on a background thread or inside a coroutine ?
The first time it is called it could be inside a "BroadcastReceiver" if the user has just updated or restarted the phone. In any other case, it is called when you start the app.
#6 * ...The best hypothesis I could come up is that the OS Scheduler is keeping this bad job running even after the update.
We think that is what is currently happening.
In this update several "works" have been migrated to workmanager, which still continued using other old systems, specifically AlarmManager and FirebaseJobDispatcher in the previous version.
It seems that the errors are stabilizing, they are even receding. I will keep you informed, especially in future updates, when there is no change of works between versions.
ra...@gmail.com <ra...@gmail.com> #12
--------- thread trace ------------
Thread : 9955/WorkManager-WorkManagerTaskExecutor-thread-1
isAlive : true
isInterrupted : false
isDaemon : false
at android.database.CursorWindow.nativeDispose(Native Method)
at android.database.CursorWindow.dispose(CursorWindow.java:175)
at android.database.CursorWindow.onAllReferencesReleased(CursorWindow.java:730)
at android.database.sqlite.SQLiteClosable.releaseReference(SQLiteClosable.java:74)
at android.database.sqlite.SQLiteClosable.close(SQLiteClosable.java:106)
at android.database.AbstractWindowedCursor.closeWindow(AbstractWindowedCursor.java:184)
at android.database.AbstractWindowedCursor.onDeactivateOrClose(AbstractWindowedCursor.java:208)
at android.database.AbstractCursor.close(AbstractCursor.java:170)
at android.database.sqlite.SQLiteCursor.close(SQLiteCursor.java:214)
at androidx.work.impl.b.j.a(WorkSpecDao_Impl.java:1211)
at androidx.work.impl.i.b(WorkerWrapper.java:427)
at androidx.work.impl.i.e(WorkerWrapper.java:393)
at androidx.work.impl.i.d(WorkerWrapper.java:150)
at androidx.work.impl.i.run(WorkerWrapper.java:128)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
-----------------------------------
This thread is the only thread on our report that is using workmanager somehow.
- # of users we rolled out the build with workmanager 1.0.1: 347
- # of users affected by this crash: 157
- Android versions affected by this crash: 7.0, 8.0 and 9.0
- # of users we rolled out the patch where we removed workmanager: 92
- # of users still seeing this crash: 47
- Android versions still affected by this crash: 7.0, 8.0 and 9.0
Another piece of information, these numbers are gather from Crashlitics (Fabric), and we notice a discrepancy between Crashlitics numbers and our internal tools.
su...@google.com <su...@google.com> #13
ra...@gmail.com <ra...@gmail.com> #14
ra...@google.com <ra...@google.com> #15
WorkManager does a lot of things including:
* Check for force-stops of your app and reschedule things automatically - without you having to do nothing.
* Handle existing onStartJob requests for persisted jobs in JobScheduler.
ra...@google.com <ra...@google.com> #16
#4 * Also from the first screenshot, it looks like you are also seeing IllegalStateException's in SystemJobService#onCreate().
* The only reason that happens is if WorkManager is not been initialized for your process. Do you have multiple processes at all ?
We call "WorkManager.getInstance()...." whenever it is used, and no special initialization is made. It is called in 3 different places:
This will not work. Because WorkManager is used in many places without you explicitly doing anything.
You should always ensure WorkManager is initialized in Application#onCreate() unless you happen to using on-demand initialization which is something we introduced in 2.1.0-alpha01.
ap...@google.com <ap...@google.com> #17
Branch: androidx-master-dev
commit d025815ea5cc023c0d33b810f99f5afb7cc40b85
Author: Sumir Kataria <sumir@google.com>
Date: Fri May 31 14:15:54 2019
Cancel invalid jobs attributed to WorkManager.
Sometimes, there are invalid jobs returned in getAllPendingJobs() with no
extras attributed to WorkManager. These should be cleaned up proactively
on startup.
Fixes: 134058261
Test: Added new test
Change-Id: I9bdf821c589bc4ba99542307ea76ca4c0cb9ac2e
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemjob/SystemJobSchedulerTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java
M work/workmanager/src/main/java/androidx/work/impl/utils/ForceStopRunnable.java
jo...@soundcloud.com <jo...@soundcloud.com> #18
The reason I think it is the same bug is that we have a very similar breakdown of affected devices
100% people on Android 7
83% people on Motorola phones
Trace:
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 101 WorkManager jobs in JobScheduler; we have 4 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:189)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:129)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:93)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:100)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
th...@amazon.com <th...@amazon.com> #19
In our case we rolled out an emergency fix to remove WorkManager entirely from our project, including the dependency on it, and the problem was not seen again. We didn't cancel the remaining jobs, but they're gone.
su...@google.com <su...@google.com> #20
Re: #19, this crash should only occur on API 23 and up, so I'm not sure if there's something else going on there for you. Unfortunately, we are chasing down some device differences that don't conform to what stock Android seems to do, and without more data. Without identifying the models, it's hard to see test these.
Motorola devices in particular seem to exhibit this class of problems much more.
ra...@google.com <ra...@google.com> #21
Can you take a look at your crashes to see the total number of users affected ? It will be useful to know what devices they are on as well.
mt...@gmail.com <mt...@gmail.com> #22
Could you please look at:
And some next info in
We use now 2.1.0-alpha03 and this crash (100 jobs) looks fixed for us. But
Thanks a lot
ra...@google.com <ra...@google.com> #23
I am not sure i understand why you are conflating WorkManager and JobIntentService here.
ra...@google.com <ra...@google.com> #24
mt...@gmail.com <mt...@gmail.com> #25
aa...@linkedin.com <aa...@linkedin.com> #26
su...@google.com <su...@google.com> #27
ra...@google.com <ra...@google.com> #28
Which version of WorkManager are you using. This bug has been marked fixed for around ~3 weeks. Are you using the new beta ?
aa...@linkedin.com <aa...@linkedin.com> #29
ra...@google.com <ra...@google.com> #30
If you are uncomfortable then you can always try using it in a beta
rollout of the app.
On Thu, Jun 20, 2019 at 5:45 PM <buganizer-system@google.com> wrote:
Description
Tracking the 100 jobs crash that affects a very small % of users of WorkManager.