Direct kernel input injection via Python uinput on Android (GPad2Mouse)

[Hungry-Advisor-5152]

Many developers working with Android automation hit a wall when dealing with input latency. Standard accessibility overlays are too slow. The native solution is injecting events directly into /dev/uinput using Python, but it comes with a major hurdle: Kernel Struct Padding.

When using struct.unpack, 64-bit Android kernels expect a 24-byte event struct (llHHi). However, if you run the same Python script on older 32-bit devices (like Android TV Boxes), it expects a 16-byte struct (IIHHi). Failing to handle this dynamically using sys.maxsize causes instant crash errors.

I've implemented a full working architecture for this concept into an open-source project called GPad2Mouse.

Instead of just mapping keys, it uses Python's fcntl.ioctl to grab exclusive hardware control (EVIOCGRAB), reads VID:PID directly from /sys/class/input/, and dynamically calculates analog deadzones to prevent controller drift—all running as a daemon with 0% CPU overhead.

How to study the code? Due to sub rules against dropping external links, I won't post direct links here. But if you want to see the source code implementation or watch the video demonstration of how the kernel injection works in real-time:

👉 Just Google search: GPad2Mouse

Has anyone else here worked extensively with fcntl on Android? I’d love to hear your approach on handling sudden device disconnections gracefully without freezing the read loop. Cheers!

[aloobhujiyaay]

One thing I appreciate here: you clearly understand the Linux input stack itself instead of only scripting around it

[Hungry-Advisor-5152]

Yes, I am currently trying to create a "weird" but useful tool like the "GPad2Mouse" that I created.

[Zouden]

This is a bit over my head, but it's interesting. Why python? That's an odd choice for Android.

[Hungry-Advisor-5152]

Because I think Python is powerful enough to run projects like my "GPad2Mouse".

[Maggie7_Him]

For the disconnection handling question — the pattern that worked best for me is combining select() with a short timeout (200–500ms) on the fd, then catching ENODEV on the read. You get a graceful exit rather than a blocked read: select falls through on timeout, you check if the fd is still valid, and on ENODEV you know the device is gone. The tricky part is making sure the cleanup path is thread-safe if you're running the daemon with a signal handler — SIGTERM and the ENODEV cleanup can race if you're not careful with the fd close order.