Modified ActivityView to inject touch events it receives back into
its activity container. The container then injects the event into
the input system along with the display id of the underlying virtual
display.
Enhanced the input system to support concurrent dispatch of touch
events on multiple displays which is required for this to work.
Change-Id: I9cf1870db3be6f99a52ed9a1e3ceafe42c940093
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
- Remove task after removing activity. Removing the task before
removing the activity led to problems when the task was still needed.
- In WindowManager wait for activity manager to remove the task.
Previously was automatically removing the task when the last activity
was removed.
Fixes bug 12957434.
Change-Id: I7f6b1f09a2e2a845f177f337769075c9376f8bdb
Just like stacks and displays, activities and tasks need to stick
around until animations have completed.
Change-Id: I54fe8f6855d60cbc3a25cbc6e762defd5ac50bf5
Changing Configuration first and then testing for changes yields a
result indicating no change.
Fixes bug 12904769.
Change-Id: If7e39e843f15b1143d9877497d595511afabd020
Allowing the detach of ActivityStack from DisplayContent to happen
immediately was causing all sorts of problems associated with not
having a Display to complete the animations.
Waiting for animations to complete before either the detach or the
display removal fixes those problems.
Change-Id: I8a5663bfac5c3c1084ff4fcc451e0e38e8080265
Now that activities and tasks can be detached from a display do not
keep their state within the DisplayContent class. All such state is
now moved to the TaskStack class with this change.
Change-Id: Ie6b1811e9ec3f545782bad8c3461bd4f2d336b93
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
PendingIntents and IntentSenders can now be launched. Still does not
work once the host activity has been paused and resumed.
Window manager TaskStacks now exist independently of Displays and app
windows persist after Displays are removed below them. Attaching the
stack to a new Display does not yet restore the windows to it.
Fixes bug 12747909.
Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
* commit '45b68ac3a7acb7af95fdfc5c0e31560b3c28c9f8':
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager
Transform DisplayManagerService into a SystemService and start cleaning
up other local services that it uses from window manager and input manager.
Clean up service thread initialization.
Remove unnecessary static variables from ActivityManagerService.
It's starting to become clear that we really need a better way to manage
service dependencies. Boot phases don't quite cut it.
Change-Id: If319dbd7cbfbd4812fe55ece969e818d4b20755b
Refactored SystemServer to get rid of a bunch of legacy cruft related
to how the ServerThread used to be started up.
Create system context first when system server starts. This removes
the tangled initialization order dependency that forced us to start
the activity manager service before most anything else.
Moved factory test related constants into the FactoryTest class.
Partially migrated Installer, ActivityManagerService, and
PowerManagerService to the new SystemService pattern. There's more
work to be done here, particularly around the lifecycle of the
power manager.
Bug: 12172368
Change-Id: Ia527dd56e3b3fd90f9eeb41289dbe044921230d4
*** FATAL EXCEPTION IN SYSTEM PROCESS: ActivityManager
java.lang.NullPointerException
at com.android.server.am.ActivityStack.removeTask(ActivityStack.java:3627)
at com.android.server.am.ActivityStack.removeActivityFromHistoryLocked(ActivityStack.java:2693)
at com.android.server.am.ActivityStack.activityDestroyedLocked(ActivityStack.java:2878)
at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:296)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at com.android.server.am.ActivityManagerService$AThread.run(ActivityManagerService.java:1868)
Change-Id: Ifaf0fe6c62d1f63897d57dc96b4d86d8111b45db
- Release Surface and VirtualDisplay when shutting down ActivityView.
- Shut down child stacks when relaunching parent activity.
Change-Id: I60314b2b43bd2da5406cf6ec871293b5baca157c
Previously stacks would be removed when the last ActivityRecord was
removed. This causes problems for ActivityContainers which persist and
permit activities to be launched into an empty stack.
Change-Id: Ia79ac65d17c42eff3a7b1321980c21b29996001b
Adding the virtual display to window manager through a handler message
causes timing issues. Add the display directly to fix it.
Change-Id: I3ad6b16ce6dff2a48abd120a8e873e11a028e2c3
With an existing ActivityContainer a caller can now create an
ActivityView which consists of a new VirtualDisplay immediately
attached to the ActivityContainer.
Change-Id: Id70333dcbef55d524a87df8f8c92d72ca5579364
