- When shutting down, if the screen goes to sleep there is code
that tries to do a notifyAll without holding the lock:
java.lang.IllegalMonitorStateException: object not locked by thread before notifyAll()
at java.lang.Object.notifyAll(Native Method)
at com.android.server.am.ActivityStack.checkReadyForSleepLocked(ActivityStack.java:776)
at com.android.server.am.ActivityStack$1.handleMessage(ActivityStack.java:282)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at com.android.server.ServerThread.run(SystemServer.java:603)
- If an invalid Uri object is sent to the system process it can crash because
the Uri class throws an assertion while unmarshalling. Change this to an
IllegalArgumentException so it gets sent back to the caller:
java.lang.AssertionError
at android.net.Uri$PathPart.readFrom(Uri.java:2224)
at android.net.Uri$HierarchicalUri.readFrom(Uri.java:1106)
at android.net.Uri$1.createFromParcel(Uri.java:1689)
at android.net.Uri$1.createFromParcel(Uri.java:1681)
at android.content.IContentService$Stub.onTransact(IContentService.java:53)
at android.content.ContentService.onTransact(ContentService.java:120)
at android.os.Binder.execTransact(Binder.java:338)
at dalvik.system.NativeStart.run(Native Method)
- StrictMode can try to access the first index in the stack crawl of a stack crawl
array of length 0. Not sure why this happens, but make the code more robust:
java.lang.ArrayIndexOutOfBoundsException: length=0; index=0
at android.app.ApplicationErrorReport$CrashInfo.<init>(ApplicationErrorReport.java:341)
at android.os.StrictMode$ViolationInfo.<init>(StrictMode.java:1978)
at android.os.StrictMode$AndroidBlockGuardPolicy.startHandlingViolationException(StrictMode.java:1097)
at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1068)
at libcore.io.BlockGuardOs.read(BlockGuardOs.java:137)
at libcore.io.IoBridge.read(IoBridge.java:426)
at java.io.FileInputStream.read(FileInputStream.java:179)
at java.io.InputStream.read(InputStream.java:148)
at com.android.internal.os.ProcessStats.readFile(ProcessStats.java:804)
at com.android.internal.os.ProcessStats.getCpuSpeedTimes(ProcessStats.java:564)
at com.android.internal.os.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:545)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1470)
at com.android.server.am.ActivityManagerService.batteryNeedsCpuUpdate(ActivityManagerService.java:1522)
at com.android.internal.os.BatteryStatsImpl$MyHandler.handleMessage(BatteryStatsImpl.java:110)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at com.android.server.am.ActivityManagerService$AThread.run(ActivityManagerService.java:1302)
(Also fix this code to not cause strict mode to trigger at all, because there is
no need, because this is just reading stuff from /proc.)
- The system seems to crash during boot if it thinks it needs to rotate
the screen, when it is trying to take the freeze snapshot way too early.
There is no need to freeze the screen during boot or if the screen is off:
java.lang.NullPointerException
at android.view.Surface.init(Native Method)
at android.view.Surface.<init>(Surface.java:256)
at com.android.server.wm.ScreenRotationAnimation.<init>(ScreenRotationAnimation.java:91)
at com.android.server.wm.WindowManagerService.startFreezingDisplayLocked(WindowManagerService.java:8758)
at com.android.server.wm.WindowManagerService.startAppFreezingScreenLocked(WindowManagerService.java:3971)
at com.android.server.wm.WindowManagerService.startAppFreezingScreen(WindowManagerService.java:4003)
at com.android.server.am.ActivityRecord.startFreezingScreenLocked(ActivityRecord.java:515)
at com.android.server.am.ActivityStack.ensureActivityConfigurationLocked(ActivityStack.java:3997)
at com.android.server.am.ActivityManagerService.updateConfigurationLocked(ActivityManagerService.java:12535)
at com.android.server.am.ActivityManagerService.updateConfiguration(ActivityManagerService.java:12439)
at com.android.server.wm.WindowManagerService.systemReady(WindowManagerService.java:6161)
at com.android.server.ServerThread.run(SystemServer.java:521)
Change-Id: I85062bb5f6b0909a0f52feedaa75e7611d9d7fbd
- Improve how we handle processes that have shown UI, to take care
of more cases where we want to push them into the background LRU
list.
- New trim memory level for when an application that has done UI
is no longer visible to the user.
- Add APIs to get new trim memory callback.
- Add a host of new bind flags to tweak how the system will adjust
the OOM level of the target process.
Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
Also improve how we handle services, keeping track of whether they showed
UI and if so putting them immediately on the LRU list.
Change-Id: I816834668722fc67071863acdb4a7f427a982a08
Now classify background processes into a set of bins of how much
memory they should try to clear. The last bin also involves
destroying all activities in that process.
Removed the old code for the simulator that is no longer needed
(yay). The debugging features it had are now integrated into the
regular oom adj code.
Small fixes to load average service.
Change-Id: Ic8df401714b188c73b50dbc8f8e6345b58f1f3a0
Location manager now checks for such intents, and logs a warning when
they are given to it. Nothing thrown yet, it needs to check the
targetSdkVersion of the caller somehow.
When sending the pending intent, we require that the recipient hold the
appropriate permission. This should pretty much close the security hole.
Includes a bunch of infrastructure in the activity manager needed to
support all this.
Change-Id: I4dba7a98a7b8bbb9e347666451aa9cb1efad1848
There was a race in the system process between applying the initial
configuration and executing code in higher-level system services
like the app widget service that relies on the config. For some
reason it starting showing up more after my code changes; it should
now be completely fixed.
Also fix the activity starting window to run in compatibility mode
if its application is going to be in compatibility mode.
And some various cleanup and small fixes.
Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
No longer accidentally puts an app into compatibility mode.
Also various cleanup, freezing screen while switching between modes.
Change-Id: Ic1b3958be7800189a93f68e9dee3c5adfc45fe57
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
We now only keep a thumbnail for the task, not for each
activity. However if you use FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET,
we will make a new secondary thumbnail for that series of
activities. There is a new API for the app to get these
secondary thumbnails.
Also set a default thumbnail size for non-xlarge screens
so we have thumbnails on phones. (We need some smarter
code in the platform for computing the actual thumbnail
dimensions of the current device). And add a test app
to show recent tasks + thumbnails.
Change-Id: Ic36759f6635522118a2cb7f156662229a610c492
The package manager now keeps track of whether an application is
stopped. There are new intent flags to control whether intent
filters in a stopped application will match the intent. This is
currently used in one place, sending broadcasts, so that stopped
apps can not be launched due to background processes.
The package manager during first init makes sure no applications
are in the stopped state. When new applications are installed,
that begin in the stopped state. When the activity manager is
launching a component of an application, it ensures the application
is taken out of the stopped state.
The "force stop" button in manage applications will now put an
application back in to the stopped state; it can't go back out
of the stopped state until one of its components is launched by
the activity manager.
There will probably be a few more places where we need to filter
stopped applications out of intent matches, but doing this for
broadcast is a very big first step.
This also introduces a new broadcast that is sent to an application
after it is replaced with a new .apk. But only if the app is not
in the stopped state. This makes it a lot easier for developers to
implement code to get their application back in proper running shape
after an upgrade.
Finally another new broadcast is added that is sent to a package's
installer at the first time it is launched. This allows the installer
to tell the package about it being installed only when it is first
actually used.
Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
We were doubly-decreasing the task's activity count, so when selected
from recent tasks it would re-launch the last Intent rather than
switching to its current state.
Change-Id: I6e58c930a0755ae0142604d42b5cd2c668a2b492
The activity manager was not performing the layout pass on the new window,
because its app token was still hidden, because the activity manager / window
manager were still waiting for it to be ready to show.
Just ignore whether the app token is hidden for this case.
Also fixes some problems with animations, and tweaks the ViewConfiguration
values for xlarge screens.
Change-Id: Icbe9c77ba8127d1e02df2d6f27b8e86ec842e50a
This is a band-aid over the existing kludgy stopping mechanism
where the semantics of stop are different in the activity manager
than in the clients.
This change is intended to be as unobtrusive as possible, only
impacting the sleep case. I have a different change that
completely reworks how we stop activities to simply this all
a lot by unifying the semantics between the server and client.
However, it is too late in HC for such an extensive change. Later
I'll revert this one and put in the better solution.
Change-Id: Id77f2db1ec83469cdd888acb8fbc4679daa7766e
We no longer enforce permissions for applications that are accessing
their own components. This allows an application to require a permission
on one of its components that it does not itself have. This is useful
for example with the new advanced widgets, which require a system-only
permission on the implementing service to ensure the app's data stays
private but it is nice to allow the application to still touch its own
widget service.
Change-Id: I5d61930a083816919545870039ad191314ed48c6
...when the device's physical orientation is portrait.
We now hold off on computing app token orientation while preparing
to open or close app tokens.
Also clean up a few other little issues.
Change-Id: Iae125a975c7706fb4d068c872fd172e69854ff15
Now recents is updated every time an activity is resumed. This
should ensure the recent list is more consistent, in the face of
pressing back or things crashing.
Change-Id: Ibf59419014e549fac55f18633185edcb5ffcaa3c
Also issue #3281400: Rotating a retained instance fragment leaks the fragment manager
And turn off fragment debug logging.
Change-Id: Ibdd7db82bb35618021bcba421ba92ced7cd691c2
Also know as:
Issue #3272051 Contacts edit view: Tapping the in-app back button
results in a forward transition
Yeah more complexity in deciding which animation to use.
Also reduce complexity in deciding which app's animation set to use,
to balance things out (and make it have less stupid behavior).
Change-Id: I78c6c5c5249a96206f7e03ce587c1dcb9a7dc14f
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
What this adds:
- A new Intent activity flag to completely replace an existing task.
- A new Intent activity flag to bring the current home task up behind
a new task being started/brought to the foreground.
- New versions of startActivity() that take an array of Intents to be
started, allowing applications to start a task in a specific state.
- A public moveTaskToFront() method on ActivityManager, with a new flag
that allows the caller to have the task moved to the front with the
current home task immediately behind it.
Change-Id: Ie8028d09acffb5349d98043c67676daba09f75c8
We now decide whether to use a bitmap background based on whether the
window's drawing is hardware accelerated. To do this, there is a new
"state_accelerated" that state list drawables can be parameterized on,
and the standard window background uses this to select a solid color
or bitmap drawable as appropriate.
Introduces a little hackery to have wm preview windows pretend like
they are hardware accelerated even if they aren't, so the preview looks
closer to the actual app.
Also Add a DialogWhenLarge variation for the light theme.
Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
- Activity manager now prints the pid doing a startActivity request.
- Package manager now remembers messages about problems it has parsing
packages.xml.
Change-Id: I11a75aa3953dbfa5dd41cfbdf69116c764ec228f
...that Market took over the screen after signing into a Google account
Don't warn the user about a new activity coming up on an activity that
is finishing.
Change-Id: I573073139d42a485473d0c8a7df450c1a23c35c3
The activity manager looks for cases where one app launches immediately
after another. If this happens, a brief toast is shown telling the user
when app is actually running and what was originally starting.
Change-Id: If94cf5bd393dd0bc0f09789dae044fde1386c481
It would grant the permission to the temporary ActivityRecord,
not the real one, so it never got cleaned up.
Also allow granting of permissions to services because... well,
it would be really really useful. And it introduces some
refactoring that we'll need to support cut/paste.
Change-Id: If521f509042e7baad7f5dc9bec84b6ba0d90ba09
Introdude a new ActivityStack class that holds all of the
state and management of a stack of activities. Paves the way
for having multiple activity stacks, though at this point
there should be no change in functionality and the activity
manager is still assuming there is only one stack.
Change-Id: Iea4859a24c9269061043755ec58a615028d4183b
