Google Opens Up Android Codebase

rsk writes "It's official: Google has Open Sourced Android. The source code can be downloaded from Android's Git repository. Bugs are handled at the Google Code Android project page with documentation being handled by a collection of Google Site pages. One of the more interesting aspects of Android seems to be the seemingly Eclipse Foundation-like organization of the project, welcoming both Individual and Commercial developers into the Android development pot. One of the benefits of this arrangement is securing the existence of the project by involving commercial interests and their money in the process ... this is also one of the downsides; having commercial entities charter and lead features of a platform that their own commercial offerings provide 'enhanced' versions of, sometimes leaving the free offering always lacking in one obvious way or another. It's hard to say at this point how involved Google will be in this process, or the Open Handset Alliance in general, with managing the health of sub-projects under the Android umbrella as time goes on."

Comments

Let the porting begin!

[Zach978]

We need to port this thing to all kinds of devices, and would also be nice to port the framework to run natively so you could develop Android apps that would run natively on Linux.

Re:Let the porting begin!

[FunkyELF]

port it to the iPhone

Re:Let the porting begin!

[FunkyELF]

We need to port this thing to all kinds of devices

An open source platform for mobile phones isn't any good at all if there isn't a open hardware platform to run it on. Good luck modifying android and running it on your shiny new phone, tmobile wouldn't let you.

Re:Let the porting begin!

[James_Duncan8181]

Just like nobody ever got Linux running on the Xbox, right?

Re:Let the porting begin!

[H0p313ss]

We need to port this thing to all kinds of devices

An open source platform for mobile phones isn't any good at all if there isn't a open hardware platform to run it on.

I seem to recall some chatter on the OpenMoko Community mailing lists. They'd love to have already ported Android to their open hardware but there was no ARM4 binaries available to play with. I'm sure that with this source release I'll be able to boot Android on my Freerunner sometime this year.

Re:Let the porting begin!

[oravecz]

Why all the talk about T-Mobile not letting you do something. They don't have any claims over the software platform. Android will be soon be shipping on a variety of wireless carriers' phones.

Re:Let the porting begin!

[Chaos Incarnate]

You might be able to port the framework to the iPhone, but you could never release it via the App Store.

Re:Let the porting begin!

[Em Ellel]

You might be able to port the framework to the iPhone, but you could never release it via the App Store.

Erm, the whole point of porting it is to NOT deal with App Store. We are taking replacing the whole iPhone OS with something else (BSD based OS/X with Linux)

Getting the OS onto iPhone is easy - thats how Jail-breaking process works, the real hard part will be writing the drivers.

Can't wait though - I was very disappointed since I found out G1 does not support AT&T's G3 frequency and that I am stuck with iPhone for a while. Android on iPhone would be a decent cancellation prize - at least until better hardware that works with AT&T and runs Android comes out. ....wonder if someone will port it to Treo too? There are number of linux drivers for some of those already.

-EM

Re:Let the porting begin!

[Anonymous Coward]

...cancellation prize...

Word Nazi says you should try using words you know you know instead of ones you think you know. Your consolation prize is a reprimand from an A/C.

Re:Let the porting begin!

[squiggleslash]

AT&T has swatches of 1700MHz spectrum themselves, I expect they'll be putting UMTS on it in the medium term. Unlike T-Mobile they're not in a hurry to do so as they already had plenty of spectrum and so were able to roll out UMTS on their existing frequencies.

Re:Let the porting begin!

[FunkyELF]

Let me know when they have graphics drivers written for Linux on the Xbox.
I ran Linux on my xbox for several years but never did anything graphical...it was pointless. I just ran a game server (bf1942).
The most useful thing you can do with the Xbox is run XBMC which is built using illegally acquired XDKs. The hardware can't handle high def sources, but the hardware on the 360 could, and now XBMC is ported to Linux....so where is the Linux on the 360?
And before you talk about Linux on the PS3 let me just say that it is broken too and the only reason you can run it on there is because Sony let you.

Re:Let the porting begin!

[Em Ellel]

...cancellation prize...

Word Nazi says you should try using words you know you know instead of ones you think you know. Your consolation prize is a reprimand from an A/C.

...or what happens when you typo on an iPhone and not pay enough attention...

my bad ;-)

-Em

Re:Let the porting begin!

[Chaos Incarnate]

Ah. I was assuming the goal was to run Android applications on top of the iPhone OS, not replace the OS wholesale. My mistake. :)

Re:Let the porting begin!

[cl0s]

You can't really do this, well not as is besides the drivers because Android depends on a lot of hard keys. It does not even have an on screen keyboard (that I've seen). I actually HAVE to use my menu, back & home buttons.

The iPhone only has 1 button which could be considered the menu, but then theres no way to get back to your desktop as there is no exiting of programs they are left open until Android decides it should close it because you have other apps open and that one has been inactive for a while.

Re:Let the porting begin!

[jamshid]

I thought the same thing -- it would be really interesting, and a lot easier, to just port the Android Runtime http://code.google.com/android/what-is-android.html (the core libraries and Dalvik Virtual Machine) on top of the iPhone OS. Doesn't seem like it would be hard, many of the listed Libraries are already ported, and code written for Linux ports easily to MacOSX. Then the iPhone can run Android applications, don't even have to recompile them. iParallels? :)

Re:Let the porting begin!

[cayenne8]

That freerunner looks pretty neat.

From reading the FAQ and some articles...it says it is not really ready for primetime, unless you are a developer.

Is this true? How easy to you find it to use? What about the apps currently available for it? What service providers can you use it for?

Can you give some detailed info on how you use the phone and how you find its ease of use, and utility as far as what you can do with it with available software?

Re:Let the porting begin!

[hackbod]

It won't be nearly that easy. The Android application environment makes no attempt to hide the underlying protected memory multiprocess kernel -- apps can create multiple processes for themselves, run services in the background, schedule events to be woken up in the background, connect to each other to communicate with IPC, etc. And of course there is the WebKit available through the WebView API that many rely on, etc.

Also the application model itself is very different than the iphone: in Android an app just stays running until the system decides to kill it, and the system maintains state about it while it is killed to help it restart in its same state. So you would need to have a lot of the persistent system services running (especially the activity manager) or app switching would be pretty broken.

And there is the global clipboard, too! ;)

But it boils down to: Android is not just a Java application framework, it is a complete floor to ceiling operating system, and the application API reflects that.

Re:Let the porting begin!

[Anonymous Coward]

Why not just support the efforts of companies supporting Linux? If we support the companies actually supporting Linux, it stands to reason that we'd see more Linux products on the market.

Re:Let the porting begin!

[Anonymous Coward]

The solution to your problem is simple. Spend a lot of time changing the source code of Android so that your problem doesn't exist.

Re:Let the porting begin!

[jamshid]

I don't understand -- an iphone app (at least jailbroken) can do all those things: IPC, run in background, launch other processes. Don't confuse Apple's App Store restrictions with iphone os restrictions.

Don't know what you mean about webkit -- of course that's been ported to the iphone.

Like an Android phone, the iphone is in many ways just a little unix box in your pocket, so assuming all of Android is open source, seems possible to port enough libraries over to allow Android apps to run.

Re:Let the porting begin!

[Anonymous Coward]

We need to port this thing to all kinds of devices, and would also be nice to port the framework to run natively so you could develop Android apps that would run natively on Linux.

Android apps do run natively on linux, retard.

Re:Let the porting begin!

[Kratisto]

