When video start in inline mode, and then transition into full screen mode, the
video is still playing, so we need to notify the player, such that the controller
can get the state correctly.
bug:6675847
Change-Id: Ib5f712ca91fe1c374dcc20de996dac6ff7b9e983
1. Currently we are providing accessibility focus search algorithm in the
framework and we are also setting accessibility focus from hover. It
appears that implementing a focus search strategy that works for all
accessibility services is non trivial task if feasible. Based on
feedback from the developers of two such services at Google - TalkBack
and BarilleBack - the built in focus search does not quite match what
they need and they would like to implement a custom strategy.
Hence, having APIs for accessibility focus search in the framework does
not make. Therefore, we are hiding this APIs and later will take out the focus
search logic and allow the accessibility service to implement search.
Also putting accessibility focus from hover is tightly integrated with
the focus search since the set of views that get accessibility focus
from hover should be the same as the set of views returned by the
focus search routine. Therefore, we are letting the accessibility service
decide where to put accessibility focus when it gets an accessibility
hover event.
bug:6675330
Change-Id: Ie152230990a6602f3fd1d82de2177d0b1444d654
This reverts commit 858491ba13ab5d45a5ec462d002b5856703b1b2b
It turns out that Surface Flinger is supposed to generate fake vsyncs while the screen is off, but sometimes it wasn't working due to a bug. That bug has now been fixed by the following change: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
When the screen is off, we might not receive real vsync pulses from
the hardware which would cause posted Choreographer callbacks to not run.
This is bad because messages in the Looper might be blocked behind a barrier
that is scheduled to be removed by one of those Choreographer callback
(see ViewRootImpl.doTraversals). Until the barrier is removed, those messages
will not run. To prevent starvation of the Looper, we synthesize fake vsync
pulses at a reduced rate whenever the display hardware stops generating them.
This change should fix a variety of rare non-deterministic bugs where
the system might appear to be unresponsive while the screen is off,
and spurious ANRs reported shortly after the screen is turned back on.
Bug: 6574842
Bug: 6636995
Bug: 6643559
Change-Id: I263f2fdf979afd79e5ac47a0cc5d34a93b860c21
* Accept a Context when fetching the names of routes and
categories. This lets string resources resolve at time of access
with the correct configuration. The older versions remain available
that will use the static resources from the application. (There are
enough cases where applications will populate this from external
data that requiring it each time even when it was not initialized
from a resource doesn't seem reasonable.)
* Remove the ability for apps to programmatically select non-user
routes.
* Make MediaRouter.Callback an abstract class instead of an interface.
This will make further extensions easier to keep compatible in the
future.
Change-Id: If981c511dfbdfaf41ef0d1cfe4a377fc14bb5600
Bug #6642475
When expanding the status bar, create one layer per notification instead of
a single giant layer for the pile of notifications. This prevents layer
creation failure when the total height of the notifications is larger
than the maximum allowed texture size in OpenGL ES 2.0.
This change only enables layers on notifications that will be visible
once the notification area is fully expanded.
Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
Moved some duplicate code from SearchPanelView and LockScreen
over to SearchManager to avoid creating yet another copy of it
in PhoneWindowManager.
Bug: 6594275
Change-Id: Ib4ebcd6817639d17548952ab2ce7cb876c05777c
1. AccessibilityInjector was returning true even if the underlying
JavaScript was not loaded/failed. This may lead to TalkBack getting
stuck in a web view. To avoid this TalkBack requires gran1ularity
change when getting into web view. This is neither advertised nor
shown in the tutorial and which is worse it is inconsistent with
the traversal of the app.
Now if the action fails, false is returned and also the timeout for
handling the action request is increased to 5s. Upon the completion
of this timeout TalkBack may decide to show a wait dialog or just
skip the web content. We are treating this as an ANR.
bug:6663344
Change-Id: Idf3d08fe928c495bb974a127f853de6f938e2f77
