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
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
It is possible that a buggy app breaks the contract and provides
content to be printed in format other than PDF. This was leading
to a crash in the print spooler. This change fixes the crash and
shows a user friendly error message.
bug:17642690
Change-Id: I5a4acb06080a152562655da6851467b3e71d8658
It is possible that two providers for the same page are assigned
to two preview views despite temporariliy while rebinding. We were
however releasing the provider from the view which is being bound
if not for the same page which as a result was cancelling rendering
of this page which is provided to another view via another provider.
Hence, having an empty page. Removed the unnecessary code to release
a provider when binding the view - release is happening only if the
view holder is recycled.
bug:17515670
Change-Id: I197438c16cfdb363f521cd1320f154da54eea5f5
Saving to PDF a subset of the pages requires trimming the
undesired pages and when this is done writing the ready doc
to a URI. To write the file to URI we have to obtain it but
it is aquired by the shredding task and never released. Now
we are releasing the document immediately after trimming it.
bug:17631301
Change-Id: I4db7966c65c75f0f14c3cb52fd83b4d8fd5a4687
If the user presses back before the remote print document
update has completed we get a crash. The reason is that
after the update completion we were trying to finish the
activity if we are in a cancelled state but this is not
needed as we aready handled the back key so we will finish.
Handling finish twice was creating the problem as classes
with lifecycles are not designed to be used after being
finished. In particular, we were calling doFinish() twice.
bug:17630561
Change-Id: If418f237a2def7c8e4a072ac8826283f4dd7fc85
In the spooler we have the renderer reading a file to visualize
content and the app writing a file to produce the content. Since
we have to swap the file under the renderer we have a mutex file
provider that both parties can request, use when released, and
release when required. This enables us to request the file which
closes the renderer and when the renderer is closed ask the app
to write some more pages, then open the renderer, and so on. The
mutex file provider was throwing of a thread that does not own
the file thries to relase it which is not needed, this should be
just a nop.
bug:17607134
Change-Id: Id6a2ce92d70077f57978b95315648faf02c13c68
The spooler communicates with he remote PDF renderer asynchronously.
When print is confirmed we close the renderer, destroy it, and unbind
from its service. If we unbind from the service after the print activiy
is finished we get a crash. The bug was that we did not wait until we
disconnect from the remote renderer before finishing the print activity.
bug:17583115
Change-Id: I55b0135f9c5658b3a4fda2901b8b3bdef044e211
When user chooses to save to PDF we open the document chooser UI.
Now if the user now backs to the print UI without choosing a file,
the print UI has all options disabled and the back button does
not work - the user is stuck. This is because we were not
transitioning the print UI in the correct state.
bug:17557454
Change-Id: I385129e106ed41564b89137ca54d409127ba8ff0
Removed the restriction for the page content providers to
be singletons as the RecyclerView may hold on views with
providers and ask us to bind other views for the same page.
Note that the views that RecyclerView is holding will be
soon rebound or recycled just they are not at the time we
bind other views for the same position. We were guarding
against this but caused some pages not appearing sometimes
on scrolling. Also now keeping the media size and magins
of recycled page view (will be updated if needed on
rebinding) or avoid changes of the background to null as
setting it to not null later causes an undesired layout pass.
bug:17537922
Change-Id: If029f6c413e15d4f5c1ba1ac5e4d52ad2cad5904
The operations of the remote renderer have to be performed in order, open,
render some pages, close. One of the tasks was executed on the wrong executor
resuling in a race and an occassional bad state.
Also fixed a NPE if the preview list is flinged and then the user presses
back.
bug:17537922
Change-Id: I5048078ba2b875a2a8335f3a4324afaa34d014a2
We were not clearing the tracked printer when the print activity is
paused and then not setting the tracked printer when the activity
is resumed.
bug:17525271
Change-Id: Ib0fb29006bfcf5ad03dce24b3407cd96dc421442
It is possible that we try to switch framents after the print
activity finish method is called. In this state the activity
is going away and trying to perform a fragment operation throws.
Now if we are finishing no fragment opration is performed.
bug:17520007
Change-Id: I0dd935d3cdaeddca31fccf49bd5de97e878abb9d
The bound pages in the adapter were not properly tracked, more
specifically we did not remove pages from the bound set ending
up in a bad state. Also when the printer changes and if the
new one has different page size the content disappears due to
us not notifying for the data set change.
bug:17515670
Change-Id: Iac74e864609012f6804584fa133e87c27dc186a5
The code executed in the shredder completion callback must
be called on the main thread but instead it was called on
another one. This led to a crash.
bug:17514533
Change-Id: Id9e86d38a90fedadc60f967b193470fd83eb3362
We laizily request printer capabilities and when they are reported
we were not updating the preview and as a result the content was not
rendered, hence pages showing an empty state.
bug:17514117
Change-Id: Icfee7eaa1ab63f5e4d7655d4057ef2110c27cd43
