Category Archives: Android Developers Blog

An Open Handset Alliance Project

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.

New Android App Bundle and target API level requirements in 2021

Posted by Hoi Lam, Developer Relations Engineer, Android Platform

Android app bundle image

In 2021, we are continuing with our annual target API level update, requiring new apps to target API level 30 (Android 11) in August and in November for all app updates. In addition, as announced earlier this year, Google Play will require new apps to use the Android App Bundle publishing format. This brings the benefits of smaller apps and simpler releases to more users and developers and supports ongoing investment in advanced distribution.

Over 750,000 apps and games already publish to production on Google Play using app bundles. Top apps switching save an average size of 15% versus a universal APK. Users benefit from smaller downloads and developers like Netflix and Riafy see higher install success rates, which is especially impactful in regions with more entry level devices and slower data speeds. Developers switching can use advanced distribution features such as Play Asset Delivery and Play Feature Delivery. We value your feedback and plan to introduce further features and options for Play App Signing and Android App Bundles before the switchover.


Requirements for new apps

From August 2021, the Google Play Console will require all new apps to:


Requirements for updates to existing apps

From November 2021, updates to existing apps will be required to target API level 30 or above and adjust for behavioral changes in Android 11. Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store.

Requirements for instant experiences

The switch to Android App Bundle delivery will also impact instant experiences using the legacy Instant app ZIP format. From August 2021, new instant experiences and updates to existing instant experiences will be required to publish instant-enabled app bundles.


Moving forward together

Here is a summary of all the changes:


TYPE OF RELEASE

REPLACED

REQUIRED AUG 2021

New apps 
on Google Play

APK

Android App Bundle (AAB)

Target API level set to 29+

Target API level set to 30+

Expansion files (OBBs)

Play Asset Delivery or 
Play Feature Delivery

TYPE OF RELEASE

REPLACED

REQUIRED NOV 2021

Updates to existing apps 
on Google Play

No new publishing format requirement

Target API level set to 29+

Target API level set to 30+



Wear OS apps are not subject to the new target API level requirement.

Apps can still use any minSdkVersion, so there is no change to your ability to build apps for older Android versions.

To learn more about transitioning to app bundles, watch our new video series: modern Android development (MAD) skills. We are extremely grateful for all the developers who have adopted app bundles and API level 30 already. We look forward to advancing the Android platform together with you.

Tips for getting your app approved for background location access

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

Graphic of phone with googleplay logo and icons to the left

When it comes to privacy, we are committed to giving users control and transparency over data access. Users consistently tell us that they want more control over their location data, so earlier this year we announced a few privacy improvements, such as updates to Google Play’s Location Permissions policy and enhancements to location permission controls in Android 11.

To help prevent unnecessary access to background location, the updated policy allows access only if it’s critical to the app’s core functionality and provides clear user benefit. We found that many apps that requested background location don’t actually need it. Removing or changing it to foreground can help apps be battery-efficient and avoid poor app ratings when users don’t want to share their location.

If your app uses background location data, you must submit a form for review and receive approval by January 18, 2021 so your apps can stay on Google Play. Existing apps first published before April 16, 2020 have until March 29, 2021 to comply.

Tips to get approved

  • If your app has multiple features that use background location, choose the one that provides the most user benefit. Describe in detail why background (and not foreground) location is needed and how it is used. Learn more
  • You must include a short video that shows how users will encounter your prominent disclosure, location-based feature and enable it in-app. If your video doesn’t show this or we can’t access the link, your request won’t be approved. We recommend that you upload it to YouTube or Google Drive.
  • Remember to include a prominent in-app disclosure to explain to users what data is used and how. Learn more
  • Ensure your privacy policy is clearly labeled and includes details on location data usage. Learn more

Resources to help

We want to help you through this process, so we’ve created this video and free training courses in Google Play Academy to use as a reference when you’re making any necessary app updates. You can also check out these best privacy practices and technical details to help identify possible background location usage in your code.

