Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
This is affecting CameraView as well.
il...@google.com <il...@google.com>
[Deleted User] <[Deleted User]> #3
Bugjuggler: wait until next quarter
il...@google.com <il...@google.com> #4
Hi. I've received your bug and will wait until 2020-01-01 00:00 -0800 PST and then assign the bug to ericng@google.com.
[Deleted User] <[Deleted User]> #5
Hello,
A fix has been applied for most cases in Alpha08 (Dec 18th release), however we are keeping this open for a more robust fix to come. Thanks.
A fix has been applied for most cases in Alpha08 (Dec 18th release), however we are keeping this open for a more robust fix to come. Thanks.
[Deleted User] <[Deleted User]> #7
Bugjuggler:
il...@google.com <il...@google.com> #8
Hi. I've received your bug and will wait for b/146048690 to be fixed and then assign the bug to ericng@google.com.
mi...@gmail.com <mi...@gmail.com> #9
Bugjuggler: wait until next month
il...@google.com <il...@google.com> #10
Hi. I've received your bug and will wait until 2020-02-01 00:00 -0800 PST and then assign the bug to ericng@google.com.
mi...@gmail.com <mi...@gmail.com> #11
dc...@gmail.com <dc...@gmail.com> #12
This will be included in the Alpha10 release. Marking as fixed. Thanks!
da...@gmail.com <da...@gmail.com> #13
I made this work, kind of: splash to main activity; starting destination D. It inflates a layout only to save state and go to the back stack as I bounce to B. If I press back, I go through the steps of restoring D--which briefly makes an appearance on screen--only to finish the activity.
I actually like the thought of an incorrect graph if it lets me handle this stuff precisely without some of the overhead needed to make a generic solution.
I actually like the thought of an incorrect graph if it lets me handle this stuff precisely without some of the overhead needed to make a generic solution.
il...@google.com <il...@google.com> #14
I've confirmed that this is fixed in alpha08 as a result of https://android-review.googlesource.com/833717 and a number of other internal changes.
app:popUpTo="@+id/graph" should always work now.
app:popUpTo="@+id/graph" should always work now.
Description
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:
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