Haystack TV is a small six person startup with an ambitious goal: personalize the news. Traditionally, watching news on TV means viewing a list of stories curated by the network. Wouldn’t it be better if you could watch a personalized news channel, based on interesting YouTube stories?

Haystack already had a mobile app, but entering the living room space seemed daunting. Although “Smart TVs” have been on the market for a while, they remain challenging for developers to work with. Many hardware OEMs have proprietary platforms, but Android TV is different. It’s an open ecosystem with great developer resources. Developers can reach millions of users with familiar Android APIs. If you have an existing Android app, it’s easy to bring it to the living room.

Two weeks was all it took for Haystack TV to bring their mobile app to Android TV. That includes building an immersive, cinematic UI (a task greatly simplified by the Android framework). Since launching on Android TV, Haystack TV’s viewership is growing at 40% per month. Previously, users were spending about 40 minutes watching content on mobile per week. Now that’s up to 80 minutes in the living room. Their longest engagements are through Chromecast and Android TV.

Hear from Daniel Barreto, CEO of Haystack TV, on developing for Android TV

Haystack TV’s success on Android TV is a great example of how the Android multi-form factor developer experience shines. Once you’ve learned the ropes of writing Android apps, developing for another form factor (Wear, Auto, TV) is simple.

Android TV helps you create cinematic UIs

Haystack TV’s UI is smooth and cinematic. How were they able to build a great one so quickly? Developing an immersive UI/UX with Android TV is surprisingly easy. The Leanback support library provides fragments for browsing content, showing a details screen, and search. You can use these to get transitions and animations almost for free. To learn more about building UIs for Android TV, watch the Using the Leanback Library DevByte and check out the code samples.

Browsing recommended stories

Your content, front and center

The recommendations row is a central feature of the Android TV home screen. It’s the first thing users see when they turn on their TVs. You can surface content to appear on the recommendations row by implementing the recommendation service. For example, your app can suggest videos your users will want to watch next (say, the next episode in a series, or a related news story). This is great for getting noticed and increasing engagements.

Haystack’s content on the recommendations row

Make your content searchable

How can users find their favorite movie or show from a library of thousands? On Android TV, they can search for it using their voice. This is much faster and more relaxing than typing on the screen with a remote control! In addition to providing in-app search, your app can surface content to appear on the global search results page. The framework takes care of speech recognition for you and delivers the result to your app as a plain text string.

Next Steps

Android TV makes it possible for small startups to create apps for the living room. There are extensive developer resources. For an overview, watch the Introduction to Android TV DevByte. For details, see the developer training docs. Watch this episode of Coffee with a Googler to learn more about the vision for the platform. To get started on your app, visit developer.android.com/tv.

Join the discussion on

+Android Developers

By Jamal Eason, Product Manager, Android

Yesterday we announced Android 5.1, an updated version of the Android Lollipop platform that improves stability, provides better control of notifications, and increases performance. As a part of the Lollipop update, we are releasing the Android 5.1 SDK (API Level 22) which supports the new platform and lets you get started with developing and testing.

What's new in Android 5.1?

For developers, Android 5.1 introduces a small set of new APIs. A key API addition is support for multiple SIM cards, which is important for many regions where Android One phones are being adopted. Consumers of Android One devices will have more flexibility to switch between carriers and manage their network activities in the way that works best for them. Therefore you, as a developer, can create new app experiences that take advantage of this new feature.

In addition to the new consumer features, Android 5.1 also enhances enterprise features to better support the launch of Android for Work.

Android 5.1 supports multiple SIM cards on compatible devices like Android One.

Updates for the Android SDK

To get you started with Android 5.1, we have updated the Android SDK tools to support the new platform and its new APIs. The SDK now includes Android 5.1 emulator system images that you can use to test your apps and develop using the latest capabilities and APIs. You can update your SDK through the Android SDK Manager in Android Studio.

For details on the new developer APIs, take a look at the API Overview.

Coming to Nexus devices soon

Over the next few weeks, we’ll be rolling out updates for Android 5.1 to the following Nexus devices: Nexus 4, Nexus 5, Nexus 6, Nexus 7 [2012], Nexus 7 [2012] (3G), Nexus 7 (2013), Nexus 7 [2013] (3G/LTE), Nexus 9, Nexus 9 (LTE), Nexus 10, and Nexus Player.

Next Steps

As with all Android releases, it’s a good idea to test your apps on the new platform as soon as possible. You can get started today using Android 5.1 system images with the emulator that’s included in the SDK, or you can download an Android 5.1 Nexus image and flash the system image to your Nexus device.

If you have not had a chance to update your app to material design, or explore how your app might work on Android Wear, Android TV, or even Android Auto, now is a good time to get started with the Android 5.1 SDK update.

Join the discussion on

+Android Developers

Today, we’re bringing you new tools to build better apps with the rollout of Google Play services 7.0. With this release, we’re delivering improvements to location settings experiences, a brand new API for place information, new fitness data, Google Play Games, and more.

Location Settings Dialog

While the FusedLocationProviderApi combines multiple sensors to give you the optimal location, the accuracy of the location your app receives still depends greatly on what settings are enabled on the device (e.g. GPS, wifi, airplane mode, etc). In Google Play services 7.0, we’re introducing a standard mechanism to check that the necessary location settings are enabled for a given LocationRequest to succeed. If there are possible improvements, you can display a one touch control for the user to change their settings without leaving your app.

This API provides a great opportunity to make for a much better user experience, particularly if location information is critical to the user experience of your app such as was the case with Google Maps when they integrated the Location Settings dialog and saw a dramatic increase in the number of users in a good location state.

Places API

Location can be so much more than a latitude and longitude: the new Places API makes it easy to get details from Google’s database of places and businesses. The built-in place picker makes it easy for the user to pick their current place and provides all the relevant place details including name, address, phone number, website, and more.

If you prefer to provide your own UI, the getCurrentPlace() API returns places directly around the user’s current location. Autocomplete predictions are also provided to allow a low latency search experience directly within your app.

You can also manually add places with the addPlace() API and report that the user is at a particular place, ensuring that even the most explorative users can input and share their favorite new places.

The Places API will also be available cross-platform: in a few days, you’ll be able to apply for the Places API for iOS beta program to ensure a great and consistent user experience across mobile platforms.

Google Fit

Google Fit makes building fitness apps easier with fitness specific APIs on retrieving sensor data like current location and speed, collecting and storing activity data in Google Fit’s open platform, and automatically aggregating that data into a single view of the user’s fitness data.

In Google Play services 7.0, the previous Fitness.API that you passed into your GoogleApiClient has now been replaced with a number of APIs, matching the high level set of Google Fit Android APIs:

• SENSORS_API to access raw sensor data via SensorsApi
• RECORDING_API to record data via RecordingApi
• HISTORY_API for inserting, deleting, or reading data via HistoryApi
• SESSIONS_API for managing sessions via SessionsApi
• BLE_API to interact with Bluetooth Low Energy devices via BleApi
• CONFIG_API to access custom data types and settings for Google Fit via ConfigApi

This change significantly reduces the memory requirement for Google Fit enabled apps running in the background. Like always, apps built on previous versions of Google Play services will continue to work, but we strongly suggest you rebuild your Google Fit enabled apps to take advantage of this change.

Having all the data can be an empowering part of making meaningful changes and Google Fit is augmenting their existing data types with the addition of body fat percentage and sleep data.

Google Play Games

Announced at Game Developers Conference (GDC), we’re offering new tools to supercharge your games on Google Play. Included in Google Play services 7.0 is the Nearby Connections API, allowing games to seamlessly connect smartphones and tablets as second-screen controls to the game running on your TV.

App Indexing

App Indexing lets Google index apps just like websites, enabling Google search results to deep-link directly into your native app. We've simplified the App Indexing API to make this integration even easier for you by combining the existing view()/viewEnd() and action()/end() flows into a single start() and end() API.

Changes to GoogleApiClient

GoogleApiClient serves as the common entry point for accessing Google APIs. For this release, we’ve made retrieval of Google OAuth 2.0 tokens part of GoogleApiClient, making it much easier to request server auth codes to access Google APIs.

SDK Coming Soon!

We will be rolling out Google Play services 7.0 over the next few days. Expect an update to this blog post, published documentation, and the availability of the SDK once the rollout is completed.

To learn more about Google Play services and the APIs available to you through it, visit the Google Services section on the Android Developer site.

Join the discussion on

+Android Developers

Everyone has a gaming-ready device in their pocket today. In fact, of the one billion Android users in more than 190 countries, three out of four of them are gamers. This allows game developers to reach a global audience and build a successful business. Over the past year, we paid out more than $7 billion to developers distributing apps and games on Google Play.

At our Developer Day during the Game Developers Conference (GDC) taking place this week, we announced a set of new features for Google Play Games and AdMob to power great gaming. Rolling out over the next few weeks, these launches can help you better measure and monetize your games.

Better measure and adapt to player needs

Google Play Games is a set of services that help game developers reach and engage their audience. To further that effort, we’re introducing Player Analytics, giving developers access to powerful analytics reports to better measure overall business success and understand in-game player behavior. Launching in the next few weeks in the Google Play Developer Console, the new tool will give indie developers and big studios better insight into how their players are progressing, spending, and churning; access to critical metrics like ARPPU and sessions per user; and assistance setting daily revenue targets.

BombSquad, created by a one-person game studio in San Francisco, was able to more than double its revenue per user on Google Play after implementing design changes informed during beta testing Player Analytics.

Optimizing ads to earn the most revenue

After optimizing your game for performance, it’s important to build a smarter monetization experience tailored to each user. That’s why we’re announcing three important updates to the AdMob platform:

• Native Ads: Currently available as a limited beta, participating game developers will be able to show ads in their app from Google advertisers, and then customize them so that users see ads that match the visual design of the game. Atari is looking to innovate on its games, like RollerCoaster Tycoon 4 Mobile, and more effectively engage users with this new feature.
• In-App Purchase House Ads Beta: Game developers will be able to smartly grow their in-app purchase revenue for free. AdMob can now predict which users are more likely to spend on in-app purchases, and developers will be able to show these users customized text or display ads promoting items for sale. Currently in beta, this feature will be coming to all AdMob accounts in the next few weeks.
• Audience Builder: A powerful tool that enables game developers to create lists of audiences based on how they use their game. They will be able to create customized experiences for users, and ultimately grow their app revenue.

New game experiences powered by Google

Last year, we launched Android TV as a way to bring Android into the living room, optimizing games for the big screen. The OEM ecosystem is growing with announced SmartTVs and micro-consoles from partners like Sony, TPVision/Philips and Razer.

To make gaming even more dynamic on Android TV, we’re launching the Nearby Connections API with the upcoming update of Google Play services. With this new protocol, games can seamlessly connect smartphones and tablets as second-screen controls to the game running on your TV. Beach Buggy Racing is a fun and competitive multiplayer racing game on Android TV that plans to use Nearby Connections in their summer release, and we are looking forward to more living room multiplayer games taking advantage of mobile devices as second screen controls.

At Google I/O last June, we also unveiled Google Cardboard with the goal of making virtual reality (VR) accessible to everyone. With Cardboard, we are giving game developers more opportunities to build unique and immersive experiences from nothing more than a piece of cardboard and your smartphone. The Cardboard SDKs for Android and Unity enable you to easily build VR apps or adapt your existing app for VR.

Check us out at GDC

Visit us at the Google booth #502 on the Expo floor to get hands on experience with Project Tango, Niantic Labs and Cardboard starting on Wednesday, March 4. Our teams from AdMob, AdWords, Analytics, Cloud Platform and Firebase will also be available to answer any of your product questions.

For more information on what we’re doing at GDC, please visit g.co/dev/gdc2015.

Join the discussion on

+Android Developers

Google Play now reaches more than 1 billion people on Android devices in more than 190 countries, helping a growing number of developers like you build successful global businesses. In fact, in the past year, we paid more than $7 billion to developers distributing apps and games on Google Play. We remain as committed as ever to making Google Play the best place to find great apps, games and other entertainment.

App discovery plays a critical role in driving your continued success, and over the past year Google has provided best practices to enhance app discovery and engagement, as well as app promotion tools to get the most out of search and display advertising for developers. We are always looking for new ways to help you get your apps in front of potential new users. That’s why, in the next few weeks, we will begin piloting sponsored search results on Google Play, bringing our unique expertise in search ads to the store.

With more than 100 billion searches every month on Google.com, we’ve seen how search ads shown next to organic search results on Google.com can significantly improve content discovery for users and advertisers, both large and small. Search ads on Google Play will enable developers to drive more awareness of their apps and provide consumers new ways to discover apps that they otherwise might have missed.

In the coming weeks, a limited set of users will begin to see ads from a pilot group of advertisers who are already running Google search ads for their apps. We’ll have more to share in the coming months about the expansion of this program as we look at the results and feedback. We believe search ads will be a useful addition to Google Play for users and developers alike, and we hope this will bring even more success to our developer community.

Work doesn’t just happen in an office from 9 to 5 anymore. Today’s workers are mobile workers, and they need to be able to get things done as efficiently and collaboratively as possible, at any time. That’s why the Android for Work initiative is bringing together partners across the ecosystem, from device and app makers to networking and management solutions, to provide businesses with a secure, flexible and reliable mobility platform that users already know and love.

Google Play for Work allows businesses to securely deploy and manage enterprise-grade apps, across all of their users running Android for Work. Google Play for Work simplifies the process of distributing apps to employees and ensures that IT approves every deployed app. For developers, this is an opportunity to reach a new audience at scale through bulk installs or purchasing, which enables easy installation of your app across enterprises.

How to join Google Play for Work

Free apps will be available on Google Play for Work at launch with no action needed on your part. If you have a paid app, you’ll soon be able to opt-in to make your app available for bulk purchase on Google Play for Work in the Developer Console during the app publishing process. Find out more about publishing in the Google Play Developer Help Center.

Designing great apps for Android for Work

Apps that are installed from Google Play for Work will function without code changes. However, please note that some of the controls that Android for Work offers IT admins could affect how your app works. To ensure the best possible experience for your users, watch the first in our series of Android for Work DevBytes below to understand the best practices you should be following in developing your app.

More DevBytes will be posted to our YouTube channel soon. Find out more about Android for Work.

Join the discussion on

+Android Developers

The Game Developers Conference (GDC) is less than one week away in San Francisco. This year we will host our annual Developer Day at West Hall and be on the Expo floor in booth #502. We’re excited to give you a glimpse into how we are helping mobile game developers build successful businesses and improve user experiences.

Our Developer Day will take place in Room 2006 of the West Hall of Moscone Center on Monday, March 2. We're keeping the content action-oriented with a few presentations and lightning talks, followed by a full afternoon of hands on hacking with Google engineers. Here’s a look at the schedule:

Opening Keynote || 10AM: We’ll kick off the day by sharing to make your games more successful with Google. You’ll hear about new platforms, new tools to make development easier, and ways to measure your mobile games and monetize them.

Running A Successful Games Business with Google || 10:30AM: Next we’ll hear from Bob Meese, the Global Head of Games Business Development from Google Play, who’ll offer some key pointers on how to make sure you're best taking advantage of unique tools on Google Play to grow your business effectively.

Lightning Talks || 11:15AM: Ready to absorb all the opportunities Google has to offer your game business? These quick, 5-minute talks will cover everything from FlatBuffers to Google Cast to data interpolation. To keep us on track, a gong may be involved.

Code Labs || 1:30PM: After lunch, we’ll turn the room into a classroom setting where you can participate in a number of self-guided code labs focused on leveraging Analytics, Google Play game services, Firebase and VR with Cardboard. These Code Labs are completely self-paced and will be available throughout the afternoon. If you want admission to the code labs earlier, sign up for Priority Access here!

Also, be sure to check out the Google booth on the Expo floor to get hands on experiences with Project Tango, Niantic Labs and Cardboard starting on Wednesday, March 4. Our teams from AdMob, AdWords, Analytics, Cloud Platform and Firebase will also be available to answer any of your product questions.

For more information on our presence at GDC, including a full list of our talks and speaker details, please visit g.co/dev/gdc2015. Please note that these events are part of the official Game Developer's Conference, so you will need a pass to attend. If you can't attend GDC in person, you can still check out our morning talks on our livestream at g.co/dev/gdc-livestream.

Join the discussion on

+Android Developers

It’s not often that a developer is born from a summer holiday joke and a parent’s love of furniture making. But this is exactly how Vincenzo Colucci started GinLemon, a successful app business on Google Play.

The choice of Android was an obvious one to Vincenzo, although he didn’t have experience with Android development at the start — he learned it by downloading the tools and playing with the examples.

From his original scratch card app, to the global success of Smart Launcher, Vincenzo is proof that great apps can come from personal passion and the willingness to do something a little different.

Find out more about Vincenzo’s journey in this video.

Vincenzo and the team he has built around Smart Launcher are working on a major update, which will be free and they hope to release in March. They also have Smart Locker, a series of lock screens with some unique features, in development and other projects in the pipeline.

To learn about creating apps for Google Play and building your own app business, check out The Secrets to App Success on Google Play [ebook], a detailed playbook on the best practices and tools you can use to maximize the reach, retention, and revenue of your new app.

Join the discussion on

+Android Developers

With so many recent updates and improvements to Android Wear, it's high time to share an updated overview of the platform. We're certainly not done—there's a lot more to come—but this is the picture today as you start or continue developing your groundbreaking Android Wear user experiences.

Guns'n'Glory Heros and Strava

The Android Wear platform emphasizes depth and flexibility. Built on Android, it allows developers to use familiar APIs to create useful, performant, and imaginative apps that run directly on the watch. In the spirit of Android, you have the freedom to make substantial changes to the user experience, including the creation of custom watch faces. There are three main categories of experiences you can build: apps, custom watch faces, and notifications.

Apps

Apps that are built for Android Wear run directly on the watch and can do nearly anything a phone can, from tracking your run to giving you a little entertainment while waiting for the bus. Some even work without a connection to the phone, such as fitness and music apps. There are libraries to help you move data between the phone and the wearable, as well as create stunning and adaptable UIs. Here's a list of some of the great features you have access to:

Selected watch faces

Watch Faces

The ability to create custom watch faces gives you direct access to the most prominent UI element on a user's most personal device. The API is simple enough to build watch faces quickly and flexible enough to allow personalization. Again, given the depth and flexibility of the Android platform, you can create something for the user that's both beautiful and packed with unique features.

The development journey starts with the simplicity of bringing your design to the wrist. At the core of the watch face API is the onDraw method that allows you to draw whatever design you can think of to the canvas at a high enough frame rate to deliver fluid animation. This will come through at full fidelity while the watch is in interactive mode.

At other times, when the watch is in ambient mode, you're able to draw a more discreet version of the watch face. Additional preferences can be set to arrange the system UI elements appropriately for your design. Once those basics are covered, the limits are your imagination! You can go further with additions like the moon phase, current weather, or fitness stats. Watchmakers call these items "complications" -- but with Android they're hardly complicated. Once you have the data, just draw it on the canvas as you did the time.

Glympse and WhatsApp

Notifications

Of course, Android Wear Notifications are the easiest way to get started in the world of wearables. If you've got an Android app with notifications -- they already work on a Wear watch. If you've already enhanced your notification with actions, this is even better and also automatically already works. You can take things further with Wear-specific functionality like Stacks, Pages, and Voice Replies that make your notifications richer experiences on the wrist.

The user experiences you build for Wear get to take advantage of the power and flexibility of the Android platform. It's easy to get started and possible to create truly groundbreaking UI for your users. Together, we can create an ecosystem of user experiences as diverse as the watches they run on and the people who wear them.

Check out the developer videos and documentation for more, and share your thoughts on the Android Wear Developers community. We can’t wait to see the innovative user experiences you will build on Android Wear.

Join the discussion on

+Android Developers

Many Android apps use a WebView for displaying HTML content. In Android 5.0 Lollipop, Google has the ability to update WebView independently of the Android platform. Beginning today, developers can use a new beta channel to test the latest version of WebView and provide feedback.

WebView updates bring numerous bug fixes, new web platform APIs and updates from Chromium. If you’re making use of the WebView in your app, becoming a beta channel tester will give you an early start with new APIs as well as the chance to test your app before the WebView rolls out to your users.

The first version offered in the beta channel will be based on Chrome 40 and you can find a full list of changes on the chromium blog entry.

To become a beta tester, join the community which will enable you to sign up for the Beta program; you’ll then be able to install the beta version of the WebView via the Play Store. If you find any bugs, please file them on the Chromium issue tracker.

Join the discussion on

+Android Developers

The Guardian is a global news organization with one of the world's largest quality English-speaking news websites, theguardian.com. It has more than 100 million monthly unique browsers and app users, two thirds of which come from outside the UK. With a longstanding reputation for agenda-setting journalism, the publication is most recently renowned for its Pulitzer Prize and Emmy-winning coverage of the disclosures made by whistleblower Edward Snowden. The Guardian’s early adoption of a digital-first policy and continued digital innovation means it has also become a respected name among developers and tech audiences. In the last year, it has launched a redesigned app and new website and been among a handful of publishers to develop its own Glassware.

The Guardian app is taking advantage of unique Google Play and Android features to drive user engagement. Their mobile app readers are now 10 to 20 times more engaged than their average web users. Improving engagement has also helped them lift the rating for their app from 4.0 to 4.4 on Google Play.

Anthony Sullivan, Director of Product, and Tom Grinsted, Product Manager, share some best practices for increasing app engagement in this video.

