Category Archives: Android Developers Blog

An Open Handset Alliance Project

Plan for success on Google Play with Reach and devices

Posted by Lauren Mytton, Product Manager, Google Play

Google Play has over 2.5B monthly active users, distributed across the world, using many different devices. How do you make the most of this opportunity?

The concept of quality reach

The foundations for your game’s (or app’s) success on Google Play are its reach and its quality:

  • Reach: Can a player access your game?
  • Quality: Does the player experience good quality when playing your game?

To unlock the opportunity for any single user on Google Play, you need both: every user must be able to access your game, AND have a good technical experience when playing it.

This is the ideal state of quality reach.

Why quality reach is foundational to your game’s success

When you have quality reach, your game development, marketing budgets, and growth strategy can be lined up to reinforce each other, because you acquire users for whom your game performs well, and your engagement and retention strategies have higher ROI for users with good experiences.

If you have poor quality reach, you can inadvertently acquire users whom you will not be able to engage and retain. Any spend to acquire these users is likely to be wasted. But the bigger problem is that poor quality reach makes it harder for you to acquire users for whom your game does perform well, since Android vitals and user ratings may affect your game’s discoverability and conversion in the Play store.

Another scenario to keep an eye on is missed reach. Unlike poor quality reach, it may not hurt your ability to acquire users who can access and enjoy your game. However it still limits your game’s scale and possibly also its ROI.

How you achieve quality reach

There are three types of decisions that determine your quality reach:

  • Devices: the device specs you build for and target
  • Geographies: the countries, languages or localization you offer
  • Testing and optimization: what you plan for and prioritize during development and pre-launch

You make these decisions when you develop and publish a game for the first time, and you continue to make them with every new release over the lifecycle of your game. You also need to think about these decisions outside your release cycle, since the Play ecosystem is constantly changing, which means your quality reach will also change over time, even if you do nothing.

However these decisions can be very hard. They require you to answer, or predict the answers to, two questions:

  1. Where are my users?
  2. Where are my issues?

These questions are challenging because of the scale and diversity of users on Google Play, both technically and geographically. Not only that, but these decisions may be made at different points in time, across both business and technical teams. How do you get them to line up?

How Reach and devices can help

We’re launching a new tool in Play Console called Reach and devices to help with these challenges. Reach and devices is a data and insights tool that helps you to plan for quality reach, by helping you understand or predict the distribution of your users and your issues across the Google Play ecosystem.

Reach and devices takes data about your app and its peers and presents it in new ways, to help you answer these questions. It also makes it easier to get all the relevant teams in your organisation on the same page.

Key features:

  • Distribution and trends of user and issue metrics, starting with install base, crash rate and ANR rate (more metrics to come)
  • Metric breakdowns by key attributes including Android version, RAM, SoC, OpenGL ES version, Vulkan version and screen metrics (with more to come)
  • Peer data so you can spot opportunities in your current game, or even plan your next game
  • Country-level filtering for more precise launch and expansion planning
  • Export all data for bespoke analysis

We’ve received great feedback during closed beta from developers who have found it useful in a variety of ways:

  • Deciding what device specs to support
  • Spotting optimization opportunities
  • Assessing the ROI of addressing issues
  • Narrowing down the root cause of technical issues

Get started

Visit g.co/play/reachanddevices for more information or go straight to Play Console to check it out.

Plan for success on Google Play with Reach and devices

Posted by Lauren Mytton, Product Manager, Google Play

Google Play has over 2.5B monthly active users, distributed across the world, using many different devices. How do you make the most of this opportunity?

The concept of quality reach

The foundations for your game’s (or app’s) success on Google Play are its reach and its quality:

  • Reach: Can a player access your game?
  • Quality: Does the player experience good quality when playing your game?

To unlock the opportunity for any single user on Google Play, you need both: every user must be able to access your game, AND have a good technical experience when playing it.

This is the ideal state of quality reach.

Why quality reach is foundational to your game’s success

When you have quality reach, your game development, marketing budgets, and growth strategy can be lined up to reinforce each other, because you acquire users for whom your game performs well, and your engagement and retention strategies have higher ROI for users with good experiences.

