History log of /frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
29931bc684bde6b430923122777684178ee2681c 11-Mar-2016 Ruben Brunk <rubenbrunk@google.com> Allow per-package exemptions for restricted AppOps

- When setting blanket user restrictions, per-package
exemptions may be granted.
- Exempt the current active VrListenerService from the
blanket restriction on drawing overlays while in VR mode.

Bug: 26775563
Change-Id: I14b17a126502c7905a970ad42d25d6dd600b86b1
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
9cea80cdddbecadb304eb7c8373cf1ed397f433a 16-Feb-2016 Svet Ganov <svetoslavganov@google.com> No overlay when permissions shown - framework

bug:26973205

Change-Id: I88395e47649191bb7db6dd8723c49e741ef4f1e4
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
85be0c4e21ba6a2b74a8546403c6da03a343e5aa 04-Jul-2015 Svet Ganov <svetoslavganov@google.com> Fix app ops aidl as it is also used from native.

bug:22248271

Change-Id: Ic3f31d1ee4d27c1483c9d19929c19946d4c815c6
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
b9d71a6f89b1183f6389b1774652445a420c6cbf 30-Apr-2015 Svet Ganov <svetoslavganov@google.com> Add body sensors app op - framework base

Change-Id: Idd5cd573fab3405e5b2a6e51d2d9d115650826e9
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
401de1785eccc946ed6c35e9b7fccab92b2022af 25-Jul-2014 Julia Reynolds <juliacr@google.com> Remove the profile/device owner user restriction bypass.

Bug: 16566096

Change-Id: I4a56046df44d36d82edc64fc727e8cad5dc75382
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
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/core/java/com/android/internal/app/IAppOpsService.aidl
d4a8b9d3c1b2ad4a65063f867665e38b8a5f9c0f 06-Sep-2013 Dianne Hackborn <hackbod@google.com> Fix issue #10650718: Camera DOA on KLP

Methods not kept in sync.

Change-Id: I2621255707bbc569ac476b8fb0f7e82f68585b12
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
911d7f411f36f2279aae44c89ff1d33a29140046 06-Sep-2013 Jeff Sharkey <jsharkey@android.com> Provide calling package to ContentProviders.

The calling package is important for ContentProviders that want to
grant Uri permissions as a side effect of operations, so offer it
through a new API. Validates the provided package against the
calling UID before returning.

Bug: 10626527
Change-Id: I7277880eebbd48444c024bcf5f69199133cd59e4
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
0770f9ef66f6e0d8724c972fbdce81aae6de2ca1 03-Aug-2013 Dianne Hackborn <hackbod@google.com> resolved conflicts for merge of c8911ddd to master

Change-Id: I790b547268a23848577199256fc5abc9bdb7abb8
607b414d0444067e166fa54d8ea37563f2715ea3 03-Aug-2013 Dianne Hackborn <hackbod@google.com> Add new app ops method to reset all op modes.

Change-Id: I5ee6764de8dc31d812e5a788914ab0099bbef4c0
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
e98f5dbe6b6f9f2cb6a73ee750faacda2596b34f 18-Jul-2013 Dianne Hackborn <hackbod@google.com> Make it safe to use start/stop app ops outside of system proc

We now keep track of all of the active start operations per
non-system process, so they can be cleaned up if the process
goes away.

Change-Id: I9d05f1e0281c47dbe1213de014f0491f1359685c
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
d7d28e675ea7aac151c0c302d233b476537af946 12-Feb-2013 Dianne Hackborn <hackbod@google.com> App ops: media ops, set up to be callable from native code.

This is to help implementation of bug #8181262 and maybe
bug #8181261

Adds some definition for media ops (though nothing is yet using
them), and re-arranges things a bit so we can implement native
calling in to the app ops service.

Also add some java docs.

Change-Id: I637959745db820e676f23a35a5d2224f51bc6689
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
c2293025a25e04b26bf53713d71f85fd9ca5e8e9 07-Feb-2013 Dianne Hackborn <hackbod@google.com> App ops: track system windows, monitoring changes.

Change-Id: I273e82bdad66ada3bf0f7ec9176bc304b9ee1ee8
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
5e45ee6752528791deb66b83d76250685de15d47 25-Jan-2013 Dianne Hackborn <hackbod@google.com> App ops: you can now turn off operations.

Also add new ops for calendar and wi-fi scans, finish
implementing rejection of content provider calls, fix
issues with rejecting location calls, fix bug in the
new pm call to retrieve apps with permissions.

Change-Id: I29d9f8600bfbbf6561abf6d491907e2bbf6af417
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
72e3983d38f656cfa8c7a038eb80bdd9ea06768e 19-Jan-2013 Dianne Hackborn <hackbod@google.com> New API to get app op information about a single package.

Change-Id: I986453d9bb4161da467fb820b12502464e936483
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
35654b61e8fe7bc85afcb076ddbb590d51c5865f 15-Jan-2013 Dianne Hackborn <hackbod@google.com> More work on App Ops service.

Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).

Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.

This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).

Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl
a06de0f29b58df9246779cc4bfd8f06f7205ddb6 12-Dec-2012 Dianne Hackborn <hackbod@google.com> New "app ops" service.

Initial implementation, tracking use of the vibrator, GPS,
and location reports.

Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).

The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.

But hey, it's a start!

Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
/frameworks/base/core/java/com/android/internal/app/IAppOpsService.aidl