To learn more, be sure to check out these resources to better engage your users:

• Convert installs to active users [video] — hear from Matteo Vallone, Partner Development Manager for Google Play, about the best practices for engaging and retaining users through intents, identity, context, and rich notifications as well as delivering a cross-platform user experience.
• Adding Wearable Features to Notifications [tutorial] — learn how to add notifications to Android Wear devices, including how to make use of the Wear notification features: voice commands, stacks, and pages.
• Beta testing [help] — discover how to make use of the alpha and beta testing features offered by Google Play, and get feedback from real users.
• Build your community (of testers) [guide] — get advice on how to build communities on G+ or other social networks, then tap into their skills and enthusiasm to help with testing your app.

Join the discussion on

+Android Developers

Trulia’s mission is to make it as easy as possible for home buyers, sellers, owners and renters to navigate the real estate market. Originally a website-based company, Trulia is keenly aware that its users are migrating to mobile. Today, more than 50 percent of Trulia’s business comes from mobile and growth shows no sign of slowing, so they know that’s where they need to innovate.

In the following video, Jonathan McNulty, VP of Consumer Product, and Lauren Hirashima, Mobile Product Manager, at Trulia, talked about how the company successfully leveraged notifications on Android to increase app engagement by 30 percent and has seen 2x the amount of engagement on Android relative to other platforms:

Trulia continues to focus on improving their mobile experience, using Google’s geo-fencing technology to create Nearby Home Alerts, which lets users know when they walk near a new listing. Combined with Android Wear, Trulia now makes it possible for users to see details and photos about a property and call or email the agent, all directly from their watch.

Find out more about using rich notifications on Android and developing for Android Wear. And check out The Secrets to App Success on Google Play (ebook) which contains a chapter dedicated to the best practices and tools you can use to increase user engagement and retention in your app.

Join the discussion on

+Android Developers

Rushing onto a train, entering a concert, or simply ordering a coffee, we have all seen users (or ourselves) rummaging through their wallets or mobile app trying to get the right boarding pass, ticket or loyalty card. With Android Wear and a few lines of code in your mobile app, this can all work like magic.

What’s new in the Android Support Library

While QR Code images could be attached to a notification since the first release of the Android Wear platform, developers have asked about two situations which they would like to see improve:

1. With circular displays, it is hard for developer to know if the QR code is displayed in it’s entirety and not cropped.
2. To conserve battery, Android Wear switches off the screen after five seconds of inactivity. However, this makes it hard for the user to ensure that the QR code is still displayed on their wrist when they reach the front of the queue.

With the latest support library, we have added two additional methods to WearableExtender to give developers more control over how background images are displayed in notifications. These new APIs can be used in a number of scenarios, we will focus on the QR code use case in this post:

• Ensure the image is not cropped - setHintAvoidBackgroundClipping(true)
With this new method, developers can ensure that the entire QR code is always visible.

Wrong: setHintAvoidBackgroundClipping (false) // this is the Default	Right: setHintAvoidBackgroundClipping (true)

• Ensure the QR code is still displayed when the user gets to the front of the queue - setHintScreenTimeout(timeInMS)
This new method enables developers to set a timeout that makes sense for their specific use case.

Design Best Practices

We have experimented with a number of customization options with QR codes and here are some of the lessons learnt:

Dos

• Do test with your equipment - Before deploying, test with your QR code readers to ensure that the QR code displayed on the wearable works with your equipment.
• Do use black and white QR codes - This ensures maximum contrasts and makes it easier for the reader to read the information.
• Do display only the core information in the text notification - Remember that less is more. Glanceability is important for wearables.
• Do test with both round and square watches - The amount of text can be displayed on the notification varies especially dependent on the form factor (square and circular).
• Do brand with icon - On the main notification in the Android Wear stream, developers can set a full color icon using setLargeIcon to brand your notification.
• Do convey additional information using background - To achieve an even better result, consider setting context sensitive backgrounds through setBackground, such as a photo of the destination for the train or a picture of the stadium.
• Do use QR codes which are 400x400 pixels or larger - In line with other background images, the recommended minimum size for QR code is 400x400 pixels.

Don'ts

• Do not brand the QR code - The screen real estate is limited on Android Wear and using some of this for branding may result in the QR code not working correctly.
• Do not use anything other than grey or default theme color for notification text - Although Android Wear notifications support basic text formatting such as setting text color, this should be used in moderation with the color set to default or grey. The reason is that the Holo theme for Android 4.x has a default background of black whereas Material Design theme for Android 5+ including Android Wear has a white background. This makes it hard for the colour to work for both themes. Bold and Italic are fine formatting choices.

Android Wear is for people on the move

Using QR codes on Android Wear is a very delightful experience. The information that the user needs is right on their wrist at the right time in the right place. With the new APIs, you can now unlock more doors than ever before and give users an easier time with check in on the go.

Sample code can be downloaded from this repository.

Join the discussion on

+Android Developers

Knowing how your customers use your app is the foundation to keeping them happy and engaged. It’s important to track downloads and user ratings, but the key to building a successful business is using data to dive deeper into understanding the full acquisition funnel and what makes users stick around.

Google Analytics is the easiest way to understand more about what your users are doing inside your app on Google Play, while also simultaneously tracking your users across the web and other mobile platforms. To show how Google Analytics can help, we've created a new "Analyze" section on the Android Developers website for you to check out. We provide guidance on how to design a measurement plan and implement effective in-app analytics – and take advantage of features only available between Google Play and Google Analytics.

Google Analytics for mobile apps provides a comprehensive view into your app’s full user lifecycle, including user acquisition, composition, in app behavior, and key conversions. Our Analytics Academy course on mobile app analytics is also a great resource to learn the fundamentals.

Eltsoft LLC, a foreign language learning and education app developer for Android, recognized early on how impactful Google Analytics would have on the company's ability to quickly improve on its apps and meet user needs.

Analytics has really helped us to track the effectiveness of the changes to our app. I would say six months ago, that our success was a mystery. The data said we were doing well, but the whys were not clear. Therefore, we couldn’t replicate or push forward. But today, we understand what’s happening and can project our future success. We have not only the data, but can control certain variables allowing us to understand that data. - Jason Byrne, Eltsoft LLC

Here are some powerful tips to make the most of Google Analytics:

1. Understand the full acquisition funnel
Uniquely integrated with the Google Play Developer Console, Google Analytics gives you a comprehensive view of the Google Play Referral Flow. By linking Analytics to the Developer Console, you can track useful data on how users move through the acquisition flow from your marketing efforts to the Google Play store listing to the action of launching the app. If you find that a significant number of users browse your app in Google Play, but don’t install it, for example, you can then focus your efforts on improving your store listing.
2. Unlock powerful insights on in-app purchases
Monitoring in-app purchases in the Google Play Developer Console will show you the total revenue your app is generating, but it does not give you the full picture about your paying users. By instrumenting your app with the Google Analytics ecommerce tracking, you’ll get a fuller understanding of what paying users do inside your app. For example, you can find out which acquisition channels deliver users who stay engaged and go on to become the highest value users.
3. Identify roadblocks and common paths with the Behavior Flow
Understanding how users move through your app is best done with in-app analytics. With Google Analytics, you can easily spot if a significant percentage of users leave your app during a specific section. For example, if you see significant drop off on a certain level of your game, you may want to make that level easier, so that more users complete the level and progress through the game. Similarly, if you find users who complete a tutorial stay engaged with your app, you might put the tutorial front and center for first-time users.
4. Segment your audience to find valuable insights
Aggregated data can help you answer questions about overall trends in your app. If you want to unlock deeper insights about what drives your users’ behavior, you can slice and dice your data using segmentation, such as demographics, behavior, or install date. If something changes in one of your key metrics, segmentation can help you get to the root of the issue -- for example, was a recent app update unpopular with users from one geographic area, or were users with a certain device or carrier affected by a bug?
5. Use custom data to measure what matters for your business
Simply activating the Google Analytics library gives you many out-of-the-box metrics without additional work, such as daily and monthly active users, session duration, breakdowns by country, and many more variables. However, it’s likely that your app has many user actions or data types that are unique to it, which are critical to building an engaged user base. Google Analytics provides events, custom dimensions, and custom metrics so you can craft a measurement strategy that fits your app and business.
6. No more one-size-fits-all ad strategy
If you’re a developer using AdMob to monetize your app, you can now see all of your Analytics data in the AdMob dashboard. Running a successful app business is all about reaching the right user with the right ad or product at the right time. If you create specific user segments in Google Analytics, you can target each segment with different ad products. For example, try targeting past purchasers with in-app purchase ads, while monetizing users who don’t purchase through targeted advertising.

By measuring your app performance on a granular level, you will be able to make better decisions for your business. Successful developers build their measurement plan at the same time as building their app in order to set goals and track progress against key success metrics, but it’s never too late to start.

Choose the implementation that works best for your app to get started with Google Analytics today and find out more about what you can do in the new “Analyze” section of developers.android.com.

Join the discussion on

+Android Developers

As you may know, high resolution textures contribute to better graphics and a more impressive game experience. Adaptive Scalable Texture Compression (ASTC) helps solve many of the challenges involved including reducing memory footprint and loading time and even increase performance and battery life.

If you have a lot of textures, you are probably already compressing them. Unfortunately, not all compression algorithms are made equal. PNG, JPG and other common formats are not GPU friendly. Some of the highest-quality algorithms today are proprietary and limited to certain GPUs. Until recently, the only broadly supported GPU accelerated formats were relatively primitive and produced poor results.

With the introduction of ASTC, a new compression technique invented by ARM and standardized by the Khronos group, we expect to see dramatic changes for the better. ASTC promises to be both high quality and broadly supported by future Android devices. But until devices with ASTC support become widely available, it’s important to understand the variety of legacy formats that exist today.

We will examine preferable compression formats which are supported on the GPU to help you reduce .apk size and loading times of your game.

Texture Compression

Popular compressed formats include PNG and JPG, which can’t be decoded directly by the GPU. As a consequence, they need to be decompressed before copying them to the GPU memory. Decompressing the textures takes time and leads to increased loading times.

A better option is to use hardware accelerated formats. These formats are lossy but have the advantage of being designed for the GPU.

This means they do not need to be decompressed before being copied and result in decreased loading times for the player and may even lead to increased performance due to hardware optimizations.

Hardware Accelerated Formats

Hardware accelerated formats have many benefits. As mentioned before, they help improve loading times and the runtime memory footprint.

Additionally, these formats help improve performance, battery life and reduce heating of the device, requiring less bandwidth while also consuming less energy.

There are two categories of hardware accelerated formats, standard and proprietary. This table shows the standard formats:

As you can see, with higher OpenGL support you gain access to better formats. There are proprietary formats to replace ETC1, delivering higher quality and alpha channel support. These are shown in the following table:

That’s a lot of formats, revealing a different problem. How do you choose which format to use?

To best support all devices you need to create multiple apks using different texture formats. The Google Play developer console allows you to add multiple apks and will deliver the right one to the user based on their device. For more information check this page.

When a device only supports OpenGL ES 2.0 it is recommended to use a proprietary format to get the best results possible, this means making an apk for each hardware.

On devices with access to OpenGL ES 3.0 you can use ETC2. The GL_COMPRESSED_RGBA8_ETC2_EAC format is an improved version of ETC1 with added alpha support.

The best case is when the device supports the Android Extension Pack. Then you should use the ASTC format which has better quality and is more efficient than the other formats.

Adaptive Scalable Texture Compression (ASTC)

The Android Extension Pack has ASTC as a standard format, removing the need to have different formats for different devices.

In addition to being supported on modern hardware, ASTC also offers improved quality over other GPU formats by having full alpha support and better quality preservation.

ASTC is a block based texture compression algorithm developed by ARM. It offers multiple block footprints and bitrate options to lower the size of the final texture. The higher the block footprint, the smaller the final file but possibly more quality loss.

Note that some images compress better than others. Images with similar neighboring pixels tend to have better quality compared to images with vastly different neighboring pixels.

Let’s examine a texture to better understand ASTC:

This bitmap is 1.1MB uncompressed and 299KB when compressed as PNG.

Compressing the Android jellybean jar texture into ASTC through the Mali GPU Texture Compression Tool yields the following results.

Block Footprint	4x4	6x6	8x8
Memory	262KB	119KB	70KB
Image Output
Difference Map
5x Enhanced Difference Map

As you can see, the highest quality (4x4) bitrate for ASTC already gains over PNG in memory size. Unlike PNG, this gain stays even after copying the image to the GPU.

The tradeoff comes in the detail, so it is important to carefully examine textures when compressing them to see how much compression is acceptable.

Conclusion

Using hardware accelerated textures in your games will help you reduce the size of your .apk, runtime memory use as well as loading times.

Improve performance on a wider range of devices by uploading multiple apks with different GPU texture formats and declaring the texture type in the AndroidManifest.xml.

If you are aiming for high end devices, make sure to use ASTC which is included in the Android Extension Pack.

Join the discussion on

+Android Developers

Cloud Tools for Android Studio allows you to simultaneously build the service- and client-side of your mobile app. Earlier this month, we announced the release of Android Studio 1.0 that showed just how much raw functionality there is available for Android app developers. However, the client isn’t the whole picture, as most mobile apps also need one or more web services. It was for this reason that the Cloud Tools for Android Studio were created.

Cloud Tools put the power of Google App Engine in the same IDE alongside of your mobile client, giving you all the same Java language tools for both sides of your app, as well as making it far easier for you to keep them in sync as each of them changes.

Getting Started

To get started with Cloud Tools for Android Studio, add a New Module to your Android Studio project, choose Google Cloud Module and you’ll have three choices:

The Java Servlet Module gives you a plain servlet class for you to implement as you see fit. If you’d like help building your REST endpoints with declarative routing and HTTP verbs and automatic Java object serialization to and from JSON, then you’ll want the Java Endpoints Module. If you want the power of endpoints, along with the ability to send notifications from your server to your clients, then choose Backend with Google Cloud Messaging.

Once you’re done, you’ll have your service code right next to your client code:

Not only does this make it very convenient to build and test your entire end-to-end, but we also dropped a little extra something into your app’s build.gradle file:

The updated Gradle file will now create a library for use in your app’s client code that changes when your service API changes. This library lets you call into your service from your client and provides full code completion as you do:

Instead of writing the code to create HTTP requests by hand, you can make calls via the library in a typesafe manner and the marshalling from JSON to Java will be handled for you, just like on the server-side (but in reverse, of course).

Endpoints Error Detection

Meanwhile, back on the server-side, as you make changes to your endpoints, we’re watching to make sure that they’re in good working order even before you compile by checking the attributes as you type:

Here, Cloud Tools have found a duplicate name in the ApiMethod attribute, which is easy to do if you’re creating a new method from an existing method.

Creating an Endpoint from an Objectify Entity

If, as part of your endpoint implementation, you decide to take advantage of the popular Objectify library, you’ll find that Cloud Tools provides special support for you. When you right-click (or control-click on the Mac) on a file containing an Objectify entity class, you’ll get the Generate Cloud Endpoint from Java class option:

If you’re running this option on a Java class that isn’t built with Objectify, then you’re going to get an endpoint with empty methods for get and insert operations that you can implement as appropriate. However, if you do this with an Objectify entity, you’ll get a fully implemented endpoint:

Using your Cloud Endpoint

As an Android developer, you’re used to deploying your client first in the emulator and then into a local device. Likewise, with the service, you’ll want to test first to your local machine and then, when you’re ready, deploy into a Google App Engine project. You can run your service app locally by simply choosing it from the Configurations menu dropdown on the toolbar and pressing the Run button:

This will build and execute your service on http://localhost:8080/ (by default) so that you can test against it with your Android app running in the emulator. Once you’re ready to deploy to Google Cloud Platform, you can do so by selecting the Deploy Module to App Engine option from the Build menu, where you’ll be able to choose the source module you want to deploy, log into your Google account and pick the target project to which you’d like to deploy:

Cloud Tools beta required some extra copying and pasting to get the Google login to work, but all of that’s gone now in this release.

What’s Next?

We’re excited to get this release into your hands, so if you’ve haven’t downloaded it yet, then go download Android Studio 1.0 right now! To take advantage of Cloud Tools for Android Studio, you’ll want to sign up for a free Google Cloud Platform trial. Nothing is stopping you from building great Android apps from front to back. If you’ve got suggestions, drop us a line so that we can keep improving. We’re just getting started putting Google Cloud Platform tools in your hands. We can’t wait to see what you’ll build.

Join the discussion on

+Android Developers

In an effort to supercharge our Google Play games services (GPGS) developer tools, we’re introducing the Game services Publishing API, a revamped Unity Plugin, additional enhancements to the C++ SDK, and improved Leaderboard Tamper Protection.

Let’s dig into what’s new for developers:

Publishing API to automate game services configuration

At Google I/O this past June, the pubsite team launched the Google Play Developer Publishing APIs to automate the configuration and publishing of applications to the Play store. Game developers can now also use the Google Play game services Publishing API to automate the configuration and publishing of game services resources, starting with achievements and leaderboards.

For example, if you plan on publishing your game in multiple languages, the game services Publishing API will enable you to pull translation data from spreadsheets, CSVs, or a Content Management System (CMS) and automatically apply those translations to your achievements.

Early adopter Square Enix believes the game services Publishing API will be an indispensable tool to manage global game rollouts:

Achievements are the most used feature in Google Play game services for us. As our games support more languages, achievement management has become increasingly difficult. With the game services Publishing API, we can automate this process, which is really helpful. The game services Publishing API also comes with great samples that we were able to easily customize for our needs

Keisuke Hata, Manager / Technical Director, SQUARE ENIX Co., Ltd.

To get started today, take a look at the developer documentation here.

Updated Unity plugin and Cross-platform C++ SDK

• Unity plugin Saved Games support: You can now take advantage of the Saved Games feature directly from the Unity plugin, with more storage and greater discoverability through the Play Games app
• New Unity plugin architecture: We’ve rewritten the plugin on top of our cross-platform C++ SDK to speed up feature development across SDKs and increase our responsiveness to your feedback
• Improved Unity generated Xcode project setup: You now have a much more robust way to generate Xcode projects integrated with Google Play Game Services in Unity
• Updated and improved Unity samples: We’ve updated our sample codes to make it easier for first time developers to integrate Google Play games services
• C++ SDK support for iPhone 6 Plus: You can now take advantage of the out-of-box games services UI (e.g., for leaderboards and achievements) for larger form factor devices, such as the iPhone 6 Plus

We also include some important bug fixes and stability improvements. Check out the release notes for the Unity Plugin and the getting started page for the C++ SDK for more details.

Leaderboard Tamper Protection

Turn on Leaderboard Tamper Protection to automatically hide suspected tampered scores from your leaderboards. To enable tamper protection on an existing leaderboard, go to your leaderboard in the Play developer console and flip the “Leaderboard tamper protection” toggle to on. Tamper protection will be on by default for new leaderboards.Learn more.

To learn more about cleaning up previously submitted suspicious scores refer to the Google Play game services Management APIs documentation or get the web demo console for the Management API directly from github here.

Join the discussion on

+Android Developers

What’s a better holiday gift than great performance? You’ve got a great watch face idea -- now, you want to make sure the face you’re presenting to the world is one of care and attention to detail.

At the core of the watch face's process is an onDraw method for canvas operations. This allows maximum flexibility for your design, but also comes with a few performance caveats. In this blog post, we will mainly focus on performance using the real life journey of how we optimised the Santa Tracker watch face, more than doubling the number of fps (from 18 fps to 42 fps) and making the animation sub-pixel smooth.

Starting point - 18 fps

Our Santa watch face contains a number of overlapping bitmaps that are used to achieve our final image. Here's a list of them from bottom to top:

1. Background (static)
2. Clouds which move to the middle
3. Tick marks (static)
4. Santa figure and sledge (static)
5. Santa’s hands - hours and minutes
6. Santa’s head (static)

The journey begins with these images...

Large images kill performance (+14 fps)

Image size is critical to performance in a Wear application, especially if the images will be scaled and rotated. Wasted pixel space (like Santa’s arm here) is a common asset mistake:

Before: 584 x 584 = 341,056 pixels	After: 48*226 = 10,848 (97% reduction)

It's tempting to use bitmaps from the original mock up that have the exact location of watch arms and components in absolute space. Sadly, this creates problems, like in Santa's arm here. While the arm is in the correct position, even transparent pixels increase the size of the image, which can cause performance problems due to memory fetch. You'll want to work with your design team to extract padding and rotational information from the images, and rely on the system to apply the transformations on our behalf.

Since the original image covers the entire screen, even though the bitmap is mostly transparent, the system still needs to check every pixel to see if they have been impacted. Cutting down the area results in significant gains in performance. After correcting both of the arms, the Santa watch face frame rate increased by 10 fps to 28 fps (fps up 56%). We saved another 4 fps (fps up 22%) by cropping Santa’s face and figure layer. 14 fps gained, not bad!

Combine Bitmaps (+7 fps)

Although it would be ideal to have the watch tick marks on top of our clouds, it actually does not make much difference visually as the clouds themselves are transparent. Therefore there is an opportunity to combine the background with the ticks.

When we combined these two views together, it meant that the watch needed to spend less time doing alpha blending operations between them, saving precious CPU time. So, consider collapsing alpha blended resources wherever we can in order to increase performance. By combining two full screen bitmaps, we were able to gain another 7 fps (fps up 39%).

Anti-alias vs FilterBitmap flags - what should you use? (+2 fps)

