This also includes a previous change to current.txt that hasn't been
copied to 16.txt yet
Bug:6662259
Change-Id: Iaab5c38ad56882a1270b5276ba7a399bbb8a49f3
* Add ActionProvider#overridesItemVisibility and isVisible.
These methods allow an ActionProvider to override the
visibility of a MenuItem that it is bound to. If a MenuItem
has been explicitly hidden by the application, it will not
be visible.
* Change MediaRouteActionProvider to not require a MediaRouter
callback, to avoid extra lifecycle management headaches.
Change-Id: I606fa98b3a6a3e60a953dd024274f9bf9c67acdd
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
Add the dialog behavior for MediaRouteActionProvider/MediaRouteButton.
Still TODO:
* Switch audio icon based on source; speaker/bt/user
* Rig up volume slider
* Rig up item icons
* Rig up group button for groupable categories
* Make grouping work
Change-Id: I3f992516b184d5ae940ddb7bbb7f94ff58914589
Bug: 6656538
Due to the WebView/WebViewClassic refactor we need to call
WebView.performLongClick instead of performLongClick directly
to allow subclasses to override performLongClick
Change-Id: I9b580217fbafc82d03e63eabfdda9f5bad98db0f
If you have no subText or summaryText in a big template, but
you *do* have a number, the overflow bar (below the big text
or inbox or whatever) would have shown; now it does not.
Bug: 6657006
Change-Id: Ib2af2712da3a98227bd8d697560893adbdc427e9
