Google Data

Forward Geocoding is the process of converting addresses (like a street address) into geographic coordinates (latitude and longitude), which you can use to place markers on a map or position the map. The Google Maps APIs have several services that you can use to convert addresses into coordinates - the Geocoding API, the Place Autocomplete service in Places API, and the Place Search service in Places API. What are the differences between them and when should you use each one? Here’s where to start.

Note that while this blog focuses on the server-side Places and Geocoding APIs, these best practices also apply to the client-side Places and Geocoding services in the Google Maps JavaScript API.

Geocoding API

The Geocoding API is best for handling unambiguous queries: complete postal address strings (for example, “48 Pirrama Rd, Pyrmont, NSW, Australia”). Compared to other Google APIs, the Geocoding API provides the best quality matching of addresses globally for these types of complete, unambiguous queries. However, Geocoding API is not recommended if your application handles ambiguous or incomplete queries, such as “123 Main St”, or if it handles queries that may contain non-address information such as apartment numbers or business names.

Geocoding API is best used for unambiguous complete addresses, such as "48 Pirrama Rd, Pyrmont, NSW, Australia"

Places API

The Places API allows users to discover both addresses and semantic locations, such as cafes or parks, by name or type. In contrast to the Geocoding API, it handles ambiguous or incomplete requests in a more robust way. If your application handles user interaction, or addresses that are ambiguous or incomplete, consider the following services.

Place Autocomplete service

For applications that respond in real time to user input, we recommend using the Place Autocomplete service in the Places API. This service is designed to return multiple possible addresses and allow the user to choose between them. The autocomplete lookup function can also be biased to return results specific to a location, enabling high quality results to be returned for incomplete queries such as “123 Main St”. Since the Place Autocomplete service is optimized for responding to user input, it also has very low latency, usually at least 10x lower than the Geocoding API. It’s also good at handling misspelled queries, or queries containing non-address information, since as the user types, they can see suggestions and correct their spelling if needed.

Typing "123 Main St" into a Place Autocomplete search box lets the user choose from multiple results. Results can also be biased to prefer those near the area shown on the map or near the current user location

Place Search service

The Place Autocomplete service relies on a user to choose the best option from multiple results. What if you have an application that handles ambiguous or incomplete queries in an automated fashion, with no user able to provide input?

For geocoding ambiguous or incomplete addresses in automated systems, when there is no user to select one of the autocomplete suggestions, we recommend the Place Search service in Places API. Place Search is better at coping with ambiguous queries than the Geocoding API, and lets you restrict your search to a specified area, or rank results by distance, allowing more precise filtering and ranking of results for ambiguous or incomplete queries. Place search is also more robust at responding to queries with additional non-address information such as business names or apartment numbers.

Future Changes to Geocoding API

We plan to roll out an update to the Geocoding API at the end of November 2016 that will increase the difference between Geocoding and Places performance for ambiguous and unambiguous queries. This change will improve the quality of Geocoding results for unambiguous queries, but will be more likely to return ZERO_RESULTS for ambiguous or incomplete queries where the Geocoding API was unable to find a high quality result.

If you are already using the above best practices, you should see an improvement in your Geocoding API results. If you are currently using the Geocoding API for incomplete or ambiguous queries, or for queries that may contain non-address information such as business names or apartment numbers, we recommend that you switch to the Places API instead, as it is likely to give better quality results for your use case.

You can try the new Geocoding service ahead of launch by adding an optional parameter, new_forward_geocoder=true, to your Geocoding API request. For example:

https://maps.googleapis.com/maps/api/geocode/json?new_forward_geocoder=true&address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=YOUR_API_KEY

If you want to try the new Geocoding service in the JavaScript Maps API Geocoding Service, you can set the new optional parameter newForwardGeocoder: true in the GeocoderRequest object. The new Geocoding service will launch for both the Geocoding API and the Geocoding Service in the JavaScript Maps API at the same time. All of the recommendations in this blog post apply to both the server-side and client-side APIs.

If you have any bug reports or feature requests for the new Geocoding service, please let us know using our public issue tracker.

In Summary