Thank you for continuing to partner with us to make Google Play a trustworthy platform for you and your users.

How useful did you find this blog post?

Android Neural Networks API 1.3 and PyTorch Mobile support

Posted by Oli Gaymond, Product Manager Android Machine Learning

Android graphic

On-Device Machine Learning enables cutting edge features to run locally without transmitting data to a server. Processing the data on-device enables lower latency, can improve privacy and allows features to work without connectivity. Achieving the best performance and power efficiency requires taking advantage of all available hardware.

Android Neural Networks API 1.3

The Android Neural Networks API (NNAPI) is designed for running computationally intensive operations for machine learning on Android devices. It provides a single set of APIs to benefit from available hardware accelerators including GPUs, DSPs and NPUs.

In Android 11, we released Neural Networks API 1.3 adding support for Quality of Service APIs, Memory Domains and expanded quantization support. This release builds on the comprehensive support for over 100 operations, floating point and quantized data types and hardware implementations from partners across the Android ecosystem.

Hardware acceleration is particularly beneficial for always-on, real-time models such as on-device computer vision or audio enhancement. These models tend to be compute-intensive, latency-sensitive and power-hungry. One such use case is in segmenting the user from the background in video calls. Facebook is now testing NNAPI within the Messenger application to enable the immersive 360 backgrounds feature. Utilising NNAPI, Facebook saw a 2x speedup and 2x reduction in power requirements. This is in addition to offloading work from the CPU, allowing it to perform other critical tasks.

Introducing PyTorch Neural Networks API support

NNAPI can be accessed directly via an Android C API or via higher level frameworks such as TensorFlow Lite. Today, PyTorch Mobile announced a new prototype feature supporting NNAPI that enables developers to use hardware accelerated inference with the PyTorch framework.

Today’s initial release includes support for well-known linear convolutional and multilayer perceptron models on Android 10 and above. Performance testing using the MobileNetV2 model shows up to a 10x speedup compared to single-threaded CPU. As part of the development towards a full stable release, future updates will include support for additional operators and model architectures including Mask R-CNN, a popular object detection and instance segmentation model.

We would like to thank the PyTorch Mobile team at Facebook for their partnership and commitment to bringing accelerated neural networks to millions of Android users.

Privacy-preserving features in the Mobile Driving License

Posted by David Zeuthen, Shawn Willden and René Mayrhofer, Android Security and Privacy team

Android Mobible Driver's license app

In the United States and other countries a Driver's License is not only used to convey driving privileges, it is also commonly used to prove identity or personal details.

Presenting a Driving License is simple, right? You hand over the card to the individual wishing to confirm your identity (the so-called “Relying Party” or “Verifier”); they check the security features of the plastic card (hologram, micro-printing, etc.) to ensure it’s not counterfeit; they check that it’s really your license, making sure you look like the portrait image printed on the card; and they read the data they’re interested in, typically your age, legal name, address etc. Finally, the verifier needs to hand back the plastic card.

Most people are so familiar with this process that they don’t think twice about it, or consider the privacy implications. In the following we’ll discuss how the new and soon-to-be-released ISO 18013-5 standard will improve on nearly every aspect of the process, and what it has to do with Android.

Mobile Driving License ISO Standard

The ISO 18013-5 “Mobile driving licence (mDL) application” standard has been written by a diverse group of people representing driving license issuers (e.g. state governments in the US), relying parties (federal and state governments, including law enforcement), academia, industry (including Google), and many others. This ISO standard allows for construction of Mobile Driving License (mDL) applications which users can carry in their phone and can use instead of the plastic card.

Instead of handing over your plastic card, you open the mDL application on your phone and press a button to share your mDL. The Verifier (aka “Relying Party”) has their own device with an mDL reader application and they either scan a QR code shown in your mDL app or do an NFC tap. The QR code (or NFC tap) conveys an ephemeral cryptographic public key and hardware address the mDL reader can connect to.

