So, the current set of patches are rather monolithic blobs that are uncomprehensible. What about splitting the patches? I have some scripts on https://github.com/Lekensteyn/PDroid-AOSP-JellyBean that do this.

Hi Mateor,

thank you for all your great work!

I'm trying to build cm11 from source with openpdroid patches.
For Nexus 5 it works fine.
Unfortunately it doesn't work for LG G2 (d802).
below is the log.
Can you help me?
Thank you!

root@ubuntu:~/android/system# . build/envsetup.sh; brunch d802
including device/generic/armv7-a-neon/vendorsetup.sh
including device/generic/goldfish/vendorsetup.sh
including device/generic/mips/vendorsetup.sh
including device/generic/x86/vendorsetup.sh
including vendor/cm/vendorsetup.sh
including sdk/bash_completion/adb.bash
including vendor/cm/bash_completion/git.bash
including vendor/cm/bash_completion/repo.bash
including vendor/cm/vendorsetup.sh
Looking for dependencies

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.4.2
CM_VERSION=11-20140430-UNOFFICIAL-d802
TARGET_PRODUCT=cm_d802
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.11.0-19-generic-x86_64-with-Ubuntu-12.04-precise
HOST_BUILD_TYPE=release
BUILD_ID=KVT49L

OUT_DIR=/root/android/system/out

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.4.2
CM_VERSION=11-20140430-UNOFFICIAL-d802
TARGET_PRODUCT=cm_d802
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.11.0-19-generic-x86_64-with-Ubuntu-12.04-precise
HOST_BUILD_TYPE=release
BUILD_ID=KVT49L

OUT_DIR=/root/android/system/out

/root/android/system/out/target/product/d802/obj/APPS/SignatureTest_intermediates
find: src': No such file or directory build/core/copy_headers.mk:15: warning: overriding commands for target/root/android/system/out/target/product/d802/obj/include/qcom/display/copybit.h'
build/core/copy_headers.mk:15: warning: ignoring old commands for target /root/android/system/out/target/product/d802/obj/include/qcom/display/copybit.h' build/core/copy_headers.mk:15: warning: overriding commands for target/root/android/system/out/target/product/d802/obj/include/qcom/display/copybit_priv.h'
build/core/copy_headers.mk:15: warning: ignoring old commands for target /root/android/system/out/target/product/d802/obj/include/qcom/display/copybit_priv.h' PRODUCT_COPY_FILES device/sample/etc/apns-full-conf.xml:system/etc/apns-conf.xml ignored. build/core/Makefile:44: warning: overriding commands for target/root/android/system/out/target/product/d802/system/etc/permissions/android.software.live_wallpaper.xml'
build/core/base_rules.mk:529: warning: ignoring old commands for target /root/android/system/out/target/product/d802/system/etc/permissions/android.software.live_wallpaper.xml' build/core/Makefile:44: warning: overriding commands for target/root/android/system/out/target/product/d802/system/lib/libcnefeatureconfig.so'
build/core/base_rules.mk:529: warning: ignoring old commands for target /root/android/system/out/target/product/d802/system/lib/libcnefeatureconfig.so' build/core/Makefile:44: warning: overriding commands for target/root/android/system/out/target/product/d802/system/lib/libril.so'
build/core/base_rules.mk:529: warning: ignoring old commands for target /root/android/system/out/target/product/d802/system/lib/libril.so' build/core/Makefile:44: warning: overriding commands for target/root/android/system/out/target/product/d802/system/bin/rild'
build/core/base_rules.mk:529: warning: ignoring old commands for target /root/android/system/out/target/product/d802/system/bin/rild' No private recovery resources for TARGET_DEVICE d802 make -C kernel/lge/msm8974 O=/root/android/system/out/target/product/d802/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE=" /root/android/system/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-" VARIANT_DEFCONFIG= SELINUX_DEFCONFIG= cyanogenmod_d802_defconfig make[1]: Entering directory/root/android/system/kernel/lge/msm8974'
Copying: /root/android/system/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes-jarjar.jar
Import includes file: /root/android/system/out/target/product/d802/obj/SHARED_LIBRARIES/libandroid_runtime_intermediates/import_includes
GEN /root/android/system/out/target/product/d802/obj/KERNEL_OBJ/Makefile
net/ipv6/Kconfig:260:warning: multi-line strings not supported
target thumb C: dhcpcd <= external/dhcpcd/arp.c
target thumb C: dhcpcd <= external/dhcpcd/bind.c
target thumb C: dhcpcd <= external/dhcpcd/common.c
target thumb C: dhcpcd <= external/dhcpcd/control.c
target thumb C: dhcpcd <= external/dhcpcd/dhcp.c
drivers/power/Kconfig:570:warning: leading whitespace ignored
target thumb C: dhcpcd <= external/dhcpcd/dhcpcd.c
target thumb C: dhcpcd <= external/dhcpcd/duid.c
target thumb C: dhcpcd <= external/dhcpcd/eloop.c
target thumb C: dhcpcd <= external/dhcpcd/if-options.c
target thumb C: dhcpcd <= external/dhcpcd/if-pref.c
target thumb C: dhcpcd <= external/dhcpcd/ipv4ll.c
target thumb C: dhcpcd <= external/dhcpcd/net.c
target thumb C: dhcpcd <= external/dhcpcd/signals.c
target thumb C: dhcpcd <= external/dhcpcd/configure.c
target thumb C: dhcpcd <= external/dhcpcd/if-linux.c
target thumb C: dhcpcd <= external/dhcpcd/if-linux-wireless.c
target thumb C: dhcpcd <= external/dhcpcd/lpf.c
target thumb C: dhcpcd <= external/dhcpcd/compat/getline.c
drivers/video/backlight/Kconfig:371:warning: leading whitespace ignored
target thumb C: dhcpcd <= external/dhcpcd/platform-linux.c
target thumb C: dhcpcd <= external/dhcpcd/compat/closefrom.c
target thumb C: dhcpcd <= external/dhcpcd/ifaddrs.c
target thumb C: dhcpcd <= external/dhcpcd/ipv6rs.c
Symlink: /root/android/system/out/target/product/d802/system/bin/dump.f2fs -> /system/bin/fsck.f2fs
Copy: /root/android/system/out/target/product/d802/system/bin/rild
Copying: /root/android/system/out/target/common/obj/JAVA_LIBRARIES/core-libart_intermediates/classes-jarjar.jar

