This is probably completely off-topic, but could this be used to create the ability to deny permissions to applications? As a privacy-sensitive person, I would like to prevent some applications from receiving certain permissions, while still using them (for example, why should a game have access to my contacts?), but Android doesn't provide that functionality.
Would this be possible/viable with this framework? I might give it a shot, if so.
Not answering your question, but applications for Android are generally written with the assumption that they have whatever permissions they requested at install time, and may behave unpredictably if calls to things that are supposed to have already been authorized raise exceptions. I would expect that if you managed to do this, lots of applications would crash.
I'm pretty sure you could fake most permissions convincingly. After all, how is an app to know that that empty contact list or those GPS coordinates on the top of mount Everest aren't actually real?
There's been a few mods out on xda for at least a year or two that let you fake most permissions per app so the app would think it was getting legit data and not just blindly crash if it was denied the data totally. I think one was built into MIUI and could also be used standalone. The other one I can't recall the name, but if I think of it I will edit my post in a bit. Both had their source out though so you could mod them.
Cyanogenmod 7 tried to totally deny permissions for apps and it was not a good idea. It resulted in apps crashing a lot. Also the reason they didn't continue to do it in Cyanogenmod 9 and 10. Faking permissions is definitely the way to go though.
Pdroid is fantastic. I waste time patching my ROM every time I need to upgrade with that tool. The amount of information you can disable or manipulate to hand to app providers is amazing.
I think Android would have much better cred in the geek community if this was standard, but the legal and business hoops it jumps around and out of make it a pipe dream. I will say when I meet Infosec guys in my area and show them that app, even the iPhone guys are impressed and want to know how to get it if they got Android phones.
Stock as in a Nexus device or stock as in some other OEM skinned device? You shouldn't have problems applying either if you're using stock vanilla AOSP and rooted. OEM skins (touchwiz/sense/etc) though are another thing since you don't have any source code to work off of without modding or using something like Cyanogenmod and they tend to mod a lot of the framework base. Pdroid's patches were to the framework_base part of the Android source from what I recall working with it before. Modding the Android source isn't too bad if you import it into Intellij IDEA or Eclipse though. If you have some questions about where to start, feel free contact me.
Nexus device, yep. I didn't know takju was AOSP, I thought AOSP is sort of the "base". I'll try to set up OpenPDroid (I think PDroid doesn't work with ICS), thank you!
Yeah, pdroid as in its Android 2.3 form is wont work. Before OpenPdroid, I had to manually merge changes into the ASOP source by hand and do a little tweaking. You should be all good with takju. I have a Verizon Galaxy Nexus (toro) and build AOSP fine with that.
All the proprietary binaries are on Google's site[1] for Nexus devices or can be pulled from your device under /vendor/ (in the past, google sometimes failed to put up a few like the camera or bluetooth so had to get those via your device or a trusted repository). Alternatively, you can pull them from a repository maintained by a some of the more well known Android ROM modders using the directions I put up here (https://github.com/yareally/android_proprietary_files). Also you'll have to get a google apps package (or alternatively build it yourself) if you compile AOSP since you won't have access to the Android Market and such otherwise (stock AOSP resembles what you get in the emulator). A premade google apps package I would trust (and use myself when I don't want to build my own) can be located on goo.im[2]. They'll say Cyanogenmod, but they'll work for stock AOSP just the same.
Oh hum, so, from what I understand, I need to use AutoPatcher(?) to patch my stock ROM and install that. Doesn't that mean that all my data will be wiped?
This sounds like a huge hassle to install a privacy manager, I'd be okay with installing a small patch, but wiping my phone quickly ventures into "not worth it" territory :/
You can back up your data first before unlocking your bootloader and such (https://play.google.com/store/apps/details?id=com.koushikdut...). Works without even being rooted since it's a wrapper around the built in backup Android implemented since Android 4.0.
After that, you unlock via running a simple command which will let you flash your own compiled rom (alternative, you can unlock and then root and patch as you mentioned after unlocking the bootloader, but unlocking is the first step for either solution).
After backing up, run from your pc command line (you need the android sdk platform-tools first):
fastboot oem unlock
↑ that will wipe all your data and put it back in the state you got it initially, so make sure to back up first. More info on that can be found in the link below ↓
Thanks for that. I've already unlocked the bootloader (back when I got it), I was referring to needing to wipe everything when installing the ROM (I'm rooted, too).
I don't want to take up more of your time, though, I'll just download the stock rom and try to AutoPatch it and see if that works. Thank you very much for your help!
Np, I don't think that patch should require you to do much and the stock ROM shoudn't really be any different (if we're talking about the Android Factory Images[1]) than what you have right now so the patch should work without flashing any ROM. If you're going to flash and wipe everything by flashing it (and you're already stock Android), then might as well try the patch first before flashing the stock ROM.
Oh if you're rooted, then just use titanium backup if you want to be safe :). Good luck.
Very true. Personally, I wish there were a way for apps to specify optional permissions (ones an app can run without, but might require for specific features) as an alternative to required ones.
To take a simple example, I've noticed that many third-party launchers request the "Services that can cost you money" permission, so that they can create dialing shortcuts, I believe. I'd prefer not to give them that permission because I don't want dialing shortcuts, but I'm sure other people do.
Yes, you could hook the permission checking methods and deny them. I think there are packages that do this already (or don't throw the Permission exception but instead return an empty contact list, etc).
just to add what the other commenters in thread said. Open pdroid is now the project you want to look at. Its open source but needs to be compile with the rom. Depending on your phone or if you know how to build a rom then its great if you want to fake permission data. http://www.xda-developers.com/android/openpdroid-brings-an-o...
The other alternative mentioned is lbe. The issue with lbe is that its a Chinese app thats translated to english and only distributed through xda found here. http://forum.xda-developers.com/showthread.php?t=1422479 . Now everything I've read and what others have looked into is that nothing malicious is occurring but of course YMMV. I've used it and I have very rarely found any issues blocking all permissions.
Also another good app is droidwall to enable data for apps based on wifi or mobile.
EDIT 2: It seems that the only "good/working" app is PDroid (and OpenPDroid for ICS). Unfortunately, it's only available for custom ROMs, and it's a lot of work to add it to stock ROMs. It looks like that this will either need a lot of hard work to do (and be hard to install), or Android will need to do it natively. Too bad neither option is very feasible...
Xposed has allowed me to iterate much more rapidly on framework tweaks, and also keep them much cleaner (since now I just have the "hooks" instead of directly changing Android framework). Also, I can run on more devices because I don't have to replace some framework JAR which the vendor tweaked substantially.
> That said, at some level the libraries are fairly similar: the core mechanism by which a method is hooked in Xposed (swapping it out for a JNI implementation) is actually the same one that I described in the talk I gave on Substrate at a conference called Android Open in 2011. The result is that there are some similarities in the functionality offered by the two frameworks.
> Thankfully, Substrate's injection mechanism does not conflict with the one used by Xposed: therefore, if users or developers would like to have both frameworks installed, that is actually possible. There are some places where the two libraries "disagree" (such as Xposed totally removing the Java security model that Substrate preserves), but the resulting behavior is harmless.
Upon further reading, I noticed the true purpose of this seemingly allows apps to extend outside their sandbox and violate the intent model in terms of how they interact.
Not sure why this is a GOOD idea though...
----- original:
As someone with a rooted galaxy nexus on cm10.1, why is this of interest to me?
I understood that cydia was an app store alternative that only could exist on rooted/jailbroken iOS. Android has no such restrictions about app stores; what value does this actually add?
This is based on reading every word of the linked to page...
> WinterBoard is a "theme engine" that allows you to use the numerous themes you may find in the Google Play Store on your device without having to install custom ROMs or use custom launchers. It allows you to use almost any launcher icon theme with your stock launcher and supports "Theme Chooser" themes without CyanogenMod.
Winterboard is for customizing graphics with more flexibility; it's not messing with how apps work.
You could also imagine people developing a collection of Substrate extensions that each implement a specific launcher customization, so that you can build up your desired set of customizations one-by-one instead of trying to choose between several launchers that each have parts of what you want.
There's nothing wrong with hacks. There's nothing wrong with runtime patching. If you know what you're doing, then you know why you shouldn't do it, and thus you're well equipped to do it anyway.
There IS something wrong with bundling up hacks and runtime patches into a simple user-friendly installer that leads users to believe that they will work and are safe. When the hacks fail (and they will), it happens in ways that leave users confused, frustrated, and blaming us -- the developers of the applications that your hacks crash.
Bug reports from people who use Mobile Substrate are a massive waste of time and user goodwill. They pollute our crash reporting system, they make users think our software is broken, and they result in bad reviews in the app store.
You've just made life more ugly for every ISV that supports Android -- and our users -- after doing the same to us on iOS for years.
He's not just referring to a jailbroken phone. From what I gather, the main purpose of Substrate is to allow apps to monkey patch functionality in other apps. I can see how this could be frustrating if users report issues that are actually caused by another app "hacking" the reported app.
The primary purpose of jailbreaking your phone is to run tweaks that use MobileSubstrate. I think Saurik himself has said Cydia only contains a handful of "apps" everything else is a tweak.
Unless the author has written an app badly in need of a tweak specifically targeting it, I doubt it's being patched directly.
Would this be possible/viable with this framework? I might give it a shot, if so.