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
The favorite printer list contains a printer multiple times as it might
have been used at different locations. Hence it can be that a printer is
in the favorite printer list multipe times but never considered close.
Hence we go into the second loop and add it multiple times as we never
add it to alreadyAddedPrinter.
Change-Id: I4ca8a6a5a05f43645a0b2c891a55df2ccce05ad4
This make services that appreared while the print manager was not active
by default enabled.
In the case we upgrade from pre-N we convert the enabled-list into a
disabled-list.
Bug: 26249649
Change-Id: Iae783a8dd19f1a9d75d675710ea4348fdfbd34f3
location of the user.
Commonly the users prints on a printer that this near the user current
location. Hence if possible we want to show the user printers that he
used before and that are close to him.
Hence store the location of the previous uses of a printer and prefer
printer that are close to the user.
Unfortunately getLastLocation might not report a usable location and it
will take at least 5 seconds until the first usable location arrives. At
this time the user might have already opened the destionation spinner.
It would be unexpected for the printers to suddenly change under the
users finger. Hence it might be that we did first show the printer
without any location information and then once the location is known we
cannot update thedestination spinner anymore.
The select printer activity does not have this issue, hence in the worst
case the user has to enter this activity to select a printer and by then
the location is usually determined.
This is not ideal but better than before.
Bug: 24133609
Change-Id: Ie7d20cf3d9dd163e57903f8f6ecc0b3fd4f4374e
- Stop using deprecated APIs
- Fix all public and some internal javadoc
- Add @Decorations to public APIs
- Some minor cleanup, e.g. don't use variables with overlapping names in same scope
- remove unnecessary properties from manifest (they are set by the build
system)
Change-Id: I0ce8849a516414763fe9de76c3a18ce17d896816
info-activities
The icon is loaded from the discovery session only when it is displayed
to avoid having to store too many icons in memory.
Also the icons are not maintained in the historical printers. Only if
the printers are available nice icons are shown. A historical printer is
updated with the appropriate properties (including icon) once it becomes
available.
Bug: 24135005
Change-Id: Iec389bab514b024634be8fb5fc8928371cba8740
The status has always been there in error cases, it is now also visible
in non-error cases.
If the progress is not set, no progress bar is shown.
Bug: 24135025
Change-Id: Iea23f45d236365433c6f6739597833d236ed6d19
