[Android Software/Hacking General [Developers Only]] FFU5y:
It doesn't lack batch permissions: long-press on something. That feature was added mid-December.

It has icons pre-generated for every resolution (which is actually why the binary is larger than PDroid 2.0 App) from high-resolution masters.

As for looking 'cheap': I'm not prioritising the style of appearance at this stage (i.e. themes) unless it is clearly a hindrance to users. If others would like to contribute work on the interface, they are more than welcome to, but that isn't where my time will be going at this stage.

I see a variety of perspectives here, and I totally acknowledge there is risk associated with adopting a deny-on-error approach.

The idea of user choice is a nice one, and indeed in most situations that can be accomodated.

However - there is always the something-has-seriously-gone-awry case: the privacy service is dead for some reason, the file which tells the code what course of action to take when the service fails is missing or invalid (assuming the preference was implemented in such a way). These are extreme cases, and frankly will probably never occur, but there is still the question of what if they do, and how should the device behave in this situation. By its very nature, this extraordinary and will-probably-never-occur error condition means that preferences can't be obtained from the privacy service, so that behaviour needs to be baked-in.

Sorry, I'm a bit confused as to what you mean by this.

The question of how to disable PDroid in the case of failure is a difficult one: basically because

the management app will inevitably need root access to be able to do it

as noted above, there still needs to be a final-all-things-have-broken-down-the-service-has-no-idea-what-is-going-on baked-in result

However, I agree that there should be a way to set whether the preferred action is 'deny' or 'allow' for if the service is dead. My biggest concern is that if the preferred action is 'allow', then that become an attack vector.

We have indeed discussed a default policy for apps which have no settings (which will cover newly installed apps) and I still think it is a good idea. However, because the current approach is 'no settings = allow all' it will be necessary to think hard about the interface so that a user doesn't accidently change the default policy and lock themselves out from everything.

Probably the best way to address that is to apply the current 'default policy' to all apps without settings when changing the default policy. Of course, that has side effects too. I'll think on it. And of course, welcome input or code =)

Expanding on what Mateor has said here:

The bleeding edge development roms are exactly that - bleeding edge. They can introduce serious bugs, and are not thoroughly tested yet. As a result, it would be quite dangerous (I think) to put them in the main auto_patcher app. If these potentially-buggy-and-incompletely-developed features were easy to install (e.g. through auto_patcher) then I think the support load would go through the roof.

That's just my feeling.

Edit: I said that having some kind of a 'kill switch' for PDroid that works even when the service is non-functional would require root. Don't take that to mean that I think we shouldn't do it, and indeed I'm comfortable with requesting root in such an extreme circumstance. Root would only need to be requested in this very narrow and rare situation.. The other big risk in adding a kill-switch that can be triggered by Root is that it will effectively make it possible for any other root app to trigger the kill switch, so we would want to consider notifying the users repeatedly (every 30s or something) when that has been triggered, until they explicitly ask not to be notified any more.