| Age | Commit message (Collapse) | Author |
|---|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
Change-Id: I829fe48e6ebcb819e260646bb19ac6ddfcf07f83
|
|
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
|
|
Fixed the Preference ordering code to consider the case where
two preferences might have the same order. In that case, it
falls back on the title to disambiguate. Previous behavior was
undefined (and technically not stable).
Expose the wifi display device address.
Perform wifi display scans every 10 seconds instead of every 15
to improve reponsiveness.
Make sure to define routes for wifi displays that we are connecting
to even if they are not yet paired. Simplified the logic for
adding and removing these routes to avoid possibly getting out
of sync and leaving stale routes behind.
Fix wifi display notification icon.
Bug: 11257292
Change-Id: I8ac15fb17d83758c0bdce80399e12723c367b83c
|
|
Bug: 9371882
Change-Id: I7417535f12fa5b75be471974250cfd13e45f87b2
|
|
Change-Id: Ibd7e3a59f7988975b4ac6c7efdba2b545097a2bd
|
|
When certification mode is enabled:
- Pass wfd session info to wifi display settings
- Allow sink to connect to source
- Add interface in display manager for pausing/resuming session
- Add interface in WifiP2pManager for setting lc, oc and starting
autonomous GO
Note that we're compliant regardless of certification mode, but
some confusing options (eg. allowing incoming connection from
sink) we want to hide when not being tested.
Bug: 9371882
Change-Id: Icc7dcae4e046453796cfa03f5f197055fabf234b
|
|
The submix will be controlled automatically from now on based on
whether there is an active audio recorder.
Bug: 10265163
Change-Id: I90a8592136c6507680e70f054243df70cc82efad
|
|
Bug: 10191053
Change-Id: I3ecc6880db4a4c77c6db4e8b50faa9b4021d17c6
|
|
Fix several problems in the way that the overscan was plumbed in
which could result in information not being delivered to applications.
There was also a violation of certain invariants regarding the
immutability of returned DisplayInfo objects.
Bug: 10213771
Change-Id: I21184a14305e44278b5e81353bf95d511e8517fb
|
|
Bug: 10154780
Change-Id: I0e711a6316cb231ec48fc31d87b8cbd5d857c2f8
|
|
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
|
|
Change-Id: I426115ec5a3fbda52a481097731abc8b3d9013a4
|
|
This change enables applications to create a private virtual
display that renders its content to a surface of its own creation.
The display is private in the sense that only the application
that owns the display is allowed to place windows upon it.
Mirroring and blanking is also disabled for these displays.
Bug: 9192512
Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
|
|
bug 9229799
Change-Id: I9f5fd2107f60c492d42c74e575e6483838a51267
|
|
Bug 9229799
Change-Id: I680015943f40cded45645dfa0eae42bbce5ce9a3
|
|
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
|
|
Bug: 8521148
Change-Id: I53b4cf7a3714b28f9df457e559abe92711c02cef
|
|
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
|
|
Change-Id: I1dfe21e5f64364c90565b594e28074cabe7daa64
|
|
natural orientation." into jb-mr1.1-dev
* commit '1edc61119d145b05f0b5e1323a2fc0fa6a29d4bc':
Pin electron beam surface to natural orientation.
|
|
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
|
|
PBC is not supported" into jb-mr1.1-dev
* commit '61b00239dda1d0c5e7c34e88ad9f56817543d0b8':
WFD: Fallback to PIN mode if PBC is not supported
|
|
Bug: 7627641
Change-Id: Ibba6114f907c67f1cb60c460d5b65479f2d1b148
|
|
|
|
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
|
|
Assume rotation of HDMI display is portait.
$ adb shell setprop persist.demo.hdmirotation portrait
Don't lock rotation while HDMI is plugged in.
$ adb shell setprop persist.demo.hdmirotationlock false
Hide secondary displays from apps but continue mirroring to them.
$ adb shell setprop persist.demo.singledisplay true
Bug: 7326281
Change-Id: I8f9a3b0bc19821a3a01043b0f516806dac82ce53
|
|
Bug: 7350174
Change-Id: I18481e2a1445b0aa3340e5d9b02511394521e50e
|
|
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
|
|
Bug: 7340725
Change-Id: Ia3835a37fa3800371920f863b82f992efe764664
|
|
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
|
|
Ensures that both the internal display and HDMI are blanked
or unblanked in tandem.
Bug: 7309812
Change-Id: Ie8b96d393e8bb20d23c92f3320142d9f7cf42aff
|
|
* changes:
Fix bug removing all windows that belong to a display.
Add some missing debug output.
|
|
|
|
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
|
|
Bug: 7257579
Change-Id: Ia8c6d7fefe6d4c4e6c37f20722c7ffce4bcfcbae
|
|
Prevents leaked Surfaces.
Bug: 7272421.
Change-Id: I6c87eb11bb0bedcf8de451b04477c70c248f905d
|
|
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
|
|
Bug: 7177920
Change-Id: I9d8406e1016988e2cd267dfa52d78a829f1b385e
|
|
Move OVERLAY_DISPLAY_DEVICES to Global.
Bug: 7127417
Change-Id: I632648ac5b01408512f59424f3bb55162431bea4
|
|
|
