Category Archives: Android Developers Blog

An Open Handset Alliance Project

Treble Plus One Equals Four

Posted by Iliyan Malchev (Project Treble Architect), Amith Dsouza (Technical Account Manager) , and Veerendra Bhora (Strategic Partnerships Manager)

Illustration of phone with settings logo in the screen

Extending Android updates on Qualcomm’s Mobile Platforms

In the past few years, the latest Android OS has been adopted earlier by OEMs and deployed in larger numbers to our users. The growth in adoption has been driven by OEMs delivering faster OS updates, taking advantage of the architecture introduced by Project Treble.

At the time Android 11 launched there were 667M active users on Android 10, 82% of whom got their Android 10 build via an over the air (OTA) update. Despite the events throughout 2020, there is a continued momentum among our partners to either launch their devices on Android 11 or offer Android 11 OTAs on their devices earlier.

Line graph comparing Android Pie, Android 10, and Android 11

Our efforts till now have been focussed on making OS updates easier and faster to deploy. The other side of this coin is supporting updates for a longer period of time, and today we’d like to provide an overview of the changes we are making to help our partners achieve this.

Project Treble was an ambitious re-architecture of Android that created a split between the OS framework and device-specific low-level software (called the vendor implementation) through a well-defined, stable vendor interface. As a part of this split, the Android OS framework guarantees backward compatibility with the vendor implementation, which is checked through a standardized compliance test suite - VTS. With each Android release, Project Treble publishes Generic System Images (GSIs) that are built from AOSP sources, and are guaranteed to be backwards-compatible with the previous 3 versions of vendor implementations, in addition of course to the current release—for a total span of four years. Devices launching with the new Android release must have vendor implementations compatible with that GSI. This is the primary vehicle for reducing fragmentation within the OS framework. While we allow and encourage our partners to modify the framework itself, the modifications post-Treble must be done in a way that reduces upgrade costs from one version to the next.

Besides the reuse of a vendor implementation across OS updates, the Treble architecture also facilitates the re-use of the same OS framework code across different vendor implementations.

Chart comparing Original OS framework to Updated OS framework

Another important change introduced by Project Treble is that new vendor-impacting requirements for Android devices are never retroactive. They apply only to devices launching on that Android version and not to devices upgrading from an older version. The term vendor-impacting here refers to requirements for new HALs, or for the shipping of a newer Linux kernel, to the device's vendor implementation. A good example might be a new revision of the camera HAL to support multiple rear camera sensors. Since the Android framework guarantees compatibility with the older HALs, we enable older vendor implementations to be reused by OEMs for upgrades without the considerable cost of updating them with new requirements.

This principle, combined with the backwards-compatibility guarantee, gives device manufacturers (OEMs) the flexibility to support upgrades both faster (since they have to upgrade just the framework, which would cover all of their devices, including those with older versions of the vendor implementation), as well as at a lower cost (since they do not have to touch the older vendor implementations).

However, seen from a System-on-Chip manufacturers’ perspective, this design introduces additional complexity. For each SoC model, the SoC manufacturers now needed to create multiple combinations of vendor implementations to support OEMs who would use that chipset to launch new devices and deploy OS upgrades on previously launched devices.

The result is that three years beyond the launch of a chipset, the SoC vendor would have to support up to 6 combinations of OS framework software and vendor implementations. The engineering costs associated with this support limited the duration for which SoC vendors offered Android OS software support on a chipset. For every single chipset, the software support timeline would look like this:

Timeline of OS framework

Considering that SoC providers have dozens of SoC models at any point of time, the full picture looks closer to this:

More accurate support timeline

The crux of the problem was that, while device requirements were never retroactive, the requirements for SoCs were. For example on Android Pie, SoCs had to support two versions of the Camera HAL API on a chipset if it was used to support new device launches and upgrades.

From this perspective, the solution was simple: we had to extend the no-retroactivity principle to the SoCs as well as to devices. With this change, the SoC provider would be able to support Android with the same vendor implementations on their SoCs for device launches as well as upgrades.

