Android Auto: Add artwork content provider and access logging

Description

This MR addresses a longstanding issue with Android Auto media player apps showing incorrect cover artwork. The issue typically emerges after a few days of usage when the AA cache fills up. A short term resolution is to clear the cache; however, the issue always returns. I began searching for a root cause based on this Reddit post. Someone observed Spotify worked correctly (which isn't surprising, as Spotify screenshots are used in Google's documentation). After extensive online searching, and a lucky debug setting, I determined the Glide library within AA is missing a cache key (signature). The Glide documentation suggests that callers devise a key which incorporates track metadata; however, that code is not in Android Auto, so we're stuck with inconsistent bitmap behavior which eventually starts returning random imagery (Glide logs contain a full dump of the configuration on each call, including URI, signature class, CacheKey, resolution, transformations, etc.)

This change also includes the code from !962 (closed) modified for logging purposes only. It was simpler to roll it together into one MR with multiple commits. I attempted to address the threading concerns in this iteration as well (JSON file load did occur on the main thread).

Motivation and Context

Google's official guidance in Build media apps for cars: display media artwork is to use a ContentProvider instead of passing bitmaps; however, many legacy APIs and older Android versions require bitmaps. From what I understand, they appear to be phasing out passing bitmaps entirely, presumably to provide support for higher resolution imagery in the future. I wish the documentation had a few more sentences and clearly stated: "Google is phasing out, and will eventually remove support for APIs which directly pass bitmaps in favor of URIs. This shift enables callers to lazily load and cache higher resolution imagery. The URI string is treated as a unique key, so consider construction of URI paths and parameters for your application to trigger imagery updates using either time-based or event-based expiration schemes." Wouldn't that be nice? For now I am going to use it as an assumption for development purposes.

VLC will use both time (shuffle all) and event based (history, last added, and playlist updates) schemes. I wrote additional details regarding how to enable Glide debugging, handle non-square images, URI construction, and checksum objectives in the source code comments.

There are very few examples of how to generate imagery in a ContentProvider. I attempted develop a comprehensive solution on top of the Medialibrary layer. Please test it out 😄

Screenshots

The well-known adventurer below was stuck in my cache for a number of weeks. She was on a mission to save me from the wrong cover art!

Note: The background image and foreground image are mismatched. This is not a mock-up! 🙈

How Has This Been Tested?

Tested on a Pixel 3 with Android Auto over a period of months. Also tested on an Android 10 emulator (pre media controls), as the notification behavior for cover art appears to have changed.

• Bug fix (Incorrect cover art)
• New feature (Caller logging)
• Enhancement (Faster last added query)

Checklist

• I have read the CONTRIBUTING section of the README document.