Feature Engineering in the Google Play Store

Posted by Harini Chandrasekharan, Staff Software Engineer, Google Play

The Google Play Store, launched 10 years ago in 2012 sits at the heart of Android, connecting billions of users with an equally staggering and ever-growing collection of apps and games worldwide.

Let's take a peek behind the curtains to learn what it takes to design the serving infrastructure of the worlds largest Android marketplace. In the world of consumer facing software, it's not a surprise that out of box engineering solutions fail to meet the requirements that Google scale demands. Therefore every system at Google is carefully crafted and honed with iterative enhancements to meet the unique availability, quality and latency demands of the Google Play Store.

What is feature engineering?

Features can be user-facing such as formats, content, arrangement of content, the page layout or information architecture. Formats represent how app content from our recommendation systems, advertisers, merchandisers and various other sources are presented on UI. The goal is to create tailor-made experiences weaving in the right content and UI to suggest the most relevant apps and games to meet the users where they are in their journey on the play store.

In the domain of consumer facing features, users’ opinions and choices, developer ecosystem and demand often changes faster than infrastructure can. In such an environment, the biggest challenge engineers face is how to be nimble and design infrastructure that’s not only future-proof but also meets the needs of the consumer space within the constraints of scalability and performance. Let’s take a deeper look at some engineering challenges in such a dynamic space.


What does success look like?

In a data driven organization such as the Play store, metrics are built for measuring anything and everything of importance. Here are some of the dimensions that come in handy when measuring and tracking success:

  • Product/business metrics - These are metrics specific to the product or service under consideration. Running A/B experiments to measure changes to these metrics for the new treatment builds confidence, particularly when decision making involves several tradeoffs.
  • Performance - Measuring latency, error rates and availability makes the backbone of almost every service and for good reason. Knowing these baseline metrics is essential since this closely tracks user experience and perception of the product.
  • System health - These are internal system metrics tracking resource utilization and fleet stability.

Challenges in feature engineering infrastructure

Designing backend systems that scale to the requirements of the Play Store that also meet the performance criteria required to make user interactions feel fluid and responsive is paramount. From an engineering perspective, infrastructure needs to continuously evolve to meet the needs of the business. The Play store is no different—the store infrastructure has evolved several times in the last decade to not only support the needs of new features that are available to users today, but also to modernize, eliminate tech debt and most of all reduce latency.


Frequent iteration

Challenge: Features often require large amounts of iteration over time, it's hard to plan engineering infrastructure that meets all the future requirements.

In an experiment driven culture, the optimum approach for rapidly building features at scale often results in tech debt. Tech debt has various forms—relics of past features that did not make it result in layers that are hard to clean up, affect performance, make code error prone and hard to test.

Independent evolution

Challenge: In large organizations spanning 100s of engineers, several features are often being built in parallel and independent of each other.

Infrastructure reuse and sharing innovations are often impossible without significantly compromising on velocity. In a space where the product evolves at a rapid pace there is often a large amount of uncertainty with the different levers and knobs one can build into systems to make them flexible. Too many levers can lead to large system complexity. Too few levers and the cost of iteration is sky high. Finding the balance between the two is one of the core competencies of a feature engineer in this space.

Time to experiment

Challenge: There is often an opportunity cost to pay for time spent building elegant engineering solutions.

Time to experiment is one of the most important metrics to keep in mind when designing solutions for user facing features. Flexible design that enables rapid iteration and meets the latency and other performance SLOs is ideal.

In practice, there is often a large amount of guesswork that goes into estimating impact of a particular user facing change, while we can use past data and learnings confidently to estimate in some scenarios, it's not sufficient for a brand new ambitious, never before tried idea.


Feature engineering guiding principles

Let’s see how the Play Store solves these challenges to enable state of the art innovation.

Data driven experiments and launches - understand your success metrics

Optimizing for time to market i.e getting the feature to the user and measuring how it impacts app installs and other store business metrics using A/B experiments is of prime importance. Iterating fast based on data helps tune the final feature to the desired end state. Google has several home grown technologies for running A/B experiments at worldwide scale with seamless integration with metric presentation tools that make running these experiments smooth and easy, so developers can spend more time coding and less in analysis.

