Toward a freer Android [LWN.net]

By Jonathan Corbet
October 6, 2009

Linux-based mobile phone platforms are really just specialized distributions. Like other distributions, phone platforms will live or die based on how well they meet the needs of their users. The Android platform has a high profile at the moment as the result of the entry of more handsets into the market, but also as a result of Google's actions toward derived distributions. Android is clearly not meeting the needs of all its users currently, but changes are afoot which may improve the situation.

The dust has mostly settled after Google's shutdown of the Cyanogen build for Android phones. Nobody can really dispute Google's core claim that Cyanogen was redistributing proprietary software in ways not allowed by the license. But numerous people have disputed Google's good sense; those applications are freely downloadable elsewhere and can only run on phones which already shipped with a copy. So shutting down their redistribution does Google little (if any) good, but it has had a harsh chilling effect over the enthusiastic communities that were promoting Android and trying to make it better. Now those communities are trying to regroup and continue their work, but the rules of the game have changed.

The most community-friendly representative within Google has long been Jean-Baptiste Queru; he clearly puts quite a bit of time into helping other developers work with Android. He is now at the center of an effort to turn Google's "Android Open Source Project" (AOSP) into something deserving of that name. Jean-Baptiste has (belatedly, one might say) figured out one of the major obstacles to contributing to the platform: the difficulty of actually running one's changes.

The primary target form factor for Android is a phone. That means that, deep inside, a fundamental part of allowing writers to play their part is to allow the Android Open-Source Project to be used on phones. And, by that, I don't just mean that it needs to compile and boot, i mean that it has to be usable as a day-to-day phone. Right now, it's not. The range of applications is too limited, the applications that are in there don't all work, and there are quite a few system glitches along the way.

Another aspect is that it makes no sense to expect every contributor to have to apply the same set of manual patches to get to a basic working state. Android Open-Source Project should be usable "out of the box" on commonly available hardware.

Anybody who has tried to build and install Android knows that this "out of the box" experience is certainly not available today. Part of the problem is the massive size and complexity of the Android platform as a whole; there is not a whole lot to be done about that. But even owners of the "Android Developer Phone," who might reasonably expect to be able to develop for their phones, have to locate a set of proprietary components and incorporate them into the build. And then there's the problem of those proprietary applications. A purely-free Android build lacks the maps, gmail, calendar, and market applications - and the synchronization backends which keep things current with the mothership. Such a build does not equip a handset to be "usable as a day-to-day phone."

The first step, according to Jean-Baptiste, is to get to where an Android build just works on the target hardware - the ADP1, naturally. Once the hardware-level hassles have been overcome, it might make sense to talk about filling in the missing applications. But until developers can easily create a build that runs on a real handset, there's not much point in looking at the bigger goals. With the upcoming AOSP 1.0 release, it looks like this preliminary phase is nearing completion.

Solving the rest of the problems should not be all that hard. If the gmail application never becomes available, mail can be read through IMAP instead - and that might just inspire some people to help improve the somewhat painful email application currently shipped with Android. There is a lot of interest in free mapping utilities, including tools like AndNav which have the potential to surpass Google's maps program. AndNav works from OpenStreetMap data and has the ability to do turn-by-turn navigation - something that the Google tool is unlikely to ever be able to do. SlideME has been offered as a free replacement for the market application. And so on.

The harder part might be the tools requiring synchronization with Google's services; those protocols are not always open. It has been made clear that the Android Open Source Project - hosted at Google - is not going to host software developed for reverse-engineered protocols. So, if Google continues to refuse to make the gmail, calendar, and market backends available, those applications simply will not be supported in free builds. There is, of course, nothing preventing the implementation of applications which synchronize to services hosted elsewhere.

The other place where Google will make its presence felt in this project is with licensing:

(L)GPLv3 is out of the question in all circumstances - it scares the phone industry so much that we'd be hurting the entire Android ecosystem if such code made it anywhere into the Android Open-Source Project.

GPLv2 might be allowed for new components, maybe, but given the extent to which Android has gone out of its way to avoid GPLv2 software as well, it could still be a hard sell.

Those looking for a more independent effort may be interested in the Open Android Alliance, which is working to make a fully-free version of Android outside of Google. The Alliance's project page (on Google Code, ironically) states that new work will be licensed under GPLv3. It looks like the developers behind the Alliance are not strongly tied to that license, but there are certainly developers out there who would like to see some sort of copyleft license used. If Google is going to hold back and make them reimplement applications, they reason, Google should not be able to take the resulting code and distribute it as another proprietary application.

