Hacker News new | past | comments | ask | show | jobs | submit login
How Android developers access installed apps on user’s device [pdf] (ivanomalavolta.com)
119 points by Fragoel2 14 days ago | hide | past | web | favorite | 25 comments

iOS had a similar leak that was exploited by apps like Twitter.


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.

Previously in Android app development, the application sandbox has been sufficiently leaky that if a user has another app installed, it can cause problems for the app being developed.

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.

It is useful yes, but so is massive surveillance. That doesn't make it a good thing.

Adblocking apps in particular have been known to break other apps on the same Android.

If I wanted to do similar research to this, can anyone share a good method for obtaining a large corpus of apps like these researchers presumably did?

EDIT: Should've read the paper first, looks like they used this https://androzoo.uni.lu/

I'd love to read a condensed version


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.

Installed apps list is available through IAMS API, Devs use this to profile users.

Interesting, what are the legit (if any) reasons this info is exposed via that API/endpoint?

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...

> Think Facebook and Messenger: two separate apps.

Of course, apps from the same developer should have access to alternative ways to share state.

Wait, is this sarcasm or not? If not, bypassing malware filters by spreading the parts over multiple apps with 'friendship' access rights to each other sounds like return-oriented programming with extra steps.

The number of "gadgets" in this case is very small, and most protections should work at the developer ID level anyways.

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.

you could achieve the same without in-app purchases or this API if you are in control of both apps. You could for example sign the app with the same key and gain privileges by that over your other apps if i recall correctly and if its still true.

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.

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

Not sure I'd trust self-identification to weed out malware..

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.

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

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

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.

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.

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

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact