Calling requestLayout() during a layout pass is inadvisable, but
happens often enough in applications (especially when it occurs in
very indirect means that the application may not easily be able to
control) that we need to handle the situation without breaking. In particular,
applications that have run across this problem have had artifacts which are
difficult to debug (like things just not showing up on the screen) and
also difficult to fix. One of the side-effects of the problem is that it
leaves the view hiearchy in an unpredictable state where some views have
requested layout and are waiting to be layed out while the root view has
not received those requests, so it is never calling layout on those views.
The fix is to try to do the 'right' thing, while avoiding getting into
an inifinite loop (which could result from calling layout, which calls requestLayout(),
which causes another layout, which ...). The solution is two-tier: we handle
all requests that happen during layout by delaying them until after the current
layout is done. We then process those requests and call layout again.
If we receive more requests during that second layout, we post them to the
next frame, to allow us to finish the current one.
Issue #7155974 handle requestLayout() during layout more robustly
Change-Id: I9d13c405be28a19c86add22210e69817ddddaf8b
Add a setting to globally disable Wifi display.
Fixed a bug where the wifi display broadcast receiver
was running on the wrong thread.
Removed the wifi-display QuickSettings dialog, all functionality
has been moved to Settings.
Bug: 7178216
Bug: 7192799
Change-Id: I9796baac8245d664cf28fa147b9ed978d81d8ab9
Bug #7186819
This optional OpenGL extension can be used by tiled renderers to optimize
copies from main memory to tiles memory.
Change-Id: Id4a5d64e61ad17f50e773e8104b9bf584bb65077
Previously, this flag conflicted with other text direction flags,
which can cause weird interactions across the View hierarchy,
specifically with ListView.
Also adds dumpFlags() utility to dump values of all know flags for
documentation and sanity checking.
Bug: 7189738
Change-Id: Iceb2f93f68a800e19a5889ced93abcce4932b067
When a user is removed, migrate all network stats belonging to that
user into special UID_REMOVED bucket. Also removes those stats from
kernel to avoid double-counting if another user is created.
Bug: 7194784
Change-Id: I03f1d660fe3754566326b7749cae8068fc224ea9
Dream manager now fires broadcast intents when entering + exiting
dreamland (except when testing).
Power manager can now listen for dreams ending, using polling only
as a backstop.
Also:
- Bullet-proof dream-manager/dream against known failure modes
- Add new read/write dream permissions
- Refactor dream-manager to delegate work + state management into
a new DreamController class, via a handler
Bug:6999949
Bug:7152024
Change-Id: I986bb7812209d8c95ae1d660a5eee5998a7b08b1
Activity manager now updates window manager's current user id
directly and immediately rather than waiting for a broadcast
update. Window manager passes this through policy to the
KeyguardViewMediator and into LockPatternUtils. LockPatternUtils
no longer goes to Activity to get the current user id if it finds
that its local id is non-default.
Fixes bug 7193726.
Change-Id: Id5613e7a9fe9e5b49e83c26b74504f587c3998c2
... until we have a solid fix for the singleton ContentProvider
problem cases in place.
Bug 7190837
Change-Id: Ibbef2ddc594896ba7b9217e2856c3e393f525af6
The way it should have been, and with the new recents enter animation
the way it must be.
Added a new method to retrieve this thumbnail, since it would be less
efficient to use the existing API (which always returns the "base"
thumbnail). Probably at some point that existing API should be tweaked
to always return the top thumbnail instead, but that is for a later time.
Also removed code that would clear the thumbnail associated with an
activity when it is resumed. I don't think there should ever be a
reason to clear a thumbnail -- it's much better to have *something*
for the task, even if it is a little out of date.
Change-Id: I83e6ca6403eb2df5e4de3009dfe8c210e8cf8d5b
