Improve Delay Time When Using USB HID Keyboard about authorizer HOT 6 OPEN

So you suggesting to have a rooted background process to avoid executing dd?
What phone are you currently using and what do you mean by bad performance? To improve on that, we should have some specific timings in ms to work on.

I'm working on a native mode, in which dd is not necessary and Authorizer directly writes to /dev/hidg. This is possible by implementing Selinux rules and change permissions of /dev/hidg device. What do you think?

from authorizer.

I'm sorry for my poor English...I mean, using 'dd' command needs to pass string commands to Shell ,and Shell needs to process string, then transfer the arguments to 'dd' .Then 'dd' start to open InputStream to write data into /dev/hidg and then close the InputStream. The whole process is not effective.

I strongly recommend you to check an open-source Android APP named 'Shizuku'. It requires adb or root permission to active, and after that it allows any APP to execute java code or execute native JNI with the UID of 2000 or 0 (depends on whether you active Shizuku by adb or root). It has very low delay.

Shizuku launches a background process by 'app_process' command ,and uses Binder to communicate with any APP. The way how APPs receive the Binder is hard for me to understand, but i'm still trying.

from authorizer.

I'm sorry for my poor English...I mean, using 'dd' command needs to pass string commands to Shell ,and Shell needs to process string, then transfer the arguments to 'dd' .Then 'dd' start to open InputStream to write data into /dev/hidg and then close the InputStream. The whole process is not effective.

I strongly recommend you to check an open-source Android APP named 'Shizuku'. It requires adb or root permission to active, and after that it allows any APP to execute java code or execute native JNI with the UID of 2000 or 0 (depends on whether you active Shizuku by adb or root). It has very low delay.

Shizuku launches a background process by 'app_process' command ,and uses Binder to communicate with any APP. The way how APPs receive the Binder is hard for me to understand, but i'm still trying.

I understood you already in your first post. Did you read and understood my reply?
What means "low delay" for you in specific numbers?

from authorizer.

I'm sorry for my poor English...I mean, using 'dd' command needs to pass string commands to Shell ,and Shell needs to process string, then transfer the arguments to 'dd' .Then 'dd' start to open InputStream to write data into /dev/hidg and then close the InputStream. The whole process is not effective.
I strongly recommend you to check an open-source Android APP named 'Shizuku'. It requires adb or root permission to active, and after that it allows any APP to execute java code or execute native JNI with the UID of 2000 or 0 (depends on whether you active Shizuku by adb or root). It has very low delay.
Shizuku launches a background process by 'app_process' command ,and uses Binder to communicate with any APP. The way how APPs receive the Binder is hard for me to understand, but i'm still trying.

I understood you already in your first post. Did you read and understood my reply? What means "low delay" for you in specific numbers?
I use such shell command to execute ‘dd’ command for 100 times：

echo date +%s%3N;
flag=1;
while ((flag < 100))
do
printf '00000000'|dd of=/dev/hidg1;let flag+=1;
done
echo date +%s%3N;

The output of the command above is "1678087807870" and "1678087809667". That means it takes 1797ms to execute 'dd' command for 100 times. The average writing speed is lower than 0.4KB/s. I think almost 95% of time was consumed by unnecessarly steps.

I want to let my Android phone become a low delay USB GamePad with Gyroscope enabled. The Gyroscope Sensor in my Android phone has a report rate up to 500 times per second, so I want to find a better way to write data to /dev/hidg .

Sorry for my misunderstand of your comment !!

from authorizer.

I deleted your duplicated comment.

Okay. I mean at general 17ms for executing dd is not bad if we talking about my general use-case: auto typing of passwords by my other project Authorizer.

But of course your GamePad case looks reasonable. As I wrote, I'm working on a native mode, so that we don't need any root process to write to /dev/hidg as the file permissions are set correctly so that Java can directly write to it.

What GamePad you would like to implement? Do you consider a specific existing one?

from authorizer.

I deleted your duplicated comment.

Okay. I mean at general 17ms for executing dd is not bad if we talking about my general use-case: auto typing of passwords by my other project Authorizer.

But of course your GamePad case looks reasonable. As I wrote, I'm working on a native mode, so that we don't need any root process to write to /dev/hidg as the file permissions are set correctly so that Java can directly write to it.

What GamePad you would like to implement? Do you consider a specific existing one?

I think modifing SELinux rules is a very very good idea. It will solve my problem and maybe make your Authorizer's development easier. And may be we can use 'magiskpolicy' command to modify SELinux rules easily (Magisk needed).

