Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
Some ANR bugs are very difficult to localize because by the time
the bug report has been captured, the relevant information is
gone. Work around this by capturing a log of the input dispatcher's
state at the exact time of the ANR before anything has changed
and include this information in the bug report.
Also fixed a nit related to some format strings that had
improper field widths specified.
Bug: 6680398
Change-Id: I5323bf18ec5e47a767cd053209753cc46852bf4c
MediaRouter dialogs now intercept the volume keys for altering the
current volume. The status icon indicates if the slider/buttons are
currently controlling the local device volume or a remote device's
volume.
Group volume for user routes is handled by using the
RemoteControlClient supplied by the first route in the group.
Change-Id: I40a0d054847ed5acce7a4c3b669487841b4dca15
Improve the API around ActionProvider visibility overriding. Allow the
application to notify whatever is hosting the ActionProvider that
visibility has changed in a way that is friendly to alternate support
library-style reimplementations of MenuItem.
Allow MediaRouter.Callback implementations to add or remove themselves
or other Callbacks during dispatch of callback events.
Make MediaRouteActionProvider track the visibility of corresponding
menu items more accurately.
Change-Id: Ic7ddb6a87c3637904750d2661e4a9fa323b09ea0
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
...in Developer options is on
Don't respect stay awake while on as long as a time to lock limit
is being enforced. When we start enforcing one, make sure the
setting is off (since we won't be respecting it anyway).
Bug: 6664140
Change-Id: Id07cb528afa0c64c7766341841c51771f507121d
The AudioService now has an API to call to get the currently
connected devices, and later reports of changes in connection
state. The information includes the name of the bluetooth
device if one is connected for display to the user, and states
for all of the pluggable devices. No longer requires a Bluetooth
permission to keep the routes updated.
Change-Id: I81ca421c60592fbc1592477d59bf1c9d1b64954a
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
Come back to old versions of setBluetoothA2dpOn() and isBluetoothA2dpOn().
MediaRouter will call methods on IAudioService directly.
Change-Id: I18f0a3106bad78715ed11a6b7b4ec1d656cdae41
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
We now track whether the device is connected at all, and use
this to suppress the disconnected message in the mobile
status string (we previously just looked at wifi
connectivity).
So, if a device is attached via ethernet:
- On wifi-only devices, the combined label is shown in the
notification panel, so you'll see "ETHERNET" (this comes
straight from EthernetDataTracker; at some point we need
localized strings and icons).
- On mobile-data devices (phones), the notification panel
only shows the mobile data label, which will be
suppressed, so you'll see nothing at all.
Bug: 6648292
Change-Id: I9841eaeffe50a4f046afbdc09d80c5bd4d78a839
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
This fixes a bug where the user uses the MMI sequence (**05*PUK*PIN1*PIN1#)
from the EmergencyDialer to unlock their phone instead of the provided interface.
The code now recognizes when UnlockMode becomes invalid because it was previously
locked because of SIM state. It then dismisses the PUK unlock screen and advances
to the home screen.
Change-Id: I8902350e6f640cd2fa0af3460c3ea1a39d926c8a
Prior change 199020 fixes it for instances of CarrierLabel;
this fixes it for customers of NetworkController.
Bug: 6639047
Change-Id: I69dada2298f4a3caf453f43d847cdb32fe7eaa9f
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
People generally expect, if they are using FLAG_KEEP_SCREEN_ON,
that the screen won't immediately dim after it is cleared, even
if it has been passed the user activity timeout since the last
user interaction. So include the flag to reset the user activity
timeout when releasing its wake lock.
Change-Id: If7a8fea8faef3edbf13dff10a2f248adc9e3ff0b
