When running in edit mode, do not use the application info to get the
icon, since it will be null.
Change-Id: I174e6126ddca341d06c5f04939470ef52f0e771c
(cherry picked from commit 90ce58ecfd)
The change adds the view cookies for the menus rendered in the action
bar. This enables the IDE to map the menu to the relevant XML Tag in the
menu xml and show the highlighting accordingly.
The change also contains a bugfix where a method wasn't renamed
properly.
Change-Id: Idcfc263a8ebe0a4f25afa3a1eb085fa628fd03ca
(cherry-picked from commit 094fd8ecb6)
This also makes a couple of changes to the framework:
1. ShareActionProvider - Use edit mode to execute activity chooser code.
2. ActionBarImpl - add a new constructor for use by layoutlib.
This also relies on some changes to the plugin to pass the correct params.
Change-Id: Ia30fef816afd91ec1e439734d56b59b1323bfee2
(cherry-picked from fe38489f67)
A certain call ordering to the action bar could cause the record of
the pre-action view expanded home button enabled state to be
incorrect. Store this in all cases, not just when the action view is
initially expanded. (Except for when we actually disable it for the
expanded view.)
If an action view is already expanded when we get a call to change the
enabled state of the home/up button, don't modify the state of the up
container or other accessibility info, but record the new state if
requested.
Bug 8142097
Change-Id: I070c151aa9f2046d2114ee541d964bf68c6f0def
A bug was introduced when these views were restructured. Make sure that the
Up button for expanded action views functions/focuses correctly.
Bug 8124825
Change-Id: I0a886e62fca21dbb9a173db87642bb79ce9245e7
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
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
