Fixed
Status Update
Comments
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #2
Could you a sample project?
cc...@google.com <cc...@google.com> #3
This is repo with very basic project
https://github.com/ThinkDeeper/leanback_crash_test
which contains our extension of GuidedStepSupportFragment and two more dummy fragments as its extension.
Steps to reproduce is pretty simple:
from fragment1 navigate to fragment2 (sometimes back to fragment1) using buttons on right pane and then hit hardware back which results in crash mentioned above.
which contains our extension of GuidedStepSupportFragment and two more dummy fragments as its extension.
Steps to reproduce is pretty simple:
from fragment1 navigate to fragment2 (sometimes back to fragment1) using buttons on right pane and then hit hardware back which results in crash mentioned above.
ra...@google.com <ra...@google.com> #4
I ran the project in android studio with 28 and 29 TV emulator, cannot reproduce it.
cc...@google.com <cc...@google.com> #5
Yes, that is our experience as well.
We were not able to reproduce on emulator.
Only NVIDIA SHILED (android 9) & Xiaomi MiBOX (android 9).
ap...@google.com <ap...@google.com> #6
Okay, I can reproduce it on a physical device.
It's a bit hard to reproduce.
It's a bit hard to reproduce.
ap...@google.com <ap...@google.com> #7
+ilake
an...@google.com <an...@google.com> #8
I captured in debugger and found that in the crash stack when returning from fragment 2 to fragment 1.
FragmentStatementManager is calling fragment1.getFocusedView().requestFocus() when returning to fragment 1.
The "focusedView" is retained in Fragment.AnimationInfo but it belongs to the previous view tree that is supposed to be destroyed when navigate from fragment 1 to fragment 2.
focusedView.isAttachedToWindow is false as shown in the screenshot.
FragmentStatementManager is calling fragment1.getFocusedView().requestFocus() when returning to fragment 1.
The "focusedView" is retained in Fragment.AnimationInfo but it belongs to the previous view tree that is supposed to be destroyed when navigate from fragment 1 to fragment 2.
focusedView.isAttachedToWindow is false as shown in the screenshot.
ap...@google.com <ap...@google.com> #9
While leanback can add check in onFocusChangeListener whether the view belongs to the fragment's current view tree.
Is it a race condition in fragment library that calling requestFocus on a detached child?
Is it a race condition in fragment library that calling requestFocus on a detached child?
ra...@google.com <ra...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 031d8dc8c746ca0840630cb6d641e91405362b6f
Author: Dake Gu <dake@google.com>
Date: Mon Nov 09 11:52:57 2020
leanback: fix wrong RecyclerView in GuidedActionAdapter
GuidedActionStylist has the same lifecycle as fragment that it can
be bound to different RecyclerViews in onCreateView/onDestroyView.
GuidedActionAdapter has the same lifecycle as the current fragment's
view. It adds onFocusChange listener to child views of RecyclerView.
Using GuidedActionStylist.getRecyclerView() may get the wrong one.
The fix is adding a final field mRecylerView in GuidedActionAdapter,
The adapter is created in fragment onCreateView and released in
fragment onDestroyView.
Bug: 172000115
Test: The bug is hard to reproduce, verified with existing Test and
verified demo app is still working.
Change-Id: Ic829f9256c1bd825a04bdeb81e673aa2a75527db
M leanback/leanback/src/main/java/androidx/leanback/widget/GuidedActionAdapter.java
https://android-review.googlesource.com/1493237
Branch: androidx-master-dev
commit 031d8dc8c746ca0840630cb6d641e91405362b6f
Author: Dake Gu <dake@google.com>
Date: Mon Nov 09 11:52:57 2020
leanback: fix wrong RecyclerView in GuidedActionAdapter
GuidedActionStylist has the same lifecycle as fragment that it can
be bound to different RecyclerViews in onCreateView/onDestroyView.
GuidedActionAdapter has the same lifecycle as the current fragment's
view. It adds onFocusChange listener to child views of RecyclerView.
Using GuidedActionStylist.getRecyclerView() may get the wrong one.
The fix is adding a final field mRecylerView in GuidedActionAdapter,
The adapter is created in fragment onCreateView and released in
fragment onDestroyView.
Bug: 172000115
Test: The bug is hard to reproduce, verified with existing Test and
verified demo app is still working.
Change-Id: Ic829f9256c1bd825a04bdeb81e673aa2a75527db
M leanback/leanback/src/main/java/androidx/leanback/widget/GuidedActionAdapter.java
cc...@google.com <cc...@google.com> #11
projected to be in leanback:1.1.0-alpha06 at release of early December
ap...@google.com <ap...@google.com> #12
Kudos and Thank you for quick fix.
cc...@google.com <cc...@google.com> #13
With the above fix, macrobench method tracing is in a good enough/experimental state to ship with 1.2, so punting further work to 1.3
Remaining issues / gaps between method tracing in micro vs macro:
- Method trace should be done in separate measurement phase, more like microbench
- Method tracing can only start for an iteration if process is launched cold, so only one occurs frequently, e.g. when measuring warm start (CL in
adds warning about this)#comment12 - Method trace not embedded into perfetto trace
ap...@google.com <ap...@google.com> #14
Project: platform/frameworks/support
Branch: androidx-main
commit 7a0dc4138dd47a207c94dead3653e4db2c36b1d9
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Nov 06 15:12:10 2023
Use a consistent naming scheme for generated method traces in Macrobenchmarks.
Test: Updated existing tests.
Bug: 285912360
Change-Id: I5367d4fad0ec62a761ed9272340638d0020cfd75
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/MacrobenchmarkScopeTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
https://android-review.googlesource.com/2816632
Branch: androidx-main
commit 7a0dc4138dd47a207c94dead3653e4db2c36b1d9
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Nov 06 15:12:10 2023
Use a consistent naming scheme for generated method traces in Macrobenchmarks.
Test: Updated existing tests.
Bug: 285912360
Change-Id: I5367d4fad0ec62a761ed9272340638d0020cfd75
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/MacrobenchmarkScopeTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
cc...@google.com <cc...@google.com>
bu...@google.com <bu...@google.com> #16
Hi. I've received your bug and will wait until 2024-04-19 10:55 -0700 PDT and then assign the bug to rahulrav@google.com.
bu...@google.com <bu...@google.com>
ra...@google.com <ra...@google.com>
cc...@google.com <cc...@google.com> #17
Last thing here should be to not capture metrics (or at least label metrics separately) for method tracing iterations.
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #18
Project: platform/frameworks/support
Branch: androidx-main
commit 2d1785e9837b97c6d64878413efb96d873895cd0
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Wed Apr 24 16:57:02 2024
Move method tracing to a separate phase.
* Method tracing now runs as a separate phase, without interfering with metrics.
Fixes: 285912360
Fixes: 336588271
Test: Existing unit tests.
Change-Id: If9a504a7bce7228840339b34294ba3fdf98aceeb
Relnote: Method tracing runs as a seperate phase during a Macrobenchmark, and it no longer affects measurements.
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Macrobenchmark.kt
A benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkPhase.kt
https://android-review.googlesource.com/3059411
Branch: androidx-main
commit 2d1785e9837b97c6d64878413efb96d873895cd0
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Wed Apr 24 16:57:02 2024
Move method tracing to a separate phase.
* Method tracing now runs as a separate phase, without interfering with metrics.
Fixes: 285912360
Fixes: 336588271
Test: Existing unit tests.
Change-Id: If9a504a7bce7228840339b34294ba3fdf98aceeb
Relnote: Method tracing runs as a seperate phase during a Macrobenchmark, and it no longer affects measurements.
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Macrobenchmark.kt
A benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkPhase.kt
pr...@google.com <pr...@google.com> #19
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-macro:1.3.0-alpha05
Description
Filing a bug to track (late) comments on macrobench tracing CL:https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2594692
Can punt this out of 1.2, but put there for minimal fix of config options