To help confirm that we're actually testing developer-visible
behaviors, we need to build against public APIs, since there have
been plenty of examples in this suite of "testing" hidden API
behaviors, which are then misleading to developers.
Bug: 120429729
Test: atest cts/tests/tests/provider/
Exempt-From-Owner-Approval: Trivial API annotations
Change-Id: I07fe33e54f611a6060217f0706fb99b809961f4d
It's an index of data scanned from disk, and it's been misleading to
let people mutate that data directly in MediaStore, since those
edits aren't durable in any way. We never updated the metadata in
the underlying files, so any changes would be lost when moving
between devices.
This change moves to always re-scan files after they've been edited,
to ensure we pick up metadata changes. It also ignores direct edit
attempts from apps.
Bug: 120711487
Test: atest android.media.cts.MediaScannerTest
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I4cc3ae24d6c6b5f01fe4bb47610ccf162c81ce83
The new ACCESS_MEDIA_LOCATION permission is designed to protect
the location metadata of items the caller doesn't own, but we can't
easily perform partial filtering of metadata from returned Cursor
objects based on per-row ownership, so we're forced to outright stop
indexing and returning location metadata via queries.
Apps can still easily obtain location metadata using ExifInterface.
Bug: 111892141
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I4d99e6aa7d94bb0e7a50ce86eb1ab0f1ed142d4a
SD card after you set SD as internel phone storage
This JE is happening due to null pointer access in makeEntryFor() in
MediaScanner.Java.
Before accessing the cursor, check if cursor is available and not null.
It is a safe check.
Bug: 119392250
Test: manual, ran test 20 times and it passed every times.
Change-Id: I23039281b63a0a6a411860eb5989cf20a5663c8f
Add keys for color aspects to VideoColumns in MediaStore.
And standard, transfer and range is stored to database.
Bug: 114329709
Test: put hdr/non-hdr contents and check media db
Change-Id: Id4bf27a35720f5cf5a60f08eb3f30314e1a1a167
Some HEIF content happens RuntimeException in ExifInterface because
sniff is failed and MediaExtractor is not found. If exception happens,
scanning is aborted. So all contents may not be registered to database
correctly. To avoid that, this fix changes caught exception from
IOException to Exception for creating ExifInterface.
Bug: 117625929
Test: put some HEIF contents and check on photos
Change-Id: I6d32dec27c3be13993ec08f92d567b772d03ace9
Add OEM_SOUNDS_DIR variable
And add judgment of OEM_SOUNDS_DIR in isSystemSoundWithMetadata.
Test: build and check sound like ringtone etc
Bug: 79123178
Change-Id: Ib432910c7a99695e73c88480b7028be1c9d04702
Recently in I830717428e72ac37c5ecd1f23d915aa878ef3744, we greatly
improved the underlying file-extension-to-MIME-type mappings defined
in libcore and used across the OS.
Instead of maintaining divergent mappings here in MediaFile, this
change delegates all file extension logic down to libcore, and
standardizes all MediaScanner internals on using MIME types. To
register new file types in the future:
1. Add the MIME-to-extension registration in libcore.
2. Add the MIME-to-MTP mapping here in MediaFile.
This change also ensures that unknown MIME types are surfaced
across MTP, using constants like FORMAT_UNDEFINED_AUDIO for audio/*
until an explicit format is defined.
We now surface WMA/WMV file formats, even if the device can't
natively play them back, since we still want to offer the ability
for users to copy them around, and the user may have a third-party
app capable of playing them.
Keeps @UnsupportedAppUsage intact for now.
Bug: 111268862, 112162449
Test: atest frameworks/base/media/tests/MediaFrameworkTest/src/com/android/mediaframeworktest/unit/MediaFileTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I2f6a5411bc215f776f00e0f9a4b7d825b10b377d
For packages:
android.media.tv
android.media.soundtrigger
android.media.session
android.media.projection
android.media.midi
android.media.effect.effects
android.media.effect
android.media.browse
android.media.audiopolicy
android.media.audiofx
android.media
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I9b58cb2d1e02d9156a7b0d19c1feff4bcd2c53a9
Merged-In: I3bd40136d7fc948f66eca6b2d139c15e39c5a248
For packages:
android.media.tv
android.media.soundtrigger
android.media.session
android.media.projection
android.media.midi
android.media.effect.effects
android.media.effect
android.media.browse
android.media.audiopolicy
android.media.audiofx
android.media
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I3bd40136d7fc948f66eca6b2d139c15e39c5a248
As part of implementing strongly-typed storage in the Q release, we've
needed to limit the items visible in strongly-typed views. (For
example, the Images view must only include images.)
This change fixes a place inside the OS that was implicitly relying on
update() leaking between these strong data types. If we're changing
the media type of an already-scanned file, we need to do that through
the Files table first, and then we can update the details at the
strongly-typed Uri.
Bug: 112467162
Test: atest android.media.cts.MediaScannerTest
Change-Id: I61c8b62e04f6542882745a20e9aed96275427b5f
bug: 76125031
Test: push some HEIC files with rotation to sdcard, and query
the content provider to see the orientation field is set.
Change-Id: I8235cbcd2aad2f0088d771ee53d2ca87cd85800d
Bug: 64195575
Test: tested reading media files from /product/media/audio after moving
files from /system/media/audio to /product/media/audio
Change-Id: Ic690965e2b5f0e237d21df1db0fd0354a76d7c90
CloseGuard instances are allocated in constructors and usually
assigned to final fields. This implies they're non-null in finalizers
except in the case where the constructor throws. We add a null check
to make sure we can continue cleaning up other state in the finalizer
(if applicable).
Also, this change decouples closeguard warnings in constructors
from other state based logic. This because the logic there is usually
duplicated with the call to close().
NOTE: This change is not a "complete" fix. Many of these finalizers
are broken in the case where <init> throws. The only objective of
this change is to make such errors more obvious.
Note that some of these classes don't have CTS tests.
Test: make, CtsMediaTestCases.
Bug: 35609098
Change-Id: I24d9e0215f80e44914dba8ab99b6312fd6ed1fc0
Always scan notification, ringtones and alarm files under /system
when the build fingerprint has changed since the last scan,
because the dates on those files is not set correctly
(by design), and hence cannot be trusted in the date-based
scanning logic.
Remove some dead code
Bug 30476971
Change-Id: I638c787dc177f7f5fb17c1c2a576be190c1c85f9
RingtoneManager is the public API that everyone should be going
through, and it now has the side-effect of caching the set ringtone
to make it available before CE storage is unlocked.
Bug: 27435331
Change-Id: I30ed4e2df2ef1e4fd47f947c70845aaa74356384
When the media scanner is invoked to scan a file which it cannot access
(e.g. one in the app-private directories) the related database entry
will be created anyway, which doesn't make sense. This results in having
broken entries showed up in e.g. Album app.
This fix is to prevent scanning files which are inaccessible.
Change-Id: I5b4909bf709c82d66e891f3e7f6890febc90c6eb
If the device was powered off during first boot, after media scanner
inserted some entries but before the default ringtone settings were
set (or committed to disk), the default settings would not be set
on subsequent boots.
Bug: 18625739
Bug: 22349910
Bug: 25633323
Change-Id: I8ff5d3c4f842297d0675e1f5cbe17c0709a14158
If the device was powered off during first boot, after media scanner
inserted some entries but before the default ringtone settings were
set (or committed to disk), the default settings would not be set
on subsequent boots.
Bug: 18625739
Bug: 22349910
Bug: 25633323
Change-Id: I8ff5d3c4f842297d0675e1f5cbe17c0709a14158
Moving forward, all client file access really needs to be going
through explicit APIs like openFileDescriptor(), since that allows
the provider to better protect its underlying files.
This change also changes several classes to use the AutoClosable
pattern, which enables try-with-resources usage. Older release()
methods are deprecated in favor of close().
Uniformly apply CloseGuard across several classes, using
AtomicBoolean to avoid double-freeing, and fix several resource
leaks and bugs related to MediaScanner allocation. Switch
MediaScanner and friends to use public API instead of raw AIDL calls.
Bug: 22958127
Change-Id: Id722379f72c9e4b80d8b72550d7ce90e5e2bc786
If the device was powered off during first boot, after media scanner
inserted some entries but before the default ringtone settings were
set (or committed to disk), the default settings would not be set
on subsequent boots.
Bug: 18625739
Bug: 22349910
Change-Id: Iff07da59a9c6d53bf2950bd107ee74d02b7f48d6
Storage devices are no longer hard-coded, and instead bubble up from
whatever Disk and VolumeBase that vold uncovered, turning into
sibling Java objects in MountService. We now treat vold events as
the source-of-truth for state, and synchronize our state by asking
vold to "reset" whenever we reconnect.
We've now moved to a model where all storage devices are mounted in
the root mount namespace (user boundaries protected with GIDs), so
we no longer need app-to-vold path translation. This also means that
zygote only needs to bind mount the user-specific /mnt/user/n/ path
onto /storage/self/ to make legacy paths like /sdcard work. This
grealy simplifies a lot of system code.
Many parts of the platform depend on a primary storage device always
being present, so we hack together a stub StorageVolume when vold
doesn't have a volume ready yet.
StorageVolume isn't really a volume anymore; it's the user-specific
view onto a volume, so MountService now filters and builds them
based on the calling user. StorageVolume is now immutable, making
it easier to reason about.
Environment now builds all of its paths dynamically based on active
volumes. Adds utility methods to turn int types and flags into
user-readable strings for debugging purposes.
Remove UMS sharing support for now, since no current devices support
it; MTP is the recommended solution going forward because it offers
better multi-user support.
Simplify unmount logic, since vold will now gladly trigger EJECTING
broadcast and kill stubborn processes.
Bug: 19993667
Change-Id: I9842280e61974c91bae15d764e386969aedcd338
Call release for DrmManagerClient to avoid resource leaks
Introduced by following commit (5d143ad4a8f...),
"Media scanner support for FL(Forward Lock) DRM file types"
Change-Id: Ic3c458579f4e99b3b072a2e13362d1996b982589
Instead of checking all the parents of every path for presence of
a .nomedia file every time a new entry is inserted, build a cache
of paths and use that when possible.
Change-Id: I5b912fd54473db8f96d3511cbc2715e0b69dd16b
For storing pointers, long is used in media classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Idc4ca0124d03df7f9cef412488abafd020e5e774
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Make scanSingleFile behave the same way as scanMtpFile, by taking into
account whether there's a .nomedia file guarding the file being scanned.
Without this, downloaded (or otherwise explicitly scanned) images/video/music
will appear in Gallery and Music even if a .nomedia file is hiding them.
Change-Id: Ib9ad4bda1b9a942f79a37ccd8e6a54d57710f528
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
