Merge commit '743a7495ab365d8a84a25ac93e22b6e6e4c5e0b4'
* commit '743a7495ab365d8a84a25ac93e22b6e6e4c5e0b4':
Make new attribute EXTRA_CHANGED_COMPONENT_NAME in
broadcast intent ACTION_PACKAGE_CHANGED public so that
apps like launcher can find out the changed component name
when loading changes made in components.
Merge commit '9073dc69b110cbd0d4bebd128ed6cc2b24a16695'
* commit '9073dc69b110cbd0d4bebd128ed6cc2b24a16695':
Expand apps' control over the settings restore process
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.
Merge commit 'c804efe278fa33555e6e836504a467cb14505eb3' into eclair
* commit 'c804efe278fa33555e6e836504a467cb14505eb3':
Update 4.xml to the most recent APIs.
Expose the presence/absence of IccCards in the system.
This is needed to fix bug 2033811 which needs to show
some SIM menus in the Mms app and Contact apps only if
there is a SIM and on CDMA there is no sims yet.
The current implementation assumes CDMA never has an
IccCard this is true at the moment but needs to change.
Change-Id: I4167368e364623ea68e9b2778556e6d730b1e715
Merge commit '93ca790c025d51780bff9be42cffdd0055091edb'
* commit '93ca790c025d51780bff9be42cffdd0055091edb':
Various infrastructure to support a running services UI.
Some of this is temporary (in particular the two approaches for getting
process memory, one working but horrible, the other not working but
preferred) until I figure out the best way to do it.
Change-Id: I8c8f25062d481fcea22a47d459b083d2fd8a5040
This change adds the EventHandler error codes to WebViewClient for the public
api. Previously, the api was ambiguous about the value of the errorCode
parameter and falsely documented that the values are HTTP status codes.
Merge commit '9b52ad61642c84f74c89627eeb28d03ebb44386c'
* commit '9b52ad61642c84f74c89627eeb28d03ebb44386c':
add the ability to specify yieldpoints in a ContentProviderOperation
Merge commit '8c0fa1a2e5966b685f75e438eb089701b404b6ef'
* commit '8c0fa1a2e5966b685f75e438eb089701b404b6ef':
Revert "Remove third party support for Quick Search Box (aka global search)."
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
Merge commit 'fef09e8f98f61d3d89a3890f5917061fd6a73015'
* commit 'fef09e8f98f61d3d89a3890f5917061fd6a73015':
Fix issue #2084148: Define the format for the auto focus preview for barcode scanning
Add new manifest/aapt support for specifying device features an application
requires. The aapt badging now returns these (as well as uses-permission since
I need to look for those anyway); if an app doesn't explicitly request the
camera feature but does request the permission, then aapt will say that it has
requested both the basic camera feature as well as the autofocus feature.
Here's what you put in your manifest to say you need a camera but don't need
autofocus:
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
Here's what will be seen from aapt:
uses-permission:'android.permission.CAMERA'
uses-feature:'android.hardware.camera'
uses-feature-not-required:'android.hardware.camera.autofocus'
Change-Id: I4dd19cee0486cc54771f5bf14fc9db0e892115d5
Merge commit '3d937945a60da48a383a5a3de37583b35abf9c11'
* commit '3d937945a60da48a383a5a3de37583b35abf9c11':
Change these string constants back to match donut.
Unfortunately we are stuck with the donut ones, can't change these in Eclair
to be the more correct names.
Change-Id: Id8aaa2e90cd21631b18a36bea3755a63d0e6d577
Now that we've merged ContactsContract and are relying on
compatibility mode, we're marking the previous public
contacts API as deprecated.
Fixes http://b/2076016
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.
