Currently ACTION_DOWN and ACTION_SCROLL cause
entering touch mode regardless of the event source.
This is especially awkward for mouse.
This should only happen when the event source is
SOURCE_TOUCHSCREEN.
Bug: 35314124
Test: android.cts.view.ViewTest#testTouchMode
Change-Id: I2205d4240be4afcbd9a3ac5558e701f7cac51926
This cl also updates label strings, renames an internal method,
and fixes some bugs in TextClassifierImpl caught by tests.
Test: See: I31ee94177e58c986e61e9b24c6c5816fa4b022e1
Bug: 34778263
Bug: 34922928
Change-Id: Ibf60d345d462dfc8a13dead6f01053f1ae50f35a
For processes with a window of type TYPE_APPLICATION_OVERLAY adjust their
oom importance to PERCEPTIBLE_APP_ADJ to reduce the chance of them getting
killed by the low-memory-killer since they are displaying something that
is perceptible to the user.
Also z-order TYPE_DREAM windows above alerts windows.
Bug: 33256752
Test: cts/.../run-test CtsAppTestCases android.app.cts.AlertWindowsTests
Change-Id: I4c05a9fee6fad61399bf4d10c8647467cc596ca6
Doing this allows us to annotate integer values that should corresponds
to WindowManager.LayoutParams#softInputMode.
Test: There should be no behavior change. RetentionPolicy.SOURCE
annotation should change nothing in production code.
Test: checkbuild
Bug: 32784563
Bug: 35079353
Change-Id: I96300b090edce327d0515c740183abe91ded6bac
A field in WindowManager.LayoutParams softInputMode is something that
definitely needs to be kept tracking in historical debugging
infrastructure across IME-related processes (Bug 35079353) [1]. As a
preparation, this CL enables InputMethodManagerService (IMMS) to
include the last softInputMode specified in IMMS#windowGainedFocus()
in the dumpsys in human readable format.
[1]: As explained in b.android.com/224318, softInputMode misspecified
by app developers is a typical root cause of unexpected behavior
in keyboard visibility. Bugs such as Bug 23168250, Bug 27275709,
and Bug 31770400 fall into this category.
Test: `adb shell dumpsys input_method | grep softInputMode=`
Bug: 35079353
Change-Id: I485ced030def179dad78b4b811c6eb52b5e5c951
Currently a default scrollbar is fairly hard to grab with
a mouse as it is sometimes as narrow as 8dp.
Introduce a larger touch target configured by
config_minScrollbarTouchTarget
Bug: 35114313
Test: manual
Change-Id: Ib15b24e5a82ea912ec5837d965319b758b4d9b6b
Bug: 35244501
Test: Ran Accessibilitiy CTS. I can no longer get the test mentioned
in the bug to fail.
Change-Id: I69e5e1b5c8f12226837ced928fbd10ff77bcd235
This CL sets the behavior for displays when they are removed.
For public displays by default all content will be moved to the
primary display and become focused. For private displays default
behavior is to destroy all content - first it moves stacks from
the secondary display to the primary display to the bottom, then
it destroys all activities in those stacks.
This CL adds two specified behaviors as modes, so in future these
rules might be altered if needed.
Bug: 34263289
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testContentDestroyOnDisplayRemoved
Change-Id: I3f89f06ff82cb4b487df58a86ba3b146a32cbd00
Package change from android.text to android.view.textclassifier.
This change was delayed until the native library code was updated
to reflect this package change.
Test: cts-tradefed run cts-dev -m CtsViewTestCases -t android.view.textclassifier.cts.TextClassificationManagerTest
Bug: 34777495
Change-Id: I723aaf79f8fbed4758bb4ee6727dfb6a8e35bf99
Clickable now implies focusable by default. While views are
only supposed to be modified on the UI thread, before O
this wasn't enforced when setting a view as clickable. Now,
it is enforced by virtue of clickable setting focusable for
auto-focusable views.
In order to prevent crashes, detect this situation for pre-O
target-sdks and skip notifying parents of a view made
focusable if:
- it was made focusable by the new auto-focusable mechanic.
- and this is occuring off the UI thread.
The net result in these cases will be a newly-focusable view
that won't immediately receive focus if it was supposed to
(though this will be exceedingly rare).
Bug: 34815147
Test: Verified that the crashing app in the bug (JWLibrary)
doesn't crash after this change.
Change-Id: I90e9a082cb1e1a3fec75ae5159f2f2c8540ffdc2
- Never display AutoFillValue.text, because it could be sensitive.
- Simplified AutoFilllId.
Fixes: 35171960
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I0853cabb695b842c947b0ae007e344f5d8385395
As explained in the commit message of my previous CL [1], we have
had a design issue in how to notify the full-screen mode change
from the IME to InputMethodManager running in the target application.
Histrically we have done this by using hooking the following IPC
from the IME to the target application.
InputConnection#reportFullscreenMode()
However, since we also want InputConnection to be deactivated in some
situations such as the when the target application is no longer
focused. In other words, InputConnection is not a reliable way to
notify something.
As a result, we have suffered from many stale state issues.
Bug 21455064 and Bug 28157836 are such examples. In Android N, we
introduced yet another hack to work around those issues, but it is
really time to fix the protocol design instead.
The new strategy is to rely on internal IPCs provided by
InputMethodManager to deliver such critical notifications from one
process to the other. This is actually more natural because our goal
is to make sure that InputMethodManager#isFullscreenMode() always
returns the latest value as long as the caller is the focused
application.
For backword compatibility, applications that are monitoring
this callback should continue working, as InputMethodManager emulates
the previous behavior. However, as updated in JavaDoc, IMEs are no
longer allowed to invoke InputConnection#reportFullscreenMode(),
which should be OK because even on previous releases IMEs should rely on
InputMethodService#updateFullscreenMode() instead.
[1]: Iba184245a01a3b340f006bc4e415d304de3c2696
1544def0fa
Fixes: 28406127
Test: Make sure Bug 21455064 is still fixed.
1. Input some words in extract mode.
2. Select a word.
3. Perform copy.
4. Select a word.
5. Rotate the device.
6. Try to select a word.
7. Make sure he word is selected and action mode starts.
Test: Make sure Bug 28157836 is still fixed.
1. Rotate device to landscape mode.
2. Tap on EditText and start full screen extracted mode.
3. Rotate device to portrait mode.
4. Long press to start action mode.
5. Make sure Action mode gets started.
Test: `adb shell dumpsys input_method` to make sure that fullscreen
state is synchronized across the app, IMMS, and the IME.
Change-Id: If23e7c7c265ab3dfb48c2fb6fdb361b17d22c594
VirtualViewDelegate was used by views providing virtual children to:
- auto-fill the chidren
- notify system about children changes
Since the notification logic moved to the AutoFillManager class, it's
kind of an overkill to provide a delegate just for autoFill(); instead,
it's simpler to add a new autoFillVirtual(virtualId, value) method on
View.
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: Ia7670aa665918496a009017a11c3de72c4ed3fa2
ViewStructure.newChild(virtualId) uses the AutoFillId of the parent,
which was not set anymore due do a previous refactoring, and was
causing this method to crash a custom view when
onProvideAutoFillVirtualStructure() was called on it.
Test: manual verification
Bug: 31001899
Change-Id: I602b421b0ec3a926ffdd52253d5b2498c4217d02
Existing apps have copies of ListView behavior that expects the old
hasFocusable behavior of only reporting explicitly focusable views.
Use targetSdkVersion to give the old behavior to existing apps.
Add hasExplicitFocusable method to View to offer the old behavior
to apps that need it. ViewCompat method required in support library
to shim through to hasFocusable pre-O.
Bug: 34946284
Test: CTS
Change-Id: I65503fa2c5fe4cb8b635efa464e653bbf5e7f821
Before this, CTRL was the default modifier for MenuItem shortcuts.
Now, It's possible to specify the modifier in XML or via MenuItem
methods.
The modifier list includes META, CTRL, ALT, SHIFT, SYM and FUNCTION.
WIP on support library implementation
Bug: 32165848
Test: Run the tests using following commands:
> cts-tradefed run cts-dev -m CtsViewTestCases -t
> android.view.cts.MenuTest#testPerformShortcut
> cts-tradefed run cts-dev -m CtsViewTestCases -t
> android.view.cts.MenuInflaterTest#testInflateShortcutModifiersFromXml
Change-Id: I7db4607d4657451934761914efe4c250de109653
- #1: Move logic for handling IME size changes into SysUI, and only rely
on PinnedStackController to provide bounds when first entering
PiP and on rotation
- #2: Doing #1 allows us to move PipMotionHelper to SysUI completely, which
lets us aggregate the animation calls out of PipTouchHandler
- #3: Add proper callbacks to the listeners when the movement bounds
changed from config change, ime change, or aspect ratio change. This
allows SysUI to calculate the associated movement bounds for the
expanded state, and we can then remove the corresponding WM call.
It also means that SysUI is the only thing that needs to know about
the expanded state.
- #4: Fix issue where TV was getting the default bounds, not taking the
aspect ratio when the PiP was entered into account. Doing #3
allows us to report the right bounds.
- #5: Remove dead code related to edge snapping/minimizing now that they
are on by default and associated tuner setting, and controller
callbacks
Test: android.server.cts.ActivityManagerPinnedStackTests (all existing tests pass)
Change-Id: I3ef361bdf8d44094b4c0a11c70ba4db7d697fdec
Signed-off-by: Winson Chung <winsonc@google.com>
This is yet another big refactoring:
- AutoFillManager keeps track of its current AutoFillSession.
- Views call AFM.startSession(View) when they can trigger autofill.
(virtual views can call it as well). At this point, the manager
sets an AutoFillSession, gets the activity token, and passes it to
the service.
- Subsequent calls to AFM.start() will be ignored since the session
is set.
- When the Activity is gone, it calls AFM.finishSession().
- Simlilarly, virtual views could call it as well.
- Added getAutoFillValue() to View.
- Removed AFM.updateAutoFillInput(childId): virtual views should now
call startSession(childId) to start a session, and use the
VirtualViewListener callbacks for updates.
- Change AutoFillValue to use String (which is immutable) instead of
CharSequence for text values.
- Check if view is enabled before auto-filling.
- Removed 'cmd autofill fill' since it would require the appCallback
- Automatically dismiss the snack bar after 30s
- Moved the "don't change autofill value when autofilling" Inception
logic into the service side.
- Etc...
BUG: 34819567
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I5fad928d4d666701302049d142026a1efa7291cd
This allows an AccessibilityService to set a flag in its
AccessibilityServiceInfo that triggers the navigation bar to show an
Accessibility Button and observe callbacks when the button is clicked
or there are changes in the visibility of the navigation bar.
Test: Manual (Created a sample AccessibilityService) + CTS
Bug:29231271
Change-Id: I03d653d85bc37df28ed71d8bba94b7c75fe56e43
