The friendly guide to android intent (simple, clear, and practical)

Introduction
An android intent is a tiny message that helps parts of an app talk to each other. It also helps apps ask the system to do things. Think of it like a note you pass to another app. The note says what you want done and can carry small bits of data. Intents make apps work together. They help you open a web page, pick a photo, or send some text. This guide explains intents in plain words. It gives clear examples, safe tips, and real patterns you can use. By the end, you will know how to send an intent, handle one, and avoid common bugs.
What is an android intent?
An android intent is an object. It describes an action and the data to act on. You build an intent and hand it to the system. The system then finds a component to run. Components include activities, services, and broadcast receivers. Intents can be simple. They can be complex. They can carry extras. Extras are key/value pairs that travel with the intent. Intents use actions like ACTION_VIEW
or ACTION_SEND
to say what to do. You can set a MIME type to tell the system the data format. In short, intents are the main way to request actions from other apps and the system.
Explicit vs implicit android intent — quick look
There are two main kinds of android intent. Explicit intents name a component. You use them to open another activity inside your app. Implicit intents name an action. They let the system pick which app can handle it. Use explicit intents for internal navigation. Use implicit intents when you want other apps to help. For example, to open a web page use an implicit intent with ACTION_VIEW
. For a camera screen inside your own app, use an explicit intent naming the camera activity. Always check that an implicit intent can be handled before you launch it.
Common actions and built-in android intent uses
Android ships with many common intent actions. These make many tasks easy. For example, ACTION_VIEW
opens a URL or a file. ACTION_SEND
shares text or an image. ACTION_DIAL
opens the phone dialer. You rarely need to build a handler from scratch. You ask the system to open a matching app. This is great for simple features. Use those when you want standard behavior. This keeps your app small and predictable. It also gives users the apps they prefer for each action.
How to create and send an android intent (short examples)
To make an android intent, you create a new Intent
object. Then you set the action and data. In Java you might write new Intent(this, NextActivity.class)
. In Kotlin the code is similar but shorter. After you make the intent, call startActivity()
to run it. If you want to pass data, use putExtra()
with a key name.
Example:
// Kotlin explicit intent
val intent = Intent(this, DetailActivity::class.java)
intent.putExtra("itemId", 42)
startActivity(intent)
// Java explicit intent
Intent intent = new Intent(this, DetailActivity.class);
intent.putExtra("itemId", 42);
startActivity(intent);
For implicit intents, set an action and data URI instead of a class name.
Passing data with extras in an android intent
Extras let you carry small bits of data with an android intent. They behave like a map with keys and values. Use putExtra()
to add data. Use getStringExtra()
or other getters to read data. You can also pass a Bundle
or Parcelable objects when you need more structure. Keep extras small and simple. Large files should go by file URI or shared storage, not in extras. Use clear key names, ideally with your app’s package as a prefix, to avoid collisions. Extras are the safest and cleanest way to send small data between screens.
Getting results back: Activity Result APIs vs startActivityForResult
In the past, apps used startActivityForResult()
and onActivityResult()
to get answers from another screen. That pattern is now superseded by the Activity Result APIs in AndroidX. The newer API uses registerForActivityResult()
with a contract. It is safer when components recreate or when fragments are involved. If you still see startActivityForResult
, know that Google recommends switching to the Activity Result APIs. Use the newer API for new code.
Intent filters and how they help your app receive an android intent
An app declares intent filters in its manifest or at runtime. Filters tell the system which intents your components can handle. Filters match actions, categories, and data like schemes or MIME types. If a user tries to view a PDF, the system finds apps whose filters match ACTION_VIEW
and the application/pdf
MIME type. Well-designed filters make your app discoverable. But be careful: overly broad filters can make your app accept unwanted data. Test filters with sample intents and use resolveActivity()
to check handlers before launching implicit intents.
Intents for services, broadcasts, and PendingIntent
Intents are not only for activities. You can start or bind services with intents. You can also send broadcasts. A PendingIntent
wraps an intent for future delivery by the system. Use pending intents for notifications, alarms, or when another app or the system will run your intent later. Services and broadcast receivers handle intents differently. Services run code in the background. Broadcasts are sent to many receivers. PendingIntent gives another app permission to run your intent with your identity.
Best practices and common pitfalls with android intent
Keep intents explicit when possible. Use explicit intents for internal navigation. For implicit intents, always check that a handler exists. Use resolveActivity()
or a safe try/catch. Avoid putting large data in extras. Use file URIs or content providers for big files. Prefer modern Activity Result APIs for getting results. Be clear with MIME types when you share content. Add categories only when needed. Avoid trusting data from external intents. Validate and sanitize every value before use. These small rules keep your app stable and secure. They also make behavior predictable for users and other apps.
Security and privacy tips for android intent handling
Intents can carry data from other apps. Treat that data as untrusted input. Never trust an external intent without validation. Check for null or unexpected types. When receiving an intent, only request the permissions you need. Use FLAG_GRANT_READ_URI_PERMISSION
with content URIs to give temporary read access. When sending sensitive data, prefer internal passing or secure storage. Avoid exposing private actions in exported components unless you guard them. Use explicit intents for internal actions to reduce attack surface. These habits protect user data and reduce security bugs.
Debugging android intent problems — quick wins
If an intent fails, confirm the action and data first. Use logs to print the intent’s action, data, and extras. When an implicit intent does nothing, test resolveActivity()
to see if any app can handle it. If data is missing, check the putExtra()
keys and types. For result flows, make sure the newer Activity Result APIs are correctly registered before launching. Use adb shell am start -a ACTION_VIEW -d "uri"
to test intents from the command line. Small checks like these speed up debugging and keep your app responsive.
Real-world patterns and examples using android intent
A common pattern is “share to” using ACTION_SEND
. Your app sets a MIME type and extras with the text or URI. Another pattern is “open with” where the system shows apps that can handle the file. For photos, you might take a picture with the camera app using an implicit intent and receive the image URI back. For forms, use explicit intents to move to the next screen. For background jobs, wrap service intents in a PendingIntent
used by alarms or notifications. Pick the pattern that matches your UX. Simple, consistent behavior wins.
Frequently Asked Questions (FAQs)
Q1 — What is the shortest way to explain an android intent?
An android intent is a message that asks the system or another app to do something. It says what you want done and can include small data bits. You build an intent, then start an activity, service, or send a broadcast. For simple uses, an intent is like saying “open this web page” or “share this text.” When you design apps, use explicit intents for internal navigation and implicit intents when you want other apps to help. This keeps your app clear and predictable.
Q2 — When should I use an implicit android intent versus an explicit one?
Choose an implicit android intent when you need another app to perform a common action. Examples include viewing a URL, picking a contact, or sharing a photo. Use an explicit intent when you know the exact activity or service to run in your app. Implicit intents let users pick their favorite apps. Explicit intents give you direct control. For security and clarity, prefer explicit intents for internal flows and implicit intents for system-wide tasks.
Q3 — How do I safely pass images or files with an android intent?
Do not put large files into intent extras. Instead, use a content URI and grant temporary access. Use FileProvider
to share local files as secure URIs. Set the correct MIME type so the receiver knows the file format. Add FLAG_GRANT_READ_URI_PERMISSION
when you send the intent. For longer-lived sharing, consider copying the file to shared storage or uploading it to a server. These steps avoid crashes and protect user files.
Q4 — Is startActivityForResult()
still OK to use with android intent?
startActivityForResult()
still works but is not the recommended way. Google favors the Activity Result APIs in AndroidX. The new APIs use registerForActivityResult()
and contracts. They handle lifecycle changes better and avoid common bugs with fragments and recreation. For new code, use the Activity Result APIs. For older code, plan a migration to the new pattern for more robust results handling.
Q5 — What are common security mistakes with android intent handling?
Common mistakes include trusting data from external intents and exposing exported components without checks. Also avoid leaving sensitive actions available via implicit intents. Do not write broad intent filters that accept unexpected data. Always validate incoming extras, check URIs, and verify permissions when needed. Use explicit intents for internal actions and only export components when necessary. These checks reduce the risk of data leaks and unwanted behavior.
Q6 — How can I test that an android intent will be handled before launching it?
Use resolveActivity()
on your intent with the package manager. If it returns non-null, there is at least one matching handler. For more complex checks, query the PackageManager
for matching activities or services. You can also test from the command line with adb shell am start
to simulate an intent. These steps help avoid crashes and give a smoother user experience.
Conclusion — put it all together
Intents are a core part of Android. A well-made android intent makes your app play nicely with the system and other apps. Use explicit intents for inside navigation. Use implicit intents for common system tasks. Use extras carefully and prefer modern Activity Result APIs for responses. Protect data by validating inputs and using secure URIs. These small habits make your app safer and friendlier. Try the examples here in a small app. Test each intent flow and practice until it feels natural.