5 ways Google is making the share sheet better in Android 14

Mishaal Rahman
Try Esper for Free
Learn about Esper mobile device management software for Android and iOS

Android 14 is currently in its Developer Preview phase, so Google hasn’t yet finalized what changes, new features, and API additions will make their way into the stable release. Still, from what we can see in the second Developer Preview release and in the documentation, it appears that Google is planning to revamp the share sheet in the coming release. Here are 5 changes to the share sheet we spotted in Android 14.

(A lot of this article won’t make sense if you aren’t familiar with what the share sheet is and how it works. Fortunately, we have a detailed explainer you can refer to right here.)

A dedicated row for app actions

One of the problems we identified with the share sheet is that, for the most part, it treats every app the same when it comes to displaying share targets. For example, Twitter’s share targets appear towards the bottom of the system share sheet because the list is sorted alphabetically. While it is possible for apps like Twitter to add custom share targets that appear before others in the share sheet, they can only specify two to appear before the rest of the Direct Share targets and two before the rest of the app targets. 

Two targets isn’t enough for many apps (Chrome’s custom share sheet has 6 actions), but allowing for more would further reduce the number of share targets from other apps the system can suggest (since they occupy the same space). That’s why Google discourages most developers from utilizing this feature, and partly why so many apps build their own custom share sheets.

Apps can specify up to two custom ChooserTargets and custom Intents to be shown first in the system share sheet. Image source: Google.

To solve this problem, Google is modifying the system share sheet in Android 14 so that it can show a dedicated row for app actions. When constructing the intent to invoke the system share sheet, apps on Android 14 can specify a new intent extra called EXTRA_CHOOSER_CUSTOM_ACTIONS that specifies ChooserAction objects to be shown in the share sheet. ChooserAction is a new API in Android 14 that lets developers provide custom “app-defined actions” to the system share sheet. These app-defined actions are shown to the user in a dedicated row below the content preview.

The share sheet in Android 14 without any custom ChooserAction objects provided by the Tasker app.
The share sheet in Android 14 with custom ChooserAction objects provided by the Tasker app.

I am not sure if there is a hard limit on the number of app-defined actions that can be provided by an app, but I was able to display up to 7 actions in a horizontally-scrollable carousel using the popular automation app Tasker by João Dias.

It will be interesting to see how developers make use of this API, if at all. Given that this new feature is only available to apps compiled against SDK 34 running on Android 14, it’s unlikely that most developers will immediately drop their custom share sheets in favor of the system one. Still, it’s good to see Google improve the share sheet in each Android release, especially in ways that address some of the major issues developers have had with it.

(The ChooserAction API and EXTRA_CHOOSER_CUSTOM_ACTIONS intent technically first made an appearance in Android 13 QPR2, but they are marked @hidden hence they are inaccessible through the public Android 13 SDK.) 

Share sheet is now a standalone app

One of the other big problems we identified with the system share sheet is that it doesn’t have a consistent design on all Android devices. OEMs customize the system share sheet to different degrees; some only add a couple of actions not found in AOSP while others tweak the UI significantly and even change the scrolling direction. If developers want to provide a sharing experience that’s consistent across Android devices, then, their only option is to build a custom share sheet.

Google may have a solution to this problem, though. Starting in Android 14 DP2, the share sheet feature is no longer handled by the OS framework. Instead, it is handled by a system app called “IntentResolver”. By unbundling the share sheet from the OS framework, Google has made it possible to update it independently of the OS. This is how Project Mainline works: Google modularized various system components by packaging them in .APK or .APEX format, distributed signed copies of these packages to OEMs to integrate into their Android builds, and built an update infrastructure into Google Play to handle pushing out updates to these packages. 

At the moment, however, there’s no indication that IntentResolver will become a new Project Mainline module. It is not referenced in the Google-signed ModuleMetadata app of Android 14 DP2, an app which contains metadata about the list of Project Mainline modules installed on the device. In contrast, the new HealthConnect APEX module is listed, as Google is making Health Connect a new Project Mainline module in Android 14. 

If Google were to turn IntentResolver into a new Project Mainline module, though, then that means they would have more control over the system share sheet on all Android devices. Hypothetically, they could enforce a particular UI, standardize the scrolling direction and buttons, and make changes more rapidly. Some OEMs may not be on board with giving up their share sheet customizations, so it remains to be seen if the share sheet will indeed become a Project Mainline module. Unbundling the share sheet from the OS framework is an important and necessary step towards making that happen, though.

This change won’t be noticeable to users, since the share sheet implementation in the IntentResolver app and the OS framework is the same. The only way to tell that the OS is using the unbundled share sheet is to check the system logs when invoking the share sheet. When the unbundled share sheet is active, the ACTION_CHOOSER intent is handled by IntentResolver’s ChooserActivity component instead of the framework’s one component, as demonstrated by the video embedded below:

The above video was recorded on an AOSP build of Android 13 QPR1, which is when I first discovered the existence of the unbundled share sheet. The CHOOSER_UNBUNDLED flag that decides whether to use the IntentResolver or framework for the share sheet was set to false by default in Android 13 QPR1, so I had to manually flip the flag using a shell command. In Android 13 QPR3 Beta 1/Android 14 DP2, the CHOOSER_UNBUNDLED flag is now enabled by default, hence IntentResolver now handles all share sheet invocations.

Share sheet reselection

When you select multiple media items to share and then tap the share button to invoke the system share sheet, you may sometimes want to go back and remove some of your selections or add some more media items to your selection. What I just described is probably a fairly common occurrence for many users, but fortunately it’s easy to dismiss the share sheet and reselect items in most apps. However, some apps don’t remember your previous selections, while others may invoke the share sheet at the end of some multi-step process that requires more than a few taps to get back to. 

To make it easier for users to modify what content they’re sharing, the share sheet in Android 14 has added support for showing a shortcut to return to the app that invoked the share sheet so that users can reselect media items. This shortcut is only shown when the source app invoking the share sheet adds the EXTRA_CHOOSER_MODIFY_SHARE_ACTION argument to the share sheet intent; this argument specifies a PendingIntent “to be sent when the user wants to modify the content that they're sharing. This can be used to allow the user to return to the source app to, for example, select different media.”

(The aforementioned intent extra is technically already present in AOSP since Android 13 QPR2 under a different name, but like the ChooserAction API and EXTRA_CHOOSER_CUSTOM_ACTIONS intent extra, it’s marked @hidden hence it isn’t available through the public Android 13 SDK.)

Scrollable image previews

Currently, when you select 4 or more images to share, the system share sheet only shows you a preview of the first 3 items in your selection and simply provides a number of how many other images you’re sharing. In Android 14, the share sheet now displays image previews in a horizontally scrollable carousel. That means if you’re sharing more than 4 images at a time, you can check to see if you’ve included any images you don’t want to share without dismissing the share sheet. Plus, if the app that invokes the share sheet adds support for the aforementioned share sheet reselection feature, then you’ll be able to easily reselect media items when you make a mistake while selecting items.

On Android 13 QPR3 Beta 1, the share sheet only shows thumbnails for the first three images being shared.
On Android 14 DP2, previews for all images being shared are visible and arranged in a horizontally scrollable carousel.

Include/exclude text with images

The fifth improvement to the share sheet we spotted in Android 14 is the ability to include/exclude text or URLs when sharing images. When an image file is being shared and there’s some accompanying text to it (defined in the android.intent.extra.TEXT intent extra), then the system share sheet will show an “[include|exclude] text” button that will add/remove the EXTRA_TEXT intent extra and reinvoke the share sheet with or without it. If the text in the EXTRA_TEXT intent extra is a URL, then the button will say “[include|exclude] link” instead, but the functionality remains the same.

“Include text” button shown when sharing an image that has some accompanying text.
“Exclude text” button shown when sharing an image that has some accompanying text.

All five of the changes described in this article are present in Android 14 DP2 without any hacks or modifications; two of the changes are documented in the official developer docs, while the remaining three are under-the-hood changes that do not need any developer-facing documentation. However, since Android 14 has not been finalized yet, it is possible that some or all of these changes could be reverted in future preview releases.

Everything You Need to Know about MDM


No items found.
No items found.

Keep Exploring

No items found.
Mishaal Rahman
Mishaal Rahman

Mishaal Rahman is a Technical Editor at Esper. He has been an Android user for over a decade and has been at the forefront of Android news coverage for half a decade. His in-depth breakdowns of new Android versions have been referenced across the Internet.

Mishaal Rahman
Learn about Esper mobile device management software for Android and iOS
Featured resource
Read more
Featured resource
Considerations for Building Android Apps for Company-Owned Devices
Your app delivers your customer (or employee) experience, making it a crucial piece of your overall solution. Use this guide to understand the considerations of designing and building your perfect app for dedicated device use cases on Android hardware.
Download the Guide

Esper is Modern Device Management

For tablets, smartphones, kiosks, point of sale, IoT, and other business-critical edge devices.
MDM Software
Kiosk mode icon as a feature in mobile device management software

Kiosk mode

Hardened device lockdown for all devices (not just kiosks)
App management icon as a feature in mobile device management software

App management

Google Play, Apple App Store, private apps, or a mix of all three
Devices groups icon as a feature in mobile device management software

Device groups

Manage devices individually, in user-defined groups, or all at once
Remote tools icon as a feature in mobile device management software

Remote tools

Monitor, troubleshoot, and update devices without leaving your desk
Touchless provisioning as a feature in mobile device management software

Touchless provisioning

Turn it on and walk away — let your devices provision themselves
Reporting and alerts as a feature in mobile device management software

Reporting and alerts

Custom reports and granular device alerts for managing by exception