History log of /frameworks/base/services/core/java/com/android/server/AppOpsService.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
8f1ea834f9af5ccf6cea1f529f63e727cd13b6a8 27-Aug-2015 Tim Kilbourn <tkilbourn@google.com> Handle the -a flag for dumpsys appops.

Bug: 23017449
Change-Id: I6ce9ac368e2739153867c246893eb544d052834f
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
4d34bb8304ae2e85c2b12628c9a6346c6835de5d 08-Aug-2015 Dianne Hackborn <hackbod@google.com> Fix issue #23037093: "Write system settings" permission value fails...

...to persist after reboot

We were writing a corrupt settings file, so would always reset back
to the default app ops state after boot...!

Also add new appops service commands to manually write and read
its settings, since that is very useful for testing.

Change-Id: Ia510507764738fd82e45ec0be6db840c6ea30c28
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
215b44a1c2c883e628e1ab5b945a1a4aa04ee392 05-Aug-2015 Svetoslav <svetoslavganov@google.com> Fix app ops regressions introduced by the per UID policy change

1. Add a missing statement in the parsing code

2. Notify for all packages on UID ap op policy change

bug:22957162

Change-Id: Ic2bd5d07ef52be207e66b63ffe45fd8a456eb5a8
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
f3807aa57267117eba83cc2a3b13add59d4a251a 02-Aug-2015 Svet Ganov <svetoslavganov@google.com> Fix NPE in AppOpsService

bug:22802981

Change-Id: I73eee5ff9cf1603d8f30355554ef075aa14afd30
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
2af5708ab0e55fe68f1810cefdc6e3889233c186 30-Jul-2015 Svet Ganov <svetoslavganov@google.com> Add per UID control to app ops.

The app ops mananger service maintains a mapping from UID to
a list of packages where each package is mapped to a list of
non-default app op states (default states are inferred and
not stored). Hence, specifying the app op state for a UID
requires setting the app op for each package in the shared
UID.

This is problematic when installing new packages if there
is a non-default app op policy set for another already
installed package in the same UID as the app op for the new
package has to be updated to be in sync. The package installer
cannot do this as it is in another process and the app op
update will not be atomic. Therefore, the app ops manager
service has to support specifying app op policy on a per
UID basis.

We now have a UID state object that contains the per package
non-default app op states as well as the per uid non-default
app op states. If there is a UID policy specified then it
takes precedence over the per package one. Even further,
changing the uid policy updates the package policies in this
UID if the state is non-default. Changing a package app op
state also updates the app op state for the whole UID if
the per UID policy for this op is non-default. Clearing the
app op state for a package, clears the policy for the UID
as well.

bug:22802981

Change-Id: I78044906d9fcc6066abf07e706c2c88f3397d293
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
6ee871e59812fea4525c50231f677c4bd10c74b8 10-Jul-2015 Svet Ganov <svetoslavganov@google.com> Teach storage appops.

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
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
99b6043dad9d215cf15810b885b6b8c215dd5b5a 27-Jun-2015 Svet Ganov <svetoslavganov@google.com> Teach receivers, activities, providers, and services app ops.

Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.

bug:22199666

Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
3853611f77997fd7670163afdc8d9f546dfba566 19-May-2015 Svet Ganov <svetoslavganov@google.com> Clear binder identity before dispatching ap op mode changes.

bug:21078841

Change-Id: I409b739bbda10542142c8aac1522ad49882f5ec5
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
9e9e2e73c6ec7bece20268196dc89ad0c8bafad4 08-May-2015 Wojciech Staszkiewicz <staszkiewicz@google.com> Pass charset to XmlPullParser.setInput instead of null

Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.

bug: b/20849543

Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
b9d71a6f89b1183f6389b1774652445a420c6cbf 30-Apr-2015 Svet Ganov <svetoslavganov@google.com> Add body sensors app op - framework base

