yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] FFU5y:
The only way to really ensure this is to have a 'kill switch' for PDroid to fully disable it: It isn't ideal to require the user to 'kill' PDroid in order to be definitely, certainly be able to make an emergency call but I don't really see any way around it. It would require an additional user action, which is not the optimal scenario, but there would always need to be some extra action in order to make sure that call, and not others, goes through.

I agree with TonyP on this one: even though it could invite more attack because of the possibility some people could have default allow, since the actual in response to such attacks would be 'deny' for those users who have set 'default deny' then I don't think there is an actual increased risk of data exposure.

The interesting thing here is that the 'development' line has now incorporated default-deny behaviour, so I (or someone) must now implement some way of defining a default behaviour - otherwise it will simply switch to default-deny when the dev code become 'release' and it sounds like that is somewhat of a problem for some users (and a boon for others). I agree usability issues are a high priority, and indeed the slow-down was the highest priority, but this will need attention reasonably urgently.

CollegeDev: if you have any thought on this, I'd certainly be interested - i.e. having a file on the file system which defines the default 'on error' behaviour, as well as being able to actually 'disable' PDroid entirely, basically for emergencies. The risk, of course, being that an app with root access could potentially access/change it unless it incorporated digital signatures etc.
[Android Software/Hacking General [Developers Only]] wbedard:
An additional idea to keep in mind is that, while all this discussion about emergency phone calls only applies to phones, there are a growing number of Android devices (let's see...tablets, TV's, set-top boxes, etc) that can't make emergency calls (although VOIP is still an option...) but still have access to all that sensitive privacy info.

