A recent change tightened the check for whether or not an APK has code.
The check verified against the application and not the individual split.
Bug: 25769800
Change-Id: Ia53bd0e31ce3379bdd8bfe6d0c3da99b6d65fe31
This is required to expand metadata capabilities of DragEvent.
Apps receiving ACTION_DRAG_* events have access to
ClipDescription, but not ClipData.
Adding extras to ClipDescription allows for a richer behavior of apps
responding to these events.
Bug: 25788641
Change-Id: I07e374f71d16f8441dc3a0b02c7d833e0139b74b
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
Needed to support storage of SharedPreferences on both credential-
encrypted and device-encrypted storage paths.
Bug: 22358539
Change-Id: I576b696951b2a9de817d5be63d31b06f7e166a19
When the correct lock pattern is presented, ask the system to also
unlock credential-encrypted storage, if enabled. The token passed
along is empty for now, but can be wired up to gatekeeper in the
future.
During each system boot, ask vold to lock all users keys to give us
a known starting state. This also has the effect of chmod'ing away
any CE data when in emulation mode.
Define and send a new foreground broadcast when the CE storage is
unlocked for the first time. Add stronger last-ditch checking for
encryption-awareness before starting an app.
Bug: 22358539
Change-Id: Id1f1bece96a2b4e6f061214d565d51c7396ab521
This policy allows DO to specify a list of apps to cache even without being
installed on any user.
Bug: 23938464
Change-Id: I2eeab7f148409739fc23a5c44e955ad12b63fd04
Some activities, like the density preference dialog in Settings, may need
to implement custom handling of display density changes.
This corresponds to the bit specified in ActivityInfo.CONFIG_NATIVE_BITS.
Change-Id: Idd4b9ec11a217b1f9af847d7ed8a6f3639e1f8ee
java.lang.IntegralToString is being removed, replaced
all its usage by com.android.internal.util.HexDump.
Bug: 24932279
(cherry-picked from 15fc0548a536750110e159e06a39ba943eccdd81)
Change-Id: Id6ab88337af12d93cd73c41775b9d5baa1e61d96
The ephemeral provider is a service that simply determines whether or
not an ephemeral application is available. The ephemeral installer
does the heavy lifting of installing the ephemeral application.
Bug: 25119046
Change-Id: I591f4c2c3f2b149d299fa8b4f359f2582d9199cb
Add new "am unlock-user" command so we can trigger changes from the
command line.
Move FBE check to static method so it can safely be called early
during boot before the mount service is ready. Move FBE emulation
to persisted system property, and start reading/writing that value.
Change default permission grants to ignore current encryption-aware
flags, since many of the target apps aren't crypto aware.
Always prepare package data directories, which is how we create the
new "user_de" paths during boot.
Bug: 22358539
Change-Id: I6f58ea2d34b3a466d3775d614f8a13de92272621
Reduces the amount of time that a lock is held and reduces the scope of
the lock to only manage the temporary TypedValue. Also ensures that the
typed value is consistently returned to the (single item) pool.
Additionally, performs some refactoring:
- removes unused variables and constants
- moves the NotFoundException cause into the constructor for consistency
with other Exceptions
- inlines sPreloadedDensity which was not used anywhere
- fixes line wrapping and indentation in nearby code
Aside from improvements to locking, there are no functional changes in
this CL.
Change-Id: I8c3059261e3cc2288a086e6637ab946e0b7d3741
Clean up usage of temporary TypedValue in Resources
Reduces the amount of time that a lock is held and reduces the scope of
the lock to only manage the temporary TypedValue. Also ensures that the
typed value is consistently returned to the (single item) pool.
Additionally, performs some refactoring:
- removes unused variables and constants
- moves the NotFoundException cause into the constructor for consistency
with other Exceptions
- inlines sPreloadedDensity which was not used anywhere
- fixes line wrapping and indentation in nearby code
Aside from improvements to locking, there are no functional changes in
this CL.
Change-Id: I8c3059261e3cc2288a086e6637ab946e0b7d3741
Previously applications where uninstalled for the system user at a later stage
in a boot process, when PM has already been initialized and registered as
a service. This was causing a flood of PACKAGE_REMOVED broadcasts.
Applications are now uninstalled at an earlier stage, when PM hasn't been
registered. Packages can simply be marked as not installed and broadcast
can be skipped.
Bug: 25626819
Change-Id: Ib64e7c45619809b0efb99cc566a9a2120ed48cd3
Add AutoPlay flag to ApplicationInfo.
Append autoplay flag to seinfo string - passed to libselinux for
domain labeling decision.
Change-Id: Ieb45ba328140888c0b679bf344df154658f9fbae
- 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
Add granular StorageManager APIs for key creation/destruction and
unlocking/locking. Start passing through an opaque token as part
of the unlock command, but leave it empty for now. We now have a
separate "prepare" method that sanity checks that user directories
are correctly setup.
Define a handful of system properties used for marking devices that
should be operating in FBE mode, and if they're emulating FBE. Wire
a command to "sm", but persisting will come later.
Start using new "encryptionAware" flag on apps previously marked with
coreApp flag, which were apps running in the legacy CryptKeeper
model. Small tweaks to handle non-encryptionAware voice interaction
services. Switch PackageManager to consult StorageManager about the
unlocked state of a user.
Bug: 22358539
Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
Except common shared libraries and boot image, all compilations
are now done through BackgroundDexOptService.
Change-Id: Ib736e253c38b0c8085bc94e45f4e61a048f66e26
This is to make the behvior the same as before
47f71a697a for cases when some of the
locales' languages are empty.
Change-Id: Ifee92e199f20130e060670f244eb3b4b7be13872
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
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
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
When the calling user is a work profile and the device has
file based encryption enabled, show the work challenge via the
Confirm Credentials APIs before launching the requested activity.
A companion CL in Settings will add support to the Confirm
Credentials flow to read the given intent extra and fire it when
the authorization succeeds.
This is part of the Separate Work Challenge feature.
Note nobody will see this yet as the feature is conditioned by
file based encryption.
Change-Id: I303890095936b1fd1f6a99d645724dffba144345
