Posted by Lily Sheringham, Google Play team
Headquartered in Singapore, Wego is a popular online travel marketplace for flights and hotels for users in South East Asia and the Middle East. They launched their Android app in early 2014, and today, more than 62 percent of Wego app users are on Android. Wego recently redesigned their app using material design principles to provide their users a more native Android experience for consistency and easier navigation.
Watch Ross Veitch, co-founder and CEO, and the Wego team talk about how they increased monthly user retention by 300 percent and reduced uninstall rates by up to 25 percent with material design.
Learn more about material design, how to use Android Studio, and how to find success on Google Play with the new guide ‘Secrets to App Success on Google Play.’
Posted by Laurence Moroney, Developer Advocate
Introduced in May 2015, App Invites is an out-of-the-box solution for conducting app referrals and encouraging sharing. So far, we’ve seen very positive results on how the feature improves app discovery. While 52 percent of users discover apps by word of mouth, we have seen 92 percent of users trust recommendations from family and friends with App Invites. In this post, we’ll share some success stories from companies that have already used App Invites to grow their user base.
Fabulous is a research-based app incubated in Duke University's Center for Advanced Hindsight. The app helps users to embark on a journey to resetting poor habits, replacing them with healthy rituals, with the ultimate goal of improving health and well-being.
Users started taking advantage of App Invites within the app to share their experience with their friends and family. App Invites installs now account for 60 percent of all Fabulous installs via referrals. Sharing clicks also increased by 10 percent once App Invites were used. Fabulous also noticed increased user retention, with 2x the Life Time Value of the app for users that came in to it via App Invites. Fabulous simplified their user experience, combining SMS and email into a single interface, allowing users to focus on sharing.
Additionally, users that were acquired via App Invites versus other channels were found to be twice as likely to stay with the app.
CTO of Fabulous, Amine Laddhari, commented, “It took me only a few hours to implement App Invites versus several days of work when we built our own solution. It was straightforward!”
You can view the full case study from Fabulous here.
Yummly, a food discovery platform that views cooking a meal as a personalized, shareable experience wanted to expand its user base and generate awareness on the Android platform. It added App Invites so that users could recommend the app to their family and friends, giving functionality to share specific recipes, dinner ideas or shipping lists.
With App invites, they found that installation rates were about 60 percent higher compared to other sharing channels. Additionally, Yummly was able to take advantage of the seamless integration of Google Analytics. It’s the only share channel that has this integration, allowing data such as the number of invites sent, accepted and resulting installs to be accurately tracked.
Melissa Guyre, Product Manager at Yummly, commented, “The App Invites Integration process was seamless. A bonus feature is the excellent tracking tie-in with Google Analytics.”
You can view the full case study from Yummly here.
App Invites is available for Android or iOS, and you can learn how you can build it into your own apps at g.co/appinvites.
Posted by Wolff Dobson, Developer Advocate
We’re taking steps to reduce sign-in friction and unnecessary permission requests for players by moving the Games APIs to a new model. The new interaction is:
In order to respect user’s privacy and avoid revealing their real name, we also have to change the way player IDs work.
Most games should see no interruption or change in service. There are a handful of cases, however, where some change is required.
Below are some issues, along with potential solutions.
These are:
Let’s cover each of these issues in detail.
Early versions of our samples and documentation created a GoogleApiClient as follows:
// Don’t do it this way! GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this) .addApi(Games.API) .addScope(Plus.SCOPE_PLUS_LOGIN) // The bad part .build(); // Don’t do it this way!
In this case, the developer is specifically requesting the plus.login scope. If you ask for plus.login, your users will get a consent dialog.
Remove any unneeded scopes from your GoogleApiClient construction along with any APIs you no longer use.
// This way you won’t get a consent screen GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this) .addApi(Games.API) .build(); // This way you won’t get a consent screen
If your app uses specific Google+ features, such as requiring access to the player’s real-world Google+ social graph, be aware that new users will still be required to have a G+ profile to use your game. (Existing users who have already signed in won’t be asked to re-consent).
To require Google+ accounts to use your game, change your Games.API declaration to the following:
.addApi(Games.API, new GamesOptions.Builder() .setRequireGooglePlus(true).build())
This will ensure that your game continues to ask for the necessary permissions/scopes to continue using the player’s real-world social graph and real name profile.
If you call the Games.getCurrentPlayerId() API, the value returned here is the identifier that Games uses for this player.
Traditionally, this value could be passed into other APIs such as Plus.PeopleApi.load. In the new model, this is no longer the case. Player IDs are ONLY valid for use with Games APIs.
The Games APIs (those accessed from com.google.android.gms.games) all use the Player ID, and as long as you use only those, they are guaranteed to work with the new IDs.
A common pattern we’ve seen is:
This is not recommended in the first place, and is even more not-recommended after the shift in scopes.
Reasons not to do this:
Fortunately, the solution is known, and is basically the same as our server-side auth recommendations for web.
Upgrade to the latest version of Google Play Services SDK - at least 8.4.87.
Create a server client ID if you don’t already have one
Go to the Google Developer Console, and select your project
From the left nav, select API Manager, then select Credentials
Select “New Credentials” and choose “OAuth Client ID”
Select “Web Application” and name it something useful for your application
The client id for this web application is now your server client id.
In your game, connect your GoogleApiClient as normal.
Once connected, call the following API:
Games.getGamesServerAuthCode(googleApiClient, “your_server_client_id”)
If you were using GoogleAuthUtil before, you were probably calling this on a background thread - in which case the code looks like this:
// Good way { GetServerAuthCodeResult result = Games.getGamesServerAuthCode(gac, clientId).await(); if (result.isSuccess()) { String authCode = result.getCode(); // Send code to server. } } // Good way
Send the auth code to your server, exactly the same as before.
On your server, make an RPC to https://www.googleapis.com/oauth2/v4/token to exchange the auth code for an access token, probably using a Google Apis Client Library.
You’ll have to provide the server client ID, server client secret (listed in the Developer Console when you created the server client ID), and the auth code.
See more details here: https://developers.google.com/identity/protocols/OAuth2WebServer?utm_campaign=play games_discussion_permissions_012316&utm;_source=anddev&utm;_medium=blog#handlingresponse
No, really: You should use a Google Apis Client Library to make this process easier.
Once you have the access token, you can now call www.googleapis.com/games/v1/applications/<app_id>/verify/ using that access token.
Pass the auth token in a header as follows:
“Authorization: OAuth <access_token>”
The response value will contain the player ID for the user. This is the correct player ID to use for this user.
This access token can be used to make additional server-to-server calls as needed.
Let’s be very clear: If you do nothing, unless you are depending explicitly on Google+ features, you will see no change in functionality, and a smoother sign-in experience.
If you are:
Thanks, and keep making awesome games!
Paris-based DJiT is the creator of edjing, one of the most downloaded DJ apps in the world, it now has more than 60 million downloads and a presence in 182 countries. Following their launch on Android, the platform became the largest contributor of business growth, with 50 percent of total revenue and more than 70 percent of new downloads coming from their Android users.
Hear from Jean-Baptiste Hironde, CEO & Co-founder, Séverine Payet, Marketing Manager, and Damien Delépine, Android Software Engineer, to learn how DJit improved latency on new Android Marshmallow, as well as leveraged other Android and Google Play features to create higher quality apps.
Find out more about building great audio apps and how to find success on Google Play.
This is the third part in a blog series on using Google Sign-In on Android, and how you can take advantage of world-class security in your Android apps. In part 1, we spoke about the user experience improvements that are available to you. In part 2, we then took a deeper dive into the client-side changes to the Google Sign-In APIs that make coding a lot simpler.
In this post, we will demonstrate how you can use Google Sign-In with your backend. By doing so, users signing in on their device can be securely authenticated to access their data on your backend servers.
First, let’s take a look at what happens if a user signs in on your app, but they also need to authenticate for access to your back-end server. Consider this scenario: You’ve built an app that delivers food to users at their location. They sign into your app, and your app gets their identity. You store their address and order preferences in a database on your server.
Unless your server endpoints are protected with some authentication mechanism, attackers could read and write to your user database by simply guessing the email addresses of your users.
Figure 1. An attacker could submit a fake request to your server with an email address
This isn’t just a bad user experience, it’s a risk that customer data can be stolen and misused. You can prevent this by getting a token from Google when the user signs in to the app, and then passing this token to your server. Your server would then validate that this token really was issued by Google, to the desired user, and intended for your app (based on your audience setting, see below). At this point your server can know that it really is your user making the call, and not a nefarious attacker. It can then respond with the required details.
Figure 2. Attacker’s Forged Tokens will be rejected
Let’s take a look at the steps for doing this:
Step 1: Your Android app gets an ID token (*) after signing in with Google. There’s a great sample that demonstrates this here. To do this, the requestIdToken method is called when creating the GoogleSignInOptions object.
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN) .requestIdToken(getString(R.string.server_client_id)) .requestEmail() .build();
This requires you to get a client ID for your server. Details on how to obtain this are available here (see Step 4).
Once your Android app has the token, it can POST it over HTTPS to your server, which will then try to validate it.
(*) An ID token is represented using JSON Web Token, as defined by RFC7519 and the OpenID Connect spec. These are an open, industry standard method for representing claims securely between two parties.
Step 2: Your Server receives the token from your Android client. It should then validate the token with methods that are provided in the Google API Client libraries, in particular, verifying that it was issued by Google and that the intended audience is your server.
Your server can use the GoogleIdTokenVerifier class to verify the token and then extract the required identity data. The ‘sub’ field (available from the getSubject() method) provides a stable string identifier that should be used to identify your users even if their email address changes, and key them in your database. Other ID token fields are available, including the name, email address and photo URL. Here’s an example of a servlet that was tested on Google App Engine that can verify tokens using a provided library. These libraries allow you to verify the token locally without a network call for every verification.
GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory) // Here is where the audience is set -- checking that it really is your server // based on your Server’s Client ID .setAudience(Arrays.asList(ENTER_YOUR_SERVER_CLIENT_ID_HERE)) // Here is where we verify that Google issued the token .setIssuer("https://accounts.google.com").build(); GoogleIdToken idToken = verifier.verify(idTokenString); if (idToken != null) { Payload payload = idToken.getPayload(); String userId = payload.getSubject(); // You can also access the following properties of the payload in order // for other attributes of the user. Note that these fields are only // available if the user has granted the 'profile' and 'email' OAuth // scopes when requested. (e.g. you configure GoogleSignInOptions like // the sample code above and got a successful GoogleSignInResult) // Note that some fields may still be null. String email = payload.getEmail(); boolean emailVerified = Boolean.valueOf(payload.getEmailVerified()); String name = (String) payload.get("name"); String pictureUrl = (String) payload.get("picture"); String locale = (String) payload.get("locale"); String familyName = (String) payload.get("family_name"); String givenName = (String) payload.get("given_name");
Note that if you have an existing app using GoogleAuthUtil to get a token to pass to your backend, you should switch to the latest ID token validation libraries and mechanisms described above. We’ll describe recommendations for server-side best practices in a future post.
This post demonstrates how to use authentication technologies to ensure your user is who they claim they are. In the next post, we’ll cover using the Google Sign-In API for authorization, so that users can, for example, access Google services such as Google Drive from within your app and backend service.
You can learn more about authentication technologies from Google at the Google Identity Platform developers site.
Originally posted on Google Developers Blog
Posted by Nathan Martz, Product Manager, Google Cardboard
Human beings experience sound in all directions—like when a fire truck zooms by, or when an airplane is overhead. Starting today, the Cardboard SDKs for Unity and Android support spatial audio, so you can create equally immersive audio experiences in your virtual reality (VR) apps. All your users need is their smartphone, a regular pair of headphones, and a Google Cardboard viewer.
Many apps create simple versions of spatial audio—by playing sounds from the left and right in separate speakers. But with today’s SDK updates, your app can produce sound the same way humans actually hear it. For example:
We built today’s updates with performance in mind, so adding spatial audio to your app has minimal impact on the primary CPU (where your app does most of its work). We achieve these results in a couple of ways:
It’s really easy to get started with the SDK’s new audio features. Unity developers will find a comprehensive set of components for creating soundscapes on Android, iOS, Windows and OS X. And native Android developers will now have a simple Java API for simulating virtual sounds and environments.
Check out our Android sample app (for developer reference only), browse the documentation on the Cardboard developers site, and start experimenting with spatial audio today. We’re excited to see (and hear) the new experiences you’ll create!
Posted by Johnny Lee, Technical Project Lead, Project Tango
Today, at CES, Lenovo announced the development of the first consumer-ready smartphone with Project Tango. By adding a few extra sensors and some computer vision software, Project Tango transforms your smartphone into a magic lens that lets you place digital information on your physical world.
*Renderings only. Not the official Lenovo device.
To support the continued growth of the ecosystem, we’re also inviting developers from around the world to submit their ideas for gaming and utility apps created using Project Tango. We’ll pick the best ideas and provide funding and engineering support to help bring them to life, as part of the app incubator. Even better, the finished apps will be featured on Lenovo’s upcoming device. The submission period closes on February 15, 2016.
All you need to do is tell us about your idea and explain how Project Tango technologies will enable new experiences. Additionally, we’ll ask you to include the following materials:
For some inspiration, Lowe's Home Improvement teamed with developer Elementals Web to demonstrate a use case they are each working on for the launch. In the app, you can point your Project Tango-enabled smartphone at your kitchen to see where a new refrigerator or dishwasher might fit virtually.
Elsewhere, developer Schell Games let’s you play virtual Jenga on any surface with friends. But this time, there is no cleanup involved when the blocks topple over.
There are also some amazing featured apps for Project Tango on Google Play. You can pick up your own Project Tango Tablet Development Kit here to brainstorm new fun and immersive experiences that use the space around you. Apply now!
