Skip to content
Snippets Groups Projects
Select Git revision
  • test
  • fifteen-qpr0-new
  • fifteen default
3 results
Search by author
  • Any Author
  • Farzin Kazemzadeh Farzin Kazemzadeh itisFarzin
1 author
  1. Sep 27, 2019
    • Tobias Thierer's avatar
      Make MimeMap final and introduce MimeMap.Builder. · fd9657d0
      Tobias Thierer authored 
      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
      fd9657d0
    • Tobias Thierer's avatar
      Move default MimeMap implementation to frameworks. · 878c77b7
      Tobias Thierer authored 
      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
      878c77b7
  3. Sep 26, 2019
  5. Sep 25, 2019
  7. Sep 24, 2019