You seem pretty vehemently opposed to all of this, so I don't think there's much/any point trying to convince you, but for the record ...
1) Static Makefiles don't support feature detection and configuration in the same way autotools do. Obviously they're not perfect, but they're a damn sight better than just writing plain static Makefiles. Converting the build system of every single project we've been working with is obviously a non-starter for any viable project.
2) This is completely possible with PulseAudio, and many vendors who've deployed it have written their own custom plugins to process streams, some extremely complex, and all without any need for custom knowledge on behalf of the applications. It also provides a number of very real benefits such as drastically reduced latency from source to hardware, and strong power savings. You can read more about this here: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinge...
3) StageFright has a number of issues, and is not particularly well-suited to more than just basic media playback (and even then ...). GStreamer, on the other hand, has been deployed in all major distributions for years, as well as part of uncountable devices (both consumer/gadget and enterprise), some of which have some hugely taxing requirements. I'm sorry to hear that it anecdotally doesn't work for you on OS X, but it certainly seems to work very well for tens of millions of people. In our Android port, it can indeed be used as part of the base system, because we're developing a branch of AOSP to use as a base for integration, rather than something you can just install from the Google Play store.
4) Wayland isn't, as you note, 1.0 yet (although it is 0.95, with a frozen core protocol), but it's something we're very interested in, as you can see from its commit stats. We think it has a lot to offer in terms of fluid and beautiful UIs which people particularly want in the mobile space, as well as media presentation. We're getting a lot of interest from both hardware vendors and their customers, so a port definitely seemed prudent.
These are all proven, solid technologies (with the exception of Wayland, which is obviously still maturing), which people have deployed and want to continue deploying on a wide range of hardware. Hardware vendors are now turning their attention to Android and only doing base enablement for the Android stack, and the number of hardware vendors who actually care about getting a proper Linux stack up on their hardware is small and diminishing every day. We don't want Android to become a completely separate silo to generic Linux, so we're trying both to offer people with Android-only hardware a much better stack, and also to use the interest from Android deployments to keep that stack more relevant so it can continue to grow and improve for everyone.
It would be nice if that weren't the reality, but what can you do?
Most of these technologies will never become mainstream Android, partially because of licensing concerns, but also partially because the Android development model is based around being almost entirely in-house within Google, rather than the traditional inclusive open source model.
Anyway, as you say, none of this will affect you in any way, so no need to be worried about it. :)
(Obviously I'm speaking for myself and not necessarily for Collabora here. One disclaimer from my brief presentation that Jake left out of the article was that I wasn't actually working on the Wayland port: it was all done by Pekka 'pq' Paalanen, but unfortunately he couldn't make it to GUADEC, so I spoke on his behalf.)
Posted Aug 17, 2012 22:56 UTC (Fri) by daniels (subscriber, #16193)
[Link]
Nate, not Jake. Sorry!
GUADEC: porting GNOME to Android
Posted Aug 18, 2012 17:56 UTC (Sat) by alankila (subscriber, #47141)
[Link]
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...
GUADEC: porting GNOME to Android
Posted Aug 19, 2012 11:14 UTC (Sun) by smcv (subscriber, #53363)
[Link]
> At least autotools insists on running programs to do the feature
> detection which tends to be a nonstarter for cross-compiling use cases
It is possible for a configure.ac to require this, but that feature is relatively rarely-used (most Autoconf checks only require preprocessing, compiling or sometimes linking a program for the embedded architecture, not actually running it).
When a check can't be done without running a program for the embedded architecture (e.g. dbus checks for support for Linux/Solaris-style abstract Unix sockets), in a properly written configure.ac it's possible to tell configure what the result will be, which stops it from actually trying the check. For instance, when building for Android you know that the kernel does support abstract Unix sockets, and there's a configure option to say so.