Doesn't putting a different OS on an apple product completely violate the point of an apple product? The advantage of apple's computers is that OSX works about as perfectly as you can expect an operating system to work because they know ahead of time what kinds of hardware they need to develop support for. Having said that, Android on the iPhone would be pretty cool (although, I don't like touch screens very much at all).

Re:Let the porting begin!

[jmcnaught]

The Openmoko isn't ready for prime time at all. It reminds me of using Linux in the nineties--lots of configuring stuff by hand--but at least back then when you got it working it was stable. I'm still getting lots of slowdowns and crashes. The GSM reception drops out every few minutes... sometimes it's better, sometimes it's worse depending on the distro you're using and what updates you've applied. Even Qtextended (formerly Qtopia) crashes a lot. I don't think the GSM reception thing is hardware related because I've had it running perfectly before. There are also basic problems like how it doesn't always wake out of suspend when you have a call or a text message, but I think that's been mostly resolved.

Something I discovered the other day was that even if you leave the phone plugged into the wall charger all night you might wake up with a dead battery. Once the battery is charged it starts draining. The best part is that if the battery is completely drained you can't power up the device even when it's plugged in. You actually have to get a new battery if you ever let it completely drain... or have the tools and knowledge to resurrect a dead battery on your own. Thankfully my brother also has a Freerunner so I managed to power on with his battery then swap mine in after it booted.

Watching from the outside it seems like the Openmoko team really lacks leadership. They started working on a GTK+ based system and released it as 2007.2... that one was close to being functional but the GSM parts were unstable. So they started working on ASU (now called 2008.8 or .9) which is a mish-mash of Qtopia ported to X11, Enlightenment and PyGTK. That's what they're focused on right now. But they've also got the project called FreeSmartphone.org, so they have a third distro called FSO. FSO has its own phone stack instead of using the one from Qtopia. Eventually they'll bring the FSO phone stack to 2008.8.

They also just announced that they're going to stop developing the applications they've been working on and focus on stability and reliability of the basic phone functions and suspend/resume. That's the best news I've heard out of the team yet.

Of course there are also community distros. Rasterman releases some of his own experimental builds and so do a few others. There's a distro called Fat and Dirty Openmoko (FDOM) that is just 2008.8 with a bunch of apps installed and some fixes applied. And you can run Debian on it too, but I haven't tried that yet.

As far as applications go, I imagine you could port anything that runs on your Linux desktop to the phone as long as it's not to resource intensive. The phone has X11 and it's even got 3d acceleration.

Right now on my phone the address book, dialer, calendar and sms/email are from Qtopia. I have Pidgin, Pythm (an mplayer front end, untested), Navit and TangoGPS for GPS, Linphone for VoIP (haven't really used it yet). For browsing I've got Minimo 0.2 (it kinda sucks) and Midori (webkit based, just installed it today). And I have Duke Nukem 3d which is controlled by tilting the phone. Sounds like fun, but it's actually a little tiresome. I was thinking of installing Abiword but I don't know how much word processing I'll be doing with the touch screen keyboard.

So I guess to wrap things up you shouldn't get this phone unless you've got money to burn for a cool pocket linux gadget. I still use my cheap Nokia flip phone most days. But the Openmoko is fun to play with and it comes with a really nifty stylus/pen/laser pointer/flash light. Really.

I'll probably try Android on it, but only after someone else releases kernel and rootfs images so I don't have to do much work. I'm still much more interested in the Openmoko platform than in Android because the Openmoko is much closer to a familiar GNU/Linux system than Android ever will be.

One thing that would be nice though is if the market gets flooded with smart phones that boot Linux kernels with all devices working. Because I was thinking that down the line I might buy an Android phone so I can put Debian or an Openmoko derivative on it.

Re:Let the porting begin!

[Anonymous Coward]

It is perfectly usable in almost any way you want, but at this point there are certain sacrifices depending on what you want. If you want to use it as an everyday phone/mp3 player, then you have to use qtopia/qt extended. But no games (worthwhile anyway), a decent but crummy in comparison gps client that's a bitch to install, no accel, basically nothing that makes linux on my phone cool. Using asu (now called 2008.8) I got duke3d running great, numpty physics, 28 other random ass games though some were kinda repeats, remoko to control my pc. I have a map of my entire country stored on an SD card so I can get directions from anywhere using navit. There is a SIP client available so that means VOIP from anywhere where you have wifi. But wifi is kinda buggy (works fine the first time you connect and sometimes at other times, but other times it you have to reboot the phone) and audio in phone calls dies after a day of it being on (i'm sure a fix is imminent though). The alsa-state files are not really kicking in with 2008.8 so you have to do a bunch of crap to get headphones working properly. To change the background image required dismanteling the entire theme (edjgedecc) file then swapping the pic that I wanted, reassemble theme (edjecc), upload to phone. Besides this, there is a debian and gentoo port which is pretty fucking amazing in and of itself (with a usb keyboard that's essentially the power of a laptop in your pocket). Long story short, if you've been using linux for a few years, it's nothing you haven't had to do since before the Ubuntu days: did you have to be a developer to use linux before 2003? If you are comfy with the command line and doing stuff it's pretty good.
P.S. you can use it with any gsm provider, I live in Canada but it worked fine when I was in Africa. Also all the above statements about 2008.8 may change depending on if you use the stable, testing, or unstable branches. I was mostly using testing.

Re:Let the porting begin!

[hackbod]

If you are relying on running a jailbroken phone, then yes it is certainly easier. But still, it isn't a matter of porting an application framework to another OS -- you are really porting a big chunk of an OS to another OS.

I'm not saying it's not possible, but I am pretty sure it would be a quite significant amount of effort.

Re:Let the porting begin!

[Anonymous Coward]

No you're a towel.

Re:Let the porting begin!

[jawee]

Definitely seems to be working now... http://www.xbox-linux.org/wiki/Screenshots

Re:Let the porting begin!

[Anonymous Coward]

wouldn't that be consolation prize?

Re:Let the porting begin!

[g0at]

a decent cancellation prize

Heh; I guess you mean consolation prize.

-b

Re:Let the porting begin!

[H0p313ss]

As other people have pointed out, the Freerunner is not a mainstream device and will not be for quite some time, in fact the current revision of the hardware has a number of acknowledged bugs that cannot be worked around in software. The software is hardly beta quality, more like alpha.

My own feelings vary from awe to frustration. We're talking about a handheld device with GSM nad GPS and bluetooth radios that is an order of magnitude more powerful than the first machines I ran linux on. (My first linux machine was a 386dx 33Mhz with 16Mb RAM and 100MB HD and a plain old VGA card, the Freerunner has a 400Mhz ARM4, 128Mb RAM and 256 Mb of flash storage on the motherboard and a microSD slot and a 600x800 touch screen.)

But I have used mine as a daily phone for almost four months with about 90% reliability, which for a alpha/beta product is not so bad really.

In short a cool and geeky device that needs serious TLC and probably presents more potential than actual. What it really needs is more people with the time and skills to improve every aspect of the hardware and software.

And FYI, the Android porting discussion has begun.

Re:Let the porting begin!

[Anonymous Coward]

are you asking an honest question or are you just trying to pull my leg?

xbox-linux.org
free60.org

Re:Let the porting begin!

[FunkyELF]

definitely not accelerated. Just because you can run tux racer doesn't mean that it is accelerated.
My point is that the same thing will happen on mobile devices. You won't be able to take advantage of hardware that is there unless you have the phone maker's blessing.

Re:Let the porting begin!

[badkarmadayaccount]

application API...

Department of redundancy department much?

Re:Let the porting begin!

[Eccles]

Department of redundancy department much?

We have several such departments.

Re:Let the porting begin!

[H0p313ss]

Things are progressing very quickly... there a whole page of Android info on the wiki already. I was being a little optimistic in my initial posting, but for once I seem to be right.

Allowing "Banned" Features

[TheMeuge]

When G1 was first introduced, it became painfully clear that it was severely hamstrung by the carrier-dictated limitations on software features.

The Bluetooth stack was totally castrated, leaving out not only tethering and PAN, but also voice features, as well as file transfer.

There are a lot of these glaring omissions in G1s software, that were clearly dictated by T-mobile. My question is this... now that Android has been open-sourced, will Google and T-mobile team up to block 3rd parties from filling in these features? Because as it stands, the G1 actually has less features than the competition, in clear contrast to the wealth of features and freedom of alteration that was touted as the hallmark of the Android platform.

Re:Allowing "Banned" Features

[tsa]

I'm so glad to live in Europe. The utterly retarded US mobile phone market never ceases to amaze me. But, since I don't know anything about programming, let me ask a stupid question: can you in principle port Android to any modern phone out there, or are there hardware requirements?

Re:Allowing "Banned" Features

[im_thatoneguy]

Weird.... Google said the bluetooth decision was theirs due to stability.

There is a Skype voice App in the G1 Marketplace.

File transfer? You have Mass Storage, You can attach files to emails. There is no limitation I am aware of in android which would forbid a p2p application which uses the memory card.

But I'm sure you're right. It's a conspiracy by TMobile to not offer... what is it you want again that you aren't getting? It's not like exchange missing is a conspiracy. The G1 is missing quite a bit of stuff but I would wager it's a result of development resources being insufficient not intentional desires to offer less.

Re:Allowing "Banned" Features

[Wrath0fb0b]

But I'm sure you're right. It's a conspiracy by TMobile to not offer... what is it you want again that you aren't getting?

(1) A2DP and AVRCP
(2) Bluetooth tethering (can be implemented as a DUN)

These are two things that work fairly well on my WinMo 6.1 (HTC6800) and should be a piece of cake. I would switch to the G1 for those things (and if TMobile had a 3G network comparable to the EVDO revA that I'm on now -- they don't).

Re:Allowing "Banned" Features

[Zach978]

They just ran out of time with Bluetooth. They also had to cut stereo bluetooth audio, why would t-mobile want to cut that?

Re:Allowing "Banned" Features

[Jah-Wren Ryel]

They also had to cut stereo bluetooth audio, why would t-mobile want to cut that?

So you would have to buy one phone for each ear.

Re:Allowing "Banned" Features

[not already in use]

Here's my take on the situation. Google realizes that carriers want strict control over their devices. This doesn't bother me one bit, nor does it bother 99% of consumers. The 1% is does bother are people who want a profit-seeking corporation to bow to the wants and needs of a small minority.

It bothers me when people complain about this, because the software is open. Branded versions will always be based on the open version, much the way you see MyEclipse staying in tune with the vanilla eclipse releases. Combine this with the fact that there is existing open hardware available (and opportunities to create more) and this supposed "community" that can put it all together, it leaves me wondering, what is there to complain about?

Re:Allowing "Banned" Features

[NoTheory]

well... Android is a linux based operating system with a custom java virtual machine that accepts java files, and spits out .dex machine code which i think (but not sure) is specific to the G1 at the moment.

So in short, i don't think it's readily portable to other machines (i'm not positive though, it'll depend on the differences in chip architecture and the like, dunno how similar the G1 is to other phones).

Re:Allowing "Banned" Features

[cl0s]

You can install apps from the market, internet or the memory card. I've been able to install an iTunes remote through the memory card thats not yet available in the market. Too bad it didn't work with Rythmbox, but still I was able to install other apps with out going through T-mobile.

I'm very optimistic about how far hackers can take this. I mean look what they do with closed source propriety stuff. They might have a few road blocks purposely put there but have already given us a huge jump just by releasing the OS source.

Re:Allowing "Banned" Features

[mc900ftjesus]

Google didn't have a production-ready BT stack, they have already said this was their fault, not T-Mo.

Re:Allowing "Banned" Features

[outZider]

Uh, if you read Google's releases, it wasn't T-Mobile castrating those features, it was limitations of releasing a bug free 1.0, and they've promised more bluetooth functionality in later API and OS releases. T-Mobile has not neutered the bluetooth functionality on their other smartphones, why would they do it on the one device they're touting so well as 'open'?

Re:Allowing "Banned" Features

[butalearner]

I'm so glad to live in Europe. The utterly retarded US mobile phone customers never cease to amaze me.

There, fixed that for you.

Re:Allowing "Banned" Features

[repvik]

iPhone doesn't support stereo bluetooth audio (A2DP) either. Apparently, there is some reason to drop this, even from a multimedia-oriented phone.

Re:Allowing "Banned" Features

[CdBee]

Apple has a real reason to not implement a full modern Bluetooth stack - if they do it on the iPhone it will be expected/demanded/hacked onto the ipod Touch, and people would then use an iPod Touch with a cheapo bluetooth phone rather than paying the premium for an iPhone

Re:Allowing "Banned" Features

[blahbooboo]

I'm so glad to live in Europe. The utterly retarded US mobile phone market never ceases to amaze me. But, since I don't know anything about programming, let me ask a stupid question: can you in principle port Android to any modern phone out there, or are there hardware requirements?

There are a lot of negatives in the U.S. cell market (mainly with the handsets sucking and all the handset crippling). However, there is one clear winner, the cost of cell phone plans is FAR cheaper than in Europe. Yes, incoming calls might be "free" in Europe, but YIKES the caller pays a lot per minute and the receiver still has a more expensive plan.

I used to think the European cell systems were better, until I saw how much these folks charge versus what the user gets for this charge. The Europeans can't even implement continental wide calling without calling it "roaming" (uh, Orange is in every country) and charging roaming fees which the USA got rid of 10 years ago. I believe the EU is getting involved to finally end this...

In any case, there is no clear winner. Both systems have their pluses and minuses.

Re:Allowing "Banned" Features

[MikeDirnt69]

Apparently, there is some reason to drop this, even from a multimedia-oriented phone.

The reason is lack of features, just it.

Re:Allowing "Banned" Features

[Anonymous Coward]

You're wrong, people have already been running it on other devices (such as the HTC vogue, I think) for quite some time now.

Re:Allowing "Banned" Features

[jbailey999]

One of the reasons we chose git was to make sure that we can't do that sort of blocking. While obviously the Core Technical Team can control what winds up in the master repositories, part of the reason we chose a distributed revision control system was to make sure that ultimately we can't block new ideas and new features.

If you'd like to chat more, come by #android on FreeNode.

(obDisclosure: I work in the Open Source Programs Office at Google)

Re:Allowing "Banned" Features

[repvik]

That's gotta be the worst excuse EVAR. You can't use a cheapo BT phone as a *headset* and use that as a replacement for an iPhone. If it was the other way around, yes.

Re:Allowing "Banned" Features

[rsk]

Zach, you are correct, heard they ran out of time from one of the team members but it's suppose to come in 1.1 and at that time T-Mobile has the change to re-vet the OS and offer an upgrade to G1 users.

Not optimal, but when you think of how ambitious launching an OS is... I can't say I'm surprised.

Let's hope the upgrade process is smooth.

Re:Allowing "Banned" Features

[lupis42]

Here's my take on the situation. Google realizes that carriers want strict control over their devices.

Of course they do. So what? Why should they get it? I want strict control over people being allowed to park in front of my house. That doesn't mean I have any right to it. AT&T wanted strict control over what could be plugged into their telephone jacks. That doesn't mean they got to have it, and I for one am grateful that it was decided that the network should be open to innovative new devices, because I like the fax machine, and I thought the MODEM was pretty handy for a while there. So what if network operators *want* more control? Are they using a public resource to provide the network? (Hint the spectrum is currently considered a public resource). Then we the public have every right to attach conditions on their use of it. If we attach reasonable conditions, they'll try to meet them while making a profit, and innovation will be served. If we attach excessive conditions that they cannot meet, the market will work, they'll go bankrupt, and we'll have to decide if we need to subsidize them, ease the conditions, or just do without the product. This is how markets are supposed to behave, and this is how regulation should interact with markets.
I don't believe that a profit seeking corporation should bow to the needs and wants of a minority intrinsically, I believe that it is the responsibility of government to step in and *make* them bow to the needs of the *whole* public, when they use public resources. When AT&T got right-of-ways to install phone wiring, they were forced to install it everywhere, profitable or not. They were still able to make a profit, and things kept going. I don't see why the cell network operators shouldn't have to face some of the same quid-pro-quo.
In slashdot terms,
Step 1: Obtain access to public resources.
Step 2: Use them to make a valuable product.
Step 3: Attempt to use the control of the resource/network to leverage monopolistic power.
Step 4: Get smacked down with regulation.
Step 5: Learn how to make money off it anyway.
Step 6: Profit.
We're between steps 3 and 4 with the cellphone industry. Frankly, considering how much we've all come to depend on their product, I think they'll be able to manage step 5.

Re:Allowing "Banned" Features

[dfn_deux]

There isn't any support hardware for bluetooth on any ipod, never has been. I doubt sincerely that Apple left out BT profiles because they thought people would hack a BT radio and antenna on the touch. While some people may be capable and motivated to do such a hack I doubt that enough people would be capable or motivated enough to follow their lead; certainly not enough to make any considerable dent in Apple's bottom line. It is far more likely that the data features were left out to prevent people from hacking together tethering applications for the iphone and also to attempt to limit methods by which "unblessed" files/data can get onto the phone. as far as their lack of A2DP stereo support and total lack of music over BT headset I think it boils down to Apple not wanting to have low quality audio over the headset profile besmirch their relatively good name in portable audio AND the A2DP stereo protocol is actually quite a proc heavy operation and I'd suspect that it was left out because it impacted the user experience negatively. Anyone who has toyed with A2DP on a Nokia N810 web tablet can tell you that without using the onboard ADAC hardware that A2DP is basically garbage, causing ridiculous slowdown for the entire device and providing a generally bad audio stream as well.

Re:Allowing "Banned" Features

[not already in use]

Of course they do. So what? Why should they get it?

They are going to get it regardless. If the stipulations of Android didn't allow this, they would use something completely closed. Do you consider this a better alternative? Google realizes that to attain market share, they have to give carriers some control. This doesn't stop anyone from putting Android on an open platform, such as OpenMoko, so I'm still trying to figure out what all the fuss is about.

Re:Allowing "Banned" Features

[arelas]

Some, but I'm already running it on my HTC Titan. Just a matter of time before it runs on many devices.

Re:Allowing "Banned" Features

[Em Ellel]

Apple has a real reason to not implement a full modern Bluetooth stack - if they do it on the iPhone it will be expected/demanded/hacked onto the ipod Touch, and people would then use an iPod Touch with a cheapo bluetooth phone rather than paying the premium for an iPhone

That's gotta be the worst excuse EVAR. You can't use a cheapo BT phone as a *headset* and use that as a replacement for an iPhone. If it was the other way around, yes.

I think you missed his point - he was saying the other way around. Get a cheap phone that supports bluetooth. Use Touch as the "headset" . Though without a microphone or bluetooth hardware in iPod Touch I am not sure how he suggests this will be done.

Now if someone builds a relatively cheap G3-to-wifi bridge - this can make things interesting.... but it has nothing to do with anything here.

-Em

Re:Allowing "Banned" Features

[repvik]

I got his point alright. Thing is that the iPhone doesn't support A2DP headsets. Even if it did, you wouldn't be able to use the iPhone *AS* a headset. You'd be able to connect headsets to it. It'd be the same with the iPod.
The iPhone could support A2DP headsets easily without supporting *being* a headset. Same with the iPod.

Re:Allowing "Banned" Features

[charlesnw]

Um. T-mobile has no problem with tethering or file transfer. My BlackBerry pearl does all that just fine. So does the Razr. T-mobile is a pretty friendly company and seems to be the least evil. As for a comment you make later on about nothing comparable to EVDO... um they have an HSDPA network rolled out in the majority of the NFL cities.

Re:Allowing "Banned" Features

[Anonymous Coward]

Apple has a real reason to not implement a full modern Bluetooth stack - if they do it on the iPhone it will be expected/demanded/hacked onto the ipod Touch, and people would then use an iPod Touch with a cheapo bluetooth phone rather than paying the premium for an iPhone

Maybe I'm being naive - What would you do with a cheap bluetooth phone and a bluetooth enabled ipod touch?

Re:Allowing "Banned" Features

[lysergic.acid]

the HTC Vogue might be running similar hardware to the HTC Dream (T-Mobile G1). either way, HTC is a member of the Open Handset Alliance, and they make a lot of popular carrier re-branded handsets. so you might be able to run Android on many of those devices.

the HTC Vogue/Touch uses the TI OMAP 850 processor while the HTC Dream/T-Mobile G1 is running on a Qualcomm MSM7201A ARM11. so other HTC phones running on, either Texas Instrument's OMAP or Qualcomm's MSM line processors, should support Android as well. in fact, all HTC phones run on either TI, Qualcomm, Intel, or Samsung processors. and it just so happens that TI, Qualcomm, Intel, and Samsung are all members of the Open Handset Alliance. so i wouldn't be surprised if all HTC handsets eventually supported the Android platform.

that's the power of having a strong cross-industry alliance supporting open standards. i think Android has a very good chance of dominating the cellphone market and potentially revolutionizing the industry.

Re:Allowing "Banned" Features

[Anonymous Coward]

That made no sense. Work on your logic or I'll work on my reading comprehension.

Re:Allowing "Banned" Features

[lysergic.acid]

both systems should be replaced with wireless broadband as part of basic public infrastructure. then you'd have truly carrier-neutral handsets.

right now handset makers need to get permission from the carriers to use their proprietary networks. they have to cripple their phones and let the carriers lock down their software. no new technologies or applications can be developed without the carrier's approval--that's why there's been very little growth in cellular technology compared to the progress made on the public internet.

with cellphone towers replaced with municipal WiFi/WiMax, we could just use VoIP handsets. anyone could develop their own wireless handset. and handset makers would be free to develop and implement new applications/technologies (VVoIP video calls, cellphone-to-cellphone file sharing, etc.). there'd also be no extortionate data plans, text message fees, roaming, and other artificial service charges. there'd be no $10,000 cellphone bill because you upload a few vacation photos. companies like Skype would route the calls, but you would choose whichever network was cheapest, fastest, or least busy--no service contracts or activation fees.

Re:Allowing "Banned" Features

[Em Ellel]

I got his point alright. Thing is that the iPhone doesn't support A2DP headsets. Even if it did, you wouldn't be able to use the iPhone *AS* a headset. You'd be able to connect headsets to it. It'd be the same with the iPod.
The iPhone could support A2DP headsets easily without supporting *being* a headset. Same with the iPod.

As I understood it he is not talking about A2DP specifically, but other features of "full featured Bluetooth stack" which include being a headset to a phone - which is still pointless as I do not think Touch has BT hardware anyway.

As for why not support A2DP - I am guessing it mostly has to do with making sure the iPhone survives past noon without needing a recharge (under current limited feature stack you can almost make to 5pm!!!)

-Em

Re:Allowing "Banned" Features

[NoTheory]

Cool, thanks for the info

Re:Allowing "Banned" Features

[WiseWeasel]

That's not the main reason. Apple is trying to encourage the ubiquity of the iPod connector interface, and including A2DP would severely undermine this, as car and electronics manufacturers would just use that to interface with iPods and iPhones instead of the proprietary iPod port. This would put Apple's competitors on much more equal footing with Apple with accessories and 3rd party electronics integration.

Re:Allowing "Banned" Features

[repvik]

I don't think the battery issue is relevant either. It does support headsets, just not *stereo* headsets. The battery sucks either way (Atleast until you jailbreak it!)
Seriously though, after I jailbreaked my iPhone, I can now get it to last almost two full days. Before that I didn't have a chance at a full days worth.

Re:Allowing "Banned" Features

[hackbod]

Dalkvik is not at all specific to the G1. The G1 is just running a standard ARM CPU.

Re:Allowing "Banned" Features

[lupis42]

They are going to get it regardless.

Why?

Why shouldn't we simply demand that the FCC (who's job is to defend our interests in the matter of communications) should be stepping and telling the carriers something like 'suck it up, you *have* to open this up or we'll take away your right to transmit'.

Re:Allowing "Banned" Features

[Em Ellel]

I don't think the battery issue is relevant either. It does support headsets, just not *stereo* headsets. The battery sucks either way (Atleast until you jailbreak it!)

Well, I think the difference is not in standby battery use, but in active usage. Average user probably talks on the phone a lot less than they would listen to iPod. That is how I think the battery usage for A2DP will have a huge impact.

-Em

Re:Allowing "Banned" Features

[Zebra_X]

T-Mobile is one of the most customer friendly carriers out there.

For example, if you have your phone for more than 3 months they will unlock it for you so that you can use other SIM cards while travelling. I learned this after paying to unlock my T-Mobile dash.

Additionally, they fully "tolerate" tethering. Again with the Dash, it was a matter of firing up the PAN app and connecting my laptop, no call required.

I don't know if this was just becuase I had a special rate plan but I also found that I was never charged a cent for international data. I can't imagine this was simply because they were that nice, since they are pretty clear about int'l roaming fees.

I'm actually disappointed with ATT, travelling was a hassel with the iPhone and the fact that you get charged just for your phone ringing abroad is absurd. Though i did find that if you forward your calls to another line before you leave the country you will escape those nasty fees.

Certainly not all carriers have T-Mobiles customer centric nature Verizon is pretty adament about controlling how you get things on and off your phone, and ATT isn't much better.

Personally, I think T-Mobile was the best possible choice for Google simply because they are so flexible.

Re:Allowing "Banned" Features

[MobileTatsu-NJG]

if they do it on the iPhone it will be expected/demanded/hacked onto the ipod Touch,

How are they going to hack BT onto an iPod Touch in a way that they aren't able to now? I don't even want to imagine the trouble you'd have to go through and how ugly that'd look.

and people would then use an iPod Touch with a cheapo bluetooth phone rather than paying the premium for an iPhone

Two problems:
    1.) Apple still makes money.
    2.) There's no way this would be widespread adopted enough to give Apple much to worry about, especially considering the first point.