If you have poor quality reach, you can inadvertently acquire users whom you will not be able to engage and retain. Any spend to acquire these users is likely to be wasted. But the bigger problem is that poor quality reach makes it harder for you to acquire users for whom your game does perform well, since Android vitals and user ratings may affect your game’s discoverability and conversion in the Play store.

Another scenario to keep an eye on is missed reach. Unlike poor quality reach, it may not hurt your ability to acquire users who can access and enjoy your game. However it still limits your game’s scale and possibly also its ROI.

How you achieve quality reach

There are three types of decisions that determine your quality reach:

  • Devices: the device specs you build for and target
  • Geographies: the countries, languages or localization you offer
  • Testing and optimization: what you plan for and prioritize during development and pre-launch

You make these decisions when you develop and publish a game for the first time, and you continue to make them with every new release over the lifecycle of your game. You also need to think about these decisions outside your release cycle, since the Play ecosystem is constantly changing, which means your quality reach will also change over time, even if you do nothing.

However these decisions can be very hard. They require you to answer, or predict the answers to, two questions:

  1. Where are my users?
  2. Where are my issues?

These questions are challenging because of the scale and diversity of users on Google Play, both technically and geographically. Not only that, but these decisions may be made at different points in time, across both business and technical teams. How do you get them to line up?

How Reach and devices can help

We’re launching a new tool in Play Console called Reach and devices to help with these challenges. Reach and devices is a data and insights tool that helps you to plan for quality reach, by helping you understand or predict the distribution of your users and your issues across the Google Play ecosystem.

Reach and devices takes data about your app and its peers and presents it in new ways, to help you answer these questions. It also makes it easier to get all the relevant teams in your organisation on the same page.

Key features:

  • Distribution and trends of user and issue metrics, starting with install base, crash rate and ANR rate (more metrics to come)
  • Metric breakdowns by key attributes including Android version, RAM, SoC, OpenGL ES version, Vulkan version and screen metrics (with more to come)
  • Peer data so you can spot opportunities in your current game, or even plan your next game
  • Country-level filtering for more precise launch and expansion planning
  • Export all data for bespoke analysis

We’ve received great feedback during closed beta from developers who have found it useful in a variety of ways:

  • Deciding what device specs to support
  • Spotting optimization opportunities
  • Assessing the ROI of addressing issues
  • Narrowing down the root cause of technical issues

Get started

Visit g.co/play/reachanddevices for more information or go straight to Play Console to check it out.

Plan for success on Google Play with Reach and devices

Posted by Lauren Mytton, Product Manager, Google Play

Google Play has over 2.5B monthly active users, distributed across the world, using many different devices. How do you make the most of this opportunity?

The concept of quality reach

The foundations for your game’s (or app’s) success on Google Play are its reach and its quality:

  • Reach: Can a player access your game?
  • Quality: Does the player experience good quality when playing your game?

To unlock the opportunity for any single user on Google Play, you need both: every user must be able to access your game, AND have a good technical experience when playing it.

This is the ideal state of quality reach.

Why quality reach is foundational to your game’s success

When you have quality reach, your game development, marketing budgets, and growth strategy can be lined up to reinforce each other, because you acquire users for whom your game performs well, and your engagement and retention strategies have higher ROI for users with good experiences.

If you have poor quality reach, you can inadvertently acquire users whom you will not be able to engage and retain. Any spend to acquire these users is likely to be wasted. But the bigger problem is that poor quality reach makes it harder for you to acquire users for whom your game does perform well, since Android vitals and user ratings may affect your game’s discoverability and conversion in the Play store.

Another scenario to keep an eye on is missed reach. Unlike poor quality reach, it may not hurt your ability to acquire users who can access and enjoy your game. However it still limits your game’s scale and possibly also its ROI.

How you achieve quality reach

There are three types of decisions that determine your quality reach:

  • Devices: the device specs you build for and target
  • Geographies: the countries, languages or localization you offer
  • Testing and optimization: what you plan for and prioritize during development and pre-launch

You make these decisions when you develop and publish a game for the first time, and you continue to make them with every new release over the lifecycle of your game. You also need to think about these decisions outside your release cycle, since the Play ecosystem is constantly changing, which means your quality reach will also change over time, even if you do nothing.

However these decisions can be very hard. They require you to answer, or predict the answers to, two questions:

  1. Where are my users?
  2. Where are my issues?

