AccessibilityNodeInfo refresh was getting the latest cached
state but this is not good enough as an accessibility service
can execute an action on the node and then refresh it to get
the new state.
bug:16954787
Change-Id: I004b4987b8dc423a2ab7031a4fbfe64365ddd7fe
(cherry picked from commit 5738fec00db65e0ee246475a7236e57ba3ee8d55)
This change prevents the Runnable posted by ActivityContainerCallback
from retaining the ActivityView's callback if it is never cleared out
from ViewRootImpl.sRunQueues.
Bug: 19872883
Bug: 19654978
Change-Id: I6dce4381b96c8c77afcd38a55bfe474f13dfbfba
I am not sure if this is the correct approach to the problem. Right now
we are reporting double chin (60 vs 30). The reason for this is that
we setDisplayPadding from Clockwork Home activity (bottom=30) and add
windowOutsetBottom.
We use display padding to set surface frame size (320x320) and both
outset bottom and display padding for inset. I think we should use only
one of these. I decided to go with display padding, because that's
what was suggested to me the last time I visited this. I removed
the dependency on windowOutsetBottom altogether.
However, I don't feel confident this is the correct way to do this.
We depend on Home activity to send the display padding now to get
the correct result, so wallpapers behind other activities will not
work correctly.
Maybe instead of setting display padding from the outside, the
windowOutsetBottom should be added to display padding bottom for the
purpose of calculating surface frame and generating insets.
Advice on what is the right approach here would be greatly appreciated.
Bug: 19881056
Change-Id: Ifb655528d8f85ef01d942bf1e64e8b08475689ca
Change way in which an outside caller can get the preferred SSLContext.
(cherry picked from commit 8a970637208207955fb6a719bd82902384b3c743)
Bug: 19798387
Bug: 17136008
Change-Id: Ide578664bcb605304322bfddd2e640a63042fa09
Problems arise if an activity is started in an ActivityView when the
parent activity is not resumed. In particular the ActivityView can
be brought to the front in front of other activities that have been
started by the parent.
This change checks the state of the parent when the ActivityView is
starting and if it is not resumed, throws an Exception.
This change also removes the queueing up of Intents if the surface
does not exist when startActivity is called. Now, the owner of the
ActivityView is notified when the surface becomes available. If
startActivity is called before that notification an Exception will be
thrown.
Fixes bug 19147472.
Change-Id: I6712cf1929fe65c4238ce7f3feb4e8511ed97244
Due to a bug caught late in the release, this API is broken
and should be removed from API 22 because it's too late for
a fix and there's no workaround.
Bug 19461292
Change-Id: Ib0757a4484b14afe7f83ae9527bb3f5f4834ee62
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
Path can be null if sd card was ejected, and we shouldn't make a thumbnail
in that case.
Bug: 19380821
Change-Id: Iee69effdd321622de026ad7b57c74cf9da81a176
A security leak was discovered whereby a malicious app could get the
IActivityContainer object from one app and use it to inject events
into another app. This fix removes the availability of the
IActivityContainer and replaces its one use with a method for
returning the information the IActivityContainer was used for.
Fixes bug 19394591.
Change-Id: Ib3cec25b25130cd8e098892c057742cfd575cfdd
