LXer: Google previews slick, tablet-oriented Android 3.0
Syndicated Linux NewsThis forum is for the discussion of Syndicated Linux News stories.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
LXer: Google previews slick, tablet-oriented Android 3.0
Published at LXer:
Google released a video overview of Android 3.0 ("Honeycomb"), confirming that it is designed for tablets while hinting at exclusivity for tablets. Honeycomb enhancements include a revamped, "virtual and holographic user interface," improved multitasking, drag and drop widgets, video chat with Google Talk, Google eBooks integration, and tablet-oriented overhauls for the browser, Gmail, and YouTube.
So now the argument about Android on PCs being hard to get accustomed to has been proven untrue. Hopefully there will be a 'honeycomb-x86' git branch soon
I doubt it, x86 chips are simply too power hungry for the kinds of devices Honeycomb (and Android in general) is aimed at. Until Intel comes up with an x86 compatible chip that can compete with ARM chips for power stinginess, there is simply no point in moving Android to x86.
I'm not saying that Honeycomb should be *exclusively* x86, I'm saying that given its form factor it might also be suited to netbooks and other devices, not just tablets, and so Google just might have an *option* for it to run on *both* x86 and ARM processors, just like Chrome OS (seeing as though Honeycomb has a similar form factor).
Sigh. I didn't say anything about running exclusively on x86 and didn't accuse you of doing so either. Please work on your reading comprehension.
My comment was based on the fact that Android is aimed at low-power devices with touchscreens, and currently x86-compatible chips don't power those sorts of things. And I just don't see any demand for putting Android on a netbook given that they are more like traditional computers than they are either phones or tablets. I guess I just see the market for Android on non-ARM stuff as being too small to be worth the hassle of porting and maintaining. Google will get a lot more bang for their buck by focusing their development on ARM powered devices. Now if Intel or AMD actually launch an x86 compatible chipset that can compete with ARM on power consumption, that may change, but currently I just don't see the need for a port.
How many netbooks have a touchscreen? Android with a mouse just seems odd, not to mention that you cant do multi-touch. Maybe I'm the weird one, but from my perspective substituting Android for Slackware on my netbook would be a huge step backwards. To be really functional, Android devices really need to be connected to a network, and with my netbook I can be either offline or online withe very little change in functionality.
Besides, look at it from Google's point of view. What additional revenue would they get from porting Android to x86? My guess is probably not much since all of Google's offerings already run on x86 devices and they generally have pretty good access to their customers. Now tablets and phones on the other hand didn't have a Google-friendly OS prior to Android, so there was a ton of additional advertising dollars by creating and deploying Android on ARM devices. It lets them go directly to their "customers" instead of letting Apple or Microsoft or BlackBerry be the intermediary. Being cut off was a real risk on phones and tablets since their development model seems to be falling into a "walled garden" approach where the OS manufacturer controls what you can, and cannot, do. Having to bow before Redmond or Cupertino would have been a real threat to Google's advertising revenue, hence spending the money to develop and support Android lets them avoid that. That sort of scenario simply doesn't exist in the x86 world.
How many netbooks have a touchscreen? Android with a mouse just seems odd, not to mention that you cant do multi-touch. Maybe I'm the weird one, but from my perspective substituting Android for Slackware on my netbook would be a huge step backwards. To be really functional, Android devices really need to be connected to a network, and with my netbook I can be either offline or online withe very little change in functionality.
Besides, look at it from Google's point of view. What additional revenue would they get from porting Android to x86? My guess is probably not much since all of Google's offerings already run on x86 devices and they generally have pretty good access to their customers. Now tablets and phones on the other hand didn't have a Google-friendly OS prior to Android, so there was a ton of additional advertising dollars by creating and deploying Android on ARM devices. It lets them go directly to their "customers" instead of letting Apple or Microsoft or BlackBerry be the intermediary. Being cut off was a real risk on phones and tablets since their development model seems to be falling into a "walled garden" approach where the OS manufacturer controls what you can, and cannot, do. Having to bow before Redmond or Cupertino would have been a real threat to Google's advertising revenue, hence spending the money to develop and support Android lets them avoid that. That sort of scenario simply doesn't exist in the x86 world.
Well, many netbooks nowadays *do* have multitouch trackpads, which do many of the things multitouch screens do, just not built into the screen.
Not having used Android I can't speak for it much, but I honestly don't see the point in running what I take it is essentially a mobile-targeted OS on a non-mobile (or semi-mobile) computing platform (e.g. a desktop or conventional laptop). That to me would be the only real reason for officially porting Android to x86 (I've heard that netbooks are slowly transitioning more towards using ARM-based chips..? ). Could be wrong, though... *shrugs*
Well, if this article is right Android 3.0 will have a windowed, conventional desktop much like that of KDE (plasma-netbook). That means that it will be easier to use (and not as HUGE) on larger devices like netbooks and standard desktops/laptops.
And wasn't Google saying when Chromium OS was first released that there would be a "marriage" of Chrome OS and Android eventually? In my opinion this is it.
Last edited by Kenny_Strawn; 01-09-2011 at 04:08 PM.
And wasn't Google saying when Chromium OS was first released that there would be a "marriage" of Chrome OS and Android eventually? In my opinion this is it.
I was assuming that was Google-speak for "We're gonna ditch Chrome OS as soon as nobody is looking". Really, there isn't anything in Chrome OS that Android could use, and a normal OS is better on laptops/netbooks/desktops than Chrome OS is.
I would think that Google would come up with an Android 3.0 version of the Chrome browser that has all the features the main Chrome browser has (including tabbed browsing, pinned tabs, and bookmark-style "apps") in place of its traditional browser. That way you have an OS that runs both Android and Chrome OS apps.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.