Google Play Developer 8-Step Checkup

Posted by Ellie Powers, Google Play team

Google Play gives you tons of options on publishing your apps and connecting with users. But as you get started with new features like beta testing and staged rollouts, it’s a good idea to do a checkup and make sure you’ve covered the basics.

1. Boost your developer account security

• If you take just one step today to protect your Google Play apps, enable two-step authentication for your Google account, and encourage the rest of your team to do the same.
• Next, many developers first set up their Google Play account with their personal gmail account, but it’s actually a good idea to transfer your apps to a separate account. All of your installations and reviews remain intact. If you haven’t done this already, transfer your apps to a new account today.
• Don’t share passwords. Instead, add each individual who needs access and only grant the minimum level of access they need — and encourage them to enable two-step authentication.
• Review the list of people with access regularly, and when people leave your project, make it a standard practice to remove their access. Learn more about developer account security.

2. Protect your keystore

In order to publish an update to an existing app, you’ll need to sign it with the same keystore every time. If you lose your keystore, you’ll lose your history and reviews, so you’ll need to start over with new apps with new package name and a new key, so you’ll want to make sure you protect it. First, choose a secure password, and don’t use the same password that you use for your Google account. Next, back up your keystore somewhere, but don’t upload it to Google Drive with an account you use to publish on Google Play.

3. Check your email addresses

As a developer, you are responsible for checking two important email addresses:

• Account owner email address: Google uses the address used to register your Developer Console to contact you about your apps and account, so it is extremely important that someone is responsible for checking it regularly. If necessary, you can forward messages from this account via Gmail, or transfer your apps to another account.
• Customer support email address: For each individual application, you can specify the best way for users to contact you for customer support. Ensure that a valid support email address for your product is specified. As a best practice, this should probably be a designated support account that is checked regularly and not the same email as the address used to login to the Developer Console.

4. Familiarize yourself with the policies

We recently launched some new guides and examples for Google Play’s Developer Program Policies and Developer Distribution Agreement. Note that once you publish an app as free, you can’t change it to a paid app later, though you can add in-app products.

5. Set up team processes

You may have many people involved with your Google Play apps. Make sure roles are clear in terms of whose job it is to publish updates, check statistics and optimization tips, read and reply to user reviews, and track revenue. Make sure all of these people have the right access to the Developer Console. Many developers who are part of larger organizations also report to their larger teams about their apps’ performance. Designate someone to make sure your app description, graphics (including localized and tablet screenshots), and pricing are up to date.

6. Configure your Developer Console UI languages

To change the language you want to see the Developer Console in, set your primary language. If you speak additional languages, configure those, too — user reviews in those languages won’t be translated automatically in the Developer Console. That was a popular request from developers.

7. Refresh your app’s marketing materials

• Optimize your Google Play image assets. Include a well designed feature graphic in your Google Play listing. Localize your feature graphic, screenshots and description to improve conversions globally. Create a great looking icon with the Launcher Icon Generator.
• Provide screenshots specifically for phones and tablets showing both portrait and landscape layouts.
• Improve your app’s marketing. Users are 47% more likely to trust & download content when you use the official Google Play Badge. Also, make sure you are linking to your apps properly. Use the Device Art Generator to create beautiful marketing material.

8. Stay on top of developer news

To make sure you’re aware of the latest Google Play updates for developers, make sure you check the Android Developers blog regularly, follow +Android Developers, and check the Developer Console regularly for announcements.

Join the discussion on

+Android Developers

Tablet Optimization Tips in the Google Play Developer Console

Posted by Ellie Powers, Google Play team

Last week we updated our guidelines for making great tablet apps and added the ability to upload tablet screenshots that are shown preferentially in Google Play to users on those devices. Today we’re introducing a new Optimization Tips page in the Google Play Developer Console that lets you quickly see how your app is doing against basic guidelines for tablet app distribution and quality.

When you upload an app, the Developer Console now runs a series of checks to verify basic criteria from the Tablet App Quality Checklist and shows you any issues it finds in the Optimization Tips page.

If you’re developing for tablets, make sure to visit your Optimization Tips page to ensure that your app is delivering a great tablet experience. If there are any issues listed, we recommend addressing them in your app as soon as possible and uploading a new binary for distribution, if needed.

For ideas on how to design and build a great tablet app, including details on how to address issues listed in your Optimization Tips page, check out the Tablet App Quality Checklist. Remember that a great tablet experience goes well beyond these basic checks. Keep working to bring your tablet users the most polished UI and richest content possible.

Join the discussion on

+Android Developers

