I ran into this with one of our customers today. I believe this actually has to do with the mime-type for the documents stored in Laserfiche. When you store an electronic document, Laserfiche also stores the mime-type, which is a kind of media type identifier that is used to determine the contents of a file and what application should be used to open it. The standard mime-type for a PDF is "application/pdf" although it could be something different depending on how your PDF was generated and imported. The documents causing a problem at the customer's site were set to a mime type of "application/octet-stream" which is a generic value for arbitrary binary data files.

What happens when you browse to the document in Weblink is that it passes this mime-type into the Content-Type response header when sending the document to the browser for download. Android browsers seem to be unsure of what to do with the file when it has this generic Content-Type header, and so it seems to ignore the recommended file name in the Content-Dispositrion header and does it's own thing. The file that gets downloaded (in this case "ElectronicFile.aspx") is actually the real PDF file, and if you change the file extension, you can open it and view it.

You can view the mime-type for documents in your repository by turning the column on in your repository browser (it is available in both the desktop client and the web products). Unfortunately, there is no good way to change this, unless you want to attempt to change it directly in the SQL tables for the repository. The longer term solution would be to try to identify what step in your process of creating/importing PDFs is the cause of the generic mime-type.