| |||||||||||||
Send patches upstream?Send patches upstream?Posted Jan 17, 2012 9:00 UTC (Tue) by mastro (subscriber, #72665)Parent article: Raghavan: PulseAudio vs. AudioFlinger: Fight!
FYI, if you want to see this happen in the official Android releases, now could be a good moment to send patches upstream since the AOSP (Android Open Source Project) has recently fixed the Gerrit webapp after the kernel.org problem last year: https://groups.google.com/group/android-contrib/msg/67d41...
(Log in to post comments)
Send patches upstream? Posted Jan 17, 2012 9:13 UTC (Tue) by Ford_Prefect (subscriber, #36934) [Link]
I did push a bunch of these upstream via the bug tracker.
http://code.google.com/p/android/issues/detail?id=17996
The AOSP-side stuff is fairly straightforward. There's others to ALSA and PulseAudio as well as their deps that have a bit more (but again, mostly build-related).
Send patches upstream? Posted Jan 17, 2012 17:17 UTC (Tue) by broonie (subscriber, #7078) [Link]
Android has a very strong preference for avoiding LGPL/GPL code in userspace, it is vanishingly unlikely that they would abandon AudioFlinger in favour of PulseAudio due that concern.
They might accept it as an external/ project though.
It looks like the invitation to fork... Posted Jan 17, 2012 20:43 UTC (Tue) by khim (subscriber, #9252) [Link] Right. Google went out of their ways to avoid GPL/LGPL in userspace (they have not avoided it completely: WebKit is LGPL) and as result Android is chock-full of half-backed components with their sole raison d'être being "they are not LGPL". This is why you can not work with your new Galaxy Nexus as normal drive: it can not support UMS because they wanted to merge partitions - and they can not offer easy to use Zaurus solution (g_ether + samba) because samba is not scary but super-scary: GPLv3, never in million years. This is why you must fight toy libc library (LGPL is no go, better to create new half-backed library from scratch rather then try to use what everyone else is using). This is, finally, why there are AudioFlinger while PulseAudio is better in from most sides except one. If the community (or a competitor) want/need to create alternative platform then the easiest way will be to take Android and replace all these toy components with time-tested analogues. Of course compatibility will be a bitch, but it should be possible to keep thing Android-compatible while simultaneously support sane tools and libraries.
It looks like the invitation to fork... Posted Jan 17, 2012 23:31 UTC (Tue) by mastro (subscriber, #72665) [Link]
No need to create an entirely different platform/distribution, at least for glibc: I think many applications in the Android Market already use it compiled statically (in the market you can find Firefox, bash, vim, grep, sed, sshd, javac, git...) and if you want it as a dynamic library there's some ongoing work on http://forum.xda-developers.com/showthread.php?t=1299962
This is different Posted Jan 17, 2012 23:47 UTC (Tue) by khim (subscriber, #9252) [Link] You can certainly pull some libraries and use them in your android application. But this is possible in stock Android, too. What you CAN NOT do with stock android is to use the whole Linux stack - and make it possible to use traditional Linux technologies in parallel to Android can be quite a challenge. But I think it'll be worth it - not so much for phones (where traditional Linux programs often make no sense), but for tablets. When you attach keyboard to Transformer Prime you get quite nice laptop - but Android programs make little sense in such configuration while traditional programs will be great to have.
It looks like the invitation to fork... Posted Jan 18, 2012 5:18 UTC (Wed) by AndreE (subscriber, #60148) [Link]
How does the "merging partitions" issue related to source code licensing?
It's interesting story Posted Jan 19, 2012 8:04 UTC (Thu) by khim (subscriber, #9252) [Link] This is [relatively] long story. First you must recall that UMS (which is supported by older Android devices) is pretty scary protocol: it basically presents your device as a block device and computer can do whatever it wants with it, can corrupt any low-level data-structures, etc. This is why when you mount SD card as UMS in older devices it becomes unavailable for Android itself. Now, when Android phones included physical SD card slot everything was easy and simple: because you've had the ability to remove SD card you, of course, had the ability to unmount it and then it can be exposed as UMS. But on newer devices (with large flash but without physical SD card slot) this meant that you need to split large (16GB-32GB-64GB) flash in two separate pieces: one will be your "root partition" and another will be "the virtual SD card". Often vendors offered small (1GB-2GB) root partition and large SD card. And a lot of programs don't work correctly on SD card (because they need to run daemons^H^Hbackground processes, for example). Now, ICS solved this problem. It supports mode (used on Galaxy Nexus, for example) where SD card is emulated using FUSE on top of a single large partition. Thus your "root partition" and "SD card" share the same space. Joy? Not fully: now you don't have block device to export via UMS. And this is where GPL comes into play. Old PDAs also faced this problem long ago and often used simple and elegant solution: it presents itself to the computer not as block device but as network card. Complete with DHCP, etc. And "free for grabs" SD card is exported as SMB share. You can find your device in the "Network Neighborhood" as a computer with shared folder. Works great on Windows (starting from Windows95OSR2.1), MacOS X (all versions), Linux (almost all versions), easy, simple (for user, under the hood it's quite complex), fast and reliable (because while it's internally complex it uses well-debugged components designed and debugged long ago). I've personally used this mode with my first PDA (aforementioned Zaurus) 10 years ago. But this way was closed becuase it needed Samba - and Samba is GPLv3 novadays. Instead they went with MTP. Which is not even supported by XP "out of the box" (you can install additional package to somehow transfer files anyway). It's also is not supported by MacOS X "out of the box" and various Linux distributions have different kinds of problems when used with MTP. Thus you are right: merging of partitions have nothing to do with GPL, but the problems which followed later (inability to use device as a [network] drive) are brought by unvillingness to rely on GPLv3 software.
GPL in Android userspace and PulseAudio Posted Jan 19, 2012 8:04 UTC (Thu) by scottt (subscriber, #5028) [Link] Android NDK r7 now ships a gnustl_shared library which is derived from GNU libstdc++ (GPLv3+ with exceptions). Android also always linked libgcc.a statically. These plus WebKit as you mentioned is LGPLv2+, allows us to claim that since Android already ships a lot of LGPL and GPL with exceptions code in important userspace components, the license of PulseAudio shouldn't be a problem. I think the argument in favor of using AudioFlinger on Android is that it keeps the hardware abstraction layers more consistent(?) across the audio, camera, gps etc subsystems. Maybe Google would adopt timer based scheduling in AudioFlinger to get the power saving benefits in the future.
Send patches upstream? Posted Jan 19, 2012 4:09 UTC (Thu) by Ford_Prefect (subscriber, #36934) [Link]
Indeed, I'm not terribly positive on PulseAudio replacing AudioFlinger in the foreseeable future for those very reasons. That's not to say it can't be available as a viable drop-in replacement if done correctly.
|
|||||||||||||