These questions are challenging because of the scale and diversity of users on Google Play, both technically and geographically. Not only that, but these decisions may be made at different points in time, across both business and technical teams. How do you get them to line up?

How Reach and devices can help

We’re launching a new tool in Play Console called Reach and devices to help with these challenges. Reach and devices is a data and insights tool that helps you to plan for quality reach, by helping you understand or predict the distribution of your users and your issues across the Google Play ecosystem.

Reach and devices takes data about your app and its peers and presents it in new ways, to help you answer these questions. It also makes it easier to get all the relevant teams in your organisation on the same page.

Key features:

  • Distribution and trends of user and issue metrics, starting with install base, crash rate and ANR rate (more metrics to come)
  • Metric breakdowns by key attributes including Android version, RAM, SoC, OpenGL ES version, Vulkan version and screen metrics (with more to come)
  • Peer data so you can spot opportunities in your current game, or even plan your next game
  • Country-level filtering for more precise launch and expansion planning
  • Export all data for bespoke analysis

We’ve received great feedback during closed beta from developers who have found it useful in a variety of ways:

  • Deciding what device specs to support
  • Spotting optimization opportunities
  • Assessing the ROI of addressing issues
  • Narrowing down the root cause of technical issues

Get started

Visit g.co/play/reachanddevices for more information or go straight to Play Console to check it out.

Introducing the Android Game Development Kit

Posted by Posted by Scott Carbon-Ogden, Product Manager Android Games

Today we’re launching the Android Game Development Kit (AGDK), a full range of tools and libraries to help you develop, optimize, and deliver high quality Android games.

AGDK features follow three key tenets:

  • Code built for game development. All of our libraries have been built and tested with performance in mind using C or C++ APIs.
  • Reduce fragmentation. The AGDK tools and libraries work across many different Android versions. Most of these features will work on almost any device in use today.
  • Built by Android, for Android. Features will be enhanced by future Android platform updates, and the libraries will provide backwards compatibility when possible.

In this initial launch, we’re focusing on covering three major areas where we heard a lot of feedback from our developer community: Integrated workflows, C/C++ game libraries, and performance optimization.

Integrated workflows

Generally, the less you need to switch tools, the more efficient you can be, so with AGDK, we’re providing new tools to facilitate Android game development in your primary IDE. We will focus on the bits of workflow where Google can add unique value and solve Android specific problems, while being compatible with whichever parts of your existing workflow you are comfortable with.

  • The Android Game Development Extension adds Android as a platform target to Visual Studio. This enables existing multi-platform Visual Studio game projects to quickly integrate Android as a new platform. Learn more in the AGDE session.
  • We are working with some of the most popular game engine developers to integrate our tools and libraries directly, so you can benefit from enhanced performance and stability without needing to make any changes.
  • Where that’s not possible, we’ve focused on building plugins for game engines such as Unity. These plugins are available in one place to help you quickly get what you need.

C/C++ game libraries

Start your C development with less Java Native Interface (JNI) by using our game libraries for C/C++ development. Most games and game engines are written in C++, whereas Android development often requires using the Java programming language. Bridging these two languages using a Java Native Interface requires effort and can introduce bugs or performance regressions. AGDK will help you build and customize game engines by providing C game libraries that minimize the use of the Java Programming language and JNI. This makes your games easier to build, debug, and maintain.

We’re focusing on what you’ve told us are your top frustrations. Initially, this will involve building foundational classes for activity and input. Longer term, we plan to make more C libraries to provide functionality that is commonly used across game engines. We're incorporating our existing frame pacing and high-performance audio libraries into this effort, and adding three new ones:

  • Game Activity provides a foundation for C++ games to be built on. It provides C interfaces for all the Android events that you'd expect, from screen rotation to app lifecycle. This way you can minimize the amount of development time you spend in the Java language. Unlike Native Activity, Game Activity is compatible with fragments and extendable, making it easier to integrate some of your favourite SDKs.
  • Game Text input provides a stable way to use the software keyboard in C, that is officially supported and will work across Android versions.
  • Game Controller is a way to handle input from game controllers in C, to map their functions and to reconnect to the device when necessary.

Learn more about these libraries in our C/C++ libraries session.

To make integration as easy as possible, you can get all our libraries as a Maven dependency, as a pre-compiled Zip file, or as source code.

