-
Notifications
You must be signed in to change notification settings - Fork 527
Possible account info leak #75
Comments
You are right, it should be move to 'before'. |
Unsure how to test, but I had a look, and as I understand this would fix it? (I might be mistaken)
|
While it might work as a quick fix, I don't think it's the proper way to do it. Some notes:
As for moving everything else to "before" instead of "after", theoretically that would be good. For synchronous calls (excluding the listener scenarios) that are to be blocked/faked, I'm not sure if calling the original method and spoofing the results afterwards is safer (semantics-wise) than faking the values upfront and not even bother calling the original method. |
Will be fixed in version 0.35 |
I haven't reproduced this yet (I'd need to code an app to try it) but looking at the code I think there's a missing check.
When XAccountManager hooks [addOnAccountsUpdatedListener](http://developer.android.com/reference/android/accounts/AccountManager.html#addOnAccountsUpdatedListener%28android.accounts.OnAccountsUpdateListener, android.os.Handler, boolean%29), it doesn't prevent the listener to be registered as it's merely overriding the result to null after the call, which it already was the original result (void).
If an app registers a listener it will still receive the accounts changed after that, and if updateImmediately is true then it will receive the current list.
Sorry if this is already covered by the other hooks, but looking at both XPrivacy and the AccountManager code, it doesn't look so.
The text was updated successfully, but these errors were encountered: