isAttachedToWindow does what it says on the label and provides a
standard, public API for checking a view's attachment state. This
removes the need for tracking this out of band in response to
onAttachedToWindow/onDetachedFromWindow in custom view
implementations.
hasLayout returns true whenever the view has been through at least one
call to layout() since the last time it was attached to or detached
from a window. This allows for standard checks in code that needs to
behave differently if first layout has not completed yet, such as
whether or not to no-op an animation in order to set up initial state.
Change-Id: I8dab70dcd5a22a32e260ed50987ccdaa4100072b
The specific bug is this: SIM PIN unlock attempt toasts are
sent from com.android.settings/.IccLockSettings which runs
as the phone process; NoMan wasn't having any of that and
was blocking the toasts.
With this change we treat SYSTEM_UID and PHONE_UID the same
for all security checks, and furthermore we guarantee that
all notifications and toasts from those UIDs will be
permitted.
Bug: 9098802
Change-Id: Idc788527aa2cb38e015fe92773766a514167999e
Bug #8725945
Selecting text in an EditText causes the View to have transient
state. This would in turn cause the View to be removed from its
ListView parent. When removed, the EditText would lose its
AttachInfo, causing all sorts of problems. Headers and footers
must not be removed, only detached. This is the part of the fix
in AbsListView.
Fixing AbsListView triggered a second bug: when a View is removed
from the Window manager, it would keep its parent assigned, thus
making it impossible to add it again to the window manager. When
a ViewRootImpl goes through doDie(), it must set its content view's
parent to null to properly cleanup.
Change-Id: I0489daa74f8f7fcf85526f0928f8925ec30d4f42
When building commands to send across NativeDaemonConnector, scrub
sensitive arguments to prevent them from being logged.
Bug: 8609800
Change-Id: I84b16791749264a010f7e59f9918f68d71bac6b9
Add TransitionManager.beginDelayedTransition() to handle starting a transition
on the next frame for a given scene root based on all changes that
take place between the first call to that method and the next animation frame.
Issue #9321937 Transitions: consider batching up multiple scene actions
Change-Id: I3fc92b6b4ec5ff42b1e678bcfd385703e32eba2a
When the launcher starts a new activity don't let it change the task
type. This would cause the stacks to get confused.
Fixes bug 9323103.
Change-Id: Ie1d9c3bf85461827c7255e68003f11ed5a38f63b
We fire notifications that the a view subtree changed for accessibility.
In some cases the notifications were fired if accessibility is not
enabled. This is now fixed. Also the runnable for making the recurring
subtree change was not dequeued if it was pending but we received a
request which we decided to run immediately.
bug:9337912
Change-Id: I27401b3d11f81c653e8761a704ee530263b08c3a
Fix bug introduced by deferring nulling of mParent.
In dismissDialog the removal was being put on a queue while the
state of the Dialog was being updated immediately. This meant that
if a show() was called before the remove was executed it would try
and add the DecorView a second time. Boom!
Fixes bug 9370301.
Change-Id: I576d1e207c786bc2e21dfd40cb94f2b63a020fe2
Previously CarrierProvisioning toggle airplane mode, but now that's
available only by the system.
Bug: 9356811
Change-Id: I5167f8614c07bafb688983a360a008f76403b2b8
The specific bug is this: SIM PIN unlock attempt toasts are
sent from com.android.settings/.IccLockSettings which runs
as the phone process; NoMan wasn't having any of that and
was blocking the toasts.
With this change we treat SYSTEM_UID and PHONE_UID the same
for all security checks, and furthermore we guarantee that
all notifications and toasts from those UIDs will be
permitted.
Bug: 9098802
Change-Id: Idc788527aa2cb38e015fe92773766a514167999e
