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
