Test: Unit tests pass. Creating a Notification with the Notify app allows access to rich media insertion via gboard, and inserted images show up in the Notify app upon sending.
Bug: 137398133
Change-Id: I65218dfaa083f7c24512430e647d8ca79058dff9
This reverts commit 098a533e78.
Reason for revert: Base CL caused slower app startup (I don't know why).
Change-Id: Ib67852b900ff2baeb34f5d553fb0d233f5475888
Added the property profilesystemserver in the RUNTIME_NATIVE_BOOT
namespace. This property is overrides the system one if it is
present.
Bug: 138851258
Test: set the property manually and verify that system server is started
Test: with profiling
Change-Id: Ifd69530e52a717a381b3f91b15a74329614906f2
At the moment isActivePasswordSufficient() can return stale result
immediately after a password change since the latest password metrics
information is pushed from LSS to DPMS asynchronously (this is to
avoid deadlock between LSS and DPMS due to lock inversion). Fix this
by moving the password metrics ground truth to LSS, and make DPMS
query LSS about the password metrics when needed.
Bug: 37090873
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest com.android.server.locksettings
Test: atest DeviceAdminHostSideTestApi24#testResetPassword_nycRestrictions
Test: atest DeviceAdminHostSideTestApi24#testRunDeviceOwnerPasswordTest
Test: atest MixedManagedProfileOwnerTest#testPasswordQualityWithoutSecureLockScreen
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest MixedManagedProfileOwnerTest#testPasswordSufficientInitially
Change-Id: Ib1d1716024b8a6a6554afdb4ee9824d457ed8308
To com.android.internal.compat.IPlatformCompat. This solves a java9
issue because libcore exported api has the same package android.compat.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make framework
Change-Id: I0918344f670669cecb04f1e9e54dbcb471b587d5
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