Once the mDL reader obtains the cryptographic key it creates its own ephemeral keypair and establishes an encrypted and authenticated, secure wireless channel (BLE, Wifi Aware or NFC)). The mDL reader uses this secure channel to request data, such as the portrait image or what kinds of vehicles you're allowed to drive, and can also be used to ask more abstract questions such as “is the holder older than 18?”

Crucially, the mDL application can ask the user to approve which data to release and may require the user to authenticate with fingerprint or face — none of which a passive plastic card could ever do.

With this explanation in mind, let’s see how presenting an mDL application compares with presenting a plastic-card driving license:

  • Your phone need not be handed to the verifier, unlike your plastic card. The first step, which requires closer contact to the Verifier to scan the QR code or tap the NFC reader, is safe from a data privacy point of view, and does not reveal any identifying information to the verifier. For additional protection, mDL apps will have the option of both requiring user authentication before releasing data and then immediately placing the phone in lockdown mode, to ensure that if the verifier takes the device they cannot easily get information from it.
  • All data is cryptographically signed by the Issuing Authority (for example the DMV who issued the mDL) and the verifier's app automatically validates the authenticity of the data transmitted by the mDL and refuses to display inauthentic data. This is far more secure than holograms and microprinting used in plastic cards where verification requires special training which most (human) verifiers don't receive. With most plastic cards, fake IDs are relatively easy to create, especially in an international context, putting everyone’s identity at risk.
  • The amount of data presented by the mDL is minimized — only data the user elects to release, either explicitly via prompts or implicitly via e.g. pre-approval and user settings, is released. This minimizes potential data abuse and increases the personal safety of users.

    For example, any bartender who checks your mDL for the sole purpose of verifying you’re old enough to buy a drink needs only a single piece of information which is whether the holder is e.g. older than 21, yes or no. Compared to the plastic card, this is a huge improvement; a plastic card shows all your data even if the verifier doesn’t need it.

    Additionally, all of this information is available via a 2D barcode on the back so if you use your plastic card driving license to buy beer, tobacco, or other restricted items at a store it’s common in some states for the cashier to scan your license. In some cases, this means you may get advertising in the mail but they may sell your identifying information to the highest bidder or, worst case, leak their whole database.

These are some of the reasons why we think mDL is a big win for end users in terms of privacy.

One commonality between plastic-card driving licences and the mDL is how the relying party verifies that the person presenting the license is the authorized holder. In both cases, the verifier manually compares the appearance of the individual against a portrait photo, either printed on the plastic or transmitted electronically and research has shown that it’s hard for individuals to match strangers to portrait images.

The initial version of ISO 18013-5 won’t improve on this but the ISO committee working on the standard is already investigating ways to utilize on-device biometrics sensors to perform this match in a secure and privacy-protecting way. The hope is that improved fidelity in the process helps reduce unauthorized use of identity documents.

mDL support in Android

Through facilities such as hardware-based Keystore, Android already offers excellent support for security and privacy-sensitive applications and in fact it’s already possible to implement the ISO 18013-5 standard on Android without further platform changes. Many organizations participating in the ISO committee have already implemented 18013-5 Android apps.

That said, with purpose-built support in the operating system it is possible to provide better security and privacy properties. Android 11 includes the Identity Credential APIs at the Framework level along with a Hardware Abstraction Layer interface which can be implemented by Android OEMs to enable identity credential support in Secure Hardware. Using the Identity Credential API, the Trusted Computing Base of mDL applications does not include the application or even Android itself. This will be particularly important for future versions where the verifier must trust the device to identify and authenticate the user, for example through fingerprint or face matching on the holder's own device. It’s likely such a solution will require certified hardware and/or software and certification is not practical if the TCB includes the hundreds of millions of lines of code in Android and the Linux kernel.

