1. Accessibility events for change in the window content are sent
with a delay and code performing the send does not check the
accessibilitys state before sending the event.
bug:4980754
Change-Id: Ice68037ebab9c5dcd0dece927765585e13959c0c
Once we switch out from full screen mode, the player will be re-created for the
next video, we should release the sources as early as possible.
bug:4332676
Change-Id: I4c26523b3600d3100f81e422979236fca57beb7c
Both stats and policy make NMS calls that depend on bandwidth control
being enabled, so move enable/disable into NMS and drop calls when
disabled. This avoids throwing heavy ISE exceptions when disabled.
Only include recent data when writing NetworkStatsHistory as part of
dumpsys call. Introduce manual poll event for Settings UI.
Bug: 4982115, 4770435, 4515856
Change-Id: I257820b057af2f0f99c736fb4f61e55b9fdc3e66
Better activation experience:
- Hold off on switching out targets until current animation has finished.
- Hide unselected targets when a target is selected.
Code simplification:
- Use explicit callback objects to handle animation updates instead of having MWV implement the interface.
- More compact chevron-loading code.
- Don't use animations for properties that need to change immediately.
Other minor timing tweaks.
Change-Id: I328533e8ab7b4c69c7ba51c8c55002765dcbbd46
Fix bug 4976004 - bad title measurement for split action modes
Fix bug 4902960 - action modes leaving a hidden action bar in a bad state
Sync with design for the behavior of various permutations of action
bar configuration + modes.
Change-Id: Id75f6b5911b761fabc5fef2cc2600ce197cf9a92
In case of non-standard load such as reload, currently the ZoomManager's
onFirstLayout will not be triggered, hence initial zoom overview will not
be set.
This change provides a fix to set initial zoom overview in case of
non-standard load for the new picture after first layout.
issue: 4975315
Change-Id: If2ba3e472f2bb7b6fc4c52024d18a66dc1e41a23
Report out of service if we don't know any better. Sometimes when switching radios
we were finding nulls reported - it crashed some code and highlighted this problem.
If we don't have a service state we're certainly out of service, so this isn't a lie.
bug:4553701
Change-Id: I094798a5f9f39f45c0ba30179aaa8f88f9b3e405
Fixed a warning identified by the InputEventConsistencyVerifier
due to some code that synthesizes a touch event which it sends
to onTouchEvent with no input device source specified.
This is generally harmless but a fake source is better than
none in this case.
Change-Id: I44cfa36a4746f598f8fde3086084af3896e2ba2a
Location manager now checks for such intents, and logs a warning when
they are given to it. Nothing thrown yet, it needs to check the
targetSdkVersion of the caller somehow.
When sending the pending intent, we require that the recipient hold the
appropriate permission. This should pretty much close the security hole.
Includes a bunch of infrastructure in the activity manager needed to
support all this.
Change-Id: I4dba7a98a7b8bbb9e347666451aa9cb1efad1848
