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.
Posted by Yoshi Tamura, Product Manager, Google Play
Over the past six months, a number of new tools in the Google Play Developer Console have been added to help you grow your app or game business on Google Play. Our improved beta testing features help you gather more feedback and fix issues. Store Listing Experiments let you run A/B tests on your app’s Play Store listing. Universal App Campaigns and the User Acquisition performance report help you grow your audience and better understand your marketing.
Starting today, you can now generate and distribute promo codes to current and new users on Google Play to drive engagement. Under the Promotions tab in the Developer Console, you can set up promo codes for your apps, games, and in-app products to distribute in your own marketing campaigns (up to 500 codes per app, per quarter). Consider using promo codes to reward loyal users and attract new customers.
How to use promo codes
Choose your app in the Developer Console.
Under the Promotions tab choose Add new promotion.
Review and accept the additional terms of service if you haven’t run a promotion before.
Choose from the options available, then generate and download your promo codes.
Distribute your promo codes via your marketing channels such as social networks, in email, on the web, to your app’s beta testers, or in your app or game itself.
Users can redeem your promo codes in a number of ways, including:
From Google Play, using the Redeem menu option.
From your app. They’ll be directed to the Play checkout flow before being redirected back to your app.
By following a link that embeds the promo code (see tips below).
Some things to keep in mind when running a successful promotion:
There’s a limit of 500 promo codes per app every quarter.
You can embed your code in a URL so that users don’t have to enter it themselves (for example, if you’re sending your codes in an email). You can use the URL: https://play.google.com/redeem?code={CODE} (where {CODE} is a generated promo code).
To use promo codes for in-app products, you should implement In-app Promotions in your app. Note that promo codes can’t be used for subscriptions.
We hope you find interesting ways to use promo codes to find new users and engage existing fans. To learn more about the many tools and best practices you can use to grow your business on Google Play, download our new developer playbook, “The Secrets to App 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.
Using Credentials on your server
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.
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.
Sound the way you hear it
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:
The SDK combines the physiology of a listener’s head with the positions of virtual sound sources to determine what users hear. For example: sounds that come from the right will reach a user’s left ear with a slight delay, and with fewer high frequency elements (which are normally dampened by the skull).
The SDK lets you specify the size and material of your virtual environment, both of which contribute to the quality of a given sound. So you can make a conversation in a tight spaceship sound very different than one in a large, underground (and still virtual) cave.
Optimized for today’s smartphones
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:
The SDK is optimized for mobile CPUs (e.g. SIMD instructions) and actually computes the audio in real-time on a separate thread, so most of the processing takes place outside of the primary CPU.
The SDK allows you to control the fidelity of each sound. As a result, you can allocate more processing power to critical sounds, while de-emphasizing others.
Simple, native integrations
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.
Experience spatial audio in our sample app for developers
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:
Project schedule including milestones for development –– we’ll reach out to the selected developers by March 15, 2016
Visual mockups of your idea including concept art
Smartphone app screenshots and videos, such as captured app footage
Appropriate narrative including storyboards, etc.
Breakdown of your team and its members
One pager introducing your past app portfolio and your company profile
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!
Sarah Clark, Program Manager, Google Developer Training
Front-end web developers face challenges when using common “asynchronous†requests. These requests, such as fetching a URL or reading a file, often lead to complicated code, especially when performing multiple actions in a row. How can we make this easier for developers?
Javascript Promises are a new tool that simplifies asynchronous code, converting a tangle of callbacks and event handlers into simple, straightforward code such as: fetch(url).then(decodeJSON).then(addToPage)...
We’ve just opened up a online course on Promises, built in collaboration with Udacity. This brief course, which you can finish in about a day, walks you through building an “Exoplanet Explorer†app that reads and displays live data using Promises. You’ll also learn to use the Fetch API and finally kiss XMLHttpRequest goodbye!
This short course is a prerequisite for most of the Senior Web Developer Nanodegree. Whether you are in the paid Nanodegree program or taking the course for free, won’t you come learn to make your code simpler and more reliable today?
We’re delighted to announce the availability of Google Play services 8.4. There’s a lot of new information to share with you about what’s available to you in this release.
Custom Email App Invites
App Invites is a technology that enables your users to share apps with people they know. In Google Play services 8.4 we’ve updated this to make it easier for them to share via email. Before this you could create a custom email that contained user defined text and an image, but now we’re allowing you to add content from the app directly into the message. It allows you to fully define the email body using HTML, and set the email subject line. So, for example, if you have a favorite cooking app that you want to share with your friends, your invite to use the app can include a favorite recipe from the app. They get the immediate benefit of being able to access the desired content, giving them a more informed choice about whether or not they decide to install the app to get richer and more content. Check out the App Invites sample on GitHub here.
Predicting User spend and churn in games
The Play Games Analytics developer experience is designed to enable game developers to better understand, manage, and optimize game experiences throughout the player lifecycle. With this in mind, we’ve extended the Player Stats API to help you better understand your players behavior, and based on this, entice them to stay in your game.
The churn prediction method will return data on the probability that the player will churn, i.e., stop playing the game. You can create content in response to this to entice them to stay in your game.
Additionally, the spend prediction method will return the probability that the player will spend something in the game. It’s up to you how to handle this data, but -- for example -- if there’s a low probability that the player will spend something, you could provide discounted in-app purchases or show ads.
Fused Location Provider Updates
The Fused Location Provider (FLP) in Google Play services provides location to your apps using a number of sensors, including GPS, WiFi and Cell Towers.
When desiring to save battery power, and using coarse updates, the FLP doesn’t use Global Positioning Services (GPS), and instead uses WiFi and Cell tower signals. In Google Play services 8.4, we have greatly improved how the FLP detects location from cell towers. Prior to this, we would get the location information relative to only the primary cell tower. Now, the FLP takes the primary tower and other towers nearby to provide a more accurate location. We’ve also improved location detection from WiFi access points, particularly in areas where GPS is not available -- such as indoors.
Maps API Improvements
Have you ever wished you could easily handle a tap on a suburb without having to add another layer on the map to intercept the taps? We’ve added an onClickListener for polygons, so you can easily add transparent polygons and intercept the taps directly. We’ve also added on click listeners to polylines and ground overlays.
Here’s how you can use a listener to detect a click on a polygon:
Info windows now also offer an OnInfoWindowCloseListener and an OnInfoWindowLongClickListener. The on close listener is particularly useful if you wish to zoom back out on the map after the user has looked at the detail associated with a particular marker.
For more details, and an example that uses these, see the ApiDemos sample on GitHub and check out the historical changes to this sample, so you can see how the new APIs work. Also see the Release Notes.
Support for Aztec bar codes
In Google Play services 7.8, we launched Vision APIs that supported face and barcode detection. One bar code format we didn’t support was Aztec bar codes, so with Google Play services 8.4 we’ve now added support for these.
Applications using BarcodeDetector in its default configuration (no barcode format restrictions) will automatically start decoding AZTEC codes.
Background Beacon Scanning
With Google Play services 8.4, the Nearby Messages API now supports background scanning for Eddystone, the open beacon format from Google. With this update, your app can be woken up when a BLE beacon is sighted. Back in July, Google Play Services 7.8 introduced the Nearby Messages API with a simple publish-subscribe interface. In the case of beacons, developers publish content by adding attachments to beacon records using Proximity Beacon API. These attachments are served back to your app when Nearby sights a beacon of interest.
New methods that we’ve added include a subscribe method for background beacon subscriptions where BLE scans are triggered at screen-on events; an associated unsubscribe event; and the ability to handle intents that you get when the Nearby API calls back during a background subscription.
We also have a new HistoryApi.updateData() method. This method allows you to update data in one API call without having to delete and insert with two calls.
Place Picker Autocomplete Widget
Today we are announcing the mobile autocomplete widget, the latest addition to our existing set of programmatic autocomplete features on Android and iOS, as well as the addition of Autocomplete to our place picker widget. Autocomplete functionality assists users by automatically completing the name and address of a place as they type. Widgets make it even easier for developers to add autocomplete functionality to their application with just a small amount of code. Learn more about this at this blog post.
