bug:8666842
In SW rendering, a previous optimization avoided clipping to the
bounds of views that are layers. This breaks if the view fails to
create a layer (such as if it's too big), so instead look at whether
the view has a layer.
Change-Id: I653882035512012aefd91f06ff0bdc73aa5e4430
Don't work around third party app bugs on the emulator.
(cherry picked from commit fc17dc2548234461eb43ff83539ede4c9893a825)
Change-Id: I35246c447de65ad4649b9aa3eb67194234fd6378
It's not the best API to use to determine anything. Defer to other
APIs such as UserManager.getUserRestrictions()
Bug: 8720520
Change-Id: Ie49589056ab52b4fdbcc736f8cdefadb8ba5d9d8
1. The accessibility events for switching a widget were dispatched
before we update the important for accessibility property. We
were lucky to get events in some cases since the pages in the
pager had alpha grater than zero, i.e. the page was already
set as important for accessibility, due to a running animation.
2. Accessibility focus clear event not fired if we give focus to
another view. The old focus was correctly cleared just the
events were not dispatched.
bug:8599670
Change-Id: Ia2647d77eaa4e10fbaf3a047dc9ea5b728f9c3c3
- Wrap all public member variables in getters and make
slots private
- Rename clear* methods to cancel* to be more consistent
with existing public Notification API
Bug: 8656860
Change-Id: I84f7e71fbb627f859352a93089c6a531b44dac95
This allows a listener service to catch up on the current
state of the notification panel at any time, including at
startup.
Bug: 8656860
Change-Id: I1a3d665d84576e17870929a63dda334afc696010
This system-only permission allows a service to disable the transmit LED
when a camera is in use.
Bug: 8554573
Change-Id: I64f7e3fcdc8ded8be3904650bd0c91d3b8f10dd4
Since the enable touch exploration capability is dynamically granted by
the user for apps targeting pre-JellybeanMR2 API level, we have to properly
update the accessibility service info for that service and also avoid
caching copies of the service info.
bug:8633951
Change-Id: I83dd1c852706ec55d40cda7209ad842889fb970a
A call to ViewGroup.bringChildToFront() or View.bringToFront()
(which delegates to the parent's bringChildToFront() method) needs
to be followed by a call to requestLayout() and invalidate() on the
parent container in order for the changes to
actually happen. That is, the order of the child views would change, but
the parent container would not run layout or even invalidation without
being told to, so there would be no visible change until something else
caused a layout and invalidation to occur.
This change clarifies this requirement in the javadocs.
Issue #8667065 bringtoTop does not work
Change-Id: Ibe41a6318dddf9fb79382e1c9fd1d21ab4510976
