Bug: 17765082
DeferredLayerUpdater had fallen behind RT updates. Re-snap to
latest expectations, ensuring to call requireGlContext() prior
to detachSurfaceTexture to avoid leaking SurfaceTextures
Change-Id: Ic65fb9831e5284f658866da8da9ad5af1d227699
Bug: 17578553
Games seem to be doing this to prevent destruction of their
GL contexts, and they assume it works even if it doesn't. However,
GLSurfaceView is clunky here, so while the app is doing something
questionable we don't really offer a better way. For now revert
back to kitkat behavior.
Change-Id: Icfa9e496279b9cfa47f9bc7f6848d9313caed0d5
When the status guard is not available, (e.g. when the window is not
drawing system bars) do not consume the insets when an action mode is
active.
Bug 17691453
Change-Id: I459622eaf161a96152fb9ac5f60bb9508aa4de89
When device is encrypted the user has to authenticate in order to decrypt
the data partition which is required for running accessibility services
and Text-To-Speech. In order to address this issue we are falling back
to use the default password if there is an enabled accessibility service
and the user has secure lock. This will enable the user to authenticate
when accessibility layer is completely functional.
bug:17671790
Change-Id: Iafffe7bcd234008cf91ffb5011b21b803dca227a
Bug 17671834
GhostViews can be added in arbitrary order since they are added
depending on how they are insterted into the TransitionValues
maps. This CL does two things: it ensures that GhostViews are always
pulled to the top of the Overlay and inserts GhostViews into
the Overlay in the order that their ghosted views are drawn.
Change-Id: I9f68105126834cc8f30a6cfe5d58fc3c51465afd
If the virtual child id is not specified we should ask the node
provider to create a node info for the hosting view bu passing
the special host node id.
bug:17664111
Change-Id: Iaf1387acdfe33b50b50729d293adcdf82340a648
If the virtual child id is not specified we should ask the node
provider to create a node info for the hosting view bu passing
the special host node id.
bug:17664111
Change-Id: I9c2d3195ad813eed7ea4108fe0d7ccb9cc32a1a0
When getting an accessibility node info we also prefetch its predecessors,
siblings and descendants up to fifty. If a view has a node provider, i.e.
virtual descendants, and the id of the virtual descendant is not specified
we use a speacial constant to refer that the provider should create a node
for its hosting view. The bug was that we were not using the correct constant
when calling into the provider.
bug:17664111
Change-Id: I4f6b2333e1e7e3e2bb6b164c0752613417c60d16
In accessibility mode we compute a location to where to send down and up
events to click a view (triggered by a double tap). This solves the problem
of interacting with views that are partially covered by other interactive
views. The logic that computes the click point was not ignoring siblings
that are not visible. As a result a blind user cannot interact with some
views.
bug:17632224
Change-Id: I93e637ee6702e4ba3e79faa736205430e2196d01
Once upon a time when the world was fresh and new, the heavens
had an easy rhythm. Day and night. Night and day. In the day,
the pixel fairies would cavort and play in the bright gardens
with narry a mark of shadow or gloom. In the night, they would
rest peacefully, dreaming no dreams and knowing no fear.
Then one night a fairy dreamed the first dream. At first
the dream was peaceful, full of colors and delight, hopes and
memories. Then all at once, jarringly, it awoke in bright
daylight. The pixel fairy knew fear, for the world had changed
and it was unprepared.
Time passed and the pixel fairies grew accustomed to their
fate, day and night, night and day, sometimes dreaming, until
there came a night when a fairy did not sleep. It roamed
the land in a dreamless doze, lost and afraid amid a grim haze
of grey and darkness. The fairy despaired. It wanted no
part of this place. It pretended for a time to be awake but
the bright daylight would not come. It pretended for a time to
be dreaming but the colors and memories would not come.
That is when the fairy wished for oblivion. Then just as
suddenly, it awoke in the daylight. It fell to the ground,
stunned as if it had forgotten how to walk in the too bright
daylight.
Though the world again grew softer and kinder in time, the pixel
fairies were never the same. For the night is dark and full
of terrors.
---
It used to be easy. Screen on and screen off could explain almost
everything about the state of the device but it's different now with
ambient display. We need to be able to wait for all windows to be
drawn even in the case where the device is still nominally asleep.
In truth, the window manager policy which drives a lot of these
interactions is a thicket of outdated assumptions.
Added a new method to tell the window manager policy when the screen
is being turned off so that it can correctly account for changes
to the interactive state (wakeUp and goingToSleep) and screen state
(screenTurningOn and screenTurnedOff). Now we can independently
poke keyguard during interactive state changes and we can apply
screen on blocking during screen state changes.
Moved the code which manages screen on blocking (which is what
ensures the UI has fully drawn before revealing screen contents)
from the power manager to the display manager since the display
manager is in a better position to accurately track the state of
the screen, particularly when the screen is being turned off.
Fixed a bunch of synchronization issues. Previously some work
had been moved to a handler without considering what might
happen if it became reordered relative to other work happening
elsewhere. Documented the desired behavior in the code to
prevent this from happening again.
There's still a bunch of stuff in here that isn't quite right,
particularly the assumption that there's only one screen, but
it's good enough for now. Hopefully there aren't too many bugs.
Bug: 17605802
Change-Id: Ic7319e09948c8a3cda014d7e169c964a3ad86f14
Bug: 16978006
Don't HWUI-accelerate KeyguardScrim
Aggressively trim memory as soon as a ViewRootImpl
dies or has its visibility changed.
Change-Id: Ie1b7c9d30653456bd2e9f309128174f972999368
We were not clearing the cache if window state change event
is fired which was the behavior before adding the window
inspection APIs. As a result if no accessibility service
cares about windows we get a leek. Also when the accessibiilty
service cares about windows we were not clearing all windows
nodes from the cache. Now if a windows change or a window
state change event is recived we clear the cache.
bug:17589257
Change-Id: I8c416fbcab623160c6f505128b9fca713fcc6623
This allows us to ensure windows are fully drawn before unblocking
screen on while dozing.
Bug: 17516245
Change-Id: Ibe63c212b8db855ce26a34a8169f33764b266ee6
This CL is a follow up CL for I6571d464a46453934f0a8f5e790.
Do not propagate Resources.NotFoundException to the caller
of InputMethodInfo.isDefault().
BUG: 17553712
BUG: 17549437
BUG: 17517332
Change-Id: Ie95880c1f68f49eb63518e69b7dfa20af3ce8737
Bug: 17516789
This change corresponds to a sudden influx of bad surface crashes.
Reverting to see if stability returns as this was an optimization
CL
This reverts commit 29ff1bc57ac2c995c56f15ed6e56e5fb247b2a44.
Change-Id: I7835e89017161d94ad05fe46d81bd437c3dae3a7
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
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
