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
|