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
This change modifies ViewRoot to wait until the MotionEvent has been
delivered before telling the input dispatcher that it is finished.
The serial ordering guarantee will be required by new features that
may need to transfer touch focus from one window to another.
Change-Id: I0a64d1f0c8bc3f08846f213d6e28ce48b1d48e58
Merge commit '40e3af61dcbf7e49979a67410f37c4b4523a0bd6'
* commit '40e3af61dcbf7e49979a67410f37c4b4523a0bd6':
Don't play a sound if a volume key press is canceled.
This change adds a second timeout to the SecuritySettings page
separate from the standard display timeout.
Change-Id: I41fe10e31688308f52695ad3ee30a4b0507112bd
This fixes a bug where some xlarge devices weren't showing 3D recent apps.
The cause was that the config wasn't guaranteed to be loaded by
the time we reach init() in PhoneWindowManager.
The fix looks at the property on-demand, which can't happen
until after the user sees the home screen, which guarantees the
configuration is loaded.
Change-Id: Ic41196f7a15218033b831e6e9cf9d536e0712844
This adds 3D recents to the platform. Enabling it is a
matter of setting 'config_enableRecentApps3D' on devices
capable of supporting it (those with OGLES2.0 at the moment).
Change-Id: Ife7bfe8ca02e7657821b68f915e31b0dab50cd2c
Merge commit '1f4421048206ca1745ddd6366588759c9c5c38f9'
* commit '1f4421048206ca1745ddd6366588759c9c5c38f9':
Improve orientation sensing when waking up while flat.
This change makes the window manager pass the currently displayed
orientation to the WindowOrientationListener each time to calls to get
the currently sensed orientation. Now, when the
WindowOrientationListener doesn't know for sure what the orientation
of the device should be (for example, if the sensed orientation is
flat on a table), then it trusts the already-displayed orientation,
rather than trusting whatever sensors reading it most recently
received.
The main use case this addresses is:
* user uses device in portrait
* user turns off device, puts it in pocket
* while in pocket, screen gets turned on, activating orientaiton
sensor, which senses landscape orientation
* screen timed out
* user takes device out, places it on a table (or looks down at it,
holding it flat), and unlocks it
Previously, when the device was unlocked, the
WindowOrientationListener would return landscape orientation based on
its previous sensor readings. Now, it will override those previous
readings because it knows they never actually took effect and the
device is presently flat.
This change also slightly modifies the way we handle flat orientation,
now completely ignoring data when the tilt distrust is nonzero (even
if the current sensor reading shows non-tilted).
Change-Id: Ia4950a41827f8c53a80487d0c2e83b556df781b9
* Fix a bug where the options panel would not open on non-xlarge
screens to show overflow menu items.
* Fix a bug where ActionBarView would try to add a custom nav view
twice.
* Fix a bug where ActionBarView would expand too far in wrap_content mode
Change-Id: I433ea56524aad885d813ae8743fe2fcefa9649fa
Merge commit 'f66f8a58cc4412bd258e1d5b11cac17a617bdc58'
* commit 'f66f8a58cc4412bd258e1d5b11cac17a617bdc58':
Add support for the PointerLocation overlay.
This change involves adding a new method to IWindowManager,
monitorInput() that returns an InputChannel to receive a copy of all
input that is dispatched to applications. The caller must have
the READ_INPUT_STATE permission to make this request (similar to
other window manager methods such as getKeycodeState).
Change-Id: Icd14d810174a5b2928671ef16de73af88302aea0
