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
System audio may reject <Request ARC Initiation> with a response
<Feature Abort> or just time out. Do not send <Request ARC Terminated>
in response so as not to turn off the ARC mode, as it may not be
the intended behavior.
Bug: 19928094
Change-Id: I469dfa53bf35dfbca7daa86a69763b10551663ec
An activity freezes the display when it is relaunched when
configuration changes. If the activity takes time to launch and
another activity is launched before it is done, the activity that
froze the display will be paused and might not have the chance to
unfreeze the display. This will put WindowManager in an odd state.
We now unfreeze the display when an activity is done pausing in case
it was previously freezing the display.
Bug: 19823482
Change-Id: If5538aea639e06d0b8621646bf6b2e12d325287a
1. Fixed the case where runtime permissons can be toggled by a
developer via a system property.
2. Relaxed the runtime permission XML parsing to be more fault
toelrant and consistent wiht the reset of the package manager
parse code.
3. Fixed a deadlock due to calling in to the activity manager
with the package manager lock held to kill an app.
Change-Id: I11dfb57ad4d8119baea79227dc2a3fe5e2208515
We now make sure to pause by at least requestFullBackupTime() between full-data
backup operations, to give the transport the ability to apply traffic control
while we're running the queue of eligible packages.
Also, we now reset a package's queue position whenever a full-data backup for
that package is run explicitly via adb.
Bug 19732890
Change-Id: I6cf24495ad18eebd55557f229d11c703e5b7f529
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
Create two special SETs.
SET_DBG_VPN_IN is used by individual applications to know
how much traffic of the NetworkIdentity was actually moved
from a VPN app.
SET_DBG_VPN_OUT is used by the VPN app to know how much
traffic of the NetworkIdentity was deducted.
A debug application can restore the raw stats by these
entries.
raw_traffic = recorded_entry (TAG_NONE, SET_ALL)
+ recorded_entry (TAG_NONE, SET_DBF_VPN_OUT)
- recorded_entry (TAG_NONE, SET_DBF_VPN_IN)
The two debug SETs are not returned by
NetworkStatsService.openSession(). These debug entries are
retrieved by NetworkStatsCollection.dump().
Bug: 19536273
Change-Id: I03ef9f7667f5f2f48cbe3f6b11447fe7ead8ad3b
More S's for More Speed
Split JankTracker's backing data from the
class to allow for data relocation to/from ashmem regions
Pack the jank tracking data to fit in 256 bytes
Change-Id: Ife86a64b71a328fbd0c8075fe6a0404e081f725b
This change adds support for the case where we change the state
of runtime permissions support via the system property. This
was not working properly before because we did not handle system
app permissions properly.:
Change-Id: I66c5e6c823b8521999972b0432b1daaba38c9709
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
In order to not deadlock the system, we need to retrieve
WiFi energy info outside of the BatteryStats lock. We do this,
then pass that data down to BatteryStatsImpl to process.
b/19729960
Change-Id: Ib8beba1d5ac81d89144d502c4b688d0a88c5b102
We now make sure, when scanning post-factory app installs, that we do not
accidentally activate a "leaked" or otherwise superfluous APK tree that the
scan algorithm happens to encounter before the one that we expect a priori
based on the persisted package-installation state. When we find such an
extraneous installation we ignore it in favor of the expected one, similarly
to the policy used when collecting system-bundled packages that have been
updated.
Even if we find an unexpected APK for the package, if the expected one
turns out to be absent we fall back to the existing "we thought this app
was present and now it isn't" logic.
Bug 19602471
Change-Id: I141a93661946176c05d8cf52a123bdf75c8eef74