Re:Allowing "Banned" Features

[Hel Toupee]

I don't think Apple cares that you're making calls. They care about the internet connection. If you enable bluetooth on the Touch, then you can get a cheap bluetooth-enabled phone and tether the Touch to it, and have what I believe Apple thinks is the essence of the iPhone -- 24/7 internet connectivity.

Re:Allowing "Banned" Features

[cyngus]

.dex is not machine code, its virtual machine bytecode.

Re:Allowing "Banned" Features

[CdBee]

I was saying - get a cheap Bluetooth phone, use the iPod Touch tethered to it for all the clever web stuff that other phones dont do as well and that is the main sales driver for the iPhone. Apple prevents bluetooth tethering on ipod touches and iPhones (although the Touch has a bluetooth chip!) as well as preventing the more well-known audio bluetooth uses

Re:Allowing "Banned" Features

[rbanffy]

There is a minor problem in your logic: the Touch has no bluetooth functionality. At least mine does not. BT is part of the "phone side", which encompasses the stuff you usually find in a cheap phone: voice, data, bluetooth and a camera. The rest is an iPod/PDA.

Re:Allowing "Banned" Features

[Anonymous Coward]

As other people have pointed out, .dex is the Dalvik virtual machine format, and that's open source under the Apache 2.0 license. Last I checked, Dalvik is a pure interpreter (no just-in-time to generate machine code) so it's not even tied to ARM.

