Fixes an issue where window insets were not further dispatched
if all happen to be zero. To prevent further dispatch, the
insets must now be consumed explicitly.
Bug: 17522145
Change-Id: Ia8f6c10c8369b58db7a7cf49f8bcc2cab8e304f1
We were invalidating the view during outline invalidation far
too often. Sometimes, it's appropriate to invalidate the view when
the outline changes, but not when the outline is being invalidated
in the middle of drawing the view, which is done in reaction to a view
invalidation.
Issue #17460940 Volantis: panning in Calendar from month to month is only at 30fps
Change-Id: I7bdee17dc9c7df89d4cd3d781010823cef931222
With this CL, the behavior of getDefaultEnabledImes() changes
as follows:
- Previously system IMEs are always enabled by default as long
as it is a software keyboard that supports En_* subtype. With
this CL, getDefaultEnabledImes() relies on the locale returned
from getFallbackLocaleForDefaultIme() instead of calling
isSystemImeThatHasEnglishKeyboardSubtype() to minimize the
number of enabled IMEs.
- Previously default enabled system IMEs are chosen in a
country-agnostic way. As a result, "en_IN" is enabled even
when the system locale is "en_US". With this CL, the system
first tries to find IMEs with taking the coutnry into account,
and use the country-agnostic way when and only when fallback
logic is required.
BUG: 17347871
Change-Id: I6571d464a46453934f0a8f5e79018a67a9a3c845
The current hidden API is necessary to perform correct inset behavior
for support libraries like appcompat. Provide a public method
consistent with the new WindowInsets APIs.
Bug 17411097
Change-Id: I71a63eea0238b94cae6b5c6f1721d5567560ba81
* commit 'a7027783e39e4da9ef6cc66a200746ffb81e720e':
Show all windows from activity that hides keyguard
Make sure FLAG_DISMISS_KEYGUARD brings up bouncer
This CL removes old API signatures marked as @removed
in the follow CLs.
- Ic8c6fab58c01206872a34e7ee604cdda1581364d
- Ia8cbb9f6b41cd9509fc0147fd68763dfde593ffc
- I772c48ff18918e48a81e807b48ff907614485c09
This is just a clean-up CL. No behavior change is intended.
BUG: 17200900
BUG: 17320996
BUG: 17365414
Change-Id: Ibfbd5cc1cdebb8851c73477cff55c9b2d631fdea
Popup windows from the activity hiding the keyguard weren't being
shown. This change retrieves that activity from PhoneWindowManager
and applies the show or hide call to the windows that match the
activity.
Fixes bug 16479813.
Change-Id: Ia6fe97240aec85c5233eee9038138f7d48095a6e
View methods that previously accepted a TypedArray to initialize
parameters parsed from xml cannot be used correctly by apps. The
TypedArray passed must always be obtained from a context using the
filter array com.android.internal.R.styleable.View, which is not
visible to the SDK.
A previous change already made this safe for existing apps already
using it so that they don't crash, this change removes these methods
from the SDK entirely.
Change-Id: I62099087ad6fd5bf8363e863b04fd0434b8cdfca
An earlier fix in L disabled hw acceleration for the starting window
after the system process became hw accelerated. This was done to preserve
the old behavior of the starting window having some default behavior
(in particular, being filled with a default color). However, this ends up
being a memory and performance problem on some platforms (memory because
some platforms have backing store for software surfaces, performance
because it takes far longer to create a screen-size software surface than
a hardware surface).
The fix is to allow the starting window to inherit the hw acceleration
behavior of its process, and to detect when we are drawing the contents
of that starting window and to fill it with a default color (black).
Issue #17443449 use hardware rendering for app preview window
Change-Id: I8be8111d9e38c51fbbc07185acca065815ce26dc
Bug 17006497
Window content transitions were being enabled by default in
the Material Theme so that Activity Transitions could be
enabled by default. Unfortunately, this gave the effect that
many applications did not want -- the default transition between
window content is a fade out/in. Here, a new attribute is
added: windowActivityTransitions that is enabled by default
in the Material theme and windowContentTransitions is disabled
by default in all themes.
Change-Id: Iab453d608f00a48ff7ab7f09ce84b52cf5f20294
This is a groundwork for subsequent CLs that are
supposed to improve default input method selection
logics.
Historically we have had a @hide constructor of
InputMethodSubtype. However, this contructor is
a bit obsolete because we can not specify some
parameters that were added in recent platform
releases. We should use InputMethodSubtypeBuilder
instead.
BUG: 17347871
Change-Id: I72ad79682a58344e14380eb20e26edf98aee37cd
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
In touch exploration mode an accessibility service can move
accessibility focus in response to user gestures. In this case
when the user double-taps the system is sending down and up
events at the center of the acessibility focused view. This
works fine until the clicked view's center is covered by another
clickable view. In such a scenario the user thinks he is clicking
on one view but the click is handled by another. Terrible.
This change solves the problem of clicking on the wrong view
and also solves the problem of clicking on the wrong window.
The key idea is that when the system detects a double tap or
a double tap and hold it asks the accessibility focused node
(if such) to compute a point at which a click can be performed.
In respinse to that the node is asking the source view to
compute this.
If a view is partially covered by siblings or siblings of
predecessors that are clickable, the click point will be
properly computed to ensure the click occurs on the desired
view. The click point is also bounded in the interactive
part of the host window.
The current approach has rare edge cases that may produce false
positives or false negatives. For example, a portion of the
view may be covered by an interactive descendant of a
predecessor, which we do not compute (we check only siblings of
predecessors). Also a view may be handling raw touch events
instead of registering click listeners, which we cannot compute.
Despite these limitations this approach will work most of the
time and it is a huge improvement over just blindly sending
the down and up events in the center of the view.
Note that the additional computational complexity is incurred
only when the user wants to click on the accessibility focused
view which is very a rare event and this is a good tradeoff.
bug:15696993
Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
This CL introduces CursorAnchorInfo.FLAG_IS_RTL for better
RTL support. This CL also renames *CharacterRect() with
*CharacterBounds() so that they can look more consistent
with other existing APIs.
Rationale:
CursorAnchorInfo.FLAG_IS_RTL addresses following issues.
1. There is no way to associate the RTL information with
the insertion marker.
2. Returning mirrored (right < left) RectF for RTL in
CursorAnchorInfo#getCharacterRect() is turned out
to be bug-prone. Such usage of RectF is not fully
supported. For example, RectF#isEmpty() always returns
false when right < left.
3. There is no reliable to provide the RTL information
when CursorAnchorInfo#getCharacterRect() returns an
empty (right == left) RectF. Perhaps we could use +0.0
and -0.0, but I'm afraid that it is also bug-prone.
BUG: 17365414
BUG: 17335734
Change-Id: Ic8c6fab58c01206872a34e7ee604cdda1581364d