Performance optimization

Our goal is to help you find any stability or performance issues before launch and monitor your game post-launch to catch any issues. We’re starting with the most important metrics like frame rate, loading time, and memory, and will be including new metrics over time.

  • We’re launching a major update to the Android GPU Inspector (AGI), that includes frame profiling functionality. This works alongside the existing GPU profiling elements to help you fully understand any GPU related issues. AGI is currently in open beta, and you can learn more in our GPU inspector session.
  • We also have a suite of profilers in Android Studio and AGDE for the system, power, CPU, and our new native memory profiler that game devs can use to find inefficiencies.
  • Android Performance Tuner provides user telemetry. You can use it to see how different parts of your game perform and how your game performs across different devices. You may already be using this tool for frame rate, and now we’re launching a new loading time function. Learn more in our Android Performance Tuner session.

Visit g.co/android/AGDK for our latest resources for Android game development and to download the AGDK. Check out the mobile session track for the full lineup of sessions from the Google for Games Developer Summit.

Updates from the Google for Games Developer Summit

Posted by Posted by Greg Hartrell, Product Management Director, Google Play & Android

Last year we saw Android and Play reach new heights with people playing more games safely at home. By continually making Google Play a better place for consumers, we've made it a richer place for game developers to connect with a diverse global audience. So much in fact, that Android has reached 3B monthly active devices, and Play grew to reach 2.5B monthly active users driving 140B installations worldwide.

At Google we build for everyone, and that means we’re here to help all developers reach gamers in the right moments: from the largest game studios, to the indie shops conjuring up fun and innovative games across the world.

During our Game Developer Summit, we shared updates on a breadth of tools and solutions to help you across the lifecycle of your gaming business. We announced new tools to make game development easier, updates on a growing ecosystem to help get your games running on more screens, and new opportunities to drive your go-to-market success on Google Play.

Here’s more about everything we shared and how you can get started today.

Easier development

  • We launched the Android Game Development Kit, a full range of tools and libraries to help you develop, optimize, and deliver high quality Android games. In this initial launch, AGDK covers three major areas:

    1. Integrated workflows (e.g. a new Visual Studio extension)

    2. Essential C/C++ game libraries (e.g. the new Game Text Input library)

    3. Performance optimization (e.g. frame profiler support in our GPU profiler and new loading time support in Android Performance Tuner)

    • In Android 12, we’re working on two new areas. Game dashboard provides an overlay experience with quick access to key utilities during gameplay - like screen capture, recording, and more, and will be available on select devices later this year. With Game Mode APIs, you can react to players selecting a performance profile for their game - like better battery life for a long commute, or performance mode to get peak frame rates. Integrate Game Mode APIs prior to the launch of Android 12 via Beta releases.
    • Reach and devices is a new data and insights tool that helps you plan for more success on Google Play. It enables you to understand and predict the distribution of your users and technical issues across countries and key device attributes (like Android version, memory, graphics stack and chipsets). You can use it to make the business case for country and device targeting decisions, to spot optimization opportunities, and to set test priorities for your next release.
    • Firebase Remote Config lets you update the behavior and appearance of your game for different audience segments without releasing a new version. The new personalization feature is now available in early access via the Firebase Alpha program. It uses the power of Google’s machine learning to automatically deliver the best experience to each of your users, individually.

More screens

  • On Chrome OS this past year, Google Play usage grew 300%, marking its biggest year of app and game usage since we launched Google Play on Chromebooks in 2016. Unity recently introduced support for Chrome OS on Unity 2021.2, with support for Unity 2020 LTS coming later this year. Optimize your game and join the growing number of developers building for Chrome OS today to access this rapidly expanding audience.

Go-to-market success

  • Play as you download, built into the core of Android 12, will allow users to get into gameplay in seconds while game assets are downloaded in the background. We are seeing games being ready to open at least 2 times faster and we are very excited about the improved user experience.
  • We’ve continued our innovation with Play Asset Delivery to ensure players spend less time waiting for downloads without sacrificing the quality of your game. Now, Texture Compression Format Targeting automatically figures out what modern compression formats to use to further reduce your game’s size.
  • Ratings and Reviews in the Play Console now offer new ways to help you understand your game’s ratings with views across different form-factors, the ability to access and query your ratings history, and new historical ratings metrics.
  • We refreshed Pre-registration in Play Store to be more useful. And now you can use App campaigns for pre-registration to build greater excitement for your game in open testing, or to drive pre-registrations in the Play Store.
  • The new Play Integrity API is designed to help you fight abuse, such as cheating and unauthorized early access by helping you determine if you’re interacting with your genuine game binary, installed by Google Play, on a genuine Android device. Express interest in the Play Integrity API early access program.

