Helper class to parse Intent events.
Bug: 117612105
Test: Compile and flash, verify Intent events can be parsed
using the class
Change-Id: I1267a1ce0cbbfd56ff9abb059ccc0117f060b7ff
With PendingIntent, there will be multiple states in the class, so it
will be simpler to mark methods synchronized on the object.
Bug: 117612105
Test: Compile only
Change-Id: I60dfac3113508b9e251e33fd3c1c8f60378017f4
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
- Clarifies that only one PendingIntent can be registered to a client
at a time, since otherwise it can't be regenerated meaningfully.
- Also adds that a ContextHubInfo object is provided in Intent events
to regenerate the client.
Bug: 117612105
Test: None
Change-Id: Ia2b1cc9bc01d10b092598374c0d82e4fa1b45079
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
