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
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
audio/x-mpeg is a valid MIME type and still being used by some apps.
Bug: 157127219
Test: atest CtsMimeMapTestCases
Change-Id: I43d18d419a282ff0ca3ca5f2773d7002fcb62014
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
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
Another CL in this topic moves libcore.net.MimeMap to package
libcore.content.type. This CL updates associated references.
Bug: 136256059
Bug: 124232146
Test: Treehugger
Test: CtsMimeMapTestCases
Exempt-From-Owner-Approval: move affecting imports only
Change-Id: I30aac8b28a1740180ea01834a2bb66b61cb255d4
This addresses an outstanding review comment from https://r.android.com/1130781
Test: Visual inspection only.
Change-Id: Ica163c4a0ec5e963c53c0cc5f2be2cd50d279eeb
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
libcore.net.MimeMap might move to a different package in
future, in which case that part of its TEST_MAPPING would
move elsewhere.
Test: croot frameworks/base/mime && atest
Test: croot libcore/luni/src/main/java/libcore/net && atest
Bug: 136256059
Change-Id: Id4aa29e6bbda439009bf82376865bff5cf36a6d9
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 CL topic introduces a new @CorePlatformApi MimeMap.Builder
and uses it to make MimeMap a concrete, final, immutable type.
This has the following advantages:
- Consistency of behavior of MimeMap implementations with regards
to lower-casing and treatment of null is trivial to guarantee
because there is only one implementation.
- The @CorePlatformApi surface now makes more sense. The responsibility
for lower-casing and treatment of null was previously split between
MimeMap in libcore and MimeMapImpl in frameworks/base, which is why
MimeMap.toLowerCase() and MimeMap.isNullOrEmpty() were in the
@CorePlatformApi.
- Most of the logic now lives in libcore / ART module.
frameworks/base now has minimal logic. This makes it easier to write
(in a follow-up CL) a CTS test that asserts all the default mappings,
because that test can now duplicate that small amount of logic in
order to read from a copy of the same data files.
Note: The semantics of the @CorePlatformApi Builder.put(String, List<String>)
are fairly complex, which isn't great. This was done because:
- By following the semantics of the *mime.types file format, it allows
us to minimize the logic in frameworks/base.
- It's simpler than having multiple overloads of put() for
mimeType -> file extension mapping and vice versa,
and for whether or not any existing mapping should be overwritten.
If we had named classes for MimeType and FileExtension with
appropriate case-insensitive equals and hashCode semantics, then
we could instead have API such as
builder.asMimeToExtensionMap().put(...)
but existing API (e.g. Intent.getType(), android.webkit.MimeTypeMap)
has set precedent for treating these as Strings.
Bug: 136256059
Test: atest CtsLibcoreTestCases
Test: atest CtsMimeMapTestCases
Change-Id: I9a185a689745726dd79b15117892001461fa4a0d
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
