Why does Google support two OSs with such overlapping use cases, roles?

http://news.cnet.com/8301-1023_3-57444837-93/googles-pichai-predicts-chrome-os-android-convergence/. I think, soon after Chrome for Android is mature enough , Google could merge Chromium (WebKit + V8) into Android as the third proper development platform along with Dalvik VM and NDK. Once Chrome for Android brings in Chrome apps and extensions on Android like its on PC and Mac, A convergence and a possible shift will begin. Why  would Google do such a thing when Android is already ruling ? The Web is Google's ultimate platform and that is where their services shine! Chrome OS is the future they look forward to, where everyone will be able to use Web 24x7 (although HTML5 has local storage!). For this they have turned into an ISP as well! They have already started super-fast http://techcrunch.com/2012/12/17/google-fiber-announces-the-next-5-kansas-city-neighborhoods-to-come-online-in-2013/ project  and have recently provided http://bits.blogs.nytimes.com/2012/06/25/google-new-york-wi-fi/. They have been questioned many times, about how is, companies forking Android and coming up with their own versions, hurting them. (Referring to the Kindle fire  and the Nook tablet ) In response, they have always said that, all they want is for people to use their services and the internet in general,  as much as much as possible. (That's where there ad and search business rules) Every move they make, is to improve the web accessibility, web usage and fast browsing experience and that is primary reason they made a browser themselves and see how they have made Microsoft go crazy about IE and HTML5! That's why they keep coming up with great iOS apps as well,  so that they don't miss out on iOS users! Also, More the usage of native, locked apps increase, more data will be locked into local storage of these apps or on their locked cloud back-end. and that would hurt on how PageRank, their Search engine algorithm works! Also it would hurl there huge keyword based ad business from where, their major revenue comes! So I guess they are sticking to Android which is their present and will slowly slowly move people to a version where Chrome OS and Android are the same thing! Soon at some Google I/O, we will see an announcement for another Android dessert with a Chrome cherry on the top !

If we see predict tech future as play a guessing game,you can guess twice time is better than guess just once: I feel like though chrome os and android have overlap, but chrome os is more like betting on future, android is more on present. Some people like dramatic changes, more likely to adpot chrome os which is more based on cloud, some people like reform in more gentle way more likey to adopt android which is  heavy on client side,more like tradition desktop os.

Because if they were to bake Chrome OS into Android they'd be slapped with a lawsuit like Microsoft has with Internet Explorer: antitrust rules apply. Hypocritically though, Android Browser is just as much a default browser as Chrome yet the powers that be let that pass while slapping Microsoft with a $740 million fine for IE10 in Windows 8. Go figure.

You could conceivably converge the middle layers of the system - the portable parts of the OS kernel through to the lower level standard libraries. This is, after all, what Apple does with OSX and iOS. Since both systems already use the same OS kernel, this is really just a question of whether you use web technologies as the primary development platform or Java. Google doesn't necessarily have to choose - they already ported Chrome to Android and encouraging more app development suitable for touch devices on that platform would be simple enough. Doesn't mean they would have to abandon Dalvik. The upper and lower layers of the OS have to be different. The very different requirements of touch-based apps mean the top layer of the GUI has to be different, and other hardware differences similarly have to be accounted for in user interactions. At the lowest levels, the device drivers, and the details of low level scheduling on mobile devices have to be much more power-sensitive than on a laptop. Minimizing the use of the CPUs, offloading work to specialized hardware, and shutting down unused peripherals are essential on mobile devices, merely nice-to-have for laptops.