GUADEC: porting GNOME to Android

1. At least autotools insists on running programs to do the feature detection which tends to be a nonstarter for cross-compiling use cases. In any case, Android's notion of the world is monolithic so there's but one configuration, one compiler, all libraries provided by the project itself if you need them, etc. So there's no features to detect and/or configure. Makefiles, though support if statements, so they are not entirely static in nature.

2. Lower latency, power usage, and freedom of sample rate are not useless features, and favor PA -- at least in some use cases. But until it has a comparable DSP story, it is inferior in other practical ways. I'm just bringing this out every time PA gets mentioned against AF so that people would keep in mind that PA is not a superior replacement in every way currently. That article you linked also mentions the OpenSL effects because I pointed them out last time too.

3. Okay. I suppose it ought to work for the basic use cases. I guess I've been really unlucky. No points for planning on distribute a modified android, though. That's precisely the sort of fragmentation Android doesn't need... ;-(

4. Does this imply that Wayland doing android-like UI is better at the job than SurfaceFlinger? Or is this just a general comparison against X? Of particular note is the fact that android 4 apparently managed to add hardware accelerated UI composition where SF apparently composes the application's UI by overlapping various buffers. It sounds fairly optimal already...