One advantage of plastic cards is that they don't require power or network communication to be useful. Putting all your licenses on your phone could seem inconvenient in cases where your device is low on battery, or does not have enough battery life to start. The Android Identity Credential HAL therefore provides support for a mode called Direct Access, where the license is still available through an NFC tap even when the phone's battery is too low to boot it up. Device makers can implement this mode, but it will require hardware support that will take several years to roll out.

For devices without the Identity Credential HAL, we have an Android Jetpack which implements the same API and works on nearly every Android device in the world (API level 24 or later). If the device has hardware-backed Identity Credential support then this Jetpack simply forwards calls to the platform API. Otherwise, an Android Keystore-backed implementation will be used. While the Android Keystore-backed implementation does not provide the same level of security and privacy, it is perfectly adequate for both holders and issuers in cases where all data is issuer-signed. Because of this, the Jetpack is the preferred way to use the Identity Credential APIs. We also made available sample open-source mDL and mDL Reader applications using the Identity Credential APIs.

Conclusion

Android now includes APIs for managing and presenting with identity documents in a more secure and privacy-focused way than was previously possible. These can be used to implement ISO 18013-5 mDLs but the APIs are generic enough to be usable for other kinds of electronic documents, from school ID or bonus program club cards to passports.

Additionally, the Android Security and Privacy team actively participates in the ISO committees where these standards are written and also works with civil liberties groups to ensure it has a positive impact on our end users.

MAD Skills Navigation Wrap-Up

Posted by Chet Haase

MAD Skills navigation illustration of mobile and desktop with Android logo

It’s a Wrap!

We’ve just finished the first series in the MAD Skills series of videos and articles on Modern Android Development. This time, the topic was Navigation component, the API and tool that helps you create and edit navigation paths through your application.

The great thing about videos and articles is that, unlike performance art, they tend to stick around for later enjoyment. So if you haven’t had a chance to see these yet, check out the links below to see what we covered. Except for the Q&A episode at the end, each episode has essentially identical content in the video and article version, so use whichever format you prefer for content consumption.

Episode 1: Overview

The first episode provides a quick, high-level overview of Navigation Component, including how to create a new application with navigation capability (using Android Studio’s handy application templates), details on the containment hierarchy of a navigation-enabled UI, and an explanation of some of the major APIs and pieces involved in making Navigation Component work.

Or in article form: https://medium.com/androiddevelopers/navigation-component-an-overview-4697a208c2b5

Episode 2: Dialog Destinations

Episode 2 explores how to use the API to navigate to dialog destinations. Most navigation takes place between different fragment destinations, which are swapped out inside of the NavHostFragment object in the UI. But it is also possible to navigate to external destinations, including dialogs, which exist outside of the NavHostFragment.

Or in article form: https://medium.com/androiddevelopers/navigation-component-dialog-destinations-bfeb8b022759

Episode 3: SafeArgs

This episode covers SafeArgs, the facility provided by Navigation component for easily passing data between destinations.

Or in article form: https://medium.com/androiddevelopers/navigating-with-safeargs-bf26c17b1269

Episode 4: Deep Links

This episode is on Deep Links, the facility provided by Navigation component for helping the user get to deeper parts of your application from UI outside the application.

Or in article form: https://medium.com/androiddevelopers/navigating-with-deep-links-910a4a6588c

Episode 5: Live Q&A

Finally, to wrap up the series (as we plan to do for future series), I hosted a Q&A session with Ian Lake. Ian fielded questions from you on Twitter and YouTube, and we discussed everything from feature requests like multiple backstacks (spoiler: it’s in the works!) to Navigation support for Jetpack Compose (spoiler: the first version of this was just released!) to other questions people had about navigation, fragments, Up-vs-Back, saving state, and other topics. It was pretty fun — more like a podcast with cameras than a Q&A.

(There is no article for this one; enjoy the video above)

Sample App: DonutTracker

The application used for most of the episodes above is DonutTracker, an app that you can use for tracking important data about donuts you enjoy (or don’t). Or you can just use it for checking out the implementation details of these Navigation features; your choice.