A quick note
If you've come from Google Play to get support, welcome! I'm glad you made it here.
Please do post a description of the problem you are having, but you may also want to read the section below labelled What should I do when it fails?, as this will make it much easier for me to provide support.
If you're having a problem, the place to post it is here, because if you do so on Google Play then I have no way of responding. Unfortunately, this has been the case where an issue has become apparent, and I have included a fix, but there is no way for me to notify those who had the problem.
In any case, back to our normal program...
What is it?
PDroid Manager is an alternative OpenPDroid/PDroid 2.0 Management App. It is currently the 'official' management app for OpenPDroid, and serves as an alternative to the PDroid 2.0 App for PDroid 2.0.
It is GPL licensed (with additional attribution conditions). Source can be obtained from my github.
What does it need?
First, this relies on either the OpenPDroid Core/Framework patches (recommended), or the PDroid 2.0 Core/Framework patches being present in the ROM. You need to have them installed, either by getting the patches (OpenPDroid, PDroid 2.0), patching and compiling a rom yourself; or using the excellent autopatcher tool by mateorod and pastime to patch an existing rom.
It also requires Android 4.1.2 or 4.2.1.
Status
This app is in a supremely alpha state. It does have bugs. It will crash if you run it without the PDroid core/framework patches. It does have a problem with the way notification icons display if you install multiple apps without configuring them. It will crash in a range of other situations I haven't thought of yet.
It will crash if you try to use it while you have the PDroid 2.0 App installed. (It's a permissions signature thing, and you can't have both installed unless you resign them both yourself: see here for how to do that.)
It has been tested on three devices a Galaxy Nexus running AOKP, and a B&N Nook (cheers to mateorod) and a Nexus 7 running AOSP.
Probably others too now, what with people using it, but I don't have a list for that =)
What is the difference between this and the PDroid 2.0 App
This is an ALPHA status tool, so it has more bugs.
This isn't complete - it is missing useful things like an 'about' box, the ability to check the PDroid core version, backup & restore, all of which are in the PDroid 2.0 App.
It can keep logs of application activities. There is currently no way to view these, though. Logs are now (I think?) supported in PDroid 2.0 App. I haven't tried them though.
You can filter the app list by whether it is a system or user app, and by the type of permissions used. Now also in PDroid 2.0 App.
You can filter apps by the 'type' of permission they use - e.g. 'messaging', 'calls', etc.
The source is available.
It can create and restore multiple (human-readable) backups on your SD card or 'external storage'.
It supports multiple languages, thanks to the contributions of others (languages and contributors are listed below) PDroid 2.0 App now supports German and English (but not Russian and French).
Did I mention it has more bugs?
What is the difference between this and Permissions Denied, and other permission-modifying apps
In brief: OpenPDroid and PDroid 2.0 do not actually change the permissions of apps; rather, they intervene when the apps try to use some of the features allowed by these permissions. For example, it doesn't remove permission for an app to use the camera - instead, it lets the app believe it is using the camera normally but then feeds back a fake image when a 'photo' is taken. Similarly, the app can try to request the phone number from the phone, but PDroid can return either a blank number, or a fake number, to the app. The main advantage of this is that rather than the app crashing, as often happens if it finds expected permissions have been removed, it continues to operate simply using incorrect data as its input.
The downside is that PDroid requires modifications to the ROM, which is difficult.
What should I do when it fails?
First, check if the problem you have discovered is a known issue, by looking at issues on my github. If if has already been lodged, but you have additional information to add, then ideally attach it to the issue in github. Otherwise, you can post it here but please clearly refer to the existing issue in github when doing so.
If it is not a known issue in the github:
You can open an issue on my github, providing a logcat: see how to get a logcat.
You can post on this thread, providing a logcat. I will try to monitor this thread, but if it starts getting out of control then I will probably try to run up a bug tracker somewhere else for people to use (and I will always fall back on the github issue tracker).
When will you stop telling me about the bugs and give me a link?
I have added PDroid Manager to the Play store, so you can obtain it from there (which means easier updating). If you do get it from the Play store, remember that support is provided via this thread, not via the Play store comments. I have only added the app to the Play store as a convenience so people can get updates without monitoring this thread.
Check the attachments to this post for the PDroid ALPHA releases. Make sure you read that ALPHA part.
Source at my github.
Requirements: Android API 16 (i.e. 4.1.2 - haven't tested in 4.2 yet).
What does it look like?
This:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Why did you build it?
The original PDroid app by Syvat, and the subsequent PDroid Addon/Extension/2.0 apps by CollegeDev didn't do everything I wanted them to do. I couldn't modify them because I didn't have the source. I'd never created an app before and I wanted to give it a shot.
Why does it need permission to access my SDCard?
I've added the ability to backup and restore your settings to the external storage. In order to do this, I need to be able to write to, and read from, the external storage. I will be adding a version at some point which doesn't require this permission, and cannot do backups.
Isn't doing backups to the external storage really insecure? Couldn't another program edit my backups?
In general, doing backups to the external storage would be insecure, in two ways: other apps could read your settings from the backup, and other apps could edit the backup so when you restore it your settings are wrong.
The ability for other apps to read your settings is a problem even ignoring backups. The Pdroid 2.0 Core (and the original PDroid Core) do not prevent applications from reading settings without any permissions whatsoever. Yes, any app can read your settings directly from the PDroid service. That is the way the PDroid core is built at present (and I don't much like it, but that's another story).
The second problem is one that I have attempted to address. Each installation of PDroid Manager will generate a 'digital signing key', and any backup you create will be signed with this key. When you attempt to restore the backup, the signature is checked to ensure the backup (or signature) has not been modified. If the signature doesn't match, you are warned and given the opportunity to restore anyway. You cannot export this signing key, because exporting that key to your external storage would make it accessible to other programs, and with it they could re-sign your backups to make it appear that they had not been modified. This means if you uninstall and reinstall PDroid Manager, you will get 'invalid signature' warnings on all the backups made from previous installations. If you don't want this to happen, I recommend downloading and using Titanium Backup - it will store the encryption key (although on external storage, which itself could be a security risk). Thus, unless you uninstall and reinstall your PDroid Manager installation, the app will verify that backups have valid signatures before restoring them. Mind you, a root app could steal the signing key. As is always stated, for root apps it is all up for grabs.
I have a great suggestion! How should I get it to you?
First, keep in mind that there are various degrees of detail which can be provided with suggestions, such as:
A suggestion of a feature which could be included
A description of how the feature should work (e.g. user cases: list XYZ, then user presses N, dialog P opens, etc.)
Storyboards or images of what the feature could look like (even if it just a box diagram done in Powerpoint or something).
A suggestion of an app which implements a similar behaviour that could be used as a reference for implementation
A bit of example code
Suggestions of new features are excellent, and some suggestions need less description than others - e.g. "add a help button to each setting" needs less description than "add the ability to filter by the 'trust' state of the app" (although in both cases, interface diagrams could be helpful: e.g. should the help button go to the left or right of the text label for the setting?)
You don't have to provide all of these details, and indeed even if you do provide some details I may not actually use them (e.g. if your suggested images were very inconsistent with the Android UI idioms, or the rest of the app). You can certainly make suggestions that are quite simple: e.g. I would like to be able to apply settings to multiple apps at once, or I would like to be able to filter by individual settings rather than groups of settings (although the latter would be a good candidate for interface suggestions too). If you are suggesting complex features, though, some suggestion of how the interface should work could be handy too - even if I don't use the suggestions as such, they can be very useful for giving me different perspectives.
If you have a suggestion then please describe clearly the suggested feature, interface or behaviour change, or whatever your suggestion it may be. If it requires a new UI screen, or a change to an existing one, descriptions of how it should work, drawings or imagery (or pointing to another app) are very welcome.
In order of 'most desirable' to 'least desirable' (from my perspective) I suggest:
Post the suggestion to my github
Post the suggestion on this thread
PM me (this is low on the list because if I get a flooded PM box it will be hard to find anything).
Finally, remember nothing says "I'd love this feature to be in the app" like a patch to implement it
Can I contribute a translation?
Absolutely! I welcome translations! The process for doing a translation will depend on whether you have a github account or not.
Currently we have translations being contributed for:
English
French (jpeg729 and patrickpr)
German (TamCore)
Hungarian: appelsson
Russian (Beasty)
If you have a Github account
You can fork the PDroid Manager project, and create a "values-xx" directory for the relevant language (e.g. values-de for German). Into that directory, you will need to copy:
Files containing text displayed to the user are:
access_notification_text.xml, which is the text for notification messages provided to the user when an app attempts to accesses a particular type of data.
arrays.xml, which currently contains the text of the drop-down lists used for filtering, and the 'Untrusted, Trusted, No Settings' text displayed.
settings_strings.xml, which contains the text descriptions of each setting, and the associated help text. (I have *just* pushed an update to github for this file, so if you want to translate it make sure you do a pull).
strings.xml, which contains the 'general' strings used in the app.
Once you have created those files, you can commit them, and then create a 'pull request' so I know they are ready to be integrated. I'll then integrate them.
If you don't have a github account
You will need to download the four files linked above, and translate the strings in them. Once you have done that, post to this thread with the files attached.
Remember:Keep in mind that if you have the files sitting around for a while in a partially translated state, they could change in development! When doing translations, make sure you have the latest version from the server. If you find that the strings etc have changed on the server, and you have done a partial translation, you can use a tool like WinMerge to merge the new changes into your file without a lot of work.
Also, if you are creating translation files, please include yourself as an @author in the header to the file, or nominate the details you would like to have recorded against your authorship. Also note that basically the entire app is under a GPL license, and I will only accept material which is licensed under a GPL or BSD license, to make sure that people are free to copy and edit the code as they see fit.
What do you have planned next?
Fix bugs
Add a 'preferences' and 'info' screen to check PDroid core/framework version, etc mostly done
Add help to the individual settings, so users can understand what they mean DONE!
Add the ability to view log and delete logs
Add the ability to create 'profiles' - i.e. pre-configured groups of settings, which can then be applied to an app
Add batch processing, so profiles can be applied to multiple apps in a single action Released in 0.9.3
Add filtering of apps by individual settings, not just by 'setting group'.
Add filtering of apps by setting state (i.e. trusted, untrusted, no settings)
If you want you can give it a go. Read the source. Have fun. Just don't complain that you haven't been warned about it being buggy.
2013-01-15 v0.2.9.9 ALPHA
Changes
Added support for 4.2.1 - not that it stopped you installing it anyway, but for Google Play it mattered =)
Added Spanish support, thanks to alceasan.
2013-01-12 v0.2.9.8 ALPHA
Changes
Fixed a force-close affecting everyone as a result of a corrupted APK. Sorry about that, all!
2013-01-12 v0.2.9.7 ALPHA
Changes
Added Hungarian language support thanks to appelsson.
Updated French language support thanks to jpeg729.
Fixed (I think) a bug in which the app crashed when an installed app does not have an icon.
2012-12-15 v0.2.9.5 ALPHA
Changes
Theoretically fixed a bug which I was unable to reproduce (but I think I know why) which caused a crash rather than a friendly message when a user attempted to run PDroid Manager without the PDroid core installed.
CHANGE LOG
2012-12-15: v0.2.9.4 ALPHA
Changes
Added detection of whether necessary permissions to write to the PDroid core were present, and provide a friendly message if they are not. (These permissions are absent if PDroid 2.0 App is installed before PDroid Manager, not uninstalled before PDroid Manager is installed, and the two packages have not been re-signed with the same key).
Otherwise, this version is identical to v.0.2.9.3. It was just added because I saw some crashes due to PDroid 2.0 App being installed with Google Play users.
2012-12-14: v0.2.9.3 ALPHA
Changes
The main stand-out of this release is batch processing: further details about that are after the list.
Instead of crashing if you don't have PDroid installed, it will now give you a message telling you that you need to install it.
Batch processing: you can now select a bunch of apps, and change their settings. Long-press on an app to enter selection mode, touch other apps to select or deselect them, then use the action bar options to choose what to do.
Added a 'purge settings' option to preferences. This deletes all settings for all apps.
Changing language now triggers a restart of the app (after prompting the user) to immediately switch language
Restructured the filtering interface to work better on smaller devices, and generally look nicer.
Info/help buttons for settings only appear on larger devices now (due to screen real-estate issues). Clicking on the name of the setting will display the help on smaller devices.
Performance improvements
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing). Still.
I think there is still something funny going on with the 'trust' indicator after you save an app, but that may be a new issue. Still.
App names in the application list don't get reloaded when the phone locale changes, which means they stay in the old language until manually refreshed. I'm no longer going to call this an issue, because it is handled by the OS.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
Key points about batch processing:
When you select some apps and choose 'custom settings', only the settings relevant to the apps will be displayed (unless you choose 25+ apps; then it was too slow to work out which ones were relevant).
Only those settings you select new values for will be changed. Those with no pressed buttons will be left alone.
You can 'deselect' a button in batch mode by pressing it again (effectively clearing that setting row, so it will not be changed).
Batch processing can be a bit slow, but unfortunately that is a consequence of the Privacy service to which PDroid Manager connects. I have modified this service to improve performance, but I'm still testing the changes so the app does not require those modifications.
You can't avoid overriding the 'logging' and 'notification' settings when doing batch processing at this stage. I will resolve this soon.
2012-12-07: v0.2.8 ALPHA
This is a minor update: It provides an updated German translation from TamCore, and
Changes
Updated German translation from TamCore,
fixes the Application List scrolling back to the top when you open details for an application, thus losing your place.
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing). Still.
The app will probably crash if PDroid is not installed. Still.
I think there is still something funny going on with the 'trust' indicator after you save an app, but that may be a new issue. Still.
App names in the application list don't get reloaded when the phone locale changes, which means they stay in the old language until manually refreshed. Still.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
2012-12-03: v0.2.7 ALPHA
A couple of new features in this one, and returning to just one version (rather than multilingual and English). The backup and restore features are shiny and new, and *should* work, but be cautious when using them. I've tried them out quite a bit, with custom settings etc, but there could be bugs there that will cook all your PDroid settings. If you find one, please, please report it (see the section on reporting bugs).
Changes
Added a 'preferences' screen, with 'About' box, 'Credits', and a link to this thread
Added language selection (i.e. overriding phone language), again in the preferences screen. Note that for the language to change, you need to force-close and restart PDroid Manager after switching languages. I'm looking at how to resolve this.
Added backup and restore of settings. This requires access to your external storage, hence the new permission. I will be adding supporting code at some stage to allow a separate version without backup and restore to be easily generated for those who are uncomfortable with SDcard access by the app. You can read more details about the backup approach in the Why does it need permission to access my SDCard? and Isn't doing backups to the external storage really insecure? Couldn't another program edit my backups? sections.
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing). Still.
The app will probably crash if PDroid is not installed. Still.
I think there is still something funny going on with the 'trust' indicator after you save an app, but that may be a new issue. Still.
App names in the application list don't get reloaded when the phone locale changes, which means they stay in the old language until manually refreshed. Still.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
2012-11-30: v0.2.6 ALPHA
This release has two versions: Forced English (PDroid_Manager_0.2.6_en) and multilingual (PDroid_Manager_0.2.6_multilingual). The multilingual will automatically use the language matching the phone where possible. The 'en' version uses the exact code I intend to apply to allow users to override the automatic language selection. Basically, this is the same as having a button to force the app to always use English, except the button isn't on the user interface and is always pressed. If you find this isn't always showing English, please let me know so I can fix it.
Changes
Incorporated updated help text (fine work by wbedard, to which I made minor edits. Thus, errors are probably mine not wbedards).
Added German translation (thanks to TamCore) and French translation (thanks to patrickpr on GitHub; note I removed a few words from the translations because the English help text changed, so may have introduced gramattical errors into patrick's French).
Added automatic language data re-loading. To optimise speed, some language-specific text is stored in the database. To make sure that stays up to date, the App will check if the language has changed, and regenerate that database data if it has. If this doesn't happen for you, and the interface stays in English when you switch your phone to German, etc, please report it..
Added different button sizes for 'large' vs 'non-large' devices. This means that buttons will appear larger on most 7-inch tablets (and maybe 10-inch tablets too; my 10-inch isn't working right now) than on phones.
Modified the code to use Android 'Fragments': hopefully, this will be invisible to users at this stage; however, in future it will allow easier development of a multi-panel tablet interface. This is a pretty major change, so may have introduced bugs. Sorry.
Updated notification bar icon to match Google's style guide.
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing). I will fix this soon, honestly.
The app will probably crash if PDroid is not installed.
I think there is still something funny going on with the 'trust' indicator after you save an app, but that may be a new issue.
App names in the application list don't get reloaded when the phone locale changes, which means they stay in the old language until manually refreshed. I'm undecided as to whether to I consider this a bug or not. Feedback (or patch to fix it) welcome.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
2012-11-25: v0.2.3 ALPHA
Changes
Added improved text for the access notifications
Added a help button for each setting with a summary of what the setting does (I know it is ugly, and I plan to fix that soon).
The application list status indicator should now work under all normal circumstances
Dialogs have been added when loading, saving etc. to avoid interactions that could cause crashes
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing).
The app will probably crash if PDroid is not installed.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
2012-11-19: v0.2.2 ALPHA
Changes
Re-added some debug logging (but still much less than was there originally).
Added the ability to delete privacy settings from an app, both in the application settings detail screen, and on the long-press menu on the application list.
The application list status indicator (i.e. trusted, untrusted, no settings) now updates after the long-press menu is used, or the settings are changes in the detail display
An 'all' option has been edited when filtering by the type of settings (e.g. messaging, media, etc).
Known bugs
The trusted/untrusted is sometimes incorrect - 'trusted' apps may appear as 'untrusted'.
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing).
The app will probably crash if PDroid is not installed.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
2012-11-16, later: v0.2.1 ALPHA
Removed writing to the device log (so logcat will not be hideously large)
Contribution to PDroid Manager acknowledgements (in alphabetical order):
mateorod: testing assistance, great ideas, building Autopatcher.
patrickpr: French translation
TamCore: contributing Android.mk, markdown for tables in README.md which were unreadable, German translation
wbedard: textual descriptions of the individual settings
Still playing with the 2e version. I like what you have done with this a lot. Having an open source version will keep us from being in-between working versions, like we were between gingerbread and the auto-patcher release.
An open source alternative like this keeps that from ever happening again.
I had noticed that CollegeDev had not added preloaded-classes to his PDroid2.0 build patches, a potential security leak. Without any access to the source or even version control with the patches I didn't have much recourse to correct the issue. I was left to suggest it in his thread and hope for the best. While he never brought it up again, I did finally see that the suggested change was integrated, but it struck me that having version control for the patches would be for the best as well.
In the spirit of having the entire process open AND available, I have pushed repos for the updated original PDroid patches, worked on by pastime1971 with some help from me, and the PDroid2.0 build patches (which I call PDroidCorePatches) by CollegeDev (which are already open-source, just not available with version control AFAIK) pushed as well.
If CollegeDev or you update the build patches for 4.2, we can either use those repos or start new ones, if necessary. But I am more than willing to add read/write to both of you. Wbedard has ported the PDroidCore patches to AOSP, but I will wait and see if he wants to put up a repo first before adding a new one (or possiibly a aosp-4.1.2 branch).
My hope is that the move towards complete open-source could galvanize all of us who work on PDroid to work together instead of splitting our efforts...we'll see how that goes.
Anyway, great job! I will eventually push the entire history (gingerbread to today) but for right now only 4.1.2 is up.
Original PDroid
PdroidCore
If anyone who has been working with us on Pdroid wants push access, pm me. Anyone who wants to contribute that I don't know yet, submit a pull request and we'll get to know you.
I think having the patches be attached to the same repo as the Auto-patcher and smali patches makes sense, but I am open to suggestion.
FFU5y said:
It is GPL licensed (with additional attribution conditions)
Click to expand...
Click to collapse
dear OP,
i was under the impression that GPL2 did not allow additional obligations (like attributions) being added to the burden of the receivers of the licensed code. however, i think GPL3 made special provisions for some extra obligations in other common permissive free software licenses (manly attributions) to make them compatible with GPL3, so there are some attribution provisions in GPL3 i think.
an example of GPL2 ban on additional restrictions: GPL3 enforces further obligations on receivers, such as non-tivoization, and thus is itself incompatible with GPL2 for the previously stated reason.
could you please clarify the method you chose to extend GPL with attributions in this case? thank you!
Lanchon said:
dear OP,
i was under the impression that GPL2 did not allow additional obligations (like attributions) being added to the burden of the receivers of the licensed code. however, i think GPL3 made special provisions for some extra obligations in other common permissive free software licenses (manly attributions) to make them compatible with GPL3, so there are some attribution provisions in GPL3 i think.
an example of GPL2 ban on additional restrictions: GPL3 enforces further obligations on receivers, such as non-tivoization, and thus is itself incompatible with GPL2 for the previously stated reason.
could you please clarify the method you chose to extend GPL with attributions in this case? thank you!
Click to expand...
Click to collapse
The code is GPL3 licensed, and the additional attribution (and differentiation) requirement are under GPL3 Section 7 (b) and (c).
If there are specific contexts in which people would like to use the app that are excluded by GPL3, they are welcome to contact me about alternative licensing arrangements. Of course, as soon as others contribute GPL3-licenced code then that will get a lot more difficult, but right now that is an option.
I hope that answers your question, but if not let me know.
This is so absolutely awesome, thanks a lot FFU5y!
The filtering options for user/system apps and permission type are exactly what I needed. Further ideas would be:
search app by name
advanced filtering for a single specific permission, e.g. "start on boot"
batch operations: e.g. block network & gps location permissions for all apps
dbx4 said:
This is so absolutely awesome, thanks a lot FFU5y!
The filtering options for user/system apps and permission type are exactly what I needed. Further ideas would be:
search app by name
advanced filtering for a single specific permission, e.g. "start on boot"
batch operations: e.g. block network & gps location permissions for all apps
Click to expand...
Click to collapse
Cheers dbx - glad you're finding it useful.
These are good ideas (and indeed, I started on 'searching app by name' but de-prioritised it for release). I'll add them to my github issues list as enhancements (so they are listed somewhere centrally).
I'm not really sure at this stage how I'd go about implementing the filtering for a single specific permission, mainly because I'm not sure how to represent it in the user interface without cluttering it up.
One way may be to have a specific view for filtering by setting, which shows a list of settings, and then upon choosing a setting shows only the apps to which that setting relates (e.g. choosing 'GPS location' from the list of settings shows only those apps which have that as a valid setting - i.e. those with permission to access the GPS).
I'm afraid those features will probably take a little bit of time to develop, but hopefully you'll find the app useful in the meantime while I'm working on them.
Version 0.2.3 ALPHA has been relased:
CHANGE LOG
2012-11-25: v0.2.3 ALPHA
Changes
Added improved text for the access notifications
Added a help button for each setting with a summary of what the setting does (I know it is ugly, and I plan to fix that soon).
The application list status indicator should now work under all normal circumstances
Dialogs have been added when loading, saving etc. to avoid interactions that could cause crashes
Known bugs
When multiple apps are installed one after the other, the notification to update settings of previous installations is replaced (rather than additional icons appearing).
The app will probably crash if PDroid is not installed.
Also see my github list: https://github.com/wsot/pdroid-manager/issues
Hi, PDroid is a very important app, and I wanted to thank you for making an open source alternative with much more features.
Wish I was a dev, so I could help you more, but I will gladly test it the moment the autopatcher supports 4.2.
Sent from my GT-I9000 using xda app-developers app
Dr.69 said:
Hi, PDroid is a very important app, and I wanted to thank you for making an open source alternative with much more features.
Wish I was a dev, so I could help you more, but I will gladly test it the moment the autopatcher supports 4.2.
Sent from my GT-I9000 using xda app-developers app
Click to expand...
Click to collapse
Cheers =)
I'm eager to give it a run on 4.2 as well, but I am aware that CollegeDev is working on a new release of the PDroid 2.0 Core and App, so I'm not going to try to port the core to 4.2 until the update is released (otherwise there may be a lot of re-working needed, and if CollegeDev is porting it already then I'd just be duplicating work).
In the meantime, I'm going to try to get some fixes and new features into PDroid Manager which can then hopefully move smoothly to the 4.2 version.
Hello, i'm using Permission pro to remove rights i don't want from program, do your program works the same way, or rights are removed by an other way ?
Also, some Gameloft games have managed to get their start at boot rights back, with every programs i used, i was never able to kick them, so this is somewhat important to know, for me, if it will fail the same way.
Don't know if it's possible to do, but people not using Jelly Beans cannot block notification from a program, amybe we could get it with PDroid manager ?
Magissia said:
Hello, i'm using Permission pro to remove rights i don't want from program, do your program works the same way, or rights are removed by an other way ?
Also, some Gameloft games have managed to get their start at boot rights back, with every programs i used, i was never able to kick them, so this is somewhat important to know, for me, if it will fail the same way.
Don't know if it's possible to do, but people not using Jelly Beans cannot block notification from a program, amybe we could get it with PDroid manager ?
Click to expand...
Click to collapse
The quick answer: PDroid and PDroid Manager do not block notifications from programs. In new version of Android, there is a feature to limit which applications can create notifications. If there are a lot of 'marketing' notifications you should report the app to Google (I think you can report it at the Play store) because they are starting to move against that kind of activity.
Anyway, continuing...
PDroid 2.0 (and PDroid Manager) work quite differently to permissions pro. First, PDroid 2.0 (which is the Android modification that PDroid Manager configures) requires a modification to be made to the ROM on the device. This allows for the Privacy Service to limit the access apps have to private information, even when they have Android permissions to access the information. The PDroid Manager App (or the alternative, PDroid 2.0 App) allows you to choose what private information is provided to what app.
So, in order to use PDroid Manager, you need:
A ROM patched to add the Privacy Servire, which you can achieve by either patching the source code yourself using the patches in the PDroid 2.0 thread and compiling the rom, or potentially by using mateorod and pastime's excellent autopatcher
PDroid Manager (or the PDroid 2.0 App) to configure
The advantages of PDroid over Permission pro is that with PDroid, the app still has the same Android permissions, but when the app requests data from the Android operating system the privacy service provides back blank or incorrect data. This means that rather than the app crashing, as often happens when its permissions are changed, it keeps running.
The main disadvantages of PDroid compared to Permission pro is that it requires changes to the Android frameworks, which means you need to be willing and able to modify your ROM in order to use PDroid. It is not 'easy', and it also means there is a delay before new Android version are supported because the patches for the framework need to be modified to support the updated framework.
I hope that helps.
Hello, thanks for your answer, on the autopatcher page, it's not clearly written if it will work on OEM's rom (but it's clearly written it won't on samsung/htc one)
I'm currently usng ASUS' stock rom and guevor's kernel, any chance to have it working ?
If the service reply false information, it's still able to block an app at boot ? to make it unable to start itself at boot ?
Magissia said:
Hello, thanks for your answer, on the autopatcher page, it's not clearly written if it will work on OEM's rom (but it's clearly written it won't on samsung/htc one)
I'm currently usng ASUS' stock rom and guevor's kernel, any chance to have it working ?
If the service reply false information, it's still able to block an app at boot ? to make it unable to start itself at boot ?
Click to expand...
Click to collapse
Autopatcher will probably not work on an OEM ROM at this stage, unfortunately. That is something mateorod has been working on, but I believe it is still a work in progress. You can give autopatcher a try nonetheless, though. If it can't patch it, it will tell you. Also, if you search around the forums for your device, you may find someone has created special patches just for that device.
If you can get the ROM modded to include PDroid, then one of the features allows you to prevent an app being notified of when the device finishes booting. For those games, that means they would not be started when the device finished booting. However, it is possible that they may use a range of other ways to make sure they start which PDroid doesn't affect.
Probably the best way to deal with these types of problem apps is to use a tool that can 'freeze' the apps, and then just 'unfreeze' them when you want to use them. If they are giving you notification bar spam, you should definitely consider reporting them at the play store, too. Notification bar spam is against Google's current policies for the Play store.
Sorry I can't give you better news - patching of already-compiled OEM ROMs is not my focus area.
Hello, i already reported gameloft for their notification ads, and a video game doesn't need to be notified of system's start. Fact are they are "super dev" in play store and i doubt google will do anything.
PDroid seems more complete than Permission Pro, to make programs unable to acces data.
So, if i understand correctly, when i refuse a right to a program, the service will give blank information instaed of letting it see the real information. Does it have a big impact on the performances ?
I wouldn't mind switching rom, but it seems that no rom is able to install and keep all the data/configuration, means you have to use the custom rom since start or you're stuck if you want to keep things.
Edit : Seems Pdroid 2 is for 4.1.2+, my device use 4.0.3, will keep this thread bookmarked and will come back once i'll have enough courage to switch rom (since ASUS won't let us get the update anyway)
Hy!
enough if I flash in recovery the my ROM's update zip?
root required ? :fingers-crossed:
hmm
it looks like it works.
Thanks.
ROM:cm10 Flinny 129.
is possible into other languages translate?
acultr said:
is possible into other languages translate?
Click to expand...
Click to collapse
It's easy. Translate this file and open a pull request or attach it here.
I loved to hear about GrapheneOS's Sandboxed Play services that allow running Google Play services as regular sandboxed apps. I don't own a google phone and am using LOS18.1. Unfortunately it seems LineageOS won't integrate the feature (see reddit).
That's why I looked for the corresponding commits in GrapheneOS, adopted them for LineageOS 18.1 (almost everything could be auto-merged) and used LOS4mG's docker CI/CD to build LOS18.1 with GrapheneOS's compatibility layer.
I don't want to release ROMs myself, but am just leaving the project here: https://github.com/sn-00-x/lineage-gmscompat
The docker image is on docker hub so you could build LOS18.1 by simply running the image sn00x/docker-lineage-cicd (set env vars and volumes as explained here). Or grab the patches here and apply yourself.
I'm very very sorry.. I have troubles building.. in fact I never got a build to succeed and didn't need much custom work anyway. But this one from your docker, I tried for two days, and there are always errors as I'm not experienced... You'd be VERY generous to build a 18.1 from your docker with the sandboxed gms patches for Pixel 4 (flame). That would be very kind of yours !! Thanks in advance
aibos said:
I'm very very sorry.. I have troubles building.. in fact I never got a build to succeed and didn't need much custom work anyway. But this one from your docker, I tried for two days, and there are always errors as I'm not experienced... You'd be VERY generous to build a 18.1 from your docker with the sandboxed gms patches for Pixel 4 (flame). That would be very kind of yours !! Thanks in advance
Click to expand...
Click to collapse
You can install GrapheneOS on Pixel 4, why would you want to use LOS 18.1?
To use VPN Tethering.
I'm pretty sure there are issues with some indexes with some of the following patch files, related to "strings.xml".
0005-gmscompat-Keep-GMS-services-alive-by-converting-to-f.patch
0015-gmscompat-Make-notification-channel-more-user-friend.patch
0016-gmscompat-Improve-foreground-service-notification-UX.patch
I get this error:
Code:
"error: invalid file path 'frameworks/base/core/res/res/values/strings.xml.orig'."
I dont know how to troubleshoot this. Any suggestion/fix?
Hello. Trying to do this same thing to lineage 19 for pixel 5....I can just merge this code into my repo and build?
Must you have signature spoofing for SPS?
It's sad when a talented dev disappears.. :'(
I am trying to take up where he left off. I will be attempting to patch this into Lineage 19 when I get off of work tonight.
That's why it's sad when a talented dev disappear...
Because then, nothing happens
Linking previous about GMS_Comapt by @sn00x here: https://forum.xda-developers.com/t/sandboxed-play-services.4341085/
I'd talks with GrapheneOS dev on twitter and reproducing them here for more insights:
> Can gms_compat be made available to use by everyone? I really want that to be implemented on LineageOS but that's not possible as they straight away rejected the request.
Is gms_compat device specific? If not, can it developed as a Magisk moduleso that installing that allows users to install GApps without actually flashing them in the first place?
Thank you.
> it's not device specific at all
> it could be easily ported elsewhere at least once the changes are squashed
> Can you elaborate a bit about these in case of the time permits? Squashing changes? You mean merging of commits?
> https://github.com/GrapheneOS/platform_libcore/commit/8d4383d15f9baed7665dbb459b29567e729b166d
> here's the simplified libcore changes, for example
> will be doing frameworks/base next
> Sandboxed Google Play compatibility layer (gmscompat):
Add support for loading DEX files from "/proc/self/fd" APK paths · GrapheneOS/[email protected]
Needed to load code from the Google Play services' Dynamite APK modules, which are available only by the file descriptor reference.
github.com
gmscompat: linker: Add support for opening zip files by fd paths · GrapheneOS/[email protected]
In some cases, it can be useful to load libraries from zip files that are only available by fd reference. For example, file descriptors of APKs containing native libraries may be sent via Binder IP...
github.com
add GmsCompat app · GrapheneOS/[email protected]
Make Build System (being phased out upstream). Contribute to GrapheneOS/platform_build development by creating an account on GitHub.
github.com
gmscompat: add compatibility layer for unprivileged GMS · GrapheneOS/[email protected]
Originally authored by Danny Lin <[email protected]> for inclusion in GrapheneOS. It has since been substantially extended and rewritten by Dmitry Muhomor <[email protected]> (pr...
github.com
gmscompat: support for Dynamite modules · GrapheneOS/[email protected]
Authored by Danny Lin <[email protected]> and Dmitry Muhomor <[email protected]> for inclusion in GrapheneOS. Commit history: Before June 2022: https://github.com/GrapheneOS/pl...
github.com
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat
https://github.com/GrapheneOS/platf...mmit/550842c62ac693234b38fcaa0ed30692fae1873b
do not allow disabling GmsCompat app · GrapheneOS/[email protected]
Apps will break if it's disabled, handling this case in code increases complexity unnecessarily.
github.com
gmscompat: Add ConnectivityManager hook for baseline compatibility · GrapheneOS/[email protected]
This is part of GmsCompat's baseline compatibility for unprivileged Google Play Services. Change-Id: I3e87706f1f3b87c0af9d00f6ce92144469596f8c
github.com
gmscompat: restart GMS processes when permission gets granted · GrapheneOS/[email protected]
Contribute to GrapheneOS/platform_packages_modules_Permission development by creating an account on GitHub.
github.com
gmscompat: Add WifiManager hooks for baseline compatibility · GrapheneOS/[email protected]
This is part of GmsCompat's baseline compatibility for unprivileged Google Play Services. Change-Id: I2f56a47a6a732d6a73531c7f80aca69065a88c38
github.com
gmscompat: allow harmless COLUMN_NOTIFICATION_CLASS · GrapheneOS/[email protected]
Contribute to GrapheneOS/platform_packages_providers_DownloadProvider development by creating an account on GitHub.
github.com
Pixel eSIM management app integration:
https://github.com/GrapheneOS/platf...mmit/be60cb05013a1fb61675f21c705ddbef296f221a
https://github.com/GrapheneOS/platf...mmit/4c4a2f0df9c53eaf22b7add0305f0bfaac46695c
> this is the list of commits now
> after it has been squashed / cleaned up
> Thank you very much for more detailed info. I'll try my level best analyse and learn from these.
Based on this, I believe that, instead of making GMS_Compat just available for LineageOS, we can make it a module that can be flashed wither with Magisk or Recovery making it available for everyone as it is **NOT** device specific..
@sn00x This is awesome!
Has anyone tried this with lineage 19 ?
Also do OTA updates work?
Hi, I am trying to build a rom and wanted to include the graphene os sandboxed google play. I have never built a rom before, do I need to sync your repo into one of the folders where I have my rom files?
Not sure if this is relevant, but I am trying to build for AOSP for Sony Xperia
GMScompat is a big joke and just a fig leaf: Making Googleapps third party apps does not do much, except for giving user a false sense of security. As long as you install GMS framework and apps, they use intents to interact with AOSP, as well as system processes to do what they were designed to do - to spy on users.. The only way to remove such intents is to modify those application's sources, which is NOT possible, because they are closed source.
optimumpro said:
GMScompat is a big joke and just a fig leaf: Making Googleapps third party apps does not do much, except for giving user a false sense of security. As long as you install GMS framework and apps, they use intents to interact with AOSP, as well as system processes to do what they were designed to do - to spy on users.. The only way to remove such intents is to modify those application's sources, which is NOT possible, because they are closed source.
Click to expand...
Click to collapse
Why is this a joke? You are completely missing the point of what gmscompat is trying to achieve: to make using gms more private and secure. The best example is that with gmscompat google cannot access device identifiers auch as imei for example. Plus, as the name suggests, google cannot escape the app sandbox anymore. it doesn't have any special permissions anymore. speaking of permissions, you can revoke any permission of the google apps thanks to gmscompat.
as i am totally intersted into this subject using and following every rom that implement this feature ( sparkos voltageos yaap os etc)
recently the gmscompat fail to start and from my search thegraphene os team make it more difficult to launch needs frequent update of gmscompat.apk and config which is nesserory to make it work
from the bigining the grahene os team doesnt want to make it to other than thier os and pixel devices
drsanusi said:
as i am totally intersted into this subject using and following every rom that implement this feature ( sparkos voltageos yaap os etc)
recently the gmscompat fail to start and from my search thegraphene os team make it more difficult to launch needs frequent update of gmscompat.apk and config which is nesserory to make it work
from the bigining the grahene os team doesnt want to make it to other than thier os and pixel devices
Click to expand...
Click to collapse
When I was using Poco F3 I had SparkOS installed as a "warmup" for Pixel and GrapheneOS. The ROM is a good replacement for anyone who wants this experience of sandboxed play services, but it lacks a lot of stuff from the GrapheneOS. And also it lacks polished default apps. Thankfully you can disable them and install your own though...
hellcat50 said:
Why is this a joke? You are completely missing the point of what gmscompat is trying to achieve: to make using gms more private and secure. The best example is that with gmscompat google cannot access device identifiers auch as imei for example. Plus, as the name suggests, google cannot escape the app sandbox anymore. it doesn't have any special permissions anymore. speaking of permissions, you can revoke any permission of the google apps thanks to gmscompat.
Click to expand...
Click to collapse
Permissions and intents are contained in app's Manifest, as well as in app's code. Google certificates, which recognize Gapps as native are in AOSP code. So, regardless of where the app is installed, it can go around 'compatibility' layers and do their thing, i.e. collect user data.
The only proper way to get rid of higher level permissions is to modify Gapps' code, which is impossible.
optimumpro said:
Permissions and intents are contained in app's Manifest, as well as in app's code. Google certificates, which recognize Gapps as native are in AOSP code. So, regardless of where the app is installed, it can go around 'compatibility' layers and do their thing, i.e. collect user data.
The only proper way to get rid of higher level permissions is to modify Gapps' code, which is impossible.
Click to expand...
Click to collapse
Sorry but i call bs on that. Do you have any sources to claim that?
hello world
unfortunately one sees more and more so called 'custom roms' including GApps by default
this brings up a question: is this legal?
as an example reading:
Google apps are the proprietary Google-branded applications that come pre-installed with most Android devices, such as the Play Store, Gmail, Maps, etc. Due to licensing restrictions, these apps cannot come pre-installed with LineageOS and must be installed separately. The Google apps are not required to boot or run LineageOS, however many users find them beneficial to take full advantage of the Android ecosystem.
Click to expand...
Click to collapse
SOURCE: https://wiki.lineageos.org/gapps
or something like this:
Take note that Open GApps does not provide you with any license for Google’s APKs included in the package. The Open GApps packages merely provide a convenient way to sideload APKs to your device. It is your own responsibility to obtain the proper permissions by e.g. buying an OHA-licensed device with pre-installed Google Apps and/or acquiring the applications from Google’s Play Store.
The pre-built packages from OpenGApps.org are provided ONLY as courtesy by OpenGApps.org without warranty of ANY kind, under the terms that they can be freely used for personal use only, and are not allowed to be mirrored to the public other than OpenGApps.org.
Click to expand...
Click to collapse
SOURCE: https://opengapps.org/#aboutsection
one can even read:
Custom ROM developers, however, can’t easily bundle these Google apps and services with their builds. As these apps are not using the Apache or GPLv2 license, bundling them within the ROM presents legal challenges.
Click to expand...
Click to collapse
SOURCE: https://www.xda-developers.com/download-google-apps-gapps/
as i am not an expert i hope this post can help to answer the question.
furthermore it will help to create some kind of orientation.
Hmm...
As far as XDA is concerned. We allow gapps in ROM.
The gapps thing was between Cyanogenmod and Google.
It's legal to run those apps on devices whose manufacturers signed up with Google.
On other devices, it was not allowed by Google
CyanogenMod had a device that was not CTS compatible so they received DMCA which prevented them from distributing ROMs with gapps.
So it depends on whom you are asking.
You can argue, "If you have purchased a device and the manufacturer has paid a license to run Gapps then you can run those gapps on your device. "
or you can argue "Google has allowed you to run gapps only on firmware approved by google so you shouldn't run gapps"
Regardless they have systems in place to prevent you from not using apps like Gpay via PlayIntegrity/SafetyNet.
@karandpr
the vast majority of all xda-topics are about:
gpay/safetynet not working help urgent now!!!
so one can asume, it ist prevented by g and so not legal
please be so kind and help me find one so called 'custom-rom-gapps-included'
that can provide a proper licensed gapps
Tom Mix said:
@karandpr
the vast majority of all xda-topics are about:
gpay/safetynet not working help urgent now!!!
so one can asume, it ist prevented by g and so not legal
please be so kind and help me find one so called 'custom-rom-gapps-included'
that can provide a proper licensed gapps
Click to expand...
Click to collapse
You can still access play store to download apps.
You can use apps that don't use SafetyNet.
Just because apps throw attestation failure doesn't mean it is illegal to run gapps.
SafetyNet | PlayIntegrity matches device firmware and root status.
Once you unlock Bootloader ,SafetyNet can flag it as Unsafe.
This is an old article on how safetynet works but the base of how it works is similar.
SafetyNet: Google's tamper detection for Android · Yiannis Kozyrakis ~ blog
thoughts on mobile security
koz.io
Technically SafetyNet is an API that is used by other apps to detect whether phone is rooted/BL unlocked or not.
Let's say you have a BL locked phone which runs Stock Android 13, and then you have a BL Unlocked phone which runs the same firmware.
However, in the later case SafetyNet will throw attestation failure.
Thats how safetynet is supposed to work./
I found a quite old article but it explains why the majority of AOSP ROMs are licensed when flashed onto compatible devices.
There are two kinds of Android forks - 'compatible' and 'non-compatible'. 'Compatible' Android forks are those that are based on the Android Open Source Project (AOSP); comply with the Android Compatibility Definition Document (CDD); and pass the Compatibility Test Suite (CTS).
'Compatible' forks may or may not include Google apps (gApps) or Google Play Services, but, because they're 'compatible', gApps and Play Services can be sideloaded or added later by users, meaning they can participate fully in the Play app ecosystem. Examples include CyanogenMod and the MIUI OS.
Google-certified CyanogenMod phones Oppo N1 and the OnePlus one have passed Google’s CTS and CDD, meaning that they officially run Google's apps and access the Google Play Store out of the box.
'Non-compatible' forks are built on AOSP, but are built to run their own ecosystems. Examples of 'non-compatible' Android devices include the Amazon Fire phone and the Blackphone with PrivatOS.
source: https://deviceatlas.com/blog/android-forks-why-google-can-rest-easy-for-now
As I understand, CyanogenMod haven't lost a lawsuit, they simply stepped back preventive of the power of Google.
My conclusion, if one is able to install GMS/Play Services, the device is compatible - hence legal.
@alecxs
very interesting article at deviceatlas! thanks for the link
the most interesting part is:
Custom ROM-makers like Cyanogen aren’t OEMs, so the same rules don’t apply to them – passing the CTS, compliance with the Android CDD. If the custom ROM is flashed onto a ‘compatible’ phone, then everything is gravy… except for the pesky issue of Google apps, which need to be licensed. Cyanogen found this out the hard way in 2009, when Google slapped lead developer Steve Kondik with a Cease and Desist letter, the gist of which was that he wasn’t licensed to distribute Google apps with CyanogenMod.
Click to expand...
Click to collapse
indeed no lawsuit just:
ingenious solution: users could Google-ify their CyanogenMod installations by backing up the Google parts already on their phones, and reactivating them after installation – without incurring Google’s wrath.
Click to expand...
Click to collapse
so flashing afterwards is okay, but not distributing with custom-rom
All those post sound to me like Liability Notices that if you use Gapps. They are not liable for any of the content given or damage to you. So They don't get sued for content you download from it or basically any liability that could develop. In so many words. You can't sue them if you use the unlicensed apps and the content creators can't sue them and have to sue you the user instead if you obtain from their service paid content. So idk. If you want the answer to this I'd call a lawyer or just don't use Google services and avoid all apps that require the use of Google and you shouldn't have a issue.
Tom Mix said:
so flashing afterwards is okay, but not distributing with custom-rom
Click to expand...
Click to collapse
both is fine on compatible forks.
@alecxs
maybe it is a language-barrier on my side but the article
and the other sources state that it cant be bundeled,
though flashed afterwards
even the g-lawyers said no! and bundled distribution was omitted.
and regarding LOS in particular one can assume that
the distribution of 'LOS-roms' including gapps is not allowed
Tom Mix said:
even the g-lawyers said no! and bundled distribution was omitted.
Click to expand...
Click to collapse
It doesn't matter what google lawyer says. As long as there is no court verdict nothing prohibits you to bundle gapps for compatible devices.
I payed for all my modding software from google. the programers are msging the google is a bumb bussness on playstore. really about playstore its got other investments not everyone 2$ 4$ app people. Ill creep my mods with luck on my shoulder tweaken on my stuff. lol sick