It used the “canOprnUrl” method if I recall correctly.
Apple locked this down less than a year later in iOS 10 where an app has to explicitly list which urls can be tested this way and there is a hard limit. Of course this goes through app review.
It's useful to be able to warn users that they've got an app installed that will conflict in this way, and suggest an upgrade/uninstall/warn them of poor behaviour.
EDIT: Should've read the paper first, looks like they used this
https://developer.android.com/reference/android/content/pm/P... and https://developer.android.com/reference/android/content/pm/P... provide a list of installed applications on the phone. These APIs are silent to the user.
The study analyzed apps available on the Google Play Store, and compared two lists of apps: Open-source apps (via https://androidtimemachine.github.io/), and non-open-source free apps (the top 500 free apps for each category in the play store). The non-open-source apps were the most common users of these APIs. Additionally, most of the time the callers of these APIs in non-open-source apps are advertising related libraries.
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 . Many of these use cases are being addressed with a more secure API, but I hope there are no apps left behind.
Of course, apps from the same developer should have access to alternative ways to share state.
The apps that tend to stay at the bottom of that launcher page are the ones I'd like to most consider removing.
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
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.
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.