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
This reduces the camera transition timeout to 0 if launched
from the navigation bar. The transition cannot be aborted once
launched.
Change-Id: I7c376fbb90fd51cd301ef49fbd3411370bc2e4b5
- No more crashing on first launch of the easter egg
- Use IMMERSIVE_STICKY to avoid getting stuck with bars
Bug: 11319125
Change-Id: I4522feb36c29be8446715ba67d454a2012d181ca
* commit '29610421a32501661d6c20136c76ec426d6500fb':
Revised some text while reading up on traceview. this is what's left of this older CL that was left for dead: I5528b476d8110df51d45aaf690d878f72bc75c9f
this is what's left of this older CL that was left for dead:
I5528b476d8110df51d45aaf690d878f72bc75c9f
Change-Id: I42f784d693c0a2a2e2e8ed4c582cbc10180191e7
This reduces the amount of time available to the user to cancel
launching the camera in order to improve average launch time.
It also increases the threshhold for flings and motions to prevent
unintentional launches which are costly in terms of falsing.
Fixes bug b/11657355
Change-Id: I852abbe3ce8ddddcb65f3a48a2f8111d20126189
Should help us identify stray clicks further back in time
thanks to the longer system log buffer.
Bug: 11273982
Change-Id: Ie2bf445622afff3dbc903adad6c0497954fa5fe0
A previous fix introduced a problem with building content descriptions
for accessibility of the home/up button in one code path while setting
display options flags. Correct the issue and also refresh content
descriptions immediately when setting related attributes one at a
time.
Bug 11542264
Change-Id: I40d07036d1026e8e40c77c47ac377c82edd827b4
This change adds some clarification when a cancellation will be
requested during a layout or write. It also clarifies from which
thread the layout and write callbacks can be invoked.
Change-Id: Id20ff04c6fca8315849ed4a6c329da1b12bb6836
Both requests are made using same id; and there is a chance that
stopResolve() is not fully completed when getAddrInfo() is issued. That
results getAddrInfo() failure, because both are using same requestId.
This change fixes this problem by creating a new unique id to call
getAddrInfo() with.
Bug: 11597153
Change-Id: I56bd78740e8a40bd31c52705dc797486aff53a50
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Also use the existing full PreferredActivity match machinery instead
of the existing direct comparison now that the intent filters can
be more flexible.
Bug 11482259
Change-Id: Icb649ca60ecfbdb9ee3c256ee512d3f3f989e05f
