Room for cerberus's android

12:01 AM

@terdon Hmm OK. I would like it to be as reliable as possible, even when I'm rapidly switching between applications.

I don't want to leak data because Xprivacy's database wasn't edited when I switched to Google Maps, then quickly to some other app.

terdon

@Cerberus That is out of the question. Nothing you are doing here could "leak data"

And there is basically no difference between the two approaches. One is simply easier to read.

tchrist

Wait, you're hacking the privacy database so you can run Google Maps? Like why?

Cerberus

@terdon No, what I mean is, eventually Tasker must modify Xprivacy's database to allow and restrict permissions dynamically. For example, Google Maps will be allowed to see my location when it is in the foreground, but not otherwise.

terdon

@Cerberus Ah, I see. Still, I wouldn't worry about this. The two approaches are equivalent.

Cerberus

If Tasker doesn't know when Maps is in the foreground, because the script is too slow or unreliable, then it will make modifications to the database at the wrong time, or to the wrong app's entries.

@terdon Ok if you say so.

I already saw one entry for my launcher, even though the task is not supposed to see the launcher. So the script must have seen the launcher mCurrent or mFocused when in fact Maps or some other app was opened.

That is: Tasker should only trigger the script when a handful of selected apps are opened / in the foreground, such as Maps.

The problem may lie with Tasker's triggers, they may be too slow or too fast.

But I'd rather have everything I can improve to be super reliable and/or fast.

terdon

12:09 AM

@Cerberus It sees that when 1) you're at the home screen; 2) you're switching between apps. Either when all aps are shown or while one or the other is loading.

Cerberus

@terdon Switching between apps, as in the task switcher? Tasker should not be triggered when the task switcher opens; and the task switcher should have a different name from that of the launcher, since I use a custom launcher but the default task switcher.

terdon

@Cerberus NO, I just meant that it will return the name, pid and uid of the launcher when switching between apps. Also when looking at the task switcher ifI remember my quick test.

I don't know why it would have triggered but I don't know how you're triggering it.

I really should be going to my "Greek bed" though, so perhaps we could have a look tomorrow and you can show me the entire thing.

Night all!

Cerberus

@terdon I use Tasker's standard context triggers: "as soon as app x is opened, do task y". But of course I have no idea how Tasker does that.

@terdon But why the home screen, which is made by Tesla (Nova Launcher), when LG's default task switcher is active?

So it could be that I switch away from Maps so quickly that the trigger goes off when I open Maps, but the task/script is executed 100ms later, when I have already switched to the home screen.

tchrist

Again, why so much work to get the UID? Isn't it your UID? Is something running suid?

Cerberus

@terdon Sleep well en sôi lechei Achaiôi!

@tchrist Not sure what you mean, but this is what I need:

1. I open Maps.

2. Xprivacy allows location permission to Maps.

3. I switch to a different application.

4. Xprivacy disallows same.

tchrist

12:18 AM

In a bash shell script, $UID is the user id of the current user.

And I think your shell script will have the same UID as Google Maps will have.

I don’t what user ids Android runs stuff as.

Usually all user processes will be owned by the logged-in user.

Cerberus

@tchrist I don't think it stands for user identifier in this case?

Unique Identifier, perhaps?

This is the manual to Xprivacy's database: github.com/M66B/XPrivacy/blob/master/DATABASE.md

But apparently the Unique IDentifier of an application is not specific/limited to Xprivacy.

Or I wouldn't be able to get it from an application using a shell thingy, independent of Xprivacy.

tchrist

I don't think so.

I think it's User ID.

Because that's what you're fetching from the /proc/PID/status file.

Cerberus

12:35 AM

@tchrist Am I?

@tchrist I don't believe the User ID is what I get from Terdon'd script, nor is it what I need to use in Xprivacy's database.

I have tried using the "UID" to alter the database, and it worked as intended: it altered the permissions for Maps, as I wanted.

> com.amazon.venezia
com.teslacoilsw.launcher
com.google.android.apps.maps

nl.blendle.app
com.here.app.maps
com.google.android.apps.maps
com.teslacoilsw.launcher

com.amazon.venezia
com.android.chrome
com.google.android.apps.m4b

com.amazon.venezia
com.android.chrome
com.here.app.maps
com.google.android.apps.maps

com.amazon.venezia
nl.blendle.app
com.android.chrome
com.here.app.maps
com.google.android.apps.maps

tchrist

Hm.

They may be assigning different user ids to different services.

grep Uid /proc/*/status

Cerberus

@terdon I have put 6 apps on my home screen and opened them all in succession. I have repeated that 5 times. The Tasker task with the script should have been triggered in each instance for each app, but, as you can see it only write some of them to file. You see 3 4 3 4 5, where you *should* see 6 6 6 6 6. So there is *something* that is being extremely unreliable.
It's probably not your script. It could be something in Android (Android doesn't supply the right data to dumpsys, as when it does mCurrentFocus=null), or it could be something in Tasker. Any idea what I could try to diagnose or …

@tchrist Should I try to run that?

tchrist

Well maybe. I'm curious to see if there are different Uids in use.

Might add name.

egrep 'Name|Uid' /proc/*/status

Cerberus

12:50 AM

@tchrist That works!

I get 10106 with a shortened name for Maps.

tchrist

I would hope so. Did different program names have different uids?

Cerberus

> /proc/9048/status:Name: ere.App.Service
/proc/9048/status:Uid: 10182 10182 10182 10182
/proc/9136/status:Name: droid.apps.maps
/proc/9136/status:Uid: 10106 10106 10106 10106

An excerpt.

tchrist

So yes.

Cerberus

Sure.

Just as they should.

Cerberus

2:57 AM

@terdon Okay, I think I know the cause of the unreliability I mentioned above: Tasker checks whether a new application is launched only once every 1,5 seconds by default.

So if you switch away from an application too fast, it may not even register that the app was ever opened.

I can set that to a shorter interval, like 0,5 seconds, but at the cost of some battery use, so says Tasker. And perhaps also some performance?

Or I could decide that permissions don't need to be given to an application that is closed within 1,5 seconds.

tchrist

er

Right, but we're speaking English I thought? :)

Cerberus

@tchrist Are we not?

Is what I said unclear?

tchrist

I know you know you can't use commas that way in English.

Or programming.