How to Send Emails from an Android App with Intent

An Android app can open the user’s preferred mail client with a prepared recipient, subject and message rather than sending an email silently in the background. This is the usual approach for support requests, booking confirmations, receipts and feedback forms, because the user stays in control of the final message and delivery.

The core technique is to use an Android email intent, usually ACTION_SENDTO with a mailto: URI. It works well with common apps such as Gmail, Outlook and Samsung Email, although no application can guarantee that a particular mail client is installed. This distinction matters when building for a broad Australian audience, from customers in Sydney and Melbourne to people using regional networks in Queensland or Western Australia.

Choosing the Right Android Intent

For a basic email action, Intent.ACTION_SENDTO is generally the safest choice. A mailto: URI tells Android that the action is intended for an email application, which helps avoid showing unrelated sharing targets such as messaging, Bluetooth or social media apps.

val intent = Intent(Intent.ACTION_SENDTO).apply {
    data = Uri.parse("mailto:support@example.com")
    putExtra(Intent.EXTRA_SUBJECT, "Support request")
    putExtra(Intent.EXTRA_TEXT, "Please describe the issue here.")
}

startActivity(Intent.createChooser(intent, "Send email"))

The recipient can be included in the URI, while the subject and body are supplied as extras. For multiple recipients, use a properly encoded address list, and use Uri.encode() when inserting dynamic values. Names, order numbers and customer-entered text should never be placed into a URI without encoding, because spaces and special characters can produce invalid links.

Some mail applications handle extras differently. A subject may appear correctly while rich formatting is ignored, or the body may be inserted as plain text. Treat the intent as a request to prefill a draft, not as a guarantee that every email application will render identical content.

Building Email Content Safely

A useful email body should be short, readable and relevant to the task. For example, a support app might include the customer’s account reference, app version and a plain-language description of the problem. Avoid placing passwords, access tokens, full payment details or unnecessary personal information into the draft.

Kotlin makes it easy to build a plain-text message:

val body = """
    Hi Support,

    Account: $accountReference
    App version: $versionName

    $userDescription

    Regards,
    $customerName
""".trimIndent()

For an HTML message, use Html.fromHtml() where appropriate, but remember that support varies between email clients. A plain-text fallback is usually the most dependable option, particularly when the message may be opened on a phone with limited connectivity or copied into another application.

If your app collects Australian addresses, preserve familiar formatting such as suburb, state abbreviation and postcode. A small business in Parramatta, for example, may need the complete customer address in an email, while a regional delivery service may also need a property name or route note. Keep these details explicit rather than relying on visual formatting alone.

Adding Attachments and Files

ACTION_SENDTO is designed for email addressing and basic extras, but attachments are less consistently supported through it. When a file must be attached, ACTION_SEND or ACTION_SEND_MULTIPLE is often more suitable:

val shareIntent = Intent(Intent.ACTION_SEND).apply {
    type = "application/pdf"
    putExtra(Intent.EXTRA_EMAIL, arrayOf("accounts@example.com"))
    putExtra(Intent.EXTRA_SUBJECT, "Invoice $invoiceNumber")
    putExtra(Intent.EXTRA_TEXT, "Please find the invoice attached.")
    putExtra(Intent.EXTRA_STREAM, invoiceUri)
    addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
}

startActivity(Intent.createChooser(shareIntent, "Email invoice"))

The file should normally be exposed through a FileProvider, not a file:// URI. A content URI lets the selected email application read the attachment for the limited purpose granted by your app. Test both small and large files, because an attachment that works on Wi-Fi in Melbourne may be slow or unreliable over mobile data in the Northern Territory.

Before creating the intent, confirm that the URI exists and that the receiving application can access it. PDFs, images and spreadsheets may require different MIME types. If the attachment is optional, explain what will happen when it cannot be loaded instead of opening an empty or confusing draft.

Approach	Best use	Main advantage	Common limitation
ACTION_SENDTO with mailto:	Recipient, subject and plain-text body	Targets email applications clearly	Attachment support is inconsistent
ACTION_SEND	One attachment or a general email draft	Works with EXTRA_STREAM	May show broader sharing targets
ACTION_SEND_MULTIPLE	Several files	Supports multiple content URIs	Requires careful MIME and permission handling
Web-based mail link	Simple browser fallback	No native mail app required	Less control over user experience

Handling User Choice and Failures

Not every Android phone has a configured email account. Some users may have Gmail installed but no active account, while others may use Outlook, a business-managed client or a browser-only mailbox. Calling startActivity() without checking for a handler can cause an ActivityNotFoundException.

A defensive implementation checks first:

val chooser = Intent.createChooser(intent, "Send email")
if (intent.resolveActivity(packageManager) != null) {
    startActivity(chooser)
} else {
    showMessage("No email app is available. Please configure one and try again.")
}

The chooser label should describe the action clearly. “Send email” is more useful than a vague “Share”, especially for older users or customers completing a form quickly between jobs. In Australia, where many small businesses use a mix of personal Gmail accounts and Microsoft 365 work accounts, allowing the user to select their preferred client avoids making assumptions about their setup.

Do not tell the user that the email has been sent when your app has only opened a draft. A message such as “Your email draft is ready” is accurate. The mail application controls saving, sending, connectivity and any account authentication that follows.

Testing Across Australian Devices

Test on physical Android devices as well as emulators. Include current Samsung models, Google Pixel devices and at least one lower-cost handset, because Android versions, default mail clients and manufacturer settings can differ. Check the experience with Gmail, Outlook and Samsung Email where available.

Use test cases that reflect real conditions: a phone in airplane mode, a device with no mail account, a long body, accented names, multiple recipients and an attachment larger than a few megabytes. A customer on a long regional drive may open the draft without a stable connection, so the app should remain responsive and avoid doing unnecessary network work before launching the email client.

For implementation references and Android-specific examples, the Android tutorial resource can provide useful background, but verify every code sample against current Android and Kotlin documentation. A default phpMyAdmin page on a DigitalOcean Droplet is unrelated to Android email handling, so it should be treated as server setup documentation rather than as an active mobile tutorial.

Keeping Email Flows Private and Maintainable

Email intents are appropriate when the user should review and approve a message. They are not the right tool for automated receipts, password resets or scheduled notifications. Those workflows should use a secure backend email service, with credentials kept on the server rather than inside the Android package.

Keep intent construction in a small helper or repository class. This makes it easier to update subject templates, encode recipients, attach files and provide a fallback when no handler is available. It also keeps UI code focused on collecting input and showing an accurate status message.

Before release, review the data placed into every draft and log as little as possible. Avoid logging full email bodies, attachments or personal identifiers. Test cancellation as well as successful sending, then make the email action visible and predictable in the interface.

Add the appropriate intent code to your Android project, test it with the mail clients your users actually rely on, and refine the fallback message for devices without a configured email account. A careful draft-based flow gives Australians a familiar way to send support requests, invoices and documents while keeping control in the user’s hands.