ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
ConfirmDeviceCredentials sometimes shows up without a title. Since CC
is now using BiometricPrompt, we need at least a private API that allows
the client to have the dialog show a default title.
Bug: 111461540
Test: Manual test with modified BiometricPromptDemo, to launch CC with
empty string
Change-Id: I02a3c9327635c04f201f76754f7c0e1135e5ff36
On devices with multiple biometrics, ConfirmCredentials can
potentially ask the user to authenticate using more than one
biometric. This is a wrapper that sets the active user for
all modalities.
Bug: 111461540
Test: With work profile set up, CC has same behavior as
device running P.
1) With one lock disabled, use modified BiometricPromptDemo
to authenticate using CC in the work version of the app
2) Go to normal version of the app, authenticating
using BP (not CC) works with non-work biometric
Change-Id: I04b6f64d3fe373269366c243f406d897cb6fd83a
The check within BiometricService is done from system server process
so we need to pass in the actual userId.
Bug: 111461540
Test: With normal profile and FP enrolled, with work profile and no
FP enrolled, launching BiometricPromptDemo for work profile
and attempting to start authentication shows "none enrolled" message.
Change-Id: I45a1136d2b33bc7c594a3401e2a087103fb839f3
This constant is being sent from BiometricService but was not exposed
properly.
Fixes: 116823693
Test: atest BiometricManagerTest
Change-Id: I3b80b4908f440b983b4aa68eefb3a785266a4065
* changes:
Move biometric setting observer from KeyguardUpdateMonitor to BiometricService
Change BiometricManager#hasEnrolledBiometrics to canAuthenticate
- Add a new flag indicating that the display should show
system decorations, such as status bar, nav bar, home and IME.
- Automatically launches home activity on secondary display
if the display support system decorations and home
activity has multiple instances supports.
- Remove ActivityStackSupervisor#mHomeStack and move several
home stack related methods to ActivityDisplay.
Bug: 111363427
Test: atest ActivityManagerMultiDisplayTests
atest com.android.server.am
Manual test on virtual display and chromecast
Change-Id: I48fe245ad12965a19a6768f5dbb4e974ce94b01a
Refactor DisplayViewport to treat internal, external, and virtual
display viewports more equally. Now stored in single array, and mLocked
contains the most up-to-date copy of these. Still enforce the
requirement that there can only be 1 internal and 1 external viewport.
We should remove this requirement in the future.
Bug: 111108021
Test: atest DisplayManagerServiceTest
Change-Id: I6fca9725f6e4180063c86f3c2bc34906ac1d0024
Fixes: 116872423
Test: with additional logging, do
adb shell settings put secure face_unlock_keyguard_enabled 1 (or 0)
Test: content observer updates when user changes
Test: clients receive the current state upon registering
Change-Id: Id37381a8c263b29a0b91abb5241d74bb52364d63
BiometricPrompt#authenticate and BiometricManager#canAuthenticate now
use the same logic to determine if the prompt can successfully be shown.
Before Android P, apps used FingerprintManager isHwAvail && hasEnrolled
before asking users to enable biometrics for their app. With
BiometricPrompt, which abstracts away individual biometric modalities,
developers need a way to determine if they should ask users to enable
biometrics for their app. Having separate checks is a nightmare due
to the untestable combinations of multi-biometric devices. This API change
makes it much more scalable since the logic will be done in the platform.
Fixes: 116823693
Test: manual test, returns status correctly
Change-Id: Ie0ecd139c9a39100b6dbc9bd85462400cb465f08
Also added check in BiometricService for user preference (enable/disable
face auth for apps). If disabled, BiometricPrompt returns
ERROR_HW_UNAVAILABLE.
Bug: 111548037
Bug: 111461540
Test: BiometricPromptDemo works
Change-Id: I94ef7fca693af9d5501f87035efbde47a47a0642
PooledRunnable has a nice optional method recycleOnUse(), which can be
used if the Runnable is guaranteed to be executed at most once.
By calling this method, PooledRunnable instance will be auto-recycled
into the internal object pool once it's executed.
Test: presubmit
Change-Id: I6ff341be5d0abddba8134489950be0b7c1affcbb
Fixes: 112570477
Test: BiometricPromptDemo works
Test: Able to get/use BiometricManager
Test: Tested with enrolled and non-enrolled biometrics
Change-Id: I26231894eccc87c42b5b3007aa0b7c6f09830452
This is in preparation for BiometricManager. Each Manager should have its
own Service.
Bug: 112570477
Test: BiometricPromptDemo works
Change-Id: Ibbbd499a0fd5a2050b329ee038776c6c9f49cdb2
* changes:
3/n: Add FaceDialogView and "confirmation" plumbing
2/n: Refactor common code from FingerprintDialogView
1/n: Rename FingerprintDialogView to BiometricDialogView
This change adds plumbing from <Biometric>Service to SystemUI for requiring
user confirmation (or not). This change also fixes some layout bugs
that were hard to notice.
Bug: 111461540
Fixes: 113130114
Fixes: 116135579
Test: With confirmation, crypto operation does not work until token
is added to Keystore
Test: Without confirmation, crypto operation works when biometric is
authenticated
Test: BiometricPromptDemo works, UI elements are all correct
Test: Talkback messages are correct
Change-Id: I2c05577699a29c09777cae4db6c7334c1e6bc179