yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] pastime1971:
i agree w/ tony on this.
[Android Software/Hacking General [Developers Only]] mateorod:
votes[1, 2, 3] = let's make it so.

The look at that OpenPDroid dashboard is what confirms sale for me. Tonyp, pastime what's up fellas!

I will get together w/FF to confirm, but this sounds like what we'll do.
[Android Software/Hacking General [Developers Only]] pulser_g2:
Getting some errors on a clean install (wipe):

W/PrivacyPersistenceAdapter( 661): Multiple privacy settings found for package
com.android.phone
W/PrivacyPersistenceAdapter( 661): Multiple privacy settings found for package
com.android.phone
D/dalvikvm( 661): GC_CONCURRENT freed 1315K, 28% free 7458K/10332K, paused 3ms+
6ms, total 57ms
D/dalvikvm( 661): WAIT_FOR_CONCURRENT_GC blocked 32ms
W/PrivacyPersistenceAdapter( 661): Multiple privacy settings found for package
com.android.phone
W/PrivacyPersistenceAdapter( 661): Multiple privacy settings found for package
com.android.phone
I/PrivacyGSMPhone( 949): Package: com.android.phone asked for getCellLocation()

W/PrivacyPersistenceAdapter( 661): Multiple privacy settings found for package
com.android.phone
W/ApplicationContext( 661): Calling a method in the system process without a qu
alified user: android.app.ContextImpl.sendBroadcast:1113 android.privacy.Privacy
SettingsManagerService.notification:127 android.privacy.IPrivacySettingsManager$
Stub.onTransact:98
V/PDroidAlternative( 1989): NotificationHandler: Notification for: com.android.p
hone:locationNetwork:0

I have not run the app yet. It's like the network location issue, but I've not even run Pdroid yet... I also applied the "fix" (or workaround) that was meant to be for this. Or at least I think I did, but it was difficult to be sure, as there were many copies of things (but last few posts ought to address that in the long run).

I run the phone with strict mode enabled when testing things like this, to flash a big red band when there is something happening on the main UI thread (see http://developer.android.com/reference/android/os/StrictMode.html), and it's flashing away like mad. Might be worth trying to see if you can reproduce it or not - the flashes coincide with Pdroid stuff in logcat.
[Android Software/Hacking General [Developers Only]] FFU5y:
For most files, we don't actually need different patch trees. The advantage of different patch trees is that patches are much more likely to apply cleanly, but really the only patches where that tends to be a problem is the frameworks patch (i.e. JB_framework.patch).

I agree:

patches = release version = auto_patcher version

A local manifest may be possible, but it may not: the reason being that if the 'default' is set in the manifests.xml and that includes a 'remote', there is no way to override that remote. I use local_manifests.xml in my AOSP build setup, because it doesn't use that 'default' in the manifests, but AOKP, CM etc all do.

This sounds like a great way to go. I'll look into it.

I think that is a good approach: I do all my development in the jb-mr1-release-openpdroid-devel branch, and then cherry-pick out from that.

The 'multiple settings' error can be ignored: it is actually a bug in logging causing it, and it will be sorted out for the next release.

In terms of the database/file operations on the main thread: the reason for this will be because all of the operations done by OpenPDroid/PDroid2.0 to check security need to be blocking operations, and so having the read/write done in a separate thread doesn't really gain anything.

I'll think more about this though, because I do feel like I'm missing something. (Edit: I may well be missing something - I need to examine what happens with background threads using the system service, and what thread that stuff winds up on)

Finally, the 'using context without a user': We're still working out how to sort that one out (and indeed, what makes sense to do with multi-user context).
[Android Software/Hacking General [Developers Only]] CollegeDev:
The network location issue depends on several things. I've rewritten the telephonyRegistry class for easier porting and it also includes the fix for network location, but there is one major issue which also have to be fixed.

At this state now, caching is a good idea, I already implemented it several weeks ago but in a different way.

@FUy Did you hammered in a testing environment just 500 objects (of PrivacySettings) in a HashMap and take a look at the heap? If not, just do it! Can you explain why you used the LRU list? normally you can only take one hashmap and have to write some additional code to hold it on a fresh state, the result -> better battery life (not so much cpu consumption)

Also I had some spare time the last hour and looked at your changings in PrivacyPersistenceAdapter. There are several problems. It could be that the settings inside your lru are not "fresh enough" on some data-access and there could be some read/write problems. The problem of this is that (in some cases) you give the wrong privacysettings out of the box. Can you please take a look at this? BEFORE this goes up to auto_patcher?

Also, is there any possibility for other people except FFU5y to provide/upload/make changes via github? I ask because I'm not very familiar with github so can someone describe a little bit detailed how we can push code or some changings? And if I'm able to push several changes up to github, we can discuss problems like the mentioned above. I've changed a lot in the new version (mostly 90% bugs closed and security related things), so it would be nice to see this on github!

Another point:

It would be nice if there will be an "developers" or "testing" section where we can push the newest changings/bugfixes/features and other developers can verify and test the code before something goes up to autopatcher. It would also be greate to see some users which can test new versions on different devices (gsm, cdma, LTE). Since I've changed all this phones it would be nice to find 1-2 users per section (gsm, cdma, LTE). Is something like this possible?
[Android Software/Hacking General [Developers Only]] alroger:
CM10.1 SGT7 patch error

Greetings.

Just built CM10.1 here for the SGT7 (p1) and I had the following error with the patch:

patching file frameworks/opt/telephony/src/java/com/android/internal/telephony/SMSDispatcher.java
Hunk #2 succeeded at 204 (offset 1 line).
Hunk #3 succeeded at 343 (offset 1 line).
Hunk #4 FAILED at 976.
Hunk #5 succeeded at 1002 (offset 8 lines).
Hunk #6 succeeded at 1137 (offset 57 lines).
1 out of 6 hunks FAILED -- saving rejects to file frameworks/opt/telephony/src/java/com/android/internal/telephony/SMSDispatcher.java.rej

rej file attached.

I want to share the patched files as a CwM ZIP. Could anyone tell me exactly which files to include in the ZIP? Old PDroid was just 3 framework files, and I'm not sure about this one.

My build thread.

sgt7 git.

Thanks for OpenPDroid!
[Android Software/Hacking General [Developers Only]] FFU5y:
Cool, thanks for letting us know. There was a change to the SMSDispatcher.java file in CyanogenMod.

I've updated the patches in the OP to accomodate that change.
[Android Software/Hacking General [Developers Only]] wbedard:
Let me know when you're ready with the code (I'm following you on GitHub...) and I'll build it for testing. Since my device is already on 4.2.1, the updates will be easy to install/revert (if necessary...).

R/

wbedard
[Android Software/Hacking General [Developers Only]] Px80:
pls tell me whats the difference between openpdroid and pdroidmanager?
[Android Software/Hacking General [Developers Only]] FFU5y:
Hi,

OpenPDroid is a series of changes to the internals of Android - it provides a new system service (the 'privacy' service) and changes several existing classes to provide additional privacy features. OpenPDroid doesn't itself have a user interface though.

That's where PDroid Manager (or the PDroid 2.0 App - although I hear it does have some FCs with OpenPDroid, but it is loosely compatible) comes in. PDroid Manager provides the user interface for you to change the settings which are applied by OpenPDroid.

As an analogy: Many Android devices have IPTables built in. However, if you want to change the IPTables settings you have to use the command line, unless you download a tool like AFWall+, which gives you a GUI to change the settings.

The relationship between OpenPDroid and PDroid Manager is pretty much like that (except OpenPDroid doesn't have any way to change the settings without an external app - no command like interface or anything. Although now I'm tempted to build a command-line interface :P)

I hope that helps.
[Android Software/Hacking General [Developers Only]] @SR:
I am using openpdroid on samsung galaxy s3 with cm-10.1-20130116-NIGHTLY and there is a problem with incoming calls. The first time if someone calls me the person gets the response as if my phone is turned off. If he immediately calls me the second time then the phone starts ringing as it should. But if some time passes then the caller gets the message that my phone is turned off again. The phone is turned on all the time and the signal strength is good all the time. There was the same problem with pdroid 2.0 with cm-10. I think the problems started around the time cm-10-2012115 was released. Before that there were no problems with incoming calls with pdroid installed.
[Android Software/Hacking General [Developers Only]] mateorod:
Build patches for 4.2.1 have been pushed to github

There is only one branch of build patches for 4.2.1, that is because I have formatted the patches so that they will apply (as of today at least) on all of the major ROMS. I tested them on Cyanogen, AOKP, PA, AOSP and Evervolv.

Directions on patching can be found at the README or on the fourth post of this thread.

You will notice that we have followed up and formed an OpenPDroid organization as discussed. So far, we are hosting build patches for OpenPDroid and the original PDroid (with the history of that project soon to follow) as well as the pertinent trees for many of the major roms.

As always, if OpenPDroid looks intriguing, but you are not quite sure if you are up to building your own rom, you can try The Auto-Patcher, which can attempt to patch an already built rom and enable PDroid Manager or PDroid2.0.

Edit Organizational dashboard (with issue reporting) can be found here.
[Android Software/Hacking General [Developers Only]] Koetermann:
Hi everyone,

first let me say thanks for starting this project.

Today I started to built openpdroid with mateorod's autopatcher (version: 2.5.25) for my Samsung i9300 with CM 10.1. Unfortunaley i got an error message:

Reversed (or previously applied) patch detected! Skipping patch.
15 out of 15 hunks ignored -- saving rejects to file 'smali/com/android/internal/telephony/RIL$RILSender.smali.rej'
3 out of 20 hunks FAILED -- saving rejects to file smali/com/android/internal/telephony/SMSDispatcher.smali.rej
!!! PATCHING FAILED FOR com/android/internal/telephony/SMSDispatcher.smali !!!

File for which patching failed:
---------------------------------------------

SMSDispatcher.smali

---------------------------------------------

I read that FFU5y did some updates concerning SMSDispatcher.java:

Has the autopatcher also the these patched files? Or should I wait for a new autopatcher version? (Unfortunately I don't know exactly how to build opendroid from source. I read the section "How do I get the source?" but I think right now it's to hard for me, although I'm using Linux Mint 32-Bit).

Additionally 2 questions:

- Is it possible to restore the pDroid 2.0 rules (saved with Titanium Backup with CM 10) when using openpdroid with CM 10.1?

- Is there a problem with other RILs? Right now I don't use the RIL included in CM 10.1.

Regards

Koetermann
[Android Software/Hacking General [Developers Only]] CollegeDev:
You have to take care of it if you're building by your own. If you use autopatcher, it "normally" works, but If mateo will "smali patch" it you can get problems with the newest builds (sometimes he just copies files over, then it will work). Just try it. If it doesn't work, wait for new version or use an older nightly build.

First: Make backup with nandroid or whatever and please check the md5sums, because sometimes there is a problem with them (broken sums). Then you can normally just wipe your cache and flash over the CM10.1

without

wiping your device (yes, it works) so you have no problems with your rules.

If you like to do a full-wipe, just backup PDroid2.0 with Titanium backup (make sure you do a backup inside PDroid2.0 before) and flash the new rom. After that restore PDroid2.0 with TitaniumBackup. Open Pdroid and tap on "reload apps". Now go to preferences and restore your settings.

Tip: CM10.1 has some new system applications, if you want to revoke permissions and don't want to search each of them, use the "search untouched settings" feature as described in the help dialog.

Btw: I've never notice any FC, can anyone of you provide a log? OpenPDroid equals 99,99% PDroid2.0 framework (on CM10) and only ported to CM10.1. There are no heavy changings in the interfaces or IPC, so why it should FC? The only thing I can imagine is that there are some changing in GUI related classes which can cause that. It would be nice to see a logcat to help me out :o Thanks

//edit: I understand it in a wrong way and looked at your output (RIL). If it is ignore, there is no heavy problem at all(normally). Second thing, sms Dispatcher will be smali-patched, not copied -> it will fail with the newest nightly as you can see at your output. Just try a nightly 2-3 days ago, that should normally work fine. If the output of this was correct, just flash it and have fun :)
[Android Software/Hacking General [Developers Only]] karamelos:
This error is reported in auto patcher thread (not openpdroid or pd2.0 error)

Passed out works fine (at the question tape "yes" ) :)
[Android Software/Hacking General [Developers Only]] FFU5y:
Edit: removed, because CollegeDev already covered it completely.

I imagine there is some way to delete the post, but I don't see it.
[Android Software/Hacking General [Developers Only]] FFU5y:
Hi,

I unfortunately don't have access to an S3, but if you could intentionally produce this error and provide a logcat for while it is occurring that would be helpful. We could hopefully then dig through and find the problem.

(I haven't been able to reproduce it on my Galaxy Nexus with AOSP, or my Motorla Defy with CM10)
[Android Software/Hacking General [Developers Only]] mateorod:
The SMSDispatcher issue is indeed covered in the latest auto-patcher. In essence, we just roll back the offending CM commit. Not a perfect solution, but one that keeps us from having to rebuild for every device when one of the upstream branches when something small changes. We are working on some bug fixes in the development branches. Once they attain a level of stability, we will rebuild and then the SMSdispatcher will be brought back in line with the upstream.

It is only in very specific cases you would ever notice this, and at no point will it break anything. A better informational message for this process will be in the next auto-patcher release.
[Android Software/Hacking General [Developers Only]] Koetermann:
Thanks again, CollegeDev. Now everything works fine. I was a little to afraid to type YES when the message "Do you want to proceed ?" appeared. So, autopatcher works also with the latest CM 10.1 nightlies (tested with cm-10.1-20130119-NIGHTLY-i9300).

Okay, I had to do full wipe because of cellphone callings problems. But the backup/restore method you described worked absolutly perfect. :)

Yes, that's it!

Have a nice sunday!!!

Koetermann
[Android Software/Hacking General [Developers Only]] Lanchon:
thanks for OpenPDroid and PDroid Manager, this is great!!!

some of us have the problem of a very heavily configured PDroid (original) and we need to migrate to OpenPDroid.

this poses two problems:

1) how to migrate the privacy data. is there a way to automatically migrate the settings, or is manual reentry the only option? (maybe a big select into query can be used to create the new db table?)

2) how to handle the migration process to avoid all leaks, so that apps don't gain access to data during the process. is freezing all apps the only solution? (ideally PDroid (original) and PDroid Manager would be able to be installed in a device side by side at the same time. PDroid Manager would be configured (manually or otherwise) with a clone PDroid's settings, and when ready a reboot recovery/restore rom/repatch rom/reboot cycle would switch over to OpenPDroid, and finally PDroid would be uninstalled ending the process. however i believe PDroid and PDroid Manager cant both be installed at the same time and this wouldn't work, right?)

thank you again for your help.
[Android Software/Hacking General [Developers Only]] SecUpwN:
AW: [MOD][4.1.2 or 4.2.1][GPL] OpenPDroid [v1.0, 2013-01-14]

Pdroid 2.0 snd openPDroid seem to work after patching my ROM - which one to use? Does it even matter?
[Android Software/Hacking General [Developers Only]] rnd83:
From what I understand the main difference at the moment is that PDroid 2.0 is not yet (officially) available for JellyBean 4.2.1. And they are not 100% identical, so you should use PDroid Manager if you're using OpenPDroid. I think you have to wipe your data and re-do your settings from scratch if you're switching from one to the other.
[Android Software/Hacking General [Developers Only]] wbedard:
Just to be clear to everyone, when switching from PDroid2.0 to OpenPDroid (or vice-versa), you do NOT need to wipe your Android device's User Data Area (i.e. a standard factory reset). What you may need to do though (and I think the jury's still out on this...) is delete the PDroid-specific data on your device. It is contained in /data/system/ and is comprised of a couple of database files (privacy.db, privacy.db-journal) and one subdirectory (privacy).

Feel free to ask first if there are still any questions!

R/

wbedard
[Android Software/Hacking General [Developers Only]] h-e-k:
Thanks for your huge work.:good:

Where can I find info how/where to get your devel branch and how to use it via ApG?
[Android Software/Hacking General [Developers Only]] SecUpwN:
AW: [MOD][4.1.2 or 4.2.1][GPL] OpenPDroid [v1.0, 2013-01-14]

