Growing GPL/FOSS Loyalty Among Chinese ARM SoC Vendors

There are visible changes in how Chinese ARM SoC vendors deal with Open Source license compliance (words) and Open Source software at all (spirit) during this year. Not only western resellers of devices based on Chinese SoCs release GPL compliance packages, but many popular SoC companies themselves established GPL compliance/loyalty/support pages. Few go beyond just adhering to word of GPL by releasing kernel source blobs (by blobs I means large tarballs devoid of any development history and support files), but also establish git repositories, release Android trees, set up public bugtrackers.

Of course, they are still not exactly GPL compliant - scrutiny of any releases would likely show missing parts, binary objects for drivers, etc. But there's definitely a difference between plucking out WiFi driver out of flash image you have on you device and downloading "official binary" from a SoC vendors. It's also a good start, and there's a hope the situation with complete source availability will improve. And as everyone watching the area knows, the industry at the whole needs to improve - Western companies may comply with GPL by providing source for kernel shims, but that doesn't help users to support vendors' hardware if they just move binary blobs to userspace.

The changes discussed didn't come by themselves and at once. Lot of people paved the road to this via gpl-violations.org, via various leaks, etc. But critical change came with emergence of Open Hardware startups. They are led by people who strongly believe in Open paradigm, but also to do their ODM-like business, they need to provide sufficient documentation/sources to the customers. So they have little choice but request that from upstream SoC vendors, in redistributable form. So, thanks Rhombus-Tech, Olimex, Cubitech!

Anyway, here're the links to Chinese companies' GPL loyalty pages I know so far. Additions and corrections are welcome.

• Telechips 
• Rockhip
• Allwinner
• Amlogic
• VIA/Wondermedia

And as extra, community projects to support some of vendor SoCs from above list:

• Rockchip 
• Allwinner 
• VIA/Wondermedia 

On animation in user interfaces

I always considered animation in GUI a whimsical feature wasting resources (in particular, power in mobile devices) and oftentimes just covering triviality of contemporary software for mobile systems (IPhone and Android, hello), and inconveniences user with slow, repetitive, boring effects.

Live and learn, I found usecase where lack of animation makes user interaction unobvious and complicated. It's not about going from one square page to another though, but about applying transformation to graphs.

It all started with my desire to study dependencies among Android modules (which is task towards my "Packaged Android" project). I found adepends.py tool (my fork), which is very nice and dumps dependency info in .dot format for rendering with Graphviz. Looking at few graphs it became obvious that for comfortable browsing there should be interactive graph viewer with few capabilities which I summarized in Stackoverflow question.

My searching didn't turn suitable viewer, but fortunately I found xdot.py, which is extremely cool graph viewer app written in Python, which was suitable base for easy implementation of needed features.

And here story comes to the topic of the post - once I implemented prototypes of  those features, they indeed proved to be really helpful, but didn't give aesthetic satisfaction - that's because when hiding a node for example, Graphviz's dot completely overhauls rendering of a graph, so user loses track of context he used with. Having shape of a graph morph from old to new state would help a lot.

Actually, animation can help even with simpler graph operation, for example going from one node to another in a complex graph - seeing a ride over an edge which connects them helps intuitive understanding a lot. See ZGRViewer's "link sliding" feature in a video on Youtube:

Simplified form of going from node to node is implemented in xdot.py, except that it moves between nodes via shortest path, which doesn't capture context of curved edges. (Btw, ZGRViewer may be full of cool ideas, but its UI grossly sucks comparing with XDot, literally, it's outbreak from last century). I seriously consider implementing non-linear animation approximating Bezier curves for XDot.

So that's it - going from hating animations to wanting implement non-trivial animations myself in couple of days ;-). (That's also the first time I embed video?)

Links for August 2012

• Using native Android USB Host API - kind of libusb within Android.
• USB Host for Nook Simple Touch Reader
• ELLCC - Project to bring decent cross-compiling support to LLVM (currently cross-compiling is rather neglected by LLVM mainline)
• Blueman - GTK+ Bluetooth Manager
• hidclient - Forward local input devices via Bluetooth HIDP
• Using the PlayStation 3 controller in Bluetooth mode with Linux - This is about "Sixaxis" game controller, not BD Remote, but confirms that PS3 likes adhoc pairing stuff instead of true Bluetooth one.