But I'm not sure whether modifying SELinux rules will cause the Google Play Store to stop working or something. At least I know in China, almost every bank's official APP will detect SElinux rules and if they found any modification, they will stop working and exit. So every time when I installed Magisk on my phone, It takes me a very long time to find ways to hide Magisk, hide Bootloader's state ,hide SELinux modification and so on. That's annoying.

I have paid 3$ for a cheap USB GamePad and I wish I could get its specific USB report descriptor. Sence I buy it online, it may takes 2~3 days until I get it on my hand. I will test and send the descriptor, report length, and the structure of report data to you as soon as possibile.

I also found the descriptor of a XBox GamePad on a website :

05 01 //0 GLOBAL_[USAGE_PAGE](Generic Desktop Controls)
09 05 //2 LOCAL_USAGE(Game Pad)
A1 01 //4 MA[IN]COLLECTION(Applicatior)
A1 00 //6 MA[IN_COLLECTION(Physical)
09 30 //8 LOCAL_USAGE(X)
09 31 //10 LOCAL_USAGE(Y)
15 00 //12 GLOBAL_LOGICAL_M[IN]IMUM(0)
26 FF FF //14 GLOBAL_LOCAL_MAXIMUM(-1)
35 00 //17 GLOBAL_PHYSICAL_MINIMUM(0)
46 FF FF //19 GLOBAL_PHYSICAL_MAXIMUM(65535)
95 02 //22 GLOBAL_REPORT_COUNT(2)
75 10 //24 GLOBAL_REPORT_SIZE(16)
81 02 //26 MAIN_INPUT(data var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
C0 //28 MAIN_COLLECTION_END
A1 00 //29 MAIN_COLLECTION(Physical)
09 33 //31 LOCAL_USAGE(Rx)
09 34 //33 LOCAL_USAGE(Ry)
15 00 //35 GLOBAL_LOGICAL_MINIMUM(0)
26 FF FF //37 GLOBAL_LOCAL_MAXIMUM(-1)
35 00 //40 GLOBAL_PHYSICAL_MINIMUM(0)
46 FF FF //42 GLOBAL_PHYSICAL_MAXIMUM(65535)
95 02 //45 GLOBAL_REPORT_COUNT(2)
75 10 //47 GLOBAL_REPORT_SIZE(16)
81 02 //49 MAIN_INPUT(data var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
C0 //51 MAIN_COLLECTION_END
A1 00 //52 MAIN_COLLECTION(Physical)
09 32 //54 LOCAL_USAGE(Z)
15 00 //56 GLOBAL_LOGICAL_MINIMUM(0)
26 FF FF //58 GLOBAL_LOCAL_MAXIMUM(-1)
35 00 //61 GLOBAL_PHYSICAL_MINIMUM(0)
46 FF FF //63 GLOBAL_PHYSICAL_MAXIMUM(65535)
95 01 //66 GLOBAL_REPORT_COUNT(1)
75 10 //68 GLOBAL_REPORT_SIZE(16)
81 02 //70 MAIN_INPUT(data var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
C0 //72 MAIN_COLLECTION_END
05 09 //73 GLOBALUSAGE_PAGE
19 01 //75 LOCAL_USAGE_MINIMUM(1)
29 0A //77 LOCAL_USAGE_MAXIMUM(10)
95 0A //79 GLOBAL_REPORT_COUNT(10)
75 01 //81 GLOBAL_REPORT_SIZE(1)
81 02 //83 MAIN_INPUT(data var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
05 01 //85 GLOBAL_[USAGE_PAGE](Generic Desktop Controls)
09 39 //87 LOCAL_USAGE(Hat switch)
15 01 //89 GLOBAL_LOGICAL_MINIMUM(1)
25 08 //91 GLOBAL_LOCAL_MAXIMUM(8)
35 00 //93 GLOBAL_PHYSICAL_MINIMUM(0)
46 3B 10 //95 GLOBAL_PHYSICAL_MAXIMUM(4155)
66 0E 00 //98 GLOBAL_REPORT_UNIT(14)
75 04 //101 GLOBAL_REPORT_SIZE(4)
95 01 //103 GLOBAL_REPORT_COUNT(1)
81 42 //105 MAIN_INPUT(data var absolute NoWrap linear PreferredState NullState NonVolatile )
75 02 //107 GLOBAL_REPORT_SIZE(2)
95 01 //109 GLOBAL_REPORT_COUNT(1)
81 03 //111 MAIN_INPUT(const var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
75 08 //113 GLOBAL_REPORT_SIZE(8)
95 02 //115 GLOBAL_REPORT_COUNT(2)
81 03 //117 MAIN_INPUT(const var absolute NoWrap linear PreferredState NoNullPosition NonVolatile )
C0 //119 MAIN_COLLECTION_END

But I can't verify this descriptor, so I choose to wait for my own USB GamePad.

from authorizer.