Most of Android should be pretty portable to anything that runs Linux. Probably the biggest issue you'd run into is interfacing with the telephony chipsets.

Re:Allowing "Banned" Features

[Weedlekin]

This is a far more likely reason than any of the others that have been given, because:

1) Apple very likely pull in a fair bit of revenue from 3rd. party accessory manufacturers who license their proprietary iPod connection protocols and logos.

2) iPods are ubiquitous, so those connectors crop up in all sorts of unexpected places, and the fact that Apple won't license the protocols to other MP3 player (and phone) manufacturers means that people who want to use anything that has such a connector have to buy from Apple.

This sort of practice is very common in the consumer electronics world, where interoperability is often defined as being able to use a device by one manufacturer with other devices from the same manufacturer. It even happens with standard protocols and connectors such as HDMI, MIDI, etc., which are frequently used to carry manufacturer-specific data that's only understood by other devices from them, and isn't published or licensed to third parties.

Re:Allowing "Banned" Features

[Jisakiel]

They could support A2DP and file transfers though. For listening music in the car without plugging it in (even in the ipods), and for sending those silly pictures and ringtones (ah, less revenue!) as the rest of us have been doing since around forever.

Re:Allowing "Banned" Features

[Anonymous Coward]

Open source. Go write it if it's a piece of cake.

