There will be, in the future, a flag (View.DRAG_FLAG_GLOBAL) that means
for the drag to be cross-application. For now that flag constant is @hide
and furthermore the server-side implementation strips it, enforcing
local-only drags.
Change-Id: I8db840480ab90e18a5b8ecf29d62b4e6eafd405e
This change implements two heuristics.
1. When events are older than 10 seconds, they are dropped.
2. If the application is currently busy processing an event and
the user touches a window belonging to a different application
then we drop the currently queued events so the other application
can start processing the gesture immediately.
Note that the system takes care of synthesizing cancelation events
automatically for any events that it drops.
Added some new handle types to allow the native dispatcher to
indirectly refer to the WindowManager's window state and app window
token. This was done to enable the dispatcher to identify the
application to which each window belongs but it also eliminates
some lookup tables and linear searches through the window list
on each key press.
Bug: 3224911
Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
When IME is being moved as part of a window going away, it could flicker
as it immediately moves behind the window. Fix this.
Also make the default soft input mode for PopupWindow to be to not change
the IME visibility, since it is a rare pop-up window that should cause your
IME to close.
Change-Id: I0b43e080ad012739e9a3e5842794c778c859ac1a
This fix improves the performance by caching the string that should
be returned, and reuse it next time if possible.
This will make it faster to switch between activities, approximately
half the time to create the new view when changing from landscape to
portrait. Also, the time for starting a new application is be reduced
as WindowState.toString is being called thousands of times in this
case.
Change-Id: I2b8b9bc1e251d1af43b6c85f049c01452f2573a2
To make a 800 tall screen run like a 720:
adb shell setprop persist.demo.screensizehack 800=720
Note this is a persistent property, so it will (intentionally) remain across boots.
Change-Id: I8a8a9f937399327444e8fb154b91f0e642db116e
Also issue #3281400: Rotating a retained instance fragment leaks the fragment manager
And turn off fragment debug logging.
Change-Id: Ibdd7db82bb35618021bcba421ba92ced7cd691c2
Also know as:
Issue #3272051 Contacts edit view: Tapping the in-app back button
results in a forward transition
Yeah more complexity in deciding which animation to use.
Also reduce complexity in deciding which app's animation set to use,
to balance things out (and make it have less stupid behavior).
Change-Id: I78c6c5c5249a96206f7e03ce587c1dcb9a7dc14f
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
This change enables the framework to synthesize key events to implement
default behavior when an application does not handle a key.
For example, this change enables numeric keypad keys to perform
their associated special function when numlock is off.
The application is informed that it is processing a fallback keypress
so it can choose to ignore it.
Added a new keycode for switching applications.
Added ALT key deadkeys.
New default key mappings:
- ESC -> BACK
- Meta+ESC -> HOME
- Alt+ESC -> MENU
- Meta+Space -> SEARCH
- Meta+Tab -> APP_SWITCH
Fixed some comments.
Fixed some tests.
Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
This patch allows users of WindowManagerService.injectKeyEvent() to
set flags on the key event being injected.
In particular this allows long presses (FLAG_LONG_PRESS) to be
injected into the window manager.
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
ViewRoot now does a fade animation between a snapshot of the previous
layout to the new one when its content rect changes.
Also tweaked some things in the window manager to fix problems in
deciding when to animate the movement of a window and when not to.
Change-Id: I9b4b3bd53c8258bd39a2f2fc315e77cfc56a409c
The ShortcutManager used to only receive the key code of the key event
that triggered the shortcut. This change now provides the shortcut
manager with the whole key event so it can look up the associated
character using the correct key character map.
To make this more efficient, added a mechanism for recycling
key events. At the moment it is only used by key events owned by the
system process, since clients of the existing API (such as Views)
might continue to hold on to key events after dispatch has finished so
they would break if the key event were recycled by the framework.
Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD.
Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
This introduces a small new feature for ScaleAnimation allowing
the scaling factor to be expressed as a percentage of the object
(which is the same as the existing float interpretation), a
percentage of the container, or a fixed dimension. Maybe not
useful for anything else, but I needed it for this.
Also fix a bug in how transformation matrices were propagated
from the Animation to Surface Flinger, so that rotate and skew
animations will actually work. :p
Change-Id: I301f4caa2147aa35564b5e511cb9c0b368d2425d
Lots of work for no visible change in behavior, but now we can
do some fancier stuff...
Also allow rotation in all 4 directions.
Change-Id: I7e5e9537c5e359f69b83c10f65cc1ce95f371461
Also make the dim fade duration configurable, with a configured value
that more closely matches what UX wants.
Change-Id: Id32e2de14a2a2003d8fade6331377d8d723ac397
Now try to slide dialogs if they end up moving due to the IME (or
other system things) showing/hiding. Pretty hackish, but seems to
work.
Change-Id: Icd297e941cf847fa920c9605145c46be63043d52
We now decide whether to use a bitmap background based on whether the
window's drawing is hardware accelerated. To do this, there is a new
"state_accelerated" that state list drawables can be parameterized on,
and the standard window background uses this to select a solid color
or bitmap drawable as appropriate.
Introduces a little hackery to have wm preview windows pretend like
they are hardware accelerated even if they aren't, so the preview looks
closer to the actual app.
Also Add a DialogWhenLarge variation for the light theme.
Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
Refactored ViewRoot, NativeActivity and related classes to tell the
dispatcher whether an input event was actually handled by the application.
This will be used to move more of the global default key processing
into the system server instead of the application.
Change-Id: If06b98b6f45c543e5ac5b1eae2b3baf9371fba28
For possible future changes to android.view.animation.Animation to tie
into StrictMode's animation annotations on violations.
Change-Id: I3a23fa9bd5edb0500586bb0e341f83f998b28ae7
Who knew there were so many Loopers in the system server?
This adds dropbox logging for the activity manager thread, policy
thread, and window manager thread.
The goal's to catch more stuttering.
Change-Id: I999a6ff4a955f0ef549b12a38796b843ade5fe66
IWindowManager now supports two new methods,
freezeRotation() and thawRotation(), that allow a caller to
temporarily stash the device's current rotation as the
default rotation (when no other constraints are present).
The system bar uses this to implement a user-accessible
rotation lock by calling freezeRotation() and then turning
off accelerometer-based display rotation; unless overridden
by an app, the display will continue to appear in the frozen
rotation until the rotation is unlocked by the user (either
via the rotation lock icon in the system bar or by checking
"rotate screen automatically" in Settings).
Bug: 2949639
Change-Id: Icd21c169d1053719590e72401f229424b254622f
Who knew there were so many Loopers in the system server?
This adds dropbox logging for the activity manager thread, policy
thread, and window manager thread.
The goal's to catch more stuttering.
Change-Id: I3ce8518ce183b3c90426750a2992e67200fee5d5
Now, each ViewGroup is tracking which of its child views [which might
themselves be ViewGroups] is currently under the drag point, and when the
drag leaves that child, a DRAG_EXITED is synthesized and dispatched all
the way down to the leaf view previously under the point. ENTERED is
still *not* dispatched down like this; instead, it's calculated and
synthesized directly at each level based on the new LOCATION.
The ViewRoot still tracks the leaf drag target, but solely for the
purpose of reporting changes to the OS after full dispatch of a new
LOCATION -- the entered/exited messaging is no longer initiated at the
ViewRoot level.
Change-Id: I0089cc538b7e33a0440187543fcfd2f8b12e197d
Rewrote interceptKeyBeforeQueueing to make the handling more systematic.
Behavior should be identical except:
- We never pass keys to applications when the screen is off and the keyguard
is not showing (the proximity sensor turned off the screen).
Previously we passed all non-wake keys through in this case which
caused a bug on Crespo where the screen would come back on if a soft key
was held at the time of power off because the resulting key up event
would sneak in just before the keyguard was shown. It would then be
passed through to the dispatcher which would poke user activity and
wake up the screen.
- We propagate the key flags when broadcasting media keys which
ensures that recipients can tell when the key is canceled.
- We ignore endcall or power if canceled (shouldn't happen anyways).
Changed the input dispatcher to not poke user activity for canceled
events since they are synthetic and should not wake the device.
Changed the lock screen so that it does not poke the wake lock when the
grab handle is released. This fixes a bug where the screen would come
back on immediately if the power went off while the user was holding
one of the grab handles because the sliding tab would receive an up
event after screen turned off and release the grab handles.
Fixed a couple of issues where media keys were being handled inconsistently
or not at all, particularly in the case of the new PAUSE, PLAY
and RECORD keys.
Bug: 3144874
Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
Also make sure to properly dispose *both* ends of the drag input
channel when we're done. That was being tidied up after, but was
also making the system work harder and was provoking a bit of
debug logging.
Change-Id: I1ff3100bc4c441f1609c57242864d5744ff1aaa2
Part of issue #3116702: New manifest tags for supported screen sizes
Kind-of.
If you turn your head side-ways.
Change-Id: I446f1e2eadba1ce284c93ff9fb0197bb0e6b0fca
DragEvent.getResult() returns 'true' if the drop was ultimately accepted;
false otherwise. The validity of this datum is only guaranteed when the
DragEvent's action verb is ACTION_DRAG_ENDED.
Also fixes the drag-start timeout handling (though the offending app is
not yet officially declared ANR).
Implements bug 3097807
Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
* Increase the opacity of the drag thumbnail a bit
* Properly present window-local drag locations; this fixes drags into
the status bar
* Pass the current drag touch point in DRAG_STARTED. This may
be reconsidered, but might conceivably be useful to someone.
Change-Id: I77690e82e9831ed6be412990c1c9da92e700a501
Now sets the layer and thumbnail dimensions correctly. Also removed the
leftover bits of the now-replaced thumbnail measurement/drawing mechanism.
Fixes bug 3077339
Change-Id: I02983648e0a7ce2ce5fee10825f744e20a3a5b8d