During the past year, we have been working hard to implement this solution. Building on our deep collaboration with our colleagues at Qualcomm, today we’re announcing the results of this work. Going forward, all new Qualcomm mobile platforms that take advantage of the no-retroactivity principle for SoCs will support 4 Android OS versions and 4 years of security updates. All Qualcomm customers will be able to take advantage of this stability to further lower both the costs of upgrades as well as launches and can now support their devices for longer periods of time.

Going one step further, we’re also reusing the same OS framework software across multiple Qualcomm chipsets. This dramatically lowers the number of OS framework and vendor implementation combinations that Qualcomm has to support across their mobile platforms and results in lowered engineering, development, and deployment costs. The diagram below indicates how significant the simplification is. From a software-support perspective, it's an altogether different situation:

Framework timeline with simplification

This change is taking effect with all SoCs launching with Android 11 and later. By working closely with Qualcomm to offer an extended period of OS and security updates, we are looking forward to delivering the best of Android to our users faster, and with greater security for an extended period of time.

Opening the Google Play Store for more car apps

Posted by Eric Bahna, Product Manager

In October, we published the Android for Cars App Library to beta so you could start bringing your navigation, parking, and charging apps to Android Auto. Thanks for sending your feedback with our issue tracker, so we know where to improve and clarify things. Now we’re ready to take the next step in delivering great in-car experiences.

Today, you can publish your apps to closed testing tracks in the Google Play Store. This is a great way to get feedback on how well your app meets the app quality guidelines, plus get your in-car experience in front of your first Android Auto users.

Image of T map
Image of PlugShare
Image of 2GIS

Three of our early access partners: T map, PlugShare,and 2GIS

We’re preparing the Play Store for open testing tracks soon. You can get your app ready today by publishing to closed testing. We’re eager to see what you’ve built!

What’s your MAD score?

Posted by Christopher Katsaros; Your #MADscore tabulator

We’ve been talking to you a lot recently about modern Android development (MAD), through the MAD Skills series. Now it’s time to see: what’s your MAD score? From how many Jetpack libraries you’re using to what percent of your app is coded in Kotlin, today we’re launching a MAD scorecard that shows just how modern an Android developer you are.

Your MAD scorecard uses Android Studio to tell you interesting things like how much size savings your app is seeing through the Android App Bundle. It spotlights each of the key MAD technologies, including specific Jetpack libraries and Kotlin features you could be using. You’ll even get a special MAD character based on your MADest skill (who knows, you just might be a MAD scientist…).

Here’s how to get your scorecard

You can get a personalized look into your MAD score through a new Android Studio plugin, here’s how to get and share your scorecard:

  • Step 1 - Install the plugin: Through Android Studio’s plugin marketplace, find and download the MAD Scorecard plugin. Install easily and quickly through your Studio.
  • Step 2 - Run the plugin: You can always find your MAD Scorecard plugin under Analyze in your main Studio menu. Click on Analyze, and Run to start creating your very own Scorecard.
  • Step 3 - View and share your scorecard: When you’ve completed running the plugin, Studio will show you a notification with your personal link where you can view all the details of your scorecard. Enjoy your results and share it with others!

Level up with the MAD Skills series

Once you’re done with your scorecard, check out the episodes in MAD Skills, a series of videos and articles we’re creating to teach you how to use the latest technologies of Modern Android Development to create better applications more easily. Arranged as a series of three-week topics, from Navigation to Kotlin to Android Studio, each topic will conclude with a Q&A where we’ll answer your questions. You can check out some of our earlier topics, like Material Design Components, App Bundles, and Navigation, and tune into Android Developers on YouTube for future topics.

See your MAD scorecard and share it with all of your friends, here!

MAD Skills Material Design Components: Wrap-Up

Posted by Nick Rout

wrap up header image

It’s a wrap_content!

The third topic in the MAD Skills series of videos and articles on Modern Android Development is complete. This time around we covered Material Design Components (a.k.a MDC). This library provides the Material Components as Android widgets and makes it easy to implement design patterns seen on material.io, such as Material Theming, Dark Theme, and Motion.

Check out the episodes and links below to see what we covered. We designed these videos to closely follow our recent series of MDC articles as well as existing sample apps and codelabs, so you’ve got a variety of ways to engage with the content. We also had a Q&A episode featuring engineers from the MDC team!