The following table sums up when we recommend you use the Geocoding API, Place Autocomplete service and Place Search service.


If your application does not yet follow these best practices, you may get worse results from Geocoding API in future, so we recommend you test how your application works with the new Geocoding service and update your application to use the above best practices if required. Try the upcoming Geocoding service by setting new_forward_geocoder=true in your geocoding request.

For more information on the Google Maps Geocoding API, Place Autocomplete in the Places API and Place Search in the Places API, please see the developer documentation. Also see this more detailed best practices guide in our documentation for more details on Geocoding best practices for various use cases, including minimizing latency when querying Directions API with addresses.

Finally, a big thank you to all the developers who use the Google Maps Geocoding API and provide feedback via the issue tracker. Getting feedback from developers is vital for us to be able to keep improving our products, so if you have any bug reports or feature requests, please let us know!

Posted by Elena Kelareva, Product Manager, Google Maps APIs

What an exciting time of the year. Supershoppers are out in full force, and your AdWords campaigns are ready for them. Last year, on mobile alone, conversion rates jumped 30% on Black Friday and 50% on Cyber Monday when compared to November 1.¹

With so much at stake, the AdWords app is the perfect way to stay in touch with your campaigns while still enjoying time away from the office.

Tips for this holiday season

Here are some ways to stay in step with your campaign performance and make last-minute changes throughout the holiday season:

1. Monitor your budget and bids daily to make sure you’re not missing out on key shopping dates
2. Make changes to your holiday campaigns, such as pausing or enabling a time-sensitive promotional campaign
3. Receive critical alerts and notifications, so you can be the first to know if your budget has run out or your ads have been disapproved
4. Take advantage of opportunities by increasing budgets or bids to drive more profitable conversions in your top-performing campaigns
5. Review daily performance metrics to understand how your campaigns are performing and if you need to make any last-minute adjustments

Get the app

The AdWords app is available for download on Android and iOS.


Posted by Sugeeti Kochar, Product Management, AdWords

---

1. Google Analytics Shopping category data, Nov 1, 2015–December 14, 2015, United States

Posted by Dave Burke, VP of Engineering

Today we're rolling out an update to the Android 7.1 Developer Preview -- the last before we release the final Android 7.1.1 platform to the ecosystem. Android 7.1.1 includes the developer features already available on Pixel and Pixel XL devices and adds optimizations and bug fixes on top of the base Android 7.1 platform. With Developer Preview 2, you can make sure your apps are ready for Android 7.1.1 and the consumers that will soon be running it on their devices.

As highlighted in October, we're also expanding the range of devices that can receive this Developer Preview update to Nexus 5X, Nexus 6P, Nexus 9, and Pixel C.

If you have a supported device that's enrolled in the Android Beta Program, you'll receive an update to Developer Preview 2 over the coming week. If you haven't enrolled your device yet, just visit the site to enroll your device and get the update.

In early December, we'll roll out Android 7.1.1 to the full lineup of supported devices as well as Pixel and Pixel XL devices.

What's in this update?

Developer Preview 2 is a release candidate for Android 7.1.1 that you can use to complete your app development and testing in preparation for the upcoming final release. In includes near-final system behaviors and UI, along with the latest bug fixes and optimizations across the system and Google apps.

It also includes the developer features and APIs (API level 25) already introduced in Developer Preview 1. If you haven't explored the developer features, you'll want to take a look at app shortcuts, round icon resources, and image keyboard support, among others -- you can see the full list of developer features here.

With Developer Preview 2, we're also updating the SDK build and platform tools in Android Studio, the Android 7.1.1 platform, and the API Level 25 emulator system images. The latest version of the support library (25.0.1) is also available for you to add image keyboard support, bottom navigation, and other features for devices running API Level 25 or earlier.

For details on API Level 25 check out the API diffs and the updated API reference on the developer preview site.

Get your apps ready for Android 7.1

Now is the time to optimize your apps to look their best on Android 7.1.1. To get started, update to Android Studio 2.2.2 and then download the API Level 25 platform, emulator system images, and tools through the SDK Manager in Android Studio.

After installing the API Level 25 SDK, you can update your project's compileSdkVersion to 25 to build and test against the new APIs. If you're doing compatibility testing, we recommend updating your app's targetSdkVersion to 25 to test your app with compatibility behaviors disabled. For details on how to set up your app with the API Level 25 SDK, see Set up the Preview.

If you're adding app shortcuts or circular launcher icons to your app, you can use Android Studio's built-in Image Asset Studio to quickly help you create icons of different sizes that meet the material design guidelines. You can test your round icons on the Google APIs emulator for API Level 25, which includes support for round icons and the new Google Pixel Launcher.

Android Studio and the Google APIs emulator let you quickly create and test your round icon assets.

If you're adding image keyboard support, you can use the Messenger and Google Keyboard apps included in the preview system images for testing as they include support for this new API.

Scale your tests using Firebase Test Lab for Android

To help scale your testing, make sure to take advantage of Firebase Test Lab for Android and run your tests in the cloud at no charge during the preview period on all virtual devices including the Developer Preview 2 (API 25). You can use the automated crawler (Robo Test) to test your app without having to write any test scripts, or you can upload your own instrumentation (e.g. Espresso) tests. You can upload your tests here.

Publish your apps to alpha, beta or production channels in Google Play

After you've finished final testing, you can publish your updates compiled against, and optionally targeting, API 25 to Google Play. You can publish to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, push your app updates to users whose devices are running Android 7.1, such as Pixel and Android Beta devices.

Get Developer Preview 2 on Your Eligible Device

If you have an eligible device that's already enrolled in the Android Beta Program, the device will get the Developer Preview 2 update over the coming week. No action is needed on your part. If you aren't yet enrolled in program, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you'll soon receive this preview update over-the-air. As always, you can also download and flash this update manually.

As mentioned above, this Developer Preview update is available for Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices.

We're expecting to launch the final release of the Android 7.1.1 in just a few weeks Starting in December, we'll roll out Android 7.1.1 to the full lineup of supported preview devices, as well as the recently launched Pixel and Pixel XL devices. At that time, we'll also push the sources to AOSP, so our device manufacturer partners can bring this new platform update to consumers on their devices.

Meanwhile, we continue to welcome your feedback in the Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the final consumer release in December!

The holiday season is upon us, and millions of people around the world are looking forward to unwrapping their new devices and downloading their favorite apps. People have more choice in apps than ever before, making it critical for brands and developers to deliver useful and delightful experiences.

We introduced the next generation of Universal App Campaigns to help marketers show your apps to the iOS and Android customers that matter most, based on your specific business goals. Today, we’re announcing three new innovations to make your holiday app campaigns more engaging and effective.

Create immersive video ads magically with AutoDirector

People love watching video, and with 1B+ users around the world¹, YouTube is the place they go to watch.

Now, advertisers using Universal App Campaigns can easily show their app in action using sight, sound, and motion with AutoDirector --- a new innovation that automatically creates immersive and engaging video ads.

AutoDirector gathers your app's description and ratings, selects the best images of your app from the App Store or Google Play, and even picks the music to give your app a soundtrack. Our machine learning models work behind-the-scenes to figure out which version of those videos gets more people to install and engage with your app across YouTube and the 1M+ apps in the Google Display Network.

Advertisers all over the world are using videos created through AutoDirector to help their dollars go further with Universal App Campaigns. According to Caio Ferreira, Performance Marketing Manager, OLX Brazil: "The new AutoDirector videos helped the OLX performance marketing team deliver 78% more conversions through AdWords ... Amazing!" Learn more.

New ways to showcase your app on Google Play

People discover apps in a variety of ways, and nearly half of users find new apps while browsing on their phone’s app store².

Today, we are announcing a new ad placement in Google Play, exclusively for advertisers running Universal App Campaigns. As people browse apps in the Google Play Store, they may see ads in a carousel alongside other app recommendations. For example, we may suggest a new game like Tap Paradise Cove to users who install the YouTube Gaming app.

We encourage advertisers to monitor their campaigns as there may be some natural changes in performance and delivery as we roll out these new placements.

Using Play data to find users who are likely to make a purchase

There’s no better place to be than front and center on Google Play when users are in the market for related apps. But finding customers who are likely to engage with your app past the install is far more complex.

