Android 4.0 Released for x86 | Hacker News Reader

Android 4.0 Released for x86

osnews.com

63 pointswslh38 comments

Could this enable more powerful, android based games consoles? I'm just imagining a console based on an i5 and one of today's epic NVIDIA/AMD chips, with dev's already able to develop using the SDK/NDK, could be pretty amazing. (Web developer, not hardware or GFX guy here :D)

It could, if someone were willing to build it.

The harder part would be getting developers on board to write games that actually take advantage of it. Most current Android games are heavily tied to touchscreen input, and thus wouldn't map well to the traditional console experience. On the plus side, developers who have already sunk costs into developing Android paths for their rendering engines would at least get a lot of code reuse out of that.

FWIW, Android on x86 isn't wholly new even in the retail device space, the current Google TV devices like Sony's $200 Bluray player with Google TV, their full TV device and the Logitech Revue are all sporting Atom chips (so... less powerful than an i5 but still x86) and other than the Logitech Revue these devices are all up to Honeycomb now.

Google TV 2.0 on those Sony devices is actually quite nice and will likely get even better with ICS+. I hope they stick with it and get past all the bad press that came out of 1.0 and Logitech's vocally negative experiences with it.

If I was building a new console I think I'd just use straight Linux; what value does Android bring?

An application sandboxing/deployment/sales system, coupled with high-level application/platform APIs that are considerably more coherent than the gnome/kde/whole-universe-of-libraries C mess.

A console maker is going to bring their own deployment/sales system, and they're going to choose a single library stack. So no advantages there.

An existing console maker.

On the other hand, look at the Kindle Fire, and the rest of the Android ecosystem.

I'd just like to point out that Amazon didn't use the Android Market for the Fire but used their own ecosystem (whether you want to argue that they built the Amazon app store for the purpose of putting it on their own devices is another story). So they didn't actually use the existing Android sales/distribution ecosystem.

I don't understand why amazon didn't offer HDMI connection on the fire(and a separately sold cradle). They could have sold more units, have more prime users and get some control on the TV and the gaming market.

But the purpose of the Kindle Fire is to be part of the Amazon ecosystem.

That's what I was thinking too when I asked the question. With all the commodity hardware - controllers etc - around these days surely someone with motivation could build a ps3 equivalent around android, x86 and AMD/NVIDIA chips. Build their own app store etc for their games (or not, they would just kill any phone :P).

It's a really exciting and intriguing concept to me - disrupting console gaming.

I'd rather they stick with high-end ARM chips for that, so they ensure cross compatibility between Android devices. Like a game on a Tegra 3 "console" should work on a Tegra 3 tablet, too, and vice-versa.

I don't want an Nvidia 580 GTX Android game, that would have no hope of working on Tegra 3 on the tablet. High-end ARM graphics look good enough for most people now. I also think it's a better strategy for Android to "flood" the console market with cheap $100-$150 ARM consoles, than $500 Intel/Nvidia ones. People would still prefer PS3/Xbox 360 over that.

The link states "Several things don't work as of yet." Anyone know what those might be?

What work:

* Wifi

* Multitouch

* OpenGL ES Hardware acceleration for AMD Radeon chipset

What NOT work (yet):

* Sound

* Camera

* Ethernet

* Hardware acceleration for Intel platform

[-] https://groups.google.com/forum/#!msg/android-x86/JxSLaEDgYB...

Awesome thanks!

Direct link: http://groups.google.com/group/android-x86/browse_thread/thr...

I don't know if this is a relevant question, but does it come with CIQ?

Of course not. This is a build of Android based on the Free Software release, not something some evil corporation wants to sell you.

I was kinda hoping we would leave x86 behind, but whatever.

Why? It's a heck of a lot more fun doing ARM assembler than x86, but the only assembly work being done these days is a few hundred lines in the bootloader to setup the PLLs and get the C environment going. Decoding the instructions is such a tiny part of today's almost billion-transistor chips that the oddities of an instruction set really doesn't matter. AMD64 gives a good register file and fixes the problems most people complain about with x86.

