4 ms·

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 th

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.

martythemaniak 15y ago
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 http://www.youtube.com/watch?v=O8lHdgHQmvc Devices like that make much more sense on x86 than ARM.
- kumarm 15y ago
  Hey Marty, Some of us are waiting on the technical details you are gonna post. Awesome hack.
fpgeek 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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).
barrkel 15y ago
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.
bnr 15y ago
Android-x86 is not a Google product.

martythemaniak 15y ago

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 http://www.youtube.com/watch?v=O8lHdgHQmvc Devices like that make much more sense on x86 than ARM.

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

fpgeek 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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).

barrkel 15y ago

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.

bnr 15y ago

Android-x86 is not a Google product.