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
Somehow InputMethodManager#peekInstance() has not been thread-safe.
Although we basically do not care this deprecated method, but let's
just update it for consistency.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I56bf05f76a7939f004efefdd956776e533bae058
This fixes a minor mistake in the TracingController class usage. The
example previously used a bare `CATEGORIES_WEB_DEVELOPER` instead of
`TracingConfig.CATEGORIES_WEB_DEVELOPER`.
Bug: 116227333
Test: make docs
Change-Id: I648dd0d5e61666e61adb27303c185013bd80b0ea
- Moved CompatModePackages to ActivityTaskManagerService since it is mostly used for activity stuff.
- Moved mHeavyWeightProcess to ActivityTaskManagerService since it is set for activities.
- Set AMS.mBooting and AMS.mBooted as volatile to allow setting from both AM and WM side with hold locks.
- Allow updating of cpu stats, usage stats, and foreground time from WM side.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I48ab55bdd5aacc864cb6a82d19d1a24b7605a5b0
This should reduce the size of the data, because we will
not track the very rare calls unless we are collecting
a detailed sample.
Test: Manual and UTs
Change-Id: If217a9a848935878a6efcdfac9df723c6ce54361
Add ThreadLocalWorkSourceUid and Message.workSourceUid
which will store the UID which caused, directly or
indirectly, the Message to be enqueued.
This was needed because using Binder.getCallingUid() does
not give us enough data since quite a few Binder services
call Binder.clearCallingIdentity() when processing the
call.
Test: UT and manual
Change-Id: I35af3a9ca5193477070990b41ff5d9c52f420069
This is the last step to remove the dependency on IInputMethodClient
from WindowManagerService.
With my previous CL [1], now WindowManagerService (WMS) depends on
IInputMethodClient just because it implements lifecycle management of
IInputMethodClient on behalf of InputMethodManagerService (IMMS).
This CL mechanically moves that responsibility from WMS to IMMS for
better separation of concerns. It is a bit ironic that this CL is
partly undoing my previous CLs [2][3] that removed
IInputMethodManager.addClient() though.
This CL aims to preserve the current observable behavior (e.g. when
InputMethodManager instance is being created) as much as possible.
Most likely there would be no observable behavior difference when seen
from other components.
[1]: I444077b1e4af4033f67ab72c181fac85b601e08a
41f89c3bcc
[2]: I453200fd5847e9a78876affb6a1caec221525e1d
e24ed79edb
[3]: Id91dd600120e4981aa1d9005ce644728968430c9
fffc0e53c6
Fix: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I7726c70613ea72d6e78fa5754e9fc840f0a40f11
InputMethodManager#sInstance is a long live static object so we have to
set its field with right value, otherwise any object referenced by it
cannot be gc including potential activity context.
Now InputMethodManager#mCurRootView is set to null in
InputMethodManager#onPreWindowFocus which is invoked when app's
ViewRootImpl received ViewRootImpl#W#windowfocusChanged from WMS.
However, in the ViewRootImpl#W#windowfocusChanged, mViewAncestor is a
weak reference which get() may returns null sometimes.
One scenario is the ViewRootImpl#W#windowfocusChanged is called after
ActivityThread#handleDestroyActivity. The activity is destroyed and its
ViewRootImpl get GC'd. Then InputMethodManager#onPreWindowFocus won't
get called and InputMethodManager#mCurRootView won't be set to null.
And it is a proper time to set InputMethodManager#mCurRootView to null
when the window it served dismissed.
Fix: 116078227
Test: Break at ActivityThread#handleDestroyActivity and ViewRootImpl#W#windowfocusChanged
Change-Id: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
Signed-off-by: daqi <daqi@xiaomi.com>
This is a preparation to remove the dependency on IInputMethodClient
from WindowManagerService.
What inputMethodClientHasFocus(IInputMethodClient) is currently doing
is basically equivalent to comparing PID (and UID), because
InputMethodManager is a per-process instance and comparing two
IInputMethodClient Binder proxies is no more or less than comparing
PID (and UID pair). We can just change its method signature to
achieve the same behavior by taking a PID/UID pair instead of taking
IInputMethodClient.
Note that we can later add display ID to this method to support
multi-display scenario.
This CL also renames inputMethodClientHasFocus() to
isInputMethodClientFocus() for better consistency with other methods.
There should be no observable behavior difference in this CL anyway.
Bug: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I444077b1e4af4033f67ab72c181fac85b601e08a
