WEB APP GENERATOR configurations

The following configurations are available for WEB APP GENERATOR:

display_mode accepts standalone (system bars visible, no URL chrome), minimal_ui (slim toolbar with URL and refresh), or fullscreen (system bars hidden; pair with Keep screen on for kiosk and signage).

orientation accepts auto, portrait, or landscape.

respect_insets only matters in Full screen mode. Leave it on for devices with display cut-outs, camera holes, rounded corners or unusual system-bar behaviour. Turn it off only when the web experience is deliberately designed to use every pixel edge-to-edge.

When an opt-in permission is off, the underlying Android permission is not declared at all and the corresponding API call fails silently. When on, the runtime permission is requested the first time the page asks; users can revoke later via Android Settings without breaking the app.

Camera, microphone and geolocation also depend on normal WebView rules. The page should be served over HTTPS, must request the capability through the appropriate web API, and still needs the user to approve the runtime permission prompt. WAG can declare the Android permission; it cannot grant a website access without the normal browser-style prompt.

External links are locked to the registered host by default. With the toggle off, same-host navigation stays inside the wrapper, main-frame tel:, mailto:, sms: and geo: links can hand off to the relevant system app from a user tap, and off-host navigation is blocked. intent:// URLs and sub-frame escapes are blocked.

Trust user CAs is on by default for enterprise deployments where MDM-distributed root certificates, SSL inspection or internal certificate authorities are common. Turn it off for higher-sensitivity deployments where the wrapper should trust only Android's system CA store.

allow_pull_to_refresh wraps the WebView in a native swipe-to-refresh container. It only fires when the page is already scrolled to the top, so normal page scrolling continues to work.

screenshot_block applies Android's FLAG_SECURE. It blocks screenshots, screen recording and the live app preview in the system app switcher, but it does not prevent another device taking a photo of the screen.

user_agent is capped at 512 characters. Use it for legacy server-side routing only; modern responsive sites should normally detect capabilities rather than a custom string.

sign_mode accepts bayton (signed with Bayton's certificate, unique package name per build unless an update code is supplied), release (signed with the uploaded keystore), or debug (auto-signed with an Android debug key; sideload testing only).

output_format accepts apk (direct install via EMM push or sideload) or aab (required for upload to Managed Google Play; smaller per-device download after Play handles density and ABI splits).

Every build ships an exported web_app_config.json file alongside the APK or AAB. This is a portable copy of the build settings, including the update code, useful for auditing the deployment or re-importing into a future build.

The export captures URL, app name, theme colour, display mode, orientation, output format, signing mode, runtime toggles, user-agent override and update code. It does not include icon bytes, keystore files or signing passwords; those must be supplied again on rebuild.

Because the export contains the update code, treat it as sensitive. Anyone with that file can rebuild against the same package name while the package registry entry exists.

Every successful build also exposes a source archive containing the post-substitution Android project. This is useful when you need to audit what was compiled, keep evidence for change control, or rebuild independently.

The archive includes the generated Kotlin, XML, Gradle files and a small build metadata file. It does not include uploaded keystores or signing passwords. Debug builds work out of the box; release builds require signing.properties to be filled in from the included template.

WAG is primarily designed as a browser tool. API access is available, but not public; it can be enabled commercially for customers who need to integrate wrapper builds into CI/CD or other internal automation flows.

These are the service surfaces integration work would build around:

Download links are intentionally short-lived. Build artefacts expire after first access and are purged after the retention window, so keep the exported config and update code with your deployment records.