Change-Id: Idd5cd573fab3405e5b2a6e51d2d9d115650826e9
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
33d3c53da021f0d044028860ace0f4ad817273f5 11-Feb-2015 Alex Klyubin <klyubin@google.com> resolved conflicts for merge of 517e0274 to lmp-mr1-dev-plus-aosp

Change-Id: Ic20b6c8851458483dd73a144bd5ae6e8d141e62a
b9f8a5204a1b0b3919fa921e858d04124c582828 03-Feb-2015 Alex Klyubin <klyubin@google.com> Move hidden ApplicationInfo flags into a separate field.

The public API field android.content.pm.ApplicationInfo.flags can
support only 32 flags. This limit has been reached. As a short term
workaround to enable new public flags to be added, this CL moves flags
which are not public API into a separate new field privateFlags and
renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED
is now PRIVATE_FLAG_PRIVILEGED).

The new privateFlags field is not public API and should not be used
for flags that are public API.

The flags that are moved out of ApplicationInfo.flags are:
* FLAG_HIDDEN,
* FLAG_CANT_SAVE_STATE,
* FLAG_FORWARD_LOCK, and
* FLAG_PRIVILEGED.

NOTE: This changes the format of packages.xml. Prior to this CL flags
were stored in the "flags" attribute. With this CL, the public flags
are stored in a new "publicFlags" attribute and private flags are
stored in a new "privateFlags" attribute. The old "flags" attribute
is interpreted by using the old values of hidden/private flags.

Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
7b7c58b3842d47c4c8df4876e2e2248c58477d97 03-Dec-2014 Dianne Hackborn <hackbod@google.com> Work on issue #18572506: AppOps in-memory state is invalid after...

...uninstalling updates to a system app

Things seem to be working fine, however we were not as aggressive at
writing out the current state in this case as we probably should be.

Also introduce more features to the appops command, which are useful
for testing this.

Change-Id: I177a9cc0e16e98b76fee0d052d742e06842bb3f9
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
0fcef84cca23724c13ecfe775b90dec3614cc3e3 13-Sep-2014 Dianne Hackborn <hackbod@google.com> Fix issue #17479850: AppOpsManager.checkPackage() allows...

...root or shell to claim any package name

Re-arrange so checkPackage() doesn't go through the path where
the package name will be forced for root and shell uids.

Change-Id: I450cd6ac8148afd75b526724afdf46ab63de4c43
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
d6a98979b5d45fff1fa842932274517e999a59c2 04-Aug-2014 Alexandra Gherghina <alexgherghina@google.com> Fix resetAllModes call to act only on the calling user

This makes it consistent with other methods in different services.
Also fixes the Settigns bug referenced below.

Bug: 16727586
Change-Id: I0b8bcb248f621fcfa2cb12163caeec9eb8ff5b1c
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
401de1785eccc946ed6c35e9b7fccab92b2022af 25-Jul-2014 Julia Reynolds <juliacr@google.com> Remove the profile/device owner user restriction bypass.

Bug: 16566096

Change-Id: I4a56046df44d36d82edc64fc727e8cad5dc75382
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
b64afe17064f126eb782c42a238db65f080fc8f0 23-Jul-2014 Dianne Hackborn <hackbod@google.com> Further fix on issue #16013164

Dumb dumb dumb copy/paste error when moving the
uid checking up out of the function.

Change-Id: I01513ccd80750b724dbfa8d9d7d171819c6b959b
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
7b41467704f941b11af6aace3e40993afc7f6c6f 18-Jul-2014 John Spurlock <jspurlock@google.com> Zen mode filtering should use new usage constants.

Refactor stream-based calls to usage-based calls.

Bug:15279516
Change-Id: I3f7757d8123c14670e2ad5f8e6aa4e9803efe7ec
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
1c7c319bb89b9988bfd12afc3e8d89449fd163fc 26-Jun-2014 Jason Monk <jmonk@google.com> User restriction for disallowing window creation

