Slow: HTTP Request Trigger -> keycode on NVIDIA SHIELD

[MarkerB]

I wanted to control my Nvidia Shield via IP, as part of my integrated remote system.

I have a rooted Shield, and created a flow that captures HTTP Request Triggers and executes a Root Command to send some media keycodes. It all works, but very slowly. Not much faster than the ADB method I was trying to improve upon.

Desmanto suggested in this post that generating keypresses this way could operate at "lightening speed", but I can only send key commands at maybe 2-3 per second, max.

I did change the Automagic response time from 500mS to 50mS, despite the warning about eating too many resources. It helped a little, but not enough.

I've used other devices' HTTP commands without this kind of lag (Yamaha receivers, TVs, etc), so what I'm expecting shouldn't be unreasonable. Maybe the problem is that each keystroke needs to check if the Automagic app has root privledges, since I get that annoying "Automagic has been granted" status message for every keypress?

Am I missing something that could be slowing this down?

Thanks!

[Desmanto]

Sorry for the confusion. When I mean the lightning speed, I mean the time needed from the http post from first device, until it is processed by the device which has the HTTP request trigger. Then, the switching of the keyboard to Automagic keyboard, send the key and switch back to your default keyboard also very fast. Usually it won't take more than 0.1 second, hence very fast.

I tested out the root command input keyevent method and yes it is very slowly, roughly 2-3 keystroke perseconds. Very unacceptable, especially if you want to emulate typing a word or sentence. I usually use/test it for single keystroke, so I don't know about this limitation. For longer word I would use Control UI setText instead.

It seems input keyevent has a very slow processing speed. That means Control UI sendKey() is the only way then. You have use the switching keyboard method.
Set Default Input Method : Automagic Premium (keyboard)
Control UI : sendKey(keyname)
Set Default Input Method : your_default_keyboard

Using this method, you can even emulate typing on the screen (useful for prank or show off), by using a random sleep time in the sentence looping.

Root is needed for Set Default Input Method. You can turn off the toast message for the Superuser log in your root management app. I use magisk, so at the magisk superuser, turn off the toast for Automagic. Automagic accessibility response time can be set as default 500 ms, it won't affect much for the Control UI operation.

[MarkerB]

Sorry for the delay. I thought the board would email me when there was a response to my post. I just found the "Subscribe topic" link at the very bottom left of this page.

Thank you so much for your care in this matter! I know how much work this kind of support can be.

I tested out the root command input keyevent method and yes it is very slowly, roughly 2-3 keystroke perseconds. Very unacceptable, especially if you want to emulate typing a word or sentence. I usually use/test it for single keystroke, so I don't know about this limitation. For longer word I would use Control UI setText instead.

I'm developing IP based navigational controls from a custom remote controller using UnifiedRemote and/or EventGhost, so I'm more concerned with D-Pad movement being responsive. Also, since the triggers are from actual, real-time user button presses, Control UI's setText would not work here.

It seems input keyevent has a very slow processing speed. That means Control UI sendKey() is the only way then. You have use the switching keyboard method.
Set Default Input Method : Automagic Premium (keyboard)
Control UI : sendKey(keyname)
Set Default Input Method : your_default_keyboard

I've gotten close to setting this up, but I cannot enable the Accessibility Service in order to run Control UI. Clicking to enable Accessibility Service says "You don't have an app that can do this", whether I do it from Automagic's Control UI flow editor, or within Automagic's "Features and Permissions" settings. This may be because I had to sideload the Automagic Premium APK after purchasing and installing it on another device. This was the only way I could install Automagic Premium, since Google Play Store says your app is not compatible with the NVIDIA SHIELD. I know it was compatible many months ago, by reading posts on the subject. I imagine Google/NVIDIA made a policy change, and the issue is not really a technical one.

Is there a way to install/enable the Accessibility Service from a sideloaded installation of Automagic Premium?

Root is needed for Set Default Input Method.

Thanks. I already have root.

You can turn off the toast message for the Superuser log in your root management app.

Wow! I didn't know this was an option. Turning off the "toast" message makes even keyevent a lot more usable, but still sluggish.

I hope I can get the Control UI sendKey() working on the SHIELD. It seems promising, and then I can post a "How To" guide for other SHIELD users wanting IP control of the shield.

Thank you again!

[Desmanto]

Just helping and learning at the same time Someday maybe I need it. And I don't know the sluggish execute root command before, until you mention it here.