Now, there’s an easier way to find these customers that matter most. Android developers who use in-app billing can now count in-app purchases as conversions in AdWords without any technical integration. Then you can use Universal App Campaigns to automatically find more of these valuable users who are more likely to make an in-app purchase in the future.

And it doesn’t end there. Android and iOS developers can define any in-app actions that matter -- from beating a level of Tap Paradise Cove, to subscribing to HBO Now, to viewing an available hotel room on trivago -- and find new users who are more likely to take those actions. Advertisers can integrate in-app conversion data with AdWords through Firebase Analytics or other third-party measurement providers.

There are 4M+ apps vying for users’ attention this holiday season. With these innovations, we hope Universal App Campaigns will make it easier for you to reach users that will install and engage with your app well into the new year.

Posted by Sissie Hsiao, Product Director, Mobile App Advertising
Please see our Official Guide to Finding Mobile App Users to learn more about getting started before the holidays.

---

1. https://www.youtube.com/yt/press/en-GB/statistics.html
2. Google/Ipsos, U.S., “How People Discover, Use, and Stay Engaged With Apps,” n=999, based on smartphone users aged 16-64, Sept. 2016.

Posted by Mike Schuster (Google Brain Team), Melvin Johnson (Google Translate) and Nikhil Thorat (Google Brain Team)

In the last 10 years, Google Translate has grown from supporting just a few languages to 103, translating over 140 billion words every day. To make this possible, we needed to build and maintain many different systems in order to translate between any two languages, incurring significant computational cost. With neural networks reforming many fields, we were convinced we could raise the translation quality further, but doing so would mean rethinking the technology behind Google Translate.

In September, we announced that Google Translate is switching to a new system called Google Neural Machine Translation (GNMT), an end-to-end learning framework that learns from millions of examples, and provided significant improvements in translation quality. However, while switching to GNMT improved the quality for the languages we tested it on, scaling up to all the 103 supported languages presented a significant challenge.

In “Google’s Multilingual Neural Machine Translation System: Enabling Zero-Shot Translation”, we address this challenge by extending our previous GNMT system, allowing for a single system to translate between multiple languages. Our proposed architecture requires no change in the base GNMT system, but instead uses an additional “token” at the beginning of the input sentence to specify the required target language to translate to. In addition to improving translation quality, our method also enables “Zero-Shot Translation” — translation between language pairs never seen explicitly by the system.
Here’s how it works. Let’s say we train a multilingual system with Japanese⇄English and Korean⇄English examples, shown by the solid blue lines in the animation. Our multilingual system, with the same size as a single GNMT system, shares its parameters to translate between these four different language pairs. This sharing enables the system to transfer the “translation knowledge” from one language pair to the others. This transfer learning and the need to translate between multiple languages forces the system to better use its modeling power.

This inspired us to ask the following question: Can we translate between a language pair which the system has never seen before? An example of this would be translations between Korean and Japanese where Korean⇄Japanese examples were not shown to the system. Impressively, the answer is yes — it can generate reasonable Korean⇄Japanese translations, even though it has never been taught to do so. We call this “zero-shot” translation, shown by the yellow dotted lines in the animation. To the best of our knowledge, this is the first time this type of transfer learning has worked in Machine Translation.

The success of the zero-shot translation raises another important question: Is the system learning a common representation in which sentences with the same meaning are represented in similar ways regardless of language — i.e. an “interlingua”? Using a 3-dimensional representation of internal network data, we were able to take a peek into the system as it translates a set of sentences between all possible pairs of the Japanese, Korean, and English languages.

Part (a) from the figure above shows an overall geometry of these translations. The points in this view are colored by the meaning; a sentence translated from English to Korean with the same meaning as a sentence translated from Japanese to English share the same color. From this view we can see distinct groupings of points, each with their own color. Part (b) zooms in to one of the groups, and part (c) colors by the source language. Within a single group, we see a sentence with the same meaning but from three different languages. This means the network must be encoding something about the semantics of the sentence rather than simply memorizing phrase-to-phrase translations. We interpret this as a sign of existence of an interlingua in the network.

