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
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
System services holding this permission have external storage bound
one level higher, giving them access to all users' files.
Bug: 7003520
Change-Id: Ib2bcb8455740c713ebd01f71c9a2b89b4e642832
Tooling for xml properties is easier/better if we can properly reflect the
xml properties at the Java language API level as well. We had setters/getters
for the other properties of ViewAnimator, but only a setter for the
animateFirstView property.
Issue #6104327 Inconsistency between XML API and Java API for widgets - ViewAnimator
Change-Id: Iede7231fa433ce14f7a8299da4cedd4720370bc8
The AlertDialog creates in onSavePassword method leaks if
WebViewClassic is destroyed when the dialog is shown.
Change-Id: I81f20e1dd138467a6413766c0a081b389b334ae0
Remove workaround for obsolete touchscreen hardware. Provide a better
focal point for scroll events.
Change-Id: I879acb4cfd23bd3762d0332e4df2203d913ae869
Wifi can have a quick disconnection followed by a reconnection. We used to
create a new DHCP state machine thread for every new connection and
never really waited until it quit after disconnect. This may have lead to
situations where repeated disconnect/reconnects resulted in multiple dhcp
start calls.
We now keep the statemachine after a disconnect and only shut it at supplicant
stop.
Bug: 6417686
Change-Id: Icf66efdc654be886e3eb46c81f09f8cce536f2f6
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
Add a useful (if somewhat dangerous) method which will help
replace similarly dangerous code patterns in a few different places.
Change-Id: If1295f7ab9652c906ce718d94eb7914d143e1939
The activity manager now keeps track of which users are running.
Initially, only user 0 is running.
When you switch to another user, that user is started so it is
running. It is only at this point that BOOT_COMPLETED is sent
for that user and it is allowed to execute anything.
You can stop any user except user 0, which brings it back to the
same state as when you first boot the device. This is also used
to be able to more cleaning delete a user, by first stopping it
before removing its data.
There is a new broadcast ACTION_USER_STOPPED sent when a user is
stopped; system services need to handle this like they currently
handle ACTION_PACKAGE_RESTARTED when individual packages are
restarted.
Change-Id: I89adbd7cbaf4a0bb72ea201385f93477f40a4119
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: I6b15a2e215cab7b9559db800fcc57374702357fc
The WindowManager retrieved from the activity Context with
getSystemService is incorrect for a Toast. Because it contains
a parent window when addView is called its LayoutParams.token
is set to the value of the parent window. Then when an Activity
is dismissed WindowManagerGlobal.closeAll() sees the incorrect
token and incorrectly closes the Toast.
This fix uses the application Context instead of the activity
Context to retrieve a WindowManager with no parent window. This
leaves the token unchanged and keeps from dismissing the toast when
the activity is closed.
Fixes bug 7048792.
Change-Id: I92c3095d8fabd6e9e4206e9bc8e917885ab322a9
