Age | Commit message (Collapse) | Author |
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
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
|
|
dynamically" into klp-dev
* commit '64397749effa088dcea3799fc8440845c5a1c193':
Handle backup transport registration dynamically
|
|
|
|
Bug 11369873
Change-Id: I9bbdcc21ce25159c6645690123b5d03c553b0ddc
|
|
attempting broadcast delivery" into klp-dev
* commit '6e5cf573f2f2e17825af2973daeba893c6aa5855':
Ensure recipient can be launched before attempting broadcast delivery
|
|
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
|
|
one scheme in the filter" into klp-dev
* commit 'e995ad1559ac12a0ac5e2e56ce378b0b29f10f24':
Support preferred activities with zero or one scheme in the filter
|
|
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
|
|
precedence over 3rd party apps\'" into klp-dev
* commit 'aa719e92ffc2193db68c86b97fce291c27d5d4dd':
System package permission decls take precedence over 3rd party apps'
|
|
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
|
|
settings are malformed" into klp-dev
* commit '9dcfcc845d5fdbedbbb41e0d22dd3e16a6a53fe5':
Don't crash when preferred activity settings are malformed
|
|
We also now ignore attempts to set preferred resolutions with
intent filters for which no actions are defined.
Bug 11392870
Change-Id: If0d0b37bf01b59463985441edfc2bddd070bfc2a
|
|
different entities" into klp-dev
* commit '525322ecbab1502586d378e7065edc402abc63bf':
Support different watchdog timeouts for different entities
|
|
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
|
|
became privileged in OTA" into klp-dev
* commit 'd34e1155226e8885d51c05209c7c87503528a2db':
Edge case: overriden system package moved & became privileged in OTA
|
|
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
|
|
klp-dev
* commit '595c48e43d8f40baaa8e281959300e582d765f56':
Fix priv-app edge case across OTAs
|
|
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
|
|
into klp-dev
* commit '5e02e0a9e1e075e3d451d929b0a67bf280c432ed':
Add <intent-filter> support to <provider>.
|
|
|
|
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
|
|
downgrading bundled apps" into klp-dev
* commit 'a5c436743c2d0343550d13f16ae557d4ea6101e1':
Make sure to maintain privilege when downgrading bundled apps
|
|
unmounted during upgrades" into klp-dev
* commit 'e67ebcbc0c5f03434aa756449f0cea6ecb1fde5b':
Notify that ASEC containers are being unmounted during upgrades
|
|
klp-dev
|
|
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
|
|
new user broken
* commit '239dc099a0d56eba3c7a537df23ef3c5046b2667':
Fix issue #11005453: [SUW] G+ profile creation for new user broken
|
|
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
|
|
into klp-dev
* commit '5f86b90b8a224e21db89bacf78d4bd4d3f44342d':
Fix issue #10848916: "Always" button is not working.
|
|
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
|
|
prevent..." into klp-dev
* commit '4bf0fcef9296b53114e86490d79956986f8b93a6':
Work on issue #10759595: preferred tag doesn't prevent...
|
|
...activity chooser from being shown
Add more useful output when intent filter debugging is enabled.
Change-Id: I3722b03ed625046398e81233cf7fb6aa5ded5eca
|
|
directories."
* commit '662b3bbe08c03de77c0676b4fdc1587723863f1b':
Proper security labeling of multi-user data directories.
|
|
|
|
* 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
|
|
Bug 10184643
Change-Id: I72c5177c621c24fac34bf8744eb6c5108b6d3464
|
|
To support improved home-app selection UX in Settings.
Bug 9958444
Change-Id: I106090784618bf7bea6fce28f4f9b9fb8480d310
|
|
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
|
|
Bug: 10024554
Change-Id: I742e918840a98dd83d713bdf7a43a919674e65fe
|
|
Change-Id: I7808cafc1f74c47fcd9d9a4b6a90fb50951457b1
|
|
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
|
|
Since this is an operation that could take a few seconds to run and needs to be
completed even if Settings dies, best to do it in the user manager.
Refactored PIN challenge/setup UI with a field to verify existing pin
when changing to a new one.
Change-Id: I0b7df5b2ccb7f343aa9282a9245d3bc2b577a794
|
|
The new apk will now correctly allow system permissions to an app
placed in the privileged install dir via 'adb push' on the fly.
Change-Id: Ie4284d12628e08d9562d18eee6a7e8f74ae6295e
|