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
Migrates getDefaultVrComponents used by SettingsProvider and
adds a flag for hidden API enforcement to ApplicationInfo.
This removes any dependency on SystemConfig from core/ and
so it can be moved into services/core and exposed as a
mainline API.
This was done instead of exposing all of the methods through
SystemConfigManager, as that is designed for use across
processes, and it's more efficient to expose SystemConfig
directly for modules running in the server process.
Although VrManager is a nullable service, so getDefaultVrComponents
had to live there to simplify the logic and maintain the existing
behavior.
Bug: 236389629
Change-Id: I4c2b14e1d34aaf439ceb1a3f9c8207e5d39fa6c2
We received many bugs the ContentCaptureService entered zombie
state but we don't know the reason why the process died. The issue
timing didn't be captured in bugreport.
Currently, the AbstractRemoteService will enter an odd state if the
service cannot be reconnected. This state does not allow the requests
be sent until the service be reconnected again on an unknown timing.
In some cases, it is expected the service will not be reconnected.
e.g. app stop from settings. We should fix the problem in the
AbstractRemoteService but before doing this, we try to add debugging
signal in bugreport to help us understand if the existing issues come
from this odd state for reasonable reasons.
Bug: 248218072
Bug: 250859760
Test: disable app and dumpsys content_capture
Change-Id: Ia33462006a3925754001562b0d80540b9b0bc45d
This change implements PersistentServiceConnection and
ObservableServiceConnection helper classes in framework for better
handling of crashes.
Fixes: 247103878
Test: manually by crashing systemui using adb while dreaming and
verifying that the overlay is visible
Test: atest com.android.internal.util.PersistentServiceConnectionTest
Test: atest com.android.internal.util.ObservableServiceConnectionTest
Change-Id: Ib9a7e8675e408c1724567335a3c186fe5c9f5f59
