IssueTracker

So they can leave the app if they don't like what it is doing.  And there is no way
to enforce a permission on this.

"So they can leave the app if they don't like what it is doing."

That assumes they are still alive.

Android has the emergency call option available outside the lock screen for this very
reason -- expecting somebody to accurately enter their lock code in an emergency
situation is too much to ask. Similarly, expecting somebody to guess that the problem
is the app they are running (versus pressing the wrong button, or the phone/OS being
broken) in an emergency situation may be too much to ask. At least let them know that
there might be a problem here when they install the app.

"And there is no way to enforce a permission on this."

Would you care to place a wager on this?

Some piece of code, somewhere, is deciding to filter out KEYCODE_ENDCALL and
KEYCODE_HOME from the path that leads to onKeyDown() and kin. One would imagine that
there is some way to have that code invoke checkPermission() or the equivalent to
determine if android.permission.OVERRIDE_CALL_BUTTON is held and, if not, also filter
out KEYCODE_CALL.

I came across this post the other day, as a work around specifically for the
geocaching.com website.

http://forum.xda-developers.com/showthread.php?t=511487

Second it, very annonying especially for geocaching users.

Yeah, i came across this bug while downloading data from geachching.com too... it's
really annoying... is there a existing fix already??

Are there any news about this one? Is there a plan when this bug is going to be fixed?

This one should be easy to fix, low hanging fruit. I'm sure the devs could fix this
in no time.

