There is a new addition in the arsenal of instruments used by Android and ChromeOS teams in the battle to measure and minimize touch and audio latency: the WALT Latency Timer.
When you use a mobile device, you expect it to respond instantly to your touch or voice: the more immediate the response, the more you feel directly connected to the device. Over the past few years, we have been trying to measure, understand, and reduce latency in our Chromebook and Android products.
Before we can reduce latency, we must first understand where it comes from. In the case of tapping a touchscreen, the time for a response includes the touch-sensing hardware and driver, the application, and the display and graphics output. For a voice command, there is time spent in sampling input audio, the application, and in audio output. Sometimes we have a mixture of these (for example, a piano app would include touch input and audio output).
Most previous work to study latency has focused on measuring a single round-trip latency number. For example, to measure audio latency, an app would measure time from app to speaker/mic and back to the app using the Dr. Rick O'Rang loopback audio dongle together with an appropriate app such as the Dr Rick O’Rang Loopback app or Superpowered Mobile Audio Latency Test App. Similarly, the TouchBot uses a fast camera to measure the round-trip delay from physical touch until a change on the screen is visible. While valuable, the problem with such a setup is that it’s very difficult to break down the latency into input vs output components.
An important innovation in WALT (a descendant of QuickStep) is that it synchronizes an external hardware clock with the Android device or Chromebook to within a millisecond. This allows it to measure input and output latencies separately as opposed to measuring a round-trip latency.
WALT is simple. The parts cost less than $50 and with some basic hobby electronics skills, you can build it yourself.
We’ve been using WALT within Google for Nexus and Chromebook development. We’re now opening this tool to app developers and anyone who wants to precisely measure real-world latencies. We hope that having readily accessible tools will help the industry as a whole improve and make all our devices more responsive to touch and voice.
Posted by Matteo Vallone, Business Development Manager at Google Play
(As a way to reach more app developers and help them grow successful businesses on Google Play, this post was first published on The Next Web – Ed.)
There is much common ground between freemium apps and games businesses when it comes to achieving success. Users are, however, more used to paying for games than apps, stemming from the history of traditional gaming consoles. Moreover, mobile games are also able to easily offer ‘virtual goods’ across a range of price points to suit every pocket. This means that game developers have had plenty of opportunity to learn about how to improve onboarding, conversion, and ultimately the user Lifetime Value (LTV). So what can app developers learn from game developers? Here are some best practice tips and insights from successful game developers that can be applied to many apps, today.
Drive app success the game developer way:
1. Optimize retention before investing in acquisition
Retention is king, and retention drives conversion. For games developers, retention is the key measure of game quality and whether it appeals to players.
Most game developers will “soft launch” to beta testing communities or test markets. During this phase, the game is tweaked to optimize retention by looking into specific areas, such as tutorial completion, level difficulty and conversion. Developers can then track retention using the Cohorts reports in Google Analytics. Once retention is satisfactory, the developer can go to full launch and start investing in user acquisition.
2. Retain users with step-by-step engagement
The first seven days after install are the most critical for retention: users install several apps to try them, and decide in the first few days which ones they want to keep using. If you can retain for that time span, your app is more likely to become part of the user’s daily routine.
There are some simple ways to progressively build user engagement. It’s important to present a strong story that explains why that app is relevant to the user, while introducing them to key features. Then place features that offer the user value early, so they can be found without much effort.
This is a not a one-size-fit-all. To find the right solution, a developer needs to first make assumptions on what user flows can improve retention and then run A/B tests to validate or correct them. For example, a developer could think that introducing sign-in later in the user flow might improve retention. Also, the developer needs to keep in mind what the key long term engagement metrics are for the individual app (such as photos uploaded or the number of articles read) and measure the impact of the different onboarding flows on those metrics as well.
In general, these principles are good places to start optimizing your onboarding:
Look for ways to let the users experience the app straight away, rather than taking them through a long, complex setup.
Present “activation moments” — such as registering an account, uploading a video, or finding friend — gradually
Start by requiring minimal investment by the user, then ask them for more details as they are needed to use the apps features.
Treat permissions as a service for the user. For example, if you want users to register, show them in advance that, by making their experience more personal, they’ll get more value from the app.
In this example, OkCupid tried different onboarding flows and found the most engaging version increased seven-day retention by over 20 percent.
Finally, ensure the user can understand the value of your app before you start asking them to pay. Game developers are particularly good at letting their users try most or all product features for free in in a set number of days or sessions.
A great tool to help analyze how users are engaging (or not) with the app is through the Flow Report in Google Analytics. Using this report, a developer can see how users navigate through the app and where they leave to identify potential roadblocks.
3. Target the right offers at the right users
Understanding different groups of users in-app purchase behavior is the key to devising strategies to encourage them to spend.
Start by identifying groups of users by how they spend and much they are likely to spend. It may be by age group, the channel that brought the install, or in-app behaviour. Use the Segment builder in Google Analytics to identify and define these groups of users. Then, tailor in-app purchase offers to match the segments spending behavior. For example, for segments where multiple users tend to spend more in one go, but spend infrequently, offer them in-app features bundled together.
4. Offer in-app purchases when users are most likely to spend
Users are also more likely to spend, if the purchasing experience is frictionless, and even more so when they can see how the expenditure will add value. So:
Present purchase opportunities to users when they’re most likely to need or want it — and explain to the user why it’s relevant.
Make purchasing accessible easily from within the app with a minimum number of taps. For example, offer an upgrade button on the footer of relevant screens.
TomTom added a countdown to indicate when the free service runs out (counted in kilometers travelled). The counter includes a button to upgrade offering a one tap in-app purchase.
Like all good game developers, they focus on building good experiences that retain and engage users through constant testing and analytics. First impressions are important, so users need to be able to quickly understand the importance of the app and easily navigate through the onboarding experience. And to start generating revenue, it is important to be thoughtful about how to make in-app purchases actionable.
Posted by Fergus Hurley, Product Manager, Google Play
Millions of users rate and review your apps every day on Google Play. From feature requests to technical issues, ratings and reviews offer a wealth of information about what people like and dislike. Since 2013, you’ve been able to reply to reviews on Google Play, giving you a direct communication channel with your most engaged users. You've told us you value having this channel because it helps you iterate on user feedback faster on Android than other platforms. In the last few months, we’ve made a number of improvements in the Google Play Developer Console to help you better analyze and manage ratings and reviews so that you can improve your app experience and boost its rating.
Improvements to ratings and reviews
We recently revamped ratings and reviews with features you can now find on dedicated pages in the Developer Console:
The new ratings page in the Google Play Developer Console
See ratings over time: See how your rating changes daily, weekly, and monthly and easily spot any changes when you release a new version of your app.
Ratings breakdown: Break down your rating by country, language, device, app version, or Android version.
The new reviews page in the Google Play Developer Console
Review highlights: See common themes from what users say in reviews of your app – these are the same highlights that users see on the Play Store. Review highlights are shown when you have a high enough volume of reviews and are updated regularly to reflect the latest user experiences with your app.
Device metadata: See certain device data such as RAM, CPU, and screen size so you can more easily identify problems users are mentioning in user reviews and debug such issues.
Search review text: Search inside reviews to see what people are saying about a particular topic or keyword.
Replies & updates to reviews: When you reply to reviews, the user receives an email. Now, you can also opt-in to be emailed if the user updates their review or rating.
Learn from other developers on how to make the most of ratings and reviews
Photo Editor by Aviary is a photo editing app with a strong focus on simplicity and intuitive use. Ratings and reviews and other Android features allow Aviary to iterate on builds two to three times faster compared to other platforms while being in a regular dialogue with their users.
Glu Mobile is a mobile gaming company known for Racing Rivals, Cooking Dash 2016 and its upcoming Taylor Swift game. Ratings and reviews features help Glu engage their audience, gather feedback, and manage user satisfaction. “Google’s review highlights allow us to see a snapshot of game features users like or dislike at a glance. We monitor review trends, watch out for notifications, and respond to reviews for our games,” says Niccolo de Masi, Glu Mobile CEO. Here are some tips Glu is using to master ratings and reviews in the Developer Console:
Reply to reviews: Reply to user reviews of your game in the Google Play Developer Console. Help them with their issues or let them know that you're considering their feature suggestions. A positive experience could result in the user increasing their rating.
Use search: You can now search within all reviews and apply search filters for rating, language, app version, device and more. Use this feature to find specific user feedback, for example, on new content you’ve added.
Take action: Now, you can be notified when a user answers you or updates their review. You can immediately start working on improvements if you learned about an issue. If the feedback is positive, engage with your community and turn satisfied users into fans.
Analyze over time: Analyze ratings over time to learn more about how user satisfaction improves as you update your game. This allows you to understand if your latest feature update or bug fix results in higher user satisfaction.
Identify key themes: Google Play automatically surfaces review highlights that users are mentioning about your game. This makes it quick for you to analyze reviews and understand user feedback.
Posted by Roy Glasberg Global Lead, Launchpad Program & Accelerator
Last month, 24 promising startups from India, Indonesia, and Brazil came to Silicon Valley to participate in Google’s Launchpad Accelerator, a new program that provides late-stage startups (mobile apps) with mentoring and resources to successfully scale in their local economies.
During the intensive two-week Accelerator kickoff in our Mountain View headquarters, Google engineers from 11 product areas, as well as experts from other companies, were on hand to provide startups with mentorship on how to scale and monetize their apps, and ultimately, build successful businesses. Now back in their home countries, the teams will continue developing their products with the support of up to $50,000 in equity-free funding, six more months of ongoing mentorship, and a breadth of developer tools from the Launchpad Accelerator program.
So far, many startup participants have already seen an immediate impact. Two weeks after attending the kickoff event, Brazilian mobile game developer UpBeat Games was featured on Google Play and saw a 1,000% increase in app installations in Asia, as well as a 200% overall increase in active users, by leveraging analytics to better understand their users.
According to UpBeat Games founder Vinicius Heimbeck, “By working one-on-one with the mentors, we learned that we needed to be a data-driven company. We now have the right analytics tools to measure the results of our efforts and to learn from them to optimize the user experience. This all directly impacted our huge success once we were featured on Google Play.”
eFishery, an Indonesian startup that produces smart automated fish feeders, turned its focus on scaling since attending Launchpad Accelerator. “The mentors gave us great insight about how to build a scalable product and how to engage billions of users,” said co-founder and CEO Gibran Chuzaefah Amsi El Farizy. “We received both technical and practical advice on our business, from building back-end technology to embracing failure with the right mindset.”
Apply now for Launchpad Accelerator We are also excited to announce the second class for Launchpad Accelerator which will begin in June 2016.
If you are a startup from India, Indonesia, Brazil, or Mexico (a new addition!) and are interested in participating in the next wave, we encourage you to apply here by March 31. We expect to continue adding more countries to the program in the future, so be on the lookout!
When talking about the Android Support Library, it is important to realize this isn’t one monolithic library, but a whole collection of libraries that seek to provide backward-compatible versions of APIs, as well as offer unique features without requiring the latest platform version. Version 23.2 adds a few new support libraries as well as new features to many of the existing libraries.
Support Vector Drawables and Animated Vector Drawables
Vector drawables allow you to replace multiple png assets with a single vector graphic, defined in XML. While previously limited to Lollipop and higher devices, both VectorDrawable and AnimatedVectorDrawable are now available through two new Support Libraries support-vector-drawable and animated-vector-drawable, respectively.
Android Studio 1.4 introduced limited support for vector drawables by generating pngs at build time. To disable this functionality (and gain the true advantage and space savings of this Support Library), you need to add vectorDrawables.useSupportLibrary = true to your build.gradle file:
// This is handled for you by the 2.0+ Gradle Plugin aaptOptions { additionalParameters "--no-version-vectors" } }
You’ll be able to use VectorDrawableCompat back to API 7 and AnimatedVectorDrawableCompat on all API 11 and higher devices. Due to how drawables are loaded by Android, not every place that accepts a drawable id (such as in an XML file) will support loading vector drawables. Thankfully, AppCompat has added a number of features to make it easy to use your new vector drawables.
Firstly, when using AppCompat with ImageView (or subclasses such as ImageButton and FloatingActionButton), you’ll be able to use the new app:srcCompat attribute to reference vector drawables (as well as any other drawable available to android:src):
And if you’re changing drawables at runtime, you’ll be able to use the same setImageResource() method as before - no changes there. Using AppCompat and app:srcCompat is the most foolproof method of integrating vector drawables into your app.
You’ll find directly referencing vector drawables outside of app:srcCompat will fail prior to Lollipop. However, AppCompat does support loading vector drawables when they are referenced in another drawable container such as a StateListDrawable, InsetDrawable, LayerDrawable, LevelListDrawable, and RotateDrawable. By using this indirection, you can use vector drawables in cases such as TextView’sandroid:drawableLeft attribute, which wouldn’t normally be able to support vector drawables.
AppCompat DayNight theme
While enabling the use of vector graphics throughout your app is already a large change to AppCompat, there’s a new theme added to AppCompat in this release: Theme.AppCompat.DayNight.
Prior to API 14, The DayNight theme and its descendents DayNight.NoActionBar, DayNight.DarkActionBar, DayNight.Dialog, etc. become their Light equivalents. But on API 14 and higher devices, this theme allows apps to easily support both a Light and Dark theme, effectively switching from a Light theme to a Dark theme based on whether it is ‘night’.
By default, whether it is ‘night’ will match the system value (from UiModeManager.getNightMode()), but you can override that value with methods in AppCompatDelegate. You’ll be able to set the default across your entire app (until process restart) with the static AppCompatDelegate.setDefaultNightMode() method or retrieve an AppCompatDelegate via getDelegate() and use setLocalNightMode() to change only the current Activity or Dialog.
When using AppCompatDelegate.MODE_NIGHT_AUTO, the time of day and your last known location (if your app has the location permissions) are used to automatically switch between day and night, while MODE_NIGHT_NO and MODE_NIGHT_YES forces the theme to never or always use a dark theme, respectively.
It is critical that you test your app thoroughly when using the DayNight themes as hardcoded colors can easily make for unreadable text or icons. If you are using the standard TextAppearance.AppCompat styles for your text or colors pulled from your theme such as android:textColorPrimary, you’ll find these automatically update for you.
However, if you’d like to customize any resources specifically for night mode, AppCompat reuses the night resource qualifier folder, making it possible customize every resource you may need. Please consider using the standard colors or taking advantage of the tinting support in AppCompat to make supporting this mode much easier.
By attaching a BottomSheetBehavior to a child View of a CoordinatorLayout (i.e., adding app:layout_behavior="android.support.design.widget.BottomSheetBehavior"), you’ll automatically get the appropriate touch detection to transition between five state:
STATE_COLLAPSED: this collapsed state is the default and shows just a portion of the layout along the bottom. The height can be controlled with the app:behavior_peekHeight attribute (defaults to 0)
STATE_DRAGGING: the intermediate state while the user is directly dragging the bottom sheet up or down
STATE_SETTLING: that brief time between when the View is released and settling into its final position
STATE_EXPANDED: the fully expanded state of the bottom sheet, where either the whole bottom sheet is visible (if its height is less than the containing CoordinatorLayout) or the entire CoordinatorLayout is filled
STATE_HIDDEN: disabled by default (and enabled with the app:behavior_hideable attribute), enabling this allows users to swipe down on the bottom sheet to completely hide the bottom sheet
Keep in mind that scrolling containers in your bottom sheet must support nested scrolling (for example, NestedScrollView, RecyclerView, or ListView/ScrollView on API 21+).
If you’d like to receive callbacks of state changes, you can add a BottomSheetCallback:
// The View with the BottomSheetBehavior View bottomSheet = coordinatorLayout.findViewById(R.id.bottom_sheet); BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet); behavior.setBottomSheetCallback(new BottomSheetCallback() { @Override public void onStateChanged(@NonNull View bottomSheet, int newState) { // React to state change } @Override public void onSlide(@NonNull View bottomSheet, float slideOffset) { // React to dragging events } });
While BottomSheetBehavior captures the persistent bottom sheet case, this release also provides a BottomSheetDialog and BottomSheetDialogFragment to fill the modal bottom sheets use case. Simply replace AppCompatDialog or AppCompatDialogFragment with their bottom sheet equivalents to have your dialog styled as a bottom sheet.
Support v4: MediaBrowserServiceCompat
The Support v4 library serves as the foundation for much of the support libraries and includes backports of many framework features introduced in newer versions of the platform (as well a number of unique features).
Adding onto the previously released MediaSessionCompat class to provide a solid foundation for media playback, this release adds MediaBrowserServiceCompat and MediaBrowserCompat providing a compatible solution that brings the latest APIs (even those added in Marshmallow) back to all API 4 and higher devices. This makes it much easier to support audio playback on Android Auto and browsing through media on Android Wear along with providing a standard interface you can use to connect your media playback service and your UI.
RecyclerView
The RecyclerView widget provides an advanced and flexible base for creating lists and grids as well as supporting animations. This release brings an exciting new feature to the LayoutManager API: auto-measurement! This allows a RecyclerView to size itself based on the size of its contents. This means that previously unavailable scenarios, such as using WRAP_CONTENT for a dimension of the RecyclerView, are now possible. You’ll find all built in LayoutManagers now support auto-measurement.
Due to this change, make sure to double check the layout parameters of your item views: previously ignored layout parameters (such as MATCH_PARENT in the scroll direction) will now be fully respected.
If you have a custom LayoutManager that does not extend one of the built in LayoutManagers, this is an opt-in API - you’ll be required to call setAutoMeasureEnabled(true) as well as make some minor changes as detailed in the Javadoc of the method.
Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs.
Custom Tabs
Custom Tabs makes it possible to seamlessly transition to web content while keeping the look and feel of your app. With this release, you’ll now be able to add actions to a bottom bar for display alongside the web content.
With the new addToolbarItem() method, you’ll be able to add up to currently 5 (MAX_TOOLBAR_ITEMS) actions to the bottom bar and update them with setToolbarItem() once the session has begun. Similar to the previous setToolbarColor() method, you’ll also find a setSecondaryToolbarColor() method for customizing the background color of the bottom bar.
The most visible change may be the introduce of a second column used for action buttons (added by overriding onCreateButtonActions() or calling setButtonActions()). This makes it much easier to reach completion actions without having to scroll through the list of available GuidedActions.
Speaking of GuidedActions, there’s a number of new features to allow richer input including editable descriptions (via descriptionEditable()), sub actions in the form of a dropdown (with subActions()), and a GuidedDatePickerAction.
These components should make it much easier for you to get information from the user when absolutely required.
Available Now
Version 23.2 of the Android Support Library is available via your SDK Manager and Android Studio. Take advantage of all of the new features as well as additional bug fixes starting now! As always, file bug reports at b.android.com and connect with other developers on the Android Development Google+ community.
This is part 4 of a series on Google Sign-In that began with a blog post on the user experience improvements that launched with Google Play services 8.3. We then discussed the API updates that make the programming model much easier. Most recently, we went into how you can use Google Sign-In to authenticate a user with your backend server.
In this post, we’ll discuss how you can have your users sign in via your app to authorize your service for access to Google APIs, such as Google Drive, on their behalf.
When using Google Sign-In, it is easy to extend your integration with Google by requesting additional scopes for API access after sign-in, like storing the user’s pictures of food in Google Drive. Typically, you should request this access incrementally (not at initial sign-in) -- i.e. in the context of a user’s actions (for example, after an app user’s order has been delivered and they’d like to save a copy of their food photos), following best practices in user experience to make it most likely that the user will grant access, and aligning with the runtime permissions model in Android Marshmallow 6.0.
When you do this kind of integration, you probably want to access data from your server, so that you can continue to have access when the user is offline, or to store user-generated data in your own database. This flow would look like Figure 1. This also has the advantage of working across all platforms.
Figure 1. Accessing Google Services with Credentials.
To do this, follow these steps:
Step 1: As with the scenario in server authentication covered in the previous post, this sample provides canonical code for your Android app. In particular see the ServerAuthCodeActivity.
This requires you to get a web client ID for your server. Details on how to obtain this are available here (see Step 4).
In this case, the scope DRIVE_APPFOLDER is requested, meaning that the user will be asked to give the app permission to access their Google Drive. In addition to this, a server auth code will be requested.
If the sign-in is successful, the auth code can be extracted from the account object like this:
This auth code should then be sent to your server using HTTPS POST, and, after it is exchanged, will give your server access to the user’s Google Drive. [Important: you should send the code in an authenticated call to your backend to ensure that it is a legitimate request from the active user].
// Set path to the Web application client_secret_*.json file you downloaded from the // Google Developers Console: https://console.developers.google.com/project/_/apiui/credential // You can also find your Web application client ID and client secret from the // console and specify them directly when you create the GoogleAuthorizationCodeTokenRequest // object. String CLIENT_SECRET_FILE = "/path/to/client_secret.json"; // Be careful not to share this! String REDIRECT_URI = "/path/to/web_app_redirect" // Can be empty if you don’t use web redirects // Exchange auth code for access token GoogleClientSecrets clientSecrets = GoogleClientSecrets.load( JacksonFactory.getDefaultInstance(), new FileReader(CLIENT_SECRET_FILE)); GoogleTokenResponse tokenResponse = new GoogleAuthorizationCodeTokenRequest( new NetHttpTransport(), JacksonFactory.getDefaultInstance(), "https://www.googleapis.com/oauth2/v4/token", clientSecrets.getDetails().getClientId(), clientSecrets.getDetails().getClientSecret(), authCode, REDIRECT_URI) .execute(); String accessToken = tokenResponse.getAccessToken(); String refreshToken = tokenResponse.getRefreshToken(); Long expiresInSeconds = tokenResponse.getExpiresInSeconds(); // You can also get an ID token from the exchange result if basic profile scopes are requested // e.g. starting GoogleSignInOptions.Builder from GoogleSignInOptions.DEFAULT_SIGN_IN like the // sample code as used here: http://goo.gl/0Unpq8 // // GoogleIdToken googleIdToken = tokenResponse.parseIdToken();
Then, create a GoogleCredential object using the tokens from GoogleTokenResponse:
If a refresh token is available, you can persist the credentials using StoredCredential for later use if you need ongoing access to the API on behalf of the user.
Step 3: The credential can then be used to access Google services. Now, in our food delivery scenario, you might want to store or retrieve photos or receipts of finished deliveries in Google Drive. For example, it would look something like this:
This demonstrates the use of Google Sign-In credentials where your server can make Google API calls on behalf of your users. To learn more about this, and all Google Sign In technologies, visit the Google Identity Platform website.
Posted by Lily Sheringham, The Google Play Apps & Games team
We recently released the second edition of The Secrets to App Success on Google Play with more best practices for finding success growing an app or game business on Google Play. Today we’re sharing our first companion guide for developers, The Family Playbook, which includes information on developing high-quality apps and games for kids and families, along with advice from other developers.
The guide includes advice to help you optimize your user interface design for children, build interactive features that both educate and entertain, develop a business model, understand legal considerations, and plan age-appropriate marketing.
If you create family apps, opt-in to the Designed for Families developer program to designate your apps and games as family-friendly. Apps that meet the program requirements will be featured through Google Play’s family-friendly search and browse experiences and help parents discover great, age-appropriate content and make more informed choices.
Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources, please let us know what you think.
Android Developer Story: BabyFirst increases installs by 50% with Google Play
BabyFirst was founded to create good educational content for babies, toddlers and their parents. Their apps now have over 30 million downloads, with 40% more downloads on Google Play than other platforms.