Block any types of windows that could by used by apps to create
views on top of a locked app. This can be used by device admins
in conjunction with lock task mode.

Added a way for system (and priv apps) to bypass user restrictions
for specified op codes.

Bug: 15279535
Change-Id: I2381530ef6226a5bb32a99bb4030baafb39bf564
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
133b9df951c633a1f72b7e12f8aa9ee9d7da9db6 01-Jul-2014 Dianne Hackborn <hackbod@google.com> Fix issue #16013164: Externally Reported Moderate:

AppOpsService.setMode() allows setting mode for own uid without permission

Change-Id: Ic60a10f0e95f19658c61567826dff28b657efe73
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
f584f014dbb281727fccfea10bc9c2539a752f17 20-May-2014 Amith Yamasani <yamasani@google.com> Allow adding a user while still removing other users

When at the user limit, removing and adding a user causes a race
condition where the deleted user is still being removed and adding
another one fails.

This change excludes deleted users from the counting to compare
against the limit.

Also fix an ArrayIndexOutOfBounds recently introduced in AppOpsService.

Bug: 13282768
Change-Id: Ib79659e7604396583a280dbbc560b288a6d9051c
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
62062996dd256df8b575b2ba1f0bf97109c4e0ba 06-May-2014 Jason Monk <jmonk@google.com> Notify AppOpsService of UserRestrictions and Owners

This makes the DevicePolicyManagerService and UserManagerService
push the DeviceOwner/ProfileOwners and user restrictions on boot
as well as on any change.

This also adds a list of restrictions that allow any op to connected with
a user restriction such that it will return MODE_IGNORED when the user
restriction is present (except for the device/profile owner).

Change-Id: Id8a9591d8f04fe5ecebd95750d9010afc0cd786c
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
1af30c7ac480e5d335f267a3ac3b2e6c748ce240 10-Mar-2014 John Spurlock <jspurlock@google.com> Add stream-level suppression to vibrate/audio services.

- Add new audio restriction layer to app-ops. Restrictions add
additional constraints to audio operations at a stream-level.
Restrictions do not affect the persistable state, and are purely
additive: that is, they can only impose additional contstraints, not
enable something that has already been disabled. Restrictions
also support a whitelisted set of exempt package names.

- Add new audio stream-level checks to app-ops.

- Implement a provisional OP_PLAY_AUDIO suppression to three
java entry points MediaPlayer, AudioTrack, & SoundPool.

- Enhance vibrator api to take stream information as an optional
hint - the constants correspond to AudioManager stream types.
OP_VIBRATE now supports the stream-level restriction check.

- Simplify Vibrator subclasses by adding default implementations
for two .vibrate calls.

- Migrate NoMan's zen-mode control to use the new app-ops
stream-level restriction mechanism.

Change-Id: Ifae8952647202f728cf1c73e881452660c704678
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
6f357d3284a833cc50a990e14b39f389b8972254 16-Jan-2014 Jeff Brown <jeffbrown@google.com> Start untangling system server early bootstrapping.

Refactored SystemServer to get rid of a bunch of legacy cruft related
to how the ServerThread used to be started up.

Create system context first when system server starts. This removes
the tangled initialization order dependency that forced us to start
the activity manager service before most anything else.

Moved factory test related constants into the FactoryTest class.

Partially migrated Installer, ActivityManagerService, and
PowerManagerService to the new SystemService pattern. There's more
work to be done here, particularly around the lifecycle of the
power manager.

Bug: 12172368
Change-Id: Ia527dd56e3b3fd90f9eeb41289dbe044921230d4
/frameworks/base/services/core/java/com/android/server/AppOpsService.java
9158825f9c41869689d6b1786d7c7aa8bdd524ce 22-Nov-2013 Amith Yamasani <yamasani@google.com> Move some system services to separate directories

Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.

Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/AppOpsService.java