NSLU Optware for Android

Yes, there was kind of attempt at that already, but:

• It's no longer available at the link announced and spread over the Internet (yep, it's available at another, but why so ... complicated?)
• It ships binary blobs of unknown origin. Yup, maybe one could trace their origins, but who'd bother, and telepaths are on vacation as usual. It should be described stringently where they are from, if not scripted to be collected in user's build directory from known good sources, so users can actually trust them.
• It is marketed as supporting only something called "Nook Color". What's that, I thought it was Optware for Android? Could I have Optware specifically for my HP nx9420 notebook, serial number XYZZY, 3Gb of RAM? Just make sure it's different from the Optware for the same notebook, but with 4Gb of RAM, and from any other Optwares in the world!
• It goes as far as patching rootfs ramdisk. That may work on Nook Color or may brick it. That may work on next firmware upgrade of Nook Color or may brick. That may work on another device or may brick. The talk is not about this, it's about the fact that it's two big differences - to be able to install and run bash and to have sshd started automatically after the boot. I definitely want first, but I will do good consideration if/when I need second. So, I don't want setup for those 2 stages to mixed and done without myself being ready for stage 2.
• It still appears to rely on presence of some other 3rd party stuff (look at that #!/bin/sh line, there's no such thing on pristine Android device, only #!/system/bin/sh)

So well, I decided to take my turn on hacking up an Optware bootstrap script for pure Android (root and adb access are the only prereqs). It's hosted here: https://github.com/pfalcon/optware-android and intended to be run on a Linux hosts. It starts by downloading CodeSourcery toolchain for libc and ipkg and immediate dependencies from http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable to bootstrap ipkg on device. Yep, it's being tested on Nook Tablet so far, but at least it is called Optware for Android and I have that aim ;-). So, bugreports and patches are welcome. And I have few more devices to test it on, just steal me some time...

Notes on Android EGL/native windowing system interface

EGL is defined here and appears to be in OpenGL ES something what GLUT was (?) in OpenGL world. At least, EGL is what takes care of actually displaying on screen what was rendered by OpenGL ES.

Donut

EGLNativeWindowType is defined in opengl/include/EGL/eglplatform.h as struct egl_native_window_t* . egl_native_window_t is defined nearby in opengl/include/EGL/eglnatives.h . This is nice, clean, standalone structure (unlike horror in Eclair+). It starts with a "magic" (signature) 0x600913, followed by "version" which is sizeof of the structure (now I know why Microsoft gets a buck on each Android phone sold - they for sure patented this (stupid? lazy?) trick widely used in Win32 API). There're some function pointers (virtual method table) used by EGL to call into native windowing system (deep, close to vendor drivers) to support its workings. Out of these, there's essentially one related to rendering finalization: swapBuffers(). So yes, it seems that eglSwapBuffers() just calls out to this. The structure also directly contains "Base memory virtual address of the surface in the CPU side" and other easily graspable memory/graphics notions.

It's clear that in its young years, Android was fair and naive, not suitable at all for typical vendor OpenGL mumbo-jumbo. The "fix" came with the later versions.

Eclair and following

EGLNativeWindowType is defined (in include/EGL/eglplatform.h) to be struct ANativeWindow*. ANativeWindow was android_native_window_t in Eclair, but was renamed to ANativeWindow in Froyo (android_native_window_t is still available for compatibility). ANativeWindow is defined in platform/frameworks/base/include/ui/egl/android_natives.h:

• Eclair
• Froyo
• Gingerbread

ANativeWindow not just emulates VMT, but seems to want to do entire C++ in C-like manner in its metes and bounds. It uses subclassing from android_native_base_t, and that contains fields for magic ("_wnd" for ANativeWindow) and version-sizeof. Methods defined are also more involved. Among the most interesting are dequeueBuffer(), lockBuffer(), queueBuffer(). Essentially, it appears that EGL takes a free buffer out of native system's rotation, locks it for changing its contents, then puts back into queue for display.

