17 Commits

Author SHA1 Message Date
Corina
506eae3745 Add gif mime type
Bug: 168001592
Test: atest MimeMapTest
Change-Id: I0413381fd94f61e96d29eb4f139743c197c99040
2021-05-13 08:24:32 +00:00
Alex Johnston
9ca2d03ff2 Allow installation of cert with .der extension
* 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-04-28 17:49:47 +01:00
Jeff Sharkey
cb1039d660 Merge "Add mobi extensions to known mime types" am: 806aa0b377 am: 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-09 20:46:37 +00:00
Sai Rijal
eeb1257df8 Add mobi extensions to known mime types
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-12-09 11:03:14 -08:00
Vignesh Venkatasubramanian
c08511b34b Add AVIF mime type to android.mime.types
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-11-06 13:38:07 -08:00
Sahana Rao
42a1345445 Add additional optional audio/x-mpeg MIME type to MIME type map
audio/x-mpeg is a valid MIME type and still being used by some apps.

Bug: 157127219
Test: atest CtsMimeMapTestCases
Change-Id: I43d18d419a282ff0ca3ca5f2773d7002fcb62014
2020-06-17 23:39:06 +01:00
Jeff Sharkey
0db4811916 Fix inconsistent MIME type mapping.
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-04-27 11:53:12 -06:00
Jeff Sharkey
01c5b10196 Add more specific subtitles and lyrics MIME types.
"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
2020-01-10 16:44:25 -07:00
Jeff Sharkey
8a1370053c Add MIME type for "amr" audio files.
More details here:
https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec

Bug: 143521987
Test: manual
Change-Id: Ic99672b746920d8733873e9df57a7c534e04e9d5
2019-11-13 10:02:02 -07:00
Jeff Sharkey
3d44b1009e Additional extensions based on real-world usage.
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-30 17:22:46 -06:00
Tobias Thierer
033bce99cd vendor.mime.types: Revert accidental modification.
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-09 17:01:27 +01:00
Tobias Thierer
8e1c1f4d9d Minimize default MIME map and optimize loading.
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-10-08 21:03:44 +01:00
Tobias Thierer
324349142c Introduce vendor.mime.types
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-30 17:10:53 +01:00
Tobias Thierer
e25c54f328 android.mime.types: Fix typo.
Test: Treehugger
Change-Id: I60032b97251146006c2dc95b4be19c3d2d70697f
2019-09-30 14:16:51 +01:00
Tobias Thierer
878c77b704 Move default MimeMap implementation to frameworks.
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-09-27 16:53:15 +01:00
Tobias Thierer
f83bd777f3 Revert "Move default MimeMap implementation to frameworks."
This reverts commit 53f15f39f82ef4c4bd99c6d22f3563bae0c35269.

Reason for revert: Caused slower app startup (I don't know why).

Change-Id: Id9e3811078bc435073f42996767589a711172400
2019-08-28 22:43:33 +00:00
Tobias Thierer
53f15f39f8 Move default MimeMap implementation to frameworks.
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
2019-08-21 14:46:50 +01:00