Progress towards per-volume database separation.
After lots of feedback from a diverse set of stakeholders, the following goals have become clear for MediaProvider: -- When an SD card is ejected, we shouldn't be leaving "stale" metadata around, such as artists, albums, or genres that are no longer relevant. -- We need to avoid heavy full re-indexing of content when an SD card is only temporarily ejected and reinserted within a week. -- We need to support "merged" queries against the virtual VOLUME_EXTERNAL view of all currently mounted volumes. For example, developers should be able to quickly list all available artists without needing to manually merge cursors. With these goals in mind, we spent a lot of time pondering various approaches, and landed upon defining "ID" columns using stable values that enable instant merging between databases. This is implemented by running the 64-bit version of FarmHash against the relevant KEY values, which have already been stripped to aid clustering of equal values. (These keys are how "The Beatles" and "Beatles, The" and "Beatles" are already merged together today.) The approach above now lets us define our artists, albums, and genres in terms of the underlying audio table/view, meaning they're always accurate. Note that the above approach means that developers no longer have dynamic control over genre membership, since it's now always derived from the underlying media files. This follows the design principle we've been using for the last year of saying the source of truth is the underlying media files, to ensure that we can accurately reconstruct the database after corruption or wiping. Developers that want to edit artist, album, or genre information should edit the metadata in the underlying file, which will trigger a rescan. This change also deprecates the various _KEY constants, since they're not reliable for sorting; developers should be using COLLATE LOCALIZED or other methods. (This places us in an awkward position where we're adding newly-deprecated GENRE_KEY columns, but they're needed for completeness.) Fix keyFor() generation to use a consistent Locale.ROOT. Bug: 136964095, 141520122, 140850497, 140127429, 138130722 Test: atest --test-mapping packages/providers/MediaProvider Change-Id: Id4945a04c6996c6ea4a909dda32aa1dd02759d08
Loading
Please register or sign in to comment