A print service may choose to provide only the printer info and then when
it is requested to start tracking the state of the printer, the service
should provide the printer capabilities. If the capabilities are not
received within ten seconds we mark the printer as unavailable and stop
tracking it.
bug:10748639
Change-Id: I9171cb5dc116fd321c23a8e4ab55109448e2fc6a
1. The printers in the printers list of settings change position if
they are updated. The settings app is using hidden platform APIs
the this change fixes.
2. Enable ProGuard for the PrintSpooler.
3. Added icons on the list of printers so the user knows which
print service used the printer. Now the user can know when
he is using cloud print and maybe incurring data costs vs
local printer discovered by a vendor plug in.
bug:10955751
Change-Id: I292f48b424cb561218fdb424d0388f4d786d8339
1. In the FusedPrintersLoader we start observing the printers on
the device and if they change we send the result. If however,
the printers are already loaded in our session (because it
joined an ongoing printer discovery) and the pritners do not
change, the loader never sends its result. Now we are registring
the callback only after historical printers are loaded. We
also immediately check after starting discovery whether the
there are printers in the discovery session and if so deliver
them.
2. Improved logging in the FusedPrintersLoader.
bug:10940712
Change-Id: Ieb9b897d64780742125b29309462dea3eda170a6
1. If the printer is unavailable we should not allow the user
to select it. Rather, show it grayed out.
2. Some string changes requeted by translators.
bug:10917222
Change-Id: I370f05f9c8e70e3f077db7eb02cf48e19a59925d
1. The fused printers provider was dropping on the floor received printers
if it was not active. It is in fact a loaded and if not active it should compute
the printers and not deliver them until activated. This fixes an issue where
opening the print dialog, then enabling a print service results in the printers
reported by the service not showing up in the print dialog.
2. Printer discovery session was created twice which leads to incorrect behavior
as the pint system is designed around the contract that there is a single
printer discovery session per service at a time. This was possible due to an
incorrect initialization of a member variable resulting in double session creation
when the print service is connected.
3. When a print service is enabled during discovery we did not use the correct
condition to start printer discovery resulting in starting it all the time even if
not needed. Also if some of the printers that had to be tracked are reported
by the service just enabled (typically historical printers) we did not ask the
service to start tracking them.
4. Removed some logging.
bug:10903343
Change-Id: I46c049471a4b099fc668df3aee2aaedc8d7786ac
Every time a printer is selected we have to refresh it by telling
the print service to stop tracking the previously selected printer
if such and start tracking the current one. As a result of start
tracking the print service has to give us the capabilities too. A
previous patch caused a regression and we do not refresh printers
when needed.
bug:10898968
Change-Id: I9d5413e324fdb8856ef61849d36a161470eb204d
1. The algorithm that determines whether a page range contains
another one had a bug and in some cases misbehaved.
2. When print is pressed we do a final layout and if nothing
changes and we have the requeted pages we skip the final
write. However, in this case we did not update the print
job with the pages to be printed but we have to since in
the previous write we did not ask for all selected pages,
rather for the first one to be shown as a preview. Now if
we have all pages and nothing changed we update the print
job pages.
bug:10530142
Change-Id: I10fb62ae5ae07b8e54d547fd4dca555a12451bc5
The user has to explicitly enable a print service from the settings UI
before using it. Usually, users very rarely if at all interact with print
services, therefore all print service management task are performed from
the print settings. We also have to get user consent warning that the
user's data is about to be given to a third-party app. We now post a
notification allowing the user to go directly to the settings screen to
turn the service on.
bug:10447510
Change-Id: Iea56c0825f0bf38328ad94912f0ea5576e9339b3
1. Layout was not called after pressing the print button if the
print attributes did not change. This is not correct since the
previous layout calls were for preview purposes and the one
after pressing print is not for preview. Hence, we always have
to do this layout.
2. After layout we decide whether to ask the app to write some
pages. We ask for a write if we do not have the pages selected
by the user or the document changed (if the page count changed,
the document type changed, or the app told us that the content
changed). We were not computing correctly whether the document
changed since we compared the size but the document info the
app passes in after a layout does not have the size yet. We set
the size after a write. So for layout purposes we should ignore
the size. We only care if the page count, document type, or
content changed where the latter is reported by the app in
the layout callback.
3. We were not updating the PrintJob after setting the data
size of the printed document.
4. Disabled debugging.
bug:10835370
Change-Id: Ic3b2871b4e954cdf610f8cf806de5fc6588a6bec
1. Move PdfDocument to android.graphics.pdf.
2. Changed the PdfDocument as per API concil request.
3. Updated the documentation.
bug:10461180
bug:10552565
bug:10681585
bug:10552336
Change-Id: I08e15b34cf37bb064248c887e6f59808019cafe8
1. Typing a range where the start is greater than the end was
leading to a crash.
2. Typing the same single range, e.g. "2,2", was leading to a crash.
3. If two ranges are non-overlapping but consecutive they were
not merged
4. Typing multiple times a digit that is less than the page count,
e.g. page count "2" and typing "11", was not caught by the input
verification.
bug:10812904
Change-Id: I754715b5d792a1a6c3a4f9f644edfa9aea7ac127
