Deal with fragments being restored when their containing view is
gone.
Try to put in a black background during rotation. Currently commented
out because it appears to cause surface flinger to hang.
Change-Id: I150d061e64488356d17513f4e2d124d7c3d04f6b
the reason for bug:3281533, bug:3127159 is probably too many cursors are left
un-closed in the process.
print the info on the number of cursors left open when the exception
"cursorwindow allocation failed" occurs.
This should help us figure out if that indeed is the reason
and which process is leaving the cursors open.
Change-Id: I4b46be63f5dfbe9b102ad7a9cf9dd21e70f71e14
See change 86347 for Step 1.
New state_multiline state flag, handled in TextView drawable background drawables.
Change-Id: I230df16c7ddee3296da180fd80ef341a4ac17dc0
Note that this used to create problems with ExtractEditText. These potential issues
were not handled in that CL.
Bug 3236848
Change-Id: I4b83ce8f66eba04f34c2faa8e38b83eb992637f0
...com.google.android.youtube: java.lang.NullPointerException at
com.google.android.youtube.async.UserAuthorizer$3.onCancel(UserAuthorizer.java:324)
Only perform one cancel callback for a particular start of the dialog.
Change-Id: Ib448fcae2489a63c9b63affdc518658447e90920
When IME is being moved as part of a window going away, it could flicker
as it immediately moves behind the window. Fix this.
Also make the default soft input mode for PopupWindow to be to not change
the IME visibility, since it is a rare pop-up window that should cause your
IME to close.
Change-Id: I0b43e080ad012739e9a3e5842794c778c859ac1a
Some parts stubbed out but you can plug in a mouse and move
a green cursor around to interact with the UI.
Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
* commit '672ebb61a755e4bbe60e4e884b1adadf186733b6':
Improved ignore-backoff handling Allow a non-epidited ignore-backoff op to pass through an expidited backed off op.
The previous change only hid the fragment when the transition animation
ended. But if there is no animation, the fragment would never be hidden.
This change adds an else clause that handles the non-animating case.
Change-Id: Ie35b2ae98cb5c21193dadefbef71b8542fcf5f7d
...android.app.Fragment.startActivityForResult(Fragment.java)
Make sure to remove all pending messages when AbsListView is detached
from its window.
But... that's not enough.
It turns out that when a fragment's views are animating away, they of
course don't get detached until after the animation is done. However
the fragment itself is immediately destroyed, leaving its live views
still going after that.
Here's a possible solution: when fragment manager initiates an animation
on a fragment whose views are being removed, it makes note of that so
it can hold off on destroying the fragment until the animation is over.
There are a lot of interesting race conditions here, if further operations
happen on the fragment while it is being animated. I think the code here
does something sensible, and it does seem to work for the situations I
have tested, but it is hard to know all of the edge cases that may happen.
Change-Id: I4490ce8862a9bb714c7ea54baca3072c62126388
