You can no longer receive CONFIGURATION_CHANGED in a manifest, which is really really
bad (launching apps every time the screen is rotated!). A new LOCALE_CHANGED broadcast
is sent that you can receive in a manifest.
Change-Id: I80022375f0716db2e672382a29db3cea1af74702
This adds a history of the last 100 broadcasts that is printed in the
debug log, to be able to see what recently happened at the time the
bug report was taken. Also does some optimization of the printing of
the broadcast records to make it feasible to print this number of
entries. (We kind-of need to do this because there are some broadcasts
like SIG_STR and SYNC_STATE_CHANGED that are being broadcast a LOT.)
Change-Id: I775e1ec0f63369c8bca8c83cee27b95ddc5ec450
The window token rearrangement is defered if an animation is
underway. Force a focus recomputation when the window tokens are finally
rearranged so that we have a valid focused window.
The locale picker and the activity transition would both change the
configuration, and depending upon the timing, the activity transition
would undo what the locale picker had just done. Usually it worked right,
but would often fail if the user changed locales just after a data wipe,
when the media scanner was working hard in the background to index
the contents of the SD card.
http://b/issue?id=2216298
Track phone service state changes and use a separate timer for out-of-service
since the hunting can timeout on some devices.
Store the timeout value in the config.xml, as it is device/network specific.
Settings App will also change to use the hunting duration to compute the cost
of zero signal.
- Don't crash if the service's app process doesn't have a thread (this
can happen if we are currently starting the process and then try to
start the service again).
- Be more robust about deciding to start a service's process: try each
time it is started; the startProcess call will take care of ignoring
it if the process is already started.
- Fix some issues where we would leave dead processes on the low memory
list.
Change-Id: I490e01ba7b45adc191bab7ace377b6873e284897
Don't hold a lock when the activity thread is telling the activity manager
to release a provider.
This requires that the activity manager now keep a reference count on the
providers, because without the lock it is possible for activity thread to
call in to request the provider again before it has finished telling
about the release.
Change-Id: I5f912903891f4edae85e28819d4e6f14b8f2e688
Tell the broadcast receiver whether it is getting an initial sticky value,
so it will be quiet about attempts to do ordered broadcast stuff.
Note that the original bug being reported was not actually a crash, just
an error log. So all we are doing here is making the log quieter.
Change-Id: Iaf1b718d82093ec1197142410a64feff47eb3859
(when booted while docked)
This isn't really a fix, but we now have the activity report the configuration
it actually launched in, so the activity manager will later adjust it if
needed. Should help us recover from hitting the race in this particular case.
Change-Id: I3bb83a48c2d692b4cb1822d8ae7d924cfa9187b2
The core logging in BackupManagerService and in the Google backup transport are
still enabled at this point.
Change-Id: I10abfa565bbd1097dd3631051b6aca163e4af33a
If not these system services will end up with inconsistent settings files
when the device runs out of storage.
Delete mangled settings file in PackageManager if the current write fails
so that we don't end up overwriting the backed up version with the
mangled version
Include null check when retrieving fwd locked resource for an existing package
I think when we were scanning the updated app in the system image,
from an older version on the data partition, we were not setting
the existing package to have the system flag, so not auto-granting
any new permissions.
This also includes some other cleanup in the package manager to
remove old files in various places, and tighten up logging.
Also similar logging cleanup elsewhere.
Change-Id: I6d113c7cf7e736ab9be512d6d7c94c806a24199a
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
The context used by the status bar (i.e., the system context) was
not properly initialized to have the right ApplicationInfo inside
its PackageInfo. This eventually caused it to believe that it
was running at 160dpi.
Kudos to Dianne for figuring this out.
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
More CPU speed stepping happening with newer devices, so we need
to qualify CPU time with the CPU speed, since power consumption
varies greatly by speed. Apps that peg the CPU should get a higher
penaltly.
Also, fix for 2062930: NPE at VolumePreference.onKey()
Avert your eyes!
The key change here is that RemoteViews can now call a Context API to
start its pending intent, which inside of the activity manager we can
use to determine to cancel the timeout delay for external entities
to disrupt the home screen.
Change-Id: If097cf7478cbed7a3c04a304050bd7fd5703d197
Some more tweaks and fixes to wallpapers. Make sure wallpapers are
told they are not visible when the screen is off. Add some new animations
for transitions across tasks, and fiddle with many of the existing
animations. Clean up the relationship between translucent activities
and animations. Add new API to start a PendingIntent from an
activity.
Change-Id: Ie0bf45fe44081bb6982c75361257a55d9cd9d863
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.
