Status Update
No update yet.
Comments
bi...@google.com
We are seeing crash #2 as well in our Android TV and Fire TV applications. We are using the androidx.leanback:leanback:1.0.0 version.
pm...@gmail.com
it happens random and we can't reproduce crash and it also happen with particular device with android 9
Could anyone help?
kg...@google.com
ma...@google.com
ma...@google.com
I looked at Pitot and can't find these errors. In fact errors reported for leanback apps seem to be pretty low.
bu...@google.com
It will be helpful if you can find a reliable way to reproduce and paste a sample app with source code.
pm...@gmail.com
It can runs into error like this, which is very hard to debug.
sh...@gmail.com
We have never been able to pin down reproducible steps to get the application to crash, but I can tell you that all of the changes made to the adapter are done on the UI thread. Our app has a Fragment that extends the BrowseSupportFragment class that uses LiveData via a ViewModel to update the UI. The app does the following once it receives that data:
- It first checks to see if the updated data contains the same number of rows that the base adapter contains
- If the number of rows are the same, it then iterates over each row and, using a
DiffCallback, updates each row's adapter - If the number of rows are different, it clears the base adapter and simply adds all of the new data to that base adapter
Most of the time, we notice that this crash occurs after the user has navigated back to this Fragment after navigating away for a long period of time. So for example, a user selects an item on the Fragment and that starts up a new Activity that plays video for an hour or so, then navigates back to Fragment.
Description
Comments from monorail:
unknown user: <b>Example URL: </b> n/a
<b>Steps to reproduce the problem:</b>
In a house/office with any brand of Mesh WiFi, with one WiFi Mesh Node in the Home Office and another Mesh Node in the Kitchen:
1. Connect Chromebook in Home Office to WiFi: Chromebook is connected to the Mesh node in the Office and WiFi is fast.
2. Wander to the kitchen with Chromebook: Chromebook remains connected to the Mesh node in the Office and doesn't flip to the node in the Kitchen. WiFi is choppy/slow for at least 10 minutes.
3. Eventually it connects to the one in Kitch
4. Wander back to Office and it takes 10 minutes again to connect to the node in the Office again.
<b>Problem Description:</b>
When physically moving a Chromebook further and nearer to different Nodes in a Mesh network, Chromebooks are not aggressive enough at connecting to the optimal node. Choppy streaming and slow internet can last at least 10 minutes and often half an hour before it eventually realizes there was a better node it should have been connected to. Possible solutions:
1. Adding a button to "Optimize Connection" somewhere would be very helpful (and would be battery friendly).
2. Adding an option like "Roaming Aggressiveness" (like Windows!) would also be helpful (but this is not as battery friendly).
<b>Additional Comments:</b>
This would make Chromebooks seem so much faster/better because many of people's complaints that "my streaming & conference calls are choppy" is 100% because they are moving around with the Chromebook and are often connected to a sub-optimal Mesh node.
<b>Chrome version: </b>116.0.0.0 <b>Channel: </b>Not sure
<b>OS:</b>Linux
-----------------------------------
hugobenichi@google.com: Migrating to public WiFi buganizer component.
-----------------------------------