Design and experiment with polished MVPs - with a focus on quality

Deciding what to build, whether it meets Google quality standards, understanding engineering costs and the user needs it solves are all important questions that need to be answered before designing anything. Feature Engineering is therefore often done in close collaboration with Product Managers. Aligning on the perfect MVP that can be built in a reasonable amount of engineering time that meets the user journey is the key to a successful product.

Frequently modernize the infrastructure - clean up tech debt

Frequent iterations and a fast MVP development culture often comes with its set of cons, the biggest being tech debt. In optimizing for fast velocity, cutting corners results in obsolete code (due to unlaunchable metrics) or discarded experiment flags. These often make testing, maintaining and impact future development velocity if left unfixed. Additionally, using the latest and greatest frameworks to get to the last milliseconds of latency or making development easier yields great dividends in the long run. Frequently modernizing the infrastructure either via refactoring or full rewrites may traditionally spell signs of poorly designed code, but it's one of the bigger tradeoffs that feature engineers often have to make, because after all what use is all the fancy infrastructure if users don't interact with the feature in the first place!


How useful did you find this blog post?

API desugaring supporting Android 13 and java.nio

Posted by Clément Béra, Software engineer

We are happy to announce the release of a new version of API desugaring based on Android 13 and Java 11 language APIs. API desugaring allows developers to use more APIs without requiring a minimum API level for your app. This reduces friction during development. You are now free to use the java.nio APIs no matter which Android version is on the user’s device. For example, libraries such as kotlin.io.path are now available on all Android devices, including devices running Android 7 and lower.

In addition to supporting java.nio, API desugaring of java.time and java.util.stream has been updated to support APIs added up to Android 13. You can use recent APIs in your Android app such as Collectors#toUnmodifiableList.

New API desugaring specifications

To enable API desugaring, you set isCoreLibraryDesugaringEnabled and add the coreLibraryDesugaring dependency in the build.gradle.kts file.

