Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
Reverting to the previous stub as the display adapter registration
and the logical to physical mapping is not at all what we are going
to need moving forward.
Fixed up the service initialization order so that the display manager
service has a context from the start.
Change-Id: I717f2f1099c7a77180ef207c371ec8329258850a
Add a View.toString() method.
Rename all of the View private flags to have a PFLAG prefix to
avoid going insane trying to figure out which constant goes with
which flag.
Activity.dump() now includes a summary of the activity's view
hierarchy, using the View.toString() method.
All exceptions thrown by FragmentManager now perform a dump of
the owning activity state, where appropriate.
Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
So each user can have their own set of intent resolution preferences.
ResolverActivity now launches the activity on the correct user, and
persists the preference for the correct user.
Bug: 6961905
Change-Id: I6d3a8a9af89bc649277d4fc8d0f367ee123f8392
Use AtomicFile for usermanager files.
Added a MANAGE_USERS permission that apps (signature permission) can use
to create/query/modify/remove users.
Change-Id: I5cf232232d0539e7508df8ec9b216e29c2351cd9
Remove the last user of FileUtils#getFileStatus and move it to
Libcore.os.stat instead. Then we can remove the JNI code that does the
equivalent of a stat.
Change-Id: Ieb566a2a8a17c2dd0150724b4eb3ac1cc41c823d
PackageManagerService just needed to know the owner for this file, so
just use stat instead so we can remove the old JNI code.
This is the last user of FileUtils#getPermissions so just remove the
FileUtils method as well.
Change-Id: I953057cd6b9de4410f33b6f22e4bddff02fe2988
The logic in the frame processing code of ValueAnimator did not handle
the situation of animators being ended while the current animation list
was being processed. In particular, if a call to an animation update
(which could result in a call out to user code) caused that animation, or
other current animators, to end, then there was the risk of running off the
end of the list of current animators.
The fix is to work from a copy of the current animator list, processing frames
on each one only if they also exist in the real animations list.
Issue #6992223 Frequent System UI crash
Change-Id: I742964558f8354f04c311b7b51c7686f26a4dacf
