There is a lot of money to be made by selling our privacy so the business model of app developers often relies on harvesting your private data. Enter the world of app privacy controls….
We have all been there: installing a simple app (say a flashlight) which demands access to all our location, contacts and photos, wants to use the microphone and camera and insists on using the internet for itself while sending texts on our costs.
The even more sneaky apps install with a normal list of permissions, but on the first update extend this enormously.
Most users just say accept without even scrolling down the list, but some of us would like to control what an app can do on our phone. Happy to let the flashlight app control the camera flash, but why give it access to our contacts or location to resell these data to an unknown third party.
For a short period Android (4.2.2) offered exactly this possibility to control the permissions of apps. You could allow or deny individual permissions. If you went too far, the app stopped working, but in most cases you got the functionality you wanted without the intrusion on your privacy.
App Ops was brilliant and applauded by privacy organization EFF, but rapidly removed by Google. This control by users was not ‘ready for prime-time’ so there was hope it would return in Android 5.
Unfortunately it’s missing from today’s announcements. What we got in terms of privacy is default encryption (nice if you lose your phone) and so called SELinux which will help against malware and controls access on a system level but it’s not user controlled.
However Android 5 / Lollipop won’t protect you against the software you install yourself. Lots of apps are basically malware as they only exist to spy on you and sell your privacy, but you were the one who accepted the long list of ‘permissions’ so officially it was your choice to sell out.
Android 5 offers us a security lollipop while we need actual user control over apps. Disappointing that Google didn’t dare to break the business model of sneaky apps
What would be your choice: fine control with the slight risk that the installed app won’t work as expected or the current black and white model of ‘accept all’ versus ‘don’t install’?
#LolliPop #Android #Privacy #Tech
Great analysis. This is an important issue and we need to give Google a report card from time to time. I personally have very little apps on my smart phone because I check the permissions first and usually end up cancelling the install. But unfortunately most people don't care so we continue to give out the message that we don't care.
And because of that, I am annoyed that all these vendors have ghost accounts on me because my family and friends gave them my information.
The problem with the security model is that it is hard to code it.
When you need to use an API that you need which requires special permission, currently it is not easy to handle if someone does not give permission to it. Thats the flaw. Because applications can run on different version of android it just makes it messy.
The only way to solve this I think (going a bit technical here), is if Google for each of their permission methods to throw a custom Exception if a property is not set somewhere. This will mean that for newer API's you will need to import this new Exception package, which should not be too much effort…
But then to decouple all the code to handle this exception is going to be MESSY indeed, so the app don't fail. Not sure how to solve it in a program that is backwards compatible.
+Richard Tan Perfect, that is the answer. Now that wasn't so hard was it?
+Donald Farmer thanks, it is easier if you just target the newer version (API level) and only run it on that API only, but I don't know how to do it going back to say ICS… Unless you enforce it now so going forward if you target the latest API you will need to handle these exceptions.
+Richard Tan absolutely right and backward compatibility can't be achieved, but let the consumer make his own choice.
How hard would it be to make a switch just like we had for device encryption or ART/Dalvik.
I second +Max Huijgen comment.
Great post on a very important topic. There are many apps I would be interested in having, some are very popular… But I just can't – because I refuse to sell my friends no matter if they are on my pictures, in my Adressbook or on my GPS 😉
+Max Huijgen ART and Davik are the same thing. It is something to runs the apps. You basically need to rewrite the APIs which is the hard thing, then handle an exception.
This means you now got to think about programming for Android twice, one targeting the newer APIs and one targeting the old one…
But I do agree it is a mess but I don't know how it can be solved without causing pain to developers.
+Richard Tan I'm going to guess that the app writers aren't going to write their code to fail gracefully if I decline/restrict permissions to the features they want (regardless of whether they want them for legit app purposes or nefarious identity accumulation). I think that'll lead back to where we are now: If you want to allow the requested permissions load the app, otherwise don't.
/sub
+Scott GrantSmith Unfortunately we don't get to see the permissions until the app is in our phone and the installer has started to run. I am really worried about how many apps I have that never asked for permissions, ie google apps? Silent installs worry me. It implies google has a way to do that so it is only a pretext of permission.
+Richard Tan ART and Dalvik are indeed both app engines but until Android 5 there was a user switch to select one of them.
ART being the newer one (default in 5.0) but for some time likely to break app compatibility.
Summary: it was a user switch like I would have to have for 'App Control'
+Scott GrantSmith actually App Ops worked quite well. It didn't break most apps when you deprived them of some permissions.
So, for example, lets say the NSA is excited about their latest surveillance app and wants everyone to try it. Would we see a popup that says Install NSA app "I can hear everything you say" Yes? or Cancel?
+Donald Farmer you could do iOS style warnings. That is possible and also being backwards compatible. However you cannot fail properly if the user reject which is a bummer…
+Max Huijgen That doesn't mean that if it becomes a released feature that apps can't check for those blocks and react accordingly.
Of course, that's key to this whole issue of privacy versus commerce +Scott GrantSmith
Tons of apps would refuse to be installed if they could detect they didn't get full snooping rights on your system. Their whole business model would otherwise fail, but that's a win for consumers.
+Richard Tan Interesting. Guess Google doesn't want to encourage this behaviour.
+Max Huijgen It's only a win for those that pay attention. How is that different from what we have now?
I disagree, users aren't capable of making decisions on what permissions an app needs. Just look at some of the comments on the Play Store where users complain that an app needs permission to your microphone when it's a todo list. The fact that it can record audio is either ignored or goes straight over peoples heads.
What Google should do however is make developers state clearly what each permission is for and why the app needs it.
However, nothing will stop the rouge apps like the one used for the Snapgate leak.
sub/
Interestingly it's actually working on iOS. Very fine interactive control of which app gets to use what function. Retroactively configurable at any time without consequence. Whatsapp wants microfone access? Not anymore.
Imagine two flashlight apps: one (GeekyLight) needs access to your camera cause of the flash function, would like to know your location to make sure it doesn't go off while it's still light and your microphone because it has that nifty function of voice control which actually makes sense in the dark.
The other app (DarkLight) wants all of that ánd the kitchen sink.
Now you deny both apps some rights. What happens:
GeekyLight would happily install and provide you with the basic flashlight, but show a sad face as it can't show off properly.
Darklight would probably refuse to install. It was developed to harvest data of your phone and sell these to the higher bidder.
Both apps get reviews in the
AppPlay store. Who do you think would win out eventually if there was consumer choice?And if GeekyLight would start offering a small ad or ask for a 10 cent contribution, who would survive in the end? +Scott GrantSmith
I already lost 26 'followers' today so I didn't dare say iOS offers this +Jan Wildeboer 😉
+Max Huijgen let me take care of those. Dutchies unite 😉
Cyanogenmod offer this functionality to a certain extent.
So absolutely agree +Max Huijgen
So sadly true for US!
With Miui on Xiaomi you can install all apps you want. Then when you launch them, if they try to access your personal data (e.g. list of phone contacts) or use certain functions (e.g. send sms o take pictures) you are asked permission by the system. If you don't grant it you can still use the app while your privacy and freedom are preserved…
+Rohan Blake that link is four months old. Where are the user controlled privacy settings now?
(in effect, even in your link they were not user controlled so could well refer to SELinux)
Why do people always assume I'm with stupid? +Rohan Blake
Yip +al pistacchio very similar to the Android 4.2.2 App Ops and the later third party XPrivacy stuff (for which you needed root).
Which point did you miss +Rohan Blake 😉
+Rohan Blake Your link to 'L' 's features, is outdated, vague and most certainly refers to SELinux which is nice on a system level but doesn't offer anything for users wanting to control the apps they willingly install.
SELinux (indeed a feature of 5.0) which includes Universal Data Controls etc is excellent against apps which try to step outside of their user generated controls (malware), not against willingly installed apps.
Exactly. Probably Google is not ready to give you more freedom yet. Maybe they need a little help from the competition. Ubuntu on the phone for a start.
FUD. until L is actually released.
Also as far as privacy is concerned two interesting projects are getting quite a success on kickstartes these days: kck.st/1sTLWb6 and kck.st/1DdvSUo (competitor of chromecast)
+Shane Menshik The developer preview has been available for months. I'll eat my hat if they add granular permission control between now and tomorrow without ever even warning developers….
+Max Huijgen you mean before another preview tomorrow that isn't the official release?
App Ops wasn't remotely a solution. I don't know how well it worked from a user perspective, but it's a non-starter based exactly on what it does to existing apps.
There isn't a way to gracefully check most permissions other than using an API that needs them, which you can't really account for. You see it in debugging, and request the permission.
This is a flaw in how permissions were implemented perhaps, but allowing something like App Ops is terrible for legit developers, never-mind those that aren't. (I'm not sure why G left it in 4.2, but I'm glad they pulled it)
The effect when an app encounters this is a Force Close…..always. You don't introduce something that causes that at the OS level, no matter how "rare" from a user perspective it may be.
So, yes, it would have to be announced way before. (like with the Preview) to allow for maybe, Devs to deal with.
Or maybe G has some way to fix it I can't think of, but it's probably not in this release, and I don't expect it anytime soon.
+Richard Tan another way around this could be to do what xprivacy (root only app) does. If an app wants access to my contacts, I am presented with a request for that permission. If I choose to deny that access, that app gets an empty contact list (instead of denying that access entirely). The app thinks there are zero contacts in my address book, and doesn't crash.
No, I am not the developer of xprivacy and have no affiliation with him. Just a happy user.
+Joseph John That's an interesting way to do it, which works for contacts, and may a few others.
Which leads to there being creative ways around it as it is. I'm not sure there always are, or could be for them all.
(*- I've never developed anything that needs contacts. I don't actually know how well that works)
+Nate Behary that app is actually pretty neat. If an app needs your location, and you deny that permission, it is fed a fake location of your choice. App wants your MAC ID? App wants your device ID? Wants your recent call history? Etc… Just send it fake data (which can be randomized on boot). No crash.
Hopefully, xprivacy will work on Android 5 too
+Joseph John It sounds so. Technically, that's a malicious app, but implementing that in Android itself wouldn't be.
There's a case to be made for apps that really need accuracy, and how they'd behave, but it is better than a Force Close. (but still possibly unintended behavior, which is a support problem being forced on developers still)
Don't get me wrong, I'd love this. But the logistics can be a nightmare in any implementation.
As an example, that really is a problem, my one app requires Internet access (well, the Key app for a full purchase does)
If it is fed garbage, the check will fail and the extra features the user paid for won't work.
(now, just about no one buys it, and I know them all, but, in a different case……)
So if a flashlight app asks for all these permissions, why would you want to use it even if you could reject the permissions it wants? Clearly, the author is either trying to do something sneaky or is totally incompetent, and in neither case do I want their code running on my phone. Just say no and move on to another app.
I would like to have optional permissions for things where the app would like to do something for additional functionality, but could operate without it (for example ability to make calls so I can click on numbers, and just disable that functionality if I say no), but I think that is a different matter from what you are requesting.
+Joseph John +Nate Behary That's pretty much how Cyanogen does it, but without much options. An app that is flagged for integrity protection will only get an empty contact list etc. You can even deny the address book app itself access to your contacts.
I can see no reason why at least this basic integrity protection should be available in Android by default. I may want to use Skype, but not let it read my contacts, dial history or disk content. With Cyanogen I can. This is not a technical problem.
+Per Siden No, it's not technical, strictly.
The thing about how publishing an App is, you declare permissions, which the user needs to accept at install.
So, you can assume they are there. There are definitely situations where denying a permission on the fly can break apps. That violates the terms under which Google allowed the app to be published, as things are.
There isn't an easy solution to that. Not without a huge change that has to effect already published apps in ways that need to be addressed.
(so, it's not happening in Lollipop, and isn't "easy" at all)
And, this is true for good and bad apps. (most aren't bad)
+Nate Behary as a developer I have no problem seeing things from app publisher's point of view. But as developers we have failed to address customer's concern.
Threema have an interesting approach. The basic app require hardly any permissions at all, but for more functionality you download additional plugins that do. That way users can choose.
Until the situation overall improves we need to take some measures. An "API firewall" is a great tool.
Play store ought to brand all apps that out of laziness or whatever other reason require permission to API:s they reasonably don't need as malware and warn users from downloading them, just the way Google search does with malicious web pages.
+Per Siden I'd argue that any reputable developer is being very careful about what they are doing. And if there could be a privacy concern, have a privacy policy published…
Detecting API usage as Malware is hard. (very…….)
But, warning users by API's requested of publishers that don't have a Privacy Policy link isn't maybe. That would help. (though, wouldn't stop bad apps from having one that says "nothing")
+Joseph John good idea, good idea to get around the contacts. Now need to figure out work around for the other permissions 😊
+Nate Behary yes, that's about what I had in mind. No privacy policy and/or nothing in the description that matches one or more of the required APIs and the app gets a "red flag". This can at least in part be automated. Add at least a rudimentary analysis of the app and a sandbox test if sorts, and we're a lot better off already.
More restricted versions of APIs could be a good move too. My app needs access to the contact book in order to search the address by name of a person, but I don't want to have full access. I don't need all the data that's in there, I don't need browsing, write permission and so on, just a simple address search, limited by searching with at least three letters and only when there is a unique result. A "restricted" contact book API like that would have been enough for my app and hopefully more acceptable to users.
A address book setting for what categories to expose to apps other than the contact book app itself may also be useful.
This culture of invasion must be stopped.
These violations of your personal privacy will continue, until phone manufacturers are sued in a court of law.
Perhaps a public list of developers and publishers with dubious privacy practices could help.
Sigh.. its as if the author never heard of all the android apps available.. that do EXACTLY this, and have been out.. for years….
+Max Huijgen what +Rohan Blake is pointing out is that this is probably the first step, this article from 2013 points out that SELinux can be considered as the laying the groundwork for more finely tuned user permission controls. also Apps opps didn't work as great as many people claim it did and broke many apps and that's why it had to be removed. http://pocketnow.com/2013/12/17/app-ops . I agree with you it is curious that Google chose not to highlight if more granular user permissions are coming but I'll wait until the final release because things can change. Anyway someone asked
As an example I remember when the early builds of iOS 8 was released people were praising Apple's stance on privacy with MAC address spoofing, what we finally got the final release however what we got was much less than was promised http://www.theverge.com/2014/9/26/6849291/ios-8s-location-tracking-protections-arent-as-powerful-as-predicted
+John A. Tamplin Re: Flashlight app asking for unreasonable permissions – why use it: Consider the Verizon FiOS mobile app – I have their TV service, but do not have their wireless phone (or regular phone) service. Their mobile app gives me the ability to stream TV channels to my phone when I'm away.
But for some reason, it wants my call logs too. I suspect the reason it asks for that is because folks who use their landline and their cellphone sevice can get a merged call history. I don't, and I don't want them to have access to my call logs. But I do want their streaming service.
This is one example of an app that is useful, but wants excessive permissions.
+Richard Tan See my earlier posts – XPrivacy does seem to have a workaround for most permissions (I hate to be sounding like an advertisement for that app – but that is the only app that I've found that seems to do most of the things that I wanted from a permissions management framework.
+Noel Beale I'm fully aware of third party apps which try to solve this, but afaik they all require root control. That's not a solution for the billion or so Android users.
+Marlon Thompson Again, if granular permission control would be in 5.0 it would have been announced and be in the developer preview.
I agree with +Max Huijgen here, that there are third party tools and alternatives such as +CyanogenMod out there that try to address these integrity issues is not enough. The default mode of operation must be changed so that the worst case situation is improved. Why should people who doesn't know how to use these alternatives, or even know about them, be left adrift and vulnerable? Android is used by everyone now, not just the tech savvy youth.
+Rohan Blake I gave up trying to explain as I said lets wait until the final build.
We are missing the real problem here, the weakest link in the chain is not Google, is not the OEM, and is not the developer with excesive permissions, the weakest link is the USER.
It's ok to demand more options for the SO we use every day, but tell me, if you find an app with too much permissions did you contact the developer??
It's easy to demand things to the big corporations, but the real ones with the power are us.
Why Facebook demands so much, 'cause we accept it that way, and the same goes for every app.
Final SDK is tomorrow +Marlon Thompson
Then i'll wait until tomorrow, +Max Huijgen here is the thing I am not a developer, never claimed to be. So I have to read other people's analysis. But from what I have read, what you are calling for may not be as hard to implement as you are making it out to be and trust me by the weekend reputable sites and developers will ask the questions about these user privacy controls. As I had mentioned in my first response many people saw the Mac Address spoofing feature of iOS8 and praised Apple (including you) on that particular post I said I wanted to wait and see the final version and see what analyst say. As I pointed out it wasn't as great as it was initially made out to be, so now that we have all the information we can push Apple to do better, I want to have all the info from Google so I can push them to do the same. And to answer your question posed in the post I son't mind the present model of accepting all permissions but the again I am careful of the apps I install.
+Nate Behary App Ops worked brilliantly if you knew how to use it. I think that is part of why it got yanked. If you blocked the permissions that were not need for an app to function there was no force close of the app. You had to know what the app did and what it needed to run. Some people just had no clue and blocked everything willy nilly.
They way that +Cyanogen Inc. handles it in their Privacy Guard is returning an empty set if the given permission is denied.
If an app requests a contact list, and you've got it disabled in PG, the app gets an empty list. No list would likely crash the app, but getting an empty list likely won't.
Same for location, sending texts, whatever.
I do wish this was standard in all OSes. Mobile and desktop.
I stay away from android. No privacy in anything related to Google. I don't even have any personal info in Google plus.
+Rohan Blake what do you mean, we can't discuss this until we know for certain if it's in the final build or not?
I think there are many aspects of this apart from Google and the next release of Android. Play Store serve also older versions of Android, and will continue to do so for quite some time yet. Making users more aware if the implications of their choices is important as well, how can we reach them? What can app developers that are interesting in developing robust apps that honor and respect user's integrity do better? There are plenty of things to ponder.
I hope you are right, and that some sort of API firewall will indeed be included in version L. But how good will it be? And what more can we do?
+Don Dudas App Ops worked brilliantly if you knew how to use it.
That's great, but the people who don't who throw up 1 star reviews because an app doesn't work because of something external to it without understanding that is an issue. (I see that happening, look at the morons complaining about lack of ART support on KK)
A solution needs to be completely seamless to work well. App Ops, or returning empty data isn't that in every case.
+Nate Behary the only way would be for Google to institute a review board for apps and approve their permissions. That's not going to happen anytime soon….
Only solution, run open source applications on devices
As a reference this is what +Sundar Pichai actually said about "user data controls" Google I/O 2014 – Keynote
"With L release, for the first time, we have a centralized setting, what we call 'universal data controls', where users can go and manage their important privacy protections"
From going through the 5.0 SDK it doesn't seem that Google is supporting AppOps/User Data controls +Anchi chan
Your request to test it on a Nexus image (LPX13D) might get more response in this topic https://plus.google.com/u/3/112352920206354603958/posts/2LSmQy8VCjk
Thank you for bringing some attention to the issue of the Universal Data Controls. It appears that I'm in the minority, but the lack of control over app permissions appears to me to be a major shortcoming of the Android operating system particularly in light of the sensitive information kept on many people's phones. I am an attorney and have to ensure that client data is kept private.
I have always preferred Android over the alternatives for my cell phones and tablets over the past six years, relying on root and apps like Permissions Denied or XPrivacy as a work-around. However, it appears that XPrivacy may no longer be an option on Lollipop given the switch to ART.
Are you (or anyone else) aware of whether Google will be implementing Data Controls? I haven't had access to any of the dev preview builds because they haven't been released for the LTE Nexus 7.
I pre-ordered a Note 4 from Verizon and am actually considering cancelling it and moving over to an iPhone 6+, which I would really prefer not to do.
+Anchi chan I actually hadn't noticed your report; thank you for pointing it out. I had previously searched and found a recent report that another user had posted regarding the absence of Universal Data Controls in the L preview builds but his report was declined. That your report has been accepted gives some hope.
This man should be hung…..
Install "Noroot Firewall", lock'em down. Or don't install any Stasi apps.
Definitely I would prefer f ine control with the slight risk that the installed app won't work as expected.
It's a shame !
Could someone bring this to court, google is encouraging data theft ?
Funny how some developers complain that it’s so difficult to deal with a permissions manager, even suggesting consumers won’t need it since most apps have no bad intentions anyway.
As a consumer I’ll decide whether or not I feel a permissions manager is necessary. And guess what, I think it is!
Most people coming to my door are not burglars, but I prefer to have a lock on my door nevertheless.
IOS does provide a permissions manager and apparently IOS developers can deal with that.
Apparently most Android apps are built ‘assuming’ that they have all the permissions announced in the Play store.
So the app may quite likely crash when such permission is denied during run time.
Well, I guess these apps have to be built again without that assumption.
Each time the app calls an API, the reply should contain either the requested information, or a ‘permission denied’ message.
The app should be able to deal with that, without crashing.
Blaming the consumer for accepting all kinds of permissions is kind of condemning them to have them endlessly search for alternatives in the Play store which actually might have the limited set of permissions they feel acceptable.
If such an alternative is there at all, it’s quite likely that after a while an update “requires” additional permissions after all.
At this time there I have a significant list of apps to be updated which I refuse to do, which is annoying because each time when I “update all”, I need to skip them.
For many consumers the solution is simple: bye Android, hello IOS.
I thought lollipop would be released on the third of november together with the nexus 6? Wrong?
http://bgr.com/2014/11/04/android-5-0-lollipop-aosp/ its coming slowly but
surely
On Tue Nov 04 2014 at 10:15:41 AM Google+ (Max Huijgen) <
****@**> wrote:
No mention of universal data control settings or anything remotely similar in the just released final 5.0 documentation.
Maybe we are expecting too much from a company whose primary focus is advertising.
Sure, but they promised ….
nooooooo! Atleast that app works on new version of android.. seem to be pressing that no button a lot
+Michael Peart
By now we can safely conclude that Google didn't live up to the promise of control over privacy settings in Android 5.0
Just uploaded "Lollipop" and bugger me it's destroyed my Nexus 7 ! Slow , Unresponsive, Snails pace ! That's not me it's me Tablet ..
What is clearly missing is a way to evaluate those requests and contrast them with the needs of the app to function. Basically a privacy grade. If I had a way to easily evaluate which requests were valid and necessary and which were clearly overreach, I would use it.
I am betting others would too. It would also help me make a cleaner decision among 34+ flashlight apps I get confronted with when looking for one.
I understand that devs need to make money. There are systems in place to allow that. They do not need to know where I live and work, and sell that to people I am not OK with.
We need a middle ground here.
Hint: if you don't like the permissions of your flashlight app, find another. If enough people want it, it'll get made, I promise.
The flashlight point is anyway moot as Android 5.0 has it built in 😉 +Joe Betsill but imagine another app.
+Max Huijgen I only used flashlight to keep with the example given. It applies to every app.
It won't be made +Joe Betsill as there is no way to feedback objection to overstretching rights. And the biz model of most app developers is based on your privacy.
+Max Huijgen A plethora of 1 star reviews that say "Why do you need access to my contacts, you're a fast app" is exactly the feedback you are talking about.
I highly doubt Google is going to risk confusing people who mess around with app permissions and break an app. It's not Google's job to let users break apps. Privacy is something that should be demanded by customers from developers.
You doubt it, but +Sundar Pichai, the most influential man at Google after the two founders promised it.
See http://9to5google.files.wordpress.com/2014/06/screen-shot-2014-06-25-at-11-57-01-am.png?w=704&h=385
+Joe Betsill You are correct that consumers/customers should demand that privacy, but considering how few people readily comprehend the problem in the real world, you'd be holding your breath a mighty long time hoping for app developers to adapt to that standard of privacy.
Google could implement this at a higher level – just as you enable Dev mode with a couple of well placed taps, why couldn't you enable a global privacy module in the same way.
Those who care to tinker, can, those who are oblivious to it, would remain so until they realize the cost or were better informed?
Perhaps we just need more mainstream reporting of the data that apps can generate to really wake the public up to the need for privacy?
Universal Data Control doesn't mean app permission control. So he didn't promised what you're asking for
+Daniel Roca please point us to some released docs that explain what Universal Data Control is, then. Google was very vauge about how it would work when they announced it and as of October had still not defined it. It doesn't exist in any form in Lollipop, so where does your intel come from? https://code.google.com/p/android-developer-preview/issues/detail?id=1526
+Max Huijgen , +Mike Hamm I can see that Google's not implementing it (for now, until the Dev 'market' has adapted), for one that most people do not know the rather fine-grained differences, which will crash a lot of apps, which will make people even more upset, believing "Google is at fault" (which it's not), which in turn will make Developers 'go away' who want to earn money, after all your personal information (like your address-book) are like gold nuggets in all this sand out there.
I can also see that OEMs and Carriers have major issues with such privacy control system, take Samsung and its shovelware-ridden smartphones for example. Which will hurt the Android ecosystem.
Bottomline it's always up to the Consumer what and how he uses/installs/purchase.
Go ask a teenie-bopper if he cares that his beloved freebie messenger or candy-crush saga game is grabbing the teenies data.
+David Kirby Lollipop on my Nexus7 made me switch tot Cyanogenmod. Runs smooth and a lot faster.
Where can you download cyanogenmod, does it work well ?
+Gordan Vosicki You can find downloads at http://cyanogenmod.org They also provide a list of supported devices and installation instructions. On my Nexus 7 (2012) it works like a charm.
+Dirk Jan van der Wal Thank you..How can I switch ? Step by step guide ? Thank you
Using +CyanogenMod on my Samsung S3. No bloatware, runs great, gets updated monthly.
I probably will have to use a non-stock rom on my Samsung Galaxy Tab Pro 12.2" anyway, if I want to run Android 5, so I can just as well root it then, and use the Xposed framework for better permissions control.
Has Xposed been ported to 5? +Filip H.F. Slagter
When I found out about app ops I was pretty excited, but if I recall correctly, there was no way to get to it with out the aid of another app, such as Nova Launcher. Ever since I got my HTC One, I've been running Android Ice Cold Project on it. Within the settings, I can setup a hot spot (USB, BT, or WiFi), tweak the kernel, and access App Ops.
Good point +Max Huijgen, and it looks like that will likely take quite some time, if at all:
° http://www.androidtipsandhacks.com/root/xposed-framework-might-not-arrive-on-android-lollipop-for-months-if-at-all/
° http://forum.xda-developers.com/xposed/framework-xposed-rom-modding-modifying-t1574401/post49979752#post49979752
° http://forum.xda-developers.com/xposed/xposed-faq-issues-t2735540
Yip +Filip H.F. Slagter that was my concern. I'm not sure if I will upgrade to 5.0 unless there is a workable solution for rights control
+Max Huijgen Sir i am using MIUI and it has all the app permission controls built in. Do u have any experience of the reliability of MIUI permission manager ? It does seem to work
On Android 5? +Joseph Anton
No sir android 4.3
Yip, that's the problem…
+David Kirby You van find instructions on cyanogenmod.org. wiki pages.
+Dirk Jan van der Wal Thank you ..
+Dirk Jan van der Wal Put in cyanogen app and so far my Nexus 7 is running a lot faster ..Thank you ..
+David Kirby You're welcome.
You can enable App Ops on rooted device with this app https://play.google.com/store/apps/details?id=droidmate.appopsinstaller
+Sundar Pichai
+Max Huijgen Google simply does not really care about our privacy, this is the proof 🙁
with android 5 there is not any difference between any other smartphone operating systems on how much control owners have on their device .if there is not control on the installed software , there is not any reason to use a linux based phone . it is the same phone with a iphone and a windows phone where owner of the phone owns nothing on his phone !
there is not any difference if you baited from a bear or from a lion . the result for us is the same and if we add the risk that owners have using UN-controlled free or payed apps from play.google only fools will continue supporting android team .
don't buy their phones and they ( manufactures and google ) will forced to give to owners some basic rights on the software .
fight with your wallet and win . your old phone is just fine to do what made it for … calls !
p.s. i didn't say anything about the no close apps …. seriously it is not funny to see your browsers never close when you are testing new mobile sites and all are running in memory destroying the battery life in a half hour !
+Richard J Fox yes, Google Android team is VERY arrogant now. They are so arrogant they don't allow us even restart an Android phone or Android Wear. Thx God I have a Samsung Android phone.