Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I4bc8c9482e4bb1af21363f951affff7ee3fefeab
An upcoming change will move MediaStore to be within the recently
created MediaProvider APEX. This means that MediaStore will need to
be fully built against @SystemApi, and so this CL adjusts APIs to
support a clean transition:
-- Listing of "recent" storage volumes and scan paths for "internal"
storage is now handled by StorageManager directly, so that partners
retain control over what is deemed recent.
-- StorageVolume now returns the MediaStore volume name and the
filesystem directory where its contents are presented to apps.
-- Conversion of legacy thumbnail "kind" values to dimensions now
happens directly inside MediaStore.
-- PendingParams and PendingSession are completely removed.
-- Contributed media APIs are completely removed.
-- Media for demo users is now surfaced as a unique StorageVolume.
-- Migrate most MediaStore APIs to accept ContentResolver, which
supports easy usage of ContentResolver.wrap().
Bug: 144247087, 137890034
Test: atest --test-mapping packages/providers/MediaProvider
Exempt-From-Owner-Approval: in-place refactoring
Change-Id: I445528b2779bb37b9f2558e67a3cfc9f60412092
We've already been parsing them for many years, and they're well
defined by other public APIs, so let's reveal them in MediaStore.
Also get some storage-related documentation updated to guide
developers towards replacements in a post-scoped-storage world.
Bug: 140247264, 139185855, 141523097, 139185322
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Id39a74a9972a330b3f83913b2eef5100ec59627d
- If we do full file decoding, we should not handle orientation by
ourselves.
- If we decode the thumbnail from ExifInterface.getThumbnailBytes()
or MediaMetadataRetriever, we should handle the orientation.
Change-Id: I632b0b0ed41710401192dfb12f407eaf74c480ba
Fix: 130446058
Test: manual
- When MediaMetadataRetriever can't create the thumbnail of some
HEIF files, attempt decoding it from ExifInterface.
- ImageDecoder can't create the thumbnail with getThumbnailBytes
from ExifInterface in some cases. It will occur DecodeException:
Failed to create image decoder with message 'unimplemented'Input
contained an error. Attempt to decoding the full image in these
cases.
- Use orientation from ExifInterface to transform the thumbnail to
right orientation.
Test: manual
Test: atest ThumbnailUtilsTest
Bug: 130775874
Fix: 130446058
Change-Id: Icd0726ec49fe85651150736199c3caa184fa1a3f
Handle many simple, smaller changes in a single CL. Hide
CPC.closeQuietly(), now that it implements AutoCloseable. Add more
details to CR.set/getCache() docs. Add many @Nullable/@NonNull
annotations.
Bug: 124507578, 124447751, 124302519, 123697622
Bug: 123661322, 122887179, 122528742, 122527812, 116224797
Test: manual
Change-Id: Icee556a6ed76bbdf4c8e42b59d69d5580d461b95
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
The existing APIs were pretty limited by only accepting a "kind"
value, so improve them to accept an arbitrary size, and offer a way
to cancel requests when no longer needed.
The older APIs were a mix of both public and @UnsupportedAppUsage,
so mark them all both public and deprecated so we can clearly steer
developers towards better options. (The deprecated methods are
implemented using the new APIs internally for sanity.)
Use modern ImageDecode internally, which is more robust than
BitmapFactory. Add CTS to confirm that we generate thumbnails of
reasonable sizes.
Bug: 119887587
Test: atest android.media.cts.ThumbnailUtilsTest
Change-Id: I4ca35569ad5c661b327a0cb24a48ebc21f6087b7
If there is no album art set, fall back to the first frame in the video,
as was previously done.
Test: manual
Change-Id: Id091c3c8a8054a87124759eb9be3ba759a115ad4
Fixes: 117161952
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: I3bd40136d7fc948f66eca6b2d139c15e39c5a248
Use the heif embedded thumbnail as long as it's not
too small to avoid decoding the full image and downscale.
bug: 74395267
Test: CTS MediaMetadataRetriever test; manual test of thumbnail
extraction by browsing new folders containing heif files in
Downloads app.
Change-Id: I5b2be0521452376153a773cb7671fefe7f9bc439
Allow for 160*120 thumbnails which is what cameras commonly
generates. The constants for the micro thumbnail were set to other
values, resulting in recalculations of the thumbnais, which
takes time.
This change only affects the maximum size of the temporary image,
when choosing whether to use the EXIF thumbnail or decoding and
downsampling the full image. Without this change, it will choose
an x16 downsampling of the full image over an x2 downsampling of
the EXIF thumbnail, after the change it will prefer the EXIF
thumbnail.
Cf the DCF specifications at http://www.exif.org/dcf.PDF,
"3.3.6. DCF basic thumbnail data structure, (C) Pixel count"
Tested by running DDMS and measuring the time required to create
a thumbnail. This was 220-280 ms prior to change, < 20 ms after.
Change-Id: I59c753493f947e920bad3fde5eeed5d49d509863
We need to close it explicitly after using it. Without this, fd will be closed
non-deterministically, and that will break the decode procedure.
Bug: 5808889
Change-Id: Icf9ff9abd6e327b122c6916df9750016b3d1b616
Added handling of OutOfMemoryError handling to createImageThumbnail
method in ThumbnailUtils.java. During mediascanner run it would run
out of memory when trying to decode very large images. Now it handles
this error and returns null which is handled by the media scanner.
Change-Id: Ie68722dfa1cedd3c0847bf483baa40c4827ad5a8
o Prepare for publishing MediaMetadataRetriever as public API
step one:
o replaced captureFrame with getFrameAtTime
o removed getMode
o Replace MediaMetadataRetriever.captureFrame() with MediaMetadataRetriever.getFrameAtTime()
as part of the preparation for publishing MediaMetadataRetriever as public Java API
o Remove captureFrame from MediaMetadataRetriever.java class
It has been replaced by getFrameAtTime() method
o Replace extractAlbumArt() with getEmbeddedPicture() in MediaMetadataRetriever.java
o Publish MediaMetadataRetriever.java as public API
o Removed setMode() methods and related mode constants
o Removed some of the unused the metadata keys
o Updated the javadoc
o part of a multi-project change.
bug - 3309041
Change-Id: I2efb6e8b8d52897186b016cb4efda6862f5584c4
o Removed setMode() methods and related mode constants
o Removed some of the unused the metadata keys
o Updated the javadoc
o part of a multi-project change.
bug - 2433195
Change-Id: I5ed167f1fd6a53cb143b7dc385b149431d434438