Android Wear watches come in all shapes and sizes. As a result, it is sometimes necessary to resize a bitmap before drawing on the screen. However, it is not always clear what options developers should select to make sure that the bitmap comes out smoothly. With canvas.drawBitmap, developers need to feed in a Paint object. There are two important options to set - they are anti-alias and FilterBitmap. Here’s our advice:

• Anti-alias does not do anything for bitmaps with transparent edges. We often switch on the anti-alias option by default as developers when we are creating a Paint object. However, this option only really makes sense for vector objects. For bitmaps, this is used to blend the rectangular edges if it is rotated or skewed and it has no impact if the edge pixels are transparent (as we would imagine most watch face arms would be). The hand on the left below has anti-alias switched on, the one on the right has it switched off. So turn off anti-aliasing for bitmaps to gain performance back. For our watch face, we gained another 2 fps (fps up 11%) by switching this option off.

• Switch on FilterBitmap for all bitmap objects which are on top of other objects - this option smooths the edges when drawBitmap is called. This should not be confused with the filter option on Bitmap.createScaledBitmap for resizing bitmaps. We need both to be turned on. The bitmaps below are the magnified view of Santa’s hand. The one on the left has FilterBitmap switched off and the one on the right has FilterBitmap switched on.

Eliminate expensive calls in the onDraw loop (+3 fps)

onDraw is the most critical function call in watch faces. It's called for every drawable frame, and the actual painting process cannot move forward until it's finished. As such, our onDraw method should be as light and as performant as possible. Here's some common problems that developers run into that can be avoided:

1. Do move heavy and common code to a precompute function - e.g. if we commonly grab R.array.cloudDegrees, try doing that in onCreate, and just referencing it in the onDraw loop.
2. Don’t repeat the same image transform in onDraw - it’s common to resize bitmaps at runtime to fit the screen size but this is not available in onCreate. To avoid resizing the bitmap over and over again in onDraw, override onSurfaceChanged where width and height information are available and resize images there.
3. Don't allocate objects in onDraw - this leads to high memory churn which will force garbage collection events to kick off, killing frame rates.
4. Do analyze the CPU performance by using a tool such as the Android Device Monitor. It’s important that the onDraw execution time is short and occurs in a regular period.

Following these simple rules will improve rendering performance drastically.

In the first version, the Santa onDraw routine has a rogue line:

int[] cloudDegrees = 
    getResources().getIntArray(R.array.cloudDegrees);

This loads the int array on every call from resources which is expensive. By eliminating this, we gained another 3 fps (fps up 17%).

Sub-pixel smooth animation (-2 fps)

For those keeping count, we should be 44 fps, so why is the end product 42 fps? The reason is a limitation with canvas.drawBitmap. Although this command takes left and top positioning settings as a float, the API actually only deals with integers if it is purely translational for backwards compatibility reasons. As a result, the cloud can only move in increments of a whole pixel resulting in janky animations. In order to be sub-pixel smooth, we actually need to draw and then rotate rather than having pre-rotate clouds which moves towards Santa. This additional rotation costs us 2 fps. However, the effect is worthwhile as the animation is now sub-pixel smooth.

Before - fast but janky and wobbly

for (int i = 0; i < mCloudBitmaps.length; i++) {
    float r = centerX - (timeElapsed / mCloudSpeeds[i]) % centerX;
    float x = centerX + 
        -1 * (r * (float) Math.cos(Math.toRadians(cloudDegrees[i] + 90)));
    float y = centerY - 
        r * (float) Math.sin(Math.toRadians(cloudDegrees[i] + 90));
    mCloudFilterPaints[i].setAlpha((int) (r/centerX * 255));
    Bitmap cloud = mCloudBitmaps[i];
    canvas.drawBitmap(cloud,
        x - cloud.getWidth() / 2,
        y - cloud.getHeight() / 2,
        mCloudFilterPaints[i]);
}

After - slightly slower but sub-pixel smooth

for (int i = 0; i < mCloudBitmaps.length; i++) {
    canvas.save();
    canvas.rotate(mCloudDegrees[i], centerX, centerY);
    float r = centerX - (timeElapsed / (mCloudSpeeds[i])) % centerX;
    mCloudFilterPaints[i].setAlpha((int) (r / centerX * 255));
    canvas.drawBitmap(mCloudBitmaps[i], centerX, centerY - r,
        mCloudFilterPaints[i]);
    canvas.restore();
}

Before: Integer translation values create janky, wobbly animation. After: smooth sailing!

Quality on every wrist

The watch face is the most prominent UI element in Android Wear. As craftspeople, it is our responsibility to make it shine. Let’s put quality on every wrist!

Join the discussion on

+Android Developers

With the launch of Android 5.0 Lollipop, we’ve added more than 20 new code samples demonstrating how to implement some of the great new features of this release. To access the code samples, you can easily import them in Android Studio 1.0 using the new Samples Wizard.

Go to File > Import Sample in order to browse the available samples, which include a description and preview for each. Once you’ve made your selection, select “Next” and a new project will be automatically created for you. Run the project on an emulator or device, and feel free to experiment with the code.

Samples Wizard in Android Studio 1.0

Newly imported sample project in Android Studio

Alternatively, you can browse through them via the Samples browser on the developer site. Each sample has an Overview description, Project page to browse app file structure, and Download link for obtaining a ZIP file of the sample. As a third option, code samples can also be accessed in the SDK Manager by downloading the SDK samples for Android 5.0 (API 21) and importing them as existing projects into your IDE.

Sample demonstrating transition animations

Material Design

When adopting material design, you can refer to our collection of sample code highlighting material elements:

• Floating action button
• Reveal effect
• CardView
• Drawable tinting
• Elevation
• Drag-and-drop with elevation
• View clipping
• Animation interpolators

For additional help, please refer to our design checklist, list of key APIs and widgets, and documentation guide.

To view some of these material design elements in action, check out the Google I/O app source code.

Platform

Lollipop brings the most extensive update to the Android platform yet. The Overview screen allows an app to surface multiple tasks as concurrent documents. You can include enhanced notifications with this sample code, which shows you how to use the lockscreen and heads-up notification APIs.

We also introduced a new Camera API to provide developers more advanced image capture and processing capabilities. These samples detail how to use the camera preview and take photos, how to record video, and implement a real-time high-dynamic range camera viewfinder.

Elsewhere, Project Volta encourages developers to make their apps more battery-efficient with new APIs and tools. The JobScheduler sample demonstrates how you can schedule background tasks to be completed later or under specific conditions.

For those interested in the enterprise device administration use case, there are sample apps on setting app restrictions and creating a managed profile.

Android Wear

For Android Wear, we have a speed tracker sample to show how to take advantage of GPS support on wearables. You can browse the rest of the Android Wear samples too, and here are some highlights that demonstrate the unique capabilities of wearables, such as data synchronization, notifications, and supporting round displays:

• DataLayer
• FindMyPhone
• GridViewPager
• Notifications
• RecipeAssistant
• SynchronizedNotifications
• WatchViewStub

Android TV

Extend your app for Android TV using the Leanback library described in this training guide and sample.

To try out a game that is specifically optimized for Android TV, download Pie Noon from Google Play. It’s an open-source game developed in-house at Google that supports multiple players using Bluetooth controllers or touch controls on mobile devices.

Android Auto

For the use cases highlighted in the Introduction to Android Auto DevByte, we have two code samples. The Media Browser sample (DevByte) demonstrates how easy it is to make an audio app compatible with Android Auto by using the new Lollipop media APIs, while the Messaging sample (DevByte) demonstrates how to implement notifications that support replies using speech recognition.

Google Play services

Since we’ve discussed sample resources for the Android platform and form factors, we also want to mention that there are existing samples for Google Play services. With Google Play services, your app can take advantage of the latest Google-powered APIs such as Maps, Google Fit, Google Cast, and more. Access samples in the Google Play services SDK or visit the individual pages for each API on the developer site. For game developers, you can reference the Google Play Games services samples for how to add achievements, leaderboards, and multiplayer support to your game.

Check out a sample today to help you with your development!

Join the discussion on

+Android Developers

We've been working on a new toolchain for Android that’s designed to improve build times and simplify development by reducing dependencies on other tools. Today, we’re introducing you to Jack (Java Android Compiler Kit) and Jill (Jack Intermediate Library Linker), the two tools at the core of the new toolchain.

We are making an early, experimental version of Jack and Jill available for testing with non-production versions of your apps. This post describes how the toolchain works, how to configure it, and how to let us know of your feature requests and any bugs you find.

So how does it work?

When the new tool chain is enabled, Jill will translate any libraries you are referencing to a new Jack library file (.jack). This prepares them to be quickly merged with other .jack files. The Android Gradle plugin and Jack collect any .jack library files, along with your source code, and compiles them into a set of dex files. During the process, Jack also handles any requested code minification. The output is then assembled into an APK file as normal. We also include support for multiple dex files, if you have enabled that support.

How do I use it?

Jack and Jill are already available in the 21.1.1+ Build Tools for Android Studio. Complementary Gradle support is also currently available in the Android 1.0.0+ Gradle plugin. To get started, all you need to do is make sure you're using these versions of the tooling and then add a single line in your build.gradle file. Perform a build of your application to receive a newly built APK.

android {
    ...
    buildToolsRevision '21.1.1'
    defaultConfig {
      // Enable the experimental Jack build tools.
      useJack = true
    }
    ...
}

android {
    ...
    productFlavors {
        dev {
            ...
        }
        experimental {
            useJack = true
        }
        prod {
            ...
        }
    }
    ...
}

How do I configure my build?

We are making the transition to Jack as smooth as possible by supporting minification (shrinking and/or obfuscation), as well as repackaging (i.e. similar to tools like jarjar), while using the same input files as you are used to. Minification is available in the Gradle plugin immediately and repackaging will follow. You should continue to use the "minifyEnabled true" directive to reduce the size of your app among all other optimizations you would normally use. There are more details on our reference page (linked below) regarding the level of support for each type of optimization. We encourage you to provide feedback there if your current configuration isn't supported.

Give us your feedback

We are attempting to make the toolchain as easy to test out as possible and we're looking for your help to fine tune it. Use the reference page to find known issues, file feature requests, and report bugs. Happy building!

Join the discussion on

+Android Developers

We’re pleased to announce that the official Android Wear Watch Face API is now available for developers. Watch faces give users even more ways to express their personal style, while creating an opportunity for developers to customize the most prominent UI feature of the watches. Watch faces have been the most requested feature from users and developers alike, and we can’t wait to see what you build for them.

An Introduction to Watch Faces for Android Wear by Timothy Jordan

Design and development

To get started, first learn about Designing Watch Faces, and then check out the Creating Watch Faces training class. The WatchFace Sample available online and in the Android Studio samples manager also provides a number of different examples to help you jump right in. For a quick overview, you can also watch the Watch Faces for Android Wear DevByte video above.

Watch faces are services that run from your wearable app, so you can provide one or multiple watch faces with a single app install. You can also choose to have configuration activities on the phone or watch, for example to let a user change between 12 and 24-hour time, or to change the watch face’s background. You can use OpenGL to provide smooth graphics, and a background service to pull in useful data like weather and calendar events. Watch faces can be analog, or digital, or display the time in some new way that hasn’t been invented yet––it’s up to you.

Updates to existing devices

Over the next week, the latest release of Android Wear, based on Android 5.0 and implementing API 21, will roll out to users. All Android Wear devices will be updated to Android 5.0 via an over-the air (OTA) update. The update allows users to manage and configure watch faces in the Android Wear app on their phone, and install watch faces from Google Play. Any handheld device running Android 4.3 or later will continue to work with all Android Wear devices.

Upgrade your watch faces

Developers are incredibly resourceful and we’re impressed with the watch faces you were able to create without any documentation at all. If you’ve already built a watch face for Android Wear using an unofficial approach, you should migrate your apps to the official API. The official API ensures a consistent user experience across the platform, while giving you additional information and controls, such as letting you know when the watch enters ambient mode, allowing you to adjust the position of system UI elements, and more. Using the new API is also necessary for your app to be featured in the Watch Faces collection on Google Play.

Deployment of watch faces to Google Play

We recommend you update your apps on Google Play as soon as the Android Wear 5.0 API 21 OTA rollout is complete, which we’ll announce on the Android Wear Developers Google+ community. It’s important to wait until the OTA rollout is complete because a Watch Face requiring API 21 will not be visible on a watch running API 20. Once your user gets the OTA, then the watch face will become visible. If you want to immediately launch your updates during the OTA rollout, make sure you set minSdkVersion to 20 in your wearable app, otherwise the app will fail to install for pre-OTA users. Once the rollout is complete, please transition your existing watch faces to the new API by January 31, 2015, at which point we plan to remove support for watch faces that don't use the official API.

Android Wear apps on Google Play

Starting today, you can submit any of your apps for designation as Android Wear apps on Google Play by following the Distributing to Android Wear guidelines. If your apps follow the criteria in the Wear App Quality checklist and are accepted as Wear apps on Play, it will be easier for Android Wear users to discover them. To opt-in for Android Wear review, visit the Pricing & Distribution section of the Google Play Developer Console.

In the few short months since we’ve launched Android Wear, developers have already written thousands of apps, taking advantage of custom notifications, voice actions, and fully native Android capabilities. Thanks to you, users have infinite ways to personalize their watches, choosing from six devices, a range of watch bands, and thousands of apps. With support for custom watch faces launching today, users will have even more choices in the future. These choices are at the heart of a rich Android Wear ecosystem and as we continue to open up core features of the platform to developers, we can’t wait to see what you build next.

Join the discussion on

+Android Developers

A constraint for some Android apps is the total number of methods that the underlying compiled .dex file can support. It’s limited by 16 bits, or 65,536 values.

When you include third-party libraries in your application, you will have all of their methods in your .dex file. Larger APIs, such as those included in Google Play services, will then begin eating into the limit very quickly.

You can learn more about this, and ways that you can work around it with the Android Studio 1.0 build system here.

Additionally, with Google Play services version 6.5 or later, it is possible for you to include Google Play services in your application using a number of smaller client libraries, so that only Google Play services APIs you use will get compiled into your .dex file, and therefore their methods won't count towards your method limit.

Prior to version 6.5, you would typically have a line like this in your build.gradle file:

compile 'com.google.android.gms:play-services:6.5.87'

Starting with version 6.5, of Google Play services, you’ll be able to pick from a number of individual APIs, and you can see which ones have their own include files in the documentation. For example, if all you want to use is Maps, you would instead have:

compile 'com.google.android.gms:play-services-maps:6.5.87'

Note that this will transitively include the ‘base’ libraries, which are used across all APIs. You can include them independently with the following line:

compile 'com.google.android.gms:play-services-base:6.5.87'

The complete list of API names is below. More details can be found on the Android Developer site.

Note: At the time of writing, the correct version to use is 6.5.87. As this is a very granular number, it will get updated quite quickly, so be sure the check the latest version when you are coding. Often people will use a ‘+’ to denote versions, such as 6.5.+ to use the latest 6.5 build. However, it’s typically discouraged to use a ‘+’ as it can lead to inconsistencies.

Also, there are some changes to the names of the libraries that will impact you if you build applications for Android Wear. Previously you may have used play-services-wearable to include the entire Google Play services library for your wearable, and if you want to continue doing so, you should now use play-services-all-wear instead. You can continue to use play-services-wearable which will instead give you just the Wearable Data Layer API (see here). Should you do this, and you want to continue working with other Google Play services features, such as the Location APIs on your wearable, you would need to add play-services-location.

Join the discussion on

+Android Developers

Over has taken a simple idea, adding text and artwork to photos, and turned it into a creative tool that enables anyone to easily and intuitively add a unique twist to any image.

The Over team recently decided to bring their successful app to Android. “We love unlocking human creativity and Android offers a massive opportunity for doing just that. It was a no-brainer,” says Aaron Marshall, Founder, CEO, and Designer at Over. “Moving to Cape Town was eye-opening in many ways. It made me experience first-hand how many people outside the US use Android. We see users in emerging markets using mobile devices as their primary device, and believe there is a lot of opportunity in providing them with creative tools for mobile.”

The entire team was new to the platform, and were quickly impressed by the ease of development and the power of the distribution tools in the Developer Console on Google Play.

In this video, the Over team talk about their experiences learning and working with Android.

Over engineer Johan Nell, who arrived with Java experience but hadn’t worked with Android, says that he and fellow engineer Herko Lategan “were able to get a working prototype out in the first week.”

Android plays a big part in Over living up to its mantra of “go big, and go home”. As Aaron explains, “we don’t think you should be sacrificing your family to create wealth, or add value, or change the world. Being able to experiment and iterate quickly is crucial in helping us achieve this goal.”

To learn about starting a successful business with Android, be sure to check out these resources:

• The Secrets to App Success on Google Play [ebook] — a detailed playbook on the best practices and tools you can use to maximize the reach, retention, and revenue of your new app.
• Getting Started [training] — check out this comprehensive learning resource that takes you from first principles through to the most powerful Android APIs.

Join the discussion on

+Android Developers

By Jamal Eason, Product Manager, Android

Today we are excited to introduce Android Studio 1.0. Android Studio is the official Integrated Development Environment (IDE) from the Android team. It is built on the popular IntelliJ IDEA (Community Edition) Java IDE.

We first released a preview of Android Studio at I/O last year. We value the on-going feedback from you, thanks! We are making Android Studio 1.0 available for download as a stable release on the Android Developer site.

Download Android Studio

If you are currently developing for Android or thinking about getting started, now is the time to download Android Studio 1.0 (or upgrade if you are using an earlier version). Similar to the Chrome release channels, Android Studio will continue to receive updates on four different release channels: Stable, Beta, Dev, and Canary. Canary builds are at the bleeding edge of development, while the stable release is fully tested. With this range of release channels you can choose how quickly you want to get the latest features for Android Studio.

Android Studio features

With the release of Android Studio, you have access to a new set of features to enable your development workflow. Some of the key features of Android Studio are listed below, but make sure to check out the Android Studio page for a full feature overview.

Startup experience

• First-run setup wizard — The getting started experience now installs the right Android SDK, sets up your development environment settings, and creates an optimized emulator for testing your app. Plus, we include a set of code templates to help you get started.

• Sample Importing & templates — Android Studio includes wizards that enable you to start with new project templates or import Google code samples.

Code and resource editing, user interface design

• Code Editing — Android Studio takes advantage of all the intelligent code editing capabilities of IntelliJ IDEA such as advanced code completion, refactoring, and code analysis.

• Internationalization string editing — Manage string translations of your app in Android Studio.

• User interface design — Edit and preview your Android Layouts across multiple screen sizes, languages, and even API versions.

Performance analysis

• Memory monitor — View the memory usage of your app over time to help find ways to improve the performance of your app.

Unified build system

• Android Studio uses a Gradle-based build system that provides a lot of flexibility and extensibility, as well as the ability to build from within and outside of the IDE. This unified build system decouples the build from Studio itself, meaning that Studio updates never impact the output of your build.
• Some of the key features of the build systems are: build variant support to better handle different build types (debug vs. release), or different versions of the same app (paid vs. free), multi-apks handling through splits, multi-dex support, and dependency management for 3rd party libraries.

Instant access to Google Cloud Services

• Android Studio even enables an easy way to add Google Cloud Backends & Endpoints to your app, as well as Google Cloud Messaging (find out more).

Time to migrate & update

If you are an Eclipse user, check out our migration steps or you can just import your projects right into Android Studio with the import wizard, shown below:

If you were using one of the early versions of Android Studio, you should also upgrade to version 1.0 since we have added a host of new features and have addressed many bugs.

We have also released version 1.0 of the Gradle plugin with a file format that is now stable. The communication between Android Studio and the Gradle plugin is now stable, so updating one will not require updating the other. Check the technical release notes for additional tips for updating your previous Android Studio projects.

Give us your feedback

We are always seeking to bring you the best Android development experience. We already have plans to add features ranging from improved testing and better support for game development, but we want to know how you work and what capabilities you'd like to have for your Android development.

Please take a moment to complete a short survey (less than 5 minutes). Your responses will help shape the next set of features offered in Android Studio.

Questions?

We develop Android Studio and the corresponding tools in open source, so you can also file bugs via the public Android bug tracker and we will do our best to address your issues or questions. If you have specific questions or need help in your migration, feel free to connect with the Android developer tools team on our Google+ community page.

Join the discussion on

+Android Developers

In the coming months, we’ll be seeing more media players, like the recently released Nexus Player, and TVs from partners with Android TV built-in hit the market. While there’s plenty of information available about the technical aspects of adapting your app or game to Android TV, it’s also useful to consider design changes to optimize for the living room. That way you can provide lasting engagement for existing fans as well as new players discovering your game in this new setting. Here are three things one developer did, and how you can do them too.

Infinite Dreams is an indie studio out of Poland, co-founded by hardcore game fans Tomasz Kostrzewski and Marek Wyszyński. With Sky Force 2014 TV, they brought their hit arcade style game to Android TV in a particularly clever way. The mobile-based version of Sky Force 2014 reimaged the 2004 classic by introducing stunning 3D visuals, and a free-to-download business model using in-app purchasing and competitive tournaments to increase engagement. In bringing Sky Force 2014 to TV, they found ways to factor in the play style, play sessions, and real-world social context of the living room, while paying homage to the title’s classic arcade heritage. As Wyszyński puts it, “We decided not to take any shortcuts, we wanted to make the game feel like it was designed to be played on TV.”

Orientation

