Android App Security · Components & Intents · Lesson 2 of 5

Intents & the Share Sheet

See how apps ask each other for help, and how the share sheet decides who answers.

Asking the system for help

In module 1 you met the intent, the message an app gives Android when it wants a component started. Intents come in two flavors.

• An explicit intent names the exact app and component, like "open com.example.quicknotes/.SettingsActivity". Apps mostly use these to move between their own screens.
• An implicit intent describes a job instead of a component, like "view this web page" or "send this photo". Android finds an app that can do it.

An implicit intent is built from a few parts. The action says what to do, such as ACTION_SEND, ACTION_VIEW or ACTION_DIAL. The data is a URI (a link-like address such as tel:5551234 or https://...), and the MIME type says what kind of content it is, such as image/jpeg or text/plain.

How does Android know which apps can help? Each app lists jobs it accepts in its manifest using an intent filter: "this activity handles ACTION_SEND for images", for example. Android compares the intent's action, data and category against every installed app's filters. If several apps match, you choose. For sharing, apps usually show the chooser (the share sheet), which asks every time and never remembers a default.

Notice what this means. Any app can add a filter claiming it handles images. Appearing in your share sheet isn't a sign of trust, only a sign the app asked to be there.

Explicit intents have limits too. An app can only start another app's component directly if that component is marked exported. You'll study that rule in module 3.

On the simulated phone, try all four buttons. For each, note the action, the data or type, and whether a chooser appears.

Handing over the goods

Sharing a photo raises a puzzle. You learned in Mobile Fundamentals that each app's private files are locked inside its sandbox. So how does Messages read a photo that lives in another app's private storage?

The answer is a content URI, an address that starts with content://. Instead of pointing at a raw file path, it points at a content provider in the sending app, which serves the file on request. Many apps use a ready-made provider called FileProvider for this. A shared photo might look like content://com.example.quicknotes.fileprovider/images/cat.jpg.

The sender then adds a flag to the intent, FLAG_GRANT_READ_URI_PERMISSION. This gives the receiving app a temporary grant: permission to read that one item, not the whole provider, and it expires on its own when the receiving app's task is finished. The provider itself can stay unexported, so no app can browse it uninvited.

The older way was to send a file:// path. That forced the receiver to have broad storage access and exposed real file locations. Since Android 7.0, apps targeting that version get an error if they try to send file:// paths in an intent.

One more piece of the picture. Since Android 11, an app that targets that version can't freely list every other app on your phone. This is called package visibility. The app has to declare in its manifest which apps or kinds of intents it needs to see, using a <queries> element. Asking to see everything requires a special permission, QUERY_ALL_PACKAGES, and Google Play only allows that for apps with a real need. Your list of installed apps reveals a lot about you, such as your bank, your health apps and your dating app, so this limit protects your privacy.