Sort of-- there are a few differences between Android's runtime permission model and LineageOS (formerly CyanogenMod's) privacy settings... https://developer.a

Sort of-- there are a few differences between Android's runtime permission model and LineageOS (formerly CyanogenMod's) privacy settings... https://developer.android.com/training/permissions/requesting.html https://developer.android.com/training/permissions/requestin... So as you may know, in the old pre-6.0 Android model (that is, any app targetting pre 6.0 Android) you are presented with the option to approve a list of all the permissions "up front" when you install the app from the play store. All-or-nothing. If you say no, the app won't install. There is no opportunity for the app really to explain why it needed the permissions, and some like "read phone state" were kind of confusing. On the new 6.0+ runtime model, permissions are combined into groups-- normal and "dangerous" -- normal includes things like Internet access which all apps have always-- needed to show ads-- and you can't block. "Dangerous" is the category type you'll be asked about. So in this new runtime model, the app is always installed without prompting the user at all about permissions. Then when the app is actually running, before the app can do anything requiring permissions, it must ask the user explicitly to accept the permission it needs via a popup UI. This gives the developer an opportunity to ask "in context". So like, if an app has a button to record some audio, it can ask you only when you press it, and then the user will go "oh, I just told it to record audio, so this makes sense". If the user declines, it's up to the app to decide what to do next-- it can offer a rationale ("The app NEEDS this permission to record sound!!") then ask again, but the 2nd time the user can say "remember my choice", and the app can do anything from disable the feature to shut down completely. Because the UI is in the hands of the developer, they can ask for them individually "in context", or maybe all up front... and figure out how to handle the case where the user says "no>'. LineageOS/CM's privacy guard, which predates Google's runtime model, works slightly differently in that (1) the permissions available to be turned on/off are different/more fine-grained than Google's permission groups... (like you can turn off fine vs course location access) but is (2) similar to the Android runtime permission model in that the user is asked "on-the fly". But with Privacy Guard, this is done automatically by the OS when a permission-needing feature is being used, not by the app developer's at their discretion. This means if Privacy Guard is turned on by default, the UI will pop up whether the developer likes it or not, when the permission is needed. In fact, (3) the app often won't know it's even been denied permissions because, (and I think this is still true), (4) if the user says "no" to a permission, the app may just be handed empty data sets (ie, a list of zero contacts or some bogus spoofed location data) rather than an outright permissions exception as with Google's method. Another huge difference is that the privacy settings stuff is available on Android much older than 6.0. Like google's permission settings, LineageOS' privacy guard settings can be changed from the settings on a per-app basis. Both let you retroactively pull permissions even on pre-6.0 apps, though expect some occassional crashes, especially with the runtime permission model. Privacy Guard also offers a count of how many times permissions were accessed, when the most recent was, and even shows a notification when an app has been blocked. The best thing is that both the runtime permissions model and privacy guard can be used at the same time.