diff options
| author | Tobias Thierer <tobiast@google.com> | 2019-08-18 15:21:55 +0100 |
|---|---|---|
| committer | Tobias Thierer <tobiast@google.com> | 2019-08-20 16:56:07 +0100 |
| commit | d9e06a7351c25bf3275cffc382e3e7f8c87e6079 (patch) | |
| tree | c18205f2936ee6f8d9cad5488a65a6be242e5185 /annotations/generate_annotated_java_files.py | |
| parent | 3b4cb251ec0a5c123b417bfe40f96d01a2343a4c (diff) | |
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.
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.
Bug: 136256059
Change-Id: I1621bd2907d5923a19541e3e859238c46187f8df
Diffstat (limited to 'annotations/generate_annotated_java_files.py')
0 files changed, 0 insertions, 0 deletions
