We also now ignore attempts to set preferred resolutions with
intent filters for which no actions are defined.
Bug 11392870
Change-Id: If0d0b37bf01b59463985441edfc2bddd070bfc2a
It's currently possible to reference deviceModeChanged in InputReader
while it's in an unknown state. Change the style of initialization
here and a few other places to better prevent this type of error.
Bug: 11433748
Change-Id: Ib332406aefb7cdb16b6a21e00dceaeca34679853
A final layout pass should be done whenever the status bar has
completed its incoming animation.
Fixes bug 10387660.
Change-Id: I48c19015c53116b58cf73e20be32d1f64dd682ca
1. Implemented the advanced printer options integration. Now a print service
may declare an advanced print options activity which may be launched by
the user if the current printer supports advanced print options. These options
are visible only to the print service that added them and it is the only party
that will interpret the options.
2. Fixed a couple of bugs in the saved print jobs parsing. One was that if there
are more than one page range, a half of the print job properties was not
properly parsed. The other was that the media size constructor was using
incorrect argument order, thus creating a media size with wring width.
3. Fixed and edge case where old print jobs and their docs can get stuck in
the spooler. If the app did not write the requested pages we were not showing
an error message, rather just finish the activity without canceling the print
job and this print job is stuck in the spooler. Now we show an error message
and the user may retry, cancel. If the user cancels the print job is also
cancelled, thus no leftover in the spooler.
4. Fixed the background color of the print dialog to meet UX spec.
bug:11241800
Change-Id: I352440bc86aec824a805883fc9579d96a06d11e6
The startService() and stopServie() calls had a redundant check for
the incoming user ID being valid, but with its own custom implementation
that doesn't match the normal handleIncomingUser flow. In fact, for
both of these we are going to do handleIncomingUser anyway when we get
to retrieveServiceLocked(), so there was just no need for this.
Change-Id: I14409a03781a14a5f1a786aceb31dcc77efb062c
The effects of the flag, Intent.FLAG_ACTIVITY_TASK_ON_HOME was being
overwritten by the call immediately after it was set. Changing the
order of operations leaves the effect intact.
Fixes bug 11376962.
Change-Id: I27371e0efeb0c08d1e14514a9e3a63157f6d34d8
Windows were previously ordered by TaskStack/ActivityStack order. This
change provides a data structure in DisplayContent that tracks task
movement. Previously Recents and Home activity windows were always
adjacent because they were on the same stack. With this change windows
from other activities can be placed between the two.
Fixes bug 11338594.
Change-Id: Ie34443ff22f330d015141d97db79370c54920d28
We need to be able to perform very lengthy operations on some threads
(e.g. the I/O thread responsible for installing multi-gigabyte APKs) but
still have long-run deadlock/hang detection applied to those threads.
Previously the watchdog mechanism applied the same policy to all
monitored threads: unresponsive after 60 seconds => restart the system.
Now, each monitored entity can have its own independent timeout after
which the watchdog declares deadlock and restarts the runtime. The
halfway-finished intermediate thread stacks are dumped based on the
specific entity's declared timeout, not the global 30 second checking
interval.
With that new mechanism in place, the Package Manager's lengthy-I/O
thread watchdog timeout is raised to 10 minutes.
Bug 11278188
Change-Id: I512599260009c31416b2385f778681e5b9597f05
The previous jank improvement only worked when closing
an app, not when bringing one forward (hitting home button).
This should cover the specific case that is being missed: Having the
Home task being brought to front over a translucent window, with
a wallpaper behind both tasks.
bug:11253262
Change-Id: I200ef6fe2dda8d9ab4e1f82059b4f888c59007f4
When a non-fullscreen task over home launches another non-fullscreen
task then the home task might not be displayed. Looking all the way
down the task stacks until reaching a visible, fullscreen activity or
home provides the right information.
Fixes bug 11273803.
Change-Id: I8dab0956c1cda06ddb7850ea3ffac7f6a223c6ad
Minor changes for dumping stack traces:
- Print the native traces right after foreground/persistent apps
- Also include mediaserver, sdcard, and surfaceflinger in traces
Bug: 11321322
Change-Id: Ic09b7da316a5f197dda0ac3bde06f75574cc2166
The android package is now a special case, not being added to the package list
when creating a multi-process component. There is no need, since this package
is actually the framework itself which must be loaded in every process.
Also cleaned up some of the procstats dump output to help see what is going
on here.
Change-Id: If65d35ecd562f3154bdebfded69c454af6ce8c96
Because properly continuing permission grants post-OTA has changed
policy to include privilege considerations based on install location,
make sure that we re-evaluate when we determine that the apk has
moved from its pre-OTA location.
Bug 11271490
Change-Id: I6c09986e2851a67504268b289932588457c05dfc
The WindowManagerService member mLowerWallpaperTarget is not stable
throughout an app transition. Relying on it to be stable causes the
intra-wallpaper animation to start out right but after the windows
have been relayed out there is no longer a lower wallpaper target.
This causes the wallpaper to start tracking the animation of the
current wallpaper target rather than remain stable.
Switching to a new variable that saves the state of wallpaper
animation at the start of the animation fixes bug 11240590.
Change-Id: I336a59c47665fcf61019f567b8663956ff0e4940
When finishing or stopping an activity the code was automatically
refocusing to the next activity on the same stack independent of the
task's onTopOfHome flag. When the activity eventually finished or
stopped it would then honor the onTopOfHome flag.
This fix examines the onTopOfHome flag and arranges the focus
correctly if home is the next activity to run.
Fixes bug 11318263.
Change-Id: I73a8f5e82de04b01acaffe366b085f9e475e1451
There were circumstances where mFocusedStack could be assigned the
home stack. If this were ever to occur then all subsequent tasks would
be put on the home stack. This fix ensures that there is no way that
mFocusedStack will ever be assigned to the home task.
Fixes bug 11271189.
Change-Id: I7ddd9b6bcbf2787cbe2f44b461ad057ae2241f00
The possibility existed that an activity was set to a task that it was
already being set to. If that were to happen, and it was the only
activity in the only task of the stack the stack would be deleted.
This fixes that situation and logs it as well to confirm that it does
fix bug 11272935. Logging to be deleted upon successful monkey run
exhibiting the log.
Change-Id: I436fdcc9a3734adad81d3ef90f29b93b3ac4dfcd
