* No longer support a package name stanza outside of
a signature tag. Package names, by themselves, have
no security associated with them in Android and thus we
should not be allowing or encouraging this
type of policy.
* Allow for nested package name stanzas inside
signature stanzas. There are cases where a finer
distinction needs to be made among apps signed with
the same cert. New code allows a different seinfo
tag to be assigned to the listed package names
signed by the parent cert. When a determination needs
to be made concerning seinfo assignments, the inner
seinfo tag takes precedence over the outer seinfo
labels which are assigned to just the signature.
* Temp structures are now used to parse new policy files
until the entire xml file is parsed and deemed correct,
at which time the temp structures are copied over to the
permanent class structures. This ensures that any structural
errors with the policy will not result in partial loads.
* Valid stanzas look like the following with the inner
package piece being optional.
<signer signature="">
<seinfo value=""/>
<package name="">
<seinfo value=""/>
</package>
<signer>
<default>
<seinfo value=""/>
</default>
Change-Id: Ia204d71211776dcf9b2dcc86ad6d77c4ad39dc25
...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
For the new documents work, we're only interested in the subset of
ContentProviders that actually implement DocumentsContract. Instead
of returning all providers, add <intent-filter> support to make it
easier to limit the set of returned ProviderInfo.
Define a well-known action for DocumentsProviders, and start using it
when querying for roots. Continue supporting the old <meta-data>
approach until all apps have been updated.
Bug: 8599233
Change-Id: I05f049bba21311f5421738002f99ee214447c909
When reparsing because the data-volume update has been removed, be sure
to apply privilege when the bundled fallback APK should be allowed it.
Bug 10958159
Change-Id: Ibad52a5644606b27f4ebc5d5d7c1a671283b0752
When an apk is installed on ordinary unmountable media, a broadcast
is sent when the OS wants to unmount it so that interested parties
can cleanly close any files they have open to read that apk's
resources or similar. We now send that broadcast when we are
about to unmount the ASEC fs container that holds a forward-locked
apk as well, so that e.g. Home knows to release the resources that
it was using for widget hosting or similar.
Bug 7703848
Change-Id: I71aefdb4086c7b73a128f89c15d192a2b92d09a8
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
This fixes a bug in parsing the package name from a file name. The suffix
was not taken into account, resulting in all restrictions files being
removed on switching to a user.
Bug: 10947554
Change-Id: I62725bbbdc0e15609872de3896130d4acbc35386
The problem was that the ResolverActivity filters some activities
out of the list it shows, but it uses that display list as the
list of components the preference is set against when ultimately
setting it on the package manager... but that filtered list is *not*
the right component set, since it is not the same as the package
manager's view on it.
The fix here is to retain the original set of matching components
and use that when setting the preferred activity. Note that this
does mean that in very unusual cases where filtering is happeing
(such as one of the activities not being exported but being seen
as a possible completion from another app), then you will be setting
the preference for the complete set. Ultimately we probably need
to have the package manager apply these filtering rules up-front so
this is all consistent, but this is a very rare case so not that
important.
And then most of the change here is just improving the debug
output for intent resolution.
Change-Id: Ie35ac2c05a45946439951bbf41433c8b7de79c05
...activity chooser from being shown
Add more useful output when intent filter debugging is enabled.
Change-Id: I3722b03ed625046398e81233cf7fb6aa5ded5eca
* Make sure that pm.getHomeActivities() returns the activity metadata
as well, so that the caller can trace the reference
* Add a public canonical name for that metadata key
Bug 10749961
Change-Id: Ic4d0750d61001ffe5af180398f042afa30eea1ce
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
Changed PackageManager to read a config value that indicates if
the default ResolverActivity should be replaced by a custom version.
This config value can be replaced via an overlay.
Bug: 10081151
Change-Id: I6f1c59d053b89fabf52bcda620eb5d4026406701
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
Provide developer APIs to discover application-specific paths on
secondary external storage devices. Covers files, cache, and OBB
directories. Apps will not have write access outside their package-
specific directories on secondary devices, so only primary storage is
exposed through Environment.
Creation of .nomedia files will be handled by FUSE daemon in future
change.
Change-Id: Ifcce6201a686d80269d7285adb597c008cf8fa7c
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
Since the Restrictions feature was removed, some cleanup code was
added to unblock apps. But the cleanup is causing some runtime exceptions
due to happening too early in the boot up sequence. Moved the cleanup
to after boot_completed broadcast is received.
Bug: 10212758
Change-Id: Id42eff16b54c24ea48cf8b3a81f77ea801264edd
A little grossness for now to support dual booting Dalvik and Art.
While I was here, removed isDexOptNeeded calls for boot class path which already return false.
Change-Id: Iaaaf21b7733c1791e7bd8ae27e84c47463f9e9c9
Note that it is *intentional* that even a privileged app cannot
add new privileged permissions via unbundled update. The set of
privileged permissions granted is strictly limited to those used
by the apk file installed as privileged.
Bug 10027033
Change-Id: I974bae0671c1962e4526d51dd9a0c53bcd27323e