Finally...

[Anonymous Coward]

... hopefully all the anti-google critics will shut up now.
There have been many comments of people, critizing the hell out of android. Now they can change what they don't like.

p.s.: let the apple vs google flamewar begin!

Re:Finally...

[NoTheory]

No they can't. The platform is still locked down. Google still has device killswitches. They can fork if they don't like what Google's done but that's different from changing what they don't like about how Google's using Android :P

Re:Finally...

[Anonymous Coward]

They only have a kill switch for apps installed through the App Market. It's trivial to install an unkillable app otherwise.

Re:Finally...

[lorenzino]

Damn it!
You seem like my colleague ..

The Kill Switch (TM) you are talking about is *part* of the
Wait for it ..

Android Market Terms of Service.

This is for application *distributed* over the android market.
And we already know that you can install applications by other means (memory card is one of them, maybe web/email/other market too) as well as the Official Market.

Big deal, I agree with them and I think this can only be positive.
I guess it could allow google to stop a competitor via the main official channel, while still allowing them to install them.
Like a normal mac/windows/linux box.
But I guess it could help make the main market, where Joe Sixpack buys, a safer place in terms of malware and viruses.
After all, you can still install anything you want.
I like the way Maemo does it .. apt like but easy as a click or a tap with the pen.

Hackability

[Microlith]

Looking at the misfeatures implemented by Motorola into their phones to inhibit hacking (signing the bootloader, kernel, filesystems) and the frequently missing drivers, it makes me wonder how far one could take the environment released here.

Could you, once built, take the resulting setup and shove it on a G1 and run it? Or are there similar vendor lockouts like those Motorola has implemented?

I'd like to see a tivo-dodge here, but I'm not optimistic.

Re:Hackability

[not already in use]

The real question -- How hard to port to OpenMoko? Or, another open hardware initiative to take advantage of everything Android has to offer.

Re:Hackability

[Microlith]

OpenMoko is about the software, not the hardware. It can't be because the Freerunner is light years behind the G1 and every other smartphone out there. There have been efforts to port it to other hardware, but generally doing so is difficult because of the mobile arena being a very end-user hostile environment.

OpenMoko and Android are mutually exclusive, unless you really have a thing for getting your phone to dual-boot operating systems.

Re:Hackability

[Wumpus]

I wouldn't say the Freerunner is "light years" behind the G1. The CPU is an earlier revision of the ARM architecture, there's plenty of memory, the phone has WiFi, GPS, Bluetooth, accelerometers, a nice VGA resolution screen, it supports uSD cards for storage... And the hardware is as open and documented as any GSM phone is ever likely to be - more than the G1, most likely.

The reason earlier attempts to port the Android stack to the Freerunner failed was that the source wasn't available, and the binaries Google provided were compiled for ARMv5, not ARMv4. With the source now being available, there's a good chance Android will run on the Freerunner.

Re:Hackability

[SWPadnos]

In what ways do you suppose the FreeRunner is light years behind?

I know one deficiency, that it's only tri-band (you have to select 850 or 950, and you get 1800/1900 in addition). It's also a bit bigger than some other phones. I guess the choice of GPRS instead of EDGE may also count against it. Hmmm.

So I guess I know three deficiencies :) Any others you can think of?

Re:Hackability

[stupkid]

there's a good chance Android will run on the Freerunner.

So much of a good chance in fact that Koolu is committing to shipping their FreeRunners with Android installed starting in November.

Re:Hackability

[Wumpus]

I'm afraid Koolu is jumping ahead of itself. November is less than two weeks away, which doesn't sound like enough time to port all the code to a new platform if something goes wrong. If everything goes smoothly - sure. But software is rarely that simple. But then, maybe they know something I don't.

I'd love to see it happen - I own a Freerunner, and I'd like to have more options and the kind of stability and usability on it I got from my first Linux machine in 1991...

Re:Hackability

[tchuladdiass]

The lack of EDGE (at least) is the biggest deficiency for me. Online work is painful at 30 - 50 kbps.
Another one (for some people) is the lack of a camera, although that don't bother me much. A bigger issue though is the lack of buttons. I don't need a full keyboard on a phone, but it would be nice to at least have the number keys (similar to how the Motorola A780 did it, or even as a slider-style keypad).

If not for the lack of buttons and lack of EDGE, I would have picked one up already.

Re:Hackability

[not already in use]

Thanks for the clarification. But yeah, what I was trying to refer to was the open hardware.

Re:Hackability

[musicalwoods]

OpenMoko seems to be responding to the community with respect to the deficiencies with its hardware.

Their next phone, the GTA03, which is currently in development will have EDGE, a camera, a 3.5mm jack, no compromised glamo chip, and a completely new case design.

All of this info was pulled from here, and probably subject to change. http://wiki.openmoko.org/wiki/GTA03

Re:Hackability

[Anonymous Coward]

You meant ahead, right?

Re:Hackability

[Wumpus]

No, not really. Why?

Re:Hackability

[Anonymous Coward]

It already runs on the FreeRunner.

Re:Hackability

[Wumpus]

Really? Where?

I follow the discussions on the Openmoko mailing lists, and people are just starting to discuss a possible port. If anyone got it to run already, they must have kept it a secret from the rest of the world. Except you, evidently.

Re:Hackability

[Anonymous Coward]

The next revision (GTA03) of freerunner (or whatever it is going to be called) is going to have edge.

What other devices will we see?

[LWATCDR]

When will we see a port to the Palm Treo?
And how about a lightweight netbook version?
Or just a light weight GP disto based on Android.
The hard part will probably be the JVM/JIT compiler.

Re:What other devices will we see?

[CdBee]

if you search a site called 'Internet Tablet Talk' you'll see some enterprising types have already got the Android preview version running on a Nokia N810 web-pad

Android on a Netbook would be superb

Re:What other devices will we see?

[dfn_deux]

Don't bother to install this unless you are are a dev. The early release that they have working on the n810 is excruciatingly slow since it runs on top of the existing maemo/hildon UI on an already resource limited platform; furthermore the android install is so feature bare that it transforms a reasonably versatile little tablet into a pretty useless little screen which does almost nothing and and what is does do is doesn't do well.

Re:What other devices will we see?

[dreamchaser]

Why would you want to run Android on a netbook when there are already perfectly good Linux distros that are more well suited to a non-phone appliance?

Re:What other devices will we see?

[LWATCDR]

Well so far most of the distros I have seen on netbooks are not that great.
A lot of people just install Ubuntu refresh on them.
Android is designed for a small screen and low cpu power. It may be a good match for netbooks.

Re:What other devices will we see?

[dreamchaser]

Fair enough, good points.

Re:What other devices will we see?

[Anonymous Coward]

I don't think the Dalvik VM has a JIT compiler (I haven't checked though), and I'd imagine the VM should run on any linux distro. Linux doesn't run particularly well on the Treo 650 though.

Re:What other devices will we see?

[ZERO1ZERO]

I agree. But in your parent post I think you meant 'heavyweight' instead of lightweight. Otherwise, 'lightweight' is redundant. /pedant

Re:What other devices will we see?

[LWATCDR]

Not really. Most netbook distros are actually pretty heavy compared to say puppy, DSL, and Google.

Re:What other devices will we see?

[LWATCDR]

Android might.

Earth to Slashdot

[Whitemice]

>having commercial entities charter and lead
>features of a platform that their own commercial
>offerings provide 'enhanced' versions of

Earth to Slashdot... this is how almost every major OSS project runs; people who pay for developers [such as me] will get the features they want.

Re:Earth to Slashdot

[morgan_greywolf]

Earth to Slashdot... this is how almost every major OSS project runs; people who pay for developers [such as me] will get the features they want.

Indeed. This is not new. Apache, Samba, the Linux kernel, OpenOffice.org, Mozilla's product line, Eclipse, etc., all have features that were bought and paid for by someone, whether by directly employing the individuals involved, or through donations to a supporting foundation, or a little of both.

I'm not saying that's good or bad -- it's just a part of the open source landscape today and will remain so for quite some time to come. It's good in that encourages development that benefits everyone. It's bad in that development effort may tend to get concentrated along pet projects that may or may not be useful to the greatest number of users.

But, like everything else in life, you take the good, the bad and the ugly and roll with it.

Re:Earth to Slashdot

[vux984]

Earth to Slashdot... this is how almost every major OSS project runs; people who pay for developers [such as me] will get the features they want.