Episode 1: Why use MDC?

The first episode by Nick Butcher is an overview video of this entire MAD Skills series, including why we recommend MDC, then deep-dives on Material Theming, Dark Theme and Motion. It also covers MDC interop with Jetpack Compose and updates to Android Studio templates that include MDC and themes/styles best practices.

Or in article form:

https://medium.com/androiddevelopers/we-recommend-material-design-components-81e6d165c2dd

Episode 2: Material Theming

Episode 2 by Nick Rout covers Material Theming and goes through a tutorial on how to implement it on Android using MDC. Key topics include setting up a `Theme.MaterialComponents.*` app theme, choosing color, type, and shape attributes — using tools on material.io —and finally adding them to your theme to see how widgets automatically react and adapt their UI. Also covered are handy utility classes that MDC provides for certain scenarios, like resolving theme color attributes and applying shape to images.

Or in article form:

https://medium.com/androiddevelopers/material-theming-with-mdc-color-860dbba8ce2f

https://medium.com/androiddevelopers/material-theming-with-mdc-type-8c2013430247

https://medium.com/androiddevelopers/material-theming-with-mdc-shape-126c4e5cd7b4

Episode 3: Dark Theme

This episode by Chris Banes gets really dark… It takes you through implementing a dark theme for an Android app using MDC. Topics covered include using “force dark” for quick conversion (and how to exclude views from this), manually crafting a dark theme with design choices, `.DayNight` MDC app themes, and `.PrimarySurface` MDC widget styles, and how to handle the system UI.

Or in article form:

https://medium.com/androiddevelopers/dark-theme-with-mdc-4c6fc357d956

Episode 4: Material Motion

Episode 4 by Nick Rout is all about Material’s motion system. It closely follows the steps in the existing “Building Beautiful Transitions with Material Motion for Android” codelab. It uses the Reply sample app to demonstrate how you can use transition patterns —container transform, shared axis, fade through, and fade —for a smoother, more understandable user experience. It goes through scenarios involving Fragments (including the Navigation component), Activities, and Views, and will feel familiar if you’ve used the AndroidX and platform transition frameworks before.

Or in article form:

https://medium.com/androiddevelopers/material-motion-with-mdc-c1f09bb90bf9

Episode 5: Community tip

Episode 5 is by a member of the Android community—Google Developer Expert (GDE) for Android Zarah Dominguez—who takes us through using the MDC catalog app as a reference for widget functionality and API examples. She also explains how it’s been beneficial to build a ‘Theme Showcase’ page in the app she works on, to ensure a cohesive design language across different screens and flows.

Episode 6: Live Q&A

To wrap things up, Chet Haase hosted us for a Q&A session along with members of the MDC engineering team —Dan Nizri and Connie Shi. We answered questions asked by you on YouTube Live, Twitter, and elsewhere. We explored the origins of MDC, how it relates to AppCompat, and how it’s evolved over the years. Other topics include best practices for organizing your themes and resources, using different fonts and typography styles, and shape theming… A lot of shape theming. We also revealed all of our favorite Material components! Lastly we looked to the future with new components coming out in MDC and Jetpack Compose, Android’s next generation UI toolkit which has Material Design built in by default.

Sample apps

During the series we used two different sample applications to demonstrate MDC :

  • “Build a Material Theme” (a.k.a MaterialThemeBuilder) is an interactive project that lets you create your own Material theme by customizing values for color, typography, and shape
  • Reply is one of the Material studies; an email app that uses Material Design components and Material Theming to create an on-brand communication experience

These can both found alongside another Material study sample app — Owl — in the MDC examples GitHub repository.

https://github.com/material-components/material-components-android-examples

Improving urban GPS accuracy for your app

Posted by Frank van Diggelen, Principal Engineer and Jennifer Wang, Product Manager

At Android, we want to make it as easy as possible for developers to create the most helpful apps for their users. That’s why we aim to provide the best location experience with our APIs like the Fused Location Provider API (FLP). However, we’ve heard from many of you that the biggest location issue is inaccuracy in dense urban areas, such as wrong-side-of-the-street and even wrong-city-block errors.

