With this CL,
adb shell dumpsys input_method,
tells us about whether startInputInner() is triggered by
InputMethodManager.DelegateImpl#onScheduledCheckFocus()
or
InputMethodManager#checkFocus().
Other than that there must be no observable behavior change.
Bug: 234882948
Test: presubmit
Change-Id: I54ebf1a4e1f749ce265756908ef52fc63f1218e5
InputMethodManagerService has had logic to show notifications when the
IME switcher icon cannot be shown on NavigationBar[1][2][3][4][5].
With this CL, such a fallback behavior is completely removed. Devices
and form-factors that need a special handling need to come up with
their own solution rather than relying on this historical notification
mechanism.
[1]: I2b9e955003c1f6703978824c947d5f322a039714
7cfc0ed21a
[2]: Id36c8c34159bea8b72557b40bcf024d401f580b6
01065a5719
[3]: I34a95732ef3e7c20d6549b57230c11f0c3db04d6
d4b625994f
[4]: I58421143bee25be459f4f744688b37614a750051
f62c0b837a
[5]: I6ad818fc9ef08991e24c5020498243f1fc417998
24ab9e18a7
Bug: 245989733
Test: atest CtsPermission2TestCases:ProtectedBroadcastsTest
Test: presubmit
Change-Id: I3b09d2b05ba9bde686b360b9f720b5d4258551c3
This adds Jank instrumentation every time recent tasks are scrolled.
Bug: 231130484
Bug: 228969045
Test: recorded prefetto trace while scrolling
Change-Id: I48201e73d7025ec2ff38c7f9158eec27ed9cbafa
This allows the framework to ask for a monitor to use for backups that
are initiated by the framework (i.e. scheduled backups). Previously
the only way to pass a monitor in was through the
BackupManager#requestBackup API.
I also moved BackupManagerMonitorWrapper to a separate class now that
it's shared by three different classes.
Bug: 252763821
Test: atest CtsBackupHostTestCases
Also manually by implementing a simple monitor inside LocalTransport
and calling the new getBackupManagerMonitor.
Change-Id: I84d56a3e80d6c94f9a327f7d71876d1bc27fe5ac
Frequent mobile radio power state changes results in frequent
ModemActivityInfo queries. To limit the unnecessary churn, a Modem
update due to mobile radio power state change will only occur some
amount of time after the previous update. Modem updates due to other
signals (plug/unplug events, battery percent change, etc) will be
unaffected.
Fixes: 239715259
Test: atest BatteryStatsNoteTest
Merged-In: Ie0af28dbc2ad4836ef6437c0656dc20eec2285ea
Change-Id: Ib3ee18113ac381b8912bb58974b5d41ceefb7131
The profiling currently works by accident: only because we profile the
boot classpath which executes in JIT zygote do we not load system server
AOT artifacts.
So make the not loading AOT artifacts in system server explicit when the
system server is being profild.
Test: system server profiling
Change-Id: I8d787c8f8524d9d6074dc0f552a856640f11cef0
Those methods are not used anymore. And the regular lambda is
already good in performance.
Bug: 120160274
Test: atest LambdaPerfTest
Change-Id: Id3d736da726d003ce9b57ff72193d33e244b6b30
- Seperate System language and app language logic to different
controller
- Fixing system langauge only show in suggested langage and not show in
all languages.
Bug: 228596568
Test: set system/app languages
Change-Id: I3b7ab0a78a77a71794dfd4a59c807637fb7b912d
This is the 5th CL after our CLs [1][2][3][4] for IME visibility
issues.
While the last CL [4] logically reverted most of changes made in
previous CLs [1][2][3], there remain some unintentional changes around
WINDOW_FOCUS_GAIN*. The biggest issue is the invocation of
IMM#mServedInputConnectionWrapper.isActive(),
from startInputOnWindowFocusGain() added in the 3rd CL [3]. This is
really problematic because it internally
IMM#checkFocus(),
which is not intended to be called from startInputOnWindowFocusGain().
This CL addresses that problem by effectively removing the call path.
App compat risk is supposed to be low because IMM#checkFocus() was not
called before the 3rd CL [3], which was introduced in Android R.
There are CTS tests to verify that related issues are not regressed
again [5][6][7].
[1]: I45a9814d812ad906f417c24200fd4219959e2423
6ecbf08772
[2]: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
48bfc3165c
[3]: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
d43b75cf0e
[4]: I022ad658844142ff4a4cf3b91953013f2bfbb58a
a24622cfcd
[5]: Ie029c109e257be81a1ad6327a706bb6bc1e8316c
3045df602f061a185f6fff18e81f5af1a2c51270
[6]: Id48eedc1a2d5597bbba5f1d3fc01540e2f6de4c5
3ed79ab2de600bce312b4ce59b319da0ad9a8dac
[7]: I022ad658844142ff4a4cf3b91953013f2bfbb58a
a24622cfcd
Bug: 152373385
Bug: 155781821
Bug: 160391516
Bug: 161273049
Bug: 182259171
Test: presubmit
Change-Id: I64412e87c4881018ea67140f9472e10ea41836e4
This allows core libraries (such as predictive back progress animation)
to use spring animation.
Files in androidx/dynamicanimation/animation that are not copied over:
FlingAnimation.java - Unused atm
AnimationHandler.java - Replaced with the framework AnimationHandler
FloatPropertyCompat.java - Replaced with FloatProperty
FrameCallbackScheduler.java - Unused in framework AnimationHandler
Test: m -j
Bug: 238475284
Change-Id: Ifdf847da0aa2a6cf57e18f9ac7c91bb0fe3b12c2
Currently we profile only main system server classpath, this is to allow
profiling for the standalone system server jars.
Bug: 241823638
Test: System server profiling: verified the profile snapshot of the boot image profile, and it showed the new jars profiling data.
Change-Id: I5b10373fb22ddfecdb95b6a4611f4af97bb5666d
This is the 6th CL for Bug 26851566 [1][2][3][4][5].
In the CLs [3][5], the approach we took was to extend an existing IPC
method
IInputMethodClient#setActive(boolean active, boolean fullscreen)
by adding one more parameter "reportToImeController".
However, it seems that such an approach made its handling code hard to
maintain, because the IPC method needed to behave in a completely
different manner depending on the newly introduced parameter.
To avoid such a confusion and to make subsequent refactoring easier,
this CL introduces a new IPC method
IInputMethodClient#setInteractive(
boolean interactive, boolean fullscreen)
to clarify what we are actually doing.
In most cases there must be no observable behavior change. One
possible behavior change is when setInteractive() gets called when
IMM#mCurRootView.getView() is not available. In the previous CL, we
fell back to previous behavior as if
FINISH_INPUT_NO_FALLBACK_CONNECTION was not defined. However it looks
like such a fallback mechanism is not an intentional behavior.
The main use case is still verified with existing CTS tests [6][7].
[1]: Ic11956fe745a829da1ec7c09ea214e9b3961c8e0
0df8812486
[2]: If06daf71160aa44a4254ac125561974ecbdef4f2
2c6e80be12
[3]: I8a657e75e274d842fb46b60375f6aeafeab96a59
152eacec4f
[4]: I16f4a34360a2f64b69978724648a9be741f140b5
3d62f739a8
[5]: Id4e71a822bfde5fe6a263bbe094c0d238017efe1
3d62f739a8
[6]: Iba0332ed3b767a9a15768b64947b9cde31105af1
e2f4138156c784746becde6a01c19f0c3de6ac32
[7]: I346ef42f2546a2925bf44ca7719ae19399e15e78
84c5ec2f81d4be5285b9c5f1d0e943f808e9158c
Bug: 26851566
Bug: 156215187
Test: atest InputMethodStartInputLifecycleTest
Change-Id: I0c95d7e70357ac98b336cd1b51a7405ba92a9a6f
In reality methods defined in IInputMethodManager are no more or less
than a set of global methods, because you can write the following
logic anywhere.
var service = IInputMethodManager.Stub.asInterface(
ServiceManager.getService(Context.INPUT_METHOD_SERVICE));
if (service != null) {
try {
service.doSomething();
} catch (RemoteException e) {
e.rethrowFromSystemServer();
}
}
With above observation, this CL introduces IInputMethodManagerGlobal
as a collection of static methods that invoke methods defined in
IInputMethodManager so that other framework classes do not need to
write the same piece of code.
public final class IInputMethodManagerGlobal {
public static void doSomething() {
final var service = getService();
if (service != null) {
try {
service.doSomething();
} catch (RemoteException e) {
e.rethrowFromSystemServer();
}
}
}
......
}
This CL then simplifies ImeTracing to demonstrate how
IInputMethodManagerGlobal can be used.
Basically this is a mechanical refactoring. There should be no
observable behavior change.
Bug: 234882948
Test: presubmit
Change-Id: I5412eb1d44e3d515ca955f00a2e777b659a15b14
Disable the button listeners after the first click to
avoid the creation of more than one user per dialog.
Bug: 252831574
Test: Manually tested by calling the API from a regular app
Change-Id: I6d343ae0a2a4d81d35a85f51a60c88c0c18dba21
