getRunning*/getRecentTasks: return own package

[Vankog]

v. 3.9.17 NVidia Shield Tablet, Stock KitKat v. 4.4.4

After updating from 3.6.9 to 3.6.16 (also 17), several apps began to crash when starting them. Having a look at the stack traces indicated some diverse problems, but all seem to suddenly miss some component or initializations. One app even stated that it could not find its own package. All these apps have in common that the solution was to disable the blocking of getRunningAppProcesses, getRunningTasks and getRecentTasks. Whitelisting the apps to themselves did not work.

So I think the functions stopped to provide the calling app's own packages, processes and tasks when active in XPrivacy.

Apps with this problems I remember: Airdroid, link bubble, App Deals (com.laurencedawson.app_deals) Most only needed to unblock getRunningAppProcesses. Link Bubble also needs the other two I mentioned above and only silently crashes when loading a URL.

I am not sure about getRunningServices. Until now no app complained about this so far, but who knows.

[M66B]

Nothing has been changed to these restrictions since 3.6.9: https://github.com/M66B/XPrivacy/commits/master/src/biz/bokhorst/xprivacy/XActivityManager.java

getRecentTasks/getRunningTasks/getRunningAppProcesses never returned the own package: https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/XActivityManager.java#L145

So, I will make this a feature request.

[Vankog]

Well it was just an educated guess about what might be going wrong here, nothing more. It might be something totally different that's just connected with these functions. I think you are the expert for this and you can assess what's going on here better than anyone else could.

The problem is that right after updating XPrivacy this issue began. Some of the apps start on boot, so I know for sure. Nothing else changed that moment. So something in the changes seem to have caused these crashes.

[Vankog]

Just realized something: I am not in AOSP mode any more: https://github.com/M66B/XPrivacy/issues/2213

Maybe that is the reason why the behaviour of these functions changed for me?

[Vankog]

OK I found the source of the issue. I it is indeed the swap to compatibility mode that I hadn't been realizing since yesterday.

The problem is that strangely the templates between the two modes are completely different, even for the same function names: In compatibility mode the mentioned functions are checked. https://goo.gl/photos/n8FrDGCRaVvsdQAu5

In AOSP mode the these functions are disabled. https://goo.gl/photos/b2zTqHSu7Zgnqt3e6

After updating XPrivacy from version 2 to 3 back then, I probably did not realize that there were these changes made to the template. So when XPrivacy switched to compatibility mode after updating it lately, I also didn't realized these functions hadn't been checked so far and thus suddenly some apps complain.

Is there a way to synchronize the templates and the app entries between the modes? I guess the manual way is quite tedious.

However, the whole premise still exists and it really would make sense to return the own packages, tasks and services for these functions.

[yilksd]

I also have this problem. Many apps fc due to getRunningAppProcesses not returning their own packages. Apps with this problems I remember:Baidu map,Uber. Could you please add this feature?