- 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
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
Currently, a velocity with a magnitude of (for example) 0.1 and a
negative sign will be displayed as positive 0.1 by the
FasterStringBuilder. This is because casting a float to an int makes it
zero, and the sign gets lost: (int)-0.1f = 0.
Add this sign here.
Bug: 112705257
Test: enabled pointer location, and manually generated some flings that
have negative direction and magnitude less than 1. Confirmed that the
velocity sign is displayed correctly.
Change-Id: I0d777e790d324739ce248d3e6b8e04692400d832
In Bug 77730201, we cleaned up a bunch of files so that only modules
inside framework/base depend on InputMethodUtils. This CL is a
preparation of a further hardening.
Just by moving two utility methods from InputMethodUtils to
LocaleUtils, InputMethodUtils is used only from
InputMethodManagerService and its direct dependencies. This allows us
to make InputMethodUtils package-private class to make sure anyone
outside our team is unexpectedly depending on InputMethodUtils in a
subsequent CL.
This is 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: Ie8cb198880a145a7b81d2bf1eae1531ac3614019
There was a small mistake in my previous CL [1].
What updateStatusIcon() takes is a resource ID for Drawable, not ID
for an integer value.
These @*Res annotations are still just hints for IDE and lint tools.
They are actually all @Retention(SOURCE) hence this kind of mistake
has no impact at run time actually.
This CL also adds the right annotation for corresponding methods in
InputMethodManager and InputMethodManagerService.
[1]: I995c4b922f91b94438c1292392b2c3030598594f
c7ca36845e
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Id7fd610c07643c79b8ec03efbda24b3dc0686844
This is one further step towards deprecating 8 IME APIs that were
accidentally defined InputMethodManager (IMM) instead of
InputMethodService (IMS).
With this CL, API calls to those 8 deprecated ones in IMM will be
forwarded to IMS so that we can completely remove corresponding IPC
methods from IInputMethodManager.aidl. This guarantees that processes
that have no InputMethodService running there become unable to access
IPC methods behind such IME APIs that are intended to be used only
from IMEs.
One tricky thing is that the following 4 public APIs have been allowed
to processes that have WRITE_SECURE_SETTINGS permission, even if such
a process does not have active InputMethodService.
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
In general, user mode apps should not have WRITE_SECURE_SETTINGS
permission. Thus it might be not that difficult for us to simply
deprecate such a special rule. Bug 114488811 is tracking that effort.
For now, this CL preserves the existing behavior when a null IME token
is specified to those 4 APIs.
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: If762714b2003fa6477e1318110f63e13968c1d7e
This is a follow up CL to previous CLs [1][2][3] that made sure that
APIs that are exposed only to IMEs should live in InputMethodService
instead of InputMethodManager.
Now that we have a dedicated Binder inferface [4] that allows
InputMethodService (IMS) to directly send IPCs to
InputMethodManagerService (IMMS) without relying on
InputMethodManager (IMM), it is natural for the above public APIs in
IMS to stop relying on IMM.
This CL also addresses a small concern that it is no longer obvious
when those APIs become available. Previously, it was a bit more
obvious that passing null IME token doesn't work so IME developers
could imagine that those APIs were unavailable until attachToken() is
called.
With this CL, InputMethodPrivilegedOperations starts showing warning
messages when called too early, which we hope help IME developers
understand why those APIs do nothing when called too early.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
[2]: If6a786c5774805d041ea9672ef2721e4a38df7fc
fbc2f7acd5
[3]: I6efd5ca473e33e6faeadb7eea7772b9d2b8ca12b
164cfba536
[4]: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
c54c117164
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I995c4b922f91b94438c1292392b2c3030598594f
This is a mechanical refactoring to split out boilerplate code around
IPCs from InputMethodManager to another file.
Bug: 114418674
Bug: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I9ca251482867daea84c2777f74fd9b8a2b0f29cd
In full backup, we backup additional metadata about the app
(manifest, widget, apk, obb) not specified by the app's backup agent.
This CL extracts these methods out to their own helper (AppMetadataBackupWriter)
and adds unit tests for these methods.
** Note: The backup behavior is the same, only the structure has changed.
Behavioral changes will be done in future CLs. **
What this CL covers:
- Move the backup of this extra app data out of the FullBackupEngine to
separate agent data backup and non-agent data backup.
- Move logic of deciding what data to backup from FullBackupEngine to
FullBackupRunner (where the writer is used).
- Add unit tests for metadata backup.
- Some style fixes/clean up.
Not covered (future CLs):
- Refactoring FullBackupEngine/FullBackupRunner mechanism.
- Streaming backup data directly instead of writing to temporary files.
- Separating out and fixing apk and obb backup.
Bug: 110081582
Test: 1) atest AppDataBackupWriterTest
2) atest RunFrameworksServicesRoboTests
3) atest GtsBackupHostTestCases
4) Verify success for:
- adb shell bmgr backupnow <full backup package>; adb restore 1 <full
backup package>
- adb backup <full backup package>; adb restore
- cloud backup and restore
5) Use local transport and adb backup to inspect manifest and widget data
written and file metadata consistent between runs.
6) Verify compatibility with adb backup -keyvalue manifest
Change-Id: Icb43fd2e0505c2416738ee3ef370b206363fac68