We show many more results and analyses in our paper, and hope that its findings are not only interesting for machine learning or machine translation researchers but also to linguists and others who are interested in how multiple languages can be processed by machines using a single system.

Finally, the described Multilingual Google Neural Machine Translation system is running in production today for all Google Translate users. Multilingual systems are currently used to serve 10 of the recently launched 16 language pairs, resulting in improved quality and a simplified production architecture.

Originally posted on Google Developers blog

Posted by Matteo Vallone, Google Play Games Business Development

To build awareness of the awesome innovation and art that indie game developers are bringing to users on Google Play, we have invested heavily over the past year in programs like Indie Corner, as well as events like the Google Play Indie Games Festivals in North America and Korea.

As part of that sustained effort, we also want to celebrate the passion and innovation of indie game developers with the introduction of the first-ever Google Play Indie Games Contest in Europe. The contest will recognize the best indie talent in several countries and offer prizes that will help you get your game noticed by industry experts and gamers worldwide.

Prizes for the finalists and winners:

• An open showcase held at the Saatchi Gallery in London
• YouTube influencer campaigns worth up to 100,000 EUR
• Premium placements on Google Play
• Tickets to Google I/O 2017 and other top industry events
• Promotions on our channels
• Special prizes for the best Unity game
• And more!

Entering the contest:

If you're based in Czech Republic, Denmark, Finland, France (coming soon), Germany, Iceland, Israel, Netherlands, Norway, Poland (coming soon), Romania, Spain, Sweden, Turkey, or UK (excl. Northern Ireland), have 15 or less full time employees, and published a new game on Google Play after 1 January 2016, you may now be eligible to enter the contest. If you're planning on publishing a new game soon, you can also enter by submitting a private beta. Check out all the details in the terms and conditions. Submissions close on 31 December 2016.

The process:

Up to 20 finalists will get to showcase their games at an open event at the Saatchi Gallery in London on the 16th February 2017. At the event, the top 10 will be selected by the event attendees and the Google Play team. The top 10 will then get the opportunity to pitch to a jury of industry experts, from which the final winner and runners up will be selected.

Even if someone is NOT entering the contest:

Even if you're not eligible to enter the contest, you can still register to attend the final showcase event in London on 16 February 2017, check out some great indie games, and have fun with various industry experts and indie developers. We will also be hosting a workshop for all indie games developers from across EMEA in the new Google office in Kings Cross the next day, so this will be a packed week.

Get started:

Enter the Indie Games Contest now and visit the contest site to find out more about the contest, the event, and the workshop.

Smartphones have become consumers’ trusted shopping companions. Mobile shopping searches surged in 2015, passing desktop for the first time on Thanksgiving and Black Friday.¹ This year, we see supershoppers continuing to turn to their phones for research and purchases.

In fact, for many consumers, smartphones have become a “door-to-the-store.” And that is particularly true during the holidays. Seventy-six percent of people who search for something nearby on their smartphone visit a related business within a day.²

As we head into the one of the busiest shopping weeks of the year, Google data reveals how consumers will shop and what they'll buy.

Women purchase early while men play the waiting game

Women drive the mobile web, searching for and buying products at twice the rate of men throughout the entire holiday season. The week of Christmas, however, men are more likely to complete their mobile purchases.³

Hatchimals and Nintendo top shoppers’ gift lists this year

Consumers are already on the hunt. Top trending product searches for the first two weeks of November include the Nintendo Entertainment System and Hatchimals -- that’s right, stuffed animals that hatch.⁴
And while many shoppers can zero in on what they want, others search for inspiration and ideas. Last year, mobile searches related to "unique gifts" grew more than 65% compared to the 2014 holiday season, while mobile searches related to "cool gifts" grew more than 80%.⁵

On Black Friday, stores are most crowded in the afternoon

Although Black Friday is often associated with early birds, store foot traffic typically peaks in the afternoon between noon and 4:00 p.m.⁶ But people are shopping all day long. Shopping searches on mobile remain steady throughout the day as shoppers take advantage of Black Friday deals and plan their trips to the store.⁷

New Englanders love a good deal

