...bad cleanup of crashing processes
We now have a special path for crashing processes, to silently
clean up their state.
Also some tweaks to Log/Slog.wtf to get better stack crawl
summaries in APR.
Change-Id: Ieced26989907a6e7615b6fa033813fced78d7474
This patch covers 2 cases. When an app is installed
and the resulting data directory is created for all
existing users. And when a new user is created and
all existing app data directories are created for
the new user.
Change-Id: Iaba7c40645bc7b6cc823d613da0c3782acf6ddd5
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
When a bundled app is upgraded, only reprocess ungranted 'system'
permissions if the bundled apk is privileged.
Also adds the 'privileged' flag to the dumpsys flag summary.
Bug 10503183
Change-Id: Ic6560fc904e5970fc871a155c898744a6607f851
This provides group membership to the FUSE daemon, since system
packages like NFC and Bluetooth hold sdcard_rw.
Bug: 10610659
Change-Id: I7428e999cfa4087ffe220b9d8bd80827191ab997
Keep track of last chosen activity for a particular intent, similar
to how it is tracked for "Always" choices.
Pre-select the last chosen activity if previously the user picked
"Just once".
Downgrade "Always" to "Last chosen" if there's a new kid on the block,
instead of removing it entirely.
Add methods to set and get last chosen entry.
UI - switch from Grid to List.
Bug: 9958096
Change-Id: Ied57147739a3ade1d36c3a7ec1e8ce77e5c5bb16
Write supplementary GIDs to packages.list for lower-level system
components to parse.
WRITE_EXTERNAL_STORAGE also implies sdcard_r GID. Switch to always
enforce READ_EXTERNAL_STORAGE permission. Update permission docs to
mention new behavior.
Change-Id: I316ba4b21beebb387ac05c80980ae9b38235b37d
The FUSE daemon is using packages.list to map from package name to
appId after it drops permissions, so create a new "package_info" GID
to grant read access.
Also switches FileUtils to use Libcore.os.
Change-Id: I9451ca4e90e8a985526805c6df0888a244a1db36
This is an extension from the existing data/etc/perferred-apps
facility. Now applications pre-installed on the system image
can declare which intents they would like to be considered the
preferred app for. When the system firsts initializes, or the
application settings are reset, these are used to configured
the current preferred app settings appropriately.
You use this with a new <preferred> tag under your activity,
which indicates which intents you would like to be the preferred
handler for. The syntax for this is written much like an
intent filter, however semantically it is not really an intent
filter and so has some important differences:
- You can not use globbing patterns (for SSPs or paths).
- You can use only one action (if you use more than one it
will only use the first one, so be careful).
Semantically what this is actually used for is a template
from which to generate a set of Intent objects, which are used
to probe the current environment in order to see if there are
multiple activities that can handle the Intent and, if so,
generate a new preferred setting for that pointing to your app.
As an example, here is how the preferred tag might be written
for the Maps application:
<preferred>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="http" />
<data android:scheme="https" />
<data android:host="maps.google.com" />
<data android:path="/" />
<data android:pathPrefix="/maps" />
</preferred>
<preferred>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="geo" />
</preferred>
From this, we generate the following set of potential Intents
to be matched, all with ACTION_VIEW, CATEGORY_DEFAULT+CATEGORY_BROWSABLE:
Change-Id: I7fd42aec8b6109c7dd20012529662362f1b7437a
http://maps.google.com/http://maps.google.com/mapshttps://maps.google.com/https://maps.google.com/maps
geo:
Introduces a new "blocked" state for each package. This is used to temporarily
disable an app via Settings->Restrictions.
PIN creation and challenge activities for use by Settings and other apps. PIN
is stored by the User Manager and it manages the interval for retry attempts
across reboots.
Change-Id: I4915329d1f72399bbcaf93a9ca9c0d2e69d098dd
Adds a platform API, and pm command. Fixes some issues with
dumping per-package data in package manager, makes battery
stats able to dump per-package state.
Change-Id: I76ee6d059f0ba17f7a7061886792b1b716d46d2d
Now that we are smarter about the initialization, we need
to do this after all packages are scanned.
Change-Id: I598f5ef84dcc83779bbff29e4c92136c63fb32de
Patch adds the seinfo label per package to the file.
This is of particular interest to the run-as program
which uses the seinfo tag to correctly label the
app security context before running the shell.
Change-Id: I9d7ea47c920b1bc09a19008345ed7fd0aa426e87
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
This patch covers 2 cases. When an app is installed
and the resulting data directory is created for all
existing users. And when a new user is created and
all existing app data directories are created for
the new user.
Change-Id: Iacaba6d9d18d5337e65713960d14efe32006b330
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
You can now declare shared libraries in apks that are
on the system image. This is like the existing mechanism
of using raw jar files as shared libraries, but since they
are contained in an apk the library can actually be updated
from the Play Store. And this even (mostly) works.
There are some deliberate limitations on this feature. A
new shared library *must* be declared by an apk on the system
image. Installing an update to a system image apk does not
allow you to add new shared libraries; they must be defined
by everything on the base system image. This allows us to
get rid of a lot of ugly edge cases (shared libraries that were
there disappearing after an update is uninstalled for example)
and give some brakes on apps that happen to be pre-installed
on devices from being able to throw in new shared libraries
after the fact.
In working on this, I ran into a recently introduced bug where
uninstalling updated to system apps would fail. This was done
to allow for the new restricted users that don't have all
system apps, but conflicts with the existing semantics for
uninstalling system apps. To fix this I added a new uninstall
flag that lets you switch on the new mode if desired.
Also to implement the desired logic for limitations on declaring
new shared libraries in app updates, I needed to slightly tweak
the initial boot to keep the Package object for hidden system
packages associated with their PackageSetting, so we can look at
it to determine which shared libraries are allowed. I think
this is probably more right than it was before -- we already
need to parse the package anyway, so we have it, and when you
install an update to a system app we are in this same state
until you reboot anyway.
And having this fixed also allowed me to fix another bug where
we wouldn't grant a new permission to an updated app if its
system image version is updated to request the permission but
its version is still older than whatever is currently installed
as an update. So that's good.
Also add new sample code showing the implementation of an apk
shared library and a client app using it.
Change-Id: I8ccca8f3c3bffd036c5968e22bd7f8a73e69be22
The goal here is to make sure that we aren't allocating a UID that
could have been in use since the last time the device booted.
Bug: 8256571
(cherry picked from commit af70d15543c89a53f064492f4e3d17c446e00039)
Change-Id: I8b11811df8d5a8ad1aa064abb43db020aceb29e3
The file that defines default preferred apps is now more
robust. It is no longer a raw dump of the package
manager settings, but instead a more general list of a
target activity and filter. When reading it, the remaining
information (match value, set of potential matches) is
determined dynamically.
Change-Id: I0edc6e0d2ed3dd2a6e2238992f18f7fc1f51d8d4
The disabled state allows you to make an app disabled
except for whatever parts of the system still want to
provide access to them and automatically enable them
if the user want to use it.
Currently the input method manager service is the only
part of the system that supports this, so you can put
an IME in this state and it will generally look disabled
but still be available in the IME list and once selected
switched to the enabled state.
Change-Id: I77f01c70610d82ce9070d4aabbadec8ae2cff2a3
Pass targetSdkVersion to installd so it knows the appropriate
permissions to apply to the app's home directory.
Bug: 7208882
Change-Id: Ia62ed36b32ee5af01077fb10a586024411be8ed4
This does some cleanup of the initial boot, especially when
booting in "no core apps" mode for encryption/decryption.
Change-Id: Ifb3949f580e52f54559e603c4b0b104f6bac2f6c
Bug: 7226656
In the case of packages with sharedUserId, the packages were inserted
into mPackages a little later. We were reading the package restrictions
before this happened and so the apps were being removed from the restricted
list, effectively setting installed=true.
Moved the block that reads the restrictions to after the processing of
mPendingPackages.
Also, don't setInstalled for all users in the pending packages processing.
Change-Id: I382787e45fecdb871d80ffb4d854782d8e32e4a7
A couple problems:
- We need to clear app preferences later, now that we have encrypted apps.
- The multi-user implementation of this would allow different preferred
apps from different users to potentially interefere with each other.
They are not completely separate data structures.
Change-Id: Id4f1ebb6414fdf30ff1049adaa1efe83dabac01a
Issue #7211769: Crash dialog from background user has non-working "report"
The report button now launches the issue reporter for the correct user.
Also for crashes on background users, either disable the report button,
or simply don't show the dialog depending on the build config.
Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything
Now they do.
Issue #7226656: second user seeing primary user's apps
I haven't had any success at reproducing this. I have tried to tighten up
the path where we create the user to ensure nothing could cause the
user's applications to be accessed before the user it fully created and thus
make them installed... but I can't convince myself that is the actual problem.
Also tightened up the user switch code to use forground broadcasts for all
of the updates about the switch (since this is really a foreground operation),
added a facility to have BOOT_COMPELTED broadcasts not get launched for
secondary users and use that on a few key system receivers, fixed some debug
output.
Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
When PackageManagerService deals with external storage, always bind
to DefaultContainerService as USER_OWNER. This avoids binding to a
stopped user, which would fail.
Bug: 7203111
Change-Id: I8e303c7558e8b5cbe4fea0acc9a472b598df0caa
Keep track of user creation and last logged-in time.
adb shell dumpsys users
User switcher shouldn't show users about to be removed.
No need to check for singleton for activities.
Bug: 7194894
Change-Id: Ic9a59ea5bd544920479e191d1a1e8a77f8b6ddcf
Commit 5e03e2ca7d moved from
PacakgeParser.Package to PackageSetting which revealed that we weren't
updating the pkgFlags when replacing an existing application.
Add flags to PackageSetting so that deletion of the package later succeeds.
Change-Id: I2e0d4e07da31f48b68601f3f3240966b6e17dbdf
When accessing a content provider, there is a check for whether
the provider can run in the caller's process; if so, even if the
provider is currently published, we return to the caller that it
can run locally.
This check was broken -- it had an old condition that allowed
content providers owned by the system UID to run in any other UID's
process. This is wrong, since by definition the other
UIDs would not be able to access the data under the original UID.
We ran into this because the activity picker is part of the
android platform manifest, so runs as the system process. However
it needs to run as the user who invoked it, so when coming from the
non-primary user we spin up a "system" process running as a uid of
that user. Now when that process tries to access the settings
provider, the broken check would think that a new instance of the
settings provider should be created in the caller's process.
Change-Id: I7bf495ed8370cb271bdaec073d5b7dda9e38c546
- New (hidden) isUserRunning() API.
- Maintain LRU list of visited users.
- New FLAG_IS_DATA_ONLY for ApplicationInfo.
- Clean up pending intent records when force-stopping a user (or package).
(Also fixes bug #6880627: PendingIntent.getService() returns stale
intent of force stopped app)
- Fix force-stopping when installing an app to do the force-stop across
all users for that app.
- When selecting which processes to kill during a force stop, do this
based on the actual packages loaded in the process, not just process
name matching.
- You can now use --user option in am when starting activities, services,
and instrumentation.
- The am --user option accepts "current" and "all" as arguments.
- The pm uninstall command now uninstalls for all users, so it matches
the semantics of the install command.
- PhoneWindowManager now explicitly says to start home in the current
user.
- Activity manager call to retrieve the MIME type from a content provider
now takes a user argument, so it will direct this to the proper user.
- The package manager uninstall paths are now implemented around
PackageSetting, not PackageParser.Package. This allows them to work
even if the application's apk has been removed (in which case it only
exists as a PackageSetting, not the PackageParser.Package parsed from
the apk).
Change-Id: I3522f6fcf32603090bd6e01cc90ce70b6c5aae40
Environment.getUserSystemDirectory(int userId)
Use it all relevant places that was hardcoding it.
Also, wipe out the user's system directory when user is removed, otherwise old state
might be transferred to a new user.
Change-Id: I788ce9c4cf9624229e65efa7047bc0c019ccef0a
UserManagerService is now closely tied to PackageManagerService,
sharing the same locks. There is no longer direct access of
Installer by UserManagerService, instead the package manager is
back to solely owning it.
Creating a new user now correctly only installs system apps for
that user.
Fixed some misc bugs, where we were getting nulls when
querying content providers and instrumentation in uninstalled
users, incorrect locking, etc.
Change-Id: Ife69b6e373d0cf7c5cfc03fc588e36b43ad5d8b0
This add a new per-user state for an app, indicating whether
it is installed for that user.
All system apps are always installed for all users (we still
use disable to "uninstall" them).
Now when you call into the package manager to install an app,
it will only install the app for that user unless you supply
a flag saying to install for all users. Only being installed
for the user is just the normal install state, but all other
users have marked in their state for that app that it is not
installed.
When you call the package manager APIs for information about
apps, uninstalled apps are treated as really being not visible
(somewhat more-so than disabled apps), unless you use the
GET_UNINSTALLED_PACKAGES flag.
If another user calls to install an app that is already installed,
just not for them, then the normal install process takes place
but in addition that user's installed state is toggled on.
The package manager will not send PACKAGE_ADDED, PACKAGE_REMOVED,
PACKAGE_REPLACED etc broadcasts to users who don't have a package
installed or not being involved in a change in the install state.
There are a few things that are not quite right with this -- for
example if you go through a full install (with a new apk) of an
app for one user who doesn't have it already installed, you will
still get the PACKAGED_REPLACED messages even though this is
technically the first install for your user. I'm not sure how
much of an issue this is.
When you call the existing API to uninstall an app, this toggles
the installed state of the app for that user to be off. Only if
that is the last user user that has the app uinstalled will it
actually be removed from the device. Again there is a new flag
you can pass in to force the app to be uninstalled for all users.
Also fixed issues with cleaning external storage of apps, which
was not dealing with multiple users. We now keep track of cleaning
each user for each package.
Change-Id: I00e66452b149defc08c5e0183fa673f532465ed5
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
Use raw arrays instead of ArrayList for data structures.
Temporarily includes a copy of the old intent resolver for
validating the new implementation.
Change-Id: I988925669b6686ac73b779be6cd6fe3a9fd86660
