> Android is "a lot cheaper for HP to implement in a laptop; ChromeOS, in contrast, comes with more stringent system requirements that would cost HP a bit more."
It looks like sweet hardware. They may have good intentions re costs. But that's not how to define a product. The laptop form factor works against the touch interface by putting the screen just a little too far away. It also completely destroys the ability to hold a device like a sheaf of paper or clipboard.
The other side of the coin is that a browser-based UI is well-suited to using a pointing device instead of (or in addition to) touch.
Going from "open government" to "outsourcing" is a non sequitur meant to set up a straw man. It is outsourcing that results in private firms treating government data as proprietary, and it is this kind of outsourcing that open government initiatives seek to avoid.
It's a long piece. Tl;dr: Think tank wonk mistakes Tim O'Reilly for a technolibertarian and turgidly tilts at windmills of his own invention.
Android app compatibility is available for Linux in several forms: You can install an Android distro in a virtualization container, Canonical's "Ubuntu for Android," Open Mobile's ACL (disclosure, I used to be CTO there), and others.
My view of the best way to do this (and not surprising that this is how Open Mobile does it) is that Android can be integrated into "foreign" desktop environments as if it were a Java SE-like runtime environment.
As for how I would want to use Ubuntu on a tablet, I would put it on a powerful tablet such as those Windows 8 will be shipping on. Then I can have my Android development tools in a tablet form factor, and I can run an x86 Android build in a VM or QEMU for testing/debugging.
The right to a patent monopoly is not a fundamental human right.
The US Constitution is written with a specific sense regarding rights. It grants no rights because it takes the point of view that you have human rights, with, or without any government's say so. Instead, the Constitution grants powers to the government.
The right to a patent monopoly is not one of the rights the Constitution assumes you have. That's because, in the eyes of the authors of that document, it's not really a basic human right. Instead, the government is explicitly empowered to grant patent and copyright monopolies. And that power is conditional: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."
If it isn't functioning as intended, is it still legitimate?
We've put on Mars a large machine that blasts the landscape with a heat ray. A heat ray. And we have set the example that such a machine can be robotic, and impervious to microbes. That's sure to end well.
Is this some kind of weird expression of the New England work ethic? Make the driver work just as hard as ever, but should he ever falter, a superior system kicks in and saves his ass?
If I have a computer that can handle emergencies more reliably than I can, surely it can handle the mundane more reliably, too.
The trend in Android has been, up to now, in the right direction.
For example, the Android Open Source Project originally did not have a development platform build target or reference hardware. Now it does. That means you can take the entire Android Open Source Project and built it and run it, instead of having to "root" a commercial device and port Android to that device before you can start playing with Android on real hardware.
It is in Google's interest to make Android progressively easier to port because Google wants faster and more-consistent updates to Android across all the OEMs using Android. A vibrant and useful AOSP is important to that goal.
Moreover, when faced with a competitor using the Android Open Source Project to build a competing platform and support a competing ecosystem, Google did nothing to thwart AOSP, or to make it harder for Amazon to use AOSP.
Android is partly-open because Google uses a suite of applications and services that are not open source to create commercial Android products with the Google Logo, and OEMs and carriers add their own software to products. There may be room in the market for a more-open mobile OS that isn't tied to big e-commerce ecosystems. Tizen might be one such system, and Jolla might bring Meego back. If those systems prove to be more open, and under less pressure to provide exclusivity to their sponsors, they could turn out to provide truly open, hackable communications devices.
Open communications devices, with open hardware and software, are important because they would enable communications privacy, among other qualities.
The article mistake's Google's lack of direct revenue from Android with revenue of all the different products Google delivers over Android and other mobile OSs. The money-making parts of Google deliver apps to Android, iOS, and other mobile platforms, and make money from those apps.
Facebook has a greater challenge, and is off to a later start, but you have to ask if that's really a worry, compared with getting the mobile launch right. Facebook faces very little competition. Other than Google+, there are no social networks that have an in-house phone OS. The mobile Google+ app is among the least well-executed mobile apps among all of Google's products.
Amazon has shown it's possible to have a successful product entry with a mobile device, even with Android and iOS as competitors. Facebook has a large ecosystem, like Amazon. There is no reason to think Facebook's mobile market window is closing. On the other hand, if Facebook were to ship a "Kin"-like flop, that would set them back substantially.
If a Facebook mobile device is coming, Facebook has every incentive to wait until it is done right.
I am one of the people Steve Jobs said would continue to need a fully general-purpose computer, which he compared to people who need to drive a truck. I make software for a living, and Linux is a great platform for software development. The point Jobs was making is that it isn't appropriate to try to make personal computers as simple to use as mobile devices. And while ease of use has many virtues for both the mainstream consumer and the "truck driver," ultimately, the way products are designed will diverge.
Android is the consumer's Linux. Android took the step of discarding much of the Linux userland and starting afresh, with a software platform that is both powerful, and designed for finger-friendly mobile devices. That turned out to be a very successful approach. Trying to evolve a desktop OS to do what Android and iOS do is very difficult, and there are no successful examples. Microsoft has repeatedly tried to make Windows work on tablets, and failed repeatedly. It's an open question if Windows 8, even though it contains a finger-friendly UI system, can straddle the two worlds without creating situations where the user is dumped into finger-hostile territory at inopportune times.
While making desktop Linux more user-friendly remains a worthy goal, it may turn out that Windows 8 is a cautionary example: When the world is dividing into PCs for people who really need them, and mobile devices that are a radical step forward in ease of use, trying to be both at once could result in being neither fish nor fowl.
Subscription services for books like Safari Books Online http://my.safaribooksonline.com/9781449309473 already "loans" books with a model like this. They pay out from a pool based on the number of times a book is selected from their library. Of course a single use isn't going to pay out as much as a purchase, but the alternative is for a Safari-like subscription library to buy a single copy, or as many copies as would be used simultaneously, and do license management. And that opens the whole DRM can of worms.
An open-ended revenue model can be advantageous to authors of frequently-read books.
Java is much complained about, on the one hand by people who think it is too hard, and on the other hand by people who think it is not sufficiently expressive. But the evidence is you can build a world-beating OS with a Java userland. And evidently it isn't urgent to augment or replace Java, either with more expressive JVM languages like Scala, or supposedly simpler languages available for the JVM like the BASIC-like Jabaco, even though this could be done for Android since the translation to Dalvik bytecode is downstream of compiling into Java bytecode.
Java has great static code analysis tooling and great refactoring. There are books like Thinking in Java and Effective Java that will make you fluent in the idioms that make Java understandable, debuggable, and maintainable. For a programming beginner I'd suggest Learning Android and Head First Java. Android's documentation, tutorials, and examples are enormously improved since Android first came out.
Every language has screws, but a good case can be made that Java has fewer of them than many other languages.
How many people do you know who really need a completely general-purpose computer that they own and control personally?
How many "PCs" are actually nodes in a centrally controlled system, and not "personal" at all?
Because of the economics of making "PCs," we have the illusion that hundreds of millions of people buy and use "personal computers" each year. In reality, a minority, possibly a small minority, of those people actually take advantage of anything those "PCs" do that would require personal control over a general-purpose computer.
This is the reason mobile devices that are not quite "personal computers" are rightly popular. They serve the actual need. Hopefully, it will be possible to use mobile devices as if they were personal computers, so that the potential of personal computers can be applied to a networked, mobile world.
This is a great proposal. I would no longer make mistakes about a meeting in another time zone changing to local time for an in-person versus a phone meeting. However, it can be improved. Decimal time would make calculating percentages of time spent on various activities much easier. Combine the two for Flawless Victory.
Nobody has ever moved an operating system from mouse to touch. There is a first time for everything, but the two winning tablet OSs were designed for touch. I believe there is a reason: Turning a non-touch OS into a touch OS is harder than anyone doing it thinks it is.
Secondarily, I think this is what is holding back Web operating systems on touch devices. The Web wasn't designed for touch and Web operating systems "leak" bad user experience in from the non-touch Web. On Android and iOS touch devices, the Web browser is an ancillary UI and application environment, not the central part of the user experience.
That is correct. And most specifications for LI ("lawful intercept") specify that it should be undetectable, or, at least, inconspicuous to the people operating the network. That is, it has to operate outside network management and network statistics gathering. LI implementations can do that successfully because they are usually specified to capture a small fraction of network data - 1% in some cases. LI is distinct from the kinds of technologies used as a data dragnet by spy agencies, and it also distinct from deep packet inspection.
As the post above points out, if you have access to law enforcement tools for monitoring telephone networks, and no effective checks on that access, the underlying technology enables one to do the kind of snooping alleged here without leaving a trace in the network's operations.
I was hoping for a visual timeline of distributed git repos, or something that would make using git easier. Git is likely a better way to do version control, but it is better because it is fundamentally different. Those differences have not worked their way into Eclipse's abstraction of version control far enough, yet.
I can't find a link to the original story, and the source cited for this post is a TechDirt post that cites a Christian Science Monitor article that doesn't, as far as I can tell, refer to the original article any more precisely than as "a rather snide commentary the other day about Apple products." A link to the original would be appreciated.
Many of the comments here have been about whether Chrome OS has a market.
The answer may have more to do with form-factor than whether Android has already run away with the market.
Turning a browser-oriented OS into a touch OS isn't easy. Chrome is much more easily applicable to netbooks than tablets. Most Web sites are not designed for touch. Just making all of Google's Web sites and Web apps touch-friendly is a huge undertaking. For a netbook, you don't have to make the touch user experience as good as it is in Android.
Tablets are a middle ground: If the Chrome browser part of Chrome OS becomes more finger-friendly, maybe the answer is to make that browser an Android app - or find some other way of combining Android and ChromeOS, as many have suggested.
Google's official position on providing the Google applications (GMail, YouTube, etc.) on non-smartphone devices isn't consistent with what Android, and Android Market, is capable of: Android applications can specify which features they need, how big a screen they can support, etc. So, while it is a legitimate concern that some apps might fail on tablet devices, the vast majority of apps won't, and those that do have a simple mechanism for excluding themselves from being listed for download to tablet devices.
In addition to the criteria for being an officially blessed Android device being arbitrary in light of Android having mechanisms for apps to determine device compatibility, the process is also opaque: There is no published process for getting devices "approved."
And, in addition to all that, while Android Market and Google's suite of apps run on most Android devices, users of ex-officio Android devices are left to bootleg this software onto their devices.
When Google was in the process of wooing first tier mobile OEMs and bargaining with them, it made sense to provide exclusivity and a closed process for OEMs, in order to give Google the strongest possible negotiating position. Now that Google has every first tier mobile OEM except Nokia as a licensee, Google can maximize the potential of Android by providing a more open process for OEMs, and by treating PMPs, e-readers, and tablet device OEMs and the customers of these devices less backhandedly, either by making Google's apps available through alternative markets and direct download, or by making Android Market part of the Android Open Source Project, or otherwise available to OEMs outside of Google's inner circle.
Android has become the de facto "embedded Linux" for 32-bit systems-on-a-chip (SoCs). The fact this happened without Google's encouragement should not be taken as a guide to how to cultivate chip-maker, ODM, and OEM relationships.
The parent post here found the key fact: If you check article, in fact it confirms the back door was NOT in the source code. Someone replaced some mirrors, and due to lack of a signature, got away with it for a long time.
This event does not repudiate the protections of having source code available to inspect, and having project governance that reviews code. It does suggest people should be careful about which mirrors they use and how signatures are checked.
I have to agree with csartanis: Hacked system images like Cyanogen show that G1 hardware is, at least, adequate.
The problem is OEMs have no incentive to put money into handsets they sold two years ago. Google has to take up the slack, either by creating incentives to update older handsets, or legitimizing hacks like Cyanogen as a form of "aftermarket upgrade."
The suggestion that the lock-screen host widgets is good. The suggestion to get rid of hardware buttons is OK, but it's really only an incremental change.
There are at least a handful of harder problems crying out for an officially sanctioned solution:
1. A shareable Android device. This is presumably on the project plan for an Android TV, which can't be tied to one individual's Google account. Some tablet devices also have shared use cases, e.g. a "kitchen tablet."
2. Cleaning up non-touch UI conventions. Android started out with an AWT-like ability to move a focus and substitute an "OK" button for a touch-press, but this has become diluted and ignored in some cases. Some tablet devices (and TVs, and in-car devices) need a non-touch mode that has not gone decadent.
3. A transparent licensing process for Google APIs and the Google Experience suite of applications. This would open Android to more OEMs that Google has the bandwidth to manage hands-on. As with Windows CE, the licensing process could be subbed-out to systems integrators.
Slashdot Mirror
> Android is "a lot cheaper for HP to implement in a laptop; ChromeOS, in contrast, comes with more stringent system requirements that would cost HP a bit more."
It looks like sweet hardware. They may have good intentions re costs. But that's not how to define a product. The laptop form factor works against the touch interface by putting the screen just a little too far away. It also completely destroys the ability to hold a device like a sheaf of paper or clipboard.
The other side of the coin is that a browser-based UI is well-suited to using a pointing device instead of (or in addition to) touch.
Could have been a great Chromebook.
Going from "open government" to "outsourcing" is a non sequitur meant to set up a straw man. It is outsourcing that results in private firms treating government data as proprietary, and it is this kind of outsourcing that open government initiatives seek to avoid.
It's a long piece. Tl;dr: Think tank wonk mistakes Tim O'Reilly for a technolibertarian and turgidly tilts at windmills of his own invention.
Android app compatibility is available for Linux in several forms: You can install an Android distro in a virtualization container, Canonical's "Ubuntu for Android," Open Mobile's ACL (disclosure, I used to be CTO there), and others.
My view of the best way to do this (and not surprising that this is how Open Mobile does it) is that Android can be integrated into "foreign" desktop environments as if it were a Java SE-like runtime environment.
As for how I would want to use Ubuntu on a tablet, I would put it on a powerful tablet such as those Windows 8 will be shipping on. Then I can have my Android development tools in a tablet form factor, and I can run an x86 Android build in a VM or QEMU for testing/debugging.
Learn Android programming. While this advice is well-founded in personal experience, it may also be slightly self serving.
Not compatible with ASUS T-300 running Jelly Bean. :-(
The right to a patent monopoly is not a fundamental human right.
The US Constitution is written with a specific sense regarding rights. It grants no rights because it takes the point of view that you have human rights, with, or without any government's say so. Instead, the Constitution grants powers to the government.
The right to a patent monopoly is not one of the rights the Constitution assumes you have. That's because, in the eyes of the authors of that document, it's not really a basic human right. Instead, the government is explicitly empowered to grant patent and copyright monopolies. And that power is conditional: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."
If it isn't functioning as intended, is it still legitimate?
We've put on Mars a large machine that blasts the landscape with a heat ray. A heat ray. And we have set the example that such a machine can be robotic, and impervious to microbes. That's sure to end well.
Is this some kind of weird expression of the New England work ethic? Make the driver work just as hard as ever, but should he ever falter, a superior system kicks in and saves his ass?
If I have a computer that can handle emergencies more reliably than I can, surely it can handle the mundane more reliably, too.
The trend in Android has been, up to now, in the right direction.
For example, the Android Open Source Project originally did not have a development platform build target or reference hardware. Now it does. That means you can take the entire Android Open Source Project and built it and run it, instead of having to "root" a commercial device and port Android to that device before you can start playing with Android on real hardware.
It is in Google's interest to make Android progressively easier to port because Google wants faster and more-consistent updates to Android across all the OEMs using Android. A vibrant and useful AOSP is important to that goal.
Moreover, when faced with a competitor using the Android Open Source Project to build a competing platform and support a competing ecosystem, Google did nothing to thwart AOSP, or to make it harder for Amazon to use AOSP.
Android is partly-open because Google uses a suite of applications and services that are not open source to create commercial Android products with the Google Logo, and OEMs and carriers add their own software to products. There may be room in the market for a more-open mobile OS that isn't tied to big e-commerce ecosystems. Tizen might be one such system, and Jolla might bring Meego back. If those systems prove to be more open, and under less pressure to provide exclusivity to their sponsors, they could turn out to provide truly open, hackable communications devices.
Open communications devices, with open hardware and software, are important because they would enable communications privacy, among other qualities.
The article mistake's Google's lack of direct revenue from Android with revenue of all the different products Google delivers over Android and other mobile OSs. The money-making parts of Google deliver apps to Android, iOS, and other mobile platforms, and make money from those apps.
Facebook has a greater challenge, and is off to a later start, but you have to ask if that's really a worry, compared with getting the mobile launch right. Facebook faces very little competition. Other than Google+, there are no social networks that have an in-house phone OS. The mobile Google+ app is among the least well-executed mobile apps among all of Google's products.
Amazon has shown it's possible to have a successful product entry with a mobile device, even with Android and iOS as competitors. Facebook has a large ecosystem, like Amazon. There is no reason to think Facebook's mobile market window is closing. On the other hand, if Facebook were to ship a "Kin"-like flop, that would set them back substantially.
If a Facebook mobile device is coming, Facebook has every incentive to wait until it is done right.
I am one of the people Steve Jobs said would continue to need a fully general-purpose computer, which he compared to people who need to drive a truck. I make software for a living, and Linux is a great platform for software development. The point Jobs was making is that it isn't appropriate to try to make personal computers as simple to use as mobile devices. And while ease of use has many virtues for both the mainstream consumer and the "truck driver," ultimately, the way products are designed will diverge.
Android is the consumer's Linux. Android took the step of discarding much of the Linux userland and starting afresh, with a software platform that is both powerful, and designed for finger-friendly mobile devices. That turned out to be a very successful approach. Trying to evolve a desktop OS to do what Android and iOS do is very difficult, and there are no successful examples. Microsoft has repeatedly tried to make Windows work on tablets, and failed repeatedly. It's an open question if Windows 8, even though it contains a finger-friendly UI system, can straddle the two worlds without creating situations where the user is dumped into finger-hostile territory at inopportune times.
While making desktop Linux more user-friendly remains a worthy goal, it may turn out that Windows 8 is a cautionary example: When the world is dividing into PCs for people who really need them, and mobile devices that are a radical step forward in ease of use, trying to be both at once could result in being neither fish nor fowl.
Subscription services for books like Safari Books Online http://my.safaribooksonline.com/9781449309473 already "loans" books with a model like this. They pay out from a pool based on the number of times a book is selected from their library. Of course a single use isn't going to pay out as much as a purchase, but the alternative is for a Safari-like subscription library to buy a single copy, or as many copies as would be used simultaneously, and do license management. And that opens the whole DRM can of worms.
An open-ended revenue model can be advantageous to authors of frequently-read books.
Java is much complained about, on the one hand by people who think it is too hard, and on the other hand by people who think it is not sufficiently expressive. But the evidence is you can build a world-beating OS with a Java userland. And evidently it isn't urgent to augment or replace Java, either with more expressive JVM languages like Scala, or supposedly simpler languages available for the JVM like the BASIC-like Jabaco, even though this could be done for Android since the translation to Dalvik bytecode is downstream of compiling into Java bytecode.
Java has great static code analysis tooling and great refactoring. There are books like Thinking in Java and Effective Java that will make you fluent in the idioms that make Java understandable, debuggable, and maintainable. For a programming beginner I'd suggest Learning Android and Head First Java. Android's documentation, tutorials, and examples are enormously improved since Android first came out.
Every language has screws, but a good case can be made that Java has fewer of them than many other languages.
Think about the phrase "personal computer."
How many people do you know who really need a completely general-purpose computer that they own and control personally?
How many "PCs" are actually nodes in a centrally controlled system, and not "personal" at all?
Because of the economics of making "PCs," we have the illusion that hundreds of millions of people buy and use "personal computers" each year. In reality, a minority, possibly a small minority, of those people actually take advantage of anything those "PCs" do that would require personal control over a general-purpose computer.
This is the reason mobile devices that are not quite "personal computers" are rightly popular. They serve the actual need. Hopefully, it will be possible to use mobile devices as if they were personal computers, so that the potential of personal computers can be applied to a networked, mobile world.
This is a great proposal. I would no longer make mistakes about a meeting in another time zone changing to local time for an in-person versus a phone meeting. However, it can be improved. Decimal time would make calculating percentages of time spent on various activities much easier. Combine the two for Flawless Victory.
Nobody has ever moved an operating system from mouse to touch. There is a first time for everything, but the two winning tablet OSs were designed for touch. I believe there is a reason: Turning a non-touch OS into a touch OS is harder than anyone doing it thinks it is.
Secondarily, I think this is what is holding back Web operating systems on touch devices. The Web wasn't designed for touch and Web operating systems "leak" bad user experience in from the non-touch Web. On Android and iOS touch devices, the Web browser is an ancillary UI and application environment, not the central part of the user experience.
That is correct. And most specifications for LI ("lawful intercept") specify that it should be undetectable, or, at least, inconspicuous to the people operating the network. That is, it has to operate outside network management and network statistics gathering. LI implementations can do that successfully because they are usually specified to capture a small fraction of network data - 1% in some cases. LI is distinct from the kinds of technologies used as a data dragnet by spy agencies, and it also distinct from deep packet inspection.
As the post above points out, if you have access to law enforcement tools for monitoring telephone networks, and no effective checks on that access, the underlying technology enables one to do the kind of snooping alleged here without leaving a trace in the network's operations.
I was hoping for a visual timeline of distributed git repos, or something that would make using git easier. Git is likely a better way to do version control, but it is better because it is fundamentally different. Those differences have not worked their way into Eclipse's abstraction of version control far enough, yet.
You wouldn't steal a car.
But would you download one?
I can't find a link to the original story, and the source cited for this post is a TechDirt post that cites a Christian Science Monitor article that doesn't, as far as I can tell, refer to the original article any more precisely than as "a rather snide commentary the other day about Apple products." A link to the original would be appreciated.
Many of the comments here have been about whether Chrome OS has a market.
The answer may have more to do with form-factor than whether Android has already run away with the market.
Turning a browser-oriented OS into a touch OS isn't easy. Chrome is much more easily applicable to netbooks than tablets. Most Web sites are not designed for touch. Just making all of Google's Web sites and Web apps touch-friendly is a huge undertaking. For a netbook, you don't have to make the touch user experience as good as it is in Android.
Tablets are a middle ground: If the Chrome browser part of Chrome OS becomes more finger-friendly, maybe the answer is to make that browser an Android app - or find some other way of combining Android and ChromeOS, as many have suggested.
Google's official position on providing the Google applications (GMail, YouTube, etc.) on non-smartphone devices isn't consistent with what Android, and Android Market, is capable of: Android applications can specify which features they need, how big a screen they can support, etc. So, while it is a legitimate concern that some apps might fail on tablet devices, the vast majority of apps won't, and those that do have a simple mechanism for excluding themselves from being listed for download to tablet devices.
In addition to the criteria for being an officially blessed Android device being arbitrary in light of Android having mechanisms for apps to determine device compatibility, the process is also opaque: There is no published process for getting devices "approved."
And, in addition to all that, while Android Market and Google's suite of apps run on most Android devices, users of ex-officio Android devices are left to bootleg this software onto their devices.
When Google was in the process of wooing first tier mobile OEMs and bargaining with them, it made sense to provide exclusivity and a closed process for OEMs, in order to give Google the strongest possible negotiating position. Now that Google has every first tier mobile OEM except Nokia as a licensee, Google can maximize the potential of Android by providing a more open process for OEMs, and by treating PMPs, e-readers, and tablet device OEMs and the customers of these devices less backhandedly, either by making Google's apps available through alternative markets and direct download, or by making Android Market part of the Android Open Source Project, or otherwise available to OEMs outside of Google's inner circle.
Android has become the de facto "embedded Linux" for 32-bit systems-on-a-chip (SoCs). The fact this happened without Google's encouragement should not be taken as a guide to how to cultivate chip-maker, ODM, and OEM relationships.
The parent post here found the key fact: If you check article, in fact it confirms the back door was NOT in the source code. Someone replaced some mirrors, and due to lack of a signature, got away with it for a long time.
This event does not repudiate the protections of having source code available to inspect, and having project governance that reviews code. It does suggest people should be careful about which mirrors they use and how signatures are checked.
I have to agree with csartanis: Hacked system images like Cyanogen show that G1 hardware is, at least, adequate.
The problem is OEMs have no incentive to put money into handsets they sold two years ago. Google has to take up the slack, either by creating incentives to update older handsets, or legitimizing hacks like Cyanogen as a form of "aftermarket upgrade."
The suggestion that the lock-screen host widgets is good. The suggestion to get rid of hardware buttons is OK, but it's really only an incremental change.
There are at least a handful of harder problems crying out for an officially sanctioned solution:
1. A shareable Android device. This is presumably on the project plan for an Android TV, which can't be tied to one individual's Google account. Some tablet devices also have shared use cases, e.g. a "kitchen tablet."
2. Cleaning up non-touch UI conventions. Android started out with an AWT-like ability to move a focus and substitute an "OK" button for a touch-press, but this has become diluted and ignored in some cases. Some tablet devices (and TVs, and in-car devices) need a non-touch mode that has not gone decadent.
3. A transparent licensing process for Google APIs and the Google Experience suite of applications. This would open Android to more OEMs that Google has the bandwidth to manage hands-on. As with Windows CE, the licensing process could be subbed-out to systems integrators.