tree 57d8c4d2b341268e852d648370087106985d51a2
parent 8018eeace2a71c598e8da678845f960314acceea
author Jeff Sharkey <jsharkey@android.com> 1570572605 -0600
committer Jeff Sharkey <jsharkey@android.com> 1570572846 -0600

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