Provide an abstract class for system services to extend from,
similar to the android.app.Service.
This will allow services to receive events in a uniform way,
and will allow services to be created and started in the
correct order regardless of whether or not a particular
service exists.
Similar to android.app.Service, services are meant to implement
Binder interfaces as inner classes. This prevents services from
having incestuous access to each other and makes them use the
public API.
Change-Id: Iaacfee8d5f080a28d7cc606761f4624673ed390f
(Cherry pick from master)
As a next step they can be moved into separate directories to be
built as separate modules that may or may not be included in a
particular configuration.
Moves AppWidgetService, BackupManagerService, ClipboardService, DevicePolicyMS,
and WallpaperMS.
Change-Id: Idd92871c1828bdde81d85fe99a9c87a22d53169d
* 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
User removal or eviction inherently races with broadcast delivery. This
patch introduces a latest-possible recheck of the availbility of the
target application before attempting to send it a broadcast.
Once the process has actually been spun up the system is essentially
committed to presenting it as a running application, and there is no
later check of the availability of the app: the failure mode for
continuing to attempt delivery is a crash *in the app process*,
and is user-visible.
We now check the app+userid existence of the intended recipient
just prior to committing to launch its process for receipt, and
if it is no longer available we simply skip that receiver and
continue normally.
Bug 11652784
Bug 11272019
Bug 8263020
Change-Id: Ib19ba2af493250890db7371c1a9f853772db1af0
Also use the existing full PreferredActivity match machinery instead
of the existing direct comparison now that the intent filters can
be more flexible.
Bug 11482259
Change-Id: Icb649ca60ecfbdb9ee3c256ee512d3f3f989e05f
In particular, if a 3rd party app tries to define a permission that
turns out to be defined by system packages following an upgrade,
the system package gets ownership and grants are re-evaluated
on that basis.
Bug 11242510
Change-Id: Id3a2b53d52750c629414cd8226e33e5e03dd0c54
We also now ignore attempts to set preferred resolutions with
intent filters for which no actions are defined.
Bug 11392870
Change-Id: If0d0b37bf01b59463985441edfc2bddd070bfc2a
We need to be able to perform very lengthy operations on some threads
(e.g. the I/O thread responsible for installing multi-gigabyte APKs) but
still have long-run deadlock/hang detection applied to those threads.
Previously the watchdog mechanism applied the same policy to all
monitored threads: unresponsive after 60 seconds => restart the system.
Now, each monitored entity can have its own independent timeout after
which the watchdog declares deadlock and restarts the runtime. The
halfway-finished intermediate thread stacks are dumped based on the
specific entity's declared timeout, not the global 30 second checking
interval.
With that new mechanism in place, the Package Manager's lengthy-I/O
thread watchdog timeout is raised to 10 minutes.
Bug 11278188
Change-Id: I512599260009c31416b2385f778681e5b9597f05
Because properly continuing permission grants post-OTA has changed
policy to include privilege considerations based on install location,
make sure that we re-evaluate when we determine that the apk has
moved from its pre-OTA location.
Bug 11271490
Change-Id: I6c09986e2851a67504268b289932588457c05dfc
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
...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
