Note: Part two on programmatically injecting events on Android has been published and is available here.

The successful Android platform has been around for a few years now. End users get lots of bells and whistles in fancy applications, but for developers, this "open-intended" platform seems even more tangled up than ever.
There are various APIs that still do not work, others that get deprecated-and-out in a single release, or some that are locked up for the supreme security purpose, invoked so very often by platform developers, that probably feel they've given the right answer.
All in one, Android also comes with a lot of frustration, because tools that are needed to accomplish various tasks or even more advanced applications, are put behind bars on purpose.

Another example of many is injecting a key press programmatically or the similar counter-part, injecting a touch event (mouse).
Because a malicious programmer might develop a software that would open your Market app and download payed apps without you knowing about it, developers world wide are prohibited from sending a key press programmatically to other applications except their own.

This is just ridiculous narrow thinking.

Of course there will always be a balance between security and functionality, but with paranoia it quickly turns to total failure. In other words why limit something so useful that can create so little damage? Users are warned about risks with normal permissions and it should stay that way for other features as well.

I'll just leave them with their issues and get back to the topic: I am aware of three methods for injecting events programmatically. This refers both to keyboard events (keys) and mouse events (touch events).

Method 1: Using internal APIs

This approach has its risks, like it is always with internal, unpublished APIs.
The idea is to get an instance of WindowManager in order to access the injectKeyEvent / injectPointerEvent methods.

  1.  
  2. IBinder wmbinder = ServiceManager.getService( "window" );
  3. IWindowManager m_WndManager = IWindowManager.Stub.asInterface( wmbinder );
  4.  

The ServiceManager and WindowsManager are defined as Stubs. We can then bind to these services and call the methods we need. The interfaces are included in the sample code attached at the end of this article.

To send a key do the following:

  1.  
  2. // key down
  3. m_WndManager.injectKeyEvent( new KeyEvent( KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_A ),true );
  4. // key up
  5. m_WndManager.injectKeyEvent( new KeyEvent( KeyEvent.ACTION_UP, KeyEvent.KEYCODE_A ),true );
  6.  

To send touch/mouse events use:

  1.  
  2. //pozx goes from 0 to SCREEN WIDTH , pozy goes from 0 to SCREEN HEIGHT
  3. m_WndManager.injectPointerEvent(MotionEvent.obtain(SystemClock.uptimeMillis(),
  4. SystemClock.uptimeMillis(),MotionEvent.ACTION_DOWN,pozx, pozy, 0), true);
  5. m_WndManager.injectPointerEvent(MotionEvent.obtain(SystemClock.uptimeMillis(),
  6. SystemClock.uptimeMillis(),MotionEvent.ACTION_UP,pozx, pozy, 0), true);
  7.  

This works fine, but only inside your application

The moment you're trying to inject keys/touch events to any other window, you'll get a force close because of the following exception:

  1.  
  2. E/AndroidRuntime(4908): java.lang.SecurityException: Injecting to another application requires INJECT_EVENTS permission
  3.  

Not much joy, as INJECT_EVENTS is a system permission. A possible solution is discussed here and here.

Method 2: Using an instrumentation object

This is a clean solution based on public API, but unfortunately it still requires that INJECT_EVENTS permission.

  1.  
  2. Instrumentation m_Instrumentation = new Instrumentation();
  3. m_Instrumentation.sendKeyDownUpSync( KeyEvent.KEYCODE_B );
  4.  

For touch events you can use:

  1.  
  2. //pozx goes from 0 to SCREEN WIDTH , pozy goes from 0 to SCREEN HEIGHT
  3. m_Instrumentation.sendPointerSync(MotionEvent.obtain(SystemClock.uptimeMillis(),
  4. SystemClock.uptimeMillis(),MotionEvent.ACTION_DOWN,pozx, pozy, 0);
  5. m_Instrumentation.sendPointerSync(MotionEvent.obtain(SystemClock.uptimeMillis(),
  6. SystemClock.uptimeMillis(),MotionEvent.ACTION_UP,pozx, pozy, 0);
  7.  


All good inside the test application, and will crash instantly when trying to inject keys to outside apps, not because the approach doesn't work, but because Android Developers have chosen so. Thanks guys, you rock! Not.
By looking at sendPointerSync's code, you will quickly see it uses the same approach as presented in method 1). So this is the same thing, but packed nicely in a easy to use API:

  1.  
  2. public void sendPointerSync(MotionEvent event) {
  3. validateNotAppThread();
  4. try {
  5. (IWindowManager.Stub.asInterface(ServiceManager.getService("window")))
  6. .injectPointerEvent(event, true);
  7. } catch (RemoteException e) {
  8. }
  9. }
  10.  

Method 3: Direct event injection to /dev/input/eventX

Linux exposes a uniform input event interface for each device as /dev/input/eventX where X is an integer. We can use it directly and skip the above Android Platform permission issues.
For this to work, we will need root access, so this approach only works on a rooted device.
I felt it was easier to deal with linux using native C code, but a pure java implementation is also possible. Therefore I have added a small JNI component to handle the interface with /dev/input/eventX.

The sample code I wrote doesn't detect the X number automatically, so make sure you set that before running the code. By default I set it to event3. You can change that in NativeInput.java, see code below.

As I said, this last method requires root. By default the eventX files have the permission set for 660 (read and write for Owner and Group only). To inject keys from our application, we need to make it writable. So do this first:

  1.  
  2. adb shell
  3. su
  4. chmod 666 /dev/input/event3
  5.  

You will need root to run the chmod command.

Sample Code

AndroidKeyInjector

Other great resources:

Generating keypresses programmatically
Internal input event handling in the Linux kernel and the Android userspace
androidscreencast

Note: Part two has been published and is available here.

Related Post