Title/subtitle text in an action bar is now a full alias for home/up.
Add some prototype ActionBar functionality around titles for future
API consideration.
Bug 7966136
Change-Id: I14377121dcb976d0a5f1e1862f35c3d267eb5458
Improves the throughput of IME event handling by ensuring that
input events do not get serialized behind UI traversal and
drawing messages such as when the UI is animating.
Added support for creating an asynchronous Handler as part of a
HandlerCaller. It turns out we should be using an asynchronous
Handler not only in IME dispatch but also in accessibility and
wallpaper events where HandlerCaller is used. So fixed those
services to also use an asynchronous Handler.
Change-Id: I0b19140c9d5ca6ee300c1a150c48312fd55ed8eb
This was initially about the Clock widget crashing repeatedly on some
devices with multiple users. Turned out that there were race conditions
when switching users that could result in remote views of one user calling
back to the RemoteViewsAdapter in keyguard that in turn sent an incorrect widget id
to a different user's widget, resulting in a crash.
Since KeyguardHostView is instantiated in the same process for different users,
it needs to carry a user identity to pass along to AppWidgetService so that
remote views services were bound to the correct user and callbacks were attached and
detached properly.
Added some aidl calls that take the userId to do the binding properly. A more
complete fix might be needed in the future so that all calls from Keyguard carry
the user id.
Also, there was a problem in comparing host uid for secondary users, since Settings
for a secondary user has a different uid than keyguard. Not an issue on single-user
systems. Changed the host.uid comparison to accomodate for the secondary user.
Bug: 7450247
Change-Id: Idbc36e3c60023cac74174f6cb7f2b2130dd3052c
MediaRouter's policy so far has been around a single selected route,
but when route types are entirely orthogonal this should not be the
case. However we still don't want to get into a situation where we
have multiple, very different routes selected for different types at
the same time, we still want to have more of an element of
predictability.
Behavior of getSelectedRoute is now:
* If the selected route matches at least one type with the requested
type flags, it is still considered selected for that request.
* If the caller specifically requested the selected user route and the
currently selected route is not a user route, return null.
* If the requested type flags do not match any types with the selected
route, return the default system route.
Note that this is "any" behavior instead of "all" - this matches
existing usage of the method. We may consider adding an "all" variant
later on.
Bug 7588042
Change-Id: I3a79d8153ca6b882fd3ef6b9b1de8f538873dec2
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
In alarm manager, print a summary of the top 10 alarms by time
being executed. Keep track of execution time (and wake count) of
each type of alarm for each application so this can be printed in
the summary (and used to compute the top 10 alarms). Rework how
the alarm summary stats are tracked so that we don't need to hold
on to the full Intent for each stat and can get the Intent information
at the time the alarm is sent rather than waiting for whatever Intent
comes back in the result.
Also in the battery stats: sort the kernel wake locks by time, add
a new section showing all partial wake locks across all applications
sorted by time.
Finally a new LocalLog class that is used by AlarmManager to log
important warning messages, so these can also be later found in
its dumpsys output.
Change-Id: Icc07810053e60fb623a49937e696819cb8352b06
1. There are two overlaid views, one is the GlowPadView and the
other is the SlidingChallengeLayout. Since the GlowPadView is
on top of the other view it has to consume the hover events or
they will be dispatched to the view behind it which results
the the GlowPadView not getting accessibility focus.
bug:7496770
Change-Id: Iae3b1777e490c56e33560a016fc04a92226bfb66
Also, if we have no widgets in lockscreen,
reinflate the default widget. If that fails,
inflate the built-in clock (KeyguardStatusView)
Change-Id: I2e90ab0893c993a755700e075e4a8ac5a685e0f2
Face Unlock would reappear when rotating a tablet after it had already
fallen back to the backup unlock method. This change suppresses Face
Unlock after going to the backup so it isn't seen again until the user
leaves and revisits keyguard.
This change also removes the exposeFallback() callback from Face
Unlock. It has been unnecessary for a long tiem since Face Unlock no
longer covers the backup. The Face Unlock service was therefore
making unnecesaary calls via the AIDL interface.
Note that the AIDL interface change broke obsolete keyguard stuff.
That is being deleted soon anyway, so code has just been commented out
of the obsolete files to make it compile.
Change-Id: Ia5c451cce1703b3bc03e27a35c6b38373e944d1b
Also, remove ability to filter widgets by feature
in appwidget picker in anticipation of api change
Change-Id: I325de0b98f03d3a250758d504229ea27794b5330
This is now being done inside stopUI instead of its own separate
call since it needs to be done on the UI thread inside FaceLockService.
Change-Id: Iaf3a203f7f201ba4dde4c878f457e765f11e6c0e
Before the FUL service started, the FUL cancel button was positioned
off of the right side of the window. This was because the
FaceUnlockView (derived from RelativeLayout) was calling
super.onMeasure() incorrectly, preventing it from using the new
'square' size when laying out child views.
Change-Id: I2f1e86617da5c8f37123febab2e433288bdea062
When the referenced bug was filed, face unlock was only showing as a
tiny sliver on tablet layouts. Due to other changes in the lockscreen
branch, it was no longer a sliver, but was still an incorrect layout,
with a width much greater than height. This change makes face unlock
square for all layouts.
The face unlock RelativeLayout was replaced with a custom
FaceUnlockView derived from RelativeLayout. The new view forces a
square layout using the same technique used by LockPatternView.
Note that there is still a bug where the pattern view covers the widget
area on portrait tablet layouts. The face unlock view has this same
issue, but may resolve itself when the pattern bug is fixed.
Also note there are two other Face Unlock tablet bugs that existed
before this change (and therefore are not caused by this change):
- flash during transition from spotlight animation to camera preview
- PIN backup is upper-left instead of centered
Change-Id: I550eccfa3924f230a9dc43f0a9b59f1ea55a9273
This makes it so that the view is hidden immediately when
a call to stop is made. This also changes the call in onPause to
only stop and not go to the backup because we still want Face Unlock
to show as the view is being dragged down.
Change-Id: I66d8fc24e82dc3a0155f7d59d8ced932cb584660
Addressing some comments:
- Sticky widget is now saved in a user-scoped setting.
- Removed multi-user widget from computation (obsolete).
- Removed status widget from computation (just use right-most).
- Removed duplicate isMusicPlaying logic.
(frameworks/base)
Change-Id: I8ef8f826677d78ac24da52adf2d99d47c8d965ac
This reverts commit 6bf6eb7d5f9207d6a3e1d6b61f17a8654d06fbdb.
and also fbc21e126f329b7b7c161858c1390ccb023be07e
I have also removed all unnecessary calls to resolveLayoutDirection(int). This is possible as
we are resolving layout params on every child of a ViewGroup as of commit
fcc3348f61b2992f0b84e8e8dcb3535fc715298f
Change-Id: I262a375b03fcc3c9261cbe2edebb6ec42ec2e186