This is particularly critical for the most used location apps, such as rideshare and navigation. For instance, when users request a rideshare vehicle in a city, apps cannot easily locate them because of the GPS errors.

The last great unsolved GPS problem

This wrong-side-of-the-street position error is caused by reflected GPS signals in cities, and we embarked on an ambitious project to help solve this great problem in GPS. Our solution uses 3D mapping aided corrections, and is only feasible to be done at scale by Google because it comprises 3D building models, raw GPS measurements, and machine learning.

The December Pixel Feature Drop adds 3D mapping aided GPS corrections to Pixel 5 and Pixel 4a (5G). With a system API that provides feedback to the Qualcomm® Snapdragon™ 5G Mobile Platform that powers Pixel, the accuracy in cities (or “urban canyons”) improves spectacularly.

Picture of a pedestrian test, with Pixel 5 phone, walking along one side of the street, then the other. Yellow = Path followed, Red = without 3D mapping aided corrections, Blue = with 3D mapping aided corrections. The picture shows that without 3D mapping aided corrections, the GPS results frequently wander to the wrong side of the street (or even the wrong city block), whereas, with 3D mapping aided corrections, the position is many times more accurate.

Picture of a pedestrian test, with Pixel 5 phone, walking along one side of the street, then the other. Yellow = Path followed, Red = without 3D mapping aided corrections, Blue = with 3D mapping aided corrections.

Why hasn’t this been solved before?

The problem is that GPS constructively locates you in the wrong place when you are in a city. This is because all GPS systems are based on line-of-sight operation from satellites. But in big cities, most or all signals reach you through non line-of-sight reflections, because the direct signals are blocked by the buildings.

Diagram of the 3D mapping aided corrections module in Google Play services, with corrections feeding into the FLP API. 3D mapping aided corrections are also fed into the GNSS chip and software, which in turn provides GNSS measurements, position, and velocity back to the module.

The GPS chip assumes that the signal is line-of-sight and therefore introduces error when it calculates the excess path length that the signals traveled. The most common side effect is that your position appears on the wrong side of the street, although your position can also appear on the wrong city block, especially in very large cities with many skyscrapers.

There have been attempts to address this problem for more than a decade. But no solution existed at scale, until 3D mapping aided corrections were launched on Android.

How 3D mapping aided corrections work

The 3D mapping aided corrections module, in Google Play services, includes tiles of 3D building models that Google has for more than 3850 cities around the world. Google Play services 3D mapping aided corrections currently supports pedestrian use-cases only. When you use your device’s GPS while walking, Android’s Activity Recognition API will recognize that you are a pedestrian, and if you are in one of the 3850+ cities, tiles with 3D models will be downloaded and cached on the phone for that city. Cache size is approximately 20MB, which is about the same size as 6 photographs.

Inside the module, the 3D mapping aided corrections algorithms solve the chicken-and-egg problem, which is: if the GPS position is not in the right place, then how do you know which buildings are blocking or reflecting the signals? Having solved this problem, 3D mapping aided corrections provide a set of corrected positions to the FLP. A system API then provides this information to the GPS chip to help the chip improve the accuracy of the next GPS fix.

With this December Pixel feature drop, we are releasing version 2 of 3D mapping aided corrections on Pixel 5 and Pixel 4a (5G). This reduces wrong-side-of-street occurrences by approximately 75%. Other Android phones, using Android 8 or later, have version 1 implemented in the FLP, which reduces wrong-side-of-street occurrences by approximately 50%. Version 2 will be available to the entire Android ecosystem (Android 8 or later) in early 2021.

Android’s 3D mapping aided corrections work with signals from the USA’s Global Positioning System (GPS) as well as other Global Navigation Satellite Systems (GNSSs): GLONASS, Galileo, BeiDou, and QZSS.

Our GPS chip partners shared the importance of this work for their technologies:

“Consumers rely on the accuracy of the positioning and navigation capabilities of their mobile phones. Location technology is at the heart of ensuring you find your favorite restaurant and you get your rideshare service in a timely manner. Qualcomm Technologies is leading the charge to improve consumer experiences with its newest Qualcomm® Location Suite technology featuring integration with Google's 3D mapping aided corrections. This collaboration with Google is an important milestone toward sidewalk-level location accuracy,” said Francesco Grilli, vice president of product management at Qualcomm Technologies, Inc.

