If the user clears data for an app we reset the permission but
only the changes made by the user. We do not modify syste or
policy flags and also ensure the permission that were granted
by default are granted after the data wipe. This is the same
as starting with a clean slate.
If the package whose data is cleared is a part of a shared user
we resent to initial state only the permissions that the cleared
package contributed. Hence, if another package also declared the
permission as used we do not clear the permission state as it is
still in use.
When a package is deleted for a user but still present for another
user we reset its permissions to their inital state follwoing
above described strategy.
Lastly when a preinstalled package wtih an upgrade is diabled
(triggers upgrade uninstall) and this package is a part of a
shared user, we do not drop permission state (grants and flags)
for permissions used by the shadowed system package. This ensures
that we do not drop runtime permission state (such state is
default grants and user changes).i
bug:22248525
Change-Id: I3a3007476d2cb9f4ff824e1e137a6e1a4d04408b
Calls to remountUid() for secondary users was not using the
correct uid. This would prevent providing the required
storage permissions to default apps.
Discovered when investigating bug: 22356546
Change-Id: I98c8f6da724e46331c1c90b95969ca0871ef4fe9
It is valid to have finger id as Hex value which is not necessarily less than 0.
Always compare with finger id 0 to make sure we are not locking out user.
Bug: 22354158
Change-Id: I19ded12ae4ee335621fd278163c652fc154be6cf
If the app requests its activity to be finished allow it to be finished
immediately if the activity is already paused.
Bug: 22170595
Change-Id: I1ecc0d5f3b85fd80cbe8cdc1d4e32d5c6a50b20c
Sadly MediaProvider makes a ton of assumptions about storage paths
not changing. To ensure that it picks up radical storage changes,
kill it and let it restart to pick up new paths.
Also give ourselves a longer timeout when benchmarking.
Bug: 20275423
Change-Id: I9971c4667dabdc685cb23528443f085f152c461d
Rather than using the fingerprintId, choose a unique name
to show in Settings for newly added fingerprints.
Fixes bug 22009865
Change-Id: I88a92ef95f132321a373bd88f6e1eecaf368f551
It ends up that MediaProvider is persisting MTP storage IDs in its
database, so we need to make sure we generate stable IDs over time,
otherwise we can end up looking into a black hole.
Bug: 22256092
Change-Id: I6a75c239aac1b71fd5f6df0df69b24971079a086
This allows you to specify that a permission can be granted to
any pre-installed system app (not just privileged ones).
And as long as I am doing this, clean up the old "system" permission
flag, renaming it to "privileged" which is what it really is today,
deprecating the old names. And switch the platform's permission
declarations to use the new name.
Change-Id: Iabf484746af232144786851ec7fe90e3de9dddb2
The system watch dog was triggering because all binder threads were
waiting for AppErrorResult#set() to be called which never happened.
One situation where this can occur is if a process continues to crash
and the activity manager marks the process as bad there by causing it
to kill the process immediately which causes a binder death
notification that automatically dismisses the app error dialog before
the user ACKs it.
We now set the result during dialog dismissal if it isn't already set.
Bug: 22141958
Change-Id: If3ac116df5e29c6fba43ee556a859ad3c84c66f3
If a device was securely locked, FLAG_TURN_SCREEN_ON failed to
wake the device from dreaming even if FLAG_SHOW_WHEN_LOCKED
was set. The fix allows SHOW_WHEN_LOCKED activities that are about
to turn the screen on to show even if they're not currently the top
most window with SHOW_WHEN_LOCKED set (which in this case would always
be the dream)
Bug: 21719374
Change-Id: I8d7bce05d95ed9de50b5a52b0973562b070aca5a
Allow multiple apps to be enabled as link handlers even their set of
accepted domains overlaps. Also, allow app linking to be turned on
even for unverified apps if the user wishes.
Bug 21817604
Change-Id: I8bc7f1764318e5d4bb6ce93c66483fe07e922b1d
Respond to --stats by generating a cleaner, easier to parse dump.
Optional argument tells historical stats when to start aggregating.
Don't emit debug information about current notification status.
Bug: 20451514
Change-Id: Ie3d25b674421caa6c9e093f5643cb18d4138a7c8
App movement now has three distinct stages: copying, scanning, and
cleanup. Previously, a battery pull late in the move process would
end up with packages.xml pointing at the old location which had been
torn down. Now, we update packages.xml to point at the new location
as the "source of truth" before we start deleting the old location.
Bug: 21831336
Change-Id: I6f57f37a8cb335127db9ebb7c6b6cfe5755ada99
When waiting for all the windows that belong to an activity, we
skipped the main window, in case it didn't had a surface yet. This
was a problem because with SurfaceViews: They set it's visibility
extremely early in the app visibility change cycle. Then, they use
another thread to draw content. Thus, they have drawn their first
frame pretty fast, where the main thread might still be in the
activity lifecycle phases. Then, we don't even have a surface for the
main window yet, but we start the app transition already because we
think the only interesting window for this app token is the
SurfaceView, which has already drawn.
Bug: 22207948
Change-Id: I708add3aab00575ae1707b25622b9b4614472892
Previous logic led to several edge cases which fixes sometimes broke
other edge cases. New logic uses the clip rect provided by the
transformation as-is and doesn't try to adjust it based on window
flags. Correct clip rect is set in
WindowManagerService#applyAnimationLock using the content insets
before the animation is loaded.
Bug: 21727851
Bug: 20652683
Bug: 19523205
Bug: 15046646
https://code.google.com/p/android/issues/detail?id=161362
Change-Id: I2d4ed6196edb8ee8c401fe9a242aec70d3494574
This prevents fingerprint access from activities
for a user that isn't the current user.
Fixes bug 20223481
Change-Id: I360f90972fe63f5066f701a3efda355a7cb11338
Typical apps are restricted so they can only view shared storage
belonging to the user they're running as. However, a handful of
system components need access to shared storage across all users,
such as DefaultContainerService and SystemUI.
Since WRITE_MEDIA_STORAGE already offers this functionality by
bypassing any FUSE emulation, reuse it to grant the "sdcard_rw" GID
which is no longer handed out to third-party apps. Then we change
the FUSE daemon to allow the "sdcard_rw" GID to see shared storage
of all users.
Bug: 19995822
Change-Id: I504c2a179ba74f142ed0d32da5baa69f4212cd82
