Calling detachViewFromParent() without calling remove or attach in the
same drawing frame could, in some situations, cause a crash in the native
DisplayList code. detach/attach are intended to be very lightweight and do
not manage the native DisplayList content the same way that add/remove do.
Nor do they cause an invalidate() or requestLayout(), which would cause the
native structures to get recreated appropriately.
This fix makes this process more robust in two ways:
- DisplayLists should not get finalized (therefore destroying their native
structures) when there are still parent DisplayLists referring to them
(each DisplayList keeps references to its child DisplayLists). This will
prevent the native crash associated with unmatched detach*() calls.
- The docs for detach/attach have been enhanced to make it easier for
developers to understand how to use these methods more correctly and
successfully.
Issue #7064818 detachViewFromParent() should be more robust
Change-Id: I53befc04d5d58c225060f397725566d470488c9b
Send the Intent.ACTION_PACKAGE_VERIFIED to all verifiers when
verification is complete (either one verifier verified the package or a
timeout occurred). Details of what occurred is in a new extra,
PackageManager.EXTRA_VERIFICATION_RESULT.
Bug: 7048930
Change-Id: I4f9855a29b0eb6d77f469891402c69e2e8922945
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
When the memory of the application did not stabilize within
the time limit, the test would report that using the application
name, instead of the result key. Fixed the test to always use the
result key.
Change-Id: Ie16969e831bd3d89ee0496b992568f52bf1989cb
Remove workaround for obsolete touchscreen hardware. Provide a better
focal point for scroll events.
Change-Id: I173cd6696dace379437b56597c4a6ac5c7fbf60d
This solves the problems around active pointer tracking when the
caller may skip events in the MotionEvent stream and replaces the
old implementation with a much simpler algorithm.
Change-Id: I97c0bfad03a6190e403e843d382e05ff2257b66f
Send becomming noisy event also when disconnecting a dock
(analog, digital or USB) or HDMI.
Bug 6760590.
Change-Id: I497df35a3c6817d2b300f532d4cc3f12e3ce9ace
The Drive application was calling PopupWindow.dismiss from within
onMeasure. This caused dispatchDetachedFromWindow to be called
from within performTraversals. Since dispatchDetachedFromWindow
destroys much of what performTraversals uses this was a disaster
waiting to happen.
This fix adds a check for seeing if die(immediate=true) is being
called from within performTraversals. If it is then die doesn't
execute doDie immediately, but instead treats it as a call to
die(immediate=false).
Fixes bug 6836841.
Change-Id: I833289e12c19fd33c17a715b2ed2adcf8388573a