For starters, Sky Force 2014 is played vertically on a smartphone or tablet, also known as portrait mode. In the game, you’re piloting a powerful fighter plane flying up the screen over a scrolling landscape, targeting waves of steampunk enemies coming down at you. You can see far enough up the screen, enabling you to plan your attacks and dodge enemies in advance.

Vertical play on the mobile version

When bringing the game to TV, the quickest approach would have been to preserve that vertical orientation of the gameplay, by pillarboxing the field of play.

With Sky Force 2014, Infinite Dreams considered their options, and decided to scale the gameplay horizontally, in landscape mode, and recompose the view and combat elements. You’re still aiming up the screen, but the world below and the enemies coming at you are filling out a much wider field of view. They also completely reworked the UI to be comfortably operated with a gamepad or simple remote. From Wyszyński’s point of view, “We really didn't want to just add support for remote and gamepad on top of what we had because we felt it would not work very well.” This approach gives the play experience a much more immersive field of view, putting you right there in the middle of the action. More information on designing for landscape orientation can be found here.

Multiplayer

Like all mobile game developers building for the TV, Infinite Dreams had to figure out how to adapt touch input onto a controller. Sky Force 2014 TV accepts both remote control and gamepad controller input. Both are well-tuned, and fighter handling is natural and responsive, but Infinite Dreams didn’t stop there. They took the opportunity to add cooperative multiplayer functionality to take advantage of the wider field of view from a TV. In this way, they not only scaled the visuals of the game to the living room, but also factored in that it’s a living room where people play together. Given the extended lateral patterns of advancing enemies, multiplayer strategies emerge, like “divide and conquer,” or “I got your back” for players of different skill levels. More information about adding controller support to your Android game can be found here, handling controller actions here, and mapping each player’s paired controllers here.

Players battle side by side in the Android TV version

Business Model

Infinite Dreams is also experimenting with monetization and extending play session length. The TV version replaces several $1.99 in-app purchases and timers with a try-before-you-buy model which charges $4.99 after playing the first 2 levels for free. We’ve seen this single purchase model prove successful with other arcade action games like Mediocre’s Smash Hit for smartphones and tablets, in which the purchase unlocks checkpoint saves. We’re also seeing strong arcade action games like Vector Unit’s Beach Buggy Racing and Ubisoft’s Hungry Shark Evolution retain their existing in-app purchase models for Android TV. More information on setting up your games for these varied business models can be found here. We’ll be tracking and sharing these variations in business models on Android TV, including variations in premium, as the Android TV platform grows.

Reflecting on the work involved in making these changes, Wyszyński says, “From a technical point of view the process was not really so difficult – it took us about a month of work to incorporate all of the features and we are very happy with the results.” Take a moment to check out Sky Force 2014 TV on a Nexus Player and the other games in the Android TV collection on Google Play, most of which made no design changes and still play well on a TV. Consider your own starting point, take a look at the Android TV section on our developer blog, and build the version of your game that would be most satisfying to players on the couch.

Join the discussion on

+Android Developers

musiXmatch is an app that offers Android users the unique and powerful feature FloatingLyrics. FloatingLyrics pops up a floating window showing synched lyrics as users listen to tracks on their favorite player and music services. It’s achieved through a seamless integration with intents on the platform, something that’s technically possible only on Android.

As a result musiXmatch has seen “a dramatic increase in terms of engagement’, says founder Max Ciociola, “which has been two times more active users and even two times more the average time they spend in the app.”

The ability to deliver lyrics to a range of different devices — such as Chromecast, Android TV, and Android Wear — is creating opportunities for musiXmatch. It’s helping them turn their app into a smart companion for their users and getting them closer to their goal of reaching 100 million people.

In the following video, Max and Android engineer Sebastiano Gottardo talk about the unique capabilities that Android offers to musiXmatch:

To learn about achieving great user engagement and retention and reaching more users through different form factors, be sure to check out these resources:

• Convert installs to active users — Watch this video to hear from Matteo Vallone, Partner Development Manager for Google Play, about the best practices in engaging and retaining app users using intents, identity, context, and rich notifications as well as delivering a cross-platform user experience.
• Expanding to new form factors: Tablet, Wear & TV — Watch this panel discussion with Google experts talking about cross-platform opportunities and answering developer questions.

Join the discussion on

+Android Developers

Google Play is the largest digital store for Android users to discover and purchase their favorite mobile app and games, and the ecosystem is continuing to grow globally. Over the past year, we’ve expanded the list of countries where app developers can sign up to be merchants on Google Play, totaling 60 countries, including Lebanon, Jordan, Oman, Pakistan, Puerto Rico, Qatar and Venezuela most recently.

As part of that continued effort, we’re excited to announce merchant support in China, enabling local developers to export and sell their apps to Google Play users in more than 130 countries. Chinese developers can now offer both free and paid applications through various monetization models, including in-app purchasing and subscriptions. For revenue generated on Google Play, developers will receive payment to their Chinese bank accounts via USD wire transfers.

If you develop Android apps in China and want to start distributing your apps to a global audience through Google Play, visit play.google.com/apps/publish and register as a developer. If you want to sell apps and in-app products, you'll need to also sign up for a Google Wallet merchant account, which is available on the “Revenue” page in the Google Play Developer Console. After you’ve uploaded your apps, you can set prices in the Developer Console and later receive reports on your revenue. You’ll receive your developer payouts via wire transfer. For more details, please visit our developer help center.

We look forward to continuing to roll out Google Play support to developers in many more countries around the world.

中国开发者可以向全球130个国家的Google Play用户提供付费应用啦

发表者：Ellie Powers, Google Play产品经理

Google Play是一个可让Android用户发现和购买他们喜爱的移动应用程序和游戏的全球最大的应用商店，这个生态系统在全球迅速成长。过去一年中，我们已经扩展到60个国家，让应用程序开发人员可以注册成为 Google Play的商家，其中新近支持的国家包括黎巴嫩、约旦、阿曼、巴基斯坦、波多黎各、卡塔尔和委内瑞拉。

作为持续改进 Google Play努力的一部分，我们很高兴地宣布在中国增加了对商家的支持，让中国的开发者能售卖应用程序到130个国家的 Google Play 用户。中国的开发者现在可以提供通过各种盈利模式的免费和付费应用，包括应用内购买和订阅。在 Google Play 产生的营收将通过美元电汇的方式支付给开发者的中国的银行账户。

如果你在中国开发Android应用程序，并希望通过 Google Play 把应用程序推广到全球，请登录play.google.com/apps/publish 并建立你的 Google Play 开发者账户。如果你想售卖付费的应用程序和应用程序内的产品，则需要再注册一个Google 电子钱包商家帐户，通过Google Play开发者控制台里的”营收”页面进行设置。上传应用程序后，你可以通过开发者控制台设定价格，之后就可以收到营收报告，你将会通过电汇的方式获得收入。

我们将继续增加更多 Google Play 商家支持的国家，敬请关注。

更多详情，请访问我们的开发者帮助中心。

Join the discussion on

+Android Developers

We’re pleased to announce Pie Noon, a simple game created to demonstrate multi-player support on the Nexus Player, an Android TV device. Pie Noon is an open source, cross-platform game written in C++ which supports:

• Up to 4 players using Bluetooth controllers.
• Touch controls.
• Google Play Games Services sign-in and leaderboards.
• Other Android devices (you can play on your phone or tablet in single-player mode, or against human adversaries using Bluetooth controllers).

Pie Noon serves as a demonstration of how to use the SDL library in Android games as well as Google technologies like Flatbuffers, Mathfu, fplutil, and WebP.

• Flatbuffers provides efficient serialization of the data loaded at run time for quick loading times. (Examples: schema files and loading compiled Flatbuffers)
• Mathfu drives the rendering code, particle effects, scene layout, and more, allowing for efficient mathematical operations optimized with SIMD. (Example: particle system)
• fplutil streamlines the build process for Android, making iteration faster and easier. Our Android build script makes use of it to easily compile and run on on Android devices.
• WebP compresses image assets more efficiently than jpg or png file formats, allowing for smaller APK sizes.

You can download the game in the Play Store and the latest open source release from our GitHub page. We invite you to learn from the code to see how you can implement these libraries and utilities in your own Android games. Take advantage of our discussion list if you have any questions, and don’t forget to throw a few pies while you’re at it!

* Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

Join the discussion on

+Android Developers

At Google I/O back in June, we provided a preview of Android Auto. Today, we’re excited to announce the availability of our first APIs for building Auto-enabled apps for audio and messaging. Android apps can now be extended to the car in a way that is optimized for the driving experience.

For users, this means they simply connect their Android handheld to a compatible vehicle and begin utilizing a car-optimized Android experience that works with the car’s head unit display, steering wheel buttons, and more. For developers, the APIs and UX guidelines make it easy to provide a simple way for users to get the information they need while on the road. As an added bonus, the Android Auto APIs let developers easily extend their existing apps targeting Android 5.0 (API level 21) or higher to work in the car without having to worry about vehicle-specific hardware differences. This gives developers wide reach across manufacturers, model and regions, by just developing with one set of APIs and UX standards.

There are two use cases that Android Auto supports today:

• Audio apps that expose content for users to browse and allow audio playback from the car, such as music, podcasts, news, etc.
• Messaging apps that receive incoming notifications, read messages aloud, and send replies via voice from the car.

To help you get started with Android Auto, check out our Getting Started guide. It’s important to note that while the APIs are available today, apps extended with Android Auto cannot be published quite yet. More app categories will be supported in the future, providing more opportunities for developers and drivers of Android Auto. We encourage you to join the Android Auto Developers Google+ community to stay up-to-date on the latest news and timelines.

We’ve already started working with partners to develop experiences for Android Auto: iHeartRadio, Joyride, Kik, MLB.com, NPR, Pandora, PocketCasts, Songza, SoundCloud, Spotify, Stitcher, TextMe, textPlus, TuneIn, Umano, and WhatsApp. If you happen to be in the Los Angeles area, stop by the LA Auto Show through November 30 and visit us in the Hyundai booth to take Android Auto and an app or two for a test drive.

Join the discussion on

+Android Developers

Saved Games Are the Future!

I think most of us have at least one or two games we play obsessively. Me? I'm a Sky Force 2014 guy. But maybe you're into matching colorful objects, battling monsters, or helping avians with their rage management issues. Either way, there's probably some game where you've spent hours upon hours upgrading your squad, reaching higher and higher levels, or unlocking every piece of bonus content in the game.

Now imagine losing all of that progress when you decide to get a new phone. Or reinstall your game. Yikes!

That's why, when Google Play Games launched, one of the very first features we included was the ability for users to save their game to the cloud using a service called the AppState API. For developers who didn't need an entire server-based infrastructure to run their game, but didn't want to lose players when they upgraded their devices, this feature was a real life-saver.

But many developers wanted even more. With AppState, you were limited to 4 slots of 256k of data each, and for some games, this just wasn't enough. So this past year at Google I/O, we launched an entirely new Saved Games feature, powered by Google Drive. This gave you huge amounts of space (up to 3MB per saved game with unlimited save slots), the ability to save a screenshot and metadata with your saved games, and some nice features like showing your player's saved games directly in the Google Play app.

...But AppState is Yesterday's News

Since the introduction of Saved Games, we've seen enough titles happily using the service and heard enough positive feedback from developers that we're convinced that Saved Games is the better offering and the way to go in the future. With that in mind, we've decided to start deprecating the old cloud save system using AppState and are encouraging everybody who's still using it to switch over to the new Saved Games feature (referred to in our libraries as "Snapshots").

What does this mean for you as a game developer?

If you haven't yet added Saved Games to your game, now would be the perfect time! The holidays are coming up and your players are going to start getting new devices over the next couple of months. Wouldn't it be great if they could take your game's progress with them? Unless, I guess, "not retaining users" is part of your business plan.

If you're already using the new Saved Games / Snapshot system, put your feet up and relax. None of these changes affect you. Okay, now put your feet down, and get back to work. You probably have a seasonal update to work on, don't you?

If you're using the old AppState system, you should start migrating your player's data over to the new Saved Games service. Luckily, it's easy to include both systems in the same game, so you should be able to migrate your users' data with their ever knowing. The process would probably work a little something like this:

• Enable the new Saved Game service for your game by
  • Adding the Drive.SCOPE_APPFOLDER scope to your list of scopes in your GoogleApiClient.
  • Turning on Saved Games for your game in the Google Play Developer Console.
• Next, when your app tries to load the user's saved game
  • First see if any saved game exists using the new Saved Games service. If there is, go ahead and use it.
  • Otherwise, grab their saved game from the AppState service.
• When you save the user's game back to the cloud, save it using the new Saved Games service.
• And that should be it! The next time your user loads up your game, it will find their saved data in the new Saved Games service, and they'll be all set.
• We've built a sample app that demonstrates how to perform these steps in your application, so we encourage you to check it out.

In a few months, we will be modifying the old AppState service to be read-only. You'll still be able to read your user's old cloud save games and transfer them to the new Saved Games service, but you'll no longer be able to save games using the old service. We are evaluating early Q2 of 2015 to make this change, which should give you enough time to push your "start using Saved Games" update to the world.

If you want to find out more about Saved Games and how they work, feel free to review our documentation, our sample applications, or our Game On! videos. And we look forward to many more hours of gaming, no matter how many times we switch devices.

Join the discussion on

+Android Developers

To offer more seamless integration of Google products within your app, we've now rolled out Google Play services 6.5.

Google Play services 6.5 includes new features in Google Maps, Google Drive and Google Wallet as well as the recently launched Google Fit API. We are also providing developers with more granular control over which Google Play services APIs your app depends on to help you maintain a lean app.

Google Maps

We’re making it easier to get directions to places from your app! The Google Maps Android API now offers a map toolbar to let users open Google Maps and immediately get directions and turn by turn navigation to the selected marker. This map toolbar will show by default when you compile against Google Play services 6.5.

In addition, there is also a new ‘lite mode’ map option, ideal for situations where you want to provide a number of smaller maps, or a map that is so small that meaningful interaction is impractical, such as a thumbnail in a list. A lite mode map is a bitmap image of a map at a specified location and zoom level.

In lite mode, markers and shapes are drawn client-side on top of the static image, so you still have full control over them. Lite mode supports all of the map types, the My Location layer, and a subset of the functionality of a fully-interactive map. Users can tap on the map to launch Google Maps when they need more details.

The Google Maps Android API also exposes a new getMapAsync(OnMapReadyCallback) method to MapFragment and MapView which will notify you exactly when the map is ready. This serves as a replacement for the now deprecated getMap() method.

We’re also exposing the Google Maps for Android app intents available to your apps including displaying the map, searching, starting turn by turn navigation, and opening Street View so you can build upon the familiar and powerful maps already available on the device.

Drive

You can now add both public and application private custom file properties to a Drive file which can be used to build very efficient search queries and allow apps to save information which is guaranteed to persist across editing by other apps.

We’ve also made it even easier to make syncing your files to Drive both user and battery friendly with the ability to control when files are uploaded by network type or charging status and cancel pending uploads.

Google Wallet

In addition to the existing ‘Buy with Google’ button available to quickly purchase goods & services using Google Wallet, this release adds a ‘Donate with Google’ button for providing the same ease of use in collecting donations.

Google Fit

The Google Fit SDK was recently officially released as part of Google Play services and can be used to super-charge your fitness apps with a simple API for working with sensors, recording activity data, and reading the user’s aggregated fitness data.

In this release, we’ve made it easier for developers to add activity segments (predefined time periods of running, walking, cycling, etc) when inserting sessions, making it easy to support pauses or multiple activity type workouts. We’ll also be adding additional samples to help kick-start your Google Fit integration.

Granular Dependency Management

As we’ve continued to add more APIs across the wide range of Google services, it can be hard to maintain a lean app, particularly if you're only using a portion of the available APIs. Now with Google Play services 6.5, you’ll be able to depend only on a minimal common library and the exact APIs your app needs. This makes it very lightweight to get started with Google Play services.

SDK Now Available

You can get started developing today by downloading the Google Play services SDK from the Android SDK Manager.

To learn more about Google Play services and the APIs available to you through it, visit the Google Play Services section on the Android Developer site.

Join the discussion on

+Android Developers

EyeEm is a global community for photographers that goes beyond sharing photos with friends: photographers can share tips, take part in missions, and sell their photos. To win more customers, a design that best showcases photos from the community is very important for this Berlin-based company.

With the idea of bringing a beautiful, simple experience to their fast growing base of Android users, the team recently embarked on a redesign of their app. Following the Android design principles, they stripped back the UI and simplified navigation. This allowed them to deliver a more streamlined app experience, along with a clean, crisp design that presents photos beautifully. And it paid off. According to Ramzi Rizk, EyeEm co-founder and CTO, “Our new design helped improve user growth and retention across the board, in every single metric we have.”

In the following video, Rizk and colleague Matias Castello, Product Head of Mobile, talk about their experience applying Android design to their app and the improvements in user engagement it has achieved:

Resources to help you with design

To learn more about how to design your apps for Android devices and achieve great user engagement and retention, be sure to check out these resources:

• Android Design — all the information you need to understand and implement Android design principles in your app.
• Design.Bytes — presented by the Google designers who created Material Design and apps, such as the Google I/O 2014 app, these videos provide a fun and informative introduction to Android design.

Join the discussion on

+Android Developers

Today we're announcing the 1.0 release of fplutil, a set of small libraries and tools by Fun Propulsion Labs at Google (the FPL in fplutil) that is useful when developing C/C++ applications for Android.

fplutil introduces the following:

• build_all_android.py, an all-in-one build script that allows you to build (with the Android NDK), install and run native (C/C++) Android apps from the command line. This is ideal for build automation, but is also useful in a developer’s compile/run loop.
• buildutil performs the configuration, build and archive steps of Android and Linux C/C++ applications using a suite of Python modules. This suite of modules can automate builds in a continuous integration environment. This framework uses legacy tools in the Android Development Toolkit.
• libfplutil enables C/C++ developers to write traditional applications (like Hello World) using "main()" and "printf()" on Android.
• android_ndk_perf.py is a desktop tool that enables native (C/C++) developers to measure the CPU utilization of their applications on Android, guiding their optimization efforts. An example report is shown below:

android_ndk_perf.py example HTML report

You can download the latest open source release from our github page. We invite you to contribute to the project and join our discussion list!

*Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

Join the discussion on

+Android Developers

We’re always looking to help developers improve the gaming experience for their users on Google Play. So today, we've expanded our existing suite of Management APIs to let you fully control all resources in your Google Play Games-enabled game during development and testing, with better support for alpha and beta groups.

Let’s take a quick dive into the expanded offering.

• Reset a single tester’s state for any resource (e.g., achievements, leaderboards), or do it for all resources at once. For example, you can now completely reset a given tester’s data if they’ve ended up in a bad state due to an experimental build. You can do this for individual instances or all instances of achievements, events, quests, or leaderboards scores.
• Reset the state of a single draft resource for all testers, or do it for all draft resources at once. You can now reset all draft leaderboards in your game before publishing with a single API call. This ensures the members of your alpha or beta communities don’t have an unfair advantage on release day. You can do this for individual instances or all instances of achievements, events, quests, or leaderboards scores.
• Clear global match state for all real time or turn based matches composed solely of testers. You can now reset all turn-based matches on release day. This will ensure that all matches from that point on are on the release version of the game. This is available for both real-time or turn-based games.

These updates make it far less complex and error prone to manage data during testing, saving you time and improving the rate at which you can make and test changes to your games.

Play Games Management API background

The Management API is a set of tools that enable developers to do things like manage tester data and clean up bogus leaderboard score submissions. Developers can also use the API to control and manipulate resources (e.g., achievements, events, multiplayer match data).

Getting started

You can get started with the latest version of the Management API right now. Review the updated API reference documentation, start with an example management interface, or download the sample client libraries to get on your way.

Join the discussion on

+Android Developers

With more than 50 billion apps and games downloaded in total, Google Play is helping developers and content creators around the world build successful businesses. In fact, we paid out more than $5 billion over the last year to developers for creating incredible apps that are changing the way people communicate, live, work, and play.

Developing an app or game and distributing it on Google Play is a good start, but it’s only the first step to building a sustainable business. That’s why we’ve written “The Secrets to App Success on Google Play,” a detailed playbook on the best practices and tools you can use to maximize the reach, retention, and revenue of your new app.

The guide is separated into the following sections:

• Publishing on Google Play — using the Google Play Developer Console to distribute your app to over 1 billion Android users worldwide.
• Quality — The fundamentals of building a great app and an insight into the Google Play guidelines and policies.
• Discoverability & reach — Maximizing your app's discoverability and reaching the widest audience possible.
• Engagement & retention — Converting installations into active users and improving user retention.
• Monetization — Monetization strategies to generate ongoing, growing revenue streams.
• Measurement with Google Analytics — Understanding your users and improving your app experience, conversions, and marketing.
• Going global — Launching your app in local markets around the world.

Download the guide now in English (PDF, 11MB) or get it on Google Play. We’ll release the guide in more languages in the coming months. If you’re in the US or the UK, we also have a limited number of printed copies that we are offering to send for free. Request a printed copy here.

Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve, let us know what you think.

Join the discussion on

+Android Developers

There are many ways to find success for a game on the international stage: it’s not a simple formula, it’s a combination of things, ranging from localizing effectively to choosing the right price. London-based Space Ape Games brought together a range of resources and tactics to take Samurai Siege into Japan, growing that market to contribute up to 15% of the game’s average $55,000 daily earnings.

