The ActivityManager.restartPackage() API is now deprecated, and no longer
allows applications to mess up the state of other applications. This was
being abused by task killers, causing users to think their other applications
had bugs.
A new API is introduced for task killers,
ActivityManager.killBackgroundProcesses(), which allows these applications
to kill processes but only the same amount that the out of memory
killer does, thus causing no permanent damage. The old restartPackage()
API is now a wrapper for calling this new API.
There is also a new private forceStopPackage() API that is used for the
system's force stop UI which does what the old restartPackage() API did.
Squash of the following:
services: MountService: Rework the way volume states are handled
MountService: Add new API for directly getting volume state via a mount point
Environment: Switch from using system property for external storage state.
MountService: Add support for UMS
MountService: Fix a few bugs
services: MountService: Add support for mount-on-insertion
services: MountService: Add some debugging around UMS
services: MountService: Fix some UMS bugs and clean-up startup mount code
Signed-off-by: San Mehat <san@google.com>
LocationManagerService was just checking if the string of (comma-separated)
Location Providers contained the provider we were interested in. This works
fine in normal cases, but breaks if we add a provider such as test_network.
Enabling test_network causes LocationManagerService to think that the network
provider is also enabled.
The code in Settings.Secure.isLocationProviderEnabled() checks for the commas
in the string as well, to make sure that a provider name which is a substring
of another provider name won't cause problems. It also centralizes the code
which reads the string.
Signed-off-by: Brad Larson <brad.larson@garmin.com>
This provides a quick fix for http://b/2298803 (if the
in-call UI comes up while the user is holding the
windowshade, the shade sticks in place and the display
becomes unresponsive).
(NB: The shade disappears immediately when the status bar is
disabled. It might be better for the shade to animate
closed; indeed, this seems to be what the code was trying to
do, but an unfortunate interaction of the animation and
touch-handling code is what caused this bug in the first
place.)
Change-Id: I92a824fe385c8d6e51993be1657b492e580f1e7b
Change how we do debug dumps from the activity manager to make
everything go through the activity manager interface (no more
secondary interfaces), and use the command line arguments to
control what gets dumped.
The output from dumpsys without args still dumps everything.
When just dumping the activity service, we now dump a subset
of all of the am state that is interesting without being
overwhelming.
You can use "dumpsys activity -h" to get help with other things
that can be dumped.
This was caused by the launchers new hidden surface on top. The
algorithm for determining whether an activity was visible assumed
that all windows would want to be visible. Now it ignores ones that
have explicitly requested to be hidden.
The crashes are also reported to the event log (and of course the
main logcat, like they always have been). Ordinary Log.e(t,m,e) isn't dropboxed
but there's a new Log.wtf() which always is. (Still @pending in this change.)
Add a hook to IPowerManager to crash the system server on demand
(only for apps with REBOOT permission, since it's basically a restart).
This is not exposed in PowerManager, must be invoked directly -- mostly
this is there so "Bad Behavior" in dev tools can do it.
Yet more special casing for the window manager... try really hard,
if we are performing an activity transition that is behind an
opaque window (like say the lock screen or status bar) to just not
do it. And, just as important, do a reasonable transition away from
whatever is on top.
Examples:
- If the lock screen is up, and you get a call or press the
emergency dialer button, we fade from the lock screen to the
new UI, instead of fading to the animation going on between
the old and new.
- If you are in something hiding the lock screen, like the
in-call screen, and that is hidden, then fade back to the
lock screen.
- If you select an item from the status bar, then have the
new item displayed behind it as the status bar rolls up
rather than seeing a second animation. (In fact this can't
always be done because we may not start the transition to
the new thing until the status bar is already going away.
But for most cases we can do this with just one anim.)
Merge commit '47c38f00ab464a8fdb6ae2d819ae189c17b72410'
* commit '47c38f00ab464a8fdb6ae2d819ae189c17b72410':
Issue #2335763: Cant dial emergency number on my device
Merge commit '558947c9899627067d632e8a6365f77a35f433e1' into eclair-plus-aosp
* commit '558947c9899627067d632e8a6365f77a35f433e1':
Issue #2335763: Cant dial emergency number on my device
This may fix the issue, but we have no repro steps so no way to
make sure.
What appeared to be going on was that the emergency dialer was
created, but still had the starting preview window above it. We
were stuck in this state because the preview window didn't have
the "hide lock screen" flag set, so the lock screen would never
be removed, and thus we would never take care of finishing the
show of the emergency dialer (because it was not visible) and
thus not remove the starting window.
The solution here is to simply propagate the lock flags up to the
starting window.
Change-Id: I6da9f6494537f0661d9d230664ebf745c293ea7d
This is intended to solve a problem on devices with more memory
where we can fill up that memory with processes that contain activities
(hidden processes), leaving no room for empty processes. Thus if a
process is receiving broadcasts regularly, or starting and stopping
a service, or such, we will continually create its process only to
have it immediately killed when done.
There is certainly some tuning that should be done on this as we
look at the actually behavior. The implementation here puts all of
the hidden and empty processes into one list, trying to make some
preferences for the very most recently used activity's processes to
stay at the top and not get pushed out by other processes being
started in the background.
Merge commit '83652ebfe1963bcecdcf24383165904223baca6e'
* commit '83652ebfe1963bcecdcf24383165904223baca6e':
Implement API to have new broadcasts replace existing broadcasts.
Merge commit '3a3fd2ba1ffc6171725375396cc59711a34bb39e' into eclair-mr2-plus-aosp
* commit '3a3fd2ba1ffc6171725375396cc59711a34bb39e':
Implement API to have new broadcasts replace existing broadcasts.
Use this in various places where it should serve no purpose to deliver
both broadcasts. This is intended to reduce somewhat the flurry of
broadcasts that we churn through during boot.
The problem is due to spurious headset connection indications received from event observer when a 3.5mm headset w/o mic is connected.
In this particular case, The HeadsetObserver first received a valid indication of headset with mic connection, followed by a headset with mic disconnection and finally a headset w/o mic connection.
The HeadsetObserver delays the headset disconnection intent to leave time to music app to pause music before the output path is switched.
As the last headset w/o mic connection indication is received from the event observer before the intent corresponding to the spurious headset with mic disconnection is broadcast, the later is discarded. Results a state where the headset with mic is always considered as connected.
The fix consists in not canceling pending intents when a new headset state is received and carrying the HeadsetObserver state with the delayed message triggering the broacast of the disconnection intent.
Merge commit '6a6f43f577c6cb22202ee86fb3c6d1601f36c3b5'
* commit '6a6f43f577c6cb22202ee86fb3c6d1601f36c3b5':
Fix#2269582 Sometimes camera preview screen is truncated
Merge commit '8091424ea332f754e6f1c712a9e28bfa7d02741e' into eclair-mr2-plus-aosp
* commit '8091424ea332f754e6f1c712a9e28bfa7d02741e':
Fix#2269582 Sometimes camera preview screen is truncated
Merge commit '9b52a2184e99565bcd7f77effb321c95a2a4837e' into eclair-mr2
* commit '9b52a2184e99565bcd7f77effb321c95a2a4837e':
Fix#2269582 Sometimes camera preview screen is truncated
Merge commit '9b52a2184e99565bcd7f77effb321c95a2a4837e' into eclair-plus-aosp
* commit '9b52a2184e99565bcd7f77effb321c95a2a4837e':
Fix#2269582 Sometimes camera preview screen is truncated
There were a few places in the window manager where we wouldn't cause
a layout after making a window visible. This would leave it using
whatever size and position it last have since we don't layout windows
when they are not visible.
Also includes a little part I missed in the security issue that
allowed wallpapers to see input on the lock screen.
Change-Id: Icd7e037ad9a67ac936bc7039d87ed68f49502d73
Make sure the application is always given the most recent configuration
when launcher. Use the current configuration, instead of whatever happens
to be set by the app, for reporting what it was launched with.
Change-Id: I2ffe306f56cc9092b640546dd0a28d2c29b9c0b3
(CrashData was a custom-marshalled crash-info class used for a server crash
reporting system I am deprecating). Use ApplicationErrorReport.CrashInfo
instead to report crash details (mostly the stack trace) from RuntimeInfo to
ActivityManagerService, since we're likely to need the crash information in
that form anyway.
Remove the (long-disabled) flags and support for the "Debug" button
in the crash dialog.
Further gut the ICheckinService interface by removing the crash-reporting
APIs (and everything that calls them), plus the synchronous checkin()
method (which has been stubbed out for a while now).
A new dropbox-based crash reporting system is in the works, but not part
of this change.
Merge commit 'af1255dab8fa3eab1caf9bae799f80de14a74470' into eclair-mr2-plus-aosp
* commit 'af1255dab8fa3eab1caf9bae799f80de14a74470':
Fix#2320798: Device hang then runtime restart
