- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
The Views created for the Toolbar were not cleaned up properly when the
mode was cancelled by the client in onCreateActionMode, leading to the
toolbar appearing over other views when it shouldn't due to
onWindowFocusChanged showing the Toolbar if it exists.
We don't actually need the views if we don't know whether they are
going to be shown yet, so moved view creation to after onCreateActionMode
Bug: 20713912
Change-Id: Ic0c31d1634e1e96d9981a77b2c769306a8bf1a8d
* Add better docs to ChooserTarget
* Change ChooserTarget to use android.graphics.drawable.Icon instead
of Bitmap
* Preserve EXTRA_REFERRER when starting ChooserTargets
Bug 21045119
Change-Id: If859b86344cebaed3eaae477af132e7d7600aba6
Rename MidiDeviceInfo.getPortList() to getPorts()
Rename MidiManager.getDeviceList() to getDevices()
Rename MidiReceiver.onReceive() to onSend()
Replace MidiManager.DeviceOpenCallback and BluetoothOpenCallback
with new interface MidiManager.OnDeviceOpenedListener
Add MidiSender.onConnect() and onDisconnect()
Add MidiReceiver.onFlush()
Ensure that MidiReceiver max message size is immutable
Bug: 21044677
Change-Id: I7711734a45e831e9744849a6f569e906feff9f80
- Add LockPatternChecker to support async security check;
- Migrate Keyguard UI to use the async check;
Bug: 20697812
Change-Id: I77002a12931feb17cc20923d7c917b3e37f2cd31
- if a default Browser is not defined and if a Browser App
is selected into the disambiguation dialog, then make it as
the default Browser
- clear default Browser saved data (package name) when
the default Browser App is removed
See bug #20144393
Change-Id: Ia8621d7a61ec2cb60deded9d70f75f1e1d88d123
Separate the chooser targets into rows by type. Remove some API that
was redundant with LabeledIntent, simplifying ChooserTarget.
Change-Id: I90de471825f05d85e6ffbe72a32fb597be824a30
airplane: quick and slow settings
bluetooth: quick and slow settings
cellular data: quick and slow settings
dnd: quick and slow settings
wifi: quick settings (slow already done)
cast: quick settings
user: quick settings
include state of the toggle in the action log
Back away slowly from the over-generalization of logging
around handleClick, the semantics of mState are particular
to the individual tiles.
Bug: 20264417
Change-Id: I4cecbd3361af64d08de9fb41b8dca210a8086a80
QS Grid visibility
Tiles that are visibile in the grid
Taps on tiles
Detail visibility for DND, Users, and Data
Bug: 20264417
Change-Id: I95e65484a9be0a53a071bc12ce8195120582621e
Merges the translate and clip reveal so that we can adjust the clip
position based on the current translate position. This ensures the
clip appears to expand from the center of the translated popup and
never extends outside the window bounds.
Change-Id: I8bbb9c0e2293a25f7807d71d9b8779bb782d4784
This avoids an NPE that could occur when:
1. disconnect() is called
2. sendMessage() is called but encounters a RemoteException
3. replyDisconnected() will attempt to dereference mSrcHandler
There does not appear to be any callers that rely on the NPE.
All callers erase their reference to the AsyncChannel after
calling disconnect(), except for NetworkAgentInfo which can
cause ConnectivityService to crash. This fix addresses that.
bug:20647016
Change-Id: I89864885dc3371941407a036b7b7647e0ec037b8
This CL relands I1e50ee42838a1bf64a612da4904aa93458d44ea4, which was
reverted by I3decaf37198e5864a1763a059df4a36ebc70c5a7 due to the build
breakage in 'layoutlib' target, with a proper fix.
Hereafter the original CL description is repeated.
The auxiliary subtypes should be listed if the input method picker is
opened from NavBar keyboard icon. However there is only
IMM#showInputMethodPicker() API to open input method picker and this is
also used from LockScreen or Settings UI. Auxiliary subtypes should not
be listed there(Id7cf5d122). Thus framework shows auxiliary subtypes
based on IMMS#mInputShown and LockScreen state, but it is not a perfect
solution. If a physical keyboard is connected, the soft input may be
gone. As the result, auxiliary subtypes won't be listed even if it is
opened from NavBar keyboard icon.
To fix this issue, this CL introduces IMM#showInputMethodPicker(boolean)
to be able to decide showing auxiliary subtypes by caller.
Note that IMM#showInputMethodPicker(boolean) is still hidden with @hide.
There is no public API change in this CL.
Bug: 20763994
Change-Id: Id156c85535a221235737ea6dcc15a67f1c4b9f71
CL is breaking the build. Discussed with Seigo and verting until he can take a look at it.
This reverts commit 80ff4ed6bb.
Change-Id: I3decaf37198e5864a1763a059df4a36ebc70c5a7
PhoneWindow, PhoneLayoutInflater and PhoneFallbackEventHandler decided
to @hide out over in the android.view package after the policy jar was
disbanded. Give them a more appropriate home over in framework that
doesn't imply that they should be accessed from other internal layers
of abstraction.
Bug 19606548
Change-Id: Id07b791d178fa447010b49b24726b52208838e88
The auxiliary subtypes should be listed if the input method picker is
opened from NavBar keyboard icon. However there is only
IMM#showInputMethodPicker() API to open input method picker and this is
also used from LockScreen or Settings UI. Auxiliary subtypes should not
be listed there(Id7cf5d122). Thus framework shows auxiliary subtypes
based on IMMS#mInputShown and LockScreen state, but it is not a perfect
solution. If a physical keyboard is connected, the soft input may be
gone. As the result, auxiliary subtypes won't be listed even if it is
opened from NavBar keyboard icon.
To fix this issue, this CL introduces IMM#showInputMethodPicker(boolean)
to be able to decide showing auxiliary subtypes by caller.
Note that IMM#showInputMethodPicker(boolean) is still hidden with @hide.
There is no public API change in this CL.
Bug: 20763994
Change-Id: I1e50ee42838a1bf64a612da4904aa93458d44ea4
Allow a calling app to supply an array of additional Intents to the
system ChooserActivity.
The chooser will present a merged list of targets that can handle any
of the Intents supplied, including both the standard EXTRA_INTENT as
well as any of the intents supplied in EXTRA_ALTERNATE_INTENTS. These are
treated as ordered; EXTRA_INTENT is considered the first/primary
Intent and EXTRA_ALTERNATE_INTENTS are sorted most important first.
Targets are queried for all supplied Intents. If the same component is
returned for more than one Intent, the target is associated with the
most important Intent that matched.
This allows calling apps to supply several different payloads for an
action depending on what the intended targets are able to support. For
example, an app performing ACTION_SEND may supply image/jpeg data to
compatible targets or a hosted web link to targets that only support
text/plain. The user will have the opportunity to pick from a single
merged list of choices using the best available payload, and will not
be bothered with the implementation details of how the payload will be
delivered to the recipient.
If the calling app wishes to provide further disambiguation or
refinement after the user makes a choice, for example to let the user
choose which of the source intents to send from the primary or
alternates, show a progress dialog as a full-resolution version of a
photo is downloaded from the server before being sent along or while
reticulating splines, the caller can supply an IntentSender to
ACTION_CHOOSER including the extra EXTRA_REFINEMENT_INTENT_SENDER.
This should be the IntentSender obtained from a PendingIntent pointing
at an activity to launch to perform the refinement.
The refinement activity should report that it is finished by obtaining
the ResultReceiver from EXTRA_RESULT_RECEIVER. Available intents to
send to the selected target will be contained in EXTRA_INTENT and
EXTRA_ALTERNATE_INTENTS.
To complete the refinement and send the result along to the chosen
target, the refinement activity should select one of the supplied
intents and send it to the ResultReceiver in a Bundle with the key
EXTRA_INTENT and the result code RESULT_OK. To cancel the refinement,
and let the user select another choice, send RESULT_CANCEL.
While refinement activities cannot modify the filterEquals-affecting
fields of the Intent they return, they may modify extras to provide
additional or altered details to the final recipient. These extras
will be filled into the Intent sent to the final target.
Change-Id: I7ad4739eadd1a0e307675847ccf47ea948918a3a
Also updates default fade duration for scrollbars to match Material
spec and moves around some padding in AlertDialog so that scrolling
text and list items aren't so close to the title.
Bug: 19098033
Change-Id: I40dca6a931480c4c48463e3ea5b8361534cbd8d7