Please anyone fix this bug! It makes Android unusable for geocaching :-(

Well, over half a year reported, and still tagged as New. What happens with
low-priority problems? Will they ever be fixed?

I think my contract is finished, before this bug (no, I don't think it is an
enhancement) is going to be fixed (if it ever will be).

My apologies for not getting to this sooner.

I filed issue 36909334 and issue 36909335 to track the aspects that are specific to the
download manager. This issue can be used to track the browser-side work.

I just want to make a note that GeoBeagle and GCDroid both have workarounds for
geocaching.  You can click on the link to Google Maps from the Geocaching.com page
and it will import into either of the apps.

To add on to dan's comment, Geodroid also uses the workaround by clicking the Google
Maps link.

@dan.fitek
I believe the work-around you mention will give you a .loc file rather than a .gpx
file.  Or at least will give you a stripped down .gpx file.  Either is wholly
inadequate because the downloaded file only contains coords, not the detail that you
need while searching for a geocache.

For geocachers, this bug means that one cannot download the full .gpx file.

GeoBeagle lets you click on the Google Maps link on the cache page, which just puts
the coordinates into GeoBeagle to allow it to display on the map.

If you want a solution for being able to download the GPX file from the GPX button, I
built a workaround a while back that works perfectly; I just have to get off of my
lazy butt and do something with it...

Continuing Off-Topic,
@DevonSumner
GCDroid gives you a full GPX, as long as you are a premium member.
It does not scrape the site, it downloads the file 'correctly'.

@bnelsontfs
I'd love to see what you have.  Please post here or email to me @gmail.com.  Thanks.

CacheMate uses the Google Maps link workaround as well but, as Devon points out,
that's not the point.  Not being allowed to screen-scrape, per the site's ToS, means
you can only use what's in the link URL, and that's even less info than you would
find in a .loc file (only the waypoint ID and coordinates, no cache or owner name).

There's definitely been a lot of fussing about this problem in the geocaching forums.

Bump, I don't geocache but still get errors trying to download items from sites using php
forms.  Any progress on this?

The bug has been assigned to an engineer and designated for a future release.

Ats great but any indication of a timeframe or word of it coming soon?

What the Hey,  Is this going to be fixed anytime soon?

James.Polka: I wish I could give you more information about Android's development and release schedules, but
this forum is limited to bug reporting.

Over on issue 36906968 jbq said that the fundamental issue is "that the browser needs to
hit the server to determine that something is a download, and that the download
manager has to separately contact the server".

I've noticed that if the initial request (from the browser) is:

  GET /foo.html?foo=http%3A%2F%2Fwww.example.com%2Fbar.html HTTP/1.1

then the second request (from the download manager) will be:

  GET /foo.html?foo=http://www.example.com/bar.html HTTP/1.1

i.e. the percent-encoding has been undone. In my case, this causes the server to
return very different data. Is this a separate bug?

Yes, this is a separate bug. I'll file it separately internally. If you file a separate bug externally, I'll hook the two
of them together. Thanks

I've filed it as issue 36915848. Thanks.

Plz fix this bug.  We need to be able to dl .gpx files.  The nice weather is here!

Use c:geo on android. It downloads the cache information and logs back to the website.

This is still a problem on 2.2, at least in the "leaked" Nexus One build.

@LynJar:
If you want to run afoul of Geocaching.com's terms of service, then sure... go that route.  Not wanting to do that is a big reason that everyone is so interested in getting this bug (not enhancement) fixed.

Anxiously waiting for a solution

The bug is still not fixed in 2.2.1 . Though *sometimes* the file DOES download, most of the time I will get two request for the data which interfere and corrupt the download or lead to premature cancellation of the download.

If a form POST in the browser results in the download manager trying a GET to the same URI but without the form parameters, you'd be hard pressed to explain to me how that's not a bug.  At a minimum, reporting to the user that the download failed is a bug, instead of blocking the download manager from ever starting and telling the user it's a platform deficiency.  For the record, my interest in this isn't for geocaching, for me it's a crippling issue for a mobile corporate site currently in development, and will likely cause us to abandon support for Android devices if there's no fix in sight.

Still no fix after two years? This is an extremely crippling bug and should be high priority. This breaks every website that serves unique content based on POST data.

just discovered this issue with the GPX files ... shocking that this has not been fixed after 27 months.

Agreed, this is getting ridiculous

[Comment deleted]

this impacts ePUBs that are dynamically generated by post variables whose content EXCEEDS get usability.

I'm trying to write an app for a travel site that generates itineraries based on data posted from travel agencies, returning the itinerary as an XML document.  Opera works, downloading the document and firing up my app to read it, but I'm loathe to make Opera a requirement for the app. The stock browser should work properly.

We are caching files on the server for the sole purpose of supporting downloads from the android browser. I would have liked to just drop support for this browser, but users don't really understand enough about how browsers work to know that the problem is with the android browser and would probably just think our web app is broken.

Someone should really fix this. This a BUG, not an enhancement.

I have the exact same problem

My ERP .NET web app uses a form post to download an attachment from within a .NET DDL control.  On all platforms, the file downloads just fine, except on the Android.

I just spent 4 days LAN tracing, tearing my .NET web app down to bare minimums and spot debugging my Javascript to find out what *I* must be doing to cause this problem.  A LAN trace showed that my POST request for the download triggered an http response for the download, yet after a few packets, my Droid sent a FIN and RST and the download was cancelled.  Then a new GET request was issued with the same URI followed.  It turns out that the partially downloaded file is populated with the HTML as a result of the 2nd GET!  Weird!

I'm not angry, I just wanted to relay my experience and show that this bug is causing pain.  Also,  it is unfortunately forcing my hand when an employee is going to get a new smart phone and they ask "Droid or IPhone?".  Using the Droid platform, no-one can download attachments using my ERP web app.

Please address this problem as soon as possible.

This problem is such a big show stopper that it makes a related article in my blog having as many views as all other articles together!

For the time being the only reliable way to make downloads work from scripts that need to receive parameters, is to NOT transfer the parameters by POST, but by GET or by RESTful URLs (encoding all needed data for the HTTP request within the URL itself).

See http://digiblog.de/2011/04/19/android-and-the-download-file-headers/ for more details.

Cheers, Jörg.

When can this be fixed?  With 100 million Android phones out there, it would mean that millions of users daily are inconvenienced when they click a link to download a text file.

Thanks.

@kingkong:

Simple download links will usually work. The problem affects downloads that are initiated by a POST, e.g. a form that is sent using a POST request and in turn returns a downloadable file.

But you are right. It is unbelievable that this issue is still not fixed (and also that it is classified as an "enhancement" instead of as a "bug" - which is simply outrageous).

But then again: Until today not a single iPhone in the world is capable of adding a contact to its internal database, if the user clicks a link to a VCF file. They have to receive the VCF by email to process it correctly.

A world of ugly imperfections...

Just curious if this issue has fallen off the face of the earth? Basically, I have a web application that allows the client download zip files which of course works in every browser but the stock android browser! While the solution seems to be either use a different browser or upgrade the device to ICS, this is not acceptable for our clients. Any help would be appreciated!

Come on Google. 3 years, and we still can't download a file initiated by a POST?

Surely something that works in every other browser is a BUG, not an enhancement.

[Comment deleted]

Any hopes for this issue to be fixed?? I am experiencing this issue both in my HTC Desire HD and Galaxy Tablet 10.1

My company has developed a webapplication for work orders where one of the features is the ability to access all kinds of documentation about the job at hand from the smartphone. Up til now we have thought that this problem was due to some bug in the third party components we use for development and have gladly endorsed Android phones to around 2000 users (and counting). Since installing another browser for this functionality seems absolutely ludicrous (not to mention an inconvenience to our users and possibly a bigger workload for our support department) i regret we won't have any option but to recommend some other system until this get fixed. This is not just a problem for geocaching hobbyists. It's hurting our business and, ultimately, yours.

Regards

Sören Alexandersson
Svensk Dataförvaltning AB

Apple can't be better than Android. Download runs under Apple and even Microsoft but not Android... Please fix this!!!

Very big problem................

I'm developing an app that is running into this problem. It is NOT an enhancement.
This is a bug and should be fixed.

When I use Stock browser and Chrome(on JB and ICS), I download an index.php file.
The file itself is still the PDF file it is supposed to download, BUT it is not creating the proper name or extention.

Dolphin is now working properly. It looks like they have their own download manager that pops up, and then verifies the filename and location.

This is a BUG, not an enhancement.

Please fix this Andriod. We just re-verified this problem today.

It is a serious problem that.

[Comment deleted]

Hello,
seconding this also.
I encountered this issue about 1 year ago. Decided to wait see if it got solved. no luck. I'm back today looking on the web for a solution, still there's none provided. I guess Android's shares (and holders) don't suffer from this bug and sales are still fine. We may be waiting in vain.

[Comment deleted]

So, based on the status, this will nto be fixed?
Why? :|
What the hack are we supposed to do?
Change our implementations and our security policies (that work everywhere else but Android) just because Google doesn't want this fixed?

I don't know the reason for the Obsolete status of this issue. Why??

Download runs under Apple and even Microsoft but not Android... Please fix this!!!

I cant open my phone
Somting wrong
Com.android.systemui = stop