I’m trying to load a Google Drive document directly within my Android app’s WebView but running into issues. When I attempt to display the document, instead of showing it inline, my app presents a dialog asking which application to use for opening the link (like Chrome, default browser, or Google Drive app). The document opens fine when I select one of these external apps, but I want it to display within my WebView itself.
The problem occurs when users tap on certain elements within the loaded content. Instead of staying within the WebView, it triggers the system’s app chooser dialog. How can I force the Google Docs content to remain and function properly within my WebView without redirecting to external applications?
Been there with mobile WebViews and Google Drive integration. This issue’s super common - Google’s viewer loves redirecting users to native apps.
Your approach has a big problem though. You’re fighting Google’s intended flow, and they constantly change how their viewer handles embedded content.
I hit this exact same wall building a document feature for our mobile app. Instead of wrestling with WebView limits and Google’s redirects, I built automation that handles the whole document display pipeline.
The solution pulls docs from Google Drive, processes them through a viewer service, and serves them in WebView-friendly format. No app chooser dialogs, no redirect headaches.
You can set it up to:
Fetch documents from your Google Drive
Convert them to WebView friendly formats
Cache them for faster loading
Handle different document types automatically
This gives you complete control over user experience and kills the external app redirect problem.
You need a custom WebViewClient to stop those external app redirects. Google Drive links trigger Android’s intent filters, making the system think you want to open another app. Override shouldOverrideUrlLoading in your WebViewClient - this lets you control which URLs stay in your WebView instead of jumping to external apps. Without it, Android defaults to showing that annoying app chooser dialog. Also turn on setDomStorageEnabled and setLoadWithOverviewMode. Google Docs viewer needs DOM storage and proper viewport handling to work in WebViews. Here’s something I learned the hard way - docs.google.com/viewer can have auth problems depending on your document’s sharing settings. Make sure your Drive document has public viewing permissions, or the viewer will try redirecting to login pages that’ll break in WebView.
Google’s security model blocks Drive documents from loading in third-party WebViews. I ran into this exact issue building document preview for a corporate app last year. Google does this on purpose to keep control over their content. Here’s what worked for me: convert to PDF first. If you can access your docs as PDFs, try this URL format: https://drive.google.com/uc?export=download&id=YOUR_FILE_ID. Then load the PDF in WebView using AndroidPdfViewer or MuPDF. You could also try Google’s preview endpoint: https://drive.google.com/file/d/YOUR_FILE_ID/preview. Sometimes this works better than the viewer URL since it handles redirects differently. For production, I ended up doing server-side processing. My backend grabs the document and serves it through our own endpoint. Cuts out Google’s redirect mess completely and gives you full control over how users view the content.
Google Drive blocks direct embedding in WebViews - they want you using their apps instead. That app chooser dialog pops up because Android thinks you’re opening a Drive file that needs a specific handler.
I’ve been through this exact problem when we needed document previews in our mobile app. WebView tricks like custom user agents and shouldOverrideUrlLoading work sometimes, but Google keeps updating their blocking methods.
Stop fighting Google’s restrictions. Instead, grab your Drive documents and serve them through your own endpoint.
Here’s what works:
Connect to Google Drive API
Download your documents
Convert to HTML or PDF
Serve from your domain
Display perfectly in WebView
You control the entire chain, so no more redirect issues. No app chooser dialogs, no blocked content, no wondering what Google broke this time.
The whole document processing pipeline takes about an hour to automate.
WebView and Google’s ecosystem don’t play nice together - Google deliberately blocks Drive document embedding to keep control over their content and user experience. That app chooser dialog? It’s Android responding to Google’s redirects that push users toward their native apps.
I hit the same wall building an enterprise app. Your WebView config isn’t the problem - Google’s viewer service actually detects WebView environments and actively blocks embedding attempts.
Here’s what works better: ditch Google Drive for document hosting. Dropbox Paper or Box have WebView-friendly APIs that won’t fight you. Or set up a document conversion service that turns your Drive files into standard web formats first. This kills Google’s redirect nonsense and gives you complete control over viewing inside your app.
Enable mixed content in your webview settings and set a proper user agent string. Google Docs viewer blocks default Android webview user agents pretty often. Switch it to Chrome’s user agent - that’ll make the system think it’s a real browser instead of an embedded webview.