Keep track of how many clients are requesting scans and scan
continuously until all of them are gone then explicitly terminate the
scan instead of letting it time out as before.
Suspend wifi display scans while connecting or connected to a remote
display. This is handled by both the display manager and media router
since neither has complete information about what is happening.
Much of this code will no longer be needed once wifi display support
is integrated directly into the media router service.
Ensure that we don't attempt to scan or connect to wifi displays
while the wifi display feature is off.
Infer when a connection attempt fails and unselect the wifi display
route automatically so it doesn't appear to be connecting forever.
Fix issues around correctly canceling and retrying connection attempts.
Often we would cancel but not retry.
Improved connection reliability somewhat. It seems that discovery must
already be in progress in order for a connection attempt to succeed.
Ensure QuickSettings uses exactly the same logic as the MediaRouteButton
to determine when the remote display tile should be made visible.
Bug: 11717053
Change-Id: I18afc977b0e8c26204b8c96adaa79f05225f7b6e
Only allow the system ui and settings to connect to a remote display.
To do this, we essentially hide the remote displays from applications
by using the ROUTE_TYPE_REMOTE_DISPLAY then add permission checks
around the operations that connect to them.
As a bonus, this may actually save power on devices since applications
that use MediaRouter will not longer be performing discover on
remote display routes at all.
Bug: 11257292
Change-Id: I9ea8c568df4df5a0f0cf3d0f11b39c87e2110795
Extend wifi display connection timeout.
Show a notification while connecting to wifi display.
Ensure that remote display providers are really trusted before
connecting to them.
Bug: 11257292
Change-Id: Iad0caaa30d7946df818bc75ade071f2e377f8a53
- No more crashing on first launch of the easter egg
- Use IMMERSIVE_STICKY to avoid getting stuck with bars
Bug: 11319125
Change-Id: I4522feb36c29be8446715ba67d454a2012d181ca
Should help us identify stray clicks further back in time
thanks to the longer system log buffer.
Bug: 11273982
Change-Id: Ie2bf445622afff3dbc903adad6c0497954fa5fe0
Port the new style UI back into the framework from the support library.
There are now two dialogs: a chooser and a controller. We use the
same dialogs for selecting routes within app and within quick settings.
Note that the new UI does not support any grouping features since they
are deprecated and unused.
Bug: 11257292
Change-Id: I64e936a18d25ab75f0c470cbc1e7085f67004863
Fixed a bug in ImageView where we failed to inform a newly updated
Drawable about the visibility state. This caused AnimationDrawables
to not animate when attached to an existing ImageView *unless* that
ImageView happened to be attached to the window *later* or have
its visibility toggled for some other reason.
Bug: 11257292
Change-Id: Iba9e0db5ba0db2b022950aec0c6f60a435da8ad2
When ticker disabled (e.g. on lockscreen) we should avoid
animating on halt if already halted.
Bug:11033324
Change-Id: Id2927d66492a128928b80ff98dc9182209be0652
This is a first pass at integrating new remote display functionality
into Quick Settings. The Wireless Display card which previously
only supported Wifi Display is reimplemented to use the media router
to enumerate available remote display routes. This ensures that the
user is presented with a consistent state regarding the currently
selected display route.
In this patch, the Wireless Display card still launches the old
Settings preference page for Wifi Display when clicked. This will be
addressed in future patches.
As part of this change, it was necessary to derive some new lifecycle
information regarding the visibility of the Quick Settings model.
When Quick Settings is shown, an onPrepare event is delivered to
give the model a chance to update its state. Likewise when Quick
Settings is hidden, an onUnprepare event is delivered.
These events allow the system to determine precisely when remote
display discovery is required to update the UI so as not to waste
power performing discovery in the background all of the time.
Bug: 11257292
Change-Id: Id802aa0983b625aeb972b5d123e4cc080dd6705f
Move the logic for managing dimming the navigation bar
elements on the lockscreen into BarTransitions.
Replace search light + camera assets with new
versions at full brightness, and apply 50% dimming
at runtime, including the IME dismiss button.
Remove unused StatusBarManager _NOP hints.
Improve choreography between camera button +
password security (w/ IME). Fix a few found bugs
in PagedView.
Improve password security unlock transition, manually
fade in back along with the rest of the icons.
Bug:11221659
Change-Id: Ifd1f8c9f400d90542f0ca858b9a4deacabbd518a
Since keyguard and systemui were merged into the same process to save
memory, they share the same Looper and graphics context. As a result,
there's no way to allow concurrent animation while keyguard inflates.
The workaround is to add a slight delay to allow the animation to finish.
Workaround for bug 11046339
Change-Id: I355ca4fb325312bae87d587acfb12b475ecdeba4
Previously, turning the screen off with the panel expanded would
run one time through panelExpansionChanged, leaving the background
in an intermediate state.
This has probably been around for a while, only uncovered now
that we can see it (if the status bar is translucent).
Bug:11357145
Change-Id: I55b768696c8791f82265a61d2c0f665503ad8bb0
- reuse intermediate bitmaps when loading resources
- only use hardware layers on views that are animating
Bug: 11269977
Change-Id: I39ad7aff16468632da47448404416404f3b54cc4
