One of the problems I have been noticing is background services
sitting around running and using resources. Some times this is
due to the app developer doing this when they shouldn't, but there
are also a number of issues with the current Service interaction
model that make it very difficult (or impossible) to avoid
getting services stuck in the started state. This is a
change/enhancement to the Service API to try to address this.
The main change is that Service.onStart() has been deprecated,
replaced with a new Service.onStartCommand() that allows the
service to better control how the system should manage it. The
key part here is a new result code returned by the function, telling
the system what it should do with the service afterwards:
- START_STICKY is basically the same as the previous behavior,
where we usually leave the service running. The only difference
is that it if it gets restarted because its process is killed,
onStartCommand() will be called on the new service with a null
Intent instead of not being called at all.
- START_NOT_STICKY says that, upon returning to the system, if
its process is killed with no remaining start commands to
deliver, then the service will be stopped instead of restarted.
This makes a lot more sense for services that are intended to
only run while executing commands sent to them.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if
the service's process is killed before it calls stopSelf()
for a given intent, that intent will be re-delivered to it
until it completes (unless after 4 or more tries it still
can't complete, at which point we give up).
Change-Id: I978f5ca420d70023d1b5e7f97de639d09381f8ad
- @hides relevant APIs
- removes relevant javadoc
- enforces that only system apps can participate
note: general support is still there, will be easy to reenable when we are ready.
Javadoc, and unhide the first pieces of the Bluetooth API.
With this commit there is enough public API to connect and use an RFCOMM
connection between Bluetooth devices.
The window manager now detects when a transition between two
wallpaper activities is happening, and switches to a new set
of animations for that. The animations I defined here are just
an arbitrary something that can work in this case.
support these functions.
This extends the MediaPlayerControl interface with some new methods, and uses
reflection to detect whether the old or new interface is used by an application.
This API is becoming seriously abused, so now it is deprecated and has
become a no-op.
As an alternative, there is now a new API that allows you to make a service
be in the foreground but requires providing a persistent notification to
go along with this state, allowing the user to know about and control it.
Merge commit 'd5884a9ba45e58294c09fd2747c87d761b9daee5' into eclair
* commit 'd5884a9ba45e58294c09fd2747c87d761b9daee5':
Unhide the broadcast intent that signals completion of the TTS language
This is pretty much the same thing as startSearch, except it also launches the
query. We enforce that this can only be done for the package of the app that is
associated with the search mananger (e.g you can't trigger a contacts search
from anywhere).
- Do better about figuring out when to stop them and other related window
management.
- Fix problem where we were not redrawing the surface when the orientation
changed. This was the cause of the device hang.
This unfortunately requires API changes because the existing text markup
classes had no access to the screen density.
TextPaint gains a "density" field so that TextView can pass the density
along. AbsoluteSizeSpan gains a new flag to indicate that its argument
is in dip instead of in physical pixels. LineHeightSpan gains an inner
interface whose chooseHeight() method includes a TextPaint argument so
it can get at the density. And when StringBlock creates the markup
objects, it now uses the density-aware versions.
Bug 1976971, Bug 2031746
Recently we added queryEntities() to the ContentProvider
interface to read out Entity objects atomically. This
change adds a helper to AsyncQueryHandler to perform these
queries on a background thread, returning the result when
finished.
This currently only works for a wallpaper that is larger than the
screen. Set the scroll position with the new wallpaper API. Right
now only does jump scrolls.
When performing a set of batch operations, some callers need
to enforce that a query has specific values. For example,
when persisting edited Contact values, we need to assert
that the RawContacts.VERSION matches the version we read out
through queryEntities().
This change adds a new TYPE_ASSERT that uses withValues()
and withSelection(), and checks all values when applying the
batch operation, bailing if any values don't match.
This adds a new theme for having a wallpaper, and fixes up the window manager
to do the right thing when transitioning between a windows with and without
wallpapers (between two windows with wallpapers is not yet addressed).
The wallpaper API now has callbacks to tell you when to start/stop animating.
Also fiddle the image wallpaper to be a little more interesting.
This is all of the basic pieces:
- The WallpaperService now creates a surface with the window manager for its
contents.
- There is a simple service that displays a bitmap.
- The wallpaper manager takes care of starting and stopping the service.
- The window manager knows about wallpaper windows and how to layer them with
the windows that want to be shown on top of wallpaper.
Lots and lots of issues remain, but at this point you can actually write a
wallpaper service, select it in the UI, and see it behind an activity.
This is mostly refactoring, adding a new WallpaperManager class that takes care
of the old wallpaper APIs on Context, so we don't need to pollute Context with
various new wallpaper APIs as they are needed. Also adds the first little
definition of a wallpaper service, which is not yet used or useful.
The major things going on here:
- The MotionEvent API is now extended to included "pointer ID" information, for
applications to keep track of individual fingers as they move up and down.
PointerLocation has been updated to take advantage of this.
- The input system now has logic to generate MotionEvents with the new ID
information, synthesizing an identifier as new points are down and trying to
keep pointer ids consistent across events by looking at the distance between
the last and next set of pointers.
- We now support the new multitouch driver protocol, and will use that instead
of the old one if it is available. We do NOT use any finger id information
coming from the driver, but always synthesize pointer ids in user space.
(This is simply because we don't yet have a driver reporting this information
from which to base an implementation on.)
- Increase maximum number of fingers to 10. This code has only been used
with a driver that reports up to 2, so no idea how more will actually work.
- Oh and the input system can now detect and report physical DPAD devices.
Merge commit '0da3bdb476086db02a1076780676b21e239c79d6'
* commit '0da3bdb476086db02a1076780676b21e239c79d6':
Fix public API caused due to CDMA changes.
Merge commit '41c104339951e0e5e78240e1f48455c21b3ba5fd'
* commit '41c104339951e0e5e78240e1f48455c21b3ba5fd':
Fix MulticastLock API to match WifiLock API.