The biggest impact instruction choice makes these days is on memory efficiency, but both ARM & x86 are relatively memory efficient compared to the other common RISC architectures.

Sure ARM uses less power and x86 provides better performance, but that's no longer due to the instruction set, that's almost entirely due to optimization tradeoffs.

I'm willing to bet that it will be easier for the x86 makers to scale down power usage than it will be for the ARM guys to scale up performance.

I wouldn't bet on it. According to Anandtech Cortex A15 will be around Core 2 Duo level of performance, with more or less the same power consumption per chip as today's dual cores and quad cores (Tegra 3).

Dual core 2 Ghz Cortex A15 chips will appear first in Q2 2012 from Samsung (Exynos 5250). Is Brazos or Atom at the level of Core 2 Duo performance yet? Nope. And they still use more power than Cortex A15. In the mean time, ARM chips grow in performance faster than x86 low-end chips drop in power consumption every year.

By the time Atom or Brazos achieves the same power consumption, high-end ARM chips will have first gen i3 or even 2nd gen i3 performance (a couple of years). Atom won't even be fanless until the end of 2013.

I'll take that bet.

Brazos & Atom are still 45nm, and are a lot faster than 45nm ARM parts. They should be, they use a lot more power. Exynos 5250 is 32nm.

In Q2 2012 we will finally be able to compare apples to apples. Medfield vs A15. And we'll definitely see fanless CPUs from Intel next year. I don't think there's room for a fan in this: http://www.anandtech.com/show/4788/intels-medfield-gingerbre...

The node doesn't matter all that much. It gives a 30% boost or so. That doesn't change the fact that ARM has been improving in performance about 2x-2.5x every 12 months. Have you seen Atom improve that fast in either performance or energy consumption lately?

The node by itself gives a 30% boost. It also enables a dramatic increase in the number of transistors, which can be leveraged to also provide a dramatic increase in performance, if there are known gains to be made.

It's far easier to be the second or third company doing something than to be the first. A large part of the increase in performance that ARM enjoyed was obtained by learning from the successes and failures of Intel & POWER & Alpha and all other performance trailblazers.

Now that ARM is getting closer to mainstream performance, that kind of momentum is going to be much harder to maintain.

But mostly I've learned to never bet against Intel. Many have done so, and the landscape is strewn with their failures over the last 30 years. Certainly NVidia & Samsung et al have some very impressive engineers that might be capable of beating them. Eventually Intel will stumble, and it might be this time. But I'm much more willing to bet on Intel than against them.

You can purchase fanless Atom and Brazos boards now. They just have huge heatsinks.

I reckon there might be more NEON that bootloader assembly out there in the ARM world.

Going to install this on an eeepc now, will post results.

Currently running it on an Acer W500 tablet, looking good except for a few graphical glitches. Stock launcher is laggy though, runs better with AWD Launcher.

how did it go? does touchpad/mouse input work?

Brazos still sips significantly more power than the best high-end ARM chip right now. I also think it's a mistake for Google to focus on the x86 platform. If they do it, and they are successful with this, they will be opening the door for Microsoft to come right in and take it all away from them with Windows 8.

Windows 8 will be weak on ARM and strong on x86 as a platform, which is why Google should support ARM over x86 for as long as possible. They are once again repeating the mistake with Flash - supporting a technology just to spite Apple, even though it's not in their best long term interest either.

Right now, in the tablet market, Apple is not their #1 enemy. Microsoft is. They need to focus on (forever) winning the #2 position after Apple in tablets. After Windows 8 fails to become #2 in tablets, they can then go back to winning the #1 position from Apple. But if they don't focus on getting a strong #2 position right now, and make it impossible for Microsoft to ever get it again (just like they did in smartphones) they risk losing both top 2 positions in tablets, and maybe even more.

