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?

• Mobile Multitasking (iPhone vs. Android)
• Why the iPad and iPhone don’t Support Multitasking
• Anatomy & Physiology of an Android
• Using SKIA in Android native code
  
• Necessitas blits to surface from native code, AndroidBitmap_* functions (libjnigraphcs.so) are used, and it pulls its implementation from AOSP source, so it works for any Android version (libjnigraphcs.so is just a thin wrapper of Skia functions). A Necessitas commit where they switch from using internal surfaces to AndroidBitmap_*: http://qt.gitorious.org/~taipan/qt/android-lighthouse/commit/37f298c40ca19570f2c2302f227323711c8478e9 (Some info at Issue 4)
  
  
• Notes and native Linux programming under Android (static and dynamic linking examples using CodeSourcery toolchain)
  
• Hello World C program using Android Toolchain
  
  
• http://blog.sina.com.cn/s/blog_6074fcd20100g648.html - Some class diagrams
  
• http://kcchao.wikidot.com/surfaceflinger - Some class diagrams
  
• surface flinger framework and issues
  
• frame buffer
  

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

OpenSource Package Manager for Android

Android is surely breaks records in many areas, like openness of platform, etc. But not only that, Android Market delivers spyware and junkware to your devices with unsustainable ease - I don't remember such wealth at Palm and PocketPC times. Maybe paid apps save the situation, but wise platform owners don't offer them in various places around the world. All in all, while it's generally great fun to dig for gems in such places, there got to be something else.

So, next move of thought is towards open-source package manager. But only to find out that:

• Trackdroid is fool's gold, with source never released (or taken down after release)
• Undroid is stopped because "ultimately it was made irrelevant by Google market place."
• apkget was started just this year, but already undergone repo created - something committed - repo removed cycle.

Googling for "android opensource package manager" doesn't give much - you know, it's all "Android OpenSource Project" and there's a PackageManager class. And - suddenly, thanks to Wikipedia, there's a winner:

f-droid.org

They offer maintained client, they offer repository of packages. Hurrah!

UPDATE: F-Droid is a fork of Aptoide, which also specialized in Android repository provision, but not specializes in FOSS. Consequently, Aptoide client lacks detailed information about licencing, etc. and the repository provided by Aptoide project contains more than just FOSS project. At the same time, Aptoide seems to be leaning towards meta-level (i.e. provide package provision solution for others to reuse), and thus has more documentation and momentum.

F-Droid on the other hand also includes build system for its packages, albeit simple/limited one (e.g., entire recipe is written in one line).

All in all, it's great that there're such solutions for Android, and pity that that they are relatively hard to find, they should be published more, that will contribute to overall software quality on Android platform.

How it all started: F-Droid Repository Vapourware

Critical review of build systems

Last time I looked at possible alternatives to OpenEmbedded, I mostly looked at how many packages they support, how many architectures/OSes, and how easy is to add overrides. Of course, OpenEmbedded outperforms any other generally available build system in these respects.

But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.

GUB
This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:

class Ctypes__mingw (Ctypes):

 One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:

    def patch (self):
        self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch
''')

Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.

mingw-cross-env
Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.