| Age | Commit message (Collapse) | Author |
|---|
|
It's not just *media* files that you can access using the DATA column.
Change-Id: I33d9681ed0592ab084575f8201e4c6552c3b6922
Test: none
Bug: 158051457
|
|
On Android 11, apps can use the DATA column when reading existing
media files using direct file path access. Explain that this is possible, but
discourage using the value to create and update media files.
Bug: 158051457
Change-Id: I78d101c3539202aa52a6fb919d8a4dcb976be777
Test: none
|
|
We're trying to figure out where volumes are disappearing.
Bug: 158059178
Test: none
Change-Id: Ifcca2f005a523d94d8dcf08fc81af4de2fd1ab53
|
|
The retail demo environment creates a special StorageVolume that
contains media to be shown while in the demo mode, so allow that
volume to be attached and scanned by MediaProvider.
Bug: 157632755
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ic3c959a5b2feb316a62c8301a92a409f80bdc6c4
|
|
Apps may be relying on the original Audio.keyFor() behavior that
returned empty strings instead of null, so restore that original
behavior.
Bug: 149776788
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Id5858ab08dc2e1b9199b96ddd7441e36ef4c126b
|
|
Previously this doc error was suppressed. This CL is part of a topic
that removes all broken @see tags and removes the suppression.
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ib1bd6148428a16165f5a1cfb7ebda237084f7243
Merged-In: Ib1bd6148428a16165f5a1cfb7ebda237084f7243
(cherry picked from commit a30696c3334c11d23d1746eacde33513fd1cffd7)
|
|
The public API clearly states that our various IS_FOO columns are
of type Cursor.FIELD_TYPE_INTEGER, but developers often rely on how
SQLite automatically converts booleans and literal strings into
integer "1" and "0" values on disk.
This change adjusts all Java logic to parse all variants of these
boolean values to match what SQLite does internally.
Bug: 154054403
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I1f3ec650c957a6c5207c5803fb667ea006666cd0
|
|
Recent changes to trashing/untrashing items require it to be applied
through the "movement" code path of updateInternal(). This works
fine when apps are updating values they own directly, but it breaks
when called indirectly via PermissionActivity, since we skip the
movement behavior entirely for all MediaProvider internals.
This change introduces a QUERY_ARG_ALLOW_MOVEMENT that can be used
to force-enable the movement feature, fixing the broken tests.
Bug: 154354407, 151979369
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.ExternalStorageHostTest#testMediaEscalation
Change-Id: I472cd2b66df93a0d2a6d22edcee365ad0529ceeb
|
|
To give users a consistent experience, we now force the DATE_EXPIRES
value to a specific duration based on the IS_PENDING or IS_TRASHED
transition that is occurring.
Bug: 150366826, 151436090, 151227951, 142809046
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ia34369f5b1a1e6f5be8eb37ed1bc19ad66f202e2
|
|
|
|
We've seen evidence of the remote caller attempting multiple
migrations, so adjust the logic to ensure that we always have a
valid database while an active migration is taking place.
Also protect the Mainline code from a legacy provided that is
having trouble with lifecycle events.
Bug: 151960212
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I3920bb652352ca3a08d2004fb5e3e135cbc0ce82
|
|
Playlists have been poorly defined for many years, as a combination
of parsed playlist files on disk, combined with "virtual" playlists
which only exist in MediaProvider. Even worse, once a playlist file
was initially parsed into the database, any future edits in the
database were never reflected in the playlist file, and any future
edits of the playlist file would overwrite the database edits.
For the last few releases, we've been generally converging towards
a strategy where MediaProvider is simply an optimized index of what
exists on disk, and that real files on disk are the authoritative
source of truth.
This change brings that strategy to playlists, where all playlists
are now "real" files on disk, and any mutations are directly
written into these files. Whenever we detect changes to these
playlist files, we simply reconcile the database playlist members
with whatever we found on disk.
To accomplish this, we split generic playlist modifications away
from the actual persistence logic that understands the various
playlist file formats, and we flesh out both reading and writing
logic for each playlist format. We also add support for the XSPF
playlist format.
Adds thorough unit tests to verify the behavior of both the generic
playlist mutation logic and the persistence logic, and integration
tests to verify the behavior for typical apps.
Remove "AUDIO_MEDIA_ID_PLAYLISTS" support, since it was a hidden
API that was never officially supported.
Bug: 134683342, 151800650, 148995524, 151209792
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I230aab32bd44ef9d52f3bae6861e7b1f1fa47fee
|
|
When storing thumbnails on a storage device, we use BaseColumns._ID
as the filename. However, when a user manually clears data on the
MediaProvider package, or when the SQLite database becomes corrupted,
it will scan files with drastically different _ID values, which means
we can no longer use cached thumbnails.
We already store a UUID in the SQLite database to help both internal
and external developers detect these conditions, so this change
extends that strategy to write the UUID into a new ".database_uuid"
file in the ".thumbnails" directory on disk. Then, when we mount a
storage volume in the future, if the UUID value disagree, we
treat all thumbnails on that device as stale as delete them.
Bring back IdleServiceTest, and extend it to validate that stale
thumbnails are wiped when the UUID changes.
Bug: 148429200
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ia89f925e151a2f7c9d27ba8ce025c43875f603ed
|
|
-- Promote generally-useful PFD API to public.
-- Add @WorkerThread annotations.
-- Add docs to explain how AUTHORITY_LEGACY works, and add explicit
START/FINISH_LEGACY_MIGRATION_CALL verbs to communicate progress.
-- Expand docs for createWriteRequest() to explain broader access
that it grants. Expand all request methods to indicate the action
is fully completed before the result is delivered.
-- Expand docs for new generation fields to explain that version
also needs to be inspected.
-- Explicitly call out why getKindSize() is deprecated, and guide
towards better alternative.
Bug: 148867182, 148403418, 148011561, 147760276
Test: none
Change-Id: Ibfae5a0b490d4b4b3f1725b72e246833f79c50e2
|
|
Playlists, like images or audio, can (and often do) have a corresponding
file on the file system. For that reason, they need to be treated like
media files by MediaStore. This means that their db view should inherit
all of the columns from MediaColumns.
In addition, this allows us to query for OWNER_PACKAGE_NAME of a
playlist or open a playlist file through ContentResolver, which we
previously couldn't do (unless we go to the files table).
Test: * Uri item = getContentResolver().insert(
MediaStore.Audio.Playlists.EXTERNAL_CONTENT_URI, values);
* getContentResolver().openFileDescriptor(item, "rw");
Bug: 150593090
Change-Id: I42a87358978053f8aacf92c363188762e9e4fadb
|
|
Partners have requested that we index XMP metadata so that gallery
apps can quickly determine XMP values (such as photosphere camera
parameters) without having to perform their own expensive indexing
of the underlying files on disk.
This change also redacts any location metadata contained in the
indexed metadata, since we can't safely perform dynamic redaction of
database values.
Bug: 148571206
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ied576422f6d43233790c241027bc9478d0f3df6f
|
|
The new annotation is android.compat.annotation.UnsupportedAppUsage.
Test: m
Bug: 145132366
Exempt-From-Owner-Approval: previously approved change
Change-Id: I454920a64718dfdd88a050efc870e0e2e0c76781
|
|
|
|
Apps can define a service to pre-warm them for performing either
ACTION_REVIEW or ACTION_REVIEW_SECURE.
Test: N/A
Bug: 144530792
Change-Id: I546b58fe7650e9b8f51cca21898e74cd718069b6
|
|
Bug: 138173113
Test: m -j
Change-Id: Ia318e2ee4161aed1d670c70359a2b2e5f5632166
|
|
The reason we created the "generation" concept was as a replacement
for DATE_ADDED and DATE_MODIFIED, and we realized there is a use-case
for having both values, so this change splits our previous work into
GENERATION_ADDED and GENERATION_MODIFIED to match the other names.
Bug: 147666253, 140248585, 142698119
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I98792f8c22a779972716019ce359a0ae54a892d6
|
|
Add generation numbers to the metadata for each media item. This is
useful for apps that are attempting to quickly identify exactly
which media items have changed since a previous point in
time. Generation numbers are monotonically increasing over time, and
can be safely arithmetically compared.
Detecting media changes using generation numbers is more robust than
using DATE_MODIFIED, since those values may change in unexpected
ways when apps use File.setLastModified() or when the system clock
is set incorrectly.
This is implemented by ensuring that all mutations to go through
our local SQLiteQueryBuilder, which then forces those mutations to
always happen inside an active transaction. Then each time we
create a transaction, we increment the generation counter, and
force-copy the current generation into any mutation operations.
This design also means that all mutations that should affect the
generation counter must go through DatabaseHelper to ensure that
the logic above is applied; there's mechanical refactoring across
MediaProvider to accomplish this.
Fix bug in getWritableDatabase() that could return a readable
database. Fix bug in LegacyMediaProvider to create missing
directories. Adjust logging script to enable log cleaner SQL from
SQLQueryBuilder instead of noisy raw logs.
Bug: 140248585
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I15f05c79ed5ff445e20679dedafb1b800755458b
|
|
Partners have requested that we start indexing this well-defined
Exif tag.
Bug: 139146203
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ib822d9f96c2da6a540233f7021297551cd255d48
|
|
The bulk of the work needed to get MediaProvider building against
the "system_current" SDK surface has been slowly merged over the
last few months, and this change makes the last few adjustments.
This adds a new StorageVolumeCallback which is simpler version of
StorageEventListener that simply delivers the changed StorageVolume.
Move DownloadManager logic into a onMediaStoreDownloadsDeleted()
method which hides the implementation details of how the OS connects
with that implementation.
Make local copies of some ExifInterface parsing logic; they could
be added to the androidx version in an unbundled release. Make a
local copy of RedactingFileDescriptor, since it's only needed for
the next few weeks until FUSE is globally enabled.
Bug: 137890034
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I03bfdf7fd5b962d2660dbfb4b0254de8218c234f
|
|
The "core_platform" SDK technically includes non-stable APIs, so we
need to shift to "core_current" instead.
While we're here, tidy up some older @removed APIs that never shipped
and replace HexEncoding with a local implementation.
Since MediaProvider itself is free to use @hide APIs from its own
framework code in MediaStore.java, we can include all sources
from "framework-mediaprovider-sources" directly.
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Iab806e7f685fc80411a78289bcc906c612e1fa6c
|
|
Recent work has paved the way to get MediaStore.java building against
"core_platform", and this change is actually shifting MediaStore.java
inside the MediaProvider APEX boundary.
This involves defining a new "updatable-mediaprovider" library JAR
and ensuring that it's spliced into classpaths where needed to keep
everything building and working.
Note that the MediaProvider APK itself is still bundled, so we're
manually including the MediaStore.java when building that APK so that
we can continue referencing @hide symbols, but there's a STOPSHIP
comment to remove that once we get the APK building against
"system_current".
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I74d16cd14889650e1dc21855766e4d2f579b5030
|
