Bug 17936593
Instead of calling setLeft(), setTop(), setRight(), setBottom()
separately, make one call that does all at the same time.
Change-Id: I986274f3a98b3136e71204501ffc272986ad31dd
For now, only animators use it but we can consider migrating
drawable cache to it as well.
Bug: 17456416
Change-Id: I571b96856805edb171f0fc52e6bff5a365f46b70
An accessibility service may register to observe the interactive windows
on the primary display. These windows are the one that has input focus and
ones a sighted user can touch. It is sometimes beneficial for an
accessibility service to overlay a window to intercept user interaction
and based on that introspect and perform an action on the windows that
are on the screen. This is problematic as overlaying a full screen window
that is touchable prevents the accessibility service to introspect the
content under this window.
This change adds a special type of window that only an accessibility service
can place which does not affect what an accessibility service can "see" on
the screen. Hence, even putting such a window full screen the service will
be able to interact with the other interactive windows it covers.
Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
The Lollipop release introduced a feature that allowed
apps to extend under the navigation bar. This also means
any popup window that is anchored to the bottom of its
parent window will overlap with the navigation bar if the
parent window is extending underneath the navigation bar.
This change introduces a new window flag
(FLAG_LAYOUT_ATTACHED_IN_DECOR) that allows the app to
specify if the popup window should be attached to the decor
frame of the parent window thereby avoiding an overlap
with the screen decorations.
By default the flag is set on SDK version LOLLIPOP_MR1 or
greater and cleared on lesser SDK versions.
Also, replaced flags FLAG_NEEDS_MENU_KEY and
PRIVATE_FLAG_NEEDS_MENU_KEY_SET with needsMenuKey state
variable to make room for the new
FLAG_LAYOUT_ATTACHED_IN_DECOR flag.
Bug: 17789629
Change-Id: I2150e0c6ac688c966c0e8f7e54d42fd20285bea6
Updating the accessibility layer behavior to reflect the new
model where accessibility no longer overrides strong encryption.
Now enabling an accessibility service lowers the encryption
level but the user can bump it up in settings if desired.
bug:17881324
Change-Id: Ic60d760c267d3f934040a42e1963b179bd8b9f5f
If a view hasn't explicitly requested layout and it's asked to measure
with MeasureSpec.EXACTLY in both dimensions and sizes that match its
current measured size, the measure operation is a no-op.
This helps out a number of ViewGroups that perform initial speculative
measurements with AT_MOST or UNSPECIFIED followed by looping over
child views and measuring EXACTLY to lock in the final measurement
with perhaps some extra leftover space distributed. In practice this
happens a fair bit, especially for views high up in the view
hierarchy. This optimization allows ViewGroup measurement code to be a
little cleaner in not having to keep track of this on its own.
Change-Id: I88ff46a7d37aeda7a4cd16204b68cab0d051b341
If nativeUnlockCanvasAndPost() throws, Surface was maintaining a
reference to the native Surface, and assuming it was still locked.
That would cause future lockCanvas() calls to throw without even
trying to lock the native Surface, even though in some cases the
native lock was actually released before the exception was thrown.
Now Surface treats the native object as unlocked even if
nativeUnlockCanvasAndPost() throws, so it will attempt the native lock
on lockCanvas() rather than assuming it would fail.
This change also changes an IllegalStateException to
IllegalArgumentException in unlockCanvasAndPost(). That exception was
added in KitKat, and was never documented or added to the throws
declaration. This was essentially a silent public API change. Quite a
bit of code in the framework (and likely in applications) catches
IAE from this method, but didn't attempt to handle ISE. Although ISE
is more correct here, it's not worth breaking code (and it did -- in
this bug it changed a problem that should have been silently and
perfectly recovered from into a fatal exception in system_server.)
Bug: 17684556
Change-Id: Ia8d3e5d33eaa690d16c7d0f557390c7bb4e1e32e
When reporting views to accessibility services we are ordering the
children in a parent based on their location on the screen. The
initial implementation worked pretty well in practive but violated
the transitivity property leading to rare crashes in apps. The current
implementation does not violate transitivity but does not produce
good ordering.
Given the lack of time and to minumize risk this change uses the
old strategy which works most of the time and if that fails we
fall back to the current strategy. Coming up with a correct strategy
that produces good results requires more time.
bug:17887986
Change-Id: I1c233ecdf318befc315e793696ac48bd6c652ab6
Negative margins can cause all sorts of other problematic assumptions,
subtle errors and unexpected behavior. While they technically work
developers should steer clear of them.
Change-Id: Ia1f7d9a33e25444ebdc3c32679ae1179210558e1
Help developers during debugging bad calls to addView by throwing an
IllegalArgumentException earlier rather than implicitly tossing NPE
the first time the child view is accessed.
Change-Id: I4a554635815a5d0b415f637b93592fb45973f26d