John Earner, Simon Hade, and Toby Moore founded Space Ape Games in 2012 with just 12 people. Their goal, to create amazing multiplayer mobile games. Samurai Siege is their first game and they found that Android players have great retention and monetize well. “Our experience has been great with Google Play. We have found that it is half of our audience and half of our business,” says John.

Check out the video below to hear more about how Space Ape expanded to Japan.

Resources to help you grow globally

You can grow your games business worldwide too, and maximize your distribution potential with Google Play. Be sure to check out these resources:

• Reaching players in new territories panel [VIDEO] — Hear first hand experiences from game developers who have successfully taken games to international markets. Antonin Lhuillier (Gameloft), Anatoly Ropotov (Game Insight), Saad Choudri (Miniclip), Eyal Rabinovich (Playscape), and Joe Raeburn (Space Ape Games) share their tips for localization, culturalization, and more.
• Go Global session [VIDEO] — Hyunse Chang, from the Google Play Apps and Games team in Korea, shares key insights into APAC markets and trends among successful apps and games in the region. Leverage these pro tips and best practices to expand your reach to a wider audience.
• Localization checklist — This document identifies the essential aspects of localization, to help you get your app ready for a successful worldwide launch on Google Play.

Join the discussion on

+Android Developers

We’re excited to see the launch of Nexus Player, the first consumer streaming media player running Android TV. Android TV delivers an entertainment experience tailored for users, including movies, shows, games and more.
Now is a great time to develop apps for Android TV that reach a whole new audience.

Starting today, you can publish your apps for Android TV on Google Play, the largest digital store for apps and games. We’ve provided guidance on how to get started building great apps for Android TV in this post.

A high bar for quality experiences

We want to offer the best possible experience for users to enjoy your apps and games. To make this possible, your Android TV app must meet the basic requirements for usability. When your app meets these requirements, users will be able to discover and download it directly on their Android TV devices.

Even if you have already uploaded your app to the Google Play Developer Console, you will need to add TV graphics and screenshots, and opt-in to distribution on TV on the Pricing & Distribution page. For complete information about the requirements and process of publishing your Android TV app for Google Play, make sure to check out the publishing documentation.

Get started!

With our Leanback Library we’ve made it easy for you to extend your existing app to the TV screen or even build a completely new app for Android TV. For a quick look at the Leanback Library, check out this DevBytes video.

We’ve only begun scratching the surface of what’s possible with this new form factor, and we are very excited to see what you will build, start developing today!

Join the discussion on

+Android Developers

How many lines of code will it take to let your users say Ok Google, and search for something in your app? Hardly any. Starting today, all you need is a small addition to your AndroidManifest.xml in order to connect the Google Now SEARCH_ACTION with your searchable activity:

<activity android:name=".SearchableActivity">
    <intent-filter>
        <action android:name="com.google.android.gms.actions.SEARCH_ACTION"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Once you make these changes, your app can receive the SEARCH_ACTION intent containing the SearchManager.QUERY extra with the search expression.

At Google, we always look for innovative ways to help you improve mobile search and drive user engagement back to your app. For example, users can now say to the Google app: “Ok Google, search pizza on Eat24” or “Ok Google, search for hotels in Maui on TripAdvisor.”

This feature is available on English locale Android devices running Jelly Bean and above with the Google app v3.5 or greater. Last but not least, users can enable the Ok Google hot-word detection from any screen, which offers them the fastest route between their search command and your app!

Join the discussion on
+Android Developers

Happy Tuesday! We've had a few questions come in recently regarding Google Accounts on Android, so we've put this post together to show you some of our best practices. The tips today will focus on Android-based authentication, which is easily achieved through the integration of Google Play services. Let's get started.

Unique Identifiers

A common confusion happens when developers use the account name (a.k.a. email address) as the primary key to a Google Account. For instance, when using GoogleApiClient to sign in a user, a developer might use the following code inside of the onConnected callback for a registered GoogleApiClient.ConnectedCallbacks listener:

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
// createLocalAccount() is specific to the app's local storage strategy.
createLocalAccount(accountName);

While it is OK to store the email address for display or caching purposes, it is possible for users to change the primary email address on a Google Account. This can happen with various types of accounts, but these changes happen most often with Google Apps For Work accounts.

So what's a developer to do? Use the Google Account ID (as opposed to the Account name) to key any data for your app that is associated to a Google Account. For most apps, this simply means storing the Account ID and comparing the value each time the onConnected callback is invoked to ensure the data locally matches the currently logged in user. The API provides methods that allow you to get the Account ID from the Account Name. Here is an example snippet you might use:

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
createLocalAccount(accountID);

Person currentUser = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
String accountID = currentUser.getID();
createLocalAccount(accountID);

This will key the local data against a Google Account ID, which is unique and stable for the user even after changing an email address.

So, in the above scenario, if your data was keyed on an ID, you wouldn’t have to worry if your users change their email address. When they sign back in, they’ll still get the same ID, and you won’t need to do anything with your data.

Multiple Accounts

If your app supports multiple account connections simultaneously (like the Gmail user interface shown below), you are calling setAccountName on the GoogleApiClient.Builder when constructing GoogleApiClients. This requires you to store the account name as well as the Google Account ID within your app. However, the account name you’ve stored will be different if the user changes their primary email address. The easiest way to deal with this is to prompt the user to re-login. Then, update the account name when onConnected is called after login. Any time a login occurs you, can use code such as this to compare Account IDs and update the email address stored locally for the Account ID.

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
// isExistingLocalAccount(), createLocalAccount(), 
// getLocalDataAccountName(), and updateLocalAccountName() 
// are all specific to the app's local storage strategy.
boolean existingLocalAccountData = isExistingLocalAccount(accountID);
if (!existingLocalAccountData) {
    // New Login.
    createLocalAccount(accountID, accountName);
} else {
    // Existing local data for this Google Account.
    String cachedAccountName = getLocalDataAccountName(accountID);    
    if (!cachedAccountName.equals(accountName)) {
        updateLocalAccountName(accountID, accountName);
    }
}

This scenario reinforces the importance of using the Account ID to store data all data in your app.

Online data

The same best practices above apply to storing data for Google Accounts in web servers for your app. If you are storing data on your servers in this manner and treating the email address as the primary key:

You need to migrate to this model where the primary key is the Google Account ID.:

If you don't make Google API calls from your web server, you might be able to depend on the Android application to notify your web server of changes to the primary email address when implementing the updateLocalAccountName method referenced in the multiple accounts sample code above. If you make Google API calls from your web server, you likely implemented it using the Cross-client authentication and can detect changes via the OAuth2 client libraries or REST endpoints on your server as well.

Conclusion

When using Google Account authentication for your app, it’s definitely a best practice to use the account ID, as opposed to the account name to distinguish data for the user. In this post, we saw three scenarios where you may need to make changes to make your apps more robust. With the growing adoption of Google for Work, users who are changing their email address, but keeping the same account ID, may occur more frequently, so we encourage all developers to make plans to update their code as soon as possible.

Join the discussion on
+Android Developers

By Roman Nurik, Design Advocate

Android 5.0 brings in material design as the new design system for the platform and system apps. Consumers will soon start getting Android 5.0 and they’re already seeing glimpses of material design with apps like Google Play Newsstand, Inbox by Gmail and Tumblr. Meanwhile, developers now have the Android 5.0 SDK, along with AppCompat for backward compatibility. And designers now have access to Photoshop, Illustrator and Sketch templates. All this means that now—yes now!—is the time to start implementing material design in your Android apps. Today, let’s talk about what implementing material design really boils down to.

Below, you’ll find a material design checklist that you can use to mark progress as you implement the new design system. The checklist is divided into 4 key sections based on the 4 key aspects of material design.

If you include a good chunk of the items in the checklist below, especially the ones indicated as signature elements, and follow traditional Android design best practices (i.e. these, these, and things we discussed on ADiA), you’ll be well on your way to material design awesomeness!

Tangible Surfaces

UIs consist of surfaces (pieces of “digital paper”) arranged at varying elevations, casting shadows on surfaces behind them.

Figure 1. Surfaces and layering.

• Signature element: Shadows are used to communicate which surfaces are in front of others, helping focus attention and establish hierarchy. Read more on depth and layering in UIs.
  In code: This is the android:elevation and android:translationZ attribute in Android 5.0. On earlier versions, shadows are normally provided as PNG assets.
• Shadows and surfaces are used in a consistent and structured way. Each shadow indicates a new surface. Surfaces are created thoughtfully and carefully.
• There are generally between 2 and 10 surfaces on the screen at once; avoid too much layering/nesting of surfaces.
• Scrollable content either scrolls to the edges of the screen or behind another surface that casts a shadow over the content’s surface. Never clip an element against an invisible edge—elements don’t just scroll off into nowhere. Put another way, you rarely scroll the ink on a surface; you scroll the surface itself.
  In code: android:clipToPadding=false often helps with this when using ListView and ScrollView.
• Surfaces have simple, single-color backgrounds.

A Bold, Print-Like Aesthetic

The “digital ink” you draw on those pieces of digital paper is informed by classic print design, with an emphasis on bold use of color and type, contextual imagery, and structured whitespace.

Figure 2. Primary and accent colors.

Figure 3. Keylines.

• Signature element: Apps use a primary color and an accent color (Figure 2) to color surface backgrounds and key UI widgets such as text fields and checkboxes. The accent color contrasts very well with the primary color (for example an app can use a dark blue primary color and a neon pink accent color). The accent color is high-contrast and is used to call attention to key UI elements, like a circular floating action button, selected tab strips, or form fields.
  In code: Set the android:colorPrimary and android:colorAccent attributes in your theme (drop the android prefix if using AppCompat). AppCompat automatically colors text fields, checkboxes, and more on pre-L devices.
• Signature element: On Android 5.0, the status bar is colored to match the app’s primary color, or the current screen’s content. For full-bleed imagery, the status bar can be translucent.
  In code: Set the android:colorPrimaryDark or android:statusBarColor attribute in your theme (drop the android prefix if using AppCompat) or call Window.setStatusBarColor.
• Icons, photos/images, text, and other foreground elements are colored “ink” on their surfaces. They don’t have shadows and don’t use gradients.
• Colors extracted from images can be used to color adjacent UI elements or surfaces.
  In code: This can be done using the Palette support library.
• Signature element: Icons in the app follow the system icon guidelines, and standard icons use the material design icon set.
• Photos are generally immersive and full-bleed. For example, for detail screens, run edge-to-edge and can even appear behind the app bar or status bar.
  In code: The new Toolbar widget (and its AppCompat equivalent) can be transparent and placed directly in your layout. For the status bar, check this Stack Overflow post.
• Signature element: Where appropriate, elements like body text, thumbnails, app bar titles, etc. are aligned to 3 keylines (Figure 3). On phones, those keylines are 16dp and 72dp from the left edge and 16dp from the right edge of the screen. On tablets those values are 24dp and 80dp.
• UI elements are aligned to and sized according to an 8dp baseline grid. For example, app bars are 56dp tall on phones and 64dp tall on tablets. Padding and margins can take on values like 8dp, 16dp, 24dp, etc. More precise text positioning uses a 4dp grid.

Authentic Motion

Motion helps communicate what’s happening in the UI, providing visual continuity across app contexts and states. Motion also adds delight using smaller-scale transitions. Motion isn’t employed simply for motion’s sake.

Figure 4. "Hero" transitions.

• In general, UI and content elements don’t just appear or disappear—they animate into place, either together as a unit, or individually.
• Signature element: When touching an item to see its details, there’s a “hero” transition (Figure 4) that moves and scales the item between its position in the browsing screen and its position in the detail screen.
  In code: These are called “shared element transitions” in the SDK. The support version of FragmentTransaction also includes some shared element support.
• Signature element: Ripple effects originating from where you touched the screen are used to show touch feedback on an item.
  In code: The default android:selectableItemBackground and android:selectableItemBackgroundBorderless have this, or you can use RippleDrawable (<ripple>) to customize the effect. On pre-5.0 devices, ripples aren’t an expected feature, so defer to the default android:selectableItemBackground behavior.
• Signature element: UI elements can appear using a circular “reveal” animation.
  In code: See this doc or the ViewAnimationUtils class for more.
• Signature element: Animations are used in more subtle, delightful ways, such as to convey the transition between icon states or text states. For example, a “+” icon can morph into an “x” symbol, or an outlined heart icon can be filled using a paint-bucket fill effect.
  In code: Icon transitions can be implemented using AnimatedStateListDrawable and its XML counterpart. An example can be found in the Google I/O app source. There’s also support for animated vector icons.
• Animations and transitions are fast—generally under 300ms.
• Crossfades are often replaced by translate/slide transitions: vertical slides for descendant navigation and horizontal slides for lateral navigation. For slide transitions, prefer quick acceleration and gentle ease-in deceleration over simple linear moves. See the material design spec on motion for more.

Adaptive Design (and UI Patterns)

Tangible surfaces, bold graphic design, and meaningful motion work together to bring a consistent experience across any screen, be it phones, tablets, laptops, desktops, TVs, wearables, or even cars. Additionally, the key UI patterns below help establish a consistent character for the app across devices.

Figure 5. The floating action button.

• The app uses responsive design best practices to ensure screens lay themselves out appropriately on any screen size, in any orientation. See the Tablet App Quality Checklist for a list of ways to optimize for tablets, and this blog post for high-level tablet optimization tips.
  • In material design, detail screens are often presented as popups that appear using “hero” transitions (see above).
  • In multi-pane layouts, the app can use multiple toolbars to place actions contextually next to their related content.
• Signature element: Where appropriate, the app promotes the key action on a screen using a circular floating action button (FAB). The FAB (Figure 5) is a circular surface, so it casts a shadow. It is colored with a bright, accent color (see above). It performs a primary action such as send, compose, create, add, or search. It floats in front of other surfaces, and is normally at an 8dp elevation. It frequently appears at the bottom right of the screen, or centered on an edge where two surfaces meet (a seam or a step).

App bar

• Signature element: The app uses a standard Android app bar. The app bar doesn’t have an app icon. Color and typography are used for branding instead. The app bar casts a shadow (or has a shadow cast on it by a surface below and behind it). The app bar normally has a 4dp elevation.
  In code: Use the new Toolbar widget in Android 5.0 that is placed directly into the activity’s view hierarchy. AppCompat also provides android.support.v7.widget.Toolbar, which supports all modern platform versions.
• The app bar might be for example 2 or 3 times taller than the standard height; on scroll, the app bar can smoothly collapse into its normal height.
• The app bar might be completely transparent in some cases, with the text and actions overlaying an image behind it. For example, see the Google Play Newsstand app.
• App bar titles align to the 2nd keyline (see more info on keylines above)
  In code: when using the Toolbar widget, use the android:contentInsetStart attribute.
• Where appropriate, upon scrolling down, the app bar can scroll off the screen, leaving more vertical space for content. Upon scrolling back up, the app bar should be shown again.

Tabs

Figure 6. Tabs with material design.

• Signature element: Tabs follow the newer material design interactions and styling (Figure 6). There are no vertical separators between tabs. If the app uses top-level tabs, tabs are visually a part of the app bar; tabs are a part of the app bar’s surface.
  In code: See the SlidingTabsBasic sample code in the SDK or the Google I/O app source (particularly the "My Schedule" section for phones).
• Tabs should support a swipe gesture for moving between them.
  In code: All tabs should be swipeable using the ViewPager widget, which is available in the support library.
• Selected tabs are indicated by a foreground color change and/or a small strip below the tab text (or icon) colored with an accent color. The tab strip should smoothly slide as you swipe between tabs.

Navigation drawer

Figure 7. Navigation drawers
with material design.

• Signature element: If the app uses a navigation drawer, it follows the newer material design interactions and styling (Figure 7). The drawer appears in front of the app bar. It also appears semitransparent behind the status bar.
  In code: Implement drawers using the DrawerLayout widget from the support library, along with the new Toolbar widget discussed above. See this Stack Overflow post for more.
• Signature element: The leftmost icon in the app bar is a navigation drawer indicator; the app icon is not visible in the app bar. Optionally, on earlier versions of the platform, if the app has a drawer, the top-left icon can remain the app icon and narrower drawer indicator, as in Android 4.0.
• The drawer is a standard width: No wider than 320dp on phones and 400dp on tablets, but no narrower than the screen width minus the standard toolbar height (360dp - 56dp = 304dp on the Nexus 5)
• Item heights in the drawer follow the baseline grid: 48dp tall rows, 8dp above list sections and 8dp above and below dividers.
• Text and icons should follow the keylines discussed above.

More and more apps from Google and across the Google Play ecosystem will be updating with material design soon, so expect Winter 2014 to be a big quarter for design on Android. For more designer resources on material design, check out the DesignBytes series. For additional developer resources, check the Creating Apps with Material Design docs!

Join the discussion on

+Android Developers

Material design is a comprehensive approach to visual, interaction and motion design for the multi-screen world. Android 5.0 Lollipop and the updated support libraries help you to create material UIs. Here’s a rundown of some of the major elements of material design and the APIs and widgets that you can use to implement them in your app.

Tangible surfaces

In material design, UIs are composed of pieces of digital paper & ink. The surfaces and the shadows they cast provide visual cues to the structure of the application, what you can touch and how it will move. This digital material can move, expand and reform to create flexible UIs.

Shadows

A surface’s position and depth result in subtle changes in lighting and shadows. The new elevation property lets you specify a view’s position on the Z-axis and the framework then casts a real-time dynamic shadow on items behind it. You can set the elevation declaratively in your layouts, defined in dips:

<ImageView …
    android:elevation="8dp" />

You can also set this from code using getElevation()/setElevation() (with shims in ViewCompat). The shadow a view casts is defined by its outline, which by default is derived from its background. For example if you set a circular shape drawable as the background for a floating action button, then it would cast an appropriate shadow. If you need finer control of a view’s shadow, you can set a ViewOutlineProvider which can customise the Outline in getOutline().

Cards

Cards are a common pattern for creating surfaces holding a distinct piece of information. The new CardView support library allows you to create them easily, providing outlines and shadows for you (with equivalent behaviour on prior platforms).

<android.support.v7.widget.CardView
    android:layout_width="match_parent"
    android:layout_height="wrap_content">
    <!-- Your card content -->

</android.support.v7.widget.CardView>

CardView extends FrameLayout and provides default elevation and corner radius for you so that cards have a consistent appearance across the platform. You can customise these via the cardElevation and cardCornerRadius attributes, if required. Note that Cards are not the only way of achieving dimensionality and you should be wary of over-cardifying your UI!

Print-like Design

Material utilises classic principles from print design to create clean, simple layouts that put your content front and center. Bold deliberate color choices, intentional whitespace, tasteful typography and a strong baseline grid create hierarchy, meaning and focus.

Typography

Android 5.0 updates the system font Roboto to beautifully and clearly display text no matter the display size. A new medium weight has been added (android:fontFamily=”sans-serif-medium”) and new TextAppearance styles implement the recommended typographic scale for balancing content density and reading comfort. For instance you can easily use the ‘Title’ style by setting android:textAppearance=”@android:style/TextAppearance.Material.Title”. These styles are available on older platforms through the AppCompat support library, e.g. “@style/TextAppearance.AppCompat.Title”.

Color

Your application’s color palette brings branding and personality to your app so we’ve made it simple to colorize UI controls by using the following theme attributes:

• colorPrimary. The primary branding color for the app; used as the action bar background, recents task title and in edge effects.
• colorAccent. Vibrant complement to the primary branding color. Applied to framework controls such as EditText and Switch.
• colorPrimaryDark. Darker variant of the primary branding color; applied to the status bar.

Further attributes give fine grained control over colorizing controls, see: colorControlNormal, colorControlActivated, colorControlHighlight, colorButtonNormal, colorSwitchThumbNormal, colorEdgeEffect, statusBarColor and navigationBarColor.

AppCompat provides a large subset of the functionality above, allowing you to colorize controls on pre-Lollipop platforms.

Dynamic color

Material Design encourages dynamic use of color, especially when you have rich images to work with. The new Palette support library lets you extract a small set of colors from an image to style your UI controls to match; creating an immersive experience. The extracted palette will include vibrant and muted tones as well as foreground text colors for optimal legibility. For example:

Palette.generateAsync(bitmap,
        new Palette.PaletteAsyncListener() {
    @Override
    public void onGenerated(Palette palette) {
         Palette.Swatch vibrant =
                 palette.getVibrantSwatch();
          if (swatch != null) {
              // If we have a vibrant color
              // update the title TextView
              titleView.setBackgroundColor(
                  vibrant.getRgb());
              titleView.setTextColor(
                  vibrant.getTitleTextColor());
          }
    }
});

Authentic Motion

Tangible surfaces don’t just appear out of nowhere like a jump-cut in a movie; they move into place helping to focus attention, establish spatial relationships and maintain continuity. Materials respond to touch to confirm your interaction and all changes radiate outward from your touch point. All motion is meaningful and intimate, aiding the user’s comprehension.

Activity + Fragment Transitions

By declaring ‘shared elements’ that are common across two screens you can create a smooth transition between the two states.

album_grid.xml
…
    <ImageView
        …
        android:transitionName="@string/transition_album_cover" />
album_details.xml
…
    <ImageView
        …
        android:transitionName="@string/transition_album_cover" />

AlbumActivity.java
Intent intent = new Intent();
String transitionName = getString(R.string.transition_album_cover);
…
ActivityOptionsCompat options =
ActivityOptionsCompat.makeSceneTransitionAnimation(activity,
    albumCoverImageView,   // The view which starts the transition
    transitionName    // The transitionName of the view we’re transitioning to
    );
