
Android 4.0 Released for x86 - wslh
http://www.osnews.com/story/25383/Android_4_0_Released_for_x86
======
te_chris
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)

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

~~~
nupark2
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.

~~~
bryanlarsen
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.

~~~
nupark2
An existing console maker.

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

~~~
dtwwtd
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.

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

~~~
NSMeta
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...](https://groups.google.com/forum/#!msg/android-x86/JxSLaEDgYBA/7iAdUzZ-
xFcJ)

~~~
gerggerg
Awesome thanks!

------
ars
Direct link:
[http://groups.google.com/group/android-x86/browse_thread/thr...](http://groups.google.com/group/android-x86/browse_thread/thread/27148b6840e06010/57c47e36531d20ee?#57c47e36531d20ee)

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

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

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

~~~
bryanlarsen
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.

~~~
nextparadigms
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.

~~~
bryanlarsen
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...](http://www.anandtech.com/show/4788/intels-medfield-
gingerbread-smartphone-reference-platform)

~~~
nextparadigms
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?

~~~
bryanlarsen
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.

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

~~~
TobbenTM
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.

------
nextparadigms
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.

~~~
fpgeek
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).

~~~
mbell
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.

~~~
fpgeek
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.

~~~
mbell
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).

