How Android developers access installed apps on user’s device [pdf]

That is a good question, and thanks for asking it with a lot less toxic sarcasm then I would have.

One legitimate use case is perhaps that in the olden days before in-app purchases, you could install an empty paid app that would than act as a token that would enable some functionality in another app. The second app would need some way of checking the presence of the first app.

For this API precisely, I have to admit I have a pretty hard time to tell.

However, there are other APIs that leak the list of installed applications that have pretty legitimate usages.

For instance the intent resolving API:

- This can be used for an app to know which applications the user can share messages to. I believe that nowadays developers are supposed to use a generic API for that, that don't expose the list of applications to the user, but that's a pretty new API.

- This can be used by application Launchers, or apps that provide shortcuts or automated launch of other apps

Anti-malware/adware applications could use it to check for known bad applications.

One legit purpose would be to provide better UX in the source app. It could display text to explain the situation to the user in the case that they don't have the required ap. This would be a more seamless experience than a screen that has to account for both possibilities.

There are plenty of legitimate use cases listed under section 4.5.

I'm sure there is some scumbag adtech SDK out there profiling people based on their installed apps, but I think that most uses of these API's would turn out to be innocuous on a closer look.

For instance, I've worked on apps that check if another app from the same company is installed, so that they can integrate together. Think Facebook and Messenger: two separate apps.

It seems that this sort of innocent check would turn out in this study as a "call accessing package names". Sounds ominous at first, but I'm just asking for one package X, not scraping all your installed apps to sell you something.

Anyway, this is all being locked down in Android 11 [1]. Many of these use cases are being addressed with a more secure API, but I hope there are no apps left behind.

[1] https://developer.android.com/preview/privacy/package-visibi...

I'm guessing for replacement launchers and apps that launch other apps?

I'm happy with granting usage access to a launcher app, that can construct a 'recently used' app page.

The apps that tend to stay at the bottom of that launcher page are the ones I'd like to most consider removing.

Lots of games give bonuses if you have other games by the same publisher installed.

Lots of ad networks reward users for installing apps, I suspect many of these ad libraries are calling this API for that reason.

I just yesterday had a fitness app tell me that Google fit wasn't installed after I'd asked it to link up with Google fit. That was useful.

This is probably a longer answer than you were looking for, but here's an example from my experience of a legitimate use for this API, which may give non-Android developers some insight into the unholy mess the Android platform is.

Android allows apps to draw transparent or translucent windows that can receive touch events and then pass them through to the window underneath. This has legitimate uses, such as using a tinted window to change the screen's color temperature. But it also has malicious uses, such as logging keystrokes or tricking users into changing settings when they think they're tapping targets in a game. This is called tapjacking and it's been a problem on Android for years.

On any reasonable platform, it would be the platform's responsibility to fix this bug. On Android, apps have to fend for themselves. So if you want to protect your app from tapjacking, you have to add code to every window you draw that checks whether the touch events it's receiving were forwarded by another app. But since there are legitimate uses for forwarding touch events (such as changing the color temperature), you can't just block forwarded events, otherwise your app will stop working whenever a color temperature app is active. The best you can do is ask the user whether they're using another app that might be drawing on top of your app, and if so, whether they your app to respond to touches when the other app's on top.

Clearly this a horrible question to present the user with, since many users won't be able to give an informed answer. But the alternative is that all the user's keystrokes get captured by malware, so what are you going to do?

To reduce the guesswork for the user, you can ask the system's package manager for a list of installed apps that have permission to draw on top of other apps. If you show the user this list when asking how they want your app to respond, maybe it will help the user to make an informed decision. It's still pushing responsibility for a platform bug onto the user, but at least the user has some information on which to base their decision.

The irony here is that it would clearly be better for privacy if this package manager method were removed - but it's needed as a workaround for an even worse privacy bug elsewhere in the API.

Welcome to Android development. Hope you packed a sense of humor.

I have worked on an app which reward users for installing certain apps and signing up on them. The API helps in detecting whether the user has installed the app on the phone or not.