SurfaceControl.closeTransaction() will block until the transaction
takes effect and this happens at the next vsync -- in practice
it means this call blocks for ~15ms.
Immediately after that we ask the choreographer to schedule the
next frame, which will happen at the next vsync. depending the
timing, this would cause the window manager to animate at 30 fps
instead of 60.
This is fixed here by calling the choreographer before we
call closeTransaction().
In the near future, we should be able to fix this by using
an offseted vsync for the window manager and it won't need
closeTransaction() to block at all.
Bug: 10209014
Change-Id: I33d0c5ecfc25154b2859f3023a8cda6e641826bf
ProcessStats is now called ProcessCpuTracker.
ProcessTracker is now ProcessStatsService, and its inner State
class is broken out into a separate top-level ProcessStats class.
This ProcessStats is moved to the framework, so we will be able
to use it elsewhere.
Change-Id: I6a127bcb835b6b474b72647c0b99b82c2137e5c5
Add more locations where mLastPausedActivity must be set null before
calling resumeTopActivityLocked().
Also separate the "No History" activity from mLastPausedActivity by
adding mLastNoHistoryActivity. This is necessary because now
mLastPausedActivity will be null when mLastNoHistoryActivity
is checked.
Continues to fix bug 10022212.
Change-Id: Ida543b0638c865127691dc51a6e0635062539659
The bindService() and startService() calls have always had
undefined behavior when used with an implicit Intent and there
are multiple matching services. Because of this, it is not
safe for applications to use such Intents when interacting with
services, yet the platform would merrily go about doing... something.
In KLP I want to cause this case to be invalid, resulting in
an exception thrown back to the app. Unfortunately there are
lots of (scary) things relying on this behavior, so we can't
immediately turn it into an exception, even one qualified by the
caller's target SDK version.
In this change, we start loggin a WTF when such a call happens,
and clean up some stuff in Bluetooth that was doing this behavior.
Change-Id: I62e25d07890588d2362104e20b054aebb6c0e007
Moving an activity to the back used to move it behind the launcher.
This meant that the test in resumeTopActivityLocked() for
mLastPausedActivity being equal to the top activity would fail after
moveTaskToBack(). In the new activity stack model the launcher is
on a different stack so if there is only one task then the test
now passes. Clearing mLastPausedActivity when moving an activity
forward now passes the test.
Fixes bug 10022212.
Change-Id: I17932d5c87d2483f13c29ae85a7067202a08f34e
This is a process that is not actually running, but would be
if we had enough RAM.
Also rework how service stats are stored to used the nice
compact structure we are already using for processes.
And fix a bug where when we committed the current state data,
we would mistakenly write it under the name of the *next* state
that is now starting. Ouch.
Change-Id: I9f2b84b8b3f305301fd48dcd9d4e6c232abe8ef9
1. The singleton print spooler isntance is created when the print spooler
service gets a connection to the system and is destroyed when this
connection is removed. Note that if the spooler has work, then the
connection to the system will not be removed.
When the spooler is created, it reads the stored state and notifies the
system which in turn dispatches this to the print services.
When the system connects to the spooler and passes it a connection, we
schedule a delayed check whether there is work for the spooler. We do
not handle this immediately to avoid intermitted spinning on and off
of the spooler process if a client makes a sequence of queries while
the spooler has really no work.
2. Fixed a bug in the NotificationManagerService where adding a notification
and removing it immediately after that does not remove the notification.
The code that is adding a notification is run on a handler thread while
the code to remove it on the calling thread. This creates a race and
erroneous results. Now the removal is also scheduled on the handler.
3. Many small fixes here and there.
Change-Id: I6415c253139fa6616393fbe23c659d031a29e1f6
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
Devices can be configured to remain in their default landscape or
portrait orientation by setting config_forceDefaultOrientation true
in overlay/.../values/config.xml.
Activities that desire to run in the non-default orientation are
supported by creating a logical display within the physical display.
Transitions to and from the activity perform a crossfade rather than
the normal rotation animation.
Also, improve SurfaceTrace debug output.
Fixes bug 9695710.
Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
1. Added notifications for a queued print job, for a started print job,
for ongoing canceling a print job, and for a failed print job. The
notifications for queued and started state have a cancel action. The
notification for failed print job has a cancel and a restart action.
2. Propagating failure message from the print service to the notifications.
3. PrintJobConfigActivity was not setting the initial value for the
print job copies and was not updating the UI immediately after creation.
4. Refactored PrintJobConfigActivity to avoid using the hack to avoid
reaction for item selection change in a spinner for an event that
happened before the callback was registered.
5. Removed the label attribute from PrinterInfo and now PrinterId is
composed of the printer name and the service component name. This
is nice since for restarting print jobs we do not need to store
information about the printer except the printer id which is
already part of the PrintJobInfo's data. Also the printer name
is not expected to change anyway.
6. Allowing cancellation of a queued print job. Also no print job is
cancelled without asking the managing print service to do that.
Before we were immediately canceling print jobs in queued state
but it was possible for a buggy print service to not set the
print job state to started before starting to do expensive work
that will not be canceled.
7. PrintServiceInfo was throwing an exception the the meta-data
XML for the print service was not well-formed which would crash
the system process. Now we just ignore not well-formed meta-data.
8. Removed unused permissions from the PrintSpooler's manifest.
Change-Id: Iba2dd14b487f56e137b90d1da17c3033422ab5e6
The goal is to collect PSS data from processes when they
are in as stable a state as possible. We now have tables
for the durations to use for PSS collection based on
process state, and scheduling of collection is all driven
by process state changes.
Change-Id: I95e076f6971b9c093118e53dc8240fb3f5bad3b2
