...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
Being on SD card and being forward-locked are package-wide flags that
shouldn't depend on an APK having an <application> stanza.
Bug: 6563724
Change-Id: If5f2159cd8e3fa136f959b656d82b05ea6bdfae5
...content provider and updating its oom adj
This introduces the concept of an "unstable" reference on a content
provider. When holding such a reference (and no normal stable ref),
the content provider dying will not cause the client process to be
killed.
This is used in ContentResolver.query(), .openAssetFileDescriptor(),
and .openTypedAssetFileDescriptor() to first access the provider
with an unstable reference, and if at the point of calling into the
provider we find it is dead then acquiring a new stable reference
and doing the operation again. Thus if the provider process dies
at any point until we get the result back, our own process will not
be killed and we can safely retry the operation.
Arguably there is still the potential for a race -- if somehow the
provider is killed way late by the OOM killer after the query or
open has returned -- but this should now be *extremely* unlikely.
We also continue to have the issue with the other calls, but these
are much less critical, and the same model can't be used there (we
wouldn't want to execute two insert operations for example).
The implementation of this required some significant changes to the
underlying plumbing of content providers, now keeping track of the
two different reference counts, and managing them appropriately. To
facilitate this, the activity manager now has a formal connection
object for a client reference on a content provider, which hands to
the application when opening the provider.
These changes have allowed a lot of the code to be cleaned up and
subtle issues closed. For example, when a process is crashing, we
now have a much better idea of the state of content provider clients
(olding a stable ref, unstable ref, or waiting for it to launch), so
that we can correctly handle each of these.
The client side code is also a fair amount cleaner, though in the
future there is more than should be done. In particular, the two
ProviderClientRecord and ProviderRefCount classes should be combined
into one, part of which is exposed to the ContentResolver internal
API as a reference on a content provider with methods for updating
reference counts and such. Some day we'll do that.
Change-Id: I87b10d1b67573ab899e09ca428f1b556fd669c8c
...when resource is aliased
We were not correctly using the final resolved configuration when
retrieving a drawable through Resources.getDrawable(). (It already
does the correct behavior when going through TypedArray.getDrawable()).
Change-Id: I9032b788b592412178e31e2e6b0181b92c20fe45
...logic for notouch in Configuration
Added new TELEVISION feature.
We now force the configuration to "television" if the TELEVISION
feature is set, and "notouch" if the TOUCHSCREEN feature is not set.
Also cleaned up documentation, deprecated some configurations that
are not used.
Change-Id: If1c7a284b580a8a66bda2a75f0c7fa841b3dc9b7
- Add documentation on "television" UI mode.
- Tweak new documentation and implementation around propagating
URI grants through choosers.
- Add new activity launch flag for closing system dialogs.
Change-Id: I978c05f0dc3d16e1c55d43631828b9efa6335b19
When sending CHOOSER intent, inspect its target for any EXTRA_STREAM
needing migration. If any migration happens, copy the ClipData to
the CHOOSER intent and set GRANT_READ flag. Also update CHOOSER docs.
Bug: 6463773
Change-Id: I66a7adf7bf6f2f173866925cb7e048f4c7a63222
Use long instead of int so we don't run into a 2GB file limit.
Fix possible overflows in offset and length.
Change-Id: Idb3a34f5600f9c2372b9c89256f21757049fa43b
An AssetFileDescriptor with a null fd is pretty useless and should
never happen during normal operation. It can't even be parcelled
without hitting an NPE. To make it easier to find bugs where a null
fd might have been generated, check at construction time.
Bug: 5655036
Change-Id: I1da6dbee0cab9c11e309f3cebe698bf44dc5e27d
Added bitmaps for permission group icons. We had to pick either
icons for a dark or light background, and it had to be light for
settings, so the installer theme has gone back to dark.
Tweaked the permission groups to match the icons.
Redid the group priorities to make them correct (they were written
with higher priorities being less important).
Fixed bug where priority was not being used for system apps.
Change-Id: Ia3d3f0c1614a11b4cfd11682ce9e6c9f87d75c06