android { ... compileSdk = 33 defaultConfig { ... // Required when setting minSdkVersion to 20 or lower. multiDexEnabled = true ... } ... compileOptions { // Flag to enable support for API desugaring. isCoreLibraryDesugaringEnabled = true // Sets Java compatibility to Java 8 sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = "1.8" } } dependencies { // Dependency required for API desugaring. coreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.0.2") }

The new version 2.0 release comes in 3 flavors:

  • com.android.tools:desugar_jdk_libs_nio:2.0.2 - the nio version includes all the desugaring available including the java.nio, java.time, stream, and functions APIs.
  • com.android.tools:desugar_jdk_libs:2.0.2 - the default version includes desugaring for the java.time, stream, and functions APIs. It’s similar to version 1.x API desugaring already available, but updated with APIs added up to Android 13.
  • com.android.tools:desugar_jdk_libs_minimal:2.0.2 - the minimal version includes only the java.util.function package and bug fixes on concurrent collections. It’s designed for minimal code size overhead.

Opting into more desugaring features will lead to a larger impact on your app’s code size. The minimal specification has, as its name indicates, a minimal impact on the code size of the app. The nio specification has the most impact.

The new java.nio APIs

The new java.nio APIs supported in API desugaring include:

  • All the classes and APIs in java.nio.file such as BasicFileAttributes, file manipulation, or usage of java.nio.file.Path.
  • Some extensions of java.nio.channels, such as the FileChannel#open methods.
  • A few utility methods such as File#toPath.

The following code snippet illustrates how you can now use the new java.nio APIs on all devices, including devices running Android 7 and lower, through the methods of kotlin.io.path which depend on java.nio.file.Files. A temp file can be created, written into, read, and its basic attributes and its existence can be queried using the new java.nio APIs.

import android.util.Log import java.nio.file.StandardOpenOption.APPEND import kotlin.io.path.createTempDirectory import kotlin.io.path.deleteIfExists import kotlin.io.path.exists import kotlin.io.path.fileSize import kotlin.io.path.readLines import kotlin.io.path.writeLines ... val TAG = "java.nio Test" val tempDirectory = createTempDirectory("tempFile") val tempFile = tempDirectory.resolve("tempFile") tempFile.writeLines(listOf("first")) tempFile.writeLines(listOf("second"), options = arrayOf(APPEND)) Log.d(TAG,"Content: ${tempFile.readLines()}") Log.d(TAG,"Size: ${tempFile.fileSize()}") Log.d(TAG,"Exists (before deletion): ${tempFile.exists()}") tempFile.deleteIfExists() Log.d(TAG,"Exists (after deletion): ${tempFile.exists()}")

// Resulting logcat output. Content: first second Size: 13 Exists (before deletion): true Exists (after deletion): false

A few features however cannot be emulated for devices running Android 7 and lower and instead throw an instance of UnsupportedOperationException or return null. They still work on devices running Android 8 or higher, so existing code guarded by an API level check should work as it used to. See the complete list of APIs available and the known limitations.

The code has been extensively tested, but we are looking for additional inputs from app developers.

Please try out the new version of API desugaring, and let us know how it worked for you!

For additional background see the post Support for newer Java language APIs from when API desugaring was introduced.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 111 (111.0.5563.30) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Harry Souders
Google Chrome

Stable Channel Desktop Update

The Stable channel has been updated to 110.0.5481.104 for Windows only, which will roll out over the coming days/weeks. A full list of changes in this build is available in the log.

The Extended Stable channel has been updated to 110.0.5481.104 for Windows only which will roll out over the coming days/weeks.

Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Daniel Yip


Google Chrome

Enable next generation IDs for better Play Games Services support for all Google accounts

Posted by Laura Nechita, Software Engineering at Google Play and Victor Chen, Product Specialist at Google Play

To further enhance the privacy of users and their multi-platform gaming experience, Play Games Services (PGS) is introducing next generation Player IDs. With this change, the first time a user plays a game, they will always be assigned a unique next generation Player ID that will remain consistent regardless of the device or platform a user plays a game on, but which will vary from game to game.

Existing users, or accounts that have already signed into your game using PGS retain their current PGS Player IDs and are not affected by this change. If you have multiple titles in your portfolio and need a way to identify users across your titles to offer cross-game user experiences, we are also introducing a developer player key. Learn more.

With next generation IDs, it will also enable better Play Games Services support for all accounts, including those under supervision.

Here is a timeline for the rollout:

Feb 16, 2023
  • You can start testing next generation IDs using PGS test accounts
  • You can publish this feature once you have completed your testing
Apr 15, 2023

  • Next generation IDs are enabled in draft mode for newly created game projects
  • You can disable next generation IDs on the game properties page in Google Play Console
Feb 2024

  • Next generation IDs will be turned on in production for all game projects (including existing game projects)
  • If you notice any issues during this period you will have one month to disable next generation IDs and fix the issue
Mar 2024

  • Next generation IDs are required for all game projects and cannot be disabled

How this affects your game

  • Next generation IDs are only assigned to users signing in to PGS on your game for the first time.
  • Users who have already signed in to PGS on your game are not affected.
  • We are introducing a new developer player key which allows you to identify users across games in your portfolio.

ML Olympiad 2023: Globally Distributed ML Competitions by Google ML Community

Posted by Hee Jung, DevRel Community Manager

What is the ML Olympiad?

The ML Olympiad is an associated Kaggle Community Competitions hosted by ML GDE, TFUG, 3rd-party ML communities, supported by Google Developers. The ML Developer Programs team and the communities successfully ran the first round of the campaign in 2022 and are now launching the second round. The goal of this campaign is to provide ML training opportunities for developers by leveraging Kaggle’s features.

ML Olympiad Community Competitions

17 ML Olympiad community competitions are currently open. Visit the ML Olympiad page to participate.

Into the Space

  • Predicting which spaceship passengers were transported by the anomaly using records recovered from the spaceship’s damaged computer system.
  • Host: MD Shahriyar Al Mustakim Mitul / TFUG Dhaka

    Water Quality Prediction

    • Estimating the quality of water.
    • Hosts: Usha Rengaraju, Vijayabharathi Karuppasamy (TFUG Chennai), Samuel T (TFUG Mysuru)

      Breast Cancer Diagnosis

      • Predicting medical diagnosis [breast cancer].
      • Host: Ankit Kumar Verma / TFUG Prayagraj

        Book Recommendations

        • To provide personalized recommendations to users based on their reading history and preferences using various machine learning algorithms.
        • Hosts: Anushka Raj, Yugandhar Surya / TFUG Hajipur

          Argania Tree Deforestation Detection

          • Use Sentinel-2 satellite imagery to detect and map areas of deforestation in the Argania region.
          • Hosts: Taha Bouhsine / TFUG Agadir

            Multilingual Spell Correction

            • Reconstruct noisy sentences in European languages: English, French, German, Bulgarian and Turkish.
            • Host: Radostin Cholakov (ML GDE)

              CO2 Emissions Forecasting

              • Forecasting CO2 emissions based on deforestation in Côte d'Ivoire.
              • Hosts: Armel Yara, Kimana Misago, Jordan Erifried / TFUG Abidjan

                Ensure Healthy Lives (in local language) 

                • Use ML techniques to help achieve common good health and well-being.
                • Hosts: Vinicius Fernandes Caridá (ML GDE), Pedro Gengo, Alex Fernandes Mansano / TFUG São Paulo

                  Predictive Maintenance

                  • Predict future engine’s failures.
                  • Host: Daniel Pereda / TFUG Santiago

                    Firetrucks Are Red And Cars Are Blue

                    • To create a model that can accurately predict the correct class for each image, without overfitting.
                    • Host: Prasoon Kottarathil / TFUG Thrissur

                      Dialect Recognition (in Arabic) 

                      • Dialect recognition in order to improve user experience in AI applications.
                      • Hosts: Ruqiya Bin Safi (ML GDE), Eyad Sibai, Hussain Alfayez / Saudi TFUG & Applied ML/AI group

                        Sentiment Analysis Of JUMIA Tunisia  (in local language) 

                        • Use JUMIA customer reviews to determine the sentiment of content from text data.
                        • Host: Boulbaba BEN AMMAR / TFUG Sfax

                          Kolkata Housing Prediction

                          • Kolkata housing prediction results can be used to address related social and economic issues.
                          • Host: Rishiraj Acharya / TFUG Kolkata

                            Can You Guess The Beer Style?

                            • This is a machine learning competition focused on classifying beer into 17 distinct styles based on key descriptors.
                            • Host: Marvik

                              Detect ChatGpt answers

                              • The goal of this competition is to classify ChatGpt answers vs real human answers for a variety of questions.
                              • Host: Elyes Manai (ML GDE) / IEEE ESSTHS + GDSC ISETSO + PyData Tunisia

                                MLAct Pose Detection

                                • Raising awareness about some basic yoga poses, and encouraging our community members to practice the basic parts of computer vision.
                                • Host: Imen Masmoudi / MLAct ML Community

                                  Hausa Sentiment Analysis 2.0 (in local language) 

                                  • Classify the sentiment of sentences of Hausa Language.
                                  • Hosts: Nuruddeen Sambo, Dattijo Murtala Makama / TFUG Bauchi

                                    Navigating ML Olympiad

                                    You can search “ML Olympiad” on Kaggle Community Competitions page to see them all. And for further info, look for #MLOlympiad on social media.

                                    Google Developers supports the hosts of each competition. Browse through the available competitions and participate in those that interest you!

                                    Supporting DDR4 and DDR5 RDIMMs in open source DRAM security testing framework

                                    In 2021, Google and Antmicro introduced a platform for testing DRAM memory chips against the unfortunate side effect of the physical shrinking of memory chips—the Rowhammer vulnerability. The platform was developed to propose a radical improvement over the “security through obscurity” approach that was predominant in the industry; as both Antmicro and Google believe that the open source approach to mitigating security threats is a way towards accelerating developments in the field.

                                    The framework was originally developed in the context of securing consumer-facing devices, using off-the-shelf Digilent Arty (DDR3, Xilinx Series7 FPGA) and Xilinx ZCU104 (DDR4, Xilinx UltraScale+ FPGA) boards, then followed by a dedicated open hardware board from Antmicro that allowed work on custom LPDDR4 modules. The framework has since helped discover a new attack method named Blacksmith and continues to provide valuable insights into how the security of both edge device and data center memory can be improved.

                                    In constant development since then, the project has welcomed two more major elements to the ecosystem in order to enable testing of DDR4 Registered Dual In-Line Memory Modules (RDIMM)—commonly used in data centers as well as the newer DDR5 standard and continues to provide useful data.

                                    Memory testing for data center use cases

                                    To extend the Rowhammer tester support from consumer-facing devices to shared-compute data center infrastructure, Antmicro developed the data center DRAM tester board. We adapted this open source hardware-test platform from the original LPDDR4 board to enable Rowhammer and other memory security experiments with DDR4 RDIMMs using a fully configurable, open source FPGA-based DDR controller.

                                    The data center DRAM Xilinx Kintex-7 FPGA based test board features:

                                    • DDR4 RDIMM connector
                                    • 676 pins FPGA (compared to the 484 for the LPDDR version)
                                    • RJ45 Gigabit Ethernet
                                    • Micro-USB console
                                    • HDMI output connector
                                    • JTAG programming connector
                                    • MicroSD card slot
                                    • 12 MBytes QSPI Flash memory
                                    • HyperRAM—external DRAM memory that can be used as an FPGA cache
                                    Photo of the Antmicro data center DRAM Xilinx Kintex-7 FPGA based tester board

                                    It’s worth mentioning that the RDIMM DDR4 memory (as opposed to the custom LPDDR4 modules designed for the original project) are generic and available off-the-shelf. This makes it easier for security researchers to get started with data center memory security research compared to edge devices using LPDDR.

                                    The Data Center DRAM Tester board design has now been upgraded into revision 1.2, which brings new features for implementing even more complex DRAM testing scenarios. The 1.2 boards support a Power over Ethernet (PoE) supply option so the board can act as a standalone network device with data exchange and power-cycling done over a single Ethernet cable. This simplifies integration of the board in DRAM testing clusters and custom runners capable of doing hardware-in-the-loop testing.

                                    The new revision of the board will support hot-swapping of the DRAM module under test, which should speed up testing of multiple DRAM modules without the need to power-cycle the tester. Finally, the new revision of the board will include power-measurement circuitry so it will be possible to compare the peak and average power consumption of DRAM while working with different DRAM refresh scenarios.

                                    We are also working on a custom enclosure design suitable for desktop and networked installations.

                                    Extending open source testing to DDR5

                                    With DDR5 quickly becoming the new standard for data center memory, Antmicro and Google’s Platforms teams also set out to develop a platform capable of interfacing with DDR5 memories, again directly from a low-cost FPGA without a dedicated hard block. The resulting DDR5 tester platform follows the structure of the data center DDR4 tester, while expanding on functionality of the Serial Presence Detection, which monitors the power supply states and system health, or adjusting the circuitry for a nominal IO voltage of 1.1V.

                                    Photo of the Antmicro DDR5 testbed

                                    Data center DRAM testing is part of Google’s and Antmicro’s belief in security through transparency. Both hyperscalers and a growing number of organizations who operate their own data centers increasingly embrace this perspective, and there is great value in providing them with a scalable, customizable, commercially supported open source platform that will help in collaborative research and mitigation of emerging security issues.

                                    Rowhammer attacks, security threats, and countermeasures remain an active research area. With Google, Antmicro continues to adjust the Rowhammer test platform to most recent developments, opening the way for researchers and memory vendors to more sophisticated testing methods to enable testing of state-of-the-art memories used in data centers. This work stems from and complements other open source activities the companies jointly lead as members of RISC-V International and CHIPS Alliance, aimed at making the hardware ecosystem more open, secure and collaborative. If you’re interested in open source solutions for DRAM security testing and memory controller development, or more broadly, FPGA and ASIC design and verification, don’t hesitate to reach out to Antmicro at [email protected].

                                    By Michael Gielda – Antmicro