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
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
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
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