ActivityCompat.startActivity(activity, intent, options.toBundle());

Here we define the same transitionName in two screens. When starting the new Activity and this transition is animated automatically. In addition to shared elements, you can now also choreograph entering and exiting elements.

Ripples

Materials respond to users’ touch with an ink ripple surface reaction. Interactive controls such as Buttons exhibit this behaviour by default when you use or inherit from Theme.Material (as will ?android:selectableItemBackground). You can add this feedback to your own drawables by simply wrapping them in a ripple element:

<ripple
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:color="@color/accent_dark">
    <item>
        <shape
            android:shape="oval">
            <solid android:color="?android:colorAccent" />
        </shape>
    </item>
</ripple>

Custom views should propagate touch location down to their drawables in the View#drawableHotspotChanged callback so that the ripple can start from the touch point.

StateListAnimator

Materials also respond to touch by raising up to meet your finger, like a magnetic attraction. You can achieve this effect by animating the translationZ attribute which is analogous to elevation but intended for transient use; such that Z = elevation + translationZ. The new stateListAnimator attribute allows you to easily animate the translationZ on touch (Buttons do this by default):

layout/your_layout.xml
<ImageButton …
    android:stateListAnimator="@anim/raise" />
anim/raise.xml
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_enabled="true" android:state_pressed="true">
        <objectAnimator
            android:duration="@android:integer/config_shortAnimTime"
            android:propertyName="translationZ"
            android:valueTo="@dimen/touch_raise"
            android:valueType="floatType" />
    </item>
    <item>
        <objectAnimator
            android:duration="@android:integer/config_shortAnimTime"
            android:propertyName="translationZ"
            android:valueTo="0dp"
            android:valueType="floatType" />
    </item>
</selector>

Reveal

A hallmark material transition for showing new content is to reveal it with an expanding circular mask. This helps to reinforce the user’s touchpoint as the start of all transitions, with its effects radiating outward radially. You can implement this using the following Animator:

Animator reveal = ViewAnimationUtils.createCircularReveal(
                    viewToReveal, // The new View to reveal
                    centerX,      // x co-ordinate to start the mask from
                    centerY,      // y co-ordinate to start the mask from
                    startRadius,  // radius of the starting mask
                    endRadius);   // radius of the final mask
reveal.start();

Interpolators

Motion should be deliberate, swift and precise. Unlike typical ease-in-ease-out transitions, in Material Design, objects tend to start quickly and ease into their final position. Over the course of the animation, the object spends more time near its final destination. As a result, the user isn’t left waiting for the animation to finish, and the negative effects of motion are minimized. A new fast-in-slow-out interpolator has been added to achieve this motion.

For elements entering and exiting the screen (which should do so at peak velocity), check out the linear-out-slow-in and fast-out-linear-in interpolators respectively.

Adaptive design

Our final core concept of material is creating a single adaptive design that works across devices of all sizes and shapes, from watches to giant TVs. Adaptive design techniques help us realize the vision that each device reflects a different view of the same underlying system. Each view is tailored to the size and interaction appropriate for that device. Colors, iconography, hierarchy, and spatial relationships remain constant. The material design system provides flexible components and patterns to help you build a design that scales.

Toolbar

The toolbar is a generalization of the action bar pattern, providing similar functionality, but much more flexibility. Unlike the standard action bar, toolbar is a view in your hierarchy just like any other, so you can place instances wherever you like, interleave them with the rest of your views, animate, react to scroll events and so on. You can make the Toolbar act as your Activity’s Action Bar by calling Activity.setActionBar().

In this example, the blue toolbar is an extended height, overlaid by the screen content and provides the navigation button. Note that two further toolbars are used in the list and detail views.

For details of implementing toolbars, see this post.

Go Forth and Materialize

Material Design helps you to build understandable, beautiful and adaptive apps, which are alive with motion. Hopefully, this post has inspired you to apply these principles to your app and signposted some of the new (and compatibility) APIs to achieve this.

Join the discussion on

+Android Developers

Updated material design Tumblr app on Nexus 6.

Last week, we unveiled the Nexus 6 and Nexus 9, the newest additions to our Nexus family that will ship with Android 5.0 Lollipop. Together, they deliver a pure Google experience, showcasing fresh visual styles with material design, improved performance, and additional features.

Let’s make sure your apps and games are optimized to give your users the best mobile experience on these devices. We’ve outlined some best practices below.

Nexus 6

Screen

The Nexus 6 boasts an impressive 5.96” Quad HD screen display at a resolution of 2560 x 1440 (493 ppi). This translates to ~ 730 x 410 dp (density independent pixels).

Check your assets

It has a quantized density of 560 dpi, which falls in between the xxhdpi and xxxhdpi primary density buckets. For the Nexus 6, the platform will scale down xxxhdpi assets, but if those aren’t available, then it will scale up xxhdpi assets.

Provide at least an xxxhdpi app icon because devices can display large app icons on the launcher. It’s best practice to place your app icons in mipmap- folders (not the drawable- folders) because they are used at resolutions different from the device’s current density. For example, an xxxhdpi app icon can be used on the launcher for an xxhdpi device.

res/
   mipmap-mdpi/
      ic_launcher.png
   mipmap-hdpi/
      ic_launcher.png
   mipmap-xhdpi/
      ic_launcher.png  
   mipmap-xxhdpi/
      ic_launcher.png
   mipmap-xxxhdpi/   
      ic_launcher.png  # App icon used on Nexus 6 device launcher

Choosing to add xxxhdpi versions for the rest of your assets will provide a sharper visual experience on the Nexus 6, but does increase apk size, so you should make an appropriate decision for your app.

res/
   drawable-mdpi/
      ic_sunny.png
   drawable-hdpi/
      ic_sunny.png
   drawable-xhdpi/   
      ic_sunny.png
   drawable-xxhdpi/  # Fall back to these if xxxhdpi versions aren’t available
      ic_sunny.png 
   drawable-xxxhdpi/ # Higher resolution assets for Nexus 6
      ic_sunny.png

Make sure you are not filtered on Google Play

If you are using the <compatible-screens> element in the AndroidManifest.xml file, you should stop using it because it’s not scalable to re-compile and publish your app each time new devices come out. However, if you must use it, make sure to update the manifest to add the configuration for these devices (by screen size and density). Otherwise your app may be excluded from Google Play search results on these devices.

Nexus 9

Screen

The Nexus 9 is a premium 8.9” tablet with a screen size of 2048 x 1536 pixels (288 ppi), which translates to 1024 x 768 dip. This is a 4:3 aspect ratio, which is unique compared to earlier tablets. The Nexus 9 falls into the xhdpi density bucket, and you should already have assets in the drawable-xhdpi folder.

Updated Material Design Wall Street Journal app on Nexus 9.

Enable NDK apps for 64-bit

The Nexus 9 runs on a 64-bit Dual Core processor, which makes it the first Android device to ship with a 64-bit ARM instruction set. Support for 64-bit processors was just added in Android 5.0, so if you have an NDK app, enable it by updating the APP_ABI value in your Application.mk file:

APP_ABI := armeabi armeabi-v7a arm64-v8a x86 x86_64 mips mips64

More detailed instructions are provided in the developer site. You can test your 64-bit enabled app on a physical device with a 64-bit processor running Android 5.0, or take advantage of the recently announced 64-bit emulator in Android Studio.

Update your hardware keyboard support

The Nexus 9 Keyboard Folio will be available as an accessory in Google Play. It’s very important that you don’t lock your app to a single orientation. The Nexus 9’s natural orientation is portrait mode, while it’s used in landscape mode with the keyboard. If you lock to the device’s natural orientation, the app may appear sideways for devices with keyboards.

Users should be able to navigate around the main content of the app with the keyboard, while relying on touch input or keyboard shortcuts for toolbar actions and button bars. Therefore, ensure that your app has proper keyboard navigation and shortcuts for primary actions. Keyboard shortcuts that are invoked with Ctrl + [shortcut] combo can be defined via menu items using:

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/menu_create"
        android:title="@string/menu_create"
        android:alphabeticShortcut="c” />
</menu/>

Alternatively, shortcuts can be defined using Activity#onKeyShortcut or View#onKeyShortcut. Learn more about keyboard actions here.

In MainActivity.java:

@Override
public boolean onKeyShortcut(int keyCode, KeyEvent event) {
    switch (keyCode) {
        case KeyEvent.KEYCODE_R:
            Toast.makeText(this, "Reply", Toast.LENGTH_SHORT).show();
            return true;
        default:
            return super.onKeyShortcut(keyCode, event);
    }
}

Responsive layouts with w- and sw- qualifiers

In order to take advantage of the screen real estate on the Nexus 6 and Nexus 9, we emphasize the importance of responsive design. In the past, if you assumed that landscape mode is significantly wider than portrait mode, you may run into problems on a device like the Nexus 9, which has an aspect ratio of 4:3. Instead of declaring layouts using the layout-land or layout-port resource folder qualifiers, we strongly recommend switching to the w<N>dp width resource folder qualifier so that content is laid out based on available screen width.

Think about content first and foremost. Decide on min and max screen real estate that your content requires, and determine cutoff points at different screen widths where you can modify the layout composition for your app (# of grid columns, multi-pane layout, etc…).

For example, a single pane layout for your main activity on phones can be defined in:

res/layout/activity_main.xml

On larger screen devices, where the current orientation is at least 600dp in width, a new two-pane layout with a list alongside a detail pane could be declared in:

res/layout-w600dp/activity_main.xml

On even larger screen devices, where the current orientation is at least 720dp in width, a new multi-pane layout where the detail pane requires even more horizontal space could be declared in:

res/layout-w720dp/activity_main.xml

As for attributes based on form factor, instead of declaring them in values-large or values-xlarge resource directories, use the sw<N>dp smallest width qualifier. For example, you could style your TextViews to have a medium font size on phones.

In res/values/styles.xml:

<style name="DescriptionTextStyle">
  <item name="android:textAppearance">?android:attr/textAppearanceMedium</item>
</style>

Meanwhile, TextViews could have a large font size when the smallest width of the device (taking the minimum of the landscape and portrait widths) is 600dp or wider. This ensures the font size of your app doesn’t change when you rotate this large screen device.

In res/values-sw600dp/styles.xml:

<style name="DescriptionTextStyle">
  <item name="android:textAppearance">?android:attr/textAppearanceLarge</item>
</style> 

Take advantage of 5.0 and Material

Set your android:targetSdkVersion to "21". Take note of the important behavior changes in Android 5.0 Lollipop including ART, the new Android runtime, to ensure that your app continues to run well. You can also leverage new platform APIs like richer notifications.

Nexus 6 and Nexus 9 users will be immersed in the new world of material design, and they’ll expect the same seamless transitions, bold colors, and delightful details from your app. As you invest time in bringing your app up to date with our latest design language, there’s a whole host of resources to help you make the leap, including important new updates to the support library, videos, and a getting started guide. Good luck and we can’t wait to see your apps!

Join the discussion on

+Android Developers

With the latest release of Android Wear, wearables with built-in GPS like the Sony Smartwatch 3 can now give you a GPS location update directly from the wearable, without a paired phone nearby. You can now build an app like MyTracks that lets a user track their run even when they leave their phone at home. For wearable devices that do not have built-in GPS, a software solution has always existed in Google Play Services that automatically uses the GPS from your connected phone.

The Golfshot wearable app uses built-in GPS to calculate your distance to the next hole, even when you don’t have your phone with you.

Implementing GPS location updates

Implementing GPS location updates for Android Wear is simple. On the wearable, use the FusedLocationProviderApi from Google Play services to request location updates. This is the same API that has been available on mobile, so you can easily reuse your existing code and samples.

FusedLocationProviderApi automatically makes the most power-efficient decision about where to get location updates. If the phone is connected to the wearable, it uses the GPS on the phone and sends the updates to the wearable. If the phone is not connected to the wearable and the wearable has a built-in GPS, then it uses the wearable’s GPS.

One case you’ll need to handle is if the phone is not connected to the wearable and the wearable does not have built-in GPS. You will need to detect this and provide a graceful recovery mechanism, such as a message telling the user to bring their phone with them. However, for the most part, deciding which GPS to use, and sending the position from the phone to the wearable, is handled automatically. You do not need to deal with the low-level implementation details yourself.

Data synchronization

When writing an app that runs on the wearable, you will eventually want to synchronize the data it collects with the paired phone. When the wearable is being taken out for a run, especially with the built-in GPS, there may not be a phone present. So you will want to store your location data using the Data Layer API, and when the phone reconnects with the wearable later, the data will be automatically synchronized.

For more details about how to use the location API, check out the extensive documentation and sample here.

Android Wear apps on Google Play

Also, as a heads up, starting on November 3 with the public release of Android 5.0, you will be able to submit your apps for clearer designation as Android Wear apps on Google Play. If your apps follow the criteria in the Wear App Quality checklist and are accepted as Wear apps on Play, it will be easier for Android Wear users to discover your apps. Stay tuned for more information about how to submit your apps for Android Wear review through the Google Play Developer Console.

Join the discussion on

+Android Developers

The Android 5.0 SDK was released last Friday, featuring new UI widgets and material design, our visual language focused on good design. To enable you to bring your latest designs to older Android platforms we have expanded our support libraries, including a major update to AppCompat, as well as new RecyclerView, CardView and Palette libraries.

In this post we'll take a look at what’s new in AppCompat and how you can use it to support material design in your apps.

What's new in AppCompat?

AppCompat (aka ActionBarCompat) started out as a backport of the Android 4.0 ActionBar API for devices running on Gingerbread, providing a common API layer on top of the backported implementation and the framework implementation. AppCompat v21 delivers an API and feature-set that is up-to-date with Android 5.0

In this release, Android introduces a new Toolbar widget. This is a generalization of the Action Bar pattern that gives you much more control and flexibility. Toolbar is a view in your hierarchy just like any other, making it easier to interleave with the rest of your views, animate it, and react to scroll events. You can also set it as your Activity’s action bar, meaning that your standard options menu actions will be display within it.

You’ve likely already been using the latest update to AppCompat for a while, it has been included in various Google app updates over the past few weeks, including Play Store and Play Newsstand. It has also been integrated into the Google I/O Android app, pictured above, which is open-source.

Setup

If you’re using Gradle, add appcompat as a dependency in your build.gradle file:

dependencies {
    compile "com.android.support:appcompat-v7:21.0.+"
}

New integration

If you are not currently using AppCompat, or you are starting from scratch, here's how to set it up:

• All of your Activities must extend from ActionBarActivity, which extends from FragmentActivity from the v4 support library, so you can continue to use fragments.
• All of your themes (that want an Action Bar/Toolbar) must inherit from Theme.AppCompat. There are variants available, including Light and NoActionBar.
• When inflating anything to be displayed on the action bar (such as a SpinnerAdapter for list navigation in the toolbar), make sure you use the action bar’s themed context, retrieved via getSupportActionBar().getThemedContext().
• You must use the static methods in MenuItemCompat for any action-related calls on a MenuItem.

For more information, see the Action Bar API guide which is a comprehensive guide on AppCompat.

Migration from previous setup

For most apps, you now only need one theme declaration, in values/:

values/themes.xml:

<style name="Theme.MyTheme" parent="Theme.AppCompat.Light">
    <!-- Set AppCompat’s actionBarStyle -->
    <item name="actionBarStyle">@style/MyActionBarStyle</item>

    <!-- Set AppCompat’s color theming attrs -->
    <item name=”colorPrimary”>@color/my_awesome_red</item>
    <item name=”colorPrimaryDark”>@color/my_awesome_darker_red</item>
    
    <!-- The rest of your attributes -->
</style>

You can now remove all of your values-v14+ Action Bar styles.

Theming

AppCompat has support for the new color palette theme attributes which allow you to easily customize your theme to fit your brand with primary and accent colors. For example:

values/themes.xml:

<style name="Theme.MyTheme" parent="Theme.AppCompat.Light">
    <!-- colorPrimary is used for the default action bar background -->
    <item name=”colorPrimary”>@color/my_awesome_color</item>

    <!-- colorPrimaryDark is used for the status bar -->
    <item name=”colorPrimaryDark”>@color/my_awesome_darker_color</item>

    <!-- colorAccent is used as the default value for colorControlActivated,
         which is used to tint widgets -->
    <item name=”colorAccent”>@color/accent</item>

    <!-- You can also set colorControlNormal, colorControlActivated
         colorControlHighlight, and colorSwitchThumbNormal. -->
    
</style>

When you set these attributes, AppCompat automatically propagates their values to the framework attributes on API 21+. This automatically colors the status bar and Overview (Recents) task entry.

On older platforms, AppCompat emulates the color theming where possible. At the moment this is limited to coloring the action bar and some widgets.

Widget tinting

When running on devices with Android 5.0, all of the widgets are tinted using the color theme attributes we just talked about. There are two main features which allow this on Lollipop: drawable tinting, and referencing theme attributes (of the form ?attr/foo) in drawables.

AppCompat provides similar behaviour on earlier versions of Android for a subset of UI widgets:

• Everything provided by AppCompat’s toolbar (action modes, etc)
• EditText
• Spinner
• CheckBox
• RadioButton
• Switch (use the new android.support.v7.widget.SwitchCompat)
• CheckedTextView

You don’t need to do anything special to make these work, just use these controls in your layouts as usual and AppCompat will do the rest (with some caveats; see the FAQ below).

Toolbar Widget

Toolbar is fully supported in AppCompat and has feature and API parity with the framework widget. In AppCompat, Toolbar is implemented in the android.support.v7.widget.Toolbar class. There are two ways to use Toolbar:

• Use a Toolbar as an Action Bar when you want to use the existing Action Bar facilities (such as menu inflation and selection, ActionBarDrawerToggle, and so on) but want to have more control over its appearance.
• Use a standalone Toolbar when you want to use the pattern in your app for situations that an Action Bar would not support; for example, showing multiple toolbars on the screen, spanning only part of the width, and so on.

Action Bar

To use Toolbar as an Action Bar, first disable the decor-provided Action Bar. The easiest way is to have your theme extend from Theme.AppCompat.NoActionBar (or its light variant).

Second, create a Toolbar instance, usually via your layout XML:

<android.support.v7.widget.Toolbar
    android:id=”@+id/my_awesome_toolbar”
    android:layout_height=”wrap_content”
    android:layout_width=”match_parent”
    android:minHeight=”?attr/actionBarSize”
    android:background=”?attr/colorPrimary” />

The height, width, background, and so on are totally up to you; these are just good examples. As Toolbar is just a ViewGroup, you can style and position it however you want.

Then in your Activity or Fragment, set the Toolbar to act as your Action Bar:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.blah);

    Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);
    setSupportActionBar(toolbar);
}

From this point on, all menu items are displayed in your Toolbar, populated via the standard options menu callbacks.

Standalone

The difference in standalone mode is that you do not set the Toolbar to act as your action bar. For this reason, you can use any AppCompat theme and you do not need to disable the decor-provided Action Bar.

In standalone mode, you need to manually populate the Toolbar with content/actions. For instance, if you want it to display actions, you need to inflate a menu into it:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.blah);

    Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);

    // Set an OnMenuItemClickListener to handle menu item clicks
    toolbar.setOnMenuItemClickListener(new Toolbar.OnMenuItemClickListener() {
        @Override
        public boolean onMenuItemClick(MenuItem item) {
            // Handle the menu item
            return true;
        }
    });

    // Inflate a menu to be displayed in the toolbar
    toolbar.inflateMenu(R.menu.your_toolbar_menu);
}

There are many other things you can do with Toolbar. For more information, see the Toolbar API reference.

Styling

Styling of Toolbar is done differently to the standard action bar, and is set directly onto the view.

Here's a basic style you should be using when you're using a Toolbar as your action bar:

<android.support.v7.widget.Toolbar  
    android:layout_height="wrap_content"
    android:layout_width="match_parent"
    android:minHeight="?attr/actionBarSize"
    app:theme="@style/ThemeOverlay.AppCompat.ActionBar" />

The app:theme declaration will make sure that your text and items are using solid colors (i.e 100% opacity white).

DarkActionBar

You can style Toolbar instances directly using layout attributes. To achieve a Toolbar which looks like 'DarkActionBar' (dark content, light overflow menu), provide the theme and popupTheme attributes:

<android.support.v7.widget.Toolbar
    android:layout_height=”wrap_content”
    android:layout_width=”match_parent”
    android:minHeight=”@dimen/triple_height_toolbar”
    app:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
    app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

SearchView Widget

AppCompat offers Lollipop’s updated SearchView API, which is far more customizable and styleable (queue the applause). We now use the Lollipop style structure instead of the old searchView* theme attributes.

Here’s how you style SearchView:

values/themes.xml:
<style name=”Theme.MyTheme” parent=”Theme.AppCompat”>
    <item name=”searchViewStyle”>@style/MySearchViewStyle</item>
</style>
<style name=”MySearchViewStyle” parent=”Widget.AppCompat.SearchView”>
    <!-- Background for the search query section (e.g. EditText) -->
    <item name="queryBackground">...</item>
    <!-- Background for the actions section (e.g. voice, submit) -->
    <item name="submitBackground">...</item>
    <!-- Close button icon -->
    <item name="closeIcon">...</item>
    <!-- Search button icon -->
    <item name="searchIcon">...</item>
    <!-- Go/commit button icon -->
    <item name="goIcon">...</item>
    <!-- Voice search button icon -->
    <item name="voiceIcon">...</item>
    <!-- Commit icon shown in the query suggestion row -->
    <item name="commitIcon">...</item>
    <!-- Layout for query suggestion rows -->
    <item name="suggestionRowLayout">...</item>
