This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
The new AndroidManifest activity attribute, lockTaskOnLaunch attribute
is a boolean that puts the system in lockTask mode when true and if
the activity specified is the root of a privileged task.
This bug also fixes lockTask mode for root activities that finish
themselves. Previously finish was not allowed even if there were
activities left in the task that were still valid.
A NullPointerException for lock task toasts has also been fixed.
Fixes bug 19995702.
Change-Id: Iba6976b1a0cc5a22eb526db66d2e9af66445541f
The install permissions for a shared user were clobbered when a pending
package for this user was matched to the shared user after reading the
state from XML. The reason was that the copy code in PackageSettingBase was
using the getter to get its settings state to which to copy the permissions
for the pending package but this is the permissions state for the shared
user instead of the package. Since the pending package has no permissions
we ended up clobbering the permissions for the shared user.
bug:19955926
Change-Id: Ia8d090883d50fc987a32ceeed6c7562c49698328
If setAppVisibility() is called multiple times in a short interval
while the screen is turned off between the calls, the visibility of
the app would be wrong. For example, the user may see the app under
the launcher, not the wallpaper under the launcher.
The flow to the issue:
1. Screen is on.
2. AM calls setAppVisibility() token=App A's token, visible=true
3. Screen is turned off.
4. AM calls setAppVisibility() token=App A's token, visible=false
Note:
a. In 2., WM would put App A into mOpeningApps, and tell it to be
visible.
b. In 4., because the screen is off now, App A would not be removed
from mOpeningApps. App A might be told to be invisible directly
through setTokenVisibilityLocked(), but it would be told to be
visible again in handleAppTransitionReadyLocked() later.
Change-Id: Icf3d69031ea2822245008248ec8f12bd57218880
- Adds a camera service to system server that forwards events to the
mediaserver camera service.
- Notify the camera service when the device user changes.
Bug: 19186859
Change-Id: I172a2ce46c8e8a131ae7e8dd99d60c5f4f0d6668
This CL mostly affects Settings app as it can run in a user different
than UserHandle.OWNER. Since it is a system app it should have access
to all uid's data usage, regardless of which user it is currently running
in.
Bug: 19967498
Change-Id: I4a7787134d998457f7e2a1029183d44d9584083e
Eliminate dependency in packagesetting keyset metadata on other packages by
introducing reference counts for KeySets and public keys. This also allows
keysets to retain their id across reboots by eliminating the need to remove
all keyset data after scanning all packages on boot, which also should
drastically reduce the number of calls to ArraySet.removeAll().
Bug: 19617481
Change-Id: I6cc65f30e431b8e4ebe49047a9219a0d983f2774
Symptom:
System server crash.
Root Cause:
The value curProcState for array index is -1 if the process
has not attached yet.
Solution:
Skip computing for process which is not attached or curProcState
is nonexistent state.
Change-Id: I71aaf45bb78d73097ebe9dfebf76b72f2d243232
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
If a scheduled full-data backup was attempted but the device had not yet
run the primary key/value backup pass, the full-data backup scheduler
would wind up in a bad state and potentially never retry until reboot.
We now properly reschedule a future retry, using the key/value
scheduling batch quantum as a backoff to be sure to give it a chance
to run before the next time full data is attempted.
Change-Id: Ic7eb7a7940fe6380f40d04813a46fc336e95815e
Added new restriction types - bundle and bundle-array.
Modified RestrictionsManager.getManifestRestrictions to support new
hierarchical restrictions.
Added RestrictionsManager.convertRestrictionsToBundle, which enables
programmatic conversion from a list of RestrictionEntries to a Bundle.
Modified read/write methods for application restrictions in UserManagerService.
Added unit tests.
Bug: 19540606
Change-Id: I32b264e04d5d177ea5b4c39a8ace5ee0ce907970
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
In installPackageLI, dexopt is now performed on a staging directory of the app
(dexopt phase 1). For each codepath:
- /oat/<isa> directory is created
- dexopt output goes to the newly created directory. Optimized files have
.odex extension.
Bug: 19550105
Change-Id: Iec59790d97837b78af82b079fd1970de3388c91d
Storing last successful sign-in/authentication timings, and providing that
information as extra's in updateCredentials and confirmCredentials.
Also, adding a new api: AccountManager#accountAuthenticated(Account).
Change-Id: Icd0dac35b13d61bc28a2e045b96caefffeb353be
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