Check out the mobile session track for the full lineup of sessions from the Google for Games Developer Summit and bookmark g.co/android/games for our latest resources for Android game development.

Announcing Android’s updateable, fully integrated ML inference stack

Posted by Oli Gaymond, Product Manager, Android ML

On-Device Machine Learning provides lower latency, more efficient battery usage, and features that do not require network connectivity. We have found that development teams deploying on-device ML on Android today encounter these common challenges:

  • Many apps are size constrained, so having to bundle and manage additional libraries just for ML can be a significant cost
  • Unlike server-based ML, the compute environment is highly heterogeneous, resulting in significant differences in performance, stability and accuracy
  • Maximising reach can lead to using older more broadly available APIs; which limits usage of the latest advances in ML.

To help solve these problems, we’ve built Android ML Platform - an updateable, fully integrated ML inference stack. With Android ML Platform, developers get:

  • Built in on-device inference essentials - we will provide on-device inference binaries with Android and keep them up to date; this reduces apk size
  • Optimal performance on all devices - we will optimize the integration with Android to automatically make performance decisions based on the device, including enabling hardware acceleration when available
  • A consistent API that spans Android versions - regular updates are delivered via Google Play Services and are made available outside of the Android OS release cycle

Built in on-device inference essentials - TensorFlow Lite for Android

TensorFlow Lite will be available on all devices with Google Play Services. Developers will no longer need to include the runtime in their apps, reducing app size. Moreover, TensorFlow Lite for Android will use metadata in the model to automatically enable hardware acceleration, allowing developers to get the best performance possible on each Android device.

Optimal performance on all devices - Automatic Acceleration

Automatic Acceleration is a new feature in TensorFlowLite for Android. It enables per-model testing to create allowlists for specific devices taking performance, accuracy and stability into account. These allowlists can be used at runtime to decide when to turn on hardware acceleration. In order to use accelerator allowlisting, developers will need to provide additional metadata to verify correctness. Automatic Acceleration will be available later this year.

A consistent API that spans Android versions

Besides keeping TensorFlow Lite for Android up to date via regular updates, we’re also going to be updating the Neural Networks API outside of OS releases while keeping the API specification the same across Android versions. In addition we are working with chipset vendors to provide the latest drivers for their hardware directly to devices, outside of OS updates. This will let developers dramatically reduce testing from thousands of devices to a handful of configurations. We’re excited to announce that we’ll be launching later this year with Qualcomm as our first partner.

Sign-up for our early access program

While several of these features will roll out later this year, we are providing early access to TensorFlow Lite for Android to developers who are interested in getting started sooner. You can sign-up for our early access program here.

Google Play services discontinuing updates for Jelly Bean (API levels 16, 17 & 18)

Posted by Vikas Kansal, Product Manager, Google Play services

The Android Jelly Bean (JB) platform was first released 9 years ago and as of July 2021, the active device count is below 1%. Since then Android has released a lot of improvements and features which are not all backported to Jelly Bean. This results in increased developer and QA time spent on new features that require special handling. Consequently, we are deprecating support for JB in future releases of Google Play services. For devices running JB, Google will no longer update the Play Services APK beyond version 21.30.99, scheduled for the end of August 2021.

What does this mean as an Application developer:

The Google Play services SDKs contain the interfaces to the functionality provided by the Google Play services APK, which runs as background services. The functionality required by the current, released SDK versions is already present on JB devices with Google Play services and will continue to work without change.

Each SDK can be independently released and may update its own minSdkVersion. Individual libraries are not required to change based on this deprecation. Newer SDK components may continue to support API levels 16 through 18 but many will update to require the higher API levels. For applications that support API levels 19 or greater, you will not need to make any changes to your build. For applications that support API levels 16 through 18, you may continue to build and publish your app to devices running JB, but you may encounter build errors when updating to newer SDK versions. The error will look like this: 

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

