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
Loading
Please register or sign in to comment