- Fix dumping of package manager intent filters so the option
to print the filter detail works again.
- Extend dump resolvers to allow you to specify the specific
types of resolvers you'd like to dump.
- Add new package manager commands for querying activities,
services, receivers.
- Move the code for parsing a command line into an intent to
the framework, so it can be used by the new package manager
commands and later elsewhere.
Change-Id: I56ea2bb8c3dd0e5198ee333be8f41ad9dcdb626f
This is to make the behvior the same as before
47f71a697a for cases when some of the
locales' languages are empty.
Change-Id: Ifee92e199f20130e060670f244eb3b4b7be13872
Move the implementation of the install variants and uninstall to the cmd
command. Additionally, make two other important changes: 1) replace calls
to the legacy PackageManager#installPackageAsUser with the PackageInstaller
2) allow streaming package bits for 'pm install'
Change-Id: I5680f57208d377daadb69b2cc09c233c02fe5016
While one party calls oneTouchPlay() to initiate the action and
put it in progress, the other parties making the same call gets
an error 'operation in progress'. This is not really an error,
but there was no other choice for them but just to wait till
the action is completed and the service is ready to accept
the API call again.
This CL resolves the inconvenice by allowing multiple callbacks
rather than returning IN_PROGRESS for those joining later. Same
was applied to queryDisplayStatus().
Change-Id: I5fc9aba4aa73e76a25f8fdec37e11cd961a3d35f
(cherry picked from commit 98a25f1ee27c1b4362a23981edc17fc92199a876)
we print using it the first time.
This warning used to be shown when the print settings app was used
to enable a service.
If two warning as shown for the same print service we automcatially
dismiss all dialogs once one dialog is confirmed. Please note that
we are not confirming the printjob as it is unexpeced to have a
single click to confirm multiple print jobs.
Change-Id: I8bb0a49bac2063c1c55e2f24bd34df2c44e2df89
Bug: 24135353
Apps can mark manifest components as being encryption-aware, which
means they can safely be run before the credential encrypted storage
is available.
Start adding filtering logic so that we only return these components
when a user is running "with amnesia." That is to say, only device
encrypted storage is available, so the user is running but with only
partial knowledge of its data.
To avoid calling into ActivityManager with the PackageManager lock
held, we quickly determine user state and splice the state into the
flags for later per-component evaluation.
Bug: 22358539
Change-Id: Idc56ec29f1ef04da8963e004314d7f5e47400997
Nested domain-config inherit unset parameters from the domain-config
they are nested in. This helps avoid copy and pasted configs that are
almost the same except a few minor differences for a domain with
slightly different requirements.
For example: Consider a domain-config for example.com that, among other
settings, does not enforce hsts. Now if you want the rules for
example.com to apply to secure.example.com except that hsts _is_
enforced you can make a nested domain-config for secure.example.com
under example.com that sets hstsEnforced="true" and nothing else.
Change-Id: I9e33f7e62127fd7f4f15c3560fff2f2626477bd4
Previously, only the first locale was dumped to the output in
android.content.res.Configuration#resourceQualifierString(). Now the full
locale list is part of the output.
Change-Id: I5d4b73738a14d48533ee96c38dbc6c4b204ea998
The setLocale() method in android.content.res.AssetManager was not
used. Removing it to reduce maintenance cost.
Change-Id: I1b168fe84c2465d1ebc2b62bb965eda885e1220a
XmlConfigSource parses an ApplicationConfig from an xml resource.
Currently this supports app-wide default configuration via the
base-config element, per domain via the domain-config element and
inheritance of unset properties at parse time.
Inheritance of unset properties is currently only:
domain-config -> base-config -> platform default configuration
Where the most specific value is used.
For example: If the base-config specifies trust anchors, all connections
will use those anchors except for connections to a domain which has a
domain-config that specifies trust anchors, in which case the
domain-config's trust anchors will be used. If the domain-config or
base-config don't set trust anchors, or don't exist, then the platform
default trust anchors will be used.
Nested domain-config entries, debug-overrides, and thorough
documentation of the xml format will follow in later commits.
Change-Id: I1232ff1e8079a81b340bc12e142f0889f6947aa0
Define two explicit directories where device-encrypted and
credential-encrypted data will be stored. Third-party apps only
need access to the device-encrypted directory, so that's the only
API exposed for now.
General cleanup in how ApplicationInfo details are derived.
Bug: 22358539
Change-Id: If0a0108721a4aa1c3052b4912e08604bbf24e1ae
