Posted by Miguel Montemayor and Diana García Ríos
As of Android Gradle plugin 3.4.0 (included in Android Studio 3.4), we are starting the deprecation process of the feature plugin (com.android.feature) and instant app plugin (com.android.instantapp) as a way to build your instant app. When building your app, you will receive a warning flagging com.android.feature as deprecated. If you have an existing instant app built with the feature plugin, migrate your existing app to an instant-enabled app bundle as soon as possible.
com.android.feature
com.android.instantapp
Last year, we introduced Android App Bundles—a new way to build and publish your Android apps. App bundles simplify delivering optimized APKs, including instant delivery, by unifying uploads into a single artifact. Google Play handles distribution by serving the correct APKs to your instant and installed app users—this is called Dynamic Delivery. To learn more about app bundles, visit the documentation site.
Dynamic Delivery is based on the idea of shipping dynamic features (com.android.dynamic-feature) to app users when they need them and only if they need them. There are currently three delivery types, based on the different values you will give the dist:module tag attributes on the dynamic feature module’s manifest file:
com.android.dynamic-feature
dist:module
<dist:module dist:instant="..." dist:onDemand="..." ... </dist:module>
dist:instant="false"
dist:instant="true"
dist:onDemand="false"
dist:onDemand="true"
By migrating your instant app to an instant-enabled app bundle with dynamic features, you will be ready to leverage the full power of this new paradigm and you will be able to simplify your app’s modular design.
Previously, instant apps required creating a feature module that acted as the base module for your app. This base feature module contained the shared code and resources for both your instant and installed application. The rest of your codebase was comprised of:
With the new app bundle implementation, your base feature module takes the role as your app module (com.android.application), hosting the code and resources common to all features (instant and installed). You organize additional, modular features as one of three types of dynamic feature modules, based on when you want to deliver them to the user. The instant app module disappears, since the dist:instant attributes in the manifest are enough to identify which features will be included as part of the instant experience.
com.android.application
dist:instant
If you don’t have an instant experience added to your app and you’d like to create one, use Android Studio 3.3+ to create an instant-enabled app bundle.
Posted by Christiaan Prins and Max Gubin
Today we are announcing the release of two new features to ML Kit: Language Identification and Smart Reply.
You might notice that both of these features are different from our existing APIs that were all focused on image/video processing. Our goal with ML Kit is to offer powerful but simple-to-use APIs to leverage the power of ML, independent of the domain. As such, we are excited to expand ML Kit with solutions for Natural Language Processing (NLP)!
NLP is a category of ML that deals with analyzing and generating text, speech, and other kinds of natural language data. We're excited to start out with two APIs: one that helps you identify the language of text, and one that generates reply suggestions in chat applications. Both of these features work fully on-device and are available on the latest version of the ML Kit SDK, on iOS (9.0 and higher) and Android (4.1 and higher).
Generate reply suggestions based on previous messages
A new feature popping up in messaging apps is to provide the user with a selection of suggested responses, either as actions on a notification or inside the app itself. This can really help a user to quickly respond when they are busy or a handy way to initiate a longer message.
With the new Smart Reply API you can now quickly achieve the same in your own apps. The API provides suggestions based on the last 10 messages in a conversation, although it still works if only one previous message is available. It is a stateless API that fully runs on-device, so we don't keep message history in memory nor send it to a server.
textPlus app providing response suggestions using Smart Reply
We have worked closely with partners like textPlus to ensure Smart Reply is ready for prime time and they have now implemented in-app response suggestions with the latest version of their app (screenshot above).
Adding Smart Reply to your own app is done with a simple function call (using Kotlin in this example):
val smartReply = FirebaseNaturalLanguage.getInstance().smartReply smartReply.suggestReplies(conversation) .addOnSuccessListener { result -> if (result.status == SmartReplySuggestionResult.STATUS_NOT_SUPPORTED_LANGUAGE) { // The conversation's language isn't supported, so the // the result doesn't contain any suggestions. } else if (result.status == SmartReplySuggestionResult.STATUS_SUCCESS) { // Task completed successfully // ... } } .addOnFailureListener { // Task failed with an exception // ... }
After you initialize a Smart Reply instance, call suggestReplies with a list of recent messages. The callback provides the result which contains a list of suggestions.
suggestReplies
result
For details on how to use the Smart Reply API, check out the documentation.
Tell me more ...
Although as a developer, you can just pick up this new API and easily get it integrated in your app, it may be interesting to reveal a bit on how it works under the hood. At the core of Smart Reply is a machine-learned model that is executed using TensorFlow Lite and has a state-of-the-art modern architecture based on SentencePiece text encoding[1] and Transformer[2].
However, as we realized when we started development of the API, the core suggestion model is not all that’s needed to provide a solution that developers can use in their apps. For example, we added a model to detect sensitive topics, so that we avoid making suggestions in response to profanity or in cases of personal tragedy/hardship. Also, we included language identification, to ensure we do not provide suggestions for languages the core model is not trained on. The Smart Reply feature is launching with English support first.
Identify the language of a piece of text
The language of a given text string is a subtle but helpful piece of information. A lot of apps have functionality with a dependency on the language: you can think of features like spell checking, text translation or Smart Reply. Rather than asking a user to specify the language they use, you can use our new Language Identification API.
ML Kit recognizes text in 110 different languages and typically only requires a few words to make an accurate determination. It is fast as well, typically providing a response within 1 to 2 ms across iOS and Android phones.
Similar to the Smart Reply API, you can identify the language with a function call (using Kotlin in this example):
val languageIdentification = FirebaseNaturalLanguage.getInstance().languageIdentification languageIdentification .identifyLanguage("¿Cómo estás?") .addOnSuccessListener { identifiedLanguage -> Log.i(TAG, "Identified language: $identifiedLanguage") } .addOnFailureListener { e -> Log.e(TAG, "Language identification error", e) }
The identifyLanguage functions takes a piece of a text and its callback provides a BCP-47 language code. If no language can be confidently recognized, ML Kit returns a code of und for undetermined. The Language Identification API can also provide a list of possible languages and their confidence values.
identifyLanguage
und
For details on how to use the Language Identification API, check out the documentation.
Get started today
We're really excited to expand ML Kit to include Natural Language APIs. Give the two new NLP APIs a spin today and let us know what you think! You can always reach us in our Firebase Talk Google Group.
As ML Kit grows we look forward to adding more APIs and categories that enables you to provide smarter experiences for your users. With that, please keep an eye out for some exciting ML Kit announcements at Google I/O.
A few weeks ago we Introduced Android Q Beta, a first look at the next version of Android. Along with new privacy features for users, Android Q adds new capabilities for developers - like enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 graphics, and more.
Android's program of early, open previews is driven by our core philosophy of openness, and collaboration with our community. Your feedback since Beta 1 proves yet again the value of that openness - it's been loud, clear, and incredibly valuable. You've sent us thousands of bug reports, giving us insights and directional feedback, changing our plans in ways that make the platform better for users and developers. We're taking your feedback to heart, so please stay tuned. We're fortunate to have such a passionate community helping to guide Android Q toward the final product later this year.
Today we're releasing Android Q Beta 2 and an updated SDK for developers. It includes the latest bug fixes, optimizations, and API updates for Android Q, along with the April 2019 security patches. You'll also notice isolated storage becoming more prominent as we look for your wider testing and feedback to help us refine that feature.
We're still in early Beta with Android Q so expect rough edges! Before you install, check out the Known Issues. In particular, expect the usual transitional issues with apps that we typically see during early Betas as developers get their app updates ready. For example, you might see issues with apps that access photos, videos, media, or other files stored on your device, such as when browsing or sharing in social media apps.
You can get Beta 2 today by enrolling any Pixel device here. If you're already enrolled, watch for the Beta 2 update coming soon. Stay tuned for more at Google I/O in May.
As we shared at Beta 1, we're making significant privacy investments in Android Q in addition to the work we've done in previous releases. Our goals are improving transparency, giving users more control, and further securing personal data across platform and apps. We know that to reach those goals, we need to partner with you, our app developers. We realize that supporting these features is an investment for you too, so we'll do everything we can to minimize the impact on your apps.
For features like Scoped Storage, we're sharing our plans as early as possible to give you more time to test and give us your input. To generate broader feedback, we've also enabled Scoped Storage for new app installs in Beta 2, so you can more easily see what is affected.
With Scoped Storage, apps can use their private sandbox without permission, but they need new permissions to access shared collections for photos, videos and audio. Apps using files in shared collections -- for example, photo and video galleries and pickers, media browsing, and document storage -- may behave differently under Scoped Storage.
We recommend getting started with Scoped Storage soon -- the developer guide has details on how to handle key use-cases. For testing, make sure to enable Scoped Storage for your app using the adb command. If you discover that your app has a use-case that's not supported by Scoped Storage, please let us know by taking this short survey. We appreciate the great feedback you've given us already, it's a big help as we move forward with the development of this feature.
In Android Q we're adding platform support for bubbles, a new way for users to multitask and re-engage with your apps. Various apps have already built similar interactions from the ground up, and we're excited to bring the best from those into the platform, while helping to make interactions consistent, safeguard user privacy, reduce development time, and drive innovation.
Bubbles will let users multitask as they move between activities.
Bubbles help users prioritize information and take action deep within another app, while maintaining their current context. They also let users carry an app's functionality around with them as they move between activities on their device.
Bubbles are great for messaging because they let users keep important conversations within easy reach. They also provide a convenient view over ongoing tasks and updates, like phone calls or arrival times. They can provide quick access to portable UI like notes or translations, and can be visual reminders of tasks too.
We've built bubbles on top of Android's notification system to provide a familiar and easy to use API for developers. To send a bubble through a notification you need to add a BubbleMetadata by calling setBubbleMetadata. Within the metadata you can provide the Activity to display as content within the bubble, along with an icon (disabled in beta 2) and associated person.
We're just getting started with bubbles, but please give them a try and let us know what you think. You can find a sample implementation here.
As the ecosystem moves quickly toward foldable devices, new use-cases are opening up for your apps to take advantage of these new screens. With Beta 2, you can build for foldable devices through Android Q enhanced platform support, combined with a new foldable device emulator, available as an Android Virtual device in Android Studio 3.5 available in the canary release channel.
7.3" Foldable AVD switches between the folded and unfolded states
On the platform side, we've made a number of improvements in onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. You can read more in the foldables developer guide.
To set up a runtime environment for your app, you can now configure a foldable emulator as a virtual device (AVD) in Android Studio. The foldable AVD is a reference device that lets you test with standard hardware configurations, behaviors, and states, as will be used by our device manufacturer partners. To ensure compatibility, the AVD meets CTS/GTS requirements and models CDD compliance. It supports runtime configuration change, multi-resume and the new resizeableActivity behaviors.
Use the canary release of Android Studio 3.5 to create a foldable virtual device to support either of two hardware configurations 7.3" (4.6" folded) and 8" (6.6" folded) with Beta 2. In each configuration, the emulator gives you on-screen controls to trigger fold/unfold, change orientation, and quick actions.
Android Studio - AVD Manager: Foldable Device Setup
Try your app on the foldable emulator today by downloading the canary release of Android Studio 3.5 and setting up a foldable AVD that uses the Android Q Beta 2 system image.
Following on the initial Sharing Shortcuts APIs in Beta 1, you can now offer a preview of the content being shared by providing an EXTRA_TITLE extra in the Intent for the title, or by setting the Intent's ClipData for a thumbnail image. See the updated sample application for the implementation details.
Android Q Beta 2 gives apps more control over audio capture through a new MicrophoneDirection API. You can use the API to specify a preferred direction of the microphone when taking an audio recording. For example, when the user is taking a "selfie" video, you can request the front-facing microphone for audio recording (if it exists) by calling setMicrophoneDirection(MIC_DIRECTION_FRONT).
Additionally, this API introduces a standardized way of controlling zoomable microphones, allowing your app to have control over the recording field dimension using setMicrophoneFieldDimension(float).
In Android Q we're continuing our long-term effort to move apps toward only using public APIs. We introduced most of the new restrictions in Beta 1, and we're making a few minor updates to those lists in Beta 2 to minimize impact on apps. Our goal is to provide public alternative APIs for valid use-cases before restricting access, so if an interface that you currently use in Android 9 Pie is now restricted, you should request a new public API for that interface.
Today's update includes Beta 2 system images for all Pixel devices and the Android Emulator, as well updated SDK and tools for developers. These give you everything you need to get started testing your apps on the new platform and build with the latest APIs.
First, make your app compatible and give your users a seamless transition to Android Q, including your users currently participating in the Android Beta program. To get started, just install your current app from Google Play onto a device or emulator running Beta 2 and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. See the migration guide for steps and a recommended timeline.
With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you'll want to test against scoped storage, new location permissions, restrictions on background Activity starts, and restrictions on device identifiers. See the privacy checklist as a starting point.
Next, update your app's targetSdkVersion to 'Q' as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.
When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Here's a video highlighting many of the changes for developers in Beta 1 and Beta 2. Take a look at the API diff report for an overview of what's changed in Beta 2, and see the Android Q Beta API reference for details. Visit the Android Q Beta developer site for more resources, including release notes and how to report issues.
To build with Android Q, download the Android Q Beta SDK and tools into Android Studio 3.3 or higher, and follow these instructions to configure your environment. If you want the latest fixes for Android Q related changes, we recommend you use Android Studio 3.5 or higher.
It's easy - you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we're supporting all three generations of Pixel -- Pixel 3, Pixel 2, and even the original Pixel!). If you're already enrolled, you'll receive the update to Beta 2 soon, no action is needed on your part. Downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.
As always, your input is critical, so please let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.
Posted by Calin Juravle, Software Engineer
In Android Pie we launched ART optimizing profiles in Play Cloud, a new optimization feature that greatly improves the application startup time after a new install or update. On average, we have observed that apps start 15% faster (cold startup) across a variety of devices. Some hero cases even show 30%+ faster startup times. One of the most important aspects is that users get this for free, without any effort from their side or from developers!
Source: Google internal data
The feature builds on previous Profile Guided Optimization (PGO) work, which was introduced in Android 7.0 Nougat. PGO allows the Android Runtime to help improve an app's performance by building a profile of the app's most important hot code and focusing its optimization effort on it. This leads to big improvements while reducing the traditional memory and storage impact of a fully compiled app. However, it relies on the device to optimize apps based on these code profiles in idle maintenance mode, which means it could be a few days before a user sees the benefits - something we aimed to improve.
ART optimizing profiles in Play Cloud leverages the power of Android Play to bring all PGO benefits at install/update time: most users can get great performance without waiting!
The idea relies on two key observations:
This means we can use the initial rollout of an app to bootstrap the performance for the rest of users. ART analyzes what part of the application code is worth optimizing on the initial devices, and then uploads the data to Play Cloud, which will build a core-aggregated code profile (containing information relevant to all devices). Once there is enough information, the code profile gets published and installed alongside the app's APKs.
On a device, the code profile acts as a seed, enabling efficient profile-guided optimization at install time. These optimizations help improve cold startup time and steady state performance, all without an app developer needing to write a single line of code.
One of the main goals is to build a quality, stable code profile out of aggregated & anonymized data as fast as possible (to maximize the number of users that can benefit), while also making sure we have enough data to accurately optimize an app's performance. Sampling too much data takes up more bandwidth and time at installation. In addition, the longer we take to build the code profile, the fewer users get the benefits. Sampling too little data, and the code profile won't have enough information on what to properly optimize in order to make a difference.
The outcome of the aggregation is what we call a core code profile, which only contains anonymous data about the code that is frequently seen across a random sample of sessions per device. We remove outliers to ensure we focus on the code that matters for most users.
Experiments show that the most commonly used code paths can be calculated very quickly, over a small amount of time. That means we are able to build a code profile fast enough that the majority of users will benefit from.
*Data averaged from Google apps, Source: Google internal data
In Android 9.0 Pie, we introduced a new type of installation artifact: dex metadata files. Similar to the APKs, the dex metadata files are regular archives that contain data about how the APK should be optimized - like the core code profiles that have been built in the cloud. A key difference is that the dex metadata are managed solely by the platform and the app stores, and are not directly visible to developers.
There is also built-in support for App Bundles / Google Play Dynamic Delivery: without any developer intervention, all the app's feature splits are optimized.
To understand how these code profiles achieve better performance, we need to look at their structure. Code profiles contain information about:
Using this information, we use a variety of optimization techniques, out of which the following three provide most of the benefits:
We rolled out profiles in the cloud to all apps on the playstore at the end of last year.
A very interesting observation is that, on average, ART profiles about 20% of the application methods (even less if we count the actual size of the code). For some apps, the profile covers only 2% of the code while for some the number goes up to 60%.
Why is this an important observation? It means that the runtime has not seen a lot of the application code, and is thus not investing in the code's optimization. While there are a lot of valid use-cases where the code will not be executed (e.g. error handling or backwards compatibility code), this may also be due to unused features or unnecessary code. The skew distribution is a strong signal that the latter could play an important role in further optimizations (e.g. lowering APK size by removing unneeded dex bytecode).
We're excited about the improvements that ART optimizing profiles has shown, and we'll be growing this concept more in the future. Building a profile of code per app opens opportunities for even more application improvements. Data can be used by developers to improve the app based on what's relevant and important for their end users. Using the information collected in Profiles, code can be re-organized or trimmed for better efficiency. Developers can potentially use App Bundles to split their features based on their use and avoid shipping unnecessary code to their users. We've already seen great improvements in app startup time, and hope to see additional benefits coming from profiles to make developer's lives easier while providing better experiences for our users.
Posted by Raman Tenneti, AOSP Software Engineer and Ally Sillins, AOSP Program Manager
When we started the Android Open Source Project (AOSP) 10 years ago, we included some basic applications in the AOSP build for three main purposes:
However, as the Android ecosystem has matured over time, we've noticed a healthy growth of alternative applications - both as open source and proprietary implementations - developed by the developer community. These alternative applications are not only capable to serve the first two purposes, but often times showcase richer set of features demonstrating the power of Android. Late last year, we began to clean up these applications in AOSP to focus more effectively on the last purpose — their role to provide functionality to other Android applications as part of the platform.
To date, the following 3 apps have been cleaned up: Music, Calendar, and Calculator. See below for details on these updates. Going forward, you can expect to see similar efforts with the other applications in the AOSP repository.
As always, we're excited to hear your feedback on the developer website or through our AOSP forum.
AOSP's Music app can now playback music, one file at a time, and exposes itself as an intent handler for the android.media.browse.MediaBrowserService. The app has controls to play and pause, and a slider moving forward and backward. Features removed include: Music Icon, Artists, Albums, Songs, Playlists, Search, and Settings.
AOSP's Calendar app now exposes itself as an intent handler for the calendar events. New events cannot be created and existing events cannot be edited or deleted. The following features have been deleted: support for multiple accounts, reminders and settings. In addition, some features remain that are not needed for providing a part of the platform functionality: views for day, week, and month. This app may be further simplified in the future.
The calculator application is a standalone app, and does not function as part of the platform and hence has been removed from the AOSP build. However, the application will continue to exist as an open source project separately.
Posted by Vlad Radu, Product Manager and Nicholas Lativy, Software Engineer
The Google Play Developer API allows you to automate your in-app billing and app distribution workflows. At Google I/O '18, we introduced version 3 of the API, which allows you to transactionally start, manage, and halt staged releases on all tracks, through production, open testing, closed testing (including the new additional testing tracks), and internal testing.
In addition to these new features, version 3 also supports all the functionality of previous versions, improving and simplifying how you manage workflows. Starting December 1, 2019, versions 1 and 2 of the Google Play Developer API will no longer be available so you need to update to version 3 ahead of this date.
If you use the Google Play API client libraries (available for Java, Python, and other popular languages), we recommend upgrading to their latest versions, which already support version 3 of the API. In many cases, changing the version of the client library should be all that is necessary. However, you may also need to update specific code references to the version of the API in use - see examples in our samples repository.
Many third-party plugins are already using version 3 of the API. If you use a plugin that does not support version 3 you will need to contact the maintainer. You will start seeing warnings in the Google Play Console in mid-May if we detect that your app is still using version 1 and version 2 endpoints.
For version 1 users
If you currently use version 1 of the API, you may also need to link your API project to the Google Console before converting to version 3. Learn more about this process.
We hope you benefit from the new features of the Google Play Developer Publishing API and are looking forward to your continued feedback to help us improve the publishing experience on Google Play.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Wojtek Kaliciński, Developer Advocate, Android
Last year, we launched Android App Bundles and Google Play's Dynamic Delivery to introduce modular development, reduce app size and streamline the release process. Since then, we've seen developers quickly adopt this new app model in over 60,000 production apps. We've been excited to see developers experience significant app size savings and reductions in the time needed to manage each release, and have documented these benefits in case studies with Duolingo and redBus.
Thank you to everyone who took the time to give us feedback on our initial launch. We're always open to new ideas, and today, we're happy to announce some new improvements based on your suggestions:
When you adopt the Android App Bundle as the publishing format for your app, Google Play is able to optimize the installation by delivering only the language resources that match the device's system locales. If a user changes the system locale after the app is installed, Play automatically downloads the required resources.
Some developers choose to decouple the app's display language from the system locale by adding an in-app language switcher. With the latest release of the Play Core library (version 1.4.0), we're introducing a new additional languages API that makes it possible to build in-app language pickers while retaining the full benefits of smaller installs provided by using app bundles.
With the additional languages API, apps can now request the Play Store to install resources for a new language configuration on demand and immediately start using it.
The app can get a list of languages that are already installed using the SplitInstallManager#getInstalledLanguages() method.
SplitInstallManager#getInstalledLanguages()
val splitInstallManager = SplitInstallManagerFactory.create(context) val langs: Set<String> = splitInstallManager.installedLanguages
Requesting an additional language is similar to requesting an on demand module. You can do this by specifying a language in the request through SplitInstallRequest.Builder#addLanguage(java.util.Locale).
SplitInstallRequest.Builder#addLanguage(java.util.Locale)
val installRequestBuilder = SplitInstallRequest.newBuilder() installRequestBuilder.addLanguage(Locale.forLanguageTag("pl")) splitInstallManager.startInstall(installRequestBuilder.build())
The app can also monitor install success with callbacks and monitor the download state with a listener, just like when requesting an on demand module.
Remember to handle the SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION state. Please note that there was an API change in a recent Play Core release, which means you should use the new SplitInstallManager#startConfirmationDialogForResult() together with Activity#onActivityResult(). The previous method of using SplitInstallSessionState#resolutionIntent() with startIntentSender() has been deprecated.
SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION
SplitInstallManager#startConfirmationDialogForResult()
Activity#onActivityResult()
SplitInstallSessionState#resolutionIntent()
startIntentSender()
Check out the updated Play Core Library documentation for more information on how to access the newly installed language resources in your activity.
We've also updated our dynamic features sample on GitHub with the additional languages API, including how to store the user's language preference and apply it to your activities at startup.
Please note that while the additional languages API is now available to all developers, on demand modules are in a closed beta for the time being. You can experiment with on demand modules in your internal, open, and closed test tracks, while we work with our partners to make sure this feature is ready for production apps.
In Android Studio 3.3, we introduced a way to build app bundles that contain both the regular, installed version of your app as well as a Google Play Instant experience for modules marked with the dist:instant="true" attribute in their AndroidManifest.xml:
AndroidManifest.xml
<manifest ... xmlns:dist="http://schemas.android.com/apk/distribution"> <dist:module dist:instant="true" /> ... </manifest>
Even though you could use a single project to generate the installed and instant versions of your app, up until now, developers were still required to use product flavors in order to build two separate app bundles and upload both to Play.
We're happy to announce that we have now removed this restriction. It's now possible to upload a single, unified app bundle artifact, containing modules enabled for the instant experience. This functionality is now available for everyone.
After you build an instant-enabled app bundle, upload it to any track on the Play Console, and you'll be able to select it when creating a new instant app release. This also means that the installed and instant versions of your app no longer need different version codes, which will simplify the release workflow.
You need to enable app signing by Google Play to publish your app using an Android App Bundle and automatically benefit from Dynamic Delivery optimizations. It is also a more secure way to manage your signing key, which we recommend to everyone, even if you want to keep publishing regular APKs for now.
Based on your feedback, we've revamped the sign-up flow for new apps to make it easier to initialize the key you want to use for signing your app.
Now developers can explicitly choose to upload their existing key without needing to upload a self-signed artifact first. You can also choose to start with a key generated by Google Play, so that the key used to locally sign your app bundle can become your upload key.
Read more about the new flow.
We have now added the ability to permanently uninstall dynamic feature modules that are included in your app's initial install.
This is a behavior change, which means you can now call the existing SplitInstallManager#deferredUninstall() API on modules that set onDemand="false". The module will be permanently uninstalled, even when the app is updated.
SplitInstallManager#deferredUninstall()
onDemand="false"
This opens up new possibilities for developers to further reduce the installed app size. For example, you can now uninstall a heavy sign-up module or any other onboarding content once the user completes it. If the user navigates to a section of your app that has been uninstalled, you can reinstall it using the standard on demand modules install API.
We hope you enjoy these improvements and test them out in your apps. Continue to share your feedback as we work to make these features even more useful for you!