Designing for Tablets? We’re Here to Help!

Posted by Roman Nurik, who often writes about Android design-related topics on Google+

So you’ve got a great Android phone app on Google Play, your users love it, and you’re kicking back and watching the download numbers soar. Congrats! But like any enterprising developer, you may be thinking, “how do I take my app’s success even further?” The answer: an equally awesome experience on tablets. Users love their tablet apps! For example, Mint.com found that the larger screen real estate allowed tablet users to engage with their budget data 7x more than on phones. And TinyCo found that on average, paying users spent 35% more on tablets than on handsets. So now is the right time to think about how your app translates onto these larger screen devices that are designed to meet users’ more generic, everyday computing needs.

In this post, we’ll recap some of the resources available for crafting a great tablet experience for your users. These resources are useful for everyone in the app development pipeline—from product managers, to designers, to developers, and QA engineers.

Android Design Guidelines

No conversation about Android app design or development should go very far without first consulting the Android Design guidelines. While most of the sections are relevant to all Android devices, certain sections stand out as particularly relevant to design on tablets.

The Devices and Displays page introduces the concept of density-independence. For example, although the Nexus 4, Nexus 7, and Motorola XOOM all have a similar pixel resolution (1280x768, 1280x800, and 1280x800 respectively), they have vastly different screens. Instead of thinking in pixels, think in dips (density-independent pixels)—that way, it’s much easier to conceptualize the difference between Nexus 4 (640x384 dp), Nexus 7 (960x600dp), and Nexus 10 or the Motorola XOOM (1280x800 dp).

Following the 48dp rhythm discussed in Metrics and Grids helps take some of the guesswork out of sizing elements, especially for tablets. When in doubt, use multiples of 48dp (or 16dp for a finer grid) for sizing elements horizontally and vertically. For example, when showing sparse content on larger screens, consider using generous side margins of 96dp or 144dp. Or when deciding how wide your master pane should be in a master/detail layout for 10” tablets, see how your master content looks and feels with a width of 240dp or 288dp.

The Multi-pane Layouts guide discusses use cases and examples for combining related views into a single screen to simultaneously improve app navigation and make optimal use of the available screen real estate. It also discusses strategies for laying out content across both portrait and landscape, all while maintaining functional parity across orientations. Since users enjoy using tablets in both portrait and landscape orientations, it’s even more important to react properly to orientation changes than with phones.

Lastly, the Downloadable Stencils offer designers a great starting point for high-fidelity mockups, complete with reference device outlines, correctly sized action bars, and more.

Android Training for Developers

The Training section of the developer site offers task-oriented technical training material, complete with flow diagrams, code snippets, sample projects and more. Several of these ‘classes’ are geared toward helping developers understand how to scale your apps across any screen size.

The Designing Effective Navigation class—aimed more at the initial design phase of the app creation process—offers a methodology for effectively planning and grouping screens on tablets, and even shows example wireframes for a simple news reader application following this methodology.

The classes Building a Dynamic UI with Fragments and Designing for Multiple Screens demonstrate how to use fragments in conjunction with Android’s resources framework. They show how to easily choose between tablet and handset layouts at runtime while maximizing code reuse and minimizing your application size using resource aliases. They also demonstrate techniques for adapting UI flows based on the current layout.

Lastly, while not precisely a training class, the Supporting Tablets and Handsets document offers even more information about some of these key best practices. And if you’re the type of developer that would prefer to skip the text and jump right into the code, you can even add a Master/Detail flow, complete with handset and tablet support, to your app with just a few clicks using the Android Developer Tools for Eclipse.

Android Design in Action Highlights

Each week, a few of us on the developer relations team get together on the Android Design in Action live show to discuss Android design best practices, as well as provide original ‘redesign’ mockups to help demonstrate our vision of how Android apps should look and feel.

A recent episode focused on the topic of responsive design, or designing flexible apps that can adapt to whatever screen size or form factor they’re run on:

In the episode, we celebrated successful examples of responsive design on Android, ranging from creating calendar events in Google Calendar, to browsing wallpapers and stories in Pattrn and Pocket, to playing video in TED, and finally to managing your conference schedule in the open-source Google I/O 2012 app.

We also regularly feature tablet design concepts on the show (some are shown below), so we highly recommend tuning in each week for design ideas.

 

For even more tablet app inspiration, check out a few of these apps: Expedia Hotels & Flights, Pulse News, SeriesGuide, Tasks and Timer.

The Tablet Quality Checklist