No. There is a big difference.

Typically when a commercial entity leads development of OSS where they have a propriety solution that enhances it, they PREVENT those key proprietary feature from EVER being added to the free version. Thus the ONLY way to get it to use their paid version.

Even if the community WANTS the feature in the free version, and volunteer developers are willing to build it, the commercial entity prevents it from happening. Refusing those patches, playing politics, and so on.

Of course the OSS community can always fork the project... but then they lose out on all the good things the commercial entity IS feeding into the development, and you get all the other community fragmentation issues that go along with forking too... there is no win-win.

Re:Earth to Slashdot

[Whitemice]

>Typically when a commercial entity leads
>development of OSS where they have a propriety
>solution that enhances it, they PREVENT those key
>proprietary feature from EVER being added to the
>free version. Thus the ONLY way to get it to use
>their paid version.

We don't yet know who will "lead" Android development. If it will be the OHA, Google, or someone/something else. Only time will answer that question.

While what you cite it certainly a legitimate concern I've very rarely seen it in practice. All the development work I've done for $$$ on OSS software has gone upstream or at least been released. There just isn't as much perceived benefit to keeping-code as many people think; perhaps there is if a company actually controls a product and 'owns' the user base. But that is pretty rare. Where are the proprietary features in Apache, Samba, MIT or Heimdal Kerberos, OpenLDAP, Mono, etc...? These products all have very large commercial contributors and are all fine examples of openness.

Most companies that sell FOSS (in any capacity) use it to sell solutions and not as a product. So the lock-it-up just doesn't really benefit anyone.

Re:Earth to Slashdot

[vux984]

These products all have very large commercial contributors and are all fine examples of openness.

Yes. Its absolutely true that not every commercial led OSS project takes this path. But its not as rare as all that... here are examples of major projects that are taking this path to some degree or other:

Scalix, Zimbra, VMware, Amanda Backup, MySQL

Its not that I object to companies creating proprietary extensions or enhancements to OSS software, ESPECIALLY given that in many cases they are the ones who created the software and then open sourced it.

But at the same time, the community is seriously stifled in terms of making enhancements to the OSS software to give it the desirable features of the proprietary enhancements. So 'yes' its open source, but the promise of open source isn't really being fulfilled, where OSS is more a marketing ploy than an invitation to modify the source and add features.

Re:Earth to Slashdot

[Whitemice]

>here are examples of major projects that are
> taking this path to some degree or other:
>Scalix, Zimbra, VMware,

None of these three are OSS projects; in the case of Scalix and Zimbra I think they are commercial products masquerading as OSS projects. VMware is certainly NOT an OSS project by any definition at all. Simply utilizing Open Source components does not turn something into an OSS project.

In defense of things like Scalix and Zimbra (not that I'm inclined to defend them) most of what they offer is Open Source. Stand-alone components like Outlook/MAPI connectors/plugins are different animals; there are real reasons why those are not generally OSS. And having independent units under different licenses in entirely OK.

>Amanda Backup, MySQL

Yep, I'll agree with those. (Fortunately alternatives, even superior alternatives [such as PostgreSQL], exist). And is "Amanda Backup" a "major" project?

I just don't see "seriously stifled in terms of making enhancements to the OSS". What significant feature has someone contributed to MySQL, or even Zimbra, that has been refused by upstream? The number seems very small.

How open is Android?

[Qwavel]

One important aspect of being 'open' is whether you favor your customers or the carriers.

I see evidence of this distinction in support for bluetooth API's: the stronger and more customer oriented phone manufacturers support bluetooth API's (which makes many interesting applications possible). On the other hand, when carriers have a stronger role in designing a phone - this comes up particularly for CDMA phones - then the bluetooth API's are dropped or postponed.

So I was quite shocked to see that Android v1.0 does not support bluetooth API's!

I know that Google has claimed that they didn't have time to get the bluetooth API's into v1.0, but that is just the sort of thing that companies will tell us when they change plans due to carrier pressure. The BREW environment (for CDMA phones) has been playing this game for years: continually telling developers that bluetooth support was just around the corner.

I sure hope that Google doesn't play the same game with us. I really want this to be an open and powerful platform.

Re:How open is Android?

[Qwavel]

I should add...

Just because Google adds support for bluetooth API's to Android won't prevent manufacturers from removing that support, but then we can blame the manufacturer/carrier.

Re:How open is Android?

[Wrath0fb0b]

On the other hand, when carriers have a stronger role in designing a phone - this comes up particularly for CDMA phones - then the bluetooth API's are dropped or postponed.

My HTC PPC6800 (Titan, Mogul) was designed for Sprint and VZ (CDMA/EVDO) and it has a perfectly functional BT implementation. External applications (e.g. pdanet) can even provide bluetooth services (DUN).

Re:How open is Android?

[mc900ftjesus]

They've done such a great job keeping out custom Windows Mobile ROMs, how could they fail at securing an open source OS? /sarcasm

Re:How open is Android?

[mc900ftjesus]

I believe they're referring to the Verizon monster. That big, ugly, overpriced, phone-locking craphole.

Re:How open is Android?

[Anonymous Coward]

it has a perfectly functional BT implementation

If you're honestly saying that you think the Windows Mobile bluetooth stack is "perfectly functional", then I can only presume you've never used a good implementation. Windows Mobile's stack is slow, crash-prone, and has lots of interoperability problems with non-Windows-based devices.

I got my G1 yesterday

[cl0s]

Got my G1 yesterday. What I've played with so far is pretty nice, the camera is very light sensitive though, so far the only complain I have.

You can install apps from the market, internet or memory card, and the possibilities are endless just with the original OS. Can't wait for some hacked versions of Android so I can really have some fun though.

Re:I got my G1 yesterday

[mspohr]

Isn't it a good thing for your camera to be 'very light sensitive'?

Re:I got my G1 yesterday

[cl0s]

correction: "so far the only complain I have" -> "the only complaint I have" (I was excited :)

Isn't it a good thing for your camera to be 'very light sensitive'?

What I mean is the light has to be perfect in the room, or nearly perfect sunlight to get a decent picture. Same goes for scanning bar codes, God forbid some of your shadow is in the way. When the light is right though the picture is very crisp.

2.1 GB??

[jonnythan]

I'm no developer.

Can someone explain why the source code for a mobile phone's OS would be 2.1 GB?

Re:2.1 GB??

[Anonymous Coward]

Because of 'Hype' :)

Re:2.1 GB??

[NoTheory]

This isn't just the OS. This is the OS and the SDK. The tools are the major component of the download. There's a whole android emulator included. :P The OS itself is a couple hundred megs of linux.

Re:2.1 GB??

[morgan_greywolf]

It's actually not all that unusual for the source code for an OS (or any project, for that matter) to be much, much larger than the resulting installable code.

Take a look, for example, at the Linux source. The kernel source is like -- what? -- 300MB?

The resultant compiled and compressed kernel on a 32-bit system is like 1.7MB.

So the source is like 300X the size of the resultant kernel.

And that's just the kernel.

Re:2.1 GB??

[Anonymous Coward]

It's extremely well documented:

/*

ADD FUNCTION
Created by KSP on the morning of the sixth day of the eleventh month of the year one thousand nine hunderd and ninety eight (Gregorian calendar)

*/

/*

This function takes 2 integers, by value, and adds them up, returning the result as one number!

*/

int add(int a, int b) {
/*Here we start our function*/
/*The line below will be executed when this function is called*/
/*Declare a temporary variable to store the result*/

      int c;
/*Initialize it with the value zero (0)*/

      c = 0;
/*Doublecheck that c is really zero*/

      if (c == 0) {
/*All good so far... */
/*Let's add them up! */
//c = b + a;
/*20080109 - JDS: above line commented out. The calling function CLEARLY wanted to sum up a plus b. NOT the other way around... I'm surrounded by aholes! Sheesh!*/

            c = a + b;

      } else {
/*DANGER! HERE BE DRAGONS!*/
/*For some reason our temporary variable lost its initial value. Oh my Lord! We need some error handling here. Perhaps we could raise an error, telling whoever called this function that something went berserk. Or maybe we can silently just return zero. I like that! This will certainly be better for the other programmer, after all, he won't have to deal with error catching, etc... Let's make life easier for everybody!!! Actually, I like the number 3 better. Ever since I was a kid, it's been my lucky number. I'll return that! I'm so good, I'm BATMAN!.*/

            c = 3;

      }
/*Here's where we return the final value...*/

      return c;

}

Re:2.1 GB??

[morgan_greywolf]

Okay, okay. I decided that perhaps I was being a tad-bit disingenuous and was feeling guilty so -- to be fair, you have to count the kernel and all the modules. 1.7 MB for the compressed kernel and about 100 MB for the all the modules, uncompressed (compressed would be ~45-50MB)

Still, the source is much larger than the resulting executables ... so my point stands :)

Re:2.1 GB??

