|From: Eric L||12/19/2013 12:14:16 PM|
|Dogfight: Apple v Google ... |
The article below was excerpted and adapted from the second chapter of Fred Vogelstein’s "Dogfight: How Apple and Google Went to War and Started a Revolution" (272 pages) which was published in hardcover. paperback, and a Kindle edition (which I purchased from Amazon but have not yet read) last month.
>> The Day Google Had to 'Start Over' on Android
Google was building a secret mobile product to fend off chief rival Microsoft. Then Apple announced the iPhone, and everything changed.
December 18, 2013
In 2005, on Google’s sprawling, college-like campus, the most secret and ambitious of many, many teams was Google’s own smartphone effort—the Android project. Tucked in a first-floor corner of Google’s Building 44, surrounded by Google ad reps, its four dozen engineers thought that they were on track to deliver a revolutionary device that would change the mobile phone industry forever.
By January 2007, they’d all worked sixty-to-eighty-hour weeks for fifteen months—some for more than two years—writing and testing code, negotiating software licenses, and flying all over the world to find the right parts, suppliers, and manufacturers. They had been working with prototypes for six months and had planned a launch by the end of the year . . . until Jobs took the stage to unveil the iPhone.
Chris DeSalvo’s reaction to the iPhone was immediate and visceral. “As a consumer I was blown away. I wanted one immediately. But as a Google engineer, I thought ‘We’re going to have to start over.’”
For most of Silicon Valley—including most of Google—the iPhone’s unveiling on January 9, 2007 was something to celebrate. Jobs had once again done the impossible. Four years before he’d talked an intransigent music industry into letting him put their catalog on iTunes for ninety-nine cents a song. Now he had convinced a wireless carrier to let him build a revolutionary smartphone. But for the Google Android team, the iPhone was a kick in the stomach.
“What we had suddenly looked just so . . . nineties,” DeSalvo said. “It’s just one of those things that are obvious when you see it.”
The cell phone industry in 2005 was the perfect example of a hairy Google-size problem. The software industry for mobile phones was one of the most dysfunctional in all technology. There wasn’t enough wireless bandwidth for users to surf the Internet on a phone without frustration. Phones weren’t powerful enough to run anything but rudimentary software. But the biggest problem, as Jobs had learned, was that the industry was ruled by an oligopoly: Few companies besides the carriers and the phone makers were writing software for phones, and what existed was terrible. Wireless bandwidth would improve and phone chips would get more powerful; but back then it looked as if the carriers and phone makers would control it all
“We had done a deal with Vodafone [the big European carrier] to try to get Google search on their phones,” said one top Google executive who would not give his name. “But the search they offered us was that we could put some results on, but that they would control most of them, and that our results would be at the bottom of every query. They didn’t have a good mobile browser. Ring-tones [that they were selling] sometimes got prioritized in search results. All the carriers were doing this. They thought they could provide all the services inside a walled garden [as AOL had in the 1990s], and that this control was the best way to make money.
The reason few developers built software for mobile phones was because anytime they tried, they lost money. There was no standardization in the industry. Virtually every phone ran its own software and set of applications, meaning software written for a Samsung phone often wouldn’t run on a Motorola phone, which wouldn’t run on a Nokia. Software platforms were incompatible even within companies. For example, there were a handful of different versions of Symbian. Put simply, the mobile industry screamed “money pit” to any enterprising developer. Most stayed away. The most lucrative business was not writing apps for phones. It was owning a testing company that would make sure your apps worked on all the phones in the market. Larry Page has never been shy talking about how frustrating those days were for him and Google.
“We had a closet full of over 100 phones [that we were developing software for], and we were building our software pretty much one device at a time,” he said in his 2012 report to shareholders. In various remarks over the years he has described the experience as both “awful” and “incredibly painful.”
But Page and the rest of Google’s executives knew that someone would figure out the mobile business eventually, and they were particularly concerned that that company would be Microsoft. Back then, Microsoft was still the richest and most powerful technology company in the world, and it was finally getting traction with its Windows CE mobile phones and software. Windows CE smartphones were still a niche market, but if consumers took to the platform en masse as they did later with the iPhone, Google’s entire business could be in jeopardy.
This wasn’t an exaggeration. Back then, Microsoft and Google were in the midst of a nasty battle of their own for dominance in search, and for top dog in the tech world. After two decades of being the first-choice workplace of top engineering talent, Microsoft was now losing many of those battles to Google. Chairman Bill Gates and CEO Steve Ballmer had made it clear they took Google’s challenge personally. Gates seemed particularly affected by it. Once or twice he made fun of the way Page and his Google cofounder Sergey Brin dressed. He said their search engine’s popularity was “a fad.” Then, in the same breath he would issue the ultimate compliment saying that of all his competitors over the years Google was the most like Microsoft.
Google executives were convinced that if Windows on mobile devices caught on, Microsoft would interfere with users’ access to Google search on those devices in favor of its own search engine. The U.S. government’s successful antitrust trial against Microsoft in the 1990s made it difficult for the company to use its monopoly on desktops and laptops to bully competitors. It could not, for example, make Microsoft’s the default search engine in Windows without giving users a choice between its search engine and those from Google, Yahoo, and others.
However, on smartphones, few rules governed how fiercely Microsoft could compete. It didn’t have a monopoly there. Google worried that if Microsoft made it hard enough to use Google search on its mobile devices and easy enough to use Microsoft search, many users would just switch search engines. This was the way Microsoft killed Netscape with Internet Explorer in the 1990s. If users stopped using Google’s search engine and began using a competitor’s such as Microsoft’s, Google’s business would quickly run aground. Google made all its money back then from the search ads that appeared next to its search results. “It’s hard to relate to that [fear of Microsoft] now, but at the time we were very concerned that Microsoft’s mobile strategy would be successful,” Schmidt said in 2012 during testimony in the Oracle v. Google copyright trial.
On the day Jobs announced the iPhone, the director of the Android team, Andy Rubin, was six hundred miles away in Las Vegas, on his way to a meeting with one of the myriad handset makers and carriers that descend on the city for the Consumer Electronics Show. He reacted exactly as DeSalvo predicted. Rubin was so astonished by what Jobs was unveiling that, on his way to a meeting, he had his driver pull over so that he could finish watching the webcast.
“Holy crap,” he said to one of his colleagues in the car. “I guess we’re not going to ship that phone.”
What the Android team had been working on, a phone code-named Sooner, sported software that was arguably more revolutionary than what had just been revealed in the iPhone. In addition to having a full Internet browser, and running all of Google’s great web applications, such as search, Maps, and YouTube, the software was designed not just to run on Sooner, but on any smartphone, tablet, or other portable device not yet conceived. It would never need to be tethered to a laptop or desktop. It would allow multiple applications to run at the same time, and it would easily connect to an online store of other applications that Google would seed and encourage. By contrast, the iPhone needed to connect to iTunes regularly, it wouldn’t run more than one application at a time, and in the beginning it had no plans to allow anything resembling an application store.
However, the Sooner phone was ugly. It looked like a Black-Berry, with a traditional keyboard and a small screen that wasn’t touch-enabled. Rubin and his team, along with partners HTC and T-Mobile, believed consumers would care more about the great software it contained than its looks. This was conventional wisdom back then. Revolutionary phone designs rarely succeeded. The Nokia N-Gage, which in 2003 tried to combine a gaming system with a phone and email device, often gets mentioned here. RIM had become one of the dominant smartphone makers on the planet by making BlackBerry’s unadorned functionality one of its main selling points: you got a phone, an incredible keyboard, secure email, all in one indestructible package.
The iPhone, in contrast, was not only cool looking, but it used those cool looks to create entirely new ways to interact with a phone—ways that Android engineers either hadn’t thought possible or had considered too risky. By using a virtual keyboard and replacing most real buttons with software-generated buttons on a big touchscreen, every application could now have its own unique set of controls. Play, Pause, and Stop buttons only appeared if you were listening to music or watching video. When you went to type a web address into the browser, the keyboard appeared, but it disappeared when you hit Enter. Without the physical keyboard taking up half the phone, the iPhone had a screen twice the size of virtually every other phone on the market. It all worked the same way whether the user held the phone in portrait or landscape mode. Apple had installed an accelerometer to use gravity to tell the phone how to orient the screen.
A lot was wrong with the first iPhone too. Rubin and the Android team—along with many others—did not think users would take to typing on a screen without the tactile feedback of a physical keyboard. That is why the first Android phone—the T-Mobile G1 from HTC, nearly two years later—had a slide-out keyboard. But what was also undeniable to the Android team was that they had underestimated Jobs. At the very least, Jobs had come up with a new way of interacting with a device— with a finger instead of a stylus or dedicated buttons—and likely a lot more. “We knew that Apple was going to announce a phone. Everyone knew that. We just didn’t think it would be that good,” said Ethan Beard, one of Android’s early business development executives.
Within weeks the Android team had completely reconfigured its objectives. A phone with a touchscreen, code-named Dream, that had been in the early stages of development, became the focus. Its launch was pushed out a year until fall 2008. Engineers started drilling into it all the things the iPhone didn’t do to differentiate their phone when launch day did occur. Erick Tseng, then Android’s project manager, remembers suddenly feeling the nervous excitement of a pending public performance. Tseng had joined Google the year before out of Stanford business school after Eric Schmidt, himself, sold him on the promise of Android.
“I never got the feeling that we should scrap what we were doing—that the iPhone meant game over. But a bar had been set, and whatever we decided to launch, we wanted to make sure that it cleared the bar.” ###
About the Author: Fred Vogelstein is a contributing editor at Wired magazine, where he writes about the tech and media industries. He has been a staff writer for Fortune, The Wall Street Journal, and U.S. News & World Report. His work has also appeared in The New York Times Magazine, The Los Angeles Times, and The Washington Post.
While reader reviews of 'Dogfight' are generally quite positive The New York Times Sunday book review by Siva Vaidhyanathan is less so ...
"... Some books about technology emphasize the people responsible for firms and innovations. Others analyze the consequences of innovation. Vogelstein, a diligent and prolific journalist for Wired magazine, fails on both counts. As he concedes in an afterword, Apple offered him no access to its executives. As for Google, Vogelstein has interviewed Eric E. Schmidt, Google’s executive chairman, and some project leaders and engineers for his Wired articles — but not Google’s co-founders Larry Page and Sergey Brin. This book breaks no news and recycles much of what Steven Levy wrote in the best book to date about Google, “In the Plex,” and what Walter Isaacson revealed in his huge biography of Steve Jobs. ... The next 10 years in Silicon Valley could be even more interesting and influential than the past 10 years. “Dogfight” might have served as a primer on the issues, personalities and technologies to watch. Instead, it’s a stale account of very familiar events and very famous men." # # #
- Eric -
|RecommendKeepReplyMark as Last Read|
|From: Eric L||12/19/2013 12:59:43 PM|
|Huawei Moving Upstream While Downsizing Its Smartphone Model base ... |
>> Huawei keeps its eye on higher end of phone market
-- Huawei executive Shao Yang (File photo/Chiu Wan-ren) --
Despite the hot sales of Chinese budget phone brand Xiaomi, leading Chinese mobile phone producer Huawei plans to keep its focus on the higher end of the market by bringing out one or two models priced at 2,600 yuan (US$430), competing directly with market leaders Samsung and Apple, said Shao Yang, vice president for terminal marketing of Huawei, on Dec. 12.
Shao made the remark at a year-end press conference in Beijing, in response to the news that Xiaomi had sold 10,000 of its low-priced Hongmi (Red Rice) phones in just 10 minutes in Taiwan last week.
Shao noted that Xiaomi has performed outstandingly well with its unique marketing approach and focus on a few "hot items," taking advantage of the desire of consumers for something different.
While Huawei is not considered as exciting as Xiaomi in the Greater China market, the brand is excelling in extending its global appeal, according to Shao, who added the company achieved remarkable sequential sales growth in many international markets worldwide in the third quarter, including 140% in Latin America, 50% in Southeast Asia, 45% in Western Europe, 45% in Russia and 50% in Africa.
Huawei plans to downsize its product range next year, when it will roll out only 10 or so models across the price spectrum, with one or two bearing a price tag of 2,600 yuan but boasting performance comparable to the high-end models of Samsung and Apple, Shao said.
Shao said Huawei will continue expanding in the US despite the company's well-publicized complications with the US government, saying that one advantage of overseas markets is that they work in line with commercial rules, rather than politics. ###
- Eric -
|RecommendKeepReplyMark as Last ReadRead Replies (1)|
|To: Eric L who wrote (1628)||1/5/2014 12:26:07 PM|
|From: Uncle Frank|
|There's a new player in the phone business, Eric... Western. They've targeted the younger demographic, and their revolutionary design doesn't require batteries!|
|RecommendKeepReplyMark as Last Read|
|From: Eric L||2/8/2014 8:47:47 AM|
|Forking Android: Ars Technica's Peter Bright Opines and Defines the Issues ... |
>> Neither Microsoft, Nokia, nor anyone else should fork Android. It’s unforkable.
Canning Windows Phone and using Android would be a huge mistake.
February 8, 2014
As happens from time to time, the suggestion has been made that Microsoft cancel Windows Phone, and instead fork Android. It's not the first time this suggestion has been made. It's probably not the last, either.
It's a poor idea. Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
The outline of the "Microsoft should fork Windows Phone" argument is as follows: Windows Phone doesn't have huge developer buy-in or sales success, but Android has both. By forking Android, Microsoft could provide unique value—corporate integration with things like Exchange, Active Directory, and System Center or InTune; full Office support; a polished user experience—and make the platform depend on its own cloud services (Bing, Bing Maps, Azure) rather than Google's. But simultaneously, it would still have access to all the Android applications that people depend on.
The result should be a platform that's somehow more attractive to consumers, by virtue of the Android brand and all those Android apps, more attractive to developers thanks to the Android APIs, and cheaper for Microsoft to develop, since core operating system development can be left to Google.
Where this falls down is that there's no good way to use the Android platform this way. It's not designed for it. In fact, with each new Android release, Google is making a forked operating system less and less viable.
Broadly speaking, Google produces two big chunks of code. The first is the Android Open Source Platform (AOSP) codebase. This provides the basic bones of a smartphone operating system: it includes Android's version of the Linux kernel, the Dalvik virtual machine, and portions of the basic user interface (settings app, notification panel, lock screen). This part is licensed under a mix of the GPL and Apache license. Google produces periodic code release of these open source parts, though has been criticized for performing the actual development largely behind closed doors.
The second chunk is called the Google Mobile Services (GMS). (Or at least, sometimes it's called GMS. Sometimes it's called just Google Services, and sometimes it's Google Play or Google Play Apps; GMS is what it's called in the code, though, so that seems to be the most common name). This has two big portions. The Google Play Services provides a wealth of APIs and system services: APIs for Google Maps, Location, and in-app purchasing; Google+ integration; Remote Wipe; Malware scanning; and more. Then there's the Play Store collection of apps: Search, Gmail, Chrome, Maps, and many more.
The GMS has a few important features. GMS isn't open source. Anyone can take AOSP and slap it on a phone. That's not true of GMS. To get GMS, the device has to meet certain technical requirements (performance, screen resolution, and so on), and it has to pass validation. Though Google says that the GMS suite is itself free, the validation process isn't, with reports that it costs around $0.75 per device.
GMS also seems not to be divisible: if your phone passes the GMS validation and can include GMS, it includes everything: both Play Services, and the various Google-branded apps that use those services.
The split between AOSP and GMS is not constant, either. Google has slowly been migrating more and more functionality to GMS. For example, in the latest Nexus 5, the core phone user interface—the thing that you use to launch apps and show icons—has been rolled into the GMS Search app.
Similarly, APIs have made the move. AOSP contains a location API, but GMS contains a newer, better one, with additional features. Google encourages developers to use the GMS API, and the AOSP Location API mostly dates back to Android 1.0, and hasn't seen any substantial changes since Android 1.5. The result is that many third-party applications are not merely "Android" applications: they're GMS applications, and won't run without the proprietary, non-open Google software.
Four ways to do Android
There are four ways that hardware builders can use Android on their phones.
The first is the way that Google really wants companies to use Android: by relying both on AOSP and GMS. Pass the certification, include all the Google services and Google apps. That's what companies like Samsung and HTC and LG do. Going this route still provides some facility for the OEM to customize. OEMs can provide their own apps to sit alongside the Google ones, for example. It appears that Google isn't completely happy about this—there are reports that the company recently made an agreement with Samsung whereby Samsung would reduce the amount of customization of the user interface and deprioritize or remove its apps that competed directly with Google-branded equivalents.
Taking this path provides the best compatibility with third-party applications by ensuring that they have both AOSP and GMS APIs available to them. It also provides the most consistent experience: in spite of the various customizations that are done, it means that Google's apps will be available, and those apps will work the same way on any AOSP+GMS device.
It also cedes most control to Google, and that level of control will only grow. Each new release increases the level of integration with Google's own services, and Google is moving more and more new functionality to GMS, leaving AOSP a barebones husk.
At the other end of the spectrum, you can ignore GMS entirely. Ship a phone with AOSP and perhaps some custom software on top of it to make the experience a little less rough for users, and call the job done. At the very cheapest end of the market, there are companies doing precisely this. If they choose, OEMs can provide their own stores and other services to fill the many, many gaps that omitting GMS leaves, but they're always at a disadvantage relative to GMS devices, because they won't be compatible with any third-party applications that use GMS' APIs. That's not a small category, either, since features such as in-app purchasing are in GMS.
The third option is the one that spans the two: ship a device with AOSP, and an equivalent to GMS that provides new implementations of substantially the same APIs. Provide workalike replacements for services such as location and mapping, but plumb into Microsoft services rather than Google ones. No company has really gone down this route. The closest is Amazon, which provides near-drop-in replacements for some Google APIs (in particular mapping), but which hasn't even begun to keep pace with GMS development in general.
Technically, however, a company with sufficient development resources could provide its own GMS replacement. The overhead would be not insignificant, especially as—to ensure optimal compatibility—the replacement would have to replicate not just correct functioning, but any bugs or quirks of the GMS implementation.
There are also lots of little awkward aspects of the GMS API; it includes such capabilities as "share with Google+" which few companies have any real counterpart to. Another example: there is an API for handling turn-based multiplayer gaming. A company could implement this API and have its own server infrastructure for managing the gaming sessions, but obviously these gaming sessions would be completely separate from Google's gaming sessions, fragmenting the player base in a way that game developers are unlikely to be keen on.
As an added bonus, should the ultimate resolution of Google's long-running legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of wholesale reimplementation of GMS would become legally actionable. Google could, if it chose to, shut it down through the courts.
To these three options, one could perhaps add a fourth: use AOSP to provide a few essential services—support for hardware, telephony, and so on—but then build an entirely new platform and APIs to run on it. Aspects of Amazon's API support would fall into this category, with some of its APIs covering the same ground as GMS APIs, but in a completely different, incompatible way. It's not clear, however, that any manufacturer has entirely embraced this path, though one might argue that Ubuntu for Android is similar, at least in spirit.
You can have compatibility or control: Not both
The first of these options—AOSP with GMS—is the only option that provides the full Android experience. It's the only one that ensures developers can transfer their skills perfectly, the only one that ensures that the full breadth and variety of Android software is available. However, it's clearly not a good option for Microsoft, given that it would almost entirely cede control of the platform to Google—and judging by the advertising company's track record, it would cede even more control with each new Android release.
The second option—AOSP with a few extra custom extras—has the upside of providing an opportunity for Microsoft to integrate its own services. It would support some Android software, though exactly how much is unclear. It would certainly mean omitting any high-profile title using in-app purchasing, so, say, Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out. If one were building a feature phone platform, this may be a somewhat reasonable path to take. When the phone is only really built for running the built-in apps (camera, browser, e-mail) the fact that many Android apps would be incompatible doesn't really matter.
The rumors of a Nokia-built Android phone suggest this kind of approach: AOSP under the hood, but with Nokia services, not Google ones, on top.
However, it's important to understand just how deficient this kind of device would be. Google has pushed very significant pieces of functionality into GMS, including messaging and the Chrome browser. The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained. If a company wants to use AOSP without GMS, it has a lot of work to do if it wants to produce a high quality experience. The open source parts just aren't good enough.
Amazon's Kindle experience also demonstrates how even having an Android-like AOSP-derived platform is challenging. Kindle doesn't have the latest and greatest Android games, because their various developers haven't bothered making non-GMS versions of their games, even though the Kindle platform is very similar to Google's. In other words, the application challenge already faced by Windows Phone isn't solved by using AOSP. The only way to solve the application issue is to be not merely an AOSP platform but a GMS platform.
The third option—AOSP with a home-grown GMS equivalent—would solve this, but it would also maximize the development effort required by the forker. Providing equivalents to every GMS capability ensures at least that users get a decent experience. It would also reinstate the software compatibility that AOSP without GMS forfeits.
But this is a huge undertaking. For Microsoft, the effort required to build a GMS workalike on top of AOSP is going to be comparable to the effort required to build the Windows Phone shell and APIs on top of Windows. In fact, it's likely to be somewhat greater: Microsoft already has, for example, a browser engine that runs on Windows. It doesn't have one that runs on AOSP.
Moreover, it still implicitly gives Google control over the platform. Various aspects of how Android is used are determined by the underlying APIs: sharing between applications, for example, is done in a particular Android way. Any platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose.
The fourth option—use AOSP with an entirely new software stack on top—gives freedom and flexibility, but to what end? The kernel isn't the important bit. Microsoft already has a smartphone kernel. Windows Phone 8 already uses it. And strikingly, for Microsoft, ditching Windows Phone doesn't mean that the company can ditch development of this kernel. It's already being developed—for Windows! The kernel isn't the hard part.
If Android were an open platform in the way that Firefox OS or Ubuntu for smartphones were an open platform, the forking suggestion would make more sense. The AOSP/GMS split wouldn't exist. Everything would be in AOSP, so piecemeal substitution of back-end services without having to reinvent vast tracts of code and without any major compatibility implications would be practical.
But it isn't. Not only is it not this kind of an open platform, but Google is actively working to make it functionally less open with each new release. The result is that a forker has to make a choice: they can give Google control and get the all the upsides of the platform, or they can snatch control from Google and get almost none of them.
Android isn't designed to be forked. With GMS, Google has deliberately designed Android to resist forking. Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform. ###
- Eric -
|RecommendKeepReplyMark as Last ReadRead Replies (1)|
|To: Eric L who wrote (1630)||2/13/2014 4:53:51 PM|
|From: Eric L|
|The Openness of Android (Paul Thurrott) ... |
>> Android Is Not Really Open, Secret Documents Reveal
Don't be evil, indeed
Windows IT Pro
February 13, 2014
A recent leak of internal Google documents reveals that Google's dominant Android mobile OS isn't "open" or "open source," as the company claims. Indeed, licensing Android comes with a complex web of requirements that binds the hardware maker's devices to Google's extensive collection of online services and forces them to use Google apps as the default.
Put simply, Google is engaging in exactly the same product-bundling practices that got Microsoft in antitrust trouble around the world. But it is doing so with a far more invasive suite of services.
"In order to obtain key mobile apps, including Google's own Search, Maps, and YouTube, manufacturers must agree to install all the apps Google specifies, with the prominence Google requires, including setting these apps as default where Google instructs," Harvard University professor Ben Edelman writes in a blog post explaining Google's practices. "It's a classic tie and an instance of full line forcing: If a phone manufacturer wants any of the apps Google offers, it must take the others also."
The timing of this revelation is interesting, as European Union (EU) antitrust officials, having accepted a settlement of Google's sweeping antitrust charges related to search, are now investigating Android. I've alleged that Google has effectively "dumped" Android in the market—selling or licensing the mobile OS below cost, or at no cost, in order to quickly gain market share and illegally harm competition—but these documents reveal a new layer of wrongdoing: Google's agreements with hardware makers also come with important and potentially illegal strings attached.
With an ever-rising 80 percent market share in smartphones and 62 percent in tablets, Google is the dominant mobile computing platform and the obvious heir apparent to Windows, which still dominates the PC world. But there are many questions swirling around Android, including multiple accusations of intellectual property and design theft. Many believe that Android's dominance has come both unfairly and illegally.
The leaked documents hint at how Google monetizes something that is ostensibly free (not to mention "open," which it is not): Google requires hardware makers to agree to a Mobile Application Distribution Agreement, previously undisclosed publicly, that numerous Google mobile apps must be preinstalled on devices, that Google Search must be set as the default search provider, and that Search and Play Store icons must appear "immediately adjacent" to the home screen, with the other Google apps appearing no more than one screen swipe away. Because search is the main conduit for Google's only actual source of revenues—advertising—much of an Android user's daily activities feeds the Google financial engine.
In case it's not obvious, an intentional side effect of these requirements is that it places Google competitors, including Microsoft's Bing, at a disadvantage. And the only way to avoid the Mobile Application Distribution Agreement is to replace key Google services and create your own mobile app store—prospects that are obviously difficult and expensive, and beyond the capabilities of most companies. (Only Amazon has done so, and its store is a tiny fraction of the size of Google's.) Thus, Android licensees are locked into Google's web, as are Android users.
Professor Edelman ably explains how this practice harms everyone but Google: its partners, its competitors, and consumers. Even if a phone maker believes a competing mapping or search provider is better for consumers, they can't use it without losing access to all of the other Google services that make Android usable. This agreement "surpresses competition," he writes, because "alternative vendors of search, maps, location, email, and other apps cannot outcompete Google on merit even if a competitor offers an app that's better than Google's offering." And "consumers do not benefit when Google prevents phone manufacturers from installing apps in whatever combination consumers prefer."
Most chillingly, this product tying gives Google's weaker and otherwise uncompetitive services—Google Checkout, Google+, Google Shopping, Google Products, and so on—artificial prominence that could over time drive out the products and services that legally established themselves in their respective markets.
He cites Google Checkout as an example.
"Reaching users a decade after Paypal and competing with Paypal's huge user base, by ordinary measures Checkout should have been entirely stillborn," Edelman notes. "Indeed, Checkout's growth has been slow. But what would have happened if, rather than featuring a special logo only for AdWords advertisers who joined Checkout, Google had shown such logos for all popular payment intermediaries? Surely equal treatment of Checkout versus competitors would have reduced Checkout's adoption and harmed Checkout's relative prospects. Yet equal treatment would have provided consumers with timely and actionable information, and would have facilitated genuine competition on the merits."
That's Android, folks: everything that antitrust regulators complained about with Windows, but worse. And as a reminder, Microsoft was originally threatened with a breakup order in the United States for its own anticompetitive behavior. I'm curious to see what antitrust regulators think of this hairball. ###
- Eric -
|RecommendKeepReplyMark as Last Read|
|From: zax||2/23/2014 1:53:26 PM|
|Firefox OS grows up with bigger, better phones and much faster software |
By Vlad Savov on February 23, 2014 10:54 am
ZTE, Huawei, Alcatel, and LG have all brought Firefox OS devices to this year's Mobile World Congress, with the latest generation of both software and hardware looking much more mature, complete, and potentially compelling. Whereas the very first Firefox OS phones had tiny screens with horrible displays and intolerable lag, the 2014 editions are much smoother in operation and more attractive in look and feel. Alcatel is leading the charge with three new handsets and a Fire 7 tablet, while ZTE is introducing the Open C and Open II phones.
Mozilla is aiming for a $25 smartphone
Handling the new devices with the latest version of the platform is like a night and day experience compared to prior Firefox OS smartphones. Apps open up much quicker, there is little to no input lag, and the browser is something that is actually usable for viewing websites on the go. Underpinning Firefox OS' on-device search is EverythingMe, which provides contextual results from the device and the web when you search for something like music.
The ZTE Open C's display is much larger and higher resolution than we've seen on Firefox OS phones before, and while it won't give a high-end Android phone anything to worry about, it does at least feel modern enough to be called a smartphone. Overall, the whole platform feels as if it's grown up a lot in the past year, and Firefox has addressed many of the performance complaints we had at its initial launch.
|RecommendKeepReplyMark as Last ReadRead Replies (1)|
|From: Eric L||5/17/2014 3:27:49 PM|
|Patent Peace? Google & Apple ...|
Apple and Google have reportedly asked a federal judge to dismiss all patent litigation between the two companies after four years of legal battles.
Reuters discovered filings posted on Friday in a Washington federal appeals court requesting an end to the patent war. The myriad of legal spats were consolidated into a single action back in 2012, and Friday's filing makes it clear that that battle is now over.
"Apple and Google have agreed to dismiss all the current lawsuits that exist directly between the two companies," the companies said in a joint statement.
"Apple and Google have also agreed to work together in some areas of patent reform. The agreement does not include a cross license."
Thus ends one of the most rancorous chapters in the patent wars currently being fought in courts around the world. Apple took on Motorola in 2010 as part of Steve Jobs' "thermonuclear war" against Android, with the Apple boss vowing to "spend my last dying breath if I need to."
A year later and he was gone, but Tim Cook and Apple's army of lawyers carried on the fight. Google bought Motorola in 2012, adding some much needed legal protection to the struggling smartphone vendor, and the Chocolate Factory and Apple have been duking it out in the courts ever since.
Judging from the carefully worded statement, this isn't the end of Apple's patent battles. It looks likely that Cupertino will carry on suing its competitors that use Google's operating system, unless some other deal can be struck with vendors such as Samsung.
That looks unlikely. Apple is currently beating Samsung like a red-headed stepchild in the courts, and secured a $120m judgment against the company earlier this month – although that is under appeal.
That sounds good, but the size of the settlement will barely cover Apple's legal bills in the case, and does nothing to stop Samsung from carrying on selling its Android-powered smartphones and fondleslabs.
It may be that Tim Cook, ever a man with an eye on the bottom line, has decided that going up against Google in court would be too expensive and show little financial benefit to Apple in the long term.
Those of you with seismology equipment may want to listen in California for the rumbling sound of Steve Jobs hitting 200rpm in his unmarked grave. ®
- Eric -
|RecommendKeepReplyMark as Last Read|
|From: zax||6/2/2014 10:22:52 AM|
|"The Samsung Z will no doubt help to boost the Tizen operating system though. Samsung already has Tizen-based devices in the market, after it used the operating system for its smartwatches — the Gear 2 and Gear 2 Neo – and just announced plans to introduce a Tizen-based SDK for smart TV products next month, but seeing it compete on smartphones will be a key test for the new operating system."|
The Samsung Z is the world’s first Tizen smartphone, will go on sale in Russia in Q3 2014
Samsung has finally announced the world’s first Tizen smartphone, the Samsung Z. It will be available in Russia in the third quarter of this year, and Samsung says there are plans to expand it to other markets.
Other than being equipped with the new Linux-based mobile operating system, the Samsung Z comes with a 4.8-inch Super AMOLED display and is powered by a 2.3GHz quad-core processor and a 2600mAh battery. It also comes with a built-in fingerprint sensor, which Samsung first introduced in its Galaxy S5 flagship. The Samsung Z has an eight-megapixel rear camera and a 2.1-megapixel front-facing camera, while it also supports 2D and 3D graphics, and boasts a better scrolling experience and improved rendering performance for web browsing.
Read the rest here: thenextweb.com
|RecommendKeepReplyMark as Last Read|
|From: Eric L||6/6/2014 11:58:14 PM|
|The Sprint/T-Mobile USA deal ... |
>> Sprint deal with T-Mobile USA nearing completion
June 5, 2014
A widely expected deal that will see US operator Sprint acquire its competitor T-Mobile USA is nearing completion, according to a number of reports citing inside sources. News agency Bloomberg said that an agreement on the price, capital structure and termination fee is close and that the deal would value T-Mobile at $40/share, or roughly $31bn. At the time of writing T-Mobile USA was trading at $35.20. The agency suggested a deal could be announced in July.
Such a deal would create an operator with the same scale as market leaders Verizon Wireless and AT&T. A combined Sprint-T-Mobile would have 103.53 million customers according to the latest figures from Informa’s WCIS Plus.
In May it was reported by the Wall Street Journal that German incumbent and T-Mobile parent Deutsche Telekom (DT) was demanding a $1bn break-up fee be written into any deal with Sprint, which is majority owned by Japan’s Softbank. The payment, from Sprint to Deutsche Telekom, would be required should an agreed deal be derailed; perhaps blocked by regulatory or competition authorities.
DT’s enthusiasm for the pre-nup is based on rewarding experience. In 2011 it walked away from the collapsed $39bn takeover of T-Mobile USA by AT&T with $3bn in cash, substantial spectrum assets and a favourable roaming agreement. It was able to invest that sum into its network and has performed well in subscriber terms since.
And yet the firm’s financial performance has not reflected this trajectory. In Q1 this year, despite claiming to have taken “virtually all of the industry phone growth” in the period, T-Mobile USA posted a $154m loss, down from a $106m profit for the same period in 2013. The firm cited increased customer acquisition costs as having a significant impact on its bottom line.From June 2012 to March 2014 the operator increased its subscriber base by 48 per cent, from 33.17 million to 49.08 million, according to figures from Informa’s WCIS Plus. Over the same period Sprint’s subscriber base dropped by 2.8 per cent to 54.45 million, while AT&T’s grew 10.3 per cent to 116.04 million and Verizon Wireless’ by 9.8 per cent to 121.29 million. ###
- Eric -
|RecommendKeepReplyMark as Last ReadRead Replies (1)|