Android apps can see what you install: what can we do about it?

January 18, 2026

This is a response to an article I read about Android permissions: Everyone knows all the apps on your phone. I’ll summarize the main problem, but I’ll also explain something the article doesn’t: what we as users can do.

What’s the problem?

The main points are:

• as a developer of an app, to see a user’s list of installed apps, you have to:
  • either list the thing you’re looking for inside of a queries key. You can search e.g. for an intent, or for a package.
    • an ‘intent’ is how you say you want to do something in Android. For example you can create an intent to open a PDF, and Android will ask the user which app to use (from a list of apps that said they can handle PDFs). Or apps can listen to intents and react to them.
  • or declare the permission QUERY_ALL_PACKAGES in the AndroidManifest.xml file
    • because this permission is sensitive, you have to justify why you need this permission to Google (at least for apps going into Google Play)
• there is a loophole, where if you declare in queries the intent as <action android:name="android.intent.action.MAIN">, you’re querying for any apps that have a main activity – basically any app with a screen
  • the legitimate use case for this is a launcher: if you want to launch apps’ main activities, you need to know which apps are launchable. But it can easily be misused.

While the title of the original article is a bit clickbaity, the point stands: everyone can know all the apps on your Android phone.

Here’s how permissions work in android. You can have install-time permissions, runtime permissions, and special permissions. Install-time permissions are granted as soon as the app is installed. They can be “normal” (if they “present very little risk to the user’s privacy”), or “signature” (only granted when “the app is signed by the same certificate as the app or the OS that defines the permission”). Runtime permissions, or “dangerous permissions”, need to be requested from the user, via the ‘X wants to access Y’ dialog. Special permissions need to be manually enabled by the user via settings.

The permission QUERY_ALL_PACKAGES is a ‘normal’ permission, so if Google allows it in a review (or if you install it from elsewhere), the app doesn’t need user consent to get a list of installed apps, and you won’t even know it’s doing that. There are some other interesting ‘normal’ permissions, such as bluetooth/wifi management, and detecting when a screen capture is attempted. Though of course, using <queries> to find all apps with a main activity, or to see if some specific apps are installed, is free: you don’t need any kind of permission at all.

Is it a real problem?

In my opinion, absolutely yes.

Sure, on first sight, it might seem unimportant. But, let’s say you have a bunch of gambling apps installed, and your bank app can get a list of that. Who says they won’t reconsider the terms of your loan or mortgage? Or maybe you have a bunch of apps installed related to your baby – sleep tracker, food tracker, whatever else. If Amazon’s app can get a list of those, who says they won’t show you a higher price for essential childcare things, like diapers? There’s no way you’d even know. Or maybe you’re in a country with age restrictions, and the app that your government forces you to use can get a list of all apps you have, including those you’re not supposed to have because you’re not old enough. Or they can see that you have messaging apps that are ‘associated with crime’ according to their definition: that might be useful in future investigations. The list goes on and on.

And of course there’s always fingerprinting – a full list of installed apps is a great way to identify potentially a single person, or one of a small group of users.

So what can we do?

What the article lacks is info on how to actually address this as a user.

First point is, don’t use an app if you don’t need to.

If you do need to use an app, disable its network access at the OS level. For example, LineageOS lets you toggle network access per app, so if an app can’t phone home the list of apps that it gathered, there’s no harm to the user. If your ROM doesn’t let you disable network access per app, get a new ROM.

If you need to use an app with network access, check the permissions. For apps that you’re about to install, Exodus audits various applications to get their list of permissions and to check what trackers they contain; this is also displayed as part of app info in Aurora Store.

If you want to check which of the apps that you’ve already installed have this permission, you can use the pm and dumpsys commands in an adb shell. For example, to get a list: pm list packages | cut -d: -f2- | while read -r l; do if dumpsys package $l | grep -i 'query_all_packages: granted=true' >/dev/null; then echo "$l"; fi; done

Unfortunately there’s no easy way to tell who’s using the <queries> loophole. For that, you’d need to download the APK, either from an online mirror, or from your phone. To get it from your phone, run dumpsys package package.bundle.id (you can see package.bundle.id at the bottom of the app’s info in Settings), and look for codePath. Then run adb pull on the path listed in codePath. Once you have the APK, decompile it with apktool d /path/to/pulled.apk, and look at AndroidManifest.xml. You’ll see a list of queries. If you want to see for yourself what the query returns, you can run adb shell pm query-activities -a intent. For example, to check what’s returned if I use that loophole to get a list of apps, I can run adb shell pm query-activities -a android.intent.action.MAIN (and it indeed returns the full list of apps).

To be fair, there are legitimate reasons why you need to query the list of installed apps. For example, for Tailscale to do split-tunneling (and let you select which apps are sent through the Tailscale connection and which are not), it needs to be able to show you a list of apps. A launcher needs to show you the list of apps. Bank apps say they need it for security reasons (I have my opinions about that but OK). It’s just important to be informed about this stuff and to know how you can mitigate potential privacy risks.