Over in the “Distribute” section of developer.android.com, the recently published Tablet App Quality checklist is a great way to check if your app is tablet-ready along a variety of technical dimensions. You should make sure that everyone involved in your mobile products is aware of  the standards defined in this checklist, as it is one of the ways in which the Google Play team selects apps to feature in the Staff Picks for Tablets collection.

So What are You Waiting For?

It's been an exciting year for Android tablets. Make sure your app is positioned to succeed in the evolving device landscape by following some of the best practices and examples discussed here and on the rest of developer.android.com.

If you have specific questions about your app, let us know on Google+ (+Android Developers) or Twitter (@AndroidDev)!

Join the discussion on +Android Developers

Making Android Games that Play Nice

[This post is by Ian Ni-Lewis, a Developer Advocate who devotes most of his time to making Android games more awesome. — Tim Bray]

Making a game on Android is easy. Making a great game for a mobile, multitasking, often multi-core, multi-purpose system like Android is trickier. Even the best developers frequently make mistakes in the way they interact with the Android system and with other applications — mistakes that don’t affect the quality of gameplay, but which affect the quality of the user’s experience in other ways.

A truly great Android game knows how to play nice: how to fit seamlessly into the system of apps, services, and UI features that run on Android devices. In this multi-part series of posts, Android Developer Relations engineers who specialize in games explain what it takes to make your game play nice.

I: The Audio Lifecycle (or, why is there music coming from my pants?)

One of the most awesome things about Android is that it can do so much stuff in the background. But when apps aren’t careful about their background behaviors, it can get annoying. Take my own personal pet peeve: game audio that doesn’t know when to quit.

The problem

I’m on the bus to work, passing the time with a great Android game. I’m completely entranced by whatever combination of birds, ropes, and ninjas is popular this week. Suddenly I panic: I’ve almost missed my stop! I leap up, quickly locking my phone as I shove it into a pocket.

I arrive breathless at my first meeting of the day. The boss, perhaps sensing my vulnerability, asks me a tough question. Not tough enough to stump me, though — I’ve got the answer to that right here on my Android phone! I whip out my phone and press the unlock button... and the room dissolves in laughter as a certain well-known game ditty blares out from the device.

The initial embarrassment is bad enough, but what’s this? I can’t even mute the thing! The phone is showing the lock screen and the volume buttons are inactive. My stress level is climbing and it takes me three tries to successfully type in my unlock code. Finally I get the thing unlocked, jam my finger on the home button and breathe a sigh of relief as the music stops. But the damage is done — my boss is glowering and for the rest of the week my co-workers make video game noises whenever they pass my desk.

What went wrong?

It’s a common mistake: the developer of the game assumed that if the game received an onResume() message, it was safe to resume audio. The problem is that onResume() doesn’t necessarily mean your app is visible — only that it’s active. In the case of a locked phone, onResume() is sent as soon as the screen turns on, even though the phone’s display is on the lock screen and the volume buttons aren’t enabled.

Fixing this is trickier than it sounds. Some games wait for onWindowFocusChanged() instead of onResume(), which works pretty well on Gingerbread. But on Honeycomb and higher, onWindowFocusChanged() is sent when certain foreground windows — like, ironically, the volume control display window — take focus. The result is that when the user changes the volume, all of the sound is muted. Not the developer’s original intent!

Waiting for onResume() and onFocusChanged() seems like a possible fix, and it works pretty well in a large number of cases. But even this approach has its Achilles’ heel. If the device falls asleep on its own, or if the user locks the phone and then immediately unlocks it, your app may not receive any focus changed messages at all.

What to do about it

Here’s the easy two-step way to avoid user embarrassment:

1. Pause the game (and all sound effects) whenever you receive an onPause() message. When gameplay is interrupted — whether because the phone is locked, or the user received a call, or for some other reason — the game should be paused.

2. After the game is paused, require user input to continue. The biggest mistake most game developers make is to automatically restart gameplay and audio as soon as the user returns to the game. This isn’t just a question of solving the “music over lock screen” issue. Users like to come back to a paused game. It’s no fun to switch back to a game, only to realize you’re about to die because gameplay has resumed before you expected it.

Some game designers don’t like the idea of pausing the background music when the game is paused. If you absolutely must resume music as soon as your game regains focus, then you should do the following:

1. Pause playback when you receive onPause().

2. When you receive onResume():

   1. If you have previously received an onFocusChanged(false) message, wait for an onFocusChanged(true) message to arrive before resuming playback.

   2. If you have not previously received an onFocusChanged(false) message, then resume audio immediately.

3. Test thoroughly!

Fixing audio embarrassments is almost always a quick and easy process. Take the time to do it right, and your users will thank you.