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
ViewDebug uses getStyleAttributes to get the attributes, and then gets the
attribute name and value so that Hierarchy Viewer can display it.
Bug: 17407087
Change-Id: I3577e32ae99668383701dc908bb46db14a75c3c4
Bug: 17317184
Unfortunately this will disable *all* RT animations in a scene,
but we don't have more selective targetting currently
Change-Id: I57e1c0ae43957f45229473bdcdaf34c05825fab7
Makes hotspot-centered ripples "just work" everywhere that old-style
pressed states work.
BUG: 17407652
Change-Id: Id4802662aea537959122f029e85aa576cf51b641
We need to allow for event dispatching in non-interactive states so
that we can enable a richer set of interactions when a device is
dozing (i.e. is in a low power state with an Always-on-Display).
Bug: 17167296
Change-Id: I8ae0f544a8106cb91ff38c2309b8b57cbe2f2c72
bug:15780987
bug:17350602
Also update docs around clipping nesting behavior,
and some Z ordering behavior.
Change-Id: Iaa204350a0adfdcbd8c4b821fb4a9c0ae22f2613
