Actually being able to configure a wallpaper relies on additional
work in the launcher and wallpapers that will be in another change.
Also note that this breaks all existing wallpapers, since they now
need to include a meta-data item about themselves. This also
will be fixed in another change.
Change-Id: I97d2c2bd07237abc32f92b9147c32530a2f73c71
The check for whether the release call is coming from another process was
very broken, and just happened to work by chance. It also never worked for
apps that had code running in two different processes, with one process
using a provider in another of its processes. Also a little cleanup and
debugging logs for provider management, and removal of that increasingly
annoying log about services being stopped.
Change-Id: Ibc298e674db7d35c4b6499fb32e30929a141b670
This makes the system a little more careful to not start third party
code until it is ready to.
Also fix a little bug in SyncManager that would cause it to crash
during boot if sync was in a failure state.
Change-Id: Ib2d287d8441d155d393fe740a5f98690895fd358
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
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.
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
- Reduce the amount that we ask processes to GC after a significant
operation occurs, but introducing a minimum time between GCs and
using this in various ways to schedule them.
- Don't spam all of the processes with onLowMemory(). Now deliver
these using the same gc facility, so we do the processes one at a
time, and don't allow the same process to get this call more than
once a minute.
- Increase the time a service must run before we will reset its
restart delay to 30 minutes (from 10).
- Increase the restart delay multiplication factor from 2 to 4.
- Ensure that we don't restart more than one service every 10 seconds
(unless some external event causes a service's process to be started
for some other reason of course).
- Increase the amount of time that a service must run before we
decide to lower it to a background process.
And some other things:
- Catch IllegalArgumentException in ViewRoot like we do for no
resources to avoid the system process crashing.
- Fix a number of places where we were missing breaks between the
activity manager's message dispatch func(!!).
- Fix reason printed for processes in the background.
- Print the list of processing waiting to GC.
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
Merge commit 'd50066f8d2ab82c2c8ff305c86cc9b39eaca3c28' into eclair
* commit 'd50066f8d2ab82c2c8ff305c86cc9b39eaca3c28':
invoke sendMessage instead of dispatchMessage to avoid deadlocks in ActivityManagerService
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 'd9d2576017fadcf47589b54e8ee198f48cc19352' into eclair
* commit 'd9d2576017fadcf47589b54e8ee198f48cc19352':
Remove dead locks in system process when installing packages
This adds some new debugging code to make it easier to see why a process is at
a certain oom_adj level -- for example telling you that a certain other process
has a binding to a certain one of its services. This has helped a lot in
identifying cases where processes are holding references to other processes that
they don't need and thus not allowing the system to get memory it needs.
Also fix a few problems with leaking entries on the service restarting and
service stopping lists.
Re-arrange various things to ensure that the search dialog is told about system windows being
closed before it is told about the navigation back to home.
Create a new package setting object for updated system apps rather than moving
around the same setting. This updates the resource, code and version correctly.
For updating system packages, disable the package first which removes the entry
from internal structures, create a new package setting, add it to list of user id's
then rest of installation steps, kill the process if needed via ActivityManager
then add this setting if everything was successful. This also fixes issues with
updating values prematurely.
When a new version of system package is available via OTA, just physically remove
entries for pkg. Note that the component and other info will be eventually updated
later on when scanning the package.
Also move certificate verification slightly ahead before scanning packages.
Some null checks
New api's in ActivityManager to kill an application pkg before finishing installation
This was previously hard-coded to 0. Now set to the value of the
"ro.opengles.version" system property. The default value is
ConfigurationInfo.GL_ES_VERSION_UNDEFINED.
Merge commit '11b822d2a91ea17c34c0cb1c11e80a9a30d72864'
* commit '11b822d2a91ea17c34c0cb1c11e80a9a30d72864':
Simplify density compatibility to a boolean.
Instead of a list, we now just have a single boolean indicating whether an
application is density aware, and this set set to true by default as of
Donut.
Merge commit 'fae76f5bdeed68efd85805db143b0426de92f7e0'
* commit 'fae76f5bdeed68efd85805db143b0426de92f7e0':
Fix issue #1985502: Sapphire (and any other device) reports that it has a hard keyboard
Merge commit 'eb09c6a07abf58b4da2c4baf3800a1f96e3b0731'
* commit 'eb09c6a07abf58b4da2c4baf3800a1f96e3b0731':
Issue #1969025: need api for launching intent as if it were coming from another component
This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named
IActivityWatcher.
This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
This adds a new <path-permission> tag you can use inside of a <provide>
to define additional path-based permissions that broaden the global
read and write permissions. The initial use for this will be global
search, so that a content provider that is protected by permissions
can make a part of itself available to global search under another
permission. This addresses the issue with global search not being able
to request permissions it would need of providers it doesn't know
about at build time.
Merge commit 'd7cd29da91ccc0aba1f1097e19366f9ca36c7ce1'
* commit 'd7cd29da91ccc0aba1f1097e19366f9ca36c7ce1':
Add facility to run setup wizard after an update.
The system now keeps a tag of the last version (just an arbitrary string)
that the setup wizard was run for. If this is different than the current
one in the setup wizard, then setup is launched at boot.
This introduces a new intent action for the part of the setup wizard that
gets run for an ungrade, which the system uses to find its current version
tag for comparing against what was last stored. It is up to the launched
setup activity update the stored setting to reflect its current value,
once it is happy.
It turns out this was not a problem in the resource code at all. Rather,
the system process has a cache of pre-loaded attributes it uses to avoid
continually reloading things as it needs them. Well it turns out this
cache wasn't flushed after a package was uninstalled or a configuration
changed, so you could re-install an app where you change its style resources
so its theme now points to one that is inconsistent in the cache.
This is mostly a problem for developers, where they continually install
new versions of an app where resources have changed. This could possibly
show up when updating an app on a normal phone, although the problem would
eventually correct itself since this cache uses weak references.
Anyway, the cache is now reworked to be flushed appropriately.
This change also includes an update to aapt to be able to dump the
contents of bags in resources.
Merge commit '8a27f923eb9dbbe3c2d0184e82d9f1a98f1e4cdc'
* commit '8a27f923eb9dbbe3c2d0184e82d9f1a98f1e4cdc':
Don't crash in various ways when using backup services too early
BackupManager now no longer tries to use a null service binder if it's used
early during the boot process. ActivityManagerService no longer tries to
dereference null pointers if bind/unbind semantics get out of step due to things
being run too early.
Merge commit 'f881762f97c74253bbc7f629380bb65739457041'
* commit 'f881762f97c74253bbc7f629380bb65739457041':
Add a method to Process to get uid for a pid.
