... if it cannot connect to remote PrintDocumentAdapter. Then the state
will be set to destroyed and the print activity will be aborted via the
onDied callback.
Bug: 27899066
Change-Id: Ieb287b92ac21fc71a56b491a1035feaff6cd2837
Bonus: null advanced keys produced a exception deep in the print
spooler. Hence prevent null keys on the surface from now on.
Bug: 27716355
Change-Id: I3c064956f4e670cd7091437ade06605aa8d797b0
destroyed synchronously.
Also: Always destroy print spooler provider when it was initialized to
avoid service leakage if print activity was finished after
onCreate but before onPrinterRegistryReady.
Bug: 27814338
Change-Id: I8401dc6e447cbd726b1a8f7c361b4ddf42e7e11d
In PrintActivity.OnPause we set the print job state based on the
PrintActivity state. The issue was that FINISHED was interpreted as
"cancel print job". Actually with FINISHED does not tell what state the
job should be in.
The only purpose of the finished state was to guard against
double-invocation of doFinish().
Hence remove this recently introduced state and use a simple boolean to
guard against doule invocation of doFinish().
Bug: 27760331
Change-Id: I0767c2b0b9c28e8904647cc832c236f67f92bcfe
of pages.
If the printing app declares more pages than the print preview pdf has
we used to throw an exception in the PDFManupulationService. This caused
the bitmap to be never written and the read-bitmap function to hang
forever. This was because read() return 0 meaning "pipe is closed" which
lead to an infinite loop. Now a read of 0 page might cause an exception
if the page is not fully read. This exception then causes the
preview_page_error to be displayed.
Bug: 27556666
Change-Id: I7b9de50dce930629e8d38efd4e2659a00b70cc4e
are canceling the command.
Before it could happen that we have a pending cancel on a layout command
but the layout command finishes normally. This enqueued a new write
command before the PrintActivity is notified. This in turn prevented the
printactivity from finishing as the write command was still pending.
Bug: 27642724
Change-Id: I3c532d53b0c66c40d2e48ab8b4419251ff473a79
In this case it cannot call back into the recyclerView and update the
data. For the call path please see the bug.
Bug: 27614499
Change-Id: I84733fea30429c20a2c96085efb47d4da5e1948a
It can happen that before we stopped we reported a set of printers. Then
while the loader is stopped, we lost all printers. Then on re-start we
need to tell the clients that there are no printers anymore.
There is one issue: The fused-printers-provider might be started
before the printer registry is fully created. In this case we get a callback
and get all king of NPEs. Hence enqueue the first load behind the
current thread. This makes sure that the current operation - creation of
the printer registry - is finished.
Bug: 27643300
Change-Id: Ife6993d57457f23a0a4a54a11869c742c05da850
It can happen that multiple async calls fail and we end up calling
doFinish from all of them. We should just ignore the later ones.
Bug: 27198033
Change-Id: Ica596b966f96e9ade6409cc45c50fd62c4018b1e
... we should not check if it is updating. As it is not initailized,
we do not have to check either, hence we can just ignore this.
Bug: 27516795
Change-Id: If618f2a10563e83074e38f0b37342a648d54202a
updated. Also fiddle with the UI to use more standard values.
To be sure the print service state alwasy updated I changed
PrintManager.getPrintServices to return a loader which just wraps a
registerListener/getList/removeListener combo.
I also added a new function to enabled/disable a print service to be
keep all updating logic inside the PrintManagerService->UserState.
Then I changed all code to use this new interface.
Detailed comments:
PrintServiceInfo:
- I had to add the enabled state to the PrintServiceInfo as some users
of PrintManager.getPrintServices want all services but then display
different data depending on the enabled state. Of course I could have
created two PrintManager.getPrintServices-loaders to load the two
separate list of services. I think it is much easier to add this
property though. It is updated every time new data is returned to the
PrintManager.getPrintServices-loader.
AddPrinterActivity:
- This is shown as a dialog-style overlay to indicate that the user will
return to the select-printers activity. It contains of three list that
are updated via separate loaders.
- The recommended services will be added later to keep this path set
small.
PrintActivity:
- There are two small places where we have to update the data when we
get a new list of print services.
- In very, very rare conditions it can happen that the print service
of the current printer gains or looses the "advancedOptions"
activity
- If we have no enabled print services we want to show "Add printer"
instead of "All printers...".
- Also the print registry is not the only loader anymore, hence we have
to assign loader ids to it to not conflict with the other loaders in
this activity.
- Small bug in onPrintersChanged: If a printer is selected and the print
service of this printer gets disabled the holder goes into "removed"
state which disables the printer. When the print service is then
enabled again, we forgot to re-enable the holder.
PrinterRegistry:
- The registry assumed that the FusedPrinterProvider was the only loader
in the activity. This is not true anymore, hence it has to assign the
appropriate loader ids.
- The FusedPrinterProvider has an internal loader, hence we have to
forward a loader Id into it.
- The PrintRegistry is only called backed for a single loader, hence no
need to check the loader-id.
SelectPrinterActivity:
- The AddPrinterDialog was removed as we now have the
AddPrinterActivity.
- Added a loader for the enabled services to update the empty state.
- Added dedicated loader Id for the PrinterRegistry again.
- If we have no enabled services, the SelectPrinterActivity chainloads
the AddPrinterActivity as this is the only thing the user can do
anyway. "Save a click". This should only happen when the activity is
create the first time.
- Moved the "add printer" from the menu item to the list of printers as
suggested by UX and Zach.
PrintManagerService, UserState and IPrintManagerParamtersTest:
- As the only place where the print service state is updated is now the
userstate, we have no more sychronization problems. Whohoo.
- The users can now register for changes to the print services similar
as they can register for changes to the print jobs.
- UserState.getPrintServices is the only function can exposes any
knowledge of the print services to the outside world.
Change-Id: I9be2c7300431e06aaff9bdf7eb36120d869b56ac
When switching between two printers with different margins but with the
same paper size we were missing updates of the print preview. This
change triggers these updates.
The issue was the we reuse the a bitmap when a page is rewritten. This
causes View.setBackground(drawable) to do nothing as the old
background is the same as the new one. This function only checks the
background drawable object reference, not the content. Hence we need to
add a call that notifies the listeners to the changes on the content of
the drawable.
Bug: 26961677
Change-Id: Id8b9be59c9ca7220f40ac59168f78bfdcccb2761
Bonus: Remove Printer-onChange listener before other state gets cleaned
up. Otherwise onChange callbacks at the wrong time cause into
destroyed data.
Bug: 27219320
Change-Id: I8335b9d8dd71112b76aa684f00524d4d8aad3f94
- The selected pages is not stored in the print job. But this is used to
communicate with the advanced options activity. Hence patch it up
before sending it out.
- If no media size is set in the returned attributes, do not try to get
the portait size of this null-media size
- The copies can be 0 if the PrintJobInfo was created via
PrintJobInfo.Builder()
Change-Id: Ic75c1db0cd5ffad663d87913dfe23e3f5a729bbf
Otherwise the print-client app can prevent the print activity from exiting as
we wait for the command to finish. As this is a violation of the
remote-print-document contract we deal with this similar to a command failure.
As the PrintActivity is exiting we don't further send any commands to the
print-client.
Bug: 27207751
Change-Id: Ieacb16786112f217ca5b8031bfb597598e28dc3d
The general theme of these changes is to always delay any action until
the printDocument finishes a command. This is done:
- Before callinng for into a different activity to select a name for the
PDF
- Before finishing
The second theme is to fix the canceling behavior of
RemotePrintDocument.AsyncCommand.
There are four bugs fixed in this review:
(1)
When the RemotePrintDocument.AsyncCommand is canceled it goes into the
"canceling" state. When it is canceled again it should stay in this
state. Before it went to "canceled" but the command was still running.
(see AsyncCommand#cancel()).
(2)
When finishing the PrintActivity in PrintActivity.doFinish() we cancel
the RemotePrintDocument. If there is a command still in progress (i.e.
isUpdating()) and it finished as canceled we used to call doFinish()
again and then try to double-clean up which lead to exceptions.
The new behavior is that is the PrintActivity is calling doFinish()
while a command is still in progress (i.e. isUpdating()) we delay the
cleanup until the command finishes. The command might finish as
canceled, completed or failed. Hence we have to call doFinish() in the
callbacks for all three cases.
(3)
When canceling there might have still been a nextCommand ready, hence
canceling does not stop execution of the RemotePrintDocument which could
lead to running commands while finshing.
(4)
When getting the location to store the PDF at a command might still be
in progress. This lead to half executed commands and caused issues once
we try to continue after the select-location-activity returns
Bug: 24713704
Bug: 24973884
Change-Id: Ied90fe8dc9bd6ea7f8b3e4ce4f922e477015568d
connected.
This can happen if finish() was called immediately after onResume() and
before PrintSpoolerProvider.onServiceConnected.
There is actually a small issue left. If the connection to the spooler
gets destroyed before it was ever connected the print job does not get
canceled. In this case it will stay "created" until the next reboot and
then it will not get recreated.
Bug: 26428518
Change-Id: I1b8696f326b842160e4db77b985577a1c8978def
The printer registry is created not in sync with the states or the
activity life-cycle. It might not be initialized when stop is called as
we might have a very quick
create -> start -> stop -> finish
without time for the print subsystem to initialize.
Bug: 21749058
Change-Id: I991029a7fd0ad162c1144ff03438707f16bf0b02
If the PrintActivity gets destroyed (e.g. due to low memory) it gets
re-created when the PrintToPDF activity returns in onActivityResult. In
this case onActivityResult is called right after onCreate and before the
UI is bound. This resulted in a NullPointerException when accessing the
unbound UI elements.
Bug: 21749058
Change-Id: I44e625e8c4f10432591d0afcf7825d7e0dbee6f5
The new printer might not support the currently selected paper size
hence the printer update changes the paper size.
Change-Id: Ie3864d87df425383b4c37f325c8fbea12f6f6051
- gray out printer icons of unavailable printers
- Increase touch target of more into button
- Use same info icon as in the Settings
- Align text correctly in destination drop down
- In general use same layout as generic list-item (as much as possible)
- remove unnecesary color file
Change-Id: I8b0339df0cb6a5130b5530f21c4ef86cb75a683b
- Propagate nullness and non-null-ness up and down from the interfaces.
- Add non-CTS print tests for IPrintManager binder.
Change-Id: I0c310d9cea8aefba5ce386931521ffaf19712bbb
