All the java code used to build the framework jar and run metalava
was previously defined in the toplevel Android.bp files. Move these
into the subdirs where the source actually lives.
This simplifies the rules themselves (no path and needless prefix) and
declutters the top level Android.bp.
Test: m
Change-Id: I97086e309eacb879d16facb8497d9940fa5ddaf6
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
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
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