[Anonymous Coward]

Probably at least partially due to the use of git for version control. A tarball of the Linux kernel is about 30mb and compiles to about 2mb or so of code. A git checkout of Linux is about 1GB.

Re:2.1 GB??

[Anonymous Coward]

Arrrggg why be you pirating code? Arrrrg

Re:2.1 GB??

[Anonymous Coward]

Admit that you just had to make sure that function compiled before you posted it!

Re:2.1 GB??

[dreamchaser]

It is Open Source, you Insensitive Clod of an AC. Arrrg.

Re:2.1 GB??

[Anonymous Coward]

/*DANGER! HERE BE DRAGONS!*/

Tasslefat Coderfoot?

Is that you?

Re:2.1 GB??

[Ed Avis]

The tragic thing is that this function doesn't even do what it says. If a and b are large enough, it won't return a + b, nor even give an error, but instead return some wrapped-around crazy value, which is almost never what you want.

Re:2.1 GB??

[centuren]

      } /*Here's where we return the final value...*/

      if(c != 0) {
          return c;
      } else {
          return 0;
      }

}

Fixed that last part. The sad thing is I've encountered this return logic in the workplace.

Re:2.1 GB??

[Anonymous Coward]

You forgot

/* End of function.. Is i over already? :( */

Eh, big deal

[192939495969798999]

Been to a P2P site or a 7-11 in Hong Kong recently? The source code for everything is 'open'...

Re:Eh, big deal

[Anonymous Coward]

Been to a P2P site or a 7-11 in Hong Kong recently? The source code for everything is 'open'...

i have no clue what that even means..

Re:Eh, big deal

[larry bagina]

A Hong Kong 7-11 is like a bath house in 1970s San Francisco. Lots of bareback sex, every hole open and willing. And FREE amyl nitrate poppers.

Eclipse has succeeded, so will Android

[postmortem]

just look at what Eclipse today is: a standard IDE for most development languages. Everybody uses it. It helps corporations; it helps workers find jobs.

And now all the support turns to you know what

[Anonymous Coward]

And now all the support turns to you know what

Linux vs Ubuntu

[buchner.johannes]

To build the Android source under Linux, you will need Ubuntu.

wtf? How do I emerge that?

Re:Linux vs Ubuntu

[John Hasler]

It isn't true. I'm sure it will build fine under Debian.

Re:Linux vs Ubuntu

[kylegordon]

wtf? How do I emerge that?

Slowly...

Re:Linux vs Ubuntu

[mibus]

To build the Android source under Linux, you will need Ubuntu.

wtf? How do I emerge that?

It's like emerging Debian, but with a custom overlay...

Doesn't mean much...

[magamiako1]

For the end users around here, this doesn't mean much for you.

This does not mean that you'll be able to run whatever version of Android you want on your phone. I would imagine there's very likely situations with code signing involved that ensures that if you're using XYZ's phone, that you'll only be allowed to run the XYZ versions of Android.

This open sourcing does not mean that you simply get to buy an Android phone and then download a version that you want and run that. Not only due to "artificial" reasons such as code signing, but due to hardware features (or lackthereof).

All this really means is that the companies get to have someone else do heavy legwork for them. Beyond that, it means more familiarity with the Android platform which means there's potentially more market for the platform on the bottom line.

More developers means more applications, more applications means more market for Android. Google and the phone carriers are happy. As an end user, you still get a locked down piece of junk--but hey, at least you'll have 50 variants of a card game to buy instead of 40.

That's what hackers are for...

[PRMan]

I'd be surprised if some of the code-signing stuff wasn't gone soon.

Re:That's what hackers are for...

[Anonymous Coward]

Okay, sure. The hackers can do the same thing they're doing on the iphone and the other phone platforms. But that doesn't mean it's difficult.

And that doesn't mean it changes anything from the current situation. (My post is trying to tell people this point)

And with regards to the code signing and running non-carrier approved android distributions, you won't see it disappear on carriers. This is part of their market. This is how they differentiate themselves.

Re:That's what hackers are for...

[magamiako1]

err not going to be difficult*

My apologies.

Yay Google!

[NSParadox]

It's so ironic that the same day Google releases one of the largest and most impactful open source projects, Microsoft declares the day "Global Anti-Piracy Day". Horray for Google -- thanks for making our cell phones more powerful at as low a cost to the user as possible. Now if only there were more free and open carriers around....

Re:Yay Google!

[Anonymous Coward]

impactful

...sob...

OH SNAP

[mrsteveman1]

"To build the Android files in a Mac OS environment, you need an Intel/x86 machine. The Android build system and tools do not support the obsolete PowerPC architecture."

quite the burn there

Re:OH SNAP

[Anonymous Coward]

Same for the iPhone SDK... why is it a burn? PPC is antiquated at this point.

Re:OH SNAP

[FrozenFOXX]

Agreed. Guess I'll just pack my 360 up and put it away...

Re:OH SNAP

[Constantine XVI]

And PS3, and Wii...

Re:OH SNAP

[MobileTatsu-NJG]

Agreed. Guess I'll just pack my 360 up and put it away...

uh.. Yeah, because dual-booting your 360 with OSX must have been a real pain up to this point, mmm?

Re:OH SNAP

[Anonymous Coward]

It was a joke about not supporting, "the obsolete PowerPC architecture." Try reading the context of the joke next time.

Re:OH SNAP

[MobileTatsu-NJG]

Try making your joke funny next time. Ignorance alone is not comedy.

I need more features

[damn_registrars]

Come on, I don't think this phone does enough yet. If they can't make a phone that can run SETI@Home while I play Duke Nukem Forever, then I'm not interested!

And there's no word on its ability to make my dinner, either. What good is a cell phone if it can't deep fry?

Re:I need more features

[Nahor]

What good is a cell phone if it can't deep fry?

This is not a software problem, they are just not using the correct battery.

Re:I need more features

[damn_registrars]

This is not a software problem, they are just not using the correct battery.

I wonder if that would explain my A/C and four-wheel-drive problems as well.

Re:I need more features

[77Punker]

I bet it'll fry just fine, it just lacks the ability to drop itself into the oil.

Not sure you are right there

[CdBee]

Google announced quite clearly before the launch that due to coding deadlines the phone would be issued with a limited Bluetooth stack and full features would be added later, and user developers were welcome to make their own solutions in the meantime...

No

[wurp]

Google realizes that carriers want strict control over their devices.

No, carriers want strict control over *your* and *my* devices. You know, the ones we either paid up front for, or the ones we paid out subsidized by our contract.

This bothers me quite a bit.

Re:No

[not already in use]

No, carriers want strict control over *your* and *my* devices.

Well, in particular, the devices you buy through them. Which, as you mentioned, are typically subsidized through contract. Of course, there is absolutely nothing stopping you from purchasing an unlocked phone from a third party and paying them for service only. It is a conscious (albeit ignorant and uninformed in the sense that many people see this as a requirement) decision to purchase the hardware from the carrier.

Re:No

[wurp]

Well, my phone is a Neo1973. I hate contracts, too, so I'm on AT&T GoPhone.

I do think it's silly of us to let carriers dictate what happens with the phone we buy from them, though.

Re:2.1 GB?? - think platform dependencies

[CdBee]

also the SDK and source probably includes lots of files which are specific to one particular hardware/CPU platform. Android probably runs on ARM, SH, MIPS, x86, etc and needs different bits of specific code on each

Re:2.1 GB?? - think platform dependencies

[morgan_greywolf]

The different bits of specific code are just like the Linux kernel, upon which Android is at least partially based, which is why I used it as an example. And yeah, the SDK is pretty big, and it's Java, and there are probably lots of examples included, and the a few base apps that come with the OS, etc.

Any way you look at it, it's not unusual for the source to be bigger. Look at the source for OpenOffice.org -- hundreds of megs, the resultant application is like, 20-30 MB, tops.

I have a ton of examples.

Buy an Openmoko Freerunner

[nikolajsheller]

Open hardware is available out there.
I recently bought one, and so far I find the hardware quire acceptable.

Re:Buy an Openmoko Freerunner

[cl0s]

I really wanted one for the longest but the software is not nearly complete. I mean Android is barely complete as far as apps go and OpenMoko is even farther behind on that.

You should be able to port Android onto your OpenMoko though, I'm sure that will be one of the first non-G1's to have it.

Android though I would say is open enough for me, the HTC hardware is closed and all but I've been able to download separate apps right from the browser and install them on my G1, without even touching T-Mobiles Android Market.

I want a computer

[kwerle]

I want my General Purpose computer to be able to fit in my pocket, run whatever programs I want, and be able to make phone calls. Why is that hard or unreasonable?

Re:I want a computer

[wurp]

So why haven't you bought an Openmoko Freerunner? I have debian in my pocket right now.

Re:I want a computer

[kwerle]

As the hacker's dream toy: it is fully functional. As a GSM phone: some people have been using it to receive and place phone calls and SMS for months, but with currently shipping software the battery life is only one day. As a GPS device: critical bugs have been ironed out and there is nice software to know where you are using OpenStreetMap. As an alarm clock, media player, internet browser, game console, email reader and contacts manager: software is not stable yet.

Run, not develop.

Re:I want a computer

[wurp]

I'm running Debian, and all the programs built for any normal debian release are there.

No windows instructions

[Anonymous Coward]

BWAHAHAHHAHAHAHAHAHAHAHHAHAHAHAHAHAH!!!!111oneoneone!!1one

The instructions on getting the source don't include how to do it under windows.

Re:No windows instructions

[brezel]

and that is so funny because?

Re:No windows instructions

[Anonymous Coward]

Because we all run SETI@Home while playing Duke Nukem Forever. C'mon dude, get with the times.

Piracy is good

[BountyX]

See cracking down on piracy has already propelled open source. It was early this morning when microsoft announced anti piracy day. Now, all of a sudden, adroid is open source. HAHA! What's next were all going to switch to linux today? If only we didn't switch sooner, then we could truly savor the moment.

Re:Source code not really accessible

[wgibson]

1) Who the heck uses Git? I know a lot of important companies do, but most people do not.

Quite a lot of people have actually read the manuals of git, and are using it in all manner of projects.

2) Who the heck is going to download 2.1GB just to look at 1-2 files in the source-code? That's just insane.

So don't!

They should make the source browseable directly off their website to spare us all this headache.

Ehm. This thing about documentation. Oh, and the acronym RTFA... At least I did not, and I hope that few others do, have any difficulty locating the gitweb repository at http://android.kernel.org/

Re:Source code not really accessible

[ciroknight]

1) Who the heck uses Git? I know a lot of important companies do, but most people do not.

Yeah, but all of the important infrastructural pieces on Linux are moving to Git, including Linux itself, Xorg and the surrounding lowlevel daemons (bluez, etc). If you're going to be pulling from a dozen git servers to build your stack, it's often easier just to manage your stack using git anyways.

2) Who the heck is going to download 2.1GB just to look at 1-2 files in the source-code? That's just insane.

Then you're clearly not the kind of person Google wants looking at the code anyways. Anybody who's really interested has no problem with downloading all of it, because they will eventually want all of it anyways, so they can build the environment and work on it.

Re:Source code not really accessible

[cowwoc2001]

Quite a lot of people have actually read the manuals of git, and are using it in all manner of projects.

As I was hinting at with my first post, there is a world of difference between "a lot of people" and "the majority of people". I'm sure a lot of people use git, but far *more* people use some other repository such as CVS or SVN. Making the code available *exclusively* over Git is annoying. They should at least have provided a zip download or something.

They should make the source browseable directly off their website to spare us all this headache.

At least I did not, and I hope that few others do, have any difficulty locating the gitweb repository at http://android.kernel.org/

That's a step in the right direction but not 100% there either. I just spent the last 10 minutes trying to find the speech-recognition related code and found nothing. The developer API seems to be buried below tons of stuff.

Linux is obsolete (Andrew Tanenbaum)

[cmd]

Irony: Seeing the quote "Linux is obsolete (Andrew Tanenbaum)" in the footer of the Slashdot article discussing Google's open source release of a new mobile phone platform based on Linux, assuring that Linux will eventually be running on more processors than any other OS created and be around for a very long time.

The interesting bits are in the details.

Open Source Problem

[supernova_hq]

As much as I LOVE open source and the idea of an open source operating system for phones, I fear that phone companies are going to take advantage of this. It won't take much for them to take a beautiful open source, extensible, customizable operating system and ship their phones with a custom locked down, provider locked, limited use piece of crap.

As much as I hate restrictive license agreements, there should be a clause in their license stating that no one can install (for resale) a version of this os with restrictions added. This clause may exist (I haven't checked), but it would be very nice if it did.

Disclaimer: I am pro open source all the way, I do not believe for a second that a OS of all things should be closed, I simply worry about how the phone companies (service, not hardware) will abuse this "open" system and close not the source, but the permissions given to the users.

Re:Open Source Problem

[fuzzyfuzzyfungus]

GPL3 does something close to what you want. It imposes no restrictions on what you do with GPL3 code; but it requires that, if you ship a device with binaries built from such code, you make the code and whatever is necessary to replace the binary with a modified version based on the code available to the purchaser of the device.

That is arguably somewhat better than your proposal, since it dodges all the hairy questions about what a "restriction" is("You removed proxy support!" "No, we simplified the UI to suit our novice users." "You removed Foo and Bar." "Device XYZ is resource limited, Foo and Bar didn't fit", etc, etc.) but ensures that anybody who builds a system with gross restrictions cannot stop people from replacing it with an unrestricted setup.

Google had the option of using such a licence; but they deliberately chose not to because they actually wanted carriers to use it. The carriers need to be made to submit to the role of dumb pipes, anything else is just a bandaid on a sucking chest wound.

Re:Open Source Problem

[Microlith]

It won't take much for them to take a beautiful open source, extensible, customizable operating system and ship their phones with a custom locked down, provider locked, limited use piece of crap.

They already do this.

There's currently an effort to see what progress can be made with the Motorola A1600/A1800 MING 2s, but as they're finding the CPU:

- CRCs the bootloader which
- CRCs the kernel / checks the kernel signature which
- Uses SELinux to confirm the security of the read-only filesystems.

Sure they can boot a kernel after transferring it via USB, but there's no way they're going to be writing a custom kernel or filesystem to the flash and getting it to boot without convincing Motorola to sell versions of the phone with no bootloader CRC check.

there should be a clause in their license stating that no one can install (for resale) a version of this os with restrictions added.

It's called an anti-Tivoization clause and was added to the GPLv3, which incidentally does not apply to the Linux kernel. Efforts like the LiMo foundation are focused on implementing a user-space that is completely non-GPL to avoid the issue. Getting that source code requires you be a member of the foundation, which is $10k anuually for vendors and $100k annually for handset manufacturers.

Yes they want to take advantage of your hard work. No they don't want to give back to you. They do the bare minimum that they can to stay legal and will return to the community a kernel that boots, but does not fully support the hardware it drives (go go closed source kernel modules.)

translate.google.com?

[Anonymous Coward]

Can someone translate this to english, please...? Does this mean we can really build an image and install it to a off-the-shelv-g1, or are there signatures etc that prevent this...?

(Chapta: aprooval, how fitting...)

WRONG. Completely wrong.

[CdBee]

the iPod Touch 2nd generation has a Bluetooth controller chip onboard. Any of the product disassembly sites will tell you that. Its disabled in software

Re:WRONG. Completely wrong.

[dfn_deux]

AFAIK this was debunked almost immediately after being claimed. The only low power radio chips in the touch are there to support wifi in the 1/2 gen and the nike+ chip in the 2nd gen.

OpenMoko plus Android = kickass

[fatalGlory]

As best I can tell, Android seems to be further along than OpenMoko's open software platform. If I were not a student and had the $400 to shell out for a FreeRunner, I'd totally run Android on that bad boy and be developing an MMO for it later today ;)

Given the existence of open phone hardware and now multiple open phone software platforms, who cares about phone vendor lock-down?

What?

[ShieldW0lf]

One of the benefits of this arrangement is securing the existence of the project by involving commercial interests and their money in the process ... this is also one of the downsides; having commercial entities charter and lead features of a platform that their own commercial offerings provide 'enhanced' versions of, sometimes leaving the free offering always lacking in one obvious way or another.

What?

init to 0

[Zoxed]

> int c;
> /*Initialize it with the value zero (0)*/

This comment is very likely to be incorrect: at least is is for SPARC/Solaris. I have traced a few bugs down to the assumption that C initializes memory to 0: in practice it *usually* is 0, but *sometimes* it is not :-(

Re:init to 0

[Anonymous Coward]

Actually, that comment was for the next line:

c=0;

Never assume that

int c;

will initialize to 0, there's no reason why it should.

int c=0;

on the other hand should be safe (I'd be really surprised if it wasn't).

Re:init to 0

[Zoxed]

> Actually, that comment was for the next line:
> c=0;

Sorry: I looked at it again and you are right (serves me right for posting quickly when I c/should be, errr, doing something else !!).

Re:init to 0

[Anonymous Coward]

Such is life, mate! No need to apologize, we all have these WTF moments ;-)

Cheers!

Android

[Anonymous Coward]

I just recently learned programming in android, and posted some of the things I just learned in a blog, Android Tutorial, I think google should be more concerned with having a decent handset to play around than with the license.

I'm now trying to learn the Google Map features and the GPS locator, but I'm not actually sure if this would work on a real handset. I'm still waiting to get an android phone in my country.

Re: RTFM

[Anonymous Coward]

emerge ubuntu

There, fixed it for you..

This news surprised me

[Cunk]

Because I thought Android was already open source. Wasn't that the whole point from when it was first announced? What was all the hoopla back then?