configuration written to .config

make[1]: Leaving directory /root/android/system/kernel/lge/msm8974' make: *** No rule to make targetvendor/lge/d802/proprietary/lib/hw/camera.msm8974.so', needed by `/root/android/system/out/target/product/d802/system/lib/hw/camera.msm8974.so'. Stop.
make: *** Waiting for unfinished jobs....
root@ubuntu:~/android/system#

i dont know the first thing about android. dont know its APIs -never did an app-, the design of the OS, and especially i dont know the security model. so all of this is complete guesswork.

i tried to make sense of the context mess we talked about before, and this is what i guessed:

the context refers to an execution unit of a certain granularity, say a process or a thead. the current context provides info to determine such things as permissions of the currently execuiting unit. the outer context provides similar info of the unit on whose behalf this unit is executing. normally a unit would be executing on its own behalf, but interunit dispatching or creation could set the outer context to the parent unit.

a very bad example: a system service that copies files. it runs with elevated privileges but when invoked it voluntarily restricts its rights to those of the caller, to restrict IO to only those files the caller can access. the service could explicitly check permissions on its outer context, or it could impersonate that context during IO system calls and let the IO subsystem manage access permissions.

why isnt there a complete invocation chain and only one outer context? IDK. is outer the immediate parent or the root? IDK, i would guess the root.

and what is staticOuterContext? seems to be a messy dangerous hack to obtain "some" context when the current context is not easily accessible. we should eliminate this hack.

some android services need the current context to enforce their policies and/or do their work. yet some others need the outer context.

there is total confusion in context use in OPD. the three contexts are used seemingly at random for determination of applicable OPD settings and for runtime services, and even to forward to the underlying android service from the surrogate classes. i've cleaned up all this for surrogates invoked from frameworks/base (only those). i fixed a bug around LocationManager. i seem to remember there is a long standing bug in OPD regarding location services that couldnt be found. i dont know its symptoms, but maybe it was this one, you should try and see if its fixed.

the cleanup i did according to these points:

A)
proposed surrogate class constructor convention:

constructors of surrogate classes should be of the form:

public final class PrivacyXXX extends SuperClass {

/** {@hide} */
public PrivacyXXX(Context privacyContext, IPrivacySettingsManager privacyService, ...parameters of the super constructor...) {
    super(...parameters of the super constructor...);
    context = privacyContext;
    pSetMan = new PrivacySettingsManager(privacyContext, privacyService);
}

but if the parameters of the super constructor include one called "context", it should be renamed to "serviceContext".

rationale: minimum of changes to existing code. removal of ad-hoc code in surrogate constructors that obscure rebasing upstream changes in ContextImpl.
rules simple to check with only local information. explicit privacyContext makes it easy to change the choice of privacy context in the future.

B)
privacyContext during surrogate construction: should it be the current context or outerContext?

here are proposed rules to deal with what we don't know (very open to discussion). ive applied these in my patch:

1. if the super class takes an explicit context param: use that same context.
   rationale: policy decisions are already being made by android using this context. in the face of our complete ignorance, we could do the same.

2. if the super class does not take an explicit context param: use the current context.
   rationale: services that take the current context are much more common than services that take outerContext. is seems outerContext based policies are the exception.

3. if super takes both contexts: have not seen this, does it happen?

4. if the service is a static service and no current context is available: use staticOuterContext.
   rationale: it is our only choice. this is probably a BUG and these cases should be eliminated.

MAIN RATIONALE: these rules change the behavior of OPD as little as possible, yet patch some bugs. in fact, im very weary of rule 1), but always using the current context would modify the behavior of OPD in ways i do not understand. i want to fix bugs without introducing new ones. i would do a bigger change only after fully understanding android's security model.

PS. ive eliminated staticOuterContext in all surrogates in frameworks/base, but there is still one use of it during the creation of the OPD's own privacy service (not a surrogate). i havent tried to understand that code so far.

C)
why the "IPrivacySettingsManager privacyService" parameter in surrogate constructors?

this is the only change mentioned here above that i didnt do in this patch, because im not completely sure of it, but the current code seems to have a security hole. again, i don't know androids security model at all, so this is guesswork.

take a look at android services, for example ConnectivityManager:

public ConnectivityManager(IConnectivityManager service, String packageName) {
    mService = checkNotNull(service, "missing IConnectivityManager");
    mPackageName = checkNotNull(packageName, "missing package name");
}

the class could create its own service [ using this code: IConnectivityManager.Stub.asInterface(ServiceManager.getService(CONNECTIVITY_SERVICE)) ] but instead it wants to get it in the constructor call as a parameter, and the caller, ContextImpl, creates the service.

anybody could create a ConnectivityManager, its constructor is public, but it wouldnt do a thing unless you pass it a valid IConnectivityManager service. here im guessing ServiceManager.getService() enforces the permissions associated with the current context. ContextImpl is trusted code and can create all the services it wants, then figure out who to hand them out to carefully. but the catch is, ConnectivityManager in also trusted code, and if it created its own service on construction anybody could create their own instance and bypass permission checks. this is why, again im guessing, the service is passed to the constructor.

now look at (the new) OPD surrogates:

public PrivacyConnectivityManager(Context privacyContext, IConnectivityManager service, String packageName) {
    super(service, packageName);
    context = privacyContext;
    pSetMan = new PrivacySettingsManager(context, IPrivacySettingsManager.Stub.asInterface(ServiceManager.getService("privacy")));
    //Log.i(P_TAG,"now in constructor for package: " + context.getPackageName());
}

privacy service creation happens in a public constructor in trusted code, so anyone can create a surrogate and thus its nested privacy service. this might open the system to attacks.

that's why i propose the "IPrivacySettingsManager privacyService" argument in surrogate constructors (see above) and creating the service in ContextImpl instead.

action items in no particular order:

1. test the network location bug (help me here please, i dont know what the bug is about at all)
2. implement the last change pending to frameworks/base surrogates (the privacyService thing), unless theres a reason not to
3. adapt the remaining surrogates used from the other patched git repos
4. understand and eliminate staticOuterContext
5. i suppose privacyContext should always be one specific context irrespective of service. gut feeling is outerContext. research this and test the result of the change. (changing the context OPD uses can completely alter its privacy decisions, either fixing big bugs or creating them. i would need some help to do this.)

btw, for now im still building the patched CM-11 right now....

this commit broke compatibility:

CyanogenMod/android_frameworks_base@fe9b529

by changing CONNECTIVITY_SERVICE from a static service to a context dependent one.

mateor, are you still working on this? would you like to patch this up or should somebody else do it? also, there is code like this:

                // BEGIN privacy-modified
                //return new LocationManager(ctx, ILocationManager.Stub.asInterface(b));
                Log.d(TAG, "PDroid:ContextImpl: returning PrivacyLocationManager");
                // SM: I'm not sure whyt this is using getStaticOuterContext rather than getOuterContext.
                // Would have thought it should have been the following line:
                // return new PrivacyLocationManager(ILocationManager.Stub.asInterface(b), ctx.getOuterContext());
                return new PrivacyLocationManager(ILocationManager.Stub.asInterface(b), getStaticOuterContext());
                // END privacy-modified                    

this led me to look a bit into the code. it seems that ContextImpl.getStaticOuterContext() should always be == ctx since there is exactly one ContextImpl instance per process. is this true? and is ctx.getOuterContext() not always == ctx because somebody calls setOuterContext? it would seem so, otherwise what would be the purpose of xxxOuterContext? can you shed some light on this?

getStaticOuterContext is potentially unsafe. is it me or is OPDs codebase kind of dirty?

Hi,
not sure if this is the best place to ask. If not please redirect me to better place.
I'm looking for a version of a patch that works well with cell location. Ideally for 4.3, 4.2 will do as well.

Hey mateo, FFU5y, wbedard and Lekensteyn,

I've made a bunch of changings to PDroid since the latest Update. It contains a lot of Bug-Fixes and some new features which are (in my Opinion) very useful. I would like to see that we melt together to create ONE Powerful framework where each of us can review the code and discuss new features or changings inside the framework. It makes no sense to split the whole work at the framework and work against. And really, I'm new to GitHub itself but I like the way we can discuss and provide code here. You can find the patches and a partial description of fixed bugs and new features here. I will push the patches to GitHub asap. What I would like to see in the framework:

• Privacy Debugging Bridge (PDB)
• Complete PrivacyCaching (it has so many advantages, please read the post in my thread for more information)
• service connection bug in the central way -> just have a look the patches
• hardcoded default deny mode -> it is ready now, why should we code it again? (it also gives notification to use, like wsot handled it in his preversion. I've updated the whole code to this so you just have to diff your source)
• disabling apps feature -> it works pretty well at all and is very powerful
• task killing -> I use it every day and it is better than going to every app and force-close it
• FailSafeMode -> I think it is a nice feature, but not mellowed and optional to include. If you want to improve it, feel free to provide Code

Please let me know what you think about the new features and the idea of one PDroid framework*. If you have any questions to the new features of bugfixes, please get in touch with me :-)

Hello everyone! I am a Chinese college student,and I would like to add a new function to OpenDroidPatches,I hope that all applications which are new installed get random info,that is a easier way to set pdroidmanager if I install many applications.But I do not know how to do it because I can not find these codes which return deviceid when the deviceid setting is real or no settings.
My device is ZTE-Blade and the android system is cm10.I build the system from cm10 source code.
I have tried many ways but all failed.I am looking forward to getting help from you.
Thank you very much!

Hello,

I'm looking to help contribute to openpdroid patches, and I was wondering what the build process is.

For example:

How do I edit the openpdroid code? which IDE would you guys suggest?
How do I create the patches once i've made changes?

What were the issues that have caused this project to have problems?
What are the future changes that you are looking to implement.

Hello.

First of all, I would like to say that I would love to have the ability to control application permissions on my device. IMO such functionality must be included in the AOSP. Unfortunately, it is not. So I am looking for alternative solutions. OpenPDroid looks like a promising project. Thank you for working on it! (BTW I use Nexus 4 with stock image, I hope you would support patching it one day)

I decided to take a closer look at the sources, just to get an idea of how complex and invasive the modifications are. Obviously, such project touches some core parts of the system and I would like to know that the modifications are sound.

I stumbled upon iptables command check implementation in openpdroid_4.2.1_libcore.patch. I think this check is an ugly hack. Moreover it simply does not work: it cannot catch all uses of iptables and it can detect false uses of iptables. I would definitely not want this particular code running on my system. And now I am trying to understand the reason behind these changes. IMO this code should be removed: it is better not to implement a feature at all than implement it in a way that does not work.

I hope this does not offend anyone. I apologize if it does.

Sorry, if this is a wrong place for the discussion.

Regards,
Dmitry

Currently, a new proxy class is created that inherits the class that is supposed to be protected:

• PrivacyCDMALTEPhone
• PrivacyCDMAPhone
• PrivacyGSMPhone
• PrivacySipPhone
  In these classes, you unconditionally ask PDroid for sanitizing the ID. Read on why this is a bad idea.

The TelephonyManager methods for retrieving things like IMEI call methods on an implementation of the IPhoneSubInfo interface that is retrieved from the iphonesubinfo service.

This is actually a PhoneSubInfoProxy, methods like getDeviceId are called on a PhoneSubInfo instance that was passed through the constructor (or changed with setmPhoneSubInfo as done in PhoneProxy).

I see no point in replacing PhoneProxy instantiations by PrivacyPhoneProxy in PhoneFactory.java as permissions are not checked in the proxy class. They are checked in PhoneSubInfo, where you can see methods like:

/**
 * Retrieves the unique device ID, e.g., IMEI for GSM phones and MEID for CDMA phones.
 */
public String getDeviceId() {
    mContext.enforceCallingOrSelfPermission(READ_PHONE_STATE, "Requires READ_PHONE_STATE");
    return mPhone.getDeviceId();
}

With the current patches, mPhone is the Privacy...Phone instance. Well, why not avoid duplicate code and insert all code in these functions? Those other classes are internal anyway. Also, please keep DRY in mind.

Once the git/review infrastructure is ready, I can send in some patches that simplifies this and makes it less repeating.

A few days ago I installed the Amazon Shop App and disabled all access rights for in in PDroidManager. I figured out, that even though I did this, Amazon can tell me that I own a Xperia tipo. Is this an error or does PDroid not protect this information?!

Hey guys (@ALL OPD/PD2.0 DEVS),

I'm currently trying to learn smali and how to handle with it.
I do that because I will port PD2.0/OPD to Stock ROMs, and I think it is possible.

The last few days I spent a lot of time to understand how to include the PD framework to the original stock framework and yeah, I believe I found a good solution for that.

But to make it easier and possible for me to port PDroid to Stock ROMs it is neccessary trying to follow following "rules":

• If you want to insert code in the framework, put as much code as you can into your OWN methods
• Try to use not so much parameters for one method (good parameter count should be smaller or equal 3)
• Don't blow up the framework methods with your own stuff
• hold the lines at a minimum level if you insert code in the framework which is out of your own methods
• try to use not so much variables

Example (an old piece of code, please ignore style or whatever, just try to understand what I mean):

Bad way:

public void startActivity (Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) {
        // BEGIN PRIVACY
        boolean isAllowed = true;
        try{
            Log.i("PrivacyContext","now we are in execStartActivity() from package: " + who.getPackageName());
            if(intent.getAction().equals(Intent.ACTION_CALL) || intent.getAction().equals(Intent.ACTION_DIAL)){
                Log.i("PrivacyContext","package: " + who.getPackageName() + " tries to take a phone call");
                if(pSetMan == null) pSetMan = new PrivacySettingsManager(who, IPrivacySettingsManager.Stub.asInterface(ServiceManager.getService("privacy")));
                PrivacySettings settings = pSetMan.getSettings(who.getPackageName(), -1);
                if(pSetMan != null && settings != null && settings.getPhoneCallSetting() != PrivacySettings.REAL){ //is not allowed
                    //test if broadcasting works!
                    final Context tmp = who;
                    isAllowed = false;
                    new Thread(new Runnable() {
                        public void run() {
                            try{
                                Thread.sleep(1000); //wait 1 Second
                            }
                            catch(Exception e){
                                //nothing here
                            }  
                            Intent privacy = new Intent("android.privacy.BLOCKED_PHONE_CALL");
                            Bundle extras = new Bundle();
                            extras.putString("packageName", tmp.getPackageName());
                            extras.putInt("phoneState", TelephonyManager.CALL_STATE_IDLE);
                            privacy.putExtras(extras);
                            tmp.sendBroadcast(privacy);
                            Log.i("PrivacyContext","sent privacy intent");
                        }
                    }).start();
                    pSetMan.notification(who.getPackageName(), 0, PrivacySettings.EMPTY, PrivacySettings.DATA_PHONE_CALL, null, settings);
                }
                else{ //is allowed
                    isAllowed = true;
                    pSetMan.notification(who.getPackageName(), 0, PrivacySettings.REAL, PrivacySettings.DATA_PHONE_CALL, null, settings);
                }

            }
        }
        catch(Exception e){
            e.printStackTrace();
             if(who != null)
                 Log.i("PrivacyContext","got exception while trying to resolve intents for package: " + who.getPackageName());
             else
                 Log.i("PrivacyContext","got exception while trying to resolve intents for unknown package");

        }
        // END PRIVACY
        ........
}

Better solution:

public void startActivity (Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) {
        // BEGIN PRIVACY
        boolean isAllowed = enforcePrivacyPermissions(params..);
        ........
        // END PRIVACY
}

private boolean enforePrivacyPermissions(params...) {
         boolean isAllowed = true;
         try{
            Log.i("PrivacyContext","now we are in execStartActivity() from package: " + who.getPackageName());
            if(intent.getAction().equals(Intent.ACTION_CALL) || intent.getAction().equals(Intent.ACTION_DIAL)){
                Log.i("PrivacyContext","package: " + who.getPackageName() + " tries to take a phone call");
                if(pSetMan == null) pSetMan = new PrivacySettingsManager(who, IPrivacySettingsManager.Stub.asInterface(ServiceManager.getService("privacy")));
                PrivacySettings settings = pSetMan.getSettings(who.getPackageName(), -1);
                if(pSetMan != null && settings != null && settings.getPhoneCallSetting() != PrivacySettings.REAL){ //is not allowed
                    //test if broadcasting works!
                    final Context tmp = who;
                    isAllowed = false;
                    new Thread(new Runnable() {
                        public void run() {
                            try{
                                Thread.sleep(1000); //wait 1 Second
                            }
                            catch(Exception e){
                                //nothing here
                            }  
                            Intent privacy = new Intent("android.privacy.BLOCKED_PHONE_CALL");
                            Bundle extras = new Bundle();
                            extras.putString("packageName", tmp.getPackageName());
                            extras.putInt("phoneState", TelephonyManager.CALL_STATE_IDLE);
                            privacy.putExtras(extras);
                            tmp.sendBroadcast(privacy);
                            Log.i("PrivacyContext","sent privacy intent");
                        }
                    }).start();
                    pSetMan.notification(who.getPackageName(), 0, PrivacySettings.EMPTY, PrivacySettings.DATA_PHONE_CALL, null, settings);
                }
                else{ //is allowed
                    isAllowed = true;
                    pSetMan.notification(who.getPackageName(), 0, PrivacySettings.REAL, PrivacySettings.DATA_PHONE_CALL, null, settings);
                }

            }
        }
        catch(Exception e){
            e.printStackTrace();
             if(who != null)
                 Log.i("PrivacyContext","got exception while trying to resolve intents for package: " + who.getPackageName());
             else
                 Log.i("PrivacyContext","got exception while trying to resolve intents for unknown package");

        }
        return isAllowed;
}

i tried many times to patch rom with pdroid but still can't launch the apg launcher for windows and i'm really in need for n7100 rom with pdroid2.0 can u please post a full tutorial on how to setup autopatcher or even send me link for a rom with pdroid patched

Recently I found out that blocking access to logs in pdroid is not secure. Going deeper in this, I found out that more permissions are affected by this. Once an application has been granted a certain permission by Android, it becomes a member of a group.

A list of permissions that are bound to a user ID can be found in https://github.com/android/platform_frameworks_base/blob/master/data/etc/platform.xml Run the following command in frameworks/base to get a list of permissions that are bound to a group:

grep -oP '<permission name="\K[^"]+permission[^"]+' data/etc/platform.xml

Result when doing this on branch cm-10.1:
android.permission.BLUETOOTH_ADMIN
android.permission.BLUETOOTH
android.permission.BLUETOOTH_STACK
android.permission.NET_TUNNELING
android.permission.INTERNET
android.permission.CAMERA
android.permission.READ_LOGS
android.permission.READ_EXTERNAL_STORAGE
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.WRITE_MEDIA_STORAGE
android.permission.ACCESS_MTP
android.permission.NET_ADMIN
android.permission.ACCESS_CACHE_FILESYSTEM
android.permission.DIAGNOSTIC
android.permission.READ_NETWORK_USAGE_HISTORY
android.permission.MODIFY_NETWORK_ACCOUNTING
com.tmobile.permission.ACCESS_DRM_THEME

Running the command grep -E "$(sed 's/\./\\./g' bar | tr '\n' '|' | sed 's/|$//') foo (with bar the above xml extract) on https://github.com/wsot/pdroid-manager gives a list of affected permissions:

• android.permission.CAMERA
• android.permission.READ_LOGS

I am mentioning it here so that nobody becomes surprised that this hole exist. From these two, the logs is the most severe issue here. It is trivial to execute logcat (reading /dev/log/ is trivial as well). I have not looked further at the camera, but with the right libraries it also becomes feasible to abuse the permission.

How much bandwidth does something like this take? I was looking over the AWS free server stuff...think that would cover it?

http://aws.amazon.com/free/

Looking more closely, I think this should cover us.

I am not sure what is on your action list, but I think we should discuss releasing again. The auto-patcher leads me to believe that our current master branch has merge (and therefore build patch) conflicts with three or four classes (GSMServicestateTracker, CDMA ServiceStateTrack, SMSDispatcher and maybe Phone Factory).

I have hot fixes in the form of provisional files (which are simply copies of those smali files as they were when we made the patches. Essentially we have just rolled the offending commits back.) But we should build again. ICS and 4.1 were like this, breaking constantly, that is why the ROM probe getting rid of the patch date argument was such a help.

Since we are producing new builds, I think we may as well release the fixes you have done. I don't known what you have left, probably the SMS bugs. But that COULD be due to the SMSDispatcher merge conflict and might be fixed by rebuilding.

Let me know.

ProcessManager.exec is modified at https://github.com/OpenPDroid/OpenPDroidPatches/blob/4.2.1/openpdroid_4.2.1_libcore.patch#L311

The current modifications are possibly insecure. If taintedCommand[0] == null, a crash occurs. The checks are performed on an array that can still be modified by the caller (timing attacks?)

What is the rationale of changing the command from bash to su if the command is denied? Wouldn't it be better to throw an exception, return null or set the command to false if you want to have a no-op command?

Anyway, the taintedCommand != null lines can be dropped and to increase security, it should be put after the sanity checks and clone (just before setting up file descriptors).

(general question, would you like patches against the source tree or patches for the patches? Incremental or full?)

In frameworks_base/core/java/android/app/Instrumentation.java, there is indentation that use spaces instead of tabs. Let's be consistent and fix that to use tabs.

In my opinion, // BEGIN privacy-added is redundant. git and diff allow you to see easily where changes are introduced and these lines are not always added (for example, some imports and camera code). What about dropping these completely?

Hey guys,

I would like to start the work on merging PD2.0 features into OPD.
Before I will describe some things:

PD2.0 is completely ported by my self and not a fork of OPD

Therefore I think it is a good way to review and compare the whole code and merging the best solutions together. Who would like to help??!

I haven't had a "deep" look at OPD yet, but that is what I can say now:

• Port contains several "normal" and "heavy" porting failures, just like the one in the TelephonyRegistry (I believe it was the cellInfo method)
• We can fix all known bugs with the review, because I can tell you what to do and how to fix or which code you have to copy
• purgeSettings method was never intended to delete the whole database. Please insert a new method to the interface just like "deleteDatabase" and change the code!
• Until now the database is never being closed the whole time (OPD), don't do that! You can fix it with AtomicInteger by increment/decrement for every dataccess and after that automatically close it
• The delete recursively method is more than deprecated and have to change
• ..... I haven't enough time to write down my mind about the framework :-D, I will update this post from time to time.

Hopefully there is someone out there who would like to start with merging.
Furthermore: I will talk with matoe about how to handle it on github.

Cheers

The privacy.x509.pem file in the patch is not used and even if it is used, it is dangerous because the private key is public. See also gsbabil/PDroid-AOSP-JellyBean#1.

Please remove it.

I am going to create a cherry-pickable commits for these patches, I think. The fact that the build patches work for all roms implies to me that this is doable.

That way we can offer several different methods of applying OpenPDroid- build patches, easy cherry-picks, or smali-patches.

I also think that perhaps we could rethink the need for holding so many device trees. But I know you are considering offering manifests. But I think that aosp-jb-mrx branches with squashed release commits would be fine.

As a last note, I am writing a small script that will apply the patches with a single command. It will just apply and remove, spooling to a log so it can find, record, and back out of failed hunks. It should be done this week, not too hard to make, just need to find the time.