Unfortunately, the stated suggestion will not help you provide app updates to devices running JB or older. In order to use the newer SDK, you will need to use one of the following options:

1. Use API level 19 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 19. 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 19. We believe that many of these old devices may not be 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 21.30.99. This is described below.

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

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 16
        versionCode 101  // Min API level 16, v01
    }
    current {
        minSdkVersion 19
        versionCode 1901  // Min API level 19, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:16.0.0'
    currentCompile 'com.google.android.gms:play-services:17.0.0'
}

In the above situation, there are two product flavors being built against two different versions of play-services-FOO. This will work fine if only APIs are called that are available in the 16.0.0 library. If you need to call newer APIs made available with 17.0.0, you will have to create your own compatibility library for the newer API calls so that they are only built into the version of the application that can use them:

  1. Declare a Java interface that exposes the higher-level functionality you want to perform that is only available in current versions of Play services.
  2. 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.
  3. Conditionally compile each library into the app using "legacyCompile" and "currentCompile" dependencies as illustrated for play-services-FOO above.
  4. 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.

MAD Skills Navigation Series 2 Wrap Up!

Posted by Murat Yener

It’s a wrap!! We’ve just finished the second series of Navigation on MAD Skills. In this series, we re-visited Chet’s DonutTracker app and added an important missing feature: the ability to track coffee.

With new functionality comes new responsibilities. While we added coffee tracking, we also improved the navigation experience, implemented conditional navigation, modularized the app and finally learned what is changing with multiple back stack support.

Episode 1: NavigationUI

As new destinations were added to the app,we used NavigationUI to offer a better navigation UI experience. NavigationUI helped us automatically integrate NavigationView and BottomNavigationView with the existing menu ids for destinations. You can check out the video linked below or if you prefer read the article here.

Episode 2: Conditional Navigation

We added coffee tracking functionality in the first episode but no matter whether users disable or enable the coffee tracker, they could still navigate to the CoffeeList fragment. In this episode, we fixed that by adding conditional navigation and directing our users to make a selection when they launch the app for the first time.

You can find the same content in article form here.

Episode 3: Nested Graphs and Include

In the third episode, we took a step back and organized the navigation graph by using nested graphs and using the include tag to import other graphs. While keeping our project more organized, this also allowed us to modularize the app and see how navigation works with modules. Check out the article or the video below.

Episode 4: Feature Modules

In the fourth episode, we took the app a step further and converted the coffee module to a feature module. With this change, the coffee tracking feature will only be downloaded and installed for users who enabled this feature. Dynamic features allowed us to modularize the app to save network and storage for the user. To learn more, check out the video linked below or if you prefer read the article here.

Episode 5: Multiple Back Stacks

In this episode, we covered a highly requested feature, multiple back stack support for Navigation. To support multiple back stacks, all you need to do is to update your navigation and fragment dependencies. You can observe multiple back stack behavior with NavigationView and BottomNavigationView instantly without any code change!

You can also find the same content in article form here.

Episode 6: Live Q&A

Finally, we wrapped up the second series of Navigation with a live Q&A session where we answered your questions. If you missed the Q&A, make sure to check out the recording below.

Sample Apps

Donut and Coffee Tracker

The application used for the first 4 episodes in the series is the DonutTracker app which Chet built during the first Navigation series on MAD Skills. You can follow the progress in each episode by checking out the starter and solution code from this repo.

Navigation Advanced Sample

This project is used to demonstrate Multiple back stack support in Navigation. Before Navigation version 2.4.0-alpha01, this project offered NavigationExtensions to mimic the multiple back stack behavior. You can check out the solution code with updated dependencies and NavigationExtensions removed in this repo.

This brings an end to the second Navigation series but the MAD series will continue with another exciting topic! Make sure you stay tuned for more Android MADness!

MAD Skills Navigation Series 2 Wrap Up!

Posted by Murat Yener

It’s a wrap!! We’ve just finished the second series of Navigation on MAD Skills. In this series, we re-visited Chet’s DonutTracker app and added an important missing feature: the ability to track coffee.

With new functionality comes new responsibilities. While we added coffee tracking, we also improved the navigation experience, implemented conditional navigation, modularized the app and finally learned what is changing with multiple back stack support.