The Open Android Alliance has a number of developers who are said to be working on various aspects of the problem. It does not, however, appear to have a mailing list or any code available for download. This is a newborn project; its long-term viability is yet to be determined.

What is clear is that people take the "open handset" idea seriously. It is not enough to dump a bunch of code into an online git server; many of us actually want to mess with our devices. Google, perhaps, is starting to understand that, even if it is still having a hard time balancing pressures from the development community, wireless carriers, hardware manufacturers, and its own lawyers. It is not yet clear whether that understanding will translate into sufficient openness for the Android project, but it appears that things might be headed in the right direction.

It seems that Linux World Domination in the handset market is within our grasp. But which Linux distributions will participate in that success? There are a number of Android handsets out there, but there are still more based on other Linux distributions and the LiMo platform. Soon (not soon enough, for many of us) there will be Maemo-based handsets to play with, and it would not be entirely surprising to see Moblin-based handsets in the not-too-distant future. Some of these platforms will do better than others in the market. It may well be that the platform which is the most open, and which draws the most developer interest, will win out.

Toward a freer Android

Posted Oct 6, 2009 19:57 UTC (Tue) by xav (guest, #18536) [Link] (21 responses)

Yes, can't wait to have a maemo-based one.
That said, a moblin-based handset would perhaps be even better, as a dev platform. It has yet
to be announced though.

Toward a freer Android

Posted Oct 6, 2009 20:31 UTC (Tue) by drag (guest, #31333) [Link] (4 responses)

Well Maemo 5 and Moblin are going to be very similar. The major difference is that Maemo is promoted for ARM handsets and Moblin platform is for Atom.

Since both projects are belong to part of the Gnome Mobile initiative it would be nice when we will be able to just run Gnome Debian or Fedora on a handset without loss of functionality.

It should be possible to do that now with a large loss of ease-of-use, but retain most of the phone functionality and such things.

Toward a freer Android

Posted Oct 7, 2009 8:48 UTC (Wed) by xav (guest, #18536) [Link] (3 responses)

Maemo will use Qt, so it won't be that GNOME-y.
Moblin, on the other hand, looks to be closer to the GNOME Mobile platform.

I also long for the day we can get rid of proprietary low-level components without any loss of functionality.

Toward a freer Android

Posted Oct 7, 2009 15:05 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

_will_ is the word here.

The nice thing about the N900 is that its pretty much open phone. There are
proprietary bits, to be sure, but it is going to take much less effort to
deal with those then what it will take with the average android phone. The
most important bits, except the bootloader (I presume) and the GSM stuff
are going to be open source. The other things should be easy to take care
of.

And I am not saying "android" as a OS.. I mean a practical phone that you
purchase. Most of those are going to be locked down quite a bit were the
average user is going to have to jump through big hoops just to get
software installed on it from sources other then the approved app store.
And they will have every number of proprietary bits that the N900 has, and
more.

If somebody releases a phone to the public that is Android and is open then
I would love to hear about it... I am not looking forward to spending the
600 dollars to get my hands on a N900, but like Google was trying to
explain to people about the first android phones is that while the OS
platform is theirs the phones are not and they have little control over the
actual vendor.

Toward a freer Android

Posted Oct 7, 2009 15:09 UTC (Wed) by xav (guest, #18536) [Link] (1 responses)

AFAIK even the bootloader should be open.

And for the $600 ... consider yourself lucky. Where I live it costs 650, which is more like $1000 nowadays.

Toward a freer Android

Posted Oct 8, 2009 3:50 UTC (Thu) by daniels (subscriber, #16193) [Link]

Bear in mind that there's very little interesting code in the bootloader. While nolo during Nokia 770 and N8x0 times was quite bloated and contained a great deal of setup code, this has almost entirely been repatriated to the kernel for the N900.

Toward a freer Android

Posted Oct 6, 2009 21:22 UTC (Tue) by job (guest, #670) [Link]

ARM will give you better battery life, and will continue to do so for at least two years from now (if the respective roadmaps are to be trusted which they aren't always).

Toward a freer Android

Posted Oct 6, 2009 22:23 UTC (Tue) by fyodor (guest, #3481) [Link] (14 responses)

I'm also impatiently awaiting the Maemo-5 based Nokia n900. How can I not, when the hardware specs (especially the 800x480 screen) are to die for and their professed philosophy is the following?

If freedom is your concern then you don't need to 'unlock' or 'jailbreak' Maemo 5. From installing an application to getting root access, it's you who decide. We trust you, and at the end it's your device. Nokia also trusts the open source community in general and the Maemo community particularly helping in getting casual users through the experience path. The N900 might just be a new and successful entry point for a new wave of open source users and developers.

Also, Jonathan is planning to get one, so I'm looking forward too a not-so-grumpy-editor review coming up.

Google claimed Android was going to be a very open Linux phone, but I'm just not impressed by their follow through :(. I'm hoping the n900 can be the open source answer to the iPhone. My Nmap Security Scanner is already available for its predecessor, the n810, and it should work just as well on the n900. No jailbreaking or root hacking necessary.

Now, if you'll excuse me, I'll go back to checking the Amazon page every day for a pre-order shipment date. It is supposed to happen this month! Also, I recently found an extremely detailed review of the n900.

Toward a freer Android

Posted Oct 7, 2009 1:06 UTC (Wed) by nbd (subscriber, #14393) [Link] (13 responses)

Sorry, but I can only laugh at claims about Maemo being open. According to the (little) information about this issue that I can find on the web, enough essential parts of Maemo are binary-only, so that you cannot even build a remotely functional variant of it yourself without relying on binary-only stuff by Nokia. See http://wiki.maemo.org/Why_the_closed_packages for some examples. Based on that it seems to me that Android is much closer to being a usable free software phone stack.

Toward a freer Android

Posted Oct 7, 2009 2:17 UTC (Wed) by dlang (guest, #313) [Link] (9 responses)

in reading that link it looks like the only thing that would be a significant problem for using it as a phone is the DSP stuff that they are working at changing

the power management stuff may be needed (depending on exactly what it does)

most of the stuff on that list is pure userspace code, most of which has free equivalents.

and I don't see any hint that you couldn't run that stuff on your own system image.

it's not perfect, but it seems at least as good as the Android "we will let you get a phone that's unlocked, but then we won't let you get apps for it" approach.

Toward a freer Android

Posted Oct 7, 2009 2:27 UTC (Wed) by nbd (subscriber, #14393) [Link] (8 responses)

I was talking about Maemo and Android, the platforms. I wasn't talking about devices like the N900 or the ADP1. Yes, most of the missing stuff is user space code, but most of what makes the platforms interesting is user space stuff ;)

Toward a freer Android

Posted Oct 7, 2009 5:53 UTC (Wed) by tajyrink (subscriber, #2750) [Link] (7 responses)

One interesting difference is that N900 is the main product, while Android Developer Phone is just that, a side product. In general one cannot select any Android phone from the market because of the limitations, instead having to trust there will be sensible... no, even cool dev phones from Google.

In my mind I also prefer N900 simply because its developers did not decide to throw everything on top of Linux kernel away, and have greatly contributed to GStreamer, D-Bus, now Qt, etc. over the years. Android seems more like Symbian in the sense that it was (or is) vaporware and then BOOM, there is a code drop of open source code but no open source community. I simply don't like all these proprietary vendors doing code-drops and then claiming they are open source right away - there's much more to open source than the code, and it takes years to build that.

/me uses Neo FreeRunner until there is some other phone fully usable with Debian, so therefore I'm interested if it takes a year or two for eg. N900 to be fully usable with Debian.

Toward a freer Android

Posted Oct 7, 2009 10:43 UTC (Wed) by fb (guest, #53265) [Link] (6 responses)

Notice that I own a G1 (converted into ADP), so I have some pro-Android bias.

> One interesting difference is that N900 is the main product, while Android Developer Phone is just that, a side product. In general one cannot select any Android phone from the market because of the limitations, instead having to trust there will be sensible... no, even cool dev phones from Google.

I think you nailed it here. Nokia produces both the software, and the hardware of the N900. Google only does the software. So the ADP, *promoted* by Google and actually produced by HTC, have this aspect of "secondary" product to it (and it sucks).

The G1/ADP hardware has now the advantage that so many people bought it, that it is very well supported by the community. So the "side product" issue was mitigated, but it is uncertain how we are going to have well supported recovery images when the Android FOSS-fans user base becomes fragmented into many different handsets. Nokia could win big time here.

I am curious about how well integrated and easy to use will be the N900. My wife has a Nokia smartphone, and I find it *very* poorly executed in some places. Nokia didn't even release this new Maemo, and (if I got it right) its API is already marked as deprecated.

Also, there is at least one company advertising another Free Android phone: http://www.engadgetmobile.com/2009/10/03/geeksphone-one-i... but most likely Nokia hardware would be better built. But in any case, we *may* have other devices will be released with root access, and decent support.

Toward a freer Android

Posted Oct 7, 2009 18:25 UTC (Wed) by brouhaha (subscriber, #1698) [Link] (5 responses)

Google doesn't manufacture the hardware, but Google did most of the hardware engineering that went into the G1 and ADP1. They provided this as a reference platform to HTC. So Google was much more "in control" of the hardware than you might think.

Sorry, but no.

Posted Oct 7, 2009 18:33 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

Google doesn't manufacture the hardware, but Google did most of the hardware engineering that went into the G1 and ADP1.

Not really

They provided this as a reference platform to HTC. So Google was much more "in control" of the hardware than you might think.

Not even close. HTC designed and provided the hardware. Sure, Google supplied requirements, but details were left to HTC - result is usual HTC crazyness (instal of 2.5mm jack and mini-USB or even normal 3.5mm jackand min-USB there are this strange combination favored by HTC).

Sorry, but no.

Posted Oct 7, 2009 18:44 UTC (Wed) by brouhaha (subscriber, #1698) [Link] (3 responses)

Sure, HTC changed the audio jack, but the reference hardware platform was designed by Android before Google bought them, much less before HTC got their hands on it. Even the mechanical design was done by Android, as one can see by the patent on the slide mechanism. Certainly HTC made some minor changes, but it was not fundamentally hardware designed by HTC.

Sorry, but no.

Posted Oct 8, 2009 1:25 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

Sure, HTC changed the audio jack, but the reference hardware platform was designed by Android before Google bought them, much less before HTC got their hands on it.

You are correct,of course. Google guys have developed initial version of the device. This is how it looked like. Find ten differences between Google's creation and G1...

Even the mechanical design was done by Android, as one can see by the patent on the slide mechanism. Certainly HTC made some minor changes, but it was not fundamentally hardware designed by HTC.

Hard to believe if you compare Google's creation and HTC's one. The only common thing they have is hardware keyboard! It was probably hard requirement at that stage so HTC was forced to design a slider. But other stuff... there huge number of differences between engineering prototype and G1...

Sorry, but no.

Posted Oct 8, 2009 1:42 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (1 responses)

That photo is one of the much later designs. The early ones were very similar to the G1. I can't find any photos of it, which isn't too surprising since Android was still in "stealth mode" at the time.

This is not photo.

Posted Oct 8, 2009 16:22 UTC (Thu) by khim (subscriber, #9252) [Link]

I can't find any photos of it, which isn't too surprising since Android was still in "stealth mode" at the time.

You can't find any photos if it because they don't exist. What I showed above is not even photo - it's default skin from the very first public release of Android SDK! Why it looks like that? Well - it's the render of actual developer device. Hundred of these or so were produced at the end 2006 (not 2007, but 2006!), but even if HTC produced them (and they even beed spotted in the wild eventually) HTC hated them. And so HTC developed Dream (aka G1) - with Google's guys help, of course, but it's not Google creation.

Later Android SDK stopped using this skin and switched to G1-like skin. Why? Google finally got sizable number of new HTC-developed devices and dropped support for it's own development platform and form-factor. First prototypes were ready by the middle of 2007, but developers got sizable number of them closer to the end of 2007. Public, of course, got them in 2008. That's the story and please don't try to rewrite it. If you are correct and initial creation was like Dream and later ones were like aforementioned developer platform,then how come we never got anything like the development platform? Why it was used by default in the very first release of the SDK and not in the later ones? Why all photos of the "later design" (by your interpretation) are shown with early versions of Android (ribbon-like interface was in the first release of SDK and in the first presentation video) and never with modern UI design? Facts just don't add up to your crazy story, sorry.

Toward a freer Android

Posted Oct 8, 2009 3:52 UTC (Thu) by daniels (subscriber, #16193) [Link] (2 responses)

The vast, vast, vast (in fact, basically all) majority of the actual power management code is in the kernel. DSME is replaceable with few-to-zero negative consequences.

Toward a freer Android

Posted Oct 8, 2009 12:07 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

So much for the 'differentiation' then. A difference that makes no difference is no difference :)

Toward a freer Android

Posted Oct 8, 2009 12:48 UTC (Thu) by xav (guest, #18536) [Link]

"in the kernel" doesn't mean it's GPLed code, unfortunately.

Toward a freer Android

Posted Oct 6, 2009 21:13 UTC (Tue) by maks (guest, #32426) [Link] (3 responses)

Intel guys at the Linux Plumbers were telling that Google is pretty anal about Android. They require the phone to have a special look and a hardware set pretty similar to what is already out (once you brand it as Android, but that is what the market is looking for). Too bad if android would loose by freezing tech progress due to stupid $big_company_stupid_law_enforcement.

Toward a freer Android

Posted Oct 7, 2009 8:29 UTC (Wed) by nedrichards (subscriber, #23295) [Link] (1 responses)

I believe those are for the 'with Google' closed source parts mentioned above.
Manufacturers who want to do their own thing with the UI (like the HTC Hero
and Motoblur) aren't allowed to ship those closed source apps (apart from the
Market).

Toward a freer Android

Posted Oct 7, 2009 12:45 UTC (Wed) by Aissen (subscriber, #59976) [Link]

I believe those are for the 'with Google' closed source parts mentioned above.
Manufacturers who want to do their own thing with the UI (like the HTC Hero and Motoblur) aren't allowed to ship those closed source apps (apart from the Market).

It's not as simple as that. The HTC Hero includes all Google Apps and, so will Motorola DEXT/CLIQ with Blur. There are three levels of connection with Google:

1- having the "with Google" logo. Google will impose you to have an almost same-as-original Android build. Upgrades will be Over-The-Air (OTA), from Google servers, in collaboration with your Carrier. G1 in the US and Magic in Europe (for example) are at that level.
2- having Google Apps, but no special logo. You can therefore have your own interface, like the Hero or Dext. Or keep the stock android UI like the Samsung Galaxy. I guess you must be tied with Google and there must be some secret agreements (as in Level 1) to be at that level. There's no OTA on this kind of phone/device (maybe a carrier/manufacturer will prove me wrong?)
3- no link at all with Google. You can ship whatever you want. No proprietary Google Apps(Market, Maps, Calendar, Gmail, Talk). The Archos 5 IT is at that level (for now).

Toward a freer Android

Posted Oct 7, 2009 16:26 UTC (Wed) by Baylink (guest, #755) [Link]

> once you brand it as Android

Nobody brands *anything* as Android, which point someone recently made as a bad thing, somewhere in the press. Everone shipping an Android phone has a different name for it; sometimes *two* different names. (G1, MyTouch)

Toward a freer Android

Posted Oct 6, 2009 21:30 UTC (Tue) by job (guest, #670) [Link] (1 responses)

The Cyangogen build system apparently works. Couldn't you just rip out the proprietary parts? And why is ADP1 the target platform? Cyanogen is used on contemporary phones such as HTC Hero and Magic (apparently it has a flexible bootloader so you don't risk bricking your phone) so it should be all you need.

Toward a freer Android

Posted Oct 9, 2009 21:57 UTC (Fri) by GNUtoo (guest, #61279) [Link]

>Couldn't you just rip out the proprietary parts
That's what I started to do(in collaboration with other people) with the replicant( http://trac.osuosl.org/trac/replicant/wiki ) project.
Basically we've achieved :
*calls(make/receive),sms(send/receive)
*sound(including routing)
What was already working:
*wifi(uses a proprietary firmware)
*bluetooth
*touchscreen(touch+screen)
*keyboard
*vibrations
What is not working:
*GPS
*camera
*3D
*compass
What is buggy:
*I didn't have time yet to look at why the US phones don't work...(CME error 100 => unknown error,may need to do everything manually with AT commands to see where the error is)
*routing don't work for calls(you can make or receive a call only with the handset mode(that is to say no earphones))

we can have 100% FLOSS builds that don't run any proprietary code on the main CPU.
The proprietary code that I didn't use is in a file called extract-files.sh:
#!/bin/sh

mkdir -p proprietary

adb pull /system/bin/akmd proprietary/akmd

adb pull /system/etc/AudioFilter.csv proprietary/AudioFilter.csv
adb pull /system/etc/AudioPara4.csv proprietary/AudioPara4.csv
adb pull /system/etc/AudioPreProcess.csv proprietary/AudioPreProcess.csv
adb pull /system/etc/firmware/brf6300.bin proprietary/brf6300.bin
adb pull /system/etc/gps.conf proprietary/gps.conf
adb pull /system/etc/wifi/Fw1251r1c.bin proprietary/Fw1251r1c.bin
adb pull /system/etc/wifi/tiwlan.ini proprietary/tiwlan.ini

adb pull /system/lib/libaudioeq.so proprietary/libaudioeq.so
adb pull /system/lib/libgps.so proprietary/libgps.so
adb pull /system/lib/libhgl.so proprietary/libhgl.so
adb pull /system/lib/libhtc_acoustic.so proprietary/libhtc_acoustic.so
adb pull /system/lib/libhtc_ril.so proprietary/libhtc_ril.so
adb pull /system/lib/libjni_pinyinime.so proprietary/libjni_pinyinime.so
adb pull /system/lib/libmm-adspsvc.so proprietary/libmm-adspsvc.so
adb pull /system/lib/libOmxCore.so proprietary/libOmxCore.so
adb pull /system/lib/libOmxH264Dec.so proprietary/libOmxH264Dec.so
adb pull /system/lib/libOmxMpeg4Dec.so proprietary/libOmxMpeg4Dec.so
adb pull /system/lib/libOmxVidEnc.so proprietary/libOmxVidEnc.so
adb pull /system/lib/libopencorehw.so proprietary/libopencorehw.so
adb pull /system/lib/libpvasf.so proprietary/libpvasf.so
adb pull /system/lib/libpvasfreg.so proprietary/libpvasfreg.so
adb pull /system/lib/libqcamera.so proprietary/libqcamera.so
adb pull /system/lib/libspeech.so proprietary/libspeech.so

adb pull /system/lib/hw/lights.goldfish.so proprietary/lights.goldfish.so
adb pull /system/lib/hw/lights.msm7k.so proprietary/lights.msm7k.so
adb pull /system/lib/hw/sensors.trout.so proprietary/sensors.trout.so

chmod 755 proprietary/akmd

there are some stuff including the RIL(see here: http://www.kandroid.org/android_pdk/telephony.html for more details),the libgps,an audio library etc...

I would have liked some help on the android side because I'm now trying to have a standard GNU/Linux system on my htcdream so I've no more time with android.
The 2 priorities were call routing and US phones like the ADP(basically it was tested on some European stock phones and the reference ril worked...but it didn't work on 2 ADP us phones),I bet that is the reason why the others members of the project are making a transition build that include proprietary components(they didn't have time or knowledge to debug the ril)

About the applications: we have no market yet but we can install FLOSS applications with adb(like the k9 mail client for instance)

BTW: we have code at gitorious(was faster to setup) (http://gitorious.org/replicant)

Toward a freer Android

Posted Oct 7, 2009 10:37 UTC (Wed) by njd27 (subscriber, #5770) [Link]

There is a lot of interest in free mapping utilities, including tools like AndNav which have the potential to surpass Google's maps program. AndNav works from OpenStreetMap data and has the ability to do turn-by-turn navigation - something that the Google tool is unlikely to ever be able to do.

Unfortunately despite the fact it uses the OpenStreetMap data, the AndNav software is proprietary. See here.

Toward a freer Android

Posted Oct 7, 2009 16:22 UTC (Wed) by Baylink (guest, #755) [Link]

It's worth noting that Verizon is commencing to make a fair amount of consumer-level noise about their forthcoming "4G" rollout.

A little bit of research suggests that this is, indeed, the 700MHz LTE data service they were competing with Google for on what are called the "Block-C" frequencies.

Why is this worth noting?

Well, it will provide a (very) high-speed IP data service to retail end users, who can run *any* protocol over it, using radios made by any manufacturer: there will likely be quite a bit more competition than previously since manufacturers merely need to meet the type-acceptance and network compatibility specs to be approved.

And when I say "any" protocol, I explicitly mean to include VOiP, which the TOS of all older cell-data protocols has explicitly forbidden.

If no wheels fall off the train on the way, this opens the door for Open Handsets that are actually *more* capable than current generation cellphones: there's enough bandwidth to support robust Forward Error Correction in both directions; you can use the carrier's gateway, or connect to your PBX; PTT over Cellular is a mere application install away (as long as the handset design *includes the friggin button*!! grrr); and finally, at 700MHz, it will have even better range and building penetration than Nextel, which is generally *much* better than 1900MHz "PCS" cell phones.

Plus, y'know, email, IM, web data, tethering, and none of it collides while you're using other stuff.

So, if we can get interchangeable radios in, say, CF-II format, and open handsets that let you plug the radio in, and can roam to WiFi when available... well, Bob's our uncle.

That Android's available to *run* on such hardware (and has OpenMoko, the Nokia stack, etc, to compete with)... gravy.

(No, I don't get money from any of those people. :-)

Toward a freer Android

Posted Oct 7, 2009 17:43 UTC (Wed) by ttonino (guest, #4073) [Link]

With regards to mapping: I _love_ Gpsmid (gpsmid.sf.net), which is an OpenStreetMap based J2ME application, especially as it uses maps on the device, saving on connection fees. It should be possible to run this on Android, as both are java-ish. And it is open source and full of features...

Toward a freer Android

Posted Oct 8, 2009 7:30 UTC (Thu) by bilboed (subscriber, #54668) [Link] (2 responses)

> (L)GPLv3 is out of the question in all circumstances - it scares the phone industry so much that we'd be hurting the entire Android ecosystem if such code made it anywhere into the Android Open-Source Project.

It scares the phone industry... yet... the overwhelming majority (if not all?) of the code in Maemo and Moblin is (L)GPL ? Oh wait, I also forgot the Palm Pre which uses (L)GPL stuff... oh and the Amazon Kindle... and the list goes on. Anyone said FUD ? :)

The biggest problem, having worked on making widely-used open-source middleware (like GStreamer) compile/work/integrate with Android... is that Google (or other partner of OHA) have gone out of their way to rewrite virtually all of the software stack, and what should have been a trivial task ends up being a never-ending nightmare.

What do users want: A shiny slick experience (1)
What do phone application developers want: A consistent environment (2)
What do phone manufacturers want: Be able to (re-)use the experience of their in-house/contracted engineers so they can ship a device as soon as possible (3)

(1) : Android is slick, no problem there
(2) : The Android java layer works accross several systems... well... if you don't try to use features from new phones that required creating "additional" APIs instead of extensions to existing APIs (which were not thought to be extended)
(3) : Total failure. Everything from kernel to the Java layer is unlike any other system. It's not a standard linux kernel, not a standard glibc, not a standard IPC system, not a standard multimedia framework, not a standard I/O system, not a standard ... oh man... I'm lost here. It's just a completely new software stack. So all your engineers/contractors that have got all this knowledge of existing LSB ... have to start again from scratch.

How to solve this ? Somewhere along the lines of :
Keep (1), Improve (2) and keep it backwards compatible, Fix (ditch?) the softare stack below Java by using the existing work done by Maemo, Moblin, etc...

Toward a freer Android

Posted Oct 11, 2009 12:51 UTC (Sun) by Velmont (guest, #46433) [Link] (1 responses)

I agree with you. But I think the emphasis here is 3 in GPL3, not GPL. Because of the patent-bits of GPL3 I would guess.

Toward a freer Android

Posted Oct 11, 2009 21:08 UTC (Sun) by bilboed (subscriber, #54668) [Link]

> I agree with you. But I think the emphasis here is 3 in GPL3, not GPL. Because of the patent-bits of GPL3 I would guess.

There's a reason I didn't specify any numbering in my comment. Since the very beginning (L)GPL has been TOTALLY out of the question in Android (they admitted screwing up for bluez)... I'm feeling way too tired and kind of fed up with Android to dig up the mails, but you'll find public statements in mailing lists from google/android people stating that (L)GPL software (without any numbering) is out of the question for Android.

GPLv3

Posted Oct 9, 2009 10:55 UTC (Fri) by angdraug (subscriber, #7487) [Link]

(L)GPLv3 is out of the question in all circumstances - it scares the phone industry so much

While this may look like a disadvantage from the point of view of a proprietary vendor such as Google, to me as a free software developer the message is quite the opposite. This here is a real world confirmation that GPLv3 has more teeth and less loopholes than GPLv2, enough so to be taken seriously by the patent holders and ASPs who have grown used to paying lip service to Free Software, taking advantage of our work while locking their results away behind DRM, web services and unbuildable code drops.

They've stopped ignoring GPLv3 and are now trying to fight it. I say lets push them back, push them into a corner and make them play fair with our toys! My software is already relicensed. Is yours?