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
invalidateSelf() already exists on Drawable. This triggers a call to
callback listeners so that they know the drawable has been invalidated.
For example, the background drawable on View will cause the View itself
to be invalidated.
Change-Id: I45b231a7600dcf3bc139e4059b7c9940ff49f60c
GL renderer was not initializing scissor correctly for translucent
surfaces, resulting in invisible window backgrounds in some cases
like fading popup windows
Change-Id: I87a964986e1ba2c4f59708c8892c5fa71903e6fc
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
PhoneWindow to a new PhoneFallbackEventHandler class that is used
for all windows, not just ones with decors.
Bug: 3155146
Change-Id: Ib070fa3e523e3564b225bca576c08012fef4f416
request a layout when asking the transparent region to be recomputed, without this
it may never happen, since the transparent region is only calculated during layout.
this also fixes an issue where some fullscreen apps will run slower than expected
because their transparent region is never processed.
Change-Id: Iba187ef7b23f08ad3454aaa6707a3d262551e30c
Also add a new interface that items in AbsListView can implement to
adjust the bounds of the selection shown for them. This will allow
contacts to use list view's regular selection facility rather than
implementing something special in their item views.
Change-Id: I29cbdbc7122111ee97e47fe7d6ec55ff07be79cc
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
This is used to allow list view's pressed and activated indicators
to fade in an out, though of course it can be used elsewhere as well.
There is a lot of complexity in supporting this in list view. The
two main things that are being dealt with:
- When recycling views, we need to make sure that the view's drawable
state doesn't get animated from an old row's state. The recycler
now keeps track of which position a view was last in, and if it is
reused at a new position there is a new View/Drawable API to tell
it to jump to its current state instead of animating.
- For the pressed indicator to fade out, we need to keep displaying it
after it is hidden. There are new variables and code to keep track
of this state, and tweaks in various places to be able to remember
the last selected position and continue updating the drawable bounds
as needed.
Change-Id: Ic96aa1a3c05e519665abf3098892ff2cc4f0ef2f
The animator classes caused autoboxing by converting primitive types (by far
the most typical types used in animations) to be converted to their
Object equivalents because of various APIs that required Object
(like getValue() to get the animated value). This change creates
factory methods on some classes instead of the former constructors
so that we can create and return private type-specific subclasses
which operate directly on the primitive types instead.
In particular, float and int are natively supported by the animators
now. Support in the APIs for double and long was removed because it
seemed like these less common types did not justify the extra
baggage of the added API and code.
Change-Id: I6008a3883e3d6dd5225005f45f112af148e5a4ea
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
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
If the listener's onDrag(view, event) returns 'false', the view's own
onDragEvent() will be called. If the listener returns 'true', it
consumes the event (and declares that it will handle the rest of the
drag event sequence, in the case of DRAG_STARTED actions).
Change-Id: I01aff0e4f59f71e55f5eea1049905c80714f0607
Merge commit 'c1a564b108c511c0bdd699567c245b031930e718' into gingerbread-plus-aosp
* commit 'c1a564b108c511c0bdd699567c245b031930e718':
Add support for secure system overlays. (DO NOT MERGE)
Manual merge from Gingerbread.
This change adds a new window type for secure system overlays
created by the system itself from non-secure system overlays that
might be created by applications that have the system alert permission.
Secure views ignore the presence of secure system overlays.
Bug: 3098519
Change-Id: Id876736fd8bf332ff9a5428bde59f5268aa49c3a
This change adds a new window type for secure system overlays
created by the system itself from non-secure system overlays that
might be created by applications that have the system alert permission.
Secure views ignore the presence of secure system overlays.
Bug: 3098519
Change-Id: I8f8398f4fdeb0469e5d71124c21bedf121bd8c07
Added new key maps for external keyboards. These maps are intended to
be shared across devices by inheriting the "keyboards.mk" product
makefile as part of the device's product definition.
One of the trickier changes here was to unwind some code in
MetaKeyKeyListener that assumed that only the low 8 bits of the meta key
state were actually used. The new code abandons bitshifts in favor
of simple conditionals that are probably easier to read anyways.
The special meta key state constants used by MetaKeyKeyListener
are now (@hide) defined in KeyEvent now so as to make it clearer that they
share the same code space even if those codes are not valid for KeyEvents.
The EventHub now takes care of detecting the appropriate key layout
map and key character map when the device is added and sets system
properties accordingly. This avoids having duplicate code in
KeyCharacterMap to probe for the appropriate key character map
although the current probing mechanism has been preserved for legacy
reasons just in case.
Added support for tracking caps lock, num lock and scroll lock and
turning their corresponding LEDs on and off as needed.
The key character map format will need to be updated to correctly support
PC style external keyboard semantics related to modifier keys.
That will come in a later change so caps lock doesn't actually do
anything right now except turn the shiny LEDs on and off...
Added a list of symbolic key names to KeyEvent and improved the toString()
output for debug diagnosis. Having this list in a central place in the
framework also allows us to remove it from Monkey so there is one less
thing to maintain when we add new keycodes.
Bug: 2912307
Change-Id: If8c25e8d50a7c29bbf5d663c94284f5f86de5da4
