LocalImageResolver should not upscale the image if it's already smaller than the maximum width.
Bug: 228719813
Test: atest LocalImageResolverTest
New test failed before change / passed after change
Change-Id: I4fc09d1955fe94159cf0e2e8125044712f3c3134
Currently, IMMS will be notified asynchronously when an IME hide
animation finishes, via message dispatching through IMS
(IMM#notifyImeHidden -> IMS#notifyImeHidden -> IMMS#hideMySoftInput).
This creates a race condition when IMM#showSoftInput or WIC#show is
called around the end of hide animation.
This CL fixes the race condition by synchronously and directly
calling IMMS#hideSoftInput from IMM#notifyImeHidden.
Note that there is still another race condition for IMM#showSoftInput
(not WIC#show) if it's called during an IME hide animation;
IMM#showSoftInput ended up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I will fix the latter issue in a separate CL.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
Bug: 210453009
Test: manual test on local phone
Test: atest ChooserActivityTest
Change-Id: Ibcc83037ca801ee0ecf2306eae954677529fa849
(cherry picked from commit 6393225873)
Merged-In: Ibcc83037ca801ee0ecf2306eae954677529fa849
The helper methods provided by this class have been unused
since ag/13807667 (part of removing the old ChooserTargetService
functionality).
Test: http://cs/search?q=chooserutil&sq=package:android-internal
Bug: 148416928
Change-Id: I0aaaa5f597ef72097f1847a3187b335791287a60
Merged-In: I0aaaa5f597ef72097f1847a3187b335791287a60
This just requires a few parameter changes to align with Launcher
(iconloaderlib), as proposed by digman@ in b/196631965.
Bug: 196631965
Test: asked digman@ to approve a screenshot.
Change-Id: Icca36fe8c5771041bea960478c2be85f0679dc8d
Merged-In: Icca36fe8c5771041bea960478c2be85f0679dc8d
We have intentionally not exposed "composition" related APIs to
A11yIME to minimize the problem space of concurrent text editing
between the real IME and A11yIMEs. To make this model more
predictable and reliable, it is planned to finish any existing
composing text when
AccessibilityInputConnection#commitText()
gets called. This CL actually make it happen.
Fix: 218749467
Test: Manually verified with sample A11yIme as follows.
1. Build aosp_coral-userdebug and flash it.
2. make -j EditTextVariations
3. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/arm64/EditTextVariations.apk
4. make -j SampleInputMethodAccessibilityService
5. adb install -r $OUT/system/app/SampleInputMethodAccessibilityService/SampleInputMethodAccessibilityService.apk
6. adb shell settings put secure enabled_accessibility_services com.example.android.sampleinputmethodaccessibilityservice/com.example.android.sampleinputmethodaccessibilityservice.SampleInputMethodAccessibilityService
7. adb shell am start -n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
8. Tap the top edit field.
9. Make sure that AOSP Keyboard shows up.
10. Type "abc" with AOSP Keyboard.
11. Hit "A" button on the sample A11yIME.
12. Make sure that the text becomes "abcA".
Change-Id: I4afd279d8bc1a04d4e52ccb947dc28aed8f891f0
This is a follow up CL to our previuos CL [1], which enabled
AccessibilityService to use a subset of InputConnection APIs.
In that CL we have reused existing AIDL interfaces that were designed
and maintained for IMEs for simplicity, where a non trivial amount of
unnecessary IPC endpoints were included.
From the security and maintainability viewpoints, however, exposing
unnecessary IPC endpoints is discouraged in general. To address such
concerns this CL introduces a set of dedicated IPC definitions for
A11yIME so that we do not need to reuse IPCs for IMEs.
This CL also stops passing InputBinding object to A11yIME process as
it contains IInputContext Binder Proxy, which can still be used to
directly invoke fallback InputConnection. This is doable now because
A11yIME no longer relies on fallback InputConnection [2].
This CL is should not have any observable changes in the semantics.
End-to-end CTS tests guarantee that everything is still working as
intended now and in the future.
[1]: Ia651a811093a939d00c081be1961e24ed3ad0356
fb17e5ae7a
[2]: I2af3cd50444d8ddf25aa0f6479238156914e6fff
dc635efb68
Fix: 215633021
Fix: 215636776
Test: atest CtsInputMethodTestCases:AccessibilityInputMethodTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityInputConnectionTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityImeTest
Change-Id: I5ff2e804cbcf90828370a0612ff54111130bdff4
Before the new insets system, a window wouldn't receive visible insets
if it:
- has FLAG_LAYOUT_NO_LIMITS,
- is not TYPE_WALLPAPER or TYPE_SYSTEM_ERROR, and
- is not in multi-window mode.
This CL makes the visible insets compatible with the legacy insets
system.
Fix: 223536648
Test: atest InsetsStateTest
Change-Id: Ia73142cfae701d0532a9a397366c50aeef82abb2
(i.e., in AppPredictionServiceResolverComparator)
This is believed to be a pure refactoring; no behavioral changes.
This is relatively simple compared to the ongoing cleanup of the
other comparator (e.g. in ag/17697713) because the AppPrediction
comparator already used simple immutable model data. This should
be more clear after this CL, which shows that the updated model
instance is derived from the sorted list we receive from the
service, along with immutable data that was provided when the
AppPredictionServiceResolverComparator was initialized.
The only parts that remain in the legacy ...ResolverComparator
code are responsible either for fetching the model data from the
remote service (which uses a somewhat sloppy/ad-hoc concurrency
model that should be cleaned up in a future CL as part of removing
the AbstractResolverComparator's Handler design), or for implementing
a fallback to use a ResolverRankerServiceResolverComparator if
there's a problem with the AppPredictionService (which should also
be cleaned up in a future CL, since the AppPredictionService
comparator really doesn't need to take on ownership responsibilities
for some completely different model).
Note that this CL also removes the bookkeeping of mTargetScores
(including the `checkAppTargetRankValid()` method) because it
wasn't used for anything.
Test: atest ResolverActivityTest ChooserActivityTest
Bug: 227486788
Change-Id: I419a73bf094c14276b0c5791edacaa27797b215c
* changes:
[automerge] Fixed status bar glitch for apps that access internal res 2p: 71eaca7ede 2p: acf060e065
[automerge] Fixed status bar glitch for apps that access internal res 2p: 71eaca7ede
Fixed status bar glitch for apps that access internal res
