We are tagging these as "watchdog" to make them visible in the
reporting tools.
Also new am command to kill all background processes, mostly to make
it easier to test this stuff.
Change-Id: Ib9dc4747cd8bd44156fdf11d6a087cd4272203eb
Pre-Holo spinners had a far more "buttony" look that expressed the
disabled state clearly, but Holo spinners are more subtle. As a result
we want to mark the contained view representing the current item as
disabled when the spinner itself is disabled.
Express this as a private framework style attribute that cannot be
changed at runtime.
Change-Id: Icff2ef2b8a3b1a96cbf00e4c75eda41a4dada7b3
The min width and height were enforced with an exception which
is not correct since a view not having enough space should not
terminate the application. Now the insufficient vertical or
horizontal space is propagated by setting the
MEASURED_STATE_TOO_SMALL flag and respecting the constraints
imposed while measuring (consistent with the rest of the View
hierarchy).
bug:5572237
Change-Id: I2dbeb5451d3426cc983b41f6023c7b0fc52c7da3
Bug 5552615
We're adding a new intent to allow 3rd party apps to disable
the Messaging app's notification. We want any app to be able to query
the setting of whether sms notifications are on or off, but only allow
system apps, particularly the Messaging app, to change that setting.
Other apps can change the setting by firing off an intent which brings
up a dialog activity in the Messaging app that'll let them turn off
Messaging notifications.
Change-Id: I4d2721191b86010efb383a24c28d911496440657
Allow a fragment to set a hint of whether or not it is currently user
visible. This will be used implicitly to defer the start of fragments
that are not user visible until the loaders for visible fragments have
run. This hint defaults to true.
Change-Id: Id1349d319886a277ef07301f64f7b9e12c8729bf
Once a backup lock has been chosen, it sends an intent to show a
congratulations screen. The moveTempGallery function has been moved
inside this new activity so it is no longer needed in LockPatternUtils.
Change-Id: I66868e6e3391b8b740f618fe633047ce388f55ca
Launcher swiping looks choppy. It's because we deliver the
motion events of the drags asynchronously, and sometimes we
may get an event to redraw before the motion event is posted, so we
end up drawing again without updating to the latest motion
information.
This fix makes input event processing more proactive. Every time
we run ViewRootImpl.performTraversals() (which is what
happens whenever we need to layout, measure, and/or draw), we
first process all pending input events, ensuring that we are
completely up-to-date with posted events prior to drawing, so that the
drawing we do is synchronous with the events we've received.
This eliminates the choppiness and means that we can now get the full
refresh rate on the screen with drag events.
The fix was done for Launcher, but it is pervasive in the system,
so this may fix other laggy drag behavior as well.
Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
Also use the AlarmManager instead of messages so the delays
are consistent whether sleeping or not.
Bug: 5534004
Change-Id: I24118b30214dddf8183c1200a89555d6c528e606
