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
Add support in ActionBar for activity-wide progress APIs.
Add ability for progress bars to set a target framerate rather than
the 5fps previously used.
Clean up some more dialog layouts using hardcoded styles rather than
theme attributes.
Change-Id: I8e88c7595e27c0b6f7829b598f2b084ac8501ae3
New default only applies to applications with targetSdkVersion >=
HONEYCOMB. Old applications default to no touch splitting for
their windows.
In addition, enabled split touch for various system windows.
Bug: 3049580
Change-Id: Idc8da9baa2cd8e1e4e76af8967d7b6a5ccb94427
When switching to a recent task that is currently active, do a
task switch instead of a start activity, so the activity is brought
back in its exact same state.
Also fix problem in phone recents where the icon would disappear
after you touch it.
Change-Id: Id5c8478f8c33c90f52fbb4d969037d2bf5af9fff
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
We were using a stale version of the accelerometer rotation
setting when figuring out what the current rotation lock
state is.
Change-Id: I7780617c875a8f6c9697e829642f86f9f664df89
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
Remove transition delay to show home.
Add new constants to allow finer tuning of "success" animation.
Transition all items to transparent on successful unlock.
Change-Id: Id9f57b9bfc08be840d9282f987925617d2b42ea1
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
The code for the new always-there status bar was a bit too brute-force,
and also impacting things like the IME. We now implement this by
actually having an explicit concept of "display size" that the status bar
can carve out from everyone else.
Change-Id: I1963d0b07f52e8d8dc3c836227da9bf5d3f2e8b9
Remember, the system and main logs are
- Shared resources
- Primarily for recording problems
- To be used only for large grained events during normal operation
Bug: 3104855
Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
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
Windows with FLAG_NEEDS_MENU_KEY (or windowNeedsMenuKey=true
in their theme) will cause the system bar to show a menu
icon. (Note that the phone's status bar currently ignores
this, but phones tend to have hardware menu keys anyway.)
Additionally, all windows whose package's SDK version is
pre-Honeycomb will have FLAG_NEEDS_MENU_KEY set by default.
Bug: 3003728
Change-Id: I2d983763a726ea4f32cd1af9b0390e30478b11d1
Fixed some issues with Monkeys turning off their own screens. Ook ook!
Added some more comments to explain what's going on.
Change-Id: Id2bc0466161a642a73ef7ef97725d1c81e984b12
Added the concept of a "trusted" event to distinguish between events from
attached input devices or trusted injectors vs. other applications.
This change enables us to move certain policy decisions out of the
dispatcher and into the policy itself where they can be handled more
systematically.
Cherry pick of b931a1b4 from gingerbread into master.
Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
Added the concept of a "trusted" event to distinguish between events from
attached input devices or trusted injectors vs. other applications.
This change enables us to move certain policy decisions out of the
dispatcher and into the policy itself where they can be handled more
systematically.
Change-Id: I4d56fdcdd31aaa675d452088af39a70c4e039970
We have the system tray for that stuff. Make long press on power
go directly to the shut down confirmation dialog. Make that dialog
auto dismiss when the screen goes off. Reword it when we're skipping
the global actions menu, because it feels too abrupt to say "The
phone will shut down" when they haven't clearly pressed a button
that says shut down.
Change-Id: I8c92a1362bd4ed242e6cd94c2dae6d9ff9c4c34d
This fix extends the lockscreen timeout to 30s while the
handle is being held. As a precaution, it will still timeout
after 30s of not completing the lock. Once the handle is
released, the screen will go dark after 5s, which gives
it enough time to finish pending animations.
Change-Id: Ie89449b6b09de06ca8a88702cc85085b2556903c
The phone button probably doesn't exist on products without phone apps,
but the monkeys still know how to find it.
Change-Id: I36aca53506c8d7d7565df8674aff9d59745139e0
Apps now must explicitly opt in to having their rotation changed while
forcing landscape mode. Also add some new orientation constants for other
things apps may want to do.
Change-Id: If64d84b5ef54793ee717ebda9b4c76408efc9bfd
The app was toggling between hiding and showing the status bar, because
the dialog was large enough to fill the screen but didn't set to hide
the status bar.
It turns out that the code to determine the top fullscreen window is
intrinsically unstable, since it relies on comparing a window's frame
with the screen, yet the window frame can change as a result of changes
such as hiding the status bar.
Instead, we now simplify all of this to just say that the top fillxfill
window gets to control the status bar.
Change-Id: I22913adf7235fe0d52612f6738c7c94351274e38
A View initiates a drag-and-drop operation (hereafter just called a "drag")
by calling its startDrag(ClipData) method. Within the processing of that
call, two callbacks are made into the originating View. The first is to
onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this
callback must respond by calling setDragThumbnailDimension(width, height) to
declare the size of the drag thumbnail image that should be used. Following
this, the View's onDrawDragThumbnail(canvas) method will be invoked to
actually produce the bits of the thumbnail image.
If all goes well, startDrag() will return 'true', and the drag is off and
running. (The other arguments to startDrag() provide reconciliation between
the current finger position and where the thumbnail should be placed on
the screen relative to it.)
Potential receipients of the ClipData behind the drag are notified by a
new dispatch mechanism, roughly parallel to motion event dispatch. The core
routine is the View's onDragEvent(event) callback, with the mechanics of
dispatch itself being routed through dispatchDragEvent(event) -- as in
the case of motion events, the dispatch logic is in ViewGroup, with leaf
View objects not needing to consider the dispatch flow.
Several different event 'actions' are delivered through this dispatch
mechanism:
ACTION_DRAG_STARTED: this event is propagated to every View in every window
(including windows created during the course of a drag). It serves as a
global notification that a drag has started with a payload whose matching
ClipDescription is supplied with the event. A View that is prepared to
consume the data described in this event should return 'true' from their
onDragEvent() method, and ideally will also make some visible on-screen
indication that they are a potential target of the drop.
ACTION_DRAG_ENTERED: this event is sent once when the drag point
enters the View's bounds. It is an opportunity for the View to set up
feedback that they are the one who will see the drop if the finger goes
up now.
ACTION_DRAG_LOCATION: when the drag point is over a given View, that
View will receive a stream of DRAG_LOCATION events, providing an
opportunity for the View to show visual feedback tied to the drag point.
ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point
leaves the View's bounds. The View should undo any visuals meant to
emphasize their being the hovered-over target.
ACTION_DROP: when the drag ends at a given point, the View under that
point is sent this event, with the full ClipData of the payload.
ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global
broadcast that the drag has ended and all Views should return to their
normal visual state. This happens after the DROP event.
Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
This adds a new "Energy Wave" widget to the internal widgets and
integrates it into LockScreen.
ValueAnimator needed a slight modification since it expects to
be run inside of Activities with a Looper. Additionally, this adds
an API, removeAllUpdateListeners(), which is needed to properly
recycle ValueAnimator objects.
Some minor code cleanup and UI tweaks after review.
Changed delay timeout from 1.3s to 0.5s.
Change-Id: Ibcf015e61fa8ba79d62f2019f1b29ace7caa00c8
