PHONE_STATE permission chained

[J316]

It looks like the phone/android.intent.action.PHONE_STATE and the calling/android.intent.action.NEW_OUTGOING_CALL permissions are chained between apps. I try to explain, let's say I have 5 apps using the PHONE_STATE permission, I deny it for 1 of them, then, when I get a phone call XPrivacy processes the 5 intents in this order (allow, allow, deny, allow, allow). The result is the first two apps can see the number I've been called by, the third can't, because I restricted it, but the forth and the fifth see the defaced number the third app has been fed with, so it's like they are restricted too. The same goes when I call. I hope it's clear.

[M66B]

Please provide a logcat of this with XPrivacy debugging enabled.

[J316]

This shows exactly what I described, I called the number 000000 for testing purpose, only one app was restricted, but all the apps processed after that were fed with those defaced data.

[M66B]

Does XPrivacy run in AOSP or compatibility mode?

[J316]

AOSP

[J316]

It looks like the same applies for contacts, in particular I get empty contact list in Viber app, like I have no contacts saved at all

[Tragen]

Does this happen on 3.6.x only or also on older versions?

[M66B]

I have changed the code to block the intents instead of changing the phone number to fix this problem. There is no other way of doing this, but the result is the same, an application cannot see your phone numbers.

Could you please check if this version solves the problem:
https://crowd.xprivacy.eu/XPrivacy_3.6.1-1.apk

The contact restriction is handled in another way, so I don't think this problem applies to contact restrictions (unless you restrict contacts for the contacts application/service itself).

[M66B]

@Tragen: this will happen in any version 3.x

[J316]

It works, at least for outgoing calls, I didn't try for incoming calls. Now the restricted apps are not fed with fake data but with empty data

[J316]

Will be possible in the future to keep feeding apps with fake data?

[M66B]

Not for these two restrictions.