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
Add unit tests to verify that bug has been fixed.
Re-enable testGetConnectionOwnerUid() unit tests in presubmit. These
were disabled due to test flakiness caused by expected failures passing
as a result of other sockets on the system. This is fixed by checking
that failures do not have the UID of the calling process instead of
INVALID_UID since previously some Qualcomm telephony sockets were
causing lookup successes.
Test: atest InetDiagSocketTest#testGetConnectionOwnerUid
Test: ls -1 /proc/<pid of system_server>/fd | wca
Test: atest --generate-new-metrics 200 InetDiagSocketTest#testGetConnectionOwnerUid
To verify flakes have been cleaned up.
Bug: 141603906
Bug: 141459241
Change-Id: Ib76674f10e4bd24952c557bac7b9c65fba42fdb2
* changes:
MimeMapImpl.createDefaultInstance() -> DefaultMimeMapFactory.create().
Make MimeMap final and introduce MimeMap.Builder.
Move default MimeMap implementation to frameworks.
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
* changes:
New FlickerTests: Run split screen tests at 0 and 90 degrees
New FlickerTests: Start app warm and cold at both 0 and 90 degrees
New FlickerTests: Start IME alongside the app (0 and 90 degrees)
New FlickerTests: Start IME tests with app rotated by 90 degrees
Limit 1 log per app launch as the statd logs as this is spamming logs.
Consider increasing in the future to once every x minutes/seconds if
needed.
Bug: 138374585
Bug: 141714588
Test: flash device
Change-Id: I3ed696fb557527d807d03aecc64c0207d7b93f08
This member has an extremely confusing name, and the logic
handling it being convoluted does not help. This change renames
the member and add comments.
Bug: 112341346
Test: atest FrameworksNetTests NetworkStackTests
Change-Id: Icfb6098d1c9e6293078ea7eede3f24a2fabe9d6b
