Status Update
Comments
ad...@gmail.com <ad...@gmail.com> #2
Now, instead of crashing, we ignore invalid deep links, printing a log message saying as much.
ra...@google.com <ra...@google.com> #3
The problem still occurs on version 2.2.0-rc04
ra...@google.com <ra...@google.com> #4
ra...@google.com <ra...@google.com> #5
ra...@gmail.com <ra...@gmail.com> #6
ra...@google.com <ra...@google.com> #7
ra...@google.com <ra...@google.com> #8
NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);
if deepLink.length == 1 node never will be null and this will cause IllegalStateException
Bug demo:
get NavigationAdvancedSample from github
on R.id.about_btn click
NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.leaderboard)
.createTaskStackBuilder()
.startActivities()
will crash because R.id.leaderboard is start destination (findInvalidDestinationDisplayNameInDeepLink will have deepLink length == 1)
NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.userProfile)
.createTaskStackBuilder()
.startActivities()
will work because findInvalidDestinationDisplayNameInDeepLink will return NOT null
[Deleted User] <[Deleted User]> #9
It still crash with the latest version 2.2.1. I think the problem lies somewhere around this code
NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);
When i
is 0
, just return mGraph
itself. When the deep link destination is a root of bottom_nav tab, the deeplink.length
becomes 1. Which means this function still says there's no invalid Destination in deep link even if deepLink[0]
is totally irrelevant tomGraph
.
So this step passes and when findDestination() is actually triggered down the road, it won't find any destination and thus lead to unknown destination
crash.
All NavControllers of bottom nav automatically call handleDeepLink()
as part of onGraphCreated()
. The problem arises the moment NavController whose graph is irrelevant to the root deep link destination calls handleDeepLink()
.
ra...@google.com <ra...@google.com> #10
It still crashes with 2.3.0-alpha03 version but only if you try to deeplink to startDestination fragment inside navigation graph. Repro steps (described in #8, but lets repeat it in hope issue will be reopened):
- download NavigationAdvancedSample
- send pending intent to any startDestination screen, e.g.
val pendingIntent = NavDeepLinkBuilder(applicationContext)
.setGraph(R.navigation.list)
.setDestination(R.id.leaderboard)
.setArguments(bundle) // no matter if it is empty in this use case
.createPendingIntent()
pendingIntent.send()
Exception:
Caused by: java.lang.IllegalStateException: unknown destination during deep link: com.example.android.navigationadvancedsample:id/list
at androidx.navigation.NavController.handleDeepLink(NavController.java:689)
at androidx.navigation.NavController.onGraphCreated(NavController.java:602)
at androidx.navigation.NavController.setGraph(NavController.java:563)
at androidx.navigation.NavController.setGraph(NavController.java:528)
at androidx.navigation.fragment.NavHostFragment.onCreate(NavHostFragment.java:246)
at androidx.fragment.app.Fragment.performCreate(Fragment.java:2684)
at androidx.fragment.app.FragmentStateManager.create(FragmentStateManager.java:280)
at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1175)
at androidx.fragment.app.FragmentTransition.addToFirstInLastOut(FragmentTransition.java:1255)
at androidx.fragment.app.FragmentTransition.calculateFragments(FragmentTransition.java:1138)
at androidx.fragment.app.FragmentTransition.startTransitions(FragmentTransition.java:136)
at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1989)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:1947)
at androidx.fragment.app.FragmentManager.execSingleAction(FragmentManager.java:1818)
at androidx.fragment.app.BackStackRecord.commitNow(BackStackRecord.java:297)
at com.example.android.navigationadvancedsample.NavigationExtensionsKt.obtainNavHostFragment(NavigationExtensions.kt:269)
at com.example.android.navigationadvancedsample.NavigationExtensionsKt.setupWithNavController(NavigationExtensions.kt:61)
at com.example.android.navigationadvancedsample.MainActivity.setupBottomNavigationBar(MainActivity.kt:121)
at com.example.android.navigationadvancedsample.MainActivity.onCreate(MainActivity.kt:54)
Reopening would be a good sign that issue is recognized.
ad...@gmail.com <ad...@gmail.com> #11
Just in a case Reopen feature is not implemented in IssueTracker :), new ticket is created:
ra...@gmail.com <ra...@gmail.com> #12
su...@google.com <su...@google.com> #13
ra...@gmail.com <ra...@gmail.com> #14
Filing a new bug with a sample project that reproduces the issue you're still seeing is indeed the correct behavior. We don't support bug necromancy, particularly 30 releases after the original fix was shipped.
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.