Can I safely block Dalvik browser agent requests?

Praemon picture Praemon · Jul 6, 2016 · Viewed 10.4k times · Source

I've noticed that when users on Android-OS devices visit my site, there's constantly two requests happening on each page. The first is the normal browser, and the second is from "Dalvik". Example:

"GET / HTTP/1.1" 200 2126 "-" "Mozilla/5.0 (Linux; Android 5.0.2; SAMSUNG SM-G925F/G925FXXU1AOD8 Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/3.0 Chrome/38.0.2125.102 Mobile Safari/537.36" 1229 2802

"GET / HTTP/1.1" 200 2117 "-" "Dalvik/2.1.0 (Linux; U; Android 5.0.2; SM-G925F Build/LRX22G)" 546 8729

From my understanding of this, the first request is from the actual browser, and the other is from the virtual machine (Dalvik) running the browser. The problem is that the Dalvik request doesn't use the same cookies, and/or POST data, and this triggers errors server side. An example would be when a user registers an account. The normal browser sends through POST data, but the Dalvik request just does a GET on the action url. Similarly, if a user is logged in, Dalvik will try a GET on a permission based page, which may redirect it somewhere else because there's no session for it.

The user doesn't experience any real problems (from what I can tell), however, we notice the attempts in our error logging. So my question is: Can I safely block all access attempts if the browser agent indicates "Dalvik/..*"? Will there be any adverse affects for the user? Considering that the Dalvik-related requests aren't actually reposting the real data or carrying a session, it seems unlikely. But hoping someone with more experience with Android can provide some feedback on it, for example, should I issue a specific HTTP header/status code, like "401 Unauthorized" or "400 Bad Request"?

Any help would be appreciated.

Answer

ZiggyTheHamster picture ZiggyTheHamster · Oct 1, 2020

This happens whenever a browser/WebView cannot render a particular server response (maybe it's a PDF, or a streaming server, or whatever) and then triggers an intent to the operating system to open another application. The VM (Dalvik) is what handles this routing, and in the process, may download the file to the device so that the other application can access it (normally, applications cannot access one another's files, but the other application needs the file to render it).

Crucially, it downloads the file before launching the intent, and the file ends up downloaded twice: once by the browser to figure out it doesn't know how to handle it, and once by Dalvik so it can pass a file:// URL to an application you might or might not launch.