Some of the native calls were left unsynchronized in the framework. Pre-empted IOCTL call
interrupted by another call from the framework cannot be handled in the driver.
Bug: 2310455
Shutdown handlers run too early for unmounting, so don't handle it.
Shutdown will be called explicitly from the ShutdownThread
Signed-off-by: San Mehat <san@google.com>
Adds android.os.RecoverySystem (marked as pending) to replace the
(hidden) com.android.internal.os.RecoverySystem. RecoverySystem
contains methods for:
- verifying the signature of an update package
- rebooting to install a package
- rebooting to wipe user data
(The reboot functions require "android.permission.REBOOT" and
"android.permission.ACCESS_CACHE_FILESYSTEM".) Providing these
simplifies implementation of OTA update for device builders.
Change-Id: I63ce743b156e7a1a0327fd395b0e4a82c0eda79a
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.
