When selecting print to PDF and then pressing back to return from the
storage UI activity, the print dialog was in a state where nothing
is selected.
bug:10983508
Change-Id: I9c14b5fa18e812104ade6a2eacd626b5f7387111
1. The getActivePrintJobs() method in print service is designed to return
the active print job i.e. ones scheduled to be processed by the print
service. Now the correct list is returned.
2. The listeners for observing the state of print jobs may be called even
after being unregistered. Ex: state change occurs and we schedule a
message on the app's main thread to make the notificaion. Now the app
unregisretes the callback and on the next loop the notification message
is handled.
bug:11200258
Change-Id: I4a497b5c9a7287a22023cafe41ce966d14300ca6
Simplification where wallpaper was behind all apps didn't work when
keyguard and associated wallpaper needed to be above phone screen when
phone screen animated in and out. Instead phone screen was instantly
hiding the wallpaper.
Fixes most of bug 10932680.
This fixes the wallpaper disappearing as soon as the animation begins
when going from keyguard to phone. There remains jank going from phone
to lockscreen where the animation is not occurring and the phone
blanks out immediately.
Change-Id: Ie5f464acb2f6cefd2fb91f3b920a687ec7c15d76
When the user selectes a printer in the UI we ask the print service to start tracking
the printer, i.e. to observe changes of the printer state and capabilities. The callback
for the initially selected printer is called twice which breaks the contract and also
may trigger potentially expensive operations on the print service side.
More precisely the printer does not change and we ask the service to start tracking,
stop tracking, and again start tracking.
bug:11199851
Change-Id: Ib761e6da03f670b3098c69b1c0927177a8e4ae6b
We persist ongoing print jobs so they can be restarted if the device
dies. The data size of the printed document was not persisted to disc.
bug:11199352
Change-Id: I53ef1ee285aa4808917dd6a5c7335226aba1ef0a
When a print service is disabled we assume all print jobs for it failed as we have
no way to know what happens to them. However we are also failing created print jobs,
i.e. ones not given to the service. Such jobs are in process of construction and
the print dialog is up. We should not fail such jobs as the dialog can still modify
their state and potentially select a print from a different service. Therefore, we
leave them alone and they will be failed if when constructed are passed to a
disabled/uninstalled service.
bug:11197432
Change-Id: Ie4fe54327e3e25776b1dd572be2dfafdd700c2e5
The previous fix that returned to home when a task on top of home was
removed was too broad. If that task was not the foreground task it was
not a good idea to bring the home screen to the front.
Fixes bug 11198552.
Change-Id: I14e5fdc167011f25e0e8490c3e52c5c1dcbffbff
Now that non-null window tokens are coming in in additional situations
(ag/372453) we have to look at whether the keyguard is hidden before
deciding to wait for it.
Fixes bug 1187500.
Change-Id: Ie89d5334ab3d0f5b8f2cf8c87fef84a9b6392b72
This fixes a problem where PhoneWindowManager times out waiting
for keyguard to draw when it's disabled. Instead, we pass a null
token back which allows PhoneWindowManager to continue.
Fixes bug 11190932
Change-Id: I041ea1d88dca681476d9477a3aab54559976b312
Killing an app that was launched from home was not relaunching home.
Previous situations relaunched the next app (i.e. home) based on the
task flag. However, when an app dies the relaunch is deferred until
the TaskRecord has long been forgotten. This fix rearranges the stacks
immediately upon the TaskRecord being removed from the stack. Then the
next resumeTopActivities() call will start the home task.
Fixes bug 11189555.
Change-Id: I0e09350a7db55ea8b38cce7bf4b69923a6b99494
