* changes:
Animate panel to transparent if profile is managed
17/n: Show credential UI if setDeviceCredentialAllowed(true) and no biometrics
16/n: Add PIN/Password
15/n: Allow Auth UI to start in credential UI
14/n: Animate to device credential UI when lockout occurs
13/n: persist device credential across configuration changes
12/n: Add LockPatternView for setDeviceCredentialAllowed(true)
11/n: Animate panel to full-screen when "Use Password" is pressed
Removing old confirm device credential logic
If the user is locked out of biometrics, and
BiometricPrompt#setDeviceCredentialAllowed(true), the user should be
shown the credential UI.
This change gives BiometricService the ability to request SystemUI
to show AuthCredentialView without first showing AuthBiometricView.
Bug: 140127687
Test: atest BiometricServiceTest
Test: atest com.android.systemui.biometrics
Change-Id: Ic26986ba044b7992641676c3d3b99fc1395a45b7
This way it can be turned on/off without a recompile, and checking the
flag doesn't require a context
Test: adb shell device_config put systemui notifications_use_people_filtering false && adb shell kill $(pid com.android.systemui)
Bug: 140232781
Change-Id: I8ba5e7809dc58e9493397db8447456601a398540
A side effect of CL topic r.android.com/q/topic:bug136256059_attempt2
was that the default MimeMap instance is now loaded eagerly (pre-fork)
regardless of whether any app process ends up using it, whereas
previously it was loaded lazily (post-fork) the first time an app
process used it.
This traded off CPU and memory use post-fork vs. pre-fork. Because it
isn't known / hasn't been proven whether and how many app processes
use that instance, the net CPU and memory impact is not known: if at
least one process makes use of a relevant API, the net impact will be
neutral or positive, or else negative.
Until this can be investigated and undergo system health review, this
CL topic changes the behavior back to post-fork lazy loading of the
default MimeMap instance.
Bug: 142019040
Test: Treehugger
Change-Id: I2a3f244240c51e7ada1f41a8abadb946ebcab40b
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
The zygote handles requests by polling on its sockets, and then handling
one request for each active socket. However, it does so by reading from
a socket via a BufferedReader, which means that if multiple requests are
written into the socket before the zygote gets a chance to read them,
the zygote reads multiple requests into its BufferedReader, it handles
one request, and then never responds to the request that's buffered,
leaving its client stuck waiting for a response that will never happen.
For most requests, this can't happen, because the client will wait for a
response to be sent from the zygote before sending another request, but
this isn't true for --boot-completed until this patch.
Bug: http://b/141767463
Test: forrest runs of apct/text/text_native_test-cloud-tf
Change-Id: I8b7a80abfd9443d98f8cf5aedb7669b82c0cb84a
Needed for scoped storage (to be used from MediaProvider).
IsChangeEnabled returns true if there are no installed packages for the
required UID, or if the change is enabled for ALL of the installed
packages associated with the provided UID.
Bug: 138275545
Test: Test app
Change-Id: I6785f57e4fcfb92ed7529f4da0a6db6ffe8b3ad4
Add showInsets(types, fromIme) in IWindow in order for WM to be able to request
show for any of the InsetTypes.
Note: This will be used in followup CLs.
Bug: 139487540
Bug: 118118435
Test: Build passing
Change-Id: Ie988d0a234befa530ca236a3bb32c77d8a4dce21
This reverts commit 243e7ea14b.
Reason for revert: b/141854898
Exempt-From-Owner-Approval: Revert for failure to boot
Change-Id: Id6812e5ecf7d88504706b2c4110d83f1034ab85c
* 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 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
