Status Update
No update yet.
Comments
to...@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.
sw...@waiport.com
it happens random and we can't reproduce crash and it also happen with particular device with android 9
Could anyone help?
to...@google.com
wo...@google.com
ph...@gmail.com
I looked at Pitot and can't find these errors. In fact errors reported for leanback apps seem to be pretty low.
to...@google.com
It will be helpful if you can find a reliable way to reproduce and paste a sample app with source code.
gv...@gmail.com
It can runs into error like this, which is very hard to debug.
ma...@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.
to...@google.com
ma...@gmail.com
Any clues on this? Can we help in anyway? This is the top crash on our app.
Description
"It seems that PlacePhoto.getUrl() changed and instead of returning a
In addition, this new url seems to have a token. Previously, I could save the googleusercontent URL to my database and continue to retrieve the image. It appears now that the urls returned by "getURL" expire and give the "quota limit" image.
I'm unsure if this is a bug or intentional behavior. If it is intentional. is it possible to get the photo_reference as part of the same request instead of just the 'getUrl'? Seems like that would be a viable alternative.
Noticed someone else has asked the same question in a StackOverflow post:
What steps will reproduce the problem? Please provide a link to a
demonstration page if at all possible, or attach code.
1. Make a Places request via the API.
2. Call the getUrl({'maxWidth': 200, 'maxHeight': 200}) function attached to one of the photos
3. Store the returned URL and try to access it in the future.