Entries from DownloadProvider are added to MediaStore Downloads
collection. COLUMN_MEDIASTORE_URI will be used to track corresponding
entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI
for this purpose because it is updateable by apps.

Bug: 120876251
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e

am: 36f0d9b9

Change-Id: I74bf7e8a7c8d2e0e9cece2ec15b829b445ac0cfa

am: 57d3db12

Change-Id: I409f34fddeb833802be67cc2c49767ba8157af24

am: 7ec9e684

Change-Id: Ie6800e9dbcf0bb56fafe0fa7791dd524df72162c

This reverts commit 1c3e7431.

Reason for revert: likely cause for broken build 5211430 and later

Change-Id: I2ef3a24c16d09b7c7d1c8c4f8a4e5570237a5bf1

The new isolated storage model we're building in Q introduces new
strongly-typed media permissions which replace the broad "Storage"
runtime permission.

That legacy "Storage" permission is marked as being "removed", and
it also splits into the new media permissions, but apps are confused
when they request the "Storage" permission, which no longer appears
as granted when the user accepts the new split media permissions.

After discussing with the permissions team, the best short-term
solution is to add special-case logic that grants the legacy
permissions when *any* of the new media permissions have also been
granted.  Only when the user revokes *all* of the new media
permissions is the legacy permission then revoked.  (MediaProvider
is already internally filtering the relevant content based on what
new media permissions the caller holds.)

Bug: 121227859
Test: manual
Change-Id: Ic87f7f93a816e91f7189509386255a260378c255

* changes:
  Public APIs for "trashing" media.
  Define secondary media item bucketing.

am: 8339fc24

Change-Id: I27985f27d8175ca374e6a63197cdbf087d201bb8

am: e3db7cfb

Change-Id: I1772eed2663d6e421a17a268f9fb4844d0118c36

am: 3ada5146

Change-Id: I7f5f0fca6c5b92a87d9ba276a48fdc00e919a490

am: 9b9c255b

Change-Id: I26f0e3d18e8a27bd9fb7745f3a7af4ca347237fe

am: 07b293f8

Change-Id: Ia835f7a7488a084c72fd5722c91d01ddb427ea19

am: aa8f1b70

Change-Id: Ib89a1d1b292aca7404d646ff61974558422fc959

This change does a first pass to introduce RcsThread querying. We can
now insert threads and query them back.

Test: Added unit test

Bug: 109759350
Change-Id: Ib116cd533a19ce4d099864a095f585ac47cdc9f6

Bug: 118341983
Test: cts
Change-Id: Ieaf082b7dbc3cb93c2398e935ead77ca1810c62a

The "delete" operation is immediate and permanent, and users may wish
to instead mark content as being "trashed", so they can recover
accidentally trashed items before they're permanently deleted.

The default trash timeout is 48 hours, which should be enough time
to recover items the user cares about.  Apps can also use a custom
timeout if desired.

This is implemented by recording an "expiration" time for trashed
items, and deleting expired items during the next idle maintenance
pass.  Also use this expiration time to clean up pending items that
haven't been published; by default apps have a day to publish
pending items.

Bug: 121227045
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I2e371b308dc135ad5363709a6f5385e4456bcb96

Unlike the original implementation, package can be verified with an
in-kernel trusted keyring.  In this case, we simply need to know if
fs-verity exists for the file.

Test: observed expected behavior with extra debug log
Bug: 112037636
Change-Id: I7a6ff35853f24f5a0a2727ddef376f9857a2d789

Merge "Merge "Deprecate Android beam APIs and create a feature flag to gate them" am: 6a3d45c4 am: d0c8a165 am: a33da54c"