“Broadcom has integrated Google's 3D mapping aided corrections into the navigation engine of the BCM47765 dual-frequency GNSS chip. The combination of dual frequency L1 and L5 signals plus 3D mapping aided corrections provides unprecedented accuracy in urban canyons. L5 plus Google’s corrections are a game-changer for GNSS use in cities,” said Charles Abraham, Senior Director of Engineering, Broadcom Inc.

“Google's 3D mapping aided corrections is a major advancement in personal location accuracy for smartphone users when walking in urban environments. MediaTek’s Dimensity 5G family enables 3D mapping aided corrections in addition to its highly accurate dual-band GNSS and industry-leading dead reckoning performance to give the most accurate global positioning ever for 5G smartphone users,” said Dr. Yenchi Lee, Deputy General Manager of MediaTek’s Wireless Communications Business Unit.

How to access 3D mapping aided corrections

Android’s 3D mapping aided corrections automatically works when the GPS is being used by a pedestrian in any of the 3850+ cities, on any phone that runs Android 8 or later. The best way for developers to take advantage of the improvement is to use FLP to get location information. The further 3D mapping aided corrections in the GPS chip are available to Pixel 5 and Pixel 4a (5G) today, and will be rolled out to the rest of the Android ecosystem (Android 8 or later) in the next several weeks. We will also soon support more modes including driving.

Android’s 3D mapping aided corrections cover more than 3850 cities, including:

  • North America: All major cities in USA, Canada, Mexico.
  • Europe: All major cities. (100%, except Russia & Ukraine)
  • Asia: All major cities in Japan and Taiwan.
  • Rest of the world: All major cities in Brazil, Argentina, Australia, New Zealand, and South Africa.

As our Google Earth 3D models expand, so will 3D mapping aided corrections coverage.

Google Maps is also getting updates that will provide more street level detail for pedestrians in select cities, such as sidewalks, crosswalks, and pedestrian islands. In 2021, you can get these updates for your app using the Google Maps Platform. Along with the improved location accuracy from 3D mapping aided corrections, we hope we can help developers like you better support use cases for the world’s 2B pedestrians that use Android.

Continuously making location better

In addition to 3D mapping aided corrections, we continue to work hard to make location as accurate and useful as possible. Below are the latest improvements to the Fused Location Provider API (FLP):

  • Developers wanted an easier way to retrieve the current location. With the new getCurrentLocation() API, developers can get the current location in a single request, rather than having to subscribe to ongoing location changes. By allowing developers to request location only when needed (and automatically timing out and closing open location requests), this new API also improves battery life. Check out our latest Kotlin sample.
  • Android 11's Data Access Auditing API provides more transparency into how your app and its dependencies access private data (like location) from users. With the new support for the API's attribution tags in the FusedLocationProviderClient, developers can more easily audit their apps’ location subscriptions in addition to regular location requests. Check out this Kotlin sample to learn more.



Qualcomm and Snapdragon are trademarks or registered trademarks of Qualcomm Incorporated.

Qualcomm Snapdragon and Qualcomm Location Suite are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

AGP 7.0: Next major release for the Android Gradle plugin

Posted by Murat Yener, Developer Advocate

Today marks the release of the first Canary version of Android Studio Arctic Fox (2020.3.1), together with Android Gradle plugin (AGP) version 7.0.0-alpha01. With this release we are adjusting the version numbering for our Gradle plugin and decoupling it from the Android Studio versioning scheme. In this blog post we'll explain the reasons for the change, as well as give a preview of some important changes we're making to our new, incubating Android Gradle plugin APIs and DSL.

New versioning scheme

With AGP 7.0.0 we are adopting the principles of semantic versioning. What this means is that only major version changes will break API compatibility. We intend to release one major version each year, right after Gradle introduces its own yearly major release.

Moreover, in the case of a breaking change, we will ensure that the removed API is marked with @Deprecated about a year in advance and that its replacement is available at the same time. This will give developers roughly a year to migrate and test their plugins with the new API before the old API is removed.

