AccountManagerService
- Maintain multiple account lists, one per user
- Keep multiple databases of accounts
- Account db moved to /data/system/users/<userid>/
SyncManager
- SyncStorageEngine keeps track of multiple users' accounts.
- SyncQueue maintained as a single instance, queueing requests from
multiple users.
- Changed some methods to take userId arguments
- Removed some deadc0de
- Store the userId in the SyncOperation, so we know which provider
instance to bind to when queued operations are processed.
ContentService
- Pass along the userid to sync manager calls.
ActivityManagerService:
- Fixed a bug in cancelIntentSender
- Don't bring other user's task forward when resetting tasks.
Updated tests
Change-Id: If317340ef68e902787aa3f5ceb4cf96f14aea695
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
This reserves a range of uids (for each user) in which these processes
run. These uids are not associated with an application, so they
effectively run with no permissions. When a Service requests to
run in such a process through android:isolatedProcess="true", each
time it is brought up a new isolated process is started with its
own unique uid.
What we have so far gives us the basic infrastructure; more work
remains to further lock down what these uids have access to.
Change-Id: Ibfd27c75619cba61f528f46ede9113f98dc5f45b
We can do this now that we ensure processes are not killed until
they have been stopped. If the two activities are in the same
process, the ordering will still be correct because we schedule
the pause before the resume.
Change-Id: I209ba739b41e832d35db3edd34d1e7af354cc183
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
... a different app opens
In some cases when reparenting activities we could end up with a reply
chain that crosses task boundaries, so if an activity below that needs
to be reparented we pull that and the activities above it up into the
new task.
Change-Id: Ia4fa041ab7069e39dac162ddbf5b8e1de98675b9
Setting it when a new activity is being resumed is too soon, because
things like an activity launching an exiting (without being seen by
the user) can knock out the real previous app that we want.
So now we set it when an activity is stopped. At this point it is
going to move from the preceptible to background oom adj, so it is
a good point to determine whether it should be a previous app to
instead put it to that oom adj. This also avoids things like
activities that start and immediately finish from impacting the
previous app.
Further, we keep track of the time each activity was last shown, and
use this to further filter what is set as the previous app.
Change-Id: I72d1cac4de0cc2d4598170296028f11b06918d4f
...the "Complete action using" dialog
I have never been able to reproduce this consistently, but here is
another stab in the twilight. It looks like during boot we have
a potential race where we could reset the config sequence number after
we had gone through a config change, causing ActivityThread to ignore
a following config change. Maybe this change will help.
Change-Id: I4b731df5fd5c63894ca2e9bd34693b31ab1c0565
This came up from bug #5601885: Memory increase (leak?) in system_server
Stingray MR1
This isn't *really* a leak in the system process -- it is a leak in an
application process that is causing the system process to keep around
a bunch of ActivityRecord objects longer than it should, until that app
process is ultimately killed.
Unfortunately these days leaking an ActivityRecord also often means
leaking a thumbnail, which is a big slab of memory.
So make the activity manager better about this, using a weak reference
from the handle the object has so we can still clean away most of the
state associated with the ActivityRecord even if the client side leaks
its own reference.
Change-Id: Idbab45e09749cdfb54899203da7981e7b3576e25
- ActivityManager now keeps track of previous app as you
move across the home app.
- Better debug info about why an activity is being destroyed.
- New performance tests.
Change-Id: I3a5ae7cb1b9f1624c6792a4f6184353f532b8f3b
This is the process that you had previously been interacting with
in the UI before the current one. Treating it specially should
allow us to improve the scenario of switching back and forth
between two apps.
Also add API constent for ICS MR1.
Change-Id: Ib3fe4df36b270be11dfd6b7e8d107c9994058a4d
The basic problem was that at some points during setup wizard, this would
happen:
1. The app's process is killed.
2. The app's process is restarted, but not to actually resume the
setup wizard activity, just to put it in the stopped state.
When doing this, the saved state is cleared but the app will
never provide a new one.
3. The app's process is killed again. At this point, because the
saved state is cleared, the activity is completely removed.
4. Eventually the entire activity stack becomes empty, and a new
setup wizard activity needs to be created as the home app.
There is a combination of bad stuff going on here.
First, why is the process being killed? At this point the setup
wizard is the home app, so it shouldn't be killed. There were two
reasons why this was happening:
- CryptKeeper still was not completely cleanly going away. To fix
this, I removed the check in the activity manager to not allow
an activity to finish if it is the only activity on the stack and
maybe-kindof looks like the home app. This really wasn't necessary
(we always take care of starting a new home activity if we find the
stack is empty), and outright dangerous with all of these things
purporting to be home but not.
- There was an issue in computing the oom_adj where the home app
would not be marked as "not hidden", and if we had to re-compute
its oom adj in the current sequence would then give it an
adjustment as a background process... and with all the processes
we spin through during boot, it quickly got down to background
#16 and killed.
Second, what is going on with the state? This is easier, the code
in the activity manager to create a new activity but put it in the
stopped state was still clearing the saved state. The saved state
should only be cleared when going in to the resumed state. When
going in to the stopped state, we can just keep holding the same
saved state.
Change-Id: I7d21cdcfa082d98ca70c79d9923e29605ee4353e
...the "Complete action using" dialog
When an application goes idle, it sends back to the activity manager
the configuration it last used, to make sure the two don't get out
of sync. Fix a bunch of edge cases here in dealing with that, and
be sure to also send the current configuration when launching an
activity so the client is always up-to-date when launching.
Also a small fix to not show the upgrading dialog during first boot.
Change-Id: I14ed366a87cd689d1c78787369e052422290ac6f
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
If the app had activities still finishing, when we checked whether it was
now stopped we would get told no. Also some other improvements:
- Schedule an idle as part of the force stop, to get any finishing
activities out of the stack soon rather than waiting for some activity
to idle.
- Don't filter out stopped system apps. This is dangerous because
system apps may have no way for the user to explicitly launch them,
so they could get put into a stopped state for which there is no way
to get them out. Also if the user really wants a system app to not
run, the new disabling mechanism is more appropriate.
Change-Id: I34003f21dac29e2ca0f66a23b88c710de41bab99
The resolver activity was hiding the following activity from recents.
Also some other fixes: a little better memory use debugging, removed
some unneeded code from window manager, moved some system activities
into their own process, added some more running process information for
manage apps.
Change-Id: I66687d16989ff965d524b92dc360f37c19199717
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
- 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
