summaryrefslogtreecommitdiff
path: root/mime/java-res
AgeCommit message (Collapse)Author
2021-06-17Merge SP1A.210604.001Brian Orr
Change-Id: I5200ee05285ae422d5e9c1c00f45709a5d6188be
2021-05-13Merge SP1A.210510.001Brian Orr
Change-Id: Ia86f3e18206beabe334e3081cedbaf5b3274f78e
2021-05-13Add gif mime typeCorina
Bug: 168001592 Test: atest MimeMapTest Change-Id: I0413381fd94f61e96d29eb4f139743c197c99040
2021-04-28Allow installation of cert with .der extensionAlex Johnston
* Add der file extension to application/x-x509-ca-cert MIME type. Manual testing steps * Push .der certificate onto device * Install CA certificate via Settings and select .der certificate * Verify certificate has been successfully installed Bug: 185283683 Test: manual testing Change-Id: I0be1897a0aaf6f771c0e534533d2413ff0fc12f6
2021-01-22Merge SP1A.210105.001Scott Lobdell
Change-Id: Iebfaf27bb339a99d9303a53e6c2c397b0001c814
2020-12-09Merge "Add mobi extensions to known mime types" am: 806aa0b377 am: ↵Jeff Sharkey
08715462b9 am: 5848bfa206 Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1514851 MUST ONLY BE SUBMITTED BY AUTOMERGER Change-Id: I107706ff1a59d76dfb610bba92d089df75a94f71
2020-12-09Add mobi extensions to known mime typesSai Rijal
Allow .prc/.mobi file extensions to be read as a separate mobi mime type. This allows Android to open mobi files with the correct mime type. This in turn allows applications to set their intent filters based on mime type when opening mobi files. Test: CtsMimeMapTestCases Change-Id: I2b8f80f019f930f888e8e50db8b4efee0f0d4035
2020-11-17Merge SP1A.201116.001Scott Lobdell
Change-Id: I51f7864ca57206ba4034be7db7ae9f36d5c53f59
2020-11-06Add AVIF mime type to android.mime.typesVignesh Venkatasubramanian
Associate "avif" extension to "image/avif" which is the mime type for AVIF images. Specification: https://aomediacodec.github.io/av1-avif/#mime-registration Unlike HEIF, AVIF does not have separate mime types for still images and sequences: https://github.com/AOMediaCodec/av1-avif/issues/59 Bug: 141654151 Change-Id: I34711d5354aac0b78e89502f84debf9ce0a1ddff
2020-06-19Merge RP1A.200619.001Steven Laver
Change-Id: I053ad69e49d1b43d1f62e75adc37f302c79b8f0d
2020-06-17Add additional optional audio/x-mpeg MIME type to MIME type mapSahana Rao
audio/x-mpeg is a valid MIME type and still being used by some apps. Bug: 157127219 Test: atest CtsMimeMapTestCases Change-Id: I43d18d419a282ff0ca3ca5f2773d7002fcb62014
2020-04-28Merge RP1A.200428.001Steven Laver
Change-Id: Ib91d14aa3fcaa1627e3a5ebcd12ef2db407dac8d
2020-04-27Fix inconsistent MIME type mapping.Jeff Sharkey
MediaProvider heavily relies on developers to provide a MIME type, which it then translates into a file extension, and then later back into a MIME type. For this flow to work without apps losing access to the data they just wrote, all MIME types need to consistently map back to the same "major" type that they started with. This change adds tests to verify this consistency for all audio, video, and image MIME types, and fixes an obscure bug where the "audio/3gpp" MIME type would end up translating to "video/3gpp". Bug: 154667531 Test: atest CtsMimeMapTestCases Change-Id: I47998d8f4b1f9922a7d9439014e2f7f51f401f04
2020-02-04Merge RP1A.200123.001Steven Laver
Change-Id: I16a4437d9876db7a6a2b07231b4584df4564bee4
2020-01-10Add more specific subtitles and lyrics MIME types.Jeff Sharkey
"srt" subtitles have a more specific MIME type of "application/x-subrip", as listed here in Apache and therefore widely used across the Internet: http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types "lrc" lyrics have a more specific MIME type of "application/lrc", as determined here from the archive.org scraping of popular Internet sites: https://discuss.httparchive.org/t/keeping-etc-mime-types-up-to-date/825 Bug: 143707020 Test: atest --test-mapping packages/providers/MediaProvider Change-Id: I9598d1de920f29fbda7efa3c17b5632f756a65f2
2019-11-22Merge RP1A.191114.001Steven Laver
Change-Id: I30dd2dce3b0c2fcd635381413a213fe3e97be97b
2019-11-13Add MIME type for "amr" audio files.Jeff Sharkey
More details here: https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec Bug: 143521987 Test: manual Change-Id: Ic99672b746920d8733873e9df57a7c534e04e9d5
2019-11-09Merge RP1A.191024.001Steven Laver
Change-Id: I5cda3bba276e99d948b752be87d4599e9f882e0f
2019-10-30Additional extensions based on real-world usage.Jeff Sharkey
We've recently started working with the VideoLAN team to understand more about media files they regularly encounter in the wild, which may not have official IANA registrations. In particular, here's the official list they support: http://git.videolan.org/?p=vlc.git;a=blob_plain;f=include/vlc_interface.h;hb=HEAD Some of these file formats are far too obscure to have official MIME types at all, but for the ones that overlap with well-defined standards, this CL registers those extensions as valid options. -- Add SDP per https://tools.ietf.org/html/rfc4566 -- Add SMIL per https://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language -- Add TTML per https://en.wikipedia.org/wiki/Timed_Text_Markup_Language -- Add 3GA as a shortened version of https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec -- Add 3GP2 as shortened version of https://en.wikipedia.org/wiki/3GP_and_3G2 -- Add AC3/A52 per https://tools.ietf.org/html/rfc4184 -- Add M4B as audiobook version of https://en.wikipedia.org/wiki/MPEG-4_Part_14 -- Add M4P as protected version of https://en.wikipedia.org/wiki/MPEG-4_Part_14 -- Add several F4* variants per https://en.wikipedia.org/wiki/Flash_Video -- Add ADTS per https://www.w3.org/2013/12/byte-stream-format-registry/mpeg-audio-byte-stream-format.html -- Add MP4V/MPEG4 as alternative extensions -- Add MP2/MP1/MPA as alternative extensions -- Add MPEG2/MPV2/MP2V/M2V as alternative extensions -- Add MPEG1/MPV1/MP1V/M1V as alternative extensions -- Add M2T as tape-specific variant Additional information available in RFC 4337. Bug: 143549606 Test: atest --test-mapping frameworks/base/mime Change-Id: Id24b6abbb5149ec8cdcb098f43ff611b01a69e96
2019-10-09vendor.mime.types: Revert accidental modification.Tobias Thierer
I had added some lines during verification of the base CL [1], but had accidentally committed, uploaded and merged them. This CL reverts the accidental addition. [1] r.android.com/1136528 commit 8e1c1f4d9dc93f1d4ca324092462690e27ca13e1 Bug: 142267887 Test: Treehugger Change-Id: If9ef2a956c8862b7022137111e6c512455780fc6
2019-10-08Minimize default MIME map and optimize loading.Tobias Thierer
This CL topic speeds up DefaultMimeMapFactory.create() from 15.5msec to 5.7msec (measured by bundling a copy of the logic and data into a test app) and saves 5.2 KByte of space (16 KBytes uncompressed) in framework.jar. This CL topic does not change the amount of heap memory consumed by the loaded MimeMap. This is achieved by moving the following parsing steps from DefaultMimeMapFactory into a build-time optimization step: * strip off comments (starting with '#') * normalize whitespace (trim leading and trailing whitespace; replace remaining whitespace with a single ' '). * drop lines that do not contain a ' ' after this step (those only contained comments or only a MIME type without any extension). * use String.indexOf(char) in favor of String.contains(String) or Pattern matching. Noteworthy extra step specific to this CL: * specifically for vendor.mime.types (but not android.mime.types), add a prefix '?' to MIME types and extensions at build time, rather than at runtime. Note that after this CL, DefaultMimeMapFactory can now *only* parse minimized *mime.types files, not the original (non-minimized) file format. Test: Checked that the mapping didn't change by checking that a device flashed after this CL passes CtsMimeMapTestCases built before this CL. Test: Ran "make mimemap-res.jar" and manually verified that files in the resulting jar look as expected. Test: Locally added some extra mappings to vendor.mime.types, some of them with a leading '?', and verified that they all show up with exactly one leading '?' for the MIME type and each extension within mimemap-res.jar. Bug: 142267887 Change-Id: Idf1ef945a4ac225476f2036fbc8bb35eb9c090af
2019-09-30Introduce vendor.mime.typesTobias Thierer
Like mime.types and android.mime.types, this file specifies mappings between MIME types and file extensions. Unlike those files, it can only be used to define _additional_ mapping but not modify (change, remove) any mappings defined by those files. This is done by prepending '?' to every line element from vendor.mime.types that doesn't already have one; when there is a leading "?", it is ignored so that it's okay to move a line from {android,vendor}.mime.types without necessarily changing it. Test: Checked manually that vendor.mime.types works as expected. Specifically, after adding these lines to vendor.mime.type: audio/mpeg testmpeg audio/testmpeg mp3 ?mime/foo ?fooext the following test passes: MimeTypeMap map = MimeTypeMap.getSingleton(); // Original mapping is unchanged assertEquals("mp3", map.getExtensionFromMimeType("audio/mpeg")); assertEquals("audio/mpeg", map.getMimeTypeFromExtension("mp3")); // Map from the key to existing value is added assertEquals("audio/mpeg", map.getMimeTypeFromExtension("testmpeg")); assertEquals("mp3", map.getExtensionFromMimeType("audio/testmpeg")); // Completely new mapping is added both ways assertEquals("mime/foo", map.getMimeTypeFromExtension("fooext")); assertEquals("fooext", map.getExtensionFromMimeType("mime/foo")); Bug: 141842825 Change-Id: Iaf918ce39324709ff58a8e0f9612e4827a673323
2019-09-30android.mime.types: Fix typo.Tobias Thierer
Test: Treehugger Change-Id: I60032b97251146006c2dc95b4be19c3d2d70697f
2019-09-27Move default MimeMap implementation to frameworks.Tobias Thierer
This is the second attempt to submit this CL. The first attempt regressed on app startup because RuntimeInit installed the custom MimeMap from commonInit() which runs post-fork of the zygote, but that was fixed by installing it pre-fork. This CL topic moves the default MimeMap implementation to frameworks. Libcore starts with a minimal implementation sufficient to pass CtsLibcoreTestCases, but frameworks can inject the real implementation. Before this CL topic, the data files and logic (MimeMapImpl) were part of core-*.jar on device; after this CL, they instead live in framework.jar. Tests from MimeMapTest that check behavior of that default implementation also move to a non-libcore CTS test. Planned work for follow-up CL: 1. Make CTS more opinionated, with a plan to assert that all of the default mappings are present. How exactly the expectated mapping will be bundled in CTS is still TBD. 2. Add a vendor.mime.types file (defaults to empty) where vendors can add additional mappings; I plan to make it such that mappings in that file are parsed last but never override any earlier mappings, as if each mime type / file extension was prefixed with '?'. 3. Perhaps enforce that public APIs android.webkit.MimeTypeMap and java.net.URLConnection.getFileNameMap() behave consistently with MimeMap.getDefault(). Test: atest CtsLibcoreTestCases Test: atest CtsMimeMapTestCases Test: Checked that CtsLibcoreTestCases still passes on a build that is missing the MimeMap.setDefault() call from RuntimeInit.java. Test: Checked that app startup time does not regress as part of this CL topic - see http://b/136256059#comment17 Bug: 136256059 Change-Id: I716914bf1a7e6205e539f0551f010615dacb17a8
2019-08-28Revert "Move default MimeMap implementation to frameworks."Tobias Thierer
This reverts commit 53f15f39f82ef4c4bd99c6d22f3563bae0c35269. Reason for revert: Caused slower app startup (I don't know why). Change-Id: Id9e3811078bc435073f42996767589a711172400
2019-08-21Move default MimeMap implementation to frameworks.Tobias Thierer
This CL topic moves the default MimeMap implementation to frameworks. Libcore starts with a minimal implementation sufficient to pass CtsLibcoreTestCases, but frameworks can inject the real implementation. Before this CL topic, the data files and logic (MimeMapImpl) were part of core-*.jar on device; after this CL, they instead live in framework.jar. Tests from MimeMapTest that check behavior of that default implementation also move to a non-libcore CTS test. Specifically, the logic and android.mime.types now live in frameworks/base/mime. The default implementation is injected into libcore from RuntimeInit. I chose to use a separate directory (frameworks/base/mime/) and build java_library target ("mimemap") in order to keep this as separate as possible from the rest of frameworks code, to make it as easy as possible to factor this out into a separate APEX module if we ever choose to do so. Planned work for follow-up CL: 1. Make CTS more opinionated, with a plan to assert that all of the default mappings are present. How exactly the expectated mapping will be bundled in CTS is still TBD. 2. Add a vendor.mime.types file (defaults to empty) where vendors can add additional mappings; I plan to make it such that mappings in that file are parsed last but never override any earlier mappings, as if each mime type / file extension was prefixed with '?'. 3. Perhaps enforce that public APIs android.webkit.MimeTypeMap and java.net.URLConnection.getFileNameMap() behave consistently with MimeMap.getDefault(). Test: atest CtsLibcoreTestCases Test: atest CtsMimeMapTestCases Bug: 136256059 Change-Id: Ib955699694d24a25c33ef2445443afb7c35ed9e7
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-03 04:40:22 +0000