What is the current android version of the device? If I am not wrong, the accessibility service in the nvidia shield is customized already. Try to see if there is another accessibility services already on and try to disable those. Maybe talkback, or any app. Accessibility should be built-in already in android since JB 4.3 above. But some ROM might disable it, until LP 5.0 where it is mandatory already. (CMIIW) If accesibility still doesn't work, try to change accessibility feedback type to other option and see if it works.

Last resort, you have to use the slow execute root command option. But of course the perfomance is very slow compared to the almost real time Unified remote. If I remember correctly, droidmote can use root and establish direct IP connection. You can even emulate mouse or keyboard from android to android realtime, not slowed down by the adb input version.

[MarkerB]

What is the current android version of the device?

NVIDIA SHIELD 2017 models are currently running Oreo.

If I am not wrong, the accessibility service in the nvidia shield is customized already. Try to see if there is another accessibility services already on and try to disable those. Maybe talkback, or any app. Accessibility should be built-in already in android since JB 4.3 above. But some ROM might disable it, until LP 5.0 where it is mandatory already. (CMIIW) If accesibility still doesn't work, try to change accessibility feedback type to other option and see if it works.

I didn't realize it was a setting in the OS, to allow different accessibility services. "Automagic" was in there, and I enabled it. All these years with Android, and I didn't know about that.

Now I have one warning left in Control UI: "Permission Draw over other apps missing. Click here to grant permission..." Clicking doesn't do anything. I'll research this, and maybe I can figure it out for myself.

Last resort, you have to use the slow execute root command option. But of course the perfomance is very slow compared to the almost real time Unified remote. If I remember correctly, droidmote can use root and establish direct IP connection. You can even emulate mouse or keyboard from android to android realtime, not slowed down by the adb input version.

Hopefully it doesn't come to that. I'm getting familiar with Automagic, and it is a powerful solution (that is, if Google doesn't strangle all these kinds of utility apps with its encroaching policies).

[MarkerB]

I read that the following ADB command can be used to enable "Draw over other apps":

Code: Select all

appops set <package name> SYSTEM_ALERT_WINDOW allow

I'll have to test this later, as I don't have my SHIELD permanently hooked to my computer. Google, why do you make everything so hard? You're turning into Apple.

[Desmanto]

I didn't know there is newer version. I thought that nvidia shield must be from some 2013 device, so must be running some older android version. Good to see it has updated to oreo.

In oreo, the setting of Permission draw over other apps is located directly at the app info. Since the ROM must have been heavily customized, the location can be different there. But at mine, RR 7.0.0 Pie 9.0, there setting is there, setting > apps & notification > Automagic > Display over other apps > Allow.

[MarkerB]

I didn't know there is newer version. I thought that nvidia shield must be from some 2013 device, so must be running some older android version. Good to see it has updated to oreo.

This is the second and still current SHIELD, released in 2017. They release updates to the OS all the time.

In oreo, the setting of Permission draw over other apps is located directly at the app info. Since the ROM must have been heavily customized, the location can be different there. But at mine, RR 7.0.0 Pie 9.0, there setting is there, setting > apps & notification > Automagic > Display over other apps > Allow.

There is nothing like this I can find. It's not there in "Settings > Apps > Automagic > Permissions" where you'd think it would be.

[Desmanto]

So it seems many others also face the same problem. You can use all adb shell command directly from terminal emulator with root access. Just type "su" first and you are free to run any command. Or you can just use Automagic action Execute Root Command itself to run the adb command, no need the prefix "adb shell", just directly the command.

Simply run this in terminal emulator at the nvidia shield, with root access. Or in Automagic execute root command.

Code: Select all

appops set ch.gridvision.ppam.androidautomagic SYSTEM_ALERT_WINDOW allow

I have tried this, disallow the draw over other app in the app info while floating widget is showing. Widget disappear. Typing this command and execute it will show the widget back immediately.

[MarkerB]

Thanks! I wondered if a rooted device could get a terminal session going, and I keep forgetting the SHIELD is just an Android device.

Anyway... I've gotten it working, having an HTTP page pull send a keycode. It definitely is faster than the root shell command method.

However... Two problems, and maybe they're related:

• Only every other execution of the flow causes a keypress. I have to reload the web page twice to get a single keypress simulated.
• After a number of executions, the flow is automatically disabled. There is no error popup.

At this point, I guess I'll have to see if there's a log file somewhere.

Here is a screen shot of my flow: