The recommended substitute for clearTask of popUpTo with popUpToInclusive only works from start destination actions [116831650]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Sep 28, 2018 10:32AM

I was previously using clearTask in my navigation actions to make sure that the user could not navigate back to the previous destination (useful for splash screens and login screens). After it was deprecated I decided to try the recommended approach of instead setting popUpTo pointing to the root of the graph together with setting popUpToInclusive="true", but this didn't have the effect I wanted.

This approach only seem to work on actions originating from the graph's start destination, and fails on actions between any other destinations. I created a sample project which reproduces the issue:

https://github.com/hsson/android-navigation-component-alpha06-bug

Here is the project's README detailing the issue:

# Bug in Android Navigation Component (alpha06)
(Note: I have only verified this in alpha06, I don't know if it exists in
previous versions)

## The problem
Basically the problem is that the NavOption "clearTask" was removed in
alpha02, and the recommended substitute was to use app:popUpTo pointing to
the root of the graph/the graph ID, together with app:popUpToInclusive="true".
However, this method does not work. It only seems to work for actions
going from the graph's start destination. If we have the following graph:

x y
A ---> B ---> C

Where A, B, and C are fragments, A is the start destination of the grapg,
and x, y are actions going from A to B and B to C respectively. Let's say
the graph's ID is "@+id/graph"

Then, if both actions x and y have
app:popUpTo="@+id/graph"
app:popUpToInclusive="true"

Then when navigating from A to B through x, and then hitting the back button
will exit the app (as expected). But if navigating from A to B to C through
x and y, and then hitting the back button we will navigate back to B — this
is not what was expected. The expected behavior with this graph is to always
exit the app when clicking the back button

## Environment
This was verified using:
Android Studio 3.2 RC 3
Build #AI-181.5540.7.32.4987877, built on August 31, 2018
JRE: 1.8.0_152-release-1136-b06 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6

Comments

[Deleted User] <[Deleted User]> #2Oct 1, 2018 08:14AM

After creating the issue I've noticed that I mixed up a few terms, sorry about that. JobService should be JobScheduler. When referring to jobs in the description, those are classes extending Worker.

il...@google.com <il...@google.com> Oct 1, 2018 10:56PM

Assigned to il...@google.com.

[Deleted User] <[Deleted User]> #3Oct 10, 2018 09:20AM

We have a large set of users seeing this same issue... I can confirm that it seems to only effect users using Android OS 4.4 - 5.1. We are also using WorkManager 2.0.0

il...@google.com <il...@google.com> #4Oct 18, 2018 06:05PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019

Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.

* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.

Fixes:

b/129226383

Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557

M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java

https://android-review.googlesource.com/933140

https://goto.google.com/android-sha1/098c163581a360c32baa6e4c215227f0efd10889

[Deleted User] <[Deleted User]> #5Oct 19, 2018 11:44AM

Great to see such a quick fix. Do you have any estimate when a new version that includes this change will be released?

mi...@gmail.com <mi...@gmail.com> #6Oct 19, 2018 12:22PM

It should be available in the next 2.x.x version.

[Deleted User] <[Deleted User]> #7Oct 19, 2018 12:24PM

ETA?

il...@google.com <il...@google.com> #8Oct 19, 2018 03:36PM

Hi, we have implemented a new big feature using WorkManager and got the same issue. We have been considering third party alternatives because we need to deliver this ASAP. But if you confirm that we will have that version within next few days we can wait for it.

mi...@gmail.com <mi...@gmail.com> #9Oct 19, 2018 03:50PM

Thanks for reporting this, OP, and thanks for the quick fix, Android team... my users were seeing this too...

il...@google.com <il...@google.com> #10Oct 19, 2018 04:13PM

We are using workmanager 2.1.0-alpha01 which include code change of

https://android-review.googlesource.com/933140, but a lot crashes caused by same problems still showing in firebase console.

Affected Android Version
62% Android 5
37% Android 4
1% Android 6

Fatal Exception: java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver@42203f30
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:769)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)

Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@421dec00 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@4222d1a8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2011)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:793)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:298)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:503)
at java.util.concurrent.Executors$DelegatedScheduledExecutorService.schedule(Executors.java:644)
at androidx.work.impl.background.systemalarm.WorkTimer.startTimer(WorkTimer.java:82)
at androidx.work.impl.background.systemalarm.DelayMetCommandHandler.onAllConstraintsMet(DelayMetCommandHandler.java:100)
at androidx.work.impl.constraints.WorkConstraintsTracker.onConstraintMet(WorkConstraintsTracker.java:150)
at androidx.work.impl.constraints.controllers.ConstraintController.updateCallback(ConstraintController.java:134)
at androidx.work.impl.constraints.controllers.ConstraintController.onConstraintChanged(ConstraintController.java:141)
at androidx.work.impl.constraints.trackers.ConstraintTracker.setState(ConstraintTracker.java:103)
at androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver.onReceive(NetworkStateTracker.java:170)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:759)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)

mi...@gmail.com <mi...@gmail.com> #11Oct 19, 2018 04:16PM

Are you sure that these crash reports are coming from the latest version of your app which has the new version of WorkManager ?

dc...@gmail.com <dc...@gmail.com> #12Oct 23, 2018 05:19PM

According to release notes this crash have been fixed in 2.0.1, but we recently update work manager from 1.0.0 to 2.0.1 and now it is our top crash.

da...@gmail.com <da...@gmail.com> #13Oct 26, 2018 10:58PM

This would still happen in some rare conditions. So we have another fix for it in 2.1.0-alpha03.

il...@google.com <il...@google.com> #14Nov 30, 2018 11:21PM

Marked as fixed.

I'm also getting same crash in Google Play console only for android-sdk 4.4 to 5.2
used work manager version = '2.3.0'
implementation "androidx.work:work-runtime:2.3.0"

This is Top most crash in my App Account.