Alignment with Gradle's version is also why we're skipping versions 5 and 6, and moving directly to AGP 7.0.0. This alignment indicates that AGP 7.x is meant to work with Gradle 7.x APIs. While it may also run on Gradle 8.x, this is not guaranteed and will depend on whether 8.x removes APIs that AGP relies on.

With this change, the AGP version number will be decoupled from the Android Studio version number. However we will keep releasing Android Studio and Android Gradle plugin together for the foreseeable future.

Compatibility between Android Studio and Android Gradle plugin remains unchanged. As a general rule, projects that use stable versions of AGP can be opened with newer versions of Android Studio.

Java 11 requirement

You can still use Java programming language version 8 with AGP 7.0.0-alpha01 but we are changing the minimum required Java programming language version to Java 11, starting with AGP 7.0.0-alpha02. We are announcing this early in the Canary schedule and many months ahead of the stable release to allow developers time to get ready.

Incubating APIs and important API changes

This release of AGP also introduces some API changes. As a reminder, a number of APIs that were introduced in AGP 4.1 were marked as incubating and were subject to change. In fact, in AGP 4.2 some of these APIs have changed. The APIs that are currently incubating do not follow the deprecation cycle that we explain above.

Here is a summary of some important API changes.

  • The onVariants, onProperties and onVariantProperties blocks are removed in version 4.2 beta.
  • These APIs are replaced with beforeVariants and onVariants in the new androidComponents block. Both beforeVariants and onVariants can optionally use a VariantSelector to reduce the number of variants the callback will run on, based on build type, name or flavor by using withBuildType, withName and withFlavor accordingly. The lambda onVariants and beforeVariants receives is executed after AGP computes variant combinations in afterEvaluate. Nesting properties inside onVariants is removed.
  • Similar APIs are added to androidComponents to allow separate blocks for UnitTests (beforeUnitTest and unitTest) and AndroidTests (beforeAndroidTest and androidTest) instead of nesting tests inside variants.
  • Two classes used by both the old and new way of registering actions for variants were renamed. Variant is now VariantBuilder, and it is used in the beforeVariants phase. VariantProperties is now Variant and it is passed to the new onVariants block.

Let’s take a look at some of these changes. Here is a sample onVariants block which targets the release build. The onVariants block Is changed to beforeVariants and uses a variant selector in the following example. 

```
android {
   …
   //onVariants.withName("release") {
   //   ...
   //}
   …
}
androidComponents {
   val release = selector().withBuildType("release")
   beforeVariants(release) { variant ->
      ...
   }
}

```

Similarly onVariantProperties block is changed to onVariants. 

```
android {
   ...
   //onVariantProperties {
   //   ... 
   //}
   …
}

androidComponents.onVariants { variant ->
      ... 
}

```

Note, this customization is typically done in a plugin and should not be located in build.gradle. We are moving away from using functions with receivers which suited the DSL syntax but are not necessary in the plugin code.

We are planning to make these APIs stable with AGP 7.0.0 and all plugin authors must migrate to the new androidComponents. If you want to avoid dealing with such changes, make sure your plugins only use stable APIs and do not depend on APIs marked as incubating.

If you want to learn more about other changes coming with this release, make sure to take a look at the release notes.

Java is a registered trademark of Oracle and/or its affiliates.

Announcing Android Studio Arctic Fox (2020.3.1) & Android Gradle plugin 7.0

Posted by Jamal Eason, Product Manager

Android Studio logo

Today marks the release of the first version of Android Studio Arctic Fox (2020.3.1) on the canary channel, together with Android Gradle plugin (AGP) version 7.0.0-alpha01. With this release, we are adjusting the version numbering of Android Studio and our Gradle plugin. This change decouples the Gradle plugin from the Android Studio versioning scheme and brings more clarity to which year and IntelliJ version Android Studio aligns with for each release.

New versioning scheme - Android Studio

