If apps are writing malformed content (typically not a PDF file) or if the
PDF content they provide to the print system is password protected, are now
crashed as both of these are app bugs.
bug:17636435
Change-Id: Ifce6a3199e587448dd38f6a84290a965c24b698b
When rendering a PDF file for print preview we take into account
the selected print options such as paper size, orientation, etc
without modifying the document. To print we send the doc in its
original form and the print options so the print service can apply
the necessary transforms in addition to the optional custom options
it supports. When saving to PDF we have to actually change the
document as we act as a print service.
bug:13545980
Change-Id: Icdcecf962bec6ff742cc6015df5af9d9086ce760
When printing from two apps at the same time the second print UI is
getting stuck. There were a couple of issues here:
AdapterView was not notifying for item selection if the data changes
after scheduling a dalayed selection notification and the notification
execution. The code assumed that a layout pass will occur and posponed
the notification after the layout pass but it is not guaranteed that
such a layout pass will occur. Now we delay only if a layout pass is
being scheduled.
Also when binding to the PDF rendering service the print spooler was
using the same intent and as a result two print activites were getting
the same renderer instance while they should get separate ones. Now
we use different data in the intent to ensure we get separate renderer
instances.
Change-Id: I6aa7c7b041957804b4273549dd837a6d70064efc
If the printing app with the print UI on top is killed from recents we get
a crash because: 1) the remote print document was not transitioned to a
failed state if the printing app dies (this is an unrecoverable failure);
2) the print preview controller was destroyed asyncronosly during which it
also asynchronously disconnects from the rendering service which however
happens after the system has already cleaned up all connections of the print
UI activity as it is being destoryed.
bug:18109386
Change-Id: If6200b14a8aa90622228bbb659e9c4962226f561
We order printers based on past usage. In some cases the ordering
does not work. The reason for that was an incorrect assumption that
the entries in an ArrayMap are ordered in the order they are added.
bug:18109283
Change-Id: Ie367e4ca5e6bd79f335a060074c9211054e3a931
One can save only one copy to PDF. Showing more that one copy when saving
to PDF enven in a disabled input box is confusing to the user. We now set
the copies to one when the PDF printer is selected.
bug:17631303
Change-Id: Ia04d144efc899e7f3836c19349d9c87f3ae8f0f0
When saving to PDF we bring up the file picker UI which covers
the print UI. In this case the printing app may get killed as
it is not in the forground (the system is bound to the print
spooler so it cannot get killed). If that happens we are ending
up with an empty file. However, if the file chooser UI is up
we already have everything from the app we need and it dying
does not matter. This change takes care if ignoring printing
app death while saving to PDF.
bug:17922948
Change-Id: I10d808e3c3e93e850dbc2a948f2482381a887928
The first issue is that the save to pdf button is enabled
before the first layout completed and at this point we do
not know anything about the document. The second is that
if a layout is in progress and we select save to pdf we
end up starting the documents UI twice and finishing the
second instance carshes the spooler.
bug:17676878
Change-Id: Id0b1f06e4d377347286c2dde09669d431441234b
The custom settings activity of a print serivce can change the selected
pages and the spooler was not checking whether the returned pages were
valid leading to a crash.
bug:17678553
Change-Id: Id8ea3d482d2909b97a06752d61b416dfe5948483