</style>

You do not need to set all (or any) of these, the defaults will work for the majority of apps.

Toolbar is coming...

Hopefully this post will help you get up and running with AppCompat and let you create some awesome material apps. Let us know in the comments/G+/Twitter if you’re have questions about AppCompat or any of the support libraries, or where we could provide more documentation.

FAQ

Why is my EditText (or other widget listed above) not being tinted correctly on my pre-Lollipop device?

The widget tinting in AppCompat works by intercepting any layout inflation and inserting a special tint-aware version of the widget in its place. For most people this will work fine, but I can think of a few scenarios where this won’t work, including:

• You have your own custom version of the widget (i.e. you’ve extended EditText)
• You are creating the EditText without a LayoutInflater (i.e., calling new EditText()).

The special tint-aware widgets are currently hidden as they’re an unfinished implementation detail. This may change in the future.

Why has X widget not been material-styled when running on pre-Lollipop?

Only some of the most common widgets have been updated so far. There are more coming in future releases of AppCompat.

Why does my Action Bar have a shadow on Android Lollipop? I’ve set android:windowContentOverlay to null.

On Lollipop, the action bar shadow is provided using the new elevation API. To remove it, either call getSupportActionBar().setElevation(0), or set the elevation attribute in your Action Bar style.

Why are there no ripples on pre-Lollipop?

A lot of what allows RippleDrawable to run smoothly is Android 5.0’s new RenderThread. To optimize for performance on previous versions of Android, we've left RippleDrawable out for now.

How do I use AppCompat with Preferences?

You can continue to use PreferenceFragment in your ActionBarActivity when running on an API v11+ device. For devices before that, you will need to provide a normal PreferenceActivity which is not material-styled.

Join the discussion on

+Android Developers

Android 5.0 Lollipop is the biggest update of Android to date, introducing an all new visual style, improved performance, and much more. Android 5.0 Lollipop also extends across screens big and small, including phones, tablets, wearables, TVs and cars, to give your users access to information when they need it most.

To get you started on developing and testing on Android 5.0 Lollipop, here are some of the developer highlights with links to related videos and documentation.

User experience

• Material design for the multiscreen world — Material Design is a new approach for designing apps in today’s multi-device world that takes a comprehensive strategy to visual, motion, and interaction design across a number of platforms and form factors. Android 5.0 brings Material Design to the platform, with a full set of tools for implementing material design in your apps. The system is incredibly flexible, allowing your app to express its individual character and brand with bold colors and a variety of responsive UI patterns and themeable elements.
• Enhanced notifications — New lockscreen notifications let you surface content, updates, and actions to users at a glance, without needing to unlock their device. Heads-up notifications let you display content and actions in a small floating window managed by the system, no matter which app is in the foreground. Notifications are refreshed for Material Design and you can use accent colors to express your brand.
• Concurrent documents in Overview — Now you can organize your app by tasks and present these concurrently as individual “documents” on the Overview screen. For example, instant messaging apps could declare each chat as a separate document. Users can flip through these on the Overview screen to find the specific chat they want and jump straight to it.

Performance

• Android Runtime (ART) — Android 5.0 runs exclusively on the ART runtime. ART offers ahead-of-time (AOT) compilation, more efficient garbage collection, and improved development and debugging features. In many cases it improves performance of the device, without you having to change your code.
• 64-bit support — Support for 64-bit ABIs provides additional address space and improved performance with certain compute workloads. Apps written in the Java language can run immediately on 64-bit architectures with no modifications required. NDK r10c includes 64-bit support, for apps and games using native code.
• Project Volta — New tools and APIs help you build battery-efficient apps. Battery Historian, a tool included in the SDK, lets you visualize power events over time and understand how your app is using battery. The JobScheduler API lets you set the conditions under which your background tasks and other jobs should run, such as when the device is idle or connected to an unmetered network or to a charger, to minimize battery impact. More in this I/O video.
• OpenGL ES 3.1 and Android Extension Pack — With OpenGL ES 3.1, you get compute shaders, stencil textures, and texture gather for your games. Android Extension Pack (AEP) is a new set of extensions to OpenGL ES that bring desktop-class graphics to Android including tessellation and geometry shaders, and use ASTC texture compression across GPU technologies. More on what's new for game developers in this DevBytes video.
• WebView updates — We’ve updated WebView to support WebRTC, WebAudio and WebGL will be supported. WebView also includes native support for all of the Web Components specifications: Custom Elements, Shadow DOM, HTML Imports, and Templates. WebView is now unbundled from the system and will be regularly updated through Google Play.

Workplace

• Managed provisioning and unified view of apps — to make it easier for employees to have a single device for personal and work use, framework enhancements offer a unified view of apps, notifications & recents across work apps and personal apps. Profile owner APIs, in the workplace context, let administrators create and manage work profiles and defined as part of a new managed provisioning process. More in this I/O video.

Media

• Advanced camera capabilities — A new camera API gives you new capabilities for advanced image capture and processing. On supported devices, your app can capture uncompressed YUV capture at full 8 megapixel resolution at 30 FPS. You can also capture raw sensor data and control parameters such as exposure time, ISO sensitivity, and frame duration, on a per-frame basis.
• Audio improvements — The sound architecture has been enhanced, with lower input latency in OpenSL, the addition of multichannel-mixing, and USB digital audio mode support. More in this I/O video.

Connectivity

• BLE Peripheral Mode — Android devices can now function in Bluetooth Low Energy (BLE) peripheral mode. Apps can use this capability to broadcast their presence to nearby devices — for example, you can now build apps that let a device function as a beacon and transmit data to another BLE device. More in this I/O video.
• Multi-networking — Apps can dynamically request networks based on capabilities such as metered or unmetered. This is useful when you want to use a specific network, such as cellular. Apps can also request platform to re-evaluate networks for an internet connection. This is useful when your app sees unusually high latency on a particular network, it can enable the platform to switch to a better network (if available) sooner with a graceful handoff.

Get started!

You can get started developing and testing on Android 5.0 right away by downloading the Android 5.0 Platform (API level 21), as well as the SDK Tools, Platform Tools, and Support Package from the Android SDK Manager.

Check out the DevByte video below for more of what’s new in Lollipop!

Join the discussion on
+Android Developers

Two more weeks!

By Jamal Eason, Product Manager, Android

At Google I/O last June, we gave you an early version of Android 5.0 with the L Developer Preview, running on Nexus 5, Nexus 7 and Android TV. Over the course of the L Developer Preview program, you’ve given us great feedback and we appreciate the engagement from you, our developer community. Thanks!

This week, we announced Android 5.0 Lollipop. Starting today, you can download the full release of the Android 5.0 SDK, along with updated developer images for Nexus 5, Nexus 7 (2013), ADT-1, and the Android emulator.

The first set of devices to run this new version of Android -- Nexus 6, Nexus 9, and Nexus Player -- will be available in early November. In the same timeframe, we'll also roll out the Android 5.0 update worldwide to Nexus 4, 5, 7 (2012 & 2013), and 10 devices, as well as to Google Play edition devices.

Therefore, now is the time to test your apps on the new platform. You have two more weeks to get ready!

What’s in Lollipop?

Android 5.0 Lollipop introduces a host of new APIs and features including:

• Material Design theme & APIs
• Enhanced Notifications for your apps
• Project Volta and Battery Historian for better power efficiency for apps
• Enhanced app runtime with Android Runtime (ART)
• OpenGL ES 3.1, Android Extension Pack & 64-bit support for better game & app performance

There's much more, so check out the Android 5.0 platform highlights for a complete overview.

What’s in the Android 5.0 SDK?

The Android 5.0 SDK includes updated tools and new developer system images for testing. You can develop against the latest Android platform using API level 21 and take advantage of the updated support library to implement Material Design as well as the leanback user interface for TV apps.

You can download these components through the Android SDK Manager and develop your app in Android Studio:

• Android 5.0 SDK Platform & Tools
• Android 5.0 Emulator System Image - 32-bit & 64-bit (x86)
• Android 5.0 Emulator System Image for Android TV (32-bit)
• Android v7 appcompat Support Library for Material Design theme backwards capability
• Android v17 leanback library for Android TV app support

For developers using the Android NDK for native C/C++ Android apps we have:

• NDK r10c with API level 21 support

For developers on Android TV devices we have:

• Android 5.0 system image over the air (OTA) update for ADT-1 Developer Kit. OTA updates will appear over the next few days.

Similar to our previous release of the preview, we are also providing updated system image downloads for Nexus 5 & Nexus 7 (2013) devices to help with your testing as well. These images support the Android 5.0 SDK, but only have the minimal apps pre-installed in order to enable developer testing:

• Nexus 5 (GSM/LTE) “hammerhead” Device System Image
• Nexus 7 (2013) - (Wifi) “razor” Device System Image

For the developer preview versions, there will not be an over the air (OTA) update. You will need to wipe and reflash your developer device to use the latest developer preview versions. If you want to receive the official consumer OTA update in November and any other official updates, you will have to have a factory image on your Nexus device.

Validate your apps with the Android 5.0 SDK

With the consumer availability of Android 5.0 and the Nexus 6, Nexus 9, and Nexus Player right around the corner, here are a few things you should do to prepare:

1. Get the emulator system images through the SDK Manager or download the Nexus device system images.
2. Recompile your apps against Android 5.0 SDK, especially if you used any preview APIs. Note: APIs have changed between the preview SDK and the final SDK.
3. Validate that your current Android apps run on the new API 21 level with ART enabled. And if you use the NDK for your C/C++ Android apps, validate against the 64-bit emulator. ART is enabled by default on API 21 & new Android devices with Android 5.0.

Once you validate your current app, explore the new APIs and features for Android 5.0.

Migrate Your Existing App to Material Design

Android 5.0 Lollipop introduces Material Design, which enables your apps to adopt a bold, colorful, and flexible design, while remaining true to a small set of key principles that guide user interaction across multiple screens and devices.

After making sure your current apps work with Android 5.0, now is the time to enable the Material theme in your app with the AppCompat support library. For quick tips & recommendations for making your app shine with Material Design, check out our Material Design guidelines and tablet optimization tips. For those of you new to Material Design, check out our Getting Started guide.

Get your apps ready for Google Play!

Starting today, you can publish your apps that are targeting Android 5.0 Lollipop to Google Play. In your app manifest, update android:targetSdkVersion to "21", test your app, and upload it to the Google Play Developer Console.

Starting November 3rd, Nexus 9 will be the first device available to consumers that will run Android 5.0. Therefore, it is a great time to publish on Google Play, once you've updated and tested your app. Even if your apps target earlier versions of Android, take a few moments to test them on the Android 5.0 system images, and publish any updates needed in advance of the Android 5.0 rollout.

Stay tuned for more details on the Nexus 6 and Nexus 9 devices, and how to make sure your apps look their best on them.

Next up, Android TV!

We also announced the first consumer Android TV device, Nexus Player. It’s a streaming media player for movies, music and videos, and also a first-of-its-kind Android gaming device. Users can play games on their HDTVs with a gamepad, then keep playing on their phones while they’re on the road. The device is also Google Cast-enabled, so users can cast your app from their phones or tablets to their TV.

If you’re developing for Android TV, watch for more information on November 3rd about how to distribute your apps to Android TV users through the Google Play Developer Console. You can start getting your app ready by making sure it meets all of the TV Quality Guidelines.

Get started with Android 5.0 Lollipop platform

If you haven’t had a chance to take a look at this new version of Android yet, download the SDK and get started today. You can learn more about what’s new in the Android 5.0 platform highlights and get all the details on new APIs and changed behaviors in the API Overview. You can also check out the latest DevBytes videos to learn more about Android 5.0 features.

Enjoy this new release of Android!

Join the discussion on

+Android Developers

Game services UIs are now updated for material design, across all of the SDKs.

Game developers, we've updated some of our popular developer tools to give you a consistent set of game services across platforms, a refreshed UI based on material design, and new tools to give you better visibility into what users are doing in your games.

Let’s take a look at the new features.

Real-time Multiplayer in the Play Games cross-platform C++ SDK

To make it easier to build cross-platform games, we’ve added Real-Time Multiplayer (RTMP) to the latest Google Play Games C++ SDK. The addition of RTMP brings the C++ SDK to feature parity with the Play services SDK on Android and the Play Games iOS SDK. Learn more »

Material Design refresh across Android, cross-platform C++, and iOS SDKs

We’ve incorporated material design into the user-interface of the latest Play Games services SDKs for Android, cross-platform C++, and iOS. This gives you a bold, colorful design that’s consistent across all of your games, for all of your users. Learn more »

New quests features and completion statistics

Quests are a popular way to increase player engagement by adding fresh content without updating your game. We’ve added some new features to quests to make them easier to implement and manage.

First, we’ve simplified quests implementations by providing out-of-the-box toasts for “quest accepted” and “quest completed” events. You can invoke these toasts from your game with just a single call, on any platform. This removes the need to create your own custom toasts, though you are still free to do so.

You also have more insight into how your quests are performing through new in-line quest stats in the Developer Console. With these stats, you can better monitor how many people are completing their quests, so you can adjust the criteria to make them easier to achieve, if needed. Learn more »

Last, we’ve eliminated the 24-hour lead-time requirement for publishing and allowing repeating quests to have the same name. You now have the freedom to publish quests whenever you want with whatever name you want.

New quest stats let you see how many users are completing their quests.

Multiplayer game statistics

Now when you add multiplayer support through Google Play game services, you get multiplayer stats for free, without having to implement a custom logging solution. You can simply visit the Developer Console to see how players are using your multiplayer integration and look at trends in overall usage. The new stats are available as tabs under the Engagement section. Learn more »

Multiplayer stats let you see trends in how players are using your app's multiplayer integration.

New game services insights and alerts

We’re continuing to expand the types of alerts we offer the Developer Console to let you know about more types of issues that might be affecting your users' gameplay experiences. You’ll now get an alert when you have a broken implementation of real-time and turn-based multiplayer, and we’ll also notify you if your Achievements and Leaderboard implementations use too many duplicate images. Learn more »

Get Started

You can get started with all of these new features right away. Visit the Google Play game services developer site to download the updated SDKs. For migration details on the Game Services SDK for iOS, see the release notes. You can take a look at the new stats and alerts by visiting the Google Play Developer Console.

Join the discussion on

+Android Developers

For developers using the Android Wear APIs in Google Play services, it is important to correctly handle all the error conditions that can occur on legacy phones or when users do not have a wearable device. This post describes the best practice in handling error conditions with the GoogleApiClient connect() method. If you do not implement this correctly, your existing application functionality may fail for non-wearable users.

There are two ways that the connect() method can return ConnectionResult.API_UNAVAILABLE for wearable support with Google Play services:

• When requesting Wearable.API on any device running Android 4.2 (API level 17) or earlier
• When requesting Wearable.API when no Android Wear companion application or device is available

Google Play services provides a wide range of useful features such as integration with Google Drive, Wallet, Google+, and Google Play games services (just to name a few!). During initialization, the application uses GoogleApiClient.Builder() to make calls to addApi() to request the features that are necessary. The connect() method is then called to establish a connection to the Google Play services library, and it can return error codes if any API is not available.

If you request multiple APIs from a single GoogleApiClient, such as Drive and Wear, and the Wear support returns API_UNAVAILABLE, then the Drive request will also fail. Since Wear support is not guaranteed to be available on all devices, you should make sure to use a separate client for this request.

The best practice for developers is to implement two separate GoogleApiClient connections:

• One connection for Android Wear support, and
• A separate connection for all of the other APIs you need

This will ensure that the functionality of your app will remain for all users, whether or not there is wearable support available on their devices, as well as on older legacy devices.

It's important that you implement this best practice immediately, because your current users may be affected if not handled correctly in your app.

Join the discussion on

+Android Developers

The best cooking companion since the apron?

Android Wear is designed for serving up useful information at just the right time and in the right place. A neat example of this is Allthecooks Recipes. It gives you the right recipe, right when you need it.

This app is a great illustration of the four creative visions for Android Wear:

1. Launched automatically
2. Glanceable
3. Suggest and demand
4. Zero or low interaction

Allthecooks also shows what developers can do by combining both the power of the mobile device and the convenience of Android Wear.

Pick the best tool for the job

One particularly well-designed aspect of Allthecooks is their approach to the multi-device experience. Allthecooks lets the user search and browse the different recipes on their Android phone or tablet. When the user is ready, there is a clearly labelled blue action link to send the recipe to the watch.

The integration is natural. Using the on-screen keyboard and the larger screen real estate, Allthecooks is using the best screen to browse through the recipes. On the wearables side, the recipe is synchronised by using the DataApi and is launched automatically, fulfilling one of the key creative visions for Android Wear.

The end result? The mobile / Wear integration is seamless.

Thoughtful navigation

Once the recipe has been sent to the Android Wear device, Allthecooks splits the steps into easily glanceable pages. At the end of that list of steps, it allows the user to jump back to the beginning with a clearly marked button.

This means if you would like to browse through the steps before starting to cook, you can effortlessly get to the beginning again without swiping through all the pages. This is a great example of two other points in the vision: glanceable and zero or low interaction.

A great (cooking) assistant

One of the key ingredients of great cooking is timing, and Allthecooks is always on hand to do all the inputs for you when you are ready to start the clock. A simple tap on the blue “1” and Allthecooks will automatically set the timer to one hour. It is a gentle suggestion that Allthecooks can set the timer for you if you want.

Alternatively, if you want to use your egg timer, why not? It is a small detail but it really demonstrates the last and final element of Android Wear’s vision of suggest and demand. It is an ever ready assistant when the user wants it. At the same time, it is respectful and does not force the user to go down a route that the user does not want.

It’s about the details

Great design is about being user-centric and paying attention to details. Allthecooks could have just shrunk their mobile app for wear. Instead the Allthecooks team put a lot of thoughts into the design and leveraged all four points of the Android Wear creative vision. The end result is that the user can get the best experience out of both their Android mobile device and their Android Wear device. So developers, what will you be cooking next on Android Wear?

For more inspiring Android Wear user experiences, check out the Android Wear collection on Google Play!

Join the discussion on
+Android Developers

Sending messages on Android Wear feels as easy as it was to pass notes back in school. Remember when your friends always felt nearby? That feeling is why I love staying in touch with friends and family using my wearable.

Your messaging app likely already works on Android Wear. With just a few more lines of code you can unlock simple but powerful features that let your users communicate even more effortlessly.

Message notifications for free

If your Android app uses notifications to let the user know about new messages, these will work automatically on their wearable. That is, when you build notifications with the NotificationCompat.Builder class, the system takes care of displaying them properly, whether they appear on a handheld or wearable. Also, an "Open on phone" action will be added so it's easy for the user to reply via the app on their handheld.

Google+ Hangouts message.

Reply like a champ

Messages on Wear get really exciting when you can reply directly from the watch with your voice. In addition to being super convenient, this always gives me a Dick Tracy thrill… but maybe that's just me. =]

To add this functionality, it's as simple as adding an action to the notification via WearableExtender that includes a RemoteInput to your notification. After the user replies, you'll just grab their voice input as a string from the RemoteInput included in the Intent. You can even include text responses the user can easily select from a list by passing an array of them to the setChoices method of the RemoteInput. More details and code can be found here.

WhatsApp message with the reply by voice action.

See who is texting

Messages are more meaningful when you are connected to the sender. That's why we recommend you include the photo of the sender as the background of the notification. As soon as the user taps into the message, they also see who it's from, which will make it matter more (or maybe that other thing, depending on who it is).

You should add a photo with a resolution of at least 400x400, but we recommend 640x400. With the larger size, the background will be given parallax scrolling. If the background is to be included in the apk, place it in the res/drawable-nodpi directory. Then call setBackground() on your WearableExtender and add it to your notification. More details and code can be found here.

Path Talk message with a clear picture of the sender.

Custom actions

Basic notifications with reply by voice and a good background image are the most important parts to get done right away. But why stop there? It's easy to extend the unique parts of your service to the wearable. A simple first step is adding in a custom action the way Omlet does. These are just actions defined with the WearableExtender that raise an intent on the handheld.

Omlet includes two extra actions with every message: Like and Check-In. Check-In sends along the user's current location.

Custom Layouts

Custom interaction on the wearable, like the following example from TextMe, is straightforward to implement. They have what appears to be a simple notification with an action that allows the user to select an emoticon. However, to show this emoticon picker, they are actually issuing a notification from the wearable. The round trip looks something like this:

1. The handheld gets a new message, issues a notification setLocalOnly(True), and sends a message to the wearable using the Data Layer API
2. The wearable receives that message using the WearableListenerService and issues a custom notification with a PendingIntent to launch an activity when the user views the notification
3. That activity has a custom layout defined with the Wearable UI Library
4. Once the user selects an emoticon, the wearable sends a message back to the handheld
5. The handheld receives that message and sends it along to the server

Custom layouts are documented in more depth here.

TextMe allows users to reply with a quick emoticon.

Next steps

Make your messaging service awesome by providing rich functionality on the user's wearable. It's easy to get started and easy to go further. It all starts at developer.android.com/wear.

Join the discussion on
+Android Developers

Google Play services 6.1 is now rolled out to devices worldwide, bringing you the newest features from Google to help you optimize your apps. You can get started developing today by downloading the Google Play services SDK from the Android SDK Manager.

