Storage devices are no longer hard-coded, and instead bubble up from
whatever Disk and VolumeBase that vold uncovered, turning into
sibling Java objects in MountService. We now treat vold events as
the source-of-truth for state, and synchronize our state by asking
vold to "reset" whenever we reconnect.
We've now moved to a model where all storage devices are mounted in
the root mount namespace (user boundaries protected with GIDs), so
we no longer need app-to-vold path translation. This also means that
zygote only needs to bind mount the user-specific /mnt/user/n/ path
onto /storage/self/ to make legacy paths like /sdcard work. This
grealy simplifies a lot of system code.
Many parts of the platform depend on a primary storage device always
being present, so we hack together a stub StorageVolume when vold
doesn't have a volume ready yet.
StorageVolume isn't really a volume anymore; it's the user-specific
view onto a volume, so MountService now filters and builds them
based on the calling user. StorageVolume is now immutable, making
it easier to reason about.
Environment now builds all of its paths dynamically based on active
volumes. Adds utility methods to turn int types and flags into
user-readable strings for debugging purposes.
Remove UMS sharing support for now, since no current devices support
it; MTP is the recommended solution going forward because it offers
better multi-user support.
Simplify unmount logic, since vold will now gladly trigger EJECTING
broadcast and kill stubborn processes.
Bug: 19993667
Change-Id: I9842280e61974c91bae15d764e386969aedcd338
Now openQuickContact goes thorough DPM. When a lookup URI is build with
a lookup key returned by the enterprise lookup APIs for a corp contact, the
lookup key will have a special prefix. In that case we go through DPM
and have it launch QC on the managed profile, if the policy allows.
For now we use the same DPM policy as enterprise-caller-id to disable this.
Design doc: go/cp2-mnc-enterprise-dd
Bug 19546108
Change-Id: I831a8190ae902ae3b1248cce6df02e3a48f602d2
The purpose of this feature is to prompt the Disambiguation dialog
to Users as less as possible.
- add the new "autoVerify" property to the IntentFilter class
- add new APIs to PackageManager:
verifyIntentFilter(int, int, List<String>),
getIntentVerificationStatus(String, int),
updateIntentVerificationStatus(String, int, int),
getIntentFilterVerifications(String)
for supporting IntentFilter verification
- add support for multi-user
- update PackageManager for IntentFilter verification:
basically when we are installing a new package, ask for verification
of all domains from the IntentFilters that have the "autoVerify" to true.
This means that the PackageManager will send a well defined protected
broadcast (with a new INTENT_FILTER_NEEDS_VERIFICATION action) to
an IntentFilter verifier to do the real job of verification.
We are passing in the broadcast Intent all the necessary data for
doing the verification. The PackageManager will receive as response
the result code of the domain verifications and, if needed, the list
of domains that have failed the verification.
- add a new INTENT_FILTER_VERIFICATION_AGENT permission that needs to
be set by an intent filter verifier to be considered as a trustable
party by the PackageManager.
- add also a new BIND_INTENT_FILTER_VERIFIER permission for securing
the binding between the PackageManager and a service doing the
intent filter verifications.
- add ResolveInfo filterNeedsVerification which is a boolean
to knows if the IntentFilter is of a type that needs a verification
(action VIEW, category BROWABLE, HTTP/HTTPS data URI)
- add new "domain-preferred-apps" / "d" dump command for listing the
prefered Apps for all domains
- add new "intent-filter-verifiers" / "ivf" command for listing the
IntentFilterVerifier used
- introduce the IntentVerificationService which is a basic service
for verifying IntentFilters. This service will send HTTPS requests
to the domain declared in the IntentFilter(s) for doing the
verification. This service has a low priority level so that it
can be replaced by a more sophisticated one if needed. This service
is updating the PackageManager intent verification states thru
the updateIntentVerificationStatus(...) API.
- update MockPackageManager
Change-Id: I0bfed193d0bf1f7c7ac79f6c1b160b7ab93b5fb5
Now openQuickContact goes thorough DPM. When a lookup URI is build with
a lookup key returned by the enterprise lookup APIs for a corp contact, the
lookup key will have a special prefix. In that case we go through DPM
and have it launch QC on the managed profile, if the policy allows.
For now we use the same DPM policy as enterprise-caller-id to disable this.
Design doc: go/cp2-mnc-enterprise-dd
Bug 19546108
Change-Id: I4840e7fad8a6a60249df07d993d26d03619650d4
We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
Change the DIA extra's type to ComponentName, making it consistent with
EXTRA_PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME.
Bug: 19891726
Change-Id: Ib41a9d22ff22e114cde80010fbc41db26f2b5f82
Added new API consisting of android.app.usage.NetworkUsageManager and
android.app.usage.NetworkUsageStats. Through them data usage on a
network interface can be programmatically queried. Both summary and
details are available.
Bug: 19208876
Change-Id: I0e0c4b37ae23ad1e589d4b0c955b93f28ba4333e
This method will be used by other system services to decide whether an
app is a profile owner or device owner.
Change-Id: I9577700d03ce2c80c798a60c6c2f480fd1913f43
This change prevents the Runnable posted by ActivityContainerCallback
from retaining the ActivityView's callback if it is never cleared out
from ViewRootImpl.sRunQueues.
Bug: 19872883
Bug: 19654978
Change-Id: I6dce4381b96c8c77afcd38a55bfe474f13dfbfba
These extras will be used in ManagedProvisioning to allow
Bluetooth connections from provisioned devices.
Change-Id: I7118acd4ea71e2028a0c9f0c61031c78deef8908
Before all permissions were granted at install time at once, so the user
was persented with an all or nothing choice. In the new runtime permissions
model all dangarous permissions (nomal are always granted and signature
one are granted if signatures match) are not granted at install time and
the app can request them as necessary at runtime.
Before, all granted permission to an app were identical for all users as
granting is performed at install time. However, the new runtime model
allows the same app running under two different users to have different
runtime permission grants. This change refactors the permissions book
keeping in the package manager to enable per user permission tracking.
The change also adds the app facing APIs for requesting runtime permissions.
Change-Id: Icbf2fc2ced15c42ca206c335996206bd1a4a4be5
Add view ID information to the assist structure.
Also rework the API to simplify how it works by removing
the ViewNode wrapper around ViewNodeImpl -- these are now
just the same thing. And then add complexity by introducing
a formal WindowNode object that contains the top-level window
information (so I can add in some more window-specific info
in the future).
Change-Id: I5d525cf61ab6a73193e5cceb4c09d2d21cc27bae
- Keep track of whether or not HUNs are allowed per-package.
- No impact on ranking, purely presentational.
- Simplify RankingHelper with a package table.
- Improve RankingHelper dump.
- Fix some warnings and typos.
Bug: 19776495
Change-Id: I28d69df69b576f4eabbb528eabecb1f736f0e830
The initial purpose of the NetworkSecurityPolicy class is to provide a
way for network libraries to check whether cleartext network traffic
(e.g., HTTP, WebSockets, XMPP, IMAP, SMTP) should be blocked from this
process.
The policy is set declaratively by the app developer in the app's
manifest and can be queried from ApplicationInfo.flags. Unfortunately,
several network stacks (bundled and unbundled) do not have a reference
to ApplicationInfo or Context.
Alternatives:
* Keep this API hidden (and thus potentially move it from framework to
libcore), thus precluding unbundled HTTP stacks from using the API.
* Introduce a new java.lang.System property instead of this API.
However, such properties are a mess and not as powerful/extensible
as a public class.
Bug: 19215516
Change-Id: If22056a74d257bf1d805ebb4fc284240b3d338f1
Doing it in binder thread will cause deadlock if stdout of
process under execution is larger than buffer of
java.lang.Runtime#exec(String).
Bug: 19829679
Change-Id: Icf0fccd3e2e80b0db4cc1115e501f79066adf091
Also add API for voice interaction service to control
whether the system should hold a wake lock while it is
working with an activity (and actually *do* hold a wake
lock while doing so, duh!).
And while in there, clean up the launching wake lock to
correctly give blame to the app that is launching.
Change-Id: I7cc4d566b80f59fe0a9ac51ae9bbb7188a01f433
Initial implementation of system APIs for broadcast
radio framework. Added manager and interfaces to control
a broadcast radio function exposed by the radio HAL.
- RadioManager: contains data structures and definitions as well as
top level API for feature discovery and tuner interface instantiation.
- RadioTuner: interface to control a broadcast radio tuner.
- RadioModule: framework component implementing the RadioTuner interface
and controlling a HW radio module via the radio HAL.
- RadioMetadata: representation of radio meta data (Station name, PTY,
song title, artwork, etc...) communicated by the framework to the client.
Change-Id: Iee42a185c694503e25f0b2dcfa417d88f5e9549b
