Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ma...@gmail.com <ma...@gmail.com> #2
Project: chromiumos/overlays/chromiumos-overlay
Branch: main
commit d9fcf3ac6751e611ab8a1970310ac6e7bf01f463
Author: Alec Bargher <abargher@google.com>
Date: Wed Aug 21 15:51:24 2024
dev-util: Add workaround for armv7a boards compiling LLDB
Currently armv7a is not parsed as a supported architecture by LLDB.
Compiling with the host architecture in the triple set to "arm" instead
of "armv7a" can work around this issue before LLDB itself is patched.
BUG=b:361414339
TEST=USE="local-lldb" cros build-packages --board=${BOARD}
Change-Id: I7c18ab9354b09fd91ac3635a8bcb4ac177f0d3cd
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/5805607
Reviewed-by: Jordan Abrahams-Whitehead <ajordanr@google.com>
Commit-Queue: Alec Bargher <abargher@google.com>
Tested-by: Alec Bargher <abargher@google.com>
Commit-Queue: ChromeOS Auto Runner <chromeos-auto-runner@chromeos-bot.iam.gserviceaccount.com>
M dev-util/lldb-server/lldb-server-9999.ebuild
https://chromium-review.googlesource.com/5805607
Branch: main
commit d9fcf3ac6751e611ab8a1970310ac6e7bf01f463
Author: Alec Bargher <abargher@google.com>
Date: Wed Aug 21 15:51:24 2024
dev-util: Add workaround for armv7a boards compiling LLDB
Currently armv7a is not parsed as a supported architecture by LLDB.
Compiling with the host architecture in the triple set to "arm" instead
of "armv7a" can work around this issue before LLDB itself is patched.
BUG=b:361414339
TEST=USE="local-lldb" cros build-packages --board=${BOARD}
Change-Id: I7c18ab9354b09fd91ac3635a8bcb4ac177f0d3cd
Reviewed-on:
Reviewed-by: Jordan Abrahams-Whitehead <ajordanr@google.com>
Commit-Queue: Alec Bargher <abargher@google.com>
Tested-by: Alec Bargher <abargher@google.com>
Commit-Queue: ChromeOS Auto Runner <chromeos-auto-runner@chromeos-bot.iam.gserviceaccount.com>
M dev-util/lldb-server/lldb-server-9999.ebuild
ch...@moqi.co.uk <ch...@moqi.co.uk> #3
We should see if we can upstream a proper fix for this "armv7a" in particular is not an uncommon form in the target triple. Working on a patch now.
il...@google.com <il...@google.com> #4
ap...@google.com <ap...@google.com> #5
Upstream PR merged! We just need to patch this down now, and we're all done.
Description
android.arch.navigation:navigation-fragment-ktx
android.arch.navigation:navigation-ui-ktx
Version used:
1.0.0-alpha05
Devices/Android versions reproduced on:
-SM-A510F, Android 7.0
-Emulator x86_64 API 28
Sample project:
Description:
Having this structure:
nav_graph.xml
<navigation
android:id="@+id/nav_graph"
app:startDestination="@id/startFragment">
<fragment
android:id="@+id/startFragment"
android:name="com.example.navbug.StartFragment"
android:label="StartFragment"
tools:layout="@layout/fragment_start">
<action
android:id="@+id/action_startFragment_to_nested_nav_graph"
app:destination="@id/nested_nav_graph" />
</fragment>
<include app:graph="@navigation/nested_nav_graph" />
</navigation>
nested_nav_graph.xml
<navigation
android:id="@+id/nested_nav_graph"
app:startDestination="@id/nestedStartFragment">
<fragment
android:id="@+id/nestedStartFragment"
android:name="com.example.navbug.NestedStartFragment"
android:label="NestedStartFragment">
<action
android:id="@+id/action_nestedStartFragment_to_nestedSecondFragment"
app:destination="@id/nestedSecondFragment"
app:popUpTo="@+id/nestedStartFragment"
app:popUpToInclusive="true" />
</fragment>
<fragment
android:id="@+id/nestedSecondFragment"
android:name="com.example.navbug.NestedSecondFragment"
android:label="NestedSecondFragment" />
</navigation>
I want to achieve this navigation pattern:
StartFragment => NestedStartFragment => NestedSecondFragment =(back)=> StartFragment
I'm trying to implement this by setting the action NestedStartFragment=>NestedSecondFragment with the options [popUpTo=NestedStartFragment, popUpToInclusive=true], so that the resulting stack would be:
0. NestedSecondFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When navigating from NestedStartFragment to NestedSecondFragment, the following execption occurs:
java.lang.IllegalArgumentException: Navigator androidx.navigation.fragment.FragmentNavigator@ccc9092 reported navigation to unknown destination id com.example.navbug:id/nestedSecondFragment
at androidx.navigation.NavController$2.onNavigatorNavigated(NavController.java:142)
at androidx.navigation.Navigator.dispatchOnNavigatorNavigated(Navigator.java:217)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:207)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:45)
at androidx.navigation.NavDestination.navigate(NavDestination.java:407)
at androidx.navigation.NavController.navigate(NavController.java:683)
at androidx.navigation.NavController.navigate(NavController.java:630)
at androidx.navigation.NavController.navigate(NavController.java:618)
at com.example.navbug.NestedStartFragment$onViewCreated$1.onClick(Fragments.kt:31)
at android.view.View.performClick(View.java:6597)
at android.view.View.performClickInternal(View.java:6574)
at android.view.View.access$3100(View.java:778)
at android.view.View$PerformClick.run(View.java:25885)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Right before the navigation, the stack is:
0. NestedStartFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When NestedStartFragment is popped on my request, NestedNavGraph is also popped because
"// We never want to leave NavGraphs on the top of the stack" (from NavController.onNavigatorNavigated)
with the effect that eventually the requested destination NestedSecondFragment is pruned from the graph and cannot be reached anymore.
Unless I'm doing something wrong, it seems that NavGraph automatic popping should be avoided if the final destination actually belongs to it.