Handling MIME type that is the result of a browser

2019-02-16 02:47发布

问题:

I have an Activity that is successfully invoked for the MIME type in which I'm interested. The content being sent from the server is an XML document created as the result of a POST. I've tried to process the result two different ways and I'm not having luck with either:

  1. android:mimeType="application/customapp" Doing this, my activity runs, but the URI I get from Intent.getData() is the URL used for the post. A call to getContentResolver().openInputStream() results in java.io.FileNotFoundException: No content provider: http://.... Obviously, just hitting that URL won't work as I don't have the posted data.
  2. android:pathPattern=".*\custom.app" The last segment of the URL is custom.app, so I tried using that with a path pattern. This way, the browser attempts to download the document and one of two things happens: The stock browser attempts to download "untitled" and fails. Opera downloads the document, naming it as hoped, and will offer to open the file, which works, but Opera Mini does nothing but download the file.

Here is the relevant section of my manifest with the scheme in:

<application android:icon="@drawable/icon" android:label="@string/app_name">
    <activity android:name=".CustomappActivity" android:label="@string/app_name">
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:mimeType="application/customapp" />
            <data android:scheme="http" />
            <data android:scheme="https" />
        </intent-filter>
    </activity>
</application>

I'd like to use the first option, but could put up with the second even if it required Opera, but only if it worked consistently across both versions of Opera. I just can't see a way to get an input stream for the result being sent from the server.

回答1:

I'll answer my own question. Apparently, I'm screwed. There is a known issue with the stock browser and the way it interacts with the download manager. At this time, it cannot retrieve documents that are sent as the result of an HTTP POST. The bug is detailed here