Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
It would be great if you can provide video and bugreport synced with the same timestamp.
il...@google.com
[Deleted User] <[Deleted User]>
What
More information
If I'm not mistaken, I need to reproduce the bug while the bug report is being generated, is that correct?
When
Time and frequency
Time when bug report was triggered: Apr 6, 2025 4:42 PM GMT+03:00
Where
Build and device data
- Build Number: google/panther_beta/panther:16/BP22.250221.015/13278879:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
Debugging information
Google Play services
com.google.android.gms
Version 251134035 (25.11.34 (260400-740024306))
System App (Updated)
Android System WebView
com.google.android.webview
Version 699813533 (134.0.6998.135)
System App (Updated)
Network operator: Vodafone UA
SIM operator: Vodafone UA
Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit
il...@google.com
Information redacted by Android Beta Feedback.
[Deleted User] <[Deleted User]>
What
More information
by the way, my friend, who also has a pixel 7, also noticed this bug, but since he is not participating in the beta testing program, he can't write about it here
Where
Build and device data
- Build Number: google/panther_beta/panther:16/BP22.250221.015/13278879:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
Debugging information
Google Play services
com.google.android.gms
Version 251134035 (25.11.34 (260400-740024306))
System App (Updated)
Android System WebView
com.google.android.webview
Version 699813533 (134.0.6998.135)
System App (Updated)
Network operator: Vodafone UA
SIM operator: Vodafone UA
Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit
mi...@gmail.com
Information redacted by Android Beta Feedback.
[Deleted User] <[Deleted User]>
We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.
il...@google.com
1) There really is a bug here - app:popUpTo="@+id/graph" should work as well - that's why I said 'workaround' above, not solution. We will be fixing that bug.
2) Popping everything off the stack is always a sign that you've built your graph incorrectly. That's on us though as we haven't documented well enough how to do conditional navigation (for example, the B->C sign in flow).
For example, in the example raised in #5, your start destination should be D.
- Splash screen should be using a splash theme (e.g.,
- B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().
- Having D as your startDestination is critical to having the right back stack when deep linking to somewhere in your graph
I realize that this is a bigger mental shift from how you've structured your apps and is a big reason why improving the documentation is an important focus for Navigation over the next few months.
mi...@gmail.com
I find this complicated and can lead to issues that resemble "callback hell", having multiple checks and flags everywhere, to know if we already navigates to some destination and if we are back and without a proper value... Can't we come up with a more streamlined solution?
il...@google.com
One thing that you need to keep in mind is that the user can hit the home button at any point then come back to *exactly that same destination in your app* an arbitrary amount of time later. If your logins expire or if users can delete their accounts (just to offer two examples), then *every* login required destination needs to handle this exact case - punting users to your login flow then handling whether they log in or not before showing their protected content. By making that the *only* flow for handling invalid login cases in your app, you can do things the right way just once.
mi...@gmail.com
dc...@gmail.com
>>> - B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().
Basically D needs to know the outcome of a task that was accomplished in B, meaning D needs to know if it was reached through opening the app (since it's a startDestination) or through pressing back in B (meaning the user canceled the login process).
Wouldn't this be a break in abstraction? My understanding was that a destination should receive it's arguments and this should be enough for it to work but in this example D needs to detect it was reached through a BACK press in B.
I don't even know how I would implement such a thing unless I start passing arguments between destinations to know about my navigation history.
da...@gmail.com
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
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