You can now control the range of target SDKs that receivers
will be need to have in order to receive your broadcast.
Use this for CONNECTIVITY_ACTION to not allow N+ applications
to receive these broadcasts through their manifest.
Also tweak the broadcast debug output code to now include the
disposition of each receiver in the list. This is becoming
important as skipping receivers is becoming a more common
thing to have happen.
Change-Id: I251daf68575c07cbb447536286ab4e68b7015148
Rename APIs to reflect that they're storage-related. Also move
credential-storage APIs to be system API.
Return a null Context when device-encrypted storage isn't
supported. This is the easiest way to keep legacy apps working when
upgrading from M to N.
Reduce strictness of path checking so we don't crash when working
with special packages like "android".
Bug: 22358539, 26104027
Change-Id: I38c24fc003488186210a6ae3b64270f86e1efe56
Right now this is just for the BOOT_COMPLETED broadcast to allow
all apps to receive it.
Also clean up the dumpsys of the broadcast queue to not have
every little detail of ResolveInfo+ActivityInfo+ApplicationInfo,
which is just not useful and makes reading the broadcast queue
debug output a lot harder because of so much noise there is.
And rename the package shell query-intent-* commands to a
shorter query-* form.
Change-Id: I0d01565babb87e68b840c9756a2ea730d699efc7
There are far too many Context APIs with special directory paths
to replicate device-encryption versions of them all. Instead, add
methods to clone a Context that explicitly stores its data in either
credential- or device-encrypted storage.
Methods to test the behavior of a given Context.
Bug: 22358539
Change-Id: I6a6290a9b282605ce9a1f82742fc2c4c50536754
Wraps the entire getDrawable() method in a try/catch block. Clears the
stack trace from the re-thrown exception, since we only need the trace
from the original exception.
Also clears stack traces from re-thrown RuntimeExceptions in applyTheme
implementations.
Change-Id: I92396abf9e748eef78777174b297a09e118f5e70
Add APIs for an ephemeral app to set a cookie which is a small
peice of data cached longer than the app itself. This is useful
for avoiding the user to login every time they use the ephemeral
app. The cookie is stored after an ephemeral app is uninstalled.
Normal apps or ephemeral apps upgraded to full apps can also use
these APIs with the difference that once they are uninstalled
the cookie is deleted.
The cookie size defaults to 16KB and is configurable by a global
settings which can be adjusted via gservices. Also eviction policy
is time based with a default of one month and is configurable by
a global setting which can be adjusted via gservices. If the cert
of the app cahnges (when ephemeral is installed, uninstalled and
installed again) the cooke is wiped to prevent data leaks.
This cahange also adds an API for apps to know whether they run in
an ephemeral mode since it this mode some APIs will not be available.
Another API exposed by this change is private for the system and
exposes all ephemeral apps - installed and uninstalled. Only the
system can call this API. When an ephemeral app is uninstalled the
system stores its name, icon, and permissions. When the app is
reinstalled or a full version is installed the permissions are
propagated.
Change-Id: Id4a73a7750bfbabda0bfcb9bf9018d2062e94367
Needed for apps that want to migrate SharedPreferences from CE to DE
storage. Note that a device will only ever enter a CE mode with a
factory reset, so apps should only be using these APIs when they
want to migrate files to a consistent location on non-FBE devices
for simplicity.
Bug: 25503089
Change-Id: Ic846215da1617d116a048e036415ac7ad523b770
Quiet mode means the user will be free from visual and audio interruptions
from apps inside the managed profile, including notifications, widgets and
others. This CL adds the underlying state bit to users and exposes various
APIs to control and query the quiet mode state.
Bug: 22541941
Change-Id: If5f8e5a897843050e83b6ec26cb39561098f12b9
The system can now boot in a "locked" state where only encryption
aware (EA) components can be safely started. When in this state,
PackageManager already filters away non-EA components, but system
services like AccountManager and SyncManager need to carefully handle
these temporarily "missing" components.
As a guiding principle, all known Accounts are still present when
the device is locked, but communication with underlying non-EA
authenticators is blocked.
To keep things simple for now, all SyncManager requests are kept
dormant until the user enters the unlocked state.
The core of this logic is that RegisteredServicesCache now works
with all components regardless of EA status, which prevents us from
accidentally thinking a service was removed when the user is locked.
Bug: 25945136
Change-Id: I8714121f6236b00821769023c4df7de1c8a99944
* Add a new --ephemeral argument to 'adb install'
* Add plumbing to internally track ephemeralness
* Create new app directory for ephemeral installs
Bug: 25119046
Change-Id: I1d379f5ccd42e9444c9051eef2d025a37bd824fe
When a user is first started, we assume that they're "locked" meaning
that credential-encrypted data is unavailable. Once credentials have
been supplied, we can transition the user to a fully running state.
To facilitate this lifecycle, UserState now has two separate
RUNNING_LOCKED and RUNNING states. To ensure consistent events are
sent on all devices, we always step through RUNNING_LOCKED before
arriving at RUNNING. This consistency means that apps processing
data based on the new ACTION_LOCKED_BOOT_COMPLETED broadcast and
system services using the new onUnlockUser() event will be less
bug-prone over time.
If the user storage is unlocked (which is the case on the majority
of legacy devices), we immediately transition from the RUNNING_LOCKED
into the RUNNING state.
Add logging for all state transitions.
When we "recover" a user in the process of being shut down, return
to the last known state.
Bug: 25943941
Change-Id: I5fec980f10b0d0fb2c272a662d193dc15136f9b9
Previously, Configuration#setTo() would not copy a null locale, and
Resources#updateConfiguration() could fail if it was updated with a
configuration with a null locale or empty locale list.
Bug: 25874762
Change-Id: I76ef5769a16a5165b91c8e5ec5d926c67ef4f3c5
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
With this flag, activities in other profiles can respond to the intent
only if no intent-filter with non-negative priority in current profile can
respond to it.
It is designed like this because activities with negative priority
intentfilter are always used as a fallback in case no one can respond
to the intent. In this case, we expect there is a "real" activity in
other profiles can handle the intentfilter
Here is the example activity that handle the call related intents when
there is no dialer.
NonPhoneActivity.java in Contacts app is an example.
https://github.com/android/platform_packages_apps_contacts/blob/master/AndroidManifest.xml#L461
Bug: 25760508
Change-Id: Ife2a7c19e91ddf5d2e81ad09bd4cf712cdcdb986
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
