The window manager now keeps track of the overscan of
each display, with an API to set it. The overscan impacts
how it positions windows in the display. There is a new set
of APIs for windows to say they would like to go into the
overscan region. There is a call into the window manager to
set the overscan region for a display, and it now has a
concept of display settings that it stores presistently.
Also added a new "wm" command, moving the window manager
specific commands from the "am" command to there and adding
a new now to set the overscan region.
Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
SurfaceControl is the window manager side; it can
control the attributes of a surface but cannot push buffers
to it. Surface on the other hand is the application (producer)
side and is used to push buffers to the surface.
Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
If a rotation occurred while the electron beam surface was showing,
the surface may have appeared in the wrong orientation. We fix this
problem by adjusting the transformation matrix of the electron beam
surface according to the display orientation whenever a display
transaction occurs.
The rotation itself is allowed to proceed but it is not visible
to the user. We must let this happen so that the lock screen
is correctly oriented when the screen is turned back on.
Note that the electron beam surface serves two purposes.
First, it is used to play the screen off animation.
When the animation is finished, the surface remains visible but is
solid black. Then we turn the screen off.
Second, when we turn the screen back on we leave the electron beam
surface showing until the window manager is ready to show the
new content. This prevents the user from seeing a flash of the
old content while the screen is being turned on. When everything is
ready, we dismiss the electron beam.
It's important for the electron beam to remain visible for
the entire duration from just before the screen is turned off until
after the screen is turned on and is ready to be seen. This is
why we cannot fix the bug by deferring rotation or otherwise
getting in the way of the window manager doing what it needs
to do to get the screen ready when the screen is turned on again.
Bug: 7479740
Change-Id: I2fcf35114ad9b2e00fdfc67793be6df62c8dc4c3
Hotplug events say which display they're for and whether the display
was connected or disconnected. Before, this info was ignored, and the
event just triggered a rescan of all displays. If a display was
disconnected and then reconnected quickly, the rescan would treat this
as a no-op or a device property change and wouldn't turn the display
on.
Now the display manager attempts to update its state with the change
the event describes. So a quick disconnect/connect cycle will cause
the display to be turned on since the display manager will have
updated its internal state to reflect the disconnect event, and will
treat the connect event as a new display rather than a device property
change.
Bug: 7491120
Change-Id: If16268fbd0708683f6401ea72fbee9fb2c3c8d19
Some Wifi display devices like to rename themselves after a
connection completes (or at other times). Make sure to update
the name of the display when we detect that it changed in
our scan results.
This problem is somewhat complicated by the fact that we remember
the display name persistently, so we need to update our list
of remembered displays too.
Improve the state machine to avoid redundant attempts to
disconnect or cancel connection.
Bug: 7478895
Change-Id: I35a9e2c6a8deadbe892dacd5e3b4a5a2b12d6cf0
This new API makes it possible for an application to ask on
which Display it should show a Presentation based on the currently
selected media route.
Also added a new API on DisplayManager to query displays that
support a certain category of uses.
Improved the documentation of the Presentation class to explain
how to choose an appropriate Display for presentation.
Bug: 7409073
Change-Id: Iab451215e570ae55f3718fc228303143c800fe51
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
This change makes use of the new 'secure' argument to the
ISurfaceComposer::createDisplay method. In this change both the overlay and
wifi displays are hard-coded to be non-secure displays.
Bug: 7368436
Change-Id: Ib65312f2adab5104d8deefbfc32af9dc106a9129
The display manager must never call into the activity manager with
its lock held. Make it clear that the adapters are constructed
while holding the syncroot lock.
Bug: 7377631
Change-Id: I1557313cbb31dcad9b5a46919a88a5a1c1af3e9b
Calling blank() on Surface Flinger to turn the screen off is not
enough to ensure that the content is blanked to all virtual displays.
What's more, the black surface left in place by the ElectronBeam may
not completely hide the content (particularly if the display orientation
changes). To fix this for real, we'll want to move the display power
management code from the power manager into the display manager
but we don't have time for that.
As a work around, force all displays to show an empty layer stack
with no surfaces on it while blanked.
Bug: 7311959
Change-Id: I870c985f9e76f3f2322e5d83cdbbed9ed15b9f10
Fix a couple of bugs that cause MediaRouter to disconnect from
the current Wifi display whenever it is renamed.
Added an extra check in WifiDisplayAdapter for identity renames.
The Settings app already handles this case but it's good to have
the service check for it as well so we don't store unnecessary
aliases.
Bug: 7310777
Change-Id: I8fddd32ca59f9b798ee31b467b81457508c345f8
Added a new API to determine whether the display supports
protected buffers so that an application can choose a different
content stream or change how it decodes the content so
that it will be viewable on the display.
At present, wifi display does not fully support protected
buffers although this may be enhanced in the future.
Bug: 6986623
Change-Id: If53a53d72b0ec92753cc4b29f99fcb131e00449b
Display controller should always stay in sync with peer list to avoid
showing incorrect available status on peers which would
cause connectivity issues.
Bug: 7268307
Change-Id: If04644339c1ee3f567939e4441dd6f6a45e4179a
WindowManager was notifying DisplayManager of content if any window
existed on a display. Now the window must be visible and we must not
be showing a Dream or the Keyguard.
Bug: 7214060.
Change-Id: I9ce4a49aabfbac22ff1e39a837199ce35b9f7503
The worst case WPS timeout for GO negotiation is two minutes.
Until, we better handle cancelling/disconnecting and re-syncing the
WFD framework with the wifi direct framework/supplicant, increase
the time out to 60s to help with dogfood
Bug: 7217600
Change-Id: I1ba0d9963b957454e2c6f47bfdf05176dea07be7
Add a setting to globally disable Wifi display.
Fixed a bug where the wifi display broadcast receiver
was running on the wrong thread.
Removed the wifi-display QuickSettings dialog, all functionality
has been moved to Settings.
Bug: 7178216
Bug: 7192799
Change-Id: I9796baac8245d664cf28fa147b9ed978d81d8ab9
- Specificy max GO intent for WFD
- Increase GO idle time out to 20s and use it for GO and client
- Fix connection broadcast
Change-Id: Ia0e28bc9eb3e23d2830a6c814c5a537ca0bcd5db
We should only report that the wifi display is connected
after the RTSP connection has been fully established.
Change-Id: Ifc6bc5d5cebd42d551026885b31cbc74b7ece2b1
