Web APIs, Android permissions and the switch in between
On a website, the browser asks the user for camera or location access and that is the end of it. In an app there are two gates. The APK has to declare the Android permission, and the app has to request it at runtime before the WebView is allowed to pass the page's request through. The builder handles both in its Permissions step (a Pro feature) — you only choose which capabilities the app should have. Choosing correctly matters in both directions:
- Too few:
getUserMedia()rejects withNotAllowedError,getCurrentPosition()calls its error callback, and unless your code handles those, the feature just does nothing. - Too many: Google Play's review asks why a recipe app wants the microphone, the Data safety form grows, and users see a permission prompt that erodes trust.
Reading the results
| Badge | Meaning |
|---|---|
| switch on | Your code uses this capability. Turn on the matching permission (Camera, Microphone or Location) in the builder's Permissions step, which is part of Pro. |
| works | Available in the app with no permission — clipboard writes, sensors, storage. |
| caveat | Works partly or depends on the device. Treat it as an enhancement, not a requirement. |
| not in WebView | The API exists in Chrome but not in Android's WebView. Feature-detect it (if ('share' in navigator)) and provide a fallback. |
The APIs that surprise people
Notifications. Notification.requestPermission() and Web Push are the most common "works on the website, not in the app" feature. A WebView has no notification system of its own; apps use native push instead, which the builder provides on Pro.
Web Share. navigator.share is undefined in a WebView even though it works in Chrome on the same phone. A share button written without a check throws and can take the rest of a click handler with it.
Downloads. A link with the download attribute, or a blob URL generated for an export, has no download manager to hand off to. The links and downloads doc covers what does work.
Speech recognition. The Web Speech API's recognition half is not implemented in WebView. Recording with MediaRecorder (Microphone permission) and sending audio to a speech-to-text service does work.
Limits of a static scan
The scanner matches source patterns, so it reads minified bundles fine but cannot follow code that is loaded at runtime from another server, and can occasionally flag a library that contains a capability you never call. When in doubt, search your own code for the API name, and test the feature on a phone in the built app.