Episode 1: NavigationUI

As new destinations were added to the app,we used NavigationUI to offer a better navigation UI experience. NavigationUI helped us automatically integrate NavigationView and BottomNavigationView with the existing menu ids for destinations. You can check out the video linked below or if you prefer read the article here.

Episode 2: Conditional Navigation

We added coffee tracking functionality in the first episode but no matter whether users disable or enable the coffee tracker, they could still navigate to the CoffeeList fragment. In this episode, we fixed that by adding conditional navigation and directing our users to make a selection when they launch the app for the first time.

You can find the same content in article form here.

Episode 3: Nested Graphs and Include

In the third episode, we took a step back and organized the navigation graph by using nested graphs and using the include tag to import other graphs. While keeping our project more organized, this also allowed us to modularize the app and see how navigation works with modules. Check out the article or the video below.

Episode 4: Feature Modules

In the fourth episode, we took the app a step further and converted the coffee module to a feature module. With this change, the coffee tracking feature will only be downloaded and installed for users who enabled this feature. Dynamic features allowed us to modularize the app to save network and storage for the user. To learn more, check out the video linked below or if you prefer read the article here.

Episode 5: Multiple Back Stacks

In this episode, we covered a highly requested feature, multiple back stack support for Navigation. To support multiple back stacks, all you need to do is to update your navigation and fragment dependencies. You can observe multiple back stack behavior with NavigationView and BottomNavigationView instantly without any code change!

You can also find the same content in article form here.

Episode 6: Live Q&A

Finally, we wrapped up the second series of Navigation with a live Q&A session where we answered your questions. If you missed the Q&A, make sure to check out the recording below.

Sample Apps

Donut and Coffee Tracker

The application used for the first 4 episodes in the series is the DonutTracker app which Chet built during the first Navigation series on MAD Skills. You can follow the progress in each episode by checking out the starter and solution code from this repo.

Navigation Advanced Sample

This project is used to demonstrate Multiple back stack support in Navigation. Before Navigation version 2.4.0-alpha01, this project offered NavigationExtensions to mimic the multiple back stack behavior. You can check out the solution code with updated dependencies and NavigationExtensions removed in this repo.

This brings an end to the second Navigation series but the MAD series will continue with another exciting topic! Make sure you stay tuned for more Android MADness!

The future of Android App Bundles is here

Posted by Dom Elliott, Product Manager at Google Play

Android App Bundles logo

Since we launched the Android App Bundle in May 2018, we’ve seen our developer community embrace this new standard to benefit from streamlined releases and advanced distribution features. There are now over 1 million apps using app bundles in production, including the majority of the top 1,000 apps and games on Google Play such as Adobe, Duolingo, Gameloft, Netflix, redBus, Riafy, and Twitter.

To bring these benefits to more users and focus on modern Android distribution that benefits all developers, Google Play will start requiring new apps to be published with the Android App Bundle starting August 2021. This will replace the APK as the standard publishing format.

Modern Android distribution

If you haven’t made the switch to app bundles yet, here are some of the benefits you’re missing:

  • Android App Bundle: Google Play uses the app bundle to generate and optimize APKs for distribution for different device configurations and languages. This makes your app smaller (on average, 15% smaller than a universal APK) and faster to download, which can lead to more installs and fewer uninstalls.
  • Play App Signing: Play App Signing, which is required for app bundles, protects your app signing key from loss by using Google’s secure infrastructure and offers the option of upgrading to a new, cryptographically stronger app signing key.
  • Play Feature Delivery: Used by more than 10% of the top apps using app bundles, Play Feature Delivery gives you the ability to customize what feature modules are delivered to which device and when, with install-time, conditional, and on-demand delivery modes.
  • Play Asset Delivery: Reduces user waiting time by dynamically delivering large assets while cutting delivery costs. Games using Play Asset Delivery can use texture compression format targeting, so your users only get the assets suitable for their device, with no wasted space or bandwidth.
  • Future improvements: Soon, Play App Signing will start rolling out APK Signature Scheme v4 to select apps making it possible for them to optionally access upcoming performance features available on newer devices. Tune into the Google for Games Developer Summit on July 12 to find out more.

Recap of what’s changing starting August 2021