With Android Studio Arctic Fox (2020.3.1) we are moving to a year-based system that is more closely aligned with IntelliJ IDEA, the IDE upon which Android Studio is built. We are changing the version numbering scheme to encode a number of important attributes: the year, the version of IntelliJ it is based on, plus feature and patch level. WIth this name change you can quickly figure out which version of the IntelliJ platform you are using in Android Studio. In addition, each major version will have a canonical codename, starting with Arctic Fox, and then proceeding alphabetically to help make it easy to see which version is newer.

We recommend that you use the latest version of Android Studio so that you have access to the latest features and quality improvements. To make it easier to stay up to date, we made the version change to clearly de-couple Android Studio from your Android Gradle Plugin version. An important detail to keep in mind is that there is no impact to the way the build system compiles and packages your app when you update the IDE. In contrast, app build process changes and APK/Bundles are dictated by your project AGP version. Therefore, it is safe to update your Android Studio version, even late in your development cycle, because your project AGP version can be updated in a different cadence than your Android Studio version. Lastly, with the new version system it is even easier than before for you or your team to run both the stable and preview versions of Android Studio at the same time on your app project as long as you keep the AGP version on a stable release.

In the previous numbering system, this release would have been Android Studio 4.3. With the new numbering system, it is now Android Studio Arctic Fox (2020.3.1) Canary 1 or just, Arctic Fox.

Going forward, here is how the Android Studio version number scheme will work:

<Year of IntelliJ Version>.<IntelliJ major version>.<Studio major version>

  • The first two number groups represent the version of the final IntellIj platform that a particular Android Studio release is based on (earlier canaries may still be on the earlier version). For this release, this is 2020.3.
  • The third number group represents the Studio major version, starting at 1 and incrementing by one for every major release.
  • To make it easier to refer to each version, we are also giving major releases a code name, incrementing from A to Z based on animal names. This initial release name is Arctic Fox.

New versioning scheme - Android Gradle plugin

With AGP 7.0.0 we are adopting the principles of semantic versioning, and aligning with the Gradle version that AGP requires. Compatibility between Android Studio and Android Gradle plugin remains unchanged. Projects that use stable versions of AGP can be opened with newer versions of Android Studio.

We will publish another post soon with more details about our AGP versioning philosophy and what is new in AGP 7.0.

What is new in Android Studio Arctic Fox

We are in early days in the feature development phase for Arctic Fox, but we have invested much of our time in addressing over 200 quality improvements and bugs across a wide range of areas in the IDE from the code editor, app inspection tools, layout editor to the embedded emulator. Check out the release notes for the specific bug fixes.

For those trying out Jetpack Compose, we have a host of new updates, like deploy @Preview composables to device/emulator:

Deploy preview composable

Also try out the new Layout Validation Tool in Arctic Fox to see how your layout responds to various screens sizes, font sizes, and Android Color Correction/Color Blind Modes. You can access this via the Layout Validation tool window when you are using the Layout Editor.

Layout Validation

Lastly, for those running MacOS (other platforms are coming soon) with the latest Android Platform tools and an Android 11 device, you can try out the IDE integration for the Wireless ADB feature by going to the Run device selection dialogue → Pair Devices Using Wi-Fi.

Menu to access Wireless ADB feature

Wireless ADB Setup Window

What’s Next

If you want to learn more about other detailed changes coming with this release for both Android Studio and the Android Gradle plugin, make sure to take a look at the release notes.

Celebrating the Developers Behind the Best Apps and Games of 2020

Posted by Posted by Purnima Kochikar, Director, Business Development, Games & Applications

Today, we announced Google Play’s annual Best of 2020 awards, highlighting the year’s best apps, games and digital content. None of this would be possible without the developers that created the amazing content that made a profound impact on us in 2020, or should we say a Genshin Impact … From miHoYo Limited to Loona Inc, the makers behind your favorite apps and games were unafraid to experiment, challenge the status quo, and design incredible experiences we never thought possible.

Check out the full rundown of the developers behind the best apps and games of 2020 in the U.S. on Google Play:

Best App of 2020

Best Personal Growth Apps

Best Hidden Gem Apps

Best Everyday Essential Apps

Best Apps for Good

Best Apps for Fun

Best Game of 2020

Best Indie Games

Best Casual Games

Best Innovative Games

Best Competitive Games

MAD Skills — Become an Android App Bundle expert

