OR Google Play, a digital application distribution platform for Android (the former Android Market) and an online electronics and digital media store, is still to catch up with the Apple iOS App Store in terms of top apps and revenue but coming on par with it in terms of downloads
Half of top iPad apps either unavailable or not optimized on Android [Canalys press release, Aug 14, 2013] – 30% of the top 50 free and paid iPad apps in the US are absent from Google Play
The top 20 app lists referenced in the Canalys press release, ‘Half of top iPad apps either unavailable or not optimized on Android’ (published 14 August 2013). You can dowload the full top 50 app lists HERE.
New Canalys’ App Interrogator research highlights one of the deficiencies of the Android ecosystem: limited availability of high-quality, tablet-optimized apps in the Google Play store. Of the top 50 paid and free iPad apps in Apple’s US App Store, based on aggregated daily rankings in the first half of 2013, 30% were absent from Google Play. A further 18% were available, but not optimized for tablet users, offering no more than a smart phone app blown up to the size of a tablet screen.
Just 52% of apps had Android versions both available through Google Play and optimized (if only a little) for tablet use. ‘Quite simply, building high-quality app experiences for Android tablets has not been among many developers’ top priorities to date,’ said Canalys Senior Analyst Tim Shepherd. ‘That there are over 375,000 apps in the Apple App Store that are designed with iPad users in mind, versus just a fraction of this – in the low tens of thousands – available through Google Play, underscores this point.’
Canalys expects this to change as the addressable base of devices continues to soar and Google brings improvements to the Play store, but points out that Google needs to do more to encourage greater numbers of developers to invest in delivering high-quality Android tablet apps quickly, else it risks disappointing consumers with weak app experiences in the short term.
The 52% of top apps available through Google Play and optimized for tablets also includes six titles that appear as top paid titles on iOS, but are only available as free, ad-supported versions on Android. ‘While nominally free, set against a paid version of the app, ad-supported offerings typically deliver a poorer and often more limited user experience, sometimes taking a considerable toll on device battery life and often subjecting users to unskippable videos or other unpopular intrusions,’ said Canalys Analyst Daniel Matte.
It is important that Google wins consumers’ trust and encourages them to register credit cards and billing details, so that the barrier to them spending money on apps – and other content – is reduced at the point of purchase. ‘Improved consumer willingness to spend will increase developers’ monetization potential and options, and help to reduce their reliance on in-app ads, leading over time to an increase in app quality,’ said Matte.
It will also make the Android tablet opportunity more enticing for developers and increase the revenue potential of the Play store and ecosystem for Google. ‘To take the Play ecosystem to the next level, Google needs more than just a large addressable base of devices. App developers need to see clear potential to build robust and sustainable business models around apps built for the platform, so increasing monetization potential must be a priority,’ said Shepherd. ‘And for tablet apps in particular, Google should go further with changes to the Play store to ensure more rigorously managed, high-quality, optimized experiences are highlighted, to the benefit of consumers, and to reward those developers who invest the time and resources in building them with improved discoverability.’
The top 50 lists [of both the “Top 50 paid tablet apps (Apple App Store, H1 2013)” and the “Top 50 free tablet apps (Apple App Store, H1 2013)”]referenced in this release can be viewed here.
Canalys is an independent analyst firm that strives to guide clients on the future of the technology industry and to think beyond the business models of the past. We deliver smart market insights to IT, channel and service provider professionals around the world. Our customer-driven analysis and consulting services empower businesses to make informed decisions and generate sales. We stake our reputation on the quality of our data, our innovative use of technology, and our high level of customer service.
App Store Market Q2 2013: Google Play Exceeds iOS App Store in App Downloads by 10%
Riding strong performances in India and Brazil, Google Play’s total app downloads were higher than those in the iOS App Store in Q2 2013.
Though Google Play had more downloads, the iOS App Store still generated 2.3x the revenue.
Bertrand Schmitt Interview – GigaOM Mobilize 2012 [AppAnnieTV YouTube channel, Oct 10, 2012]
App Annie has released its 2nd quarter mobile platform analysis and reports that Google Play has exceeded the iOS App Store downloads by 10%. While iOS is behind Android in downloads, still generates 2.3 times the revenue.
For iOS, the top countries by number of downloads were: (1) – United States; (2) China; (3) Japan; (4) United Kingdom; and (5) Russia, with the US and China making up around 40% of the market. The top countries by revenue were: (1)United States; (2) Japan; (3) United Kingdom; (4) Australia; and (5)China, with Australia moving to #4 and China dropping to #5 compared to Q1.
For Android, the top countries by download were: (1) United States; (2) South Korea; (3) India; (4) Russia; and (5) Brazil putting three emerging markets (South Korea, Russia, and Brazil) into the top 5. The top countries for revenue were: (1) Japan; (2) South Korea; (3) United States; (4) Germany; and (5) United Kingdom with Germany and the UK swapping spots.
Games have not slowed down and are still at the top of revenue and download charts for both iOS and Android.
For iOS, the top countries by app category downloads were: (1) Games; (2) Entertainment; (3) Photo & Video: (4) Lifestyle and (5) Utilities with games garnering 40% of downloads. The top iOS revenue by category were: (1) Games; (2) Social Networking; (3) Music; (4) Productivity; and (5) Entertainment with games taking almost a 75% share.
For Android, the top countries by app category downloads were: (1) Games; (2) Communication; (3) Tools; (4) Entertainment and (5) Social with communication apps moving up one. The top Android revenue by category were: (1) Games: (2) Communication; (3) Social; (4) Travel and Local; and (5) Tools with games accounting for over 80% of revenue.
The Global App Store Economy – Olivier Bernard, App Annie [Welcome to Nevosoft.Ru YouTube channel, April 4, 2013]
The latest App Annie statistics show that Google GOOG -1.38% has already overtaken iOS in app downloads. This has happened far faster than anyone would have expected even one year ago. One factor here was the massive surge in Android app downloads in Japan and South Korea in 1Q 2013. What finally pushed Google into lead was another surge in India and Russia during 2Q 2013. Russia and Brazil have become Top Five countries for Google Play app download volume, which bodes well for future growth of the platform.
On app revenue front, iOS still leads Google Play by 130%. Yet even this lead has been shrinking rapidly – less than two years ago, the iOS lead was more than 400%. It now seems that it will be only a matter of time before Google will overtake iOS in revenue generation. The key here is the flood of cheap Android models that have started dominating the smartphone markets of China, India, Russia and Brazil, the most important growth engines of the global smartphone industry.
Much now depends on h0w low Apple AAPL +2.42% will price the new budget iPhone. Apple may value its hardware margins highly, but app market leadership is exceptionally important in attracting the best app developer talent and thus ensuring long term success of the entire OS ecosystem. Apple clearly needs to hit Google hard in Latin America, India and China before Android app market takes over these regions decisively.
More at: http://blog.appannie.com/app-annie-index-market-q2-2013/ [July 31, 2013]
Global Trends in App Store Monetization | Junde YU [CasualConnect YouTube channel, June 5, 2013]
Month Report Webinar: A Granular App Level Look at Revenues: Google Play vs Apple App Store [distimo YouTube channel, June 7, 2013]
Google Play Revenue Up 67% Over Past 6 Months, Fueled By Japan & S. Korea [TechCrunch, Aug 12, 2013]
Google’s Android app marketplace, Google Play, has seen significant revenue growth this year, fueled in large part by Japan and South Korea. In a new report released today by app store analytics firm Distimo, the company found that Google Play’s revenue grew by 67 percent over the past six months, while Apple’s App Store revenue grew by just 15 percent during the same time frame.
While these numbers reflect the impact Android’s massive market share is having on the app industry, it’s worth noting that of the two app stores, the Apple App Store’s market is still the largest, and continues to see more than two times the revenue of Google Play.
That latter figure varies a bit from an earlier report put out by competing analytics firm App Annie in April, which found that Apple’s App Store earned around 2.6 times more revenue in the preceding quarter. But not only do the firms’ methodologies differ in general, Distimo looked at the earnings of all ranked apps in the 18 largest countries over 6 months, while App Annie’s data was, as noted above, for the quarter.
That being said, Google Play’s revenue growth is notable. While only 25 percent of the revenue from the two stores combined came from Google Play in February 2013, this went up 8 percentage points to reach 33 percent by July.
Tanisha Gupta Discusses Distimo’s Mobile Conversion Tracking Technology [TheMailDotCom1 YouTube channel, Aug 2, 2013]
Celebrating Google Play’s first birthday [Official Android Blog, March 6, 2013]
Accessing digital entertainment should be simple, whether you like to read books on your tablet, listen to music on your phone and computer, or watch movies on all three. That’s why one year ago today we launched Google Play, where you can find and enjoy your favorite music, movies, books and apps on your Android phone and tablet, or on the web.
Google Play has grown rapidly in the last year, bringing you more content in more languages and places around the globe. In addition to offering more than 700,000 apps and games, we’ve partnered with all of the major music companies, movie studios and publishers to bring you the music, movies, TV shows, books and magazines you love. And we’ve added more ways for you to buy them, including paying through your phone bill and gift cards, which we’re beginning to roll out in the U.K. this week.
Since no birthday is complete without presents, we’re celebrating with a bunch of special offers across the store on songs, TV shows, movies and books. We’re even offering a collection of games with some fun birthday surprises created by developers.
It’s been a busy year, but we’re just getting started. We look forward to many more years of bringing you the best in entertainment!
Introducing Google Play: All your entertainment, anywhere you go [Google Official Blog, March 6, 2012]
Entertainment is supposed to be fun. But in reality, getting everything to work can be the exact opposite—moving files between your computers, endless syncing across your devices, and wires…lots of wires. Today we’re eliminating all that hassle with Google Play, a digital entertainment destination where you can find, enjoy and share your favorite music, movies, books and apps on the web and on your Android phone or tablet. Google Play is entirely cloud-based so all your music, movies, books and apps are stored online, always available to you, and you never have to worry about losing them or moving them again.
Introducing Google Play [googleplay YouTube channel, March 6, 2012]Your favorite entertainment is now all in one place, always accessible on the web and across your Android devices.
With Google Play you can:
- Store up to 20,000 songs for free and buy millions of new tracks
- Download more than 450,000 Android apps and games
- Browse the world’s largest selection of eBooks
- Rent thousands of your favorite movies, including new releases and HD titles
Starting today, Android Market, Google Music and the Google eBookstore will become part of Google Play. On your Android phone or tablet, we’ll be upgrading the Android Market app to the Google Play Store app over the coming days. Your videos, books and music apps (in countries where they are available) will also be upgraded to Google Play Movies, Google Play Books and Google Play Music apps. The music, movies, books and apps you’ve purchased will continue to be available to you through Google Play—simply log in with your Google account like always.
To celebrate, we’ll be offering a different album, book, video rental and Android app at a special price each day for the next week in our “7 Days to Play” sale. In the U.S., today’s titles include the collection of top 40 hits Now That’s What I Call Music 41, the popular game Where’s My Water, the novel Extremely Loud and Incredibly Close and the movie Puncture for just 25 cents each. In addition, you’ll find great collections of hip-hop, rock and country albums for $3.99 all week, detective novels from $2.99, some of our editorial team’s favorite movies from 99 cents, and our favorite apps from 49 cents.
In the U.S., music, movies, books and Android apps are available in Google Play. In Canada and the U.K., we’ll offer movies, books and Android apps; in Australia, books and apps; and in Japan, movies and apps. Everywhere else, Google Play will be the new home for Android apps. Our long-term goal is to roll out as many different types of content as possible to people around the world, and we’ll keep adding new content to keep it fresh.
To learn more, head over to play.google.com/about or keep up with the latest on our Google+ page. If you’re headed to Austin later this week for South by Southwest, come to the Google Village to see Google Play in action. We can’t wait for you to try Google Play and experience a simpler way to manage your entertainment.
Posted by Jamie Rosenberg, Director of Digital Content
Android Apps on Google Play [googleplay YouTube channel, March 6, 2012]
Supported devices [Android Developer Help, Aug 5, 2013]
The following is a list of devices that are supported for use with Google Play. This list is sorted alphabetically by manufacturer. You can also search within this page to find your device (PC: Ctrl + F, Mac: Command + F).
If you’re experiencing issues with the Google Play website or the Google Play app, please verify that your device is included on the list below. If your device isn’t listed, it’s possible that your device is newly released or may not be listed for other reasons. If you need further information on whether your device is supported for use with Google Play, please contact your device manufacturer for further support.
Note: Some devices are listed by their official model number. To find your model number, go to Settings > About Phone > Model Number on your device.
This list was last updated on 8/5/2013.
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
Google Apps on Android [GApps] [Google site, created on June 27, 2012]
Quickly & easily find what you need on the web & your phone or tablet.
Browse fast & bring your personalized Chrome with you.
Never get lost as you go to new places & old favorites.
Stay connected and share life as it happens.
Read the books you love, everywhere you are.
Read your favorite magazines, everywhere you are.
Play your music instantly, anywhere.
Watch movies & TV shows instantly, anywhere.
Millions of videos at your fingertips, available on the go.
One place to create, share, collaborate & keep your stuff, available on all your devices.
Get smarter email wherever you are.
Make your phone your wallet.
Discover, buy and redeem great deals with your Android device.
A Note on Google Apps for Android [Android Developers Blog, Sept 25, 2009]
Lately we’ve been busy bees in Mountain View, as you can see from the recent release of Android 1.6 to the open-source tree, not to mention some devices we’re working on with partners that we think you’ll really like. Of course, the community isn’t sitting around either, and we’ve been seeing some really cool and impressive things, such as the custom Android builds that are popular with many enthusiasts. Recently there’s been some discussion about an exchange we had with the developer of one of those builds, and I’ve noticed some confusion around what is and isn’t part of Android’s open source code. I want to take a few moments to clear up some of those misconceptions, and explain how Google’s apps for Android fit in.
Everyone knows that mobile is a big deal, but for a long time it was hard to be a mobile app developer. Competing interests and the slow pace of platform innovation made it hard to create innovative apps. For our part, Google offers a lot of services — such as Google Search, Google Maps, and so on — and we found delivering those services to users’ phones to be a very frustrating experience. But we also found that we weren’t alone, so we formed the Open Handset Alliance, a group of like-minded partners, and created Android to be the platform that we all wished we had. To encourage broad adoption, we arranged for Android to be open-source. Google also created and operates Android Market as a service for developers to distribute their apps to Android users. In other words, we created Android because the industry needed an injection of openness. Today, we’re thrilled to see all the enthusiasm that developers, users, and others in the mobile industry have shown toward Android.
With a high-quality open platform in hand, we then returned to our goal of making our services available on users’ phones. That’s why we developed Android apps for many of our services like YouTube, Gmail, Google Voice, and so on. These apps are Google’s way of benefiting from Android in the same way that any other developer can, but the apps are not part of the Android platform itself. We make some of these apps available to users of any Android-powered device via Android Market, and others are pre-installed on some phones through business deals. Either way, these apps aren’t open source, and that’s why they aren’t included in the Android source code repository. Unauthorized distribution of this software harms us just like it would any other business, even if it’s done with the best of intentions.
I hope that clears up some of the confusion around Google’s apps for Android. We always love seeing novel uses of Android, including custom Android builds from developers who see a need. I look forward to seeing what comes next!
Compatibility Test Suite [Frequently Asked Questions | Android Open Source, created on May 24, 2010; excerpted on Aug 15, 2013]
Compatibility Test Suite
What is the purpose of the CTS?
The Compatibility Test Suite is a tool used by device manufacturers to help ensure their devices are compatible, and to report test results for validations. The CTS is intended to be run frequently by OEMs throughout the engineering process to catch compatibility issues early.
What kinds of things does the CTS test?
The CTS currently tests that all of the supported Android strong-typed APIs are present and behave correctly. It also tests other non-API system behaviors such as application lifecycle and performance. We plan to add support in future CTS versions to test “soft” APIs such as Intents as well.
Will the CTS reports be made public?
Yes. While not currently implemented, Google intends to provide web-based self-service tools for OEMs to publish CTS reports so that they can be viewed by anyone. CTS reports can be shared as widely as manufacturers prefer.
How is the CTS licensed?
The CTS is licensed under the same Apache Software License 2.0 that the bulk of Android uses.
Does the CTS accept contributions?
Yes please! The Android Open-Source Project accepts contributions to improve the CTS in the same way as for any other component. In fact, improving the coverage and quality of the CTS test cases is one of the best ways to help out Android.
Can anyone use the CTS on existing devices?
The Compatibility Definition Document requires that compatible devices implement the ‘adb’ debugging utility. This means that any compatible device — including ones available at retail — must be able to run the CTS tests.
Compatibility [Frequently Asked Questions | Android Open Source, created on May 24, 2010; excerpted on Aug 15, 2013]
What does “compatibility” mean?
We define an “Android compatible” device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.
In other words, compatibility is a prerequisite to participate in the Android apps ecosystem. Anyone is welcome to use the Android source code, but if the device isn’t compatible, it’s not considered part of the Android ecosystem.
What is the role of Google Play in compatibility?
Devices that are Android compatible may seek to license the Google Play client software. This allows them to become part of the Android app ecosystem, by allowing users to download developers’ apps from a catalog shared by all compatible devices. This option isn’t available to devices that aren’t compatible.
What kinds of devices can be Android compatible?
The Android software can be ported to a lot of different kinds of devices, including some on which third-party apps won’t run properly. The Android Compatibility Definition Document (CDD) spells out the specific device configurations that will be considered compatible.
For example, though the Android source code could be ported to run on a phone that doesn’t have a camera, the CDD requires that in order to be compatible, all phones must have a camera. This allows developers to rely on a consistent set of capabilities when writing their apps.
The CDD will evolve over time to reflect market realities. For instance, the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit telephony hardware, allowing for non-phone devices such as tablet-style music players to be compatible. As we make these changes, we will also augment Google Play to allow developers to retain control over where their apps are available. To continue the telephony example, an app that manages SMS text messages would not be useful on a media player, so Google Play allows the developer to restrict that app exclusively to phone devices.
If my device is compatible, does it automatically have access to Google Play and branding?
Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. Device manufacturers should contact Google to obtain access to Google Play.
If I am not a manufacturer, how can I get Google Play?
Google Play is only licensed to handset manufacturers shipping devices. For questions about specific cases, contact firstname.lastname@example.org.
How can I get access to the Google apps for Android, such as Maps?
The Google apps for Android, such as YouTube, Google Maps and Navigation, Gmail, and so on are Google properties that are not part of Android, and are licensed separately. Contact email@example.com for inquiries related to those apps.
Is compatibility mandatory?
No. The Android Compatibility Program is optional. Since the Android source code is open, anyone can use it to build any kind of device. However, if a manufacturer wishes to use the Android name with their product, or wants access to Google Play, they must first demonstrate that the device is compatible.
How much does compatibility certification cost?
There is no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone to use to test a device.
How long does compatibility take?
The process is automated. The Compatibility Test Suite generates a report that can be provided to Google to verify compatibility. Eventually we intend to provide self-service tools to upload these reports to a public database.
Who determines what will be part of the compatibility definition?
Since Google is responsible for the overall direction of Android as a platform and product, Google maintains the Compatibility Definition Document for each release. We draft the CDD for a new Android version in consultation with a number of OEMs, who provide input on its contents.
How long will each Android version be supported for new devices?
Since Android’s code is open-source, we can’t prevent someone from using an old version to launch a device. Instead, Google chooses not to license the Google Play client software for use on versions that are considered obsolete. This allows anyone to continue to ship old versions of Android, but those devices won’t use the Android name and will exist outside the Android apps ecosystem, just as if they were non-compatible.
Can a device have a different user interface and still be compatible?
The Android Compatibility Program focuses on whether a device can run third-party applications. The user interface components shipped with a device (such as home screen, dialer, color scheme, and so on) does not generally have much effect on third-party apps. As such, device builders are free to customize the user interface as much as they like. The Compatibility Definition Document does restrict the degree to which OEMs may alter the system user interface for areas that do impact third-party apps.
When are compatibility definitions released for new Android versions?
Our goal is to release new versions of Android Compatibility Definition Documents (CDDs) once the corresponding Android platform version has converged enough to permit it. While we can’t release a final draft of a CDD for an Android software version before the first flagship device ships with that software, final CDDs will always be released after the first device. However, wherever practical we will make draft versions of CDDs available.
How are device manufacturers’ compatibility claims validated?
There is no validation process for Android device compatibility. However, if the device is to include Google Play, Google will typically validate the device for compatibility before agreeing to license the Google Play client software.
What happens if a device that claims compatibility is later found to have compatibility problems?
Typically, Google’s relationships with Google Play licensees allow us to ask them to release updated system images that fix the problems.
The Benefits & Importance of Compatibility [Official Android Blog, Sept 15, 2012]
We built Android to be an open source mobile platform freely available to anyone wishing to use it. In 2008, Android was released under the Apache open source license and we continue to develop and innovate the platform under the same open source license — it is available to everyone at: http://source.android.com. This openness allows device manufacturers to customize Android and enable new user experiences, driving innovation and consumer choice.
As the lead developer and shepherd of the open platform, we realize that we have a responsibility to app developers — those who invested in the platform by adopting it and building applications specifically for Android. These developers each contribute to making the platform better — because when developers support a platform with their applications, the platform becomes better and more attractive to consumers. As more developers build great apps for Android, more consumers are likely to buy Android devices because of the availability of great software content (app titles like Fruit Ninja or Google Maps). As more delighted consumers adopt Android phones and tablets, it creates a larger audience for app developers to sell more apps. The result is a strategy that is good for developers (they sell more apps), good for device manufacturers (they sell more devices) and good for consumers (they get more features and innovation).
In biological terms, this is sometimes referred to as an ecosystem. In economic terms, this is known as a virtuous cycle — a set of events that reinforces itself through a feedback loop. Each iteration of the cycle positively reinforces the previous one. These cycles will continue in the direction of their momentum until an external factor intervenes and breaks the cycle.
When we first contemplated Android and formed the Open Handset Alliance, we wanted to create an open virtuous cycle where all members of the ecosystem would benefit. We thought hard about what types of external factors could intervene to weaken the ecosystem as a whole. One important external factor we knew could do this was incompatibilities between implementations of Android. Let me explain:
Imagine a hypothetical situation where the platform on each phone sold was just a little bit different. Different enough where Google Maps would run normally on one phone but run terribly slow on another. Let’s say, for sake of example, that Android implemented an API that put the phone to sleep for a fraction of a second to conserve battery life when nothing was moving on the screen. The API prototype for such a function might look like SystemClock.sleep(millis) where the parameter “millis” is the number of milliseconds to put the device to sleep for.
If one phone manufacturer implemented SystemClock.sleep() incorrectly, and interpreted the parameter as Seconds instead of Milliseconds, the phone would be put to sleep a thousand times longer than intended! This manufacturer’s phone would have a terrible time running Google Maps. If apps don’t run well across devices due to incompatibilities, consumers would leave the ecosystem, followed by developers. The end of the virtuous cycle.
We have never believed in a “one size fits all” strategy, so we found a way to enable differentiation for device manufactures while protecting developers and consumers from incompatibilities by offering a free “compatibility test suite” (CTS). CTS is a set of software tools that tests and exercises the platform to make sure that (for example) SystemClock.sleep(millis) actually puts the device to sleep for only milliseconds. Like Android, the test suite is freely available to everyone under the Apache open source license: http://source.android.com/compatibility/cts-intro.html
While Android remains free for anyone to use as they would like, only Android compatible devices benefit from the full Android ecosystem. By joining the Open Handset Alliance, each member contributes to and builds one Android platform — not a bunch of incompatible versions. We’re grateful to the over 85 Open Handset Alliance members who have helped us build the Android ecosystem and continue to drive innovation at an incredible pace. Thanks to their support the Android ecosystem now has over 500 million Android-compatible devices and counting!
Posted by Andy Rubin, Senior Vice President of Mobile and Digital Content
On Android Compatibility [Android Developers Blog, May 31, 2010]
[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]
At Google I/O 2010, we announced that there are over 60 Android models now, selling 100,000 units a day. When I wear my open-source hat, this is exciting: every day the equivalent of the entire population of my old home city starts using open-source software, possibly for the first time. When I put on my hat for Android Compatibility, this is humbling: that’s a whole lotta phones that can all share the same apps.
Another thing we launched at Google I/O was an upgraded and expanded source.android.com. The new version has refreshed info on the Android Open-Source Project, and some new tips and tools for device manufacturers — useful if you’re an OEM. However, it also has details on the Android compatibility program, now. This is also aimed mostly at OEMs, but Tim Bray suggested that developers might be interested in a peek at how we keep those 100,000 devices marching to the same beat, every day. So here I am, back on the blog.
The F-word, or, Remember remember the fifth of November
I remember sitting with my colleagues in a conference room in Building 44 on November 5, 2007, listening to Andy Rubin and Eric Schmidt announce Android to the world. I remember a lot of the press stories, too. For instance, Android was “just words on paper” which was especially entertaining since I knew we were getting ready to launch the first early-look SDK a mere week later.
Another meme I remember is… yes, “fragmentation”. Literally before the close of business on the same day we announced Android (4:46pm to be precise), I saw the first article about Android “fragmentation.” The first day wasn’t even over yet, and the press had already decided that Android would have a “fragmentation” problem.
The thing is, nobody ever defined “fragmentation” — or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to “locked down” devices, or even to the existence of multiple versions of the software at the same time. I’ve even seen it used to refer to the existence of different UI skins. Most of these definitions don’t even have any impact on whether apps can run!
Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.
Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.
We define “Android compatibility” to be the ability of a device to properly run apps written with the Android SDK. This is a deceptively simple way to frame it, because there are a number of things that can go wrong. Here are a few:
Bugs – devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.
Missing components – devices might omit hardware (such as a camera) that apps expect, and attempt to “fake” or stub out the corresponding API.
Added or altered APIs – devices might add or alter APIs that aren’t part of standard Android. Done correctly this is innovation; done poorly and it’s “embrace and extend”.
Each of these is an example of something that can make an app not run properly on a device. They might run, but they won’t runproperly. These are the things that I spend my time preventing.
How It Works
As stewards of the platform we realize that it’s vital to allow only compatible devices to participate in the Android ecosystem. So, we make compatibility a strict prerequisite for access to Android Market and the right to use the Android name. This means that developers can rely on the fact that Android Market — the keystone of the Android ecosystem — will only allow their apps to run on compatible devices. It’s pretty self-evident that a single app ecosystem is better than many small ones, so OEMs are generally pretty motivated to ship compatible devices.
But motivation alone doesn’t get us very far without tools to actually ensure compatibility, which is where the Android compatibility program [page created on May 20, 2010] comes in. This program is like a stool with three legs: the Android source code, the Compatibility Definition Document, and the Compatibility Test Suite.
It all starts with the Android source code. Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code. The fact that all Android devices run the same core Android code goes a long way toward making sure those devices all work the same way.
However, this doesn’t solve the problems of missing components or altered APIs, because the source code can always be tweaked. This is where the Compatibility Definition Document (or CDD) comes in. The CDD defines in gory detail exactly what is expected of Android devices. It clearly states, for example, that devices may not omit most components, and that the official Android APIs may not be altered. In a nutshell, the CDD exists to remove ambiguities around what’s required of an Android device.
Of course, none of that overcomes the simple reality of human error — bugs. This is where the Compatibility Test Suite comes in. The CTS is a collection of more than 20,000 test cases that check Android device implementations for known issues. Device makers run the CTS on their devices throughout the development process, and use it to identify and fix bugs early. This helps ensure that the builds they finally ship are as bug-free as possible.
Keeping Up with the Times
We’ve been operating this compatibility process with our OEM partners for over a year now, and it’s largely responsible for those 60+ device models being interoperable. However no process is ever perfect and no test suite is ever 100% comprehensive, and sometimes bugs get through. What happens then?
Well, we have great relationships with our OEMs, and like I said, they’re motivated to be compatible. Whenever we hear about a serious bug affecting apps, we report it to our partners, and they typically prepare a bugfix release and get it out to end users. We will also typically add a test case to the CTS to catch that problem for future devices. It’s an ongoing process, but generally our partners are as interested as we are in the user experience of the devices they sell.
The mobile industry today is “very exciting”, which is code for “changes painfully fast”. We believe that the only way Android will be a success is to keep up with that change, and ultimately drive that change. This means that over time, the CDD will also change. We’ll add new text to handle problem cases we encounter, and the actual requirements will change to accommodate the innovations happening in the field. For example, in the 2.1/Eclair CDD, we tweaked the CDD slightly to make telephony optional, which allows Android to ship compatibly on non-phone handheld devices. Whenever we do this, of course, we’ll make corresponding changes to the Android APIs and Android Market to make sure that your apps are protected from ill effects.
On a somewhat related note, a lot of ink has been spilled on the fact that there are multiple versions of Android out there in users’ hands at the same time. While it’s true that devices without the latest software can’t run some of the latest apps, Android is 100% forward compatible — apps written properly for older versions also run on the newest versions. The choice is in app developers’ hands as to whether they want to live on the bleeding edge for the flashiest features, or stay on older versions for the largest possible audience. And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded.
What It Means for You
All that is great — but what does it mean for developers? Well, we put together a page in the SDK Documentation to explain this, so you should take a look there. But really it boils down to this:
As a developer, you simply decide what features your app requires, and list them in your app’s AndroidManifest.xml.
The Android compatibility program ensures that only compatible devices have access to Android Market.
Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don’t have the features you listed.
There almost certainly will be devices that have access to Android Market that probably weren’t quite what you had in mind when you wrote your app. But this is a very good thing — it increases the size of the potential audience for your app. As long as you accurately list your app’s requirements, we’ll do the rest and make sure that your app won’t be accessible to a device where it won’t run properly. After all, we’re app developers ourselves, and we know how painful it is to deal with users upset about an app not working on a device it wasn’t designed for.
Now, that’s not to say that we think our current solution is perfect — no solution is. But we’re continuously working on improvements to the SDK tools and Android Market to make your life as an Android developer even easier. Keep an eye on this blog and on the Android Market itself for the latest info.
Thanks for reading, and happy coding!
Android Compatibility Downloads [page created on May 19, 2010; content excerpted on Aug 15, 2013]
Thanks for your interest in Android Compatibility! The links below allow you to access the key documents and information.
Thanks for your interest in Android Compatibility! The links below allow you to access the key documents and information.
Android 4.3 is the release of the development milestone code-named Jelly Bean-MR2 [July 24, 2013]. Source code for Android 4.3 is found in the ‘android-4.3_r1’ branch in the open-source tree.
- Android 4.3 Compatibility Definition Document (CDD)
- Android 4.3 R1 Compatibility Test Suite (CTS)
- Android 4.3 R1 CTS Verifier
Android 4.2 is the release of the development milestone code-named Jelly Bean-MR1 [Oct 29, 2012]. Source code for Android 4.2 is found in the ‘android-4.2.2_r1’ branch in the open-source tree.
- Android 4.2 Compatibility Definition Document (CDD)
- Android 4.2 R4 Compatibility Test Suite (CTS)
- Android 4.2 R5 CTS Verifier
Android 4.1.1 is the release of the development milestone code-named Jelly Bean [July 23, 2012]. Source code for Android 4.1.1 is found in the ‘android-4.1.1_r1’ branch in the open-source tree.
- Android 4.1 Compatibility Definition Document (CDD)
- Android 4.1 R3 Compatibility Test Suite (CTS)
- Android 4.1 R6 CTS Verifier
Android 4.0.3 is the release of the development milestone code-named Ice Cream Sandwich [Dec 16, 2011]. Android 4.0.3 is the current version of Android. Source code for Android 4.0.3 is found in the ‘android-4.0.3_r1’ branch in the open-source tree.
- Android 4.0 Compatibility Definition Document (CDD)
- Android 4.0.3 R3 Compatibility Test Suite (CTS)
- Android 4.0.3 R2 CTS Verifier
Android 2.3 is the release of the development milestone code-named Gingerbread [Dec 6, 2010]. Source code for Android 2.3 is found in the ‘gingerbread’ branch in the open-source tree.
- Android 2.3 Compatibility Definition Document (CDD)
- Android 2.3 R13 Compatibility Test Suite (CTS)
- Android 2.3 R3 CTS Verifier
Android 2.2 is the release of the development milestone code-named FroYo [May 20, 2010]. Source code for Android 2.2 is found in the ‘froyo’ branch in the open-source tree.
Android 2.1 is the release of the development milestone code-named Eclair [Jan 12, 2010]. Source code for Android 2.1 is found in the ‘eclair’ branch in the open-source tree. Note that for technical reasons, there is no compatibility program for Android 2.0 or 2.0.1, and new devices must use Android 2.1.
Android 1.6 was the release of the development milestone code-named Donut [Sept 15, 2009]. Android 1.6 was obsoleted by Android 2.1. Source code for Android 1.6 is found in the ‘donut’ branch in the open-source tree.
Compatibility Test Suite Manual
The CTS user manual is applicable to any CTS version, but CTS 2.1 R2 and beyond require additional steps to run the accessibility tests.
CTS Media Files
These media files are required for the CTS media stress tests.
Older Android Versions
There is no Compatibility Program for older versions of Android, such as Android 1.5 (known in development as Cupcake). New devices intended to be Android compatible must ship with Android 1.6 or later.