Introduction

Checking whether another app is installed on Android sounds simple, but modern Android adds a package-visibility rule that changes the implementation. The basic lookup still uses PackageManager, but on Android 11 and later your app may need to declare which packages it wants to query before the lookup can succeed reliably.

Basic PackageManager Check

The classic approach is to ask the package manager for information about a package name and catch the “not found” case.

1import android.content.Context
2import android.content.pm.PackageManager
3
4fun isInstalled(context: Context, packageName: String): Boolean {
5    return try {
6        context.packageManager.getPackageInfo(packageName, 0)
7        true
8    } catch (e: PackageManager.NameNotFoundException) {
9        false
10    }
11}

If the package exists and is visible to your app, the function returns true.

Package Visibility on Android 11+

Starting with Android 11, apps cannot freely query every installed package. If you want to check for another app, declare that visibility in the manifest.

1<manifest ...>
2    <queries>
3        <package android:name="com.example.otherapp" />
4    </queries>
5</manifest>

Without the appropriate queries entry, your package lookup can behave as if the app is not installed even when it actually is.

When getLaunchIntentForPackage Is Enough

If your real goal is “can I launch this app,” getLaunchIntentForPackage can be a practical shortcut.

fun canLaunch(context: Context, packageName: String): Boolean {
    return context.packageManager.getLaunchIntentForPackage(packageName) != null
}

This is useful when you only care whether the target app exposes a launchable activity, not whether every package detail can be queried. It is not a perfect substitute, though, because some installed apps deliberately expose no launcher entry point at all.

Distinguish “Installed” from “Usable”

These are not always the same question.

• installed: package exists on the device and is visible to your app
• launchable: app exposes an activity you can start
• integration-ready: app exposes the specific intent, service, or provider your workflow needs

Sometimes a better check is to query for a specific intent action rather than for installation in the abstract.

Querying by Intent

If the interaction is based on an intent rather than a hardcoded package name, ask whether any matching activity exists.

1import android.content.Intent
2import android.content.pm.PackageManager
3
4fun canHandleIntent(context: Context): Boolean {
5    val intent = Intent(Intent.ACTION_VIEW).apply {
6        setPackage("com.example.otherapp")
7    }
8    return intent.resolveActivity(context.packageManager) != null
9}

This can be more robust than treating installation as the entire problem.

Use Cases and Privacy

Android tightened package visibility for privacy reasons. That means the platform expects you to query only packages relevant to your app’s functionality. If you find yourself wanting a full installed-app inventory, that is usually a sign you should recheck the product requirement rather than search for a workaround.

Common Pitfalls

A common mistake is using getPackageInfo without a corresponding queries declaration on Android 11 and later. Another is checking only whether the package exists when the real requirement is whether a particular activity or intent can be handled. Developers also sometimes confuse installation with enablement, since a package can exist but still be disabled for the user. Finally, querying broad sets of packages unnecessarily can run into policy and privacy concerns.

Summary

• Use PackageManager to check whether a known package is installed.
• On Android 11 and later, declare package visibility with a queries manifest entry.
• If your goal is launching another app, getLaunchIntentForPackage may be the simpler check.
• Sometimes intent resolution is a better test than package existence.
• Think carefully about visibility and privacy, because modern Android does not allow unrestricted package discovery by default.