There was a bug causing PackageManager to think apps on adopted media
were actually in an ASEC, causing it to skip ABI derivation. This
change fixes the issue by copying the volume UUID into place early
in the scanning process.
Also fixes two places where we had incorrectly been including apps
on adopted media; switched them to check only for ASECs.
Bug: 24583803
Change-Id: If66d1bce02824a4d8e22f741b04a2abda0378cfb
ActivityInfo was missing initialization for the
documentLaunchMode flag in the copy-constructor
and the Parcel constructor. The copy-constructor
is used in multi-user/profile mode to create a
seperate instance of the ActivityInfo per uid
and this was manifesting in the linked bug.
Bug: 21590916
Change-Id: I6f71d94ec32ec6326d23c9b62e9d8d319e2fa25e
(cherry picked from commit 3e2e011785)
Update storage related docs on Context to be consistent, and to call
out relevant Environment methods. Start calling it "shared" storage,
and only mention external for historical reasons. Mention that there
isn't much benefit to using emulated storage over private data
directories to help guide developers to safer locations.
Point out which paths can change over time, so developers know to
only persist relative paths.
Update Environment docs to reflect how they behave for the new
class of adopted storage devices.
Bug: 24251945
Change-Id: Ie5ab337649b4740dfd7594997bbb19c4969cfd2f
Previously, size of of oat directory was not counted by the getsize command,
because base APK location was passed as apkpath argument.
Bug: 23896047
Change-Id: Ic7b6b725785ff2e2a0cf3887ba68c162b23b1212
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
We don't differentiate between null conifguration and
Configuration.EMPTY, but if ResourceKey uses both, it will produce
different hashes and won't be equal. This CL makes ResourceKey always
hold a non null reference to the Configuration object.
We started delivering the configuration overrides in
Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0, which changed behavior from
using always null, to using both null and Conifguration.EMPTY for empty
confgiuration. Now we will switch to using only one value, which is
Configuration.EMPTY.
Bug: 22620824
Change-Id: I090fd90ac21a6b3ebc7f2974a91dd7c861af10d7
BUG: 22287469
1) Fix SyncManager waking up every 2 hrs if there is nothing
to do.
2) Fix sync wake-up alarm not being properly updated if the new
alarm was in the future.
2a) Due to staus bar sync signal that were removed post-K
one of the wake-ups was for 30s in the future, removed this
@hide intent completely.
3) The SyncManager will still set a timeout alarm for 5mins after
the start of a sync. Leaving this in as to post to a handler is
less expensive but more complex, and the alarm update is
correctly working now.
Change-Id: If51c9dd68391ccaeb480a17eb5a1364c4afe4c2a
This CL adds the following permissions by default to the
SIM call manager:
- microphone
- phone
BUG: 22790160
Change-Id: Icaf1db6c6943b3ddbd16a946a81d1bfb734d761f
...space causing package manager to fail
Lower the maximum IPC size we use in various places, to keep it
under the threshold of becoming dangerous. Now everything tries
to keep not much more than 64k.
Change-Id: I814013097966a7843179e5d581bfdb254c5ae318
If they pass in a null data for the intent matching, don't throw up
on it, just consider it to not match.
Change-Id: I30b6af49989eb8b5c2e585ce5d96416f0daff3a8
Any place that we check permissions we also need to check any
app-ops associated with those permissions. In the case of providers
with both <provider> and <path-permission> permissions, track and
report the strongest app-ops denial.
Bug: 22718722
Change-Id: I45e62de39b04d16d071558ad980b701667cfcb9a
...disabled after toggling them off
Keep track of whether a permission that has been declared by an app
was able to actually be installed in the system, along with an API
to find this information so that system UI can tell whether that
permission is of interest.
Also clean up some of the permission debug output.
Change-Id: If4541bedb857789b255bb18f03cad155dcda0b95
There is a zoo of components that handle the home intent and
have different priority. There is no reliable way to distinguish
the setup app from the other apps that handle home as some of
them have lower priority than the setup app and some higher.
This change adds a dedicated category to recognize the default
setup app.
Uncommented the code that grants accounts permissions as the
get_accounts permission is now a runtime permission and can be
granted.
bug:22471024
bug:22501463
Change-Id: I41726751fa2567cbcd7d09c7acfa7615b8aba577
We now place whoever is receiving the MMS on the temporary
whitelist while doing so, so they can get network access to
download it.
There was also an issue that needed to be fixed where we
were no longer updating the list of allowed uids while
dozing based on their proc states... we now do that.
Also did a bit of optimization of the temp white list update
path do the network policy manager, instead of going through
a broadcast we now directly call in to the network policy
manager. This also allows us to have a synchronous version
of updating the list, so we can know the app has network access
before we tell it to do anything.
Finally added battery stats events for things going on and off
the whitelist so we can diagnose the behavior there.
Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
Added Context.sendBroadcastMultiplePermissions(Intent intent, String[]
receiverPermissions) method, which allows an array of required permissions
to be enforced.
Bug: 21852542
Change-Id: I27c9130e8f004b428452501ebc8a36aabde1f343
Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
For modern apps targeting M SDK and up the external storage state
is deterined by granted permissions. For apps targeting older SDK
the storage access is determined by app ops correspning to the
storage permissions as the latter are always granted.
When app ops change we do not remount as we kill the app process
in both cases enabling and disabling an app op since legacy code
is not prepared for dynamic behavior where an operation that failed
may next succeed. Hence, we remount when we start the app.
For modern apps we don't kill the app process on a permission
grant, therefore we synchronously remount the app storage.
bug:22104923
Change-Id: I601c19c764a74c2d15bea6630d0f5fdc52bf6a5a
In the case when multiple apps handle a given web-link action,
all of which have been marked as "launch the app instead of a
browser" and so are otherwise ambiguous, always prefer the app
that was most recently placed into the always-handle-links state.
Bug 22051035
Change-Id: I3f43c19b0d7b74e9843445e41971bb5433affb1c
Bug: 22392651
ColorStateLists were never cached because the lazy-create
of the constant state had a typo.
Resource caching in general was broken because ThemeKey did not
clone the hash code, so all keys in the cache had a hashCode
of 0 which did not match the real, uncloned ThemeKeys hash code
so the binary search in ArrayMap based off of hash code was failing.
Change-Id: I9df1628b226bfa797bed97875354c19bf64f41ad
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