Actual implementation of ANativeWindow for read device screen is in libs/ui/FramebufferNativeWindow.cpp . There's factory function to get its instance: android_createDisplaySurface().

All implementation details on buffers used are hidden in android_native_buffer_t type. It is also subclassed from android_native_base_t, its magic is "_bfr". Among simple things like width/height it contains buffer_handle_t, which leads in utero of vendor graphics driver. buffer_handle_t is native_handle*, and native_handle is a generic container for arbitrary number of fd's and pointers.

native_handle's are produced by gralloc vendor module, and that's exactly what FramebufferNativeWindow constructor does - it loads gralloc module, then uses it to open framebuffer and gralloc devices. It then allocates back and front buffers from gralloc devices with the size of the framebuffer. queueBuffer() method is implemented by calling framebuffer's post() method which well, shows the buffer on the screen.

Thoughts/notes on Android version upgrades and reusing Android drivers

So, what it takes to upgrade Android on an arbitrary Android device (from user perspective)? What takes to run Linux in full-fledged mode? This boils down to few things:

Kernel porting

Upgrade kernel. This means forward-porting hardware support modules to a new kernel version. That's, when source code for such modules is available. Sometimes, it's not violating GPL (or tainting kernel, but who wants that? ;-) ). In an ideal world, that would all that's needed, but vendors don't like GPL, and try to move stuff outside of kernel. So, the list continues.



Bitblt acceleration porting

Next step is making sure that basic hardware acceleration works - accelerated bitblt/compositing (defining compositing as bitblt with alpha). This is actually pretty important step - without accelerated bitblt, Android with more or less big screen will run pretty sluggishly. Well, X Windows won't run too zippy either. Bitblt code in Android lives in /system/lib/hw/copybit.*.so  and depends on gralloc.*.so from the same dir (* there is vendor/implementation identifier - Android support multiple, pluggable implementations). Needless to say, for a random device, source for these modules are not available - vendors don't have to provide it, it's Apache2-licensed, and very few choose to uphold OpenSource spirit nonetheless. So, if new Android version have changes the ABI for those modules, then oops - upgrade is "not possible" is layman terms. Of course, real men will immediately think about writing adapters, etc...

What about other X and other "foreign" windowing systems? They would need drivers/adapters too, and base all their low-level FB access based on Android's gralloc/bitblt/etc. model.

OpenGL ES porting

Last, least, but nonetheless. Curse of the modern world - OpenGL. You didn't have it on your Apple 2 (I mean Apple 2, yes, not what you thought about!) and everything was great, wasn't it? Apart from games you don't have time to play, what it's useful for? Yes, as soon as we'll stream videosignal directly into the brain, it will be useful for augmented reality, but I mean, *useful now*. They keep talking they added some hardware acceleration using OpenGL to the normal UI, then immediately say it didn't work that great, and depends on many things, because... Because OpenGL simply doesn't work that great, yeah. For example, even "accelerated", it's pretty slow, buggy, inconsistent across devices, etc, etc.

Anyway, thanks for listening to the rant. Let's de-emphasize usefulness of OpenGL, let's just take it as a challenge - vendors hacked it, so why can't hackers hack it? The basic idea is the same as with bitblt - there's an interface between closed vendor OpenGL ES implementation and Android. If interface changed, you're hosed. I mean, you write adapters. You also write adapters to make it talk with your windowing system of choice, and not Android. The core interfacing part of OpenGL ES/Android junction is EGL. How to deal about it is worth a separate post.

Stopping Android GUI services

Well, this really worth a cross-post. The way to stop Android GUI services is (under root of course):

setprop ctl.stop zygote

UPDATE: Thanks to hint from StackOverflow: there're even simpler commands: "start" & "stop". Surprise.

Towards decent mouse wheel support in Android

One thing everyone would notice on attaching a USB mouse to an Android device is that mouse wheel is not supported, which makes interaction very tedious. I take a quick look at the state of its support.

