Posted by Iliyan Malchev (Project Treble Architect), Amith Dsouza (Technical Account Manager) , and Veerendra Bhora (Strategic Partnerships Manager)
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.
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.
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:
Considering that SoC providers have dozens of SoC models at any point of time, the full picture looks closer to this:
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:
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.
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.
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!
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…).
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:
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!
Posted by Nick Rout
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!
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 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.
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
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.
https://medium.com/androiddevelopers/dark-theme-with-mdc-4c6fc357d956
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.
https://medium.com/androiddevelopers/material-motion-with-mdc-c1f09bb90bf9
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.
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.
During the series we used two different sample applications to demonstrate MDC :
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
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.
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.
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:
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):
getCurrentLocation
FusedLocationProviderClient
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.
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.
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.
@Deprecated
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.
With AGP 7.0.0-alpha01 we are changing the minimum required Java programming language version to Java 11. We are announcing this early in the Canary schedule and many months ahead of the stable release to allow developers time to get ready.
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.
onVariants
onProperties
onVariantProperties
beforeVariants
androidComponents
VariantSelector
withBuildType
withName
withFlavor
afterEvaluate
beforeUnitTest
unitTest
beforeAndroidTest
androidTest
Variant
VariantBuilder
VariantProperties
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.
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.
Posted by Jamal Eason, Product Manager
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.
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>
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.
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:
@Preview
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
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.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
