Postby rstone » 01 Jan 2021 20:35
I am glad you are enjoying the Android Auto interface. I contributed the updates earlier this year to the UI, so I am familiar with the issue you are experiencing.
First, just to verify--you are using the latest version, 3.3.2, correct? I want to make sure my comments are reflective of the current state of the UI, rather than an older release. Can you tell me what version of Android you are running, phone model, etc. ?
Second, the issue you are observing is a result of the design of the Android Auto API, which only allows us to send back a large data structure containing all the songs for the track list. It isn't elegantly designed for pagination, unfortunately. The way the list is passed data is serialized internally into a Parcel, which is limited in size to approximately 1 MB. With the tracks in my playlist, I empirically determined this to be approximately 930-ish songs, but I padded it down to exactly 800 to leave some room. We iterate over the track list until we hit 800--wherever that might be alphabetically, and then stop. This is the reason you see the track list "Search by letter" frequently truncates the end of the alphabet. Sadly, there's nothing we can do about the API design unless we create the pagination ourselves, such as A->(whatever letter lands at track 800), followed by 801->1600, 1601->2400, you get the idea. We'd have to insert another menu level below Tracks to enable that functionality, which I suppose is doable. Is that something you would find valuable?
Third, there is a subtle data sizing issue with determining the number of bytes used by each track in the data structure. In order to load the artwork, we pass the file path internally to the ContentProvider responsible for returning the image to Android Auto. This will be impacted by the depth of the directory structure, folder name length, etc. I am currently working on a new ArtworkProvider which will make the size much more predictable by only passing the internal media id number and not the entire path. We'll be able to more predictably hit the 800 track number that way without worrying about the on-disk organization of the media library. This also resolves the bug with incorrect cover art appearing after the Android Auto cache fills up. I assume you are still seeing that issue, but perhaps you have learned to ignore it?
If you are able to view the logs, I think you'll see a TransactionTooLargeException, followed by a message that says "!!! FAILED BINDER TRANSACTION !!!". Can you post the message, including the allowed parcel size? It's going to happen almost immediately after navigation.
Thanks!