Though Black Friday weekend is the rare retail event that pulls even reluctant shoppers into stores, some areas of the country are more interested in deals than others.

By 10:00 a.m. on Black Friday, more than one-quarter of New England shoppers are already on the hunt for a good deal, having stepped inside a department store or shopping center. The rest of the country lags behind an hour.⁸ And the same is true on mobile: people living in New Hampshire search for more product-related deals than people in other states.⁹

But even before stores open—and long after they close—consumers continue to shop. Last Thanksgiving, 59% of shopping searches on mobile took place before stores opened. Shopping continued well into the evening, with mobile shopping searches peaking at 8:00 p.m.¹⁰


The way consumers shop and behave during the holiday season is rapidly changing, from the way they create their gift lists to the way they purchase. Shoppers are proving that both with their fingertips and their feet.

For more data about mobile search trends and shopper foot traffic on Black Friday, check out our infographic “What Google Data Reveals About Black Friday Shoppers.”

Natalie Zmuda, Managing Editor, Think with Google
Elizabeth Fabiani, Product Marketing Manager, Google Shopping

---

1. Google Search Data, Nov. 2014 vs. Nov. 2015, U.S.
2. Google/Purchased Digital Diary: How Consumers Solve Their Needs in the Moment, May 2016, Representative sample of U.S. Smartphone users = 1000, Local searchers = 634, Purchases = 1,140
3. Google Analytics, aggregated, anonymized data from U.S. accounts that are opted into sharing benchmark data; mobile only, shopping vertical, Nov. 15, 2015 - Dec. 31, 2015.
4. Google Shopping Insights, U.S., all devices, Nov. 1 - Nov. 13, 2016.
5. Google Search Data, U.S., apparel, home & garden, beauty & personal care, computers & electronics, gifts, toys & games, photo & video, Nov.–Dec. 2014 vs. Nov.–Dec. 2015.
6. Google Data, Aggregated, anonymized store traffic for clothing, electronics, and toy stores from a sample of U.S. users that have turned on Location History, Nov. 2015.
7. Google Search Data, U.S., apparel, computer & electronics, and games & toys. mobile only. Nov. 2015.
8. Google Data, Aggregated anonymized store traffic for clothing, electronics, and toy stores from a sample of U.S. users that have turned on Location History; Store traffic after midnight attributed to Black Friday, Nov. 2015.
9. Google Search Data, U.S., apparel, home & garden, beauty & personal care, computers & electronics, gifts, toys & games, photo & video; mobile only. Nov. 2015, U.S.
10. Google Data, Aggregated, anonymized store traffic for Clothing, Electronics and Toy stores from a sample of U.S. users that have turned on Location History; Google Search Data, U.S., Apparel, Computer & Electronics and Games & Toys; Stores considered open after 6 P.M. on Thanksgiving, November 2015.

Posted by Doug Stevenson, Developer Advocate

Version 10.0.0 of the Google Play services client libraries, as well as the Firebase client libraries for Android, will be the last version of these libraries that support Android API level 9 (Android 2.3, Gingerbread). The next scheduled release of these libraries, version 10.2.0, will increase the minimum supported API level from 9 to 14 (Android 4.0.1, Ice Cream Sandwich). This change will happen in early 2017.

Why are we discontinuing support for Gingerbread and Honeycomb in Google Play services?

The Gingerbread platform is almost six years old. Many Android developers have already discontinued support for Gingerbread in their apps. This helps them build better apps that make use of the newer capabilities of the Android platform. For us, the situation is the same. By making this change, we will be able to provide a more robust collection of tools for Android developers with greater speed.

What this means for your Android app that uses Google Play services or Firebase:

You may use version 10.0.0 of Google Play services and Firebase as you are currently. It will continue to work with Gingerbread devices as it has in the past.

When you choose to upgrade to the future version 10.2.0, and if your app minimally supports API level 14 or greater (typically specified as "minSdkVersion" in your build.gradle), you will not encounter any versioning problems. However, if your app supports lower than API level 14, you will encounter a problem at build time with an error that looks like this:

Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 9 cannot be smaller than version 14 declared in library [com.google.android.gms:play-services:10.2.0]
        Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage

Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use Google Play services 10.2.0 and later, you can choose one of the following options:

1. Target API level 14 as the minimum supported API level.

This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 14. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.

A very small percentage of all Android devices are using API levels less than 14. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.

If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 10.0.0. This is described below.

2. Build multiple APKs to support devices with an API level less than 14.

Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the components of Play Services you're using:

productFlavors {
    legacy {
        minSdkVersion 9
        versionCode 901  // Min API level 9, v01
    }
    current {
        minSdkVersion 14
        versionCode 1401  // Min API level 14, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:10.0.0'
    currentCompile 'com.google.android.gms:play-services:10.2.0'
}

In the above situation, there are two product flavors being built against two different versions of the Google Play services client libraries. This will work fine if only APIs are called that are available in the 10.0.0 library. If you need to call newer APIs made available with 10.2.0, you will have to create a compatibility library for the newer API calls so that they are only built into the version of the application that can use them:

• Declare a Java interface that exposes the higher-level functionality you want to perform that is only available in current versions of Play services.
• Build two Android libraries that implement that interface. The "current" implementation should call the newer APIs as desired. The "legacy" implementation should no-op or otherwise act as desired with older versions of Play services. The interface should be added to both libraries.
• Conditionally compile each library into the app using "legacyCompile" and "currentCompile" dependencies.
• In the app's code, call through to the compatibility library whenever newer Play APIs are required.

After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.

Amy Baldwin

Alma Castillo

Deliver beautiful catalog experiences with Gmail ads

Customize your message with responsive ads

We're sharing guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016. This is the fifth post in that series and there are more on the way.


Linux XIA is the native implementation of XIA, a meta network architecture that supports evolution of all of its components, which we call “principals,” and promotes interoperability between these principals. It is the second year that our organization, Boston University / XIA, has participated in Google Summer of Code (GSoC), and this year we received 31 proposals from 8 countries.

Our ideas list this year focused on upgrading key forwarding data structures to their best known versions. Our group chose the most deserving students for each of the following projects:

Accelerating the forwarding speed of the LPM principal with poptrie

Student André Ferreira Eleuterio and mentor Cody Doucette implemented the first version of the LPM principal in Linux XIA for GSoC 2015. The LPM principal enables Linux XIA to leverage routing tables derived from BGP, OSPF, IS-IS and any other IP routing protocol to forward XIA packets natively, that is, without encapsulation in IP. For GSoC 2016, student Vaibhav Raj Gupta from India partnered with mentor Cody Doucette to speed up the LPM principal by employing a state-of-the-art data structure to find the longest prefix matching using general purpose processors: poptrie.

Upgrading the FIB hash table of principals to the relativistic hash table

Principals that rely on routing flat names have used a resizable hash table that supports lockless readers since 2011. While this data structure was unique in 2011, in the same year, relativistic hash tables were published. The appeal to upgrade to relativistic hash tables was twofold: reduced memory footprint per hashed element, and the fact they were implemented in the Linux kernel in 2014. Student Sachin Paryani, also from India, worked with mentor Qiaobin Fu to replace our resizable hash table with the relativistic hash table.

Google Summer of Code nurtures a brighter future. Thanks to GSoC, our project has received important code contributions, and our community has been enlarged. It was rewarding to learn that two of our GSoC students have decided to pursue graduate school after their GSoC experience with us: Pranav Goswami (2015) and Sachin Paryani (2016). We hope these examples will motivate other students to do their best because the world is what we make of it.

By Michel Machado, Boston University / XIA organization administrator

Author: Jochen Wuttke

In a recent post, we broadly talked about What Test Engineers do at Google. In this post, I talk about one aspect of the work TEs may do: building and improving test infrastructure to make engineers more productive.

Refurbishing legacy systems makes new tools necessary
A few years ago, I joined an engineering team that was working on replacing a legacy system with a new implementation. Because building the replacement would take several years, we had to keep the legacy system operational and even add features, while building the replacement so there would be no impact on our external users.

The legacy system was so complex and brittle that the engineers spent most of their time triaging and fixing bugs and flaky tests, but had little time to implement new features. The goal for the rewrite was to learn from the legacy system and to build something that was easier to maintain and extend. As the team's TE, my job was to understand what caused the high maintenance cost and how to improve on it. I found two main causes:

• Tight coupling and insufficient abstraction made unit testing very hard, and as a consequence, a lot of end-to-end tests served as functional tests of that code.
• The infrastructure used for the end-to-end tests had no good way to create and inject fakes or mocks for these services. As a result, the tests had to run the large number of servers for all these external dependencies. This led to very large and brittle tests that our existing test execution infrastructure was not able to handle reliably.

Exploring solutions
At first, I explored if I could split the large tests into smaller ones that would test specific functionality and depend on fewer external services. This proved impossible, because of the poorly structured legacy code. Making this approach work would have required refactoring the entire system and its dependencies, not just the parts my team owned.

In my second approach, I also focussed on large tests and tried to mock services that were not required for the functionality under test. This also proved very difficult, because dependencies changed often and individual dependencies were hard to trace in a graph of over 200 services. Ultimately, this approach just shifted the required effort from maintaining test code to maintaining test dependencies and mocks.

My third and final approach, illustrated in the figure below, made small tests more powerful. In the typical end-to-end test we faced, the client made RPCcalls to several services, which in turn made RPC calls to other services. Together the client and the transitive closure over all backend services formed a large graph (not tree!) of dependencies, which all had to be up and running for the end-to-end test. The new model changes how we test client and service integration. Instead of running the client on inputs that will somehow trigger RPC calls, we write unit tests for the code making method calls to the RPC stub. The stub itself is mocked with a common mocking framework like Mockito in Java. For each such test, a second test verifies that the data used to drive that mock "makes sense" to the actual service. This is also done with a unit test, where a replay client uses the same data the RPC mock uses to call the RPC handler method of the service.


This pattern of integration testing applies to any RPC call, so the RPC calls made by a backend server to another backend can be tested just as well as front-end client calls. When we apply this approach consistently, we benefit from smaller tests that still test correct integration behavior, and make sure that the behavior we are testing is "real".

To arrive at this solution, I had to build, evaluate, and discard several prototypes. While it took a day to build a proof-of-concept for this approach, it took me and another engineer a year to implement a finished tool developers could use.

Adoption
The engineers embraced the new solution very quickly when they saw that the new framework removes large amounts of boilerplate code from their tests. To further drive its adoption, I organized multi-day events with the engineering team where we focussed on migrating test cases. It took a few months to migrate all existing unit tests to the new framework, close gaps in coverage, and create the new tests that validate the mocks. Once we converted about 80% of the tests, we started comparing the efficacy of the new tests and the existing end-to-end tests.

The results are very good:

• The new tests are as effective in finding bugs as the end-to-end tests are.
• The new tests run in about 3 minutes instead of 30 minutes for the end-to-end tests.
• The client side tests are 0% flaky. The verification tests are usually less flaky than the end-to-end tests, and never more.

Additionally, the new tests are unit tests, so you can run them in your IDE and step through them to debug. These results allowed us to run the end-to-end tests very rarely, only to detect misconfigurations of the interacting services, but not as functional tests.

Building and improving test infrastructure to help engineers be more productive is one of the many things test engineers do at Google. Running this project from requirements gathering all the way to a finished product gave me the opportunity to design and implement several prototypes, drive the full implementation of one solution, lead engineering teams to adoption of the new framework, and integrate feedback from engineers and actual measurements into the continuous refinement of the tool.

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer
[Cross-posted from the Android Developers Blog]

Encryption protects your data if your phone falls into someone else's hands. The new Google Pixel and Pixel XL are encrypted by default to offer strong data protection, while maintaining a great user experience with high I/O performance and long battery life. In addition to encryption, the Pixel phones debuted running the Android Nougat release, which has even more security improvements.

This blog post covers the encryption implementation on Google Pixel devices and how it improves the user experience, performance, and security of the device.
File-Based Encryption Direct Boot experience
One of the security features introduced in Android Nougat was file-based encryption. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.

Direct boot uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software.

This secures encrypted data in two ways:

• TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.
• TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.