1. Now a user state has ins own spooler since the spooler app is
running per user. The user state registers an observer for the state
of the spooler to get information needed to orchestrate unbinding
from print serivces that have no work and eventually unbinding from
the spooler when all no service has any work.
2. Abstracted a remote print service from the perspective of the system
in a class that is transparently managing binding and unbinding to
the remote instance.
3. Abstracted the remote print spooler to transparently manage binding
and unbinding to the remote instance when there is work and when
there is no work, respectively.
4. Cleaned up the print document adapter (ex-PrintAdapter) APIs to
enable implementing the all callbacks on a thread of choice. If
the document is really small, using the main thread makes sense.
Now if an app that does not need the UI state to layout the printed
content, it can schedule all the work for allocating resources, laying
out, writing, and releasing resources on a dedicated thread.
5. Added info class for the printed document that is now propagated
the the print services. A print service gets an instance of a
new document class that encapsulates the document info and a method
to access the document's data.
6. Added APIs for describing the type of a document to the new document
info class. This allows a print service to do smarts based on the
doc type. For now we have only photo and document types.
7. Renamed the systemReady method for system services that implement
it with different semantics to systemRunning. Such methods assume
the the service can run third-party code which is not the same as
systemReady.
8. Cleaned up the print job configuration activity.
9. Sigh... code clean up here and there. Factoring out classes to
improve readability.
Change-Id: I637ba28412793166cbf519273fdf022241159a92
To minimize fix size, return only valid dreams from the service api.
Settings will "just work" with no changes.
Bug:7699398
Change-Id: I3eb88237a8ccc421fdb68d1de19820614b13d7b8
Implement a timeout between when the dream binds and
when the dream creates the service connection. If
the connection is not created within a certain amount of
time, stop the dream.
This fixes the current bug where a dream that crashes in
onCreate (or the ctor) can put the dream controller in a
bad state until the screen is turned off.
The timeout is equal to the service restart delay in
activity manager (ActiveServices) to avoid restarting
(and recrashing).
Bug:7596707
Change-Id: I3e11efc6af0b79ec4cb0fbc94e4e109c7602ddac
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
Bug: 7368245
Log a warning if the system process calls unqualified sendBroadcast()
and other calls.
As a result of the logging above, found a few more method calls such as
bindService() that would benefit from being more explicit to avoid
future confusion and reduce the log warnings.
Change-Id: I17f15c8be9adf7becd456d6abbab606f19befdbf
Reduce reliance on Service interface overrides, instead
steering clients to the DreamService-specific lifecycle
hooks:
onAttachedToWindow .. onDreamingStarted ..
onDreamingStopped .. onDetachedFromWindow
The old Dream.java is finally gone now too.
Bug: 7281802
Change-Id: Ib7802c3397fde60ad1132fa49831da182eef4d7a
Clearly isolated the DreamManagerService and DreamController
responsibilities. DreamManagerService contains just enough logic to
manage the global synchronous behaviors. All of the asynchronous
behaviors are in DreamController.
Added a new PowerManager function called nap() to request the device
to start napping. If it is a good time to nap, then the
PowerManagerService will call startDream() on the DreamManagerService
to start dreaming.
Fixed a possible multi-user issue by explicitly tracking for
which user a dream service is being started and stopping dreams
when the current user changes. The user id is also passed to
bindService() to ensure that the dream has the right environment.
Fix interactions with docks and the UI mode manager. It is
important that we always send the ACTION_DOCK_EVENT broadcast
to the system so that it can configure audio routing and the like.
When docked, the UI mode manager starts a dock app if there is
one, otherwise it starts a dream.
This change resolves issues with dreams started for reasons other
than a user activity timeout.
Bug: 7204211
Change-Id: I3193cc8190982c0836319176fa2e9c4dcad9c01f
