Historically, the mapping implemented by MimeMap (formerly MimeUtils)
was largely untested and therefore differed between Android devices.
This CL topic makes CtsMimeMapTestCases a lot more opinionated by
checking that:
- MimeMap.getDefault() must respect all of the mappings supplied
in stock Android. This is enforced via CTS bundling a copy of:
- the {,android.,vendor.}mime.types data files
- DefaultMimeMapFactory (rewritten via jarjar to
android.content.type.cts.StockAndroidMimeMapFactory)
MimeMap.getDefault() is allowed to implement _additional_
mappings, but changed or removed mappings are not allowed.
- Public APIs android.webkit.MimeTypeMap and
URLConnection.getFileNameMap() must behave consistently with
MimeMap.getDefault() (in stock Android, those APIs are
implemented directly on top of MimeMap.getDefault()).
Test: atest CtsMimeMapTestCases
Test: atest CtsLibcoreTestCases:libcore.libcore.net.MimeMapTest
Test: The above atest runs pass on a device that contains an
additional mapping in vendor.mime.types that is not
present in CTS.
Test: Checked that on a device that changes a mapping in
android.mime.types, CtsLibcoreTestCases still passes
but CtsMimeMapTestCases fails.
Bug: 141842930
Bug: 139895945
Change-Id: I68e0e9c3ce53c1acf2a89f8b80519f4658c07217
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
The class no longer implements MimeMap, so the name MimeMapImpl
no longer made sense.
Test: Treehugger
Bug: 136256059
Change-Id: I2cbc70a7769232b704a9bdfde2def832c1e292b8
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
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