Google Play services 6.1 adds Enhanced Ecommerce analytics support from Google Tag Manager and offers new improvements to the Google Drive Android API. With the latest release, we’re also including a refresh of the Google Fit developer preview, so that you can test your fitness apps on any Android device.

Analytics

Launched in Google Play services 5.0, Enhanced Ecommerce is an analytics extension designed to provide richer insights into pre-purchase shopping behavior and into product performance. It’s a great way to gain visibility into the full customer journey, helping you understand how different user acquisition campaigns are performing at a granular level. By including support for Enhanced Ecommerce in Google Tag Manager with the latest release of Google Play services, we are supercharging your ability to regularly update and manage tags on mobile apps more easily, so that you can consistently measure product impressions, shopping funnel events, and more.

Drive

To make it easier to use Drive, we added enhancements to the Google Drive Android API. With the new Completion Events feature, you can see when actions are committed to the server and improve the response time to conflicts. Material design elements have been incorporated into the File Picker UI, along with the addition of Recent and Starred views. A new setParents() method enables you to organize files and folders, while the previous Contents class has been replaced with a simpler DriveContents class.

Learn more about how to use these new features in this DevBytes video.

Google Fit

Initially introduced in August, the Google Fit Developer Preview has been refreshed to enable you to test your new fitness apps on any Android device. We expect to make additional changes to the APIs, so please check back with us on new developments.

Get Started

To get started developing, download the latest Google Play services SDK from the Android SDK Manager. For details on the new APIs, take a look at the New Features documentation. For setup information, see Set Up Google Play Services SDK.

To learn more about Google Play services and the APIs available to you through it, visit the Google Services section on the Android Developers site.

We hope you enjoy this release of Google Play services!

Join the discussion on
+Android Developers

With the launch of Android One, more people across the world will have access to high-quality and affordable smartphones, packed with plenty of processing power and running the latest version of Android. These devices are available now in India and soon in Indonesia, the Philippines, and South Asia, so now is a good time to make sure your apps are ready for these new markets. This post highlights a few areas to consider.

These days, we often talk about smooth, 60fps transitions and keeping apps jank-free, and rightly so — performance is a critical metric for app quality. But in the user experience hierarchy of needs, an app should first and foremost do its job reliably and consistently.

If your app has search functionality, will user requests time out entirely? Do you think it is more important that a result is returned in a timely manner, or that the result is returned at all? If you're trying to build a robust app to reach the next five billion, it might be less about returning a result immediately, and more about returning a result at all. To address this challenge, why not include an option to users to “notify me with the results” when a search query is running on a slow network? Your app can then take as long as it needs to successfully retrieve the data in the background and show a notification when complete. The difference in user experience between an app that times out on a slower network and one that caters to user-specific needs will be very impactful for driving mobile app adoption.

There are also ways to test app performance without flying around the globe. The Android Emulator has network speed and network delay emulation settings, which can become an integral part of your testing strategy. If you’re testing on physical hardware, try turning off WiFi and switching the network to 2G only; how well does your app perform? Do search pages load? Does data refresh? These issues can often be fixed with relatively minor changes to your app logic or by leveraging a SyncAdapter. Check out our blog post on sync in the Google I/O app for more ideas.

Another key area for you to be aware of is app memory utilization. As part of the KitKat launch, we added new tools to the SDK for analyzing memory use and new APIs like isLowRamDevice(). We also just added a Memory Monitor to Android Studio 0.8.10 (currently in Canary). Much of this is documented in our Best Practices for Performance guide.

Moving forward, the Android L release has a strong focus on battery usage and analysis. Project Volta introduces new tools, such as Battery Historian and new APIs like JobScheduler, that can really help optimize battery use of your app.

By ensuring your app works well on slower networks, uses minimal memory, minimizes battery usage and doesn’t have a larger-than-necessary APK, you will help the next five billion discover, use and love your app.

Keeping data in sync with the cloud is an important part of many applications, and the Google I/O App is no exception. To do this, we leverage the standard Android mechanism for this purpose: a Sync Adapter. Using a Sync Adapter has many benefits over using a more rudimentary mechanism such as setting up recurring alarms, because the system automatically handles the scheduling of Sync Adapters to optimize battery life.

We store the data in a local SQLite database. However, rather than having the whole application access that database directly, the application employs another standard Android mechanism to control and organize access to that data. This structure is, naturally, a Content Provider. Only the content provider's implementation has direct access to the SQLite database. All other parts of the app can only access data through the Content Resolver. This allows for a very flexible decoupling between the representation of the data in the database and the more abstract view of that data that is used throughout the app.

The I/O app maintains with two main kinds of data: conference data (sessions, speakers, rooms, etc) and user data (the user's personalized schedule). Conference data is kept up to date with a one-way sync from a set of JSON files stored in Google Cloud Storage, whereas user data goes through a two-way sync with a file stored in the user's Google Drive AppData folder.

Downloading Conference Data Efficiently

For a conference like Google I/O, conference data can be somewhat large. It consists of information about all the sessions, rooms, speakers, map locations, social hashtags, video library items and others. Downloading the whole data set repeatedly would be wasteful both in terms of battery and bandwidth, so we adopt a strategy to minimize the amount of data we download and process.

This strategy is separating the data into several different JSON files, and having them be referenced by a central master JSON file called the manifest file. The URL of the manifest file is the only URL that is hard-coded into the app (it is defined by the MANIFEST_URL constant in Config.java). Note that the I/O app uses Google Cloud Storage to store and serve these files, but any robust hosting service accessible via HTTP can be used for the same purpose.

The first part of the sync process is checking if the manifest file was changed since the app last downloaded it, and processing it only if it's newer. This logic is implemented by the fetchConfenceDataIfNewer method in RemoteConferenceDataFetcher.

public class RemoteConferenceDataFetcher {
    // (...)
    public String[] fetchConferenceDataIfNewer(String refTimestamp) throws IOException {
        BasicHttpClient httpClient = new BasicHttpClient();
        httpClient.setRequestLogger(mQuietLogger);
        // (...)

        // Only download if data is newer than refTimestamp
        if (!TextUtils.isEmpty(refTimestamp) && TimeUtils
            .isValidFormatForIfModifiedSinceHeader(refTimestamp)) {
                httpClient.addHeader("If-Modified-Since", refTimestamp);
            }
        }

        HttpResponse response = httpClient.get(mManifestUrl, null);
        int status = response.getStatus();
        if (status == HttpURLConnection.HTTP_OK) {
            // Data modified since we last checked -- process it!
        } else if (status == HttpURLConnection.HTTP_NOT_MODIFIED) {
            // data on the server is not newer than our data - no work to do!
            return null;
        } else {
            // (handle error)
        }
    }
    // (...)
}

Notice that we submit the HTTP If-Modified-Since header with our request, so that if the manifest hasn't changed since we last checked it, we will get an HTTP response code of HTTP_NOT_MODIFIED rather than HTTP_OK, we will react by skipping the download and parsing process. This means that unless the manifest has changed since we last saw it, the sync process is very economical: it consists only of a single HTTP request and a short response.

The manifest file's format is straightforward: it consists of references to other JSON files that contain the relevant pieces of the conference data:

{
  "format": "iosched-json-v1",
  "data_files": [
    "past_io_videolibrary_v5.json",
    "experts_v11.json",
    "hashtags_v8.json",
    "blocks_v10.json",
    "map_v11.json",
    "keynote_v10.json",
    "partners_v2.json",
    "session_data_v2.681.json"
  ]
}

The sync process then proceeds to process each of the listed data files in order. This part is also implemented to be as economical as possible: if we detect that we already have a cached version of a specific data file, we skip it entirely and use our local cache instead. This task is done by the processManifest method.

Then, each JSON file is parsed and the entities present in each one are accumulated in memory. At the end of this process, the data is written to the Content Provider.

Issuing Content Provider Operations Efficiently

The conference data sync needs to be efficient not only in the amount of data it downloads, but also in the amount of operations it performs on the database. This must be done as economically as possible, so this step is also optimized: instead of overwriting the whole database with the new data, the Sync Adapter attempts to preserve the existing entities and only update the ones that have changed. In our tests, this optimization step reduced the total sync time from 16 seconds to around 2 seconds on our test devices.

In order to accomplish this important third layer of optimization, the application needs to know, given an entity in memory and its version in the Content Provider, whether or not we need to issue content provider operations to update that entity. Comparing the entity in memory to the entity in the database field by field is one option, but is cumbersome and slow, since it would require us to read every field. Instead, we add a field to each entity called the import hashcode. The import hashcode is a weak hash value generated from its data. For example, here is how the import hashcode for a speaker is computed:

public class Speaker {
    public String id;
    public String publicPlusId;
    public String bio;
    public String name;
    public String company;
    public String plusoneUrl;
    public String thumbnailUrl;

    public String getImportHashcode() {
        StringBuilder sb = new StringBuilder();
        sb.append("id").append(id == null ? "" : id)
                .append("publicPlusId")
                .append(publicPlusId == null ? "" : publicPlusId)
                .append("bio")
                .append(bio == null ? "" : bio)
                .append("name")
                .append(name == null ? "" : name)
                .append("company")
                .append(company== null ? "" : company)
                .append("plusoneUrl")
                .append(plusoneUrl == null ? "" : plusoneUrl)
                .append("thumbnailUrl")
                .append(thumbnailUrl == null ? "" : thumbnailUrl);
        String result = sb.toString();
        return String.format(Locale.US, "%08x%08x", 
            result.hashCode(), result.length());
    }
}

Every time an entity is updated in the database, its import hashcode is saved with it as a database column. Later, when we have a candidate for an updated version of that entity, all we need to do is compute the import hashcode of the candidate and compare it to the import hashcode of the entity in the database. If they differ, then we issue Content Provider operations to update the entity in the database. If they are the same, we skip that entity. This incremental update logic can be seen, for example, in the makeContentProviderOperations method of the SpeakersHandler class:

public class SpeakersHandler extends JSONHandler {
    private HashMap mSpeakers = new HashMap();

    // (...)
    @Override
    public void makeContentProviderOperations(ArrayList list) {
        // (...)
        int updatedSpeakers = 0;
        for (Speaker speaker : mSpeakers.values()) {
            String hashCode = speaker.getImportHashcode();
            speakersToKeep.add(speaker.id);

            if (!isIncrementalUpdate || !speakerHashcodes.containsKey(speaker.id) ||
                    !speakerHashcodes.get(speaker.id).equals(hashCode)) {
                // speaker is new/updated, so issue content provider operations
                ++updatedSpeakers;
                boolean isNew = !isIncrementalUpdate || 
                    !speakerHashcodes.containsKey(speaker.id);
                buildSpeaker(isNew, speaker, list);
            }
        }

        // delete obsolete speakers
        int deletedSpeakers = 0;
        if (isIncrementalUpdate) {
            for (String speakerId : speakerHashcodes.keySet()) {
                if (!speakersToKeep.contains(speakerId)) {
                    buildDeleteOperation(speakerId, list);
                    ++deletedSpeakers;
                }
            }
        }
    }
}

The buildSpeaker and buildDeleteOperation methods (omitted here for brevity) simply build the Content Provider operations necessary to, respectively, insert/update a speaker or delete a speaker from the Content Provider. Notice that this approach means we only issue Content Provider operations to update a speaker if the import hashcode has changed. We also deal with obsolete speakers, that is, speakers that were in the database but were not referenced by the incoming data, and we issue delete operations for those speakers.

Making Sync Robust

The sync adapter in the I/O app is responsible for several tasks, amongst which are the remote conference data sync, the user schedule sync and also the user feedback sync. Failures can happen in any of them because of network conditions and other factors. However, a failure in one of the tasks should not impact the execution of the other tasks. This is why we structure the sync process as a series of independent tasks, each protected by a try/catch block, as can be seen in the performSync method of the SyncHelper class:

// remote sync consists of these operations, which we try one by one (and
// tolerate individual failures on each)
final int OP_REMOTE_SYNC = 0;
final int OP_USER_SCHEDULE_SYNC = 1;
final int OP_USER_FEEDBACK_SYNC = 2;

int[] opsToPerform = userDataOnly ?
        new int[] { OP_USER_SCHEDULE_SYNC } :
        new int[] { OP_REMOTE_SYNC, OP_USER_SCHEDULE_SYNC, OP_USER_FEEDBACK_SYNC};

for (int op : opsToPerform) {
    try {
        switch (op) {
            case OP_REMOTE_SYNC:
                dataChanged |= doRemoteSync();
                break;
            case OP_USER_SCHEDULE_SYNC:
                dataChanged |= doUserScheduleSync(account.name);
                break;
            case OP_USER_FEEDBACK_SYNC:
                doUserFeedbackSync();
                break;
        }
    } catch (AuthException ex) {
        // (... handle auth error...)
    } catch (Throwable throwable) {
        // (... handle other error...)

        // Let system know an exception happened:
        if (syncResult != null && syncResult.stats != null) {
            ++syncResult.stats.numIoExceptions;
        }
    }
}

When one particular part of the sync process fails, we let the system know about it by increasing syncResult.stats.numIoExceptions. This will cause the system to retry the sync at a later time, using exponential backoff.

When Should We Sync? Enter GCM.

It's very important for users to be able to get updates about conference data in a timely manner, especially during (and in the few days leading up to) Google I/O. A naïve way to solve this problem is simply making the app poll the server repeatedly for updates. Naturally, this causes problems with bandwidth and battery consumption.

To solve this problem in a more elegant way, we use GCM (Google Cloud Messaging). Whenever there is an update to the data on the server side, the server sends a GCM message to all registered devices. Upon receipt of this GCM message, the device performs a sync to download the new conference data. The GCMIntentService class handles the incoming GCM messages:

Update (23 September 2014): Since this blog post was first published, the GCMBaseIntentService class has been deprecated. Please use the GoogleCloudMessaging API instead.

public class GCMIntentService extends GCMBaseIntentService {
    private static final String TAG = makeLogTag("GCM");

    private static final Map MESSAGE_RECEIVERS;
    static {
        // Known messages and their GCM message receivers
        Map  receivers = new HashMap();
        receivers.put("test", new TestCommand());
        receivers.put("announcement", new AnnouncementCommand());
        receivers.put("sync_schedule", new SyncCommand());
        receivers.put("sync_user", new SyncUserCommand());
        receivers.put("notification", new NotificationCommand());
        MESSAGE_RECEIVERS = Collections.unmodifiableMap(receivers);
    }

    // (...)

    @Override
    protected void onMessage(Context context, Intent intent) {
        String action = intent.getStringExtra("action");
        String extraData = intent.getStringExtra("extraData");
        LOGD(TAG, "Got GCM message, action=" + action + ", extraData=" + extraData);

        if (action == null) {
            LOGE(TAG, "Message received without command action");
            return;
        }

        action = action.toLowerCase();
        GCMCommand command = MESSAGE_RECEIVERS.get(action);
        if (command == null) {
            LOGE(TAG, "Unknown command received: " + action);
        } else {
            command.execute(this, action, extraData);
        }

    }
    // (...)
}

Notice that the onMessage method delivers the message to the appropriate handler depending on the GCM message's "action" field. If the action field is "sync_schedule", the application delivers the message to an instance of the SyncCommand class, which causes a sync to happen. Incidentally, notice that the implementation of the SyncCommand class allows the GCM message to specify a jitter parameter, which causes it to trigger a sync not immediately but at a random time in the future within the jitter interval. This spreads out the syncs evenly over a period of time rather than forcing all clients to sync simultaneously, and thus prevents a sudden peak in requests on the server side.

Syncing User Data

The I/O app allows the user to build their own personalized schedule by choosing which sessions they are interested in attending. This data must be shared across the user's Android devices, and also between the I/O website and Android. This means this data has to be stored in the cloud, in the user's Google account. We chose to use the Google Drive AppData folder for this task.

User data is synced to Google Drive by the doUserScheduleSync method of the SyncHelper class. If you dive into the source code, you will notice that this method essentially accesses the Google Drive AppData folder through the Google Drive HTTP API, then reconciles the set of sessions in the data with the set of sessions starred by the user on the device, and issues the necessary modifications to the cloud if there are locally updated sessions.

This means that if the user selects one session on their Android device and then selects another session on the I/O website, the result should be that both the Android device and the I/O website will show that both sessions are in the user's schedule.

Also, whenever the user adds or removes a session on the I/O website, the data on all their Android devices should be updated, and vice versa. To accomplish that, the I/O website sends our GCM server a notification every time the user makes a change to their schedule; the GCM server, in turn, sends a GCM message to all the devices owned by that user in order to cause them to sync their user data. The same mechanism works across the user's devices as well: when one device updates the data, it issues a GCM message to all other devices.

Conclusion

Serving fresh data is a key component of many Android apps. This article showed how the I/O app deals with the challenges of keeping the data up-to-date while minimizing network traffic and database changes, and also keeping this data in sync across different platforms and devices through the use of Google Cloud Storage, Google Drive and Google Cloud Messaging.

It’s that time again! Last summer, we published the first Beautiful Design collection on Google Play, and updated it in the winter with a fresh set of beautifully crafted apps.

Since then, developers have been hard at work updating their existing apps with new design ideas, and many new apps targeted to phones and tablets have launched on Google Play sporting exquisite detail in their UIs. Some apps are even starting to incorporate elements from material design, which is great to see. We’re on the lookout for even more material design concepts applied across the Google Play ecosystem!

Today, we're refreshing the Beautiful Design collection with our latest favorite specimens of delightful design from Google Play. As a reminder, the goal of this collection is to highlight beautiful apps with masterfully crafted design details such as beautiful presentation of photos, crisp and meaningful layout and typography, and delightful yet intuitive gestures and transitions.

The newly updated Beautiful Design Summer 2014 collection includes:

Flight Track 5, whose gorgeously detailed flight info, full of maps and interactive charts, stylishly keeps you in the know.

Oyster, a book-reading app whose clean, focused reading experience and delightful discovery makes it a joy to take your library with you, wherever you go.

Gogobot, an app whose bright colors and big images make exploring your next city delightful and fun.

Lumosity, Vivino, FIFA, Duolingo, SeriesGuide, Spotify, Runtastic, Yahoo News Digest… each with delightful design details.

Airbnb, a veteran of the collection from this past winter, remains as they continue to finesse their app.

If you’re an Android designer or developer, make sure to play with some of these apps to get a sense for the types of design details that can separate good apps from great ones. And remember to review the material design spec for ideas on how to design your next beautiful Android app!.

Join the discussion on

+Android Developers

By Subir Jhanb, Google Cloud Messaging team

Developers from all segments are increasingly relying on Google Cloud Messaging (GCM) to handle their messaging needs and make sure that their apps stay battery-friendly. GCM has been experiencing incredible momentum, with more than 100,000 apps registered, 700,000 QPS, and 300% QPS growth over the past year.

At Google I/O we announced the general availability of several GCM capabilities, including the GCM Cloud Connection Server, User Notifications, and a new API called Delivery Receipt. This post highlights the new features and how you can use them in your apps. You can watch these and other GCM announcements at our I/O presentation.

Two-way XMPP messaging with Cloud Connection Server

XMPP-based Cloud Connection Server (CCS) provides a persistent, asynchronous, bidirectional connection to Google servers. You can use the connection to send and receive messages between your server and your users' GCM-connected devices. Apps can now send upstream messages using CCS, without needing to manage network connections. This helps keep battery and data usage to a minimum. You can establish up to 100 XMPP connections and have up to 100 outstanding messages per connection. CCS is available for both Android and Chrome.

User notifications managed across multiple devices

Nowadays users have multiple devices and hence receive notifications multiple times. This can reduce notifications from being a useful feature to being an annoyance. Thankfully, the GCM User Notifications API provides a convenient way to reach all devices for a user and help you synchronise notifications including dismissals - when the user dismisses a notification on one device, the notification disappears automatically from all the other devices. User Notifications is available on both HTTP and XMPP.

Insight into message status through delivery receipts

When sending messages to a device, a common request from developers is to get more insight on the state of the message and to know if it was delivered. This is now available using CCS with the new Delivery Receipt API. A receipt is sent as soon as the message is sent to the endpoint, and you can also use upstream for app level delivery receipt.

How to get started

If you’re already using GCM, you can take advantage of these new features right away. If you haven't used GCM yet, you’ll be surprised at how easy it is to set up — get started today! And remember, GCM is completely free no matter how big your messaging needs are.

To learn more about GCM and its new features — CCS, user notifications, and Delivery Receipt — take a look at the I/O Bytes video below and read our developer documentation.

Join the discussion on
+Android Developers

By Roman Nurik, lead designer for the Google I/O Android App

Every year for Google I/O, we publish an Android app for the conference that serves two purposes. First, it serves as a companion for conference attendees and those tuning in from home, with a personalized schedule, a browsing interface for talks, and more. Second, and arguably more importantly, it serves as a reference demo for Android design and development best practices.

Last week, we announced that the Google I/O 2014 app source code is now available, so you can go check out how we implemented some of the features and design details you got to play with during the conference. In this post, I’ll share a glimpse into some of our design thinking for this year’s app.

On the design front, this year’s I/O app uses the new material design approach and features of the Android L Developer Preview to present content in a rational, consistent, adaptive and beautiful way. Let’s take a look at some of the design decisions and outcomes that informed the design of the app.

Surfaces and shadows

In material design, surfaces and shadows play an important role in conveying the structure of your app. The material design spec outlines a set of layout principles that helps guide decisions like when and where shadows should appear. As an example, here are some of the iterations we went through for the schedule screen: