[Android Software/Hacking General [Developers Only]] FFU5y:
Sorry it has taken me a couple of days to respond to you all. I'm in the process of moving house, and the new house doesn't have a net connection yet. I've also been making some fairly substantial changes to OpenPDroid, but I'll describe those in a sec.

You don't actually need to. The databases should be compatible, though I haven't specifically tested the transition from one to another.

If you want to be safe, then you can either:

Install PDroid Manager (note: you must uninstall PDroid 2.0 App first), then use the 'backup' feature to create a backup. Make sure you don't lose the backup (it is on the SDCard in 'pdroidmanager/backups' by default).

Install a ROM containing OpenPDroid. Use the 'restore' feature of OpenPDroid to restore your backup. If you've wiped your userdata, then you will be prompted about the signature on the backup not being valid. This is normal: the key used to sign backups for verification is tied to the installation of PDroid Manager (although it is kept if you are using Titanium Backup or equivalent).

You can, I believe, achieve the same thing with the PDroid 2.0 App, using its backup and restore features. I'm not familiar enough with them to provide specific details, though.

Right now, not a lot. OpenPDroid fixed some security-related issues in PDroid 2.0, but CollegeDev is aware of them too and will no doubt fix them soon. There is no known examples of these being used 'in the wild' - though who'd notice, right?

The release version of OpenPDroid is a bit slower than PDroid 2.0, but that is fixed in the development code and will be released very soon.

I am about to push up a lot of changes to OpenPDroid development repositories which will make it a lot faster than it is right now (and probably faster than PDroid 2.0, though I haven't specifically checked) in some ways (i.e. caching is implemented, other database read weirdnesses are fixed). However, these changes also incorporate a lot of security-related changes, which I'll describe at the end of this post.

In short: if you're using 4.2.1, then OpenPDroid is better - or more accurately, is an option - especially if you're building from the development code. If you're using 4.1.2, then PDroid 2.0 is a bit faster, especially with camera, compass, and for some people the Google Play store but OpenPDroid is more secure from threats I've not seen in the wild.

In brief: given the current releases, it doesn't really matter that much.

In terms of migrating across: to avoid data leaks, you will need to freeze all the apps, or back them up and uninstall them. You can use the backup and restore process described above to backup and restore your settings.

PDroid Manager and the PDroid 2.0 App can't be installed at the same time, because of the way PDroid (all versions) currently use permissions: only PDroid 2.0 App or PDroid Manager can have the permissions at the same time - unless you re-sign both apps yourself. There is a description of the process for doing that here. If you do re-sign the apps, though, you will not be able to install a new version without uninstalling and reinstalling the app or re-signing those ones as well.

edit: Sorry, are you using PDroid 2.0 or the Syvat's original PDroid? If you're using Syvat's PDroid, then using PDroid Manager for backup and restore will not work, but let me know and I'll think on that.

(Note: if you're trixy with SQL, then you could dump all the data from the original PDroid database, and then convert it to 'insert' statements to put into OpenPDroid/PDroid 2.0. However, I should be able to integrate that transition into OpenPDroid. If you can send me your PDroid database, that would be great: I could then develop/test against it)

Precisely. Thanks for that =)

If anyone does have experiences going from PDroid 2.0 to OpenPDroid, or the reverse, and has observed whether the database 'just works' please let us know. All my devices are being used for testing the cutting edge OpenPDroid code, so I haven't been able to check.

So now, on to:

What's in this big push to jb-mr1-release-openpdroid-devel?

The last few days, I've been working on some fairly extensive changes to OpenPDroid, to further try to address both real and potential security issues. The main target of my concern has been that by and large, the existing code ever since Syvat's PDroid has had a 'allow-when-failing' approach. That is, if the privacy service is unavailable for some reason, if there is a database read problem which prevents the settings being obtained, etc. the response is to allow access rather than denying access. This isn't universal, but it is very broad.

Part of the difficulty in resolving this is that 'null' is used to represent 'no settings for this app', which then allows full access. Whether that is a good idea is a question worth asking, but separate from the question at hand.

The issue is that much of the existing code has the approach of returning 'null' if there is a error. Thus, when you ask the privacy service for settings it is basically indistinguishable whether there are no settings for an app, and thus access should be allowed, or whether an error has occured.

This only matters if your response to an error occurring is to do something other than allow access. However, I'm of the school of thought that 'default deny' is the right way to go. I mean, if your office swipe-card lock used wireless to check a card's authorisation with a server, but then just let anyone in when the wireless wasn't working, that would be weird behaviour right? I think the same applies here.

So what I've done is go through most (not quite all) of the PDroid code and modify this behaviour, so that if an error occurs the result is the app being blocked, not allowed. This does have one major consequence: default deny behaviour has a much greater risk of locking you out when something goes wrong.. That is really annoying, but would you rather have a door lock that always locks intruders out, and locks you out occasionally, or one that never locks you out but only locks out intruders some of the time.

Please note:

I haven't tried this with a clean-wiped device yet. I will very soon, but I wanted to get the code out for others to look over as a priority. Tried with a clean-wiped device. Booted, was able to get Google Play installed, install an app. Then I went back to my backup.

These changes have affected virtually every file in platform_frameworks_base and platform_frameworks_opt_telephony (the heart of the android Framework) touched by PDroid in the first place. This much code doesn't get changed without the risk of introducing bugs. I've gone over my code once already quite carefully, but I will go over it again. If you're enthusiastic, feel free to do so yourself.

I'm very open to the opinions of others, so if you actually think this behaviour is wrong (i.e. deny-on-error) please feel free to post why you think so.

These changes are currently only in the jb-mr1-release-openpdroid-devel branches (or at least, that's where I'm pushing them now). I will be cherry-picking them to other branches (or others are welcome to do on forks, and then put it merge requests if they'd like), but this may take a day or two because I'm in the middle of moving, and there are a great many changes.

I've now pushed these changes to aokp-jb-mr1-openpdroid-devel and cm10.1-openpdroid-devel as well.

I believe OpenPDroid on PA is currently buggy, so I have not been pushing to that until I get a chance to sort that out.

I will backport to 4.1.2-based ROMs soon also.

If you run into problems building these changes, then please do let me know.

Good luck (not my most comforting words ever :P)

edit:

footnote: The code for the changes I made is not beautiful code, and I am aware of that. I plan to beautify the code - and indeed others are more than welcome to do so, too - but I wanted to priorise getting it working, otherwise I can get all tied up in making beautiful code and never get it finished.

footnote 2: I don't want to freak anyone out too much about the changes. I'm using my latest development code on my day-to-day devices.