InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: I7242e765426353672823fcc8277f20ac361930d7
The extractNativeLibs property was ignored by the package installer
for environments with native bridge. This is not neccessary since
native bridge implementations are required to support
open-directly-from-apk feature and in this respect are not different
from environments without native bridge.
Bug: http://b/116854266
Test: cts-tradefed run singleCommand cts --skip-preconditions -m CtsJniTestCases
Change-Id: I9ea7397183d7ebe2c00e461b95d188b15b51eca2
For the intermediate period, MetricsLogger logs to both event buffer in
logd as well as stastd socket.
Bug: 110537511
Test: statsd, statsd_test
Change-Id: Ie349b1d202e07c585ab5b085141865f20d1f57cd
Adds diskio information to statsd. The puller queries the
proc/uid_io/stats file to get cumulative counts since boot.
Bug: b/116331466
Test: unit test
Test: manually verified that the puller and "cat /proc/uid_io/stats"
returned almost identical output when executed at the same time
Change-Id: Iac446f8dd879ab6bf859eed6e779cc16fdee6c5b
- Also update vold to create sandboxes for secondary storage devices.
- Since bind mounts are created in the process specific namespaces, we
don't need /mnt/storage anymore which we were using it to prevent
some bind mounts from propagating onto /mnt/runtime/write.
- Create bind mounts for {media,obb} dirs similar to data dir in
per process namespace.
- Also fix a bug where we are not passing correct packages to vold when
a new user starts.
Bug: 111890351
Test: manual
Change-Id: I1abbafabc58993860305e5a928c980420f89f289
Updating the CPU stats can be quite slow and blocks the ActivityManager
handler thread.
Bug: 115506775
Change-Id: I9f67acfe2724c11d117703b2c4ccdbcc1f61c5ab
Test: manual - dumpsys batterystats | grep CPU
Add api to collect committed procstats data.
Use highwatermark from the user to filter which files to include. This
way multiple users in the system can use this api.
Also allow ProcessStats.java to dump optional ProcessStatsSectionProto
so that other users can use it.
Test: will add cts test
Change-Id: If37c0fd25814460a1c8d5996d24d138295ff6421
ExternalStorageProvider always throw exception when renameDocument
because it will check file exist when getFileForDocId. However,
beforeVisibleFile is not exist after rename, it will throw
exception. Fix it by put getting beforeVisibleFile before rename.
Test: manual test rename in DocumentsUI
Test: atest RenameActualProviderUiTest
Fix: 113302685
Fix: 115304092
Change-Id: I45d60d2f940e3dbc2b121f7cd28acc3c2d085ec4
Merged-In: I45d60d2f940e3dbc2b121f7cd28acc3c2d085ec4
This CL effectively reverts the following 3 CLs.
* Reduce window resizing during IME transition
I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
* Clear the inset of previous IME when necessary
Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
* Make IMS#clearInsetOfPreviousIme() reliable
Ib567daa009c1139858dccadcfc6a04465ebecf36
833bdcedce
The main idea behind the first CL is that the target application can
skil avoid layout resizing if the following two conditions are met.
A. WindowManagerService (WMS) can remember the last IME's inset until
the next IME's window is fully shown.
B. Both the last IME and the new IME have the same inset.
Basically the first CL implements the above A part with an assumption
that some IMEs would do the B part. However, in reality it is quite
unlikely that two random IMEs have the same inset size. At the same
time, maintaining this kind of special optimization is getting harder
and harder as more and more use cases and form factors need to be
supported.
Let's remove this optimization given that no one is benefited by it.
Fix: 116492038
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: do not see any noticeable visual difference
Change-Id: I8ffbf9bf7c3a8be54df0ca8eac1a1f041ef7d3c9
resolveColor() now considers that black backgrounds should have
monochromatic icons. Ambient style is an exception because we
do want colors in there.
Change-Id: Ia21202bb354babb77013feda67c313323ec1e070
Fixes: 115887386
Test: visual
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
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
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
This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.
When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.
Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs. Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.
With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.
* InputMethodManager.hideSoftInputFromInputMethod
* InputMethodManager.hideStatusIcon
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.shouldOfferSwitchingToNextInputMethod
* InputMethodManager.showSoftInputFromInputMethod
* InputMethodManager.showStatusIcon
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
[1]: If762714b2003fa6477e1318110f63e13968c1d7e
eec552e9e9
Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4
KernelCpuProcReader used FileChannel to dump bytes into a large enough
ByteBuffer. However, FileChannel#read stops as soon as there is nothing
left to read. Since the kernel may not deliver all parts of a proc file
simultaneously, previous read mechanism would possibly read only a
portion of the proc file. The impact is that KernelUidCpuFreqTimeReader
gets an incomplete UID list.
New mechanism uses a loop to turn non-blocking FileChannel#read into a
blocking operation. It does not return until hitting EOF. The reason
not to use Files#readAllBytes is that we want to reuse the byte[].
Bug: 111805985
Test: atest KernelCpuProcReaderTest
Test: compared KernelCpuProcReader#readBytes against Files#readAllBytes
locally
Change-Id: If0d2b6742489632e22c8fec34c627851cda875f2