Android-x86 project advertises mouse wheel support, but looking at their patch, they translate mouse wheel clicks into up/down buttons. That's better than not supporting wheel at all of course, but still not intuitive usage. What I'd like to have is not analog of up/down key press, but actual scroll, i.e. analog of drag.

But probably, such behavior couldn't be reliably emulated on the lower level of input processing, (or this might lead to adverse effects, like mouse wheel movement interpreted as click). Instead, higher-level controls should have explicit support for discrete scroll events. For example this event handler block should be factored out to be callable for such event and be passed just deltaY.

Of course, that would be more or less big refactor, so another approach would be just waiting until Google thinks it gave enough competitive advantage to big vendors over small and finally releases 3.0+ source code, which supposedly implements wheel support.

Comparison of OpenSource PDF readers for Android

Today we're going to review few open-source PDF readers for Android platform. The table below provides links and feature-by-feature comparison, with more detailed discussion of features below the table. It should be noted that all these readers are based on the same PDF rendering library - MuPDF, so offer roughly the same rendering quality, the differences may be only due different version of the library used, or different configuration options (for example, some readers compile MuPDF without JPEG2000/JBIG support, or without standard PDF fonts).

The review summarizes with expectable conclusion - there's no perfect reader so far, but selects clear winner, which is worth to be hacked on.

Feature	DroidReader 0.5	APV aka PDFViewer 0.2.9	VuDroid 1.4	MuPDF Android Client 0.8.165
Builtin open file	-	+	+	-
On-screen zoom	-	+	+	+
Continuous pages	-	+	+	-
Page smaller than screen	- (force close on attempt)	+	-	-
In-app rotate	+	+	-	-
Go to page	+	+	+	-
Table of contents	-	-	-	-
Find text	-	+	-	-
JPEG2000/JBIG	- (doesn't recognize pdf)	+	-	+
Other formats	-	-	DJVU	-

• Builtin open file - whether you can start application and select file to view, or must have a compatible file manager and open PDF in it using "open with".
• On-screen zoom - whether you can zoom by direct manipulation on screen (like, pinch zoom, zoom in/out widgets) or need to go to menu. Needless to say, without on-screen zoom a reader is hard to use for real reading.
• Continuous pages - whether you see single page at time and need to use explicit next/prev page actions, or can just scroll a page away and see next/previous page. (Arguably, continuous page reading is easier and more productive.)
  
• Page smaller than screen - whether you can zoom out page so it is smaller than screen. For continuous pages reader, that would mean showing more than 2 pages at the same time on the screen. While this seems like neat feature, it actually just complicates real reading, when you need to take extra care to zoom back carefully after occasional zoom-in. (That's of course why most apps don't bother to implement it.)
• In-app rotate - whether app has own support for rotating pages, or relies on OS to support rotation. Got a vendor-crippled device without OS support for rotation? You're lost without in-app rotate, so that's boon.
• Go to page - basic navigation feature. That's not much convenient for real reading, but without this, you can't do any real reading at all.
• Table of contents - real navigation. For an app to be really usable, it must support this. Nope of apps in review does though.
• Find text - other very useful navigational feature. You hardly can read technical/reference docs without this.
• JPEG2000/JBIG images support - Apps which doesn't support these images format don't really support PDF, just some crippled subset of it.
• Other formats support: You found your perfect PDF reader? Congrats, now repeat that for all other ebook formats you use. Don't wanna waste time like that? Choose readers which support all reasonably similar formats. For already typeset ebook, there're actually two formats: PDF & DJVU, so good reader should support both. For TXT, HTML, CHM you indeed would rather look for different reader with different featureset.
  

And the winner is...

Based on the table above, the clear winner is VuDroid: it supports both typeset-ebook formats, PDF & DJVU, and has reasonable usability features (like has limit for page zoom out, as well as adjusts zoom on rotation). One serious, but easy to fix thing lack of JPEG2000/JBIG support (fixable by extending MuPDF config). Other thing it lacks comparing to APV is text find. Well, all readers in review lack ToC support, which a perfect reader must have. Back to VuDroid, it's UI is rather bare - there's no even About dialog, so you can't know that you're running VuDroid at all, or its version!

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