Also, I really wish they were more pro-active in getting more (a LOT more) developers to make Android tablet apps. Why are they so slow on this? How can Microsoft push for 40,000 apps in one year on a 1% market share platform, and they can't do the same with Android for tablets? Google really needs to get this priority straight because it's vital for the continuing success of Android.

This is not the time to be laid-back about this. They need a very strong showing on tablets by the time Windows 8 appears on them. I still think it's too late for Windows 8 for tablets, but the more laid-back they are about it, the higher the risk is. They need to minimize Microsoft's opportunity as much as possible. This is Google's (and Apple's) chance to stop Windows from dominating the market for another decade.

With the exception of Google TV (which is Honeycomb/x86 at the moment), I don't think Google is focusing on the x86 platform for Android themselves. I think they're just happily accepting AMD's and Intel's contributions for a few reasons:

1. A good Android/x86 port will give them the option of offering an Android simulator (like Apple's iOS simulator) to developers as an alternative to the much-maligned emulator.

2. If Intel or AMD gets anywhere with x86 smartphones and/or tablets, it is better for Android if it is involved (or at least prepared).

3. They'd rather have the android/x86 work take place under the official umbrella, rather than be an external fork (especially if the existing external fork(s) would otherwise get high-profile sponsors like Intel and AMD).

Its worth noting that the only reason I know of that Google TV and some other early gen "media box" type devices ended up on x86 was the lack of an ARM SoC that could handle 1080p MPEG-4 AVC/h.264 decoding on the higher codec profiles. Boxee for instance publicly stated this was the reason for canning their original design based on the Tegra 2 SoC. There are now ARM SoCs which can do this, NVIDIA's Tegra 3 and the new TI OMAP 4 line.

I wouldn't be surprised to see many such devices move back to the ARM SoC platforms in their next incarnations.

Hmmm... I didn't realize the availability of appropriate ARM SoCs was a factor. I'd presumed that having Intel as a co-developer on Google TV was why it launched on x86. However, I can see how the causality can go the other way (not having usable ARM SoCs meant picking Intel as a partner).

I wouldn't be surprised to see devices move back (to line up with the bulk of the Android ecosystem, for instance), but since battery life / power consumption isn't a big issue for TV peripherals, I could see things staying with x86 as well. We'll see.

Outside political influences I would see ARM SoCs as a much better fit in this space. While power consumption isn't an issue directly it is an issue indirectly in the form of heat and coincidentally cooling. A device without a fan is desirable from a noise perspective in a living-room, a cost stand point and a "sex appeal" standpoint (pretty case, tiny or no power brick, etc).

ARM systems can also be generally cheaper to implement as with many SoCs there is no "chip set" just the single SoC and a couple auxiliary parts. Few parts and fewer traces generally results in a cheaper product.

I would _think_ but certainly don't know that maintaining a single set of optimized drivers would also be a win. As many of the ARM SoCs share sub-components with the SoCs used already on android. Thus there is a cost win in being able to use existing drivers. On the other hand anyone that has used linux on Intel GMA video knows there are some "issues" with those devices and since android sits on linux, I would assume they had to do a bunch of custom work to get it working well (or maybe its just an X11 thing).

Also, Intel canceled their Atom CE line, so now there aren't any x86 chips that are optimized for STBs.

How does being available on x86 limit availability on ARM? Why should they artificially limit the usefulness of the OS?

A few months ago I put together a 23" android device: http://www.youtube.com/watch?v=O8lHdgHQmvc

Devices like that make much more sense on x86 than ARM.

Hey Marty, Some of us are waiting on the technical details you are gonna post. Awesome hack.

FWIW, I'd prefer Microsoft to dominate than Apple. Apple is far more controlling. As such, I prefer Google attacking Apple rather than MS. But I'm not sure that there is a distinction in the kinds of moves Google can make. It's all about marketshare: developers and users; and as such, it's more or less zero-sum. Yes, you can technically grow the market, but you can't grow marketshare without eating into the competitors' marketshare. And in the tablet space, Apple is the one with all the marketshare.

Android-x86 is not a Google product.

Reply on news.ycombinator.com