Protecting Your Privacy: App Ops, Privacy Guard, and XPrivacy

Protecting Your Privacy: App Ops, Privacy Guard, and XPrivacy

After yesterday’s article about Google’s recent changes to the Play Store that post a number of privacy concerns for users, today we are going to look at the three most popular options for users to protect their own privacy on their Android devices. First though, let’s take a look at how they work, and what they are for.

Why Should I Care?

Since the start, Android has had a permissions system, to allow users to control what apps are able to do on their device. When an application is installed, the user is prompted to agree to the permissions that an app requires. The Android operating system ensures apps cannot use permissions they have not requested, and the user is responsible for deciding if an app can be installed.


At first this worked well, as users could see what data an app could access. Unfortunately, however, developers found that very few users paid much attention to the permissions prompts, and it became more common for developers to use more and more permissions–presumably to either improve user experience or monetize their apps.

So What? Big Deal?

In light of this, today we have reached a point where a front-page featured game from the Play Store makes use of the following permissions:

  • retrieve running apps
  • find accounts on the device
  • precise location (GPS and network-based)
  • approximate location (network-based)
  • modify or delete the contents of your USB storage
  • test access to protected storage
  • view Wi-Fi connections
  • read phone status and identity
  • receive data from Internet
  • full network access
  • view network connections
  • prevent device from sleeping

All this for a game that lets you play some fantasy football? At this point, I must open up a few questions to the reader (feel free to discuss in the comments below): Is there any possible justification for about half of these permissions? Is it necessary for this app to see what other apps a user is using? Or to see what accounts the user has on his/her device? Or to access your exact location in the world using GPS? Or to read your IMEI number, and the phone number of someone you are on a phone call with?

This is not an isolated incident. It is just the first app I selected on the front page of the Play Store. Select another, and have a look for yourself! Because of the fact that the vast majority of apps are now making use of what I argue to be excessive permissions, a growing number of users feel it’s no longer enough to simply not use applications that use excessive permissions. That gives rise to a common request, which is for users to select which permissions an app can access. This returns the balance of power towards the user, whose phone is running the app, rather than the developer, who was previously free to dictate the permissions their app required to run.

The obvious solution for the tech community is to develop ways to have greater control over what apps are able to do, and to prevent them from using all of the permissions which they request. The three most common ways to revoke permissions are App Ops, Privacy Guard, and XPrivacy.

App Ops

The first way to get more control over your device is via a feature known as “App Ops.” This was originally introduced by Google in Android 4.3 as a hidden feature. With the release of KitKat, Google made it more difficult to access App Ops, but continued to introduce new improvements to the feature. Ultimately in Android 4.4.2, Google removed access to App Ops. However, it’s still possible to access with root and an Xposed modification or custom ROM.

The main limitation of App Ops is that, being made by Google, it only lets you block access to things that they are willing to let you block. Notably, App Ops doesn’t provide any ability to control whether an application should have access to the Internet. It’s also not possible to prevent apps from uniquely identifying your device, or you as a user, via your third party accounts. This means that an app can still tie together all of your account identities on your device and access your IMEI and other unique device identifiers with the appropriate permissions, and it’s not possible to prevent this using App Ops.

A cynic could argue that Google has a serious ulterior motive to prevent users from blocking apps from accessing the Internet. After all, Google has incentive to push their in-app advertising and gather information about users for Google Analytics. Likewise, Google is proficient at creating a profile of its users, which would explain why it’s not possible to block your identity from applications via your account names. The ability to access unique device identifiers only helps to allow other applications to track your usage (and thus allow Google to track your usage across applications).

For this reason, we believe that while App Ops is a lot better than nothing (you can control access to your contacts, messages, location, and so on), it is definitely not the best solution for protecting your privacy. There are a number of types of data that cannot be blocked, and it appears these may be related to Google’s motives in tracking and gathering data on its users. As such, we recommend you look at alternatives.

Privacy Guard

Privacy Guard is a feature originally developed by CyanogenMod to place a simple user interface over App Ops with a single “on/ off” toggle to control it. As such, Privacy Guard is subject to the same criticisms as App Ops in its limitations. It also imposes a notification at all times while running an application protected by Privacy Guard, supposedly to remind users that it is in operation.

Unfortunately, however, Privacy Guard makes no attempt to anonymize users or prevent apps from tracking their sessions via device identifiers or Internet access. With a single on-off control however, it’s certainly easy to use for beginners, and the default settings should be fairly good. The only downside is the lack of granularity, meaning that an app needing access to your location cannot be allowed that, while still blocking contacts and calendar access. Nonetheless, as a one-click solution, it works nicely. It does require the user to install a custom firmware though, which spoils the benefits of one-click appeal.


XPrivacy is the Swiss Army Knife of Android privacy protection. Compared to the other solutions we’ve looked at here, XPrivacy is much more customizable, but also much more complicated as a result. If you’re unfamiliar with Android permissions, XPrivacy is probably not the best place to start. It requires the Xposed framework, which means you also need a rooted device. However, XPrivacy should work on almost any ROM.

The main advantage of XPrivacy over alternatives is the sheer breadth and granularity of restrictions you can impose on apps. You can restrict an app to only be able to access and see certain accounts on your device, block access to your clipboard (to stop an app from accessing copied data), and even block access to the Internet, both directly, and via the web browser (to prevent any means of covert data exfiltration from your device). If there’s something you want to restrict, it’s almost guaranteed XPrivacy can restrict it.

Despite being a very powerful tool, there’s a large learning curve behind XPrivacy. I’d suggest reading through all the documentation on XDA Recognized Developer m66b’s Github repository (did I mention it’s fully open source?), and his thread on the XDA forums, for more information.

Overall, if you want absolute control over your private data, I’d recommend you check out XPrivacy. It takes a lot of getting used to, but it gives you unparalleled choice. If you are not quite as certain about what you’re doing, using App Ops will give you good control, albeit without the ability to control Internet access and data that identifies you as the user of the device. Both App Ops and XPrivacy are available on any ROM, via Xposed plugins. Privacy Guard is good for someone who simply wants a one-click solution, but the need to install a custom ROM to achieve it is a limitation in this regard, as you cannot (currently) find an implementation on stock firmwares.

About author


Developer Admin at xda-developers, interested in everything in mobile and security. A developer and engineer, who would re-write everything in C or Assembler if the time was there.

We are reader supported. External links may earn us a commission.