Share Targets

Android 10 is changing the “share sheet” that is displayed when an ACTION_SEND Intent is used. A new system of “share targets” is available, to help the user not only send content to your app, but send it to some specific context. To do this, Android 10 hacks in a change to dynamic shortcuts, reusing those for ACTION_SEND scenarios.

What Came Before

Android 10, in effect, implements a mash-up of the old “direct share” system with the old “dynamic shortcuts” system to create the new “share targets” system.

Direct Share

Many apps that support responding to ACTION_SEND just do that, nothing more. Android 6.0, though, added a “direct share” API that allows apps to offer not only the app as a place to share, but something specific within the app:

• A messaging client might offer sharing to a particular contact
• A note-taking app might offer “sharing” to a particular category, filing the shared content under that category for later retrieval
• A file manager might offer “sharing” to a particular directory, saving the content as a file in that specified location
• And so on

This involved:

• Creating a subclass of ChooserTargetService
• Registering it in the manifest with an <intent-filter> having <action android:name="android.service.chooser.ChooserTargetService"/>
• Having your ACTION_SEND activity have a <meta-data> element pointing to the service
• Implementing onGetChooserTargets() to supply a list of ChooserTarget options based on the IntentFilter matched for your ACTION_SEND activity

The ChooserTarget objects would contain a title, an icon, and a Bundle of extras. The Bundle would be merged into the rest of the ACTION_SEND Intent if the user chose that particular ChooserTarget, where the icon and title would be shown as an additional option on the “share sheet” UI that appeared for an ACTION_SEND request

This worked, but it had performance implications. This approach was a “pull” mechanism, where Android would need to collect the ChooserTarget objects before the “share sheet” could be fully displayed. For any candidate apps that lacked running processes, this would involve forking fresh processes for those apps, so their ChooserTargetService subclasses could do their work. This added a lot of overhead, particularly for users who installed a bunch of ACTION_SEND-capable apps that advertised support for a wide range of content (e.g., */* as a MIME type).

Part of the reason for Android 10’s changes is to switch to a “push” mechanism, whereby apps can register possible share targets in advance. That way, the data is available immediately when an ACTION_SEND is requested, and the “share sheet” can be displayed more rapidly.

Dynamic Shortcuts

Android 7.1 added app shortcuts. This is a way for an app to advertise additional entry points into the app, without having multiple launcher icons. Instead, the app can teach Android additional shortcuts, which launcher apps (or other apps) could then present to the user. For example, long-pressing on a launcher icon might pop up a list of these shortcuts for a user to choose from.

Static shortcuts are the easiest ones to set up, as they just require a resource and a manifest entry. However, they are fixed options. Dynamic shortcuts, by comparison, allow your app to offer shortcuts based on user data and behavior (e.g., have a shortcut to compose an email to a particular contact). However, they are more complex to set up, requiring you to work with a ShortcutManager system service and define the available shortcuts from your Java or Kotlin code.