components by apps which could result in thrashing on the PackageManager. For apps that
do not want to be restarted when such a broadcast is sent, we can just aggregate these broadcasts and
handle them at one go.
Changes include:
New structure to hold pending broadcasts by class name. If a component is enabled or disabled frequently
aggregate component enabled/disabled settings in this structure in a 10 second window and then
send out the accumulated list of broadcasts to the ActivityManager.
A new Handler implementation handles this message
Add new attribute name EXTRA_CHANGED_COMPONENT_NAME in broadcast intent Intent.ACTION_PACKAGE_CHANGED for
additional information for apps like Launcher.
Rename a couple of parameters, the names were too jarring.
Applications can now specify two more aspects of the restore process: whether
they need to run with their own custom Application subclass rather than being
launched in the usual restricted mode during restore, and whether it's okay for
the backup manager to kill the app process once restore has completed. The new
manifest attributes for these are, respectively, android:restoreNeedsApplication
and android:killAfterRestore.
If unspecified in the manifest, restoreNeedsApplication is false, and
killAfterRestore is true.
In order to support kill-after-restore cleanly, this change also adds a new
system-process-only interface to the Activity Manager, which will schedule a
"commit suicide" event on the target app's main thread looper.
The framework backup agents have been given the appropriate new backup
attributes as well.
This introduces a new mechanism to define features associated with
a platform, query the current device for the available features,
and enforce that apps requiring features that aren't available can't
be installed.
Also now allows uses-library to specify that a library is optional,
so the lack of such a library will not prevent the app from being
installed (but if it does exist it will be correctly linked into
the app).
Change-Id: I5b369b46cfa0b3d37c9e08fd14ef1098a978e67b
Unfortunately we are stuck with the donut ones, can't change these in Eclair
to be the more correct names.
Change-Id: Id8aaa2e90cd21631b18a36bea3755a63d0e6d577
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.
Split BluetoothDevice into BluetoothDevice and BluetoothAdapter.
BluetoothAdapter: Represents the local BT adapter. Operations on the local
adapter (start a scan, etc).
BluetoothDevice: Represents a remote BT device. Operations on remote devices
(pair, connect, etc).
IBluetoothDevice.aidl -> Bluetooth.aidl
BluetoothDeviceService.java -> BluetoothDeviceService.java
TODO:
Javadoc
Docking station intents for dock switch driver.
Add DockObserver and updated Intent.java and systemserver.jave
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
modified: core/java/android/content/Intent.java
new file: services/java/com/android/server/DockObserver.java
modified: services/java/com/android/server/SystemServer.java
Docking station updates
Add constants for the dock
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
- 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.
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 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.
Without this, it's really hard to debug exceptions coming
over from a ContentProvider. This is lightweight logging
that is only triggered by an exception, and doesn't write a
full stacktrace.
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.
