If the window maanger received BinderDied for a starting window
before activity manager then it would null
AppWindowToken.startingWindow and not go through the
PhoneWindowManager.removeStartingWindow call later. That meant that
Surface.release() was never called from
ViewRootImpl.dispatchDetachedFromWindow(). Which in turn meant that
graphics memory was being leaked.
This change notifies the PhoneWindowManager to go through the
removeStartingWindow path when the starting window gets removed for
any reason.
This change also ensures that scheduleRemoveStartingWindow is
always called with the window manager lock held.
Fixes bug 17381033.
Change-Id: Ic6860d0e1410c9bb5053d85ae21a08b11f573b6d
We missed the alpha for the vector drawable root level in the documentation.
And the animation target can be vector drawable itself for the alpha value,
which is more than path and group object.
b/17696183
Change-Id: Ic9d441fbdf411dad92718ae5adbc6655fe708453
When calling getContentProvider() across user boundaries, and
creating the provider for the first time, we need to clear caller
identity. (We could have torn down the provider while the system
was under memory pressure.)
Bug: 17409650
Change-Id: I67713a03e5f7106f5e8fcf33fe3fdae81ce644ec
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
The app is no longer useful if the underlying Network has disconnected
and could get in the way of another signing into another Network.
bug:17672087
Change-Id: I26e820444640975e7fd4dd73244f4d4f4b40cb5e
Drop down the limit on when we log, since under normal operation we
will never get more than a few K of data due to strict mode.
Try to clean up the code paths coming in and out of binder IPCs to
plug any places where we could disrupt the gather flag of a thread,
causing it to keep gathering stack crawls (which is the thing that
is causing our strict mode data to become so large).
Change-Id: I9a46512283d33e863c429840b465855d1fabb74e
Also consolidate roaming logic while here, to make it easier to
maintain.
Bug: 17514906
Bug: 17619763
Change-Id: I8efabdecc26722ff6ac70d715f3befaae989abdc
Per UX request:
- remove PreferenceHeader list divider
- make list item primary/secondary text using the correct themed list item
text appearance (so that they can be overridden)
Change-Id: Ie0cadf81914cf208434a342829a48b5a1df62141
Revert back to (mostly) KK behavior, fix a problem where we were
collecting some data in an inconsistent state.
Change-Id: Ida3ca3fb734a9d7d61a90fd5044152e927c59e02
Remove the checks for large parcel sizes. Those were triggering,
and identifyng the area of the problem, but also cause a lot of
trouble by making the unsafe deadlocky code there much more likely
to deadlock.
Add logging for strict mode IPCs, since those seem to be the
problem. Only log when things look bad.
Also add a log when battery stats are reset, to diagnose why they
are getting reset when they shouldn't be.
Change-Id: I588c858fb8d8c45f3c9c164ae2de9ae01547b304
