Fixed
Status Update
No update yet.
Comments
wu...@google.com
ma...@gmail.com
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.
ma...@gmail.com
ch...@google.com
I ran the project in android studio with 28 and 29 TV emulator, cannot reproduce it.
ch...@google.com
Yes, that is our experience as well.
We were not able to reproduce on emulator.
Only NVIDIA SHILED (android 9) & Xiaomi MiBOX (android 9).
ma...@gmail.com
Okay, I can reproduce it on a physical device.
It's a bit hard to reproduce.
It's a bit hard to reproduce.
ma...@gmail.com
+ilake
ma...@gmail.com
ch...@google.com
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
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?
ch...@google.com
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
pr...@google.com
projected to be in leanback:1.1.0-alpha06 at release of early December
Description
CAMERAX VERSION: 1.4.0-alpha02 - 1.4.0-alpha05
CAMERA APPLICATION NAME AND VERSION: custom app
ANDROID OS BUILD NUMBER: Android 14, UP1A.231005.007.X200XXU3DXB3
DEVICE NAME: Samsung Galaxy Tab A8
DESCRIPTION:
When calling
imageCapture.takePicturewith anImageCapture.onImageSavedCallback, the onCaptureStarted method is called, but none of the other methods are ever called.Opening the camera and issuing the first imageCapture has logs like this:
Further interactions add the following:
LIST ANY EXPERIMENTAL FEATURES: NONE
STEPS TO REPRODUCE:
OBSERVED RESULTS: takePicture is called, but never returns anything, not even an error.
EXPECTED RESULTS: some kind of return
REPRODUCIBILITY: (5 of 5, 1 of 100, etc) 100% on this device. Exact same code works on other devices (Pixel 7, Samsung Galaxy S24 Ultra, Pixel 3a)
ADDITIONAL INFORMATION:
CODE FRAGMENTS (this will help us troubleshoot your issues):