FFU5y explained earlier (I don't recall where...) that PDroid enforces it's privacy policy in a couple of ways. One is focused on the core framework and the other is focused on modifications to a few native Java apps...MMS for one. When people were having problems with the PDroid-enabled MMS app, a solution was to simply flash over a stock app which would (I believe) simply disregard the rest of PDroid since it can make "native" calls (I'm probably screwing up some of the technical detail here...).

I wonder if a simple solution to supporting both camps of PDroid users could involve focusing on the Phone app itself. Although it is not an app modified by PDroid, I wonder if some creative mods could be made to allow the "emergency override" some people are passionate about while still allowing a very secure underlying framework to protect everything else.

R/

wbedard
[Android Software/Hacking General [Developers Only]] tonyp:
I don't quite get what you mean here.

In your second sentence you're writing to have a "default allow" action.

But in your first sentence you're saying you can't ensure it? Wouldn't default-allowing ensure emergency calls?

I'm totally fine with allowing all apps to default-allow as long as I won't get locked-out from making calls.

If you can choose between default-allow and default-deny it's everyones own decision.

People like Lanchon can have the call lockout, I can have the privacy-leak-default-allowing.

(Oh and I would bet some serious amount of money that both of us will never run into a default-allow or default-deny scenario anyways. This is merely a ethical/philosophical question).

Maybe I shouldn't always talk about emergency calls here - as I include the possibility of making "important" calls to others (and not only to emergency services) here as well.

And I probably should even include sending SMS here. So it's not just the phone app. It's just the default-allow vs. default-deny approach.

Edit: Something just came to my mind:

If I'm a kidnapper and the victim gets hold of my phone I would consider PDroid overriding my default-deny to allow emergency-calls a privacy-leak as well :cyclops:
[Android Software/Hacking General [Developers Only]] wbedard:
Nice scenario...I admire your keeping an open mind! :eek:

R/

wbedard
[Android Software/Hacking General [Developers Only]] FFU5y:
Cool, the reason that didn't make sense is because my starting point of thought was 'emergency calls should always, always be allowed' (my earlier statement) which to me equated to '000, 911, 112 etc should be let through irrespective of any PDroid settings, at any time'. Thus, when you were talking about 'emergency calls' being calls to anyone, then I immediately jumped to 'there needs to be a switch to make it possible to make calls to anyone immediately from any program' - thus the 'kill switch'. I wasn't referring to just error conditions, but a total override.

What you were talking about, I think, was "a broken PDroid service shouldn't stop me making phone calls" which relates to the "default allow" option. I was thinking "I should always be able to call emergency numbers" which relates to "a complete override of PDroid"

Anyway, I think having an option to "default allow" is important, so long as it doesn't lead to data leakage when the "default deny" option is chosen. I think there probably needs to be a "kill switch" to entirely disable PDroid, in case all hell has broken loose, the PDroid service is working fine, but you don't have time to dig through specific settings to disable the block - e.g. need to make emergency call, and you have accidentally blocked phone calls from the phone app.

Finally, what do people think about having hard-coded functionality to always allow 112 calls from com.phone.android, irrespective of any settings at all? Basically, that would be the super-emergency-override-someone-picked-up-your-phone-from-your-bleeding-body-and-needs-to-call-you-an-ambulance override.

The other option would be to have a distinct settings in PDroid for emergency services calls vs all other calls.

Edit:

If your kidnapper is calling emergency services for you then you should count yourself lucky :P
[Android Software/Hacking General [Developers Only]] htrakr:
What about an option to make a list of phone numbers that user could add to from the kill switch app. So I guess if someone wants to they can add their contact list and all calls will work without actually messing with pdroid setting (default allow/deny unless these are unrelated and I have no idea what you are talking about)
[Android Software/Hacking General [Developers Only]] siseam:
If I patch my CM10.1 sources with the changes from the "cm-10.1-openpdroid-devel" branch I get this error:

frameworks/base/privacy/java/android/privacy/IPrivacySettingsManager.aidl:14: couldn't find import for class android.privacy.PrivacySettings
make: *** [/android_sources/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/src/privacy/java/android/privacy/IPrivacySettingsManager.java] Error 1

Any ideas?
[Android Software/Hacking General [Developers Only]] mateorod:
How are you patching the source, by cherry-picking the relevant commits or by syncing down the entire cm-10.1-openpdroid-devel trees? I haven't built straight from the cm-10.1 devel branch in awhile, but I do know that the tree is generally building for all branches and roms.

Two things to try:

Check and ensure that frameworks/base/privacy/java/android/privacy in your local tree has all the files here

Try deleting the out folder, rm -rf /android_sources/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/. Make is usually smart enough for this to be unnecessary but it is necessary to delete the out folder to revert, so problems are not unheard of.

If you are still getting errors with both of those things tried/looked at, post again and I will look deeper. I am away from my computer, but I could quickly ssh in and build and see if you have exposed a wider issue.
[Android Software/Hacking General [Developers Only]] wbedard:
I can't make an extensive reply atm but I wanted to note that I was almost certainly in error earlier when I said that the backend writes to the database. The database only stores deviations from the default profile and, indeed, PDroid Manager will happily indicate the apps that have "No Settings" saved in the database. So, as I continue to refine my understanding of some of what you have been "conceptualizing", the idea of nodes in the database could be restated as "presets" where an app could be assigned a preset/node and inherit all of it's associated settings instead of always having to assign the permissions individually. Interestingly, a form of this feature already exists in CollegeDev's PDroid2.0 as a "persistence profile". It's basically a preset collection of settings that you can apply (after installation) to a selected group of applications. I do like your idea of using "nodes" in the database to store such presets and being able to simultaneously refine the settings for all the apps that use a particular preset/node.

Once things settle down for FFU5y, I really look forward to hearing his thoughts on this possibility.

BTW, make sure you're up on GitHub, follow the OpenPDroid project and FFU5y's other repos (wsot on GitHub). Feel free to post an issue there and include the code that you keep referencing. That way, he can look it over and discuss it with you. That sort of code-level discussion is better handled over there than here in the XDA forums. Additionally, you can always fork OpenPDroid, implement the code you mentioned and make a "pull request" on OpenPDroid to incorporate it. Vive La Open-Source!

R/

wbedard
[Android Software/Hacking General [Developers Only]] mateorod:
New OpenPDroid patch release (v1.0.1) has been pushed to the repo. These build patches match the project repos *.openpdroid branches and is reflected in the latest Auto-Patcher release(v2.6.0) as well.

Fixes that are hopefully in order include:

Fix for the SMS problems (I don't have SMS, let me know)

Cache issues

Performance Issues

Much more.

The build patches have been updated in the OpenPDroid repos, for those so inclined. See the individual repos for the individual commits and write-ups.

Among the things we are still aware of yet have not fixed:

The Llama/Cell Tower bug

more?

But the performance and SMS were the big issues, along with the broken AutoPatcher patches, so hopefully this is an improvement. The Auto-Patcher v.2.6.0 (out in the Auto-Patcher thread) includes patches for CM10, CM10.1, AOKP 4.1.2 and 4.2.1, AOSP 4.1.2 and 4.2.1, Evervolv and SlimRom 4.2.1.

Within the Auto-patcher, ParanoidAndroid is not yet updated to OpenPDroid 1.0.1. I am building it now, so it should be soon. As always, please let us know your experiences, and feel free to file an issue on the issue tracker.
[Android Software/Hacking General [Developers Only]] Der_Schubi:
Hey, I ran into an issue:

I'm building my own CM10.1 ROM from source with OpenPDroid development branch (cm-10.1-openpdroid-devel).

Now that you fixed the GPS issue (SystemUI lagging while GPS on) my device kept rebooting as soon as any app want to get a GPS location.

I did a full wipe without any change.

After some investigation I found the Faux Kernel (latest beta for Mako) as the reason. As soon as I use the CM Default Kernel, GPS will work.

The second thing is: Faux's kernel control app (named Fauxclock) keeps crashing right after reboot and also every time I launch it. Even on a complete wiped device with CM default kernel. It simply wont work.

I tested the very same things on the same ROM but without OpenPDroid and got none of these issues.

EDIT:

Now I got the first reboot on default kernel. So its NOT only with Faux Kernel.

Does anyone have an idea?

Logcat:

http://pastebin.com/download.php?i=JaKyMt9p
[Android Software/Hacking General [Developers Only]] g.armour:
I just ran into an issue trying to patch aokp mr1 build 2. It keeps giving me an error eveytime I try to patch.

http://codepad.org/KyZisUrT

Edit so I flashed CM 10.1 and everything seems to be solid, no problems with MMS or Camera. Nice work
[Android Software/Hacking General [Developers Only]] Cluat854:
OpenPDroid and contact access

Hey,

first of all I'm not 100% sure whether the following is a problem with OpenPDroid at all or whether it has a different cause, I'm sorry for that but I think if it's a problem with OpenPDroid it should be mentioned.

Anyway here's what I did:

I first flashed the Cyanogenmod, then a stripped down version of the Google Apps and finally OpenPDroid (Created with the AutoPatcher) and then I took the most permissions of the remaining Google Apps with PDroid Manager. In particular the permission for accessing the contacts.

Only now I have created a Google Account so I was able to log in Play Store.

After that I was quite surprised that all of a sudden the name of the "Ich-Kontakt" (Sorry, I don't know how to say in English) in the contacts app was changed to the name associated with my Google Account.

Now I don't know if all apps can access this special contact. It wouldn't be a huge problem but one should know about it.

Thank you in advance for any answer.

Cluat854
[Android Software/Hacking General [Developers Only]] h-e-k:
The performance issues fixes are great...:good: Patched them using APG into CM10.1 Unofficial. Thanks a lot for the work.
[Android Software/Hacking General [Developers Only]] nsmart:
One more thought about the default deny/allow strategy:

If you are concerned about privacy, then you normally do not install untrusted apps that require access to your personal data. But when you hear about pdroid, which allows you to individually block access rights for certain apps then you might come to the conclusion that it is a good idea to first install pdroid and afterwards untrusted apps, because you feel safe to use these apps controlled by pdroid. If pdroid fails or a default allow-policy gets active and passes your personal data to the untrusted apps, did pdroid as a result then increase or decrease the overall security on your phone/data?

If a default allow-policy will be implemented, I would recommend to make this transparent to all users, so everyone knows what to expect from pdroid. Sounds to me a bit like a security solution with a predetermined breaking point in security.
[Android Software/Hacking General [Developers Only]] lOtz1009:
Hi,

I've just tried to patch Flinnys Cm10.1 Build 13 for the Desire S.

Unfortunately the patch is failing → h**p://codepad.org/GpyitO2o

Any idea of what is wrong?
[Android Software/Hacking General [Developers Only]] precardo:
Re: aquaaqm[APP][2.2+] The Lightning Browser v2.0.0 - the fastest browser aroundqmqWq

Hi mateorod, im using Windows7. Which version of AutoPatcher is suitable for patching CM9??:)
[Android Software/Hacking General [Developers Only]] mateorod:
Just in case anyone new to the thread sees this---these issues are long solved as are the performance hits. Try Auto-patcher 2.6 or above that is loaded with the OpenPdroid1.0.1 patches.

Found a problem with our Aokp patches...this was our fault. I have just now uploaded a fix, it is available for Windows users through ApG and will be available for Linux/OSX sometime today. It is Auto-patcher version 2.6.50 and above.

Sorry, I don't see why that is failing. Unofficial builds sometimes stray far enough from the main tree that they refuse to patch. We usually see this with CM Kangs based off of Quarx's tree. My only advice is to try building from source with the build patches. We are working on widening our patches, but that is still a ways off.

In the Auto-Patcher thread OP, there is a link to a GUI for the auto-patcher, it is called ApG. You can use that with Windows or install the dependencies and use the command line.

All Autopatchers have CM9 support,but unfortunately OpenPdroid is only for Jellybean. Porting back to ICS has been something we have wanted to do, but have not found the time for. You can, however, use the auto-patcher to install the original PDroid.

Good luck!
[Android Software/Hacking General [Developers Only]] Micha_Btz:
is there a version with will work correct with llama?
[Android Software/Hacking General [Developers Only]] scutworker:
Not yet. The devs are aware that cell tower location/Llama problems exist and are working on it.

An update with the fix will come in due course :D
[Android Software/Hacking General [Developers Only]] Troj80:
Great! Thanks!
[Android Software/Hacking General [Developers Only]] hellunn:
I vote for default deny

In the discussion about deny/allow default mode I vote for deny. I don't know details about how the framework is or could be implemented so I can not opine about the DoS attack if the allow default mode is offered as a configuration option, but if only a default behaviour can be configured I think it should be deny all, that's what I have installed OpenPDroid for. Usability concerns, in my opinion, should be in the background, and maybe even only considered for the PDroid Manager app, that I think has a lot to improve about this, in spite that it really offers all the necessary functionality.

Yes, I agree, in this case, I'm part of the 1% ;)
[Android Software/Hacking General [Developers Only]] Lanchon:
hi,

could you please point us to a source for this claim?

thanks!
[Android Software/Hacking General [Developers Only]] nsmart:
This is the most official post I could find, although it might not exactly answer Discostrings question. It is from an admin user ("ciwrl") of the forum at cyanogenmod.org.

You can find the original article here:

http://forum.cyanogenmod.org/topic/44589-combining-cyanogen-with-pdroid/
[Android Software/Hacking General [Developers Only]] siseam:
Read the thread more carefully. This is the answer to the second question only, it is even obvious it is about spoofing without knowing the question,e.g. read the "neuter" catchword. Spoofing and permission management are two different things.
[Android Software/Hacking General [Developers Only]] Discostrings:
It was quite a few months ago that I looked into the permissions management in CM7.1 not being ported to future releases, and the statement I made was mostly based on my memory of the post linked by nsmart ( http://forum.cyanogenmod.org/topic/44589-combining-cyanogen-with-pdroid/ ).

I agree that the statement from ciwrl refers specifically to PDroid-style spoofing and not to permission revocation in general, and that my earlier comment was unintentionally a bit broader than what ciwrl's post states. It was quite a while ago that I read it.

Indeed, a recent post suggests that permission revocation is something the developers are considering bringing back.

However, that's a bit tangential to the point I was getting at, which is: a seemingly credible source states that the CyanogenMod team "received feedback from 'the powers that be' that should such functionality [PDroid-style spoofing] be issued directly, CM could very well be cutoff from all Android Market applications". This gives a pretty good idea of the nature of the response from 'the powers that be' if OpenPDroid achieves a notable level of popularity.

And while I don't have concrete evidence to support this, I speculate that the decision not to port the permissions management from CM7.1 to CM9 or CM10 (or the low priority given to this task) was at least somewhat influenced by Google's feedback. A statement like that has a chilling effect on developers who care about privacy but whose main concerns are elsewhere. I can only imagine it lessened the once strong enthusiasm for this feature.

Nobody's really talking about it--it's probably best not to force the issue to a head until there's already a robust privacy tool in existence. The personal information we don't want to give is central to Google's business model--that's why there isn't the trivial-to-implement ability to sensibly restrict access to personal information in the first place! I'm sure there are a lot of sympathetic developers at Google, but if this becomes a business issue that is seen as a threat to their ecosystem, the response will likely be fierce and unwelcome.

I'm personally hoping OpenPDroid has a lot of development and time to mature before it gets too much attention!
[Android Software/Hacking General [Developers Only]] mateorod:
For those interested in the original discussion, read the comments here...http://review.cyanogenmod.org/#/c/5677/

This is not even as in depth as the original PDroid, so what we are doing here is not, and will likely never be, included in CM and the like. I could see some factions of AOKP considering it, but probably never. The conversation is restarted every couple of months where people wonder why PDroid is not included in the big custom roms...this is why.

My impression isn't so much that there was any direct conversations from Google, but more that previous discussions let CM know where they stood on issues such as these. I have, myself, seen Steve discuss potential (un-Pdroid-related) features only to see a Google engineer stop by and not-so-subtly warn that said feature will result in a closing of the Play Store access to CM roms. CM is great, they do what they can, PDroid is out of their scope.

I can easily understand some of their concerns, of course. They are reasonable in many cases. Of course, I am also more inclined to believe that users have the right to protect their own data, and that if the Android framework didn't make it so easy for applocation developers to request (and recieve!) the moon, they would be forced to reconsider and develop more conscientious practices.

But the goal of this ( and the auto-patcher) thread is to make it easy for users to protect their privacy so that no one has to rely on the rom developer of their choise to include a controversial feature, they can add it themselves. As CollegeDev and FFU5y continue to work on the framework, I am working on getting OpenPDroid to stock roms and beyond. We want it to be easier...we will see how well we can do that.

Edit: Let's just say this...my 60+ year old mother-in-law has boycotted Google completely...she uses Bing, for godsakes. You know their is a serious credibility problem when housewives trust Microsoft over Google, especially for search. She is incredibly tech-minded...but c'mon. If they won't be responsible with data, we have to make them...