So, just for my own clarification: If my ROM is patched, I just have to make the decision whether to use PDroid 2.0 or OpenPDroid, right? Meaning, both PDroid 2.0 AND OpenPDroid should NOT be installed at the the same time and there are NO OTHER apps needed. "OpenPDroid" is the "core patch". Did I get this right?
[Android Software/Hacking General [Developers Only]] mateorod:
This is not possible, really. The only way to get the bleeding-edge, day-to-day changes is to build your own rom from source on a regular basis. But we keep the auto-patcher (and it's GUI, ApG) stocked with the most current release branch. So as the development branch changes get tested and vetted, then we will push them to the release branches. On a semi-regular release schedule (as-in, whenever the smali patches break or we feel their are development fixes that NEED to be released) we will build the roms, make the smali patches and then release them through ApG.

A discussion is currently on-going about releasing some of these new fixes through the auto-patcher very soon. Stay tuned.

Yep. CollegeDev has been getting active in the OpenPDroid core, so I would expect an upcoming OpenPdroid release (and the sooner the better, I think) to be tested and completely compatible with the PDroid2.0 app.

You should not, at the moment, have both installed at once, although perhaps that may change.

One of the things discussed is how to only allow PDroid settings to be changed by approved management apps. A solution might be to add signature-verification, but leave that available upon request. So anyone could fork the core and add their application to the approved managers list, or simply ask a maintainer of the OpenPDroid core to add it for them. But that is just one idea, and maybe there is problems there.

Whichever PDroid management app you choose (PDroid2.0 or PDroid Manager) is up to you. They both have merits (and I am not currently involved with either of the management apps)-

PDroid Manager is open-source, and therefore has extra eyeballs on how it operates and why, and also has the advantage of being available to improve should FFU5y ever leave the project. When Svyat left the original PDroid (you were there at the very beginning of the auto-patcher SecUpwn) you saw the the hoops I had to go through to keep it available and working, even though no one could even get it from the Play store anymore. It is also available for improvement through anyone's contribution.

PDroid2.0 is currently a fine choice, though, and will remain that way as long as CollegeDev is able to give it his attention. It has lots of things going for it, not the least of which is CollegeDev is the architect of much of the expanded PDroid core. He has been getting active with this OpenPDroid project as well, so we should be able to adequately support either app and the user-base should be all the richer for it.
[Android Software/Hacking General [Developers Only]] SecUpwN:
AW: [MOD][4.1.2 or 4.2.1][GPL] OpenPDroid [v1.0, 2013-01-14]

Thanks for the clarification. To be honest, I really dislike the look and feel of PDroid-Manager. It also lacks batch permissions and high-quality icons. It just feels too.. umm.. cheap. Yeah, you may punch me for that, FFUy5 - but that's just my honest opinion. Looking forward for some graphical polishment and feature enrichments, then I'll install it. Again. :)
[Android Software/Hacking General [Developers Only]] tonyp:
About the default deny strategy:

In theory I do totally agree that denying is the way to go, but from a users perspective it might be dangerous.

Imagine you run into some kind of data corruption and get locked in.

Now you need to make a really important phone call, but can't as your contacts app doesn't have access to your account list and the contacts anymore.

Or take a quick picture of your car crash but the camera app doesn't have access to the camera anymore.

Or are in some time pressure to drive to someone but your navigation app doesn't have access to gps anymore.

I don't think I would ship a ROM to others where stuff like this can happen.

I know it's extremely rare and unlikely to happen, but it's even more unlikely for default allowing some restricted data to an app.

Why even more unlikely? Because you get locked out of all apps and data that PDroid can deny access to while a data breach might only affect apps which you have pre-configured in PDroid. And the chance of the data that got leaked being harmful for you is even more unlikely again..

I mainly use PDroid to keep Facebook from accessing my data, especially location-based ones. In the rare case of a bad data read I'd prefer the Facebook app to indeed have access to this data instead of being locked out of _all_ apps that PDroid affects.

So I think we need an option if we want to have a default allow or default deny approach - and if neither the app data nor the new option can get read it should, in my opinion, indeed fall back to default allow.

Let's take your analogy from getting access granted to a door when there's a malfunction. While it's true that this is unacceptable, I think the impact of an app getting access to some data isn't even close as critical as that. Consider that without PDroid every app gets these data anyways.

So to sum up: I believe that a default-denying approach which the consequence of being locked out of all apps is more harmful than a consequence of giving some data to an app.
[Android Software/Hacking General [Developers Only]] alroger:
I would prefer the deny strategy. It would be perfect if we just had the choice to select one or another.

The deny strategy would also help testing, since you would definatly know when something is wrong behind the curtains.