...for a smoother OOB experience
Way provided.
Put your defaults in system/etc/preferred-apps/*.xml.
Figure out what to put there with "adb shell dumpsys package preferred-xml".
Bug: 6680894
Change-Id: Ia06bb0061876274a5f80bf06d1ba5ad155edc323
...mismatched uid: X on disk, Y in settings" errors on Froyo and Gingerbread
Deal more gracefully with the uid changing in three ways:
1. If the uid on disk has become root, then have installd change it to
the application's uid. This is to correct a potential case where
installd was interrupted while linking or unlinking the libs dir,
during which it temporarily changes the owner of the dir to root
so that a malicious app can not get in its way. So if the uid on
disk has become root, we assume we can safely just change it back
to the correct uid.
2. When scaning packages at boot, use the same "delete and rebuild data
directory" code for third party applications as we have for system
applications. This allows us to at least end up in a state where the
app will run, even if its data is lost.
3. But we really don't want to get in to case 2, so if an application
update is being installed and we find that the uid we now have for
the app is different than the one on disk, fail the update. This will
protect against for example a developer changing the sharedUserId of
their app and getting into this bad state.
Bug: 6295373
Change-Id: Ic802fdd818ac62449ff3c61d1fff1aa4d4942f39
Forward-locked apps are mostly in ASEC containers now, so the
containers need to be measured as well.
Bug: 6606390
Change-Id: I69e9fe47aabe1e130568779a45fe8000b3ce9d4c
When media packages were loaded, they would lose their forward-locked
status since the flags covering it was not available when the
doPostInstall step was called.
Bug: 6611980
Change-Id: I807fcec6b61cedf7654808b704fba7de9c7c1922
The old style forward-locked apps were in a directory called
/data/app-private but the new style forward-locked apps are in ASEC
containers. This made the upgrade path confused and it wouldn't
correctly generate the InstallArgs to delete the old file.
Bug: 6619438
Change-Id: If4323fa8701d9fc653998f5db58670b4124b9e87
When app verfication is enabled and the verifier times out, allow
PackageManagerService to continue with the installation.
Bug: 6531120
Change-Id: Ic6aef755af92588e8887c918b70fb195c683b24c
Pending install list is cleared if there is an error connecting to DCS,
so don't try to remove each pending install in the loop.
Change-Id: I736114878ad92136c3b8a3ca27a1f058adaba395
Move MountService up the list, then pause waiting for MountService to
finish scanning ASECs before the services that require those packages to
be ready.
Additionally, don't automatically mark all ASEC apps as FLAG_EXTERNAL on
reboot. This prevents AppWidgets and other things from being used with
ASECs which are on internal storage.
Bug: 6445613
Change-Id: I3e0b3e244fec966814d7a5ea93de5d337aea79bd
Change the thread priority for all disk measurement and statfs calls to
background priority.
Also move the measurement fully into the measurement task since it makes
more sense.
Bug: 6332097
Change-Id: Iafc2151313ad9b14117daf67e933dccd32f68d54
Need to use PackageManager.INSTALL_{EXTERNAL,FORWARD_LOCKED} for
createInstallArgs instead of ApplicationInfo.FLAG_etc for the install
args to be created correctly. If certain flags conflict, there will be a
failure to delete the package.
Change-Id: Ibd8705943371596b2f2d6c24bd071b737ca74ef4
If there were apps already installed that were added in a later system
OTA, bad things would happen.
If the previously installed application is an older version, simply
delete the installed application. If the system app is older than the
previously installed one, mark it as a disabled system app and use the
previoulsy installed application.
Additionally, the application will now have the correct granted
permissions.
Bug: 6251602
Change-Id: Iea444b6acac460fca1e08d4e2cbf68a258214ca6
System applications which had an update applied to them at some point
were in a semi-broken state when removed via an OTA. The
"updated-package" setting would stay around forever and permissions
wouldn't be revoked.
Change-Id: I908e813b5de59c0f777d9b051253b28255a1c694
On devices that had external storage, permissions weren't set correctly
on non-forward-locked applications. Also, moving forward locked
applications didn't work since DefaultContainerService wasn't able to
read it.
Fixed some faulty unit tests as well.
Bug: 6427212
Change-Id: I5c1f0bf5278549069c78939f0708c4c43a7d4006
We couldn't put forward-locked apps in ASEC containers before since we
didn't have any permissioned filesystems. This adds the ability for
forward-locked applications to be in ASEC containers.
This means that forward locked applications will be able to be on the SD
card now.
This change also removes the old type of forward-locking that placed
parts of apps in /data/app-private. Now all forward-locked applications
will be in ASEC containers.
Change-Id: I17ae0b0d65a4a965ef33c0ac2c47e990e55707ad
The forward lock utilities will need to be called from
DefaultContainerService for ASEC packages in the future. Move them to
PackageHelper to aid in the transition.
Also move the public resource copying to the FileInstallArgs step which
makes a little bit more sense.
Change-Id: I3a62ac817719db3ee1c89c106a551dcbe9c44744
The packagemanager uses a ParceledListSlice to send back its lists
of installed packages and apps. The list slice has a method append
which, in addition to adding the item to the list, also returns true
if the list has passed a size limit (about 1/4 of the total possible
IPC parcel size) to let the caller know that he should send the
slice. However, when used by the pm, it has an extra ! that makes it
send whenever it ISN'T over this limit instead (and conversely, not
send if it is under). This causes a lot more calls than needed since
it sends tiny one item slices instead of larger ones. This patch
removes the extra ! making it behave correctly.
Change-Id: I8db46d380a25406b55f3214aee1505e81949acc5
Forward-locked apps aren't very prevalent, but it needed to be
restructured to make sure both streams and ZipFile objects are closed.
Change-Id: I41f863224fecd24069e525e9ce3738de8237bd5e
It's difficult to see in bugreports when this situation arises. Add a
small log so we can easily determine installation failure reason.
Change-Id: Ie59c205cf731cad7b3d04ceb995e58a093c62455
Enable default enforcement of READ_EXTERNAL_STORAGE on non-user
builds. Users can still explicitly enable enforcement in Settings.
Bug: 6131916
Change-Id: I7dc66b624ad252ed2a2ad3647f3ea85dda7f8e82
Broadcast intents that get sent out when users are added/removed/switched.
More work on generating user-specific information in package manager queries.
APIs to update user name and query a user by id.
Removed Package.mSetStopped and mSetEnabled, since they're not user specific.
User removal:
- Cleanup ActivityManager, PackageManager, WallpaperManager, AppWidgetService
and AccountManager.
- Shutdown processes belonging to the user.
Don't show vibrate option in long-press power if there's no vibrator.
Lock the screen when switching users, to force unlocking.
Change-Id: Ib23a721cb75285eef5fd6ba8c7272462764038fa
When READ_EXTERNAL_STORAGE isn't enforced, grant its GID to all
launched processes. When changing enforcement, kill all processes
below foreground adjustment, causing them to be relaunched with
update GIDs.
Bug: 6131916
Change-Id: I6d83efc937919f13a1a7d9caac902e572869406a
Packages can be enabled/disabled per user.
This requires maintaining stopped/launched states and
enabled / disabled components and packages per user.
Refactored pm.Settings and PackageSettingsBase to keep
track of states per user.
Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml
Changed intent resolution to handle individual user restrictions.
Bunch of IPackageManager calls now have a userId argument.
Make AppWidgetService handle removals of packages.
Added some tests for pm.Settings and PackageManager.
Change-Id: Ia83b529e1df88dbcb3bd55ebfc952a6e9b20e861
Store enforcement state of specific permissions, allowing them to be
selectively enforced. Currently supports READ_EXTERNAL_STORAGE, which
by default isn't enforced, but enforcement can be enabled at runtime.
Bug: 6131916
Change-Id: I4bcc215a2eb5e6507d6257b577311cbd13c77acf
The code for this was fairly conservative since the components of the
apps could change, leaving junk in the preferred app list. Now we
don't pro-actively clear them, but try to catch missing components
later.
Change-Id: I793063449dcc577fd3d56bb56495b308f0c95ea8
