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
Make the meaning of CONTENTS_FILE_DESCRIPTOR more explicit, and
emphasize that describeContents() applies to the current object
instance, not to the class generically.
Change-Id: Ie5010e24c2e57bdc6c982249adb9d4c871d46f5a
It forces the user to stop instead of going into the background. Also
changed behavior of stopUser method. Now it also attempts to stop related
users along with the specified userId.
Based on ag/807976, with the only difference that it's now a user restriction.
Bug: 24579258
Bug: 24708668
Change-Id: I357298908816fc58feeed83b7e9979fc33d25da6
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
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
Now that the activity manager keeps track of per-uid process states,
we can push that already rolled-up data into battery stats to directly
track the times in those states.
The problem with the reporting was actually that we weren't dealing
correctly with negative process states, which is now fixed. (It was
interpreting them as FOREGROUND rather than not running.)
Also split out a number of new states -- TOP, FOREGROUND_SERVICE,
TOP_SLEEPING -- from FOREGROUND. This should allow us to get a much
better idea of how much an app has been actively in use: TOP is when
it is directly visible to the user or in use by such, FOREGROUND_SERVICE
is when it is running in the background in a way the user is aware of.
Also when reporting these numbers, they are no longer added together as
reported but kept as separate times.
Change-Id: I6d307503a4b4ad5c0d5d49305ef63f8eb858e2c9
Use restrictions from mGuestRestrictions when creating a guest. Initially
phone calls, SMS and installing from unknown sources is not allowed.
Bug: 25904144
Bug: 25729516
Change-Id: I461c492ad64842d3707f73dfd83b533aa31b63ef
- Also make sure DPMS.mOwners is always guarded with DPMS.this.
(and remove synchronization from Owners.)
Bug 25796840
Change-Id: I83f7b78e7b437d9c2a2b1d6e714346cd15f95330
Now that we don't have UM.setUserRestriction*s*() that could remove
all existing restrictions, there's almost no point handling
DISALLOW_RECORD_AUDIO differently.
Now DISALLOW_RECORD_AUDIO is handled just like other restrictions,
except we don't persist it.
Bug 24954662
Change-Id: I27875b4a74dd95a3ce6bb774081eeaf718eaec15
Due to org.apache.harmony.security package removal,
RecoverySystem#verifyPackage was rewritten to use
sun.security.pkcs package for verifining package
signature.
(cherry-picked from 84acbd76f7e1300e8404ac1b94f008826f9cc0fb)
Change-Id: I3a2058982beadab1aaae793c25db5c6f7387a72b
- Now when DO/PO sets a user restriction, DPMS pushes it to UMS and
then UMS persists it, in order for UserManager.hasUserRestriction()
to never have to talk with DPMS, which would cause lock inversion.
- Also apply user restrictions when a user start.
- This is an updated version of the abandoned CL -- the difference
is, ActivityManager no longer has to call DPMS.
- Also removed an unnecessary write to userlist.xml in UMS.
upgradeIfNecessaryLP().
Bug 23902097
Bug 25388912
Bug 25354031
Bug 25641040
Change-Id: I0948aea06ad7d0f45fe612a431d765faddfe3c58
Add new "am unlock-user" command so we can trigger changes from the
command line.
Move FBE check to static method so it can safely be called early
during boot before the mount service is ready. Move FBE emulation
to persisted system property, and start reading/writing that value.
Change default permission grants to ignore current encryption-aware
flags, since many of the target apps aren't crypto aware.
Always prepare package data directories, which is how we create the
new "user_de" paths during boot.
Bug: 22358539
Change-Id: I6f58ea2d34b3a466d3775d614f8a13de92272621
- Cleanup: rename the "open copy destination" action to "pick copy
destination", which better reflects what it does.
- Move DocumentsIntent from BaseActivity to Shared.
- Rename ACTION_BROWSE_DOCUMENT_ROOT to ACTION_BROWSE for general browsing.
- Use the new ACTION_BROWSE to open the copy destination when copy
notifications are tapped.
BUG=23137963
Change-Id: I10480b45a16ce716febac5453cb5015d26bb0062
The device idle service now knows when the system is actively
doing significant things (syncs, jobs, alarms, downloads). It
uses this, when in an idle maintenance window, to determine when
it can end that window early -- when such work is no longer
happening.
For now this just allows us to shorten the windows. In the future
we should use this to allow us to expand the windows to a longer
potential time, adjusting future windows to shorter durations if
earlier ones use more time. This will allow us to batch occasional
long operations (such as downloads) into one window, making up
for that with much shorter later windows.
Change-Id: Ie482abd50bc43be9a8917a769a5175851eee4ec4
Change-Id: I4013e0700369764a26485d8620ebf16d8bea1951
Test: Built and ran Android in an emulator
Bug: 25242023
Signed-off-by: Casey Dahlin <sadmac@google.com>
- Fix dumping of package manager intent filters so the option
to print the filter detail works again.
- Extend dump resolvers to allow you to specify the specific
types of resolvers you'd like to dump.
- Add new package manager commands for querying activities,
services, receivers.
- Move the code for parsing a command line into an intent to
the framework, so it can be used by the new package manager
commands and later elsewhere.
Change-Id: I56ea2bb8c3dd0e5198ee333be8f41ad9dcdb626f
Add granular StorageManager APIs for key creation/destruction and
unlocking/locking. Start passing through an opaque token as part
of the unlock command, but leave it empty for now. We now have a
separate "prepare" method that sanity checks that user directories
are correctly setup.
Define a handful of system properties used for marking devices that
should be operating in FBE mode, and if they're emulating FBE. Wire
a command to "sm", but persisting will come later.
Start using new "encryptionAware" flag on apps previously marked with
coreApp flag, which were apps running in the legacy CryptKeeper
model. Small tweaks to handle non-encryptionAware voice interaction
services. Switch PackageManager to consult StorageManager about the
unlocked state of a user.
Bug: 22358539
Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
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