Posted by Ben Weiss, Developer Relations Engineer

Android image

The Android App Bundle series of Modern Android Development has just concluded. We finished off with a live Q&A session. I was joined by Chet Haase, Wojtek Kaliciński, and Iurii Makhno to go over bundles of questions from the #AskAndroid hashtag on Twitter as well as from the chat during the live stream.

But let’s rewind for a moment and take it from the top.

Introduction to Android App Bundles

In the inaugural episode Wojtek sets the tone for this series by talking about why app bundles matter to you and your app.

Everything to know about Play App Signing

In this episode you learn how to opt into Play App Signing by joining Wojtek on a journey through the Play Console. After watching this video you will have learned what options are available to you when opting into Play App Signing.

Alongside this video we recommend taking a look at the FAQ about Play App Signing, the app signing Android docs and the Play Console’s Play App Signing help page.

Building your first app bundle

Now it’s time to learn how to build and upload your first Android App Bundle.

In this episode, I take you through the process of building a bundle using Android Studio and the command line interface.

Instead, you can read the write up of this episode.

Accompanying this episode, take a look at the app bundles documentation.

Configuring your app for Play Feature Delivery

Here you’ll learn about delivery options. From install time, to conditional delivery to on demand delivery. I cover it all. And we’ll take an excursion through the sample on GitHub.

This episode also is available as an article for you to read. Additionally, the PlayCore guide is a valuable resource.

Testing app bundles with bundletool and the Play Console

Have you wondered about how you can test your app bundle? No more wondering. Wojtek takes you through testing your app bundle locally and with the Play Console.

You can read up on this episode’s content in the accompanying article and the guide to testing your Android App Bundle.

Additionally we have guidance on developer tools on the Play Console and the Play Console help page for internal app sharing available for you.

And, if you want to download bundletool, here is where to find it.

Big savings with Android App Bundles

Android GDE Angélica Oliveira tells us about the process and the impressive size savings her company saw when switching over to Android App Bundles.

Live Q&A session

We asked for your questions on Twitter. You replied, using the #AskAndroid hashtag.

And you continued asking questions during the live Q&A session.

Chet then got Wojtek, Iurii and myself in front of the camera for a live Q&A to answer your questions.

Reminder: App bundles will be mandatory for new apps from August 2021

Read more about the 2021 API level bump and app bundle requirement

The future of Kotlin Android Extensions

Posted by David Winer, Product Manager

The Android Kotlin Extensions Gradle plugin (not to be confused with Android KTX) was released in 2017 and brought two new conveniences to Android development in Kotlin:

  • Synthetics let you replace calls to findViewById with kotlinx.android.synthetic bindings.
  • Parcelize allows you to remove boilerplate and easily create Parcelables through the @Parcelize annotation.

Since then, we have released View Binding for Android, an officially supported library that has deep integration with the Android build toolchain and provides similar functionality as Kotlin synthetics. While we continue to recommend Parcelize, a number of drawbacks have appeared with using Kotlin synthetics:

  • They pollute the global namespace
  • They don’t expose nullability information
  • They only work in Kotlin code

JetBrains originally developed the Android Kotlin Extensions plugin, and together we have discussed the pros and cons of continuing to maintain synthetics: we strive to ensure long term support for APIs where we can but want to guide developers towards best practices that make for healthy codebases and, ultimately, happy users.

Over the course of the next year, our teams will be jointly deprecating synthetics in favor of continuing to support our recommended option, View Binding. Here’s what that means:

  • If you are using Parcelize, you can continue to use the same annotations and APIs. The annotation package will change to kotlinx.parcelize, however, and In your module-level Gradle file, you should start using the standalone kotlin-parcelize plugin instead of android-kotlin-extensions. You’ll be able to find documentation for Parcelize on the Android developer documentation site.
  • If you are using Android Kotlin synthetics, you should migrate to View Binding. Check out our migration guide for more details.

The deprecation period starts with Kotlin 1.4.20, released today. android-kotlin-extensions will be removed in a future Kotlin release during or after September 2021. Long term, we will continue to maintain the kotlin-parcelize plugin, and you can continue to file issues on Parcelize in the Android Studio issue tracker.