Sunday, March 20, 2011

Breaking out of Android sandbox

The aim: run real native applications side-by-side with Android Dalvik applications.
Reason: Android imposes drastic lifecycle scheme on any application started under its Dalvik VM. That lifecycle is not how real software is written (be be written, should be written).

So, the idea is to run Linux-native application which will create a window/surface/display compatible with ones managed by Android's "Window Manager". It seems that level on which such app should operate is "SurfaceFlinger" Android service which is essentially a compositing display server. So, the app will create a new surface (possibly, still showing standard Android toolbar), and essentially will have exclusive control over the hardware during its runtime (for example, it apparently would read input events directly from Linux devices), but of course it should be able to "minimize" itself to let Android window manager to control its windows, and be able to "maximize" (by receiving some IPC event).

The problem: how to deal with OOB Android window interaction (for example, alarm window pops up)? Apparently, that should lead to another surface to be created on top of our app's, so new one should be just visible to user, and our one should just go offscreen. But what about input events? Does SurfaceFlinger notifies clients of their surface state changes?


http://www.mail-archive.com/android-porting@googlegroups.com/msg01680.html

No comments: