Posted by Ben Weiss, Developer Relations Engineer
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.
In the inaugural episode Wojtek sets the tone for this series by talking about why app bundles matter to you and your app.
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.
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.
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.
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.
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.
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.
Read more about the 2021 API level bump and app bundle requirement
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:
findViewById
kotlinx.android.synthetic
@Parcelize
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:
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:
kotlinx.parcelize
kotlin-parcelize
android-kotlin-extensions
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.
Posted by Hoi Lam, Developer Relations Engineer, Android Platform
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.
From August 2021, the Google Play Console will require all new apps to:
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.
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
REQUIRED NOV 2021
Updates to existing apps on Google Play
No new publishing format requirement
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.
minSdkVersion
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.
Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play
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
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?
★ ★ ★ ★ ★
Posted by Oli Gaymond, Product Manager Android Machine Learning
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.
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.
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.
Posted by David Zeuthen, Shawn Willden and René Mayrhofer, Android Security and Privacy team
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.
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:
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.
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.
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.
Posted by Chet Haase
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.
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 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.
NavHostFragment
Or in article form: https://medium.com/androiddevelopers/navigation-component-dialog-destinations-bfeb8b022759
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
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
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)
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.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
