| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to my previous CL [1], which introduced a
hidden callback method into Window.Callback.
This CL does not change any observable behavior but consolidate that
hidden callback into a newly introduced Window.DecorCallback
interface. In this approach, we no longer need to worry about
accidental method name collision in Window.Callback implementations
classes.
Here is the new callback chain.
ViewRootImpl#performTraversals()
-> DecorView#onSystemBarAppearanceChanged()
-> Window.dispatchOnSystemBarAppearanceChanged()
-> NavigationBarController.Impl#onSystemBarAppearanceChanged()
[1]: I08566034bebfafff6777ce0152cd6ca1f66f6cad
678ddce11c131a8e6746fe386c40ddc8d99d01c3
Bug: 215549533
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
12. Make sure that the navigation button color is optimized for light
navigation bar.
13. Tap "STANDARD LIGHT NAVIGARION BAR" mode
14. Make sure that the navigation button color is optimized for light
navigation bar.
Change-Id: I5168f76dfc9526e925c565dbfa87597b5543fcdc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to propagate the information about whether the IME is using
light navigation bar or not from
android.view.ViewRootImpl
to
android.inputmethodservice.NavigationBarController
within the same process, this CL adds a new @hide method to
Window.Callback
as follows.
ViewRootImpl#performTraversals()
-> DecorView#onSystemBarAppearanceChanged()
-> Window.Callback#onSystemBarAppearanceChanged()
-> SoftInputWindow#onSystemBarAppearanceChanged()
-> NavigationBarController#onSystemBarAppearanceChanged()
Button color transition will be implemented in a subsequent CL.
Bug: 215549533
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
12. Make sure that the navigation button color is optimized for light
navigation bar.
13. Tap "STANDARD LIGHT NAVIGARION BAR" mode
14. Make sure that the navigation button color is optimized for light
navigation bar.
Change-Id: I08566034bebfafff6777ce0152cd6ca1f66f6cad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to my previous CL [1], which made it clear that
the following 4 tracing fields in SoftInputWindowProto had always been
logged with the same values.
- name: "InputMethod"
- window_type: WindowManager.LayoutParams.TYPE_INPUT_METHOD
- gravity: Gravity.BOTTOM
- takes_focus: false
This CL simply deprecates those fields in favor of simplicity and
smaller code size.
There should be no behavior change unless IME tracing is enabled.
[1]: I619ae6011f5e66dba126931719569a97513eaa7e
ea7801bd267f98fba10741b88bc900aef9f84121
Bug: 192412909
Test: IME tracing still works
Change-Id: I04b59307ecf2c692282c7882ac839f77c94b938f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL merges
SoftInputWindow#initDockWindow()
into
InputMethodService#onCreate()
so that we can see what parameters are set to the IME window at a
glance, rather than having to check 2 different files.
The end result is expected to be the same, and in theory there should
be no observable behavior change.
If you are reading this commit message to look for why those
parameters have been set, here are some quick links to relevant CLs.
* `FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS`
- DecorView#mNavigationGuard is gone [1]
* `window.setDecorFitsSystemWindows(false)`
- Updated InputMethodService to not inset by navigation bar if
requested by automotive. [2]
- Smooth out IME animation for automotive devices [3]
* `setFitInsetsTypes(statusBars() | navigationBars())`
- Do let IME fit invisible insets [4]
* `setFitInsetsSides(Side.all() & ~Side.BOTTOM)`
- Make IME fit navgation bars at left and right sides [5]
* `receiveInsetsIgnoringZOrder = true`
- Let IME receive insets ignoring z-order [6]
[1]: I664630099b6eb3fe31675444ba94944cb0eb98b0
8f162c6e846ac99d6aac4473d7903722e9d6e54b
[2]: I4faf82bdd7536bd2d049ded04034a9635d8ca0d3
7eec316f54e22237f92a2808a3a2f9356229335d
[3]: I5d7b03d5c829a2679efdd06fa961d1158494e08f
b0d0d7c46ab0425431912d2e03cc620be657a969
[4]: I6e7d665c55839dfbb14c8d2e5365537416f5f6c6
145f71182ab1c1e0be4f128683c97403c97d2696
[5]: I0ef3d6379a9ae52b3749154d2fdc54e9aa94a9e0
c8364e3878aa8e0f9e8dda1bd5305c5ef7eeada0
[6]: I53c64a5598f246ad577f652156903e4666a30cd9
ea491da863774457299ffd5f2534dc2ba4d3ba52
Bug: 192412909
Test: presubmit
Change-Id: If0f2bac45e6752612cc11e57d2fac55626221bd1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that SoftInputWindow is used only by InputMethodService [1], we
can safely simplify SoftInputWindow.
This is still mechanical refactoring. There should be no observable
behavior change.
[1]: 5ed8dae6bc9cca87d5f35e781f173477a2388c2e
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I619ae6011f5e66dba126931719569a97513eaa7e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanical refactoring CL as a preparation to remove the
dependency on
android.inputmethodservice.SoftInputWindow
from
android.service.voice.VoiceInteractionSession.
Before creating a copy of SoftInputWindow for VoiceInteractionSession,
this CL aims to clean up lint errors and style nits as many as
possible, notably:
* Addressing lint errors
* Adding missing @Override
* Making SoftInputWindow a final class
* Making internal member fields private
* Removing SoftInputWindow#{get,set}Gravity(), which are no longer used
* Renaming SoftInputWindowState to WindowState
There should be no observable behavior change in this CL.
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I547489d3946bf523a59ada80f63cfd934e70c1f4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL implements a mechanism to dump InputMethodService and IME
related server states into a proto file which can later be imported
to Winscope to allow easy debugging.
The Design Doc for the IME tracing project is: go/ime-tracing
Bug: 154348613
Test: start trace by calling "adb shell ime tracing start"
end trace by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace.pb ime_trace.pb"
Change-Id: Icbfb8c11e882f29eb45dea9d4c23315c48e9d619
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's useful for apps to know which inset types they can currently
control, as otherwise they have to poll by calling
controlInsetsAnimation repeatedly.
This can be used when apps want to apply a custom animation
immediately during startup as soon as possible.
Fixes: 150780468
Test: InsetsControllerTest
Test: CTS will be added soon
Test: WindowInsetsActivity
Change-Id: Ic0388c11d759843d3ac9edd8ef23904c9ce05c46
|
| |
|
|
|
|
|
|
| |
by automotive.
Bug: 147155538
Test: Manual
Change-Id: I4faf82bdd7536bd2d049ded04034a9635d8ca0d3
|
| |
|
|
|
|
|
|
|
| |
This feature is configurable and set to false as the default value. It
is overlayed as true for Automotive.
Bug: 138242566
Test: manual
Change-Id: I5dde8adc9d4ce749d895287ccf63017b284caec8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several java files had the typo {#link (for cross-references to other
Javadocs) instead of the proper {@link format. This was confusing the
new doc publish tool (Mivi) since that's the format used for {# Django
comments #}.
Fixed a couple of links that had other errors (which prevented building
once the {# -> {@ was done) and other typos.
Replaced throughout the frameworks/base project; I'll need a separate CL
for the AndroidX fixes.
(Other files were not in the public Javadocs.)
Bug: 111925950
Test: make ds-docs
Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Original Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Exempt-From-Owner-Approval: Docs-only change
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After several attempts [1][2], this is our latest attempt to
gracefully ignore BadTokenException an IME that is being destroyed is
still handling pending showSoftInput() requests.
The point is that SoftInputWindow is a hidden API. This means that
instead of adding a bunch of try/catch blocks around mWindow.show() in
InputMethodService we can always override SoftInputWindow#show() to
inject our own code around mWindow.show().
With this CL, we can now fully track the internal lifecycle of
SoftInputWindow in SoftInputWindow#mWindowState. It enables us to
easily sort out cases like double fault cases discussed
in Bug 113159114, where showSoftInput() requests were queued multiple
times and still IMEs crash because what mWindow.show() throws for
the 2nd failure is IllegaStateException not BadTokenException.
[1] Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135
6fcbb5629019489a88a9748f278d40d554cc5cdc
[2] I2c21573cf972145ab08e66604cdb9344139a3f31
e4bbb1cc451c7ebdad9f92968732fc4f6c21a70c
Fix: 113159114
Test: Manually verified IME switching scenario 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 the Dialer app and tap the top edit field.
6. Make sure that AOSP Keyboard is shown.
7. Tap the globe button on AOSP Keyboard.
8. Make sure that AOSP Keyboard is dismissed and SoftKeybaord is
shown.
9. Tap the globe button on SoftKeybaord.
10. Make sure that SoftKeybaord. is dismissed and AOSP Keyboard is
shown again.
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I1f51ed29df6b22b003ca285698e06b8f3ee5106a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is now a special theme for voice interaction activities
to use, so they can be a panel that is better intergrated with
the rest of the voice interaction experience. This is still
not completely working, I have some hacks in the demo app to
get it right; I'll fix that in a future change.
Also improve VoiceInteractor to be retained across activity
instances, for things like rotation.
And bump up the number of concurrent broadcasts that are allowed
on non-svelte devices, since they can handle more and this makes
the boot experience better when dispatching BOOT_COMPLETED.
Change-Id: Ie86b5fd09b928da20d645ec2200577dee3e6889d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes VoiceInteractionSession a more first-class
concept. Now the flow is that a VoiceInteractionService
calls startSession() when it wants to begin a session.
This will result in a new VoiceInteractionSession via the
VoiceInteractionSessionService containing it, and the
session at that point an decide what to do. It can now
show UI, and it is what has access to the startVoiceActivity
API.
Change-Id: Ie2b85b3020ef1206d3f44b335b128d064e8f9935
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- IME service now switches between visible and perceptible depending on
whether it is being showm, allowing us to more aggressively free its
memory when not shown.
- The activity display time is no longer delayed by the activity
transition animation.
- New -R (repeat) option for launching activities with the am command.
- Improved some documentation on Loader to be clear about some methods
that apps should not normally call.
- FrameworkPerf test now allows you to select individual tests to run.
Change-Id: Id1f73de66dc93d63212183958a72119ad174318b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the concept of pointer properties in a MotionEvent.
This is currently used to track the pointer tool type to enable
applications to distinguish finger touches from a stylus.
Button states are also reported to application as part of touch events.
There are no new actions for detecting changes in button states.
The application should instead query the button state from the
MotionEvent and take appropriate action as needed.
A good time to check the button state is on ACTION_DOWN.
As a side-effect, applications that do not support multiple buttons
will treat primary, secondary and tertiary buttons identically
for all touch events.
The back button on the mouse is mapped to KEYCODE_BACK
and the forward button is mapped to KEYCODE_FORWARD.
Added basic plumbing for the secondary mouse button to invoke
the context menu, particularly in lists.
Added clamp and split methods on MotionEvent to take care of
common filtering operations so we don't have them scattered
in multiple places across the framework.
Bug: 4260011
Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
|
| |
|
|
|
| |
Bug: 3238092
Change-Id: I92d98bed75957c8db149e1ad87defe24d44f4d53
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
