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
- call LooperStats.reset() from StatsCompanionService
- add screen_interactive to the LooperStats atom
- temporarily set uid = 1000 to avoid statsd warnings that the uid is invalid
Bug: 113651685
Test: Manual and UTs
Change-Id: Iacf45fcb746c6bb9837456a2a0c74f5a073ff822
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
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
1) Moving WMS.setInputMethodWindowLocked to DisplayContent,
each display can have its own IME window.
2) Add getDisplayIdFromWindow in WindowManagerInternal,
used for InputMethodManagerService to know which display
for given IME window token.
3) Support add / remove IME window according displayId.
4) Modify WMS.inputMethodClientHasFocus to traverse all active display
if inputMethodClient focused.
5) Add displayId parameter for IInputMethod.initializeInternal to
update context display then client can addView to right display.
Note: 1) There should be zero behavior difference as long as the target
app is running on the default display.
2) The current implementation is not final and there are still
chances that the current IME may not work well or even crash
depending on how the IME is implemented.
Bug: 111364446
Test: manual, use ActivityView & launch Messages in VirtualDisplay,
tap search icon to see if soft input keyboard shown &
app window size is adjusted by soft input.
Change-Id: I8da315936caebdc8b2c16cff4e24192c06743251
Short summary:
There is no need to have these 3 utility classes in frameworks.jar,
because these classes are used only from InputMethodManagerService
(IMMS) and its utility classes. We should move them to services.jar.
Long summary:
* InputMethodSubtypeSwitchingController
This class was mistakenly placed in the current Java package since its
beginning [1]. This class is purely a state machine that is designed
to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.
* LocaleUtils
This class was also mistakenly placed in the current Java package
since its beginning [2]. This class is purely a state machine that is
designed to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.
* InputMethodUtils
The situation of InputMethodUtils is a bit different. It was
introduced in the right place actually [3], because the original
purpose of this class was to share some utility methods between IMMS
and the Settings application. For that purpose, having this class
under frameworks/base/core/java instead of frameworks/base/services/
totally made sense.
What was unfortunate is that we have kept adding more and more utility
methods into InputMethodUtils since then, even though most of methods
have been used only from IMMS. To make things worse, more and more
random components started depending on this utility class. When we
realized it, we were in the situation where we could not even easily
refactor methods in InputMethodUtils without updating a bunch of
call-sites across repositories, including multiple platform-specific
Settings app and SetupWizards.
This is basically why I decided to stop allowing Settings apps and
SetupWizard to use InputMethodUtils, and decided to let them depend on
SettingsLib [4] instead. After many cleanup CLs [5], we have finally
achieved the state where InputMethodUtils is used only from the system
server process.
* A special bonus
With my previous CL [6], we can even make these 3 utility classes
package-private, which guarantees that only IMMS and its utility
classes directly depends on these utility classes.
* Risk
Now that this is purely a mechanical refactoring of an implementation
detail within frameworks/base, there should be no observable behavior
difference.
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ce
[2]: I315cf3722a06e00bdbfac284c4949578da8fe78d
102ff0726d
[3]: I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6
8e303cc5dd
[4]: frameworks/base/packages/SettingsLib
[5]: CLs that have Bug 77730201 in their commit messages
[6]: I023d8f2863601ee54f304988117d8ea750770f70
603f4d00c6
Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.inputmethod
Change-Id: I37594096151d77adb6741a41d7985a4506f96ccb
The main motivation of this refactoring is to move InputMethodUtils to
com.android.server.inputmethod as a package-private class. With a lot
of cleanup CLs in Bug 77730201, the only remaining utility method that
is used by multiple Java package is this constructLocaleFromString()
method.
This is purely a mechanical refactoring. There should be no
observable behavior difference.
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: Ic47b680ad9efde104015d34311f49e224d3fb56f
When I needed to introduced a new helper method for
TextServicesManagerService (TSMS) to fix Bug 22042994 [2] I was just
lazy and decided to put it into InputMethodUtils instead of creating a
new utility class for TSMS.
Now that InputMethodUtils is going to be moved to
com.android.server.inputmethod as a package-private utility class, it
is time to pay off my laziness.
With this CL, getSuitableLocalesForSpellChecker() will be extracted
out from InputMethodUtils to a new package-private utility class
com.android.server.textservices.
This is purely a mechanical refactoring. There should be no
observable behavior difference.
[1]: I094f1c33430f7904a1dac6167431d6df64a07212
174843afb6
Bug: 77730201
Bug: 114660660
Bug: 115516399
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: If6cd051aa0ae7780631d5bec5b7d01faac4a83a0
This class should have lived in services.jar. When I introduced
LazyIntToIntMap [1] to re-enable cross-profile use of spell checker
APIs, I unnecessarily put this class in frameworks.jar despite the
fact that this utility class is used only in the system server
process.
This CL also makes this utility class package-private so that other
component will not accidentaly depend on it.
This is purely a mechanical refactoring. There should be no
observable behavior difference.
[1]: Ic046f832f203115106409a53418a5746eb6d4939
3f8c568883
Bug: 115516399
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: I9390ba11687e1db66d02fe1cdfb9ed59adde3768
This reverts commit 16703c4b47.
Reason for revert:
Just realized that this was not the best approach.
We could already make LocaleUtils package-private too before this CL.
So the right approach was moving these methods to new Java class(es)
instead of moving these methods to LocaleUtils.
Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I29c87b9692f0f5e8255835579e2fb5270bc6c9c3
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
This CL moves InputMethodManagerService (IMMS)
from com.android.server
to com.android.server.inputmethod
so that we can mechanically factor out inner classes from IMMS to
separate package private classes.
This is purely a mechanical refactoring of an implementation detail.
There should be no observable behavior difference.
Fix: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I023d8f2863601ee54f304988117d8ea750770f70
I forgot to update this JavaDoc in my recent CL [1] that moved
inputMethodClientHasFocus() from WindowManagerService to
WindowManagerInternal.
[1]: I20c618174d8279a9a57f458fb908235f452b2281
cf93f9a53f
Bug: 112722651
Test: compile
Change-Id: I46cc9dd7479cc178770098a7bb6f0785598db3cf
This CL re-implements the way to propagate user action on an IME to
InputMethodManagerService (IMMS) so that we can dynamically update IME
Subtype rotation list discussed as requested in Bug 7043015.
It turns out that my previous CLs [1][2][3][4] are unnecessarily
complex because I tried to monitor user behavior in the IME client
process rather than in the IME process. In the end, I ended up
introducing a sequence number protocol for the sake of performance
with a ton of complexity.
This could have been implemented in a much safer and simpler way by
sending user action signals from the IME process to IMMS, because
A. IME already knows when it switches to a new subtype. IME needs to
send a signal only once per subtype change. There is no need to
use sequence counter.
B. Malicious IME client is unable to disturb IME rotation list by
sending a fake signal because the IPC endpoint is no longer exposed
to IME client processes.
In case there remain some applitations that still call this hidden API
via reflection without gracefully handling exceptions, this CL keeps
InputMethodManager.notifyUserAction() as a stub method so as not to
break such applications.
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ce
[2]: I7f3e13a7226ef0dceee82b67e8a0d8536f7e9807
2a6a8d2fbb063c84e388c185402c4ca788618c72
[3]: I19ad8542659bc092b92ee13eb9f1d68ddd4b815a
b56c6c721fc01fba8e36632d8e28f5123831abc5
[4]: I03fa436df0a5e348b3f93170aab3a8ac5a7e1677
c21ccc151631663d71230a3c1c756d94b575ab9e
Bug: 113177698
Fix: 114159783
Test: Manually verified as follows
1. Build and flush aosp_taimen-userdebug
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open AOSP Keyboard settings
6. Enable "English (US)", "French", and "German"
7. Open SoftKeyboard settings
8. Enable "English (United States)", "English (GB)"
9. Open the Dialer app and tap the top edit field.
10. Make sure that the IME layout rotation order when tapping the
globe key will be updated only when you tap the keyboard to enter
some character.
11. Also confirm it with "adb shell dumpsys input_method" by checking
"mSwitchingController:" section there.
Change-Id: Icc1f9c7f530f0144ecfd460e86114e109ae0044e