TYPE OF RELEASE

REPLACED

REQUIRED AUG 2021

New apps 

on Google Play

APK

Android App Bundle (AAB)

Expansion files (OBBs)

Play Asset Delivery or 

Play Feature Delivery

Updates to existing apps

No change

New instant experiences

Instant app ZIP

Instant-enabled Android App Bundle (AAB)

Updates to instant experiences

As a reminder, the app bundle requirement applies to new apps. Existing apps are currently exempt, as are private apps being published to managed Google Play users. Thanks to the thousands of developers who have been a part of the app bundle journey. We look forward to bringing you more improvements and features soon.

- - -

Answers to some Android App Bundle FAQs

How much work is required to use an app bundle vs an APK?

For most apps, very little work is required to build an AAB instead of an APK. It’s mostly a matter of choosing a different option at build time and then testing as normal. The app bundle is an open source format supported by major build tools such as Android Studio, Gradle, Bazel, Buck, Cocos Creator, Unity, Unreal Engine, and other engines. Play Core Native and Play Core Java & Kotlin SDKs also make it easy to start using optional, advanced app bundle features, whatever your preferred coding environment.

Why aren't expansion files (OBBs) supported with app bundles? Why should games use Play Asset Delivery?

APKs require separate files (OBBs) to serve additional resources to users. However, because OBBs are not signed and are stored in the app’s external storage, they’re not very secure. With Play Asset Delivery (PAD), games larger than 150MB can replace OBBs by publishing the entire game as a single app bundle on the Play Store. Beyond offering a smoother publishing process and flexible delivery modes, PAD carries benefits over the legacy expansion files: its delta patching of assets is optimized for large apps meaning updates require dramatically less device storage than OBBs. As a result, fast-follow drives higher install rate and store conversion rate. Finally, with ASTC now supported on ~80% of devices, texture compression format targeting lets you serve ASTC to devices that support it. You can target the widest range of Android devices while making efficient use of the available hardware and device storage.

If I use app bundles, can I still publish through multiple distribution channels/app stores?

Yes, there are multiple ways to achieve this. You can either use the same app signing key everywhere or use unique app signing keys for different channels, including a unique app signing key for Google Play. You can either build and sign artifacts for all distribution channels locally or you can download distribution APKs from Google Play for use on other channels. Distribution APKs downloaded from Google Play, either via the app bundle explorer in Play Console or via the Play Developer API, are signed with the same key used by Play App Signing.

I’m launching a new app. Can I decide what my app signing key is?

Yes, this option is available in the Play Console. When creating a new app, you can choose one of the options to provide the app signing key that Google uses. This allows you to keep a copy of your app signing key locally, for example to generate signed versions for distribution through other channels using the same key as the Play version. Soon, the Play Console will make releasing an app for the first time a little easier by giving you the ability to change your app signing key if you make a mistake, as long as you do it before you publish to an open track the first time.

When distributing apps on Google Play, how do I ensure my app is delivered to users the way I intend?

At any time, you can download and inspect artifacts from the Play Store, from the app bundle explorer in the Play Console, and via the Play Developer API to verify your app. In addition, code transparency for app bundles is a new, optional feature that can be used to inspect that code running on a device matches the code that was originally built and signed by the developer.

I have an app published on Google Play already. Can I start using Play App Signing without providing a copy of my existing app signing key?

To use Play App Signing today you have to provide a copy of your existing app signing key because Google Play needs a copy of it to sign and deliver updates to your existing users. This suits most developers, over 1M apps are using Play App Signing in production. Soon, we will add an additional option for existing apps to opt in to Play App Signing by performing a key upgrade. Choosing this option means Play App Signing can use a new, unique key for all new installs and their updates. However, for this to work, when you upload an app bundle, you also need to upload a legacy APK signed with your old key so that Google Play can continue to deliver updates to your existing users.

Can I ever change my app signing key?

Yes, some apps can request an app signing key upgrade for new installs in Play Console. Google Play will use your new key to sign new installs and app updates while using your legacy app signing key to sign updates for users who installed your app before the key upgrade. Soon, Play App Signing key upgrade will also add support for APK Signature Scheme v3 key rotation. This will make key upgrade a possible option for more apps and help apps signed with upgraded keys reach more users.