Move the implementation of the install variants and uninstall to the cmd
command. Additionally, make two other important changes: 1) replace calls
to the legacy PackageManager#installPackageAsUser with the PackageInstaller
2) allow streaming package bits for 'pm install'
Change-Id: I5680f57208d377daadb69b2cc09c233c02fe5016
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
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
Move the implementation of the install variants and uninstall to the cmd
command. Additionally, make two other important changes: 1) replace calls
to the legacy PackageManager#installPackageAsUser with the PackageInstaller
2) allow streaming package bits for 'pm install'
Change-Id: Ia49dac0ccd6470f9d1c1964bdeb3c0b22b856075
... DISALLOW_ADJUST_VOLUME, instead of UserManager pushing
new settings to AudioService.
Also:
- Allow PO to set these two restrictions.
- Now AS.setMasterMuteInternal() respects mUseFixedVolume to make
it consistent with readPersistedSettings().
- When a user switches and restores the mute state in
AS.readPersistedSettings(), also check the current user restrictions
in addition to system settings. Because of the delay in AudioService
before persisting the mute settings in setMasterMuteInternal() and
setMicrophoneMute(), there's was an edge case
DISALLOW_UNMUTE_MICROPHONE and DISALLOW_ADJUST_VOLUME would be ignored
when the user switches right after they are set.
Bug 24981972
Change-Id: I4d9b709a0a0e6812319204568c6e44d6664bdeb4
This set of changes adds the screen that offers this conversion,
and the plumbing so the option is only available on suitable
devices.
It does not implement the conversion mechanism.Add conversion from FDE to FBE
Change-Id: Idf7bc834f30b3d1b0473e0a53c985ef01dd0ad18
The DPC can use it to tell if provisioning a managed profile or for
device owner would work or not.
BUG:25338478
Change-Id: I09ea6a9f23a8e88e4ed37c048170b2a68213086e
Added mUsersLock - short-term lock for internal state, when interaction and
synchronization with PM is not required. Modifications to mUsers and
mRemovingUserIds must be guarded by 3 locks: mInstallLock, mPackagesLock and
mUsersLock. While reads can use mUsersLock.
Testing revealed that the following methods in UMS often cause contention:
- exists
- getUserInfo
- getProfileParent
They all now use a short-term lock mUsersLock for reads.
Bug: 24979571
Change-Id: Ie3a22ea7cbb450c7969800fe2a4a2b2516165e5b
Otherwise the context within it can't be GCed.
It's better to leave the caching to the ContextImpl.
Bug: 25308506
Change-Id: I9be3ba5b1bb6cdc88b77520b2fbd72d9b72ef30d
The battery service just implements the existing commands that
are available through dump.
The activity service implements the small set of commands that
are available through dump (not the rest of the dump commands),
and also introduces some of the simple "am" shell commands as
a proof-of-concept of moving those into the service implementation.
Change-Id: If5ff80930dde787703e2682e43c36ce1dab05d69
- Now DPMS remembers user restrictions set by DO / PO in their ActiveAdmin.
- User restrictions set by DO/PO will no longer be saved by UserManger. Instead,
when needed, UMS will consult DPMS to build "effective" user restrictions.
- UM.getUserRestrictions() will now always return "effective" user restrictions.
- DPMS migrates existing user restrictions per the eng spec.
- Also now UM.setUserRestrictions() will crash. UMS.setUserRestrictions() has
been removed.
This was needed because UM.setUserRestrctions(UM.getUserRestrictions()) will no
longer be a valid use like it used to be.
- Also introduced a fined-grained lock for user restrictions in UM to avoid
deadlock between DPMS and also for better performance.
Bug 23902097
Change-Id: If0e1e49344e2f3e9226532d00777976d1eaa7df3
This mode turns on after the screen has been off for 15 minutes,
and then cycles through 15 minutes of idle and 1 minute of
maintenance, ragardless of whether the device is moving around.
It currently only impacts network access and sync/job scheduling.
It does not remove access to wake locks or alarms for any apps.
It also doesn't report in the public API that the device is in
idle mode (since it isn't modifying the behavior of the power
manager) -- this is probably what we desire, since we don't want
stuff like GCM to be reporting these frequent changes.
We'll probably at least want to have the alarm manager do some
kind of more aggressive batching of alarms in this most (not allowing
more than one wakeup every minute?). That's for the future.
Also updated batterystats to include this new information, which
means the format of some of the data has changed -- device_idle
is no longer a flag, but an enum of (off, light, full), and there
is no information about time spent in light modes.
Also added new data about the maximum duration spent in both light
and full idle modes, to get a better understanding of how those
are behaving.
And did a little cleanup of DeviceIdleController, removing the
sensing alarm which was redundant with the regular alarm.
Change-Id: Ibeea6659577dc02deff58f048f97fcd9b0223307
An OTA package needs to be uncrypted before rebooting into recovery if
it sits on an encrypted /data partition. Once uncrypt gets started, we
cannot re-run it on the package again. Because the file may have been
fully or particially uncrypted and we may end up with a corrupt file
under recovery. Always clean up the package when the device boots into
the normal system to avoid that.
Bug: 24973532
Change-Id: I91682c103d1f2b603626c4bf8d818bced71e3674
