Vet Your Manifest, Again

A couple of years ago, I warned you to vet the contents of your manifest. But, if you are like me, the past two years have felt like a decade. So, it’s not unreasonable to have forgotten the lessons from that blog post. Since a recent bit of news highlighted this problem again, perhaps it is time to revisit the topic.

What you ship in your app is your job to manage. That includes all the entries in the merged manifest. It does not matter whether the entries were added by you, by a library, or by a space alien 👽. If it is in your app, you own it and any problems it causes.

So, there’s this app. It is not a Web browser. However, as Kate McNamara pointed out, the app really wants to be a Web browser, offering to handle random URLs as an alternative to the user’s real browser.

The app has a splash screen, in the form of a SplashActivity. That activity’s manifest entry has the following <intent-filter>:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:name="http" />
</intent-filter>

If another app calls startActivity() for a matching Intent, and the user chooses to have this app handle it, this app will start up and show its SplashActivity. However, that is a very generic <intent-filter>, having little to do with the app or its maker.

This is not good.

Fortunately, it only honors the insecure http scheme. 🙄

Having an activity in your app that responds to your own domain name is reasonable. It is a key element of deep links, for example. But the <intent-filter> needs to be scoped to your own site using android:host on the <data> element. In this case, that was not done, to users’ detriment.

Every so often, scan through your merged manifest and ask yourself: do we need all this stuff? You might be scared by what you find in there.

And, um, don’t try to be a Web browser. Unless, y’know, you are writing a Web browser.