If setView() will be called from two different threads
then mView property of a View object may have inconsistent
value. For instance, setView() may set mView to null causing
NullPointerException. Synchronize root.setView() as well to
avoid this.
Change-Id: I5f9cf47ece5d4aca575bd8644ecfcee0ed43d843
Fix issue #30766518: Document what targeting N does
Also small documentation cleanup in a few other places.
(cherry picked from commit b34cbedb4e)
Change-Id: I9560b29faa4f2674277349272af8193122a1f95e
The onKeyMultiple() event captures simulated, not actual, presses of
the same key in rapid succession. Adjusted the method definition to
include this clarification.
Bug: 2335983
Change-Id: Id01182d81dafe98df9e559ff24f9e1d5a1f949c3
getCurrentInputMethodSubtype() acquires InputManagerService.mMethodMap
within its body. There seems to be no reason for holding
InputMethodManager.mH to call getCurrentInputMethodSubtype(). Holding mH
can cause potential deadlock b/w two threads acquiring mH and mMethodMap
in different orders.
Bug: 31247871
Bug: 31273203
Bug: b.android.com/218423
Change-Id: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
The following changes are in this commit:
Avoid destroying TextureView surfaces for onStop
bug:30238922
TextureViews will hold onto their backing surfaces, which will allow
them to resume gracefully when the app's surfaces are saved.
Now only resources that are destroyed for onStop are DisplayLists.
(cherry picked from commit 391d560402)
TextureView: destroy layer on destroyHardwareResources event
bug:30468770
(cherry picked from commit 1c16c37d86)
Fix NPE in TextureView
Bug: 30651595
(cherry picked from commit 3c2587f26e)
Fix NPE in TextureView
Bug: 30779663
(cherry picked from commit 7e237189c2)
Fix maps resume being blank
Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
(cherry picked from commit 03df0834e6)
This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d)
Document that getClipDescription() and getLocaState() do not return valid data
when getAction() == DragEvent.ACTION_DRAG_ENDED.
Bug: 30016099
Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
Previously the DisplayMetrics passed to a new ResourcesImpl
object would be generated from the default DisplayAdjustments.
We now use the correct DisplayAdjustments for the ResourcesImpl
and make sure to update them for things like rotation changes.
Bug:29619314
Change-Id: If2ba0d7670a4554dcd3fde9766e2337f20a191fd
(cherry picked from commit 8e8d23214a)
Fix a regression where a change in insets would forceLayout on the
view hierarchy but not run the measure/layout as a result. This would
cause layout requests to become stalled until a window-level relayout
event.
Bug 29634368
Change-Id: Ia3f32f5891c8b32c06c13f95ebd0572233572b04
Bug: 29586513
Also gives BackdropFrameRenderer a direct-destroy
of Choreographer since it's hammering on new Threads
and we don't want to wait for the GC to release
FDs.
Change-Id: Id2ec0af2ee4d5304961c4ab87a104ccb92f35fc2
Bug: 29547000
Instead of shifting the window off screen fall
back to the UI-thread calculated values. This fixes
a race issue around tear-down where we stop
drawing long before our window is actually no longer
visible, as well as fixes a funky issue with
PRESERVE_GEOMETRY during first draw.
Change-Id: I792d1966f5aaee1e703295ae79166c723b97a1dc
Make sure that when our Resources get updated, that DisplayAdjustment
and Display properly reflect the potentially new screen dimensions.
Bug:28388969
Change-Id: I340550ea094ece87abc8790dd46aaa60ab3cedd3
No longer release permissions in finalize(), so that
apps do not have to maintain a reference to the
DragAndDropPermissions object.
Also make it parcelable, so that permission instances can be
retained across activity instances so that they can be
manually released.
Bug: 29162822
Change-Id: Ie604dd3e83ee45a8665d743449b91857dd54e896
We might have a pending MSG_RESIZED_REPORT, but if it's executed after
relayoutWindow, mPendingInsets will already be the new value and it'll
not forceLayout. So we need to forceLayout here to make sure the measure
cache is cleared.
bug: 29391054
Change-Id: I73793b1427b89e75700369ec3b37053a6a732f0d
